现象：
在项目启动时，我们决定引入 CrewAI 这个流行的多智能体框架。我让 Gemini 去执行安装，它很快就为我生成了 poetry add crewai 的指令。我几乎没有思考，就直接运行了。
结果，我们陷入了一场惨烈的 “依赖地狱”。CrewAI 对它的下游依赖，有着极其严格、甚至 “霸道” 的版本要求，这与我们项目自身对其他库（如 langchain）的要求，产生了不可调和的冲突。我们花了好几个小时，才从这个泥潭里爬出来。
根源分析：
这个错误的根源，在于我将 AI 当成了一个 “无所不知的专家”，而不是一个 “效率极高的实习生”。我看到了它生成的指令，就下意识地认为 “AI 给的，肯定是对的”，从而放弃了自己作为架构师，去 “审查” 和 “预研” 一个核心技术选型的责任。
在 AI 时代，这种陷阱会变得更致命。因为 AI 生成代码、生成指令的速度太快了，它会让我们产生一种 “进展神速” 的幻觉，从而忽略了在每一个关键决策点上，进行审慎思考的必要性。
生存法则 1：敬畏依赖，AI 只给 “选项”，你来做 “决策”。
在引入任何一个核心依赖（特别是像 CrewAI 这样复杂的框架）之前，永远不要直接采纳 AI 给你的第一个 add 指令。你应该让 AI 成为你的 “分析师”，为你生成一份关于这个库的 “依赖分析报告”，清晰地列出它的核心依赖、版本要求、以及与你现有技术栈可能产生的冲突。看完了报告，再由你，这个人类架构师，来做出最终的决策。
