这就是"AI 是乙方"这个比喻成立的地方。乙方不是没价值，恰恰相反，好的乙方能把大量执行工作接过去。但甲方如果说不清需求、不给清验收标准、看不懂交付物，最后项目一样会烂。AI 越强，人越不能只做"发一句 prompt 的甲方"，而要学会做真正的甲方。
我的判断就一句话：AI 时代人的稀缺能力，不是亲手完成每一步，而是把工作改造成 AI 可执行、人类可验收、组织可追责的任务。
为什么"乙方"这个比喻用得上
把 AI 说成工具，说的是"谁用谁知道"；说成员工，说的是"要管要带要考核"。这两种说法都不太贴。AI 更像一个高吞吐、低摩擦、可反复返工的乙方。
乙方的第一个特征，是必须拿到清晰 brief 才能干活。GitHub 在讲 Copilot coding agent 的工程实践时反复强调的一件事是：生成代码是直接了当的，审查代码、确保它符合标准、做了你想做的事、能被你的团队维护，仍然需要人的判断。OpenAI 推 AGENTS.md 的背后逻辑也一样：给 AI 一份可读的项目工作手册，而不是指望它从对话里猜出你的规范。这不是 prompt 工程的花活，这是甲方给乙方的施工方案。
乙方的第二个特征，是交付要过验收，不能自证完成。GitHub Copilot coding agent 默认的产品形态是"做完 tag 你 review，CI/CD 需要人工批准"。OpenAI 在 Codex 的介绍里也写得很明白：用户仍然必须在集成和执行前手动审查和验证所有 agent 生成的代码。这些都不是谨慎派的说教，而是真实产品里默认打开的保护机制。
乙方的第三个特征，是可以给更多自主权，但关键控制权必须留在甲方。Anthropic 讲有效 agent 的时候把话说得很清楚：需要清晰的成功标准、反馈循环、以及有意义的人类监督。这不是为了让人多一道章，而是因为一旦 agent 真的有权限敲键盘、改文件、发请求、调 API，任何模糊的授权都会在某个角落被滥用。
生产力收益是真的，但有三重打折
外部数据里最被引用的一条，是 St. Louis Fed 的估算：生成式 AI 用户平均每周节省 2.2 小时，折算约 5.4% 的工作时长。Harvard 和 BCG 对咨询顾问的实验更乐观：能力边界内的任务，效率提升 25%，完成量多 12%，质量高出 40% 以上。这些数字是真的。
但它们有三重需要打折的地方。
第一重，这些多是自报数据。"用得爽"和"真的节省"在问卷里分不开，把 2.2 小时理解成每周凭空多出 2.2 小时新产出，是过度解读。
第二重，能力边界外的使用会反向扣分。同一项 Harvard / BCG 研究还有另一个结论：当任务超出 AI 能力边界时，使用 AI 的顾问正确率反而下降 19%。Harvard Crimson 对此有句话很尖锐：更快地得到错误答案，不算生产力。
第三重，对经验丰富的知识工作者，收益甚至可能是负的。METR 在 2025 年做过一次很严谨的 RCT，针对经验丰富的开源开发者在真实代码任务上做了对照实验。反直觉的结论是：在 20 分钟到 4 小时的真实 coding 任务上，使用 AI 的开发者更慢。不是工具不好，而是熟练者知道自己怎么写代码，多出来的是"审查加纠偏加返工"的开销。
三重折扣叠在一起，比较诚实的总结是：AI 的生产力收益真实存在，但会被任务类型 × 使用者经验 × 验收门槛三个维度调制。哪一维错位，账就可能从正变负。
比喻不要用过头，要补三个原生批判
"AI 是乙方"是一个有用的起点，不是终点。把它用过头，会漏掉三个在传统甲乙方关系里不存在的问题。
第一个问题：AI 乙方的能力会持续漂移。传统乙方能力相对稳定，甲方几次合作之后可以把验收流程固化下来。AI 乙方不是这样。基础模型每几个月一次跃迁，同样一份 AGENTS.md，半年前跑不动的任务今天可能一把过；同样一份 review 清单，上个月抓得住的 bug 这个月可能已经不会再出现。甲方能力的本质不是"建立一套 SOP"，而是持续校准：每隔一段时间重新评估哪些任务可以放权、哪些必须收回、哪些模板需要重写。这种动态校准是传统甲方管理里没有的职责。
第二个问题：验收能力的自我循环困境。传统认知里，能判断代码好坏的人是写过很多代码的人，能判断方案好坏的人是做过很多方案的人。如果未来大部分执行被 AI 接走，新一代从业者没有足够的执行经验去建立判断力，几年之后谁来做验收？这个循环从个人层面延伸到组织层面：一家公司如果过早把所有"动手活"交给 AI，它在一段时间内看起来效率很高，但当下一次模型能力波动、任务超出边界、或出现新型业务场景时，它可能已经没有足够多的"能判断对错"的人了。
第三个问题：谁来验收验收者？如果甲方能力是判断乙方做得对不对，那谁来判断甲方做得对不对？当人做验收时，他的判断由同伴、上级、客户的反馈来校准；当验收者也开始借助 AI 辅助时（比如用另一个模型 review 前一个模型的产出），验收本身就进入了 AI 辅助的链条。整个体系需要一个新的"元锚点"去定义什么叫做对。目前没有一个行业有清晰答案。
我没有全套方案。但我觉得这三个问题必须显式摆在桌面上，而不是被一句"AI 像乙方"顺滑地盖过去。
甲方新能力是四件事，不是"会写 prompt"
收益和风险说清楚之后，落回到"一个人、一个团队、一个管理者到底要做什么"。甲方新能力不是"更会写 prompt"，而是四件事。
第一件：把目标讲清楚。不是把需求写成多长的文档，而是把目标讲成可被执行的形状。一个可以交给 AI 的目标应该能回答三个问题：产出物是什么、约束条件是什么、输入从哪里来。OpenAI 推 AGENTS.md 的背后逻辑就是这个：给 AI 一本可读的工作手册，而不是期望它从对话里猜出项目规范。
第二件：把验收标准写在前面。大部分 AI 项目翻车的原因，不是 AI 做错了，而是甲方没讲清楚什么叫做对。验收标准的简单模板是：用什么方式验证、谁来验证、失败时怎么处理。代码场景里这套标准天然存在（单元测试、集成测试、PR review）；在写作、分析、决策这些场景里，这套标准需要被显式建出来。
第三件：看懂过程证据。AI 说"已完成"不算完成。过程证据包括：它调用了哪些工具，读了哪些文件，写了哪些内容，跳过了哪些步骤。GitHub 的 Mission Control 有一句我很同意的话：当检查失败时，不要简单重启 agent，要调查为什么失败。甲方看过程证据的能力，是防止"表演式交付"的唯一办法。
第四件：为结果负责。OpenAI 在讲 AI-native engineering team 时把话说得最直白：工程师最终为部署到生产环境的代码负责。这里不需要太多解释。把任务外包给 AI 不改变责任归属，只改变执行方式。如果一位产品经理说"这个需求是 AI 写的，不准的地方不怪我"，这家公司的验收体系已经塌了一半。
这四件事不对称：讲清楚目标偏向个人技能，写验收标准偏向团队机制，看懂过程证据偏向工具链和可观测性，为结果负责偏向组织文化。任何一件没做到，剩下三件的价值都会大打折扣。
对三类人的不同含义
如果你是个人从业者，真正应该练的不是"让 AI 写得更多"，而是四件事里的前两件：把目标讲清楚、把验收标准写在前面。大多数人用 AI 的瓶颈不是模型不够强，而是自己没想清楚要什么。一个简单的自检：每次使用 AI 前，用 30 秒写下"这次我希望它产出什么、我怎么判断它做到了"。写不出来，说明任务本身还没定义好，让 AI 先做只会把不清晰的需求放大。
如果你是团队 leader 或项目 owner，真正该投入的不是"更强的工具"，而是任务模板、验收标准、过程可观测性。McKinsey 的 State of AI 调研指出，高绩效组织比普通组织更可能"根本性重新设计个人工作流"。重新设计工作流听起来抽象，落到具体就是：哪些任务可以交给 AI、输入从哪来、输出要达到什么标准、谁来 review、失败如何升级。这些不是 AI 项目，是组织工程。
如果你是管理者，值钱的管理工作正在被重新定义。AI 不会自动消灭管理工作，但会压缩低价值的管理工作：进度追踪、信息汇总、会议纪要、催办、格式校对，这些会被逐步吸收。真正留给管理者的价值点会往两端集中：一端是定义什么叫做对（验收标准、质量基线、风险边界），一端是为组织判断力的长期再生产负责（有没有培养出能独立判断的人，有没有机制持续校准能力边界）。把管理者的 KPI 从"推动多少事发生"转向"让多少事被判断得对"，是这一阶段组织设计的关键题。
回到开头
回到开头那个场景。真正困扰人的不是 AI 做得快，而是判断它做得对。这件事过去也存在，只是过去的甲方通常自己是乙方出身，自己干过几年，验收时的肌肉记忆已经内化，所以"多一道审核"看起来不费力。现在 AI 把执行的成本压到很低，同时把执行的数量和速度拉到很高。当产出像潮水一样涌过来，"验收"就不再是工作流程里的一个步骤，而变成工作本身。
这个时候，"当好甲方"就不再是比喻，它是一组具体能力：讲清楚需求、写清楚验收、看懂过程证据、为结果负责。这四项能力过去分散在不同角色里（产品、架构师、测试、leader），现在会被压到每一个严肃使用 AI 的从业者身上。
如果让我从这轮调研里挑一个最值得带走的直觉，就是这句话：AI 时代最贵的能力，是知道什么叫做对了，并能在一个合理成本内把这件事验证到位。
本文的局限性
第一，引用的多数数据来自 2024 到 2025 年的研究。2026 年上半年以来的模型跃迁在这些研究基线里还没有充分体现，METR 那种"经验开发者用 AI 反而变慢"的结论是否在新一代模型上仍然成立，我没有把握。
第二，本文的甲乙方比喻天然偏向知识工作，尤其是软件工程。coding agent 是整个调研里证据链最清晰的一块，但它不代表所有知识工作。在销售、教学、客服、设计这些场景里，验收标准的结构完全不同，这套四件事框架需要重新具体化。
第三，关于"验收能力自我循环"和"元验收问题"，本文提出的更多是判断和警告，不是方案。如果未来一两年这个领域出现真正有效的组织实践，文中的结论应当被修订。