YY研发四铁律 · YY Dev Iron Laws
> 把"人的工程纪律"固化成给 AI 的说明书：不定决策，只定流程规矩，用四条铁律治代码返工。
> 灵感来源：Matt Pocock 开源的 AI 干活规矩（skills），专治代码返工。本文取其方法论精髓，落地为一份可直接加载给 AI 的研发纪律。
30 秒速查
| 任务 | 必过 | 第一个动作 |
|---|---|---|
| 新功能 | 律一 + 律三 | 写 DoD，问 3 个岔路 |
| 修 bug | 律一 + 律二 + 律三 | 要一条复现命令 |
| 重构 | 律一 + 律三 + 律四 | 先体检出报告 |
| 线上急救 | 律一（精简）+ 律二 + 律三 | 先复现再止血 |
| 一次性脚本 | 豁免 | 直接写 |
分诊细节见 references/triage.md。
0. 元原则：技能是说明书，不是决策者
这套 skills 的本质 = 给 AI 的"说明书"：不替你做决定，只定好规矩让 AI 照着干。
- 它约束的是流程，不是结论。要不要做这个功能、用哪个技术方案，永远由人定。
- AI 的本职是"在规矩内把活干对"，不是"替你拍板"。
- 任何一条铁律，都是把软件工程讲了二三十年的老规矩，变成 AI 在开工前必须过的门。
元原则补充：先读再改。 动任何代码前，先读三处——① 这个函数的调用方；② 同目录里同类的实现；③ 覆盖它的测试。不读就改，是 AI 最高频的事故来源。
什么时候加载本技能：用户让你写代码、写新功能、改老代码、接新需求、查 bug、做重构评估、定团队研发规范，或要把工程最佳实践固化成可复用的工作流时。
1. 铁律一：需求没问透，不许写
规矩：接到新需求、写新功能、改老代码之前，先把岔路盘清楚。AI 要反过来盘问，直到所有分叉、边界、验收标准都明确，再动手。
AI 的执行动作：
1. 不急着写代码、不给完整方案，先列出"还没搞清"的点。
2. 用 assets/clarify_gate.md 的清单逐项核对，把模糊点转成具体问题反问用户。
3. 当所有"必须澄清项"都关闭，给出一句验收标准（Definition of Done）让用户确认，然后再写。
4. 宁可多问十句，不瞎写一行。
反例：用户说"给登录加个记住我"，AI 立刻写出一个带 localStorage 的开关——却没问清楚：记住多久？多端同步吗？安全合规怎么过？结果返工三次。
判定标准：凡是会引出"哦不对，我其实是想……"的需求，都属于"没问透"。
2. 铁律二：排错得先复现
规矩：收到 bug，第一件事不是猜原因、不是改代码，而是逼出一条能稳定复现的命令或步骤。
AI 的执行动作：
1. 先要复现路径：最小可复现的操作序列、输入、环境、预期 vs 实际。
2. 用 assets/bug_repro.md 模板把复现收敛成一条可粘贴执行的命令或步骤清单。
3. 跑不出来复现，就停手：不许改代码、不许提"可能是 XX 导致的"。
4. 复现稳定后，再定位根因、再给最小修复，并附上"修复后如何验证"的步骤。
反例：用户报"偶尔登录失败"，AI 凭直觉去改超时配置，改完发现根本不是那个问题，白改两小时。
判定标准：没有"稳定复现 bug 的命令/步骤"之前，任何"原因诊断"和"代码改动"都视为违规。
3. 铁律三：测试得先写
规矩：实现功能之前，先写一个会失败的测试（TDD 前置）。杜绝"全写完再补测试"的假把式。
AI 的执行动作：
1. 动手写实现前，先和用户对齐要测什么（输入/输出/边界/异常）。
2. 按 assets/tdd_workflow.md 先写一条最小失败测试，跑红。
3. 再写刚好让测试变绿的实现，不超额设计。
4. 绿了之后才考虑重构；重构后测试必须仍全绿。
反例：一口气写完 300 行功能，最后说"我补个测试吧"——补的测试永远顺着实现写，等于自己证明自己没错，毫无意义。
判定标准：没有先红的测试，不算"开始实现"。一次性脚本可豁免（见不适用场景）。
4. 铁律四：架构得常体检
规矩：定期只读扫描仓库，把烂摊子找出来出报告，但绝不自作主张重构。
AI 的执行动作：
1. 周期性（或用户说"看看这项目健康度"）运行 scripts/repo_checkup.py 做只读体检。
2. 报告聚焦：超大文件、缺测试的目录、TODO/FIXME 堆积、疑似高复杂度文件、最大文件 Top。
3. 报告只给"现象 + 风险 + 建议"，不自动改任何文件。
4. 如果用户要重构，回到铁律一：先澄清目标与边界，再动手，且每步可回滚。
反例：AI 逛着逛着觉得某个函数"不顺眼"，自作主张重构成函数式写法，顺带改挂了三个调用方。
判定标准：任何"体检"产出的动作，默认是报告，不是改动。改动必须用户明确授权。
违规判定表
| 铁律 | 典型违规信号 | 立刻纠正 |
|---|---|---|
| 一 | 没写 DoD 就给完整方案 | 停下来，先要一句验收标准 |
| 一 | 没划"不做项" | 补一句"本次明确不做……" |
| 二 | 没复现就说"可能是 X" | 停手，先要复现命令 |
| 二 | 复现稳定性未记录就修 | 补"必现/偶现/环境"再动手 |
| 三 | 实现写完才出现第一条测试 | 回退，先补红测试 |
| 三 | 测试从未见过红 | 重写测试并确认因未实现而失败 |
| 四 | 体检后直接改了文件 | 还原改动，只交报告 |
| 四 | 把"建议重构"当成"已重构" | 需用户明确授权 + 可回滚 |
落地节奏：别一股脑全装
- 挑最对症的先用：常接需求先上铁律一，常查 bug 先上铁律二，顺手了再加别的。
- 顺序建议：铁律一（澄清）→ 铁律二（复现）→ 铁律三（测试）→ 铁律四（体检）。
- 团队沉淀：把这几条写进团队的 AI 提示词规矩 / 研发规范文档，让每个 AI 会话都默认过这四道门。
配套资产
| 路径 | 用途 |
|---|---|
assets/clarify_gate.md |
需求澄清门：开工前必须关闭的澄清项清单 |
assets/bug_repro.md |
bug 复现模板：把复现收敛成一条可执行命令/步骤 |
assets/tdd_workflow.md |
TDD 前置工作流：先红后绿再重构的标准动作 |
references/four_ironlaws.md |
四条铁律详解：为什么、什么时候触发、怎么判定违规 |
references/when_to_use.md |
适用 / 不适用 / 落地节奏的完整清单 |
references/triage.md |
30 秒分诊：这类任务该过哪几道门 |
references/ai_excuses.md |
AI 常见借口与反驳（10 条） |
scripts/gate.py |
四律卡生成与校验：没填满不许开工 |
scripts/repo_checkup.py |
只读仓库体检：扫描健康度，零修改，可输出 JSON |
内置脚本
# 1) 四律卡：生成 → 填 → 校验（不 PASS 不动手）
python scripts/gate.py new --title "给登录加记住我" --type feature
python scripts/gate.py check 四律卡.md
python scripts/gate.py check 四律卡.md --json
# 2) 只读体检（铁律四）
python scripts/repo_checkup.py .
python scripts/repo_checkup.py . --json
python scripts/repo_checkup.py . --max-lines 400 --todo 5 --top 10
python scripts/repo_checkup.py . --exclude "vendor/*" --fail-on high # CI 用
gate.py 按任务类型决定必过铁律：feature→1/3，bug→1/2/3，refactor→1/3/4，hotfix→1/2/3。
收尾三问（写完之后）
- 测试：全量测试是否通过？新增行为有没有对应测试？
- 范围：改动是否越过了 DoD 与"不做项"？
- 回滚：这个改动能否单独回滚？回滚点是什么？
> 三问答不上来，说明这次改动还没收干净。
不适用场景
- 只想快速糊一个一次性脚本（跑完就扔、不进仓库、不被复用），就别折腾四道门，直接写。
- 纯文本 / 文档 / 数据分析类任务（非代码研发），本技能不触发。
- 用户已明确给出完整规格、验收标准和环境信息，可跳过铁律一的盘问，直接进入实现（但仍建议过铁律三）。
> 启发：这东西没黑科技，全是软件工程讲了二三十年的老规矩。只是 AI 写得太快，这些"澄清—复现—测试—体检"的老纪律，反而成了防返工的救命稻草——快，更要守规矩。
