软件工程3.0：测试给了 85 屏，运维只有 13 屏

2026-11-13silcano

微信读书《软件工程3.0：大模型驱动的研发新范式》（朱少民、王千祥 著，人民邮电出版社 2025-05，ISBN 9787115666390）· 逐页翻阅 495 屏 · 抓取标记 reached_end=True（end_reason=last_page，书尾落在"奔腾不息，未来已来"）· 阅读器共记录 112 个章块，六章。
抽样说明：这是一本讲研发范式的书，所以我按"时代划分—新形态—路线图—能力建设—生命周期落地—未来"六条线抽读：p0001 版权页、p0006 推荐序二、p0011 前言（软件形态从"程序"到"模型"这一段）、p0058 迈向 10 倍效能、p0059 图 2-5（LLM 提效的阶段分布，来源《AI4SE 行业洞察》）、p0325 o1 代码生成能力展示、p0405 决策表生成、p0460 LLM 是银弹吗。
章屏数按阅读器顶部章标签切分（112 个章块，小节级）。所有引文与数字只来自上述页面；关于"综述多于实证""10 倍停在标题""作者专长决定篇幅分配"这类判断，是我的核查意见，不是书里的原话。

495 屏，六章，112 个章块。这个屏数在本系列里排第二，仅次于那本 793 屏的《智能体设计指南》。

先说结论：这是我读到的、对"AI 到底改了软件工程的哪几段"讲得最全的一本，也是最能看出作者是哪一行出身的一本。

它像一张地图。画得很完整，从需求到运维七段路都标了，哪段能通车、哪段还是土路、哪段容易塌方，都写在图例里。它的问题是：地图上那些数字，几乎全是抄别人量出来的。

一、495 屏的账：一半篇幅压在第五章

按章统计：前置（版权、内容提要、两篇推荐序、前言、致谢）19 屏；第 1 章 演变之路：软件工程的三个时代 22 屏；第 2 章 为何定义软件工程 3.0 26 屏；第 3 章 实施策略和路线图 39 屏；第 4 章 核心能力建设 98 屏；第 5 章 实践场：重塑软件开发生命周期 253 屏；第 6 章 未来展望 28 屏；参考资料与后记 10 屏。

加起来 495。

第 5 章一个人占了 51.1%。这一章里又分七节，页数是这样的：5.1 需求获取与分析定义 44 屏；5.2 架构设计 42 屏；5.3 UI 革命 26 屏；5.4 结对编程 41 屏；5.5 TDD 青春焕发 29 屏；5.6 测试智能化 56 屏；5.7 LLM 驱动运维 13 屏。

两组数字值得单独看一眼。

第一组：测试相关的两节加起来 85 屏，占全书 17.2%。5.5 讲 UTDD 和 ATDD 怎么在大模型时代复活，5.6 讲 LLM 怎么驱动测试分析与设计、怎么生成用例和脚本、怎么做非功能性测试。这两节是全书密度最高的部分，案例是具体的，方法是可以照着做的。

第二组：运维只有 13 屏，占 2.6%。5.7 讲 LLM 在运维上的核心能力和应用案例，四屏加六屏加两屏，一节就完了。

85 比 13。这个比例不是巧合。朱少民是国内软件测试领域写得最多的人之一，测试是他的主场；运维不是。所以这本书在测试那两节写得像专著，在运维那一节写得像导言。

一本书的篇幅分配，就是作者的诚实自白。他没法假装自己什么都会，于是把力气全花在自己真会的地方。这一点我不认为是缺点，反而觉得比那些每章平均用力、每章都写得很平的书要好。你至少知道哪几章值得反复读。

前置 19 屏也算克制：版权 1 屏、内容提要 1 屏、两篇推荐序 7 屏、前言 10 屏、致谢。没有大段专家赞誉，没有学员推荐，翻开就进正文。附录的参考资料 3 屏，后记 7 屏。这个编排很"学者"——把版面留给内容，把客套压到最低。

二、它真正的贡献：把"AI 改软件工程"拆成七段流水线

市面上讲"AI 提高研发效率"的书很多，多数停在两个层次：一层是"提示词怎么写"，一层是"哪个工具好用"。这本书难得的地方，是它把软件开发生命周期拆成七段，然后一段一段问：这一段里，大模型能做什么、不能做什么、做法变了没有。

比如需求这一段（5.1，44 屏），它没有停在"让 AI 帮你写需求文档"。它把 RAG 和智能体接进需求分析，然后往下走到业务需求建模、需求定义、需求评审与优化，最后讲到验收标准怎么写——这里出现了那个我认为全书最可落地的概念：用 BDD 的 Given-When-Then 格式写验收标准。

为什么这个格式重要？因为验收标准一旦写成"给定什么前提、执行什么动作、期望什么结果"的结构化句子，它同时就是三样东西：需求、测试用例、以及给模型的提示。作者在第 5.4 节里顺着这条线讲下去，说需求和测试都从同一个 BDD 出发，各自生成产品代码和测试脚本，"互相博弈"，自动化和质量水平都能达到很高的水平。

这个说法有点乐观，但方向是对的。它不是"AI 帮你写代码"，而是"你把话说成机器能同时当需求、当用例、当提示的样子"。这是范式层面的变化，不是工具层面的。

第 5.6 节给的东西更具体。它让模型从需求出发生成决策表——17 屏那张图里，列头是"策略名称有效、优先级有效、催收渠道有效、时间表有效"，行是 R1 到 R15 十五种条件组合，最后一列给出对应的预期行动 A1 到 A5。这就是一张可以直接转成测试用例的判定表，而且是模型按条件组合穷举出来的，人很容易漏掉 R9 到 R15 这种多条件交叉的情形。

这个案例的说服力，比后面所有"效率提升 40%"的数字加起来都强。因为它让你看见了一个具体的、人可以核对的东西。

还有一个判断，我在第 2.3 节读到的时候点了头：

单独在某个环节应用LLM可能不会立即带来显著的效率提升。为了实现更高效的开发流程，我们需要借助过去的平台工程能力，打通各个环节，实现从需求分析到产品交付的全过程大模型应用。

这句话解释了很多团队的困惑：为什么我们给每个人都开了 Copilot，交付速度没变？因为你在一个环节加速，上下游没变，瓶颈就转移到别处去了。写得快不等于交付快，交付快不等于上线快。效率这件事是全链路的，不是单点的。

顺着这条线，第 4 章把"核心能力"列成六项：提示工程、RAG、智能体、数据治理、模型工程、安全治理。98 屏，一项一节。这六项不是并列关系，是有顺序的——提示工程是最浅的，谁都能上手；RAG 要有数字资产；智能体要有工具和编排；数据治理和模型工程要有人和钱；安全治理要有制度和流程。这一章的价值，是让你知道自己在第几层。

三、"10 倍"是个标题，不是结论

第 2.3 节的标题很响：生产力革命：迈向 10 倍效能。

正文是这么写的：

目前，尽管统计数据显示LLM在软件研发中的应用效率提升中位数大约为40%（如图2-5所示），但这仅仅是一个开始，随着大模型能力的不断增强以及研发人员应用LLM的能力的提升，LLM将更全面地融入软件研发的整个生命周期，最终可能带来高达10倍的效能提升。

这句话本身没毛病，措辞甚至是谨慎的——"可能"。但它把两件事放在了一段里：一个是数据（40%），一个是愿景（10 倍）。读者读完，记住的往往是后者。

我要追问的是那个 40% 从哪来。答案是图 2-5，标题叫"LLM 在软件研发各个阶段的提效工作"，来源标注是《AI4SE 行业洞察》。也就是说，这个数字不是作者测的，是转引的；它甚至不是一项针对某家公司的研究，而是一份行业观察报告里的统计。

顺带说，这张图本身是全书信息量最密的一处。它按阶段列出 LLM 能接的工作：需求分析、设计、编程、测试、运维，每个阶段标出提效幅度。你如果只想要一个"哪一段最值得先投"的判断，看这一张图比读四十页正文快。

这就是这本书的基本结构：观点很硬，证据很软。

再往后看第 6.1 节，讨论"LLM 是银弹吗"，开篇放的是 GitHub CEO Thomas Dohmke 那篇《Copilot X: Realizing the '10x Developer'》的截图；论证里引的是"中国信通院的调查数据显示，代码采纳率在 21%~80% 的团队占……"。全是二手的。

我得说清楚：引用二手数据本身不是错，综述性著作本来就该这么写。真正的问题是，这本书同时想当综述和想当实证，结果两头都不彻底。它用了实证的语气（"效率提升中位数大约为 40%"），却只给了综述的证据（一份行业报告的图）。

四、自己动手的地方，加起来不到三十屏

我把 495 屏翻完，专门找"作者自己做了、然后给你看结果"的段落。找到三处，都在第 5 章。

第一处，5.4.2 节，19 屏：拿 o1 preview 解多重背包。

做法挺坦率：因为 LeetCode 上只考 01 背包和完全背包，没有多重背包，所以挑这个题，测 o1 preview 能不能生成。原文写着"我们期望生成的代码逻辑思路清晰、时间复杂度低，而且借助模型的自我测试功能，确保代码运行、验证通过"。然后给出完整提示词和模型的输出。

挑一个"题库里没有"的题，这个心思是对的——至少说明他们想过"防背题"。但评价标准还是主观的：清晰、复杂度低、验证通过。没有跑分，没有和别的模型对照。

第二处，5.5.1 节，UTDD 的对照实验。这是全书做得最漂亮的一处教学设计：先给出用 UTDD 流程（先写测试、再写实现）生成的 Calculator 类和测试类，然后紧接着说——如果不是 UTDD，大模型很可能生成下面这样的结果，于是把一份"非 UTDD"版本也贴出来，最后问一句："与上面生成结果对比，代码和测试脚本的质量孰高孰低，是不是显而易见？"

这份对照里，非 UTDD 版本把除法里的零判断用 IllegalArgumentException 抛出来，然后写了个 main 方法自己打印结果算完事；UTDD 版本则有一整套 JUnit 断言。差别确实显而易见，而且是读者自己看出来的，不是作者塞给你的结论。这种"把两份东西摆在一起，让你自己判断"的写法，比十句"UTDD 更好"都管用。

第三处，5.5.2 节，ATDD 里那个数字。这一节用 Cucumber.js 写 Given-When-Then，给出催收账单场景的完整 step definitions。然后有这么一句：如果觉得验收标准不够完善，可以把业务需求文档上传给模型做参考，重新生成——"从输出结果看，验收标准从 3 个增加到 9 个，更能保证验收标准的完整性和测试的充分性"。

3 个变 9 个。这是全书我找到的、唯一一个既具体又不含糊的对照数字。它很小，小到不值得写进摘要，但它是我在 495 屏里唯一能抓住的实证。

三处加起来，不到 30 屏。其余 460 多屏，是"应该这样做""行业数据显示""某公司实践表明"。这个比例，是我给这本书打分的核心依据。

五、它讲对了一件别人常讲错的事

公道话也要说。这本书有一个判断，我认为比市面上绝大多数"AI 取代程序员"的论调清醒。

第 1 章划分三个时代，作者没有写成"后者淘汰前者"。他明确说，软件工程从 1.0 到 2.0 再到 3.0，是持续成长与演进的过程，绝非简单的替代：传统软件工程的 V 模型仍在航空航天等高可靠性领域发挥重要作用，敏捷研发范式继续在快速迭代的业务场景中创造价值，而智能软件工程则在其适用领域释放生产力。

三句话，三个"其适用领域"。这是内行话。

因为真正做过工程的人都知道，一个银行核心系统的清算模块不会因为有了大模型就改成生成式的——它需要确定性、可审计、可复现。而一个营销落地页的文案，用大模型生成就是最优解。同一个行业里，两套方法并存，各管一段。

第 2 章讲软件形态的变化，也是同一个思路。它把传统程序和大模型做了个对照：传统程序以算法和数据结构为基石，适合处理确定性问题，从问题出发，分析问题、解决问题；大模型以海量参数、高维向量及关联关系为基础，善于应对不确定性、大规模输入，常输出概率性结果，不是在"解决问题"，而是在解空间中搜索相对最优解。

最后那句"不是从问题出发，而是直接在解空间中搜索相对最优解"，我认为是全书最锋利的一句。它点出了两种范式的根本差异：一个是构造，一个是搜索。构造出来的东西你能证明它对；搜索出来的东西你只能抽样看它像不像对。

这一句解释了为什么测试在这本书里占了 85 屏。因为当软件从"构造"变成"搜索"，验收就从"证明正确"变成"评估像不像"——而这恰恰是测试这门手艺最核心的部分。

顺着这个逻辑，第 2 章还讲了生产关系的变化（2.4，6 屏）：超级个体与新型团队。这一段不长，但它提的问题很实在——如果一个人带着模型能干完过去五个人的活，那团队该怎么组、评审该谁做、责任该谁背。书里没有给答案，但把问题摆出来了，而且摆得很克制，没有画那种"一个 AI 管一百个工程师"的大饼。

六、它的短板

按这本书自己的框架，我给四条。

第一，综述多于实证。这是最根本的一条。全书的论证链条基本是"引用 → 归纳 → 断言"，引用源包括《AI4SE 行业洞察》、中国信通院调查、GitHub CEO 的文章、各家模型榜单。这些引用都有价值，但它们拼起来是一篇很好的行业综述，不是一本实验报告。当一本书的标题写着"新范式"，读者会期待范式被验证过，而不只是被描述过。

第二，10 倍停在标题。节名"迈向 10 倍效能"，正文的数据支撑是中位数 40%，10 倍靠"最终可能"。这个落差在书里不止一处：第 6 章问"软件复杂度问题能彻底解决吗"，答"取决于"；问"未来的软件会更加安全可信吗"，答"取决于"。用提问当结构、用"取决于"当结论，读起来很周到，实际上是把判断推回给读者。

第三，第 6 章 28 屏像一场圆桌。六问六答：LLM 是银弹吗、复杂度能解决吗、会更安全吗、工具角色怎么协同、多模态带来什么、AGI 影响如何。每问四到五行，每答都四平八稳。这一章的信息密度明显低于第 5 章，更像是为了"给个收尾"而写的。

第四，案例的"作者"身份模糊。第 5 章里的例子很多，但很少说清这是谁做的、在哪家公司做的、多大团队做的。有些案例看得出是作者自己试的（比如 o1 那道背包题、UTDD 的那组对照），有些明显是转述别人的实践，但书里没有统一标注。读者没法判断哪一段是"我做过"，哪一段是"我读到过"。这一点在工程书里是要命的，因为两者的可信度差着一个量级。

最后说一句横向的感受。这一周我连着读了四本 AI 工程书，作者背景各不相同：一个后端老手写的避坑、一个提示词社区写的设计指南、一个培训班团队写的高并发、一本资深测试专家写的范式。四本里，最能给我"能直接用的东西"的是那本 Eino（代码是真的），最能给我"完整结构"的是这一本（地图是全的），最能给我"原创方法"的是那本结构化提示词。

但它们有一个共同的缺口：四个人都没有把自己的结论量一遍。一个不给 QPS，一个不给准确率，一个不给验收标准的覆盖率，这本书给了 3 条变 9 条——已经是四本里最具体的一个数字了。

这不是四个人偷懒，是这个行业还没到能量的时候。方法论先跑，度量后补，历来如此。我只是希望下一本书里，那张表能出现。

七、这本书适合谁

它不适合想学写代码的人。全书几乎没有可运行的代码，提示词倒是给了不少。

它适合三类人。

第一类，技术负责人或研发管理者。你要回答"我们团队该怎么引入大模型"这个问题，这本书的第 3 章（实施策略与路线图，39 屏）能直接拿去用：先自我评估选方案，再局部试点适当扩围，最后全面实施与持续改进；模型是自己微调还是买第三方，第 3.3 到 3.5 节给了判断依据。这三步不需要多聪明，但需要有人把顺序捋清楚，这本书捋清楚了。

第二类，测试和质量岗。第 5.5、5.6 两节 85 屏，是这本书真正的核心资产。UTDD 和 ATDD 在大模型时代怎么变、测试用例怎么让模型生成、非功能性测试怎么做，这些内容在中文书里还很稀缺。你做这行，这两节值得读两遍。

第三类，想理解"范式"这个词到底指什么的人。第 1、2 章 48 屏，把 1.0、2.0、3.0 三个时代的差异讲得清楚，而且没有踩"颠覆"的坑。这是这本书最耐读的部分，也是最不容易过期的部分。

反过来说，如果你想要的是"怎么让我的团队这个季度交付快 30%"，这本书帮不上。它给的是方向、结构和清单，不是数字。

八、怎么读

我给三个读法。

时间紧的，读三处，不到 90 屏：第 1.3 节（p0028 起，3.0 的特征与跨时代比较，14 屏）、第 3.2 节（p0080 起，实施三部曲，10 屏）、第 6.1 节（p0459 起，LLM 是银弹吗，4 屏）。这三处读完，你对这本书的立场就有数了。

做研发管理的，把第 3 章 39 屏整章读完，再做一遍 3.2.1 那个自我评估。这一章的价值不在观点，在顺序——很多团队引入大模型失败，不是工具选错，是顺序错了：先全面铺开，再回头补基础设施。

做测试的，直接跳到 p0360，把 5.5 和 5.6 两节 85 屏读完，中间不要跳。这是全书写得最实的地方，也是唯一能让你明天就改工作方式的地方。

第 4 章 98 屏讲核心能力建设（提示工程、RAG、智能体、数据治理、模型工程、安全治理），是一份很完整的"能力清单"，但每一块都只有入门深度。当索引查可以，当教材读会不够。

还有一个读法上的提醒：这本书的"节"划分很细，112 个章块，很多节只有一到两屏，读起来会碎。它的结构更像一份报告而不像一篇文章，所以不要顺着读到底，要按"我现在卡在哪一段"去翻。把它当手册，比当书读效率高。

最后说一句我的整体判断。

这本书的价值，不在于它证明了什么，而在于它把一件正在发生但没人整理的事，整理成了一份可以讨论的稿子。软件工程正在被改写，改写到什么程度、哪些环节先变、哪些环节动不了，这些问题的答案现在还没有定论。作者没有假装有定论，他给了一张地图和一堆标注，标注的可靠性参差不齐，但地图本身是有用的。

读它的时候，我建议你带着一个动作：每读到一个数字，问一句"这是谁量的"。问完之后你会发现，这本书里能站住的数字不多，但能站住的那几个，恰恰是最重要的——比如"测试从证明正确变成评估像不像"，比如"V 模型不会消失，只会退到它该在的地方"。

一句话收尾：它把一张正在改画的地图描得很全，只是每一处标高都标着"据他人测量"。

---

阅读记录｜微信读书《软件工程3.0：大模型驱动的研发新范式》，朱少民、王千祥 著，人民邮电出版社 2025 年 5 月第 1 版，ISBN 9787115666390。逐页截图 495 屏，112 个章块，六章，抓取耗时 598.6 秒，读到书尾（end_reason=last_page）。本文引文出自 p0011、p0058、p0059、p0325、p0405、p0460 等页；第 5 章七节的屏数按阅读器章标签逐页归属计算；判断与批评为本人观点。