从会议转写到 Voice-to-Outcome

行动项通常只有动词和责任人，例如“补充 ROI”。对下游执行系统而言，这远远不够。它还需要知道计算基于哪些假设、可以引用哪些数据、不能承诺哪些范围、面向谁表达，以及成果通过什么标准才可以外发。

因此，Voice-to-Outcome 的中间产物不应只是一条任务，而应是一份可执行输入。它至少包括目标、证据、约束、责任边界和完成标准。我们把这种结构称为 Context Pack。它不是把全部会议记录塞给模型，而是针对当前任务选择必要信息，并保留每项信息的来源。

Resolve｜指代消解

系统先确认“昨天的会议”“那个客户”“上次版本”等表达对应的真实对象。低置信度时应向用户确认，而不是静默猜测。这个阶段的输出是明确的业务事件与主体。

Ground｜需求锚定

把口头要求还原为可讨论的业务目标。例如，“补一下 ROI”可能意味着增加测算假设、成本项、回收周期和数据来源，而不只是插入一页数字。这个阶段需要结合会议上下文和既有材料确定需求边界。

Package｜上下文打包

在调用者有权访问的范围内，选择合同约束、产品说明、历史方案、会议证据和审批要求，形成 Context Pack。每项关键结论都应能够回到来源；无关或越权信息不应因为“可能有用”而被加入。

Route｜执行路由

依据任务类型选择企业已有的文档 Agent、分析工作流、CRM 自动化或其他执行系统。复杂工作可以拆分，但每一步都要有明确的输入输出和失败回退。Stay 的角色是组织与路由，不是声称由一个通用 Agent 包办全部专业判断。

Return｜审批与回传

下游生成成果后，系统根据风险策略决定是否需要负责人审批。客户外发、报价承诺和关键数据写入通常应保留人工控制点。确认后的成果与状态回到文档、CRM 或项目系统，修改意见与采用状态成为下一次判断的反馈。

Voice-to-Outcome 不能只用“生成速度更快”来证明价值。至少应分开观察四组指标。

第一组是理解质量：指代识别正确率、上下文选择精确度，以及需要人工澄清的比例。第二组是执行质量：路由成功率、工具调用完成率和失败类型。第三组是成果质量：负责人修改范围、审批通过率和成果采用率。第四组是业务影响：从会议结束到可评审成果的周期、人工搬运步骤和重复解释时间。

这些指标必须有基线。例如，若过去由销售手工完成方案，就需要记录原流程耗时、参与角色和返工原因，再与新流程比较。没有基线的“节省很多时间”，不是可靠结论。

不是所有会议内容都适合自动进入执行链路。探索性讨论可能只需保留背景；内部低风险任务可以生成草稿；对外发送、合同承诺、价格变更或生产系统写入，则应要求更严格的证据与审批。

好的系统不是尽可能减少人工，而是把人工放在最需要判断和承担责任的位置。把重复查找、复制与格式整理交给系统，把目标确认、例外处理和关键批准留给负责人，通常比追求“全自动”更适合企业环境。

第一阶段应选择一个部门和一种成果。明确采集授权、数据范围、执行系统、审批人和验收标准，然后在有限用户中记录失败。等上下文结构、连接方式和评估方法稳定后，再扩展到其他会议类型或成果。

这个顺序看似保守，实际更快。它迫使团队尽早面对业务边界，也使每次扩展都能够复用已经验证的权限、连接器和流程模板，而不是不断增加一次性自动化。

会议转写回答“发生了什么”；Voice-to-Outcome 进一步回答“这件事应如何被理解、由谁继续执行、如何审批，以及什么状态才算完成”。两者不是同一个产品目标。

Stay 希望成为两者之间的入口层：从语音中识别意图，组织必要上下文，将可执行输入交给匹配的 Agent / 工作流，并追踪成果回传。价值不在于生成了多少文字，而在于一项真实工作是否更早开始、更少丢失背景，并以可复核的方式完成。

文章 CTA 如果您希望把一类会议从“纪要完成”推进到“成果可评审”，欢迎与 Stay 一起梳理输入、上下文、执行者与验收指标。

---