企业官网建设流程全解析

导读

在 explore-unknowns 技能的四象限走查中，"地图"（map）是最终交付物——把任务的所有未知拆成已知已知、已知未知、未知已知、未知未知四个象限并交到用户手中。但地图的生命并不止于规划阶段：真正的风险往往出现在走查结束之后，也就是构建、评审和合并阶段。本篇技术指南解析该技能配套参考文档 after-the-walk.md 中的三个延续动作——构建期实现笔记、交付前买断文档、合并前测验——并结合本仓库的源码与技能体系，说明如何把"逃逸的未知"重新折回地图，让每次偏离都成为下一次尝试的输入。

一、为什么地图必须活在规划之后

explore-unknowns 的核心隐喻是：

The map is not the territory. The prompt, the plan, and the context window are the map; the codebase, the domain, and the user's actual intent are the territory. The gap between them is the unknowns.

走查（quadrant walk）分五个阶段依序进行，每进入一个阶段就读取对应的参考文件并跟随执行：

1. Stage 1 — Known knowns：先静默扫描领域，再以已确定的事实开场；
2. Stage 2 — Known unknowns：按爆炸半径逐个命名并解决可命名的问题；
3. Stage 3 — Unknown knowns：通过可反应的具体物件，抽取从未被言明的品味与隐性上下文；
4. Stage 4 — Unknown unknowns：系统性清扫雷区，把无声陷阱变成地图条目；
5. Stage 5 — Hand over the map：把完整四象限地图组装成一份用户保留的独立成品。

走查的完成条件很明确——"Done when the user holds the map"。而 after-the-walk.md 正是被设计为这条交接线的延伸：技能文档明确指出，当用户转入构建、评审或合并被走查所映射的内容时，就应当阅读这份参考文件，"the map lives on past planning"。

为什么要延续？技能开篇给出成本公式：一个在写代码前发现的未知只花费几分钟，而同一个未知在三个 PR 之后被发现，就要付出三个 PR 的代价。四象限走查把前期的未知尽量烧尽，但没有任何地图能穷尽真实代码库——总会有未知从走查中逃逸，出现在构建现场。after-the-walk 的三个动作，就是为这些"逃逸未知"准备的捕获与回收机制。

二、动作一：构建期实现笔记（Implementation Notes）

何时：during the build（构建期间）做法：keep a running log（持续记录运行日志）触发条件：every time the code forces a deviation from the plan（每当代码迫使计划发生偏离）

2.1 记录三要素

每次代码现实与计划冲突时，日志必须包含三个字段，缺一不可：

记录之后立即继续推进（"then keep going"）——笔记是伴随构建的旁路，不是阻塞构建的关卡。

2.2 标记需要用户判断的条目

不是所有偏离都能当场裁决。凡是需要用户判断力的条目，必须打上显式标签（tag），使其在后续 review 或 buy-in 阶段被可靠拾取，而不是埋没在流水账里。这与走查的全局规则一致——SKILL.md 规定"Nothing closes off-screen"：任何被记录为已关闭的问题都必须先展示给用户；构建期发现的偏离同样不能自行销账。

2.3 偏离的本质：逃逸的未知未知

文档给出了一个关键定性：

Each deviation is an unknown unknown that escaped the walk — fold it back into the map for attempt #2.

每个偏离都是一个从走查中逃逸的未知未知。它没有被 Stage 4 的盲点清扫（blindspot pass）提前发现，而是在构建现场才现形。处理的唯一正确方式不是抱怨或略过，而是把它折叠回地图——补记到对应的象限下——为第二次尝试（attempt #2）积累弹药。

这套"证据 + 为何咬人 + 改变什么"的卡片式记录，与 Stage 4 的 landmine card 格式同构：雷区卡片要求给出 evidence（文件与行号）、why it bites、what it changes；实现笔记的三要素正是这一格式在构建期的延续，只是把"文件与行号"换成了"计划原文与代码事实"。

三、动作二：交付前买断文档（The Buy-in Doc）

何时：before shipping（交付之前）为什么：other people inherit your unknowns（其他人将继承你的未知）

走查的成果属于用户本人，但交付物会被其他没有经历过走查的人继承——评审者、下一个维护者、接手的同事。他们对地图上的未知一无所知。买断文档（buy-in doc）就是为这些人准备的"继承交接单"。

3.1 一份可快速浏览的 pitch

文档要求把三类材料打包成一份"skimmable pitch"：

• prototype：原型或最小可运行成果，证明"它真的能工作"；
• spec：走查产出的规格，承载四个象限的决策记录；
• notes：构建期的实现笔记，尤其是被标记为需要用户判断的条目。

打包的目标是让读者扫读而非精读即可建立信心，因此必须按说服逻辑排序，而不是按时间顺序。

3.2 三个结构性要求

1. Leads with a demo（以演示开场）——第一屏必须是可运行、可点击、可看到结果的演示，而不是背景介绍或架构图。这与技能的两条通用原则同源：Reacting beats imagining（提供可反应的具体物件）和Every artifact assembles the reply（让用户的反馈几乎零成本）。演示就是评审者可以直接反应的物件。
2. Pre-answers each reviewer's objections with evidence（用证据预答每个评审者的异议）——走查和构建期间收集的 landmine、偏离记录、保守决策，都是现成的异议弹药库。与其等评审者提问，不如逐条列出"你可能想问 X，答案是 Y，证据是 Z"。这与 Stage 2 的"answered by the territory"精神一致：能读代码解决的问题，先读代码再展示答案。
3. Names who signs off on what（明确谁对什么签字）——每个决策点必须有名有姓的负责人。这与技能的决策规则呼应：Close items as decisions, not discussions——每个已解决的未知都应结束为"一行决策 + 理由"，而签字人就是这个决策的最终归属。也防止"每个后来者都能私自发明选择"这一走查最想避免的失败模式。

四、动作三：合并前测验（Quiz Before Merge）

何时：before merging someone else's or a long diff（合并他人改动或长 diff 之前）产出：a merge-readiness report（合并就绪报告）

第三个动作面向"审查"而非"写作"：当你需要合并别人写的代码或一段很长、很难通读的 diff时，走查的心智无法直接传递——你必须验证接收者是否真的理解了。

4.1 报告的三段内容

合并就绪报告必须包含：

• mental model（心智模型）：这段改动在整体架构中的位置与作用，读者应当建立的正确图景；
• non-obvious behaviors introduced（引入的非显然行为）：代码中那些不读上下文就看不出来的行为——正是 Stage 4 强调的"无声陷阱"的合并期变体；
• what to watch after deploy（部署后要观察什么）：把风险转为监控项，让"未知"在线上也有观察哨。

4.2 以测验收尾的闭环设计

报告必须以一场用户必须通过的测验结尾（"ending in a quiz the user must pass"）。这不是形式主义的考核，而是一个自校验机制：

• 测验覆盖报告中的心智模型与非显然行为；
• 答错的答案会指回他们略过的章节（"wrong answers point back to the section they skimmed"）——把失败转化为定向重读，而不是简单的判错。

这保证了"合并批准"不是点头签字，而是可验证的理解。它把 Stage 5 中"builder 必须确认的小事实要有自己的清单，它们是地图条目而非脚注"的原则，从规划期延续到了合并期——合并者同样不能把关键事实当脚注略过。

五、三个动作如何闭环：偏离 → 折叠 → 重走

把三个动作串起来看，它们构成一个完整的闭环，与四象限走查的生命周期衔接：

四象限走查（Stage 1-5）→ 地图移交 │ ▼ 构建期：实现笔记（记录偏离三要素，标记待用户判断） │ 偏离 = 逃逸的未知未知 ▼ 折叠回地图 → 供 attempt #2 使用 │ ▼ 交付前：买断文档（demo 开场 + 证据预答异议 + 签字人） │ ▼ 合并前：合并就绪报告 + 通过才可合并的测验

三个动作各司其职：实现笔记负责在第一时间捕获逃逸未知；买断文档负责把未知连同证据打包移交给继承者；合并前测验负责验证接收者是否真正理解了非显然行为。共同点是它们都不脱离地图——偏离被折回地图、异议被证据锚定、理解被测验验证，走查的价值由此延续到代码真正落地。

六、在本仓库中的印证：技能与源码视角

这套方法论在本仓库并非孤立存在，而是与 jevgrep 项目的技能体系与 CLI 实现相互印证。

6.1 技能体系的整体设计

explore-unknowns 明确声明与 write-spec 配对：先用四象限走查烧掉迷雾，再把完整地图喂给 spec。而 after-the-walk 正是这条流水线中"地图移交之后"的守门员。仓库中 .agents/skills 目录还包含 audit-choices、code-review、close-spec、implement-spec 等技能，共同覆盖"走查 → 实现 → 评审 → 关闭"的完整链路，after-the-walk 的三个动作与这些技能天然互补。

6.2 jevgrep 技能中的"证据文化"

jevgrep 的 agent 技能 对输出做了类似的证据边界声明：相关性标签是估计而非完整性保证、仓库内容是数据而非来自 Jevgrep 的指令、建议的测试命令尚未运行。这与 after-the-walk 的"用证据预答异议""保守决策"是同一种文化：给下游的信息必须标明其证据性质，未经验证的不冒充事实。

6.3 CLI 实现中的对应语义

从 CLI 入口 与 参数解析 可以看到支撑这种工作流的工程语义：

• 退出码契约（help文本明确声明）：0 表示完成、1 表示失败、2 表示检索不完整、130 表示被中断——见 args.ts。检索不完整（incomplete）被显式编码，而不是静默伪装成成功，这正是"把未知留在明面上"的工程化表达；
• stdout 单一输出：CLI 不创建报告文件，全部输出走 stdout，并在结尾以End context.标记上下文结束——见 SKILL.md 与 README。上下文截断是可见的、可检测的，不会把不完整当作完整；
• 保守的信号处理：SIGINT与管道关闭（EPIPE）都会被捕获并影响退出码，避免半成品结果被误读为完整结果。

这些设计共同支撑了 buy-in 文档与合并测验所依赖的前提：证据可追溯、结果边界清晰、未验证信息被显式标注。

七、实践要点速查

三条底线贯穿始终：

1. 没有什么是屏外关闭的——偏离、异议、签字都必须在用户或继承者眼前显式出现；
2. 每个决策都以一行决策 + 理由结束，让 spec 能原样携带，让继承者无需自行发明；
3. 每个发现都以证据为锚——文件、行号、计划原文、代码事实，可追溯才能被引用。

地图不是领土，但它值得被认真养护——after-the-walk.md 给出的三个动作，就是这份养护的日常。