第六章的追问#
第六章让我们看到了 Harness 闭环的完整图景：四阶段重叠运转、上下文交接接力、监控回流驱动。但这个框架只是一个"容器"。容器里装什么角色、这些角色有什么能力边界、它们之间如何协作——这些问题需要更细粒度的设计。
前六章中，我们一直把 Planner、Generator、Evaluator 当作单一角色来论述。但真实的软件开发远比"一个 Planner 拆需求、一个 Generator 写代码、一个 Evaluator 跑测试"复杂得多。一个涉及前端、后端、数据库、DevOps 的完整系统，需要多种技术专长；一个需要满足功能、性能、安全、合规多重标准的项目，需要多种验收维度；一个从模糊业务需求到可执行技术方案的翻译过程，需要多种分析视角。
复杂的系统需要专业化的分工。 Planner、Generator、Evaluator 不是三个通用角色包打天下，而是三种角色家族，每个家族内部有多种专业化变体。
7.1 为什么需要多种角色#
想象一个初创公司的技术团队。公司刚成立时，只有三个工程师，每个人都是全栈——写前端、搭后端、配服务器、调数据库，什么都做。这时候不需要专业化，因为系统简单，沟通成本低，一个人能掌握全局。
但当公司发展到两百人、系统拆分成三十个微服务、技术栈覆盖 React、Go、Python、Kubernetes、Terraform 时，“全栈"就不够用了。你需要专门的前端团队、后端团队、平台团队、数据团队。不是全栈工程师变笨了，而是系统的复杂度超过了单一角色的认知边界。
Harness 的角色分工遵循同样的规律。
一个简单的内部工具页面——一个表单、一个提交按钮、一个结果展示——通用型 Generator 完全可以胜任。但一个涉及实时音视频处理、分布式一致性、多地域部署的复杂系统，通用型 Generator 产出的代码可能在功能上正确，但在性能、可靠性、可维护性上无法满足生产环境的要求。
角色专业化的触发条件有三个：
第一，系统复杂度超过阈值。 当系统模块数量、技术栈种类、交互边界超过一定规模时，通用型角色无法在每个领域都保持足够的深度。
第二，质量维度超过单一 Evaluator 的覆盖范围。 功能正确只是底线，性能、安全、合规、用户体验、业务价值——每个维度都需要专门的知识和工具来验收。
第三，输入类型的差异大到需要不同的分析视角。 从模糊的业务需求到精确的算法需求，从合规约束到用户体验优化——不同类型的"输入"需要不同类型的 Planner 来翻译。
但这不意味着 Harness 从一开始就需要全套专业化角色。专业化是演进而来的，不是设计出来的。 就像公司从三人到两百人的过程中，专业化是随着系统复杂度增长自然发生的。Harness 的实践也应该从通用型角色起步，在瓶颈出现时再引入专业化变体。
7.2 Planner 的变体：输入类型决定分工#
Planner 的核心职责是"翻译”——把人类的意图翻译成机器可执行的 Design。但"意图"有很多种，不同类型的意图需要不同类型的翻译者。
| 变体 | 专长领域 | 接收的输入 | 产出的 Design | 与通用型的差异 |
|---|---|---|---|---|
| 需求分析型 Planner | 业务需求翻译 | 模糊的人类意图、市场诉求、用户痛点 | 用户旅程、效果描述、验收标准 | 擅长从"一句话需求"中挖掘隐性假设 |
| 架构规划型 Planner | 技术方案设计 | 技术约束、性能基线、已有系统边界 | 系统架构、模块划分、接口契约 | 擅长在约束条件下做技术取舍 |
| 安全规划型 Planner | 安全合规设计 | 合规要求、安全基线、威胁模型 | 安全策略、访问控制、审计方案 | 擅长识别安全风险和设计防御机制 |
| 数据规划型 Planner | 数据模型设计 | 业务实体关系、查询模式、增长预期 | 数据模型、存储方案、迁移策略 | 擅长权衡一致性、可用性、分区容错 |
为什么需要这些专业化？
通用型 Planner 能处理"实现一个用户登录功能"这样的标准需求，但面对"我们的支付系统需要满足 PCI-DSS 合规，同时支持东南亚市场的本地化税务计算"时，通用型 Planner 会遗漏合规细节或低估本地化复杂度。安全规划型 Planner 知道 PCI-DSS 的 12 项要求中哪 5 项与代码直接相关；数据规划型 Planner 知道东南亚各国的税务规则如何映射到数据模型。
关键洞察：Planner 的专业化不是按"行业"划分（如"金融 Planner"“电商 Planner”），而是按"输入类型"划分。同一个金融系统，需求分析型 Planner 处理业务需求，架构规划型 Planner 处理技术约束，安全规划型 Planner 处理合规要求——三种 Planner 协作完成一个系统的整体设计。
7.3 Generator 的变体：技术栈决定分工#
Generator 的核心职责是"实现"——把 Design 翻译成代码。但代码有很多种，不同类型的代码需要不同类型的程序员。
| 变体 | 专长技术栈 | 适用场景 | 与通用型的差异 |
|---|---|---|---|
| 前端 Generator | React/Vue/Angular、CSS、浏览器性能 | 用户界面、交互逻辑、可视化 | 掌握浏览器渲染原理、响应式设计、无障碍标准 |
| 后端 Generator | Go/Java/Python、分布式系统、数据库 | API 服务、业务逻辑、数据处理 | 掌握并发模型、事务一致性、服务治理 |
| 数据库 Generator | SQL/NoSQL、查询优化、分片策略 | 数据模型、查询设计、迁移脚本 | 掌握索引优化、执行计划分析、容量规划 |
| DevOps Generator | Kubernetes、Terraform、CI/CD | 部署流水线、基础设施、监控配置 | 掌握云原生架构、不可变基础设施、可观测性 |
为什么需要这些专业化？
通用型 Generator 能写出一个功能正确的 CRUD 应用，但面对"十万并发下的秒杀系统"时，通用型 Generator 产出的代码可能在功能上正确，但在数据库连接池管理、缓存一致性、降级策略上存在隐患。后端 Generator 知道如何在分布式事务中处理超时和回滚；数据库 Generator 知道如何设计索引让秒杀查询不走全表扫描。
关键洞察：Generator 的专业化按"技术栈"划分，但技术栈的边界正在模糊。一个"后端 Generator"可能需要理解前端的数据请求模式来设计高效的 API；一个"DevOps Generator"需要理解后端的服务发现机制来配置负载均衡。专业化不等于孤立——不同 Generator 之间需要协作协议来对接（如 API 契约的定义和验证）。
7.4 Evaluator 的变体：验收维度决定分工#
Evaluator 的核心职责是"验收"——验证 Generator 的产出是否达标。但"达标"有很多维度，不同维度需要不同的验收专家。
| 变体 | 验收维度 | 使用的工具/方法 | 与通用型的差异 |
|---|---|---|---|
| 功能 Evaluator | 正确性、完整性、边界覆盖 | 单元测试、集成测试、端到端测试 | 擅长设计全面的测试用例，覆盖正常路径和异常路径 |
| 性能 Evaluator | 延迟、吞吐量、资源消耗 | 负载测试、压力测试、性能剖析 | 擅长识别性能瓶颈，定义可量化的性能基线 |
| 安全 Evaluator | 漏洞、合规、风险暴露 | 静态分析、渗透测试、依赖扫描 | 掌握 OWASP Top 10、已知漏洞库、攻击向量 |
| 业务价值 Evaluator | 用户体验、商业价值、战略契合 | A/B 测试、用户反馈分析、埋点数据 | 擅长从业务视角判断功能是否"值得做" |
为什么需要这些专业化？
通用型 Evaluator 能验证"功能是否正确"，但面对"这个支付接口在双十一峰值下的可用性"时，通用型 Evaluator 可能会遗漏并发场景下的死锁风险，或者误判"99.9% 可用性"是否足够。性能 Evaluator 知道如何设计负载测试来模拟真实峰值；安全 Evaluator 知道如何构造 SQL 注入和越权访问的测试用例。
关键洞察：Evaluator 的专业化与 Generator 的专业化是配对关系。前端 Generator 的产出需要功能 Evaluator 验证交互正确性，也需要性能 Evaluator 验证首屏加载时间；后端 Generator 的产出需要功能 Evaluator 验证 API 契约，也需要安全 Evaluator 验证输入校验。一个复杂的系统可能需要多个 Evaluator 同时验收同一个 Generator 的产出。
7.5 角色协作协议：交响乐团模型#
当多个专业化角色在同一个闭环中协作时，一个自然的问题是：谁什么时候上场？如何配合？意见不一致怎么办？
想象一个交响乐团。乐团里有弦乐、管乐、打击乐等多个声部，每个声部有各自的专长。但乐团不是所有人同时演奏各自最喜欢的曲子——有一个指挥决定什么时候哪个声部上场，有一个乐谱定义了每个声部的节奏和旋律，有一个排练机制确保大家在正式演出前协调一致。
Harness 的多角色协作也需要类似的协议。
协商机制：谁主导这一轮？#
在 Harness 的闭环中，不同轮次由不同的角色主导：
- 需求变更轮次：需求分析型 Planner 主导，其他角色配合
- 技术重构轮次：架构规划型 Planner + 后端 Generator 主导，其他角色配合
- 安全加固轮次：安全规划型 Planner + 安全 Evaluator 主导，其他角色配合
主导权不是固定的，而是按轮次的目标动态分配。每个轮次开始前，系统明确"这一轮要解决什么问题"，然后决定哪个角色主导、哪些角色配合。
交接规则：信息如何传递？#
多角色协作时，交接不再是简单的"前一阶段→后一阶段"，而是多对多的：
- 需求分析型 Planner 的 Design 需要交接给架构规划型 Planner（业务需求→技术约束）
- 架构规划型 Planner 的 Design 需要交接给后端 Generator 和前端 Generator（系统架构→模块实现）
- 后端 Generator 的 API 契约需要交接给前端 Generator（接口定义→调用实现）
- 多个 Evaluator 的验收报告需要汇总后交接给人类验收方（多维度验收→综合判断）
第六章讲的"上下文交接"在这里变得更加复杂——交接文件不再是单一的"Design→代码→部署"链条，而是一个交接网络。Harness 需要一个"交接路由器"来决定每份交接文件应该发给谁。
冲突避免：意见不一致怎么办？#
多角色协作必然产生冲突：
- 性能 Evaluator 要求"缓存所有查询结果"，安全 Evaluator 要求"敏感数据禁止缓存"——怎么办？
- 前端 Generator 要求"API 返回嵌套结构减少请求次数"，后端 Generator 要求"API 返回扁平结构简化序列化"——怎么办？
Harness 的冲突解决机制不是"投票"或"层级压制"，而是回到 Design 的验收标准。Planner 在产出 Design 时已经定义了优先级（如"安全优先于性能"或"用户体验优先于实现复杂度"）。当冲突发生时，角色们回到 Design 的约束条件中寻找裁决依据。如果 Design 没有覆盖这个冲突场景，冲突被升级给人类决策——这正是 Harness 中人类校准层的价值所在。
7.6 本章小结#
让我们回顾本章的核心脉络。
专业化必要性：复杂的系统需要专业化的角色分工。角色专业化的触发条件是系统复杂度超过阈值、质量维度超过单一 Evaluator 覆盖范围、输入类型差异大到需要不同分析视角。
Planner 变体：按"输入类型"专业化——需求分析型处理模糊需求、架构规划型处理技术约束、安全规划型处理合规要求、数据规划型处理数据模型。
Generator 变体：按"技术栈"专业化——前端、后端、数据库、DevOps，每种 Generator 在特定技术领域保持深度。
Evaluator 变体：按"验收维度"专业化——功能、性能、安全、业务价值，每种 Evaluator 在特定质量维度保持深度。
协作协议：多角色协作需要协商机制（谁主导这一轮）、交接规则（信息如何在多角色间传递）、冲突避免（回到 Design 约束条件寻找裁决依据）。
至此，上篇"理论指导思想"全部完成。我们从"AI 能做什么"（第一章）→“如何让 AI 协作”（第二章）→“如何在工程理论中落地”（第三、四章）→“人如何与 AI 共处”（第五章）→“如何组装成闭环系统”（第六章）→“角色如何专业化分工”（本章），完成了从问题到框架、从理论到系统、从角色到分工的完整认知闭环。
下篇"落地实践路径"即将开始。当理论的坐标系建立之后，下一个问题是：如何把这些理论和角色落地为一个可运转的生产系统？ 第八章，我们将设计 Harness 的总体架构——AI 执行引擎与人类验收层的技术蓝图。
本章内容说明
- 论文原意：Harness 三角色（Planner / Generator / Evaluator）体系源自 Anthropic《Harness Design for Long-Running Application Development》。
- 作者分析：“角色专业化"的必要性论证、三种角色的变体体系（按输入类型/技术栈/验收维度划分）、“交响乐团"协作协议模型，为本文作者基于 Harness 框架与软件工程实践的分析推导。
- 工程扩展：角色专业化的三个触发条件、多角色交接网络的"交接路由器"概念、冲突解决的"回到 Design 约束"机制，是基于工程落地实践的推导，非论文原文。
- 虚构示例：本章未构造具体场景示例，角色体系基于通用软件工程团队模型推导。