提示词的作用？
提示词：
（1）不懂不明白不清晰不明确的，随时问我
1、你又犯这个错了，把这次的教训写进 CLAUDE.md，以后别再犯。
2、拷问我这些改动，我答不上来，你就别让我提 PR。
3、把这个报错的根本原因修掉，不要打表面补丁，修完验证一遍真的能过。
4、以你现在知道的一切，把刚才这版推倒，重新写一个优雅的方案。
5、先进入计划模式，只出方案，一行代码都不准碰。
6、你是一位资深工程师，把这份开发计划狠狠审一遍，把所有隐患都给我挑出来。
7、别硬改了，停下来，回到计划模式重新规划。
8、动手写方案之前，先把代码库里能复用的函数摸一遍，别重复造轮子。
9、对比 main 分支和这个分支的行为差异，证明你没有改坏任何东西。
10、先去看老功能是怎么实现的，摸清它的套路，再照着同样的方式做这个新功能。
11、我先讲一遍我对这块代码的理解，你来追问，把我没吃透的地方都问出来。
12、（把报错信息整段贴进去，然后只说一个字）修。
13、画一张架构图，帮我快速看懂这个代码库的整体结构。
14、给这个任务建一个笔记目录，每次提交完代码就把进展更新进去。
15、这个任务比较复杂，多开几个 subagent 并行去做。
16、我想做一个新功能，先别写代码，访谈我，把实现方式、交互、边界情况全部问清楚。
17、审一遍我还没提交的改动，把所有看着有风险的地方标出来。
18、如果我删掉这个函数，哪些地方会炸？
我自己最近用得最多是：「开一个 subagent，帮我检查 xxx 的问题」，因为 subagent 是独立上下文，不会被主 agent 的上下文污染，检查和评估的结果反而更客观，而且也可以保持主 agent 的上下文干净不膨胀。
上下文混乱太长时变笨：开一个子agent，联网搜索
这些提示词怎么样？这些提示词本质是在解决agent或者llm的什么问题？
阅读说明
这篇笔记整理 18 条 Coding Agent 指令，讨论它们分别针对什么问题、何时有帮助，以及还需要哪些验证。重点包括需求澄清、代码库理解、根因修复、独立审查和长任务中的目标保持。提示词可以约束协作过程，但不能单凭措辞保证实现正确，也不能让有限测试证明所有情况都没有问题。
核心结论
它们不是普通的“让模型写得更好”的提示词，而是一套简化版的 Agent 工程治理机制。
它们主要在解决六类问题：
- 需求不明确时擅自补全
- 没理解代码库就急着动手
- 只修表象，不找根因
- 写完即宣布成功，缺少验证
- 同一上下文里的确认偏误
- 长任务中的上下文衰减与目标漂移
换句话说，它们是在把一个容易“凭感觉向前冲”的模型，约束成一个按软件工程流程工作的工程师。
这些提示词分别在解决什么
逐条评价
1. 把教训写进 CLAUDE.md
有效，解决的是 模型没有可靠长期记忆的问题。
但要注意：
-
教训应写成可复用规则，而不是记录一次事故。
-
应包含“触发条件、正确行为、验证方式”。
-
不要每犯一次错就追加一条高度重复的规则，否则文件会膨胀并产生规则冲突。
-
不同工具读取的项目指令文件可能不同，例如有些系统使用
AGENTS.md，不能假设所有 Agent 都会读取CLAUDE.md。
更好的表达是：
先总结这次错误背后的通用原因，检查现有项目规则是否已经覆盖；如果没有，用一条可执行、可验证、不重复的规则补充进去。
2. 拷问改动，答不上来就不提 PR
非常好，解决的是：
-
用户没有真正理解 AI 生成的代码。
-
Agent 把“代码能运行”误认为“代码可以维护”。
-
人类在不知情的情况下承担合并责任。
不过“答不上来就绝不提 PR”可能过于绝对。更实用的是规定必须能解释：
-
为什么这样改。
-
数据流如何变化。
-
有哪些边界情况。
-
测试覆盖了什么。
-
如何回滚。
-
哪些地方仍然不确定。
3. 修根因并验证真的能过
这是最重要的一类提示词，针对 表面修复倾向。
建议把“验证”具体化：
- 先稳定复现原问题。
- 给出根因链路。
- 添加能够在修复前失败的回归测试。
- 实施修复。
- 运行相关测试与更广范围测试。
- 确认没有通过屏蔽错误、放宽断言或吞掉异常来“修复”。
否则 Agent 可能把“命令退出码为 0”当成根因已解决。
4. 推倒重写优雅方案
适合已有实现明显受错误假设影响的情况，解决 锚定效应和沉没成本。
风险是模型可能误解成“删除所有已有成果”。最好要求：
-
先列出现方案中值得保留的部分。
-
再说明哪些假设已经失效。
-
给出新旧方案比较。
-
获得确认后再替换实现。
5. 计划模式，一行代码不碰
非常有效，是明确的 阶段门禁。
它阻止模型把“思考方案”和“修改代码”混在一起。适合高风险、跨模块或需求尚未稳定的任务。
计划中最好强制包含：
-
已知事实。
-
尚未确认的信息。
-
涉及文件和模块。
-
可复用能力。
-
风险与回滚方式。
-
测试与验收标准。
6. 资深工程师狠狠审计划
这是典型的 对抗式审查，解决方案阶段的确认偏误。
为了避免只得到泛泛而谈的风险清单，可以要求每个问题包含：
-
严重程度。
-
触发条件。
-
影响范围。
-
证据或代码位置。
-
修改建议。
-
是否阻塞实施。
7. 停止硬改，重新规划
这是很好的 止损提示词。
Agent 常见问题之一是：第一次路线不对后，继续在错误架构上打补丁。该提示词强制终止这种局部修补循环。
8. 先摸可复用函数
非常实用，解决 代码库理解不足和重复造轮子。
还可以进一步要求检查：
-
公共工具函数。
-
相邻模块。
-
测试辅助代码。
-
类型定义。
-
已废弃但仍在使用的接口。
-
同类功能的调用路径。
9. 对比 main 与当前分支行为
方向很好，但“证明没有改坏任何东西”在严格意义上通常无法做到。
测试只能证明“已覆盖范围内没有观察到回归”，不能证明所有可能输入都安全。更准确的要求是：
-
列出预期行为变化。
-
列出应保持不变的行为。
-
对两分支运行相同的测试或样例。
-
对输出、接口、性能和错误行为做差异比较。
-
明确仍未覆盖的风险。
10. 模仿老功能的实现套路
很强，解决 不符合项目惯例的问题。
这比只说“遵循最佳实践”更有效，因为代码库自己的错误处理、依赖注入、测试组织和命名习惯，通常比抽象的行业最佳实践更具体。
但需要允许 Agent 指出现有模式本身是否存在明显缺陷，避免机械复制历史债务。
11. 让 Agent 追问你的理解
这是很好的 苏格拉底式学习。
它不只是检查你记住了什么，而是在暴露：
-
因果链断点。
-
模糊概念。
-
隐含假设。
-
无法解释的边界情况。
-
“知道怎么用，但不知道为什么”的部分。
最好要求 Agent 不直接讲答案，先通过递进问题定位认知缺口。
12. 贴报错后只说“修”
在上下文完整时很高效，但本身不是高质量需求，而是一种 授权 Agent 自主调查的简写。
它能否奏效取决于 Agent 是否拥有：
-
完整报错。
-
代码库访问权限。
-
可复现环境。
-
测试运行能力。
-
修改权限。
报错信息只描述症状时，Agent 仍然应该先调查，不能仅根据堆栈最上层直接打补丁。
13. 画架构图
很好，解决 代码结构难以内化的问题。
高质量架构图应该基于实际代码，而不是根据目录名猜测，并标出：
-
入口。
-
核心模块。
-
数据流。
-
外部依赖。
-
状态存储。
-
关键调用方向。
-
当前任务会影响的位置。
14. 建笔记目录并持续更新
适合长周期任务，属于 外部化工作记忆。
价值包括：
-
跨会话恢复上下文。
-
记录关键决策。
-
避免重复调查。
-
让提交与需求建立对应关系。
风险是笔记变成流水账。建议只维护少量固定文件，例如：
-
README.md：当前状态和下一步。 -
decisions.md：重要决策及理由。 -
verification.md：测试和验证证据。
15. 多开几个 subagent
适合可以清晰拆分的复杂任务，例如：
-
一个调查现有实现。
-
一个分析依赖和影响面。
-
一个设计测试方案。
-
一个进行独立审查。
不适合多人同时修改高度重叠的文件，否则会引入协调成本、重复劳动和冲突。
关键不是“多开”，而是让每个 subagent 拥有：
-
独立、边界明确的任务。
-
明确输入。
-
可验证输出。
-
不重叠的修改范围。
-
最终由主 Agent 统一核对结论。
16. 先访谈再开发
非常好，解决 需求空白被模型自行填充的问题。
访谈至少应覆盖：
-
用户目标。
-
核心流程。
-
交互反馈。
-
权限。
-
空状态。
-
异常状态。
-
数据规模。
-
兼容要求。
-
边界情况。
-
验收标准。
-
明确不做的内容。
17. 审查未提交改动
这是非常实用的提交前质量门。
应该检查的不只是语法，还包括：
-
意外改动。
-
调试代码。
-
敏感信息。
-
错误处理。
-
兼容性。
-
性能退化。
-
测试缺口。
-
注释与实现不一致。
-
与需求无关的范围扩张。
最好要求按严重程度排序，并提供具体文件和代码位置。
18. 删除函数的影响分析
这是 变更影响分析。
Agent 应检查：
-
直接调用。
-
间接调用。
-
重导出。
-
动态调用。
-
配置引用。
-
测试引用。
-
插件或公共接口。
-
文档与示例。
-
运行时反射或字符串调用。
需要明确的是，静态搜索未发现引用，不等于运行时绝对没有依赖。
它们本质上在补偿哪些 LLM 缺陷
客观事实
1. 没有天然的长期学习机制
普通对话中的一次纠正，不会自动成为后续所有任务的永久规则。把经验写进项目指令或任务笔记，本质上是在构建 外部记忆。
2. 输出具有概率性
LLM 生成的是当前上下文下较可能的后续内容，不是先构造完整证明再输出。因此它可能给出看起来合理、实际没有验证的答案。
3. 上下文容量有限
上下文越长，信息虽然仍可能存在，但重要规则、早期决策和局部细节更容易被后续内容稀释。这通常被称为 上下文衰减、注意力稀释或 “lost in the middle” 类问题。
4. 测试无法证明绝对正确
Agent 可以通过测试提供证据，但有限测试只能覆盖有限路径。因此“验证通过”和“证明绝无回归”不是同一件事。
基于事实的分析
1. 模糊需求下的自动补全
LLM 的强项之一是补全缺失信息，但在软件工程中，这也可能成为缺陷：它会把一个合理猜测悄悄变成实现决定。
所以第 0、11、16 条是在建立 歧义处理机制。
2. 过早行动
Agent 往往倾向快速产生可见进展，例如立即修改文件。第 5、7、8、10 条通过设置阶段门禁，强制它先调查、再设计、最后执行。
3. 局部最优
看到某个异常后，最短路径通常是修改报错附近的代码，但真正原因可能位于更上游。第 3、4、9 条是在迫使 Agent 从“让错误消失”转向“解释因果并提供证据”。
4. 确认偏误
同一个 Agent 刚完成实现后再审查，往往仍沿用原先的假设和解释框架。它更容易确认自己的方案，而不是重新质疑问题定义。
第 6、15、17 条是在人为引入 认知独立性和对抗性检查。
5. 目标漂移
长任务中，Agent 可能逐渐从“解决用户问题”滑向“让当前修改能跑”。任务笔记、明确计划和阶段验证是在维持最初目标。
为什么 subagent 的检查经常更客观
你的观察总体成立，但需要加一个限定：独立上下文提高了独立性，不自动保证客观性。
它通常更有效，主要有四个原因：
- 没有实现者的心理锚点
审查者没有经历前面的方案辩护和修改过程，更容易直接质疑假设。 - 减少上下文污染
主 Agent 的上下文里可能混有失败尝试、临时结论和已经失效的需求，独立 Agent 接收精简材料后更容易抓住核心。 - 角色目标不同
实现者的隐含目标是“把它做成”，审查者的目标是“找出它为什么可能失败”。 - 并行搜索空间更大
多个 Agent 可能沿不同方向调查，降低所有推理都卡在同一错误假设上的概率。
不过，如果主 Agent 把自己的结论直接写进任务，例如“确认这个实现是正确的”，subagent 仍然会被锚定。更好的委派方式是：
独立检查这组改动。不要假设当前方案正确。先从需求和代码行为重建判断，找出可能的回归、遗漏与错误假设；每个结论必须附代码位置或可复现证据。
“上下文太长时，开子 Agent 联网搜索”是否正确
这要拆成两个动作看。
-
开子 Agent：通常正确，适合隔离调查任务、压缩主上下文和获得独立判断。
-
联网搜索：只有问题依赖最新资料、官方文档、外部接口、法律规则、版本行为或陌生技术时才有价值。
如果问题答案就在代码库里，联网搜索可能引入与当前版本不匹配的信息。更合理的优先顺序是：
- 读取当前代码和项目文档。
- 检查依赖版本及本地实现。
- 查对应版本的官方文档。
- 必要时再搜索外部资料。
- 将外部结论与本地代码相互验证。
最值得保留的统一原则
可以把这些提示词压缩成一套工作协议：
遇到会改变实现方向的歧义，先询问，不得自行假设。动手前先调查现有实现、可复用能力、调用关系和项目惯例，并提交包含风险、边界与验证方式的计划。实施时必须修复根因，避免扩大范围。完成后进行独立审查，运行回归测试，并对比基线行为。所有“已解决”“无回归”“可提交”的结论都必须附带可复现证据。
这些提示词的本质，是用流程约束、外部记忆、证据门槛和独立审查，弥补 LLM 在长期记忆、不确定性管理、上下文稳定性和自我验证方面的先天不足。