Harness Engineering 深度实践：给团队、程序员和管理者的行动手册
上一篇聊 Harness Engineering，很多人问：『道理我都懂，具体怎么落地？』
这篇不灌鸡汤，直接给框架、给 checklist、给组织变革路径。写给三类人：开发团队、一线程序员、技术管理者。各取所需，但最好全看——因为这不是个人修行，是系统工程。
一、先对齐认知：Harness Engineering 到底是什么
很多人把 Harness Engineering 理解成『用 AI 写代码』，太浅了。
它的本质是重新设计人机协作的生产关系。不是 AI 替代人，也不是人驾驭 AI 这么简单——而是构建一个三层 Harness（驾驭层）：
- Personal Harness（个人层）：单个工程师如何重构自己的工作流，让 AI 接管低价值任务，自己专注高价值决策
- Team Harness（团队层）：团队如何重新定义代码所有权、评审流程、知识管理和交付标准
- Organizational Harness（组织层）：公司如何调整绩效体系、招聘标准、技术治理和风险管理框架
缺任何一层，这个系统都会崩。个人再强，放在不支持的团队里会被拖死；团队流程再好，组织层面的绩效评估还在奖励代码行数，那就是自掘坟墓。
下面分层拆解。
二、给开发团队：流程重构，不是加个 Copilot 就完事
1. 把 AI 纳入 CI/CD 质检流水线
这是底线。AI 生成的代码必须在进入主分支前经过自动化的三层过滤：
- 静态安全扫描（SAST）：AI 特别喜欢引用有 CVE 的库版本，或者写出有注入风险的 SQL。SonarQube、CodeQL、Semgrep 必须跑
- 行为一致性校验：AI 重构代码时经常改变边界行为。除了单元测试，还要有契约测试（Pact）或 API 快照测试，确保对外接口语义没变
- AI 置信度标记：要求工程师标注哪些文件/函数是 AI 生成的。不是搞歧视，是为了在故障排查时快速定位可疑代码
Checklist：
- [ ] CI 流水线里增加了 AI 生成代码的特殊 lint 规则
- [ ] 所有 PR 必须附带 AI 生成比例声明（哪怕写的是 0%）
- [ ] 部署到 staging 后，自动对比 AI 修改区域的黄金流量（golden traffic）响应差异
2. 重新定义代码所有权
传统的代码所有权是『谁写的谁维护』。但 AI 写了 60% 的代码后，这个模型崩了。
新的所有权模型应该是领域所有权（Domain Ownership）：
- 不看你写了哪几行，而看你对哪个业务领域负责
- 这个领域内的所有代码——不管是人写的还是 AI 写的——最终的架构决策权、故障问责权都在你
- AI 生成的代码如果出 bug，责任不在 AI，而在领域负责人没有建立足够的验证机制
这倒逼工程师从『我写了什么』转向『我确保了什么』。
3. 知识管理从文档转向 Prompt 工程库
团队知识库过去是 Confluence、Wiki。现在，最有价值的团队资产是经过验证的高质量 Prompt 模板。
建议每个团队维护一个内部的 Prompt Registry：
- 生成单元测试的标准 Prompt（带上下文注入模板）
- 重构遗留代码的约束 Prompt（哪些不能动、风格要求）
- 安全敏感代码的审查 Prompt（专门用来让 AI 自查潜在漏洞）
这些 Prompt 要版本控制、要 Code Review、要持续迭代——因为 Prompt 本身就是新的源代码。
4. 团队技能矩阵重新设计
传统的团队技能矩阵是语言 × 框架。现在需要增加三个维度：
- Prompt 设计能力：能把模糊需求转化为 AI 可执行指令的能力
- AI 输出审计能力：快速识别 AI 幻觉、逻辑漏洞、性能陷阱的眼力
- 系统编织能力：把 AI 生成的碎片代码整合成可维护、可观测、可回滚的系统的能力
招聘和晋升时，这三个维度的权重应该逐年上升。
三、给程序员：别焦虑，但要动真格
1. 建立你的 Personal Harness 工作流
这不是用不用 Cursor 的问题，而是你有没有一套可复现、可迭代、可度量的 AI 协作工作流。
建议按这个漏斗设计：
- 需求拆解（100% 人类）：把业务需求拆成 AI 可执行的子任务。这一步决定了一切。拆不好，AI 再强也白搭
- 初稿生成（80% AI）：让 AI 写第一版，但要在 Prompt 里注入约束（测试要求、风格指南、性能基线）
- 审计精修（100% 人类）：逐行审查，重点看边界条件、并发安全、资源泄漏、依赖风险
- 验证闭环（工具 + 人类）：跑测试、跑扫描、跑性能基准，不达标打回重写
每完成一个任务，问自己三个问题：
- 我在这个任务里创造了什么 AI 无法替代的价值？
- 我的 Prompt 有没有沉淀成可复用的模板？
- 如果三个月后这个代码出 bug，我能不能在三分钟内定位到根因？
2. 深度 vs 广度的新权衡
AI 时代，广度型全栈工程师的价值在下降——因为 AI 本身就覆盖了整个栈。但深度型专家的价值在上升，因为AI 不懂你的业务。
建议选择一个垂直领域扎下去，同时保持对上下游的接口级理解。具体策略：
- T 型人才 → π 型人才：一个主深度领域 + 一个辅助领域 + 对 AI 工具的系统性理解
- 主深度领域选业务耦合度高的（比如支付风控、医疗合规、嵌入式实时系统），AI 替代难度大
- 辅助领域选能快速用 AI 补强的（比如前端、运维、测试），保持交付端到端价值的能力
3. 处理职业焦虑的硬核方法
焦虑来自两个幻觉：
- 『我十年的编码技艺突然不值钱了』——确实，纯编码技能在贬值，但系统设计和质量把控技能在升值
- 『AI 会越来越好，迟早连架构师也取代』——可能，但那是十年后的事。现在到未来三年，窗口期还在
行动清单：
- [ ] 每周花 2 小时研究一个新的 AI 工程实践（Prompt 模式、RAG 架构、Agent 工作流），记笔记
- [ ] 每月输出一篇内部技术博客或做一次团队分享，建立『AI 工程』领域的个人品牌
- [ ] 每个季度评估一次自己的技能组合：哪些被 AI 削弱了？哪些被 AI 放大了？哪些 AI 还碰不到？
别等着公司给你培训。AI 时代的工程师，自我教育是默认配置。
四、给管理者：你的 KPI 体系可能正在杀死团队
1. 绩效评估必须重构
还在用代码行数、提交次数、故事点完成量来评估工程师？赶紧停。
AI 时代的有效绩效指标应该包括：
- 系统健康度：你负责的领域，MTTR（平均修复时间）、变更失败率、安全漏洞数量
- 决策质量：架构评审通过率、技术债务清理的 ROI、引入新技术的风险评估准确性
- 知识资产沉淀：Prompt 模板贡献数、团队培训次数、文档/指南的采纳率
- AI 协作效率：AI 生成代码的首次通过率、返工率、生产环境缺陷归因率
重点不是『你写了多少』，而是『你让系统变得多可靠』和『你让团队变得多高效』。
2. 招聘标准要换血
面试题该改了：
- 少问『手写红黑树』，多问『怎么设计一个 Prompt 让 AI 生成符合团队规范的 CRUD 代码』
- 少问『怎么优化这个 SQL』，多问『怎么验证 AI 重构后的 SQL 在百万级数据下性能不劣化』
- 少问『解释 OAuth2 流程』，多问『如果让 AI 实现 OAuth2，你会在哪些地方设置人工审核点』
招进来的人，要给三个月的 AI 协作能力培养期。不是培训他们用 Copilot，而是培训他们建立完整的 Harness 工作流。
3. 警惕「AI 债务」
技术债务大家都知道。AI 债务是新物种：
- 幻觉累积：AI 在某个模块里埋了一个错误的假设，三个月后扩散到十个模块才发现
- 黑盒依赖：团队过度依赖 AI 生成的代码，导致没人真正理解核心逻辑，关键人一旦离职就抓瞎
- Prompt 腐烂：早期的 Prompt 模板没维护，随着模型升级，输出质量越来越不可控
- 安全盲区：AI 生成的代码通过了所有自动化扫描，但在业务语义层面存在逻辑漏洞（比如权限检查顺序错误）
治理方法：建立 AI 债务看板，每季度审计，跟技术债务同等对待。
4. 团队结构：扁平化还是专业化？
AI 让个体产出暴增，但系统复杂度也在暴增。我的建议是：
- 小团队保持扁平：10 人以内，每个人都应该有端到端交付能力（借助 AI）。减少交接损耗
- 大团队引入 Harness 架构师：不是传统架构师，而是专门负责设计 AI 协作流程、维护 Prompt Registry、建立质量门的人
- 跨团队设置 AI 治理委员会：制定全公司的 AI 使用规范、安全红线、模型选型标准。别让各个团队各自为战
5. 风险管理框架
AI 不是魔法，是概率系统。管理者必须建立清醒的风险认知：
| 风险类型 | 缓解策略 |
|---|---|
| 模型供应商锁定 | 至少支持两种模型（比如 GPT-4 + Claude），Prompt 设计遵循可移植原则 |
| 数据泄露 | 敏感代码和业务逻辑不得输入公有 AI；自建私有化部署或严格的数据脱敏流程 |
| 合规风险 | AI 生成的代码必须有明确的溯源记录；涉及安全认证、金融合规的模块禁止全 AI 生成 |
| 单点故障 | 核心系统的关键路径代码，必须有至少一名人类工程师深度理解并签字确认 |
| 模型漂移 | 定期用固定测试集回归验证 AI 输出质量；Prompt 版本与模型版本绑定管理 |
五、统一框架：三层 Harness 的落地路线图
如果你想在公司推动 Harness Engineering，建议按这个节奏走：
Phase 1：个人实验期（1-2 个月）
- 选 3-5 个愿意尝鲜的工程师，各自建立 Personal Harness 工作流
- 收集数据：AI 生成比例、返工率、缺陷率、个人效率变化
- 产出：一套经过验证的内部 Prompt 模板初版
Phase 2：团队制度化（2-4 个月）
- 把 Phase 1 的最佳实践固化为团队流程：新的 Code Review 标准、新的 CI 质检项、新的知识管理方式
- 调整绩效指标，让用了 Harness 方法的人不吃亏
- 培训全覆盖：不是教工具，是教工作流
Phase 3：组织规模化（4-6 个月）
- 成立 AI 治理委员会，制定全公司标准
- 引入 Harness 架构师角色
- 建立 AI 债务看板，纳入技术治理体系
- 招聘标准全面更新
Phase 4：持续进化（长期）
- 每季度评估 AI 工具栈，淘汰落后的，引入更先进的
- Prompt Registry 持续迭代，跟代码库一样做版本管理
- 关注模型能力边界的变化，及时调整人机分工
写在最后
Harness Engineering 不是让你成为 AI 的奴隶，也不是让你假装 AI 不存在。
它是让你在认清现实的基础上，重新夺回控制权。
现实是：AI 已经能写出不错的代码了，而且会越来越强。控制权的含义是：你决定哪些让 AI 做、哪些必须自己做、哪些需要人类和 AI 协作、用什么流程来保证质量、用什么机制来管理风险。
个人建立 Personal Harness，团队建立 Team Harness，组织建立 Organizational Harness。三层都到位了，你才有资格说自己在做 Harness Engineering。
否则，你只是在用 AI 加速制造垃圾。
如果你的团队已经在实践 Harness Engineering，欢迎分享你们的流程和踩过的坑。如果还没开始，从今天开始不算晚。