AI编程的真正风险，是意图的失传
关于AI写代码争论的焦点通常是，AI生成的代码质量如何？够不够健壮？有没有隐藏的bug？很多人觉得，AI写的代码就像一个水平中等的程序员，能用，但不够优雅，甚至有点“笨”。
但真正的问题不是AI生成的代码好不好，而是当整个团队都依赖AI时，没有人再真正理解系统的架构，以及当初做出某个技术选型背后的“意图”。现在，从需求文档、代码、测试用例到故障报告，所有东西都是Claude生成的。人们每天工作12个小时，只是为了不停地按回车键，没人思考，也没人阅读。
这种“意图失传”的后果，比代码里有几个bug要严重得多：
第一，维护成本的指数级增长。软件的生命周期里，维护远比开发更漫长。如果一个系统从诞生之初，就没有一个核心成员能完整地解释其设计哲学和数据流转，那么当它出现问题时，修复就不是改几行代码那么简单了。它会变成一场灾难性的考古，因为你不知道动了A，会不会导致远在天边的B和C同时崩溃。
第二，决策链的“幽灵化”。一个更深层次的危险是，不仅代码的意图失传了，连商业决策的意图都开始变得模糊。如果高管用AI写战略备忘录，备忘录被AI消化成产品文档，文档被AI生成开发任务，最后任务由AI写成代码。在这条链路上，每一环都有“人类审核”，但没有人是真正的决策源头。整个公司像一个被幽灵驱动的机器，为了一个谁也说不清的目标而空转。
第三，工程师核心能力的瓦解。编程的本质，不仅仅是把需求翻译成代码，更是一个通过反复重构和调试，将问题“内化于心”的过程。正是这个过程，塑造了工程师对系统的直觉和掌控力。当这个最核心的思考过程被外包给AI，工程师就从“建筑师”退化成了“监工”，一个随时可以被替换的“AI人肉代理”。
这正在催生一种新的分化。那些放任“意图失传”的公司，短期内或许能看到惊人的交付速度，但他们正在积累一种看不见的“知识债务”。就像长跑比赛中起跑就猛冲的选手，第一年会遥遥领先，但第二、三年，当维护的噩梦降临时，系统可能会迅速崩溃。
而对于开发者个人，路径也变得清晰。你可以选择成为一个高效的“AI操作员”，但这注定是一条价值越来越低的路。或者，你必须强迫自己成为那个“负责任的成年人”，利用AI提升效率，但始终保持对系统架构和最终意图的绝对控制权。
当整个系统变成一个由AI维护的、无人能解释的黑箱时，真正被淘汰的，或许不是写代码的能力，而是定义和解决问题的能力本身。