前面在第七章里，其实已经讲到一件事： 当 Rule 开始管不住、Agent 开始会解释性执行、甚至会拿“历史遗留问题”给自己找理由时，很多约束最后一定会继续下沉到脚本。
所以第八章我不再重复那段演化过程，而是只把这件事本身讲透：
为什么总验证脚本会逐渐变成整套 Harness 里最关键的基础设施之一。
在我们工程里，这个角色就是一份总验证脚本。 它不再是“建议你验证一下”，而是在客观上决定：这次开发到底算不算完成。
8.1 总验证脚本到底做了什么
它不是一个单一检查，而是一套“研发后验证总入口”。
它更像一个统一裁判：
先扫规范 | 再看编译 |
再看测试 | 再看规则文件同步 |
再看工程文件是否完整 |
它覆盖了很多本来散落在 Rule 里的内容。最典型的几类包括：
A 类：静态规范问题
XAML 里是否出现中文 | XAML 里是否出现 Emoji | 是否使用了 C# 8.0+ 语法 |
是否直接用了 | 是否有硬编码 UI 文本 | 日志是否缺少前缀 |
是否直接访问 | SVN 认证参数是否规范 | 文件是否过长 |
本地化是否合规 |
B 类：基础交付门槛
编译必须成功 | 测试必须全部通过 | 测试数量不能异常减少 |
C 类：工程一致性
规则文件是否完成多格式同步 |
|
这些检查项单看每一条都不复杂，但它们合在一起，才真正构成了一个“这次开发到底合不合格”的门槛。
更重要的是，事后验证本身就是 Harness 极其关键的一环。
因为前面的 SPEC、Rule、Skill、多 Agent，本质上都还在解决“怎样让 AI 去做事”的问题；但如果没有事后验证，你其实始终不知道它这次做出来的结果，到底是正确的、错误的，还是只是看起来像完成了。
这一点是我们后来越做越深以后，感受特别强的一件事。 很多团队把 AI 开发做成了“能自动往前推进任务”，但它们缺少一个扎实的反馈回路。结果就是：
AI 的确把事情做完了 | 文档也写了 |
代码也改了 | 甚至自己还会告诉你“已经验证通过” |
但系统本身并没有真正感知： 这次产出到底是对还是错。
而事后验证的意义，恰恰就在这里。它不是为了让流程看起来完整，而是为了让这套 Harness 第一次具备“结果感知能力”。 也正是从这一步开始，我们的系统才不再只是“能推动事情继续发生”，而是开始有能力判断：这次事情到底做得对不对。
8.2 为什么这一步对 Harness 特别关键
因为从这一刻开始，AI 的完成定义不再是：
“我觉得我做完了。”
而变成：
“脚本判定你通过了，你才算做完。”
这一步是一个非常大的质变。
8.3 为什么它最后会变成统一入口
总验证脚本真正厉害的地方，不只是“多了一个检查工具”，而是它把很多原本分散的事情收成了一个统一入口。
以前这些动作可能分散在：
Rule 里的一句话 | Skill 里的某个步骤 |
Agent 自己的收尾说明 | 维护人脑子里的经验 |
但当它们被统一收进一份总验证脚本以后，开发完成的定义就第一次真正被收紧了：
不是你主观说做完了就算 不是你局部通过了某一项就算 而是要经过同一个统一入口的检查
这对 Harness 很重要。 因为只有当“完成”也被统一定义以后，整套系统才开始从“很多零散约束”变成“一个真正有门禁的工程流程”。
如果让我从整个 Harness 里挑一个最容易被低估、但实际价值极高的模块，我会选事后验证。
因为它补上的不是一个步骤，而是一整个反馈闭环。
在没有这套闭环之前，我们其实经常停留在一种“任务完成幻觉”里： AI 把代码改了，文档写了，流程往下推进了，于是我们会下意识觉得这次开发完成了。 但完成不等于正确，推进不等于收口，做了事情不等于把事情做好了。
而当这类事后验证真正成为流程硬门槛以后，整套 Harness 的性质就变了：
它不再只是一个会驱动 AI 往前跑的系统 它开始具备对结果做判断的能力 它开始形成“做事 -> 校验结果 -> 发现问题 -> 回退修复 -> 再次验证”的完整回路
这才是我理解里真正开始成熟的 Harness。
做到这里，我们的 Harness 已经能独立完成相当复杂的需求了。 但如果任务进入持续迭代阶段，还会遇到一个非常现实的问题：
PM 和各个 Agent 缺乏整个项目的全局视野。
这时候如果还只是单看当前需求，很容易发生两种惨案：
1. 新方案把旧方案冲掉
2. AI 重复造轮子，根本不知道项目里已经有现成实现
这一章要补的，可以粗粗理解成：给 AI 配一份跟着仓库走的项目级知识库。 但这里说的知识库，不是把整仓说明书塞进上下文那种「百科全书」，而是一套够准的索引——先告诉它该从哪几条线、哪几份文档进门，再让它自己去翻代码、对细节。
维护上，我们尽量让流程里的 AI 自己改、自己闭环（谁动代码谁改地图，谁管需求谁改看板），减少「写一份永远没人更新的漂亮文档」那种尴尬。
具体落到我们工程里，是 dev-map 和 任务看板 这两块；它们和第一章 Workflow 末尾那条纪律也对得上：项目还小的时候，没必要一上来就把整仓库地图和全部任务历史塞给 AI。 时机会变：持续迭代起来以后，这一层才变得划算。
前面几章更多是在补「流程上下文」
到这一章，补的是「项目上下文」——写进仓库、大家能看见、能接着改的那一层
9.1 「项目级索引」常见有哪些搭法
同一件事，不同团队会选不同材料；下面只是几种常见路子，互不排斥，也经常混着用。 本章后面写的 dev-map 和任务看板，只是我们仓库里实际在跑的组合，不是唯一答案。
人工整理的导航文档：按功能、服务、配置把「该看哪、别碰哪、惯例怎么写」写清楚，改结构时跟着改文档（我们 dev-map 属于这一类）。
任务 / 需求总览：一张表或一页索引，记当前在做什么、做到哪一阶段、文档落在哪个目录、上一轮结论是什么（任务看板属于这一类）。
工具自动吐出来的「地图」：依赖图、模块清单、接口列表、测试报告之类，由脚本或 CI 定期生成，给人和 AI 当第二参照。
编辑器 / 语言服务能提供的跳转：符号定义、引用查找——负责的是「这一行代码在哪」，和「这一坨业务该从哪进门」往往是两回事，可以互补。
检索进上下文：对文档或代码块做全文搜、关键词搜，或接上向量检索，按问题临时捞片段；适合兜底，通常代替不了一张维护得好的索引表。
仓库里的轻量约定：顶层 README、各模块 README、CODEOWNERS、贡献指南——篇幅短，但能把「从哪读起」说死。
单独的知识库或 Wiki：和代码分仓管理时常见；要记得和仓库里的真相对齐，否则容易各说各话。
看清这些选项以后，第九章想强调的其实就两句：别把「项目级上下文」理解成堆字数；它首先该是一套索引。 至于索引具体长什么样，完全可以按团队习惯换材料——我们接下来只展开自己用的那两样。
它们在我们这边的分工，可以先压成一张表：
9.2 dev-map：开发侧那本导航
主工程下面有一套开发导航地图，规则写得很直白：改代码之前，先查 dev-map。 动刀之前先把功能落点、影响范围从地图里对一遍。
很多人第一次听到 dev-map，会以为它只是「文件列表」。 它的用处其实更大一些：更像这座工程的开发导航图，说的是——
某个功能一般落在哪些文件 | 某类服务怎么接入 |
某类配置通常在哪定义 | 改一个模块可能会牵动哪些链路 |
项目里已有的标准写法长什么样 |
核心就一条：先搞清这里已经长成了什么样，再下手。 AI 容易「重新发明一遍轮子」；地图的作用，是让它早点看见这座城市不是空地。
这套东西由 开发 Agent 在干活的过程中维护，而不是 PM 单维护。 谁改地貌，谁最有资格改地图——这和前面说的「AI 闭环更新知识库」是同一套逻辑。
仓库很大的时候
文件多到一定程度，一张表想写全所有文件，表本身会先变成负担，也很难长期和仓库对齐。更常见的折中是：前面留几页总览——从哪进门、几大块各管什么；扎进某一块开发，再翻那一块自己的说明。具体某个类、某个路径，交给搜索、跳转或后面的检索去办；dev-map 这边，主要还是结构和习惯用法。大地图可以拆成好几本薄一点的册子，每本封面写清管哪一片，往往比硬撑一本厚目录要现实。
9.3 任务看板：需求侧那张总览
另一个关键是项目任务看板，由 PM 维护。 它不是普通待办，而是项目级的任务总览，一般会记：
当前有哪些任务在做 | 每个任务进行到哪个阶段 |
对应的文档目录在哪 | 已完成任务的交付结论是什么 |
新的需求分析 Agent 进来时，不必从零猜和历史有没有关系——先看一眼看板，往往能回答：是不是旧需求的延续、有没有类似任务做过、文档在哪、上一轮设计怎么定的。 「新需求把旧设计冲掉」的概率会小很多。
dev-map 偏代码与模块结构从哪进门；任务看板偏需求和任务历史从哪进门。两个入口都写在仓库里，AI 在流程里各改各的，这一层才算转得起来。
所以这一章收束时想留的，不是「两个工具的名字」，而是一层能力：
AI 已经会把当前任务做完以后，还能在仓库里找到「整个项目从哪读起」的那几把钥匙。