Anti-Laziness Protocol（反懒贪协议）
> 核心原则：宁可一个模块做深做透，不要三个模块都浮在表面
快速触发
以下场景必须加载本协议：
- 源码解读 / 技术调研
- 报告撰写 / 文档校验
- 用户要求"详细分析"
- 任何需要验证的工作
8 条铁律
1. 调研 = 逐行阅读源码，不是 grep 函数名
- 搜索结果只能作为发现线索
- 文档中必须包含源码片段和行号引用（格式：
文件路径:行号） - 反例：只 grep 函数名就下结论
- 正例：
trainer.py:84-98 调用了 xxx()
2. 一次只做一个任务，做透再走
- 不允许一口气开多个任务然后快速收工
- 每个任务做完后强制自检：
- 我读了多少行源码？（回答"0"就是偷懒）
- 我写了多少处
文件:行号 引用？
3. 诚实标注分析深度
- 如果只做了表面搜索，必须标注：
⚠️ 此节仅基于搜索结果，未深入源码验证 - 对比表的 ✅/❌ 必须有源码证据支撑
4. 交付前必过自检清单
- [ ] 是否逐行阅读了核心源码？
- [ ] 每个结论是否有
文件路径:行号 引用？ - [ ] 数据流向是否从输入跟踪到输出？
- [ ] 关键参数是否有具体数值？
- [ ] "未实现"/"不支持"的断言是否经过了全文搜索验证？
5. 不赶工，不凑数
- 宁可一个模块做深做透，不要三个模块都浮在表面
- 如果时间不够，诚实说明哪些部分未深入
- 「写完」≠「写好」
6. 置信度标注
- 不确定的信息必须标注
[待验证] - 区分"源码证据"和"推理结论"
7. 过程注释与记忆固化
- 长任务中每个关键发现必须输出到临时文件
- 每完成一个步骤，用一句话总结记录到进度文件
8. 两层质量门控
- 自检 — Agent 自己过清单
- 独立 Sub Agent 验收 — 第三方审阅，主 Agent 不可自己放行
禁止模糊语言
| 禁用 | 替代 |
|---|
| ----- | ------ |
| likely | 标注 UNRESOLVED |
| probably | 标注 [待验证] |
| seems/看起来 | 给出具体证据或 UNRESOLVED |
| should/应该 | 改为"根据源码 Lxxx，实际行为是..." |
| might/或许 | 标注 [待验证] |
场景专项规范
校验工作
详细规范见 references/校验规范.md
写作场景
详细规范见 references/写作规范.md
源码调研
详细规范见 references/源码规范.md
偷懒诊断决策树
| 表现 | 根因 | 对策 |
|---|
| ------ | ------ | ------ |
| 中途跳过关键函数 | 指令结构问题 | 铁律1+三阶段门控 |
| 分析深度不够 | 任务拆解不够细 | 原子步骤拆解 |
| 幻觉或张冠李戴 | 上下文过长 | 过程注释+记忆固化 |
| 验收声称通过但没验证 | 偷懒递归性 | 用户抽查+SubAgent验收 |
防偷懒递归问题
⚠️ 防偷懒措施本身也会被偷懒跳过——这是递归问题。
唯一解法：用户抽查 + 独立第三方验证
快速查阅
自检清单（8条）
- [ ] 逐行阅读了核心源码？
- [ ] 每个结论有
文件:行号 引用？ - [ ] 数据流从输入到输出？
- [ ] 关键参数有具体数值？
- [ ] "不支持"断言已全文搜索？
- [ ] 对比表每项有源码证据？
- [ ] 无模糊语言？
- [ ] 验收记录完整？
禁止清单
- ❌ 只 grep 不读源码
- ❌ 跳过自检
- ❌ 自己给自己放行
- ❌ 用"应该没问题"代替验证
- ❌ 用 likely/probably/可能 代替证据