访谈停止判定：Flowness 如何判断需求信息是否足以进入设计

Flowness 在安排 Agent 实施一项工作之前，需要先理解用户想得到什么。用户可能已经讲了很多场景，却还没有明确谁能批准上线；也可能只回答了几个问题，但目标、边界和验收方式已经很清楚。访谈轮数和文字长度，都不能单独决定是否可以进入设计。

本文介绍的是访谈信息充分度判定。它接收前期整理出的停止检查与信息质量评分，返回三种建议：信息足够、有条件足够、信息仍不足。它不生成下一道问题，也不自动替用户结束讨论；最终停止仍需要主会话与用户结合具体情况判断。

设用户要建设一个客户材料上传系统。访谈已经明确文件类型、页面流程、容量要求和交付日期，但谁能访问客户材料尚未确定。此时继续增加页面风格细节，会让记录越来越丰富，却不能消除设计所依赖的关键空缺。

实现因此把停止检查放在质量分数之前。当前四项检查分别围绕红线缺口是否闭合、方向是否稳定、信息是否足以导出设计，以及需要用户独有判断的部分是否得到覆盖。具体通过与否需要上游依据真实材料作出，不能由这个小函数凭空知道。

任意一项检查失败，建议就是信息仍不足。哪怕四项质量评分都是 0.9，也不会用平均分把失败抵消。这个顺序表达了一种设计选择：不可替代的必要前提，要先于整体信息看起来有多丰富。

四个质量维度是广度、具体性、可对话性和质量。评分在 0 到 1 之间，当前默认阈值为 0.6。广度与需求覆盖有关，其他维度依赖提供评分与理由的评估环节。分数表达的是输入评估，不能当成机器测量出的信息熵或成功概率。

规则按顺序执行：存在失败检查，返回仍不足；必要检查没有失败，但至少一个维度低于阈值，返回有条件足够；检查通过且各维度达到阈值，才返回足够。每一维分别比较，避免一个很高的分数掩盖另一个明显偏低的维度。

回到上传系统。访问权限经过确认，四项检查都通过；评分分别为 0.8、0.7、0.55、0.9。第三项低于 0.6，结果是有条件足够。这时后续工作应知道哪项条件仍偏弱，而不能把结果简写成“需求已完全明确”。

若补充交流后第三项被有依据地评为 0.65，其他输入不变，规则就会返回足够。这个教学过程展示的是确定性分支如何变化，不说明几次沟通一定能提升到这个分数，更不说明 0.65 代表 65% 的真实可靠性。

为了避免下游拿到一句结论却看不到依据，结果结构要求四项停止检查和四项质量维度完整出现，并核对失败检查与结论是否一致。对于信息仍不足的结果，还要求列出缺失项；足够的结果则不能同时挂着一份需要补齐的缺失清单。这层结构校验没有按 0.6 阈值重新计算“足够”与“有条件足够”，评分分支仍应通过前述决策函数生成。

这种一致性检查能发现一类表达错误，例如所有输入指向继续访谈，结果字段却写着足够。它不能判断上游是否把一个本来缺失的权限要求错误标成了通过。输入的真实性与结论计算的一致性，是两个需要分别审阅的问题。

因此，真正使用时，评分理由和原始用户表达仍然需要可回查。若用户指出“你们从未问过我谁能批准”，应当重新检查覆盖情况，而不是因为函数已返回足够就坚持原结论。

一种容易执行的停止办法是问满十个问题，或讨论三轮后转入设计。它能控制时间，但同样十问可能分别带来重复描述和关键澄清。只设置一个总体主观分，又容易把不同缺口揉在一起。

当前机制选择了“必要检查优先、各维度分别过线”的组合。源码在背景中引用了 information power 的研究思路，但本文的四项检查和四维评分是项目自己的操作化规则，不能把它们直接说成某篇学术论文原封不动提出的算法。使用一个已有概念，也不会自动证明这里的阈值有效。

0.6 应当被视为需要校准的工程参数。如果一些被判为足够的任务持续在设计阶段发现关键缺口，就需要回看检查定义、评分依据与阈值。如果大量有条件结果其实都能顺利进入设计，也需要判断条件是否设得过严。

我们已经找到确定性决策代码与相关测试入口，但尚未取得判停建议与人工判断的一致性对照，也没有访谈耗时下降的实测数字。这是本系列中效果证据较弱的一项，应作为实现解读和研究中的方法介绍。

它已经让停止讨论的依据变得更具体：哪项必要前提仍缺失，哪一维信息偏弱，哪一部分必须回到用户确认。后续评价应追踪进入设计后的实际返工与遗漏，检查这份建议是否帮助人们在合适的时点继续工作。访谈的结束，最终要由下一步能否有依据地展开来检验。

本篇另备有明亮、适合手机连续阅读的公众号排版稿，配图按照本文机制单独绘制。查看公众号版，或下载 Markdown、HTML、PNG 与 SVG 配图包。