执行者验收测试

如何验证一整套 SOP 是否真的可执行——owner 的方法：

生成一个干净上下文的 agent。只给它两样东西：（1）产品文档，（2）SOP 语料库——不给别的，不联网。让它端到端地规划并模拟整个操作，遵守一条硬规则：每一步行动都必须引用其依据（文件 + 步骤）。语料库没有对某一步给出规定时，它不得自行发挥——而要记录一个结构化的缺口（{需要什么、在哪里找过、为什么没找到、严重度：阻塞/降级/表面}），并在一个明确标注的假设下继续。然后审查：核实这些引用是否属实，并把缺口清单当作缺陷清单。

为什么有效：

• 语料库是被测系统，agent 是测试用的 harness。 干净的上下文无法像作者本人那样用对话记忆把漏洞糊过去——它只读写下来的东西，而这恰好就是未来的执行者（人或 agent）所能拥有的一切。
• "引用或缺口"这条规则强制区分"语料库决定了这个"和"我决定了这个"——后一类一旦被明确标出，就是理论与实践之间的差距。
• 严重度分级为填补工作定出优先级：阻塞缺口是缺失的装配（把活干了）、降级缺口是缺失的规则（去找经过检验的理论/案例/规范——绝不臆造）、表面缺口是可以容忍的假设。
• 填补的纪律呼应了语料库自身的取材法则：缺口要用成熟理论、有文献记载的案例、或经受住检验的规范去填——缺口不是编造的许可证。

第一轮（2026-07-16，StandMeet × 认知度相关的 SOP）：执行者完成了一份引用齐全的 30 天计划，并报告了 9 个缺口——1 个阻塞（测试产品还没有对应的按项目分发的渠道工具包）、6 个降级（没有工时预算规则、没有场域排序的触发条件、没有发布前的类型划分、没有漏斗前测量、一张承诺过却没写出来的匹配表、某份 SOP 里缺了一个画像步骤）、2 个表面——外加一条结构性的观察（决策层里没有留出主张与场域共振的位置）。当天就用经过检验的来源填补了全部 6 个降级缺口（排序用 Bullseye/《Traction》；其余用语料库自身发布前的先例）；阻塞缺口属于按项目装配的工作。

第二轮（2026-07-16，FlexMesh × 已经加厚过的语料库）：与应用之间的距离，被量出了数。 在补完一整轮理论（矩阵、上下文清单、参与度旋钮、被看见的阶梯、视频流水线）之后，执行者给出的结论明显更好：理论层执行得干净，并且引用到了真实的步骤——匹配表、操作顺序、参与度旋钮、人力+见效时间表、Bullseye，以及上下文清单的汇编，全都确定性地跑通了；集中/试探的划分自然浮现，没有臆造。剩下的缺口主要是 (a) 按项目的装配，而不是 (b) 理论上的空洞：DemoForge 的 9:16 构建、尚未组装的 FlexMesh 语料和产品事实包、两件还没造出来的工具（逐帖日志、赢家扫描），以及门店控制台/归因的接线——全是 owner 的工作，不是语料库的工作。恰好只浮现出一个真正的规则缺口：Reddit/人设那套教条假设了 founder ∈ users，却没有给出创始人不属于用户群体时该怎么办的流程——当天就用有文献记载的规范和案例填上了（outsider-founder-earns-voice）。第二轮把这条区分磨得更清楚了：理论已经接近可用；剩下的距离是按项目的装配——这个测试正确地拒绝让语料库在这一点上蒙混过关。

Kin：industrialization-needs-a-mechanical-arbiter（这个测试把"这套 SOP 完整吗？"从主观判断变成了机械化的裁定）· vault 的 pre-commit lint（在笔记这个层级上是同一种哲学）· trust-follows-provenance（两者都拒绝把"表述流畅的断言"当证据：靠从源头重新推导来验证，而不是靠一句说得顺的话）。