GitHub Issue能放计划书了：让工作背景不再埋在评论里
修复代码在PR里，为什么这样改却可能藏在很早的聊天中。如果代理的调查结果也放在别处，接手的人就容易重复调查。GitHub在10月28日推出Issue artifacts公开预览，让这些资料直接关联到对应的Issue。
对话和持续更新的文档各有作用
资料可以是Markdown文档、外部链接或HTML文档，例如根因分析、原型、Slack和Teams讨论。在github.com上可以创建、编辑并保留版本历史。它与GitHub Actions运行产生的构建产物不同，不要把两种artifact混为一谈。
假设有一个重复扣款的虚构故障。评论记录新观察，计划书整理重试键的处理和待验证实验。第一张图是为本文自制的示例，不是GitHub界面。把观察、假设和实验分开，有助于避免代理将猜测当作确定需求。
挂上一份文件，再持续维护同一份背景
gh issue artifact create在Issue编号或URL后接文件或链接。gh issue artifact create 42 retry-plan.md -R OWNER/REPO会把文件附到指定仓库的Issue 42。仓库和编号都是占位值，执行会写入Issue；本文没有实际运行。
名称可来自文件名，也可用--name指定。--body-file读取单份文档内容，--attach支持图片和视频。gh issue artifact edit 42 1 --body-file retry-plan.md -R OWNER/REPO可替换内容。第二张图是命令语法示例，不是上传成功日志。
保留最新计划，也留下变化原因
edit可改名或替换内容，但不改变资料类型。--restore-version把旧名称和内容保存为新版本，view可显示编辑历史。这样既能维护当前计划，也不必抹去形成判断的过程。
在扣款示例中，调查可能从网络超时转向重复键处理。更新计划并链接解释原因的评论，是一种文档组织建议，不是产品自动行为。附件本身不能证明代码正确，结论附近仍需放置证据。
HTML支持取决于使用入口
公告描述了HTML渲染预览和源码切换，但GitHub App内创建、查看HTML仍标注为即将推出。会话产物自动附到Issue，不代表所有入口都完整支持HTML。CLI也处于预览阶段，语法和行为可能调整。
这次变化的价值在于背景资料的位置，而非文档数量。可以先关联已有的一份计划，再在下次修改时延续历史。当前支持范围以官方公告和CLI文档为准。