1. 从“会用AI”到“会造AI Skill”一个超级个体的能力跃迁这两年我身边越来越多的独立开发者、自由职业者、小团队主理人开始琢磨一件事怎么把自己的行业经验、工作流、判断逻辑封装成一个能反复调用、能交付给别人的 AI Skill。不是那种“写个提示词就完事”的玩具而是真正能解决具体问题、能稳定输出、甚至能作为产品雏形去验证市场需求的东西。我自己从去年开始陆续做了几个 AI Skill有帮教培老师做备课的有给数学建模竞赛队伍做论文降重和思路梳理的也有专门用来“去 AI 味”的文本润色工具。踩了不少坑也总结出了一套还算靠谱的流程。这篇文章就把整个从零到一的过程拆开讲清楚——一个超级个体做 AI Skill到底需要经历哪几步每一步的核心决策点在哪里哪些地方最容易翻车。如果你是一个有明确专业领域经验的人比如老师、分析师、设计师、咨询顾问、程序员或者单纯就是某个垂直场景里的重度用户想把自己的“手感”变成可复用的工具那这篇内容就是写给你的。不需要你会训练模型不需要你懂深度学习但你需要对自己的业务逻辑有足够清晰的认知。2. 第一步把“隐性经验”翻译成“可执行规则”2.1 先搞清楚你的 Skill 到底解决谁的什么问题很多人一上来就想“我要做一个很牛的 AI 工具”结果做了三个月发现没人用。问题出在起点没有明确定义目标用户和触发场景。我自己的做法是先写一句话“这个 Skill 是给______在______的时候用来解决______的问题。”三个空必须填得足够具体。比如“给初中数学老师在准备期末复习课的时候用来快速生成分层练习题和易错点讲解”。这句话写不出来后面所有工作都是空中楼阁。这里有个很实用的判断标准如果你的目标用户可以用“所有人”来概括那基本等于没有用户。超级个体的优势就在于垂直深度不要试图做通用工具那是大厂的事。2.2 把你的工作流拆成“判断节点”和“执行节点”接下来要做的是把你脑子里那套“怎么做”的东西倒出来。我习惯拿一张纸把自己完成这个任务的完整过程画成流程图——注意不是画给领导看的流程图而是画给自己看的“真实决策树”。举个例子我做“去 AI 味”这个 Skill 的时候一开始以为就是同义词替换。但真正拆解后发现人类写作和 AI 写作的差异远不止词汇层面句式节奏AI 喜欢用结构完整的长句人类会穿插短句、断句、甚至不完整句逻辑连接AI 频繁使用“因此”“然而”“此外”人类更多靠语义自然过渡信息密度AI 倾向于把每个点都展开说透人类会默认某些背景知识情感颗粒度AI 的情绪表达是标签化的人类是混合的、有层次的这些判断节点才是 Skill 的核心价值。执行节点比如具体替换哪个词反而可以交给模型去发挥。2.3 区分“必须硬编码”和“可以交给模型”的部分这一步是很多新手容易走偏的地方。我的经验法则是内容类型处理方式原因格式规范、输出结构硬编码在提示词里模型自由发挥容易跑偏专业术语、行业黑话提供术语表或示例模型不一定懂你的垂直领域判断逻辑、优先级写成明确的规则链这是你的核心经验不能丢具体措辞、表达方式交给模型生成发挥模型的语言能力边界情况处理预设 fallback 策略避免模型胡编乱造我见过太多人把整个 Skill 写成一个巨大的提示词里面塞了几千字的规则结果模型要么忽略一部分要么过度拟合。正确的做法是分层底层是硬规则中层是示例和参考上层是模型的自由发挥空间。2.4 用“最小可验证样本”测试你的规则是否成立在正式动手做 Skill 之前我强烈建议先做一件事找 5 到 10 个真实案例手动按照你设计的规则走一遍看看输出结果是否稳定。这个步骤看起来笨但能帮你省下大量后期调试的时间。我当时做数学建模 Skill 的时候一开始设计了一套“自动识别模型假设漏洞”的规则手动跑了 8 篇往年竞赛论文发现其中有 3 篇的漏洞类型根本不在我预设的规则里。如果直接做成 Skill这 3 种情况就会变成盲区。实操心得手动测试的时候一定要记录“规则失效”的案例这些才是你后续迭代的核心素材。成功的案例反而参考价值有限。3. 第二步技术选型与工具链搭建3.1 先想清楚交付形态对话式、API 还是嵌入式AI Skill 的交付形态直接决定了你的技术选型。目前主流的有三种对话式 Skill用户通过聊天界面调用适合咨询、辅导、创意生成类场景。优点是开发成本低缺点是用户粘性差容易被替代。API 式 Skill把能力封装成接口供其他系统调用。适合有明确输入输出格式的任务比如文本分类、信息抽取、格式转换。优点是容易集成缺点是需要一定的技术能力才能使用。嵌入式 Skill把 AI 能力嵌入到现有工作流中比如浏览器插件、办公软件插件、IDE 插件。优点是用户体验好缺点是开发成本高需要适配不同平台。我个人的建议是超级个体先从对话式做起验证需求后再考虑 API 化。不要一上来就追求“产品级”那是团队做的事。3.2 模型选择不是越贵越好而是越合适越好现在市面上的模型选择很多我的选型逻辑是这样的任务复杂度简单的格式转换、文本润色小模型足够复杂的逻辑推理、多步判断需要大模型响应速度要求实时交互场景优先考虑推理速度快的模型成本预算按 token 计费的模型要算清楚单次调用成本乘以预估调用量数据隐私涉及敏感信息的场景优先考虑可本地部署的方案我实测下来对于“去 AI 味”这类文本风格调整任务中等规模的模型配合好的提示词设计效果已经足够好。而对于数学建模这种需要深度推理的场景就必须用推理能力更强的模型。3.3 提示词工程把你的经验“编译”成模型能懂的语言提示词不是越长越好而是要结构清晰、层次分明。我通常把提示词分成四个模块角色定义告诉模型它是谁具备什么能力服务什么对象。这部分要具体不要写“你是一个 helpful assistant”而要写“你是一个有 10 年教龄的初中数学老师擅长把抽象概念转化成生活化例子”。任务描述清晰说明输入是什么、输出是什么、中间需要经过哪些步骤。如果有固定的输出格式直接给出模板。规则约束列出必须遵守的硬性规则和禁止事项。这部分要用明确的指令语气比如“必须”“禁止”“始终”“绝不”。示例参考给出 2 到 3 个高质量的输入输出示例。示例的质量直接决定模型输出的上限。注意事项提示词里的规则不要超过 7 条。超过 7 条后模型对每条规则的遵守程度会明显下降。如果规则确实很多考虑拆分成多个 Skill 串联。3.4 版本管理别让你的 Skill 变成“一次性作品”我早期做 Skill 最大的问题就是没有版本管理改着改着就忘了之前哪版效果更好。后来我养成了一个习惯每次修改提示词或规则都记录三个东西——改了什么、为什么改、改完之后的测试结果。推荐用简单的表格来管理版本号修改内容修改原因测试结果是否保留v1.0初始版本-60% 可用否v1.1增加句式节奏规则输出太像 AI75% 可用否v1.2调整示例质量示例不够典型85% 可用是这个习惯看起来繁琐但当你迭代到 v3.0 的时候回头查记录能帮你快速定位问题。4. 第三步核心环节实现与实操流程4.1 以“去 AI 味 Skill”为例的完整搭建过程我拿自己最近做的一个“去 AI 味”Skill 来完整走一遍流程。这个 Skill 的需求场景很明确很多用 AI 辅助写作的人输出内容一眼就能被看出来是机器写的需要一种工具把文本调整得更像人类自然表达。第一步定义输入输出输入是一段待处理的文本输出是调整后的文本。但这里有个关键决策是保留原意只改风格还是允许一定程度的改写我的选择是保留核心信息允许调整句式和表达方式但不允许增加或删除关键信息点。第二步拆解“AI 味”的具体特征我收集了 50 段被标记为“AI 生成”的文本和 50 段人类写作文本做了对比分析总结出以下高频特征过度使用“首先、其次、最后”等序列词每段开头都是完整的主题句喜欢用“不仅...而且”“虽然...但是”等固定搭配段落长度高度均匀缺乏口语化表达和语气词情感表达单一要么全正面要么全负面第三步设计处理规则链根据以上特征我设计了一套处理流程检测并标记 AI 高频特征词对标记部分进行替换或删除调整段落长度制造长短交错在合适位置插入口语化过渡检查情感表达是否有多层次第四步编写提示词提示词的核心结构是这样的你是一个有 15 年经验的文字编辑专门帮助作者把 AI 辅助生成的文本调整成自然的人类写作风格。 处理规则 1. 删除或替换以下词汇首先、其次、最后、此外、然而、因此、总之、综上所述 2. 把超过 40 字的长句拆分成 2 到 3 个短句 3. 每段开头不要都用完整主题句允许直接进入细节 4. 适当加入“说实话”“我试过”“踩过的坑”等口语化表达 5. 保持原意不变不增加新信息 输出格式 直接输出调整后的文本不需要解释修改原因。第五步测试与迭代我找了 20 段不同来源的 AI 生成文本进行测试第一版通过率只有 55%。主要问题是模型有时候会过度修改把专业术语也替换掉了。第二版增加了“专业术语保护列表”通过率提升到 78%。第三版调整了示例质量通过率达到 88%。4.2 以“AI 备课 Skill”为例的差异化设计再来看一个完全不同的场景AI 备课 Skill。这个 Skill 的目标用户是中小学老师核心需求是快速生成教案框架、分层练习题和易错点分析。这个 Skill 和“去 AI 味”的最大区别在于它需要输出结构化内容而不是自由文本。所以技术方案完全不同。核心设计决策输出格式必须严格遵循教案模板不能自由发挥题目难度需要分层通常分为基础、提高、拓展三个层级易错点分析需要基于真实教学经验不能泛泛而谈需要支持不同教材版本的适配实现要点我用了“模板 规则 示例”的三层结构。模板定义输出框架规则定义难度分层逻辑和易错点判断标准示例提供高质量参考。实测下来这种结构比纯提示词方式的输出稳定性高出很多。实操心得结构化输出的 Skill一定要在提示词里给出完整的输出模板并且用“必须严格按照以下格式输出”这样的强指令。否则模型会自作主张调整格式。4.3 以“数学建模 Skill 降 AI”为例的复杂场景处理数学建模竞赛场景对 AI 检测特别敏感很多队伍用 AI 辅助写的论文会被判定为违规。所以“数学建模 Skill 降 AI”这个需求就出现了既要利用 AI 提高写作效率又要让最终文本看起来不像 AI 写的。这个场景的复杂度在于数学建模论文有固定的学术写作规范不能像普通文章那样随意口语化。所以“去 AI 味”的策略需要调整。我的处理方案是保留学术写作的正式语气但打破 AI 的句式规律在公式推导和模型描述部分增加人类常见的“不完美表达”比如“这里我们尝试了一种可能不太成熟的做法”在结果分析部分加入更多主观判断和局限性讨论调整段落结构避免 AI 喜欢的“总-分-总”模式这个 Skill 的测试周期最长因为需要找真实的竞赛论文做对比。最终通过率在 82% 左右对于竞赛场景来说已经够用了。4.4 实操中的参数调优与效果评估不管做哪种 Skill参数调优都是绕不开的环节。我常用的可调参数包括参数作用调整建议温度值控制输出随机性创意类任务调高结构化任务调低最大输出长度限制响应长度根据任务复杂度设置避免截断重复惩罚减少重复表达文本生成类任务适当调高示例数量影响输出风格2 到 3 个高质量示例效果最好效果评估我一般用三个指标可用率输出直接可用的比例、修改率需要人工修改的比例、一致性相同输入多次调用输出是否稳定。这三个指标比单纯的“好不好”更有参考价值。5. 第四步常见问题排查与避坑指南5.1 输出不稳定同样的输入结果差异很大这是最常见的问题。原因通常有三个温度值设置过高、提示词规则不够明确、示例质量参差不齐。排查顺序先把温度值调到 0.3 以下测试如果稳定了就是温度问题如果还不稳定检查提示词里是否有模糊表述比如“尽量”“可以”这类词要改成“必须”“始终”最后检查示例确保每个示例都是高质量的、有代表性的。5.2 模型不遵守规则明明写了禁止还是会出现模型对规则的遵守程度和规则的表述方式强相关。我总结了几条经验否定式规则效果差“不要使用首先其次”不如“使用以下词汇替代...”规则要具体“保持简洁”不如“每句话不超过 30 字”规则要有优先级如果规则冲突明确告诉模型哪条优先规则数量要控制超过 7 条后遵守率明显下降5.3 输出格式跑偏说好的 JSON结果给了段散文结构化输出场景下格式跑偏是高频问题。我的解决方案是在提示词里给出完整的输出模板用代码块包裹明确说明“只输出 JSON不要有任何其他文字”如果模型仍然跑偏在末尾加一句“如果输出格式不正确将导致系统错误”极端情况下用 few-shot 示例强制格式5.4 专业术语被误改模型把行业黑话当成了 AI 味这个问题在垂直领域 Skill 中特别常见。我的做法是维护一个“保护词列表”在提示词里明确列出这些词不能被修改。同时在示例中故意包含这些术语让模型学会识别。5.5 常见问题速查表问题现象可能原因排查方法解决方案输出不稳定温度过高/规则模糊降低温度测试调低温度明确规则规则不遵守规则表述不当检查规则措辞改用肯定式、具体化格式跑偏模板不清晰检查输出模板给出完整模板和示例术语被误改缺少保护列表检查术语处理添加保护词列表输出太短最大长度限制检查参数设置调高最大输出长度输出太长缺少长度约束检查提示词增加长度限制规则避坑技巧每次修改 Skill 后一定要用同一组测试用例跑一遍对比修改前后的效果。不要凭感觉判断“好像变好了”。6. 第五步从“能用”到“好用”的迭代心法6.1 收集真实反馈别自己觉得好就完事了Skill 做出来之后一定要找真实用户用。我自己的经验是自己测试 100 次不如让 3 个真实用户各用 10 次。因为你自己知道怎么“绕开”问题真实用户不会。收集反馈的时候不要问“你觉得好不好”而要问“你在什么场景下会用它”“有没有哪次输出让你觉得不对劲”“如果只能保留一个功能你选哪个”。具体的问题才能得到具体的答案。6.2 建立“失败案例库”错误比正确更有价值我专门建了一个文档记录所有输出失败的案例。每个案例记录输入是什么、期望输出是什么、实际输出是什么、失败原因分类。这个文档是我迭代 Skill 最重要的素材来源。失败原因我通常分成几类规则缺失、规则冲突、示例误导、模型能力边界。前三类可以通过修改提示词解决第四类需要考虑换模型或者调整任务设计。6.3 控制迭代节奏不要频繁大改我见过有人一天改三版提示词结果越改越乱。我的建议是小步快跑但每次只改一个变量。改了规则就不要同时改示例否则你无法判断是哪个改动起了作用。另外每次大版本更新前保留一个稳定版本作为 fallback。新版本测试通过率超过旧版本 10% 以上再正式切换。6.4 考虑 Skill 的“可组合性”当你做了多个 Skill 之后会发现有些能力是可以复用的。比如“去 AI 味”的能力可以用在备课 Skill 的输出环节“结构化输出”的能力可以用在数学建模 Skill 的格式整理环节。我的做法是把通用能力抽出来做成“基础 Skill”具体场景的 Skill 调用这些基础能力。这样维护成本更低效果也更稳定。6.5 关于商业化的一点个人观察如果你做 Skill 的目的是变现那从一开始就要想清楚收费模式。目前我观察到几种可行的方式按调用次数收费、按月订阅、一次性买断、或者作为咨询服务的附属品。但说实话超级个体做 Skill 最大的价值不一定是直接卖钱而是作为个人品牌的放大器。一个高质量的 Skill 能帮你建立“这个领域我最懂”的认知后续的咨询、课程、定制服务才是更大的收入来源。我自己在实际操作中的体会是做 Skill 这件事技术只占三成剩下七成是对业务的理解深度和持续迭代的耐心。那些做得好的 Skill背后都是作者在某个领域积累了大量的“隐性知识”然后通过 AI 把它们显性化了。如果你在某个领域有足够深的积累现在就是把它变成 Skill 的最好时机。