关于这个话题，我收到过一条读者留言：AI 工作流的核心其实很简单——人定好验收标准，AI 执行并且按标准验收。
他说得没错，但实现起来并不容易。“标准”如何而来？如何得到尊重？随着上下文的增长或换一个新上下文，标准难免偏移甚至会被篡改。
我需要一种可被信任的 AI 使用方式，简单来说就是“可委托”：人不必盯住每一步，工作仍能在明确边界内继续；遇到缺口会停下来交回，换一个上下文后也能从同一状态接上。
这是两篇系列的下篇。上篇讲 AI 工作中几个不会因模型升级立刻消失的问题；本文讲我因此想要什么，以及 Task-Driven 如何把它落到实际工作中。
稳定比偶尔做到最好更重要
一个偶尔做到 A、偶尔掉到 C 的系统，我不敢把工作交出去。稳定的 B+ 反而更有价值。
这里的稳定，不是要求模型每次给出相同答案，而是让整个流程的波动可控：范围不会越做越大，验收标准不会中途变化，不同上下文不会各自处理一件不同的事，一次较差的结果也不会未经检查就传到最终交付。
边界之内应该让模型充分发挥。真正需要约束的，是波动怎样传导，而不是消除波动本身。
可委托性也不以“任何人”为主语。委托的一方需要提供意图、边界和授权；系统则有责任主动索取那些必需、又推断不出来的信息。使用者没有提供一个从未被问过的答案，那是系统的设计缺口。
成本要可预测，验收标准就得有边界
可预测性有两部分：质量和成本。缺少任何一部分，工作都很难真正委托。
一个可能三轮、也可能三十轮的任务，即使最后质量不错，也很难安排和预算。真正可以控制的杠杆，是验收标准：要求做到什么程度，就要为这个程度付出相应代价。
所以顺序应该是：工作价值决定验收标准，验收标准决定投入成本。低价值工作使用轻流程，高价值工作才值得多轮检查。轻流程不是把同一套要求做得马虎一些，而是一开始就选择与工作价值相称的完成标准。
流程可以减轻，底线不能消失。外置记录仍然是权威，范围之外的问题仍要明确写出，授权也不能靠推测。可以减少的是仪式，不是这些性质。
不追求证明所有问题都已找到
有了成本边界，也要接受另一件事：不把“证明所有问题都已经找到”当成每个任务的义务。
这不意味着降低检查要求。已经发现的问题，默认仍然阻止任务通过。放弃的只是那个几乎没有终点的附加目标——不仅解决已知问题，还要证明未知问题已经不存在。
如果一项工作需要带着残留问题结束，这些问题必须被明确记录，再由有权决定的人根据工作的价值选择是否接受。没有记录的问题无法验收，也无法被质疑。所谓边界，不能只是把缺陷推到看不见的地方。
人、模型和工具各做什么
分工的标准很简单：谁能可靠地提供某样东西，它就应该归谁负责。
- 人负责意图、边界、验收标准、价值判断和授权；
- 模型负责边界内的判断与执行；
- 工具负责事实、状态、记录，以及对边界的强制。
任何一方越界，都会带来问题。
让工具代替判断，流程会僵化；让模型自己决定边界，任务会随它的理解逐渐漂移；让人承担大量机械确认，人又会成为瓶颈。
其中最不能让渡的是授权。授权表达的是人的意志，不是对事实的判断。模型可以分析一件事是否值得做，却不能据此推断“已经获准去做”。提交、推送、发布等会改变共享历史或外部环境的动作，仍然需要单独确认。
这不等于要求人亲手写完所有契约。模型应该主动整理讨论、暴露假设并提出问题；人的注意力只留给那些无法推断、必须由人作出的决定。
交接必须写在对话之外
委托会跨越不同上下文。只存在于当前对话里的目标和边界，下一个上下文既看不到，也无法据此继续工作。
因此，需要一份独立于对话、可以长期保存的外置记录。它不是权威内容的摘要，它本身就是当前工作的权威。对话记录、模型记忆和临时传入的上下文都可以辅助理解，但发生冲突时，以外置记录为准。
交接还必须是双向的。下游发现的问题、提出的异议和作出的裁决，都要能够写回并保存。只能从上游传到下游的文档更像简报，无法记录“上一轮的判断后来被推翻了”。
这也是为什么“让另一个 AI 验收”还不够。另一个模型可以带来独立视角，但如果它没有读取同一份权威记录，或者结果无法写回，它只是在另一个房间里发表意见。
每个新上下文都不靠上一段对话直接传话。它读取外置记录，完成当前工作，再把结果写回。下一个上下文从更新后的状态重新开始。
隔离和交接解决的是两个问题：前者减少上一轮思路对下一轮判断的影响，后者避免历史丢失和目标漂移。缺一不可。
只保留不会很快过时的规则
一套工作方式是否耐用，可以用一个问题检验：模型升级之后，这条规则会不会变得多余？
如果会，它通常不应该成为体系的固定部分，而应继续留给模型。
怎样调查、怎样实现、采用什么推理方法，都可能随模型能力提升而变化。人的意图、价值和授权不会因此消失；事实和任务状态也仍然需要被稳定保存，不能每次都让模型重新猜测。
固定的应该是责任边界和交接规则，而不是越来越厚的执行手册。
可委托性的完整结构
到这里，几个部分才真正连在一起。
模型、上下文和执行方法都可以变化，但整套系统不能全是变量。外置文档提供连续性，运行工具（runtime）提供确定性。
runtime 不负责替模型判断。它用固定规则决定任务从哪里开始、当前上下文可以做什么、需要满足哪些前提、结果写到哪里，以及下一轮交给谁。
它不保证模型每次给出相同答案，而是保证不同答案都经过同一套读取、校验、写回和交接规则。模型的判断可以变化，但判断怎样进入任务历史必须确定。
只有外置文档，没有 runtime，模型可能漏读、误读，也可能完成工作后忘记更新。只有 runtime，没有外置文档，它最多约束当前一轮，无法让下一个上下文知道之前为什么这样决定。
人定标准、AI 执行并验收，这句话没有错，只是还差两层：外置文档让不同上下文面对同一项工作，确定性的 runtime 保证每一轮都按同一套规则进入、写回和交接。
Task-Driven：一种具体实现
从去年底开始，我一直沿着这些方向实践，并逐渐整理出一套名为 Task-Driven 的工作方式。它不是可委托性的唯一答案，只是我目前采用的一种实现。
一项工作通常从讨论开始。AI 先把它理解到的目标、边界、假设和缺少的授权完整摊开，人确认之后，才形成可执行、可验收的 task。这里的 task 既是契约，也是跨上下文交接的基本单位。
复杂工作会进入不同角色：凝练任务（Frame）、收敛价值与范围（PM）、定义行为与流程（Design）、实现并给出证据（Dev）、独立判断（QA）。每一次角色工作使用新的上下文，只承担当前责任；路径可以缩短，也可以因为新发现退回上游，但这些变化必须被记录，不能由模型在执行中悄悄省略。
每个角色开始时，runtime 提供当前状态、实际交接、反馈和相关记录；结束时，再受控地写入判断、证据与下一步。角色之间传递的不是上一段聊天，而是 runtime 确认过的状态变化。
验证证据会绑定到当时的代码状态：产品仓的 revision、是否存在未提交改动、改动摘要。代码一旦变化，旧证据就不能自动证明新版本仍然成立。
会改变共享历史或外部环境的动作仍然保留独立授权。简单、一次性的工作则可以采用更轻的路径，让模型自行决定执行和检查方法；轻量化的是过程，不是外置记录、证据和授权这些底线。
代价与边界
Task-Driven 会使用更多时间和 token，也要求模型具备足够的理解和工具使用能力。它不是让弱模型突然变强的办法，也不保证产出一定更出色。
它换来的是另一种东西：结果更稳定，过程可以追溯，工作中断后能够继续，人和模型的责任也更清楚。
复杂、重要、需要多轮协作的任务，多付出的成本会看到更明显的回报。聊天、补全和单次问答仍然各有自己的位置。
对我来说，从使用 AI 到委托 AI，并不是把一句提示词写得更长，而是把可以变化的判断和不该变化的边界分开。
边界稳定下来之后，AI 才不只是一个随叫随用的工具，而开始成为可以接手工作的协作者。