当 AI 能写 80% 的代码，剩下 20% 是什么？

Thu, 07 May 2026 00:00:00 +0000

当 AI 能写 80% 的代码，剩下 20% 是什么？

当 AI 能写 80% 的代码，剩下 20% 决定你值多少钱。

一、一个让人愣住的瞬间

用 AI 写代码的人，大概都有过这样的时刻：

一个功能模块，搁以前至少得写一天——定义接口、写解析逻辑、处理异常、补单元测试。现在呢？描述一下需求和数据格式，AI 噼里啪啦就生成了。review 一遍，改几个边界 case，提交。

然后你愣住了。

我刚才干了啥？我"编程"了吗？

仔细回想，做的工作是：描述需求 → 审查代码 → 修修补补。写代码的主力是 AI，开发者更像是一个"代码质检员"。

这个问题像一根刺一样扎在脑子里：当 AI 能写 80% 的代码，剩下 20% 是什么？我到底是开发者，还是 Prompt 工程师？

二、Vibe Coding 的狂欢与翻车

2025 年初，Andrej Karpathy（前 Tesla AI 总监）提出了一个概念叫 “Vibe Coding”——不看代码细节，凭感觉让 AI 写，能跑就行。

这个概念迅速流行。一时间，人人都可以用 AI 写 App，不会编程的人也能"做产品"了。社交媒体上到处是"我用 AI 一天做了个完整应用"的帖子。

然后翻车开始来了。

有数据显示，7% 的 vibe-coded 应用带着裸奔的数据库上线了。不是 AI 写得不好，是使用者根本不知道什么叫"安全"。他们能描述功能，但描述不了约束。

Karpathy 自己后来也修正了路线，提出了一个演进框架：

Vibe Coding → Context Engineering → Agentic Engineering
凭感觉写 → 精心设计上下文 → 让 AI 自主完成任务

大多数人还停留在第一阶段。而真正的价值，在第二阶段。

三、三个绕不开的场景

场景一：代码风格——没给规范，怪谁？

刚开始用 AI 写代码的时候，很多人都会犯同一个错误：直接开干。

结果呢？生成的代码风格跟团队规范完全对不上——错误处理方式不对、日志格式不对、命名约定不对。第一反应是：这 AI 也不行啊。

后来学乖了。把团队的 .cursorrules 配好，把代码规范文档喂进去，再贴几段项目里现有的代码作为示例。

输出立刻对味了。

AI 不是不懂你的风格，是你没告诉它。 这就像带新员工——你不培训就指望人家按你的规矩来，可能吗？

场景二：性能问题——能搞定，但费 Token

代码跑起来了，但性能不达标。把日志、profiling 输出、相关代码一股脑丢给 AI。

AI 确实能给出分析方向，但过程往往是这样的：

给了一段日志 → AI 说可能是锁竞争
补充了锁相关的代码 → AI 改口说可能是 GC 压力
又给了 GC 日志 → AI 说可能是内存分配模式有问题
来回好几轮……最后自己看了火焰图，一把定位到根源

Token 烧了一堆，结论是：AI 有定位能力，但效率取决于上下文的完整度。给少了它猜，给多了它准。

问题是，“给多少算够"这件事，本身就是个技术活。

场景三：业务理解——代码里藏着的隐形逻辑

让 AI 写一段数据校验逻辑，它写得又快又漂亮。但一跑，业务方说不对。

为什么？因为那段校验逻辑里藏着业务规则：某个字段在特定条件下才能为空、某个状态流转只能单向、某个阈值会随季节调整……这些规则不在技术文档里，在业务方的脑子里。

AI 不知道这些潜规则，它只能按照你给的需求字面意思写。代码逻辑里暗藏业务逻辑，业务理解不到位，写出来的代码就是不能用。

你得一条一条纠正。但有趣的是，纠正一次之后，它就能跟着对了——前提是上下文窗口还装得下。

四、一个新概念：上下文工程

这三个场景有个共同点：AI 的输出质量，取决于你给它的输入质量。

这不是什么新道理——计算机科学早就有句话叫 “Garbage In, Garbage Out”。但在 AI 编程时代，这句话有了新的含义。

Martin Fowler 的团队在 2026 年初写了一篇文章叫 “Context Engineering for Coding Agents”，给出了一个精辟的定义：

“Context engineering is curating what the model sees so that you get a better result.” （上下文工程就是精心策划模型看到的东西，以获得更好的结果）

他们把上下文分成了两类：

Instructions：告诉 AI 做什么——“写一个 E2E 测试”
Guidance：告诉 AI 遵循什么——“测试要相互独立，不要共享状态”

我之前代码风格不对，本质是缺了 Guidance。Bug 定位低效，是 Instructions 里的信息密度不够。业务理解差，是上下文窗口的物理限制。

场景	问题根源	解法
代码风格不对	没给规范约束	喂 `.cursorrules` + 代码示例
Bug 定位低效	上下文不完整	一次性给足日志 + 代码 + 复现步骤
业务理解差	窗口装不下	分层喂知识，先给架构再给细节

核心观点：AI 的能力边界，本质上是你构建上下文的能力边界。

五、放大器效应：为什么资深开发者用 AI 更香

这里有一个很容易被忽视的点：AI 对不同水平的开发者，放大倍率是不一样的。

新手 + AI = 1 × 2 = 2
资深 + AI = 10 × 2 = 20

新手不知道该问什么、该检查什么、该约束什么。他们给 AI 的上下文是模糊的、不完整的，所以 AI 的输出也是平庸的。

资深开发者知道：这个模块的边界条件是什么、这个并发场景的坑在哪里、这个客户的合规要求有哪些。他们给 AI 的上下文是精准的、结构化的，所以 AI 的输出也是高质量的。

AI 是放大器，不是替代品。它放大你已有的能力，但没法凭空给你能力。

这也解释了一个现象：很多人用 AI 写代码，觉得"也没多厉害啊”。不是 AI 不厉害，是你给它的上下文不厉害。

六、一个前瞻：AI 友好的代码库

Martin Fowler 的文章里还提到了一个概念：AI-friendly codebase design。

意思是：你的代码本身就是给 AI 的"文档"。命名清晰、模块化、有好的注释——这些本来就是好实践，现在多了一个理由：

让 AI 更好地理解你的代码。

想想看，当你把一段代码丢给 AI，如果这段代码命名模糊、逻辑混乱、没有注释，AI 能做的就是"猜"。但如果你的代码自解释、模块边界清晰、有完善的类型定义，AI 就能精准地理解你的意图。

这是一个正向循环：

好代码 → AI 理解更准 → AI 生成更高质量的代码 → 代码库更好

反过来也成立：

烂代码 → AI 理解偏差 → AI 生成更烂的代码 → 代码库更烂

AI 会加速你的代码库演进方向——无论是向上还是向下。

七、所以，我们到底是什么？

回到开头的问题：我到底是开发者，还是 Prompt 工程师？

我觉得这个问法本身就错了。正确的问法是：你是在写 Prompt，还是在做上下文工程？

Prompt 工程师：琢磨怎么写提示词让 AI 听话
上下文工程师：设计 AI 的认知环境，让它能精准输出

区别在于，Prompt 是一次性的，上下文是系统性的。

一个好的上下文工程师，需要：

架构能力：知道系统该怎么拆，模块边界在哪
业务理解：知道需求背后的真正意图
代码审美：能看出 AI 生成的代码哪里不对劲
调试直觉：AI 搞不定的 bug，你能搞定

这些恰恰是资深开发者的核心资产。AI 没有让这些资产贬值，反而让它们更值钱了。

Andrej Karpathy 的演进路线还在继续：

Vibe Coding → Context Engineering → Agentic Engineering
凭感觉写 → 精心设计上下文 → 让 AI 自主完成任务

我们现在处在第二阶段。而能做好 Context Engineering 的人，才有资格进入第三阶段。

写在最后：

“Prompt 工程师"不是贬义词，但只会写 Prompt 的开发者是。

真正的技能不是写 Prompt，而是构建一个让 AI 能精准输出的"认知环境”。这需要架构能力、业务理解、代码审美——这些都是时间和经验换来的，AI 给不了你。

所以下次有人问你是干嘛的，别说"我写 Prompt 的"。

说"我是上下文工程师"。

参考：

开发者 on Yison's Blog

当 AI 能写 80% 的代码，剩下 20% 是什么？

当 AI 能写 80% 的代码，剩下 20% 是什么？

一、一个让人愣住的瞬间

二、Vibe Coding 的狂欢与翻车

三、三个绕不开的场景

场景一：代码风格——没给规范，怪谁？

场景二：性能问题——能搞定，但费 Token

场景三：业务理解——代码里藏着的隐形逻辑

四、一个新概念：上下文工程

五、放大器效应：为什么资深开发者用 AI 更香

六、一个前瞻：AI 友好的代码库

七、所以，我们到底是什么？