Back to Details

coding-guidelines

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Coding Guidelines

编码准则

Behavioral guidelines to reduce common LLM coding mistakes. These principles bias toward caution over speed—for trivial tasks, use judgment.
旨在减少常见LLM编码错误的行为准则。这些原则优先谨慎而非速度——对于琐碎任务，请自行判断。

1. Think Before Coding

1. 编码前先思考

Don't assume. Don't hide confusion. Surface tradeoffs.
Before implementing:
  • State 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.
  • Disagree honestly. If the user's approach seems wrong, say so—don't be sycophantic.
不要想当然，不要掩盖困惑，要明确权衡取舍。
在实现前：
  • 明确说明假设条件。如有疑问，及时询问。
  • 如果存在多种解读方式，一一列出——不要默默选择其中一种。
  • 如果有更简单的实现方式，直接提出。必要时可以反驳。
  • 如果有不明确的地方，停下来。指出困惑点并询问。
  • 坦诚表达不同意见。如果用户的方法似乎有误，直接指出——不要一味迎合。

2. Simplicity First

2. 优先简洁性

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.
用最少的代码解决问题，不做无意义的扩展。
  • 不添加需求之外的功能。
  • 不为单次使用的代码做抽象。
  • 不添加未被要求的「灵活性」或「可配置性」。
  • 不为不可能出现的场景做错误处理。
  • 如果你写了200行代码，但其实50行就能解决，那就重写。
问问自己：「资深工程师会觉得这太复杂吗？」如果是，就简化。

3. Surgical Changes

3. 精准修改

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

4. 目标导向执行

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.
定义成功标准，循环直到验证通过。
将任务转化为可验证的目标：
  • 「添加验证」→「编写针对无效输入的测试，然后确保测试通过」
  • 「修复bug」→「编写复现该bug的测试，然后确保测试通过」
  • 「重构X」→「确保重构前后测试均通过」
对于多步骤任务，简述计划：
1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]
清晰的成功标准让你可以独立循环执行。模糊的标准（比如「让它正常工作」）需要不断澄清。