别再幻想「晚上让 AI 写代码，白天验收」了------从信息熵定律看大模型长任务自动化的天花板
摘要：很多人对 AI 编程有一个浪漫幻想：晚上写个需求文档丢给大模型，睡一觉起来就能验收完美代码。但现实是------任务越跑越偏，结果越来越离谱。这真的是大模型"不够聪明"吗？本文从一场深度对话出发，结合信息论与物理规律，揭示长任务自动化「漂移爆炸」的根本原因，并探讨可行的人机协作范式。
一、一个普遍的幻想
过去几个月，AI 编程工具的能力让人惊叹。Cursor、Claude Code、OpenClaw 等工具让开发效率大幅提升。尝到甜头后，一个念头几乎会出现在每个人脑中：
「能不能晚上把需求写好，让 AI 跑一晚上，早上来验收？」
听起来很美好------人类休息，AI 劳作，无缝衔接，效率拉满。
但现实很快给了冷冰冰的答案：除非你的场景极其简单，否则长任务几乎百分百会随着时间漂移甚至爆炸。什么 ReAct、CoT、自动化工件流都不好使。
这背后的问题，远比大多数人想象的要深刻。
二、表象：漂移与爆炸
为什么长任务会漂移？表面上的原因可以列出一串：
2.1 错误的累积放大
复杂任务涉及多步骤决策、外部工具调用、环境变化响应。模型在链式推理中，一旦某一步产生轻微偏差，就会像多米诺骨牌一样放大成后面步骤的严重错误。
2.2 长上下文的"遗忘"
虽然现在上下文窗口能到 128K、1M tokens，但模型在长序列中检索和保持关键信息的能力依然有限------早期设定可能被遗忘，中间状态可能被误解。
2.3 环境的不确定性
如果任务涉及网站操作、API 调用，目标界面或数据格式随时可能变化。模型缺乏真正的实时自适应和异常处理机制，容易卡死或跑偏。
2.4 无监督自纠正能力弱
当前大模型能在单轮对话中做一定自我修正，但在长时间跨度的自主执行中，没有人工干预的情况下，它极难识别自己已经偏离目标------更别说回溯到正确路径。
这些原因听起来都挺合理，似乎都是技术问题。改进模型、优化框架，总能解决吧？
答案是：不对。这些只是表象。
三、本质：信息熵定律的硬约束
信息是不会自己凭空产生的。如果真的凭空产生了，那也只是无意义的噪声。
这句话切中了问题的核心。
3.1 需求文档的信息缺口
从一个需求文档到可运行的代码，本质上是一次「信息量大幅扩张」的过程。
需求文档只是骨架，大量细节没有被记录------不是因为写的人不认真，而是因为很多细节只有在做的过程中才会浮现出来。真人开发尚且需要反复跟产品经理对细节，何况是一个本来就"不够聪明"的 AI？
用信息量低的需求文档，生成信息量巨大的代码，这中间的信息差，必须有来源来填补。
3.2 信息增量的三大来源
从需求到代码，增加的信息来自三个渠道：
- 大模型训练数据中的知识储备（从互联网学习的常见模式）
- 互联网实时检索（联网搜索补充）
- 你（需求方）提供的增量信息（需求文档 + 过程中的沟通澄清）
前两个来源能覆盖大多数通用场景，但你的需求是高度定制化的 ------总有那么一部分信息，既不在训练数据里，也不在互联网上。这部分信息，只能由你来输出。
3.3 为什么「一次性需求文档」行不通
这就好比产品经理的需求文档不可能滴水不漏------
- 你在写需求时，自己也不一定知道所有细节
- 开发过程中，遇到模糊点才会发现「这里需要确认」
- 这个「确认」就是增量信息传递的过程
在「晚上全自动」模式下，增量信息传递的通道被切断了。模型只能二选一：
- 选项 A：停下来 → 任务卡死，什么产出都没有
- 选项 B：靠「脑补」填坑 → 产生的结果偏离预期
模型几乎总是选择 B。因为它没有能力判断「这里需要停下来问问」，它的本质是「根据已有信息生成下一个 token」，当信息不足时，就基于训练数据中的常见模式进行脑补。
问题是：脑补一旦方向错了，后面就会全盘偏离。而且偏离程度随任务复杂度指数上升。
四、用类比来理解
换一个角度想这个问题：
如果把 Agent 换成真人，你写一个需求文档后甩给他，拆任务、分给各个开发做，然后你去睡觉。一晚上他能做好吗？
大概率做不好。
不是因为人不够聪明，而是因为需求文档不可能說清每一个细节。需求文档只是主要的骨架，大量细节天然缺失。真人做需求也得不停地跟产品经理对细节------结果你去睡觉了，把一个本就不聪明的 AI（或者一个无法沟通的人）丢在那儿去猜这些细节，不跑偏才怪。
所以，不是 AI 不够聪明，而是这种工作方式本身就存在结构性的缺陷。
五、大模型不是许愿机
很多人潜意识里把大模型当成了「许愿机」------只要说出粗略愿望，机器就能理解全部隐含约束并完美实现。
这是一种对智能的误解。真实智能（无论是人还是 AI）都需要：
- 足够的信息输入（显式约束与隐式约束）
- 与环境实时互动来消除不确定性
- 在不确定时能够主动寻求信息，而不是盲目猜测
当前大模型第 3 点能力还很弱。即使设计了「遇到不确定时提问」的指令，模型对「不确定」的判断也很不可靠------它经常在不清楚的情况下依然「自信」地执行错误操作。
大模型不是神，它不应该被要求突破物理规律：在信息输入封闭的条件下，实现信息增量的输出。
六、当前可行的解决方案
认识到问题的本质后，解决方向不再是无谓地追求「让模型更聪明」，而是设计允许信息增量同步的工作流。
6.1 人在回路（Human-in-the-Loop）
当前阶段人机协作的合适模式应当是「人在回路」，而不是「人完全脱手」：
- 模型承担大量机械性、模式明确的子任务
- 遇到模糊、依赖新信息、或可能产生连锁影响的决策点 → 自动暂停并请求人工澄清
6.2 三层安全防御体系
实践中，一套行之有效的安全机制分为三层：
第一层：流程控制（核对-审批-求助）------在「决策」层面建立安全门
- 核对：对模糊指令主动调研、提方案、向用户确认，在意图层面对齐
- 审批：为工具行为划分风险等级------低风险（读文件）自动放行；高风险（删除、修改）请求用户确认
- 求助：遇到超出能力范围的情况，尽早暴露问题而非硬着头皮瞎做
第二层：环境隔离（沙箱）------在「执行」层面建立试验场
- 脚本、高风险操作先在沙箱预演
- 不仅能捕获恶意代码，更能发现幻觉导致的反直觉逻辑错误
第三层：边界限制（工作区）------在「访问」层面建立围墙
- Agent 默认只能在工作区内操作，通过最小权限原则缩小破坏面
- 即使安保前两层被突破，破坏范围也被严格限定
6.3 工程化的分工设计
架构层面：「核心思考 + 核心执行 + N 个细分功能 Agent」
- 验证 Agent、反思 Agent、修正 Agent、结构化输出 Agent 等独立、职责单一
- 每个小 Agent 更容易通过 Prompt、Few-shot、Fine-tuning 稳定其行为
- 一个模块故障不会导致整个系统崩溃
- 可独立优化、可并行执行
七、未来展望
回到那个问题：「晚上干活白天验收」什么时候能做到？
坦率地说，当前的纯 LLM 架构下，复杂任务的完全无人值守还不现实。要真正实现，可能需要：
- 更强大的世界模型与推理框架------模型本身具备更强的长期规划与自我纠错能力
- 强化学习与长期记忆------让 Agent 从成功和失败中学习，积累经验库
- 程序辅助的规划与验证------用确定性逻辑处理结构化子任务，LLM 只处理需要灵活理解的部分
- 新型的需求表达方式------不再是「写一个文档」，而是「在交互中逐步明确需求，由模型实时记录为可执行规范」
但即便未来模型更强，只要信息输入不充分、反馈不及时，漂移就不可能完全消除。
这不是一个技术迭代能翻越的坎，这是信息论的基本约束。
八、总结
回到三个核心认知：
| 层次 | 认知 |
|---|---|
| 表象层 | 长任务漂移 = 多步骤错误累积 + 长上下文遗忘 + 环境不确定性 + 无监督自纠正弱 |
| 本质层 | 信息不能凭空产生。粗文档→详细代码的信息差，需要实时沟通来填补。无人值守切断了这个通道 |
| 实践层 | 人在回路 + 三层安全体系 + 细粒度分工，让 AI 在清晰边界内工作，模糊地带由人介入 |
大模型不是许愿机，复杂任务的「全自动夜间开发」也不只是技术问题------它是一个信息供给与消耗的基本约束问题。放弃幻想、面对现实、设计合理的人机分工，才是当前阶段的正解。
你觉得呢？欢迎在评论区聊聊你的实践经历。