评估系统的最后一公里，不是把分数算得更准，而是让非工程读者看得懂、动得了。前五篇解决的都是”怎么算”：数据质检、结构化输出、容错归一化、任务编排。这一篇解决”怎么讲”——同一份诊断数据，工程师要的是明细和字段，产品经理要的是结论和下一步动作。如果报告只为前者设计，那它只是一个查询界面，不是一个决策工具；PM 打开后仍然要自己在十几个模块之间建立联系，评估系统的价值就停在最后一步。
这一篇的核心观点是：报告的信息架构本身就是产品设计。我们最终把首页组织成三个问题的顺序回答——Agent 是否健康、有什么问题、如何优化——每块只回答一个问题；健康判断收敛为显式规则产生的三个词之一；首页只给建议不做拍板，决策动作留在详情页；覆盖率先行展示，任何结论都能下钻到会话级证据并导出验收案例。回头看，走到这一步用了三次迭代，其中第一版”三块并排”是一个实打实的败笔。
下面按迭代顺序展开。
一、两类读者，一份报告
先说清楚读者是谁。诊断流水线的直接消费者是工程师：他们关心诊断覆盖率、失败模式枚举、JSON 字段是否完整。但报告的最终读者是产品经理和 Agent 运营——他们不写代码，打开报告时脑中的问题是：“这个 Agent 现在能不能放心用？哪里最该改？改什么？”
这两类读者的阅读方式差异很大：
| 维度 | 工程师 | 产品经理 |
|---|---|---|
| 阅读单位 | 一条诊断、一个字段 | 一个结论、一批事项 |
| 阅读顺序 | 任意跳转，按需查询 | 线性阅读，期待被引导 |
| 关心的问题 | 数据对不对、流水线稳不稳 | 先做什么、为什么、值不值 |
| 对细节的态度 | 越细越好 | 需要时才下钻 |
第一版报告低估了这个差异。它把分析产物按流水线阶段纵向罗列：覆盖率、问题率、优先优化事项、高风险低频问题、失败模式分布、改造对象统计、问题处置分布、暂待观察项、原始证据……每个模块单看都没错，但整体上没有一个叙事主线。PM 需要自己在模块之间搭桥，才能回答”先解决什么”。
于是有了第二版：把报告从”分析结果展示页”调整为”产品决策工作台”，顶部拼一句结构化的管理结论（例如”本次共发现 28 个问题实例，最优先处理’退款进度答非所问’，首要改造方向为知识库与工作流”），正文以可执行优化事项为核心单位，并给每个事项配上”本期处理 / 继续观察 / 暂不处理”的团队决策状态。
二、败笔复盘：三块并排，PM 分不清先看哪
第二版上线后暴露了一个新问题，也是这篇想坦诚复盘的败笔。
当时首页把「管理结论」「优化决策」「建议优化方向」三块并排放在一起。三块都在讲结论、问题和改法，语义高度重叠：
- 管理结论说”最优先处理退款进度答非所问”；
- 优化决策表格里排名第一的也是它；
- 建议优化方向柱状图里知识库排第一。
对做报告的人来说，这三块各有职责；对 PM 来说，这是同一件事被讲了三遍，而且分不清先看哪、每块回答什么。更糟的是”优化决策”区把决策下拉、筛选、保存状态全部堆在首页，PM 还没理解问题，就被要求做决定。
复盘下来，问题出在信息架构没有对应读者的心智路径。PM 打开一份已完成的报告，心理上要按顺序回答三个问题：
- 这个 Agent 是否健康？
- 有什么问题？
- 如何优化？
三问是天然的单向漏斗：先要一个总判断，再看问题分布，最后才是行动。而”三块并排”把漏斗压成了平面，每一块都想当主角，结果谁都不是主角。信息架构上有一条朴素的纪律：导航顺序 = DOM 顺序 = 阅读顺序。如果页面结构本身不表达优先级，靠加粗和颜色是救不回来的。
第三版重构就是把首页拆回三问，外加一块承接工程细节的”分析附录”。
三、三问叙事：每块只回答一个问题
重构后的首页结构是四个区块，顺序固定：
- Agent 是否健康（
#agent-health） - 有什么问题（
#problem-landscape） - 如何优化（
#optimization-actions） - 分析附录（
#analysis-appendix）
顶栏导航文案与锚点一一对应，导航顺序和页面 DOM 顺序完全一致——PM 从上往下读，就是被引导的思考路径。
三块之间的职责切分要足够狠，狠到有些信息被刻意”驱逐”：
- 健康块只回答”是否健康”。结论文案禁止点名优先事项，禁止出现任何优化方向（流程、知识库、提示词、工具、交互策略、数据质量）。一旦健康结论里出现”建议优先优化知识库”，健康块就偷偷变成了优化块，三问又开始互相渗透。
- 问题块只回答”坏在哪”。保留失败模式分布图和问题清单，清单每行只显示序号、标题、场景、问题类型、影响数，不出现行动建议。
- 优化块只回答”该动什么”。同一批事项换成建议视角：方向摘要一句话（“本期建议优先动：知识库、提示词”），加一张建议列表。
注意一个关键设计：问题清单和优化清单是同一批数据的两种读法，不是两套数据。正式事项池由 optimizationActions 和 riskActions 合并后按优先级排序，问题块读它时展示”坏在哪”，优化块读它时展示”怎么改”。这保证了两个视角永远一致，也避免了重复的聚类逻辑。
至于暂待观察项、数据质量指标、运行版本、导出入口，全部收进”分析附录”。工程细节没有被删掉，只是不再抢占 PM 的阅读路径。
四、健康判断：显式规则，三个词之一
三问的第一问是”是否健康”，这要求报告给出一个明确的判断，而不是一堆指标让读者自己掂量。
我们的做法是把判断规则显式化，写死在代码里而不是让 LLM 现场总结：
| 条件 | 结论标题 |
|---|---|
存在严重问题实例（severeProblemInstances > 0） | 需干预 |
| 无严重问题，且问题占比 ≥ 15% | 需关注 |
| 其余情况 | 健康 |
三条规则，三个词，边界清晰：
- 可解释。PM 质疑”为什么说需干预”时，答案是一行规则加三个数字，不需要重新解释模型。
- 可复现。同一份数据永远得到同一个结论，不存在措辞漂移。
- 可校准。15% 这个阈值是经验值，未来要调整时改的是一个常量，而不是一段 prompt。
判断依据不再写成一段长文，而是做成三列指标卡：问题占比、严重问题数、诊断覆盖率。其中覆盖率卡必须注明一句”只代表结论可信度，不代表 Agent 质量”——这是第二篇踩过的坑的延续：覆盖率低说明结论可能站不住，但绝不等于 Agent 表现差，两类数字在视觉和文案上必须严格区分。覆盖率也不参与健康打分，只在低于阈值时于结论文案末尾追加一句”当前覆盖率偏低，结论仅供参考”。
结论文案用模板拼接而非 LLM 生成，例如有问题但无严重问题时输出”{问题占比}% 的对话存在体验问题”；部分完成的报告句首加”基于已完成诊断”。另一个细节：健康判断不依赖是否存在正式优化事项——没有达到行动门槛的事项时，只要统计上仍有问题，照样判”需关注”，避免”没有建议就等于没有问题”的误读。
五、决策边界：首页只给建议，不拍板
第二版曾在首页放了完整的决策 UI：全部/待决策/本期处理/继续观察/暂不处理的筛选，表格里的决策下拉，保存中/已保存/重试保存的状态流转。第三版把这些从首页全部移除，“本期处理/继续观察/暂不处理”的三态决策只保留在点击事项打开的详情抽屉里。
为什么？因为决策和阅读是两种动作，不该混在一屏：
- 决策需要上下文。负责任的”本期处理”判断，至少要看过根因假设、置信度、影响范围和验收案例——这些都在详情里。在首页列表直接下拉拍板，等于鼓励轻率决策。
- 决策控件会污染阅读路径。表格里每行一个下拉框，PM 扫读问题清单时注意力会被状态切换和保存反馈打断，三问叙事就断了。
- 报告的职责是建议。系统的判断以”建议优先动什么”的形式表达；“这期做不做”是团队基于资源排期的决定，留给人在看完证据后做。
这是一条信息架构纪律：报告页承担理解，详情页承担决策。已有的决策数据不丢，详情抽屉里的决策控件和对应的持久化接口原样保留，只是入口收窄了一层。
六、证据闭环：覆盖率先行，结论可追溯
评估报告最大的信任风险是”结论看起来很有道理，但没人知道它建立在什么数据上”。我们的对策是把证据链做成显式的三段：
第一段，覆盖率先行。 首页明确展示诊断覆盖率、分析范围和分母口径（呼应第二篇：诊断之前先定义人口——哪些对话进入诊断、哪些被风险筛掉、哪些失败隔离）。覆盖率低时结论自动降级措辞。PM 看到”需关注”三个字之前，先看到这个判断建立在多大的样本上。
第二段，下钻到会话级证据。 报告里的汇总数字——问题实例数、失败模式分布——都不是死数字，而是可点击的下钻入口。点击”问题实例”统计卡，右侧抽屉展开所有失败或部分成功的诊断实例，每条包含用户问题、Agent 回答、观察事实、诊断结果、失败模式、严重程度，以及存在时的前序会话上下文。点击失败模式分布图中的某个柱形（比如”退款进度答非所问”），抽屉则只展示命中该模式的实例。抽屉用游标分页支撑大量实例，报告页滚动位置保持不变。从”问题簇”到”具体对话”的每一跳都可点击，任何一个汇总结论都能被还原成原始证据。
第三段，导出验收案例。 每个优化事项在详情里附带验收案例列表和 CSV 下载。优化上线后，拿这批案例回归验证”改了之后这些问题对话是否变好”，让评估从一次性报告变成可复测的基线。全量诊断 CSV 也在附录提供，供工程师离线分析。
三段合起来：先声明数据边界，再让每个结论可下钻，最后让每次优化可验收。
七、优化事项：从问题簇到行动建议
三问的最后一问”如何优化”，数据来源是问题聚类：诊断阶段给每条对话打上失败模式和严重程度，聚类阶段把相似问题归成簇，再为达到行动门槛的簇生成优化事项。事项的候选池有一条明确规则：RISK 类事项全量进入，ACTION 类按优先级取前 10。高风险低频问题即使样本少也必须出现在首页，并带危险标记——这类问题出现一次就可能造成资损，不能因为频率低被排序淹没。
事项的完整信息在详情抽屉里按固定顺序展开：观察事实 → 根因假设与置信度 → 建议动作 → 预期影响 → 验收案例 → 对话证据。顺序本身是刻意设计的：先看事实（别急着信结论），再看假设（允许质疑），然后才是动作。
首页的问题分布图有一个值得一提的迭代小案例。最初的柱形图只展示各失败模式的实例数，PM 反馈”知道退款类问题最多，但不知道里面有没有严重的”。于是我们给每根柱形加上了最严重级别标注——柱形高度回答”有多少”，标注回答”有多严重”。看似只是加一个标签，实际逼着回答一个产品问题：分布图的读者要做的判断是”先看哪类问题”，而这个判断需要频次和严重度两个维度，缺一个就会误导排序。类似的还有把旧的”问题处置分布”环形图移除，改为决策筛选标签上的数量摘要——同一信息服务工作流比独立成图更有用。
八、局限与后续
这套报告设计还有三个已知局限：
- 聚类质量依赖 embedding。 问题簇的语义纯度决定了优化事项的准确度：簇太杂，根因假设就是几类问题的混搭；簇太碎，同一根因被拆进多个事项，影响数被低估。目前没有对簇质量本身的评估指标，只能靠人工抽检。
- 健康阈值是经验值。 15% 的问题占比阈值没有统计学依据，它需要随着分母口径、场景风险容忍度的变化持续校准，也完全没有区分问题的业务严重度——一个”回答口径不统一”和一个”承诺了错误的退款金额”在占比里权重相同，后者其实由严重问题数兜底，但边界情形仍然粗糙。
- 决策是单人的、瞬时的。 目前决策状态只记录最近修改人和时间，多人同时修改按最后写入生效。真实的团队协作需要决策留痕、讨论上下文、甚至变更审批，这是下一步的方向：把”决策”从一个人的一次下拉，变成一个小型协作流程。
九、系列总结
六篇写完，回顾整条主线：第一篇定义了只用对话文本的黑盒诊断工作流——不接内部埋点、不改 Agent 代码，从最终产物反推健康状态；第二篇讲诊断之前先定义人口，用数据质检和风险筛选保证分母干净；第三篇用严格 JSON Schema 让 LLM 稳定输出结构化诊断；第四篇承认 LLM 输出必然不完美，用归一化、一次修复和失败隔离兜住长尾；第五篇解释为什么不用消息队列，而用数据库做任务编排换取可靠与简单；这一篇收尾，把前面所有算出来的东西，变成 PM 能读、能动、能追溯的报告。
贯穿六篇的其实是同一句话：模型负责语义判断，应用负责协议边界。 哪一步交给 LLM（判断这段对话有没有问题、归因到什么、严重到什么程度），哪一步用确定性工程兜住（schema 校验、字段归一化、重试与隔离、任务状态机、健康打分规则、信息架构），这条线画清楚，评估系统才能既保留语义判断的灵活性，又保住工程实现的可依赖性。报告的产品化也不例外——健康结论里的三个词、三问的区块顺序、首页与详情的决策边界，都是把”讲不清楚的语义”翻译成”确定的协议”。评估系统如此，Agent 本身也如此。