夜雨聆风
AI编程正在侵蚀整个软件工程职业?真正危险的不是 Copilot,而是我们还在用旧方法管理新工程
今日，关于 AI 编程最刺耳的一种说法是：
> LLM 正在侵蚀软件工程这个职业。
这句话听起来像标题党，但它击中了很多开发者的真实焦虑。
不是因为大家真的相信“程序员明天就失业”，而是因为我们已经看到了更微妙的变化：代码生成越来越快，初级任务越来越容易被 AI 接管，PR 里出现越来越多“能跑但没人真正理解”的代码。
软件工程里最传统的成长路径——从小需求、小 bug、小模块开始，靠不断踩坑建立基本功——正在被压缩。
短期看，AI 编程工具提高了编码速度；长期看，它可能重写整个工程组织的招聘、培养、评审和责任体系。
真正的问题不是“AI 会不会写代码”，而是：
> 当代码产出变便宜以后，工程能力到底还值不值钱？
一、AI 提升的不是“软件工程生产率”，而是“局部编码速度”
最容易被误读的数据来自 GitHub Copilot 的早期实验。GitHub、Microsoft 和 MIT 的一项研究显示，使用 Copilot 的开发者完成一个 HTTP server 编程任务的速度快了约 **55.8%**。
这个数字很漂亮，也很容易被老板拿去做 PPT： “既然效率提升 56%，是不是团队可以少招 30% 的人？”
问题是，软件工程不是 LeetCode，也不是单文件小任务。
真实项目里，工程师的大量时间花在这些地方：
– 理解业务需求；
– 判断这个需求该不该做；
– 阅读遗留代码；
– 找到正确抽象；
– 兼容旧接口；
– 写测试；
– 处理线上事故；
– 和产品、安全、运维沟通；
– 为未来维护成本负责。
METR 在 2025 年做过一个更接近真实环境的研究：让有经验的开源开发者在自己熟悉的大型代码库中使用 AI 工具完成真实 issue。结果很反直觉：开发者原本预期 AI 会让自己快约 24%，但实际完成时间反而 慢了约 19%。更有意思的是，事后他们仍然以为自己变快了。
这说明一个问题：AI 很擅长制造“我正在高速推进”的感觉。它不断输出代码、解释、方案、测试，让你觉得工作流很顺。但软件工程最终看的不是输出速度，而是交付结果。
可以用一个很简单的表格区分：
AI 容易提升的 AI 不一定提升的
样板代码生成 需求判断
API 调用示例 架构取舍
单元测试初稿 测试有效性
局部重构 系统一致性
文档摘要 责任归属
快速 demo 长期维护
所以，更准确的说法不是“AI 让程序员效率提升 50%”，而是：
> AI 让清晰、局部、低上下文的编码任务变快；但它不自动提升端到端软件工程能力。
二、最先被冲击的，可能是初级工程师的成长路径
开发者社区真正担心的，不是 senior 明天被替代，而是 junior 没地方长大。
以前，一个初级工程师进入团队，通常会从这些任务开始：
– 改一个按钮；
– 修一个简单 bug；
– 写一个后台字段；
– 补一段测试；
– 做一个 CRUD 页面；
– 查一个线上日志。
这些任务看起来“低价值”，但它们恰恰是工程基本功的训练场。新人通过这些小任务，慢慢学会代码风格、业务规则、系统边界、调试方法和发布流程。
现在问题来了：这些任务正是 AI 最擅长的。
当团队把简单需求都交给 AI 或由 senior 带着 AI 快速完成，junior 可能会失去最重要的训练机会。最后出现一种奇怪断层：
“`text
AI 能写简单代码
Senior 能判断 AI 写得对不对
但 Junior 没机会练到能判断
“`
这才是“AI 侵蚀软件工程职业”的核心。
它不是把所有程序员一次性替代掉，而是可能先掏空职业阶梯底部。短期看，企业似乎更高效；长期看，行业可能缺少下一代高级工程师。
Sourcegraph 早就讨论过“The death of the junior developer?”这个问题。Addy Osmani 在《The 70% Problem》里也提出过类似判断：AI 可以很快生成“70% 看起来可用”的代码，但最后 30%——正确性、边界条件、性能、安全、可维护性——依然需要有经验的人完成。
危险的是，很多组织会误把前 70% 当成全部。
三、AI 让代码变多了，但不一定让系统变好了
以前写代码有成本，所以人会犹豫：这个抽象要不要加？这个依赖要不要引？这个模块是不是过度设计？
现在不一样了。AI 可以在一分钟内生成三种实现、五个类、十个测试文件。代码变得太便宜，便宜到我们忘了每一行代码未来都要被维护。
软件工程有个残酷事实：
> 写代码只是开始，理解代码才是长期成本。
AI 生成代码最大的风险，不是它一定错，而是它经常“看起来对”。它会使用流畅的命名、整齐的结构、完整的注释，甚至补上测试。但这些测试可能只覆盖 happy path；这些接口可能误解了业务语义；这些依赖可能根本不存在；这些安全边界可能被悄悄绕过。
Stanford 曾研究过 AI 助手对安全代码的影响，发现使用 AI 助手的参与者更可能写出不安全代码，同时还更自信。NYU 早期对 Copilot 的安全评估也发现，在安全相关场景中，相当比例的生成代码存在可利用漏洞。
这对工程管理的启发很直接：
> AI 生成的代码，默认应该被当成“不可信贡献者”提交的 PR。
不是不能用，而是不能免审。
四、AI 时代的软件工程能力，应该重新定义
过去我们评价程序员，经常看这些东西：
– 能不能快速写代码；
– 会不会某个框架；
– 熟不熟某门语言；
– 一天能提几个 PR；
– 能不能独立实现需求。
这些指标在 AI 时代会失真。因为一个会写 prompt 的人，也可能一天产出很多代码。但他是否真正理解系统，是否能发现 AI 的错误，是否能为上线结果负责，是另一回事。
更合理的能力模型应该变成这样：
能力层级 过去关注 AI 时代更应关注
编码能力 能写出来 能判断该不该写
调试能力 能修 bug 能定位 AI 引入的隐性 bug
架构能力 能设计模块 能控制复杂度不被 AI 放大
测试能力 能补测试 能设计能打破 AI 假设的测试
协作能力 能交付需求 能解释、验证、接管 AI 输出
责任意识 代码能跑 线上出事知道谁负责
一句话：
> 未来值钱的不是“会不会让 AI 写代码”，而是“能不能对 AI 写出的代码负责”。
五、代码评审要从“逐行看代码”变成“风险分层”
AI 时代，PR 数量和代码量可能都会上升。如果还让 reviewer 逐行阅读所有代码，团队会很快被淹没。
更好的方式是四层评审：
“`text
第一层：CI 做确定性检查
– 编译
– 类型检查
– 单元测试
– lint
– SAST
– 依赖扫描
– secret 扫描
第二层：AI 做预审
– 总结变更
– 提醒缺失测试
– 找明显错误
– 标记高风险文件
第三层：人类做语义评审
– 需求是否正确
– 权限边界是否安全
– 数据流是否合理
– 架构是否变复杂
– 是否影响线上稳定性
第四层：高风险专家审批
– 支付
– 认证授权
– 隐私数据
– 基础设施
– 核心依赖
– 生产权限
“`
注意：AI 可以做 reviewer assistant，但不能做最终 approver。
GitHub 关于 Copilot Code Review 的文档也明确提醒，AI 评审可能遗漏问题，不能替代人工判断。Google 的代码评审原则也一直强调，review 的目标是改善代码库健康度，而不是追求表面通过。
未来每个 AI 参与的 PR，至少应该回答三个问题：
“`text
AI 使用：
– 使用了什么工具/模型？
– 用于设计、编码、测试还是评审？
– 是否输入了敏感数据？
验证证据：
– 跑了哪些测试？
– 哪些假设由人工确认？
– 是否新增依赖或外部代码？
责任归属：
– 最坏失败模式是什么？
– 如何监控和回滚？
– 谁最终批准上线？
“`
这不是形式主义，而是组织自保。
六、真正要重构的不是工具，而是工程管理系统
很多公司把 AI 编程理解成采购工具：买 Copilot、买 Cursor、接一个 Claude Code，然后让大家“提高效率”。
这太浅了。
AI 编程不是 IDE 插件，而是工程管理体系的变量。它会影响：
– 招聘标准；
– 新人培养；
– 代码评审；
– 安全策略；
– 权限管理；
– 绩效指标；
– 事故责任；
– 团队编制。
如果这些不变，只是让每个人多一个 AI 助手，结果可能不是效率革命，而是更快地产生更多技术债。
一个比较稳妥的组织框架可以叫 **HUMAN**：
“`text
H – Hire for AI-era engineering
招聘会驾驭 AI、也能脱离 AI 思考的人。
U – Upskill through real work
用真实项目训练判断力，而不是只教提示词。
M – Make review risk-based
让机器做广度检查，让人类做语义和风险判断。
A – Apply security by default
默认最小权限、隔离执行、保留审计。
N – Name the accountable human
AI 可以执行，但不能成为责任主体。
“`
这里最重要的是最后一句：
> Agent 可以拥有执行权限，但不能拥有组织责任。
出了事故，不能说“这是模型写的”。 合并代码，不能说“AI reviewer 通过了”。 泄露数据，不能说“供应商说不会保存”。
模型没有绩效，没有职业伦理，没有客户承诺，也不会半夜起来处理线上故障。责任最终必须落到具体的人和组织。
七、程序员该怎么办？
对个人来说，AI 编程时代最差的策略，是把自己训练成“提示词操作员”。
因为提示词技巧会快速贬值，工具界面会变，模型能力会变，今天复杂的 workflow 明天可能一键完成。
更长期的护城河是这些：
1. **读代码能力**：能快速理解陌生系统；
2. **调试能力**：能定位不稳定、不可复现的问题；
3. **测试能力**：能设计真正能发现错误的测试；
4. **系统设计能力**：知道复杂度该放在哪里；
5. **安全意识**：知道哪些边界不能交给模型猜；
6. **业务理解**：知道代码背后的真实目标；
7. **责任感**：敢为上线结果签字。
未来的优秀工程师，不一定是写代码最多的人，而是能把 AI 变成杠杆、同时不被 AI 带偏的人。
结语：AI 不会消灭软件工程，但会淘汰一部分“只会产出代码”的工作方式
所以，“LLM 正在侵蚀软件工程职业”这句话，既对也不对。
不对在于：软件工程远不只是写代码。需求、架构、测试、上线、治理、责任，这些都不会因为模型会补全函数而消失。
对在于：如果一个人的核心价值只剩下“把明确需求翻译成代码”，那这部分价值确实正在快速贬值。
AI 编程真正带来的变化，不是程序员消失，而是软件工程的重心上移：
从写代码，转向定义问题； 从生成实现，转向验证结果； 从个人效率，转向组织治理； 从“谁写得快”，转向“谁能负责”。
未来的软件工程师，可能写的代码更少，但需要承担的判断更多。
这不是职业的终点。 这是软件工程从“代码生产”走向“复杂系统治理”的开始。
—END—