让 AI 一次写完和分步交活，差别有多大？

柏林ACS · 2026-08-01 · 读完约需 5 分钟

同一个团队，同一个模型，同一个任务，先后用两种方式各跑了一遍。

第一种方式是做数据库迁移，让 AI 一口气写完整的迁移脚本：建表、迁移、校验、回滚，结构漂亮，注释齐全。

执行到中途，脚本挂了。排查发现，开头有一个假设就错了——它假定旧表的某个字段永远非空，而线上数据里确实存在不少空值。后面的迁移步骤全都建立在这个假设之上：错得整整齐齐，错得逻辑自洽。

第二种方式是换个用法。还是同一个模型，这次要求先给迁移计划，分阶段执行；每完成一段，先在测试库跑一遍，把结果贴回来，确认无误再生成下一段。

这次慢得多，但每一步都落在真实数据的地面上。很快就暴露了一个字符集问题——按上次的方式一口气写完，这个问题会拖到什么时候才出现，谁也说不准。

同样的模型，同样的任务。初始化、目标、空间都可以做得一样充分，差别在"怎么走"。

差别背后是一个结构事实：默认的搜索是开环的。前几篇说过，搜索的每一步只看"下一步是否合理"，沿概率最高的方向往前延伸。从起点到终点，中间没有任何环节把"走得对不对"的信号送回来。那份一口气写完的脚本就是开环的产物：开头的错误没有被任何环节拦截，后面的每一步都在忠实地放大它。

这就是四层结构的最后一层：搜索运行——搜索真正展开的过程，一步一步怎么走。这一层的全部机制，可以理解为同一件事：给开环的搜索装上闭环。四个最实用的做法：

拆开走，每步落地再走下一步。 "先给计划，分步执行，每步把运行结果贴回来确认。"这不只是稳妥，还有一个隐蔽的原理：先完成的部分会变成后续部分的初始状态——第一步走对了，后面每一步的起跑线都更可靠；第一步埋了雷，雷会跟着走进后面每一步。

让环境说话。 调用工具查真实文档、执行代码看报错、读 API 的真实返回。环境信号是搜索过程中重要的外部校验：搜索路径上的每一步都能自洽——错误也能自洽，但环境不讲自洽，测试红了就是红了。

别迷信"让它自己检查一遍"。 自我反思能拦住粗心的错，拦不住系统性的盲区——检查者和被检查者是同一套认知，带着同一个偏置走岔的路，很可能带着同一个偏置通过复查。真正可靠的是外部标准："我觉得我对吗"和"客观标准认为我对吗"，是两回事。所以能用测试验证就不靠自查，能读真实反馈就不靠自我感觉。

定好止损线。 "连续两次验证失败，就放弃当前路径，退回起点换一条根本不同的路线。"没有这条线，闭环会变成死循环：失败，修正，再失败，无限重试，在一条死路上耗尽所有预算。

四个做法连起来，其实就是一个微型工作流：计划→执行→验证→止损。用得多了会发现，规划、检查、执行、验证渐渐由不同的对话来承担——同一个模型，不同的职责分工。这差不多就是后来人们说的 Agent 的雏形，那是书的后半部分要展开的事。

运行层的完整机制，出自《AI认知搜索理论》的第七章（搜索运行），书里有那个迁移团队的后续：他们把这四步固化成了标准流程。

到这里，四层结构全部走完：从什么状态起跑（初始化），为了什么而搜（目标），能去哪些地方（空间），怎样走完全程（运行）。接下来几篇连载，我们换个口味：拿这张四层图，去诊断几个真实场景里翻车的 AI 协作——你可以猜猜，它们各自卡在了哪一层。