模型越强，程序员越没用？这个问题问反了

模型越强，程序员越没用？这个问题问反了

最近，一个问题正在开发者群体里悄悄蔓延——

GPT 能写代码，Claude 能审需求，Cursor 能自动补全整个函数……

那我们还有什么用？

很多人的第一反应是"赶紧学 Prompt"，或者"赶紧学最新框架"。

但我今天想告诉你：这两件事，可能正在把你引向一条越走越窄的路。

---

先说一个让人不舒服的真相

过去两年，有一类开发者的工作正在以肉眼可见的速度被替代——

他们写的代码，本质上只是在"帮模型打补丁"：

• 手写正则，因为模型输出格式不稳定
• 切分文本块，因为窗口只有 4K
• 维护一堆 Prompt 模板，因为模型容易"跑偏"

这类工作有个专有名词，叫补偿性工程。

它的特点只有一个：模型能力每进化一步，你的代码就作废一批。

128K 窗口一出，分块代码没了。Tool Call 原生支持了，手写解析器没了。

这不是危言耸听，这是框架的更新日志。

---

但还有另一类工程师，越来越值钱

他们不研究怎么"绕过"模型的局限，他们研究一个更本质的问题：

如何把一个天生不可控的黑盒，变成一套稳定可靠的业务系统？

这件事有个核心公式，非常简单，但大多数人没想透：

Agent = Model（发动机）+ Harness（驾驭系统）

模型是引擎，是别人造的，你控制不了它的概率分布。

但 Harness 是你造的——方向盘、刹车、仪表盘，整套底盘都是你的。

你的价值，不在于造引擎，在于造那辆车。

---

那辆"车"，到底由哪几个零件组成？

零件一：上下文管理——上下文即逻辑

传统开发：数据存数据库，逻辑写在代码里。

Agent 开发：提示词的顺序、注入的时机，直接决定模型下一步往哪走。

一个反直觉的事实：上下文窗口再大，也是稀缺资源。

把所有背景信息一股脑塞进 Prompt，就像往新员工桌上堆了三米高的文件——他反而连一支笔都找不到。

真正的技术在于：在对的步骤，注入对的信息，压缩掉无效的噪音。

---

零件二：控制流设计——你是裁判，不是操作员

传统代码是流水线：A → B → C，死的。

Agent 系统是棋盘：模型是棋子，下哪步由它定——但合法着法的边界，由你划定。

一个被低估的技巧：强制模型在行动前先写计划。

实测数据表明，这一步能让复杂任务的成功率翻倍。

不是因为模型变聪明了，而是因为你给它装上了"先想后做"的约束。

---

零件三：错误恢复——拒绝盲目重试

AI 报错，不是你的代码有 Bug，而是概率系统的天性。

很多人的第一反应是：加个 for 循环，retry 三次。

但如果模型失败的原因是"缺少信息"，给它 100 次机会也没用——就像给一个没有密码的人 100 次重试机会，他依然登不进系统。

正确的做法是：分析它缺了什么，精准补全之后再试。

这是工程师的工作，不是模型的工作。

---

零件四：反馈回路——给模型装上后视镜

传统监控大屏是给人看的。

Agent 时代的反馈，是给模型看的。

把执行结果实时塞回上下文，逼迫它自我修正；把未完成的计划表贴在它眼前，防止它在长对话中"执行漂移"；在耗时任务完成后，像发微信一样通知它："数据已就绪，请继续。"

还有一个高级玩法——波浪策略（Wave Strategy）：

• 规划阶段 → 最贵、最强的模型（昂贵的大脑）
• 执行阶段 → 廉价、快速的小模型（廉价的肌肉）
• 校验阶段 → 再拉回强模型挑错

同样的成本，三倍的可靠性。

---

最后，一个值得收藏的类比

有人问：如果未来模型窗口无限大、永远不报错了，工程师还有用吗？

回顾一下 CPU 和操作系统的历史：

过去几十年，CPU 性能提升了百万倍。

操作系统消失了吗？

没有——它反而因为底层算力的激增，变得更庞大、更复杂了。

底层越强，越需要复杂的系统去调度它。

更何况，还有一件事模型永远感知不到：物理世界的熵。

API 返回 500，服务器超时，网络抖动……这些混乱，存在于黑盒之外。

如何做故障隔离，如何实现断点恢复——这座桥，只有工程师能造。

---

写在最后

框架会过时，API 会废弃。

但在概率性的不确定之上，强行构建出业务所需的确定性——

这是 Agent 工程师永不过时的护城河。

不要和模型赛跑。

去造那辆车。

---

觉得有收获，点个赞、在看、转发支持一下；想不错过更新，记得星标⭐。下次见。

本文由mdnice多平台发布