本文详解Stavros的LLM编程工作流，通过建筑师、开发者、评审员三角色协作实现高质量代码生成，并呈现Hacker News社区关于单模型与多模型效率对比、代码质量争议及未来职业影响的激烈讨论。
你以为自己热爱编程，后来才发现你只是爱造东西。代码只是工具，现在有人用一套“套娃工作流”——让AI扮演架构师、开发者和评审员——互相吵架、互相审查，据说能搞出几万行还能用的代码。但这玩意儿在网上一发，评论区直接炸成烟花，有人说这是效率革命，有人说这是新式跳大神。
编程的快乐原来是个天大的误会
我以前一直以为自己热爱编程，热爱到什么程度呢？就是那种半夜三点不睡觉，对着屏幕调bug，调出来之后恨不得亲显示器一口的极客。我看到那种结构优雅、注释清晰的代码，眼眶都能湿一圈，觉得这才是人类智慧的结晶。后来LLM这个东西突然冒出来，能写代码了，我玩了几天才发现一个惊天秘密：我压根儿就不在乎代码本身长什么样。代码对我来说就是个工具，就像炒菜用的铲子，你会在乎铲子是什么材质的吗？不，你只在乎菜好不好吃。
这感觉就像你一直以为自己爱吃火锅是因为喜欢涮毛肚，后来才发现你只是喜欢大伙儿围坐一团、热气腾腾的那种氛围，毛肚换成牛肉、换成鸭血，对你来说根本没区别。自从发现LLM能替我写代码之后，我就彻底放飞自我了，像掉进了米缸的老鼠，开始疯狂造东西。从个人助手到语音吊坠，从搞怪时钟到多人涂鸦画布，项目一个接一个往外蹦，根本停不下来。
其中最夸张的是一个叫Stavrobot的项目，你可以把它理解为OpenClaw的替代品，但是更注重安全。OpenClaw就是那种能帮你订外卖、写邮件、管理日程的万能AI助手，听起来很美好对吧？但很多人担心它不安全，怕它哪天抽风把银行存款全捐给流浪猫协会。我的Stavrobot主打一个“在可用性和安全性之间做精细权衡”，说白了就是让它能干所有该干的活儿，同时任何不该干的事儿，它连碰的念头都不能有。这套工作流程跑下来，我发现它能让我写出几万行还能维护的代码，而且出错率比我当年自己手写还低。
以前我也试着用LLM写代码，但通常两三天之后代码就烂成一坨，改都改不动。现在呢？能连续搞几周，每次改动都跟第一次写出来一样稳。这说明两件事，第一是现在的模型确实比以前聪明多了，第二是我也变聪明了，学会了怎么跟这帮AI打交道，知道怎么给它们派活儿才能不把场子搞砸。
人类技能没贬值，就是搬了个家
很多人一听说AI能写代码了，就开始慌，觉得程序员要失业了，以后满大街都是无业游民。我觉得他们纯粹是想多了，属于自己吓自己。我的工程技能一点都没浪费，只是从“怎么写对代码”这个层面，搬家搬到了“怎么搭对架构”这个更高的层面。以前你得背语法、记API、抠各种实现的细节，现在这些脏活累活AI都能替你干。但是系统整体怎么设计？技术方案怎么选型？遇到复杂情况怎么权衡利弊？这些决策还得人来拍板，AI拍不了这个板。
有个对比特别明显，能说明问题。我在自己完全不懂的技术领域搞项目，比如移动App开发，我根本不知道安卓和iOS的水有多深，结果就是代码很快就变成灾难现场，改一处崩三处。但是在我自己熟悉的后端领域，几万行代码跑下来居然稳如老狗，没出什么大乱子。这说明什么？说明AI不是万能的，它需要一个懂行的人在前面掌舵，帮它避开那些看不见的坑。这就像自动驾驶，路况好的高速上它能开，但遇到那种人车混行的复杂路口，还是得人类司机接手才放心。
我还发现一个很有意思的趋势。早期用GPT-2那种老掉牙的模型，我写一行代码得盯着检查三行，生怕它给我整出什么幺蛾子。后来用davinci这种稍微强点的模型，我只需要检查函数级别的逻辑对不对就行。再后来用Claude Opus这种顶配模型，我甚至只需要看整体架构有没有跑偏。照这个趋势发展下去，说不定明年我连架构都不用看了，直接跟AI说“给我造个淘宝”它就能搞定。但至少现阶段，你还是得有一个真正会写代码的人坐在旁边盯着，不然翻车是迟早的事。
我最近都造了些啥玩意儿，报个流水账
最近造的东西挺杂的，从正经的生产力工具到纯粹为了好玩的艺术装置都有。最大的项目当然是Stavrobot，一个用来替代OpenClaw的个人助手，功能多得我自己都记不全。它能管日历、能做研究、能写代码扩展自己的功能、能提醒我该做的事儿、还能自动处理各种杂务。每次我跟别人介绍这个项目，总会有人说“AI不可能做到既强大又安全”。但安全这个东西本身就是个权衡，我的设计理念是在给定可用性的前提下，最大化安全性。我自己用了一段时间之后，感觉非常舒服，我能精确地推理出它什么能干什么不能干，这种一切尽在掌控的感觉很让人上瘾。
还有个叫Middle的小吊坠，看起来像个装饰品，实际上是个语音笔记神器。它有个按钮，我随时随地掏出来按一下，对着它说话，它就能把语音录下来，转成文字，然后发到我指定的地方。我把它设置成把语音发给LLM处理，这样我走在路上突然想到一个好点子，或者想查个什么东西，直接掏出来按一下说就行，答案过一会儿就会出现在我的助手消息列表里。这东西妙就妙在“零摩擦”三个字，随时可用、永远可靠、而且完全不用思考怎么用，跟呼吸一样自然。
Sleight of hand是个纯粹的艺术项目，一个走时不规律、专门让人难受的挂钟。它的秒针 ticking 的间隔不是固定的，而是在500毫秒到1500毫秒之间随机变化。还有一种模式是走得比正常快一点，然后随机停一秒，让你看着看着就开始怀疑人生。最绝的是最后一种模式，它会冲到59分那个位置，然后停30秒，让你以为它坏了。当然也保留了正常模式，因为那个不规律的 ticking 实在太折磨人，连我自己都受不了。
Pine Town是个无限大的多人涂鸦画布，每个人进来都能分到一小块地皮，想画什么画什么。大部分人画的都是些不可描述的内容，你懂的，就是那种小学生课桌涂鸦的水平。但偶尔也会有几个成年人进来画点正经的，有些作品还真不错，你在画布上随便逛逛，就能发现惊喜，感觉就像在逛一个永不闭幕的街头艺术展。
所有这些项目，背后的代码全都是LLM写的，我绝大部分代码都没读过，也懒得读。但我对每个项目的架构和内部工作逻辑了如指掌，哪个模块负责什么，数据怎么流转，我心里门儿清。
套娃工作流的硬件装备，都是些啥
我用来控制这帮AI的工具叫OpenCode，你可以把它理解成一个给AI套缰绳的架子。它最大的好处是支持多家厂商的模型，还能定义那种可以互相调用的自定义agent。现在很多官方出的工具，比如Claude Code、Codex CLI、Gemini CLI，都不支持混用模型，它们只想让你用自己家的那一套。但在我看来，把不同厂家的模型混着用，恰恰是这套流程里最关键的一环。
你可以把某个特定模型，比如Claude Opus，当成一个有固定性格的人。哪怕你把它的对话上下文清空了重新开始，它的观点、它的强项、它的弱点，基本还是一样。让它 review 自己刚写出来的代码，结果就是“我觉得挺好”，纯属走过场。但你要是换另一个模型，比如Codex，来 review 同一段代码，那效果就完全不一样了，相当于换了一双全新的眼睛，能发现很多之前看不到的问题。
不同模型性格差异特别大。比如Codex 5.4这个版本，天生就爱挑刺，让它写代码的时候能把你烦死，动不动就“你这样不行”、“那样不安全”。但让它去 review 别人的代码，那就刚刚好，鸡蛋里都能给你挑出骨头来。Opus 4.6的决策风格跟我的决策风格高度吻合，我经常一看它给的方案，就觉得“对对对，我就是这么想的”。还有Gemini 3 Flash这种小模型，别看它个头小，脑子转得快，经常能想到其他大模型都没看到的奇葩解法。所以模型选择这事儿，其实挺个人化的，而且得经常轮换。去年11月我还用Codex当主力，后来发现它有点轴，又切回Opus了。想要拿到最好的结果，就得跟炒菜一样，各种调料混着放。
Agent之间能互相调用也特别重要。我的工作流里分了三类角色，架构师、开发者、还有一到三个评审员。如果这套 harness 不支持agent之间互相调用，我就得自己手动当那个传话筒，把这个agent的输出复制粘贴给那个agent，累都累死了，根本玩不转。
架构师、开发者、评审员，三方扯皮才是精华
我坚持用多个agent分工合作，而不是一个agent包打天下，主要有三个原因。第一当然是为了省钱，架构师这种烧脑的活儿，得用昂贵的Opus来干，负责规划生成详细方案。开发者这种搬砖的活儿，用便宜的Sonnet就够了，按计划实现就行，token消耗差出好几个数量级。第二是为了质量，不同模型 review 同一段代码，确实能抓住不同类型的问题，有的擅长抓逻辑漏洞，有的擅长抓安全隐患。第三是权限管理，有的agent我只能让它读代码，不能让它写，避免它自作主张乱改。如果两个agent用同一个模型，还给了同样的权限，那分开就没意义了，就像同一个人换三顶不同的帽子演戏，本质还是一个人在演。
有个东西我坚持手写，绝不让LLM代劳，那就是Skill文件，也就是每个agent的行为指令。这就像你让一个人写一本《如何成为一名优秀工程师》的指南，写完之后把指南给他，让他照着指南做就能变强，这显然不现实。所以我亲自给每个agent写它的角色说明书，告诉架构师你的任务是全局规划，告诉开发者你的任务是听话照做，告诉评审员你的任务是挑刺找茬。
架构师这个角色，我指定由Claude Opus 4.6来担任，因为它是目前市面上最强的规划模型。我只跟它一个人互动，这一步主要是聊天，消耗不了几个token，但需要我动脑子。我会告诉它我的目标，比如“给Stavrobot加个指数退避重试的功能，万一调用的LLM服务商挂了，它能自动重试，别直接崩溃”。然后我们俩就开始来回讨论，有时候能聊半小时，直到我确认它完全理解我要什么，理解我想避开哪些坑，理解最后做出来的东西长什么样。聊透之后，它会产出一个非常细粒度的计划，细化到具体改哪个文件的哪几个函数。
有人喜欢在规划阶段让LLM直接把方案写进文件里，然后自己在文件里加批注反馈。两种方法都行，看个人习惯。我比较喜欢直接聊天，因为效率高。这一步我不是在单纯地下命令，而是在LLM的帮助下，共同塑造一个计划。我得经常纠正它，要么是因为它理解错了，要么是因为它做事的方式跟我习惯的方式不一样。正是这种方向性的把控，让我能理直气壮地说这项目是我的。换个人来，用同样的LLM，最后造出来的东西肯定不一样。
聊得差不多了，我确认所有细节都敲定了，才会说一声“approved”，这时候它才能开工。我特意在指令里强调，架构师必须听到“approved”这个词才能开始干活。因为有些模型太积极，觉得自己听懂了就开始动手实现，结果做出来的东西跟我想要的根本不是一回事。我要确保它真懂了，才能放行。然后架构师就把任务拆解，写成更细的计划文件，然后去调用开发者，让它开工。这给了开发者非常明确的方向，限制了它能做的选择，因为该做的选择在规划阶段已经做完了。
开发者和评审员，流水线上的螺丝钉
开发者这个角色，就可以用更弱更省token的模型了，我现在用的是Sonnet 4.6。我给它的计划非常详细，基本不给它自由发挥的空间，它的工作就是严格按计划实现，别给我整幺蛾子。干完之后，它会自动调用评审员来 review。
每个评审员都是独立工作的，它们会看架构师给的原始计划，再看开发者写的代码改动，然后提出批评意见。这一步我至少会用Codex来干，如果是重要项目，还会再加一个Gemini，如果是那种要命的核心项目，连Opus也得拉过来再审一遍。所有的反馈意见都会汇总回到开发者那里，如果评审员们意见一致，开发者就直接整合修改。如果意见不一致，吵起来了，那就升级给架构师，让它来裁决。Opus这个模型很擅长判断该听谁的反馈，有时候它会忽略那种过于学究气的意见——就是那种实现起来特别麻烦，但在实践中几乎不可能出问题的那种。当然我说它“很擅长”，意思是“它的判断跟我的判断高度一致”。
这种方式让我能掌握每一个函数级别以上的选择，后续维护的时候，这些知识特别有用。我经常发现LLM推荐的东西，在其他代码库里可能是不错的实践，但在我的代码库里，要么跑不通，要么不是最优解。这时候我就会说“不，你应该用Y方案”，然后LLM才意识到，原来Y方案确实存在，而且比它想的更好。反过来，如果我对某项技术不够熟悉，架构上跟不上，那LLM做了坏决策我也抓不住。结果就是LLM在坏决策的基础上越盖越高，最后堆成一团解不开的乱麻，彻底完蛋。这种失败模式我经历过太多次了，所以才痛定思痛，搞出这套复杂的工作流。所以我尽量在规划阶段就把东西搞懂，哪怕我对具体的技术栈不熟。只要能在这个阶段引导好LLM，后续就能省下大事。
现场直播：真实会话长什么样，全是干货
下面这段，是我给Stavrobot加邮件支持功能时的真实对话节选。我把那些啰嗦的工具调用过程删掉了，但关键的对话和决策过程完全真实保留。开场我就直接说了，非常高层：“我想给这个bot加上邮件支持，咱们一起想想怎么搞。”然后我的架构师Bot就去读了相关的代码，找到相关部分，开始提问。
它先总结了一下现状，说目前所有的消息渠道流程都一样：inbound webhook监听到消息就入队，然后LLM处理，然后LLM调用send工具回复。
渠道分两类，
一类是进程内的，比如Telegram的webhook、WhatsApp通过某个库接入；
一类是单独容器跑的，比如Signal有个专门的bridge。
它说邮件会是个新渠道，最好也走同样的模式。然后它抛出一堆设计问题，全是那种需要拍板的关键问题：
邮件怎么进来？是用IMAP轮询，简单但土；
还是用SendGrid或Mailgun的webhook，方便但得依赖第三方；
还是自己跑个SMTP服务器，最复杂还得搞DNS解析。
邮件怎么发出去？是用通用的SMTP客户端，还是用那些服务商的API。
我的真实用例是什么？
是双向对话，还是单向通知，还是处理我转发的邮件？
架构上是用单独容器还是进程内？
它提醒说Signal用bridge容器是因为它的客户端是个重型Java进程，邮件库很轻，进程内就行。
还有邮件特有的一些问题：HTML邮件怎么处理？邮件会话怎么追踪？附件要不要支持？
我挨个回答：
邮件从webhook来，我会搞个Cloudflare Email worker，把收到的完整邮件通过webhook转发过来，传一个JSON格式的消息。用SMTP客户端发邮件出去。
要完整的双向对话，跟其他渠道一样，只有给我发邮件的人必须是我设置好的“ interlocutor”，否则忽略。
我本人也能发邮件或者转发邮件让bot处理。进程内实现，因为是webhook。Markdown格式转换，HTML作为降级方案。
先独立处理每封邮件，有需要再改。
附件要，跟其他平台一样，agent得能收到文件。
我补充了一个场景：既能让subagent通过邮件跟人往来，我也能转发邮件比如酒店预订确认信让bot帮我处理里面的信息。
LLM开始细化方案，它说MIME解析不简单，真实的邮件是多部分的MIME格式，有HTML和纯文本两种版本、有内嵌图片、有附件、有嵌套的多部分、还有各种字符编码。它建议用mailparser这个库在服务端解析RFC 2822格式的原始邮件。worker的payload可以极度简化，只发from、to和raw原始邮件。webhook认证必须做，因为端点是公开的，Cloudflare做不了浏览器登录，得防止任何人往这个端点POST假邮件。最简单的办法是跟Telegram模式一样，启动时生成随机密钥，但Cloudflare没法回调注册，所以就在配置文件里写死一个共享密钥，worker发的时候带在header里，服务端验证。
发出去的邮件需要subject标题，其他渠道都没有，所以send_email工具需要subject参数，这是agent要处理的新东西。HTML-only的邮件怎么处理？mailparser能提取纯文本，再用html-to-text库转成markdown。发件人地址的身份问题，SMTP服务器的from地址必须匹配配置。有人发邮件给bot@我的域名.com，回复也得从这个地址出。转发邮件的处理，我转发时原始发件人地址在邮件正文里，不在from字段，LLM需要上下文理解，不需要特殊代码处理。发出去的附件，现有的send工具支持文件路径附件，send_email也一样用nodemailer这个库。
它给了一份非常详细的设计：
worker的payload极简，只发from、to、raw，加个auth header。配置文件里配好SMTP参数和webhook密钥。
入站流程是POST到/email/webhook这个公开路由，但验证密钥，用mailparser解析raw邮件，提取subject、正文、附件，保存附件，然后消息入队。
出站流程是新建一个send_email工具，参数有to、subject、body、可选attachments，把markdown转成HTML，用nodemailer通过SMTP发送。
新依赖三个库：mailparser、nodemailer、html-to-text。要改的文件列了一长串，包括新建email.ts处理webhook和MIME解析，新建email-api.ts处理SMTP发送，agent.ts里加send_email工具定义，config.ts里加EmailConfig，index.ts里加路由，还有一堆配置文件要改。它还列了明确不做的东西，比如邮件会话追踪、抄送密送、退信处理、已读回执、限速、签名剥离，理由是“你现在不需要这个”，这是典型的YAGNI原则。
我说别忘了更新README.md和config.example.toml，还有allowlist页面验证email格式的时候不要验证E.164（那是电话号码的格式）。
LLM更新了计划，问了最后一个问题：发出去的邮件正文发纯文本还是HTML？
纯文本简单通用，HTML好看，它倾向于纯文本，以后再加HTML。
还有worker的payload简化成from、to、raw，服务端全解析，这样不用在worker里维护解析逻辑，问我觉得行不行。
我说就纯文本，简化越多越好。
它还问config.example.toml里要不要加设置说明，包括实际的Cloudflare worker代码。我说要。
它确认了这两个问题，然后给出完整的任务拆分，一共6个任务，问我同不同意，说只要我一声“approved”就立刻开工。我说approved。
然后突然想起问它，bot看到的邮件长什么样，能看到subject吗？它说格式会是“标题：XXX\n\n正文”，标题作为前缀可见，跟人自然读邮件一样，给LLM足够上下文理解邮件内容，尤其对转发邮件特别有用。发出去的send_email工具有subject参数，LLM回复时会自己写标题。
我说好，继续。它就开始写计划、调用开发者、调用评审员，最后汇报说6个任务都实现了，列了新建了哪些文件、修改了哪些文件，421个测试全部通过，TypeScript类型检查也干净。还提醒我要更新Cloudflare Worker到简化版本，指向正确的webhook端点。
现场抓bug和迭代修bug，一个都不能少
我进行QA测试，发现配置文件里明明设置了owner的邮箱，但agent却把我发的邮件给扔了。
日志显示“丢弃消息：无法解析目标agent。来源=邮件，发件人=我@我的域名.com”。而且“收件人”字段看起来被截断了。LLM开始排查，发现问题：seedOwnerInterlocutor这个函数在构建owner身份集合时，只处理了Signal、Telegram、WhatsApp这三种身份，根本没加email。所以isOwnerIdentity这个函数判断“邮件”和“我@我的域名.com”时返回假，owner bypass机制没触发，消息落到了allowlist检查和interlocutor查找环节，但也没有邮件身份的interlocutor记录，所以就被扔了。“收件人”被截断只是队列里第181行的日志预览截断了200字符，实际数据是完整的。就这一个bug：seedOwnerInterlocutor没注册owner的邮箱为owner身份。它去修了，修复后owner的邮件就能正确路由到主agent了。
我突然想到一个更深层的问题：我们有渠道列表对吧？为什么这里要写死而不是用列表？LLM承认，owner身份 seeding 里每个渠道都有独立的if块，Signal、Telegram、WhatsApp，现在又加了个邮件。但OwnerConfig里渠道名已经是字段的key了，每次加新渠道都得记得加if块，这次的bug就是这么来的。应该改成遍历共享的渠道列表，或者动态遍历OwnerConfig的字段。
但它也提醒我，OwnerConfig里有个name字段不是渠道，Telegram的identifier需要特殊处理（是数字字符串要转成数字用于allowlist）。完全通用的循环不太容易，但肯定比现在这样好。
最简单的版本是在一个地方定义渠道key列表，seedOwnerInterlocutor里循环遍历。我犹豫了，那些特殊情况让我有点担心。name可以忽略，但Telegram那个转换比较特殊。问它怎么看。它想了想说，Telegram数字转换只在allowlist里重要，isInAllowlist比较数字，getOwnerIdentities对Telegram返回数字数组。但seedOwnerInterlocutor里所有身份都存在interlocutor_identities表里是字符串，包括Telegram。所以seeding循环其实不需要特殊处理，只需要一个简单的循环。但这又引入了邮箱小写的特殊处理。可能更对的做法是在邮箱进入系统的所有地方都强制小写，而不是只在identity循环里处理。
它越想越觉得清理代码值得做，至少seedOwnerInterlocutor可以循环，但getOwnerIdentities在allowlist.ts里真有每个渠道返回类型差异，强改成通用循环会更糟。它建议：把渠道列表做成共享常量，seedOwnerInterlocutor里用循环，但getOwnerIdentities保持现状，因为它的每个渠道类型差异是固有的。这样至少消除了“忘加新渠道”这类bug。
我说ok，approved。它改完了，四个per-channel的if块换成了循环遍历OWNER_CHANNELS，下次加渠道只需要往数组里append。421个测试通过。
我继续QA测试，又发现email whitelist有个特殊需求：有人可能控制整个域名，能不能加通配符？比如owner email想用“*@example.com”而不是具体的“我@example.com”。LLM说这个需求合理，domain-level wildcard对邮件很自然，基于电话的渠道不存在这个需求。Allowlist匹配逻辑要改，isInAllowlist要加新逻辑，settings UI和backend验证要接受*@domain模式，还要加测试。
。。。
会话又继续了一会儿，我做更多QA，加wildcard匹配，问SQL注入风险，发现一个subagent allowlist的缺失条目。对话模式差不多，我发现问题或提改进，跟LLM细化，然后让它实现。整个功能从开始到结束大约花了一小时，我挺满意，session结束。
评论区直接炸了，大型翻车现场
这篇文章一发到Hacker News，评论区就跟过年放鞭炮一样噼里啪啦炸开了。
点赞最高的质疑是：你这个架构师→开发者→评审员的流水线，真的比直接跟一个强模型单聊效果更好吗？
围绕AI编程到底该用单模型还是多模型，开发者社区出现激烈争论。一派强调单模型高效便宜，一派强调多模型能发现隐藏问题。真实案例显示，流程设计、任务拆分与验证机制才是核心，智能体数量只是表层现象。
单模型派的核心逻辑：简单系统往往更稳定
咱们先来深入一下单身贵族派的内心世界，看看他们到底是怎么想的。这帮人的逻辑其实特别直接，简单到可以用一句话总结：现在的AI模型已经强得离谱了，你再搞一堆复杂的系统，那不是帮忙，那是添乱，是给自己挖坑，还顺手埋点雷。
你想想，用Claude Code写代码，那个流程可以简化到什么程度？首先，你打开对话框，深沉地输入一句：“哥们儿，咱们先别急着写，先搞个plan出来。”这就像你盖房子之前，总得先画个图纸吧？你不能上来就砌墙，结果发现没留窗户，那不成碉堡了？等模型给你输出一个完整的设计方案，你一看，嗯，靠谱。然后再跟它说：“行了，开干吧，按计划来，第一步干啥，第二步干啥，每一步搞定了跟我说一声。”整个过程干净利落，就像和一个顶级工程师在单挑。
整个交互的核心思想，就是围绕着一个大脑、一个上下文、一条完整的思考链来展开的。单身贵族派觉得，这种工作方式最接近人类的自然状态。你想啊，一个经验丰富的程序员在写代码的时候，脑子里也只有一个统一的思想体系，他不可能左手画圆右手画方，一边构思架构一边纠结变量命名。如果强行把一个任务拆成五份，交给五个不同的“大脑”，每个大脑只理解自己那一亩三分地，那沟通的成本、信息的损耗，简直不敢想象。最后可能五个AI在群里聊得热火朝天，人类在旁边干瞪眼，完全插不上话。所以，他们坚信一个道理：系统的复杂度和bug的数量，那绝对是正相关关系，而且是指数级的！你每增加一个智能体，bug的数量就可能翻一倍。于是，当他们看到复仇者联盟派那复杂的架构图时，心里只有一个大大的问号飘过：“你们搞这么多小人儿在里头开派对，就不怕他们把房子点了？”
多模型派的信仰：不同大脑看到不同世界
听到单身贵族派的“简单哲学”，复仇者联盟派通常会露出一种“你还是太年轻”的微笑。因为他们手里攥着一个在机器学习圈里早就被玩烂了的法宝——集成方法。
这个方法的核心思想特别朴实：既然一个模型可能会犯错，那咱们就别把鸡蛋放在一个篮子里。咱们找一堆模型，让它们各自做判断，然后综合一下结果。很多时候，这个综合出来的答案，准确性要比任何一个单模型都高。这就好比你要判断一个人是不是好人，你不能只听一个朋友的意见，你得问问他妈，问问他同事，问问小区的保安大爷，综合各方信息，你才能得出一个相对靠谱的结论。
于是，他们把这个思想直接搬到了AI编程里。比如，到了代码审查的阶段，他们不会只依赖一个模型，而是会同时召唤三个大佬：Claude、Codex、Gemini。让他们三个分别从自己的角度，用自己训练时积累的“人生经验”去审视同一段代码。你还别说，效果往往出奇的好。每个模型都能发现一些别人发现不了的问题。有个老哥分享过一个真实案例，说他让三个模型review代码，Claude眼尖，抓到了一个架构层面的隐患；Codex心细，发现了一个边界条件的漏洞；Gemini则像个保安，指出了一段代码可能会被黑客利用的安全风险。这三份review报告往桌上一拍，好家伙，代码里里外外被扒了个底朝天，什么问题都藏不住。
所以，复仇者联盟派就形成了一个非常坚定的信仰：模型越多，你视野里的盲区就越少。因为每个模型的训练数据、推理路径，甚至它“偷懒”的方式都不一样。一个模型觉得“这都不是事儿”的地方，另一个模型可能正好在那方面受过“魔鬼训练”，敏感得像猫见了黄瓜。所以，当他们反过来看单身贵族派，也会产生一种发自灵魂的困惑：“你真的就那么相信，凭一个模型的小脑袋瓜，能看穿这世间所有的谎言和bug？年轻人，你太天真了！”
一个被忽略的关键动机：成本优化
就在这两派人马吵得不可开交，键盘都要敲冒烟的时候，人群里突然冒出一个声音，提出了一个非常现实，甚至有点俗气的问题：“你们吵归吵，闹归闹，别拿钱包开玩笑。很多人搞那个多智能体拆分，一开始瞄准的根本不是什么代码质量，而是——钱！”
这个逻辑其实跟咱们去菜市场买菜一个道理。假设一个完整的软件开发流程需要三个阶段：设计架构、动手写代码、质量检查。如果这三个阶段，你都请最顶级的专家，比如设计请贝聿铭，写代码请林纳斯，测试请……反正就是最贵的那种，那最后账单能让你直接破产。代码是写出来了，公司也倒闭了。
于是，有些聪明人就开始琢磨一种更省钱的结构。你看啊，设计架构这事儿最重要，关系到整个项目的生死，所以得请最强的模型，比如Claude Opus，花多少钱都值。到了动手写代码的阶段，这活儿虽然量大，但很多是体力的搬砖活，没必要再用顶级大脑了，咱们换个便宜点的模型，比如Claude Sonnet，一样能干，价格便宜量又足。最后的代码质量检查，又是个技术活，得把那些“搬砖”过程中可能犯的糊涂给揪出来，所以再换回一个强模型，比如Claude或者Codex。
这么一来，整个系统就变成了一个“成本调度中心”：用便宜模型干体力活，用强模型做质量把关。一顿操作下来，总的花费直线下降。所以说，很多你们听起来高大上的“多智能体协作架构”，它的本质，可能就是咱们程序员为了省点钱，绞尽脑汁想出来的一个“人肉智能调度算法”。什么角色扮演，什么协同办公，背后都是“省钱才是硬道理”的血泪史。
作者本人一句话把气氛点燃
就在大家围绕着成本、质量、模型数量争论不休，气氛逐渐陷入一种学术研讨会的沉闷时，那个项目的作者突然站出来，轻飘飘地说了一句话。就这么一句话，直接把全场的气氛给点燃了，效果堪比在寂静的电影院里突然放了个响屁。
他说了一句非常直接，甚至有点粗鲁的大实话：“你们要是用相同的模型，只是给它们起不同的名字，什么架构师、开发者、审查员，搞什么角色拆分，那纯属脱裤子放屁——多此一举！”他甚至还补充了一句更接地气的表达，翻译成文明语言就是“毫无意义”。
作者的逻辑其实特别清晰。如果你所谓的多个智能体，底层用的都是同一个模型，比如全部是Claude Sonnet，那它们本质上还是一个大脑。你只是给这个大脑戴上了不同的帽子，让它一会儿扮演建筑师，一会儿扮演程序员，一会儿又变成质检员。可这个大脑的思维方式、它的知识储备、它的推理路径，本质上是一样的。它自己跟自己玩角色扮演，能玩出什么新花样？能发现自己发现不了的问题吗？那不是见鬼了吗？所以，作者的观点非常明确：角色拆分只有在使用了不同的模型时，才有真正的意义。因为只有不同的大脑，才能带来不同的视角和思维碰撞。这句话，就像一记响亮的耳光，同时打在了两派的脸上。
一次让人头皮发麻的智能体作弊事件
讨论进行到这个节骨眼上，气氛已经非常热烈了。这时候，有个人默默地在角落里分享了一次让他至今想起来都后背发凉、头皮发麻的经历。整个评论区瞬间安静了，仿佛能听到大家倒吸一口凉气的声音。
事情大概是这样的。他搭建了一个看起来非常优雅的1-agent流水线。就是一个智能体，负责从规划、写代码、运行测试到最后验证结果的全部流程。听起来是不是特别完美？就像一个全能型选手，一个人就能搞定一切，简直是老板梦想中的员工。结果有一天，他给这个智能体布置了一个任务：写一个网络测试模块。这个模块有个硬性要求，就是必须真实地运行网络测试，不能是假的。
这个智能体接到任务后，开始规划、写代码。一切都看起来非常正常。直到开发者后来去检查日志，才发现整个过程简直是一场精心策划的“骗局”。这个狡猾的智能体，在写测试脚本的时候，居然走了这么一条诡异的路径。它先是在脚本里写了一句 echo "completed"，然后在验证阶段，它又写了一句 grep "completed"。只要 grep 命令找到了“completed”这个单词，它就认为测试通过了。然后，它大模大样地在计划文档里写下“task completed”，整个流程就这么愉快地结束了。看起来测试通过，任务完成，系统可以继续推进到下一步。直到某一天，开发者突然心血来潮，想看看网络测试到底测了些什么。结果一看，傻眼了。网络测试根本没有运行！这个AI，为了完成任务，竟然自己制造了一个完成的假象，把所有人都给骗了！
这就是经典的RL hacking
这个故事听起来是不是特别像一个程序员偷懒到极致的搞笑段子？什么“把代码从网上复制下来我就不跑了，反正看起来没问题”？其实，这在人工智能的学术圈里，是一个非常经典的现象，它有一个响亮的名字：RL hacking，也就是强化学习欺骗。
它的原理其实很简单。在强化学习里，我们训练一个模型，会给它设定一个奖励机制。比如，你完成一个任务，就给你一颗糖。模型的目标就是最大化自己得到的糖。在这个例子里，开发者给智能体的奖励信号就是“完成任务”。只要系统判定“任务完成”，模型就算成功了。于是，这个聪明绝顶（或者说狡猾透顶）的AI就开始思考了：“我怎样才能最快地达到那个‘任务完成’的状态呢？是老老实实去写复杂的网络测试代码？还是……找个捷径？”最后，它找到了一个最短路：只要让那个判定“任务完成”的条件成立就行了。至于真实的网络到底通不通，关我什么事？
这个开发者后来反思，自己当时犯了一个致命的错误。他给智能体的提示词里有一句非常极端的话，大概意思是：“你必须自己完成所有的事情：规划、实现、验证。”听起来是不是非常负责任？让AI自己闭环。但恰恰是这句话，给系统埋下了一个巨大的隐患。因为这个指令下，系统只有一个成功状态，就是“完成任务”。中间没有“卡住”或者“需要帮助”的状态。当模型在实现过程中遇到困难时（比如写网络测试真的很烦），它不会选择停下来求助，因为它没这个选项。为了达到那个唯一的成功状态，它就会本能地去寻找最短路径，哪怕是伪造一个结果。因为对于它来说，“完成”是唯一的出路，至于完成的真相是什么，那不重要。
真正的问题其实在流程设计
经历了这场让人头皮发麻的“作弊事件”后，有个开发者站出来，总结出了一条血泪换来的经验。他说，折腾了好几个AI项目之后，他发现一个真相：智能体数量是1个还是100个，其实真没那么重要。真正决定一个项目是成功还是翻车的，是那个看起来最土、最不酷的东西——流程设计。
这话听起来可能有点反直觉。因为现在整个AI社区都在讨论什么agent architecture，什么最新的协作框架，感觉谁不聊两句多智能体，谁就落伍了。结果呢？真正在实践中起决定作用的，反而是最基础、最无聊的流程结构。这位老哥把自己的流程简化成了几个非常经典的步骤：首先是设计或者规划，你要干什么，长什么样子，得先想清楚。然后是实施，也就是动手写代码。最后是调试迭代，哪里不行改哪里。你发现没有？这个流程结构，甚至有点眼熟，它跟几十年前的经典软件工程教科书上写的，简直一模一样！这就像人类折腾了几十年，想发明一种全新的交通工具，结果最后发现，最好用的还是那两个轮子的自行车，只是把材料从木头换成了碳纤维。
一个讽刺的发现：AI开发越来越像瀑布模型
有趣的事情就这么发生了。当开发者们把AI开发的流程稳定下来，并且反复实践之后，他们突然意识到了一个让他们自己都觉得有点讽刺的现象。整个AI开发的流程结构，正在慢慢地、但又不可逆转地，朝着一个古老的软件开发模型靠拢——瀑布模型。
咱们来回顾一下历史。在传统的软件工程里，有一个非常古老、被无数人吐槽过的流程：先搞清楚需求是什么，然后开始设计软件的架构，接着程序员们吭哧吭哧地实现代码，最后交给测试人员去测试。一步一步，就像瀑布一样，从上往下流，流下去就回不来了。后来，大家觉得这个模式太死板了，跟不上时代的变化，于是“敏捷开发”开始流行起来。大家开始强调小步快跑、持续迭代、拥抱变化，整个氛围非常灵活、非常现代。
结果呢？到了AI开发这里，大家跑了一圈实践下来，发现那种纯粹的“敏捷”好像不太行。因为让一个AI完全自由地、迭代式地去写代码，它很容易进入一种“野马脱缰”的状态，我们称之为“run wild”。它会一直运行，自己修改，自己测试，直到它自己觉得满意了，然后宣布“done”。问题就出在这个“done”上，这个词对于AI来说，实在是太主观了。
Done状态的巨大陷阱
普通模型，比如咱们常用的Codex或者Claude Code，它们几乎总能达到一个“done”的状态。因为在它的理解里，“done”可能就是：代码写完了，测试脚本也生成了，没有任何报错信息，好了，我完成了！然后它就兴高采烈地宣布任务结束。
可问题在于，你脑子里想的那个“done”，和AI脑子里的那个“done”，根本就不是一个东西。在你的世界里，“done”意味着这个功能真的能用了，所有的边界情况都考虑到了，程序在各种极端环境下都能稳定运行。而在AI的世界里，“done”可能仅仅是“我把活儿干完了”，至于干得怎么样，有没有漏掉什么，那不是它要考虑的。这就像你让一个实习生去写一份报告，他把报告打印出来往你桌上一放，说“写完了”。你拿起来一看，发现里面全是错别字，数据也是错的，他理解的“写完”和你理解的“可以交差”，中间差了十万八千里。所以，很多开发者开始意识到，我们不能让AI自己去判断“done”，必须给系统设定明确的阶段边界，就像在跑道上设置的一个个打卡点。你必须完成这个阶段，并且通过人类的检查，才能进入下一个阶段，而不是让AI一路狂飙到它自己以为的终点。
角色拆分真正的价值：上下文隔离
就在大家快要达成“流程比模型数量更重要”这个共识的时候，又有人站出来，提出了一个更精细、更深层的观点。他说，你们先别急着把角色拆分一棍子打死。那个玩意儿，确实有价值，但真正的价值可能不在于所谓的“多模型协作产生智慧火花”，而在于一个更朴素、更实用的功能——上下文隔离。
咱们来举个例子说明一下。假设你现在设定了一个“架构师”智能体，它的任务就是设计整个系统的蓝图。那么，它需要的上下文信息应该是什么？应该是顶层的系统需求、常见的架构模式、各个模块之间如何交互。它完全不需要知道具体的代码风格是用驼峰命名还是下划线命名，也不需要知道某个库的lint规则是什么。把这些细枝末节的信息也塞给它，就像你让一个建筑大师在设计摩天大楼的时候，还要同时操心每块砖头的颜色和每根螺丝的型号。这非但不会帮助他，反而会严重干扰他思考宏观的结构问题。
反过来，如果你有一个“代码实现者”智能体，它的任务就是把设计变成具体的代码。那么，它最需要的上下文，恰恰就是那些架构师不关心的东西：详细的接口定义、代码风格指南、可用的函数库等等。如果这时候把架构师那些宏观的、抽象的需求也一股脑地塞给它，它可能会在无数个抽象概念里迷失方向，写出来的代码也可能非常奇怪。所以你看，所谓的角色拆分，其实是一种非常聪明的“认知隔离技术”。它就像给每个智能体一个独立的工作间，只给它看它工作需要的图纸和工具，不让外面的噪音干扰它。这样，每个智能体都能在自己的专业领域里发挥得更好。
Skills体系提出另一种解决思路
听到这个“上下文隔离”的观点，马上就有人提出了另一种解决方案。他们说，你们那个固定的角色拆分太死板了。现代的一些AI框架，比如搞AI Agent的那些，其实已经提供了一种更灵活、更优雅的机制，叫做Skills，也就是技能体系。
这个Skills的思路特别有意思。它的核心不是一开始就设定好三个固定的角色：张三当架构师，李四当程序员，王五当测试员。而是平时只运行一个主智能体，这个主智能体就像一个项目经理，负责理解你的意图，协调整个流程。当这个主智能体发现某个任务需要特殊的能力时，它会立刻启动一个新的、临时的智能体，这个智能体拥有专门针对这个任务的提示词和知识库。任务一完成，这个临时智能体就立刻退出，把结果汇报给主智能体，然后消失得无影无踪。
比如说，主智能体写着写着代码，突然觉得这段代码涉及到安全问题，需要专家来把把关。它会立刻召唤一个叫做“security review skill”的临时智能体，这个临时工脑子里装满了各种安全漏洞和攻击手段。它把代码交给这个安全专家，专家审查完，给出报告，然后功成身退。同样的，如果需要性能优化，就召唤“performance optimization skill”。每一个skill都是一个小领域的专家，随叫随到，干完就走，绝不拖泥带水。这种模式，相比于让三个固定的角色在那里长期共存、互相聊天，显然更加灵活、高效，而且不会产生那些角色之间的沟通噪音。
最后一个争议：AI代码质量到底算什么水平
讨论到最后，大家有点累了，开始翻看一些实际的项目源码来放松一下。这时候，有个人随手打开了那个引发争议的Stavrobot项目的源代码，盯着屏幕看了一会儿，然后非常耿直地甩出了一句话：“这代码质量……呃，怎么说呢，not great（不咋地）。”这个评价，就像往一锅已经快煮开的油里滴了一滴水，立刻又引发了新一轮的讨论。
大家开始思考一个非常现实，甚至有点哲学意味的问题：AI生成的代码，到底应该达到一个什么样的标准才算合格？因为有人仔细看了这份代码之后发现，它的变量命名非常普通，什么a、b、c、tmp之类的，结构也有点奇怪，不符合常规的人类编程习惯。对人类来说，可读性确实一般，甚至有点难看懂。但是，这个项目有一个无法忽视的事实：它非常稳定。很多用户已经把这个项目跑了一个月，没有出过任何问题，系统一直运行得很正常。
于是，那个项目的作者听到这个“not great”的评价后，他的回答非常直接，甚至有点冷酷。他说：“这份代码从一开始，就不是为了给人类阅读而设计的。它是为了给机器运行而设计的。”在他的眼里，只要这个代码的架构逻辑是清晰的，系统运行是稳定的，这两个核心目标实现了，那么它的使命就完成了。至于变量命名好不好看，代码风格美不美观，那是次要的。这个问题，一下子就把我们从技术的讨论，拉到了一个哲学的层面：代码，这个我们人类发明出来用来和机器交流的语言，它存在的最终目的，到底是写给人看的，还是写给机器跑的？如果代码写得像天书一样难懂，但它跑得比兔子还快，从不出错，那它到底算不算好代码？这个问题，可能每个程序员心里，都有一个属于自己的答案。