把一套自动化决策系统的核心算法整个重做一次，前后跑了一个月。
以前的做法很像丢飞镖：把需求丢给模型，等它吐出一堆文件，看个大概，跑起来没问题就往前推，真的出事再回头补。结果最后补东补西，很多 bug 修起来并不难，真正昂贵的是根本不该在那个方向上写两周。
这次团队拆得很明确：人类负责判断方向、写 spec、做取舍；快速模型专心写 code；强推理模型专门 challenge；另一个模型家族只做 review；外部模型（Web AI）负责 deep research。整条流程慢很多，前后拉了一个月，过程明显从「用 AI 补手速」切换到「带一个小团队做开发」。
Phase 0：假设先行，不急着写 code
手上原本有一个系统在跑，表面上看不差，所以人很容易被现况骗住。每天看着它，会把很多前提默默当成常识。
第一步是先停下来，把那些前提一条一条拆出来，整理成四份问题包，丢给四个外部模型做 deep research。这一步不到一天。回来的报告风格差很多，有的像研究助理，有的像吹毛求疵的审稿人，有的甚至会主动补反例。但它们打到的是同一个洞：原本最被相信的那个设计，藏着结构性风险，靠修小参数解不掉。
方向不确定的题目，先做 deep research 比直接开始写 code 还是划算太多。写 code 有产出感，研究没有，问题是产出感很会骗人。
一天的外部研究，可能挡掉三周的精雕细修。
这里有个明确偏好：同一个问题宁可看四份彼此独立的报告，也不要看一份写得很漂亮的单一结论。要交叉印证，别被流畅叙事说服。外部模型最大的价值刚好在这里，它们没有人类已经投入的时间，没那么想替原本设计找台阶下。
Phase 1：Spec + Challenge Loop
方向翻掉之后，才回来写 v1 spec。
这次的 spec 没有追求文笔，结构写得很硬，不容变更。目标、接受度、数据完整性、边界条件，全部先写死。这里如果写的不清不楚含糊，后面每个模型都会各自脑补，到头来还是得收拾残局。
真正有感的是 challenge prompt。不再叫模型「帮忙 review 一下」，那种 prompt 太温柔了。改成直接要求它找出会让这份 spec 失败的地方，最好附上能验证的情境和反例。第一轮 challenge 进来，就会知道这次有机会走得比较稳。第一轮下来就抓了十几个问题，里面有几个很深，甚至把状态机缺的 transition 和可能卡死的位置一起翻出来。
这几轮修 spec 的过程很像被人拿手电筒照着走路。v1 还在补大洞，v2 开始收紧条件，到了 v3 之后，问题才慢慢从整块逻辑缺失，缩到边界案例没绑紧。前后大概跑了五到六轮，challenge 数量才稳定下来。Spec 上多花的一小时，常常会在后面省掉两小时 debug。
值得提醒的一条：challenge 太少，不一定是 spec 写得好。有时候只是 prompt 太弱，或者 reviewer 太客气。模型会讨好用户，这件事在开发里很危险。问题问得太松，它就会顺着讲，像个很有礼貌但没什么帮助的同事。
Phase 2-3：实作 + 跨家族审查
Spec 收敛到一定程度后，才开始 dispatch 实作。
整体拆成几个 task，先画 dependency graph，再决定哪些可以平行。这一步其实是在保护自己的上下文。分工边界没切干净，后面 merge 的时候，前面省下来的时间会整笔吐回去。
整轮做下来，改了不少文件。新逻辑其实没有最麻烦，最麻烦的是它怎么碰到旧路径。这也是直接跳过 self-review 的原因。写 code 的模型刚把新东西接起来，注意力通常都还黏在自己那条线上，很容易漏看相邻模块被连带影响的地方。换另一个模型家族进来 review，错误分布和视角真的不同。
这一招很快就验证了。第一轮 cross-family review 马上抓到几个 critical issue，而且全都不在新功能本身，而是在旧路径。少了这层，整段会带着一种「看起来都通了」的假信心往前走，等到验证阶段再慢慢发现边角开始掉。
平行开发也踩过很典型的坑。两个 task 同时碰到相邻函数，逻辑上都没错，合起来却互相覆盖。那次 merge 没有炸得很大，却足够提醒：平行 dispatch 不能只靠感觉。哪些文件会碰到、哪些接口会共享，前面都要先画出来。
Phase 4-5：验证 + 监控
写完还不算结束。
完整验证跑下去之后才发现，核心逻辑其实没有大问题，真正拖后腿的是另一个分类元件。它的误判率偏高，把本来应该保留的情境提早排掉，结果让主逻辑一直以为自己要再修。没有把验证做完整，很可能会在错的地方多绕一周。
这也是为什么 canary 那一层需要重视：先小规模上线、监控指标先设好、kill criteria 先写好、跌破门槛就自动降级。流程先到位，人比较不会在压力下乱改。系统状态也刻意分成 Active、Bench、Retired 三桶，让「先退下来观察」变成正常动作。
回头看，时间其实花在别的地方
如果硬拆比例，这一个月大概是这样：假设验证 15%、Spec + Challenge 25%、实作 20%、Review + Fix 15%、验证 + 部署 25%。
这个分配跟以前差很多。以前大概七成时间都卡在 code 和 debug，会误以为工程本来就该这么累。现在 review code 本身只占一成，反而觉得合理。真正花时间的地方，变成确认该不该做、怎么做、做完怎么证明它真的可用。
最值得的一笔投资，还是 Phase 0 的外部 deeep research。一天而已，却直接挡掉了一条错方向。最意外的收获，则是第一轮 challenge 喷回来的那十几个问题。它们如果晚到 production 才爆，修复成本很可能翻十倍。
这套方法不轻。简单脚本、低风险修补，真的没必要把流程拉这么长。但只要题目碰到真数据、真成本、真风险，慢一点常常更便宜。
仍在试的另一条线：Phase 0 只花 15% 的时间就挡掉一次方向错误，照理讲应该值得多投；可研究一旦做上瘾，人也很容易卡进 analysis paralysis。那个停手点怎么抓，目前还没有完全满意的答案。
延伸阅读
GitHub: https://github.com/p3nchan/orchestration-playbook
本文仅供研究与讨论，非投资建议。DYOR + NFA。
小企鹅的经验
OpenClaw 上 Opus / Sonnet / Codex 三 agent 真的是这样跑下来的。最有感的两件事：Phase 0 一天的外部 DR 直接救掉一周实作；challenge prompt 从「帮我 review」改成「找出让这份 spec 失败的地方并附反例」之后，第一轮就抓到十几个 valid issue。Spec 多花的一小时通常会在后面省掉两小时 debug，这条规律对自己的工作流稳定成立。推荐给大家。
常见问题
Q: 一个人用 AI 团队真的能开发算法吗？
可以，但需要明确的分工和流程。实战做法：自己负责策略决策和规格撰写，快速模型负责写 code，强推理模型负责 review，外部模型负责盲点搜索。关键是每个角色只做自己擅长的事。
Q: AI 开发的 Challenge Loop 实际跑起来是什么样子？
一份算法 spec 大概跑 4-6 轮 challenge。第一轮通常抓到好几个真正的问题，后面几轮逐渐收敛。重点是每个 challenge 都要附可测试的证据，否则会退化成空转。
Q: 外部模型 Deep Research 在开发流程中扮演什么角色？
两个时间点最值得用外部 DR：开始前验证假设方向，和收敛后做盲点搜索。一般的 code 开发不需要 DR。
整理：Penna｜小企鹅 Penchan