上一集让 OPC 的输出变得可见。现在能看到工具在做什么了——那工具做得对不对？这一集用 OPC 审 OPC 自己，然后发现工具链之间长出了一个意料之外的三层结构。
一个跑了 8 天的 Claude Code 会话停下来后，留下 400MB 的 JSONL 日志——8675 条条目，884 条消息，8 天累计消耗 6.4 亿词元。
里面埋着大量技术决策和调试故事，但没人会去翻 400MB 的日志。知识锁死在会话里，会话结束就散了。
这就是 Logex 要解决的问题。而讽刺的是——想清楚这个问题的头脑风暴会话，本身就因为上下文溢出丢失了部分讨论内容。
从 Session 到文章：810 行代码
Logex 的流水线出奇地小：810 行 TypeScript，五个阶段把会话变成文章——parse → chunk → prompt → prepare → extract。评分公式决定一个分块（chunk）值不值得提取：知识类别命中数、关键词密度、用户文本比例。269 个分块里 247 个过了阈值。
几个早期决策影响深远：
大语言模型自己在会话里写文章，不调外部 API。 会话里的大语言模型已经拥有完整上下文。另起一个 API 调用要传 400MB 日志，贵且上下文不完整——外部摘要器会丢掉凌晨两点一个调试决策和六小时后一次重构之间的关联。
GitHub repo 当存储，不用数据库。 只有一个用户——YAGNI（不提前构建不需要的东西）的极致落地。留了适配器（adapter）接口但不提前实现。
自我指涉：你正在读的这个系列，就是 Logex 的产物。 S2 所有素材都来自 logex-data 仓库。
用 OPC 审 OPC：核心承诺从未被测试
Logex 能把会话变成文章。但这个能力引出了一个更尖锐的问题：OPC 自己经得起审吗？用 OPC 的全栈模板对自己做一次完整审查——14 个节点，从 discuss 到 post-launch-sim。
3 小时后流程跑完了。所有门禁一次 PASS。
FAIL/ITERATE 回环一次都没触发。 maxLoopsPerEdge=3 的限制从未被考验。
这个发现需要正面面对。
S1 到 S2，OPC 反复强调的核心价值主张是三条：做的人不评，评的人不做，不过不放行。前两条在每个 review 节点都有验证——审查者独立评判，这是真实发生的。但”不过不放行”这个最关键的强制机制？从 S2E01 的家庭日历到 S2E07 的 opc-viewer，八个产品，几十次门禁判定，回环机制没有被真正行使过一次。
一个从未被触发的强制机制，和一个不存在的强制机制，在生产环境里没有区别。
这不代表门禁没有价值——审查本身有价值，它让每个 commit 都经过了独立视角的检验。但门禁的”牙齿”——拦住不合格的代码、打回去重做——是一个未验证的承诺。可能的解释有几个：AI 审查者的标准太宽松（一致性偏差），测试覆盖的需求太简单（没有触及真正困难的边界），或者 OPC 的构建质量确实够高。我不知道是哪个。诚实的答案是：目前没有足够的数据来区分。
更糟的是，手动检查审查结果时发现了一个 bug。opc-harness synthesize 的裁决计算按 emoji 计数：🔴 = critical，🟡 = warning。但当审查者写的是”### 🔴 Must Fix: None.”——synthesize 扫到 🔴 emoji，判定为 critical 审查发现。整个裁决变成 FAIL。
这个 bug 的含义比它本身更严重：如果 PASS 的判定可能因为格式误判而本应是 FAIL，那之前所有门禁 PASS 是否也有误判——只是方向相反？ 机械门禁的失效模式不是大语言模型的那种（被语气锚定），而是解析器的那种（格式与内容错配）。S1E07 的结论是机械门禁优于大语言模型门禁。这一次的补充是：机械门禁有自己不同的失效模式。没有银弹。
还暴露了一个核心缺失：审查发现的处置追踪。 当前的流程：审查发现 → 门禁判定 FAIL → 回环到构建节点 → ???。没有机制追踪哪些审查发现被修复了、哪些被推迟、哪些是误判。重新审查时审查者每轮从零开始。这不是锦上添花——这是门禁回环能真正工作的前提条件。
Skill-Audit：给工具做体检
Logex 上线后，用 skill-audit（另一个自己写的工具）审计 Logex 自身。发现了事故现场：
Logex 的 skill.md 硬编码了 ~/Code/logex-data，但实际目录是 ~/Code/logex-projects/logex-data。每次跑 /logex 都会 git clone 出一份幽灵副本。功能正常——clone 出来的副本也能用——但多了一份不该存在的数据。
更深一层：本机 skill.md 是两代前的版本。源 repo 一周前已重构为 GitHub Contents API，本机还在讲 CLI flag 和本地 clone。
这是在给一具尸体洗脸。
四条教训：本机缓存落后两代而我不知道——审计不是检查清单，是认识自己的盲区。硬编码路径是漂移的温床。Commit ≠ push ≠ 发布——每一层都可能停在半路。审计工具本身要能承受审计。
三层套娃
回看全景，最有趣的不是任何单个产品，是三层工具互相使用的结构：
第一层：OPC 生成了 Logex。 产品论证流水线做可行性验证，OPC 循环做 UI 实现。
第二层：Logex 记录了 OPC 怎么跑。 本季所有 episode 的素材——从 S2E01 的家庭日历到这一集——都是 Logex 从 OPC 会话里提取的。
第三层：skill-audit 审计了 Logex。 发现了 skill.md 的两代漂移和幽灵副本。
没有人画过一张”工具链互相验证”的架构图。它是迭代中长出来的——一个人用 OPC 做产品，用 Logex 记录过程，用 skill-audit 检查质量。连接不是接口设计出来的，是使用频率磨出来的，就像田间小路从每天走同一条路线的人脚下踩出来一样。
工具生态从使用摩擦中长出来，不是设计出来的。 但隐式连接是定时炸弹——这种方式在单人场景下够用。如果要第二个人接手，这些磨出来的小路没有路标、没有地图、没有维护手册。
S2 回看：八个产品之后
带进来的假设，哪些活下来了
S1 结束时我带着三个核心假设进入 S2：
假设一：做的人不评自己，就能保证质量。 活下来了，但需要加星号。独立审查确实能捕捉到写代码的智能体看不到的问题——EP01 的 E2E 测试直接调真实 Claude 接口，就是审查智能体在代码审查轮次发现的。EP03 的怀疑者（skeptic-owner）提了”想象力的失败”，三个技术审查者全没看出来。角色分离是有效的。但角色分离只保证了”有人在看”，不保证”看到的人能拦住”——因为回环从未触发。
假设二：机械门禁优于大语言模型门禁。 依然成立，但边界更清晰了。Emoji 解析 bug 说明机械门禁有自己的失效模式——格式与内容错配。它不犯大语言模型的错误（被语气锚定、上下文污染），但犯解析器的错误。结论不是”机械门禁不好”，而是”机械门禁不是银弹——它把失效模式从不可预测变成了可调试。“能调试比不犯错更重要。
假设三：产品方向可以靠 AI 自动发现。 被推翻了。EP01 的日历网格是训练数据的默认选择，不是正确选择。做产品筛选时让 AI 去 Hacker News 挖痛点，25 轮下来花了 $147，发现 upvotes 测量的是共鸣不是付费意愿——共鸣 ≠ 需求。用 OPC 审查流程消化 575 条 flomo 笔记，96% 被丢弃——消化的核心动作不是加工，是丢弃。AI 能执行产品计划，但在本书观察的案例中不能自主生成产品方向；能辅助知识消化，不能替代判断。这个结论从第一集到最后一集都在被反复验证。
八个产品的模式
八集下来，每集有一个产品推边界，每个边界倒逼一次框架升级：
- EP01 家庭日历暴露了方向决策问题——AI 的默认选择需要人来校准
- EP02 第二个产品暴露了自主循环的停机问题——没有终止守卫的循环会空转烧钱
- EP03 所有审查者都说通过，加了第十人——角色分离是审查的免疫系统
- EP04 30 个开源项目提供了参照系——上帝文件三基因、插件困难三角
- EP05 每做一个新产品核心就胖一圈——能力合约和钩子解耦了框架
- EP06 三个审查者看不出颜色不对——Design Intelligence 让机器理解设计规范
- EP07 opc-viewer 让审查过程可见——看不到就不能信
- EP08 用 OPC 审 OPC，发现核心承诺未被测试——强制机制需要被行使才有意义
回头看，这八集不是线性推进，而是一条螺旋。EP01-02 用机器做产品，发现方向决策和停机问题。EP03 给审查加了第十人角色。EP04 停下来看别人怎么做。EP05-06 核心代码发胖，拆出扩展系统、装上设计审查。EP07-08 让过程可见，再用工具审自己——然后发现核心假设未被验证。
每次转折都不是计划好的。EP03 加第十人是因为所有审查者都在看代码 bug，没人质疑方向。EP05 的扩展系统是因为每做一个新产品核心就胖一圈。EP07 的 opc-viewer 是因为 JSON 日志没人看。EP08 的自审是因为好奇——结果发现了 FAIL 路径的空白。产品暴露工具的短板，短板驱动工具的进化——这条线是事后看出来的叙事，不是事先画好的路线图。
仍未解决的问题
S1E10 说的是人什么时候该介入；S2 的答案是：凡是人必须反复介入的地方，最终都应该变成工具链的一部分。方向判断还不能自动化，终止守卫还没完全机械化，FAIL 路径验证也还欠账。下面是具体的清单：
诚实列出这一季留下的未关闭问题：
1. FAIL 路径验证。 八个产品，零次门禁回环。需要刻意设计一个会触发 FAIL 的场景——比如给审查者更严格的标准，或者故意提交一个已知有缺陷的实现——来验证回环机制是否真的能工作。不是为了证明它坏了，是为了证明它没坏。
2. 终止守卫。 EP02 最核心的教训是自主循环需要退出条件。到 EP08 为止，这个问题在 OPC 层面仍未完全解决。有了 maxLoopsPerEdge 上限，但更高层的”整个 loop session 该什么时候停”没有机械化的守卫。
3. 审查发现处置追踪。 门禁判 FAIL 后回环到构建节点，但没有机制追踪哪些发现被修了、哪些被推迟、哪些是误判。审查者每轮从零开始。这是回环机制真正工作的前提。
4. 成本的真实图景。 EP01 的 $92、EP02 的 $347、产品筛选的 $147——这些都只是 API 费用。每个产品我自己花了 3-8 小时做方向审查和质量判断。如果把人工时间算进去，真实成本翻 2-4 倍。一个更诚实的衡量方式：不是”AI 花了多少钱”，而是”比一个人从零手写，节省了多少总成本”。这个数字我还算不出来。
5. N=1 的外推边界。 整季的所有数据都来自一个人、一套工具链、一组产品。OPC 在我的使用模式下运作良好，不代表它在另一个人的工作流中也行。S1-S2 证明了一种可能性，不是一种方法论。
这一季真正改变了什么认知
S1 结束时我相信：只要约束够紧，AI 就可信。S2 结束时我的理解变了：约束让 AI 可审计，但可审计不等于可信——还需要看到审计过程，并且验证审计机制本身有效。
可审计 → 可观测 → 可验证 → 可信任。这是四个递进的台阶，不是同一件事。S1 走到了可审计。EP07 走到了可观测。EP08 试图走到可验证——然后发现验证本身有漏洞。
这条路比 S1 结束时想的要长。
工具链的演化也给了一个意外的认知：在这个项目里，工具不是设计出来的，是从使用摩擦中长出来的。 OPC → Logex → skill-audit 的三层结构没有人画过架构图。它是一个人反复使用同一组工具时，每次碰到摩擦就造一个小工具来解决，最终回头看发现它们互相连接了。这种涌现很美——但它只在一个人的脑子里有地图。当第二个人出现，这些磨出来的路需要变成铺好的路。
EP01 的教训是扳回方向之后产品才刚开始。八集之后再看这句话，意思多了一层：不只是产品方向会跑偏，工具链本身的方向也会跑偏。这一季一直在优化审查流程——加角色、加扩展、加设计审查——但核心的强制机制从未被行使过。工具在变好，而”好”的定义一直在被修正。
Season 3 的问题：从”我能用”到”别人也能用”，中间隔着什么？
硅基团队 S2: 在实战中进化工具链 ← S2E07: 看不到过程，就没法信结果 | S3E01: 第二个人不是没来，是卡在门口 →