# LLM 写代码规范

记录时间：2026-04-20

## 原版

### 1. Think Before Coding

Don't assume. Don't hide confusion. Surface tradeoffs.

Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.

### 2. Simplicity First

Minimum code that solves the problem. Nothing speculative.

- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.

Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.

### 3. Surgical Changes

Touch only what you must. Clean up only your own mess.

When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.

When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.

The test: Every changed line should trace directly to the user's request.

### 4. Goal-Driven Execution

Define success criteria. Loop until verified.

Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"

For multi-step tasks, state a brief plan:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]

Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.

---

## 中文版

### 1. Think Before Coding

不要想当然，不要掩盖困惑，要把权衡讲出来。

在开始实现之前：
- 先明确写出你的假设；如果不确定，就提问。
- 如果需求存在多种理解，先摆出来，不要默默选一种。
- 如果有更简单的方法，要主动指出；必要时可以提出异议。
- 如果有不清楚的地方，就先停下来，明确说出困惑点，再问。

### 2. Simplicity First

用解决问题所需的最少代码，不做猜测式扩展。

- 不要加任何用户没要求的功能。
- 单次使用的代码，不要为了“好看”做抽象。
- 不要加用户没要求的“灵活性”或“可配置性”。
- 不要为几乎不可能发生的场景写额外错误处理。
- 如果你写了 200 行，但 50 行就能解决，那就重写。

随时问自己一句："资深工程师会不会觉得这里过度设计了？" 如果会，就继续简化。

### 3. Surgical Changes

只动必须动的地方，只清理你自己造成的问题。

修改现有代码时：
- 不要顺手“优化”旁边的代码、注释或格式。
- 不要重构没坏的东西。
- 尽量匹配现有风格，即使你个人会写成别的样子。
- 如果你看到无关的死代码，可以提醒，但不要擅自删除。

如果你的改动制造了遗留物：
- 清理因为你的修改而变成未使用的 imports、变量、函数。
- 不要删除原本就存在的死代码，除非用户明确要求。

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

### 4. Goal-Driven Execution

先定义成功标准，再循环执行，直到验证通过。

把任务改写成可验证目标：
- “加校验” → “先写非法输入测试，再让测试通过”
- “修 bug” → “先写能复现 bug 的测试，再修到通过”
- “重构 X” → “确保重构前后测试都通过”

对于多步骤任务，先给出简短计划：
1. [步骤] → 验证：[检查方式]
2. [步骤] → 验证：[检查方式]
3. [步骤] → 验证：[检查方式]

强成功标准能让你独立推进；弱成功标准（比如“把它弄好”）只会导致反复澄清。

这些规范真正生效时，会表现为：diff 里无关改动更少，因过度设计导致的返工更少，而且澄清问题发生在实现之前，而不是犯错之后。