AI 不会生成可用的产品，这仍然是你的工作
AI 工具正在让从创意到第一个可工作的原型变得快得多，但许多工程师认为，它并没有显著缩短通往可靠、可维护、“生产级”软件的更艰难旅程。评论者把 AI 生成的代码描述为适合小应用和实验的原始材料，或者说是“加强版 IDE”，但在缺乏强有力的人类架构、测试和领域专业知识时，它往往杂乱、不连贯，并且难以在规模上演进。其背后折射出更广泛的焦虑：软件开发的工业化、技能要求的变化，以及 AI 最终会主要增强开发者、让他们去技能化，还是最终取代整个岗位的不确定性。
AI 帮助的范围：原型 vs. 生产
- 普遍认为，AI 极大地加速了从无到有做出第一个可工作的版本。
- 许多人认为，它并不会以同样的方式缩短通往“生产级”的路径：经过实战检验、可维护、团队对其有清晰共同理解，并且在各种边缘情况下都足够稳健。
- 也有人反驳：如果编码时间快了 10 倍，后续阶段也必须受益。反驳观点则认为：真正的瓶颈是用户反馈、需求发现和权衡决策，而不是敲代码的速度。
“生产级”意味着什么
- 被描述为：
- 经得起真实用户的抱怨、边缘情况和不断变化的需求。
- 反映出团队对系统的共享心智模型。
- 在维护时不会不断出现意外或回归问题。
- AI 生成的代码在本地看起来常常没问题，但在数月后会产生整体上不连贯的架构：细微的设计漂移、过度复杂，以及难以推理的系统。
代码质量、slop 与维护
- 许多人反馈：
- AI 非常适合顺畅路径上的 CRUD 应用、内部工具和“一次性”实验。
- 当长期存在或复杂的系统主要由智能体推动时，质量会下降；AI 擅长增加代码，不擅长删除/清理代码。
- 反复进行“查找并修复问题”的循环会造成无休止的消耗：修好某处，又把别处弄坏。
- 也有人认为，得益于更好的模式、linters 以及 AI 辅助修 bug，行业平均的微观代码质量已经提高，但宏观层面的连贯性仍然是个挑战。
人们如何有效使用 AI
- 成功的模式：
- 把 AI 当作一个非常快的助手或“代码猴”：人类负责架构、领域建模和测试设计；AI 负责大部分实现。
- 先要求明确计划，再逐步实现并进行严格测试（单元测试、集成测试、属性检查）。
- 使用更小/更弱的模型进行紧密、交互式的辅助，而不是完全代理式的“放手让它跑”工作流。
- 失败的模式：
- 每个 PR 只靠一个提示的 “vibe coding”，没有深入审查。
- 非工程师把自己并不理解的 AI 生成系统直接上线，然后指望别人把它“生产化”。
工作、角色与方法论
- 担忧的核心与其说是个人技能，不如说是：
- 为实现相同产出所需的角色更少了。
- 传统软件工程师“工艺 + 方法论”身份的侵蚀。
- 也有几位认为，我们需要针对 AI 规模代码库的新方法论（例如更形式化的方法、代数数据类型、更强的验证），而不是只把旧做法里的“AI”替换进去。
对产品和经济的影响
- 对可见影响存在分歧：
- 有些人看到大量新工具涌现，尤其是细分领域工具，特别是在医疗保健和内部 SaaS 等领域。
- 另一些人则指出，低投入应用泛滥、UX 变差，而且几乎没有明显改变终端用户体验的产品。
- 总体而言：AI 显然提升了代码产出和原型开发；它是否已经在同等程度上带来了更好的产品和更耐久的系统，仍有争议，而且大体上被认为尚无定论。