人机边界

实现可以整段交出去，判断不能。判断指什么、哪些活能交、哪些必须留人，用一个三秒判断法定下来。

派活的写法，到这一篇只剩最后一课：这个活该不该交给它。判据只有一条——它能补全实现，补不上判断。这条分界线不画在能力上，画在责任上：实现是「照着已经定下的标准做出来」，判断是「定下这个标准、并为定错负责」。前一半可以整段交出去，后一半交不出去——因为它必须落在一个能担责的主体身上，而它没有这种资格。

读完你能回答：

「判断」落到你的日常里，具体是哪几件事？
一个三秒钟就能跑完的检查，怎么判断某件活能不能交出去？
哪些环节必须留一道人，为什么「看起来不用核对」的活反而最危险？
方向定完之后，交出去的动作该按什么顺序做？

这条线画在责任上，不画在能力上

它在「实现」这一侧近乎无限：写代码、出文档、批量整理、翻译改写、出初稿。快、不累、不限量，也不会因为重复而厌倦。这是它无可替代的价值。

它在「判断」这一侧接近于零：它没有立场，没有价值观，没有「这件事该不该做」的动机，也无法承担后果。它唯一做的，是给出「在给定输入下最顺的文字」。

因此分工的原则很简单：实现交给它，判断留给你。 判断给出方向和标准，它负责用最高效率把方向和标准变成现实。

换个角度说更清楚：它不会替你的团队担责。法律上不存在「这是它决定的」这种说法，也没人能在事故复盘会上代表它签字。欧盟《AI 法案》把高风险场景的人工监督写成硬性义务，理由就是同一条——责任必须落到一个能被追问的人身上。eu-ai-act 判断和执行、责任这三层怎么分工，你负责判断，它负责执行讲得更细。

判断这个词太抽象，落到工作里是四件事

做什么。「我们到底要做出什么」——答案只能从你的处境、手头的资源和不得不做的取舍里长出来，概率模型给不了。它能帮你把选项摆开比较，但选哪一个要你担着。
拿什么换什么。「这个功能值得做吗」「涨价的代价是什么」——涉及利益分配、长期和短期、对谁负责。这类取舍没有最优解，只有你选的那个。
产出对业务意味着什么。一份数据、一个结论、一次实验，落到你的生意上是好消息还是坏消息、要不要因此调整方向，这需要业务上下文，不在它的输入里。
结果能不能接受。「这样就够好了吗」「这个错误率能不能上线」——这是验收标准，也是它给不出的东西。它只能告诉你它做到了什么，不能告诉你这算不算够。

四件事有一条共同点：都需要有人承担后果。 所以把判断交出去，不是分担，是把自己的责任交给一个没有担责能力的东西。它省下的是「做出来」的时间，「决定该不该做」的那部分一点没少。

三秒三问，答不上来就降级

判断不是态度问题，是任务的性质问题。三个问题，三秒钟：

① 规则清楚吗？ 输入是什么、输出要什么、什么算完成，你能一句话说清吗？说得清，它可以做；说不清——「你觉得我们下一步该怎么走」这类没有边界的题——它会自己补一个你从没说过的目标，而那个目标多半不是你想要的。

② 错了能收回吗？ 草稿、试算、只给内部看的第一版，错了重来一次就好；已经发出去的报价单、被覆盖掉的原表、已经执行的付款指令，收不回来。判断一件事可不可逆，看的是有没有备份、有没有回退的路，而不是这个动作听起来像不像能撤销——「把这个环境重置一下」听上去总有办法复原，可如果那里面是唯一一份线上数据，重置就是终局。

③ 结果能核对吗？ 它交活了，你有没有办法看出对不对？有出处可查、有标准答案可比，或者能靠机器判定，那就敢放手；反过来，如果它编了东西你也发现不了，那就得先把核对的手段造出来，再谈放权。

三问里有一问答不上来，结论就是降级：加一道人工确认，或者把范围缩小。事故库里收录的案例，多数都能从这三问里找到根子——不可逆的动作被自动执行、影响被低估、核对被跳过。incident-db

注意第三问和「影响面」不是一回事：影响面不在这三问里，因为它衡量的是同一个动作值得配多少把关，而不是这个任务能不能交出去。它归下一节。

人停在哪几处，由错了之后会怎样决定

除了判断本身，还有几类活不能让它自己走完。它们的共同点是：做成之后，你没法把结果改回来，或者改回来的代价远超这件事的价值。

一、不可逆的动作。 把分支合进主线、覆盖生产环境配置、跑一次数据迁移、批量发出通知。这类动作的共同点是「做完之后没有回头路」，所以停顿时机在动作之前，而不是之后想办法。落到工程上靠权限与审批来拦——凭证不发出去，它就走不到那一步。owasp-llm 具体怎么按动作分级、审批该卡在哪一环，沙箱、凭证与人机边界讲的是这一层。

二、会出门的产出。 发给客户的报价单、对外公告、交给合作方的接口约定。它的影响面按最坏传播算，不按直接受众算——「只是内部传阅的版本」照样会被转出去。凡是要出门的东西，出门前必须有人看过。

三、核不了又后果严重的结论。 涉及钱、法律、健康、安全，而你没有办法独立验证它说法的真假：一次税务口径的适用、一份安全评估的结论、一段用药建议。这类活不是「做得慢」，是根本不该交给一个只会给出「像」的组件。

四、看起来不用核对的那种。「它只是把这份记录摘一下，不用查」——恰恰这类活最容易出错，因为模型编造时的自信程度远超过人的预想。越是这种活，越要多问一句：万一错了，我能不能知道？

还要说清楚：类别不是固定的，它取决于你怎么设计流程。一道机械校验加上去，原本不敢交的活可以变成「它做、代码查」；一个审批点插进去，原本不敢交的活可以变成「它做、人点头」。变的是你的流程，不是它的能力。

交出去的动作，按这个顺序做

先把方向和标准说清，再让它动手。同样是要一份东西，「把这次客户访谈整理一下」和「按角色、场景、待办三个字段整理，每条不超过三十字，原话里没有的不要补」，交回来的东西差别很大。方向交代得越清楚，它交回来的越有用——而方向本身从哪来，正是你贡献的那部分判断。

然后记住：用它给的方案，不用它替你做的决定。 让它把几条路线的成本、风险和迁移代价并排列出来，再标一句它更倾向哪条——注意，这句倾向只是为了让你比较起来省事，最终走哪条仍然由你拍板。

再往后是分工的最后一层：它出第一版，你过最后一关。效率的部分交给它拉满，质量的部分由你兜住。最后一关怎么过，三个动作筛掉大部分会害到你的错给的是动作清单：查来源、找反例、复算关键数字。

而放权本身是一段一段给的。不要设计一个「全自动」的功能然后祈祷它不出事，在设计的时候就把每个环节归好类，把该由人确认的点和该核对的点提前写进流程。信任不是靠祈祷，是靠设计。这条线怎么按阶段交出去，上线不是开关讲的是工程侧的做法。

最后一句：它是同事，不是上级，更不是替你顶罪的人。它替你省下的是「把事情做出来」的那段时间，「决定该不该做」的责任一点没少。与其把这条线当成一种限制，不如说，它正是你不可替代的理由。

能派的活想清楚了，下一章换下一个问题：同一个活，怎么让它从偶然做对变成次次做对。起点是一次只改一处的迭代方法。