AGENTS.md 优化与死代码清理提示词合集
整理 AGENTS.md 优化、死代码清理与实验审计的可复制 Prompt，附 OpenAI 大规模清理案例。
原始内容
很有用的最佳实践！AGENTS.md的优化几乎每个人都能用到。 我挑了文章里面几个常用场景，把prompt贴过来了，方便大家直接复制带走： 1. 科学优化你的 AGENTS.md Prompt: 查看我最近的 Codex 会话，找出一条似乎误导了智能体或导致不必要工作的 AGENTS.md 指令，并选出发生该问题时的原始用户提示词。 使用相同的代码仓库快照和模型，将该提示词重新运行两次： 保持当前 AGENTS.md 指令不变。 仅删除或修正那一条指令。 比较两次运行的任务完成质量、智能体行为、工具调用、Token 用量、运行时间和费用。展示这条指令，并说明修改它是否带来了改善。 2. 清理死代码 Prompt: 帮我识别并清理仓库中的死代码，你可以自由检查 Slack、Statsig（AB实验平台）或任何其他你需要的来源，以确认这些内容确实不再使用，并且可以被清理或简化。 3. 全仓库实验审计与 CPU 成本优先级排序 Prompt: /goal 找出整个代码库中所有过期、固定不变、已废弃或已全量发布的 Statsig 门控、配置、实验和图层，确保它们可以在不影响生产环境的情况下被安全移除。审计所有的 Statsig 项目和清单，而不仅仅是标记为过期的对象。 找出通过枚举、常量、包装器、别名、模式、动态拼接名称以及跨服务消费者进行的间接调用。核对每一个在生产环境中被引用到的常量；不要仅仅生成一份保守的简短列表就停止。 考虑每个对象的云资源使用情况（包括 CPU）。在可用的情况下利用生产环境遥测数据和性能分析文件来识别高开销的无效检查。 生成一份 Markdown 报告，将所有验证过的清理候选项按可并行处理的归属团队/文件工作流进行分组，包含生产环境的值、证据、负责人、调用点，以及观察到的评估开销或 CPU 成本（如有）。不要修改线上配置或服务。
OpenAI 一个团队用 GPT-6 Astra + Codex 清理废代码，5 个工程师利用两周业余时间，合并了 1400 多个 PR，删掉 80 多万行代码。 他们还用 GPT-6.1 Sol 优化 CI，把中位耗时从约 10 分钟降到 4.5 分钟。 清理废代码的原始 Prompt 也公开在文章里了 👇 https://t.co/UDWPyoFtwl
深度解析
是什么 这是一条策展式推文，把一篇「AGENTS.md 最佳实践」文章中的三条可直接复制的 Prompt 摘出来，并附上一条引用：OpenAI 团队用 GPT-6 Astra + Codex 在两周业余时间合并 1400+ PR、删除 80 多万行死代码，并用 GPT-6.1 Sol 把 CI 中位耗时从约 10 分钟降到 4.5 分钟。
核心设计 三条 Prompt 对应三种工程场景：①单变量对照实验——锁定仓库快照和模型，只删除/修正一条 AGENTS.md 指令，重跑同一用户提示，比较完成质量、工具调用、Token、时间与费用，把「配置优化」变成可度量的 A/B 测试；②死代码清理——允许智能体自由查阅 Slack、Statsig 等来源做使用性取证；③全仓库实验审计——用 /goal 明确目标，要求覆盖所有项目而非仅标记过期项，追踪枚举、常量、包装器、别名、动态拼接等间接引用，并结合生产遥测与 CPU 成本排序，最终产出可并行的 Markdown 报告，且明确不修改线上配置。
关键洞察 提示词的杠杆不在措辞华丽，而在「限定变量 + 要求证据 + 约束动作边界」：选定单一改动、要求核对每个生产引用而非提前收敛、用遥测数据量化成本、显式禁止改线上。这套结构让 Coding Agent 的产出可复核、可分工、可回归。
边界与风险 原文的 1400 PR、80 万行等数字来自引用推文的转述，缺少一手来源校验；仓库快照一致性、模型版本漂移会让对照实验的可比性打折；实验门控的「可安全移除」判断高度依赖遥测覆盖率，未被埋点路径可能被误删。因此审计报告与真实删除之间仍需人工复核与灰度。
精选追评与案例
补充全量审计中处理动态引用不确定性的可操作边界与断点续查方法。
@thomaszhou_ 做这种全量审计时，遇到动态拼接等拿不准的引用，可以单独记为待核实状态和阻塞原因，别直接当成可清理。把检查点和证据缺口持久存下来，下次就能直接接着往下排查。 https://t.co/gFWT47QY1Z
给出 AGENTS.md 行数、任务成功率等实测参数，并提示规则版本漂移风险。
AGENTS.md 这招很实用。补一个我们验证过的数字：写到 400 行的时候 agent 反而开始忽略它，砍到只剩「构建/测试命令 + 三个不能碰的目录」之后，20 条真实任务的成功率从 11 条涨到 17 条，模型一点没换。另一个坑是规则会随版本漂——我们会在每个 skill 里记一行版本号，升级 CLI 先用它跑一遍冒烟测试，不然参数被改名、脚本静默忽略，能跑一整晚白干。你们现在多久回头清理一次 AGENTS.md？
提供只删不加、删除须附拦截证据、每周人工看 diff 的可复用约束流程。
让 agent 自己审 AGENTS.md 这招好用，但会矫枉过正：它会倾向于把"看着啰嗦"的规则全砍掉，包括那几条真正拦过事故的。我现在的做法是只允许它删、不允许加，而且每条删除必须附一句"这条最近一次拦住了什么"；每周跑一次，人工只看 diff。跑了一个月，文件从 400 行降到 40 行不到，踩坑反而少了。你那边是让它自由改，还是也设了这种单向约束？
纠错并划清实验门槛、冻结复跑与回退边界，强调两类审计证据不可混用。
@thomaszhou_ 对照实验还不是闸门。删掉那条指令后，完成质量没升、工具调用和费用也没降，就别改 AGENTS.md。升了也先冻结新文件，用原提示词再跑一遍，对不上就回退。死代码和门控审计不能当成同一类证据。