什么能出环，什么必须留在人这一侧

关于自动化的争论，通常落在模型能力上：它读不读得懂、推不推得动、难题上表现如何。人机分工不在这里决定。它由一个问题决定：这件事需要的输入，能不能被送进一个接口。能，就可以出环；不能，就留在人这一侧，模型多强都一样。

注意这条判据回答的是什么。它回答「谁来做」，不回答「AI 够不够好」。一件事完全在模型能力范围内，仍然可能是出环的坏候选，因为它依赖的上下文待在一个接口读不到的地方。

五种送不进接口的输入

送不进去的输入可以归成很短的几类。贴在物理环境里的便条。藏在方言和口语简称里的判断。房间里两个人之间的实时反应。流程文档与执行版本之间的差额。旧文档里、以及已经离职的人留下的隐喻和半句话。

这份清单上的每一条都是上下文问题，不是智力问题。没有一条在说模型太弱；每一条都在说，接口看不见判断所依赖的那个东西。

三种情况

结构化输入——规整的表格、报文、字段、协议——可读、可加工、可监控，今天就能出环。

非结构化输入——手写便签、私人 Excel、方言、肌肉记忆——必须先被显化。显化本身就是那件工作，也是最容易被低估报价的部分，因为它看起来像写文档，实际干的是工程。

伪结构化输入——形式规整，但描述的是 SOP 版本而不是执行版本——在往上搭任何东西之前，必须先做版本对照。跳过这一步，自动化会完美地跑在一个并不存在的流程上。

三次失败，同一个结构

出环的三种典型失败很好复述：自动审批漏掉了那一项本来绝不该批的；自动质检漏掉了那一张预示整批报废的回流工单；自动告警漏掉了凌晨两点那一条真正要紧的。

任务不同，结构相同：在这些例子里，本该拦住它的那条上下文只出现在异常路径上，而异常路径从来没有被固化进接口。不是模型不够聪明，是接口太窄。

这对系统怎么建有直接影响。正常路径是你做测试的地方，因为正常路径上才有样本；异常路径是你失败的地方，因为异常路径上按定义就没有样本。所以出环的前提不是测试集上的准确率，而是：在人退出之前，判断所需的上下文已经被固化到接口读得到的地方。

那个人在环里，其实不在

一个确认按钮不是控制。当审批请求来的速度超过一个人思考的速度，审批就变成条件反射：Anthropic 的遥测显示，用户会批准约 93% 的权限请求——那不是信任的证据，是注意力耗尽的证据。解法不是把警告写得更严厉，而是把边界下沉到系统里，默认拒绝，让例外来向人要注意力，而不是指望人自己发现。

对任何「人工复核」环节都可以问一句：这个人要能反对，他得知道什么？如果答案是「系统知道的全部」，那这道复核就是装饰。

编制单位：席位

编制的单位不是一个人，也不是一个 Agent，而是一个席位：一名人类加一个配对的 Agent。四层要分清，因为它们的可替换性不同。魂是判断与可携带的记忆，不可替换；骨是任务结构、判据和评估集，可以迁移；肉是具体技能与工具链，可以替换；皮是交互界面与渠道，也可以替换。

由此得到一条很短的规矩：壳可以换，魂必须留。换了个模型重建、但判据和评估集丢了的 Agent，是一个没有记忆的新人，跑分再高也一样。

上下文五标准

固化进接口的上下文要满足五条：关联，只放与当前判断相关的信息；充分，判断所需的不缺；隔离，一个任务的失败不能污染另一个任务的状态；经济，上下文的成本要被计算；可溯源，每条证据都能指回来源。这五条是显化工作的质量线，它长在交付方法里面而不是旁边——每一条在哪个环节被检查，见五阶段交付方法。

判据，落到动作

把这件事需要的输入一行一条写下来，每条注明它现在存在哪里。只要有一行写着「在她脑子里」「在群里」「在一份已经和实际工作对不上的文档里」，这条输入就还不能出环。这时候硬上，不是自动化，是删掉一个检查点，然后把删掉这件事叫提速。