Harness Engineering 十四讲：AI 时代，软件工程的基本功反而更重要（郑晔风格）

Harness Engineering 十四讲

副标题：郑晔风格——结构化教学体，写给一线工程师和技术管理者

开篇：写给那些“也开始让 agent 写代码”的团队

最近一年，我接触过的研发团队里，没有一支没在用 coding agent。Cursor、Claude Code、Codex，或者企业内部基于开源模型搭的方案——agent 已经是开发现场的标配了。

但当我和这些团队的负责人坐下来聊，几乎每个人都会冒出同一类问题：

“agent 速度看起来很快，合并的 PR 怎么反而要返工三次？”
“让 agent 写测试，覆盖率上去了，线上 bug 怎么没少？”
“AGENTS.md 写了，越写越长，最后没人维护，怎么回事？”
“agent 给团队的实际收益怎么衡量？PR 数？工时数？还是别的？”

问题听起来五花八门，抽象一下，其实都在问同一件事：怎么让 AI agent 在我们的工程系统里靠谱地工作？

这正是 Birgitta Böckeler 在 martinfowler.com 上提出“Harness Engineering”想解决的事。需要说明一下：那篇《Harness engineering for coding agent users》的作者是 Thoughtworks 的 Böckeler，不是 Fowler 本人。下文我说“Fowler / Thoughtworks 思想脉络”，指的是这一整脉技术思想生态——重构、CI/CD、测试金字塔、技术债、演进式架构——而不是把所有观点安到 Fowler 一个人头上。

接下来 14 讲，我会把这个话题拆开讲。每一讲对应一个核心概念，配实践建议，最后给一份可以发给团队的 checklist。希望这套内容能成为你和团队讨论“怎么用好 agent”时的共同语言。

第 1 讲：先看清楚 Harness Engineering 到底在解决什么

核心结论：Harness Engineering 不是新名词，它是软件工程基本功在 AI 时代的延伸。

先来定义。Böckeler 在文章里的描述是：harness 是 agent 周围那一整套外部工程环境——上下文、规范、质量检查、工作流指导、工具、测试、反馈信号——让 agent 知道自己有没有走偏的全部机制。

留意她用的词：harness。马具里的挽具，那套缰绳和肩带。不是用来禁锢马的，是让马的力量被引导到对的方向。这个词选得精确——一整套让强大但不完全可控的执行体能被驾驭的工程环境。

Böckeler 直接借用了控制论的语言：agent 的 harness 像控制论里的 governor（调速器），结合前馈（feed-forward）和反馈（feedback），把代码库调节到期望状态。

这就把问题的层级拉高了。我们要解决的不是“怎么写好提示词”，也不是“怎么挑一个更好用的 IDE 插件”，而是：怎么设计一个让人类、agent、代码库、测试、部署、监控、用户反馈共同构成的可控系统？

仔细想想，这其实是软件工程一直在问的老问题。Fowler 写《Refactoring》《Continuous Integration》《Continuous Delivery》《Building Evolutionary Architectures》，本质上都在解决同一件事：让大型软件系统能长期、安全、快速地演进。AI agent 没有改变这个问题，只是把它放大了——变化的速度被拉到了人类阅读速度之上。

所以我建议你建立这样一个心智模型：

Harness Engineering = 在 AI agent 时代，把软件工程的“基本功”重新组织成一个可执行、可观测、可治理的反馈系统。

带着这个框架，下面 13 讲的所有内容，都会显得顺理成章。

第 2 讲：澄清一个常见误会——Harness Engineering 不是 Prompt Engineering

核心结论：提示词是控制策略的一种表达，但真正的控制系统依赖多层传感器和反馈闭环。

我经常听到团队负责人这样汇报：“我们今年重点投入了 prompt engineering，沉淀了一批高质量提示词。”

这是好事。但如果只停在这一层，其实只解决了 harness 的很小一部分。

用控制系统的语言来对比：

Prompt engineering：关注“怎么对模型说话”，对应控制论里的“控制信号设计”。
Harness engineering：关注“怎么搭一个让错误更容易暴露、好行为更容易发生、偏差更容易被纠正的工程环境”，对应控制论里的“被控对象 + 调节器 + 传感器 + 反馈通路”。

提示词是 feed-forward，是 agent 行动之前的引导。Harness 还包括 feedback——agent 行动之后，靠测试、类型检查、lint、CI、静态分析、生产监控、用户行为来发现偏差、修正偏差。Böckeler 在原文里直接说 harness 像一个 cybernetic governor——她不是在用比喻，是在指出方向：这件事必须用控制论的方式去想。

建议在团队内部统一这样的语言：

维度	Prompt Engineering	Harness Engineering
解决问题	怎么让 agent 听懂我说什么	怎么让 agent 在系统里可靠地工作
主要对象	提示词 / 上下文 / few-shot	工程环境 / 反馈系统 / 治理机制
触发时机	行动之前	行动之前 + 行动之后 + 长期演化
失败模式	表达不清 / 上下文不够	反馈不及时 / 边界不清 / 治理失效

这张表可以直接搬到团队周会上，帮你判断：今天遇到的问题，是 prompt 层面的，还是 harness 层面的？

我的经验是：超过一半被报告为“prompt 不好用”的问题，根因都在 harness 那一层——反馈链路太慢，测试在装样子，规则没人执行。

第 3 讲：基本功复盘——持续集成、测试金字塔、重构、技术债、演进式架构

核心结论：Fowler 这一脉积累了三十年的工程实践，每一项都是一个反馈系统的部件。

要理解 Harness Engineering，先把基本功盘点一遍。下面快速过，重点放在每一项和“反馈系统”的关系上。

持续集成（CI）。Fowler 给 CI 的定义：团队成员至少每天把工作集成到主线，每次集成由自动化构建和测试验证。他反复强调两件事：broken build 必须立刻修，build 时间最好不超过十分钟。这两条不是洁癖，是反馈系统设计的地基——反馈太慢，开发者就会忽略它；反馈快到位，行为闭环才能形成。

持续交付（CD）。CI 关注代码变化的快速验证，CD 把反馈范围扩展到发布能力。CD 的核心不是“每天都上线”，而是“随时具备安全上线的能力”。发布一旦变成罕见、巨大、不可预测的事件，组织就失去了反馈；发布变成频繁、小步、可回滚、可观测的过程，组织就获得了控制。

测试金字塔。底层是大量快速的单元测试，中间是集成层测试，顶部是少量 E2E 测试。关键洞察是：反馈系统本身需要架构。单元测试快、定位清晰，但覆盖系统交互有限；E2E 测试信心高，但慢、脆、维护贵。好的反馈系统是不同粒度传感器的合理组合，不是一味堆砌。

重构。在不改变外部可观察行为的前提下，逐步改善内部结构。重构不是“把代码改漂亮”，它回答的是一个工程问题：软件开发真正的困难，不是第一次把功能写出来，而是在未来无数次变化中保持系统可理解、可修改、可验证。重构是受控改变的技能，是后续所有“安全演进”的基础。

技术债。代码中积累的 cruft 让未来修改变得更困难，这些额外成本就像债务利息。Fowler 的技术债象限提醒我们，债务不一定源于愚蠢决策——团队可能有意识地承担债务，也可能在学习后才发现早期设计有局限。重点不是“消灭所有债务”，而是让债务可见、可估、可还。

演进式架构与 Fitness Function。《Building Evolutionary Architectures》的核心思想：架构不能交给偶然，要靠小步变化加反馈循环来演进；fitness function 把“架构治理”变成了可执行规则——以前架构靠架构师脑袋里的模型，现在靠 CI 里跑得动的检查。

五件事放一起看：它们都不是关于“写代码”的，而是关于“让代码能被持续、安全地改”的。

这就是 Harness Engineering 的根基。AI agent 没有让这些基本功过时，反而让它们更重要——变化速度被放大了，没有反馈系统兜底，速度就等于失控。

第 4 讲：上下文工程——AGENTS.md 和服务模板该怎么写

核心结论：在 AI 时代，文档不只是给人看的说明书，更是 agent 的操作环境。

很多团队接触 agent 后做的第一件事，就是写 AGENTS.md。方向没错，但落地时常走两个极端：

写得太少。一句“我们用 Spring Boot，请遵循代码规范”，agent 完全无从下手。
写得太多。十几页，规范、风格、提交规则、目录布局、CR 要求、线上事故反思全塞进去。Thoughtworks 在 Radar 里管这叫 agent instruction bloat——过长、冲突、臃肿的指令要么被忽略，要么产生副作用。

正确的方式是 progressive context disclosure：分层组织，按任务渐进披露。

建议按这个结构来组织：

全局原则（顶层 AGENTS.md，控制在一两屏内）：领域语言、架构原则、技术栈、提交规范、不可触碰的边界。这一层只放“不会因任务变化的”内容。
服务级约束（每个微服务一份 AGENTS.md）：本服务的限界上下文、对外契约、依赖规则、特殊约束。
模块级契约（关键模块的 README）：本模块的不变量、典型调用方式、易踩坑的地方。
任务级验收标准（写在 issue / PR 描述里）：这一次任务的目标、验收条件、关键测试点。
运行时反馈（CI / lint / test / fitness function）：这些是机器自动给 agent 的硬性反馈，不依赖文档。
历史经验沉淀（事故复盘 / 重复 review comment）：把它们升级为 lint 规则、模板约束或 agent instruction，而不是在文档里反复写。

OpenAI 在 2026 年那篇关于 harness engineering 的文章里也提了类似看法：repo knowledge base 应该成为系统记录，文档和检查结合，信息渐进披露，通过 lint、CI 等机械方式执行。

容易被忽视的几件事：

AGENTS.md 必须版本化、CR 化，和代码同步演化。不做这一步，它很快就会成为一份谁都不信的过时文档。
别把“团队文化”塞进 AGENTS.md。文化靠人讲，靠 1on1。AGENTS.md 是给 agent 看的，要写它能执行的内容。
服务模板（service template）的价值远高于文档。一个好的模板让 agent 从一开始就处在可治理状态：lint、test、CI、可观测性、健康检查全部默认就位。这比任何“风格指南”都管用。
反复出现的 review comment，升级为 lint 规则或模板条目。让机器替你说话，比让人不断重复有效得多。

一句话：好的上下文不是越多越好，而是越能被 agent 直接拿着用越好。

第 5 讲：Harnessability——让代码库变成 Agent 友好的环境

核心结论：不是所有团队都能同等受益于 coding agent，原因不在模型，而在代码库。

Böckeler 在文章里引用了控制论的 Ashby Law：调节器要有效控制系统，其可处理的复杂度必须至少匹配被控系统的复杂度。她据此提出一个重要概念：harnessability——代码库被 harness 化的难易程度。

判断标准很直观：类型检查、模块边界、框架和清晰结构会让代码库更适合被 harness；遗留系统和缺乏结构约束的代码库则更难被 agent 安全处理。

这个洞察对国内大量“在维护期”的团队尤其重要。我接触过一些金融、电信、政务系统的团队，代码库历史超过十年，结构难以言说，文档与代码完全脱节。这种代码库直接放 agent 进去，几乎一定是混乱被加速：

没有清晰的限界上下文，agent 会跨越边界写代码；
没有类型系统或弱类型，agent 的猜测空间过大；
没有覆盖到位的测试，agent 改动后没有反馈；
没有架构规则的可执行表达，agent 会自然漂移。

所以我给这种团队的建议是反直觉的：先别急着推 agent，先花半年做 harnessability 改造。

从这几件事入手：

画清楚限界上下文。基于 DDD 思想，让团队明确每一块业务的边界。不要求一步到位，从最核心的两三个上下文开始。
补完核心模块的类型。Java / TypeScript / Go 把核心数据结构和对外接口的类型严格化；Python 至少在核心模块加 type hint 并启用 mypy。
先把测试骨架搭起来。优先级：先有契约测试和关键路径的集成测试，再补单元测试。目标不是覆盖率数字，而是“任何破坏行为都能在 CI 里立刻显形”。
架构规则可执行化。ArchUnit、依赖扫描、模块边界检查、Spring Modulith——把“不能依赖什么”“不能跨过什么”变成 CI 里的硬规则。
建服务模板。新服务从模板出发，模板默认带好 CI、lint、可观测性、健康检查、安全基线。

做完这些，代码库才有“被 harness 化”的基础。agent 进来才会产生杠杆，而不是制造灾难。

给团队的一句话：AI coding agent 的生产力 = 模型能力 × 代码库 harnessability × 工程反馈系统质量。模型能力大家差不多，真正拉开差距的是后两个因子。

第 6 讲：反馈传感器——六层反馈环的合理布局

核心结论：Harness 不是一个调节器，是一组各有节奏的反馈环。

一个完整的工程反馈系统可以拆成六层，每层有自己的延迟、成本和检查目标。

第一层：本地与编辑器反馈（毫秒到秒级）
类型检查、语法检查、格式化、IDE 提示、编辑器内 lint。反馈最快、成本最低，应该最先建好。

第二层：预提交与 CI 早期反馈（秒到几分钟）
单元测试、契约检查、静态分析、基础安全扫描、依赖审计。Thoughtworks Radar 把它叫做 “feedback sensors for coding agents”——agent 必须能直接访问这些信号，失败时即时触发自我修正。

第三层：CI 完整反馈（几分钟到几十分钟）
集成测试、API/服务级测试、性能基准、构建产物校验。要快但不能省。Fowler 的“十分钟构建”是一条好的目标线——超过它，开发者就开始敷衍。

第四层：部署与预生产反馈（几十分钟到几小时）
端到端测试、灰度发布、金丝雀、影子流量、合成监测。E2E 测试昂贵，只保留给最关键的用户旅程。

第五层：生产与用户反馈（小时到天）
错误率、SLO、可观测性、用户行为、留存、商业指标。这一层 agent 自己看不到，必须通过人类工程师或自动化通道回到代码改进。

第六层：架构与组织学习反馈（周到季度）
架构漂移、依赖健康、模块耦合、变更热点、技术债利息、事故复盘、团队负担。最慢的一层，但决定了系统的长期可演进性。

建议你的团队画一张六层“反馈地图”，看哪些层是空的，哪些层是慢的，哪些层是没人看的。

我见过很多团队，一二层做得不错，第三层勉强，四五六层基本空白。agent 进来之后体感就是“看起来很灵，生产 bug 没少”。原因很简单：agent 只能在前三层的反馈里自我修正；四五六层的偏差要等上线才暴露，那时候 agent 已经又往前跑了几百步了。

补齐这六层，是 Harness Engineering 落地最实在的工作。

第 7 讲：从 Human in the loop 到 Human on the loop

核心结论：人类的位置不是“在每一行代码上把关”，而是“监督和改进 harness 本身”。

传统人机协作模型叫 human in the loop：每个关键决策点都需要人来审查批准。agent 一次只改一两行的时代，这个模型是合理的。

但当 agent 一次提交改 30 个文件、写 60 个测试、引 3 个新依赖，human in the loop 的成本就扛不住了。坚持每行都看，team velocity 反而比没用 agent 还慢。

Böckeler 提出了一个更精确的位置：human on the loop——人不在每个动作里，而在 loop 之上，监督、调整、改进反馈系统本身。

这不是放弃审查，是审查对象的转移。

维度	Human in the loop	Human on the loop
主要审查对象	每一行代码 / 每一次产出	反馈系统 / 规则 / 治理机制
主要问题	这次产出对不对？	我们的系统在长出什么？
时间分配	大量花在 review 上	大量花在改 harness 上
失败模式	来不及看 / 被淹没	长期看不见 / 反应慢

落到具体行为上，我建议你的团队这样分工：

核心代码：仍然是 in the loop。每一行人类都看。这是不能让步的红线。
边缘代码：上 on the loop。靠测试、生产反馈、监控兜底，PR 看结构和命名而不是每行。
临时代码：完全交给 agent，但要标记“过期日”。

同时，团队里要有人——不一定专职——负责改进 harness 本身：观察重复失败、定期 review lint 规则、维护 AGENTS.md、迭代服务模板、在 retrospective 里把人工经验升级为机制。这个角色我叫它 harness steward。

AI 时代的工程师，不是从“写代码的人”变成“点按钮的人”，而是从“局部执行者”变成“系统调节者”。

第 8 讲：度量——别只量速度，更要量协作质量

核心结论：错的指标会引来大量低质量代码；对的指标才能让团队真正变好。

AI agent 给组织带来一个很大的诱惑：那些“看起来很美”的指标——每周生成代码行数 ↑、合并 PR 数 ↑、节约工时 ↑、测试覆盖率 ↑。

直说吧：这些指标单独看，几乎都是有害的。它们鼓励的是“合更多 PR、写更多测试、生成更多代码”，而不是“做对的事”。

Thoughtworks Radar 2026 给出了一个更平衡的体系，我整理成三类：

第一类：局部反馈指标（看 agent 自己干得怎么样）

测试失败率 / lint 违规率 / 类型错误率
agent 任务的迭代次数（迭代次数过多通常是上下文不够或边界不清）
构建时间 / pre-commit 时间
agent 输出的 first-pass acceptance（一次通过率）

第二类：交付流指标（看团队整体怎么样，DORA 派系）

Lead time for changes（变更前置时间）
Deployment frequency（部署频率）
Change failure rate（变更失败率）
Mean time to recovery（恢复时间）
在此基础上，再加一个 review burden（人均 review 工作量）

第三类：长期健康指标（看一年后的事）

架构漂移指数（依赖跨界违规数 / 月）
依赖健康（过期依赖数、CVE 暴露数）
模块耦合演化（耦合度趋势）
测试有效性（mutation testing 杀死率）
技术债利息估算
生产事故趋势 / 用户体验信号

三类指标合起来用，才能避免被 AI 的表面速度欺骗。

不过必须提醒一点（Thoughtworks 自己也说了）：指标应作为指导，而不是管理激励。一旦把这些指标和 KPI、奖金挂钩，团队行为会立刻畸变——人会去优化指标，而不是优化系统。

我的建议：把这些指标公开，定期在 retrospective 里讨论，用来推动团队对话和学习；绩效评估仍然靠综合判断、产品成果、长期能力。这是我的偏见，但我相信它经得起检验。

第 9 讲：安全与 Zero Trust——给 Agent 设最小权限

核心结论：Coding agent 不是可信同事，而是需要受控权限的自动化执行体。

这一讲短一点，但每一句都值得记住。

当 agent 可以读写代码、运行命令、调用工具、访问网络、安装依赖甚至触发部署，它的攻击面就非常大了。Thoughtworks Radar 直接把 sandboxed execution 列为 coding agent 的合理默认——限制文件系统、网络、资源访问，因为 permission-hungry agents 会带来 prompt injection、tool poisoning、不安全路径等风险。

按 Zero Trust 原则来设计 agent 的运行环境：

默认沙箱：agent 在容器或沙箱里跑，文件系统、网络、密钥都隔离。
最小权限：每个任务只给完成它必需的权限。读代码不等于改代码，改代码不等于推送，推送不等于部署。
凭据隔离：production 凭据永远不进入 agent 上下文；secrets 用临时 token，过期失效。
可疑动作要二次确认：删除文件、改 CI 配置、改 IAM、改密钥、安装新依赖——这些都要 human approval。
审计日志：所有动作可追溯。一次事故发生时，你能清楚地知道是 agent 还是人，做了什么。
网络出口控制：agent 默认不允许访问任意外网，只允许白名单。
依赖审查：agent 引入新依赖时，自动经过供应链安全扫描。

我见过最危险的实践：有团队让 agent 拥有 kubectl 和生产数据库的写权限，理由是“这样它能自己 debug”。它确实能自己 debug，但有一天它也会自己删表。

把 agent 当作一个拥有键盘自动化能力的实习生，权限就按这个心智模型来设。

第 10 讲：技术债治理——从季度盘点到持续传感器

核心结论：技术债不是季度盘点出来的，是持续传感出来的。

Thoughtworks 关于 scaleups 的一篇文章把技术债列为成长型企业的常见瓶颈，分成几类：代码质量、测试、耦合、低价值功能、过时库和框架、工具、可靠性和性能。这套分类很实用，可以直接拿来给团队画债务清单。

但更重要的是：在 AI 时代，技术债治理不能只靠“季度复盘 + 临时清理周”。Agent 制造小不一致的速度远比这个节奏快，必须把识别嵌入日常开发流。

可以落地的做法：

变更热点高亮：用 git history 找出近 N 个月被频繁修改的文件。这些是 bug 和重复修复的高发区，应该提高 agent 在这里的检查强度，强制人类 reviewer。
回归缺陷与契约测试挂钩：某个模块出了回归 bug，修复 PR 里要求补充契约测试。这一步可以写成 PR 模板，机械执行。
依赖健康看板：依赖过期、CVE 暴露、license 风险，自动每天扫描，自动开 PR。这件事 agent 干得很好，比人省心。
mutation testing 抽样：每周对核心模块跑一次，看测试到底有没有真本事。覆盖率 100% 但 mutation kill rate 只有 30%，说明测试在装样子。
架构边界检查：把限界上下文和依赖规则编码成 fitness function，agent 一跨界，CI 直接挂。
review comment 模式识别：每月统计哪些 review comment 在重复，重复 N 次的升级为 lint 规则或 AGENTS.md 条目。
agent 一次通过率追踪：某个模块一次通过率持续低于平均，说明它的 harnessability 有问题——文档缺、边界乱或测试少。列入下个迭代的整理清单。

OpenAI 那篇 harness 文章里有句话值得反复读：反复出现的失败不是单个 agent 的“犯错”，而是工具、文档、护栏或验收标准缺失的信号。

技术债治理的核心思路就是这个：把偶发的人工判断，转化为持续的系统能力。

第 11 讲：团队治理——自治 + 平台 + 轻量规则

核心结论：好的治理不是中央审批，是让正确行为成为默认路径。

Thoughtworks 长期支持团队自治，但他们说的“自治”是有结构的——轻量规则 + paved road + 反馈机制。

组织设计上的几个要点：

平台团队提供 paved road，不做审批瓶颈。Paved road 就是默认带好 CI、lint、可观测性、安全基线、agent harness 的服务模板。走这条路，享受全部基础设施；不走，自己负责合规。这比“必须经过架构审批”管用得多。
业务团队拥有自己的 agent 用法，但实践要进入共享的知识库，新经验、新失败定期回流。
建立 harness steward 角色。可以兼职，也可以是 community of practice，负责把跨团队的失败模式和好做法沉淀下来。
中央团队做“信号”，不做“审批”。观察整体趋势——哪些模块在出 bug、哪些团队在累、哪些技术栈过期、哪些 agent 模式在失败——把发现变成 paved road 的下一步改进。
技术债治理纳入产品迭代。别做“集中清债周”，那是创可贴。让债务清理成为每个迭代固定比例的工作（比如 20%），由团队自己决定还哪些。
失败日志与学习闭环。每次 incident 之后问三个问题：哪些反馈环没生效？哪些规则该升级？哪些 agent instruction 该改？答案变成下个版本的 harness。

治理不是束缚，是让“不出错”成为最便宜的选择。当正确路径就是默认路径，团队不需要勇气也能做对事。

第 12 讲：Harness 也会失效——警惕虚假安全感

核心结论：调节器自己也是系统的一部分，它会衰老、漂移、被绕过。

讲到这里，该泼一盆冷水了。

AGENTS.md 写好了，CI 搭好了，fitness function 铺了，观测建了，指标定了，harness steward 也安排了——是不是万事大吉？

不是。Böckeler 自己也写了一个开放问题：你怎么知道你的 harness 是否真的有效？传感器从来不触发，是系统真的健康，还是传感器根本没覆盖到风险？

这个问题很深刻。我见过太多团队栽在“虚假安全感”上：

测试在装样子：覆盖率高，断言空洞，重构一改全通过。
lint 在装样子：规则全开，但都是格式化级别，架构层面什么都没约束。
AI review 在装样子：每个 PR 都有 LLM 评论，看着专业，关键安全漏洞照漏。
架构规则过时：fitness function 还在检查三年前的架构，新结构早悄悄长出来了。
指标驱动错误行为：为了 first-pass acceptance 高，agent 学会了写最保守的代码、最简单的实现，复杂边界全跳过。
AGENTS.md 失控：规则一半过时，但新人来了还在按它走。

Thoughtworks 也明确指出：AI 生成的测试目前不能完全信任，行为层面的 harness 仍然困难。

所以成熟的 Harness Engineering 必须包含一项工作：对 harness 自身建反馈环。

怎么做：

mutation testing 定期跑：抽样核心模块，验证测试的真实有效性。
incident-driven harness review：每次 incident 后问“harness 为什么没拦住？”没有规则就加规则；有但被关了，搞清楚原因。
lint 规则季度 review：过一遍所有规则，删掉过时的，加上新发现的。
AGENTS.md 半年瘦身一次：删除过时和冲突的条款。
抽样人工 review：即使有 AI review，团队 leader 每月抽几个 PR 自己看，校准 AI 的判断质量。
retrospective 也要 retro harness：不只 retro 项目，也要 retro 反馈系统本身。

好的 harness 不是“永远正确的自动化规则”，而是一个不断被现实校正的控制系统。

第 13 讲：给团队的实操 Checklist

前面 12 讲的内容，落到一份团队可以直接拿走的 checklist。分成五块。

A. 上下文与指令

团队有一份顶层 AGENTS.md，控制在两屏内，明确架构原则、技术栈、不可触碰的边界。
每个核心服务有自己的 AGENTS.md，写清楚限界上下文和对外契约。
重复出现的 review comment 已升级为 lint 规则或 AGENTS.md 条目，而不是反复在 PR 里写。
AGENTS.md 与代码同仓库、同版本、走同样的 CR 流程。
有一份服务模板，新服务从模板出发，自带 CI、lint、可观测性、安全基线。

B. 反馈系统

本地与编辑器反馈（类型、lint、格式）齐全。
预提交反馈（单元测试、契约检查、静态分析）秒级可用。
CI 完整反馈在十分钟内（核心服务），二十分钟内（整体集成）。
端到端测试只覆盖关键用户旅程，且稳定（flaky rate < 5%）。
生产可观测性能在小时级反馈到代码改进。
架构与债务反馈（fitness function、依赖扫描、热点统计）每周输出。

C. Harnessability

核心模块类型严格化，弱类型语言至少有 type hint + 静态检查。
限界上下文已画清楚，模块边界在 CI 里可执行。
关键路径有契约测试与集成测试，覆盖率不是目标，破坏行为能否被发现才是。
定期跑 mutation testing 抽样，了解测试真实有效性。

D. 安全与权限

Agent 默认在沙箱里跑。
Agent 没有生产凭据。
高风险操作（删文件、改 CI、改 IAM、装依赖）需要人类二次确认。
所有 agent 操作可审计、可回溯。
网络出口白名单。

E. 治理与度量

看板上同时有三类指标：局部反馈、交付流（DORA）、长期健康。
这些指标用于 retrospective，不直接挂钩个人绩效。
有 harness steward 角色，负责持续改进 harness 本身。
每季度做一次 harness review：lint 规则 / AGENTS.md / fitness function 是否过时？
每次 incident 之后，必须更新某一处 harness。

这份 checklist 不用全做完才算合格。和团队一起过一遍，挑出最差的 5 项，作为下一季度的目标。三个季度下来，工程纪律会有质的变化。

第 14 讲：小结——AI 时代的工程师是什么样的？

最后一讲，拉远一点看。

把过去三十年 Fowler 这一脉的工程思想串起来，主线非常清晰：持续集成解决集成反馈，持续交付解决发布反馈，测试金字塔给行为反馈提供架构，重构保证结构能持续改善，技术债理论让长期修改成本可见化，Design Stamina Hypothesis 解释了为什么短期速度不能替代长期耐力，演进式架构和 fitness function 解决架构反馈，Technology Radar 解决组织层面的技术选择反馈。Harness Engineering 把这些思想带入 AI coding agent 时代，形成一个新的控制平面。

软件工程的核心，从来不是写更多代码，而是让系统能长期、安全、快速地演进。AI 没让这件事变简单，反而让它更急迫——变化速度被拉到了人类阅读速度之上，没有 harness，速度就是失控。

AI 时代的工程师，不是被替代的执行者，也不只是审查 AI 产出的把关人。他是新工程系统的设计者——设计上下文让 agent 知道方向，设计反馈环让偏差快速暴露，设计架构边界让结构不容易漂移，设计指标让团队不被表面速度蒙蔽，设计治理机制让正确路径成为默认选择，设计学习闭环让每次失败都让系统更健壮。

说到底，他是一个用控制论思维重新定义自己工作的人。

如果读完这 14 讲只记一句话，我希望是这句：

AI 时代的软件组织，竞争的不是谁拥有最强模型，而是谁拥有最强的反馈系统。

模型大家都买得到，反馈系统得自己长出来。这不是几周能完成的事，但每一周都可以让它好一点。

从下一个 sprint 开始吧。

李文业的思考笔记