最近我设计了一套“小红书AI概念图解Skill”负责图文生产，并把开源“Human Writing”改造成“个人化的写作Skill”负责写作选题和大纲的梳理。这两个项目最后都指向同一个结论：好的 Skill 不是一条更长的提示词，而是一套能够判断、暂停、确认、执行和验收的工作流。本文复盘其中六条可迁移的设计经验，以及真实测试过程中暴露的问题。

在系统学习AI相关知识、并开始去做自己有关AI内容账号的过程中，我越来越频繁地使用Chat GPT和Claude Code写文章、整理知识和制作配图。最开始，我只是通过提示词来引导AI达到我的目标，文章不像我的风格就补风格词，图片不统一就加视觉描述，流程跑偏就把步骤写得更长。但是我每次的输出结果依旧不够稳定，这导致我每次做相似内容的时候都要花大量时间做重复的工作。

后来我根据我的需求先后做了上面提到的两个不同的Skill。“小红书AI概念图解Skill”偏视觉生产，“个人化的写作Skill”偏长文写作。设计完以后，我发现我之前认为的Skill是更长的、可复用的Prompt的理解是片面且错误的。它们真正解决的是三个更基础的问题：AI应该先判断什么，什么时候必须停下来确认，什么样的结果才算完成。

我现在认为如果Prompt是一次任务的操作说明，Skill就像一个可复用的小型产品：有范围、输入、决策、异常处理和验收标准。值得封装的不是某次表现不错的指令，而是反复做同类任务时形成的判断方法。

第一条经验：先定义边界，再定义能力

设计 Skill 时，人很容易先写“它应该做什么”。实际使用中，更能决定稳定性的往往是“它不应该什么”。

我把“小红书AI概念图解Skill” 的解释范围限定在AI概念和AI应用，而不是通用的小红书文案生成器，它不能把未经核验的观点直接做成知识卡片。

“个人化的写作Skill”同样有明确边界：它服务 AI产品经理方向的专业写作，不虚构在职经历，不把课程案例改写成作者负责的真实项目，不靠段子、网络梗或娱乐化开场制造“活人感”。材料不足时，应缩短文章或指出缺口，而不是为了达到目标字数重复解释。

这些限制不是保守，而是在定义产品承诺。一个 Skill 如果同时写行业分析、小说、朋友圈和广告文案，看起来能力很强，实际上每次都要重猜作者、读者和事实标准。范围越宽，隐含决策越多，结果越难复用。

我现在在制作Skill前会先想清楚四个问题：这个 Skill 服务哪一类重复任务？默认读者是谁？哪些事实风险不能接受？能力不足时应该停在哪里？把这四个问题想清楚，往往比再增加二十条风格要求更有效。当然，如果你暂时还没想清楚可以和AI讨论以明确问题的答案。

第二条经验：在工作流中加入“向我确认”的要求，而不是单纯罗列执行步骤

普通提示词经常写成连续动作：分析、拟大纲、写正文、配图、检查。AI 会把它理解成一条应尽快跑完的流水线。只要前面误判，后面就会稳定地把错误做完整。

经过一段时间制作和使用Skill的经验，我在这两个Skill里都加入了“向我确认”的要求。“小红书AI概念图解Skill”采用五阶段流程。第一阶段诊断素材并提出选题、页数和大纲；第二阶段联网核验，完成逐页脚本和来源记录；第三阶段只做封面和一张代表性内页；第四阶段逐页生产；第五阶段统一质检。

“个人化的写作Skill”的确认更细。新任务先复述题目、读者、材料和预计交付；长文再经过研究、观点、大纲、章节、合稿和终稿确认。

前者里的“确认”是为了防止选题和视觉方向跑偏，后者里的“确认”是为了保护作者对观点和表达的所有权。这二者里“向我确认”的动作都是控制高成本返工的产品机制。

不过，“确认”也不是越多越好。“个人化的写作Skill”的端到端测试中，连续确认带来了等待和协作成本。用户有时已经明确“直接看全文”，如果系统仍然为同一阶段的读取、校验和保存重复询问，确认就从风险控制变成了流程负担。

因此，我后来更强调区分两类动作。改变选题、中心判断、读者或交付形式的实质动作需要确认。已确认范围内的格式检查、保存和机械校验，不必反复打断。

“向我确认”的价值不在于让流程显得严谨，而在于把人的判断放在最能降低返工的位置。

第三条经验：内容类Skill的所有观点都要经过验证

内容类Skill 最危险的能力，不是写得慢，而是把不确定内容写得像真的。

在“小红书AI概念图解Skill”里，AI概念、协议和产品能力都可能变化。用户文章只能视为编辑素材，不能自动成为已核验事实。产品能力优先查官方文档，研究概念优先查原始论文，关键断言尽量交叉验证。来源、断言、时间和适用范围要放在同一条记录里。

在“个人化的写作Skill”里，我保留了原项目“材料先于篇幅”的原则：计划写较长的现实题材文章时，需要有能够组成真实过程的具体材料。材料不足，先研究；研究后仍然不足，就缩短成可用短稿并指出关键缺口。目标字数不能成为虚构经历的理由。

我在使用“个人化的写作Skill”写Second Me使用体验这篇文章时，很好地验证了这一点。最初我提供的素材包括用户群体不清晰、Context 收集成本高、AI社交价值不明确等，但这些素材的论点过于分散，而且可验证性也不足。这导致我第一版的大纲和每一章的写作内容概述总是不如人意。

真正改变文章写作方向的，是我举了一个我在使用Second Me过程中的真实案例之后：AI数字分身在回答的时候，只考虑了回答的逻辑，没有考虑回答对象和语气。这段真实材料让文章从宽泛的产品评价，进入语境权限这一具体产品问题。

对内容Skill来说，最重要的不是让AI“更像专家”，而是让它始终知道：哪些是有论据直接支持的事实，哪些是作者的判断，哪些还只是待验证的推测。

第四条经验：主文件负责路由，复杂规则要模块化

随着我在不断修改过程中写进Skill的规则越来越多，导致Skill.md文件内容过长、也导致了我在调用Skill时响应时间变慢，上下文占用变长的问题。同时我修改一条规则还可能影响其他任务。

因此，两个 Skill 最终都采用了模块化结构。“小红书AI概念图解Skill”的主文件只保留触发范围、核心规则、工作流和异常处理；选题研究、内容架构、视觉系统、交付质检分别放进参考文件；内容包使用独立模板；图片数量、编号和比例交给脚本检查。

“个人化的写作Skill”也把作者画像、专业文章规则、现实题材边界、审稿规则和检查脚本分开，按任务逐步读取。这种拆分让主流程更容易理解，不同模块可以单独更新，也让自动检查与创作判断不再混在一起。

我把Skill的结构理解成五层：入口层决定什么时候触发；身份与范围层定义服务对象和边界；决策层规定何时判断、何时确认；执行层连接研究、写作、生图和排版工具；验收层检查事实、格式、文件和平台适配。如果把所有内容都写成一段提示词，这五层会纠缠在一起。模块化不是为了目录好看，而是为了让规则可以维护、替换和追踪。

第五条经验：最值得优先自动化的，可能不是生成

开始做Skill时，我最关注的是如何自动写正文、自动出图。做到后面才发现，更值得优先自动化的往往是选题诊断和质量控制。生成环节天然醒目，真正影响成品质量的问题，却经常发生在生成之前和交付之后。

小红书图解如果选题过宽，再好的视觉也救不了内容；脚本未经确认，逐页生产只会放大返工. 因此，把选题、事实映射、脚本确认和视觉试稿放在批量生成之前就显得尤为重要了。

“个人化的写作Skill”的测试则暴露了另一类问题。Second Me 文章进入最终发布整理阶段后， 参考资料的两位数编号出现了显示异常；第一次调整编号时，又遗漏了原始链接。最终只能重新设计参考资料格式，统一使用手动编号，并将完整网址作为独立信息保留。

我遇到的以上两个问题，不是观点、事实或文风问题，却会直接影响我的最终交付。内容生成完成，并不等于成品已经可以交付。编号、链接、图片位置、段落层级和版式兼容，同样属于内容质量的一部分。

第六条经验：工具不是架构目标，稳定完成任务才是

设计AI工作流时，很容易把调用外部服务或使用外工具当成先进程度的证明。但每增加一个渠道，也增加一段调用链路、一个故障点和一份维护成本。

如果平台已有可靠的搜索或生图能力，就优先使用，“小红书AI概念图解Skill”明确采用稳定的内置能力。使用的是 ChatGPT里的 Image 生图能力。视觉生产也需要分工。背景、科技主体和插画可以交给生图模型；中文标题、箭头、标签、页码和精确图解，应该尽量使用确定性排版。让模型直接生成整页中文，看似一步到位，实际会把错别字、乱码和布局漂移带进最终交付。

工具选型的第一原则不应是能不能接，而应是接入后是否让关键任务更稳定。这条原则不只适用于Skill，也适用于一般的AI产品设计。

结语：Skill的本质，是一份可执行的决策协议

做这两个Skill之前，我关注的是提示词怎么写得更完整。做完以后，我更关注哪些需求更真实，哪些风险需要暂停，哪些结果可以被验收。真正稳定的AI工作流，不是让模型一口气把所有事情做完，而是把人的经验拆成一组可执行的约束。

对产品经理来说，设计Skill 也不只是学会写Prompt。它更像一次微型产品设计：需要定义用户、任务、边界、流程、异常和质量标准。

当这些隐性经验被写进系统，AI就不是偶尔给出一个好结果，而是开始以相对稳定、可解释、可迭代的方式协作。而这可能才是Skill 最有价值的地方：它封装的不是答案，而是产生可靠答案的方法。