本文作者吴穹博士近 30 年行业沉淀北京大学软件工程博士行业知名的精益与敏捷创新管理专家软件工程专家。过去一年我们在很多研发组织里都能观察到一个相似现象AI的使用已经从个人尝鲜逐步进入日常研发工作。产品经理开始用AI生成原型工程师用AI阅读代码、生成代码、补充测试测试人员用AI整理用例和分析缺陷架构师也开始借助AI做方案评审和影响分析。从个人视角看这种变化是实实在在的。过去需要花很久才能理解的代码现在AI可以先帮忙梳理主线过去需要反复复制修改的样板代码现在可以生成初稿过去容易遗漏的测试点也可以先让AI做一轮补充。但回到组织层面很多管理者的感受并没有那么强。需求仍然在排队版本仍然按原来的节奏推进跨团队沟通仍然很多测试环境仍然紧张联调和评审仍然需要反复协调。每个人似乎都变快了一些但组织整体并没有同步变快。这形成了AI时代软件工程里的一个典型悖论个人提效已经发生但组织提效没有自然发生。原因并不复杂。软件交付从来不是一个人的工作而是一条协作链路。需求要澄清方案要评审代码要合入测试要验证环境要准备数据要构造发布要协同问题要追踪。如果这些环节仍然按旧方式运转只是每个人多了一个AI工具组织效率就很难出现根本变化。所以AI给软件工程带来的第一个问题不是个人能不能变快。这个问题的答案已经很清楚。真正的问题是个人变快之后组织有没有新的协作方式来承接这种变化—— why ——成本结构变了组织也必须变AI 改变的不只是开发工具而是软件开发的成本结构。过去很多研发组织最大的瓶颈是开发产能。需求来了要排期方案定了要等人写代码功能复杂一点就要投入更多开发资源。现在这个结构开始变化。代码理解、代码生成、测试补充、缺陷分析和文档整理的成本正在下降。代码仍然重要但“写出代码”本身正在从最稀缺的能力变成可以被 AI 大幅放大的能力。新的瓶颈开始转移到其他地方。需求是否足够清楚架构边界是否合理测试能否自动化验证环境和数据能否快速准备代码能否安全合入知识能否沉淀复用发布以后能否快速验证价值这些问题会变得越来越关键。与此同时AI 又带来了大量新的应用需求。企业开始需要智能客服、智能运营、智能分析、个人智能体、企业智能体、知识库问答、流程自动化和人智协同平台。软件系统不只是给人使用也要给智能体调用不只是提供页面也要提供接口、上下文、权限、工具和可审计的执行环境。这意味着研发组织不能只是“给每个人配一个 AI 工具”。图 1大模型与 Agent 能力演进趋势任务变了成本结构变了协作对象也变了。产品、开发、测试、架构、数据、知识、平台和安全都需要重新分工重新协作重新组织。我们认为AI 时代的软件工程变革不能停留在个人效率提升上而必须进入一套新的组织模式。这就是本文要讨论的 52 新范式。—— what ——52 新范式用新的生产关系承接新的生产力为什么需要一套新的范式因为 AI 同时改变了两件事。第一软件开发的成本结构变了。过去很多依赖人力堆出来的工作现在可以由人和 AI 一起完成。第二软件系统面对的需求变了。未来的软件系统不只是给人使用也要给智能体调用。成本变了需求变了研发工作的内容也会随之变化。过去软件研发主要围绕“把功能做出来”展开。现在团队还要回答一组新的问题需求能不能被 AI 快速理解代码库能不能被 AI 安全修改测试能不能被 AI 自动执行环境和数据能不能被 AI 快速准备知识能不能被 AI 持续复用架构原则能不能被自动守护高风险决策什么时候必须由人审核AI 带来的成本和收益能不能被度量这些问题已经超出了单个工具的范围。它会催生新的角色要求新的流程和工艺也会沉淀出新的工程资产需要新的工具平台来承载并进一步要求新的治理模式。因此AI 时代的软件工程不能只看“工具升级”而要看一整套生产关系的重构。我们把这套新范式概括为 52。图 2AI 时代软件工程 52 新范式前面的“5”是软件工程主体部分的变化后面的“2”是支撑系统52 新范式1/5 新角色从Developer到Builder。研发组织需要 Product Builder、Application Builder、Agent Builder、Test Builder、Platform Builder以及架构、前端、后端、测试、UX、安全、性能等专家角色。2/5 新组织组织形态会从传统职能分工走向 FDE 团队、产品团队和平台团队三层协同。3/5 新工艺软件交付会从线性流程走向创意、需求、交付、运营四个持续闭环。4/5 新流程FDE 负责快速探索产品团队负责产品化沉淀平台团队负责底座化沉淀代码和能力在三层之间流动。5/5 新资产需求文档、设计文档、代码、测试案例、数据脚本、契约、Skill、Agent 记忆、本体网络都会变成可复用、可演进的工程资产。1/2 新工具工具体系会从“人使用系统”升级为人类、个人智能体、企业智能体共同协作的人智协同平台。2/2 新治理AI 协同评审、架构评审 as Code、AI 代码评审、AI 技术债治理、多层自动化测试、Human in the Loop、FinOps 和 Token ROI会成为新的治理能力。52 不是七个概念的罗列。它真正要解决的是一个问题如何把个人使用 AI 的效率转化为小队、产品线和组织的系统效率。—— 52 新范式 ——新角色从 Developer 到 Builder52 新范式的第一件事是角色变化。AI 时代的软件研发组织不再只是围绕 Developer 分工而会逐步围绕 Builder 分工。这里的 Builder不是简单换一个岗位名称。它强调的是人不再只负责某个狭窄环节而是要和 AI、Agent、平台、资产一起把业务问题构建成可运行、可验证、可持续演进的系统。未来研发组织里至少会出现五类 Builder。图 3AI时代软件工程新角色地图第一类是Product Builder。它来自传统产品经理但不再只是写需求、排优先级、组织评审。在 AI 辅助下产品角色可以更快生成界面原型更快和业务讨论需求也可以基于数据反馈判断功能效果。部分具备编码能力的产品角色甚至可以在 Agent 或前端 FDE 的帮助下直接修改简单页面快速验证想法。Product Builder 的核心变化是从“需求管理者”变成“产品构建者”。第二类是Application Builder。它来自传统开发工程师也是 Developer 演进的主方向。随着代码理解、代码生成和测试补充成本下降开发人员会越来越全栈化。这个全栈不只是前端和后端一体化还会进一步走向应用、数据、算法一体化。Application Builder 需要更靠近业务参与需求澄清、原型验证、方案设计和价值反馈。同时他也要带着 Agent 守护代码质量负责自动化测试、影响分析、回归验证、文档更新和基础质量闭环。Application Builder 的核心变化是从“写代码的人”变成“应用系统构建者”。第三类是Agent Builder。它不是简单写 Prompt 的人而是建设智能体能力的人。Agent Builder 负责设计 Agent 工作流沉淀 Skill连接工具组织上下文构建评测体系管理记忆、权限和版本让智能体可以稳定参与软件交付。在这个体系里Agent 是任务执行主体Skill 是可复用能力资产。成熟组织不会长期依赖临时 Prompt而会把高频任务沉淀成 Skill再通过版本化、评测和治理持续演进。Agent Builder 和知识工程师会有很强的重叠。因为好的 Agent 离不开高质量知识资产、本体网络、业务规则和上下文组织。Agent Builder 的核心变化是从“使用 AI”变成“构建 AI 能力”。第四类是Test Builder。测试角色不会消失但工作重心会改变。当开发人员可以在 Agent 辅助下完成更多自测、自动化测试和功能验收传统手工执行型测试的占比会下降。测试人员会更多转向测试基础设施、专项测试、测试覆盖强化、质量门禁、测试数据构建和自动化策略设计。Test Builder 不只是发现问题的人而是构建质量体系的人。Test Builder 的核心变化是从“测试执行者”变成“质量基础设施构建者”。第五类是Platform Builder。它来自平台团队、架构团队和各类支撑团队。AI 时代的一线小队要高效运转背后必须有强大的平台能力支撑包括 AI 平台、数据平台、知识平台、工程平台、CI/CD、环境管理、权限管理、观测体系、FinOps、架构守护、公共工具链和公共 Skill。Platform Builder 不只是响应项目需求而是沉淀组织级能力让更多 FDE 小队可以低成本复用。Platform Builder 的核心变化是从“平台支撑者”变成“组织能力构建者”。这样看未来的一线小队并不是简单由传统产品、开发、测试组成而会形成新的组合。Product Builder 负责产品判断和快速原型Application Builder 负责应用交付和质量闭环Agent Builder 负责智能体能力和 Skill 沉淀。Test Builder 和 Platform Builder 更多在产品团队、平台团队中提供支撑也可以根据阶段需要前置到一线小队。当然Builder 化并不意味着专家角色消失。恰恰相反当一线角色变宽之后组织更需要少量高水平 Expert 来管理复杂性。Architecture Expert、Performance Expert、Security Expert、UX Expert、Frontend Expert、Backend Expert、Testing Expert、Data Expert 等角色仍然非常重要。只是他们的工作方式会发生变化。过去很多 Expert 更像流程后面的审批关口。需求设计好了代码写完了问题暴露了再请架构、安全、性能、体验专家来评审和兜底。未来Expert 更应该作为产品团队和平台团队中的专家角色承担能力中心职责负责定义标准、沉淀资产、建设工具链和质量门禁。也就是说Expert 不一定需要单独设成专职专家部门。更好的方式是让专家能力长在产品团队和平台团队里把专业能力产品化、工具化、资产化让更多 Builder 小队可以复用。所以未来的角色体系不是“Builder 替代 Expert”而是两类角色重新协作Builder 负责交付闭环Expert 负责能力沉淀和复杂性治理。这就是角色变化的本质不是让每个人都变成超级个体而是让组织围绕 Builder、Agent、资产和平台重新分工。—— 52 新范式 ——新组织FDE 团队、产品团队和平台团队三层协同角色变化之后组织形态也必须变化。如果还是按照传统职能墙来组织Product Builder、Application Builder、Agent Builder、Test Builder 和 Platform Builder 的能力很难真正发挥出来。个人可以变快但协作链路仍然很长组织仍然会慢。未来的软件研发组织可以逐步演进为三层结构。图 4AI 时代软件工程新组织第一层是前置到业务的FDE 团队。FDE 团队由多个业务 FDE 小队组成每个小队规模可以控制在 3-5 人。这些小队不是传统意义上的项目组而是前置到具体业务场景围绕需求澄清、快速原型、契约驱动开发、交付验收和价值反馈形成闭环。一个 FDE 小队里通常会包含 Product Builder、Application Builder 和 Agent Builder。根据阶段需要也可以临时引入 Test Builder 或 Platform Builder 支持。多个业务 FDE 小队可以进一步组成 FDE 领域团队。领域团队面向一个业务域沉淀经验、资产、Skill 和最佳实践让单个小队的能力可以在领域内复用。FDE 团队的核心价值是让业务变化可以更快变成可运行、可验证的软件变化。第二层是面向业务应用的产品团队。业务应用仍然需要按照产品来组织。一个复杂产品可以拆成多个产品小队每个小队同样控制在 3-5 人。多个产品小队组成产品线团队负责一个产品或产品族的长期演进。产品团队不是只负责需求管理也不是只做版本排期。它要负责产品架构、复杂共性需求、代码复审、重构优化、技术债治理、测试强化和版本发布。FDE 小队可以快速闭环修改产品但这些修改不能长期停留在局部最优。产品团队需要对这些变化进行复审、吸收、重构和熵减把一线创新沉淀为产品能力。因此产品团队承担的是“产品长期健康”的责任。Architecture Expert、UX Expert、Frontend Expert、Backend Expert、Testing Expert、Performance Expert、Security Expert 等专家角色可以作为产品团队成员存在。他们不一定是专职审批者而是在产品演进过程中持续建设标准、工具、Skill 和质量门禁。第三层是提供底座能力的平台团队。最底层是平台团队包括 AI 平台、数据平台、知识平台、应用平台、工程平台等。平台团队的职责是为 FDE 团队和产品团队提供可复用的组织级能力。AI 平台提供模型接入、Agent 运行、评测、权限、观测和 Token 成本治理。数据平台提供数据资产、指标口径、分析能力和数据脚本。知识平台提供本体网络、知识检索、记忆管理和知识资产治理。应用平台和工程平台提供环境、CI/CD、CLI、自动化测试、发布治理和运行支撑。平台团队也应该由多个小队组成而不是一个大而全的中心部门。每个平台小队围绕一类平台能力持续演进并把能力以工具、接口、Skill、规则和服务的方式提供出去。平台团队的核心价值是让组织不必在每个产品、每个小队里重复建设底层能力。这样未来组织就形成了三层协同FDE 团队贴近业务负责快速闭环产品团队面向产品负责复审、重构和熵减平台团队沉淀底座负责组织级能力复用。这三层不是上下级审批关系而是基于资产和智能体协同的能力流动关系。FDE 小队把业务想法更快变成产品变化产品团队把这些变化沉淀成稳定产品能力平台团队再把共性能力沉淀成更底层的平台能力。反过来平台能力会推回给产品团队产品能力会推回给 FDE 小队让一线团队的交付成本越来越低。这就是新组织的核心组织不再只靠职能分工运转而是通过 FDE 团队、产品团队和平台团队三层协同把一线变化持续沉淀为产品能力和平台能力。—— 52 新范式 ——新工艺四大闭环和两个底座有了新的角色和组织还需要新的工艺。过去的软件交付通常被理解为一条流程需求分析、方案设计、编码开发、测试验收、发布上线。这条流程在 AI 时代仍然有价值但已经不够了。因为 AI 让很多工作可以更早发生、更快验证、更频繁反馈。产品可以快速做原型Agent 可以提前阅读代码提出问题Builder 可以带着 Agent 完成实现和测试FDE 可以根据运营数据直接推动系统优化。因此新工艺不应该只是把原来的线性流程切得更细而应该把关键工作变成持续闭环。我们认为可以概括为四大闭环和两个底座。图 5AI 时代软件工程新工艺第一是创意闭环业务 - 产品/Agent - 原型 - 业务。这一环解决的是“做什么、值不值得做”。业务提出问题或机会Product Builder 借助 Agent 快速生成原型、场景说明和价值假设再回到业务侧讨论、试用和调整。它的输出物不是完整 PRD而是业务场景、价值假设、原型和 BRD。这个闭环的核心是低成本把想法变成可讨论、可试用、可调整的东西。第二是需求闭环产品 - 编码 Agent - 问题 - 产品。这一环解决的是“需求能不能落进现有系统”。产品不再只是闭门写 PRD而是让编码 Agent 读取代码、接口、数据结构、历史需求、现有配置和系统约束由 Agent 反向提出问题。这些问题再回到产品侧促使产品不断澄清边界、异常、权限、状态流、兼容性和验收标准。它的输出物是高质量 PRD、澄清问题清单、验收标准和需求契约。这个闭环的核心是让需求在进入开发前就和真实系统发生碰撞。第三是交付闭环Builder - 需求 - Spec - Coding - 测试验收 - Builder。这一环解决的是“如何交付高质量代码”。Builder 接收高质量需求后和 Agent 一起把需求转成 Spec再细化设计、编码实现并在真实或准真实环境下完成各种测试验收。这里的质量不再单独作为最后一道关而是内嵌在交付闭环里。自动化测试、CLI 环境准备、测试数据构建、AI 代码评审、架构规则检查、功能验收、回归测试都应该成为交付过程的一部分。它的输出物是 Spec、详细设计、代码、测试案例、验收结果和高质量可发布版本。这个闭环的核心是交付不是写完代码而是完成可验证的系统变化。第四是运营闭环FDE - 运营数据 - 调整系统 - FDE。这一环解决的是“上线后有没有创造价值”。FDE 不只是交付需求也要持续观察系统运行后的真实反馈包括用户行为、业务指标、运营数据、日志、问题反馈和实验结果。这些反馈会直接推动下一轮系统调整形成持续优化。它的输出物是运营数据、价值评估、优化清单、调整后的系统和下一轮需求。这个闭环的核心是交付代码不是终点交付价值才是终点。在四个闭环之下还需要两个底座。第一个底座是知识联通底座。所有关键知识都要尽量在代码库或强关联资产中沉淀。需求、设计、代码、测试案例、数据脚本、接口契约、业务规则、运营数据、决策记录都不应该孤立存在。它们需要通过本体网络、语义检索、向量检索和代码引用关系连接起来让人和 Agent 都能低成本获取上下文。知识联通底座解决的是让知识可被人和 Agent 共同理解。第二个底座是经验进化底座。每次交付、失败、评审、测试、运营反馈都应该沉淀成可复用经验。Prompt、Skill、Agent 记忆、失败案例、测试集、质量规则、架构规则、专家经验和最佳实践都需要被版本化、评测和持续改进。这些经验反过来升级 Agent、Skill、规则和流程让组织越用越强。经验进化底座解决的是让组织经验不只留在人脑里而能持续进化成能力。所以新工艺可以概括成一句话四个闭环负责让业务想法持续变成价值两个底座负责让知识和经验持续进化。—— 52 新范式 ——新流程让代码和能力在三层之间流动如果说新工艺解决的是一次需求内部如何闭环那么新流程解决的是组织内部如何流动。AI 时代的流程不能再简单理解为“需求从产品流向开发再流向测试和发布”。新的流程要允许前线更快探索也要允许后线持续熵减。图 6AI 时代软件工程新流程在第一层FDE 团队前置到业务围绕创意闭环、需求闭环、交付闭环和运营闭环快速推进。为了满足客户要求FDE 可以直接修改产品代码在必要场景下也可以修改平台代码。产品智能体和平台智能体会参与设计和架构评审帮助识别影响范围、风险点和更优方案但它们不应该成为低风险探索的阻塞点。也就是说智能体参与评审是为了更早发现问题、提示风险、把握方向而不是把流程重新变成排队审批。在第二层产品团队接收 FDE 的代码贡献和场景经验。产品团队要对这些变化进行复审、重构、熵减、测试强化和产品化发布。前线代码不一定一开始就是最优产品实现但只要它验证了业务价值就应该被产品团队吸收和沉淀。产品团队也可以在必要时修改平台代码推动平台能力补齐。在第三层平台团队接收来自产品团队或 FDE 的平台改动和共性需求。平台团队负责复审、重构、优化平台、强化测试和平台化发布把共性能力沉淀成稳定底座再推回产品团队和 FDE 使用。这个流程能跑起来有一个前提自动化测试必须足够强。因为只有测试、环境、数据和质量门禁可以自动化验证产品团队和平台团队才敢对前线代码进行重构FDE 也才敢更快探索。所以新流程的本质不是多一层审批而是形成一种内部开源式的流动机制。FDE 负责快速探索产品团队负责产品化沉淀平台团队负责底座化沉淀。智能体参与评审但不替代责任自动化测试保障重构和复用。代码和能力在三层之间流动经过复审、重构、测试和发布最终反哺前线。这也意味着流程的关键不再是“谁先批准”而是“谁能快速贡献谁来持续熵减谁负责稳定复用”。—— 52 新范式 ——新资产从文件沉淀到语义连接进入 AI 时代以后软件工程资产的边界会明显扩大。在 DevOps 时代我们强调 Everything as Code希望环境、配置、流水线、基础设施都可以被版本化、自动化和可追溯。到了 AI 时代仅仅“代码化”还不够。因为大模型和 Agent 真正需要的不只是代码本身而是完整上下文。需求文档、设计文档、代码仓库、测试案例、数据脚本、接口契约、运行日志、评测集、架构决策和历史缺陷都会成为 Agent 理解系统、生成方案、执行任务和验证结果时需要调用的上下文。同时还会出现一类过去并不被充分重视的新资产Agent 执行过程数据。例如Agent 如何拆解任务调用了哪些工具参考了哪些文档在哪些步骤失败测试报错如何修复人类在哪些地方进行了纠偏某个 Skill 在什么场景下表现稳定、在什么场景下容易失效。这些过程数据不能只是临时日志。它们应该被保存、结构化、评测和复盘成为优化 Prompt、沉淀 Skill、增强 Agent 记忆、扩充评测集的重要来源。这意味着AI 时代的工程资产不再只是“最终产物”还包括“产生最终产物的过程”。但资产多起来以后如果只是把文档、代码、日志和案例堆进仓库价值仍然有限。新的关键是用本体网络把这些资产连接起来。业务概念、系统边界、模块职责、数据实体、接口契约、业务规则、测试案例、运行指标、缺陷记录和架构决策都需要形成语义关联。这样大模型检索信息时才不是只靠关键词或向量相似度去“猜”而是可以沿着业务语义、系统关系和工程依赖找到更准确的上下文。新资产大体可以分成三层。图 7AI 时代软件工程新资产第一层是底层工程资产包括需求、设计、代码、测试案例、数据脚本、契约/API、运行日志、评测集和 Agent 执行轨迹。第二层是语义连接层用本体网络和知识图谱把概念、系统、数据、规则、接口、测试和经验连接起来。第三层是能力资产包括 Agent 记忆、Skill、Prompt、工具调用模板、评测集和专家规则。随着使用不断发生底层资产会持续增加本体网络会持续完善Agent 记忆和 Skill 也会持续进化。所以新资产不是把更多文件放进仓库而是把软件交付过程中的知识、经验和执行轨迹变成人和智能体都能理解、检索、调用和进化的组织资产。—— 52 新范式 ——新工具以智能系统为中枢的生产平台谈 AI 时代的新工具不能只从“多了哪些 AI 工具”开始看。更好的切入点是回到企业软件体系本身。过去很多企业 IT 架构可以用几类系统来理解。图 8AI 时代软件工程新工具第一类是System of Record记录系统。它负责记录确定性业务事实比如客户、订单、合同、账户、库存、交易、状态和审计记录。AI 时代到来以后System of Record 不会被替代。恰恰相反它的重要性会更高。因为智能体越能行动越需要有一个可靠的事实底座告诉它什么是真的、什么已经发生、什么可以被追溯。第二类是System of Engagement互动系统。它承载人与业务、人与组织、人与客户之间的互动比如门户、移动应用、协同系统、消息系统、审批系统和客户触点。在移动互联网和数字化时代很多企业的建设重点是把更多用户、员工和伙伴连接到互动系统上。第三类是System of Insight洞察系统。它把记录系统和互动系统产生的数据汇聚起来通过报表、分析、模型、指标和实验帮助组织理解发生了什么、为什么发生、下一步可能怎么做。对于软件研发组织还存在一类过去不一定被单独命名、但一直非常重要的系统可以称为System of Delivery交付系统。它包括需求管理、项目协同、代码仓库、分支管理、CI/CD、自动化测试、制品库、环境管理、发布管理、缺陷管理、监控告警和事故复盘。这类系统记录的不是业务交易而是“组织如何把想法变成软件”的过程。AI 来了以后真正发生变化的正是这套交付系统。原来的交付系统主要服务人类工程师记录任务、流转流程、管理代码和发布。新的交付系统要同时服务人类和智能体。它不仅要管理工作项还要管理 Agent 身份、权限、任务队列、执行日志、工具调用、上下文引用、Skill 版本、评测结果、Token 成本、质量门禁和人工审核。也就是说原来的 System of Delivery不只是多接入几个 AI 工具而是要长出一层面向人和智能体共同工作的协同入口。这层入口可以称为人智协同平台或者 Delivery Workbench。但需要注意它不是独立于交付系统之外的总平台而是 System of Delivery 的 AI 化扩展。它负责把需求、任务、代码、测试、环境、发布和复盘这些交付活动组织起来同时把桌面智能体、云端智能体和人类工程师连接起来。从归属上看它仍然属于 System of Delivery从作用上看它连接 System of Delivery 和后面要讲的 System of Intelligence。在这个基础上还需要补两层 AI 时代的新系统。第一层是System of Ontology本体系统。它不是一个普通知识库而是负责把业务概念、系统边界、数据实体、接口契约、业务规则、测试案例、运行指标、架构决策和历史缺陷连接起来。它既连接 System of Record 里的确定性事实也连接 System of Delivery 里的工程资产还连接 System of Insight 里的指标和分析结论。如果没有这层本体系统智能体只能在文档、代码和数据之间做相似度检索很容易找错上下文、误解概念、遗漏约束。有了本体系统智能体才更容易知道这个需求影响哪个系统涉及哪些数据实体调用哪些接口触发哪些规则需要补哪些测试可能破坏哪些架构边界。第二层是System of Intelligence智能系统。这里需要和 System of Insight 区分开。System of Insight 主要回答“看见什么、理解什么、预测什么”。System of Intelligence 则进一步回答“应该怎么做、由谁来做、调用什么工具、如何验证结果、什么时候交给人类审核”。在 AI 时代System of Intelligence 应该成为新的智能中枢。它包括大模型、Agent 运行平台、多智能体协作、工具调用、记忆、规划、评测、权限、风险分级和 Human in the Loop。其中智能体可以进一步分成两类。第一类是桌面智能体。它更像人类员工的个人助手跟随个人上下文工作帮助生成、总结、检索、提醒、局部执行和辅助判断。它的关键价值是增强个人的工作半径让产品经理、Builder、测试人员、架构师都能更快完成原本需要大量手工操作和上下文切换的工作。第二类是云端智能体。它更像企业里的数字员工运行在云端拥有独立身份、角色权限、任务队列、操作日志和责任归属。它可以接收任务、调用工具、执行流程、提交结果也需要受到权限、审计、成本、质量门禁和人工审核机制的约束。桌面智能体增强个人云端智能体增强组织。二者都属于 System of Intelligence但工作方式和治理要求并不一样。如果说 System of Engagement 是人进入系统的互动入口那么 System of Intelligence 就是智能体理解意图、组织上下文、调用工具并推进任务的执行中枢。所以AI 时代的新工具体系可以理解为一次企业软件架构的扩展。System of Record 仍然负责事实。System of Engagement 仍然负责互动。System of Insight 仍然负责洞察。System of Delivery 仍然负责交付过程但会长出人智协同平台作为连接人、任务、代码和智能体的 AI 化工作台。System of Ontology 负责把事实、资产、知识和经验做语义连接。System of Intelligence 则成为新的智能中枢负责让桌面智能体和云端智能体在规则、权限和上下文约束下执行任务。这也是为什么 AI 时代的软件工程工具体系不是一个 AI IDE也不是几个插件而是一整套新的生产基础设施。它要让人类员工、个人智能体、企业智能体、工程资产、业务数据、知识网络、测试环境和治理规则在同一个工作体系中协同运转。新工具的核心变化不是把 AI 接到旧系统上而是以 System of Intelligence 为智能中枢把 System of Delivery 升级为人智协同工作台让人、智能体、资产、数据和治理协同运转。—— 52 新范式 ——新治理先建安全网再放大自主度最后要谈的是治理。AI 能力越强治理越不能停留在过去那套“层层审批、人工兜底”的方式上。因为 AI 带来的问题有两个特点。一方面它可以显著提高交付速度让一个人、一个小队在短时间内完成更多设计、代码、测试和文档工作。另一方面它也天然存在不确定性。它可能误解上下文可能生成看似合理但实际有缺陷的方案可能局部优化但破坏系统边界也可能在没有足够反馈时持续沿着错误方向推进。所以AI 时代的新治理不应该是简单把 AI 的每一步都拉回人工审批。那样会把速度优势抵消掉。更合理的思路是先建立可验证的安全网再逐步放大 Agent 的自主度。治理的顺序大体可以分成五步。图 9AI 时代软件工程新治理第一步是多层自动化测试。这是 AI 时代治理的起点。AI 改代码以后最重要的反馈不是“看起来对不对”而是系统能不能自动验证它有没有破坏功能、接口、数据、权限和性能。单元测试、接口测试、契约测试、端到端测试、回归测试、性能基线、安全扫描、Agent Eval、CLI 造数脚本都应该成为 AI 改代码之后的反馈机制。这套安全网越强AI 能承担的自主执行范围就越大。反过来如果没有测试和环境支撑就算 AI 写代码很快组织也不敢放心合并、重构和发布。所以新治理的第一件事不是先讨论“要不要让 AI 自主”而是先回答“AI 做完以后我们能不能快速验证”。第二步是AI 参与评审。有了基本安全网以后就可以让 AI 更早参与需求、设计、架构、代码、测试缺口和文档一致性的评审。AI 评审的价值不是替代责任人也不是制造新的排队审批。它更适合做“前置发现”和“并行辅助”。在需求阶段它可以帮助识别歧义、边界条件和缺失验收标准。在设计阶段它可以提示影响范围、接口风险、数据风险和跨系统依赖。在编码阶段它可以提前发现缺陷、安全隐患、性能问题、测试缺口和文档不同步。这样很多问题不必等到正式评审会或发布前才暴露而是在交付过程中被持续发现、持续修正。第三步是规则守护与熵减。AI 时代的治理不能只靠人看文档也不能只靠一次性评审。一部分架构原则和工程规则应该变成可以持续执行的脚本、检查和流水线门禁。比如分层依赖不能倒置核心领域不能直接访问外部实现接口契约必须兼容关键模块必须有测试敏感数据不能越权访问公共能力不能在多个产品线重复实现。这些规则可以通过架构评审 as Code、静态检查、依赖扫描、代码库规则和流水线质量门禁持续守护。AI 也可以反过来帮助组织治理技术债。它可以扫描重复代码、过期依赖、低覆盖模块、复杂度异常、接口不一致、文档缺失、测试缺口和架构偏离。更重要的是它可以把技术债治理拆成一批低风险、可验证、可回滚的小任务在自动化测试保护下持续推进。这样技术债治理就不再只是每年一次的大工程而可以变成日常交付中的持续熵减机制。第四步是风险分级和 Human in the Loop。不是所有变更都需要同样强度的治理。低风险改动可以让 Agent 在自动化测试和质量门禁下自主完成。中风险改动需要人工确认方案或重点结果。高风险改动例如涉及资金、权限、隐私、安全、核心交易、关键架构边界和大范围数据迁移就必须由人类在关键节点把关。这里的 Human in the Loop不是每一步都人工批准而是在真正重要的决策点上保留人类责任。风险分级决定 Agent 的自主度也决定人工评审的强度。这既是风险控制也是责任归属。第五步是效能度量和 AI FinOps。企业不能只看“用了多少 AI”还要看“AI 带来了什么收益”。Token 成本、模型调用成本、Agent 执行成本、成功率、返工率、缺陷率、测试覆盖、交付周期、需求吞吐、上线后价值都需要被度量。尤其要注意AI 会放大人员能力差异。同样的工具有的人只是用来补全文案有的人可以用来澄清需求、生成原型、构造测试、重构代码和沉淀 Skill。因此组织要度量的不只是工具使用量还包括 AI 对个人产能、小队产能、交付质量和业务价值的真实影响。这会反过来推动培训、最佳实践沉淀、Skill 复用和团队能力建设。所以新治理的目标不是让 AI 慢下来而是让 AI 在可控边界内跑得更快。治理顺序应该是先建安全网再让 AI 参与评审再把规则脚本化和债务持续熵减然后用风险分级决定自主度和人工把关强度最后用效能度量和 AI FinOps 判断投入产出。AI 时代的治理不是在人和智能体之间重新堆审批而是先建安全网再放大自主度最终让速度、质量、责任和价值同时可控。—— how ——导入建议不要先改组织先让一个产品跑起来最后回到落地。如果把前面的角色、组织、工艺、流程、资产、工具和治理都放在一起看很容易得出一个过大的结论组织要全面转型。这个判断没有错但真正落地时不能一上来就大规模改组织、改岗位、改考核。那样风险很高也很容易把问题变成组织运动。更好的切入方式是选择一个合适的产品从工程底座开始把 AI 可协同的交付能力先跑出来。也就是说先让一个产品具备“人和智能体可以一起稳定工作”的能力再逐步复制到更多产品和领域。可以把导入路径分成六个阶段。图 10AI 时代软件工程落地路径阶段 0是选产品与建基线。这个阶段通常发生在正式启动前 2 到 4 周。关键不是马上上工具而是选对试点产品。试点产品最好有真实业务需求有一定代码和测试基础团队愿意尝试也有足够清晰的业务负责人和技术负责人。同时要建立一组基线指标。例如需求交付周期、缺陷率、返工率、测试覆盖、发布频率、环境准备时间、需求澄清次数、代码评审周期、上线后业务指标。还要定义风险边界。哪些代码可以让 Agent 辅助修改哪些必须人工确认哪些数据和权限不能触碰哪些发布必须走人工审核。没有这一步后面很容易变成“感觉 AI 很有用”但组织无法判断到底哪里变好了。阶段 1是工程底座试点。这个阶段大约可以放在 M1 到 M2。核心任务是先补齐 AI 协同所需要的工程底座。包括 CLI 化能力、环境自动化、测试环境快速准备、自动化测试补强、数据构造脚本、基础质量门禁以及需求、设计、代码、测试案例等资产的 Git 化管理。这一步看起来不够“AI”但它是后续所有 AI 能力真正落地的前提。因为没有自动化环境和自动化测试Agent 即使能写代码也很难形成可靠闭环。没有资产版本化Agent 也无法稳定获取上下文、沉淀经验和复用能力。所以阶段 1 的目标不是炫技而是让产品具备 AI 可验证、可追溯、可复盘的工程基础。阶段 2是产品 AI 小队试点。这个阶段大约可以放在 M2 到 M4。在工程底座初步具备以后可以开始建立产品 AI 小队。这个小队不一定人数很多通常由产品经理、Application Builder、Agent / Skill Builder以及必要的测试和平台支持组成。早期重点是训练产品经理和 Builder 的协同方式。产品经理可以利用 AI 快速生成原型、梳理需求、补充验收标准甚至在安全边界内完成部分简单前端修改。Builder 则用契约驱动开发、智能体协作和自动化测试把需求快速变成可验证的软件变化。这个阶段要重点跑通三件事AI 快速原型、契约驱动交付、产品与全栈开发协同。一旦这三件事跑通个人提效才开始变成小队提效。阶段 3是数据与知识试点。这个阶段大约可以放在 M3 到 M6。前面的试点更多偏业务应用交付接下来要把数据和知识能力补进来。知识工程和数据分析不一定一开始就组建独立团队可以先采用平台团队前置 FDE 工程师的方式试点。一方面把需求、设计、代码、测试、接口、运行日志、历史缺陷和业务规则逐步纳入知识工程范围。另一方面把常用数据口径、分析脚本、造数脚本、指标定义和业务效果评估沉淀成可复用资产。这个阶段要开始推进本体网络雏形。目标不是一次性建成庞大的知识图谱而是围绕试点产品把业务概念、系统模块、数据实体、接口契约、测试案例和运营指标先连接起来。这样 Agent 在处理需求和代码时才能获得更准确的上下文。阶段 4是应用、数据、知识融合的 FDE 小队试点。这个阶段大约可以放在 M6 到 M9。到了这个阶段就不能只把 AI 当成开发辅助工具了。需要在业务领域里建立融合型 FDE 小队让应用、数据和知识能力一起前置到业务。FDE 小队可以围绕业务问题快速完成需求澄清、原型验证、应用改造、数据分析和知识沉淀。同时人智协同平台要开始发挥作用。人类员工、桌面智能体、云端智能体、产品团队和平台团队需要在同一个任务、权限、审计和资产体系里协同。企业智能体也可以逐步接入承担一部分可重复、可验证、风险可控的任务。这个阶段的目标是从“产品 AI 小队试点”走向“领域 FDE 小队试点”。也就是让 AI 能力不只服务某个产品而是服务一个业务领域的持续交付。阶段 5是组织架构转型。这个阶段通常放在 M9 到 M18。只有当前面的试点已经证明有效才适合推动更大范围的组织变化。这时可以开始建设 FDE 领域团队把多个 3 到 5 人的 FDE 小队组织起来前置到不同业务场景。产品团队也可以按照产品线形成多个产品小队负责产品化沉淀、重构优化、测试强化和版本发布。平台团队则围绕 AI 平台、数据平台、知识平台、应用平台和研发平台提供底座能力。能力中心、平台团队和产品团队不再只是后线支持而是承担标准、工具链、质量门禁、资产沉淀、治理规则和组织级复用能力。同时要把治理和 ROI 制度化。也就是说AI 使用成本、Token ROI、交付效率、质量变化、业务价值、人员能力差异和小队成熟度都需要进入持续度量。否则组织很容易只看到局部提效却看不到整体效能有没有真正改善。所以AI 时代软件工程转型的关键不是先把组织图画漂亮而是先让一个产品具备 AI 可协同的工程底座。每一个阶段都要沉淀 52 新范式的一部分。新角色要在试点中长出来新组织要在小队协同中演化出来新工艺和新流程要在真实交付中跑顺新资产要随着使用不断沉淀新工具要围绕真实任务建设新治理要基于真实风险和真实数据形成闭环。只有这样AI 才不会停留在个人工具层面而会逐步变成组织能力。落地的关键判断是不要先大规模改组织先让一个产品具备 AI 可协同的工程底座再用试点成果逐步复制到更多产品和领域。写在最后AI时代软件工程的变革不是要不要用AI的问题——这个答案已经很明显。真正的问题是个人提效之后组织如何承接52新范式的提出不是为了给出一套完美的蓝图而是为了回答一个更务实的问题当每个人都变快了组织能不能建立一套新的生产关系让这些效率真正转化为系统性的竞争力如果你也在思考AI强了组织怎么还没变快这个问题希望这篇文章能给你一些启发。【END】
本文作者吴穹博士近 30 年行业沉淀北京大学软件工程博士行业知名的精益与敏捷创新管理专家软件工程专家。过去一年我们在很多研发组织里都能观察到一个相似现象AI的使用已经从个人尝鲜逐步进入日常研发工作。产品经理开始用AI生成原型工程师用AI阅读代码、生成代码、补充测试测试人员用AI整理用例和分析缺陷架构师也开始借助AI做方案评审和影响分析。从个人视角看这种变化是实实在在的。过去需要花很久才能理解的代码现在AI可以先帮忙梳理主线过去需要反复复制修改的样板代码现在可以生成初稿过去容易遗漏的测试点也可以先让AI做一轮补充。但回到组织层面很多管理者的感受并没有那么强。需求仍然在排队版本仍然按原来的节奏推进跨团队沟通仍然很多测试环境仍然紧张联调和评审仍然需要反复协调。每个人似乎都变快了一些但组织整体并没有同步变快。这形成了AI时代软件工程里的一个典型悖论个人提效已经发生但组织提效没有自然发生。原因并不复杂。软件交付从来不是一个人的工作而是一条协作链路。需求要澄清方案要评审代码要合入测试要验证环境要准备数据要构造发布要协同问题要追踪。如果这些环节仍然按旧方式运转只是每个人多了一个AI工具组织效率就很难出现根本变化。所以AI给软件工程带来的第一个问题不是个人能不能变快。这个问题的答案已经很清楚。真正的问题是个人变快之后组织有没有新的协作方式来承接这种变化—— why ——成本结构变了组织也必须变AI 改变的不只是开发工具而是软件开发的成本结构。过去很多研发组织最大的瓶颈是开发产能。需求来了要排期方案定了要等人写代码功能复杂一点就要投入更多开发资源。现在这个结构开始变化。代码理解、代码生成、测试补充、缺陷分析和文档整理的成本正在下降。代码仍然重要但“写出代码”本身正在从最稀缺的能力变成可以被 AI 大幅放大的能力。新的瓶颈开始转移到其他地方。需求是否足够清楚架构边界是否合理测试能否自动化验证环境和数据能否快速准备代码能否安全合入知识能否沉淀复用发布以后能否快速验证价值这些问题会变得越来越关键。与此同时AI 又带来了大量新的应用需求。企业开始需要智能客服、智能运营、智能分析、个人智能体、企业智能体、知识库问答、流程自动化和人智协同平台。软件系统不只是给人使用也要给智能体调用不只是提供页面也要提供接口、上下文、权限、工具和可审计的执行环境。这意味着研发组织不能只是“给每个人配一个 AI 工具”。图 1大模型与 Agent 能力演进趋势任务变了成本结构变了协作对象也变了。产品、开发、测试、架构、数据、知识、平台和安全都需要重新分工重新协作重新组织。我们认为AI 时代的软件工程变革不能停留在个人效率提升上而必须进入一套新的组织模式。这就是本文要讨论的 52 新范式。—— what ——52 新范式用新的生产关系承接新的生产力为什么需要一套新的范式因为 AI 同时改变了两件事。第一软件开发的成本结构变了。过去很多依赖人力堆出来的工作现在可以由人和 AI 一起完成。第二软件系统面对的需求变了。未来的软件系统不只是给人使用也要给智能体调用。成本变了需求变了研发工作的内容也会随之变化。过去软件研发主要围绕“把功能做出来”展开。现在团队还要回答一组新的问题需求能不能被 AI 快速理解代码库能不能被 AI 安全修改测试能不能被 AI 自动执行环境和数据能不能被 AI 快速准备知识能不能被 AI 持续复用架构原则能不能被自动守护高风险决策什么时候必须由人审核AI 带来的成本和收益能不能被度量这些问题已经超出了单个工具的范围。它会催生新的角色要求新的流程和工艺也会沉淀出新的工程资产需要新的工具平台来承载并进一步要求新的治理模式。因此AI 时代的软件工程不能只看“工具升级”而要看一整套生产关系的重构。我们把这套新范式概括为 52。图 2AI 时代软件工程 52 新范式前面的“5”是软件工程主体部分的变化后面的“2”是支撑系统52 新范式1/5 新角色从Developer到Builder。研发组织需要 Product Builder、Application Builder、Agent Builder、Test Builder、Platform Builder以及架构、前端、后端、测试、UX、安全、性能等专家角色。2/5 新组织组织形态会从传统职能分工走向 FDE 团队、产品团队和平台团队三层协同。3/5 新工艺软件交付会从线性流程走向创意、需求、交付、运营四个持续闭环。4/5 新流程FDE 负责快速探索产品团队负责产品化沉淀平台团队负责底座化沉淀代码和能力在三层之间流动。5/5 新资产需求文档、设计文档、代码、测试案例、数据脚本、契约、Skill、Agent 记忆、本体网络都会变成可复用、可演进的工程资产。1/2 新工具工具体系会从“人使用系统”升级为人类、个人智能体、企业智能体共同协作的人智协同平台。2/2 新治理AI 协同评审、架构评审 as Code、AI 代码评审、AI 技术债治理、多层自动化测试、Human in the Loop、FinOps 和 Token ROI会成为新的治理能力。52 不是七个概念的罗列。它真正要解决的是一个问题如何把个人使用 AI 的效率转化为小队、产品线和组织的系统效率。—— 52 新范式 ——新角色从 Developer 到 Builder52 新范式的第一件事是角色变化。AI 时代的软件研发组织不再只是围绕 Developer 分工而会逐步围绕 Builder 分工。这里的 Builder不是简单换一个岗位名称。它强调的是人不再只负责某个狭窄环节而是要和 AI、Agent、平台、资产一起把业务问题构建成可运行、可验证、可持续演进的系统。未来研发组织里至少会出现五类 Builder。图 3AI时代软件工程新角色地图第一类是Product Builder。它来自传统产品经理但不再只是写需求、排优先级、组织评审。在 AI 辅助下产品角色可以更快生成界面原型更快和业务讨论需求也可以基于数据反馈判断功能效果。部分具备编码能力的产品角色甚至可以在 Agent 或前端 FDE 的帮助下直接修改简单页面快速验证想法。Product Builder 的核心变化是从“需求管理者”变成“产品构建者”。第二类是Application Builder。它来自传统开发工程师也是 Developer 演进的主方向。随着代码理解、代码生成和测试补充成本下降开发人员会越来越全栈化。这个全栈不只是前端和后端一体化还会进一步走向应用、数据、算法一体化。Application Builder 需要更靠近业务参与需求澄清、原型验证、方案设计和价值反馈。同时他也要带着 Agent 守护代码质量负责自动化测试、影响分析、回归验证、文档更新和基础质量闭环。Application Builder 的核心变化是从“写代码的人”变成“应用系统构建者”。第三类是Agent Builder。它不是简单写 Prompt 的人而是建设智能体能力的人。Agent Builder 负责设计 Agent 工作流沉淀 Skill连接工具组织上下文构建评测体系管理记忆、权限和版本让智能体可以稳定参与软件交付。在这个体系里Agent 是任务执行主体Skill 是可复用能力资产。成熟组织不会长期依赖临时 Prompt而会把高频任务沉淀成 Skill再通过版本化、评测和治理持续演进。Agent Builder 和知识工程师会有很强的重叠。因为好的 Agent 离不开高质量知识资产、本体网络、业务规则和上下文组织。Agent Builder 的核心变化是从“使用 AI”变成“构建 AI 能力”。第四类是Test Builder。测试角色不会消失但工作重心会改变。当开发人员可以在 Agent 辅助下完成更多自测、自动化测试和功能验收传统手工执行型测试的占比会下降。测试人员会更多转向测试基础设施、专项测试、测试覆盖强化、质量门禁、测试数据构建和自动化策略设计。Test Builder 不只是发现问题的人而是构建质量体系的人。Test Builder 的核心变化是从“测试执行者”变成“质量基础设施构建者”。第五类是Platform Builder。它来自平台团队、架构团队和各类支撑团队。AI 时代的一线小队要高效运转背后必须有强大的平台能力支撑包括 AI 平台、数据平台、知识平台、工程平台、CI/CD、环境管理、权限管理、观测体系、FinOps、架构守护、公共工具链和公共 Skill。Platform Builder 不只是响应项目需求而是沉淀组织级能力让更多 FDE 小队可以低成本复用。Platform Builder 的核心变化是从“平台支撑者”变成“组织能力构建者”。这样看未来的一线小队并不是简单由传统产品、开发、测试组成而会形成新的组合。Product Builder 负责产品判断和快速原型Application Builder 负责应用交付和质量闭环Agent Builder 负责智能体能力和 Skill 沉淀。Test Builder 和 Platform Builder 更多在产品团队、平台团队中提供支撑也可以根据阶段需要前置到一线小队。当然Builder 化并不意味着专家角色消失。恰恰相反当一线角色变宽之后组织更需要少量高水平 Expert 来管理复杂性。Architecture Expert、Performance Expert、Security Expert、UX Expert、Frontend Expert、Backend Expert、Testing Expert、Data Expert 等角色仍然非常重要。只是他们的工作方式会发生变化。过去很多 Expert 更像流程后面的审批关口。需求设计好了代码写完了问题暴露了再请架构、安全、性能、体验专家来评审和兜底。未来Expert 更应该作为产品团队和平台团队中的专家角色承担能力中心职责负责定义标准、沉淀资产、建设工具链和质量门禁。也就是说Expert 不一定需要单独设成专职专家部门。更好的方式是让专家能力长在产品团队和平台团队里把专业能力产品化、工具化、资产化让更多 Builder 小队可以复用。所以未来的角色体系不是“Builder 替代 Expert”而是两类角色重新协作Builder 负责交付闭环Expert 负责能力沉淀和复杂性治理。这就是角色变化的本质不是让每个人都变成超级个体而是让组织围绕 Builder、Agent、资产和平台重新分工。—— 52 新范式 ——新组织FDE 团队、产品团队和平台团队三层协同角色变化之后组织形态也必须变化。如果还是按照传统职能墙来组织Product Builder、Application Builder、Agent Builder、Test Builder 和 Platform Builder 的能力很难真正发挥出来。个人可以变快但协作链路仍然很长组织仍然会慢。未来的软件研发组织可以逐步演进为三层结构。图 4AI 时代软件工程新组织第一层是前置到业务的FDE 团队。FDE 团队由多个业务 FDE 小队组成每个小队规模可以控制在 3-5 人。这些小队不是传统意义上的项目组而是前置到具体业务场景围绕需求澄清、快速原型、契约驱动开发、交付验收和价值反馈形成闭环。一个 FDE 小队里通常会包含 Product Builder、Application Builder 和 Agent Builder。根据阶段需要也可以临时引入 Test Builder 或 Platform Builder 支持。多个业务 FDE 小队可以进一步组成 FDE 领域团队。领域团队面向一个业务域沉淀经验、资产、Skill 和最佳实践让单个小队的能力可以在领域内复用。FDE 团队的核心价值是让业务变化可以更快变成可运行、可验证的软件变化。第二层是面向业务应用的产品团队。业务应用仍然需要按照产品来组织。一个复杂产品可以拆成多个产品小队每个小队同样控制在 3-5 人。多个产品小队组成产品线团队负责一个产品或产品族的长期演进。产品团队不是只负责需求管理也不是只做版本排期。它要负责产品架构、复杂共性需求、代码复审、重构优化、技术债治理、测试强化和版本发布。FDE 小队可以快速闭环修改产品但这些修改不能长期停留在局部最优。产品团队需要对这些变化进行复审、吸收、重构和熵减把一线创新沉淀为产品能力。因此产品团队承担的是“产品长期健康”的责任。Architecture Expert、UX Expert、Frontend Expert、Backend Expert、Testing Expert、Performance Expert、Security Expert 等专家角色可以作为产品团队成员存在。他们不一定是专职审批者而是在产品演进过程中持续建设标准、工具、Skill 和质量门禁。第三层是提供底座能力的平台团队。最底层是平台团队包括 AI 平台、数据平台、知识平台、应用平台、工程平台等。平台团队的职责是为 FDE 团队和产品团队提供可复用的组织级能力。AI 平台提供模型接入、Agent 运行、评测、权限、观测和 Token 成本治理。数据平台提供数据资产、指标口径、分析能力和数据脚本。知识平台提供本体网络、知识检索、记忆管理和知识资产治理。应用平台和工程平台提供环境、CI/CD、CLI、自动化测试、发布治理和运行支撑。平台团队也应该由多个小队组成而不是一个大而全的中心部门。每个平台小队围绕一类平台能力持续演进并把能力以工具、接口、Skill、规则和服务的方式提供出去。平台团队的核心价值是让组织不必在每个产品、每个小队里重复建设底层能力。这样未来组织就形成了三层协同FDE 团队贴近业务负责快速闭环产品团队面向产品负责复审、重构和熵减平台团队沉淀底座负责组织级能力复用。这三层不是上下级审批关系而是基于资产和智能体协同的能力流动关系。FDE 小队把业务想法更快变成产品变化产品团队把这些变化沉淀成稳定产品能力平台团队再把共性能力沉淀成更底层的平台能力。反过来平台能力会推回给产品团队产品能力会推回给 FDE 小队让一线团队的交付成本越来越低。这就是新组织的核心组织不再只靠职能分工运转而是通过 FDE 团队、产品团队和平台团队三层协同把一线变化持续沉淀为产品能力和平台能力。—— 52 新范式 ——新工艺四大闭环和两个底座有了新的角色和组织还需要新的工艺。过去的软件交付通常被理解为一条流程需求分析、方案设计、编码开发、测试验收、发布上线。这条流程在 AI 时代仍然有价值但已经不够了。因为 AI 让很多工作可以更早发生、更快验证、更频繁反馈。产品可以快速做原型Agent 可以提前阅读代码提出问题Builder 可以带着 Agent 完成实现和测试FDE 可以根据运营数据直接推动系统优化。因此新工艺不应该只是把原来的线性流程切得更细而应该把关键工作变成持续闭环。我们认为可以概括为四大闭环和两个底座。图 5AI 时代软件工程新工艺第一是创意闭环业务 - 产品/Agent - 原型 - 业务。这一环解决的是“做什么、值不值得做”。业务提出问题或机会Product Builder 借助 Agent 快速生成原型、场景说明和价值假设再回到业务侧讨论、试用和调整。它的输出物不是完整 PRD而是业务场景、价值假设、原型和 BRD。这个闭环的核心是低成本把想法变成可讨论、可试用、可调整的东西。第二是需求闭环产品 - 编码 Agent - 问题 - 产品。这一环解决的是“需求能不能落进现有系统”。产品不再只是闭门写 PRD而是让编码 Agent 读取代码、接口、数据结构、历史需求、现有配置和系统约束由 Agent 反向提出问题。这些问题再回到产品侧促使产品不断澄清边界、异常、权限、状态流、兼容性和验收标准。它的输出物是高质量 PRD、澄清问题清单、验收标准和需求契约。这个闭环的核心是让需求在进入开发前就和真实系统发生碰撞。第三是交付闭环Builder - 需求 - Spec - Coding - 测试验收 - Builder。这一环解决的是“如何交付高质量代码”。Builder 接收高质量需求后和 Agent 一起把需求转成 Spec再细化设计、编码实现并在真实或准真实环境下完成各种测试验收。这里的质量不再单独作为最后一道关而是内嵌在交付闭环里。自动化测试、CLI 环境准备、测试数据构建、AI 代码评审、架构规则检查、功能验收、回归测试都应该成为交付过程的一部分。它的输出物是 Spec、详细设计、代码、测试案例、验收结果和高质量可发布版本。这个闭环的核心是交付不是写完代码而是完成可验证的系统变化。第四是运营闭环FDE - 运营数据 - 调整系统 - FDE。这一环解决的是“上线后有没有创造价值”。FDE 不只是交付需求也要持续观察系统运行后的真实反馈包括用户行为、业务指标、运营数据、日志、问题反馈和实验结果。这些反馈会直接推动下一轮系统调整形成持续优化。它的输出物是运营数据、价值评估、优化清单、调整后的系统和下一轮需求。这个闭环的核心是交付代码不是终点交付价值才是终点。在四个闭环之下还需要两个底座。第一个底座是知识联通底座。所有关键知识都要尽量在代码库或强关联资产中沉淀。需求、设计、代码、测试案例、数据脚本、接口契约、业务规则、运营数据、决策记录都不应该孤立存在。它们需要通过本体网络、语义检索、向量检索和代码引用关系连接起来让人和 Agent 都能低成本获取上下文。知识联通底座解决的是让知识可被人和 Agent 共同理解。第二个底座是经验进化底座。每次交付、失败、评审、测试、运营反馈都应该沉淀成可复用经验。Prompt、Skill、Agent 记忆、失败案例、测试集、质量规则、架构规则、专家经验和最佳实践都需要被版本化、评测和持续改进。这些经验反过来升级 Agent、Skill、规则和流程让组织越用越强。经验进化底座解决的是让组织经验不只留在人脑里而能持续进化成能力。所以新工艺可以概括成一句话四个闭环负责让业务想法持续变成价值两个底座负责让知识和经验持续进化。—— 52 新范式 ——新流程让代码和能力在三层之间流动如果说新工艺解决的是一次需求内部如何闭环那么新流程解决的是组织内部如何流动。AI 时代的流程不能再简单理解为“需求从产品流向开发再流向测试和发布”。新的流程要允许前线更快探索也要允许后线持续熵减。图 6AI 时代软件工程新流程在第一层FDE 团队前置到业务围绕创意闭环、需求闭环、交付闭环和运营闭环快速推进。为了满足客户要求FDE 可以直接修改产品代码在必要场景下也可以修改平台代码。产品智能体和平台智能体会参与设计和架构评审帮助识别影响范围、风险点和更优方案但它们不应该成为低风险探索的阻塞点。也就是说智能体参与评审是为了更早发现问题、提示风险、把握方向而不是把流程重新变成排队审批。在第二层产品团队接收 FDE 的代码贡献和场景经验。产品团队要对这些变化进行复审、重构、熵减、测试强化和产品化发布。前线代码不一定一开始就是最优产品实现但只要它验证了业务价值就应该被产品团队吸收和沉淀。产品团队也可以在必要时修改平台代码推动平台能力补齐。在第三层平台团队接收来自产品团队或 FDE 的平台改动和共性需求。平台团队负责复审、重构、优化平台、强化测试和平台化发布把共性能力沉淀成稳定底座再推回产品团队和 FDE 使用。这个流程能跑起来有一个前提自动化测试必须足够强。因为只有测试、环境、数据和质量门禁可以自动化验证产品团队和平台团队才敢对前线代码进行重构FDE 也才敢更快探索。所以新流程的本质不是多一层审批而是形成一种内部开源式的流动机制。FDE 负责快速探索产品团队负责产品化沉淀平台团队负责底座化沉淀。智能体参与评审但不替代责任自动化测试保障重构和复用。代码和能力在三层之间流动经过复审、重构、测试和发布最终反哺前线。这也意味着流程的关键不再是“谁先批准”而是“谁能快速贡献谁来持续熵减谁负责稳定复用”。—— 52 新范式 ——新资产从文件沉淀到语义连接进入 AI 时代以后软件工程资产的边界会明显扩大。在 DevOps 时代我们强调 Everything as Code希望环境、配置、流水线、基础设施都可以被版本化、自动化和可追溯。到了 AI 时代仅仅“代码化”还不够。因为大模型和 Agent 真正需要的不只是代码本身而是完整上下文。需求文档、设计文档、代码仓库、测试案例、数据脚本、接口契约、运行日志、评测集、架构决策和历史缺陷都会成为 Agent 理解系统、生成方案、执行任务和验证结果时需要调用的上下文。同时还会出现一类过去并不被充分重视的新资产Agent 执行过程数据。例如Agent 如何拆解任务调用了哪些工具参考了哪些文档在哪些步骤失败测试报错如何修复人类在哪些地方进行了纠偏某个 Skill 在什么场景下表现稳定、在什么场景下容易失效。这些过程数据不能只是临时日志。它们应该被保存、结构化、评测和复盘成为优化 Prompt、沉淀 Skill、增强 Agent 记忆、扩充评测集的重要来源。这意味着AI 时代的工程资产不再只是“最终产物”还包括“产生最终产物的过程”。但资产多起来以后如果只是把文档、代码、日志和案例堆进仓库价值仍然有限。新的关键是用本体网络把这些资产连接起来。业务概念、系统边界、模块职责、数据实体、接口契约、业务规则、测试案例、运行指标、缺陷记录和架构决策都需要形成语义关联。这样大模型检索信息时才不是只靠关键词或向量相似度去“猜”而是可以沿着业务语义、系统关系和工程依赖找到更准确的上下文。新资产大体可以分成三层。图 7AI 时代软件工程新资产第一层是底层工程资产包括需求、设计、代码、测试案例、数据脚本、契约/API、运行日志、评测集和 Agent 执行轨迹。第二层是语义连接层用本体网络和知识图谱把概念、系统、数据、规则、接口、测试和经验连接起来。第三层是能力资产包括 Agent 记忆、Skill、Prompt、工具调用模板、评测集和专家规则。随着使用不断发生底层资产会持续增加本体网络会持续完善Agent 记忆和 Skill 也会持续进化。所以新资产不是把更多文件放进仓库而是把软件交付过程中的知识、经验和执行轨迹变成人和智能体都能理解、检索、调用和进化的组织资产。—— 52 新范式 ——新工具以智能系统为中枢的生产平台谈 AI 时代的新工具不能只从“多了哪些 AI 工具”开始看。更好的切入点是回到企业软件体系本身。过去很多企业 IT 架构可以用几类系统来理解。图 8AI 时代软件工程新工具第一类是System of Record记录系统。它负责记录确定性业务事实比如客户、订单、合同、账户、库存、交易、状态和审计记录。AI 时代到来以后System of Record 不会被替代。恰恰相反它的重要性会更高。因为智能体越能行动越需要有一个可靠的事实底座告诉它什么是真的、什么已经发生、什么可以被追溯。第二类是System of Engagement互动系统。它承载人与业务、人与组织、人与客户之间的互动比如门户、移动应用、协同系统、消息系统、审批系统和客户触点。在移动互联网和数字化时代很多企业的建设重点是把更多用户、员工和伙伴连接到互动系统上。第三类是System of Insight洞察系统。它把记录系统和互动系统产生的数据汇聚起来通过报表、分析、模型、指标和实验帮助组织理解发生了什么、为什么发生、下一步可能怎么做。对于软件研发组织还存在一类过去不一定被单独命名、但一直非常重要的系统可以称为System of Delivery交付系统。它包括需求管理、项目协同、代码仓库、分支管理、CI/CD、自动化测试、制品库、环境管理、发布管理、缺陷管理、监控告警和事故复盘。这类系统记录的不是业务交易而是“组织如何把想法变成软件”的过程。AI 来了以后真正发生变化的正是这套交付系统。原来的交付系统主要服务人类工程师记录任务、流转流程、管理代码和发布。新的交付系统要同时服务人类和智能体。它不仅要管理工作项还要管理 Agent 身份、权限、任务队列、执行日志、工具调用、上下文引用、Skill 版本、评测结果、Token 成本、质量门禁和人工审核。也就是说原来的 System of Delivery不只是多接入几个 AI 工具而是要长出一层面向人和智能体共同工作的协同入口。这层入口可以称为人智协同平台或者 Delivery Workbench。但需要注意它不是独立于交付系统之外的总平台而是 System of Delivery 的 AI 化扩展。它负责把需求、任务、代码、测试、环境、发布和复盘这些交付活动组织起来同时把桌面智能体、云端智能体和人类工程师连接起来。从归属上看它仍然属于 System of Delivery从作用上看它连接 System of Delivery 和后面要讲的 System of Intelligence。在这个基础上还需要补两层 AI 时代的新系统。第一层是System of Ontology本体系统。它不是一个普通知识库而是负责把业务概念、系统边界、数据实体、接口契约、业务规则、测试案例、运行指标、架构决策和历史缺陷连接起来。它既连接 System of Record 里的确定性事实也连接 System of Delivery 里的工程资产还连接 System of Insight 里的指标和分析结论。如果没有这层本体系统智能体只能在文档、代码和数据之间做相似度检索很容易找错上下文、误解概念、遗漏约束。有了本体系统智能体才更容易知道这个需求影响哪个系统涉及哪些数据实体调用哪些接口触发哪些规则需要补哪些测试可能破坏哪些架构边界。第二层是System of Intelligence智能系统。这里需要和 System of Insight 区分开。System of Insight 主要回答“看见什么、理解什么、预测什么”。System of Intelligence 则进一步回答“应该怎么做、由谁来做、调用什么工具、如何验证结果、什么时候交给人类审核”。在 AI 时代System of Intelligence 应该成为新的智能中枢。它包括大模型、Agent 运行平台、多智能体协作、工具调用、记忆、规划、评测、权限、风险分级和 Human in the Loop。其中智能体可以进一步分成两类。第一类是桌面智能体。它更像人类员工的个人助手跟随个人上下文工作帮助生成、总结、检索、提醒、局部执行和辅助判断。它的关键价值是增强个人的工作半径让产品经理、Builder、测试人员、架构师都能更快完成原本需要大量手工操作和上下文切换的工作。第二类是云端智能体。它更像企业里的数字员工运行在云端拥有独立身份、角色权限、任务队列、操作日志和责任归属。它可以接收任务、调用工具、执行流程、提交结果也需要受到权限、审计、成本、质量门禁和人工审核机制的约束。桌面智能体增强个人云端智能体增强组织。二者都属于 System of Intelligence但工作方式和治理要求并不一样。如果说 System of Engagement 是人进入系统的互动入口那么 System of Intelligence 就是智能体理解意图、组织上下文、调用工具并推进任务的执行中枢。所以AI 时代的新工具体系可以理解为一次企业软件架构的扩展。System of Record 仍然负责事实。System of Engagement 仍然负责互动。System of Insight 仍然负责洞察。System of Delivery 仍然负责交付过程但会长出人智协同平台作为连接人、任务、代码和智能体的 AI 化工作台。System of Ontology 负责把事实、资产、知识和经验做语义连接。System of Intelligence 则成为新的智能中枢负责让桌面智能体和云端智能体在规则、权限和上下文约束下执行任务。这也是为什么 AI 时代的软件工程工具体系不是一个 AI IDE也不是几个插件而是一整套新的生产基础设施。它要让人类员工、个人智能体、企业智能体、工程资产、业务数据、知识网络、测试环境和治理规则在同一个工作体系中协同运转。新工具的核心变化不是把 AI 接到旧系统上而是以 System of Intelligence 为智能中枢把 System of Delivery 升级为人智协同工作台让人、智能体、资产、数据和治理协同运转。—— 52 新范式 ——新治理先建安全网再放大自主度最后要谈的是治理。AI 能力越强治理越不能停留在过去那套“层层审批、人工兜底”的方式上。因为 AI 带来的问题有两个特点。一方面它可以显著提高交付速度让一个人、一个小队在短时间内完成更多设计、代码、测试和文档工作。另一方面它也天然存在不确定性。它可能误解上下文可能生成看似合理但实际有缺陷的方案可能局部优化但破坏系统边界也可能在没有足够反馈时持续沿着错误方向推进。所以AI 时代的新治理不应该是简单把 AI 的每一步都拉回人工审批。那样会把速度优势抵消掉。更合理的思路是先建立可验证的安全网再逐步放大 Agent 的自主度。治理的顺序大体可以分成五步。图 9AI 时代软件工程新治理第一步是多层自动化测试。这是 AI 时代治理的起点。AI 改代码以后最重要的反馈不是“看起来对不对”而是系统能不能自动验证它有没有破坏功能、接口、数据、权限和性能。单元测试、接口测试、契约测试、端到端测试、回归测试、性能基线、安全扫描、Agent Eval、CLI 造数脚本都应该成为 AI 改代码之后的反馈机制。这套安全网越强AI 能承担的自主执行范围就越大。反过来如果没有测试和环境支撑就算 AI 写代码很快组织也不敢放心合并、重构和发布。所以新治理的第一件事不是先讨论“要不要让 AI 自主”而是先回答“AI 做完以后我们能不能快速验证”。第二步是AI 参与评审。有了基本安全网以后就可以让 AI 更早参与需求、设计、架构、代码、测试缺口和文档一致性的评审。AI 评审的价值不是替代责任人也不是制造新的排队审批。它更适合做“前置发现”和“并行辅助”。在需求阶段它可以帮助识别歧义、边界条件和缺失验收标准。在设计阶段它可以提示影响范围、接口风险、数据风险和跨系统依赖。在编码阶段它可以提前发现缺陷、安全隐患、性能问题、测试缺口和文档不同步。这样很多问题不必等到正式评审会或发布前才暴露而是在交付过程中被持续发现、持续修正。第三步是规则守护与熵减。AI 时代的治理不能只靠人看文档也不能只靠一次性评审。一部分架构原则和工程规则应该变成可以持续执行的脚本、检查和流水线门禁。比如分层依赖不能倒置核心领域不能直接访问外部实现接口契约必须兼容关键模块必须有测试敏感数据不能越权访问公共能力不能在多个产品线重复实现。这些规则可以通过架构评审 as Code、静态检查、依赖扫描、代码库规则和流水线质量门禁持续守护。AI 也可以反过来帮助组织治理技术债。它可以扫描重复代码、过期依赖、低覆盖模块、复杂度异常、接口不一致、文档缺失、测试缺口和架构偏离。更重要的是它可以把技术债治理拆成一批低风险、可验证、可回滚的小任务在自动化测试保护下持续推进。这样技术债治理就不再只是每年一次的大工程而可以变成日常交付中的持续熵减机制。第四步是风险分级和 Human in the Loop。不是所有变更都需要同样强度的治理。低风险改动可以让 Agent 在自动化测试和质量门禁下自主完成。中风险改动需要人工确认方案或重点结果。高风险改动例如涉及资金、权限、隐私、安全、核心交易、关键架构边界和大范围数据迁移就必须由人类在关键节点把关。这里的 Human in the Loop不是每一步都人工批准而是在真正重要的决策点上保留人类责任。风险分级决定 Agent 的自主度也决定人工评审的强度。这既是风险控制也是责任归属。第五步是效能度量和 AI FinOps。企业不能只看“用了多少 AI”还要看“AI 带来了什么收益”。Token 成本、模型调用成本、Agent 执行成本、成功率、返工率、缺陷率、测试覆盖、交付周期、需求吞吐、上线后价值都需要被度量。尤其要注意AI 会放大人员能力差异。同样的工具有的人只是用来补全文案有的人可以用来澄清需求、生成原型、构造测试、重构代码和沉淀 Skill。因此组织要度量的不只是工具使用量还包括 AI 对个人产能、小队产能、交付质量和业务价值的真实影响。这会反过来推动培训、最佳实践沉淀、Skill 复用和团队能力建设。所以新治理的目标不是让 AI 慢下来而是让 AI 在可控边界内跑得更快。治理顺序应该是先建安全网再让 AI 参与评审再把规则脚本化和债务持续熵减然后用风险分级决定自主度和人工把关强度最后用效能度量和 AI FinOps 判断投入产出。AI 时代的治理不是在人和智能体之间重新堆审批而是先建安全网再放大自主度最终让速度、质量、责任和价值同时可控。—— how ——导入建议不要先改组织先让一个产品跑起来最后回到落地。如果把前面的角色、组织、工艺、流程、资产、工具和治理都放在一起看很容易得出一个过大的结论组织要全面转型。这个判断没有错但真正落地时不能一上来就大规模改组织、改岗位、改考核。那样风险很高也很容易把问题变成组织运动。更好的切入方式是选择一个合适的产品从工程底座开始把 AI 可协同的交付能力先跑出来。也就是说先让一个产品具备“人和智能体可以一起稳定工作”的能力再逐步复制到更多产品和领域。可以把导入路径分成六个阶段。图 10AI 时代软件工程落地路径阶段 0是选产品与建基线。这个阶段通常发生在正式启动前 2 到 4 周。关键不是马上上工具而是选对试点产品。试点产品最好有真实业务需求有一定代码和测试基础团队愿意尝试也有足够清晰的业务负责人和技术负责人。同时要建立一组基线指标。例如需求交付周期、缺陷率、返工率、测试覆盖、发布频率、环境准备时间、需求澄清次数、代码评审周期、上线后业务指标。还要定义风险边界。哪些代码可以让 Agent 辅助修改哪些必须人工确认哪些数据和权限不能触碰哪些发布必须走人工审核。没有这一步后面很容易变成“感觉 AI 很有用”但组织无法判断到底哪里变好了。阶段 1是工程底座试点。这个阶段大约可以放在 M1 到 M2。核心任务是先补齐 AI 协同所需要的工程底座。包括 CLI 化能力、环境自动化、测试环境快速准备、自动化测试补强、数据构造脚本、基础质量门禁以及需求、设计、代码、测试案例等资产的 Git 化管理。这一步看起来不够“AI”但它是后续所有 AI 能力真正落地的前提。因为没有自动化环境和自动化测试Agent 即使能写代码也很难形成可靠闭环。没有资产版本化Agent 也无法稳定获取上下文、沉淀经验和复用能力。所以阶段 1 的目标不是炫技而是让产品具备 AI 可验证、可追溯、可复盘的工程基础。阶段 2是产品 AI 小队试点。这个阶段大约可以放在 M2 到 M4。在工程底座初步具备以后可以开始建立产品 AI 小队。这个小队不一定人数很多通常由产品经理、Application Builder、Agent / Skill Builder以及必要的测试和平台支持组成。早期重点是训练产品经理和 Builder 的协同方式。产品经理可以利用 AI 快速生成原型、梳理需求、补充验收标准甚至在安全边界内完成部分简单前端修改。Builder 则用契约驱动开发、智能体协作和自动化测试把需求快速变成可验证的软件变化。这个阶段要重点跑通三件事AI 快速原型、契约驱动交付、产品与全栈开发协同。一旦这三件事跑通个人提效才开始变成小队提效。阶段 3是数据与知识试点。这个阶段大约可以放在 M3 到 M6。前面的试点更多偏业务应用交付接下来要把数据和知识能力补进来。知识工程和数据分析不一定一开始就组建独立团队可以先采用平台团队前置 FDE 工程师的方式试点。一方面把需求、设计、代码、测试、接口、运行日志、历史缺陷和业务规则逐步纳入知识工程范围。另一方面把常用数据口径、分析脚本、造数脚本、指标定义和业务效果评估沉淀成可复用资产。这个阶段要开始推进本体网络雏形。目标不是一次性建成庞大的知识图谱而是围绕试点产品把业务概念、系统模块、数据实体、接口契约、测试案例和运营指标先连接起来。这样 Agent 在处理需求和代码时才能获得更准确的上下文。阶段 4是应用、数据、知识融合的 FDE 小队试点。这个阶段大约可以放在 M6 到 M9。到了这个阶段就不能只把 AI 当成开发辅助工具了。需要在业务领域里建立融合型 FDE 小队让应用、数据和知识能力一起前置到业务。FDE 小队可以围绕业务问题快速完成需求澄清、原型验证、应用改造、数据分析和知识沉淀。同时人智协同平台要开始发挥作用。人类员工、桌面智能体、云端智能体、产品团队和平台团队需要在同一个任务、权限、审计和资产体系里协同。企业智能体也可以逐步接入承担一部分可重复、可验证、风险可控的任务。这个阶段的目标是从“产品 AI 小队试点”走向“领域 FDE 小队试点”。也就是让 AI 能力不只服务某个产品而是服务一个业务领域的持续交付。阶段 5是组织架构转型。这个阶段通常放在 M9 到 M18。只有当前面的试点已经证明有效才适合推动更大范围的组织变化。这时可以开始建设 FDE 领域团队把多个 3 到 5 人的 FDE 小队组织起来前置到不同业务场景。产品团队也可以按照产品线形成多个产品小队负责产品化沉淀、重构优化、测试强化和版本发布。平台团队则围绕 AI 平台、数据平台、知识平台、应用平台和研发平台提供底座能力。能力中心、平台团队和产品团队不再只是后线支持而是承担标准、工具链、质量门禁、资产沉淀、治理规则和组织级复用能力。同时要把治理和 ROI 制度化。也就是说AI 使用成本、Token ROI、交付效率、质量变化、业务价值、人员能力差异和小队成熟度都需要进入持续度量。否则组织很容易只看到局部提效却看不到整体效能有没有真正改善。所以AI 时代软件工程转型的关键不是先把组织图画漂亮而是先让一个产品具备 AI 可协同的工程底座。每一个阶段都要沉淀 52 新范式的一部分。新角色要在试点中长出来新组织要在小队协同中演化出来新工艺和新流程要在真实交付中跑顺新资产要随着使用不断沉淀新工具要围绕真实任务建设新治理要基于真实风险和真实数据形成闭环。只有这样AI 才不会停留在个人工具层面而会逐步变成组织能力。落地的关键判断是不要先大规模改组织先让一个产品具备 AI 可协同的工程底座再用试点成果逐步复制到更多产品和领域。写在最后AI时代软件工程的变革不是要不要用AI的问题——这个答案已经很明显。真正的问题是个人提效之后组织如何承接52新范式的提出不是为了给出一套完美的蓝图而是为了回答一个更务实的问题当每个人都变快了组织能不能建立一套新的生产关系让这些效率真正转化为系统性的竞争力如果你也在思考AI强了组织怎么还没变快这个问题希望这篇文章能给你一些启发。【END】
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
