一份「人机双读」规范：飞飞看得懂，Codex / Claude Code 也能当执行契约照着跑。
Fable 5 出方案初版 → GPT-5.6 Sol 纠错定稿。越大的方案越吃模型智力。
测试 / CI / 上线验收 + 洁癖.skill 让代码·文档·规则·记忆四端统一。
写代码已经不是瓶颈了。钱和精力砸在 两头 ——出好方案 + 建好测试；中间执行交给 Agent 挂机跑。
全套 18 步跑一个改文案的活太重——光双模型出方案就二三十分钟。所以先按改动风险定档，只跑该档需要的步骤。Agent 开工前必须报一句「这个我按 X 档走」，不报不动手，禁止中途偷偷降档。
| 档 | 什么活 | 跑哪些步 | 要点 |
|---|---|---|---|
| S · 标准 | 改文案 / 调样式 / 改配置值 / 加日志 | 5 → 7 → 8 → commit | 预先批准，无分支无 PR |
| M · 常规 | 修 bug / 加小功能 / 改一个接口 | 5 → 6 → 7 → 8 → 9 → 10 → 11 → 12 → 15 | 跳过双模型出方案（第 2、3 步） |
| L · 全档 | 新模块 / 动数据结构 / 跨系统 / 影响真钱真客人 | 18 步全走 | 第 3 步换模型挑刺绝不可省 |
| E · 紧急 | 线上已炸、店里正营业用不了 | 先止血，24h 内补 PR + 测试 + 复盘 | 唯一允许先改后补；债必须还 |
| X · 实验 | 试想法 / 验证可行性 / spike | 随便写，不进 main | 限时 + 开工声明"这是要扔的" |
三条的由来：外部来自 Tw93 2026-08-30 谈 Mole 十三个版本如何不腐化的公开分享（第 3、5、6 条）；本地各有一次实证——① 同一个毛病存在于两条打印链路，只修了一条，压了一整天 ② 许愿池此前只有进口没有闸门，想到就记、记了就排队 ③ 3 笔提交落在没人看的分支上，全程零报错、检查全绿、东西一份没丢，只是没到。
<input type="date"> 胜过装个日期库） ⑤ 已装的依赖能干吗（绝不为几行代码新装一个） ⑥ 一行能写完吗 ⑦ 才轮到「能跑的最少代码」。梯子抄自 DietrichGebert/ponytail（MIT · 11.7 万星）的核心 skill，飞飞 08-31 拍板：只抄梯子，不装插件——理由正是梯子第 1 级，那个插件要常驻两个 Node 钩子、每次对话都跑，而我们缺的只是这份动作清单，不是一个安装包。用它自己的标准判它自己。它的基准（-54% 代码量）跑在 Haiku 4.5 上；作者自己写明，在会深度思考的推理模型上省钱省时那部分会反过来——所以我们要的是「少写没必要的代码」，不是「省钱」。
分档依据三条业界实践：ITIL 三类变更（标准 / 常规 / 紧急——低风险改动预先批准，不再逐次审批）· DORA 变更审批研究（正式审批关卡对质量无益还拖慢速度，有效的是过程内评审 + 自动化早期拦截，所以砍的是重型审批不是测试）· 2026 agentic SDLC 共识（控制强度按风险配比；Agent 提速带来"验证债"，人工评审跟不上，自动化测试是唯一扛得住的）。
每一步对号入座：用你现有的哪个 skill／工具，缺不缺，是自动还是手动。
✅ 有 · ⚠ 有但半手动，该自动化 · ❌ 缺 · ➖ 该保留手动
| # | 步骤 | 你的工具 / skill | 状态 |
|---|---|---|---|
| 1 | 需求 | 你口述（Hermes / TG 输入） | ➖ 手动 |
| 2 | 出方案初版 | brainstorming + writing-plans + codebase-design（或直接让强模型出） | ✅ 有 |
| 3 | 纠错定稿 | codex-cross-review（Codex / GPT 复核） | ✅ 有 |
| 4 | 启动执行 | goal ＝目标模式 | ✅ 有 |
| 5 | 理解核实 | Agent 默认行为（brainstorming 可兜） | ✅ 内建 |
| 6 | 建隔离环境 | using-git-worktrees | ✅ 有 |
| 7 | 开发修改 | test-driven-development / executing-plans | ✅ 有 |
| 8 | 自动测试 | /verify + verification-before-completion + TDD | ⚠ 常手动跑 |
| 9 | 推分支 + PR | finishing-a-development-branch + requesting-code-review | ✅ 有 |
| 10 | CI 自动验收 | GitHub-hosted runner（已有多项目运行） | ⚠ 待全套标准化 |
| 11 | 合并主线 | git（finishing-a-development-branch） | ✅ 有 |
| 12 | 部署上线 | /run + 你的 wrangler 部署 | ⚠ 半手动 |
| 13 | 查线上效果 | /verify + webapp-testing + screenshot | ✅ 有 |
| 14 | 四端同步 | neat-freak（洁癖） | ✅ 有 |
| 15 | 汇报 | Hermes / TG 推送 | ✅ 有 |
| 16 | 确认 | 你拍板 | ➖ 手动 |
| 17 | 清理 | finishing-a-development-branch | ✅ 有 |
| 18 | 结束 / 迭代 | session-closure（可选） | ✅ 有 |
executing-plans / subagent-driven-development 不是过时，是可选：大任务用 goal 目标模式替代更省心，小任务才用它们。留着，按任务大小挑。
前期把大量 token 砸这。覆盖率做到舒服区间，Agent 才敢在你睡觉时放手写。
已有项目继续用 GitHub-hosted runner；下一步统一 Gate 并补齐缺项。原计划普通 CI 默认自建 / 不用 GitHub Runner。 只有未来真吃本地模型或大算力的评测，才按需路由到 Spark。
每个任务收尾自动同步四端。你这边对应 neat-freak（洁癖）skill。
把整个开发想成 一家餐厅出一道新菜，你就全懂了：
给新菜单独开个小灶试做，不动正在营业的大厨房。做砸了也不影响客人。
提前写好的一堆"小尝味勺"。菜一改，自动一勺勺尝过去，看咸淡对不对、有没有把别的料弄洒——。
这道菜有多少比例被"尝味勺"盯着。=大部分地方改坏了立刻被抓；低=很多地方没勺子，坏了没人知道。
专门确认"以前做得好的老菜，现在还是那个味"。防止你改新菜时手一抖，把隔壁招牌菜的配方也动了。
尝味勺尝不出"摆盘好不好看"，所以真去点一下页面、走一遍完整流程看效果。
新菜做好，写张"申请上正式菜单"的单子，先送审、别直接端给客人。
一条自动质检流水线。申请单一交，自动把所有尝味勺+老菜回测全跑一遍，全绿才亮灯放行。普通测试跑 GitHub-hosted runner；原先设想专门跑一台自建服务器。 Spark 只在未来真需要本地模型或大算力评测时接入。
质检亮绿 → 新菜写进主菜单（合并）；菜单印出来摆到每张桌上，客人真能点（上线）。
你只告诉厨师"把这桌菜做到完美再端上来，中间别烦我"，厨师不达标不停手。你去睡觉，起床收菜。
测试就是让机器替你反复尝味、反复回头检查老菜——这样 Agent 才敢在你睡觉时放手改代码，因为改坏了流水线会亮红灯自动打回，坏东西上不了线。
飞飞 · AI Agent 开发工作流人类可读派生视图 · 唯一 operational SSOT：dev-flow/references/workflow.md