夜雨聆风
他的排序大致是：
前端开发，加速最多；
后端开发，次之；
基础设施，更少；
研究工作，最少。
我认为这个判断很重要。
因为现在很多企业一谈 AI 编程，就会问一个问题：用了 AI 以后，研发效率能提升几倍？
这个问题看起来直接，但很容易误导管理者。
AI 编程不是平均提速。
不同工作，反馈速度不同，错误是否可见不同，出错后的影响范围不同，对人的判断要求也不同。所以 AI 带来的提效，不可能是一个统一数字。
如果企业用一个简单的“AI 提效倍数”要求所有研发团队，很可能出现两个问题：
一是对容易提速的工作要求不够；
二是对高风险工作放松控制。
前者浪费机会，后者制造风险。
一、为什么前端开发最容易被 AI 加速？
前端开发是 Coding Agent 当前最容易发挥作用的领域之一。
原因不复杂。
第一，主流前端语言和框架的训练数据很多。TypeScript、JavaScript、React、Vue、Angular 等技术栈，模型非常熟悉。
第二，前端结果容易看见。页面有没有出来，按钮能不能点，样式有没有错，打开浏览器就能看到。
第三，反馈速度快。AI 写完代码，可以启动页面、截图、检查 DOM、比较效果，再继续修改。
第四，很多前端错误的风险半径相对小。一个页面不好看、一个按钮位置不对，当然也是问题，但通常不会直接造成数据库损坏、资金损失或生产系统中断。
所以，在前端开发中，AI 很容易形成闭环：
生成代码 → 运行页面 → 观察效果 → 修改代码 → 再验证。
这个闭环越短，AI 提速越明显。
我在 AI 辅助开发实践中也看到类似现象。凡是输出标准清楚、验证直接、错误容易发现的工作，AI 的效果通常更好。
这不是因为 AI 在这些地方“更聪明”，而是因为这些工作更容易被验证。
二、为什么后端开发不能简单交给 AI？
后端开发也会被 AI 明显加速，但风险高很多。
例如写一个 API，AI 可以很快生成接口代码、数据库查询、参数校验和基本测试。
但后端真正难的地方，往往不是“代码能不能写出来”，而是这些问题：
边界条件有没有考虑？
权限控制有没有漏洞？
异常处理是否完整？
并发场景下数据是否一致？
数据库迁移会不会丢数据？
接口变化会不会影响下游系统？
这些问题不像前端页面那样一眼能看出来。
一个后端 bug 可能上线几天后才暴露。更麻烦的是，它可能已经污染数据库，或者让下游系统基于错误数据继续运行。
这类问题的特点是：错误不容易看见，但后果会持续扩散。
所以，AI 写后端代码可以提高效率，但不能替代有经验工程师的设计、评审和验证。
如果一个团队本来就没有清晰的接口规范、权限模型、数据模型、异常处理规则和测试机制，引入 Coding Agent 之后，不一定会变成熟。
它只是把不成熟的过程执行得更快。
三、为什么基础设施更不能只看代码速度？
基础设施工作更特殊。
比如要把一个系统扩展到 1 万活跃用户，并且保持 99.99% 可用性，这不是多写几段代码就能解决的问题。
这里涉及容量规划、网络配置、部署架构、监控告警、容灾方案、成本控制、安全边界、故障演练等一系列工程判断。
AI 可以帮忙写脚本、生成配置、分析日志、整理排查步骤。
这些都有价值。
但关键决策不能轻易交给 AI。
因为基础设施的错误通常有三个特点：
第一，错误隐藏很深。一个网络配置问题、权限配置问题、缓存策略问题，平时可能看不出来，只有在高并发或故障场景下才暴露。
第二，影响范围很大。前端页面错了，可能影响一个功能；基础设施错了，可能影响整个系统。
第三，回滚成本高。有些基础设施变更不是点一下撤销就能恢复，尤其涉及数据、网络、安全和部署链路时。
所以，基础设施领域真正稀缺的不是写代码速度，而是工程经验、风险判断和验证体系。
成熟企业为什么要有变更管理、配置管理、发布审批、监控指标、应急预案和复盘机制？原因就在这里。做CMMI的企业，都不陌生。
AI 时代这些东西没有过时，反而更重要。
四、为什么研究工作最难被 AI 加速？
Andrew Ng 还提到，研究工作被 Coding Agent 加速得更少。
这个判断也很准确。
研究工作当然需要写代码。AI 可以帮助写实验代码、整理数据、跑脚本、记录实验结果。
但研究的核心不是写代码。
研究的核心是提出问题、形成假设、设计实验、解释结果、修正方向。
如果假设本身错了，代码写得再快也没有用。
如果实验设计不合理，结果再漂亮也没有意义。
如果对结果的解释有偏差，后续迭代就会走错方向。
这和企业管理很像。
很多企业以为 AI 能帮自己“快速做事”，但没有先想清楚到底要解决什么问题、用什么指标判断有效、出了问题怎么复盘。
方向错了，速度越快，偏离越远。
五、企业最容易犯的错误：用一个数字管理 AI 提效
现在很多企业推动 AI 编程时，会问研发负责人：
用了 AI 之后，效率能不能提高 30%？
能不能减少一半开发人员？
能不能所有项目周期缩短一半？
我的看法是，这种问法太粗。
前端页面、接口开发、数据库迁移、生产环境变更、算法研究、需求分析、测试设计、缺陷定位，这些工作根本不是同一类过程。
它们的输入不同，输出不同，风险不同，验证方式不同，人的判断作用也不同。
所以企业不能只问“AI 能不能做”。
应该问六个问题：
第一，这项工作的反馈速度有多快？
第二，错误是否容易被发现？
第三，出错后是否容易回滚？
第四，错误的影响范围有多大？
第五，结果能否被自动验证？
第六，这项工作需要多少人的专业判断？
这六个问题，比“AI 能提高几倍效率”更有管理价值。
六、从 CMMI/AIM 角度看，这是过程分类问题
从 CMMI 和 AIM 的角度看，Andrew Ng 的观点本质上不是工具观点，而是过程观点。
不同过程有不同特性，就应该有不同管理方式。
对于反馈快、风险低、容易验证的过程，可以大胆自动化，提高速度。
对于错误隐藏、风险高、影响大的过程，必须增加验证门禁、审批机制、回滚方案和过程证据。
对于高度依赖判断的过程，要让 AI 做辅助，而不是让 AI 替代责任人。
这和过程改进的基本原则一致。
过程不是为了限制效率，而是为了让效率稳定、可控、可持续。
AI 加快了局部活动，但也放大了过程缺陷。
企业如果没有清晰的需求过程，AI 会更快地产生错误需求。
如果没有有效的设计评审，AI 会更快地产生看似合理但隐藏风险的设计。
如果没有测试和验证机制，AI 会更快地产生无法信任的代码。
如果没有配置和变更控制，AI 会更快地把错误带入生产环境。
七、企业应该怎样落地？
我建议企业不要一开始就喊“全面 AI 编程”。
更现实的做法，是先把研发工作分类。
第一类，快反馈、低风险工作。
例如前端页面、原型、内部工具、脚本、文档生成、测试数据准备。这类工作可以让 AI 多做，重点看效率提升。
第二类，中等风险、可验证工作。
例如普通接口开发、单元测试、测试用例生成、代码重构。这类工作可以用 AI 提速，但必须配套代码评审、自动化测试和静态检查。
第三类，高风险、影响大的工作。
例如数据库迁移、权限控制、支付流程、生产环境变更、基础设施配置。这类工作可以让 AI 辅助分析和生成方案，但必须有人审批、验证、备份和回滚。
第四类，高判断密度工作。
例如架构决策、技术路线、研究假设、需求取舍、产品方向。这类工作 AI 可以提供资料和备选方案，但最终判断必须由有经验的人负责。
这样分类以后，企业就不会盲目追求“全员提效几倍”。
管理者可以针对不同类型的工作设定不同目标、指标和控制方式。
这才是 AI 时代的软件过程管理。
八、最后的话
AI 编程正在改变软件开发，但它不是平均地改变所有工作。
越是反馈快、结果可见、容易回滚、容易验证的工作，AI 提速越明显。
越是错误隐藏、影响范围大、验证困难、依赖判断的工作，越需要人的经验和过程控制。
所以，企业引入 Coding Agent 时，不能只问：
我们能不能更快写代码？
更应该问：
哪些工作可以安全加速？
哪些工作必须加强验证？
哪些工作需要保留人的判断？
哪些过程需要重新定义？
哪些证据需要自动留下？
AI 不会简单替代软件工程。
AI 会重新划分软件工程中的速度、风险和责任。
谁能把这些边界设计清楚，谁才能真正从 Coding Agent 中获得稳定收益。
祝你成功！
如果您的企业正在推 AI 转型但卡壳，欢迎预约免费诊断。
