结论先行：在AI-First的大潮中，当需求文档、技术设计与测试用例不再是“写给人看的”，软件工程真正被颠覆的，并不是“谁在写代码”，而是——整个开发生命周期中，哪些产物还值得存在。很多人一提 AI-First，就自然联想到：

• 自动写代码

• 自动生成接口

• 自动修 Bug

• 自动补测试

但如果你真的把 AI 引入真实研发流程，而不是 Demo，你会很快发现：代码反而是最不需要重构的那一层，真正开始失效的，是我们过去二十年默认合理的三样东西：

• 需求文档

• 技术设计

• 测试用例

不是因为 AI “太强”，而是因为这些东西，本来就是在“人类能力有限”的前提下被设计出来的。

一、我们过去写的“需求文档”，本质上是给谁看的？

如果你做过足够多的项目，你一定见过这种需求文档：

• 长篇背景

• 模糊目标

• 大量“应该”“支持”“尽量”

• 关键约束藏在角落

• 真正的判断规则，靠口头补充

它存在的真实目的，其实只有两个：

1. 在不确定中形成共识

2. 把复杂意图压缩成人类可读的文本

这在过去是必要的。因为：人的理解能力有限、沟通成本极高、只能靠文档“冻结”认知。但当你引入 Agent 之后，这套逻辑开始出现裂缝。

二、AI-First 之后，需求的“第一读者”已经变了

这是我踩过坑之后，才真正意识到的一点。在 AI-First 的研发模式下：需求的第一读者，已经不再是人，而是系统中的智能体。这会直接导致一个后果：传统需求文档的表达方式，对 Agent 是低效甚至有害的。因为Agent不需要：叙事性的背景铺垫、情绪化的业务描述、模糊的业务期望。它真正需要的是：

• 明确的目标边界

• 可判断的成功条件

• 明确的约束与禁止项

• 可枚举的业务状态

在我的过去项目里，只要你把原始 PRD 原封不动丢给 Agent，几乎一定会出现：过度实现、边界误判、“看起来合理，但完全不符合真实业务预期”的方案。这不是模型不行，这正好说明了传统需求表达已经不适合“机器理解”了。

三、需求文档正在从“说明书”退化为“配置层”

在 AI-First 的前提下，需求文档不再是：“描述我们要做什么的说明书”，而是在逐步变成：约束Agent行为的结构化输入。这意味着几个根本性变化：

• 自然语言必须被压缩

• 隐含规则必须被显式化

• 模糊表述必须被淘汰

• “大家都懂”的部分，必须写清楚

真正高质量的 AI-First 需求文档，越来越不像文档，反而越来越像一份规则定义。这对很多人来说是很不舒服的。因为它暴露了一个事实：很多需求，从一开始就是不清楚的，只是以前靠人脑兜住了。

四、技术设计文档的问题，从来不是“写得不够详细”

再说技术设计文档。在传统软件工程里，技术设计文档承担的角色非常明确：

• 对齐架构

• 分配模块

• 降低实现风险

• 方便评审与交接

但在引入Agent之后，你会发现一个很奇怪的现象：设计文档写得越细，Agent 的发挥空间反而越差。原因不复杂。大部分技术设计文档，其实是写给“人类理解”的、强依赖隐含上下文、包含大量经验性判断。但Agent在执行时，并不会自动继承这些“默认常识”。于是你会看到两种极端：

• 要么 Agent 严格照文档执行，但产出僵硬、低效

• 要么 Agent 自行“优化”，但偏离设计初衷

这时候你会意识到一个事实：技术设计文档，本质上不是执行规格，而是沟通媒介。

而在 AI-First 的体系里，“沟通”这件事，本身就被重构了。

五、AI-First 下，技术设计正在被拆成两层

在我现在认可的结构里，技术设计开始明显分裂为两种东西：

人类设计层

这一层关注的是：

• 为什么这么设计

• 哪些地方不能动

• 哪些是经验判断

• 哪些是风险兜底

它主要是写给“未来的维护者”看的。是技术文档

Agent 可执行层

这一层才是真正写给智能体的

• 模块边界

• 接口契约

• 不变量

• 资源限制

• 禁止路径

它不是解释，而是约束。是落地规范。

当你开始这样拆分，你会发现：以前混在一篇文档里的内容，现在必须被强制区分， 否则 Agent 一定会“误解你的意图”。

六、测试用例，正在从“验证工具”变成“行为定义”

这是AI-First时代变化最大的一环。在传统开发中，测试用例的地位其实并不高：

• 常被当成“补作业”

• 很少参与设计讨论

• 更多是验证结果

但当 Agent 开始写代码、改代码、重构代码之后，情况彻底变了。你会发现：测试用例，已经变成了系统唯一不会被“误解”的东西。需求可以被曲解，设计可以被优化，但测试用例：要么过、要么不过对Agent来说，它是最硬的约束。

七、在 AI-First 体系里，测试用例开始前移

在我现在的项目里，测试用例已经不再是“最后写的”。而是：在需求阶段就开始定义、在设计阶段不断补充、在实现阶段成为Agent的主要反馈来源。它的角色正在从：验证实现是否正确转变为定义系统允许的行为空间。这也是为什么我现在越来越认为：测试用例，本质上是一种“可执行的需求”。这正是 Agent 最擅长理解的形式。

八、AI-First 时代的软件工程变迁

如果你把需求、设计、测试重新放在一起看，你会发现：需求从叙事 → 约束、设计从说明 → 不变量、测试从验证 → 定义。这三件事，正在同时朝一个方向收敛：它们都在变成“系统规则的一部分”。AI-First 真谛并不是“让 AI 多干活”，而是逼着工程体系重新对“规则”和“约束”负责。AI-First并不是真实工程里的效率革命，相反它是对工程不严谨的惩罚机制。

如果你问我一句实话：AI-First 会不会让软件开发变简单？我的答案是不会。它只是把复杂度，从人脑的隐性负担转移到了系统的显性结构上。你不能再指望老员工默契、经验兜底、临场发挥等等，相反你必须把目标&&约束&&判断&&责任全部写进系统里。这也是为什么我现在越来越确信：AI-First 的终点，不是“人被替代”，而是工程终于被迫变得诚实。这是趋势，无论有没有 AI，迟早都会发生。