有了 dev-map 和任务看板以后，我们忽然发现，前文几乎没单独提一件很多人挂在嘴上的东西：Memory。
第九章补的是「项目级上下文」——写进仓库的索引：开发导航（dev-map）和任务总览（任务看板），大家能看见、流程里也会接着改。业界和产品里常说的 Memory，多半是另一类东西：藏在会话或产品里的、帮模型「记着点啥」。二者听起来都在解决「别丢上下文」，解决的却不是同一个问题。把这件事说清楚，这一章就值得单独占一节。
在标准化的、多人协作的、项目级 Harness Engineering 里，我的观点依旧很明确：Memory 可以不在主干上——不是说它「邪恶」，而是说团队该对齐的真相与规矩，不该指望靠「记忆层」当权威来源。
10.1 先把 Memory 拆成两类：都在存什么
大家说的 Memory，大致两种：
一类是偏「这一轮」的。
也就是当前对话里攒下的上下文：刚讨论过的结论、临时贴进去的说明、甚至有人把「错题、反例」先堆在聊天里。作用很简单：这一场别断片。
一类是偏「跨很多轮」的。
隔几天再来，产品或系统仍帮你记着的东西：个人偏好（例如「回答用中文」）、操作习惯（例如「用 PowerShell 跑命令」）、「别这么写」的口头规矩、或者几条成功/失败案例的片段。作用也很直接：少重复交代。
但是我认为：凡是最后会变成「团队都要遵守」或「交付要对齐」的东西，都不该长期停在这一层。
10.2 档案、故事、手册——该进仓库的，别只靠聊天记忆
我喜欢用三句话压住分工：
事实像档案，例子像故事，规矩像手册——手册应进仓库，别只靠聊天记忆。
对照到这套 Harness 里，可以这样理解：
| 优先 Scripts（能判定就脚本），其次 Rule； |
所谓「错题集」，若真重要，就该晋升级：进 Rule 或进 Scripts，而不是长期当对话里的私有笔记。
10.3 个人偏好与 Memory：可以用，但要和「团队标准」划界
纯个人偏好——回答语言、常用 shell、你喜欢的排版说明——用 Memory 减少摩擦，无可厚非。
但在团队里要克制，原因很现实：
同一件事，不同人的 Memory 可能悄悄矛盾； 交接、审计、CI 看不见 Memory； 「个人风格」容易变成隐性规范，损害标准化。
团队级 Harness 的目标，是不依赖某个具体的人也能把事做对。所以：偏好要么小到不影响契约，要么应写进团队共识（Rule、贡献指南、统一脚本入口），而不是留在私人记忆里。
10.4 个人工具与团队项目：Memory 何时作用大、何时尽量少用
个人项目、或 OpenClaw 等偏「一人一把工具」的形态（OpenClaw 可理解为个人向 AI 工具栈的一种代表，主战场在「顺手」而非团队仓库对齐），目标常常是「更顺手、更懂我」——Memory 性价比很高，省重复话、省摩擦。
多人、标准、要长期维护的工程，目标是可交接、可审计、可对齐——主干必须是仓库里的资产 + 门禁。Memory 顶多是润滑剂，不能当规范源。
这不是否定 Memory 这种能力，而是分清主场：团队 Harness 的主场在 SPEC / Rule / Skill / Scripts / dev-map / 任务看板 / 流程与契约。
10.5 实践上可以多问自己的几句话
这是「个人习惯」还是「团队要对齐」？后者 → 进仓库。
错题有没有可执行判定？有 → Scripts；只能先文字约束 → Rule，并争取以后脚本化。
成功/失败样例能不能变成测试或样例数据？能 → 别只存在聊天记录里。
solo 时可以用 Memory 提速；合并进团队流程前，把该沉淀的沉淀掉。
写到这里，其实已经能看到一个很清晰的演进过程了。
一开始，我们只是希望 AI 能帮我们完成一个小任务。 后来，我们希望它能稳定地完成一个完整需求。 再后来，我们希望它不是一次性地帮我们写代码，而是能参与项目的持续维护。
随着目标越来越大，Harness 的作用也越来越明显。
11.1 在这个过程中，人到底在做什么
很多人会误以为，Harness 搭起来以后，人是不是就退场了。
恰恰相反。 Harness 越强，人越重要。
只是人的职责发生了变化。
以前，人更多是在直接写代码、直接改需求、直接盯每一个细节。 现在，人更像是在做下面几件事：
定义项目目标和边界 | 设计流程 | 制定规则 |
设计脚本门禁 | 审视流程哪里有漏洞 | 在流程卡住时做最终判断 |
也就是说，人从“执行者”逐步上移成了“系统设计者”和“最后责任人”。
11.2 今后人和 AI 应该是什么关系
我现在越来越不认同一种说法： “AI 是你的助手。”
这个说法太轻了，也太不准确。
在复杂工程里，AI 不是助手，AI 更像是一支执行力极强但必须被制度化管理的团队。 你不能指望它天生懂规矩，也不能指望它自己长出流程意识。 你要给它边界、给它分工、给它门禁、给它反馈闭环。
所以未来人和 AI 更合理的关系，我觉得是：
人负责设计系统
AI 负责在系统里高强度执行
人对最终结果负责
11.3 后续怎样做更专业的 Harness Engineering
如果继续往前走，我认为还有几个方向特别值得做。
第一，更多规则继续脚本化
只要是能判定的，就尽量不要停留在 Rule 层，而应该下沉成脚本。 因为只要还是自然语言，就永远存在解释空间。
而且这件事背后还有一个更长远的方向：让反馈闭环越来越完整。 我们现在的事后验证，已经能在很多静态规则、编译、测试层面给出明确判断；但这还不是终点。后面我们持续在探索的，是把这一层再往前推进：
自动编译 | 自动调试 |
自动模拟用户行为 | 自动感知关键路径是否真的跑通 |
如果这些能力继续补齐，Harness 的反馈回路就会从“你写完以后我来扫一遍”，升级成“你写完以后，系统能尽可能接近真实使用场景地验证这次结果到底对不对”。 那时候它就不再只是一个开发约束系统，而更像一个真正有自我校验能力的工程执行系统。
但如果要再往前走一步，真正把这个反馈闭环从“开发完成”延伸到“可交付、可发布、可回滚”，光靠本地脚本其实还不够，这时候 MCP 的价值就会真正体现出来。
因为完整的工程闭环通常至少还包含下面这些环节：
1 构建闭环 AI 改完代码后，不只是本地编译，而是能发起标准 CI 构建，拿到统一环境下的构建结果。 | 2 签名闭环 对于桌面端、安装包、更新包这类产物，很多时候必须经过签名服务或企业证书流程。这个环节通常不适合直接硬编码进本地脚本，而更适合通过 MCP 去调用一个受控的签名能力。 |
3 制品闭环 构建通过以后，要把产物上传到制品库、共享盘、下载源或更新平台。只有产物真正进入可分发的位置，交付才算往前走了一步。 | 4 发布闭环 再往后可能还包括调用发布平台、创建发布单、推进灰度、记录版本状态、回写发布结果。 |
5 结果回写闭环 最后要把这些外部系统里的状态，再回写到任务文档、发布文档、任务看板里，让 Harness 知道这次不仅“代码对了”，而且“工程交付动作也真正完成了”。 |
这一整串动作，如果全部让 AI 直接自由发挥，其实风险很高；但如果这些外部系统都能通过 MCP 提供受控、结构化、可审计的能力接口，那么 AI 就能在明确边界里完成：
发起构建 | 读取日志 | 调用签名 |
上传制品 | 推进发布 | 回写结果 |
这时候，你的 Harness 就不再只是一个“开发过程管控系统”，而会开始长成一个真正意义上的工程执行闭环系统。
第二，把流程进一步产品化
现在我们的 Workflow 已经有了流程定义文件和契约，后面完全可以继续往更强的状态机、更强的自动校验上发展。 这时候再考虑 LangGraph 这类流程 / 状态图编排框架，就会更顺手，因为你的流程已经先被整理清楚了。
而如果未来 MCP 这一层也补上，流程产品化就不只是“文档阶段怎么走”，还会进一步升级成“每个阶段对哪些外部系统有权操作、操作成功以后如何自动推进下一步”。 这其实就是很多团队最终想做但一开始做不到的事情：让 AI 不只是懂研发流程，还能在受控前提下参与真实工程交付。
第三，做项目类型模板
不同项目的 Harness 形态会不同。 WPF 工程、Unity 工程、后端服务、工具脚本仓库，它们需要的门禁和工作流一定不一样。 但你完全可以沉淀出每类项目的“最小可用 Harness 模板”。
第四，把“知识”沉淀进项目，而不是沉淀进人
这也是我一直特别强调的一点。 真正专业的 Harness，不应该越来越像“我和我的 AI 的默契”，而应该越来越像“任何一个人拿到这个工程，都能顺着这套系统做对事情”。
这才是工程化。