AI越强,软件工程的价值越大

先说结论：AI用得越深，越发现软件工程那套东西是对的。

不是"规范要遵守"那种对——是底层逻辑上的对。软件工程是几十年无数工程师用失败换来的基本原理，它描述的是软件开发这件事本身的运作规律。AI按这个逻辑跑，出错概率最低。你偏离它，不是在挑战规范，是在对抗规律。

过去的软件开发，有一套行之有效的运作方式——很多隐性知识不需要写下来，因为它就活在团队里。老工程师在，需求说一半他能脑补另一半，设计没落纸他知道哪里不能动。

这不是偷懒，是当时条件下合理的工程选择。把隐性知识显式化的成本，往往高于它带来的收益。

AI来了之后，这个逻辑开始崩。

AI有强大的通用知识——语言、算法、框架、设计模式，训练数据里什么都有。但它天然缺失一样东西：你项目的专属上下文。

你们的业务规则是什么？这个字段为什么不能为空？那个接口为什么要这样设计？这个模块三年前重构过一次，当时踩了什么坑？

这些东西，训练再多数据也不会自动拥有。

你省掉的每一份需求文档、每一个架构设计、每一条测试标准，就是在切断AI理解你的唯一通道。它只能在这些空白处用通用经验去猜。猜出来的东西，看起来合理，但离你的实际需要差之千里。

同样一个需求，给AI一份完整的PRD和只给一句口头描述，结果的差距不是好一点——是能不能用的差距。

我们有个真实案例。同一个功能，口头描述给AI，生成的代码改了四轮还没对。后来花了半天把业务规则整理成文档再喂给它，一次过。

模型没变，上下文变了，结果就变了。

过去跳过架构设计，是因为"太贵"——画图、评审、对齐，要花好几天，还不如直接开干。

现在这个逻辑不成立了。

AI把执行成本打穿了。写代码不再是瓶颈。一个功能，过去要三天，现在半天。

但产出质量取决于什么？取决于你给AI的上下文质量。

需求写得清不清楚，架构设计有没有落纸，测试标准定没定——这些"准备工作"，过去因为执行成本高所以跳过，现在变成了决定产出质量的唯一变量。

过去省掉架构设计，省的是几天时间，损失的是一点点代码质量。

现在省掉架构设计，省的还是那几天时间，损失的是AI在整个项目周期里每一次生成的质量。

同样的选择，代价放大了十倍。

需求文档、架构设计、测试规范——这些东西的本质是什么？

不是流程，不是规范，是软件开发这件事本身的运作规律。几十年来无数工程师踩坑总结出来的：需求不清楚，做出来的东西就会偏；设计没想清楚，后面改起来就会痛；没有测试标准，你永远不知道做没做对。

这套逻辑，在人写代码的时代是对的。在AI写代码的时代，同样是对的——而且更严格。

人写代码，还能靠经验和直觉修正偏差。AI没有这个能力。你给它的上下文偏了，它会非常高效地沿着错误方向跑下去。

我们有个实战案例。一个核心模块，之前需求都是口头对齐，AI生成的代码返工率很高，平均一个功能要改三四轮。后来花了两天把这个模块的业务规则整理成文档，喂给AI之后，返工率直接降了一大半。

不是AI变聪明了——是我们把软件工程该做的事补回来了。

所有AI给出不符合预期的结果，本质上都是对软件工程基本原理的偏移。

这不是线性关系，是乘数关系。AI越强，执行越快，偏移的代价就越大。

不是让你回到瀑布模型，不是让你把每个需求都写成一百页的规格说明书。

是认清楚一件事：软件工程不是束缚，是规律。它描述的是软件开发这件事怎么做才能做对——这个规律在人写代码的时代成立，在AI写代码的时代同样成立。

你省掉的每一个步骤，不是在提效，是在给AI制造偏移的空间。

关注「灵机智枢」，我们一起把AI用到极致。