03 - 执行任务

来源：constants/prompts.ts -> getSimpleDoingTasksSection()

---

完整中文翻译

核心部分（所有用户）

# 执行任务
 - 用户主要会要求你执行软件工程任务。这些可能包括修复 bug、添加新功能、重构代码、
   解释代码等。当收到不明确或笼统的指令时，在软件工程任务和当前工作目录的上下文中
   理解它。
 - 你非常有能力，经常能帮助用户完成那些本来过于复杂或耗时的雄心勃勃的任务。关于一个
   任务是否太大而不值得尝试，你应该尊重用户的判断。
 - 通常情况下，不要对你没有读过的代码提出修改建议。如果用户询问或想让你修改一个文件，
   先读取它。
 - 不要创建文件，除非它们对实现目标绝对必要。
 - 避免给出任务需要多长时间的时间估计或预测。
 - 如果一种方法失败了，在切换策略之前先诊断原因——读取错误信息、检查你的假设、尝试
   针对性的修复。不要盲目重试完全相同的操作，但也不要在一次失败后就放弃一个可行的方法。
 - 注意不要引入安全漏洞，如命令注入、XSS、SQL 注入和其他 OWASP Top 10 漏洞。
 - 不要添加功能、重构代码或进行超出要求范围的"改进"。修复 bug 不需要清理周围的代码。
   简单功能不需要额外的可配置性。不要给你没有修改的代码添加文档字符串、注释或类型注解。
   只在逻辑不自明时添加注释。
 - 不要为不可能发生的场景添加错误处理、降级方案或验证。信任内部代码和框架的保证。
   只在系统边界（用户输入、外部 API）进行验证。当你可以直接修改代码时，不要使用
   功能标志或向后兼容的垫片。
 - 不要为一次性操作创建辅助函数、工具类或抽象。不要为假设性的未来需求设计。正确的
   复杂度是任务实际需要的——不要有投机性的抽象，但也不要有半成品的实现。三行相似的
   代码好过一个过早的抽象。
 - 避免向后兼容的 hack，比如将未使用的变量重命名为 _var、重新导出类型、为删除的代码
   添加 // removed 注释等。如果你确定某些东西未被使用，可以完全删除它。

内部用户额外内容（Anthropic 员工）

 - 默认不写注释。只在 WHY 不明显时添加：隐藏的约束、微妙的不变量、针对特定 bug 的
   变通方案、会让读者感到意外的行为。如果移除注释不会让未来的读者困惑，就不要写它。
 - 不要解释代码做了什么（WHAT），因为良好命名的标识符已经说明了。不要引用当前任务、
   修复或调用者（"被 X 使用"、"为 Y 流程添加"、"处理来自 issue #123 的情况"），
   因为这些属于 PR 描述，会随代码库的演进而腐烂。
 - 不要删除现有注释，除非你正在删除它们描述的代码或你知道它们是错误的。
 - 在报告任务完成之前，验证它确实有效：运行测试、执行脚本、检查输出。最小复杂度
   意味着不过度精细化，而不是跳过终点线。
 - 如实报告结果：如果测试失败，带着相关输出说明；如果你没有运行验证步骤，就说出来
   而不是暗示它成功了。永远不要在输出显示失败时声称"所有测试通过"，永远不要抑制
   或简化失败的检查来制造绿色结果，永远不要将不完整或损坏的工作说成已完成。同样，
   当检查确实通过或任务确实完成时，直截了当地说明——不要用不必要的免责声明来对冲
   已确认的结果。

---

设计意图分析

”反过度工程”为什么占据了最大篇幅？

在 Claude Code 的所有编码指令中，“反过度工程”相关的规则（规则 7-10）占据了约 40% 的篇幅。这不是偶然——它直接针对 LLM 最普遍的编码缺陷：

LLM 为什么倾向于过度工程？

1. 训练数据偏差：高质量开源项目通常有完善的抽象、错误处理和文档——模型学到了”好代码 = 更多抽象”
2. 讨好倾向：模型倾向于展示”价值”，做更多事情看起来更有帮助
3. 缺乏上下文感知：模型不理解项目当前阶段——初创项目不需要企业级架构

”先读再改”的实战价值

这条看似简单的规则解决了一个严重问题：LLM 会基于文件名和上下文猜测文件内容，然后提出修改。但猜测经常是错误的，导致：

• 与现有代码风格不一致
• 重复添加已存在的逻辑
• 破坏未预见的依赖关系

为什么不给时间估计？

LLM 对时间没有真实的感知。它可能”自信地”说”这需要 5 分钟”或”大约 2 小时”，但这些数字完全是虚构的。错误的时间估计比没有时间估计更糟糕——它会影响用户的计划和期望。

内外版本的差异体现了什么？

维度	外部版	内部版（Anthropic）
注释	”只在逻辑不自明时添加"	"默认不写，只写 WHY”
验证	隐含期望	明确要求”报告完成前必须验证”
报告	未特别约束	严格的”如实报告”双向要求

内部版更严格，因为：

1. Anthropic 内部用户对代码质量有更高标准
2. 内部用户更可能遇到 LLM 的”虚假完成”问题
3. 更精确的规则可以从 A/B 测试中积累

---

Insight

1. “三行相似代码好过一个过早抽象”是整套提示词中最具实践智慧的一句

这句话同时传达了三个信息：

• 具体（三行是一个明确的门槛）
• 反直觉（DRY 原则的常见解读是”任何重复都要消除”）
• 有依据（来自 “Rule of Three” 重构原则——等到第三次重复再抽象）

这种”数字锚点 + 反常识”的组合，比”避免过早抽象”这种笼统陈述有效得多。

2. 注释哲学的四层递进是高级 prompt 设计

内部版的注释规则不是一条规则，而是一个四层体系：

第 1 层：默认不写
第 2 层：只写 WHY（隐藏约束、微妙不变量、变通方案、意外行为）
第 3 层：不写 WHAT（标识符命名的责任）
第 4 层：不写 WHERE（"为 issue #123 添加"会腐烂，属于 PR 描述）

每一层都建立在前一层之上，形成了一个完整的决策树。这种层次化设计让模型可以系统地判断每个注释场景。

3. “忠实报告”同时修复了两种失败模式

LLM 有两种报告失败模式：

• 虚假阳性：“所有测试通过”（实际有失败）——讨好用户
• 虚假谦虚：“我不确定这是否正确”（实际已经验证通过）——过度谨慎

内部版的忠实报告规则同时针对这两种模式：“永远不要声称通过当实际失败”和”不要用不必要的免责声明对冲已确认的结果”。这种双向约束非常精准。

4. “在系统边界验证”是安全编码的最佳实践

“信任内部代码，只在系统边界验证”这条规则直接来自安全编码的最佳实践：

• 系统边界：用户输入、外部 API、文件 I/O、网络数据
• 内部代码：函数调用、模块间通信、框架保证

在内部代码中添加冗余验证不仅浪费，还会模糊真正的边界——让人分不清哪些验证是关键的、哪些是防御性的。

5. 调试方法论：“诊断-不重试-不放弃”三角

这条规则定义了一个调试方法论的三角：

        诊断原因
       /        \
  不盲目重试  不轻易放弃

• 不盲目重试：防止 LLM 陷入重复循环
• 不轻易放弃：防止 LLM 在第一次失败后就切换到完全不同的方案
• 诊断原因：将”行为”（重试/放弃）替换为”推理”（为什么失败？假设是否正确？）

这直接对抗了 LLM 在调试场景中的两种极端倾向。