我以前写作，把一个主题扔给 Codex，几分钟后就能拿到一篇结构完整的稿子，但是说实话，无论怎么调整提示词和 skill 工作流程，最终生成的文章，还是不够看。
资料从哪里来的说不清，每一节都像同一个模板复制出来的，句子很顺，但 AI 味也很明显。
所以我已经放弃使用一个 skill 来写作的模式了，无论那些写作 skill 吹得多么天花乱坠，我觉得都不太行。
我最近研究了一套写作流程，目前使用下来的感受是，虽然还是需要人工修改一部分，但是整体已经能够很好的提高效率了，目前还在最后的调测阶段，后面也会开源出来，到时候大家给捧捧场，走个面儿哦。
然后今天分享的，是已经开源在 GitHub 上的，可能不是很著名，但是依旧非常给力的几个写作 skill，同时也结合了我最近的一些思考，先分享给大家。
一条万能提示词远远不够
Skill 就是一套可以重复使用的工作流程，里面可以写输入要求、执行步骤、输出格式，也可以放资料、脚本和检查规则。
写一篇文章，表面上看只是打字，实际上同时包含了找资料、定主线、挑结构、保留个人语气、核对事实和终稿校对等等步骤。如果把这些都压给一个“帮我写篇文章” 的 skill，那模型只能先选一条最常见的路走完，没有办法兼顾所有。
所以还是那句话，与其去追求一个 skill 把所有的事情都搞定，还真不如让多个 skill 分工合作，大家各司其职，可能效果要好得多。
先把资料和结构打牢
很多时候我们写文章，收集资料都是第一步，有时候我看着别人的文章各种引经据典，其实就很好奇，这些大佬都是怎么找资料的，感觉这些找资料的时间要占据大部分写作时间啊。
直到我找到了下面这个 skill，你别说真的挺好用的，Content Research Writer。
https://github.com/CommandCodeAI/agent-skills/blob/main/skills/content-research-writer/SKILL.md
它的主要工作就是研究、引用和输出大纲。当接收到用户给的主题、受众和文章目标之后，该 skill 就会开始搜资料、补引用、改开头，后面还能按章节给出反馈。
我觉得它最好的地方，是给作者留了很多发挥空间。你可以只让它查一个问题，也可以拿自己刚写好的某一节让它找逻辑漏洞和补充信息。
AI 负责找材料和打辅助，我们自己依然把握着文章的整体方向。
现在资料齐了，文章的骨架也搭建好了，但是还有一个重要的需要注意的点，有时候提案、PRD 和决策文档里面，大量的背景信息可能只有作者才知道，需要做成必要的解释才行。
这时可以看看 Anthropic 开源的 Doc Co-Authoring。
https://github.com/anthropics/skills/blob/main/skills/doc-coauthoring/SKILL.md
这个 skill 会先引导用户把背景信息全部输出出来，再逐节搭文档，最后让一个没有前文记忆的新 Agent 做读者测试这一块。
这个读者测试很有意思，因为很多时候作者觉得顺畅的地方，陌生读者可能根本接不上。有了读者测试，就能提前发现这些隐藏的坑，看到一个改正一个。
真正的风格可不是几句口头禅
现在文章的研究和结构部分做好了，只是文章可能还是不像你，它没有你的写作风格，这个时候一般人可能会来一句“请用口语化的风格输出一篇文章”。
这样做的效果显然不会太好，口语化的范围太宽了。一个人写公众号、回邮件和发群消息，语气本来就不一样，而且更重要的是，写文章一定要留下属于自己的语言风格，这样读者才能一下子记住你。
这里我推荐这个 skill，Ghostwriter 的思路很精细。它用 soul.md 记录跨平台的个人特征，再用 blog.md、slack.md 这类平台文件控制具体场景下的语气。同一个人的核心表达习惯留着，但是文章和消息又不会像从一个模板里刻出来。
https://github.com/mblode/ghostwriter
它还拆出了 train-ghostwriter 和 evaluate-ghostwriter。一个用自己的历史文本建风格档案，另一个用盲测比较风格档案有没有帮上忙，这样做肯定比简单收集几个“高频词语”更靠谱。
当然要想发挥这个 skill 的最大价值，真正费心力的部分还是挑选能代表自己的文章和文字，如果样本选错了，风格档案学到的也只会是某几篇稿子的偶然习惯，那最后生成的文章肯定要变味了。
产品文案和技术文档，各自有一套写法
很多人可能会用一套 skill 来写所有类型的文档，其实我觉得不同类型文档用不同的 skill，可能会更好。
比如 Copywriting 可以用来写落地页、产品介绍、CTA、引导语和邮件标题。
https://github.com/mblode/agent-skills/blob/main/skills/copywriting/SKILL.md
它在动手前会先看页面要推动什么动作，读者是谁，产品能带来什么具体结果，还会看读者从哪个入口过来。这几个问题确定了，最终生成的文案才更贴近我们想要的。
Copywriting 还会告诉大模型什么时候应该交给别的 Skill，而不是大包大揽的做所有事情，任务范围窄一点，反而跑起来更稳定。
同一个仓库里的 Docs Writing 则主要处理技术文档。
https://github.com/mblode/agent-skills/blob/main/skills/docs-writing/SKILL.md
它按 Diataxis 把文档分成教程、操作指南、参考资料和解释文档，不同类型各有自己的文章结构。
它自身的验收标准也非常硬，它要求生成的产物，代码示例要真正能跑起来，链接要能打开，参数名要回到实现里去核对。技术文档读起来很顺只能算基本要求，读者能不能照着做成事，才是它最关心的结果。
这个仓库下面还有很多其他好用的 skill，大家可以挑选着去安装使用。
去 AI 味，应该放在写作的最后一步
最后一个是 Humanizer。
https://github.com/Aboudjem/humanizer-skill
其实现在去 AI 味的工具和 skill 有很多，我之所以选择这个 skill，是因为这个项目把 53 种 AI 写作痕迹放进规则库，做了检测、重写和直接编辑 Markdown 文件几种模式。
它还有多套写作风格配置和一个 0 到 100 的 AI 痕迹分数。
这个分数可以帮我们找修改方向，哪些高频词汇需要删掉，哪些段落太整齐、句长太平均，文章里面的转场每次是不是都类似等等。
还有一点很重要的就是它的事实保护机制。在进行去 AI 味改写的时候，不能为了显得更像真人，就悄悄加入原文没有的经历、数字和引用。如果为了让一篇文章读起来自然，但是事实却被改坏了，那这个代价太大，完全不能接受。
这 6 个 Skill，怎么串成一条线
其实我觉得没有任何一个 skill 是必备的，只有随着我们诉求的变化而变化的 skill 清单。
写公众号长文，可以先用 Content Research Writer 查资料和搭大纲，再让 Ghostwriter 调整个人风格，最后用 Humanizer 找结构和句子里的模板痕迹。
Content Research Writer → Ghostwriter → Humanizer写产品落地页时，路线可以短一些。Copywriting 先把目标读者和页面动作写准，Humanizer 再过滤一遍 AI 句子。
Copywriting → Humanizer技术教程需要多一道核对流程。前面先查资料，成稿后再检查代码、链接和参数是否真能用。
Content Research Writer → Docs Writing → Humanizer其实如果一个写作 Skill 越是声称自己什么都能写，我们越要翻开它的输入要求、任务边界和检查步骤看一遍。程序写了很长，不代表流程已经跑通，更不代表它能做的更好。
我觉得新人更应该从自己的痛点入手。比如资料总是不够，就先做研究 Skill，让收集资料慢慢的自动化起来；文章总是没有自己的味道，那就先建立风格档案；技术文档经常跑不通前后不搭边，就把验证脚本和验收门槛先补齐再说。
现在我更愿意把 Codex 当成一个可以分工的写作搭档。先让它把资料查好，再和我一起搭建文章结构。语气、专业格式和终稿检查，交给各自合适的 Skill。
不追求一个 skill 或者一个自动化流程搞定所有事情，很多时候，我宁愿多复制几次文案，多开几个窗口。
