如果你尚未阅读卷一、卷二和卷三，这里先统一一下基准。卷一重点阐述了意图、成果及验收标准；卷二聚焦于技术图谱，帮你明确“改哪里、影响谁”；卷三则围绕任务单、书面签收以及合并前的自动检查展开，核心解决的是“敢不敢合”的问题。而本卷（卷四）将讨论合并完成之后的事项——一个完整专题如何从清晰的任务单撰写一路走到关账归档，并避免反复翻阅冗长的协作记录。

一句话概括核心：关账编译摘要的目的是让你在跨任务回顾时能快速定位当时的决策节点，它并不替代技术图谱中“改哪里、影响谁”的职责——那依然是卷二的范畴。下文将通过一次虚构专题走通快乐路径（happy path），并演示一次契约检查拦住合并的主线失败场景（第17节）。第18节会说明关账后经验卡片、团队Skill和编译摘要如何分工，同时提供后端项目中的关账回顾对照数据（注意存在数字边界，不可外推）。

先对个标，下面三句话贯穿全文，不再赘述：协作流程（Harness）以任务单为核心，任务单是开工规格（验收、非范围、失败路径），并非与流程并列的第二套文书（paperwork）。敢合并 = 合并前自动检查全部通过 + 书面审查结论落盘——不是“在平台上点一下Approve就算交付”。一轮专题 = 具有边界的一包工程交付，而不是与模型无限次对话。

一轮专题交付：从SPEC到归档

一轮专题可以对应产品上的一个Epic，也可以对应仓库里的一条任务链（一个主任务单 + 若干关联子任务）。关键在于：意图、成果、验收需在任务单里明确写死；改哪条链路需在任务单里挂上图谱入口；结束标志是代码合并、任务单与审查记录可检索，以及可选的关账编译摘要。

各阶段的产出和回指关系，汇总如下：

以下情节完全匿名化，仅用来说明机制，不必与任何真实仓库一一对应。

背景：示例栈为Python后端API + Next.js BFF消费后端的流式聊天（SSE）。产品需要将统一聊天流中某个事件的字段名与必填项对齐，方便前端解析。

任务单（节选）：

节拍1～2：开工与实现

先由人员冻结任务单；Agent按图谱入口修改后端流式接口，调整某个SSE事件的字段名。实现者只改了代码，忘记同步契约/锚点清单（仓库里用清单文件声明“文档里写明的端点/事件/字段应与代码一致”——具体文件名因项目而异，这里只记住机制）。

节拍3：主失败分支——合并被契约检查拦住

推送PR后，契约/锚点检查变红（与单测workflow并列，不是替代关系）。流水线给出的信息大致如下：

❌ 合并被阻塞：契约/锚点与代码不一致位置：统一聊天 · SSE 事件 "chunk_done"文档声明：字段 message_id（必填）当前代码：字段 msg_id（必填）你可以：1. 若确属契约变更：在任务单写明变更 → 同PR更新契约/锚点与结构图 → 补测试；2. 若为误改：回滚相关代码；3. 本地运行与PR相同的检查命令，确认变绿后再push。

这就是大家常问的“图谱/契约CI”：不是玄学，而是机器对照“你承诺的对外形状”与“仓库里实际代码”。它管的是门牌号对不对，屋内逻辑后面再补。

路径A（本案例采用）：确认产品就是要改名 → 在任务单补充变更说明（Delta） → 同一PR内更新契约/锚点清单 +（若流程的边/调用关系变了）更新结构图 → 补/改SSE相关单测 → 检查变绿 → 审查签收 → 合并。

路径B（穿插一句）：若发现是Agent误改字段，回滚相关代码即可变绿——不必硬改文档去“凑”过检查。

注意：不要再开一个“只改文档”的PR等代码PR先合——这种双PR的做法很容易死锁。习惯应是原子提交：代码 + 契约/锚点/图 + 测试同PR一起走。如果PR推送后才发现漏改契约/锚点，直接在同一个PR上补推，不要另开一个。

节拍4～6：副分支、合并与关账

副分支只说一句：有时契约/锚点检查已绿，单测仍红——说明门牌号对了，屋内行为仍可能出错。这时要靠失败路径与pytest（卷五FAQ会再展开）。合并后：验收通过，任务单移入已归档任务目录；开工前审核与合并前签收的书面记录仍可查——并非合并完就散。业务代码合并不会自动变为关账编译摘要；摘要须在关账后按需生成（§18）。

关账不等于再跑一轮全自动“打回重做”（那是进阶调优话题，卷五再提）。关账首先是归档与可检索。

拒开工与驳回：任务单字段不齐（缺非范围、失败路径、合并前必绿条等）时，应在实现开始前书面指出并阻塞开工（卷三 §12.4有清单思路）。实现不合格应驳回并要求修代码或补测，而不是只改聊天结论。

合并后若仍需复盘，建议用五类根因归类（非强制录入数据库）：

• 规格漏项（任务单没写清的边界）
• 契约/锚点未与代码同步（本节主线）
• 失败路径未覆盖的测试
• 结构图与真实流程漂移
• 跨端假设错误（后端改了，前端仍按旧字段）

可以附一张失败路径表（卷三 §11.4），例如：

不建议把“15分钟必须响应”“全团队强制Feature Flag”写成本文标配——视基础设施而定。

更细的踩坑备忘，可在关账后整理进经验卡片或§18的编译摘要层；不必规定“每个新任务必须先检索failure库”。

闭环后：经验卡片与关账编译摘要

第17节讲的是怎么合并、怎么关账，这一节聚焦关账之后多出来的三层“沉淀”：哪些是可选备忘，哪些值得编译成摘要，以及它们与卷二技术图谱、经验卡片和团队Skill如何分工。

一句话总结：图谱管结构；任务单+签收管本轮真值（卷三）；摘要管跨轮决策蒸馏；Skill管怎么问、怎么测。

大家听到Wiki，常会想到Confluence、飞书文档里人工维护的产品百科。这里另有一类：LLM Wiki——由Agent增量编写并维护的Markdown知识库，原始资料只读，中间层页面由LLM交叉引用、持续整理，你主要提问与把关来源，不必亲手维护每一页。

这与PRD/需求文档（人写的产品规格）、技术图谱（改代码用的流程/契约/入口地图，卷二）、关账编译摘要（从已关账任务与审查材料编译出的Epic级决策页）都不同。

实践中常用下表来避免混用：

关账编译摘要不是PRD，也不等于整本LLM Wiki。摘要回答“这个Epic关账时工程上定了什么”；PRD回答“用户要什么”；LLM Wiki若采用，往往是更广的领域知识层（可收录摘要页，但不能代替任务单字段与合并前检查）。在后端项目中，关账摘要与部分Wiki页同属“可读沉淀层”。

借鉴Karpathy的LLM Wiki：为何用在关账回顾

关账回顾场景借鉴了Andrej Karpathy公开阐述的LLM Wiki思路（业内讨论度较高，可自行阅读原文）。与“把文件丢进向量库、每次问答现检索”不同，LLM Wiki主张：原始资料保持只读，由LLM持续维护一层可交叉引用的Wiki页面——知识编译进结构里并保持更新，而不是每问从碎片里重新拼凑。

为什么把它落在关账上？跑通Harness之后，任务单、审查记录、对话导出会越积越多。半年后再问“这个Epic当时定了什么、踩过什么坑”，如果每次让Agent整包读取全部分支留痕，上下文成本高、噪声大，回答还容易漂移（本轮临时拼出的片段，与当时书面签收不一定一致）。关账编译摘要就是在这一思路上，把已关账材料蒸馏成少量synthesis页，专门服务跨会话回顾——属于初步缓解“文档越来越多、回顾越来越难”的方案，不是一劳永逸的知识管理产品。

为什么不把传统RAG当主方案？（针对本项目协作留痕，不是否定RAG的全部用途）

线上ChatBI/用户问答仍可用各自的RAG栈；本卷只讨论工程关账后的可读沉淀。与技术图谱、Harness签收的分工仍见上表——摘要/Wiki层不替代“改哪里”的地图，也不替代“敢不敢合”的CI与书面落盘。

协作一旦走Harness，过程留痕自然会变长。关账半年后，如果仍只靠完整读取原文做回顾，成本高、噪声大，还容易漏跨任务的模式（例如“这类改动必须过契约/锚点检查”）。一个更好的习惯是：关账回顾时，先看摘要索引 → 打开单篇synthesis摘要 → 必要时再回链原始task/review。

合并业务代码 ≠ 自动生成摘要。关账归档之后，是否编译ingest摘要（或写入LLM Wiki的某一类页面），仍按团队纪律按需触发——不是push到main就立刻多出一页知识库。

数字边界

以下数字来自单一后端示例仓做的关账回顾对照实验（2026-05），不是线上用户流量，也不等于模型API的token账单。实验用事先声明的gold题集：六类代表性关账场景（如Harness文档试点、图谱闸口、流式探针、契约/锚点检查CI、LLM Wiki层元实验、Harness与Wiki层闭环主任务单等），每类四题。

两组对比（同一套题，只改Agent先读什么；A为基准，B在A上叠摘要）：

能写什么结论

在同一题集下，B组相对A组，喂给模型的字符量大约还能再少六成到七成多（六类场景聚合约61%–77%）。六类里五类四题全中；一类只中了三题——因为该Epic的编译摘要漏写了测试策略字段，有一道题Agent无法从摘要里还原“必须自动化”的约束。

诚实边界（不可外推）

没写进摘要的运行时细节与生产配置，不能当事实用——仍以代码与合并前检查为准。前端Next/BFF与双仓协作须另行验证，不能靠这一后端实验代替。线上RAG/ChatBI排障效果等实现级指标，本实验未覆盖。

失败样本（必写）

某Harness与Wiki层闭环主任务单在B组（叠摘要）下3/4：根因是编译时未把主任务单上的测试策略枚举蒸馏进摘要，不是模型“突然变笨”。这提醒一个要点：摘要省字与摘要写全要一起管——关账ingest纪律和任务单字段一样，漏一项就会在回顾题上露馅。

摘要索引建议放在团队约定的归档目录（例如docs/archive/或synthesis/路径），与仍活跃的任务单目录分开，避免Agent把“已关账Epic”当成当前开工材料。

签收仍然不可省：摘要再全，也不能代替卷三的非范围、失败路径、合并前必绿。

曾经把“编译摘要”当成“合并后自动出现”——实际关账归档后还要按需触发编译，否则回顾时只有冗长原文。此类备忘适合写在经验卡片（一两段），不必写进每份摘要正文。

与「只会Prompt」的工具链如何叠加

不少朋友会问：我已经有Cursor Rules、Copilot指令和各种Prompt大全了，还需要学图谱和Harness吗？

答案是：要叠，但不是重复。Prompt管这一轮对话怎么说；本系列管改哪、敢不敢合、关账后怎么少忘——三件事Rules很难单独承担。

不是买了Cursor Pro就不用画地图；也不是多贴十条System Prompt就等于Harness。

卷一 §0 提过：在Auto/换模型时，单条Prompt容易漂移。更可靠的路径是流程 + 机器验收 + 高敏书面复检：任务单字段不随模型变而消失；合并前检查仍须全部通过；动对外API、流式协议时，仍建议独立复检（卷三 §12.5）。

如果团队想换模型前自检，可以自行列几条定性问题 + 可选的小场景自测表（卷五将提供可复制模板）——结果仅供内部讨论，不作PR合并条件，也不设“模型成功率KPI”。那是纪律辅助，不是新的闸门。

如果你已有Prompt库，想最小成本叠上本系列，建议的顺序是：

• 保留卷一 §6 任务单骨架（验收、非范围、失败路径、合并前必绿），明天就能用。
• 选一条链路画最小地图（卷二 §8.2–8.3），任务单写图谱入口。
• 关账后可选：写一张经验卡片；同类任务重复两次再沉淀团队Skill；Epic结束再考虑编译摘要。

范例栈是后端API + 可选Next/BFF双仓组合，不是“一个React单体教程”——全栈读者请按自己的仓拆成契约 + 分栈合并前命令（卷一 §6 分栈）。

结语

卷四把卷一～三收束成一条可执行的关账故事：

图谱回答改哪里；Harness回答敢不敢合；关账编译摘要回答跨Epic怎么回顾——三者都不替代彼此。

如果你读卷三时对“冷层/温层/热层”仍有“是不是架构三层”的疑惑：卷三正文已发表；卷五将给出协作记忆分层（冷/温/热）与架构分层的对照表，届时请以卷五为准（协作记忆分层，不是架构/契约/实现）。

下一卷·卷五面向存量项目：一周量级如何试通一条链、常见误区、渐进路线；附册（术语、模板、延伸阅读）将随卷五连载发布；卷五 §26 计划链出Blocking三行模板与换模型定性自检等可复制附件。

新项目：从卷一 §6 起步。老项目：从卷五阶段0（手动门禁写进任务单）起步。