第四章的追问#
第四章让我们看到了一个清晰的结论：人对线上系统的最终责任不可转移。 AI 可以生成代码、运行测试、分析日志，但 AI 不会承担责任。当 sprint 因为错误预算耗尽而停止时，需要人类来判断——验收标准是否设得太高？Generator 的能力是否不足？是继续投入预算，还是调整需求范围？
这些决策涉及业务判断、成本权衡和风险承受度。但这里有一个更深层的问题没有被回答：在 Harness 框架中，人类与 AI 的具体分工边界在哪里？
不是"哪些工作给 AI、哪些工作留给人"这么简单。真正的问题是：当 AI 接管了越来越多的执行层工作后，人的核心价值从"动手"转向了哪里？ 各岗位的能力模型需要如何重构？
这就是本章要建立的"人机协作范式"——不是一张分工表，而是一套认知框架：人类从"执行者"变为"判断者"，从"做事"变为"验收事"。
5.1 范式转移：从"人执行"到"人判断"#
Harness 框架运转起来后，一个令人不安又令人兴奋的事实会逐渐浮现：AI 在执行层的效率已经超越人类。
Generator 可以在几分钟内写出人类需要几小时才能完成的代码；Evaluator 可以在几十秒内运行完人类需要半天才能跑完的测试套件；Planner 可以在一轮对话中梳理出人类需要开三次会才能对齐的需求边界。这不是未来的愿景，而是正在发生的现实。
但效率的超越不等于价值的替代。历史上每一次技术革命都遵循同一个模式：机器替代的不是"人"，而是"人的某类动作"。 工业革命中，纺织机替代了手工纺织的动作，但设计师、品控员、市场判断者的价值反而上升；计算机普及后，算盘和手工计算消失，但数据分析师、算法工程师、业务建模者的价值大幅放大。
AI 对软件开发的影响也不例外。Generator 替代的是"写代码"这个动作，Planner 替代的是"拆需求"这个动作，Evaluator 替代的是"跑测试"这个动作——但判断代码是否值得写、需求是否拆对了、测试是否测到了点子上，这些判断权仍然在人手中。
这就是范式转移的核心：人类工作的本质从"把事情做对"（执行）转向"判断什么事情值得做、做到什么程度算够好"（判断与验收）。
需要特别澄清的是，这不是"AI 取代人"的焦虑叙事。“取代"暗示的是零和博弈——AI 多做一些，人就少做一些，直到人没有事情可做。但"重构"是另一套逻辑：AI 把执行层的边际成本压到趋近于零，人类的差异化价值就从执行层转移到了判断层。不是人被边缘化，而是人的能力重心发生了转移。
这不是关于谁取代谁，而是关于人类在 AI 时代重新定义自己的价值坐标。
5.2 各角色的 AI 协同模式#
范式转移是抽象的认知升级。要让它落地，需要回到具体的岗位，看看每个角色在 Harness 时代的工作边界发生了哪些变化。
5.2.1 产品经理：需求真伪判断、优先级权衡、市场预判#
AI 接管什么： 需求文档的结构化梳理、用户故事的格式转换、竞品功能的对标分析、数据报表的自动生成。
人类保留什么： 需求真伪的判断、优先级的权衡、市场趋势的预判。
关键转变： 从"写 PRD 的人"变为"判断什么需求值得做的人”。
传统产品经理的大量时间花在写文档、画原型、开对齐会上——这些工作 Planner 可以做得很好。但 Planner 不会告诉你"这个功能用户真的需要吗"“现在做还是三个月后做"“做了之后对留存率有什么影响”。这些判断依赖对业务的深刻理解、对用户心理的洞察、对市场竞争的感知，AI 无法替代。
Harness 时代的产品经理，核心竞争力不再是文档写得有多规范，而是判断能力有多准——在十个看似合理的需求中，识别出哪三个真正值得投入资源。
5.2.2 程序员：Agent 范式 mastery，通过优化模型提升 AI 生产力#
AI 接管什么： 代码编写、单元测试生成、文档注释、代码重构、bug 修复。
人类保留什么： 系统架构设计、技术选型决策、代码审查（从语法层上升到设计层）、Harness Agent 的调优与编排。
关键转变： 从"写代码的人"变为"设计如何让 AI 写出好代码的人”。
这是最反直觉也最重要的转变。初级程序员还在手动修改 AI 生成的代码，逐行审阅、逐句修正——他们把 AI 当作一个"需要被纠正的实习生"。高级程序员已经在优化 Generator 的上下文配置、调整 Evaluator 的验收标准、设计更高效的反馈闭环——他们把 AI 当作一个"可以被调校的生产力系统"。
两者的根本区别，不在于代码能力，而在于对 AI 工作范式的理解深度。
Agent 范式 mastery 的核心不是写代码，而是三个层面的设计能力：
- 上下文设计：给 Generator 提供什么样的设计蓝图（Design）、什么样的参考代码、什么样的约束条件，能让它一次性产出更高质量的代码；
- 工具链设计：为 Generator 配置哪些 MCP 工具、哪些测试框架、哪些监控接口，能让它在执行阶段拥有正确的"感官"；
- 反馈闭环设计：当 Evaluator 发现问题时，如何设计反馈的格式和路径，让 Generator 在下一轮迭代中精准修正，而不是反复踩同一个坑。
未来的高价值工程师，不是代码写得最快的，而是最懂得如何让 AI 把代码写对的人。
5.2.3 架构师：演进路线判断、约束条件下的取舍#
AI 接管什么： 技术方案的代码实现、接口定义的自动生成、依赖关系的可视化梳理、性能基准测试的执行。
人类保留什么： 演进路线的判断、约束条件下的取舍、技术债务的权衡。
关键转变： 从"画架构图的人"变为"判断技术演进方向的人"。
AI 可以生成一个微服务拆分方案，可以画出漂亮的架构图，甚至可以论证为什么选 Kafka 而不是 RabbitMQ。但 AI 不会理解"公司明年要进入东南亚市场，架构需要支持多地域部署"“这个业务线的生命周期可能只有两年，不需要过度设计"“团队目前有五个新人，复杂度太高的架构会拖慢交付”。
架构设计的本质是在约束条件下做取舍。约束条件来自业务战略、团队能力、时间窗口、成本预算——这些都是动态的、组织特有的、AI 无法从代码库中推断出来的信息。Harness 时代的架构师，核心价值不是画出最优雅的架构，而是做出最符合当前约束的取舍。
5.2.4 项目经理：风险预判、资源冲突权衡、危机识别#
AI 接管什么： 进度跟踪、任务状态更新、工时估算（基于历史数据）、会议纪要的自动生成、依赖关系的可视化。
人类保留什么： 风险预判、资源冲突的权衡、危机识别与升级决策。
关键转变： 从"盯进度的人"变为"判断风险在哪里的人”。
AI 可以精确地告诉你"任务 A 延迟了 2 天，任务 B 因此受到影响，预计整体延期 3 天"——但这只是对已发生事实的陈述。人类项目经理的价值在于在延迟发生前就嗅到风险：为什么这个估算看起来过于乐观？为什么两个团队负责人最近没有在同步会上发言？为什么需求变更的频率在悄然上升？
Harness 可以压缩执行周期，但无法消除不确定性。项目经理的核心能力从"管理确定性"（排期、跟踪、汇报）转向"管理不确定性"（预判、权衡、危机响应）。
5.2.5 测试工程师：策略设计、边界风险预判#
AI 接管什么： 测试用例的自动生成、回归测试的执行、覆盖率报告的生成、边界条件的穷举、性能基准的自动化跑测。
人类保留什么： 测试策略的设计、边界风险的预判、验收标准的定义。
关键转变： 从"写测试用例的人"变为"判断什么风险最值得测的人"。
Evaluator 可以生成和执行海量测试用例，但 Evaluator 不会判断"这个系统的核心风险是并发一致性还是数据迁移兼容性"。测试策略的设计需要理解业务场景、用户行为模式、系统架构的脆弱点——这些判断决定了测试资源的分配方向。
Harness 时代的测试工程师，核心竞争力不是用例写得多全面，而是风险判断有多准——在有限的验收轮次和 token 预算内，让 Evaluator 测到最关键的地方。
5.2.6 实施/运维：故障模式预判、应急预案制定#
AI 接管什么： 部署脚本的执行、监控告警的响应、日志分析、常规故障的自动修复、容量扩缩容的自动化。
人类保留什么： 故障模式的预判、应急预案的设计、重大故障的指挥决策。
关键转变： 从"盯监控的人"变为"判断系统可能以什么方式崩溃的人"。
AI 可以在内存使用率超过 90% 时自动扩容，可以在服务实例挂掉时自动重启，可以在错误率飙升时自动回滚。但 AI 不会提前三个月预判"双十一期间支付链路可能因为第三方接口限频而雪崩"，不会设计"当主数据库所在可用区整体故障时的降级策略"，不会在凌晨三点的 P0 故障中决定"是先止损还是先去根因"。
运维的终极价值不是让系统不出问题，而是当问题不可避免地发生时，有人已经预判过、有预案、能决策。
小结：执行层被接管，经验层 + Agent 设计能力价值放大#
六个角色的分析指向同一个结论：
- AI 接管的是执行层——写文档、写代码、跑测试、盯监控、做部署。这些工作的共同特点是：目标明确、标准清晰、可重复、可验证。
- 人类保留的是判断层——需求真伪、技术取舍、风险预判、验收标准、危机决策。这些工作的共同特点是：依赖经验、需要权衡、标准模糊、后果重大。
- 程序员多了一个独特维度——Agent 设计能力。这是其他角色没有的：不仅要判断，还要设计如何让 AI 更好地执行。
执行层被 AI 接管后，经验层的判断力和程序员的 Agent 设计能力，成为价值放大的两个核心杠杆。
5.3 能力门槛重构：数控机床与八级钳工#
上一节描述了各角色的分工变化，但有一个问题需要更直观的回答：这种变化对个人的能力门槛意味着什么？ 是门槛降低了（AI 帮忙，人人都可以），还是门槛提高了（需要新技能）？
工业史提供了一个精准的类比。
二十世纪中叶，制造业有一个备受尊崇的工种——八级钳工。八级钳工靠手工就能将零件加工到微米级精度，这种技艺需要十年以上的磨练，是工厂里技术地位最高、收入最丰厚的岗位。同一时期，数控机床开始出现。最初的数控机床精度并不如顶级钳工，但它有两个特征：一旦调好程序，它可以不眠不休地重复同一精度；它的精度提升曲线是指数级的，每五年翻一番。
到二十世纪末，数控机床的精度已经全面超越手工。八级钳工的手艺不再是稀缺资源——工厂不再愿意为一个"手工精度"支付高昂溢价，因为机床可以以十分之一的成本提供更高的精度。执行技能贬值了。
但故事没有以"钳工下岗"结束。真正发生的是能力门槛的重构：
- 操作工——只需要按按钮、装夹具、看仪表，门槛极低，可替代性极高；
- 调机师——能读懂图纸、编写数控程序、选择刀具参数、诊断加工异常，门槛显著提升，价值也显著提升；
- 工艺设计师——能判断什么零件适合什么加工方式、如何优化生产流程、如何在质量和成本之间取舍，这是最高门槛，也是最高价值。
AI 对软件开发的影响正在复刻这个故事。
Generator 相当于数控机床：它可以不眠不休地生成代码，且代码质量在持续提升。纯"写代码"的能力——就像"手工加工精度"一样——正在从稀缺技能变为基础能力。未来的程序员分层将会是：
- 操作工型——能看懂 AI 生成的代码、能手动修 bug、能完成简单的功能实现。门槛极低，可替代性极高。
- 调机师型——能设计好的上下文、能调优 Evaluator 的验收标准、能诊断 AI 产出中的系统性问题。门槛提升，价值提升。
- 工艺设计师型——能判断系统架构方向、能设计 Harness 工作流、能在业务约束下做出技术取舍。这是最高门槛，也是最高价值。
执行技能贬值的技术逻辑很直接：AI 的执行成本趋近于零，执行质量趋向标准化，执行速度指数级提升——纯执行能力的稀缺性必然下降。
判断技能升值的逻辑同样直接：业务复杂度在上升（系统越来越复杂、用户场景越来越多样），AI 无法自主定义"够好"的标准（因为标准依赖业务目标），战略权衡需要组织上下文（而组织上下文不在代码库中）——判断能力的稀缺性必然上升。
未来的高价值工程师，不是代码写得最快的，而是最懂得如何让 AI 把代码写对的人。这不是安慰，而是正在发生的工业规律。
5.4 验收驱动机制#
理解了范式转移、角色分工和能力重构之后，最后一个问题需要回答：Harness 中的人类验收，与 Evaluator 的自动验收，是什么关系？
第四章已经论证了一个原则：人对线上系统的最终责任不可转移。但"责任"是一个抽象概念，需要转化为具体的机制。这个机制就是分层验收模型。
第一层：Evaluator 验"对不对"
Evaluator 的职责是验证 Generator 的产出是否达到了预设的技术标准——功能是否正确、性能是否达标、安全是否合规、边界条件是否覆盖。这些是"对不对"的问题，标准清晰、可量化、可自动化。
第二层：人类验"值不值"
人类的职责是在 Evaluator 通过之后，验证一个更深层的问题：这个结果对业务来说是否有价值？
- 功能完整，但用户真的需要这个功能吗？（需求真伪）
- 性能达标，但投入的成本（token、时间、算力）与收益是否匹配？（成本权衡）
- 安全合规，但安全策略是否过度影响了用户体验？（取舍平衡）
- 代码正确，但与现有系统的集成是否引入了隐性风险？（兼容性判断）
这些是"值不值"的问题，标准模糊、依赖上下文、需要权衡——AI 无法替代。
为什么 AI 无法自主定义"足够好"？
因为"足够好"的标准不是技术问题，而是业务问题。Evaluator 可以判断"API 响应时间是否低于 200ms"，但它无法判断"200ms 对我们的用户来说是否足够好"——也许对于 B 端后台管理，500ms 也够用；也许对于 C 端实时交互，100ms 才是及格线。这个判断需要理解用户场景、竞争环境、业务目标，而这些信息不在代码里。
Harness 的 Evaluator 和人类验收不是对立关系，而是互补关系。Evaluator 确保"技术正确"，人类确保"业务正确"——两者叠加，才是完整的"正确"。
这与第二章"人类的角色：需求校准层"形成呼应，但视角不同。第二章从 Harness 框架的功能必要性出发——框架需要一个人类校准层来防止方向性偏差；本章从人的工作范式重构出发——人类的验收权是 AI 时代不可被替代的核心权力。前者回答"为什么 Harness 需要人"，后者回答"人如何在 Harness 中重新定义自己"。
5.5 本章小结#
让我们回顾本章的核心脉络。
范式转移：AI 在执行层的效率已经超越人类，人类工作的本质从"动手执行"转向"判断与验收"。这不是"被替代"，而是"被重构"。
角色分工：产品经理保留需求判断，程序员升级为 Agent 设计能力，架构师保留取舍权衡，项目经理保留风险预判，测试工程师保留策略设计，运维保留故障预判与应急决策。执行层被 AI 接管，经验层 + Agent 设计能力价值放大。
能力门槛重构：以"数控机床与八级钳工"为鉴，执行技能必然贬值，判断技能必然升值。未来工程师的分层将从"代码能力"转向"Agent 设计能力 + 业务判断力"。
验收机制：Evaluator 验"对不对"（技术指标），人类验"值不值"（业务价值）。两者互补，构成完整的正确性验证。
至此，我们从"AI 能做什么"（第一章）→“如何让 AI 协作”（第二章）→“如何在工程理论中落地”（第三、四章）→“人如何与 AI 共处”（本章），完成了从问题到框架、从理论到人的完整闭环。
但闭环不是终点。当 Harness 的三角色开始运转、当人类的验收权确立、当各角色的分工边界清晰之后，下一个问题是：如何把这些碎片组装成一个可运转的、覆盖软件全生命周期的闭环系统？ 从需求分析到设计、开发、测试、部署、运维——Harness 的框架如何贯穿始终？
下一章，我们将设计这个全生命周期闭环框架。
本章内容说明
- 论文原意：Harness 三角色（Planner / Generator / Evaluator）体系及 AI-AI 验收标准协商机制，源自 Anthropic《Harness Design for Long-Running Application Development》。
- 作者分析：“范式转移”（从人执行到人判断）、各角色 AI 协同模式、“数控机床与八级钳工"类比、分层验收模型（Evaluator 验"对不对”、人类验"值不值"），为本文作者基于 Harness 框架与软件工程实践的分析推导。
- 工程扩展：“Agent 范式 mastery"概念（程序员从写代码到优化 Agent 模型的能力升级）、“操作工/调机师/工艺设计师"三层工程师模型，是基于 AI 落地实践的观察总结，非论文原文。
- 虚构示例：本章未构造具体场景示例，角色分析基于通用岗位模型推导。