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

45次阅读
没有评论
和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能力”的错误预设,导致“架构错位”

现象:

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

根源分析:

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

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

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

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

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

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

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

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

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

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

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

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

正文完
 0
技术老金
版权声明:本站原创文章,由 技术老金 于2025-08-04发表,共计2239字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(没有评论)