这是一个超级深刻且在当前阶段超级准确的观点。

这句话精准地切中了当前 AI（如 GPT-4, Claude 3.5 Sonnet, Copilot 等）在软件工程领域的能力边界。简单来说：AI 擅长战术执行（写代码），但缺乏战略统筹（造软件）。

为了深入剖析这个观点，我们需要区分“代码（Code）”和“软件（Software）”这两个概念的本质区别。

核心差异：代码 vs. 软件

我们可以用“建筑”来打个比方：AI 会砌砖（写代码），但它还不是建筑师和包工头（造软件）。

为什么说“AI 造不出软件”？

尽管 AI 可以瞬间生成几百行完美运行的代码，但要构建一个真正的“软件产品”，它面临以下几个难以逾越的鸿沟：

1. 缺乏“上下文”和“全局架构”能力

软件不仅仅是代码的堆砌，而是模块之间的有机组合。

• 现状： AI 的上下文窗口（Context Window）虽然在变大，但它依旧很难真正理解一个拥有数百万行代码、历史遗留问题复杂的企业级项目。
• 后果： AI 可能会写出一个完美的函数，但这个函数可能与现有的架构冲突，或者引入了隐蔽的依赖问题。它只看到了树木，看不见森林。

2. 无法处理“模糊性” (Ambiguity)

软件开发的难点往往不在于“怎么写”，而在于“写什么”。

• 现状： 客户或产品经理的需求往往是模糊的、矛盾的（例如：“让界面看起来更现代一点”）。
• 后果： 只有人类工程师能通过沟通、同理心和经验，将这些模糊的业务需求转化为具体的技术规范。AI 需要明确的 Prompt，它无法主动去澄清需求。

3. 缺乏“责任”与“决策力”

造软件涉及无数的权衡（Trade-offs）：选 SQL 还是 NoSQL？追求性能还是开发速度？

• 现状： AI 可以列出优缺点，但它无法根据公司的财务状况、团队的技术栈储备、未来的业务规划来做最终决策。
• 后果： 软件出了严重的 Bug，导致资金损失，你不能把 AI 告上法庭。人类必须为软件的可靠性（Reliability）负责。

4. 调试与维护 (The “Last Mile” Problem)

写代码只是开始，维护才是大头。

• 现状： 当 AI 生成的代码出现极度复杂的逻辑错误，或者涉及多线程并发、内存泄漏等深层问题时，AI 往往会陷入“幻觉”或给出死循环式的修复提议。
• 后果： 最终还是需要资深的人类工程师介入，像“擦屁股”一样去修复 AI 遗留的微妙错误。