——技能：把开发流程拆成 AI 能执行的步骤
这是《嵌入式 AI 落地手记》的第六篇。前面讲了工程底座，这篇讲 AI 具体怎样工作：生成与检查怎样分工，人工确认放在哪里，技能又怎样根据使用反馈继续修改。
我们以为需求明确了，AI 却先问了起来
新流程在一个真实项目里开始试用时，我们起初认为需求已经基本明确，甚至已经开始讨论设计问题。
结果文档转换和整理阶段先卡住了：有的需求描述不清，有的内容在两份输入里互相矛盾，还有一些硬件机制，仅凭现有文件不知道应该怎样使用。AI 没有顺着“基本明确”的判断往下写，而是一直追问，直到这些问题有了着落。
这次暴露的不是谁粗心，而是大家对“需求明确”的标准并不一样。技能把一部分原本依赖个人经验的检查标准变成了固定步骤，新加入流程的人也会走到这些步骤上。
对我来说，技能的价值首先不是生成得有多快，而是这种标准能够被执行和继承。
模板管产出，技能管过程
第一版仓库里有文档模板，也有检查技能，但生成侧基本是空的。改版后，每个主要阶段逐渐形成生成与检查两类技能：
| 阶段 | 生成辅助 | 检查辅助 |
|---|---|---|
| 输入准备 | 原始文档转换 | 转换结果的人工抽检 |
| 需求 | 需求整理与起草 | 需求完备性与质量检查 |
| 设计 | 设计起草 | 设计完备性、依赖与承接检查 |
| 编码 | 按模块起草代码 | 静态检查，以及架构、模块、流程三个维度的评审 |
| 测试用例 | 测试用例整理 | 用例覆盖与质量检查 |
生成技能负责归集、提取、结构化和起草；检查技能负责发现遗漏、重复、漂移和不一致。它们不会互相调用，生成完成后由人触发检查，检查结果也交给人处置。
文档模板也不是单纯的排版格式。栏目、功能四件套、适用性判定和内容边界，本身就沉淀了过去对“合格交付物”的理解；它们既约束最终产物，也把这部分知识传给 AI。
所以，生成与检查分开，是为了让两类工作使用不同判据，不等于自动形成了独立验证。最后的评审和放行仍然由人完成。
一个技能怎样推进工作
以需求整理为例，技能不是一句“请阅读输入并编写需求文档”就结束，而是拆成一串有文件产出的步骤。
先清点输入，确认哪些文件可用、哪些转换件还留有待核对项。然后只做事实提取，每条事实带来源，不推测。接着生成需求骨架，能根据事实填写的就填，不能填的留空。
下一步最关键：AI 把自己补出来的解释、仍然不确定的问题全部列成清单。到这里必须停下来，由工程师逐条确认。没有确认完，不能装配正式需求文档。
确认之后，AI 再把结果装配进模板，并检查骨架里的留空项是否都有去处：已经定义、经假设确认，或者明确列入待解决问题。不能因为最后文档看起来完整，就把中间的空白悄悄丢掉。
这些工作文件可以随阶段分支提交，评审者看得到需求是怎样形成的，而不只是看到一份最终稿。
设计和修改类工作还有另一道闸：方案必须得到明确批准才能实施。假设清单的回答、其他话题的回复、沉默，都不算批准。人因此可以把精力放在小清单和关键决策上，不必每次都从几百行最终稿里寻找 AI 可能猜错的地方。
反馈写下来了，还要回到技能里
每个技能目录下都可以有一份反馈记录。执行中被用户纠正时，把“问题 + 纠正”追加进去；下次修改技能前，先回读这些问题，再把需要固化的内容写回技能规则。
有一次代码生成后，连续几轮增量构建都显示没有告警。后来一次全量重建，却暴露出已有代码里的多条告警。原因并不复杂：没有重新编译的文件，旧告警不会再次出现，增量构建造成了“全部干净”的假象。
这个问题被记下后，规则随之改变：只有全量构建才能作为“零告警”的依据，增量结果必须明确标注。
这件事也让我看到，收集反馈只是第一步。若纠正没有进入下一次执行时会读到的规则或自查清单，同类问题仍然可能复发。技能变聪明不是靠文件越来越厚，而是靠纠正真正改变下一次行为。
反馈记录里就有过同类错误再次出现的实例，原因正是前次教训没有进入起草时的自查清单。记录、回读、回填，缺一环都可能让反馈停在档案里。
当然，也不是每次纠正都要变成通用规则。先要分清这是当前项目的特例，还是其他项目也会遇到的共性问题，否则技能很快又会被例外塞满。
技能的边界
我现在会刻意给每个技能写清四样东西：输入是什么，产出是什么，什么时候必须停止，哪里需要人接手。
旧体系曾有一个几百行的技能，试图扫描所有交付物状态后告诉团队下一步该做什么。自动化程度看起来很高，实际却要处理大量上下文，还依赖各种状态被及时维护。现在改成 AI 按工程师的指示完成具体任务，阶段顺序仍由人掌握。
技能不直接给出放行结论，也不应该成为一个从原始文档一路跑到发布的超级提示词。阶段越大，上下文越长，人工能介入的位置越晚，出了问题也越难定位。
阻塞也不是越多越好。只有后续工作确实依赖人的答案时才停下，否则每个步骤都等待确认，交互带宽又会被吃光。
设计和编码技能还有一条默认依赖：会调用知识库。技能负责告诉 AI 工作怎样推进，知识库提供系统架构和各模块的程序模式。两者不是一回事，也不能互相替代。
这些边界不是为了限制 AI 的使用范围，而是为了让每次执行都有可以检查、可以纠正、可以复用的过程。
踩坑与教训
如果你准备把团队流程拆成技能，我会建议先从一个阶段的一条短管道做起。先写清事实从哪里来、哪些内容不许猜、哪些问题必须停下来问，再考虑自动生成多少内容。
生成与检查可以分开，但不要因此宣称结果已经被独立证明；反馈可以留档，但规则是否修改仍然需要人判断；关键确认可以强制执行，普通建议则不必都做成阻塞点。
技能真正固化的不是一句“照我说的做”，而是一套下次还能重复执行的工作界面。
下一篇
技能解决了“怎样做”，但还有一类知识无法在每个技能里临时重写：我们为什么习惯这样分层，为什么这些接口这样约定，为什么某种模块模式在过去项目里更可靠。
下一篇讲知识库：怎样把成熟项目里的经验变成每个新项目都会参考的默认输入。
