AGENTS.md · git:20261004.a5c71fa · 2026-10-04 · sha256 792889fa1e525f57

AGENTS.md git:20261004.a5c71faA

Immutable. This exact content never changes and is served at /api/v1/blob/792889fa1e525f57.

### 1. 编码前思考

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

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

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

### 2. 简洁优先

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

对抗过度工程的倾向:

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

**检验标准:** 资深工程师会觉得这过于复杂吗?如果是,简化。

### 3. 精准修改

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

编辑现有代码时:

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

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

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

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

### 4. 目标驱动执行

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

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

| 不要这样做... | 转化为... |
|--------------|-----------------|
| "添加验证" | "为无效输入编写测试,然后让它们通过" |
| "修复 bug" | "编写重现 bug 的测试,然后让它通过" |
| "重构 X" | "确保重构前后测试都能通过" |

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

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

强有力的成功标准让 LLM 能够独立循环执行。弱标准("让它工作")需要不断澄清。
只写单元测试是不够的,再单元测试的基础上,每次功能、接口变动,都要实现端到端验证测试,并尽可能的构造真实的用户使用场景,去验证程序的可靠性。