北京
你打开一个对话窗口，让最喜欢的模型从头到尾做完需求规划、代码编写、逻辑审查和功能测试。看起来省事，其实是在流水线上埋雷。
同一个模型写代码时看不到的缺陷，审查时同样看不到。写的人和审的人共用一套大脑，第二意见的价值直接清零。更麻烦的是，一旦这家厂商宕机、限流或者涨价，整条流水线就跟着停摆。
代码库也会慢慢染上某个模型的默认风格偏好。那些换个模型一眼就能发现的可读性问题，被同一种审美惯得心安理得。测试用例只覆盖作者脑子里想过要避开的失败场景，真正的边界异常反而悄悄漏过去。
你已经习惯让不同的人做技术评审和代码评审，却让一个模型审计所有东西，这就打破了最基本的制衡原则。
正确的做法没那么复杂。选一个推理能力强的模型做需求拆分，只让它做只读规划。把写好的计划丢给一个跑得快、成本低的代码调优模型，放在能自动执行测试的沙箱里干活。每个阶段配一个独立子代理，给够它需要的上下文，不多给。
审查环节交给没碰过代码的那个模型。当你的规则够清晰、可复用技能和沙箱够稳固之后，审查甚至可以用便宜模型。让它专门盯着作者漏掉的边界情况，把测试套件补齐。
每次记录下哪个模型干了哪个阶段，做了哪些前提假设。建一份架构决策记录，方便以后回头看是谁的盲点在重复出现。隔几个月轮换一次模型配对，随着新版本发布，不同模型的强项一直在变。
还可以用TDD的对抗思路来安排任务：让一个模型写测试，另一个模型写最简实现让它通过，再换第三个模型决定值不值得重构。每个模型都只做自己最擅长的事，同时替别人发现盲区。
这样拆开之后，收益很明显。缺陷更容易被揪出来，因为审查模型的本能盲区和编写模型不同。成本也能匹配复杂度，最贵的推理模型只用在规划阶段，日常语法工作交给便宜的。测试覆盖范围更广，训练数据不同的模型会想出原作者根本没想到的边界用例。
角色定义被倒逼得更精确，精确到随便哪个模型都能套进去执行。代码风格不再被某一家模型带偏，你的标准就是你的标准。供应商依赖也被摊开了，一家出问题整条线不至于瘫掉。
每个模型都背着一身训练历史留下的惯用陷阱，这决定了它会怎么想问题、会漏掉什么、会过度关注什么。别把这种隐形成本堆在同一个棋盘上。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
