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. [步骤] → 验证：[检查项]
明确的成功标准让你可以独立循环推进。模糊的标准（比如“让它正常工作”）需要不断澄清。