AI 真的让开发更轻松了吗?——不见得

我爱免费

作者：微信文章
有了 AI 之后，开发人员的工作量其实不但没有减少，反而在很多场景下明显增加了。至少对我来说，这种增加主要体现在两条线：

用 AI 辅助写代码的传统开发； 基于大模型做智能体（Agent）的开发。

---

一、用 AI 写代码：从「自下而上」变成「自上而下」的黑盒

在 AI 普及之前，我们构建系统通常是典型的「自下而上」路径：

一个功能点一个功能点地实现； 每完成一个最小工作单元，就写对应的单元测试； 确保每个小模块的逻辑完全符合预期； 最后再把这些小模块像积木一样拼出一个完整系统。

这种方式有几个显而易见的优势：

每个微小功能点都在我们的掌控之中； 一旦整体功能有偏差，可以很快定位到是哪一个小模块出了问题； 程序员对系统从整体到细节，都有比较精确的认知。

---

用 AI 之后：从「能跑」到「难维护」

当我们开始用 AI 来生成代码之后，构建方式悄悄发生了变化，变成了「自上而下」：

我们向 AI 描述一个「大致」的业务需求，再补充一些关键模块的要求； AI 一次性生成一大坨看上去「差不多能跑」的代码； 我们做几轮简单测试，发现功能基本可用，于是心理上就很容易放松警惕。

问题恰恰就出在这个「大致可行」上。

我们很容易默认 AI 生成的代码是可行的； 测试更多是验证「能不能跑起来」，而不是像以前那样精细校验每个单元逻辑； 模块之间如何衔接、如何通信、数据如何在系统中流动，并没有被真正梳理清楚。

于是，开发过程变成了：

前期很爽：进度看起来飞快，功能很快「成型」； 后期极其难受：

维护时你会发现很多代码根本不知道是干什么的； 要搞清楚，只能回到最原始的方式：一行一行地 debug，一块一块地重新建立自己的理解。

本质上，用 AI 写项目，只是帮我们快速搭了一个大致符合需求的框架，但：

底层细节对开发者来说几乎是个黑盒； 细节掌控感被弱化了； 真正的工作量，从「前期构建 + 单元测试」转移成了「后期维护 + 逆向理解」。

AI 带来的第一个痛点：细节缺失，掌控成本上升。

---

二、做智能体：提示词工程是一块新的「巨大工作量」

另一条工作线，是基于大模型的智能体开发。

我最近一直在做智能体相关的东西，而且还只是相对简单的单一智能体：

通过 Function Call 的方式对接外部系统； 写各种工具（Tool）、API 接口，或者更高级一点的 MCP 服务。

从工程实现上看，这部分和传统开发的差异并不大：

定义接口、参数、返回结构； 实现业务逻辑； 做常规的测试与部署。

真正不一样、也最消耗精力的，是智能体的系统提示词（System Prompt）。

---

系统提示词的两难：写长不行，写短也不行

系统提示词有一种天然的矛盾：

写长一点：

可以把每个细节逻辑交代得非常清晰； 但提示信息一多，给模型的上下文过于庞杂，反而容易引发幻觉； 输出结果不够聚焦，精细度下降。


写短一点：

指令简洁干练； 但很多关键细节没法说清楚； 模型只能「靠猜」，很难完全按照我们心目中的规格执行。

实际项目中的体验是：

提示词的构建、调整、调优与测试，本身就是一项非常耗时的工程工作。

结合自己的实践经验，大致可以这么粗略估算一下一次智能体开发的工作量：

约 1/3：工具（API / MCP 等）的设计与实现； 约 1/3：对需求、场景、功能点的理解与拆解； 约 1/3：提示词的构建、调优与各种测试。

也就是说，从整体工作量上看，智能体开发并没有因为用了大模型而省掉多少时间，反而新多出了一整块「提示词工程」的工作。

---

那 5% 的错误，会要你半条命

大模型本质还是在做概率推断。

就算你调教得很好，一些比较「强」的智能体能做到：

95% 左右的准确度。

听上去已经很不错了，但问题在于：

一旦剩下那 5% 的错误，刚好发生在关键场景上，你的感受就会非常糟糕； 落地到工程层面，这 5% 就是各种诡异 bug 的来源。

为了解决这 5%，我们通常需要从两个方向持续投入：

优化工具结构与编排

调整工具的设计、调用顺序、异常兜底策略等； 这一部分和传统工程开发非常类似，几乎是老本行。


进一步优化提示词

不误解、不遗漏任何关键信息点； 同时还要保持表达简洁，避免上下文噪音。



本质上，你是在给一个「很聪明，但又很抽象」的对象讲一个复杂故事； 你希望 TA 能百分之百准确地理解你的意图： 要做到这一点，其实非常难，而且非常费脑力、费时间。

---

三、工作量没降低，只是换了一种形态

综合以上两条线，我现在的总体感受是：

基于 AI 的开发，整体工作量并没有明显降低，很多时候反而增加了。

区别主要在于：

过去：

更多时间花在「手写代码 + 单元测试」上；

现在：

大量时间花在「理解 AI 生成的代码」、 「优化提示词」、 「设计工具编排与容错机制」上。

从知识层级的角度看，新增加的这些工作：

确实比传统纯业务编码要更「抽象」一些； 更需要系统设计能力、建模能力和表达能力； 更考验对复杂系统的调试与溯源能力。

但如果只问一句简单的话：

“AI 让开发更轻松了吗？”

我的回答是：

它并没有真正帮开发者省掉多少工作量，
只是把工作从「写代码」的一端，迁移到了「理解 + 调教 AI」的另一端——
代码可能少写了一些，但脑子要多动很多。

仅此而已。