Appearance
Skill 成长与二次定制
这份文件解决一个问题：拿到本资料包里的 host-computer-dev Skill 以后，怎么把它慢慢改成适合你自己行业、项目、设备和交付习惯的 Skill。
本资料提供的 Skill 是一个起点，不是终点。它来自一套 C# WPF/WinForms 上位机开发经验，默认适合串口/TCP、协议解析、WPF 界面、数据保存、日志、回归验收这类项目。但每个人面对的设备、行业、客户要求、公司规范都不一样，后续一定要结合自己的工作继续完善。
1. 最重要的经验：Skill 是提效工具，不是固定枷锁
使用 Skill 最重要的一条经验是：Skill 可能提高效率，也可能降低效率。
如果 Skill 写得太死、流程太僵化，就会出现一个问题：明明只是改一个很简单的功能，本来 1 分钟可以改完，但一调用 Skill，它先走完整分析、路由、模板、质量门，反而花 5 分钟。
所以不要把 Skill 理解成“所有任务都必须调用的流程”。它更像一套可选工具：
text
复杂任务用 Skill 稳住流程。
简单任务直接快速处理。
高风险任务必须走质量门。
低风险小改不要被重流程拖慢。1.1 什么时候应该调用 Skill
适合调用 Skill：
- 需求不清楚，需要先拆需求。
- 新增一个完整页面、完整功能或完整流程。
- 涉及串口、TCP、协议、CRC、粘包半包。
- 涉及数据库、文件保存、日志、报警、配置。
- Bug 根因不明确，需要先调查。
- 涉及多文件修改，担心改 A 坏 B。
- 涉及真实设备、线程、高频采集、长时间运行。
- 需要生成回归清单、验收说明或交付文档。
1.2 什么时候可以不调用完整 Skill
可以直接让 AI 快速处理：
- 改一个按钮文字。
- 改一个标题、标签、提示语。
- 调整一个简单样式。
- 修一个明确的拼写错误。
- 修一个很明确的编译错误。
- 改一个局部变量名或字段显示名。
- 用户已经明确指出文件、位置和改法。
这类任务可以直接说：
text
这是一个低风险小改，不需要走完整 Skill 流程。
请只做最小修改，改完告诉我改了哪里和怎么验证。1.3 Skill 二次定制的核心目标
二次定制不是把流程越写越长，而是让 Skill 更会判断任务大小。
好的 Skill 应该能分流：
| 任务类型 | 建议处理方式 |
|---|---|
| 简单文字、样式、小编译错误 | 直接最小修改 |
| 局部功能调整 | 简短影响分析 + 最小修改 |
| 普通功能新增 | 走对应 Skill，但不要过度文档化 |
| 通信、数据库、线程、真实设备 | 走完整质量门和回归 |
| 根因不明确的 Bug | 先调查，再修复 |
| 正式交付 | 需求、实现、测试、验收都要完整 |
如果你发现某个 Skill 经常把小事办复杂，就应该把这条经验写进 Skill：
text
遇到低风险小改时，不要启动完整流程。
先判断是否可以直接最小修改。
只有涉及多文件、高风险、需求不清、通信、数据库、线程、真实设备、交付验收时，才进入完整流程。2. 先理解 Skill 是什么
在本资料里，Skill 可以理解成“让 AI 按固定工作方式办事的一套说明书”。
它一般包含：
- 角色分工：谁负责需求，谁负责设计，谁负责修 Bug，谁负责回归。
- 工作流程：先分析什么，再设计什么，什么时候才能写代码。
- 输入模板：用户要给 AI 哪些信息。
- 输出模板：AI 必须输出哪些内容。
- 质量门：哪些情况必须先备份、先确认、先测试。
- 经验规则：你不想每次都重新解释给 AI 的习惯和注意事项。
- 示例：让 AI 知道“正确输出大概长什么样”。
对用户来说，Skill 的价值不是“多一个文件夹”，也不是让所有任务都变成重流程，而是减少重复沟通，让 AI 在该谨慎的时候谨慎、该快速的时候快速。
3. 为什么一定要二次定制
每个人做的上位机项目都不一样。
| 差异 | 示例 |
|---|---|
| 行业不同 | 电源测试、FPGA 调试、PLC 控制、温控采集、运动控制、产线工装 |
| 设备不同 | 串口仪表、TCP 设备、扫码枪、运动控制卡、电源、示波器 |
| 协议不同 | 自定义帧、Modbus、CAN、TCP 私有协议、ASCII 指令 |
| 界面习惯不同 | 工控深色 Dashboard、普通桌面软件、触摸屏、调试工具 |
| 数据要求不同 | CSV、Excel、SQLite、MySQL、BIN、PDF 报告导出 |
| 交付要求不同 | 内部自用、客户现场、产线使用、正式验收 |
| 公司环境不同 | 是否有加密软件、是否必须走 Git、是否限制外网 |
所以正确做法不是指望一套 Skill 永远适配所有项目，而是：
text
先用通用 Skill 起步
在真实项目里发现不顺手的地方
把反复出现的经验沉淀进去
最后形成自己的行业 Skill4. 不要一开始就大改
刚拿到资料包时，不建议马上重写 Skill。
先按原样使用 skills/host-computer-dev/ 处理 2-3 个真实任务：
- 整理一次需求。
- 设计一次页面。
- 修一次 Bug。
- 拆一次通信协议。
- 做一次回归清单。
这一步的目的不是追求完美，而是观察：
- 哪些地方输出稳定。
- 哪些地方问了无关问题。
- 哪些地方缺少你行业里的规则。
- 哪些地方修改范围太大。
- 哪些地方没有按你的交付习惯来。
- 哪些简单任务被它处理得太复杂。
先用，再改。没有真实使用记录，改出来的 Skill 很容易变成空话。
5. 一套通用的成长流程
推荐按下面 6 步做。
第一步：保存原版
先保留一份原始版本，后面改乱了还能回退。
可以这样做：
text
skills/host-computer-dev-original/
skills/host-computer-dev/也可以用 Git / GitHub / Gitee 管理版本。
如果你已经使用本资料包里的备份流程，也可以在改 Skill 前先做一次本地快照。
第二步：直接用于真实任务
不要拿假题目测试太久。Skill 的问题通常只有在真实项目里才会暴露。
建议从低风险任务开始：
- 需求整理。
- UI 方案。
- 回归清单。
- 文档生成。
暂时不要一上来就让它直接改大量代码、改数据库、改真实设备控制逻辑。
第三步：记录卡点
每次觉得 AI 不顺手时，不要只记录“AI 不好用”，要记录具体卡点。
| 卡点 | 应该记录什么 |
|---|---|
| 问题问偏了 | 它问了什么，哪些问题对你的项目没必要 |
| 输出太泛 | 你希望它多输出哪些字段、表格或结论 |
| 改动太大 | 它多改了哪些文件，正确范围应该是什么 |
| 流程太重 | 原本应该 1 分钟的小改，被 Skill 处理成 5 分钟的大流程 |
| 忽略行业规则 | 哪条行业规则它没考虑 |
| 忽略公司习惯 | 例如命名、目录、日志、报告格式 |
| 验收不够 | 哪些场景没有测到 |
| 文件被改坏 | 是否缺少备份、编码检查、读回检查 |
建议把这些记录到：
text
31-度量复盘与经验沉淀.md记录格式可以很简单：
text
日期：
任务：
AI 原输出问题：
我希望它以后怎么做：
是否需要写进 Skill：
应该写到哪个文件：第四步：只沉淀反复出现的问题
不是所有问题都要写进 Skill。
适合写进去：
- 每个项目都会遇到的规则。
- 多次返工后总结出来的检查项。
- 行业里固定的术语、设备、协议习惯。
- 你明确不希望 AI 再犯的错误。
- 你希望 AI 每次都按固定格式输出的内容。
不适合写进去：
- 只出现一次的临时需求。
- 某个客户的敏感信息。
- 没验证过的猜测。
- 过细、过死、经常变化的实现细节。
- “要专业”“要稳定”这种没有执行标准的空话。
判断标准很简单：
text
如果以后大概率还会用到，就沉淀。
如果只是这一次项目特有，就放在项目文档里，不写进通用 Skill。第五步：一次只改一个小地方
不要一次性重写整个 Skill。
推荐一次只改一个文件，例如：
- 只改
03-ui-designer/SKILL.md。 - 只补
_shared/domain-dictionary.md。 - 只加一个协议模板。
- 只改一个回归测试清单。
改完后马上用一个真实任务测试：
- 输出是否更清楚。
- 是否减少了重复沟通。
- 是否没有把流程变得更重。
- 是否没有影响其他任务。
如果有效，再继续改下一块。
第六步：形成自己的行业版本
当你的补充越来越多，就可以从通用 Skill 派生出自己的版本。
例如：
text
skills/my-power-test-dev/
skills/my-fpga-debug-dev/
skills/my-plc-tool-dev/
skills/my-lab-acquisition-dev/
skills/my-production-tool-dev/新 Skill 不需要从零写。可以复制 host-computer-dev，再逐步改：
- 改 Skill 名称和描述。
- 删除你很少用的子 Skill。
- 增加你的行业词典。
- 增加你的协议模板。
- 增加你的 UI 规则。
- 增加你的回归验收清单。
- 增加你的公司交付文档格式。
6. 哪些文件最适合改
如果你不知道从哪里开始，优先看下面这些位置。
| 你想改什么 | 建议修改位置 |
|---|---|
| 行业术语 | skills/host-computer-dev/_shared/domain-dictionary.md |
| 通用工程规则 | skills/host-computer-dev/_shared/engineering-rules.md |
| 输入输出格式 | skills/host-computer-dev/_shared/skill-io-templates.md |
| WPF/WinForms 界面习惯 | 03-ui-designer/SKILL.md、_shared/domain-notes/wpf-notes.md |
| 串口/TCP 经验 | 05-communication-expert/SKILL.md、_shared/domain-notes/serial-communication-notes.md |
| 协议帧规则 | 04-protocol-designer/SKILL.md |
| 数据保存规则 | 06-data-storage-designer/SKILL.md |
| Bug 调查习惯 | 09-bug-investigator/SKILL.md |
| 最小修复习惯 | 10-bug-fixer/SKILL.md |
| 回归测试要求 | 11-regression-guardian/SKILL.md、12-test-designer/SKILL.md |
| 交付文档格式 | 15-document-generator/SKILL.md |
7. 常见定制方向
7.1 行业词典
把你行业里的固定术语写进去。
例如：
text
ADC：模数转换通道。
FPGA：现场可编程门阵列。
抽采：按比例降低采样频率。
CRC 错误：报文校验失败。
长稳测试：连续运行稳定性测试。适合放到：
text
_shared/domain-dictionary.md这样 AI 后续处理需求、日志、协议时，不容易把行业词理解错。
7.2 协议模板
如果你经常处理类似协议，可以沉淀：
- 帧头格式。
- 长度字段规则。
- 命令字规则。
- CRC 规则。
- 粘包半包处理。
- 错误帧处理。
- 测试报文样例。
适合放到：
text
04-protocol-designer/TEMPLATE.md
_shared/protocol-notes.md7.3 UI 规则
如果你经常做工控界面，可以沉淀：
- 主界面优先 Dashboard。
- 高频操作放主界面。
- 低频配置放二级窗口。
- 日志区域要保留。
- 关键状态要有颜色和文字双提示。
- 图表不能显示异常大数值。
- 中文标签要避免乱码。
适合放到：
text
03-ui-designer/SKILL.md
_shared/ui-rules.md7.4 回归清单
把你最容易漏测的点固定下来。
例如：
- 连接/断开。
- 断线重连。
- CRC 错误。
- 粘包半包。
- 停止采集后文件释放。
- 保存路径无权限。
- 长时间运行图表不卡顿。
- 改完后旧功能还能正常用。
适合放到：
text
11-regression-guardian/TEMPLATE.md
_shared/test-checklist.md7.5 文件安全规则
如果你经常遇到 AI 改乱文件、乱码、空文件、加密软件影响读取，可以把下面规则固定进去：
- 修改前必须备份。
- 修改前确认编码。
- 重要文件先改工作副本。
- 改完后读回检查。
- 编译通过后再认为修改完成。
- 有加密软件时，编辑阶段使用
.work这类不会被加密的后缀。
适合放到：
text
_shared/engineering-rules.md
07-加密软件环境下的AI开发注意事项.md
12-AI开发质量门.md7.6 快慢分流规则
如果你的 Skill 经常把小任务做复杂，可以增加一条快慢分流规则。
适合写进 00-project-orchestrator/SKILL.md 或 _shared/engineering-rules.md：
text
任务开始前，先判断任务规模和风险。
如果是低风险小改，例如文案、标签、简单样式、明确编译错误，只做最小修改，不启动完整需求分析、架构设计和回归流程。
如果涉及通信、数据库、线程、真实设备、多文件修改、需求不清或正式交付，再进入完整 Skill 流程。这样 Skill 既能保留复杂任务的稳定性，也不会拖慢简单任务。
8. 一条经验从项目进入 Skill 的例子
假设你做了一个电源测试上位机，项目里反复出现一个问题：AI 每次都忘记保存原始通信报文，只保存解析后的数据。
不要只在聊天里提醒一次。可以按下面方式沉淀。
8.1 先记录
写到 31-度量复盘与经验沉淀.md：
text
问题：
AI 设计数据保存时只保存了解析后的电压、电流，没有保存 RX/TX 原始十六进制报文。
影响：
现场出现通信异常时，无法回放和排查原始数据。
以后规则：
凡是涉及串口/TCP 通信的上位机，必须保留原始报文日志。解析后的业务数据和原始报文不能互相替代。8.2 再写入共享规则
写到 _shared/engineering-rules.md 或通信相关说明：
text
涉及串口/TCP 通信时，必须保存 RX/TX 原始十六进制报文日志。
解析后的业务数据不能替代原始报文日志。
如果用户没有明确日志格式，先建议至少包含时间、方向、端口/连接、原始十六进制、解析结果、错误信息。8.3 最后补到模板
在通信或测试模板里补一项：
text
通信日志验证：
- 是否记录 RX 原始报文
- 是否记录 TX 原始报文
- 是否能根据时间线追踪一次完整命令
- CRC 错误、超时、断线是否有日志这样以后 AI 设计通信模块、修通信 Bug、做回归清单时，就更容易自动考虑这个要求。
9. 迁移到其他 AI 工具
本资料里的 Skill 默认按 Codex 使用方式组织，但它不是只能给 Codex 用。
如果你用 Cursor、Claude Code、Trae、CodeBuddy/WorkBuddy、CodeGeeX 或其他 AI 编程工具，可以让当前工具读取：
text
skills/host-computer-dev/
60-host-computer-dev-Skill说明.md
61-Skill成长与二次定制.md然后让它转换成当前工具支持的形式。
常见转换目标包括：
| 工具类型 | 可以转换成什么 |
|---|---|
| Codex | Skill 目录、全局 Skill、项目 Skill |
| Cursor | Project Rules、User Rules、项目规则文件 |
| Claude Code | 项目说明、命令、Agent/子任务说明 |
| CodeBuddy/WorkBuddy | 快捷方式、专家角色、项目规则 |
| 普通 ChatGPT | 可复制的提示词、任务模板、检查清单 |
你可以直接这样问 AI：
text
请读取这个资料包里的 skills/host-computer-dev 目录。
我现在使用的工具是：【填写 Codex / Cursor / Claude Code / Trae / CodeBuddy / WorkBuddy / CodeGeeX】。
请帮我把这套 Skill 转换成当前工具可用的形式。
要求：
1. 保留需求分析、系统设计、UI 设计、通信、数据保存、代码修改、Bug 调查、回归测试、文档交付这些核心流程。
2. 不要照搬所有文件，先提炼成当前工具最容易加载和执行的规则。
3. 如果当前工具支持项目规则，就生成项目规则。
4. 如果当前工具支持快捷指令，就生成常用快捷指令。
5. 如果当前工具支持专家角色，就拆成几个常用专家。
6. 输出安装位置、文件名、使用方式和一个测试任务。核心思路是：不要死记某一种工具的格式。让 AI 先理解这套 Skill 的流程，再按你手上的工具重新包装。
10. 判断一条规则写得好不好
好的 Skill 规则应该能被执行。
不好的写法：
text
代码要专业。
界面要好看。
修 Bug 要稳定。更好的写法：
text
修改已有功能前，必须先输出影响范围：涉及文件、可能影响的功能、最小修改方案、回归验证点。不好的写法：
text
所有上位机都必须有 3 个 ADC 图表和 4 个电源图表。更好的写法：
text
如果是多通道采集类上位机，优先考虑 Dashboard 同屏显示关键曲线、实时状态和日志；具体通道数量按项目需求确认。写规则时尽量包含：
- 触发条件：什么情况下用这条规则。
- 动作：AI 必须做什么。
- 输出：结果里必须包含什么。
- 禁止项：不能做什么。
- 验证：怎么判断做完。
- 成本：这条规则会不会让小任务变慢。
如果一条规则只对复杂任务有用，就写清楚触发条件，不要让它影响所有任务。
11. 每次项目结束后怎么更新 Skill
项目结束后，不要只交付代码。建议花 10-20 分钟做一次复盘。
问自己：
- 哪些需求以后还会遇到？
- 哪些 Bug 以后还可能出现？
- 哪些提示词这次特别有效？
- 哪些检查项漏掉了问题？
- 哪些行业规则应该固定下来？
- 哪些流程太重，可以简化？
- 哪些流程太轻，导致返工？
- 哪些文件或模板应该补充示例？
- 哪些简单任务被 Skill 拖慢了，应该增加快速通道？
然后更新：
text
31-度量复盘与经验沉淀.md
skills/host-computer-dev/_shared/
相关子 Skill 的 SKILL.md / TEMPLATE.md / EXAMPLE.md建议一个项目最多沉淀 3-5 条最有价值的经验。不要把所有细节都塞进 Skill。
12. 让 AI 帮你做二次定制
可以把下面这段复制给 AI。
text
请帮我基于当前资料包里的 host-computer-dev Skill，设计一个适合我自己工作的二次定制方案。
我的行业/项目类型：
【例如：FPGA 数据采集上位机 / 电源测试上位机 / PLC 调试工具】
我常见的设备：
【填写】
我常见的通信方式：
【串口 / TCP / Modbus / CAN / 自定义协议】
我常见的界面风格：
【Dashboard / 参数配置 / 调试工具 / 触摸屏 / 产线工装】
我常见的数据保存方式：
【CSV / Excel / SQLite / MySQL / 报告导出】
我常见的交付要求：
【验收、日志、报告、长稳测试、客户现场调试等】
我觉得现有 Skill 不顺手的地方：
1.
2.
3.
请输出：
1. 哪些规则应该保留。
2. 哪些规则应该修改。
3. 应该新增哪些行业规则。
4. 应该新增哪些模板。
5. 建议修改哪些 SKILL.md、TEMPLATE.md、EXAMPLE.md。
6. 分三步给我一个 Skill 二次定制计划。
7. 给我一个最小测试任务，用来验证修改后的 Skill 是否真的更好用。
8. 帮我设计一个快慢分流规则：哪些任务走完整 Skill，哪些任务直接最小修改。13. 不建议的做法
- 一开始就把 Skill 改得很复杂。
- 把未经验证的想法写进 Skill。
- 把客户敏感信息写进 Skill。
- 每个项目都重新写一套 Skill。
- 修改 Skill 后不测试。
- 只加规则，不加示例。
- 只写“要稳定”“要专业”这类空话。
- 把某个项目的通道数、页面数、客户字段写成所有项目都必须遵守。
- 把所有小改都强制走完整流程，导致效率下降。
- 为了“规范”而牺牲明显可以快速完成的小任务。
14. 最短说明
先记住：Skill 是提效工具，不是所有任务都必须调用。
简单小改可以直接最小修改。
复杂任务、高风险任务、交付任务再走完整 Skill。
再使用本资料提供的 host-computer-dev。
用几次之后，记录哪里不顺手。
把反复出现的行业规则、开发习惯、Bug、验收项和快慢分流规则补进 Skill。
改一次，测一次，别一次改太多。
最后形成适合你自己行业和工作方式的 Skill。
15. 可参考资料
以下资料可以作为理解 Skill/规则文件的参考：
- OpenAI Codex Skills：
https://developers.openai.com/codex/skills - OpenAI Codex 可复用 Skills 案例：
https://developers.openai.com/codex/use-cases/reusable-codex-skills - OpenAI Codex Best Practices：
https://developers.openai.com/codex/learn/best-practices - OpenAI Codex Customization：
https://developers.openai.com/codex/concepts/customization - Cursor Rules：
https://cursor.com/docs/rules
这些资料的共同思路是：把反复出现的工作流、规则、示例和检查项沉淀下来，让 AI 在后续任务中少走弯路。