如何和 AI 共创一个可交付 Skill
前言
如果只用一句话概括这次经历，听起来其实很简单：
我跟 AI 一起做了一个
skill-cosmic。
但如果真的把整个过程重新走一遍，我会觉得，这件事远不只是“做了一个 skill”。
它更像是一次非常完整的 AI 协作开发实践。
最后产出的成果，是一个用于生成和校验 COSMIC 功能点拆分表的技能仓库。它既可以根据需求清单生成拆分表，也可以对已有拆分表做送审前校验。
可真正让我想把这件事写下来的，不只是这个结果，而是这次我是怎么和 AI 一起，把它一步一步做出来的。
skill-cosmic 从素材到交付的总览图
一开始，我面对的不是一个项目，而是一堆素材
最开始手头的东西，其实很像很多真实项目的起点：
- 有模板；
- 有 Prompt；
- 有经验稿；
- 有已经在真实项目里验证过的脚本；
- 也有一些能参考、但并不能直接交付的文件。
这些东西单看都很有用，但放在一起，并不会自动变成一个真正可复用的 skill。
我很清楚，如果这时候直接让 AI “帮我做一个技能”，它大概率也能很快产出一些像样的结果。问题是，那个结果很可能只是把现有材料重新拼装一遍，而不是做出一个真正稳定、可维护、可交付的能力。
所以我没有让 AI 一上来就写代码。
我做的第一件事，是先让它和我一起把问题想清楚。
我先让 AI 参与理解，而不是直接参与输出
这是这次我感触最深的一点。
以前很多人用 AI 的方式，往往是一上来就提要求，然后期待它直接给出完整答案。但这次我越来越确认，真正好用的方式，是先让 AI 参与“理解问题”。
也就是说，我先和它一起确认：
- 这个 skill 到底要解决什么问题；
- 它的职责边界是什么；
- 哪些能力是必须做的；
- 哪些材料只是参考，不应该被原样带进最终交付。
这些问题没想清楚之前，越快动手，反而越容易把东西做散。
而一旦这些边界被说清楚，我会明显感觉到，后面的协作稳定了很多。AI 不再像是在“猜我想要什么”，而更像是真的进入了同一个项目上下文。
AI 很适合陪我做结构整理
接下来，我们一起做的事，并不是立刻写功能，而是先重新组织材料。
这一步特别像在搭框架：
- 哪些内容应该进入
SKILL.md； - 哪些规则更适合下沉到
references/； - 哪些事情应该交给脚本；
- 哪些参数适合沉到
config.yaml； - 哪些约束应该变成回归测试。
这一步看似不“炫技”，但其实决定了后面一切会不会稳。
因为如果一开始结构没立住，后面再怎么补功能，都只是在一堆松散材料上继续叠东西。
而 AI 在这里给我的帮助非常明显：
它不一定替我决定方向，但它特别擅长配合我，把已经想清楚的方向快速收拢成结构。
这让我越来越认同一件事：在协作开发里，AI 很强的一个角色，不是“替我做决定”，而是“帮我把决定稳定落下来”。
skill-cosmic 的结构整理图
spec 和 plan，让这次协作开始有了工程感
这次我没有跳过 spec 和 implementation plan。
说实话，很多小项目都会有一种冲动：先写出来再说。到了这个阶段，spec 和 plan 很容易被认为是多余的。
但这次我反而觉得，正是因为没有跳过这两步，整个 AI 协作过程才真正有了工程感。
因为一旦 spec 写出来，很多原本模糊的地方就必须被说清楚。
一旦 plan 写出来，后面的实现路径就不再是随缘推进，而是有了明确顺序和锚点。
这件事对 AI 尤其重要。
AI 并不是天然知道什么该先做、什么该后做。如果没有设计文档和计划，它很容易在长对话里不断局部最优，甚至反复回到已经讨论过的问题。
而一旦有了 spec 和 plan，它像是终于拿到了一张地图。
从那一刻开始，我才真正感觉到，这次不是“和 AI 聊着做点东西”，而是在“和 AI 一起推进一个工程”。
真正把问题逼出来的，是那张真实需求表
如果说前面更多是在搭结构，那么后面真正让我觉得这个 skill 开始“活起来”的，是我们拿真实需求表去跑的时候。
因为只要一进入真实数据环境，问题就立刻变得非常具体，而且特别诚实。
之前看起来没问题的逻辑，一上真实表就会暴露出一连串细节问题：
- 主场景识别不准；
- 申请和审批混在一起；
- 子过程描述出现重复动作词；
- 角色和触发事件主语不一致；
- 真实表头和模板列名不兼容；
- 四级功能结构读不进去。
这些问题如果只盯着模板，很难真正意识到；但只要一跑真实数据，就再也绕不过去。
而这恰恰是我觉得 AI 最有价值的时候。
不是让它一次生成一个“看起来完整”的答案，而是让它跟我一起进入一种更像工程的循环：
发现问题，
总结问题，
修规则，
补测试，
再验证。
我很喜欢这种状态。因为在这个过程中，AI 不再只是一个“回答器”，而更像一个随时在线的搭档。我不需要每次都从头解释全部上下文，它能持续接住前面的判断，并把这些判断同步到代码、测试和文档里。
真实需求驱动下的问题修正闭环图
这次协作让我更清楚，人和 AI 的分工应该是什么
做到中段的时候，我越来越清楚一件事：
边界判断，还是得由我来做。
但一旦边界明确了，AI 特别适合帮我把这条边界快速铺开、落实、校准。
比如这次里就有一些非常典型的判断题：
- “申请”到底算“审批”还是“发起”；
- 目标行数要不要强行凑；
- 需求名称应该预配置还是运行时输入；
- 接收者要不要单独配置。
这些问题，本质上都不是代码问题，而是产品和规则问题。
这部分我不能完全交给 AI，因为这决定了 skill-cosmic 最后到底长成什么样。
但一旦我拍板了方向，AI 就能很快帮我把这个判断变成：
- 脚本逻辑；
- 测试用例；
- 错误提示；
- README 文档；
- skill 规则；
- CLI 参数。
我越来越认同这种分工：
- 我负责方向、边界和取舍；
- AI 负责整理、实现、同步和收敛。
这比“AI 全做”更真实，也比“我全做，AI 只补代码”更高效。
连“最后 20% 的整理活”，AI 都特别适合参与
很多项目都会遇到同一个问题：
功能做完了，但离真正能交付，还差一堆收尾工作。
比如：
- 清理目录；
- 保留最终资产；
- 写 README；
- 优化手册样式；
- 适配 GitLab 渲染；
- 初始化仓库；
- 提交 git；
- 推送远端。
这些事不难，但很琐碎，也特别容易拖。
而这次我很明显地感受到，AI 在这里也特别好用。它不只是陪我做核心功能，连这些“最后 20% 的整理活”也能一起推进掉。
而往往就是这 20%，决定了一个成果到底只是“我电脑里一套能跑的东西”，还是“一个别人真的能拿去用的仓库”。
最后我们把 skill-cosmic 做成了一个完整项目：
- 有正式目录结构；
- 有生成脚本；
- 有校验脚本；
- 有回归测试；
- 有 README；
- 有 Git 仓库；
- 有 GitLab 远端。
到那个时候，我才真的觉得，这件事做完了。
这次之后，我对 AI 协作开发的理解更具体了
以前我也会说“AI 是协作者”，但这次之后，这句话在我心里变得具体了很多。
我现在更愿意这样理解：
AI 最适合的角色，不是替我一次性把事情做完的人，而是陪我把一件事从混乱做到完整的搭档。
这里的“完整”很重要。
不是只写出一段代码，
不是只生成一个脚本，
不是只回答一个问题，
而是完整地参与到：
- 理解问题；
- 梳理结构；
- 抽象规则；
- 实现逻辑；
- 验证结果；
- 整理文档；
- 完成交付；
这个闭环里。
而我觉得，真正有价值的，也正是这个闭环。
最后回头看，我们一起完成了两件事
表面上，我们完成的是一个 skill-cosmic 仓库。
但更深一层，我觉得我们一起完成的，其实还有另一件事：
我们验证了一种我自己越来越认可的 AI 协作开发方式。
这套方式不是：
“把需求扔给 AI，等它吐结果。”
而是：
先一起把问题想清楚，
再一起把结构搭起来，
再用真实数据逼问题，
再用测试锁规则，
最后把结果做成真正能交付的东西。
skill-cosmic 只是这次的项目成果。
但对我来说，更重要的是，我越来越知道以后该怎么和 AI 一起做项目了。
这可能才是这次协作里，最值得留下来的部分。
开源地址
仅内部使用：