第十一章聊的是人和 AI 往后的关系。 在收束全文之前，我想把前面几十页里已经长出来的东西，压成一张总图： 约束与流程、反馈、知识库、进化——四块拼图，彼此勾着走。
这一章只做对照复盘：你在第三～七章里看到的是「怎么让 AI 在规矩里干活」；第八章是「干完以后谁来判卷」；第九章是「这座工程从哪读起」。第十、十一章则把问题收束到「人、项目与 AI 各自站在哪一层」。
12.1 四块拼图与章节大致落点
| 约束与流程 | ||
| 反馈 | ||
| 知识库 | ||
| 进化 |
这不是唯一一种拆法，但可以用来对照我们这篇长文的叙事。
12.2 第一块：约束与流程（第三～七章）
从 Rule、Skill 讲起，到多 Agent、流程定义文件和角色契约，再到第七章里一轮轮「撞墙、补洞」——这一条线，本质上都在回答：AI 在工程里按什么节奏、什么纪律推进。
没有这一层，模型再强也只是在对话里即兴发挥；有了这一层，复杂需求才能拆成可重复的接力，每一棒才有明确的输入输出。第七章补的那些漏洞（文档边界、回退、维护方式），其实也是流程本身的硬化：不让协作在「口头默契」里塌掉。
12.3 第二块：反馈（第八章）
约束告诉 AI「应该怎样做」；反馈回答的是「这次做出来的，算不算过关」。第八章把总验证脚本推到台前，就是在补第一章里已经埋过的伏笔：Rule 会软、会忘、会解释性执行，最后总要有一个机器能拍板的入口。
反馈一旦接上，Harness 才第一次具备结果感知：不是流程走完了就完事，而是同一套门槛对每次交付说话。后面第十一章里提到的「规则继续脚本化」「反馈闭环往外推」，都是这一块在往厚里长。
12.4 第三块：知识库（第九章）
第九章把「项目级上下文」说透了：不是给 AI 一本读不完的百科全书，而是给一套够准的索引——开发从 dev-map 进门，需求与任务史从任务看板进门；谁在流程里动刀，谁在流程里顺手改地图。这样 AI 才少在已经长出来的城市里重复铺路。
这一块和「约束与流程」的关系很实在：流程规定什么时候该读地图；地图降低在错误的地方动手的概率；反馈则能在地图过期或漏改时，用失败结果把维护压力打回来。
12.5 第四块：进化（第十～十一章）
第十章讨论 Memory，其实是在划主场：团队要对齐的东西，最终应落在仓库里能看见、能审计、能交接的资产上，而不是长期停在会话记忆。第十一章讨论人和 AI，其实是在划责任上移：人越来越像系统设计者和最后责任人，AI 在制度里高强度执行——Harness 本身会随着项目变难、团队变大而继续改结构、加门禁、加长链条。
所以「进化」不是玄学，而是：前三块搭起来以后，由人与 AI 在各自边界里协作推动的持续改版——人定方向与闸门，AI 在规矩里高密度落地；哪条规矩该进脚本、哪张地图该拆薄、哪段流程该接到 MCP，落成可审计的仓库变更，并会回过头拉升流程、反馈与知识库。
12.6 四块怎么咬在一起
四块是相辅相成的，缺一块，典型症状也很直观：
只有流程没有反馈：容易变成「看起来很忙、但不知道做对没有」的完成幻觉。
只有反馈没有流程：闸机有了，但上游仍是一团即兴，失败日志很难收敛成可维护的改法。
没有知识库（索引）：同一类功能反复被重写、同一类坑反复踩，流程再细也扛不住噪音。
没有进化：前三块容易冻在某一版：脚本与规则没人按新标准收紧，地图与真实结构脱节，改法长期堆在会话里落不回仓库。缺的是人划边界与验收、AI 在规矩内动手这一棒接力——没有它，谈不上对约束、反馈与知识库的持续反哺。
这里把进化再说透一点：它不是泛泛的「项目要写文档」，而是人与 AI 共同驱动 Harness 自身改版的那股力——人决定改成什么样算过关、哪些可以自动化、何时收束进仓库；AI在已定流程与契约里高密度落地（改 Rule、补验证脚本、拆 dev-map、顺任务看板等）。这些变更回过头去拉升前三块：约束与流程会更贴现状，反馈门槛会更准或覆盖面更大，知识库会与最新结构对齐。缺了这一层，常见结局是只靠少数人能记着为什么这样定，或每轮靠聊天临时指挥，前三块得不到结构性的往上推。
把它们放在一起看，Harness 的核心图景就是：
用流程和约束把动作摆进轨道，用反馈让轨道尽头有人判卷，用知识库让 AI 别在城里瞎撞；进化则是人与 AI 合力，把实践与门禁里长出来的结论持续灌回流程和约束、反馈与知识库，让规矩、闸机与地图跟得上结构变化——整套东西才真正跟项目活下去。
12.7 收束到这篇长文本身
JK Launcher 这一路，并不是按「理论四章」一次性设计出来的，而是哪痛补哪、补着补着，四块才逐渐齐全。你若在自己的工程里动手，也大可以从四块里最缺的那一角下刀——不必和我同一顺序，但心里有这样一张总图，后面加 Skill、加脚本时，不容易加偏、也不容易加重复。
让 AI 在工程里受控地工作
第十二章已经把全貌收过一遍；这里只留几句送给要动手的人的话。
Harness Engineering 不是为了让 AI 看起来更聪明，而是为了让 AI 在复杂工程里更可控、更可靠、更可维护。真正跑起来以后，多一分能判对错的反馈，就多一分踏实。
这件事不会一次搭齐。你愿意从最痛、最反复的那一个问题开始，把规矩、技能、脚本和流程一点点沉进仓库，四块拼图就会自己长全。
不要贪大，不要一步到位，先从你最反复、最痛的那个问题开始。
文中关键模块速览