# 让 AI 补全几行代码，和让它做完一整个任务，差在哪里

从正确性由谁定义、错误如何累积这两点，看清 AI 编程助手强在哪、不可靠在哪，以及人该站的位置

> AI 编程协作 · 长任务可靠性 · 代码审查 · 约 7 分钟 · 09 月 26 日

## 本篇要点

1. 补全和完整任务的区别不在代码行数，而在正确性从哪来：补全的判定标准由周围代码和你的即时判断现成给出，完整任务的标准必须先由你造出来。
2. 自然语言和代码之间的规格鸿沟意味着，程序越长，没被说清的分叉点越多，而这些选择会被模型默默替你做完。
3. 每步准确率会复利：99% 的单步准确率跑 100 步，全程做对的概率只有约 37%，所以把任务切短、让每步都能验证，比换更强的模型杠杆更大。
4. 模型看到自己先前的错误后更容易继续犯错（自我条件化），这让长任务里的准确率随步数下滑，而非保持常数；这项观察来自受控的合成任务，不等于所有真实项目都按同一比例退化。
5. AI 强在目标由外部给定、反馈即时、模式密集的局部任务，弱在需要跨多步一致或需要了解你项目内部约定的地方，尤其是边界情况、API 误用和复用已有抽象。
6. 你的职责从写代码转为定义正确、切分步骤、挑地方审查，并掌握上下文的归属权。

---

你大概已经习惯这种用法：写下一行，AI 接着补完；选中一段，让它改成另一种写法。这类用法很少让你失望。于是很自然地会想：既然一行能写，一百行是不是也能？我说一句“做一个增删改查的待办小工具”，然后去泡杯咖啡，回来收代码。

结果往往不是这样。不是因为它这次突然变笨了，而是因为**补全和完整任务，本来就是两种性质不同的问题**。把差别拆开看，你在协作里该站的位置也就清楚了。

## 一、补全的可靠，来自“正确性是现成的”

你让 AI 补全时，它面对的处境是：周围的代码已经在那里。变量名、类型、函数的输入输出、这段代码被谁调用、上一步算出了什么，全都摆在它眼前。它要做的只是把最合理的下一段填进去。

更关键的是：**你随时能判断它写得对不对**。类型不匹配、变量不存在、逻辑接不上，你扫一眼就知道，或者编辑器、编译器马上告诉你。写得不对，删掉，代价接近零。

这才是补全可靠的真正来源：**正确性的标准由周围代码和你的即时判断给出，不需要谁来定义。** 模型只需要做它最擅长的事——在密集的模式里预测接下来最像什么。

## 二、完整任务把问题换了个方向

现在你说“做一个可以增删改查的待办工具，数据存本地，命令行界面”。看起来更清楚了，但和补全相比，有一件事变了：**“写对了没有”这个标准，此刻还不存在。**

一项梳理 AI 软件工程挑战的综述把这段距离称为规格鸿沟（specification gap）：自然语言和你真正想要的代码之间隔着一层，你说的话永远比程序需要的细节少 [1]。比如“数据存本地”——存 JSON 文件还是 SQLite？文件名怎么定？两个进程同时写怎么办？“可以增删改查”——id 是自增还是随机？“命令行”——用什么解析参数？

这不是刁难。真正的问题是：**程序越长，这类没被说清的分叉点越多，而每一个分叉点，模型都在替你做决定。** 它不会专门通知你，这些决定被默默写进代码里。等你运行起来发现“这不是我要的”，代码却完全能跑、看起来也挑不出毛病。

所以完整任务的第一个本质区别是：**正确性不再由环境给出，而要你先把它造出来。** 你不说的地方不是没有答案，而是答案由模型代填。

## 三、任务变长以后，错误不是摊平，而是滚雪球

第二个区别更硬，也最能解释“补全很顺、整活儿就翻车”。

假设 AI 每一步做对的概率是 99%——这个水平已经很高，比多数补全场景的实际表现只好不差。一个需要 100 步的任务，全程做对的概率是：

$$0.99^{100}\approx 37\%$$

反过来读同一个式子：每一步的准确率哪怕只提高一点，能做成的任务长度就会成倍增长。这就是“每步准确率”和“任务能走多远”之间的杠杆关系。

但真实的退化比这个公式更糟。一项关于长程执行的研究发现，模型出错之后，**下一步出错的概率会升高**：当上下文里含有它自己先前的错误时，后续每一步的准确率都会下降，研究者称之为自我条件化（self-conditioning）[2]。也就是说，每步准确率不是常数，而是随任务推进往下掉——错误在污染它自己的判断。

还有一条独立的原因：上下文本身变长就会让模型变迟钝。Anthropic 的工程文章把它比作“注意力预算”——放进上下文的 token 越多，模型准确取用其中某条信息的能力越弱，他们把这个现象叫 context rot [3]。所以“把整个项目塞进上下文让它一次想清楚”，并不是一条可靠的路线。

需要说清边界：自我条件化是在受控的合成任务上观察到的，不等于所有真实项目都按这个比例退化；带推理过程的新模型受它的影响明显更小，单轮能执行的步骤数也长得多。所以结论不是“长任务一定失败”，而是**长任务里的错误有系统性累积的倾向，而且这种累积不是你多给点耐心就能抵消的**。

## 四、强弱分工因此变得具体

把上面两点合起来，哪些环节强、哪些不可靠，就不再是一句“看情况”：

**强的地方，共同点是目标由外部给定、反馈即时、模式密集。**

- 补完一个结构清晰的函数、写样板代码、把一段逻辑改写成另一种写法；
- 给已有函数补测试、解释一段报错、把错误信息翻译成可能的原因；
- 语法层面基本不出错。一项大规模分析发现，AI 生成代码里语法错误占比最低，功能错误占比最高 [4]。

**弱的地方，共同点是需要跨很多步保持一致，或者需要知道“你的项目里到底是怎么回事”。**

- 边角情况。同一项分析的真实项目基准上，在属于逻辑理解错误的那一类缺陷里，遗漏边界检查最常见，占 53.2% [4]。
- API 误用。在多数基准上，运行时错误里最主要的一类就是它：模型会照着训练里见过的形状，编出一个你项目里并不存在的函数或参数 [4]。
- 跨文件的约定。命名风格、模块边界、已有的抽象该不该复用——模型倾向于再写一遍，而不是接上你原来的结构。这个毛病在补全模式下几乎看不出来，因为补全时这些约定就摆在它眼前。
- 算法效率。功能正确但超时，在复杂问题上很常见 [4]。

所以不能靠“它上一个函数写得不错”，推断下一个环节也可靠。

## 五、你的职责变成了什么

到这里，协作方式的起点就清楚了。你不是从“写代码的人”变成“提需求的人”，而是变成**定义正确、切分验证、承担判断的人**。落到具体动作上是三件事。

**第一，把隐含的选择显式化。** 不是把需求写得更长，而是把“模型会替你决定、而你在意的那些分叉点”写出来：数据存在哪、id 怎么生成、出错时给用户看到什么。写少一点、说准一点，比写一大段模糊描述有用。

**第二，把任务切成能验证的短段。** 前面那个 0.99 的公式直接给出了理由：可靠性是每一步的函数，不是整个任务的函数。你能施加的最大杠杆不是换更强的模型，而是让每一步在很短的距离内就拿到验证——能编译、能跑过一个测试、能看到输出。有即时反馈时，模型可以在几步内自我纠正；没有反馈时，错误会一路带下去，还污染后面的判断。

**第三，审查要挑地方，而不是逐行重读。** 你不需要像读自己写的代码那样通读，而要建立“哪里可能错”的预判：边界条件处理了吗？它用的这个 API 在这个项目里真的存在吗？是不是把已有的函数又抄了一遍？这些恰好对应统计里缺陷最集中的位置。

最后一件容易忽略的事：**上下文的归属权在你手上。** 模型会在长对话里逐渐偏离最初的决定，也会被自己前面的错误带跑。所以要定期把“已经定下的约定”重新讲一遍，或者在进入新模块时开一段干净的上下文，而不是一路追加、指望它自己记住。

## 起点

所以这套协作方式真正的起点，不是“怎么让它一次写更多”，而是反过来问：**这一步写对了没有，我怎么知道？**

补全模式下你觉得它可靠，是因为这个问题被周围代码自动回答了。让它承担完整任务时，这个问题必须由你来回答——写清楚需求、切成小步、给每一步一个即时的验证信号。做到这些，它的能力才真正被用上；做不到，你拿到的只是一堆看起来能跑、却不知道对不对的代码。

## 术语表

- 规格鸿沟（specification gap）：自然语言描述和程序真正需要的细节之间的那段距离，说漏的部分由模型替你决定。
- 每步准确率的复利：一个任务的成功率约等于单步准确率的步数次方，所以步数一多，细微的准确率差距会被放大。
- 自我条件化（self-conditioning）：模型在上下文里看到自己先前的错误后，下一步出错的概率升高，使长任务的单步准确率随步数下降。
- 上下文腐化（context rot）：上下文越长，模型越难准确取用其中某条具体信息；可理解为模型的“注意力预算”有限。
- 验证信号：一次改动之后能立刻判断对错的反馈，比如编译通过、测试跑通、观察到输出；有没有它，决定了错误是当场被纠正还是一路累积。

## 来源

1. [Challenges and Paths Towards AI for Software Engineering — 规格鸿沟与人类-AI 协作可控性的综述性讨论](https://arxiv.org/abs/2503.22625)
2. [The Illusion of Diminishing Returns: Measuring Long Horizon Execution in LLMs — 每步准确率复利与自我条件化的受控实验](https://arxiv.org/abs/2509.09677)
3. [Anthropic: Effective context engineering for AI agents — 上下文腐化、注意力预算与上下文压缩](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
4. [What is Wrong with Your Code Generated by Large Language Models? — 生成代码缺陷分类统计，含真实项目基准上的边界检查缺失与 API 误用数据](https://arxiv.org/abs/2407.06153)
5. [SemBench: How well do LLMs understand code? — 代码生成能力与静态语义理解之间的差距](https://www.nature.com/articles/s44488-026-00014-y)

---

原文：https://pangzhengboyin.com/articles/code-completion-vs-full-task-with-ai-d257a949

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com