AI编程不是许愿：一位”万元玩家”踩过的所有坑

花了一万美金买token，最后得出”要学Haskell”的结论——这不是AI的错，是用法错了。

一个昂贵的教训

最近读到一篇很有意思的实践复盘。作者自称在AI编程上投入超过一万美元，试遍了Opus 4.6、Codex-5.3-xHigh、Gemini 3 Pro等顶级模型，最后得出的结论是：AI coding不行，得回去学Rust和Haskell，甚至要给数据结构加形式化验证。

一万美金。让我换算一下——这是50个月的Claude Max订阅费，或者一台顶配MacBook Pro。

投入这么多，最后的药方是”回归传统CS”？这让我想起那个经典笑话：花大价钱买了辆特斯拉，发现不会开，于是得出结论——电动车是骗局，还是马车靠谱。

问题不在车，在驾驶技术。

作者的失败案例很有代表性：让agent为Kotlin项目集成GCP Transcoding服务，只给了一句话描述。Agent通读文档后，决定用Ktor-client手动实现RESTful接口。结果？作者抱怨agent”蠢”，说人类一眼就知道该包装Java SDK。

等等。你告诉新来的实习生”把这个功能做了”，他会怎么选技术路线？他当然会自己判断。如果你想让他封装SDK，你得明确说**“封装现有Java SDK”**。六个字，能省下一万美金。

这不是agent能力不足，恰恰证明agent很听话：你说集成，它就集成；你说封装，它就封装。你不说，它只能猜。

工程管理的第一课：需求不明确，神仙也救不了。

作者还提到一个现象：agent写了上千行getter/setter的测试用例，测试全绿，上线后才发现字段名写错了。他的困惑是——“测试也是AI写的，错的一致就是’对’的”。

这个问题，软件工程界二十年前就解决了。叫TDD，叫测试先行，叫独立验证。让同一个agent既写代码又写测试，相当于让考生自己出卷自己答，然后惊讶地发现他每次都满分。

我的做法是13个agents配7个skills的团队架构：coder写代码，tester写测试，reviewer做审查，architect把控设计。每个角色独立，互相制约。6996行代码跑下来，外部review只发现两个问题，还都是我自己手动干预的结果。

Google Chrome团队的Addy Osmani说得很直白：

The single biggest differentiator between agentic engineering and vibe coding is testing.

测试。就这么简单。

作者观察到agent有个特点：新项目惊艳，老项目拉垮。原因他也说了——上下文越长，agent越蠢。

这个现象有研究支撑。Chroma对18个大模型做过测试，发现长上下文注意力不均匀，到某个阈值后性能断崖式下跌，有效容量通常只有标称最大值的60-70%。

但知道问题和解决问题是两回事。作者写了claude.md和agents.md，但显然没有做session拆分、任务边界控制、上下文清理。就像一个人连续工作72小时然后怪他犯错——你不会这样对待人类同事，为什么要这样对待agent？

在我们社区有个说法：如果你触发了Claude Code的自动压缩，说明你还停留在入门阶段。

作者的核心药方是用强类型语言——Rust、Scala、Haskell，甚至建议给红黑树加形式化验证来”上强度”。

强类型确实能抓类型错误。但类型错误只是代码质量问题的一小部分：业务逻辑错了，类型系统不管；安全漏洞，类型系统不管；性能瓶颈，类型系统不管；架构决策失误，类型系统更不管。

给红黑树加形式化验证来”学CS”，就像让不会炒菜的人去研究分子料理。你连基本的TDD都没掌握，讨论液氮冰淇淋的温度曲线有什么意义？

先学会把鸡蛋炒熟，再谈米其林三星。

Osmani、Martin Fowler、《Agentic Coding Handbook》，所有严肃从业者都指向同一个方向：把AI当工程问题管理，而不是当魔法许愿机。

对比一下两种模式：

作者花了一万美金，全程落在左边那一列。然后怪右边那一列不好用。

这就像买了台数控机床，按了启动键就去喝咖啡，回来发现工件废了，于是恨铁不成钢地说”CNC不行，还是手工锉刀靠谱”。

问题是，CNC操作员如果只量一次也会出废品。作者不是没有卡尺，是他根本不会用——或者说，他不想学怎么用。

软件行业可以向土木工程学很多东西。盖一栋楼，有甲方提需求、设计院出图纸、施工队干活、监理做验收，四方各司其职，互相制约。没有哪个包工头敢自己画图、自己施工、自己验收，然后告诉业主”放心住吧”。

但很多程序员让同一个agent干所有事情，就是这个包工头。

AI时代，核心竞争力不是写更多代码，也不是学更多语言，而是管理能力。管理agent就像管理团队：拆任务、分角色、定流程、建质量关卡。这些以前叫tech lead的技能，现在成了AI coding的基本功。

许愿不灵的时候，答案不是换一个更贵的神灯，是停止许愿，开始工程化管理。

本文的观点，来自我过去一年搭建AI开发团队的实战经验。13个agents、7个skills、数千行生产代码、极低的缺陷率——不是靠运气，是靠流程。

如果你也在探索AI编程的工程化路径，欢迎交流。骂我也行，但请带上你的工程实践，而不只是token账单。

毕竟，最贵的不是那一万美金，是用错误的方式重复一万次。

参考来源：Addy Osmani《Agentic Engineering》、Martin Fowler《Context Engineering for Coding Agents》、Chroma Research《Context Rot》