Trigger
工作软件里有人提醒你处理一封邮件
打开邮件后发现需要回复，回复所需的数据分散在其他应用、文档或历史记录中
Ordo 收集邮件问题、收件人、目的、语气、相关资料和来源
用户确认真正缺失的数据、敏感信息、不能承诺的内容和最终交付要求
EMAIL需要回复
MEETING TO-DO形成方案
→
Scene A · Email
回复一封需要跨应用查资料的邮件
重点不是帮用户凭空写一封邮件，而是把邮件提出的问题、相关资料、来源、限制和交付要求放在同一个上下文里
Output
一版有依据、可编辑的回复草稿
Agent 负责形成草稿，用户负责检查事实、语气、敏感信息和外部发送
合格标准每个关键结论能回到来源，缺口和风险明确，草稿可以直接修改
禁止项不自动发送、不把缺失信息当成事实、不隐藏无法确认的承诺
Scene B · Meeting To-do
从讨论结论到有上下文的方案
方案必须基于群聊或会议讨论后的明确 To-do，知道为什么做、为谁做、在什么场景下完成以及什么叫交付合格
Context
先保留讨论，再开始调研
Ordo 先定位 To-do 的来源、参与人意见、截止时间和完成场景，再确定要补齐的调研问题
Ordo 收集讨论结论、目标、参与人意见、已有资料、限制和时间要求
用户确认是否遗漏关键背景，方案面向谁，哪些内容需要用户做最终判断
Output
一份可被检查的解决方案
调研服务于具体场景，方案写清适用条件、取舍、依据、行动项和验收方法
合格标准方案回到原始讨论，不是直接从互联网上随便提问得到的泛化答案
交付物背景摘要、调研结论、推荐方案、风险与依赖、下一步行动和验收标准
Quality gate
两个场景共用一套交付门
上下文完整、来源可追溯、缺口可见、要求可修改、结果可验收，才算进入 Agent 执行