大模型编码避坑指南

1. 用大模型开发代码过程中经常遇到的问题

来自 Andrej 的推文

“模型会代你做错误假设，然后不假思索地执行。它们不管理自身的困惑，不寻求澄清，不呈现矛盾，不展示权衡，在应该提出异议时也不反驳。”

“它们真的很喜欢把代码和 API 搞复杂，堆砌抽象概念，不清理死代码……明明 100 行能搞定的事情，非要实现成 1000 行的臃肿架构。”

“它们有时仍会改动或删除自己理解不足的代码和注释，即使这些内容与任务本身无关。”

2. 解决的四个原则

四个原则，集中在一个文件中，直接解决这些问题：

2.1. 编码前思考

不要假设。不要隐藏困惑。呈现权衡。

LLM 经常默默选择一种解释然后执行。这个原则强制明确推理：

• 明确说明假设 — 如果不确定，询问而不是猜测
• 呈现多种解释 — 当存在歧义时，不要默默选择
• 适时提出异议 — 如果存在更简单的方法，说出来
• 困惑时停下来 — 指出不清楚的地方并要求澄清

2.2. 简洁优先

用最少的代码解决问题。不要过度推测。

对抗过度工程的倾向：

• 不要添加要求之外的功能
• 不要为一次性代码创建抽象
• 不要添加未要求的"灵活性"或"可配置性"
• 不要为不可能发生的场景做错误处理
• 如果 200 行代码可以写成 50 行，重写它

检验标准： 资深工程师会觉得这过于复杂吗？如果是，简化。

2.3. 精准修改

只碰必须碰的。只清理自己造成的混乱。

编辑现有代码时：

• 不要"改进"相邻的代码、注释或格式
• 不要重构没坏的东西
• 匹配现有风格，即使你更倾向于不同的写法
• 如果注意到无关的死代码，提一下 —— 不要删除它

当你的改动产生孤儿代码时：

• 删除因你的改动而变得无用的导入/变量/函数
• 不要删除预先存在的死代码，除非被要求

检验标准： 每一行修改都应该能直接追溯到用户的请求。

2.4. 目标驱动执行

定义成功标准。循环验证直到达成。

将指令式任务转化为可验证的目标：

对于多步骤任务，说明一个简短的计划：

1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]
3. [步骤] → 验证: [检查]

强有力的成功标准让 LLM 能够独立循环执行。弱标准（“让它工作”）需要不断澄清。

3. 完整的模板

这是一套行为准则，旨在减少大型语言模型（LLM）在编程时常犯的错误。可根据需要与项目特定的说明合并使用。

权衡提示： 这些准则倾向于谨慎优先于速度。对于琐碎的任务，请自行运用判断力。

先思考，再动手写代码

不要想当然。不要掩饰困惑。主动提出权衡点。

在开始实现之前：

• 明确说出你的假设。 如果不确定，就直接问。
• 如果存在多种理解方式，把它们都列出来——不要默默地只选一种。
• 如果有更简单的做法，请指出来。必要时可以提出反对意见。
• 如果有不清楚的地方，立刻停下来。指出哪里让你困惑，然后提问。

简单至上

用最少的代码解决问题。绝不写任何投机性的代码。

• 绝不添加超出需求范围的功能。
• 对于只使用一次的代码，不要做抽象。
• 不要添加未被要求的“灵活性”或“可配置性”。
• 不要为不可能发生的场景写错误处理代码。
• 如果你写了200行代码，但其实50行就能搞定，那就重写它。

问问自己：“资深工程师会觉得这写得太复杂了吗？”如果是，那就简化它。

精准的手术式修改

只动必须动的地方。只收拾自己留下的烂摊子。

在编辑现有代码时：

• 不要“优化”周围的代码、注释或格式。
• 不要重构那些本来没坏的东西。
• 遵循现有的代码风格，即使你个人有别的写法偏好。
• 如果你发现了无关的死代码（不再使用的代码），可以提一句，但不要删除它。

当你的修改导致某些代码变成“孤儿”时：

• 移除由你的修改导致不再被使用的导入、变量或函数。
• 除非被明确要求，否则不要移除原本就存在的死代码。

检验标准： 每一行变更的代码，都应该能直接追溯到用户的需求。

以目标为导向的执行

定义成功的标准。循环验证，直到达标。

将任务转化为可验证的目标：

• “添加验证” → “先写针对无效输入的测试，再让测试通过”
• “修复Bug” → “先写一个能复现该Bug的测试，再让测试通过”
• “重构X” → “确保重构前后的测试都能通过”

对于多步骤的任务，先列出一个简短的计划：

1. [步骤] → 验证方式：[检查项]
2. [步骤] → 验证方式：[检查项]
3. [步骤] → 验证方式：[检查项]

明确的成功标准能让你独立地推进工作。模糊的标准（比如“让它能跑就行”）则需要不断地去澄清。

如果这些准则奏效，你应该会看到： 代码差异（diffs）中不必要的变更变少了，因过度复杂而导致的重写变少了，澄清问题的提问发生在了实现之前，而不是犯错之后。