AI修过一次漏洞还会再犯吗？关键不只是“记住”
内容提要
GitHub 让 Agentic Autofix 读取 Copilot Memory，复用成功修复模式，以减少同类漏洞的重复解释，但风险从单次补丁正确性扩大到旧经验是否仍适用。作者主张记忆单位应为“规则＋证据＋失效条件”，需经提出、验证、批准、使用、复查、撤销六阶段，并限定仓库级、绑定回归测试与失效日期，否则不应自动影响补丁。
延伸解读
记忆复用如何扩大风险半径
GitHub 让 Agentic Autofix 读取 Copilot Memory 并保存修复模式，这减少了同类漏洞的重复解释，但风险从单次补丁正确性扩大到旧经验是否仍适用。代码、依赖和威胁模型会变化，没有来源与有效期的旧经验可能把已修复的模式重新引入。因此，记忆的单位应是“规则＋证据＋失效条件”，而非一段自然语言结论。
最小治理门禁的实践要点
文章给出的纯 Python 示例演示了治理逻辑：规则必须带来源提交、测试名和到期日，过期或未被当前测试集覆盖的记忆不会进入提示上下文。真实系统还应验证提交签名、规则适用目录、依赖版本和测试结果来源。这提示团队，记忆进入提示前需经过可验证的门禁，而非直接信任。
记忆生命周期与撤销能力
一条修复经验进入共享层前，应经历提出、验证、批准、使用、复查、撤销六个状态。撤销尤其重要，例如仓库从自建会话迁移到托管身份后，过去关于 Cookie 的安全模式可能不再适用，系统应先标记停用并观察新补丁是否仍引用，而非直接删除痕迹。冲突时按目录范围、依赖版本和最近验证时间选择，无法消解则退回人工审查。
落地时的四个约束
文章建议落地先做四件事：把记忆限定在仓库级；要求每条规则链接到修复 PR 与回归测试；设置责任人和失效日期；每次依赖大版本升级后重跑记忆对应的测试。若无法回答“谁证明过、在哪适用、何时失效”，就不该让它自动影响补丁。这强调可审计、可撤销的经验层比记忆长度更重要。
Q&A
GitHub 的 Agentic Autofix 和 Copilot Memory 是如何配合工作的？
启用 Copilot Memory 后，Agentic Autofix 会读取已有记忆来辅助解决安全告警；创建修复后，系统会保存修复模式，供以后处理相似告警，并可被代码审查、云端 Agent 等功能使用。两者目前都处于公开预览。
为什么记忆能提高漏洞修复质量？
漏洞修复常涉及仓库特有的局部约束，如数据库访问必须经过特定封装、配置文件需同步修改等。通用模型不知道这些事实，容易生成破坏项目边界的补丁。记忆把局部约束带入下一次推理，相当于给新来的安全工程师一份值班手册。
作者认为记忆应该以什么为单位？为什么？
作者主张记忆的单位应是“规则＋证据＋失效条件”，不能只保存一段自然语言结论。因为代码、依赖和威胁模型都会变化，没有来源与有效期的旧经验可能把已修复的模式重新引入。
团队在落地记忆治理时，可以先做哪四件事？
落地时可先做四件事：把记忆限定在仓库级；要求每条规则链接到修复 PR 与回归测试；设置责任人和失效日期；每次依赖大版本升级后重跑记忆对应的测试。
记忆可能带来哪些风险？官方公告披露了哪些信息？
风险包括：被复用的经验可能不再正确、临时补丁被当成最佳实践、攻击者通过文档或注释植入伪规则等。官方公告没有披露记忆检索排序、冲突消解和误用率，因此不能据此声称 Autofix 的漏洞修复率已经提高。
一条修复经验进入共享层前，应该经历哪些生命周期阶段？
至少应经历“提出、验证、批准、使用、复查、撤销”六个状态。提出阶段保留告警类型、受影响路径和补丁链接；验证阶段绑定回归测试；批准阶段由代码所有者确认适用范围；后续每次使用都记录命中规则、是否被采纳及测试结果。
