AI时代的软件工程新范式

有人说AI是提效神器，能把自己从重复的代码里解放出来；也有人吐槽AI是“坑王”，生成的内容初看惊艳，细看全是漏洞，改起来比自己从头写还费劲儿。更有意思的是，很多团队全员都用上了AI，结果沟通协作成本没降反升，AI带来的新错误，反而成了团队新的内耗。

我也一直在琢磨，到底是我们用的模型不够强，还是我们用AI的方式，从根上就没找对？

直到最近看了Thoughtworks全球技术策略顾问徐昊老师 《AI 时代的软件工程》 的分享，里面的很多观点，一下子就把我之前的困惑解开了。今天就不聊什么高深理论，单纯和大家分享一下，我看完这份分享后的一些感悟和思考。

先聊个最实在的：AI很聪明，为啥总干不好我们手里的活？

相信很多人都有过这种体验：给AI甩过去一个需求，它很快就能输出一个像模像样的结果，可真要拿到业务里用，才发现到处都是问题。

分享里有句话我特别认同：在LLM时代，AI生成内容很容易，AI把内容生成对很难。

我们总觉得AI无所不能，却忽略了一个最核心的差距：AI的通用能力，和我们需要的岗位能力，根本不是一回事。

这些藏在公司文档里、老员工脑子里的隐性知识，你不主动、清晰地告诉AI，它永远不可能自己悟出来。

AI时代，软件工程的底层逻辑从来没有变，变化的只是生产工具和工作方式。 我们要做的，从来不是逼着AI变聪明，而是用软件工程成熟的范式，去解决AI生成内容的不可控和质量波动问题，说白了，就是驯服AI的不确定性。

一个很重要的认知跃迁：从“人服务于人”，到“人服务于AI”

以前我们做软件工程，写规范、定流程、拆需求，核心是为了团队里的人能对齐认知，方便人和人之间的协作，本质上是“人服务于人”。

但AI时代，我们的角色其实已经悄悄发生了变化：从亲手干活的执行者，变成了给AI定规则的决策者。我们的核心工作，变成了给AI写清楚“工作手册”，让它能精准、稳定、符合业务要求地完成任务，也就是“人服务于AI”。

这里还有个很有意思的黄金法则：你对AI的掌控力，完全取决于你对需求、规范、流程的定义能力。

AI不是不能干活，而是经常干得不稳、不深、不像一个真正懂你业务的人。你能把规则定义得多清楚，对AI的掌控力就有多强。

而实现这一切的核心抓手，就是之前文章提到的SDD规范驱动开发（Specification Driven Development）。用大白话讲，它的核心逻辑特别简单：把错误写成规则，把经验写成SOP，把SOP写成AI自己也能检查的门禁。

软件工程编程范式演进：以结构化Spec为核心，实现人机协同「一人即团队」

软件工程编程范式演进：构建企业级SDD编程范式“Skills + OpenSpec OPSX”

解决AI输出不稳定，这套三步闭环真的很实用

聊完了认知，再和大家分享一下最落地的部分，就是SDD的「Spec → Plan → Coding」三步闭环。它最难得的地方，是把人和AI的分工划得明明白白，既发挥了AI的能力，又不会让我们被AI牵着鼻子走。

第一步：Spec 规范定义

这一步是人类主导，AI辅助。 也是整个流程里最核心的一步。说白了，就是把我们脑子里模糊的需求，转换成AI能读懂、没有歧义、没有遗漏的结构化规范文档。

不管是业务需求文档、UI设计图，还是数据库设计，都要拆解成清晰的业务目标、用户角色、规则流程、验收标准。我们要做的，就是审核、修正、确认这份规范，确保需求没有任何模糊的地方，不给AI留任何“自由发挥”的空间。

这一步最终的产出，就是一份机器可读的Spec规范文档，这就是AI干活的“行动指南”。

第二步：Plan 计划拆解

这一步是AI主导，人类审核。 规范定好了，就该让AI发挥它的优势了。我们把Spec文档交给AI，让它去规划具体的技术方案和实现路径，具体到要修改哪些文件、分几步完成、每个节点的交付物是什么，最终输出一份完整的实施计划和任务清单。

我们不用自己费劲儿拆任务，只需要做好审核：看看技术方案合不合理，任务拆解得完不完整，有没有漏掉关键环节，有没有业务风险，把问题掐死在执行之前。

第三步：Coding 代码实现

这一步是AI执行，人类验收。 到了真正的执行环节，我们完全可以把具体的代码实现交给AI去做，不用再一行行敲代码了。

但这不代表我们可以当甩手掌柜。我们的核心工作，是在关键节点做验收，把控架构的合理性、代码质量，以及最重要的——最终的交付结果，是不是严格按照最初的Spec规范来做的。合格的就验收通过，不合格的直接打回，彻底告别AI生成的“看似能用，一跑就崩”的内容。

分享一个真实落地案例，看看这套方法用起来是什么效果

AI辅助编程开发生产级应用。 很多开发者用AI写代码，最怕的就是“看着能跑，一上线就崩”。而这套方法，给AI生成的代码上了一套全生命周期的“守护锁”。

整套流程严格遵循「Spec→Plan→Coding」的闭环，同时在代码变更的全流程里，嵌入了层层校验：从需求变更、AI生成内容开始，就先设置基础质量门槛，再做风险识别与分流、深度验证，每一个检查点，系统都能直接通过、要求补证，或者直接触发阻断。

代码能不能正常编译？测试覆盖率达不达标？有没有改动高影响的核心区域？全是自动化的硬约束，不合格的代码，连合入的机会都没有，彻底解决了AI代码质量参差不齐的问题。

如果团队想落地，这四步走的思路很有参考意义

如果有朋友想在自己的团队里试试这套方法，分享里也给了一个很稳妥的四步落地SOP，不是什么高大上的理论，都是能直接上手的步骤，也和大家分享一下：

第一步，先统一规范，搭建模板。由架构组牵头，先把全团队的Spec、Plan、Skills模板统一起来，沉淀高频场景的标准化技能，先让全员对齐认知，定好统一的“游戏规则”。

第二步，小范围试点，跑通闭环。不用上来就全团队铺开，先选低风险的业务模块做试点，跑通完整的三步闭环，记录过程中遇到的问题，优化方案，先做出可复制的成功经验。

第三步，全面推广，建设资产库。在全团队推行三步工作流的门禁，同时完善企业级的Skills体系，把团队的业务Know-how、踩坑经验、最佳实践，全部沉淀成可复用的技能资产，让团队的经验能真正沉淀下来。

第四步，持续迭代，优化模式。定期复盘团队的效率和质量数据，跟进行业最新的工具和方法，持续优化规范和流程，慢慢建设团队的AI工程化能力。

最后，聊点我自己的心里话

我们真的不用神化AI，也不用焦虑AI会替代我们。

AI终究只是一个工具，它能帮我们完成重复繁琐的执行工作，能帮我们提升效率，但它永远替代不了我们对业务的理解、对规则的定义、对风险的把控。

Skill的作用，从来不是让AI更聪明，而是让AI在你的业务里更可靠。而我们要做的，就是完成从执行者到决策者的角色跃迁，用规范约束AI，而不是被AI的自由发挥牵着走。