企业官网建设流程全解析

ljg-book 是一个面向"拆书"场景的 Agent 技能：在只给出书名、PDF、EPUB 或样章的情况下，让没读过原书的读者理解整本书讲了什么、各部分为什么写在一起、原有理解如何被事实与事件逐步改变。本文聚焦该技能的核心管控文件coverage-map.md（材料与检查记录模板），逐字段讲解它在材料边界、整书身份、认识线索、来源取舍与成品阅读检查上的设计要求，并结合 验证器、测试用例 与 评估体系 说明这份模板如何被脚本强制执行。读完本文，你将掌握这套"覆盖记录 + 结构验证 + 成品复读"三层质量闸门的完整工作机制，以及把任何一本陌生书籍做成高质量拆书笔记的实操流程。

覆盖记录是什么：拆书任务的后台合同，而不是正文提纲

coverage-map.md 开篇第一句就划定了它的身份："这是研究与核对记录，不是正文提纲。"它是一份后台（backstage）记录，供研究与检查使用，不照搬进正文。它的存在意义可以从 SKILL.md 的工作流路由中看清：

按 SKILL.md 的规定，"每次任务复制references/coverage-map.md记录材料、关系、取舍和复读结果；这份 coverage 供研究与检查使用，不照搬进正文。新任务使用版本 3；验证器继续读取旧记录"。也就是说，每拆一本书都要新建一份覆盖记录，它既是写作者的思考台账，也是验证器（validate_note）读取的机器可解析契约。

模板中有两条总原则值得反复强调：

1. 冒号前字段名由脚本读取，保留写法——字段名是验证器正则匹配的键，不能随意改名，例如- 材料等级：完整拆书中的"材料等级"就是validate_note.ts中lineField()函数要抓取的精确字段名。
2. 字段填写只能证明记录存在，不能证明解释正确或文章好读——这是整套体系的伦理底线：结构合规不等于语义合格。验证器Result类型中assessment_scope明确写着"结构与记录完整性；不证明来源准确、阅读连续或理解效果"，semantic_assessment恒为"not_performed"。

模板还要求"没有材料时如实写清，不以推测补齐经历"，这与 ReadingGuide.md 中的材料等级制度互为表里。

材料边界：先声明"能支持到什么"，再决定"能声称什么"

coverage-map.md 的第一大节"材料边界"包含五条必填字段，其核心思想是让证据的边界先于结论出现：

• 覆盖合同版本：3——当前合同为 3，验证器兼容 2 与 legacy；validate_note.ts中validMaterialGrades之外的未知版本（如"99"）会直接报错"不受支持"。
• 材料等级：{完整拆书 / 初拆 / 假设版}——三档递进的材料承诺，取值必须在这三个枚举值内，写成"大概读过"会被验证器拒绝。
• 主要材料：{实际读过的版本、路径或来源；全书阅读范围与未读部分}——必须如实记录"实际读过什么"。
• 能支持到：{可以解释哪些内容；不能支持哪些内容；若需补材料，记录结果}——与上一条共同构成sourceBoundaryFields，验证器要求"主要材料"与"能支持到"两项都必须填写。
• 材料能否支撑认识更新路径：{是 / 否}——这一条是 v3 合同新增的认识更新门：原有理解、压力与变化是否有依据。它必须明确写"是"或"否"，写"也许可以"会被拒绝；材料不足时，不允许把材料等级升级为"完整拆书"。

三档材料等级能声称的内容，在 ReadingGuide.md 中被严格限定：

验证器对这条门还有联动校验：if (!supported && complete) errors.push("完整拆书不能通过：材料不足以支撑认识更新路径")——即"材料能否支撑认识更新路径"写了"否"时，材料等级绝不允许是"完整拆书"。

全书怎样构成整体：六要素整书身份门

第二大节"全书怎样构成整体"要求把整书作为一个有机整体来回答，每个概念各记录一次，不要在不同栏里反复改写同一句总论。v3 合同要求完整拆书必须填齐以下六项（v3WholeBookFields）：

1. 这是什么类型或形态的书——先定位体裁：分析书、历史书、传记、文学、哲学还是技术书。后续"按书的性质选择变化"（见 ReadingGuide.md 的表格）都以此为前提。
2. 起点、主要变化与终点——记录具体对象或人物、重要过程、结尾与未决部分。
3. 核心理解——最初怎样理解；什么内容迫使补充或改变；修订后怎样看。这是"认识更新路径"在整书层面的落点。
4. 各部分怎样相连——不可省主线及各自作用；依赖、分工、因果、对照或限制；不能只写共同主题。
5. 作者最想纠正或保留什么——从原书取舍与发展推知并给出依据，不虚构作者心理。
6. 正文必须出现的整书锚点——正文选用、具有材料依据的具体短语；完整拆书至少 3 个，部分拆书至少 1 个，用｜分隔；不以增加数量证明完整。

验证器对"整书锚点"有一组精密的强制检查：锚点必须是能唯一指向这本书的具体短语——genericWholeBookAnchors集合里的"问题、关系、变化、结果、理解、判断、结论、主题、作者、本书、读者、证据、边界、方法、概念"被判定为"过于通用"直接报错；同时每个锚点都必须真实出现在成品正文中（missingWholeBookAnchors检查），声明了却不出现同样报错。测试用例rejects generic or absent whole-book anchors专门验证了这两条路径。

这背后的设计意图从 SKILL.md 可以读出：分析书要讲清方法的分工与组合；历史、文学和传记可以通过条件变化、关系与无法消除的矛盾构成整体，"不强凑统一公式"。coverage-map.md 也明确允许"多线作品按实际内容说明，允许并列、对照或无法统一的矛盾"。

正文沿哪些线索展开：一条 [thread] 认识线索的六段式

第三大节是 v3 合同的亮点——用[thread]（认识线索）取代旧版零散的场景字段，每行记录一个持续展开的问题、人物、关系或模型。格式为：

- [thread] 名称：｜起点：｜关键推进：｜前后变化：｜换场理由：｜依据与边界：

六段字段在v3ThreadFields中被完整校验，缺一不可：

• 名称——线索的标识，必须出现在成品正文中（threadMissingInBody检查）。
• 起点——读者能理解的初始处境，让"原来的判断先有成立的理由"（SKILL.md）。
• 关键推进——这条线索经历了哪些阶段、承担了哪些不同作用。
• 前后变化——写出原来和后来的实际判断、条件或含义；"无行动结果时不要编造"。
• 换场理由——换对象确有必要的说明：带来必要的新范围、对照或独立主线，并承接尚未解决的关切。
• 依据与边界——原书事实与自拟情景在此分清；没有依据的 thread 行应删除。

模板特别说明："一个线索可以经过多个阶段、承担不同作用；不为每个概念另建一个例子。"这对应 ReadingGuide.md 的"让例子发展，而不只替结论作证"：同一个对象可以先让人形成自然判断，再暴露条件、承受反对、改变主张。完整拆书要求至少 1 条 thread，且六字段必须全部填完；在v3Coverage测试夹具中可以看到一个符合规范的示例："[thread] 名称：四句话｜起点：点头｜关键推进：查前提｜前后变化：等待证据｜换场理由：前提仍待证｜依据与边界：source:1-90"。

共同解释与图表：全书生成器的诚实性检查

第四大节处理两个相互关联的判定：

• 是否存在全书生成器：{是 / 否}——必须明确写是或否并说明理由。所谓"全书生成器"，是指确实能解释多处转折的同一种关系。声明"是"时，必须接着回答三个深化字段：生成器怎样贯穿至少两个远距转折；生成器在哪些条件、范围或层级失效（前提、反例或不能回答的问题）；以及它的具体作用机制。
• 是否需要视觉表示：{是 / 否}——必须明确写是或否，并说明为什么文字足够或不够。声明"是"时，必须逐一记录"使用图表的位置与目的"：所表示的关系、图后解释与具体运行；同时成品正文必须真的出现至少一个 ASCII 图块或表格（exampleBlocks + tableBlocks计数检查），且每个图/表宽度不超过 80 显示列（displayWidth()按全角字符计 2 列）。

这两条门的核心是诚实性：没有共同解释就如实保留多种关系，不要把若干方法压成一句口号；图表必须"解决具体理解困难"，图后要紧接着用眼前内容解释怎样读它。验证器 validate_note.ts 中的generatorGatePresent、representationRequired检查，以及测试用例requires an elected visual without treating carrier presence as semantic proof，都在防止"声明需要图表但正文没有图""有图但没说清用途"两种偷懒。

来源与取舍：四类全书证据与候选部件

第五大节是完整拆书最重的部分。完整拆书必须保留四类来源证据，各自标明位置与证据：

• [starting-point] 位置：｜证据：——原来的问题如何建立。
• [pressure] 位置：｜证据：——什么使原来理解不够。
• [revision] 位置：｜证据：——增加了哪些关系或条件。
• [boundary] 位置：｜证据：——最后形成了什么、还有什么无法解决。

验证器要求：声明的证据行必须写明位置（"已声明的来源证据必须写明位置；材料不支持的证据行应删除"）；完整拆书必须四类证据齐全，缺一类即报错（coverageZones !== zones.length）。

紧随其后是候选部件（candidate）记录，完整拆书需要至少 5 项：

- [candidate] 名称：｜位置：｜解决的问题：｜与其他部件的关系：｜决定：｜删除测试：

"决定"只能取保留 / 合并 / 删除三值之一。每个候选都要写"删除测试"——删除它之后，它承担的必要解释是否丢失。模板特别提醒："候选可以是方法、事件、关系或主线，不等于正文需要相同数量的场景。删去一个例子，仍要确认它承担的必要解释没有丢失。"这也呼应 ReadingGuide.md 的取舍原则：完整性由读者是否理解全书来检验，"不靠人名、章节名或例子数证明"。

本节的收尾是反证与取舍：{当前解释会遗漏什么，竞争解释或边界是什么，怎样处理；全书有何重要内容未展开及理由}。这条强制写作者面对"竞争解释"，而不是只给一个顺滑的故事。

成品阅读检查：评估者只读成品，不看后台

第六大节"成品阅读检查"规定了覆盖记录的最后四个字段，它们全部围绕成品限定阅读展开。评估者只读最终正文，不看 coverage、原书、写作者分析或预期答案（见 SKILL.md"只读成品，找出理解在哪里中断"）：

• 整书复述与关系重建——记录具体阅读位置和结果，不只写 PASS。评估者先以日常话复述"这是什么书；主要对象、起点、变化与终点；不可省的主线怎样相连；哪些得到解释、哪些仍然未知"，再为这些认识指出正文中实际展开的解释与变化；"摘抄概况段、主题词或末句总结，不足以证明理解成立"。
• 阅读断点与修订——沿实际阅读顺序找断点：哪里缺了关系、过早换对象或引入名称、或退到书籍简介与写作说明；切换的实质必要性；哪两段显示实际理解变化；怎样修订及复读结果。未发现时也要记录依据。
• 遮住末节后能否理解作者关切——正文哪些发展已使关切可见；有没有靠末节补进新道理或重复收束。
• 正文中哪两个相隔较远的转折共同托住它——这是末节精神内核的证据化：必须指出两处相隔较远的转折及其共同作用，"不另写一份精神内核"。

这四个字段在 v3 中由v3ReviewFields校验，完整拆书必须全部填齐。阅读断点的四个问题在 SKILL.md 中有详细展开，其中"原来的判断为什么可信，压力来自哪里，改变后的判断具体是什么"要求能指出前后对应，而非只找到'认识改变'一句话——这正是 coverage-map.md 第三大节"前后变化"的延伸。

验证器如何执行这份合同：validate_note.ts 结构校验全解析

validate_note.ts 是这份模板的机器执行端，用 Bun 运行，同时支持 Org 与 Markdown 两种成品格式。运行方式见 SKILL.md 的 Completion 部分：

bun skills/ljg-book/scripts/validate_note.ts /absolute/path/to/note.org \ --coverage /absolute/path/to/coverage-map.md

也支持 stdin 模式：bun scripts/validate_note.ts --stdin <denote-filename> --coverage <coverage-map.md>。退出码 0 表示ok，非 0 表示存在 error。

它对成品正文的检查要点（每一条都有对应测试用例）：

1. 文件头完整性：Org 必须含#+TITLE / #+SUBTITLE / #+DESCRIPTION / #+DATE / #+FILETAGS / #+IDENTIFIER六项，Markdown 对应title / subtitle / description / date / tags / identifier；IDENTIFIER必须与文件名中的 Denote 时间戳一致（{YYYYMMDDTHHMMSS}--前缀）。
2. 末节约束：成品最后一个一级标题必须是"读完后留下什么"，只能出现一次、只能写一个自然段、不能写成分类清单或子标题（essenceFormatLineHits检查）。
3. 禁入内容：正文不能暴露 x/R/f/E 分析标签、不能出现独立"资料校准"章节、不能出现"材料等级"字样、不能含"本轮核验/补写/不替"等后台核验语言（backstageAccountingPatterns）。
4. 篇幅记录：记录段落字数与句长（>220 字段落、>90 字句子会统计在checks中），但只记录不评判——测试明确"records paragraph and sentence lengths without inferring overload"。
5. 图表约束：ASCII 图与表格宽度均不得超过 80 显示列（全角按 2 列计），代码块内被引用的表格不计为实际表格。

它对覆盖记录（coverage）的检查按合同版本分派：

• v3 合同（当前）：校验材料等级枚举、材料边界两项、认识更新门是/否；完整拆书必须填齐六要素整书身份、至少 3 个非通用锚点（且全部出现在正文）、至少 1 条完整 thread（名称出现在正文）、四类来源证据、至少 5 个候选部件（决定为保留/合并/删除）、四项成品阅读检查字段；声明"存在全书生成器"必须补三个生成器字段；声明"需要视觉表示"必须补图表用途且正文确有图表。初拆/假设版只要求材料能支持的字段，锚点至少 1 个。
• v2 与 legacy 合同：可继续被读取，但会给出迁移警告（"下次重跑时请改用认识更新门"）；v2 额外校验[frontstage]前台载体（名称、唯一职责、设置或起点、结果或后果、改变的关系、下一问，职责不得重复）；legacy 则读取旧版"读者运行门/现场化门"字段。

测试文件 validate_note.test.ts 用 40 余个用例把上述每条规则固化成回归测试，例如：requires the essence section to be last and rejects category lists、rejects identifier mismatch and missing coverage、rejects visible backstage fields and missing description、rejects an over-wide ASCII diagram。其中live coverage template contract用例直接读取真实的coverage-map.md模板填值验证，确保模板与验证器永远同步。

合同版本与向后兼容：3 为主、2 与 legacy 可读

coverage-map.md 目前声明"覆盖合同版本：3"。验证器的版本分派逻辑（coverageContractVersion）允许"2"、"3"与"legacy"：未知版本报"不受支持"，legacy 既支持显式声明也支持不声明版本。三版差异的本质是质检重心的迁移：

• legacy 版检查"读者运行门"（读者先问什么、最小模型、第一次猜什么、最小动作、立即结果、再运行、复述、来源边界）与"现场化门"（镜头站在哪里、先看见什么、自然判断、可见结果、打断它的证据、命名后重跑）。
• v2 引入"整书身份门"与"前台载体门"，并要求明确"是否存在全书生成器"与"是否需要视觉表示"。
• v3 统一为"认识更新门"：整书身份六要素 +[thread]认识线索 + 来源证据/候选部件 + 成品阅读检查四字段，彻底移除旧版零散场景字段，让记录直接服务于"原有理解怎样被证据改变"这条主线。

从 evals 的说明可以看到版本演进的动因："执行者只收到 prompt、材料和当前技能，不收到 material_fixture、expected_output 或 assertions；评估者只收到最终正文。来源核对另做。"即评估要防的是模板里的预期答案被当成测试结果。

评估体系：从生成到评阅的双重防线

仓库把"生成质量的验证"拆成两道互不替代的防线：

1. validate_note.test.ts + validate_note.ts：机器可判的结构与记录完整性检查。ok只表示所检查的结构与记录合格（SKILL.md Completion 明确："ok 仅表示所检查的结构与记录合格"）。
2. evals/evals.json：7 个普通请求评估用例，覆盖完整论证方法书、旧解读笔记（《鳗鱼的旅行》）、多地区历史书、完整文学作品、技术书、材料不足（只有书名、目录与短样章）、无法统一立场的多线作品七种材料形态。每种都要求"按实际材料形成来源有界、全书关系可理解、关键线索持续展开的Org及coverage；不预设正文对象、标题或最终结论"。材料不足用例（id 6）专门检验是否守住范围："明确初拆或假设范围，不靠领域知识补成全书情节或论证，记录无法判断的部分，不虚构完整认识变化"。
3. evals/reading-pair.json：真实两稿的匿名比较入口。把两份同书解读正文交给评估者，隐藏产生次序与反馈、调换呈现顺序，要求先独立指出断点与关系再作比较。其 provenance 字段诚实交代："首轮成品曾被实际读者指出阅读破碎"——这正是 coverage-map 与成品阅读检查要拦截的那类缺陷。它的定位也写得很克制："比较真实成品的阅读连续性，独立于文件结构校验；不能作为生成效果的证明"。

仓库中还保留了这两份评估用成品：20000101T000001--reading-a__book.org与20000101T000002--reading-b__book.org，均为对《论证是一门学问：如何让你的观点有说服力》的完整拆书样例。它们展示了合格成品的样子：以"学生交流计划/游泳池建议"为持续线索，先让原有理解成立，再逐层展开前提、证据、反对意见与方案比较，最后以"读完后留下什么"一个自然段收束——注意它们的#+TITLE / #+SUBTITLE / #+DESCRIPTION / #+DATE / #+FILETAGS / #+IDENTIFIER六项文件头全部齐备，IDENTIFIER与文件名时间戳完全一致。

模板与成品的分工：coverage-map、template.org、SKILL.md、ReadingGuide.md 各司其职

四个文档共同构成 ljg-book 的完整规范，理解它们的分工是正确使用覆盖记录的前提：

• SKILL.md：技能主文件，定义触发条件、工作流路由、正文写作原则（让一个念头有机会走完、Gotchas）、成品阅读检查、末节约定与 Completion 检查清单（含验证命令与 Emacs Denote 回读要求）。
• ReadingGuide.md：方法论细则——材料等级表、四类来源证据、按书性质选择变化（分析/技术/历史/传记/文学哲学各自的展开过程与保留边界）、概念与图表何时出现、复读与来源核对分开、维护 skill 时的检验方式。
• references/template.org：成品 Org 的骨架模板，含六项文件头占位与三个一级标题结构（读者正在面对的具体处境或问题 → 原来的问题遇到什么变化 → 读完后留下什么），要求"删除本注释与所有占位提示；不要把每个段落扩成固定流程"。
• references/coverage-map.md：本篇主角——每次任务复制填写的后台覆盖记录，是验证器读取的合同本体。

在 SKILL.md 的 Completion 中，还有一条容易被忽略的硬性要求：用真实 Emacs 回读成品——denote-retrieve-filename-identifier与文件名一致、denote-file-has-denoted-filename-p为真、文件出现在denote-directory-files与 consult-notes 中、实际运行org-lint，并且"不可用时明确延期，不能把未执行写成通过"。这与 coverage-map.md 的诚实原则完全同构：记录存在与工作完成是两回事。

实战工作流：用覆盖记录拆完一本陌生书

综合上述规范，一次完整拆书的标准链路可以概括为六步：

1. 确认材料边界：按输入类型（书名 / 全文 / 样章 / 旧笔记）选定材料等级（完整拆书/初拆/假设版），复制 coverage-map.md 并声明"覆盖合同版本：3"，如实填写"主要材料"与"能支持到"。
2. 建立整书身份：回答六要素（类型形态、起点变化终点、核心理解、各部分相连、作者纠正保留、整书锚点），锚点用｜分隔，完整拆书不少于 3 个、且必须是能唯一指向这本书的具体短语。
3. 铺设认识线索：为每条持续展开的问题/人物/关系填写[thread]六段式；明确是否存在全书生成器及其失效边界；按需声明视觉表示与图表用途。
4. 沉淀来源取舍：完整拆书记录四类来源证据（starting-point / pressure / revision / boundary）与至少 5 个候选部件（含"保留/合并/删除"决定与删除测试），再写反证与取舍。
5. 写作并做成品阅读检查：按 template.org 写 Org 成品（默认保存到~/Context/，文件名{YYYYMMDDTHHMMSS}--拆书-{书名}__book.org），然后模拟只读成品的评估者，填写整书复述、阅读断点、遮住末节测试、两个相隔转折四项检查。
6. 运行验证器并回读：执行bun skills/ljg-book/scripts/validate_note.ts <note> --coverage <coverage-map.md>，逐条读回 error 与 warning 并修复；再用真实 Emacs 按 Denote 流程回读成品，如实报告结果。

这套体系最值得借鉴的设计，是把"写作质量"拆成两层可独立把关的产物：后台覆盖记录负责逼着写作者把材料边界、关系取舍、认识变化和反证想清楚；成品限定阅读负责防止"结构合规却没人读得懂"。coverage-map.md 作为连接这两层的契约，既是人读的研究台账，也是机器读的校验合同——理解它的每个字段，就理解了 ljg-book 拆书质量管控的全部逻辑。