选对模型做对事：AI编程四席位分工法

同一个前沿模型，一个下午干了四件事——走查UI、写架构方案、做40文件重构、过安全审查。四件事都算合格，但真正合适的只有一件。到了晚饭时间，手里多了一个自信却错过关键接缝的方案、一个"能编译"但改错抽象层的重构、一份描述点击过程而非复现失败的UI报告、一次听起来周全却放过爆炸半径的审查。一个模型，四份工作，一个人的下午被稀释了。

选对模型做对事

常见建议的反面

通常的建议是"选一个最喜欢的模型一直用"，或者"追最新榜单"。但作者提出了一个更安静的逆向思路：模型不是你要结婚的性格对象，它们是乐器。真正的技能是把乐器匹配到工作阶段，并在打开标签页之前先写下什么叫"完成"。

这篇文章是「Ship With Agents」系列第四篇。前几篇分别讲了长任务运行、把付费栈当作有交接的团队名册、以及从手机端检查进度而不假装手机是完整IDE。这一篇的核心是：不同席位，不同证据。

同一个模型不等于同一份工作

把每个难题都当成"问最聪明的模型"，你优化的是口才，而不是你下一步需要的产物。

UI走查需要模型（及其脚手架）能待在产品路径里，故意让复现失败，并带回证据
规划阶段需要能压缩约束、而不发明你没要的架构
长重构需要对跨文件保持耐心、尊重既有接缝，并且停止条件不是"看起来更干净"
审查需要对抗性注意力：找漏洞、抓过度声明、指出你忽略的爆炸半径

这些是不同的失败模式。擅长长文的模型会愉快地写出一份漂亮但错误的方案；擅长代码编辑的模型会因为没人告诉它爆炸半径而"好心"扩大范围；擅长批判的模型如果没被指定席位，就会开始重写整个功能。

标签页上的logo，不如你摆到它面前的契约重要。工具确实不一样——延迟、上下文行为、工具调用、固执程度、对结构的品味都不同。但要把这种感觉从"凭直觉"升级为"角色分工"。

我实际会安排的四个席位

以下是我在实践中使用的名册。名字会随着实验室发布新品而变动，但席位不应该变。

一、UI与产品路径工作

职责：进入真实路径（或预发副本），复现、观察、返回证据。证据是失败到通过的路径、未损坏屏幕的截图、trace id——而不是一句"现在应该能用了"。

我需要模型在工具调用下保持具体，UI出问题时不要自己编故事。如果修复后Agent不能把旧复现验证成失败，那它就是在起草，没完成。

trace id（追踪标识符）是分布式系统中用于串联一次请求全链路日志的唯一字符串。当一个操作跨越多服务、多组件时，同一个 trace id 会出现在所有相关日志里，让排查者能把散落各处的记录拼成完整时间线。在 UI 走查场景中，它的价值在于把「我点了这里，然后出错了」这种口述，变成可被他人复现和验证的客观锚点——审查者拿到 trace id 就能定位到具体那次调用，对照参数、响应和耗时，而不是依赖报告者的记忆与叙述。没有 trace id，UI 报告很容易滑向「重述操作步骤」，反而掩盖了真正失败的请求。

二、规划与压缩

职责：把混乱问题压缩成下一层能执行的短契约。目标、约束、爆炸半径、验收检查、未解问题。证据是一份能直接粘进实现阶段、不需要从聊天语气里重建意图的简报。

我需要会砍的模型。如果方案长成一部小说，那要么选错了流程，要么选错了席位。

三、长重构与多文件变更

职责：把接缝移到代码库别处，而不是为了好玩重写产品。证据是相对分支的小而可逆的diff、附上的测试或脚本检查、清晰的回滚路径。

我需要能记住局部架构、并在工单只是"改名+更新调用点"时拒绝史诗级重写的模型。过夜循环只适合在痕迹能扛过标签页崩溃的场景（参见「Let It Run for Days」）。

**接缝（seam）**是 Michael Feathers 在《修改代码的艺术》中提出的概念：代码库中可以在不修改某段逻辑本身的前提下，改变其行为或替换其依赖的位置。典型接缝包括接口边界、依赖注入点、可覆写的工厂方法等。重构的核心判断不是「代码看起来是否更干净」，而是「变更是否沿着已有接缝移动了职责」。如果一次重构硬生生穿过接缝、把抽象层推翻重写，它就从安全的移动变成了高风险的手术，回滚成本和冲突面都会骤增。识别并尊重接缝，是长重构席位能否产出小而可逆 diff 的关键。

四、审查与对抗性通过

职责：在生产环境之前找到漏洞。风险清单、可证伪点、缺失的检查、过度声明。证据是一份让实现者感到"有用的不舒服"的列表。

我需要愿意"粗鲁"的模型。如果它开始动手建功能，那就是我把它拉出了自己的车道。

作者把这些席位映射到Claude Max、ChatGPT Pro、SuperGrok、Cursor和Antigravity：持久性和长循环在一处，压缩在另一处，对抗性审查在第三处，仓库本地实现放在diff所在之处，产品走查放在证据所在之处。映射关系下季度可能会变，但席位不变。

**爆炸半径（blast radius）**指一次变更失败时，受影响的范围有多大——从单个测试用户、一个预发环境，到全部生产流量、下游依赖方乃至数据不可逆损坏。审查席位的重要职责之一，就是主动估算并明确指出这个范围，而不是只看代码是否正确。常见做法包括：梳理变更触及的调用链、确认是否有共享状态或全局配置被改动、检查降级与回滚路径是否覆盖最坏情况。一个听起来周全却没说清爆炸半径的审查，等于把「影响可控」当作默认假设，而这恰恰是事故最常见的起点。

一个上午的实操：一张工单，四种乐器

不是舞台演示，是具体形态。

工单：预发环境上一个设置保存后刷新会丢失一个字段。经典问题，容易讨论，也容易在错误的层次"修好"。

我不会打开最强的模型，把整个故事粘进去。

第一步：规划席位，五分钟。 只给简报：在预发环境保存和重载时保留字段X。爆炸半径：预发、测试用户、不写生产。停止条件：脚本化重载显示X仍存在，外加空字段情况的说明。未解：客户端状态 vs API省略 vs 缓存。这份简报就是契约。

第二步：对抗性席位，带着简报和第一个假设。 我要的是重拳，不是重写。它返回三条：检查PATCH载荷、检查空字符串被当作省略、检查第二个标签页竞态。现在实现者有了可证伪点，而不是凭感觉。

第三步：重构或实现席位，在仓库里拥有变更。 最小可逆修复、合适的测试或脚本、我能回滚的PR。

第四步：UI席位走一遍简报命名的同一路径并返回证据。 重载前后对比。如果空字段情况仍失败，就明确指出来。

如果四个阶段都用同一个模型，我得到的还是文字。我不会在接缝处得到干净的产物。这个上午能成立，是因为每个席位产出该席位该有的证据，而交接由我自己负责。

匹配是一个写下来的决策

人们跳过匹配这一步，因为觉得比"直接问"慢。

前30秒确实慢，整个下午会更快。打开标签页前写三行：

席位：UI、规划、重构、还是审查（选一个）
产物：这轮结束时必须存在什么（简报、diff、证据包、清单）
停止条件：在产品或仓库里什么叫"完成"，而不是模型自述里的完成

那张便利贴就是全部技能。没有它，每个模型都变成有编译器的聊天治疗师；有了它，下个月换模型也能保留操作系统。

有界、可逆、可检查依然适用。席位卡应该说明模型可以写什么、只能读什么、以及如何撤销一个糟糕的小时。演示能量是一个模型在每个阶段听起来都很聪明；生产能量是四个无聊的产物能扛过一次交接。

**停止条件（stop condition）**不是模型自述的「我认为完成了」，而是一个在产品或仓库层面可被第三人独立验证的状态：某个脚本化重载显示字段仍存在、某个测试从红变绿、某个 trace 复现出旧失败。把停止条件写进契约，等于提前把「完成」从主观判断转为客观证据。它同时约束模型的范围扩张——当模型想顺手「优化一下」时，停止条件会把它拉回工单边界。没有停止条件，模型倾向于用更长的输出替代更明确的收敛，轮次被无限延长，交接却始终无法发生。

跳过匹配会出什么问题

规划模型做UI走查：得到一个自信的bug理论，零路径证据。你"修复"了心理模型，屏幕仍然丢字段。
UI走查者做多文件重构：得到点击叙述和可见症状附近的机会主义编辑。抽象层仍然是错的，bug移动了位置。
重构模型做安全或爆炸半径审查：得到一个更干净的模块和一次安静的权限扩大。PR看起来很整齐，风险变漂亮了。
审查模型做绿地规划：得到一个对还不存在的方案的精彩批判。当调料有用，当唯一一道菜就是致命的。

安静的失败最爱错配的席位。输出听起来仍然像工作。下一个人（通常是两小时后的你）分不清哪个主张来自哪个阶段。这就是同一个bug一天栽两次的原因。

把默认值砍成每轮一个席位

如果你的默认值是"打开最好的模型把整个问题倒进去"，改掉这个默认值。

每轮一个席位，一个产物，然后交接。 没有契约的模型跳来跳去仍然是抖动；有契约的模型匹配才是把技术栈变成团队的方式。

你不需要每个模型和每个任务类型的完美矩阵。你需要的是更少的、假装一次能做完所有工作的轮次。新模型发布时，用一张试运行工单和写好的停止条件把它提升到一个席位；如果它只是为错误的产物写出更漂亮的段落，就降级。

工具很便宜，契约才是工作。选模型就是选你即将执行哪份契约。

底线

"什么都能干"的最佳模型，通常是对下一个产物而言错误的模型。

把席位匹配到工作，写下停止条件，要求那个席位该有的证据。口才不是发货闸门——简报、diff、证据和清单才是。