从零构建可复用AI Skill：MD文件、Prompt工程与Agent协作实战

1. 从零理解 Skill 机制它到底是什么为什么值得折腾1.1 Skill 不是插件也不是 Prompt 模板很多人第一次接触 Skill 这个概念会下意识把它归类成“插件”或者“提示词模板”。我一开始也这么理解直到自己动手写了几个之后才发现这个认知偏差会直接导致后面设计思路跑偏。Skill 的本质是一个可复用的能力封装单元。它和 Prompt 最大的区别在于Prompt 是一次性的指令你发给模型模型回你对话结束就散了而 Skill 是有结构的、可持久化的、能被反复调用的能力模块。你可以把它理解成给 AI 装了一个“技能包”——这个技能包里包含了指令、上下文、工具调用逻辑、输出格式约束甚至包含了对特定领域知识的引用。和插件相比Skill 又更轻量。插件通常需要注册、需要 API 对接、需要处理鉴权和回调Skill 更多是在 Prompt 层面做结构化封装通过一个 MD 文件或者一组配置文件来定义行为。它不依赖外部服务的稳定性也不需要复杂的部署流程。那为什么现在 Skill 这么火核心原因是大模型的能力上限已经足够高瓶颈转移到了“如何稳定地让模型在特定场景下做对的事”。Skill 就是解决这个稳定性问题的工程化手段。1.2 一个 Skill 的典型组成结构我拆过不少别人写的 Skill也自己从零构建过十几个总结下来一个完整的 Skill 通常包含以下几个部分元信息层名称、描述、适用场景、触发条件。这部分决定了 Skill 什么时候被激活。指令层核心的 Prompt 内容告诉模型“你要做什么、怎么做、做到什么程度”。上下文层领域知识、参考文档、示例输入输出。这部分通常以 MD 文件的形式挂载。约束层输出格式、边界条件、禁止行为。比如“不要编造数据”“必须用表格输出”等。工具层可选如果 Skill 需要调用外部工具或检索这里定义调用逻辑。这五层里指令层和上下文层是核心也是大多数人写 Skill 时最容易偷懒的地方。很多人只写了几句指令就发布了一个 Skill结果用起来效果飘忽不定根本原因就是上下文层太薄模型没有足够的锚点来约束自己的输出。1.3 为什么用 MD 文件来承载 Skill热词里反复出现“MD 文件”“md文件编辑器”“如何利用 vx code 编辑 md 文件”这不是偶然的。MD 文件天然适合做 Skill 的载体原因有几个第一MD 是纯文本任何编辑器都能打开不依赖特定平台。你用 VS Code 能编辑用 Typora 能编辑甚至用记事本也能改。这意味着 Skill 的可移植性极强。第二MD 有结构。标题、列表、代码块、表格、引用块这些语法天然适合组织 Prompt 内容。你可以用##来分章节用-来列要点用 来包裹示例代码。模型在解析 MD 格式的 Prompt 时对结构的理解也更准确。第三MD 可版本管理。放到 Git 仓库里每次修改都有记录团队协作时也能 diff 对比。这一点对于需要迭代优化的 Skill 来说非常关键。我自己的习惯是每个 Skill 一个独立目录目录下至少有一个SKILL.md作为主文件如果有参考文档就放在references/子目录下如果有示例就放在examples/子目录下。这样结构清晰后续维护也方便。提示不要把所有内容都塞进一个 MD 文件里。超过 500 行的 Skill 文件维护成本会急剧上升而且模型在解析时也容易丢失重点。拆分成多个文件用引用关系组织效果更好。2. 创建 Skill 的完整实操流程2.1 环境准备与工具选型在动手写 Skill 之前先把工具链搭好。我目前的主力组合是编辑器VS Code。装一个 Markdown All in One 插件再加一个 Markdown Preview Enhanced写 MD 文件的体验基本拉满。VS Code 的好处是自带终端写完 Skill 可以直接在同一个窗口里测试。版本管理Git。每个 Skill 一个仓库或者多个 Skill 放在一个 monorepo 里看你的管理习惯。测试环境取决于你用的平台。如果是在 Claude Code 里用 Skill直接在终端里跑就行如果是在其他支持 Skill 的平台上用按照平台的测试流程来。这里重点说一下 VS Code 编辑 MD 文件的几个实用技巧CtrlShiftV打开预览边写边看渲染效果。CtrlShiftP打开命令面板输入 “Markdown” 可以看到所有可用的 MD 相关命令。用!-- --写注释这些注释不会出现在预览里但会保留在源文件中适合写一些给自己看的备注。用写引用块在 Skill 里用来标注重要提示和禁忌模型对引用块的注意力权重通常更高。2.2 定义 Skill 的元信息元信息是 Skill 的“身份证”。一个好的元信息应该让使用者在看到的第一眼就知道这个 Skill 是干什么的、什么时候该用它、用了之后能得到什么。我通常用以下格式来定义元信息--- name: skill-name description: 一句话说明这个 Skill 能做什么 trigger: 什么情况下应该激活这个 Skill version: 1.0.0 author: your-name ---description要具体不要写“一个有用的 Skill”这种废话。比如你要做一个“论文检索 Skill”description 应该写成“根据关键词检索学术论文并整理成结构化摘要”。trigger要写清楚触发条件比如“当用户要求检索文献、查找论文、整理参考文献时激活”。这里有个经验trigger 写得越具体Skill 被误触发的概率越低。我见过有人把 trigger 写成“当用户需要帮助时”结果这个 Skill 几乎每轮对话都会被激活完全失去了意义。2.3 编写核心指令层指令层是 Skill 的灵魂。这部分写得好不好直接决定了 Skill 的输出质量。我的写法是遵循“三段式”结构第一段角色定义。告诉模型它现在是什么角色。比如“你是一名学术文献检索助手擅长从多个数据源中查找论文并整理成结构化摘要。”第二段任务流程。分步骤说明模型应该怎么做。这里要用有序列表每一步都要具体到可执行。比如从用户输入中提取关键词和检索范围。根据关键词构造检索式。在指定数据源中执行检索。对检索结果去重、排序、筛选。按照指定格式输出摘要。第三段输出约束。定义输出的格式、长度、语言风格。比如“输出必须使用 Markdown 表格包含标题、作者、年份、摘要四个字段摘要不超过 200 字。”这三段写完之后再补充一个“边界条件”部分说明什么情况下不应该做什么。比如“如果检索结果为空不要编造论文信息直接告知用户未找到相关结果。”2.4 构建上下文层与参考文档上下文层是很多 Skill 拉开差距的地方。同样一个“论文检索 Skill”有的人只写了指令层输出质量时好时坏有的人在上下文层里挂了一个“检索式构造指南”和一个“摘要写作规范”输出就稳定得多。上下文层的组织方式我推荐用“主文件 引用文件”的结构SKILL.md主文件包含元信息、指令层、约束层。references/search-guide.md检索式构造指南包含不同数据库的检索语法、常用字段、布尔逻辑组合方式。references/summary-format.md摘要写作规范包含摘要的结构、长度要求、语言风格示例。examples/input-output.md示例输入输出给模型提供 few-shot 参考。主文件里用相对路径引用这些文件比如“检索式构造请参考references/search-guide.md”。模型在解析时会自动加载这些引用文件的内容。注意引用文件不要太多3-5 个足够了。太多引用文件会导致模型在解析时分散注意力反而降低输出质量。每个引用文件的内容也要控制长度单文件不超过 300 行。2.5 约束层与输出格式定义约束层的核心作用是“防止模型跑偏”。大模型有一个通病你给它一个任务它总想额外发挥一下加一些你没要求的内容。约束层就是用来堵住这些额外发挥的。我常用的约束手段包括格式约束明确指定输出格式用代码块给出模板。长度约束明确指定每个部分的字数上限。内容约束明确列出禁止出现的内容类型。语言约束明确指定输出语言和语气。举个例子如果你做一个“PPT 大纲生成 Skill”约束层可以这样写## 输出约束 - 输出必须为 Markdown 格式使用三级标题划分每页内容。 - 每页内容不超过 5 个要点每个要点不超过 20 字。 - 禁止在输出中添加任何解释性文字只输出大纲本身。 - 如果用户没有指定页数默认生成 10 页。这种约束看起来很简单但实际用起来效果差异巨大。没有约束层的 Skill输出经常是“一坨”有了约束层之后输出就变得规整可用。3. 修改与迭代 Skill 的实战方法3.1 什么时候需要修改 SkillSkill 不是写完就完事的它需要持续迭代。我总结了几种必须修改 Skill 的场景场景一输出不稳定。同样的输入有时候输出很好有时候输出很差。这说明指令层或约束层有歧义模型在不同轮次的理解不一致。场景二场景覆盖不全。用户提了一个新需求现有 Skill 处理不了。这时候需要扩展指令层增加新的处理分支。场景三输出格式不符合预期。模型输出的格式和你想要的格式有偏差。这时候需要加强约束层给出更明确的格式模板。场景四性能问题。Skill 执行太慢或者消耗的 token 太多。这时候需要精简上下文层去掉不必要的参考文档。场景五平台更新。底层模型或平台更新了原有的 Skill 行为发生了变化。这时候需要重新测试并适配。3.2 修改 Skill 的正确姿势修改 Skill 最容易犯的错误是“直接改主文件改完就发布”。这种做法的问题在于你改了什么、为什么改、改完之后效果是好了还是坏了完全没有记录。过一段时间回头看自己都忘了当初为什么这么改。我的做法是遵循“分支-测试-合并”的流程从主分支切一个feature/xxx分支出来。在分支上修改 Skill 文件。用一组固定的测试用例跑一遍对比修改前后的输出。如果效果确实好了合并回主分支如果效果变差了直接丢弃分支。测试用例的构造很关键。我通常会准备 5-10 个典型输入覆盖正常场景、边界场景、异常场景。每次修改 Skill 之后都用这组用例跑一遍确保没有回归。3.3 用版本管理追踪 Skill 的演化Git 是 Skill 迭代的最佳搭档。我建议每个 Skill 都维护一个CHANGELOG.md记录每次修改的内容和原因。格式可以很简单## v1.2.0 (2025-01-15) - 增加对英文文献检索的支持 - 修复摘要长度超出限制的问题 - 优化检索式构造逻辑减少无效检索 ## v1.1.0 (2025-01-10) - 增加输出格式约束 - 补充检索式构造指南 ## v1.0.0 (2025-01-05) - 初始版本发布这个 CHANGELOG 看起来不起眼但实际用起来非常有用。尤其是当你同时维护多个 Skill 的时候没有 CHANGELOG 根本记不住每个 Skill 改了什么。3.4 常见修改场景与对应策略我把常见的修改场景和对应策略整理成了一张表方便快速查阅问题现象可能原因修改策略输出格式不稳定约束层不够明确增加格式模板用代码块给出示例输出内容太泛指令层不够具体细化任务流程增加步骤说明输出缺少领域知识上下文层太薄增加参考文档补充领域知识执行速度慢上下文层太长精简参考文档去掉冗余内容误触发率高元信息 trigger 太宽泛收窄触发条件增加排除条件输出语言不对语言约束缺失在约束层明确指定输出语言这张表是我踩了无数坑之后总结出来的基本上覆盖了 80% 的常见问题。遇到问题的时候先查表能省不少时间。4. Prompt 工程在 Skill 中的核心应用4.1 Prompt 和 Skill 的关系热词里“prompt”“prompt engineering”“prompt提示词”出现的频率非常高这说明大家普遍关心 Prompt 和 Skill 的关系。我的理解是Prompt 是 Skill 的原材料Skill 是 Prompt 的工程化封装。一个 Skill 里可能包含多个 Prompt分别用于不同的处理阶段。比如一个“论文检索 Skill”里可能包含“关键词提取 Prompt”“检索式构造 Prompt”“摘要生成 Prompt”“结果排序 Prompt”。这些 Prompt 各自负责一个环节组合起来完成整个任务。所以写 Skill 的过程本质上就是 Prompt 工程的过程。你的 Prompt 写得好不好直接决定了 Skill 的输出质量。4.2 高质量 Prompt 的五个特征我总结了高质量 Prompt 的五个特征写 Skill 的时候可以对照检查特征一角色明确。Prompt 开头就告诉模型它是什么角色。角色越具体模型的输出越聚焦。特征二任务具体。不要写“帮我处理一下这个数据”要写“从以下文本中提取所有日期按照 YYYY-MM-DD 格式输出”。特征三示例充分。给出 2-3 个输入输出示例模型就能理解你想要什么。这比写一大堆描述管用得多。特征四约束清晰。明确告诉模型什么能做、什么不能做、输出格式是什么。特征五结构清晰。用标题、列表、代码块组织 Prompt 内容让模型容易解析。这五个特征里示例充分是最容易被忽视的。很多人写 Prompt 喜欢用大段描述但模型对示例的理解能力远强于对描述的理解能力。给两个好示例比写五百字描述管用。4.3 Prompt 闪退与异常处理热词里出现了“prompt闪退”和“invalid prompt: your prompt was flagged as potentially violating our usage p”这两个问题我都遇到过。Prompt 闪退通常是因为 Prompt 内容太长超出了平台的输入限制。解决办法是精简 Prompt把不必要的内容移到引用文件里或者拆分成多个 Prompt 分步执行。Invalid prompt 被标记通常是因为 Prompt 里包含了平台认为不合适的內容。解决办法是检查 Prompt 里是否有敏感词、是否有诱导性表述、是否有违反平台规则的内容。把这些问题内容去掉之后通常就能正常使用了。提示写 Prompt 的时候尽量避免使用绝对化表述如“必须”“一定”“绝对”也避免使用可能被误判的词汇。用“建议”“推荐”“通常情况下”这类温和表述触发风控的概率会低很多。4.4 用 Prompt 工程提升 Skill 的稳定性Skill 的稳定性问题80% 可以通过 Prompt 工程解决。我常用的几个技巧技巧一分步执行。不要试图用一个 Prompt 完成所有事情。把任务拆成多个步骤每个步骤一个 Prompt逐步执行。这样每一步的输出都可控整体稳定性更高。技巧二输出校验。在 Prompt 里加入校验逻辑让模型自己检查输出是否符合要求。比如“输出之前请检查摘要长度是否超过 200 字如果超过请精简。”技巧三失败重试。如果模型输出不符合要求让它重试。可以在 Prompt 里写“如果输出格式不正确请重新生成直到符合要求为止。”技巧四温度调低。对于需要稳定输出的 Skill把模型的温度参数调低比如 0.1-0.3输出的随机性会小很多。技巧五固定示例。在 Prompt 里给出固定的输入输出示例模型会倾向于模仿示例的格式和风格输出稳定性会明显提升。5. Skill 与 Agent 的区别及协作模式5.1 Skill 和 Agent 的本质区别热词里“skill和agent的区别”是一个高频问题。我用一句话概括Skill 是能力Agent 是执行者。Skill 定义的是“能做什么”Agent 定义的是“谁来做、什么时候做、怎么做”。一个 Agent 可以调用多个 Skill一个 Skill 也可以被多个 Agent 调用。打个比方Skill 就像工具箱里的锤子、螺丝刀、扳手Agent 就像拿着工具箱的修理工。修理工根据任务需要选择合适的工具来完成任务。从技术实现上看Skill 通常是一个静态的配置文件MD 文件Agent 通常是一个运行时的调度逻辑代码。Skill 不包含状态管理Agent 包含状态管理和决策逻辑。5.2 多 Skill 协作的编排模式在实际项目中很少只用一个 Skill。更多时候是多个 Skill 协作完成一个复杂任务。我常用的编排模式有三种串行模式Skill A 的输出作为 Skill B 的输入依次执行。适合有明确先后依赖的任务。并行模式多个 Skill 同时执行结果汇总后统一处理。适合可以独立执行的子任务。条件模式根据中间结果决定下一步调用哪个 Skill。适合需要动态决策的任务。这三种模式可以组合使用。比如一个“科研助手 Agent”可能先用串行模式提取关键词、检索文献然后用并行模式同时生成摘要和提取引用最后用条件模式根据文献数量决定是否进行二次检索。5.3 从 Skill 到 Agent 的演进路径如果你已经写了一些 Skill想进一步构建 Agent我建议的演进路径是第一步单 Skill 验证。先把单个 Skill 写好、调稳确保它在独立运行时输出质量稳定。第二步多 Skill 串联。把多个 Skill 串联起来验证它们之间的输入输出能否正确对接。第三步加入调度逻辑。写一个简单的调度器根据任务类型决定调用哪些 Skill、以什么顺序调用。第四步加入状态管理。让 Agent 能够记住上下文在多次交互中保持状态一致。第五步加入异常处理。让 Agent 在 Skill 执行失败时能够重试、降级或切换策略。这个路径看起来简单但每一步都有不少坑。我的经验是不要跳过第一步。很多人 Skill 还没写好就急着搭 Agent结果 Agent 跑起来各种问题最后还得回头修 Skill反而更费时间。6. 常见问题与排查技巧实录6.1 Skill 不生效的排查思路Skill 不生效是最常见的问题。排查思路按以下顺序进行第一步检查元信息。确认name、description、trigger是否正确填写。特别是trigger如果触发条件写得太窄Skill 可能永远不会被激活。第二步检查文件路径。确认 Skill 文件放在平台指定的目录下。不同平台对 Skill 的存放位置要求不同放错位置就不会被加载。第三步检查文件格式。确认 MD 文件的格式正确特别是 frontmatter 部分---包裹的元信息不能有语法错误。第四步检查引用文件。如果 Skill 引用了其他文件确认引用路径正确且被引用的文件存在。第五步查看日志。大多数平台在 Skill 加载失败时会输出日志查看日志能快速定位问题。6.2 输出质量不稳定的优化方法输出质量不稳定是另一个高频问题。我总结的优化方法包括增加示例在 Prompt 里增加 2-3 个输入输出示例模型会倾向于模仿示例。加强约束在约束层明确输出格式、长度、语言风格。降低温度把模型温度参数调低减少随机性。分步执行把复杂任务拆成多个简单步骤逐步执行。增加校验在 Prompt 里加入自检逻辑让模型自己检查输出。这几个方法里增加示例和分步执行是最有效的。我实测下来加了示例之后输出稳定性至少提升 50%分步执行之后稳定性提升更明显。6.3 常见问题速查表问题排查方向解决方法Skill 不生效元信息、文件路径、文件格式逐项检查查看加载日志输出格式不对约束层增加格式模板给出示例输出内容太泛指令层细化任务流程增加步骤输出缺少领域知识上下文层增加参考文档执行速度慢上下文层长度精简参考文档误触发率高trigger 条件收窄触发条件Prompt 闪退Prompt 长度精简 Prompt拆分执行输出语言不对语言约束明确指定输出语言6.4 几个踩过的坑和独家技巧坑一引用文件路径用绝对路径。绝对路径在不同环境下会失效一定要用相对路径。坑二元信息里写太多内容。元信息只放最基本的字段详细内容放到指令层。元信息太长会影响加载速度。坑三忽略平台差异。不同平台对 Skill 的支持程度不同写 Skill 之前先确认平台支持哪些功能。坑四不写 CHANGELOG。改了几次之后完全忘了改了什么回头排查问题非常痛苦。技巧一用注释做备注。在 MD 文件里用!-- --写备注不影响渲染但方便自己后续维护。技巧二用表格组织约束。约束层用表格来写比用列表更清晰模型解析也更准确。技巧三定期回归测试。每次修改 Skill 之后用固定测试用例跑一遍确保没有回归。技巧四保留旧版本。修改 Skill 之前先备份旧版本新版本效果不好可以快速回滚。技巧五多看别人的 Skill。学习别人怎么写 Skill比闭门造车效率高得多。尤其是那些被广泛使用的 Skill它们的写法经过了大量验证值得参考。7. 不同场景下的 Skill 设计要点7.1 科研场景的 Skill 设计科研场景的 Skill 有几个特殊要求准确性优先、引用可追溯、格式规范。准确性优先意味着在 Prompt 里要明确要求模型“不要编造数据”“如果不确定请标注不确定”。引用可追溯意味着输出里要包含来源信息比如论文的 DOI 或 URL。格式规范意味着输出要符合学术写作的格式要求比如 APA、MLA 等。我做过一个“文献综述 Skill”核心设计思路是先用检索 Skill 找到相关文献然后用摘要 Skill 提取每篇文献的核心观点最后用综述 Skill 把摘要整合成一篇综述。整个流程分三步每一步都有明确的输入输出格式约束。7.2 办公场景的 Skill 设计办公场景的 Skill 更注重效率和格式统一。比如“PPT 大纲生成 Skill”“会议纪要整理 Skill”“邮件草稿 Skill”等。这类 Skill 的设计要点是输出格式要固定最好给出模板处理速度要快上下文层不要太厚要支持批量处理一次能处理多条输入。我做过一个“会议纪要 Skill”输入是会议录音的文字稿输出是结构化的会议纪要。核心设计是先用一个 Prompt 提取关键信息参会人、议题、决议、待办然后用另一个 Prompt 按照固定模板组织成纪要。两个 Prompt 串联执行效果比用一个 Prompt 好很多。7.3 编程场景的 Skill 设计编程场景的 Skill 对准确性要求最高。代码不能有语法错误逻辑不能有漏洞边界条件要考虑周全。这类 Skill 的设计要点是Prompt 里要包含代码规范比如 PEP 8、Google Style要包含测试要求比如“生成的代码必须包含单元测试”要包含边界条件检查比如“处理空输入、超长输入、非法输入”。我做过一个“代码审查 Skill”输入是一段代码输出是审查意见。核心设计是Prompt 里列出了 20 多条审查规则命名规范、注释完整性、异常处理、性能问题等模型逐条检查并输出意见。这个 Skill 用起来效果不错能发现不少人工审查容易漏掉的问题。7.4 创意场景的 Skill 设计创意场景的 Skill 和前面几种相反它更注重多样性和新颖性。比如“文案生成 Skill”“故事创作 Skill”“命名建议 Skill”等。这类 Skill 的设计要点是温度参数可以调高一些0.7-0.9让输出更多样Prompt 里要鼓励模型“给出多个不同方向的方案”约束层不要写太死给模型留一些发挥空间。我做过一个“产品命名 Skill”输入是产品描述输出是 10 个候选名称。核心设计是Prompt 里要求模型从不同角度命名功能角度、情感角度、文化角度、谐音角度每个角度给出 2-3 个方案。这样输出的名称多样性明显更好。8. Skill 的测试与质量保障8.1 构造有效的测试用例测试用例的质量直接决定了 Skill 的质量。我构造测试用例的原则是覆盖正常场景、边界场景、异常场景。正常场景就是最常见的输入比如“检索关于机器学习的论文”。边界场景是输入处于临界值的情况比如“检索关于一个非常冷门主题的论文可能没有结果”。异常场景是输入不符合预期的情况比如“输入为空”“输入包含特殊字符”“输入语言不是中文或英文”。每个场景至少准备 2-3 个用例总共 10 个左右的用例就能比较全面地覆盖 Skill 的行为。8.2 输出质量的评估标准评估 Skill 输出质量我通常从四个维度打分准确性输出内容是否正确有没有事实错误。完整性输出是否覆盖了所有要求的内容。格式规范性输出格式是否符合要求。可读性输出是否清晰易读逻辑是否连贯。每个维度 1-5 分总分 20 分。15 分以上算合格18 分以上算优秀。每次修改 Skill 之后重新打分对比修改前后的分数变化。8.3 持续迭代的节奏把控Skill 的迭代节奏很重要。太频繁会导致不稳定太慢会导致问题积累。我的建议是小修改随时改改完立即测试。中等修改攒一批一起改改完跑完整测试用例。大修改先切分支充分测试后再合并。另外每次修改之后都要更新 CHANGELOG记录改了什么、为什么改、效果如何。这个习惯看起来麻烦但长期来看能省大量时间。9. 我个人的一些经验和建议写了这么多 Skill踩了这么多坑最后分享几条个人体会。第一条从简单开始。不要一上来就写复杂的 Skill。先写一个最简单的、只做一件事的 Skill跑通了再逐步增加功能。我见过太多人一上来就写一个“全能助手 Skill”结果什么都做不好。第二条多测试少猜测。不要凭感觉判断 Skill 好不好用要实际跑测试用例。很多时候你觉得写得挺好的 Prompt实际跑起来效果一塌糊涂。第三条保持克制。Skill 不是越多越好功能也不是越全越好。一个 Skill 只做一件事做好做精比做一个大而全的 Skill 有价值得多。第四条多看别人的。学习别人写的 Skill尤其是那些被广泛使用的能少走很多弯路。但不要照抄要理解背后的设计思路然后根据自己的需求调整。第五条持续迭代。Skill 不是写完就完事的它需要持续迭代。每次使用中发现的问题都是改进的机会。把每次改进都记录下来时间长了就是一笔宝贵的经验财富。最后再分享一个小技巧如果你在写 Skill 的时候卡住了不知道怎么写可以先手动做一遍任务把每一步的操作和思考过程记录下来然后把这个记录整理成 Prompt。这个方法我用了很多次效果很好。因为手动做一遍能让你发现很多写 Prompt 时容易忽略的细节这些细节往往就是决定 Skill 质量的关键。