夜雨聆风最近我在尝试各种项目去跑我设计的AI工作流，过程还是碰到不少问题，还挺爽的，有问题很正常，就怕一直没问题，最后来一波大的。
客户给了我一版技术规范文档，CAN协议、控制命令、方向字段、速度范围、限位开关、源码变量位置都写了。坦率的讲，作为工程师看这份文档，信息量是够的。
但我把这份文档喂给AI的时候，AI疯了。
不是AI不行，是这份文档里混着好几个层级的信息。对人来说可以靠经验补全，但AI会把缺失的部分自己猜出来，而且猜出来的东西，表面看着合理，实际是错的。
举几个例子。
文档里有个命令叫「位置控制」，但目标值写的是200-1000Rpm。你作为工程师可能能猜到客户想表达什么，给一个值让电机运行嘛。但AI看到「位置控制」加Rpm，逻辑已经混了。这到底是位置环，还是速度环？
还有文档里写了Speed.c里某个变量的位置，直接当事实写死。AI就去这个文件、这个变量名下面死找，找不到就开始编。实际上这个变量在旧版本源码里存在，新版本已经改了。
文档写了PA12限位断开为低电平。对人来说，知道限位到了要停电机。但对AI来说，这句话缺了几个关键信息。什么时候检测？检测到之后做什么？需不需要消抖？消抖期间电机要不要先关？
还有一句「目标位置等于某个值后停止」。这个「某个值」到底是位置值、速度值、运行时间还是协议字段？没有单位，没有来源，AI只能猜。
这些问题不是客户不认真。恰恰相反，客户写了很多细节。但人和人之间的交接，天然带着「对方有经验」这个前提。人能从上下文猜出你的意思，AI不行。
我后来做了一件事。
我把客户的文档重写了一版。不是重写内容，而是把同样的信息换了一种组织方式。改了几个关键地方。
源码位置改成「线索」。原来写「在Speed.c的某个变量里」，我改成了「目前可能在某文件某变量，但以实际源码分析为准」。AI就不会把旧源码位置当成绝对事实了。
改完之后，同一个AI，同一个模型，读同一份需求，给出的分析和代码方案完全不一样了。从「来回猜三轮」变成「一次就能进入正确方向」。
同样的事情，同样的信息量，就因为组织方式不同，AI的表现会差一倍多。
其实在改的时候，我就发现了一个问题，这是一种对AI的认知，全凭我的感觉，好像并没有什么固定的方法论，但是没有的话，就不能把流程标准化。
我把这次经验整理成了一个框架，可能有些想法还不成熟，但已经毫无保留地分享出来了。
我不知道这个方法对大家有没有用，但我是真的觉得，它至少帮我自己省了很多来回。
不管你是在做电机控制，还是别的项目开发，这套框架的逻辑是通用的。我把需求拆成了7个部分。不是建议，是约束。每少一条，AI就多猜一轮。
1，目标。
这条需求最终要实现什么功能。
坏写法是「实现位置控制」。好写法是「收到命令后后，按照方向字段驱动电机运行，达到运行时间或限位条件后停止」。
区别在哪？坏写法是一个功能名词，好写法是一个完整行为描述。AI需要知道最终要发生什么事，而不是知道一个标签。
2，输入字段。
AI必须知道输入从哪里来、字段在哪、单位是什么。
这一项要写清的东西比较多，命令ID、字节位置、位定义、数值范围、单位、大小端、默认值。比如BYTE2 bit2表示方向，0为CW上升，1为CCW下降。Data[4..5]表示运行时间，单位ms，小端。
3，状态条件。
这个动作在什么状态下允许执行。
比如系统上电后先检测自学习标志，自学习完成或标志有效后进入正常流程，再接收CAN命令。运行中是否允许中途覆盖命令。故障状态下是否禁止启动。
很多需求文档只写「做什么」，不写「什么条件下做」。结果AI就会在不该启动的时候启动，在不该执行的时候执行。
4，动作。
收到命令后具体做什么。
这一项不能写成一句话概括，要写成动作序列。解析CAN命令，判断方向字段，设置目标速度或运行参数，启动电机，周期检测停止条件，停止电机并回到待机。
你想想看，AI不擅长从一句话里拆出多个步骤。你写「控制电机按方向运行」，AI可能只写启动不写停止。只写正转不写如何判断方向。你把步骤列出来，它就能一步步照着实现。
5，停止条件。
在嵌入式控制里，停止条件必须单独写。
常见停止条件有达到目标时间、达到目标位置、检测到限位、收到停止命令、出现故障、超时保护。
如果你觉得这条是多余的，想想你遇到过几次AI写的代码只管开不管关的情况。。。
这块需要注意一下。
6，硬件边界。
凡是涉及电机、继电器、加热、PWM、限位、急停的需求，都要写边界。
哪个引脚、有效电平、是否需要消抖、是否需要互锁、是否需要安全默认态、什么情况下禁止启动。硬件边界的核心就一句话，告诉AI什么情况下宁可不动，也不能乱动。
7，验证方法。
AI不只需要知道「要写什么」，还要知道「怎么判断写对了」。
用什么命令测试、预期反馈帧是什么、串口或CAN日志看什么字段、编译是否通过、硬件动作是否符合预期、异常时如何回退。
有了验证方法，AI才能进入「写代码、看结果、修正」的闭环。没有验证方法，AI只能写完就完，对不对它自己也不知道。
我把这7项做成了一个评分表，方便你自测。每项0到2分，满分14分。
| 项目 | 0分 | 1分 | 2分 |
|---|---|---|---|
| 目标 | 没写清 | 有功能名但模糊 | 明确最终行为 |
| 输入字段 | 没有字段定义 | 有字段但单位/位置不全 | 字节、位、单位、范围完整 |
| 状态条件 | 没写状态 | 写了部分前置条件 | 状态流转清楚 |
| 动作 | 只有概括 | 有动作但顺序不完整 | 动作序列清楚 |
| 停止条件 | 没写 | 写了一个停止条件 | 正常/异常停止都清楚 |
| 硬件边界 | 没写 | 写了引脚但缺少边界 | 引脚、电平、消抖、安全边界完整 |
| 验证方法 | 没写 | 有测试但无判定标准 | 命令、日志、反馈、验收标准完整 |
分数怎么看？
0到5分，AI只能猜，需要多轮澄清。来回几轮才可能对。
6到8分，可以做初步分析，但实现的时候容易返工。
9到11分，可以进入方案设计和代码修改，但还需要人工确认边界。
12到14分，适合直接进入AI实现加人审核加编译验证的流程。
拿客户那版原文打分，大概4到5分。改写之后的版本，大概10到11分。
这套东西不只能用在电机项目上。让AI帮你分析原理图、读芯片手册、拆项目阶段，逻辑都一样，把需求拆成这7个约束。
只有一个场景我想单独说一下，因为它最容易出事。
数字电源控制代码。坏输入是「帮我写一个电源控制算法」。好输入是，目标实现某个控制环节的输入输出且不直接上电，输入采样量和控制周期和输出限制和保护条件，输出模块接口和状态机和保护逻辑，验证先验证输入输出和限幅再进入硬件测试。危险外设场景里，AI需求必须带安全边界和验证顺序。宁可多写一句「不直接上电」，也不要让AI帮你生成一个炸机的方案。
还有带团队现场导入AI的。团队要的不是AI知识，而是第一套能复用的工作流样板。用一个真实小项目，从需求到代码到编译到复盘，现场跑通一个小闭环就行。
我把这个框架整理成了一个模板，你下次给AI写需求的时候可以直接套。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 ## 需求名称
## 1. 目标
- 要实现什么：
- 不做什么：
## 2. 输入
- 命令/接口：
- 字段定义：
- 单位/范围：
- 默认值：
## 3. 状态条件
- 前置状态：
- 允许执行条件：
- 禁止执行条件：
## 4. 动作流程
1.
2.
3.
## 5. 停止条件
- 正常停止：
- 异常停止：
- 超时/保护：
## 6. 硬件/安全边界
- 引脚/外设：
- 有效电平：
- 消抖/互锁：
- 风险动作：
## 7. 验证方法
- 测试命令：
- 预期日志：
- 预期反馈：
- 验收标准：
## 8. 不确定项
- 需要 AI 回源码确认：
- 需要人工确认：
- 待硬件验证：
注意最后一项「不确定项」，这个很多人会忽略。不是所有信息你一开始就能写全，但你可以标注「这个我不确定，需要AI回源码确认」或者「这个需要上电之后才知道」。
AI不怕你说不确定。
它怕的是你把不确定的东西写成了确定的东西。
我自己一开始也踩过这个坑。觉得AI应该能读懂啊，信息都给了啊。后来才慢慢意识到，我们做工程师这么多年，养成的习惯是给别人讲需求的时候默认对方有经验。这个习惯在人跟人之间是好习惯，它提高了沟通效率。但当你把对话对象换成AI的时候，这个习惯反而成了最大的障碍。
