代码越来越容易写，为什么还需要软件工程HERMES & AGENT ENGINEERING · 课时 06

6.1 那些看起来没有用的东西

我们只是想做一个胶囊系统，但一路走下来，已经遇到了项目宪章、核心原则和治理规则，连版本怎么记录、以后怎样修订也有规定。要是继续往传统软件工程里走，还会遇到更多名词，比如架构决策记录（ADR）、变更申请（Change Request）和需求追踪矩阵。

看到这里，产生怀疑很正常。一个项目，真的需要这么多东西吗？

一次性的演示项目，能跑起来往往就足够了。个人项目和小团队也没有必要照搬大公司的审批流程，给每次改动开会、签字、编号，再准备十几份没人看的表格。软件工程不是文档越多越好，更不是把简单的事情故意做复杂。

但可以这么说，演示性质的个人项目和真正的商业项目往往不是差在规模上，而是差在长期的生命周期管理上。

6.2 软件工程真正难的是管理变更

第一次把代码写出来，往往不是一个软件最难的时刻。真正麻烦的是它开始被使用以后：用户提出新需求，原来的规则要调整，新的实现又可能破坏旧功能。项目每向前走一步，都可能改动前面已经确定的东西。

比如胶囊系统已经规定“未经用户确认，不得永久删除原始证据”。几个月后，我们又想增加自动清理功能。Agent 很快就能写出一段定期删除旧资料的代码，但问题也随之出现：为什么当初禁止自动删除？哪些资料可以删除？删错了还能不能恢复？

代码只能告诉你系统现在怎么做，很难告诉你当初为什么这样做。Git 可以记录哪一行在什么时候被改过，却不一定能回答这次修改的业务动机。聊天记录可能保存过讨论，但几个月后散落在不同会话里，也很难成为可靠的项目记忆。

宪章、SPEC、技术方案、测试和变更记录，分别保存了不同层次的答案。宪章记录不能轻易跨过的边界，SPEC 记录系统应该表现成什么样，技术方案记录当时为什么选择这种实现，测试和验收记录哪些行为已经被证明有效，变更记录则把修改的原因、范围和结果串起来。它们不是为了把项目变得越来越复杂，而是为了解决下面这个问题：

当项目发生变化时，我们怎样知道自己改了什么、为什么改，以及有没有把原来正确的东西改坏。

软件工程讨论了几十年，本质上一直在处理“变化”这个问题。我个人的暴论是：软件工程就是为了解决变化，如果项目不存在变化，软件工程则毫无用处。

项目会变化，团队会换人，人会忘记。只要这些事实没有消失，记录、验证和追溯就不会失去价值。

6.3 真实使用为什么会逼出这些规范

我自己的感受是，国内不少开发团队对文档和测试的重视程度确实不高，甚至大部分程序员连软件工程讲的是什么都不知道。需求常常散落在聊天记录里，功能先做出来再说，出了问题就临时找人修复。项目赶着交付时，文档和测试会变成不重要的部分，“以后再补吧”，而这个“以后”通常永远不会到来。

这里不完全是开发者习惯的问题，也和项目怎样挣钱、能活多久有关。有些项目交付以后很少有人真正使用，或者验收结束就不再持续维护（我敢说至少 80% 的项目都是这样的）。没有真实用户不断提出问题，也没有旧数据需要兼容，更没有人追究某次修改为什么破坏了过去的功能，不写文档、不做测试的代价当然看不出来。说得直接一些，一个不会继续生长的项目，不太需要为未来留下记忆。

但软件一旦真的有人长期使用，情况马上就变了。一次看起来很小的修改，背后可能连着用户已经保存的数据、对外提供的接口和正在履行的合同。需求写得含糊，开发者就可能做错；没有测试，谁也不知道新功能破坏了什么；没有版本和变更记录，出了问题连应该回退到哪里都说不清楚。此时再依靠“大家应该知道”“代码里应该能看出来”，已经不足以支撑项目继续运行。

这正是严谨规范与软件实用性之间的关系。软件越是被真实使用，一次错误变更影响的人就越多，修复和赔偿的成本也越高。于是需求和方案需要确认，旧行为需要测试，发布和回滚需要留下版本依据。项目规模继续扩大以后，同一套动作还会进一步变成需求追踪、架构决策记录和发布审批。那些看起来复杂的流程，往往不是哪个公司喜欢把事情做复杂，而是项目已经承担不起一次说不清楚的变更。

在不少海外软件公司，甚至外包项目里，变更申请、测试报告和交接文档都会成为正式交付物。原因未必是谁更热爱写文档，而是软件交付以后还要继续使用，变更本身也有明确的价格和责任：需求是谁提出的，增加了多少工作，哪一版得到批准，都需要留下依据。客户付钱购买的也不只是眼前可以运行的代码，还包括以后可以继续修改、可以交给别人维护、出了问题能够追查的确定性。

所以我们看到一些长期运行的商业项目拥有非常严谨，甚至显得有些笨重的规范时，不能只看到多出来的文档和审批。更应该看到的是，这个项目背后已经有真实用户、历史数据和维护责任。每多一层不能轻易承受的后果，变更就需要多留下一层证据。

6.4 AI 让软件工程重新回到中心

Vibe Coding 改变了软件开发中最显眼的一部分。过去，一个想法最大的门槛可能是不会写代码；现在把需求交给 Agent，几分钟就能生成一个可以运行的版本。实现代码正在变得越来越便宜。

但代码越容易生成，变化也会来得越快。过去一个团队一周只能做一个版本，现在一天可以尝试十个方案。Agent 可以迅速增加功能、替换框架、调整数据结构，也可能在没有充分理解历史原因的情况下，把原来正确的约束一起改掉。代码数量增加得越快，人越难仅凭记忆掌握系统为什么会变成今天这样。

AI 降低的是生成代码的成本，没有降低理解变更、验证行为和承担后果的成本。

这就是软件工程在 AI 时代重新受到重视的原因。人的工作开始从“亲手写出每一行代码”，转向把需求讲清楚、把边界定下来，再验证结果并管理后续变更。SPEC、宪章、测试和变更记录，恰好为 Agent 提供了可以持续读取的项目上下文，也为人保留了检查和追责的依据。

所以，不要因为这些文件看起来像废话，就把它们全部丢掉；也不要因为软件工程有几十年历史，就把所有流程原样搬进个人项目。更实际的做法是理解每一种方法在解决什么问题，再根据项目的寿命、风险和协作规模，保留当前真正需要的部分。

6.5 软考高项的经历

我自己对这件事的感受很深。之前考软考高级时，我有意报的是“信息系统项目管理师”，也就是大家常说的软考高项。这个考试除了信息系统知识，还包含不少和 PMP 项目管理知识相通的内容。那时候我是程序员出身，总觉得范围、风险、变更这些东西离写代码很远；考试时也还没有今天这样普遍使用 AI 的开发方式，所以并没有觉得它们有多重要。

考过后，现在回头看，当时学到的东西恰好可以用来理解 AI 开发：先把范围和验收条件写清楚，Agent 才不会过度发挥；需求发生变化时先看可能影响的范围，再决定改哪些文件。这些内容在考试里像答题模板，看似无聊，但到了 AI 时代，突然变成了管理代码变化的实际办法，还真的有点用。

所以，如果还有余力，我很建议重新学习一次经典软件工程。需求分析、软件测试和变更控制，这些内容并没有因为 AI 会写代码而过时。相反，当写代码不再是主要瓶颈时，我们才会更清楚地看到，它们原本是在替我们管理什么。

6.6 ■ 学点英语