*——技能：把开发流程拆成 AI 能执行的步骤*

> 这是《嵌入式 AI 落地手记》的第六篇。前面讲了工程底座，这篇讲 AI 具体怎样工作：生成与检查怎样分工，人工确认放在哪里，技能又怎样根据使用反馈继续修改。

## 我们以为需求明确了，AI 却先问了起来

新流程在一个真实项目里开始试用时，我们起初认为需求已经基本明确，甚至已经开始讨论设计问题。

结果文档转换和整理阶段先卡住了：有的需求描述不清，有的内容在两份输入里互相矛盾，还有一些硬件机制，仅凭现有文件不知道应该怎样使用。AI 没有顺着“基本明确”的判断往下写，而是一直追问，直到这些问题有了着落。

这次暴露的不是谁粗心，而是大家对“需求明确”的标准并不一样。技能把一部分原本依赖个人经验的检查标准变成了固定步骤，新加入流程的人也会走到这些步骤上。

对我来说，技能的价值首先不是生成得有多快，而是这种标准能够被执行和继承。

## 模板管产出，技能管过程

第一版仓库里有文档模板，也有检查技能，但生成侧基本是空的。改版后，每个主要阶段逐渐形成生成与检查两类技能：

| 阶段 | 生成辅助 | 检查辅助 |
|---|---|---|
| 输入准备 | 原始文档转换 | 转换结果的人工抽检 |
| 需求 | 需求整理与起草 | 需求完备性与质量检查 |
| 设计 | 设计起草 | 设计完备性、依赖与承接检查 |
| 编码 | 按模块起草代码 | 静态检查，以及架构、模块、流程三个维度的评审 |
| 测试用例 | 测试用例整理 | 用例覆盖与质量检查 |

生成技能负责归集、提取、结构化和起草；检查技能负责发现遗漏、重复、漂移和不一致。它们不会互相调用，生成完成后由人触发检查，检查结果也交给人处置。

文档模板也不是单纯的排版格式。栏目、功能四件套、适用性判定和内容边界，本身就沉淀了过去对“合格交付物”的理解；它们既约束最终产物，也把这部分知识传给 AI。

所以，生成与检查分开，是为了让两类工作使用不同判据，不等于自动形成了独立验证。最后的评审和放行仍然由人完成。

## 一个技能怎样推进工作

以需求整理为例，技能不是一句“请阅读输入并编写需求文档”就结束，而是拆成一串有文件产出的步骤。

先清点输入，确认哪些文件可用、哪些转换件还留有待核对项。然后只做事实提取，每条事实带来源，不推测。接着生成需求骨架，能根据事实填写的就填，不能填的留空。

下一步最关键：AI 把自己补出来的解释、仍然不确定的问题全部列成清单。到这里必须停下来，由工程师逐条确认。没有确认完，不能装配正式需求文档。

确认之后，AI 再把结果装配进模板，并检查骨架里的留空项是否都有去处：已经定义、经假设确认，或者明确列入待解决问题。不能因为最后文档看起来完整，就把中间的空白悄悄丢掉。

这些工作文件可以随阶段分支提交，评审者看得到需求是怎样形成的，而不只是看到一份最终稿。

设计和修改类工作还有另一道闸：方案必须得到明确批准才能实施。假设清单的回答、其他话题的回复、沉默，都不算批准。人因此可以把精力放在小清单和关键决策上，不必每次都从几百行最终稿里寻找 AI 可能猜错的地方。

## 反馈写下来了，还要回到技能里

每个技能目录下都可以有一份反馈记录。执行中被用户纠正时，把“问题 + 纠正”追加进去；下次修改技能前，先回读这些问题，再把需要固化的内容写回技能规则。

有一次代码生成后，连续几轮增量构建都显示没有告警。后来一次全量重建，却暴露出已有代码里的多条告警。原因并不复杂：没有重新编译的文件，旧告警不会再次出现，增量构建造成了“全部干净”的假象。

这个问题被记下后，规则随之改变：只有全量构建才能作为“零告警”的依据，增量结果必须明确标注。

这件事也让我看到，收集反馈只是第一步。若纠正没有进入下一次执行时会读到的规则或自查清单，同类问题仍然可能复发。技能变聪明不是靠文件越来越厚，而是靠纠正真正改变下一次行为。

反馈记录里就有过同类错误再次出现的实例，原因正是前次教训没有进入起草时的自查清单。记录、回读、回填，缺一环都可能让反馈停在档案里。

当然，也不是每次纠正都要变成通用规则。先要分清这是当前项目的特例，还是其他项目也会遇到的共性问题，否则技能很快又会被例外塞满。

## 技能的边界

我现在会刻意给每个技能写清四样东西：输入是什么，产出是什么，什么时候必须停止，哪里需要人接手。

旧体系曾有一个几百行的技能，试图扫描所有交付物状态后告诉团队下一步该做什么。自动化程度看起来很高，实际却要处理大量上下文，还依赖各种状态被及时维护。现在改成 AI 按工程师的指示完成具体任务，阶段顺序仍由人掌握。

技能不直接给出放行结论，也不应该成为一个从原始文档一路跑到发布的超级提示词。阶段越大，上下文越长，人工能介入的位置越晚，出了问题也越难定位。

阻塞也不是越多越好。只有后续工作确实依赖人的答案时才停下，否则每个步骤都等待确认，交互带宽又会被吃光。

设计和编码技能还有一条默认依赖：会调用知识库。技能负责告诉 AI 工作怎样推进，知识库提供系统架构和各模块的程序模式。两者不是一回事，也不能互相替代。

这些边界不是为了限制 AI 的使用范围，而是为了让每次执行都有可以检查、可以纠正、可以复用的过程。

## 踩坑与教训

如果你准备把团队流程拆成技能，我会建议先从一个阶段的一条短管道做起。先写清事实从哪里来、哪些内容不许猜、哪些问题必须停下来问，再考虑自动生成多少内容。

生成与检查可以分开，但不要因此宣称结果已经被独立证明；反馈可以留档，但规则是否修改仍然需要人判断；关键确认可以强制执行，普通建议则不必都做成阻塞点。

技能真正固化的不是一句“照我说的做”，而是一套下次还能重复执行的工作界面。

## 下一篇

技能解决了“怎样做”，但还有一类知识无法在每个技能里临时重写：我们为什么习惯这样分层，为什么这些接口这样约定，为什么某种模块模式在过去项目里更可靠。

下一篇讲知识库：怎样把成熟项目里的经验变成每个新项目都会参考的默认输入。

这是《嵌入式 AI 落地手记》的第六篇。前面讲了工程底座，这篇讲 AI 具体怎样工作：生成与检查怎样分工，人工确认放在哪里，技能又怎样根据使用反馈继续修改。

06 · 我把开发流程拆成了 AI 能执行的技能

人工智能

开发工具

将开发流程拆解为AI可执行的生成与检查技能，通过人工确认关键节点、反馈回填优化规则，明确输入产出及边界，实现流程标准化与问题精准定位，避免遗漏并提升复用效率。

腾讯云双十一大促

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

06 · 我把开发流程拆成了 AI 能执行的技能-腾讯云开发者社区-腾讯云

06 · 我把开发流程拆成了 AI 能执行的技能

06 · 我把开发流程拆成了 AI 能执行的技能

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐