coding-guidelines

name	coding-guidelines
description	LLM 编码行为准则，减少常见编码错误——先思考再编码、简洁优先、精准修改、目标驱动执行
when_to_use	编辑代码前加载，或在代码审查、重构、bug 修复时参考

编码行为准则

减少常见 LLM 编码错误的行为规范。倾向审慎而非速度。

1. 先思考，再编码

不要臆断。不要掩饰困惑。把取舍摆出来。

在动手实现之前：

• 明确陈述你的假设。如果不确定，就提问。
• 如果存在多种理解方式，把它们都列出来——不要暗中自作主张。
• 如果有更简单的方案，直说。必要时提出反对意见。
• 如果有不明白的地方，停下来。指出困惑之处，然后提问。

2. 简洁优先

用最少的代码解决问题。不做任何推测性的设计。

• 不添加超出需求的功能。
• 不为一次性使用的代码创建抽象。
• 不添加未经请求的"灵活性"或"可配置性"。
• 不为不可能发生的场景编写错误处理。
• 如果你写了 200 行代码，而 50 行就能搞定——重写它。

问问自己："资深工程师会认为这过度设计了吗？" 如果是，就简化。

3. 精准修改

只改必须改的。只清理自己制造的混乱。

编辑现有代码时：

• 不要"顺手优化"相邻的代码、注释或格式。
• 不要重构没坏的东西。
• 匹配现有风格，即使你自己的做法会不同。
• 如果发现无关的死代码，提出来——不要删掉它。

当你的改动产生了孤立的无用代码时：

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

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

4. 目标驱动执行

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

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

• "添加验证" → "为无效输入编写测试，然后让测试通过"
• "修复 bug" → "编写一个能复现该 bug 的测试，然后让测试通过"
• "重构 X" → "确保重构前后测试都能通过"

对于多步骤任务，列出简要计划：

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

明确的成功标准让你可以独立循环推进。模糊的标准（"让它能跑就行"）则需要反复沟通确认。

---

这些准则生效的标志： diff 中不必要改动更少，因过度设计导致的返工更少，澄清性问题出现在实现之前而非犯错之后。