前六集用 OPC 做产品、加扩展、看同行、筛 idea、消化知识——机器越做越壮，但有一个问题一直被搁置：这台机器的输出，人类能看懂吗？
OPC 从 S1 到现在，所有审查结果都是 JSON 文件。~/.opc/reports/ 目录下躺着几百个 JSON——每个报告包含协调者的分诊（triage）、各智能体的裁决（verdict）、所有审查发现的严重度/文件/行号/问题/修复/推理、被驳回（dismissed）和降级（downgraded）的原因。
数据很完整。但没人看。
不是因为数据不重要——是因为读 JSON 的认知成本太高。打开一个 2000 行的 JSON 文件，先折叠到顶层结构，找到 findings 数组，展开第一个元素，读 severity、file、message，然后折叠回去找第二个。没有叙事线索（narrative thread），没有因果关系，没有”这个发现导致了那个决策”的脉络。JSON 是给机器读的格式，不是给人读的格式。
我自己都不看。跑完流水线，看一眼门禁是 PASS 还是 FAIL，如果 PASS 就继续，如果 FAIL 就去修——但具体哪个智能体说了什么、协调者为什么驳回了某个审查发现、安全审查者和后端审查者的意见有没有冲突——这些信息淹没在嵌套三层的 JSON 结构里。
S1E07 讲过机械门禁的价值：数数，不做判断。但门禁只给一个 PASS/FAIL——它不告诉过程。当门禁 PASS 时不知道”差一点就 FAIL”；当门禁 FAIL 时不知道 7 个审查发现里哪几个是真的、哪几个是误判。这意味着人类对门禁的信任是盲信——你信它是因为它挡住了坏代码，但你不知道它有没有误判过好代码、有没有放过过边界代码。长期下来，要么过度信任（“PASS 了就不用看”），要么过度怀疑（“FAIL 了但我觉得是误判，手动跳过”）。两种极端都很危险。
可观测性不是可选的装饰，是信任的前提。
从 JSON 到对话
opc-viewer 的核心设计决策是一个比喻：把 AI 团队的审查过程呈现为一场 Slack 对话。
不是仪表盘。不是表格。不是日志查看器。是对话——有头像、有名字、有先后顺序的消息流。
理由很直接：审查本来就是对话。协调者分配任务，各领域专家给出意见，协调者综合判断、驳回不合理的审查发现、降级过重的严重度，最后给出裁决。这个过程天然有顺序、有角色、有交互——它不是一个平铺的数据集，而是一段有因果的叙事。如果用表格呈现，看到的是一堆扁平的审查发现列表；用对话呈现，看到的是谁说了什么、为什么说、以及后来怎么处理了。
为什么不是仪表盘？仪表盘预设了你要看什么——指标和图表背后是设计者提前选好的问题。但审查的本质是发现你没预期到的问题。仪表盘能展示 “critical findings: 3”，但没法展示”安全审查者的担忧和前端审查者的建议指向同一个 API 端点”。对话格式不预设问题，它只呈现发生了什么，让读者自己发现关联。
实现上，前端从原始 JSON 合成出一条时间线——协调者发起分诊，分发各智能体，每个智能体回复裁决和审查发现，协调者做验证（驳回/降级），最后综合。每条消息按时间顺序排列，60ms 间隔依次动画出现。
16 个虚拟团队成员
opc-viewer 做的最”多余”的事：给每个智能体角色一个虚拟人格（persona）。
security 是 Sarah Chen，Security Engineer，红橙渐变头像。backend 是 Daniel Okafor，Backend Engineer，蓝色渐变。frontend 是 Maya Lin，Frontend Engineer，紫粉渐变。new-user 是 Alex Rivera，First-time User，绿色渐变。pm 是 Priya Mehta，Product Manager，蓝紫渐变。
16 个虚拟人格，每个有名字、title、initials、颜色。Apple Contacts 风格的渐变圆形头像。
这看起来纯粹是装饰。但用了一周之后发现——它改变了我读审查报告的方式。
以前看 JSON："role": "security", "verdict": "..." 只是数据。现在看 Slack 风格的回放（replay）：Sarah Chen 说了一段话，Daniel Okafor 说了另一段——阅读时不自觉地按人来读，而不是按审查发现来读。按审查发现读是在清单上打勾；按人读是在听团队讨论。前者快，后者让人注意到不同角色之间的观点冲突——安全审查者说”这个接口必须加鉴权”，新用户代言人说”这个流程太复杂了”，两个审查发现单独看都对，放在一起才发现是一个取舍。
按人读还有一个好处：能判断推理质量。同一个 critical finding，如果推理链条是三步因果（“因为 A 所以 B，导致 C 可被利用”），就比只说”这个不安全”更可信。JSON 平铺展示时，所有 critical 看起来一样重；对话格式下，推理深的和推理浅的一目了然——你自然会更认真对待 Sarah Chen 写了三段推理的那个发现，而快速略过只有一句断言的那个。
虚拟人格的另一个好处是记忆锚点。“Sarah 上次在 auth 那个报告里说过什么来着？“比”security role 在 report-2026-05-15-auth.json 里的 finding #3”好记得多。人脑天然擅长记人，不擅长记 ID。当你用 opc-viewer 看过几十份报告之后，你会开始记住每个虚拟人格的”性格”——Sarah 总是在鉴权问题上特别严格，Alex 总是关注首次使用体验——这些印象帮助你更快地定位到值得深入看的审查发现。
角色到虚拟人格的映射支持前缀匹配（prefix matching）——new-user-genz 会回退（fallback）到 new-user 的虚拟人格。未知角色用通用的 “Specialist” 兜底。这保证了扩展新增的自定义角色不会让 UI 崩溃。
虚拟人格这个设计看起来投入产出比不高——毕竟只是取名字选颜色。但它触及了人机交互的一个底层问题：人不擅长和数据结构对话，但天然擅长和角色对话。 把 role: security 变成 Sarah Chen，不只是换了个名字——它激活了读者的社会认知（social cognition），让你用理解人的方式去理解机器输出。
Flow Replay：逐帧回放 Pipeline
opc-viewer 的第二个核心功能：把整个流水线的执行过程可视化为有向无环图（DAG），支持逐帧回放。
为什么需要这个？因为审查只是流水线的一个环节。OPC 的流水线可以有构建、审查、门禁、回环、多轮修复——一个完整的流水线运行是一棵执行树，不是一条直线。如果只看单次审查的对话回放，你看到的是一个截面；如果看整个流程的回放，你看到的是全貌——包括流水线在哪些节点花了时间、在哪个门禁被打回去了、打回去之后发生了什么。
左边是流程图——每个节点的状态（pending/current/completed），节点之间的连线，回环（loopback，即门禁 FAIL 后循环回构建节点）用 “LOOP” 标记。右边是当前节点的详细时间线——分发了哪些智能体、每个智能体的裁决、门禁的判定结果。
底部是播放控制——play/pause、前进后退、进度条。键盘快捷键：→ 下一帧，← 上一帧，Space 下一帧，P 播放/暂停，R 重新开始。
数据来自 .harness/flow-state.json（流程元数据）和 .harness/nodes/[nodeId]/handshake.json（每个节点的裁决和审查发现）。如果有 opc-harness replay 命令行可用，会额外拉取模板填充数据。
流程回放解决的问题：当流水线有 14 个节点时，没法从 JSON 里看出执行顺序、哪个门禁触发了回环、回环之后重新执行的结果和第一次有什么不同。 表格和日志是扁平的，流水线是有拓扑结构的。可视化必须匹配数据的形状。
举个例子：一次流水线运行中，构建节点（build）产出代码，门禁节点（gate）审查发现两个 critical，流水线自动回环——Claude 根据审查发现修改代码，再次进入门禁。第二次审查通过了。但如果只看最终的 JSON 报告，你只看到 “PASS, 0 critical”——你不知道第一次有 2 个 critical，不知道 Claude 是怎么修的，不知道修复本身有没有引入新问题。流程回放让你看到完整的两轮：第一轮的审查发现、Claude 的修复、第二轮的审查结果。两轮对比，才能判断修复的质量。
两个视图，一个目的
opc-viewer 提供两个入口：
回放视图（ChatView）：按时间顺序看”这次审查怎么发生的”——协调者怎么分工、各智能体怎么回应、哪些审查发现被驳回了。适合理解审查过程。
摘要视图：按严重度排序的审查发现列表——critical 在上，suggestion 在下，支持过滤（All / Critical / Warning / Suggestion / Dismissed）。每个审查发现卡片可展开看修复建议、推理过程、驳回说明。适合快速扫描”哪些东西需要修”。
同一份数据，两种阅读模式。过程和结果，都要可见。
实际使用中，两个视图的切换形成了一个自然的工作流：先看摘要视图快速判断”这次审查有没有大问题”，如果全是 suggestion 和已驳回的发现，就不用深入了；如果出现了 critical 或 warning，切到回放视图看具体上下文——协调者为什么没有驳回这个发现？其他审查者对同一个文件说了什么？这个发现的推理链条可信吗？摘要视图是快速筛选（triage），回放视图是深度分析。
看得见才能信
opc-viewer 的技术细节不多——React 19 + Vite + 一个 Node server，读 JSON 渲染 UI，Playwright 做 E2E 验证。代码量不大（相对 OPC 本体）。
但它解决了一个在 S1 到 S2 整个过程中一直存在的隐性问题：工具链的输出不可读。
这不是一个小问题。不可读的输出导致了一个恶性循环：因为看不懂，所以不看；因为不看，所以不知道系统的判断质量；因为不知道判断质量，所以不知道该信任还是该怀疑；最终变成了要么全信要么全不信——两者都不是和 AI 工具协作的健康方式。
OPC 的机械门禁保证了”坏东西过不去”。扩展系统保证了”领域能力可扩展”。但这两个保证都是对机器说的。对我这个唯一的人类用户来说，保证只在我能看到的时候才存在。一个 PASS 的门禁，如果我不知道它差点 FAIL，我就不知道这次审查的质量其实在悬崖边上。一个 FAIL 的门禁，如果我不知道 7 个审查发现里 4 个是 emoji 解析误判（S2E08 会讲这个 bug），我就会以为问题真的很严重。
可观测性改变了我和工具的关系——从”信任 PASS/FAIL”变成”理解为什么 PASS/FAIL”。这不是一个效率工具。这是一个信任工具。
信任不是一次性的。每次流水线运行都在积累或消耗信任。如果连续十次审查你都看到协调者做出了合理的驳回决策，你对系统的信心会自然增长。如果某次审查你发现协调者驳回了一个明显正确的 critical finding，你知道系统在这个场景下有盲区——这比一个不透明的 PASS 有价值得多，因为你知道了系统的边界在哪里。
工具链的输出不可读，输出等于不存在。
硅基团队 S2: 在实战中进化工具链 ← S2E06: 三个审查者没一个看出颜色不对 | S2E08: 让工具审自己，发现它从没拦过谁 →