人开始一项工作时，往往还不知道最终要交付什么。先说“帮我看看这几份材料”，读过比较结果以后，才发现真正要决定的是服务范围，而不是报价高低。要求是在合作中形成的，产品很难在第一句话以前把它们全部问清。
但等到决定具体修改一项价格、采用一份报告或授权执行，对话里的大致理解又不够了。人需要准确看见对象与内容，知道这次决定会改变什么。
这两种需要共同决定了 Teloa 的交互：对话容纳尚未确定的意图，工作界面承接已经具体的内容与动作。我们关心的是人怎样在两者之间往返，并逐渐把一件事做对。
意图还在形成时，先让人把问题讲出来
以一项假设的供应商比较为例。用户最初希望“选一家合适的”，随后才补充预算、售后与交付时间。若开始就要求填写全部字段，系统得到的也许只是用户为了通过表单而作出的过早决定。
对话允许人补充、追问和推翻原来的设想。主助手可以先帮助理解问题，需要持续执行以后，再明确交办为独立工作；反复出现的职责，之后才值得保留为员工。创建结构的时机，应当跟着工作逐渐清楚的程度走。
小松鼠的小窗和完整主聊共用会话，也服务于这个过程。短问题可以在页面旁提出，讨论变长以后可以换到更大的空间，先前形成的要求仍然延续。它降低的是开始与接续的成本，不能据此假定助手已经阅读当前屏幕上的所有资料。
内容具体以后，决定也需要具体
比较结果可能揭示一个新问题：报价包含的服务范围不同。用户说“把条件补清楚”，还需要检查究竟补了哪些内容。模型回答“已经调整”无法替代这次检查。
这时，界面提供了对话不擅长的精确性。正文可以直接阅读和编辑，业务修改可以查看字段差异，执行审批可以明确选择。人在实际内容上作决定，比在一段行动说明上猜测更可靠。
社区版已支持的业务修改先保存草稿，再由本人请求采用，沿原会话处理审批与执行。自然语言业务搭建也先形成受支持的配置草案。这里有意保留了一次检查：省去手工填写之后，仍要让人看见系统如何理解要求。
精确操作也会增加界面与版本管理的成本。但让模型直接以自己的理解写入，等于要求用户事后发现它误解了哪个日期、哪个客户或哪项条件。把检查放在决定发生的位置，是我们愿意承担的产品成本。
第一稿之后，合作才进入更有信息的阶段
很多要求只有看过第一稿才能说清。供应商比较表做出来以后，人可能决定保留价格差异，却要求单列不包含的服务。这个反馈比最初的“帮我选一家”更具体，因为双方已经有一份共同可见的内容。
因此，成果需要可以取得、检查和继续修改。仅仅把长文本留在回复里，用户很难明确指向自己接受的内容，也难以判断后来一轮究竟改变了什么。
当前通用成果路径保存针对明确版本的反馈。本人明确交回并通过执行审批后，后续任务可以写入同一成果的新版本，原任务仍保留已接受的内容。它让“继续修改”成为可以追查的合作，而不是重新生成一份相似文本。
从使用者角度看，这段往返很简单：
- 先用自然语言提出还没完全想清的目标。
- 对照实际内容，指出差异或改变决定。
- 沿原工作取得修订结果，再判断是否可用。
产品结构存在的意义，是让这三次处理能够互相承接。
切换表达方式，已有修改应当继续有效
同一份服务说明可以先在对话中形成，再到资料库修改适用条件，最后回到对话补充例子。第三次处理需要面对第二次保存的内容。否则，每换一种入口，用户就要重新同步一次自己的工作。
Teloa 已支持的自然语言资源操作复用原服务，保留同一对象的身份、版本与范围。对话因此能够成为维护方式，原界面也继续有效。指代不明、内容已更新时，需要回到具体对象核对，这些条件由共同服务处理。
跟进过程同样需要分工。会话中的工作概览把进展、后台工作与成果放在附近，帮助人决定是否等待或检查；临时详情读完即可返回。它们给对话补上必要依据，不要求用户先读完执行日志。
让人能够改变主意
只有对话，具体决定容易埋在往返文字里；只有固定界面，尚未形成的要求又很难表达。共同工作需要同时接受这两种不完美，并在它们之间建立准确联系。
我们希望用户可以早一点开始，也可以晚一点改变主意。前一次投入的资料、检查和判断，应当帮助下一轮更接近结果。衡量交互的标准，也就从“第一次输入有多省事”，延伸到了“看过结果以后，还能怎样把它做好”。