AI工程实践:软件工程到底变没变?

AI工程实践：软件工程到底变没变？

这个点是近期和一些老师傅聊 AI 工程时，经常会出现一个分歧。

我的观点是：软件工程正在发生巨大变化，而且这个变化不是“工具变好用”这么简单，而是软件工程正在从 Human First 逐步走向 AI First。

过去的软件工程默认以人为中心：人理解需求，人拆任务，人写代码，人验证结果，工具围绕人服务。

但接下来，越来越多工程动作会默认先考虑 AI 能不能执行、AI 需要什么上下文、AI 如何被验证、人在哪些关键节点介入。这就是我说的 AI First。

换句话说，软件工程正在从人工主导，逐步迁移到 AI 主导。

老师傅的观点是：软件工程没有发生什么本质变化，还是需求、设计、编码、测试、Review、发布、运维这一套，仍然要遵循标准、工整、可维护、可验证的软件工程体系。

表面看，我们像是在互相反驳。

但我现在更愿意把它拆开看：

我说的是软件工程的真实形态正在巨变；老师傅说的是软件工程的底层约束没有消失。

这两个判断都成立。

但主趋势我觉得会非常明确：软件工程一定会从 Human First 向 AI First 迁移。这个方向不会因为我们喜欢不喜欢而停下来。– 至少我自己都能跑通很多的实际案例了。

一、我的观点：软件工程正在从 Human First 走向 AI First

过去的软件工程，本质上是 Human First。

人写需求，人拆任务，人设计方案，人写代码，人补测试，人做 Review，人排查问题，人写发布说明，人复盘事故。

工具只是辅助。

Jira 记录任务，Git 管代码，CI 跑测试，看板展示状态，文档沉淀知识。工具不真正“干活”，真正干活的是人。

但 AI 进入以后，这个结构开始变了，软件工程开始进入 AI First 阶段。

AI 不再只是补全几行代码，也不再只是回答一个技术问题。它开始进入需求分析、任务拆解、方案生成、代码修改、测试补齐、PR 描述、风险提示、文档更新、问题排查这些研发动作里。

这意味着什么？

意味着软件工程的执行主体开始变化。

以前是人执行，工具记录。

现在正在变成：人定义目标和边界，AI 执行大量工程动作，工程系统负责验证、记录、审计和反馈。

这就是我说的“从 Human First 走向 AI First”，也就是从人工主导逐步走向 AI 主导。

注意，我不是说人不重要了。

恰恰相反，人会更重要。

但人的重要性会从“亲手完成每一步”，转向“定义问题、提供上下文、设计边界、判断结果、承担责任”。

工程师不再只是写代码的人，而会越来越像一个 Agent 的任务设计者、上下文管理者、质量审查者和系统负责人。

研发经理也不再只是盯人和排期，而要开始思考：哪些任务可以交给 Agent，哪些任务必须人来做，哪些结果必须强制验证，哪些风险必须人工确认。

这不是小变化。

这是一场软件工程生产方式的迁移。

二、为什么我说这是“巨变”，不是普通工具升级

有人会说：以前也有很多工具升级，IDE、Git、CI/CD、云原生、敏捷、DevOps，不都改变过软件工程吗？

是的。

但这次不一样。

过去的大多数工具，替代的是确定性动作。

CI/CD 替代人工构建、人工测试、人工部署。

Git 替代更落后的版本管理方式。

云平台替代一部分基础设施运维。

这些工具很强，但它们大多不参与“理解”和“生成”。

AI Agent 不一样。

它参与的是半结构化的软件工程动作：理解需求、阅读代码、判断影响范围、生成方案、修改实现、补测试、总结风险、根据失败信息继续修。

这就会触碰到软件工程里更深的东西：角色分工、流程设计、质量责任、管理指标和工具形态。

比如过去一个看板任务，默认是分配给某个人。

未来它可能是分配给一个 Agent，由人负责描述任务、补充上下文、审核结果。

过去项目管理系统盯的是人有没有更新状态。

未来它可能要盯 Agent 卡在哪里：上下文不够、权限不够、测试失败，还是需要人工判断。

过去研发效能看交付周期、Review 时长、缺陷率。

未来还要看 Agent 任务成功率、人工介入率、AI 生成代码回滚率、上下文缺失率、测试补齐率。

过去工时管理看某个人写了多久代码。

未来更重要的是看一个需求里，人类判断、AI 执行、Review 修正、自动化验证分别消耗了多少成本。

所以，项目管理 SaaS、敏捷看板、工时管理、研发效能平台、DevOps 工具，都会面临一次重构机会 — 这些是很多SaaS厂商的真实机会。

它们不能只服务人。

它们还要服务 Agent。

它们不能只记录人的工作。

它们还要承载人和 AI 协作的过程。

这就是我认为的软件工程巨变。

三、Harness Engineering 是这场迁移的关键支架

如果软件工程正在从 Human First 走向 AI First，那最关键的问题就不是“AI 会不会写代码”。

这件事已经不用争了。

真正的问题是：AI 怎么进入真实的软件工程体系，而不是变成每个人手里的“自由发挥工具”。

这就是 Harness Engineering 的价值。

我理解的 Harness Engineering，不是几个 prompt，也不是买一个 AI 编程工具，而是一套围绕 AI Agent 的工程支架：任务怎么描述，上下文怎么供给，工具怎么调用，权限怎么控制，结果怎么验证，失败怎么反馈，经验怎么沉淀。

AI 主导不是让 AI 随便干。

AI 主导是让 AI 在工程系统里干。

如果没有这层支架，团队很容易出现上下文不一致、验证不一致、责任不一致的问题。短期看每个人都更快了，长期看 Review 压力、质量风险和管理盲区都会上来。

所以我一直认为，真正要建设的不是“每个人都会用 AI”，而是“团队具备让 AI 进入生产流程的工程系统”。

这就是 Harness Engineering。

四、老师傅为什么说软件工程没变？

那老师傅为什么会说软件工程没变？

因为他们看的不是执行形态，而是工程本质。

从这个角度看，他们是对的。

《Google 软件工程》里有一个很重要的判断：软件工程是“随时间累积的编程”。

这句话放到今天仍然成立。

软件工程真正难的，不是把代码写出来，而是代码如何在长期时间尺度里持续演进，如何在多人协作里保持可维护，如何在需求变化和系统复杂度里不失控。

AI 能生成代码，但它不能天然替你承担业务责任。

AI 能补测试，但它未必知道哪些场景是真正的生死线。

AI 能重构模块，但它可能不知道某个看起来很丑的逻辑，其实是三年前为了兼容一个大客户留下来的。

AI 能生成一个漂亮抽象，但它未必知道这套抽象会不会让后面维护的人痛苦。

所以老师傅强调需求评审、架构设计、测试覆盖、代码 Review、发布灰度、监控告警、事故复盘，这些都没有错。

尤其在大型 SaaS 团队里，质量是生死线。

客户不会因为代码是 AI 写的，就少提一个稳定性要求。

线上事故也不会因为你用了 Agent，就少影响一个客户。

所以，老师傅说“软件工程本质没变”，我认。

但如果由此得出“软件工程没发生大变化”，我不同意。

因为执行主体变了，协作方式变了，工具形态变了，管理对象也变了。

这已经不是普通工具升级。

五、Karpathy 的分叉判断，正好说明这个问题

Karpathy 对 Vibe Coding 的修正，我觉得很适合放在这里。

Vibe Coding 适合原型期。

一个想法，一个 demo，一个小工具，一个页面验证，让 AI 大胆写，边试边改，这很有效。

但进入生产环境，就不能只靠 vibe。

生产环境需要更严肃的工程框架，需要验证、边界、Review、权限、回滚、监控和责任人。

这句话其实把两边观点接起来了。

原型期可以 Vibe。

生产期必须 Harness。

我的观点强调的是：软件工程正在从 Human First 向 AI First 迁移。

老师傅观点强调的是：生产级软件必须有工程纪律。

这两句话不是互相抵消，而是应该合在一起。

AI First 的生产级软件工程，更需要 Harness。

六、关键不是谁对谁错，而是怎么结合

我不太想把这个问题写成“我和老师傅到底谁赢了”。

更实际的判断是：两种观点必须结合起来。

老师傅的软件工程纪律，用来守住质量底线：需求、架构、测试、Review、发布、监控、责任，这些不能因为 AI 出现而消失。

我的 AI First 判断，用来重建执行系统：让更多研发动作由 AI 主导执行，让工具、流程和管理指标开始适配人机协作。

所以我的结论很明确：

软件工程的本质不会消失，但软件工程的形态正在从 Human First 迁移到 AI First，这是我们每个人面临的现实。

对研发管理者来说，下一步不是争论 AI 会不会改变软件工程。它已经在改变了。

更应该问的是：

1.哪些研发动作可以交给 AI 主导执行？2.哪些关键判断必须由人负责？3.AI 执行任务时需要什么上下文、权限、工具和验证链路？4.现有项目管理、看板、工时、研发效能系统，能不能描述 AI 参与后的真实工作？5.老师傅的隐性经验，能不能沉淀成 Agent 可读的规则、案例和质量门禁？

这几个问题，才是软件工程接下来真正要回答的问题。

我的判断是：用老师傅的软件工程纪律守住质量，用 AI First 的新形态重建效率。

但趋势不要看错。

这场迁移的方向，是从 Human First 走向 AI First。

Harness Engineering，就是这个迁移过程中最关键的工程支架。

下一篇：总结下我对打造 超级个体 与 超级团队的一些实践和经验。