夜雨聆风2026年，AI编程工具已从新鲜事物变成了行业标配。但几组数据让人不得不重新审视这个趋势。
New Relic调查了200位美国科技决策者，揭示了一个引人深思的矛盾：
94%的领导者认为AI生成的代码在审查时质量更高，但78%的组织报告AI代码上线后生产事故反而增加了。 86%的高级工程师正在花更多时间修复AI代码。
Entelligence AI的调研则从财务角度量化了这个问题：企业在AI工程上每投入1美元，仅有0.18美元最终转化为可用的生产系统。剩下的0.82美元消耗在了修复漏洞、重写代码和处理审查延误上。
这些数据并非在说AI无用，也不是在否定AI编程的价值。它们揭示了一个更深层的问题：我们面对AI时，往往陷入了两种极端态度——要么迷信，要么不信。 而两种态度，都偏离了问题的本质。
01 两种极端的表现与根源
“迷信AI” 的表现并不陌生。
62%的技术领导者坦言，其工程团队经常信任AI生成的代码，不加逐行验证就直接部署到生产环境。不少开发者跳过需求分析与任务分解，将一句模糊描述直接丢给AI，期待它产出完整功能。代码审查走过场，用审查人类代码的标准去审视AI代码，难以发现那些隐性的架构缺陷。
“不信AI” 同样普遍。
看到AI代码频繁引发生产事故，便退回纯手工开发的惯性中。认为AI只能写样板代码，忽视其在需求整理、知识检索、测试用例生成等环节的辅助价值。
两种看似对立的态度，实则有一个共同的认知根源：都把AI当作一个独立的生产主体来看待。 迷信者视其为“优秀员工”，不信者视其为“不合格员工”。但AI既非前者，也非后者。它是一个概率计算工具，不存在抽象的“能干”或“不能干”，只有在特定条件下“适用”或“不适用”的区别。
决定AI能否发挥价值的，从来不是AI本身，而是使用它的人和支撑它的流程。
一个基础不牢、急于求成的开发者，用AI会更快地生产更多垃圾代码。一个具备良好工程素养和批判性思维的开发者，用AI是将重复劳动外包，把省下的时间投入架构设计与深度审查。同样的工具，结果迥异。差距不在AI，在人。 这种差距，就是我们一直在讨论的“AI亲和力”——不是会不会写Prompt，而是能不能清醒地判断：什么该让AI做，什么必须自己做，AI给的东西能信几成。
02 人与AI的辩证关系：正向螺旋与负向螺旋
要理解这种差距，需要回到一个基本的认识上来：AI是工具，不是生产主体。
工具的价值不取决于工具本身，而取决于使用工具的人，以及将人与工具组织起来的生产关系——在软件工程中，就是流程与组织方式。当前AI编程出现的种种问题，根源不在于工具性能不足，而在于生产关系尚未适配新工具。流程仍停留在“人写代码”的时代，突然引入一个能批量生成代码的AI，需求分析、任务分解、代码审查、上线验证各环节的衔接处，必然出现系统性断裂。
人与AI的关系，可以用一个公式来做一个简化表达：
AI亲和力 = 人类定义问题与价值判断的能力 × AI执行与生成的能力
但这个公式是静态的。它只描述了某一个时刻人与AI各自的能力乘积，却没有描述这个乘积在持续协作中会怎样变化。实际上，人与AI的关系不是一个固定值，而是一个双向互动的动态循环。这个循环可以朝着两个截然相反的方向发展。
▎正向螺旋：人与AI相互促进
具备良好工程素养的人，能将需求分析清楚、把任务拆到合理粒度，为AI提供清晰约束和精准上下文。AI在此条件下产出高质量代码，这份输出反过来可能暴露人的知识盲区，或提供一种未曾想到的实现思路，促使人深入学习。人提升了，便能更好地引导AI。人与AI的能力在此过程中同步上升。
▎负向螺旋：人与AI相互拖累
基础不牢、急于求成的人，盲目信任AI的输出，跳过需求分析和任务分解，将模糊需求直接丢给AI。AI在缺少约束的情况下自由发挥，生成能跑但有缺陷的代码。因为不去深究，人失去了学习机会，能力停滞甚至退化。在更低的认知水平上继续使用AI，产出更差的代码。最终，人离不开AI却又驾驭不了AI，组织积累了大量难以维护的技术债——那些没人能解释为什么这样写、但谁也不敢改的代码。
同一款大模型，在不同的工程素养和流程设计下，可以走向完全相反的结果。这说明问题不在工具本身，而在人与工具的结合方式。
“不信AI”和“迷信AI”，本质上都错在把AI当成了独立的生产主体。实际上，AI只是一个能力放大器——它放大的是人和流程现有的水平。 水平高，正向放大；水平低，负向放大。而决定放大方向的那个关键变量，就是AI亲和力。它不是一个静态的指标，而是人与AI协作中的动态素养：人能否定义清楚问题、做出准确判断、承担最终责任；AI能否在清晰的约束下扩展信息、加速执行、暴露盲区。
03 推动正向螺旋的实践路径
认识到问题的本质，解决路径便清晰了：不是换更好的模型，也不是干脆不用AI，而是通过强化流程，在每个环节实现人与AI的有机结合，把螺旋方向扭正。
需求阶段：人主导分析，AI辅助整理。
需求必须有结构化的文档才能进入设计阶段。人负责定义问题、做出价值判断、承担决策责任。AI辅助整理信息、检查逻辑矛盾、发现遗漏点。这一步的目标，是给AI提供精准的上下文，而不是让AI从模糊描述中“猜”。
设计与任务分解阶段：人主导架构，AI充当挑战者。
架构设计不能让AI自由发挥，但可以让AI当“方案辩论对手”——人对AI说“这是我的设计思路，你觉得哪里有漏洞”。AI的输出不是最终答案，而是促进人深入思考的引子。
任务必须拆到“单个功能点、单次交互”的粒度，才能让AI在足够聚焦的上下文里生成代码。这是控制Token消耗、减少返工最关键的环节。
编码阶段：AI做模式化工作，人做深度工作。
样板代码、测试用例、格式转换等模式匹配的任务交给AI。核心逻辑、边界条件、跨模块交互这些需要深度理解的代码，人亲自写。分工原则很明确：匹配模式的交给AI，需要理解语义的留给人。
审查阶段：建立针对AI代码的审查标准。
传统的代码审查关注语法规范和功能正确性，对付不了AI代码的特有问题。针对AI代码的审查，还必须追问：这段代码为什么放在这里？它的隐式假设是什么？和其他模块的交互有没有边界遗漏？这一步是拦截Agent债务的最后防线。
反思阶段：让每一次迭代都推动螺旋上升。
每个迭代结束后，团队应回顾AI代码的质量趋势，分析反复出现的问题类型，找到根因，然后调整提示词策略、任务分解粒度或审查标准。这一步是正向螺旋的引擎——不是修一个Bug就完事，而是找到“为什么AI会写出这个Bug”的根因，从源头上优化。每一次反思，都是人向AI输出更高质量指令的起点。
关于Token成本。
Token是有成本的，对个人开发者和小型创业团队来说更是如此。但在当前阶段，主要矛盾不是Token太贵，而是Token被大量浪费在返工、修复和无效生成上。合理使用DeepSeek、豆包等免费工具也能显著降低成本。先把螺旋方向扭正，Token的投入产出比自然会改善。
结语
AI编程当前面临的效率困境，本质上不是技术问题，而是认识问题和流程问题。
“迷信AI”与“不信AI”，都停留在把AI当作独立生产主体的旧框架里。走出这个二元对立，回归到人、组织、流程的有机结合上来，推动正向螺旋，才是当前最该做的一件事。