这阵子我在整理过去十年的写作笔记，越整理越觉得亏：经验攒了一大堆，但每次提笔还是靠感觉、靠状态，换个场景就失效。后来我索性把这些笔记里能用的部分，全部拆碎、归类、重构成一个叫phodal-writer的 Skill。它不是什么高阶魔法，说白了就是把我的写作方法论变成一套 AI 能读懂、能执行的规则包。这个 Skill 解决的核心问题，不是“帮你写一篇文章”，而是“让 AI 在写得像你、按你的套路推进、还能在你偷懒的时候主动自检”。如果你也在写作、做内容、或者想把个人方法论沉淀成可复用的 AI 工作流，这篇就是给你参考的完整拆解过程。
网上聊 Prompt 的文章很多，但真正聊“如何把自己的工作经验整理成技能包”的少。我这次不打算只给一段花哨的提示词，而是把整个思考过程、规则提取方法、结构设计、以及调试阶段踩过的坑都摊开讲，能直接落地。
1. 为什么要给写作经验做“结构化封装”
1.1 Skill 不是大号 Prompt
先说清楚概念。一个普通 Prompt 是“一次性设定的对话开头”，你这次跟 AI 说“你是一位资深编辑”，它这次会听话，下次换了对话它可能就忘了。而 Skill 是“一套可复用的组件”，它包含角色设定、核心规则、执行流程、参考示例、自检清单，可以被打包、被版本管理、被反复调用。打个比方：Prompt 是你临时叫来帮忙的朋友，Skill 是你的编辑手册——手册里的流程不会因为朋友今天心情不好就变形。
我做phodal-writer时，给自己的要求是：不看它写出来的表面句子，而是看它“遇到各种写作场景时，是否会稳定地执行我脑子里的那套判断标准”。比如我文章里很少用“综上所述”这类收尾，Skill 里就明确写了一条“禁止在结尾出现总结性废词”；我写小标题喜欢用“动作+疑问”，Skill 里就规定“标题要么带动词、要么带冲突，不允许出现‘介绍、分析、探讨’这类开场白”。这些不是大而化之的风格描述，而是可验证的硬规则。
1.2 写作经验为什么难迁移
经验这东西，最难的不是积累，而是“从自己脑子里搬到别人脑子里”。你可能无数次跟同事说“标题要起得有网感”，但“网感”是什么？长度？句式？有没有数字？是不是制造了认知冲突？你没法说清。这就是隐性知识，它藏在你过往的成功选题和打开率数据里，连你自己都没总结过。
我刚开始整理时，翻自己过去五年的每篇文章标题，硬是扒出了几个高频规律：标题在20到24字之间打开数据最好；带具体数字的比带形容词的稳定；有明确反常识点的比普通陈述句多一倍转发。这些一度只存在于我的“手感”里，当我真正把它们写成规则时，才有机会变成 AI 可以执行的指令。所以整理 Skill 的第一步不是写提示词，而是做一次“经验显性化”的苦活。
1.3 做成 Skill 的三个实际收益
很多人觉得“我把个人说明发给 AI 不也一样嘛”。区别在于三点。第一是可持续：普通对话关掉就没了，但 Skill 文件可以持续迭代，今天发现一条新规则直接加进去，下次依然生效。第二是可测试：我改一条标题规则，拿同样的旧选题跑三遍，输出风格差异一目了然，改提示词做不到这么严谨。第三是可组合：写作 Skill 可以和选题分析 Skill、素材检索 Skill 联动，形成一个完整的内容生产链。
也就是说，整理 Skill 的本质不是“喂 AI 一段漂亮话”，而是“给自己建立一套可以复用、验证、迭代的方法论接口”。
2. 把十年经验拆成可执行规则的实操方法
2.1 先做一次穷举式盘点
别急着写任何 AI 相关的文件。我建议你先准备一个表格，横轴是写作环节：选题、标题、开头、结构、论证、结尾、修改；纵轴是文章类型：教程、观点、复盘、推广软文、行业观察。然后一个格子一个格子地问自己：“这一格，我通常会怎么做？”
比如“教程类文章的开头，我通常会先抛一个问题，再给承诺，30秒内让读者知道读完全文能得到什么”；“观点文章的结尾，我不总结，而是抛一个反常识提问”。把这些全写下来，哪怕是零碎短语也行。这一步做得越细，后面 Skill 的可用性越强。
我在盘点中发现一个很有意思的事：很多我认为自己“一定是这样写”的环节，其实根本没固定套路。没有固定套路就是 AI 最擅长的发挥空间吗？恰恰相反，它意味着输出不稳定。所以盘点时要区分“我能说清的”和“我只知道好坏但说不清为什么”的。前者直接成为规则，后者需要额外做几步分析才能转化。
2.2 用“铁律、偏好、禁区”三层过滤经验
如果所有经验都写成硬性要求，AI 会陷入“规则打架”的状态。我最终把提炼出的经验筛成三层。
| 层级 | 含义 | 示例 |
|---|---|---|
| 铁律 | 违背了就不是我的文章 | 每个 H2 小标题必须对读者有明确收益点，禁止空话套话 |
| 偏好 | 多数时候这样更好但允许例外 | 开头第一句优先用事件/问题切入，偶尔可以用场景描写 |
| 禁区 | 哪怕看起来合理也绝不使用 | 不写“随着技术的发展”式开头，结尾不做归纳总结 |
铁律数量必须克制，我最终只留了12条。偏好可以多一些，作为风格化参考。禁区要写得非常具体，不能用“不要啰嗦”这种表达，必须说清楚“哪种句子算啰嗦”，比如“同一段落内出现两次相同意思的铺垫”。
这个三层结构背后的逻辑是：模型对规则的理解是概率性的，规则之间如果有冲突，它往往随机选一个。铁律给确定性，偏好给灵活性，禁区给底线，三者能明显降低输出失控的概率。
2.3 用自己过去的文章反向蒸馏
这是我认为最值得做、也最容易被忽略的一步。规则如果只靠回忆，一定漏掉很多东西。我在完成初步盘点后，挑选了10篇风格差异比较大的旧文章，一篇篇上了“解剖台”：开头怎么写、段落之间靠什么衔接、什么时候插案例、什么时候甩数据、结尾用什么情绪收场。
比如我发现自己写长文有个隐藏习惯：每两到三个自然段里，至少有一段是带具体场景细节的，像“我打开后台看到某篇文章在第三天突然被大量转发，当时的第一反应不是开心，是紧张”。这种细节不是刻意加的技巧，而是我天然的节奏感。可如果不做反向提炼，我永远不知道把它写成规则。
蒸馏出的成果不要只留“我习惯插案例”这种结论，要留原句片段。这些片段我会直接作为 Skill 的 Few-shot 示例，告诉 AI：“看到没有，这是我过去真实写出来的段落。新文章里如果出现类似场景，请保持这种画面感和节奏。”后文我会展开讲示例文件的具体组织方式。
3. Skill 的 Prompt 结构设计与关键写法
3.1 用伪代码描述工作流
传统 Prompt 喜欢写一大堆“你需要做到……”的散文，效果其实一般。我更推荐用接近配置文件的“伪代码”来写，结构固定、意图清晰、调试方便。这是我的 Skill 主文件精简后的骨架：
role: 资深非虚构写作者 profile: 十年写作经验，擅长技术科普、经验复盘、行业分析 goal: 在给定选题下，输出一篇符合 phodal 风格的完整文章或文章框架 input: - 主题 - 读者画像 - 发布平台 - 目标篇幅 - 语气基准 rules: - 铁律：每个 H2 小标题必须是读者收益或冲突视角，不用陈述句标题 - 铁律：每个核心观点必须回答“为什么”，不允许只给结论 - 铁律：结尾禁止总结，禁止“总之”“综上所述” - 偏好：每 300 字左右至少出现一个具体的人、事、数据或场景细节 - 禁区：不出现“赋能”“抓手”“闭环”等词 workflow: 1. 识别文章类型（教程、观点、复盘、分析） 2. 针对选题输出“读者问题清单”，不少于 5 个真实问题 3. 输出标题候选 5 个，每个标出满足哪条铁律/偏好 4. 输出文章骨架，每个 H2/H3 标注“读者在这里能得到什么” 5. 按骨架生成正文，每写一个 H2 后先自评一次 6. 完成后执行自检清单，输出体检表 memory: - 记录本文用了哪些开头类型，便于下一次调用时切换 - 记录本次违反的规则，输出在自检表底部用 YAML 式结构而不是自然语言长文，有两个理由。第一，模型对高度结构化的指令遵循度更好，因为它的注意力能轻易落在每个字段上；第二，你可以在调试阶段清晰地判断是哪个字段写错了，而不是在面对一大段“人话”时无从下手。
3.2 把模糊经验改写成动作指令
这一步考验的是“翻译能力”。你要把“好文章要有对象感”翻译成 AI 能执行的具体动作。
| 模糊经验 | 改写后的动作指令 |
|---|---|
| 标题要吸引人 | 标题必须包含一个具体数字或反常识名词，禁止只用形容词堆情绪 |
| 开头要有代入感 | 开头前80字内出现人物或事件，禁止用定义或背景介绍开场 |
| 论证要有说服力 | 每个论点至少同时给出案例支撑和反方观点回应 |
| 语言要生动 | 每三个自然段必须有一个可被读者看见、听见或感受的细节 |
“翻译”时要不断检查每个词。比如我最初写“案例必须具体”，AI 给的案例还是虚的，于是我改成“案例中必须出现可核实的动作：谁在什么时间做了什么，产生了什么结果。禁止用‘某人’‘有一个朋友’这类模糊主语”。改完之后输出质量立刻不一样。
3.3 强制输出自检清单
Skill 的最后一环，是让 AI 在写完文章后给自己打一次分。这不仅是形式主义，它能逼模型回看自己生成的文本，是降低低级错误最有效的手段。我在工作流里规定了输出自检表：
- 是否在前80字内建立了读者收益预期？
- 每个 H2 是否都回应了最开始的“读者问题清单”？
- 是否出现至少一次具体场景描写？
- 结尾是否没有出现总结性段落？
- 是否有任何一句可以直接删除而不影响上下文衔接？
- 写作过程中是否违反了 memory 里记录过的旧错误？
要求模型给自己打分还不够，我会要求它对每项给出一句证据，防止它瞎编。证据就是引用原文的对应句。
这样做还有意外收获：自检清单实际承载了“我过去的犯错经验”。比如我过去常犯“结尾强行升华”的毛病，在清单里列出来后，AI 每次都会专门检查这一项，相当于把我的教训变成自动化检查点。
4. 资源文件和上下文管理策略
4.1 不要把所有内容塞进一个文件
一开始我也犯过这个错误，把标题规则、开头规则、示例片段、写作禁忌全塞在一条系统提示词里。结果模型越到后面越“迷”，前面的规则记住了，后面的规则全忘。后来我参照工程领域“模块化”的思路，把 Skill 拆成以下目录结构：
phodal-writer/ ├── instruction.md # 角色、核心流程、调用入口 ├── rules.md # 铁律、偏好、禁区明细 ├── workflow.md # 各环节的处理步骤与方法 ├── examples/ │ ├── opening.json # 10 个不同风格的开头示例 │ ├── ending.json # 5 类结尾写法及反例 │ └── full_demo.md # 一篇完整标注文章 ├── resources/ │ ├── headline_hits.md # 多年高打开率标题汇总 │ ├── switch_words.md # 常用段落衔接词与场景 │ └── anti_patterns.md # 历史踩坑错误模板 └── checklist.md # 每次交付后的自检表这种拆分在普通聊天里看似“多余”，但真正用起来很方便。比如我想调整结尾风格，只需要打开examples/ending.json改一个文件，不影响其他部分；我想要测试“标题规则是否更优”，也能单独切换资源的版本。
4.2 按需加载，避免上下文污染
上下文长度是有限资源。如果把十年的索引、标题库全部塞进主指令，AI 很快就会在长文章写作中把前面的参考忘了。我的处理方式是在workflow.md里写清“读取条件”：
- 当用户要求“起标题”时，读取
resources/headline_hits.md； - 当用户要求“写开头”时，读取
examples/opening.json； - 当生成正文但不确定段落衔接时，读取
resources/switch_words.md； - 每次输出结尾前，先读取
examples/ending.json中的反例列表。
也就是说，Skill 内部不同场景分别“打开”对应的资料，而不是让所有资料常驻。你可以在主指令里用“任务开启后如果需要以下资源，请先读取”这类方式引导模型按序调取。
这个方法的代价是模型偶尔会“忘读”，所以我会在 workflow 步骤里设置检查点：“完成 H2 后，确认是否已引用过至少一个资源文件中的内容，如果没有，请回到资源目录重新读取”。相当于给执行过程加上一个触发钩子。
4.3 输入信息不足时，先完成“需求五问”
如果你只给 AI 一个主题让它直接写，它一定会写出“正确但平庸”的稿子。这和你的 Skill 再强都无关，因为输入信息不足，模型只能用默认的最高概率路径来写，那种路径往往是平均化表达。
我在phodal-writer里设置了一个硬性步骤：开始动笔前，如果用户没有主动提供以下信息，AI 必须先向用户提问。
- 这篇文章的主要读者是谁？
- 发布平台是什么？这决定标题风格、段落长度和行文密度。
- 目标篇幅多少字？这决定 H2 数量与论证深度。
- 你希望读者读完做什么？收藏、评论、转发，还是理解一个概念？
- 有没有需要刻意避免的话术或偏好？
这样设计之后，输出质量稳定了不少。哪怕用户回答“我也不知道”，AI 也会按默认模式（读者为普通从业者、平台为个人博客、目的是理解概念）来生成，而不是悬空发挥。
5. 调试阶段最常见的四个问题
任何 Skill 都不可能一次写对。我调phodal-writer的过程大概花了三周，下面四个问题最具代表性。
5.1 规则写了，模型就是不听
最让人崩溃的现象是：规则明明写得很清楚，AI 还是产出“综上所述”式结尾。我排查后发现原因通常这么几种。第一，规则数量太多。超过20条硬规则后，模型的注意力会集中在最前面几条，后面的就变成了装饰。第二，规则本身太抽象。比如“逻辑要清晰”这种，它不知道怎样才算清晰。第三，只有正面要求，没有反面示例。你光说“结尾不要总结”，它不知道总结长什么样，你必须给它一个错误示例。第四，缺少自检反馈。生成了错误内容也没被纠正，下次自然再犯。
我的解决方案：把铁律压到12条以内；给每条铁律配一对“对/错”示例；工作流末尾执行自检环节。这四步做完，规则遵守率有质的提升。
5.2 输出风格不像自己
我在最早几版测试时，发现 AI 写出来的文章虽然规则全对，但读起来就是“AI 味过重”。后来我意识到，问题出在“示例不够”“示例过于规整”。我把自己的旧文章片段原封不动丢进examples/，不加修饰，不提炼总结，就是让它模仿原文的气口。同时我给每条示例加了“特征标注”：
- 这段开头用了一个短句制造悬念，然后立刻进入事件。
- 这段中间插入了一个括号内的自我反问，形成节奏停顿。
- 这段结尾没有给出答案，而是回到开头人物的某个动作。
这些标注相当于把“风格”拆解成可学习的局部特征，AI 不是玄学式模仿，而是照着特征点逐个对齐。
5.3 Skill 越调越复杂，反而变蠢
一个真实存在的陷阱：你在测试中发现一个漏洞，就往 Skill 里加一条规则；发现一个例外，又加一条。加到第三周，Skill 文件已经膨胀到一次对话快塞不下，输出也越来越模板化。
后来我给自己定了一个“精简三问法”。每次想加新规则时先问自己：这条规则能解决过去三次以上出现的问题吗？它是否和已有规则冲突？如果没有它，模型大概率也会做对吗？三问都通过才允许加入。同时，要定期统计哪个资源文件被读取次数最少，果断删掉那些“备用资料”。一个精简、每条规则都有效的 Skill，远比一个什么都能提一嘴的巨型 Skill 好用。
5.4 长文写到一半，前文规则失效
写长文时模型容易出现“后半程失焦”：前面很守规矩，写到第四个 H2 之后开始无限制发挥。这个问题不能靠规则堆砌解决，我的办法是分段生成 + 阶段性回读。工作流中规定：每写一个 H2，AI 必须先回读前面已经生成的小标题与核心论点，再继续下一部分；同时每完成一半篇幅，就执行一次简化版自检，只检查“是否偏离读者问题清单”和“是否重复使用上一个段落的表达模式”两项。这相当于给它一个短期记忆刷新点，对抗上下文注意力衰减。
6. 持续维护：让 Skill 跟着你的经验一起成长
6.1 给 Skill 做版本标记
我把phodal-writer当成一个独立的小项目来维护，每次修改都同步更新版本号和变更说明。比如v0.3.2 去掉标题规则中的“含数字”硬条件，改为偏好；v0.4.0 新增资源文件 anti_patterns.md，补充三类最容易犯的结尾失误。这样做最大的好处是，当你发现改动后效果变差时，能立刻回滚到上一版本。
调试时我还会为每一次测试保留“输入-输出-问题判定”三行记录。输入就是当时的测试选题，输出是模型生成的片段，问题判定是我的点评。几轮迭代后，再翻这些记录，你能看到自己从“凭直觉调 Prompt”到“系统性修正规则”的转变。
6.2 一次只改一个变量
这是工程师都知道、但做 Prompt 时容易被忽略的原则。如果你同时改了两条规则和三个示例，输出变了你根本分不清是哪个改动起了作用。我每次只改一个文件、只动一个参数，然后用同样的三条测试输入去跑对比。测试输入我专门准备了三类：一篇经验教程型、一篇观点分析型、一篇复盘反思型，覆盖我的主要写作场景。
6.3 持续回流旧文章，补充语义样本
Skill 不是一次性做完就结束了。我现在每隔一段时间，就会把新写的、反响好的文章片断重新转成示例或规则。写作规律会随着平台、读者、阶段变化，Skill 也必须跟着刷新。比如过去我很少写短句开头，但有一段时间笔记平台的数据表明短句开头更容易被读完，我就在偏好区增加了这条观察。这套东西就像一个个人知识库，要不断把新经验同步进去。
最后再分享一个我个人很受用的做法：在整理phodal-writer的第三天，我突然意识到，这个 Skill 最值钱的部分不是让 AI 生成的文章有多漂亮，而是它逼着我把过去很多“说不清但对”的直觉写成了一条条可解释的判断标准。有了这些标准，AI 写得像我的旧文只是基础收益，更大的收益是我自己再写新文章时，思路会比以前更清晰。你与其说是在做 AI 技能包，不如说是以工程化的方式重新认识了一遍自己的专业积累。
