AI 工作最容易被简化成一次请求和一次回复。但真实交付并不沿着这样的边界结束：缺资料可以继续补，初稿需要修改，已经接受的版本之后还可能增加要求。
这要求产品同时认识三种对象。任务保存一项交付责任，运行记录具体执行，成果保存不断演变的内容。它们经常一起出现，生命周期却不同。
Teloa 将三者分开，是为了让工作能够继续变化，同时不改写已经发生的判断。一次运行可以结束而任务仍未交付，一项任务可以结项而成果继续形成新版。版本在这里承接内容历史，任务承接每次交付责任。
从报价材料到一份可用的比较表
以下用供应商比较作假设例子。要求依据已提供报价，比较价格、交付周期和支持范围，单列缺少依据的条目，交付一张比较表。
这个目标把几种能力组织到同一份交付中。研究岗位提供长期的查证标准，已采用的比较技能提供步骤，报价与服务说明提供事实；本次任务再规定比较哪几家、哪些条件必须单列。岗位任务准备执行时，将实际采用的岗位版本、技能、资料与任务要求一同固定，交给执行层处理。
它们各有用途。只给报价，容易得到三份摘要；比较方法要求检查是否采用了同样的价格单位和支持口径；再明确交付要求，缺少依据的部分才有位置列出，而不必由用户从流畅文字里重新找遗漏。系统组织这些输入，研究判断仍需依据材料完成。
第一轮缺少一家报价，第二轮补齐，第三轮调整表达，任务可以延续同一目标，运行则保留各轮实际条件。用户核对的是比较表是否回答了原问题，指出的差异再成为下一轮要求。任务、运行和成果的联系，由此支持一份交付逐步完成，也让中途补充不必从头交代。
任务名称帮助寻找，明确的目标帮助判断。比较表少了一家供应商，或者把不确定条件写成事实，问题都能回到原要求，而不只是评价文字是否流畅。
修改发生在什么阶段，决定怎样继续
研究仍在进行时补充“请单列售后响应时间”，可以沿适合的活动运行追加，或在原任务中继续一轮。系统需要记录它实际进入哪里，不能用编辑后的目标文字改写已经发生的输入。
但任务已经结项后，情况不同。那份成果已经依据当时要求被接受，新反馈又提出了一次交付。如果直接覆盖旧成果，原验收就会指向负责人没有看过的内容；如果始终重开旧任务，也容易丢失两次工作的边界。
在当前通用工作路径中，已结项成果这样继续修改：
- 保存反馈，并明确交回 AI。
- 批准后，系统建立独立后续任务与运行。
- 后续任务写入同一成果的新版本。
原任务仍对应旧版，后续任务对应新版。
用户不必另存一份名字相近的文件，系统也不必假装旧验收一直适用于最新内容。成果继续完善，两次责任分别留下。
反馈应当指向一份确定内容
“把售后部分补具体些”，依赖原版本与段落。反馈如果只留在一段新聊天中，执行者可能依据另一份历史改稿，甚至顺手重写已经接受的价格和交期。
Teloa 的续改请求固定成果、版本、反馈和选定段落。交付的新版本保留同一成果身份，同时记录由哪项后续工作产生，便于从任务取得，也能回到原成果比较。
可以把这次续改理解为一份具体约定：以v1为基础，只修改售后段落，保留已有价格比较，返回同一成果的下一版。用户表达的是修改意图，系统固定的是执行所需的基础与范围。两者接上以后，局部修改才不会悄悄扩成整份重写。
这也解释了为什么冲突不能简单采用“最后保存获胜”。人工已经改出v2，AI却仍依据v1完成，直接写入会丢掉人工工作。保留未应用候选虽然增加一次核对，却同时保护两边已经完成的内容。成果身份维持连续，版本条件决定哪次写入可以成立。
任务与成果的关系在这里比文件命名更重要。任务回答谁对这次修改负责，成果回答内容怎样演变。用后续任务承接已结项后的修改，能让两项责任都准确指向自己的交付。
文字改了，还要看原问题是否解决
模型再润色一遍，可能让表达更顺，也可能删掉关键条件。Teloa 在接入了复核步骤的任务中，将草稿修正与交付前核验分开。
复核面对本轮待交付草稿。局部续改时，检查的是选定段落的修订正文，原成果其余部分并未重新验收。修正保留问题、依据和受影响内容，核验再检查原问题是否解决。
依据引用从固定来源片段还原，不能用模型重新抄写的相似句子代替。找到一段原文之后，还要判断它是否真正支持这次改动。
这能约束结构与证据关系，但不能代替任意业务事实判断。报价是否仍然有效，两个条件是否可比较，仍需依据材料和专业判断。系统核验与本人接受保留不同含义。
已经接受的版本，需要继续成立
已经接受的版本需要保持可解释。负责人上周核对的内容，不能因为今天产生新版而悄悄改变；预览与下载也需要指向同一份确定内容。
将责任与内容分开，增加了产品内部的关系维护，却减少了用户自己另存文件、辨认版本和解释旧验收的负担。它也让后续修改有一个合理位置：新要求对应新工作，内容仍沿同一成果演变。
这是一种为迭代设计的完成方式。完成记录了某项责任在当时条件下得到接受，同时为以后的变化保留准确起点。