和AI结对编程第一天，我踩了3个大坑，差点项目失败！复盘4条生存法则

我是技术老金。

最近，我启动了一个极具挑战性的个人项目：用AI来辅助我，从零开发一个通用的自主行动智能体框架。

我选择的核心AI工具，不是大家常用的ChatGPT或Copilot，而是一个更硬核、更接近开发本质的工具：Google的Gemini CLI。在这个项目中，我将扮演“架构师”的角色，负责提出方向、做出决策；而它，将作为我的“AI结对程序员”，负责执行编码、测试和文件操作。

我们的协作，在第一天就高速推进，但也几乎在第一天，就因为几个看似低级、实则致命的错误，而差点当场失败。复盘这次经历，我发现，我们几乎完美地踩中了所有在“AI结对编程”这种新型协作模式下，最容易出现的“第一天陷阱”。

今天，我把这些陷阱，以及我们总结出的4条生存法则，分享给你。

---

陷阱一：对“AI生成”的盲目信任，导致“依赖地狱”

现象：

在项目启动时，我们决定引入CrewAI这个流行的多智能体框架。我让Gemini去执行安装，它很快就为我生成了poetry add crewai的指令。我几乎没有思考，就直接运行了。

结果，我们陷入了一场惨烈的“依赖地狱”。CrewAI对它的下游依赖，有着极其严格、甚至“霸道”的版本要求，这与我们项目自身对其他库（如langchain）的要求，产生了不可调和的冲突。我们花了好几个小时，才从这个泥潭里爬出来。

根源分析：

这个错误的根源，在于我将AI当成了一个“无所不知的专家”，而不是一个“效率极高的实习生”。我看到了它生成的指令，就下意识地认为“AI给的，肯定是对的”，从而放弃了自己作为架构师，去“审查”和“预研”一个核心技术选型的责任。

在AI时代，这种陷阱会变得更致命。因为AI生成代码、生成指令的速度太快了，它会让我们产生一种“进展神速”的幻觉，从而忽略了在每一个关键决策点上，进行审慎思考的必要性。

生存法则 1：敬畏依赖，AI只给“选项”，你来做“决策”。

在引入任何一个核心依赖（特别是像CrewAI这样复杂的框架）之前，永远不要直接采纳AI给你的第一个add指令。你应该让AI成为你的“分析师”，为你生成一份关于这个库的“依赖分析报告”，清晰地列出它的核心依赖、版本要求、以及与你现有技术栈可能产生的冲突。看完了报告，再由你，这个人类架构师，来做出最终的决策。

陷阱二：对“AI速度”的过度依赖，导致“黑盒调试”

现象：

在集成CrewAI的过程中，我们反复遇到ImportError。我一次又一次地让Gemini去“试错”——“换个路径试试”、“换个类名试试”。我们像没头苍蝇一样，在黑暗中反复碰壁，浪费了大量时间。

根源分析：

这暴露了AI辅助编程的第二个陷阱：AI的“高速试错”能力，会让我们产生一种“逃避思考”的惰性。

在没有AI的时代，我们遇到问题，会本能地去“RTFM”（Read The F**king Manual）。因为我们自己“试错”的成本很高。但现在，AI可以在一秒钟内，为我们生成十种不同的解决方案，这会诱使我们放弃最重要、也最艰难的那一步——静下心来，去阅读官方文档，去理解问题的本质。

生存法则 2：文档驱动，而非猜测驱动，让AI为你“阅读”，而不是替你“瞎猜”。

当遇到问题时，正确的做法，不是让AI为你生成10种可能的“修复方案”，而是应该把官方文档的URL丢给它，然后对它下达指令：“阅读这份文档，然后告诉我，在2025年，集成这个功能最官方、最正确的方式是什么？”

让AI成为你的“阅读助理”，而不是你的“试错机器”。这才能让你从“黑盒调试”的泥潭中，解脱出来。

陷阱三：对“AI能力”的错误预设，导致“架构错位”

现象：

我们花费了大量精力，试图将我们自己设计的、通用的BaseTool和BaseLLM接口，“强行”塞给CrewAI。我们想让它来适应我们。结果，我们发现CrewAI的底层，与我们这种“灵活切换”的设计思想，存在根本冲突。

根源分析：

我们犯了一个经典的架构错误：我们对一个第三方技术的能力边界，做出了错误的预设。 我们想当然地以为，CrewAI应该是一个“可插拔的、乐高式的库”，但它的真实定位，却是一个“大而全的、拥有自己世界观的框架”。

生存法则 3：先“摸底”，再“集成”，让AI为你生成“技术选型报告”。

在决定集成任何一个第三方组件之前，都应该先让AI为你生成一份详细的“技术选型分析报告”。这份报告至少要回答三个问题：

1. 它的核心定位是什么？ 是一个“库”，还是一个“框架”？
2. 它的依赖关系是“重”还是“轻”？ 它是否会对我们的技术栈产生“污染”？
3. 它的扩展方式是“开放”还是“封闭”？ 它是否提供了官方支持的、清晰的自定义扩展方式？

只有在对一个技术有了清晰、准确的“摸底”之后，我们才能做出正确的架构决策。

结语：重新定义“结对编程”

与AI结对编程的第一天，是充满教训的一天。它让我深刻地意识到，在AI时代，我们作为“人类开发者”的角色，已经发生了根本性的变化。

我们不再是那个在键盘上奋力敲击的“编码者”，我们的核心价值，正在向上游转移，转移到了那些AI无法替代的、更宏观的领域。

这，就是我们的第四条、也是最重要的生存法则：

做好“架构师”，而非“监工”。 你的职责，不是监督AI写下每一行代码，而是为它设定清晰的目标、划定明确的边界、做出关键的决策，并在它犯错时，能从更高的维度，去洞察错误的本质。

AI是一个能力极强、但毫无经验的实习生。而你，必须成为那个值得它信赖的、经验丰富的架构师。

这，就是在AI时代下，“人机协作”的、唯一的、正确的相处之道。

[版权声明]
本文由“技术老金”原创首发于个人博客及微信公众号『技术老金』，转载请注明出处。