沿同一项需求，看工作怎样继续。
以虚构需求 REQ-014 的订单导出改进为例，观察一项工作如何从范围确认走到交付，再将经人审改的方法带入下一版。看的是连续的协作关系，不是实时产品运行。
同一份需求，保留历史，也保留尚未完成的事
示例中的不同工位共同处理 REQ-014：先明确验收条件，再完成实现与检查；人决定接受和发布 v1。随后，AI 提出总结候选，人实际修改、确认并决定采用，方法才被保留。
下一版仍属于同一需求。它引用已经保留的方法，并更新自己的验收条件；v1 历史和方法原件继续存在，v2 不会因为引用方法就自动获得验收或发布许可。
把需求说清楚。
让协作完成交付。
让反馈推动下一版。
v1 与方法保留 · v2 仍待人验收
Claude Code
Codex CLI示意边界
REQ-014、Agent 岗位、品牌与反馈均为虚构示意，不代表预置岗位或固定模型绑定。编码示例展示可选 CLI 底座；CLI 与模型不是同一层，不构成任意组合兼容矩阵。已有配置的 Agent 参与工作不等于新员工创建。AI 总结经验，人审核、修改、确认并决定采用，不代表模型训练或无人自动上线。v1 历史与方法原件不被 v2 改写，v2 最终仍待人验收。原厂标识说明厂商来源，不代表专属 CLI Logo 或品牌背书。
第一段：先确认范围，再进入协作
起点是可判断的要求
REQ-014 不是一句“把订单导出做好”。示例把工作范围和验收条件交给人确认，再进入协作与方案准备。已有工位接力执行，不代表此时正在培养新员工。
人确认范围，是这段示例里明确展示的决定；不能由此推断全部工作入口的每一步都强制审批。
这里的人为关口
先确认这次要做什么、允许改什么，以及如何验收。目标偏差应在这一层被识别，而不是等到交付后用“执行成功”掩盖。
第二段：检查完成以后，仍需要人验收
协作工位完成实现与验证，形成可供核对的交付依据。检查先发生，随后才是人的验收与批准发布，最终保留 v1 的交付历史。
这里需要区分三个事实：检查得到结果，人确认接受，发布获得批准。Agent 的完成状态不替代其中任何一项，也不能证明真实生产系统已经上线。
在真实研发任务中看什么？
把摘要与变更、实际测试结果、冻结文件和真实交付链接相互核对。要查看对应操作入口，可阅读观察执行与审阅结果。
第三段：方法由人审改，不是自动成为团队真理
AI 提出总结候选
候选来自已经发生的工作与反馈，不是无来源的新结论。它还不能等同于已经采用的方法。
人实际修改并确认
人检查适用条件、修正内容，再明确确认候选。确认与最终决定采用是不同动作，示例分别保留。
保留方法原件与来源
采用后留下明确的方法及其工作来源。这里表达可复用方法的形成，不是训练底层模型，也不是复制全部聊天记录。
第四段：同一需求进入 v2，验收仍然待完成
引用方法，不抹掉原件
v2 使用独立引用连接到已保留的方法，原方法和 v1 历史继续存在。新一轮先更新自己的验收条件，再开展后续工作，不把过去的决定当作新的授权。
示例结束时，v2 仍待人验收
这不是展示遗漏，而是明确的边界：方法复用可以为工作提供依据，不能自动证明新版本正确。v2 未验收、未发布，不能把它写成已经完成第二轮上线。
从这个案例进入产品操作
| 你想核对的动作 | 对应资料 | 注意边界 |
|---|---|---|
| 交代输入与验收条件 | 创建任务 | 资料与仓库需要当前成员授权。 |
| 查看执行与验收依据 | 观察执行与审阅结果 | 执行完成不代表合并、部署或业务验收。 |
| 复用有来源的方法 | 复用角色、流程与能力 | 核对发布版本、输入契约和当前依赖。 |
| 进一步从经验形成员工 | 培养与雇佣数字员工 | 不是本例已有工位参与的含义；分析后仍需人确认创建。 |
REQ-014 为虚构流程示意，不是客户成果或效果承诺。不同产品入口保留自己的运行对象、权限与策略，不能将本故事理解为覆盖全部入口的统一状态机。
继续了解
从一项真实工作开始
看看 AI 如何成为
你们的工作能力。
围绕工作场景、现有系统与治理要求，梳理值得验证的第一步。
仅在本地预览预约信息，
不发送、不保存，不构成实际预约。