一个人 + 一群 Agent = 一座产品工作室

先交代事实口径：近半年，我以个人身份（非团队项目）交付了 50+ 个 Git 仓库，覆盖 TypeScript、Electron、Tauri、Go、Rust、Swift 等技术栈。其中包括一个 4000+ TS 文件、2500+ commits 的桌面端工作台，一个已上架 Mac App Store 的本地 AI 图像应用，若干企业级平台，和十几个可复用的 Agent Skill。

我知道这组数字听起来像吹牛。所以这篇先把最重要的话说在前面：仓库数量和文件数量作为能力信号，约等于零。 AI 时代生成代码不稀奇，稀奇的是让生成的代码可控、可验证、能交付。这篇要讲的是后者——一个人怎么把自己组织成一座工作室。

分工：我做判断，Agent 做执行，另一群 Agent 做验证

我的日常工具组合是分角色的，不是”哪个顺手用哪个”：

Claude Code 是主力执行者：CLI-first，hooks 做确定性外挂，subagent 做上下文隔离；
Codex 是第二意见：云端异步跑，专门当只读 reviewer——不同模型的盲区不同，同一段代码，两个模型找出来的 bug 集合只有部分重叠，跨模型审查是免费的盲区互补；
Cursor 负责编辑器内的小修改；
自建的多 Agent 编排系统负责流水线化的任务：17 个角色、11 条声明式工作流，从分诊、开发、审查、QA 到验收各司其职。

关键不在于用了几个工具，而在于人的位置：我不写大部分代码，但我写每一个任务的规格和验收标准；我不逐行 review，但我设计了让 Agent 互相 review、且结论可信的机制。

三条保命机制

一个人指挥一群 Agent，最大的敌人不是 Agent 能力不够，是不确定性的复利——每个环节 95% 的可靠性，十个环节串起来只剩 60%。这半年我收敛出三条机制，每条背后都是真实的翻车：

第一条：确定性编排大于 LLM 自由发挥。 Agent 之间的任务交接不走自然语言，走结构化 contract——任务从哪开始（locus）、什么证据证明有问题（signal）、做到什么算完（done）、完成后自动验证还是人工验证（done-v）。这四个要素在任务入列时就强制生成。自然语言交接每一步都是新的不确定性来源；结构化规格让”做完没做完”变成可判定的问题。

第二条：永远不信 Agent 的自报。 “我做完了，测试都通过了”——这句话在我的系统里没有任何效力。协调者会独立重跑测试（不是执行者跑的那份结果）、对照 Done Definition、检查产物完整性，全过了才算交付。听起来多此一举？在没有这层 Gate 的早期，我吃过的亏是：Agent 信誓旦旦说功能完成，实际连编译都过不了。不是模型在撒谎，是它真的以为自己做完了。 自我评估偏差是结构性的，只能用独立验证对冲。

第三条：失败要分级恢复，不能无脑重试。 第一次失败，标准退回附上日志——可能只是临时错误；第二次失败，退回并附上”方向审视”——连续失败大概率是方向本身有问题；第三次，区分”方向错了要重启”还是”执行错了要修复”；第四次，停下来升级给我。简单重试在第二次之后的成功率低得惊人，而无限重试烧掉的是真金白银的 token。

代价与边界（不讲这个的都是营销号）

这套模式不是免费午餐，三个真实代价：

token 消耗是重度的。 高峰期我一天烧掉的 token 以 B 计。跨模型审查、独立重跑验证、多 Agent 并发，每一层可靠性都是用推理成本换的。对我来说划算——它换来的是我一个人能维护 50 个仓库；但这个账每个人要自己算。
17 个角色不是能力，是成本。 这是我最重要的一条反思。每加一个 Agent 角色，就多一份上下文开销和一层信息失真。我的 17 角色系统是实验场，帮我摸清了派发、验收、恢复的机制边界——但如果重来一次，我会从 3 个角色开始，逼着自己证明每一次增员的必要性。
“production-scale”不等于”in production”。 我的项目里有真实用户在用的，也有停在”能跑通的完整形态”的。诚实地区分这两者，是对读者的尊重，也是对自己的清醒。

这个系列会写什么

「一人工作室手记」会持续写这座工作室的运转实录：单个项目从想法到交付的完整拆解、真实的翻车与修复、成本账本、以及那些”删掉的复杂度”——我做过然后扔掉的东西，往往比留下的更有信息量。

如果你也在用 AI 把自己放大成一支团队，欢迎对照参考；如果你正打算开始，希望这个系列能帮你少走几个我掉过的坑。

这是「一人工作室手记」系列的第一篇。下一篇：《我的 Agent 工具箱：十个 Skill 把交付流程串成流水线》。