软件工程被重构之后，企业重建什么

引言

上一篇的结尾，留了一句话：诊断清楚了，处方才有意义。这一篇，就是那张处方。

上一篇我们讨论"变了什么"：AI把软件工程的重心，从腰部移向了两端，中间的实现被大幅压薄，两端的规格与治理被抬高。那么，组织怎么跟着这条曲线去适应呢？

过去几十年，大多数软件工程组织的形状，是围绕"实现"长出来的：以代码产能为轴心，按人数配资源，以产出论绩效。但现在，产能不再稀缺，判断才稀缺。组织的形状如果不跟着改，多出来的产能只会更快地制造混乱。相信非常多的资深工程师都会遇到同样的问题，“代码屎山”这个难听的自嘲词语从来没有缺席过。

我认为"重建"拆成四个维度：组织架构（谁对什么负责）、人才管道（判断力怎么传下去）、产品与交付（流程怎么整形）、探索与观察（怎么保持方向感）。

这篇不谈"买什么工具"，也不给"必装清单"——工具是四个维度里最不重要的东西。要谈的是另一层：当产能的供给方变了，组织、人才、流程和视野，需要怎么跟着变。

提前交代两句：如果读者本身就是资深管理人员，且已经有非常独到的洞察，那么这篇文章可能并不适合您。这篇不是标准答案，更像一份讨论稿。给那些正在扩张人力储备、调整组织结构，并大幅提升AI工具化应用的团队共同探讨。

企业适应 AI 重构的四个维度，中心是"判断与责任"

一、组织架构：谁对什么负责

实现环节被压缩之后，"堆人扩产能"的杠杆失灵了。过去，加人约等于加产能；现在，产能完全由AI供给，人加错了位置，增加的反而是协调成本与风险面。组织要调的不是人多人少，而是"判断与责任"的密度——让每一个进入系统的决定，都有一个明确的人在负责。

软件工程组织的形状大致要长成三层。

决策层：定方向、定标准、定不可谈判的红线（安全、合规、长期健康）。

中枢层，也就是规格与架构的中枢：把业务意图翻译成规格，把规格拆成任务，把任务定义成可验收的边界，对系统的长期健康负责。这一层最容易被"扁平化"顺手压掉，本人在最近三年的顾问工作中，遇到这类企业的情况不是个例。现在，需要它重新长回来，它是微笑曲线两个抬起端共同的支点。

执行层：人加AI的混合产能。编码与测试的大部分工作被AI承接，人负责验收、集成与最后一公里。

随之而来的是角色重排。过去按技术栈分人——前端、后端、运维；今后，或许更合理的分法，是按责任分：规格定义者、验收与集成者、系统的长期责任人、AI协作规范的维护者。同一个人可以身兼数角，但每一个角色，都要能回答"出了问题找谁"。

还有一个绕不开的问题：中枢层的人，应该从哪里来？是他们，原来的团队中里那些资深的开发工程师。过去，他们是团队里最贵的产能；今后，他们应该成为最重要的节点：写规格、定契约、审架构、带新人。

治理也要跟着回归。架构评审与规格评审，重新变成硬动作，而不是流程装饰；规格与契约也不应该是一次性文档，而要沉淀为组织资产，使其可归档、检索、复用和演进。这些资源分布在各种AI编程工具中，比如spec，rule等等。

这一维最大的风险，是把"扁平"当成目的。中枢层一旦塌陷，AI的产能就失去了对接的两端——产能越猛，混乱越大。

二、人才管道：判断力怎么传下去

四个维度里，这一维决定了团队的长远发展能力。

过去，判断力是从底层长出来的。写代码、改bug、救火、返工，这些重复劳动，其实是判断力的孵化器：当一个人写下足够多的代码，接触了足够多的不同应用，才慢慢有了对软件系统的直觉；踩过的坑，变成了他对风险的嗅觉。传统的晋升管道，大概率是架在这个孵化路径之上的 —— 从写代码，到定接口，再到定架构。

现在AI把这个路径的底层抽掉了。新手变得冗余，大多数工作AI即可完成，成长的第一级台阶凭空矮了一截，这会带来一个延迟发作的后果。如果我们对人才培养的标准仅仅是精通使用各种AI编程工具，那么他的判断力、决策力又如何长出来？过去这大概率会形成未来的"判断力断层"。

断层不只在底层。更隐蔽的一层在中段：工作两到五年的工程师，过去靠代码质量写得又快又好立足。如今在AI的世界，评估坐标错位了，他们的位置突然尴尬。上又上不去，架构判断还没长成，下也下不来，拼开发交付效率已无意义。AI抬高了所有人的下限，也压扁了中间的台阶。对团队来说，这层人是最容易被扁平化简单淘汰的，但是他们是中枢层几乎唯一的来源，要做的是把他们从"产能"重新塑造成"判断"。一个人走这条路，是从"代码生产者"到"系统架构师"；一个组织走这条路，那就是重建。

比较合理的组织分层，可以是：

层级	能力标志	关键动作
入门层	会用 AI、能写清规格、能审查与验收	从"能写"转向"能判断对不对"
进阶层	能定契约、能判断架构取舍、能识别风险边界	在真实系统上，有监督地做决定
高阶层	定方向、定标准、对系统的长期健康负责	对结果负责，而不只是对过程

培训，也得跟着变。教语法、教框架的时代过去了，现在要教的是判断力：读代码（包括AI写的代码）、审设计、做故障复盘。而判断力不会从培训课里长出来，只能从有监督的练手机会里长出来：在真实系统上、有人兜底的前提下，让新人做真实的决定，并承担可承受的后果。

过去我们做团队培养，会分享bug、设计缺陷、优质代码以及各种案例。未来，还需要多一个非常重要的培训内容，那就是AI为什么会这么思考，怎么导致了AI输出了这样的结果，哪些真实的决策是AI永远无法确定性的输出的。人机分工的状态是否最佳，如何螺旋式提升。

还有一条容易被漏掉的：管道不只是给新人的。今天最会写代码的人，明天必须成为最会写规格、最会验收、最会判断的人，老兵的经验仍然值钱，但用法变了。

三、产品与交付：流程怎么整形

这一维的方向，一句话可以说完：从"以代码为中心"，掰成"以规格与契约为中心"。

产品设计上，规格先行（Spec First）不再只是好习惯，而是输入条件：PRD/SOW 从"给人看的文档"，变成"给 AI 的输入 + 验收的基线"。同时要保持好双轨，探索期可以用快速原型换速度，生产期用规范驱动换确定性。如果两套节奏混用，是事故最常见的温床。

开发环节的格局，大致为：规格驱动、AI产能、人验收。核心逻辑由人主导，实现交给AI；每一段进入系统的代码，都要能回答"谁放行的"。

对大型应用系统开发，未来的主工具箱，大概率是FDD与SDD —— 特性驱动开发（Feature-Driven Development）与规格驱动开发（Spec-Driven Development）。

SDD 是这两年长出来的新范式：把"什么算对"事先写成明确、可验证、AI 可读的规格，再让 AI 围绕规格生成、对照规格验收——规格从"过程中的文档"升格为"第一工件"，它同时是给 AI 的输入、人机之间的协作契约、最终的验收基线。某种意义上，SDD 就是把上一篇里"规格先行"那句话，做成了工程方法。它对企业真正的价值，是把"意图"变成可管理的对象：产品定"做什么"、架构定"怎么做"、工程落到"具体任务"，每一步都有可检查的中间物——恰好是中枢层最趁手的工具。这不是纸面推演，国内已经有金融企业把它落进私域研发体系。

FDD 则是一套老方法：诞生于复杂的系统开发，核心是按"特性"组织一切。建特性清单、按特性规划、按特性设计、按特性构建；每个特性都必须对客户有价值，且小到一两周可交付。它在当年的"敏捷之争"里没火起来，被更简单的scrum盖过风头。但"没火"的原因，恰恰是它在今天的机会。FDD一直被认为"重"，因为拆特性、设计特性要消耗大量人力。而现在，这部分工作有相当一块可以交给AI，人只保留最关键的判断与验收。新的成本结构将它又端上了桌面。

两者其实是互补的：SDD管"什么算对"，FDD管"怎么切开做"。一个定义验收，一个定义切分。系统规模大、角色多、生命周期长，最需要的就是这两样合体——一个特性、一份规格、一轮验收，正好完成了 "人定义意图 + AI执行 + 人验收与担责" 的一个完整闭环。（更系统的论述，见文末参考文章）

当然，我认为SDD也有坑。落地不当，它会变成文档洪水，会养出一头"Markdown怪兽"。分寸在于：规格是拿来用的，要像代码一样被维护、迭代、演进和淘汰。

交付是最被低估的一环。部署几乎没被AI解决，甚至风险更大。某些情况下AI给出的版本、依赖、配置信息可能已经过时，照单全收，就是给未来埋雷。这一环得守住人工复核的最后一公里。我曾在一个基于全球节点进行分布式部署的场景中，需要实现中心化配置以及分区环境的自动化推送。在灰度环境上，AI就遇到了无比的困难。但是他会在规格文档中自行探索，以幻觉的方式理解他能够实现的路径。

运维的权重同步上升：生成代码量越大，长期可维护性、可观测性、技术债就越要命。它们从后台指标，变成了核心矛盾。

最后是治理的嵌入：把AI放进每个环节（规格、测试、审查、部署校验），同时确立好AI代码的准入规范（什么可以生成、什么必须人写）、审查清单、问责链。度量的尺子，也得换：从代码量、故事点，转向系统健康度——缺陷率、返工率、审查时长、技术债增速。

四、探索与观察：保持方向感

前三个维度是"术"，这一维是"道"。如果道也要一句话，那就是：以不变应万变。

AI是这个时代最让人眼花缭乱的领域：新模型、新架构、新评分榜按月刷新；prompt、agent、context、MCP、skills、harness、loop……新词层出不穷。企业最容易犯的错，是追着新词跑——把工具当成了目标。我的思考是看反面：到底什么没变。

这些新词其实都指向同一个方向：一个正在被全面重构的信息技术世界。面对任何一个新概念，先问一句："它解决了哪个工程根本问题？"。如果答得上来，值得试；答不上来，先放下。这一个过滤器，能滤掉八成的噪音。

再往深一层，回到AI的本质：概率模型，加上模式的生成与匹配。它本质上是一台放大器——放大你的意图，也放大你的错误。它的能力边界，值得我们贴在手边：

• 能做：生成、翻译、总结、模式识别、批量重复。
• 不能做：担责、理解业务约束、做价值判断、保证确定的正确、理解因果。

真正稀缺的从来不是新工具，而是清醒的认知。

结语

AI不会取代软件工程，它重排了软件工程的权重 —— 中间塌陷、两端抬高。我们要做的，是沿着这条曲线，把组织、人才、流程与视野一并重新排布。

本文不承诺捷径。四个维度不会同时见效，也不该同时铺开。先把规格与验收立起来（流程），再补上中枢层的位置（组织），然后做最有耐心的事（人才）；而视野，是贯穿始终的底色。从哪个维度动手，取决于你的系统处在哪个阶段：救火中的团队，先补交付的最后一公里；扩张中的团队，先立规格；而所有团队此刻都值得做的一件事，是把"判断与责任"写进岗位描述里。

有一件事从头到尾没有变：工程的基本盘——可维护、可观测、可扩展、可问责。工具会继续翻新，新词会继续涌来，但这四样东西，是系统能持续运行若干年的全部理由。

上一篇，重新思考了什么是软件工程；这一篇，是重新建设。至于在团队手里具体怎么落地，我曾在Vibe Coding系列的文章中写过一部分。

总之，工具方法会变，基本盘不会。

---

参考文章

1. 《规范驱动开发——企业规模化落地实践》—— InfoQ：https://www.infoq.cn/article/OOwOxKFZQbShKx1timMP
2. 《规范驱动开发：让架构变得可执行》—— InfoQ：https://www.infoq.cn/article/iCTcI93pGKD0aqoQv7ae
3. 《SCRUM 对 SDD 的启发与警醒》—— 温昱：https://cloud.tencent.com.cn/developer/article/2608137
4. 《民生银行基于规格驱动开发（SDD）的 CodeAgent 私域研发探索与实践》—— 阿里云开发者社区：https://developer.aliyun.com/article/1733237

---

本文由作者执笔，观点、经历与判断均出自本人；AI 辅助的只是资料核实、文字润色与排版校对