你有没有过这种经历写了十年的东西换了三个平台、换了四五套笔名真正沉淀下来的却没有几篇。素材散在旧稿里经验全在脑子里换个工具、换个人就得从头再来一遍。我最近捣鼓了一个项目把一个资深博主的“十年写作经验”折腾成了一份可以重复调用的 Skill下面就叫它 phodal-writer 吧。这个 Skill 不是什么玄学本质上是把作者脑袋里那些“这么说更顺”“这段必须砍掉”“标题得这么起”的隐性判断拆成了一套结构化的写作流程和检查清单让 AI 在写作、改稿、起标题、搭大纲时都能按照这套经验办事。这篇文章就是来复盘这件事的完整过程怎么把十年经验盘出来、怎么设计 Skill 的结构、怎么把经验写成机器能遵守的规则以及我实际调试过程中踩过的坑。适合两类人看一类是内容创作者写了很多年、想把自己的方法论沉淀成可复用的东西另一类是搞提示词工程或 Agent 开发的想参考一个真实的“经验技能化”案例而不仅仅是一句“写清楚一点”。1. 为什么要把写作经验做成 Skill而不是写成文档1.1 经验在文档里是死的在 Skill 里才是活的大部分人沉淀经验的方式是写文档。我也写过洋洋洒洒几万字从选题逻辑写到排版规范写完之后放在某个角落吃灰。问题出在哪文档是给人看的而真正执行写作任务的是一个 AI 或者一个半自动化的写作流程它不会像人一样打开文档、理解语境、再灵活变通。它只能按照提示词、流程和规则去执行。这就引出了 Skill 和文档的本质区别Skill 是“可执行的经验”文档是“可阅读的经验”。一份写作规范文档放到 AI 面前它可能只吸收其中 20% 的内容但一份 Skill 文件放到支持技能调用的工具里它可以在每次任务中加载相关规则、执行对应流程、核验输出质量。同样是那十年的经验文档化之后是一只死老虎做成 Skill 之后才是能自己跑起来的活老虎。我之前有个错误认知以为 Skill 就是复杂版的系统提示词。做多了才发现不对。提示词解决的是“这一次怎么做”Skill 解决的是“这一类任务应该具备什么能力、按什么流程走、在哪些环节做判断”。写作这件事特别适合做成 Skill因为写作本身就是一个高度流程化的活动定题、列大纲、找素材、写初稿、自检、改稿、定稿每一步都有大量的可复用判断。1.2 谁需要这个东西、它能解决什么问题先说清楚不是所有人都需要做这件事。如果你只是为了写一两篇爆款文章直接套用网上的提示词模板就够用了没必要整个 Skill 出来。但如果你符合下面任意一条这件事就值得认真做你已经写了很久公众号、博客、专栏加起来几百篇但每一篇还是从零开始构思没有沉淀出稳定的方法论你经常需要让 AI 帮你产出内容但每次生成的风格和水平飘忽不定需要反复调整提示词其实是不停地在给 AI 重复你的偏好你有一个小团队内容方向靠你把控但你不可能每一篇文章都亲自改你希望有一套机制让写手或者 AI 接手时仍然能贴着你的标准走你在做 Agent 类应用发现通用大模型的写作能力不稳定需要给 Agent 配备一套领域内的高质量“行为准则”。我做的这个 phodal-writer场景就非常清晰它服务的任务是“中文个人博客内容创作”。输入可以是一个粗糙的想法、一个关键词、一条新闻链接输出是一篇符合某资深博主风格和标准的完整文章包括标题、结构、段落节奏和修改建议。它解决的核心问题是同一个作者的经验能不能让 AI 在不同任务、不同场景下稳定复现。这里有一个前提值得说透你只能把“已经被验证有效”的经验放进去。很多人在做技能化的时候用的素材全是自己想当然的写作理念什么“好的文章要有灵魂”“标题要吸引人”这种正确但虚的话做成 Skill 等于没做。真正有用的是那种可以被检查、被执行的判断比如“开头前三段必须出现核心关键词”“每段不超过 150 字”“一个自然段必须只表达一个核心观点”。这些才是能落地的经验颗粒度。2. 动手之前先把你脑子里的经验盘出来2.1 用复盘的方式收集经验而不是靠回忆做 Skill 的第一步不是写代码、不是定义数据结构而是把经验从脑子里“导出来”。我当时用了一个很笨但很有效的办法把这十年写过的文章按类型分组一篇一篇看自己的旧稿问三个问题——当时为什么这么写哪些地方定稿时反复纠结读者反馈最好的段落有什么共同点这个动作听起来慢实际上效率很高。因为你真正重要的经验往往不是那些让你得意的高光时刻而是反复出现的“纠结点”。比如我发现我几乎每篇文章的第三稿都在干同一件事把第二稿里那些修饰性副词删掉把“非常”“真的”“特别”这类词替换成具体的事实或数字。这个动作重复了上百次但一直没被我当成“方法论”。它只是我写作习惯的一部分。把这些重复动作和纠结点记录下来就是最原始的经验素材。我强烈建议你像我一样建一个表格字段就是场景、动作、原因、反例。场景指的是什么样的写作任务动作是你在这种情况下会做什么原因是为什么这么做反例是曾经因为没这么做而出过什么问题。四年写作经验和十年写作经验的差距其实不在天赋而在于后者已经有了几百条这种“场景-动作”的对应关系只是从来没结构化过。这一步做完你会得到大概几十条零散经验。下一步是整理去重。2.2 从几十条零散记录中提炼出核心准则经验记录是原始的、碎片化的直接塞进 Skill 里就是灾难。举个例子你可能记录了“文章开头要有吸引力”“第一段不要太长”“第三句之前要抛出一个问题”这三条本质上说的是同一件事开头要有钩子。如果不做归类Skill 里就会充斥着重复甚至互相矛盾的规则AI 加载之后不知道该听哪条。我最终把这些经验聚成了六类每一类对应一个写作阶段第一类是选题与定位解决的是“写什么”的问题。核心准则是一个选题必须具备对象感能说出来是写给谁看的、解决他的什么问题。泛泛的“谈谈写作技巧”不是选题而“写给写了三年却还在硬憋开头的中文博主”才是。第二类是标题与开头解决的是“读者点不点进来”的问题。核心准则包括标题里要有具体数字或结果承诺如果做不到宁可用疑问句开头一百字内必须出现核心关键词或核心矛盾。第三类是结构与逻辑解决的是“读者读不读得下去”的问题。核心准则是一篇文章只讲透一个核心论点每段只表达一个意思段落之间必须有逻辑连接词或者语义衔接不允许生硬跳转。第四类是表达与语言解决的是“读起来有没有节奏感”的问题。核心准则是删掉所有形容词的修饰性叠加能用具体名词和数字就不用抽象描述能用短句就不用长句。第五类是案例与论据解决的是“凭什么信你”的问题。核心准则是任何一个观点必须配一个具体案例或一个具体操作步骤案例需要读者可以自己验证禁止“某网友”式的模糊指代。第六类是修改与定稿解决的是“文章到底行不行”的问题。核心准则是写完初稿后至少留出一次专门做删减的改稿时间删减量在 10% 以上才算有效修改所有“感觉有点不对”的地方必须定位到具体句子。这六类已经是 Skill 的骨架了。你会发现真正有价值的经验不是那种听起来很高级的理念而是可以被写进检查清单的判断标准。这也是为什么我说经验技能化的本质是“把品味翻译成规则”。3. 设计 Skill 的结构一个能跑起来的写作操作系统3.1 Skill 的骨架不复杂复杂的是每个部件的粒度第一次设计 Skill 结构时我的思路很容易跑偏总是想着要做得像一个“系统”加各种模块、各种接口。后面做多了才明白一个能被 AI 稳定调用的 Skill骨架其实不复杂。核心就五个部分元信息、触发条件、工作流、约束规则、质量检查清单。如果写得更好一点还可以加一个“历史案例库”但那是锦上添花前五个是刚需。为什么这样拆因为 AI 执行任务时需要一个渐进收敛的方法元信息让 AI 知道这个 Skill 是干什么的触发条件让 AI 判断现在该不该用它工作流告诉 AI 按什么顺序做事约束规则告诉 AI 哪些能做、哪些不能做质量检查清单是最后的阀门所有输出交付之前必须过一遍。每一部分的粒度都很有讲究。元信息不要写作文案写成机器友好的一两句话就够了。触发条件要具体不要写“当用户想写文章时”这种废话要写“当用户给出一个选题或关键词并要求生成一篇中文技术/经验分享类博客文章时”。前面那种触发条件等于没说后面这种 Edge Case 一多AI 的命中率就上来了。工作流部分是 Skill 的主干也是写作经验和别人最大的不同所在。大部分人写提示词的时候只会要求 AI“写一篇文章”好一点的会加“先列大纲再写全文”但一个真正可运行的写作 Skill工作流要细到每个阶段的可交付成果。3.2 一个写作工作流的实例六个阶段六个产出物以下是我在 phodal-writer 里用的一套工作流供参考第一阶段是理解与澄清。AI 拿到用户给的粗糙想法之后必须先输出一份“选题定位单”内容包括目标读者是谁、这篇文章要解决他什么问题、和已有文章的差异化在哪。如果这些信息不明确要主动放慢速度向用户提问而不是直接动笔。第二阶段是素材与案例收集。AI 需要列出这篇文章可能涉及的核心观点并为每个观点准备候选案例或论据。案例不足时必须明确说明“该观点目前没有强案例支撑建议用户补充”而不是硬编一个。第三阶段是大纲设计。输出一份带逻辑递进的大纲每一个章节必须回答“这一章解决读者的什么疑问”不允许给出“介绍背景—深入分析—总结”这种万能但空洞的结构。第四阶段是初稿写作。按照大纲逐段产出每段遵循“核心句先行解释和例证跟上段尾有收束并衔接到下一段”的节奏。第五阶段是自检与修订。AI 必须用检查清单逐条过一遍初稿标注不符合项然后至少做一轮实质性修改。修改不只是换词而是重新组织段落结构、删除冗余、强化逻辑连接。第六阶段是输出与交付。输出最终稿时附带一份“修改说明”告诉用户这一版相比初稿改了哪些地方、为什么改、还能怎么继续优化。这套流程看着不复杂难点在于每一步的产出物都要有明确格式且每一步之间不能跳步。举个例子很多 AI 写作工具号称“一键生成全文”体验却很差根本原因就是把第一阶段到第四阶段全部压缩成了“写一篇 XX 风格的文章”这一句话。AI 没有经过理解、定位、结构设计的环节直接生成三千字质量自然飘。你让一个资深编辑直接写他有内隐的经验在脑子里自动完成了那些环节但 AI 没有那个内隐经验所以你必须把那些隐形的步骤外显出来。这就是“经验整理成 Skill”的真正含义把资深作者脑子里自动完成的隐性流程拆成 AI 能一步步执行的显性流程。4. 把经验写成机器能遵守的规则一份 Skill 实例拆解4.1 Skill 文件的最小可用原型下面是一份缩略过的 Skill 定义结构上覆盖了前面说的五个部件。这里用 YAML 开头做元信息和配置正文用 Markdown 写规则和流程因为大多数支持自定义技能的工具都能解析这种格式。name: phodal-writer description: 用于中文经验分享类博客文章创作。输入一个想法或关键词输出一篇符合资深博主风格的结构化文章。 version: 1.0.0 trigger_rules: - 用户要求写一篇中文博文 - 用户要求把某个想法整理成文章 - 用户要求基于某个主题生成标题或大纲 workflow: - step: understand name: 理解与澄清 output: 选题定位单 - step: collect name: 素材与案例收集 output: 论据清单 - step: outline name: 大纲设计 output: 带逻辑递进的大纲 - step: draft name: 初稿写作 output: 完整初稿 - step: revise name: 自检与修订 output: 修订版文章与修改说明 - step: deliver name: 输出与交付 output: 最终稿 style_rules: - 一个自然段只表达一个核心观点 - 每段不超过 150 字 - 少用形容词叠加改用具体名词和数字 - 禁止出现“综上所述”“总而言之”类过度总结词 - 每一层论点必须配有可验证的案例 - 段落之间必须自然衔接禁止强行断节 quality_checklist: - 标题是否包含核心关键词 - 开头 100 字内是否出现核心概念或矛盾 - 每个 H2 段落是否有独立价值或独立观点 - 是否每段都保持了“一段一义” - 删除所有空话套话后剩余内容是否仍有完整逻辑单看这份文件可能觉得简单但真正使用的时候AI 会把它当作一个强制执行的作业指导书。你的写作经验就通过这些准则和检查项在每一次生成中起作用。4.2 把每条经验写成可检查的规则而不是正确的废话写规则的时候最容易踩的坑有三个我一个个说。第一个坑是量化不足。比如你写“开头要有吸引力”AI 无法判断什么叫有吸引力它只能生成一个看起来热闹但没有信息量的开头。改成像“开头 100 字内必须包含核心主题词或一个具体的问题”之后AI 就有了一个可以核验的抓手。这里不是要求每条规则都带数字但凡是能被量化的判断必须量化。第二个坑是把品味当规则。什么“好的文章要有温度”“文字要有力量”这些不是规则是审美判断。审美判断必须被翻译成具体的操作指令之后才有效。比如“有温度”可以被翻译为“在案例段落加入第一人称的实际经历和感受”“有力量”可以被翻译为“多用短句一句话控制在 20 字以内”。翻译之后AI 才知道怎么执行。第三个坑是只写“要怎么做”没写“不能怎么做”。AI 生成的文本有一个天然的毛病就是喜欢堆砌四字结构、排比句、套话连接词。如果你的规则里只有正向要求AI 很容易在满足正向要求的表象下产出毫无信息量的官样文章。所以我在 style_rules 里专门放了负面清单禁止用“综上所述”禁止形容词叠加禁止强行排比。负面清单往往比正面清单更管用。写完规则之后我强烈建议你做一次“无知测试”找一个完全不了解你的同事或朋友把 Skill 文件丢给他让他按照这份文件用 AI 写一篇稿子看他能不能顺畅跑下来。如果对方频繁跑来问你“这句话是什么意思”“这个环节怎么做”说明你的规则粒度还不够。这套方法成本最低效果最明显。5. 把 Skill 嵌进真实工作流工具选型与落地经验5.1 工具层面不存在“最好的 Skill 平台”只有“最合适的工作流”Skill 这个概念在行业内没有统一的标准格式各家工具支持的自定义方式也不同。一类是直接在交互式对话工具里加载自定义指令适合个人单兵作战另一类是走工程化的方式把 Skill 文件集成到工作流里让不同任务自动调用适合团队或批量生产场景。我在实际使用中倾向于一个原则先像写文档一样写规则再把它塞进最小可用的工具链。不要一上来就追求架构完美否则你会在配置工具和调试格式上耗费大量时间没等体验到效果就先放弃了。第一版只需要做到“把 Skill 文件放进去简单触发就能得到比默认提示词更好的输出”这就够了。关于工具的具体配置流程不同平台不一样但不外乎三步导入技能文件、设置触发方式、试跑一个任务。试跑时不要选一个你已经写过好几遍的熟悉选题那样你很容易觉得 AI 写得不够好要选一个你完全没有头绪的新题目这样你才能感受到 Skill 对你从零开始构思的帮助有多大。5.2 调稿比调规则更重要先用起来再改文件很多人在调试 Skill 时会陷入一个恶性循环发现输出不行就开始疯狂改规则文件加各种条款结果改完之后输出反而更僵化。这个误区很常见。正确的策略是先接受一个平庸但结构正确的初稿然后依托这个 Skill 的工作流去人工干预其中一个环节看把这一环节的规则改掉之后输出有没有实质改善。也就是说把 Skill 当成一个活的稿件流程去调而不是当成一个配置文件去焊死。举个例子第一版 phodal-writer 的结构设计阶段输出的效果不错但到了正文表达阶段AI 写出来的段落总是“软软的”缺一种笃定的语气。我刚开始以为是规则写得不够细加了一大堆“语气要肯定”“避免模棱两可”之类的描述完全没用。后来才发现问题的根源不在表达阶段而是“理解与澄清”阶段的目标读者定义过于抽象AI 不知道在跟谁说话自然就拿不准语气。我改了理解阶段的输出模板要求必须写明读者画像和读者当前的状态正文表达一下子就立住了。这个案例很有意思它反映了经验技能化的一个核心规律写作质量问题往往不在它表面出现的位置而在流程上游的某个环节。你调规则的时候要顺着流程去追根因而不是在出现问题的位置打补丁。6. 踩过坑之后Skill 的边界、迭代与团队复用6.1 Skill 不是银弹它有自己的使用边界做到第二个版本的时候我给 phodal-writer 加了很多新功能比如自动生成文章摘要、自动生成 SEO 关键词、自动配图建议结果一次实测就翻车了。功能越多AI 在主干任务上的注意力就越分散文章质量反而下降。这里有个残酷的教训Skill 的边界越清晰产出质量越稳定什么都能干的 Skill往往什么都干不好。写作 Skill 就专注在写作上。SEO 关键词可以做成独立技能配图可以交给另外的工具不要不分青红皂白地全都揉进一个文件里。大模型处理一个复杂任务时本身就需要把注意力分配给多个子环节如果你在 Skill 里又塞了五六个与核心无关的子目标它的表现会明显下滑。另外还要考虑一个边界不是所有写作任务都适合同一个 Skill。写一篇深度教程和写一条小红书种草文案背后的经验体系完全不同。强行用一套规则去覆盖结果是深度教程失去了轻盈感种草文案又缺乏逻辑深度。我的做法是按内容类型拆成不同的 Skill 文件phodal-writer 只负责“经验分享类长文”这一种类型。短内容、社交媒体文案另外再建立对应的 Skill。6.2 迭代节奏Skill 是“长”出来的不是“写”出来的一个成熟的 Skill 不是一次性设计出来的而是用过几十次之后迭代出来的。我的经验是每写完三到五篇稿子花十分钟做一次回看把这次写作过程中出现的所有“卡顿点”记下来。所谓卡顿点就是你在写作或改稿时忽然觉得 AI 的输出“哪里不对劲”但一时说不清楚的地方。把这些卡顿点攒起来攒到三五个再一次性检查是否可以通过调整规则解决。这里要注意卡顿点分为偶尔型和系统型。偶尔型卡顿往往是大模型随机性造成的不用管系统型卡顿指的是同一类问题反复出现这种才是你需要修补的规则盲区。判断方法很容易同一个 Skill 生成三次如果三次都出现同一个毛病记录下来如果只出现一次忽略它。团队复用场景下还有一层额外要求Skill 文件里的每一条规则都应该留一个“为什么”。我一开始没在意这件事后来把 Skill 共享给其他写手时对方看到“每段不超过 150 字”这条规则第一反应是“凭什么”。当我补上原因“短段落能控制读者注意力的分配节奏同时强迫作者每段只留一个信息点”后对方接受度高了很多。规则写入什么理由不会占用太多成本但对协作效率的提升极大。6.3 经验技能化的尽头是保留“人的判断”做了几个月之后我对这件事有了新的理解真正有价值的不是把所有经验都塞给机器而是把重复性的判断交给机器把真正重要的判断留在人手里。phodal-writer 里的大部分规则处理的是“平庸之恶”——避免 AI 写出正确但没有灵魂的文字。但文章最终的选题方向、立场表达、观点取舍这些是不能技能化的。举个最直接的例子我试过一次完全交给 Skill 流程自动产出文章从选题到定稿全部让 AI 按照规则跑。结果文章挑不出毛病但读完之后我也不知道作者是谁。因为这篇文章太“正确”了完全不符合我作为一个有偏好、有态度、会生气的真实个体的表达习惯。那次经历之后我把工作流的最后一步改掉了AI 必须在交付定稿之前输出一个“本文的个人观点声明”明确告诉用户这篇文章的立场是基于什么样的经历或判断。如果这个声明写不出来说明文章还没有打上作者的烙印需要退回重写。这个设计不在任何写作技巧书上反而是我把写作经验做成 Skill 之后最大的收获。经验技能化的目的不是把我们自己变成一个可以被参数化的写作机器而是让机器替我们分担表达过程中低效重复的部分让我们更有精力去做那些只有人才能做出的判断。如果你打算做自己的写作 Skill我的建议是先花一个周末把自己的旧稿翻一遍把那些重复出现的纠结点写下来不管用什么工具先做一个极其简陋的第一版然后用它写三篇文章记录每个不舒服的瞬间最后只针对系统型问题做修改不要贪多求全。经验化成一个文件并不难难的是你愿意花时间去面对那些你其实早就知道的、只是从来没写下来的东西。