@luoleiorg: 最近花时间整理了自己的 AI 工作流，做成了一个网页，想和大家分享一下 👨‍💻

最近，我花了点时间整理自己的 AI 工作流，把它做成了一个网页，想分享给大家 👨💻 🔗 http://ai-workflow.zuoluo.tv 我是 Vibe Coding 的重度用户，同时订阅了 Claude、Codex、Kimi、Gro­k 和 Gemini。平常的日子里，我要同时处理公司和团队的业务需求，还有自己的个人项目，一直在用 AI 编排和处理各种横跨不同平台、多场景、多业务上下文的任务。有些事需要我亲自介入和把关，有些则可以交给 Agent 自主盯守：🔑 哪些权限可以放出去，我什么时候必须介入 🤝 任务怎么分给几个模型，又怎么交叉验证 🌙 我不在电脑前的时候，哪些任务还能自己跑下去 这些都是我在真实工作中一点点调教出来的细节。随着 AI 在个人项目和团队里用得越来越多，这套工作流已经迭代了好几轮。也很想和各位 AI 高手交流一下各自的实战心得。— # 我的 AI 工作流 来源：https://ai-workflow.zuoluo.tv/ 01 · 写在前面 ## 一开始只有一个 Claude Code 最早我的用法很简单：开一个 Claude Code，什么活都丢给它，模型挑最强的那个。 这样用了一阵子，冒出来四个问题： - 最贵的 Fable 成了默认模型，改个文案也是它在想，额度消耗得飞快。 - 同样的话要反复说。回头翻了 4,993 条历史 prompt，「注意」「重新」「不要」这类纠正词一个月出现 70 多次。 - 它说做完了，我一验就有问题。有个开关叫「自动拉黑」，实际执行的却是「隐藏」。 - 改过什么没人记得。7 月初的 loop、7 月中的 ai-runtime、9 月初的多模型路由，前三轮都没留版本历史，现在说不清当时为什么那样改。 现在这套东西是第四轮。我管它叫 harness（套在模型外面的那一层）：几份 Markdown 约定、几个 shell 钩子、一个外包脚本，再加一个用 git 管起来的记录仓。没有框架，也没有服务。第四轮从 9 月 6 日 建记录仓算起，中间做过两次复盘，最近一次模型换代是 9 月 24 日，换到 Fable 5.1 和 Opus 5.5。 ### 可能对你有用，如果 - 手上有两家以上的模型订阅，想让它们各干各的 - 经常让 AI 跑长任务、过夜任务，人不在旁边 - 同一类错误已经纠正过三次以上 ### 大概用不上，如果 - 只用一个模型，偶尔问几个问题 - 每一步都想自己盯着改 - 团队已经有成熟的 AI 平台和规范 整套东西按「一条消息进来之后要回答的四个问题」分成四层： 1. ### 约定层 模型该守什么规矩？ 一份全局 CLAUDE\.md：分工表、成本红线、循环纪律、UI 标准。项目里的 CLAUDE.md 可以覆盖它。 2. ### 派单层 这条消息交给谁做？ 派单（判断一条消息该哪个模型接）由一个 UserPromptSubmit 钩子负责，它读一张规则表，命中就往主会话里塞一句指令。 3. ### 执行层 谁动手，出事怎么办？ 需要上下文的活留在主会话。能一句话写清验收的，交给座位层（统一的外包脚本，第 5 章讲）。 4. ### 验收层 凭什么说做完了？ 一个子代理看质量，另一个做证伪（专门找证据证明它没做完），最后过门禁（类型检查、测试、CI 这些机器检查）。 分层 上层定规矩，下层兜底 ← 左右滑动看完整的图 → 01 约定层 CLAUDE\.md 全局约定 分工表 · 成本红线 · 循环纪律 · UI 标准 写给模型读的「宪法」 02 派单层 UserPromptSubmit 钩子 router\-rules\.json 正则 → 注入一句硬指令 判定逻辑在配置里，不在脚本里 03 执行层 主会话 + 座位层 Opus 写需要上下文的；codex/kimi 写能一句话验收的 座位有熔断、顶替、日限 04 验收层 reviewer · verifier · 门禁 Fable 看质量，Sonnet 逐项证伪，CI 终审 没通过就不许说「完成」 还有一条是踩坑之后定的：配置只留一份。真正生效的是 ~/.claude/ 里那些文件，记录仓只放脱敏快照、决策记录和指标。以前两边各存一份，没过多久就对不上了。现在每次改完跑一遍快照脚本，拿 diff 看两台机器之间有没有漂移。 我分工时不看哪个模型最强，先看这个活需要多少判断力，再看手上哪份额度最便宜。 成本阶梯 越往上越贵、越稀缺 ← 左右滑动看完整的图 → Fable 5.1 规划 · 架构取舍 · 评审 · 复盘｜最贵、额度最快见底，只走两个子代理入口 Opus 5.5 主会话：日常编码、bug、需要本会话上下文的活｜settings.json 钉精确 ID codex · kimi 座位 批量机械改动、脚手架、长文阅读、第二意见｜订阅制额度，当备份产能用 Sonnet · Haiku 子代理 只读搜索、翻日志、证伪验收｜便宜、快，可以多开 贵 ↑ 便宜 ↓ 任务类型 首选 备选 怎么进入 规划、架构取舍、复盘 Fable 5.1 fable-planner Opus 5.5 钩子自动派 评审、验收前的质量把关 Fable 5.1 fable-reviewer codex 只读执行块完成后自动 日常编码、bug 修复 Opus 5.5 主会话 Sonnet 不切模型 批量机械改动、迁移、脚手架 codex gpt-6-astra kimi K3 /bulk 第二意见、安全审查 codex 只读 高推理 kimi K3 /second\-opinion 本地长文、多文件对照 kimi K3 · 1M 上下文 gemini 外包脚本 网页调研、大量网页摘要 gemini kimi K3 直接 CLI X / 社媒、实时信息 grok 4.7 gemini 外包脚本 只读搜索、翻日志 Haiku log-digger Sonnet 子代理 验收核验 Sonnet goal-verifier Opus 子代理 表格挺长，CLAUDE\.md 里真正用来判断的触发规则就三句：30 秒能答完的不进 Fable，拿不准就往便宜的一档走；能写成一句话验收的（比如「改完跑 pnpm test 全绿」）交给 codex；需要这次对话上下文的才留在主会话，因为外包要把来龙去脉重讲一遍，有时比自己做还贵。 主会话固定用 Opus 5.5，我不手动 /model 切。Fable 只从两个入口进来：规划和评审。以前手动切来切去，事后根本算不清钱花在了哪。 ### 模型 ID：哪里写死，哪里用别名 新模型上线那天踩过一次坑：两台机器各自漂到了不同版本，账本里查不出某次跑的到底是哪个模型。现在分三处处理： - settings\.json 和外包脚本里写精确 ID。无人值守的活要能复现，账本要能对上；模型悄悄换代，成本和行为会一起变。 - 子代理文件开头的配置区（frontmatter）里用别名（fable/sonnet/haiku）。同一份文件软链到两台机器，写死 ID 碰到旧版 CLI 会直接报错。 - 换代那天这三处一起改，再往决策记录里写一行，两台机器同步。 04 · 派单 ## 7 条规则、50 个正则，决定一条消息交给谁 分工表写得再清楚，模型也不会每次都去翻。所以我在 UserPromptSubmit 上挂了一个钩子 seat\-router\.sh：每条消息进来先对一遍规则表，命中了就往上下文里加一句指令，告诉主会话这活该给谁。 派单流程 判定逻辑在配置里，脚本只负责执行 ← 左右滑动看完整的图 → 我发一条消息 UserPromptSubmit seat\-router\.sh 跳过系统消息 / 斜杠命令 命中逃生口？「我自己做」「直接改」 按顺序匹配规则 7 条规则 · 50 个正则 都没命中，不注入，正常对话 plan / review → Fable 子代理 bulk / 第二意见 → codex 长文 → kimi · 实时 → grok 只读搜索 → Haiku 子代理 注入一句硬指令给 Opus 执行 只注入，不拦截 bulk 未外包则 seat\-guard 拒写 规则表 router\-rules\.json 现在有 7 条规则、50 个正则。一条规则大概长这样： { "id": "plan", "seat": "fable-planner", "patterns": ["^/goal\\b", "(制定|出|给|写)(一个|一份|个)?(方案|规划|计划|路线图)", "架构(选型|取舍|设计)", "复盘", "(怎么|如何)(优化|重构|设计)"], "instruction": "本条任务判定为【规划 / 复盘】：先调用 fable-planner 子代理拿到验收清单与任务拆分， 再由你（Opus）按拆分执行；标注 codex/kimi 的执行块必须经座位层外包； 全部完成后调用 fable-reviewer 复核，再调 goal-verifier 证伪验收。" } 用下来有三点体会： - 这个钩子只加提示，不拦东西。派单这条链上唯一会拦的是 seat\-guard：判定为批量改动、账本里又没有外包记录时，主会话的 Edit / Write 会被拒。 - 一定要留逃生口。消息里带「我自己做」「直接改」就不派。判错了我说一句话就能绕过去，不用跟规则较劲。 - 没命中规则时，一开始会再问一次 Haiku，后来关了：一会儿超时，每条长消息多等 7–25 秒；一会儿钩子又截到了它自己发出的分类请求。正则可预测，也不花钱。 规则放在我能直接改的配置文件里，个人特例也走配置，不写进脚本。这是我所有「判定类」逻辑的通用做法。 05 · 座位层 ## codex、kimi、grok 的外包都走同一个脚本 codex、kimi、grok 的外包调用都走 ai\-worker\.sh。我把它叫「座位」：调用方只说「要一个 codex 座位」，这一单最后由谁做、额度够不够，脚本自己决定。 多包这一层，是因为以前有一家的额度见底，几条直接调 CLI 的流水线全卡在那里。直接调 CLI，熔断和顶替就都没有了。 失败处理 先分类，再熔断，最后沿顶替链改派 ← 左右滑动看完整的图 → 编排层 ai\-worker\.sh codex 1200 prompt codex 座位 gpt-6-astra 模型钉死 rc=0 有产出 实际执行方写进 .provider + 账本 额度 / 限流 / 凭据失败 硬熔断 4h · 软熔断 15min 凭据失效私聊点名 rc=124 硬超时 不降级：体量问题交编排层拆任务 opus Claude 顶替 日限 12 次 codex 跳过失败座位 自身 kimi 订阅额度 不设日限 顶替链（同一座位当场改派）全链都挂 → rc=1 + 告警 grok 备用，显式点名才用 机制 做法 为什么 模型写死 每个座位的模型和推理档位都写在脚本变量里 不用 CLI 默认值；新版默认推理档位降了一档，不写明就会悄悄变浅 失败分类 额度见底 / 瞬时限流 / 凭据失效 / 其它 额度见底冷却 4 小时；限流冷却 15 分钟；凭据失效私聊我去登录 顶替链 opus → codex → kimi，跳过刚失败的那个 某一家额度见底时流水线不停 硬上限 Claude 顶替每天最多 12 次；Fable 原生调用每天 20 次 原生通道挂了，也不能一声不响把 Claude 额度抽干 返回码 0 有产出 · 124 超时 · 1 彻底失败 超时不自动换模型重跑，先查原因。我遇到的超时多半是活切得太大，换一家也照样超 账本 每次调用记一行：座位、实际执行方、模型、耗时、返回码 周报和复盘都从这里算 同目录互斥 按工作目录加锁，同一个 worktree 不许两个座位同时写 要并行就各开一个 worktree 有一周 MacBook 上 8 单 codex 里有 7 单被悄悄顶替成了 Claude：非交互 bash 里找不到 codex 命令，返回 127，脚本把它归到「其它失败」直接改派，账本里每单都记着「成功」。现在每次外包完我都会看一眼 .provider 文件，被顶替了就写进汇报。 06 · /goal 链路 ## 一句 /goal 之后发生的事 我交给 AI 的大活基本都是一句 /goal。比如这一页，最初我只说了一句「帮我梳理 AI Workflow，参考 net.zuoluo.tv，图文并茂，发布到 ai-workflow.zuoluo.tv」。 后面的流程是固定的： 标准链路 规划和评审用 Fable，其余都是便宜的 ← 左右滑动看完整的图 → /goal 一句话目标 先列人工阻塞项 fable-planner 验收清单 任务拆分 + 执行方 Opus 执行 每轮推进一条 通过即 commit 座位外包 codex / kimi 能一句话验收的块 fable-reviewer 看质量与设计 PASS / BLOCKERS goal-verifier 证伪立场 逐项实测 FAIL 就回去接着修，不许宣告完成 保险丝：≤25 轮 · 连续 3 轮没有任务从 false 翻成 true 就停下汇报 · 人工阻塞跳过不等，收尾集中报 第一步 1. ### 先列人工项 拿到目标第一件事：把要我授权、配置、登录的事一次列全。 中途卡在要我处理的地方也不停下，先做下一条，收尾时一起报。 2. ### 拆成清单 每条任务都带一条能执行的 verify 和 "passes": false。 每轮只推进一条，验证通过才改成 true，改了就 commit。 3. ### 装保险丝 最多 25 轮。 连续 3 轮没有任何一条变成 true，就停下来汇报。 4. ### 证伪验收 goal-verifier 的任务是尽力证明它没做完。 它说 FAIL，就回去接着修。 这一页第一版的任务清单长这样（节选）： [ {"id":"S1","title":"事实卡片 facts.json（claim → 出处 path:line）","owner":"kimi", "verify":"python3 -c \"...assert len(f['facts'])>=40 and all('source' in x for x in f['facts'])\"", "passes":false}, {"id":"S7","title":"脱敏终审：扫描 0 命中 + codex 只读复查","owner":"main", "verify":"bash site/scripts/redact-check.sh site/dist/index.html","passes":false}, {"id":"S9","title":"Pages 项目 + 自定义域名","owner":"main", "verify":"curl -s https://ai-workflow.zuoluo.tv/ | grep -q ' └── ai-worker.sh # 座位层：模型写死、失败分类、熔断、顶替链、日限、账本 / # 记录仓（git）：不生效，只记录 ├── STATE.md DECISIONS.md ITERATIONS.md OPERATING.md ├── tasks.json # 每条带 verify + passes ├── metrics/ # 周快照，脚本产出不手写 └── snapshots/ # 两台机器 ~/.claude 的脱敏快照，查漂移用 如果要我建议顺序： ### 先写约定 一张分工表加三条红线，一个下午就够。先用两周，看哪些规则总被违反。 ### 再包外包脚本 我加这层，是因为有一家额度用完时流水线卡住过。用到第二家模型时就可以考虑：模型写死、失败分类、顶替、账本。 ### 钩子最后加 只给被违反过两次的规则加。钩子一多会很吵，模型也会开始想办法绕过去。 12 · 还没做完的 ## 六件明知道有问题、还没解决的事 这套东西远没到「搭好了」的程度。目前挂着的有这些： - 三家各写一版还在影子试跑。9 月 25 日开始让 codex、grok、kimi 对同一个 issue 各写一版，再由 Fable 做一次比较式盲评。上线前拿 12 个真实 issue 做过对比：36 份实现全过了测试，但没有一份能原样合并；按评审意见合成了 9 份，CI 全绿。要不要转正，等试跑数据够了再定。 - 同时处理的任务上限要不要从 4 个降到 2 个，还没实测。三家同时写会不会把 mini 的内存吃满，要看峰值数据。 - 贵模型吃的上下文还没动。第 9 章说过，Fable 的 token 占比比消息占比高得多，规划和评审两个子代理读进去的东西太多了。这是下一步最该省钱的地方。 - 纠正次数在涨。每天 0.86 次涨到 1.71 次，大部分在排查基础设施，但我还没细分到底哪些能被规则或钩子提前挡住。 - mini 断电重启后能不能自己恢复，还没定方案。磁盘加密和 24 小时无人值守有冲突，两种做法各有代价，还在权衡。 - 周报只留哪一条生成链路，也还没拍板。 下一次复盘之后，我会回来更新这一节。