需求文档才是老板:图解规格驱动开发怎么管住 AI 生成代码

一个工控项目最怕的不是“需求变了”，而是需求被口头改了 8 次以后，代码已经没人说得清为什么长成现在这样。

现场说“油温高一点就要降功率”，老板又补一句“别影响正常作业”，软件工程师最后在代码里加了几个限幅和告警。两个月后设备又出问题，大家翻需求文档，发现上面还写着旧逻辑；翻代码，又看不出当时到底按谁的意见改的。

这就是**规格驱动开发**要解决的问题。它不是让你多写一份没人看的 Word，而是把“需求文档”变成 AI 写代码、生成规格、交叉编译、下载验证、问题修复时共同对齐的源头真相。换句话说，**需求文档驱动**不是文书工作，而是把 AI 的自由发挥管起来。

## 一、规格驱动开发：先把“写什么”钉住

我核对了本地正在做的严酷环境计算机开发工作台源码和说明文档（截至 2026-07）：它的主流程不是“输入一句话，直接生成代码”，而是六段闭环：需求编写、规格澄清、代码生成、交叉编译、下载验证、问题修复。下面这张流程参考图，就是这六段闭环在真实工作台里的落点。`需求.md` 不是旁观材料，而是后续每一步都要回看的源头。

这里最容易被低估的是“澄清需求”。比如你写“液压油温过高要保护”，AI 必须继续问清楚：多少度算过高？保护动作是降 PWM、报警，还是停机？影响哪几个任务周期？如果不澄清，模型会替你假设。

## 二、三个循环：不是瀑布，是可追溯迭代

这套流程可以拆成三个循环。

第一个是“需求—规格循环”：编辑需求，AI 找模糊点，澄清后再回写需求，解决“说不清”。

第二个是“生成—编译循环”：AI 先生成规格说明、设计、任务清单，再写代码；构建失败时，系统读取构建摘要，把错误回灌给 AI 修复，直到产出可下载验证的 `output/hec_app`。

第三个是“验证—修复循环”：下载到设备前，现场确认安全条件；验证后如果发现问题，就记录现象，重新进入修复问题或增加功能流程。这样现场反馈能回到需求和规格，而不是变成一段没人敢删的临时代码。

从架构上看，关键不是“AI 更聪明”，而是把 AI 放进受控链路：需求文档和项目生成物被统一管控，代码生成之后还有构建、产物和流程状态留痕。也就是说，AI 的不确定性不是靠口头承诺控制，而是靠文档、规格、构建结果和人工决策点一起收住。

## 三、六个决策点：AI 生成，人来把关

规格驱动开发不是全自动黑箱。真正关键的是六个决策点：

项目/机型、需求具体度、AI 澄清假设、本轮生成范围、下载验证安全、验证后的修复/加功能/交付判断，都必须人来确认。

其中“下载验证”尤其不能省。本地说明文档里，下载运行前会提示安全风险，并要求确认现场做好防护后输入 `yes`。这不是形式主义，而是工业现场的底线。

所以，D01 讲的三重难，不能靠“让 AI 多写点代码”解决。真正需要的是：让懂现场的人把需求讲清楚，让 AI 围绕同一份需求文档生成、编译、修复，让每次变更都有痕迹可查。

这就是我理解的**规格驱动开发**：不是让文档压过代码，而是让代码终于能回答一个问题——“我为什么这样写？”

---

**聊聊**：你们团队的需求文档和实际代码，多久会出现一次对不上？

建议收藏本文主图。下一篇我们继续聊：这套方法对 CoDeSys/PLC 背景、不是职业程序员的现场工程师意味着什么。

如果想要快速验证本文所提到的方法，建议访问 https://hecas.online 下载HEC AI Studio，零成本、零门槛快速开始【规格驱动开发】最接地气的实践。