研究写稿Skill | 从选题到成稿

title: " 研究写稿Skill | 从选题到成稿" category: 人工智能 tags:

• 大模型API中转站
• Deep Research
• Humanizer
• wewrite
• 内容写作
• 4SAPI description: "详细拆解 Deep-Research-skills、wewrite、Humanizer-zh、oh-story-claudecode 和 marketingskills 在中文内容创作中的定位，给出选题、调研、写稿、改稿和复盘流程。"

很多内容团队不是不会写，而是每天卡在三个地方：

不知道写什么
  -> 找到选题后没有足够资料
  -> 写出来像 AI 模板文

这三个问题对应五个 Skill：

这五个不是互相替代，而是分工不同。真正好用的流程，是让它们各做一段。

1. Deep-Research-skills：先把“写作材料”准备好

项目地址：Weizhena/Deep-Research-skills

截至 2026-06-17，GitHub API 查询约 1.1k star。项目描述是面向 Claude Code、OpenCode 和 Codex 的结构化深度研究 Skill，支持两阶段调研：先生成 outline，再深度调查，并且强调人在回路控制。

这类 Skill 的核心价值不是“帮你搜网页”，而是把调研拆成明确动作：

提出研究主题
  -> 生成调研对象和字段
  -> 人工补充或删改范围
  -> 并行调研每个对象
  -> 生成 JSON 结果
  -> 汇总成 Markdown 报告

它内置的命令包括：

1.1 适合写哪类文章

Deep-Research-skills 适合资料密度高的内容：

不适合的场景也要说清楚：

1.2 一个适合博客选题的调研提示词

可以这样用：

Use the research skill to build an outline for:

中文内容创作者如何选择开源 AI Skill 工具链。

请把调研对象限定在：
1. Deep-Research-skills
2. wewrite
3. Humanizer-zh
4. guizang-ppt-skill
5. guizang-social-card-skill
6. awesome-gpt-image-2
7. anything-to-notebooklm
8. Youtube-clipper-skill
9. oh-story-claudecode
10. marketingskills

字段包括：
- 项目定位
- 主要功能
- 适合场景
- 不适合场景
- 安装或使用门槛
- 内容创作流程里的位置
- GitHub star 和 license
- 需要人工复核的风险点

这个提示词的关键是“限制对象和字段”。不要让模型自由发挥“帮我研究所有内容创作工具”，那样会查得很散。

1.3 成本控制

深度调研很容易烧调用量。建议把 4SAPI 的模型路由分成两层：

如果每个选题都用最强模型从头查到尾，内容团队很快会觉得“AI 很贵”。更稳的做法是把调研限定在真正需要的选题上。

2. wewrite：公众号的一条龙编辑部

项目地址：oaker-io/wewrite

截至 2026-06-17，GitHub API 查询约 2.4k star。项目定位是公众号文章全流程 AI Skill，从热点抓取到草稿箱推送。

它的流程很适合公众号运营：

写一篇公众号文章
  -> 抓热点
  -> 选题评分
  -> 框架选择
  -> 素材采集
  -> 内容增强
  -> 写作
  -> SEO 优化
  -> AI 配图
  -> 微信排版
  -> 推送草稿箱

README 里提到的核心能力包括热点抓取、SEO 评分、10 个选题三维评分、7 套写作骨架、真实信息锚定、风格注入、16+ 排版主题、微信兼容修复和草稿箱 API。

2.1 它适合谁

wewrite 的价值不只是“写文章”，而是把公众号这件事拆成了完整管道。

很多人写公众号只关注正文，实际发布时才发现还有这些琐碎工作：

• 标题是否有搜索词。
• 摘要是否能承接标题。
• 封面是否适合 21:9。
• 正文是否适合微信阅读节奏。
• 是否需要提示框、引用框、代码块。
• 是否能进入草稿箱。
• 发布后有没有阅读数据复盘。

wewrite 把这些都纳入了流程。

2.2 适合的指令

/wewrite 写一篇关于 AI 内容创作 Skill 工具链的公众号文章。

要求：
1. 面向独立创作者和小团队。
2. 重点讲清楚选题、调研、写稿、配图和分发流程。
3. 标题给 5 个备选。
4. 正文保留“人工复核”和“合规边界”段落。
5. 不要夸大自动化效果。

如果你不想让它全自动，可以加一句：

请使用交互模式，在选题、框架、配图三个节点暂停让我确认。

对公众号团队来说，这句很重要。越接近发布，越要让人有机会刹车。

2.3 不要把草稿箱当发布按钮

wewrite 可以进入微信草稿箱，但草稿箱不是终点。

发布前至少检查：

公众号内容尤其要谨慎。模型能帮你生成草稿，但不能替你承担读者信任。

3. Humanizer-zh：把“正确但难读”改成人话

项目地址：op7418/Humanizer-zh

截至 2026-06-17，GitHub API 查询约 10.4k star。项目说明是 Humanizer 的汉化版本，Claude Code Skill，旨在消除文本中的 AI 生成痕迹。

它的 README 里强调，它不是为了欺骗检测器，而是为了提升写作质量。这个定位很关键。

AI 文案常见的问题不是“错”，而是太平、太满、太模板化：

Humanizer-zh 会扫描这些模式，再把问题片段改得更自然。

3.1 最适合放在哪一步

不要一开始就用 Humanizer-zh。它适合放在最后两轮：

资料调研
  -> 大纲
  -> 初稿
  -> 事实复核
  -> 结构修改
  -> Humanizer-zh 口吻编辑
  -> 人工终审

如果初稿事实不准，先人话化没有意义。它会把错话改得更像人说的错话。

3.2 一段实用指令

请用 Humanizer-zh 审阅这篇文章。

目标：
1. 去掉明显 AI 腔、翻译腔和空泛总结。
2. 保留技术事实、表格、代码块和链接。
3. 不要为了口语化牺牲准确性。
4. 标出你改动最大的 5 处，并说明原因。
5. 不要增加未经验证的新观点。

这里要特别强调“保留技术事实”。技术博客和测评文章不能为了好读，把限定条件删掉。

3.3 它不是洗稿工具

Humanizer-zh 适合改自己的初稿，不适合拿别人的文章来“降重”。内容团队可以把边界写进规范：

Humanizer-zh 只能处理：
- 自己写的初稿
- 已获得授权的稿件
- 团队内部文档
- 需要改口吻的产品资料

不得用于：
- 洗稿
- 规避版权
- 掩盖虚假来源
- 把未经授权内容伪装成原创

这个边界比技术细节更重要。

4. oh-story-claudecode：小说和故事创作的选题雷达

项目地址：worldwonderer/oh-story-claudecode

截至 2026-06-17，GitHub API 查询约 2.6k star。项目描述是网文/小说写作 Skill 包，覆盖长篇与短篇网络小说的扫榜、拆文、写作、去 AI 味、封面图全流程。

它和前面的工具不太一样。Deep-Research-skills 更偏事实研究，wewrite 更偏公众号，oh-story-claudecode 更偏故事生产。

适合场景：

4.1 内容创作者也能用

即使你不写小说，它也有参考价值。

很多公众号文章、短视频脚本、小红书笔记，本质上也需要故事：

• 一个真实场景。
• 一个矛盾。
• 一个选择。
• 一个结果。
• 一个反思。

如果你的文章总是像说明书，可以借 oh-story-claudecode 的思路改开头：

请从故事写作角度重写这篇技术文章的开头。

要求：
1. 不虚构人物姓名和具体数据。
2. 用一个常见工作场景引入问题。
3. 第一段控制在 150 字以内。
4. 不使用夸张情绪。
5. 保留后文要解决的技术问题。

4.2 不能做什么

故事类 Skill 最容易滑向“模仿爆款”。要把研究和抄袭分开。

可以做：

• 分析题材趋势。
• 总结开篇结构。
• 提炼常见冲突。
• 学习节奏和信息释放。

不要做：

• 复制具体情节。
• 改名复刻人物。
• 仿写某个作者的可识别风格。
• 把平台榜单内容当成自己的原创素材。

内容创作要借鉴结构，不要搬运表达。

5. marketingskills：英文营销技能库

项目地址：coreyhaines31/marketingskills

截至 2026-06-17，GitHub API 查询约 33.6k star，是这 10 个项目里 star 最高的一个。项目描述是面向 Claude Code 和 AI agents 的营销技能库，覆盖 CRO、copywriting、SEO、analytics 和 growth engineering。

它最适合三类人：

5.1 中文团队怎么用

不要直接把英文营销方法硬翻成中文。英文 landing page 常见的强 CTA、社会证明、痛点拆解，在中文公众号或小红书里不一定自然。

更适合的用法是提取框架：

请参考 marketingskills 的营销思路，帮我分析这个产品页。

输出：
1. 目标用户是谁。
2. 首屏承诺是否清晰。
3. 痛点和收益是否具体。
4. 证据是否足够。
5. CTA 是否过早或过多。
6. 如果改成中文公众号文章，哪些表达需要本地化。

5.2 适合和 4SAPI 结合的地方

营销类任务适合做 A/B 版本，但也容易浪费调用量。可以这样分层：

不要把“生成更多版本”当成优化。真正的优化要回到点击率、转化率、停留时长和用户反馈。

6. 五个 Skill 串成一条写作流程

如果目标是一篇深度公众号或技术博客，可以这样搭：

Step 1 选题
  wewrite 生成热点和选题
  marketingskills 提供营销/增长角度
  oh-story-claudecode 提供故事化开头或用户冲突

Step 2 调研
  Deep-Research-skills 生成 outline
  人工删掉不相关对象
  /research-deep 做分项调查
  /research-report 汇总为报告

Step 3 写稿
  wewrite 选择框架
  结合调研报告写初稿
  4SAPI 路由到适合中文写作的模型

Step 4 改稿
  人工核对事实、数据、链接和引用
  Humanizer-zh 改口吻
  再人工终审

Step 5 复盘
  记录标题、阅读、收藏、转发、评论
  下次选题时喂给 wewrite 或自定义提示词

这条流程不是最短的，但比较稳。它把“灵感、资料、表达、平台、复盘”分开处理。

7. 一个可复制的文件结构

建议给内容项目建一个小仓库：

content-pipeline/
  README.md
  sources/
    links.md
    notes.md
  research/
    outline.md
    report.md
  drafts/
    2026-06-17-skill-tools-draft.md
  final/
    2026-06-17-skill-tools.md
  prompts/
    research.md
    wewrite.md
    humanizer.md
  review/
    fact-check.md
    publish-checklist.md

每个目录的责任：

这样做有两个好处：

1. 下次写同类文章时可以复用资料和提示词。
2. 出错时能追溯，是资料错、模型错，还是人工判断错。

8. 发布前检查清单

用这些 Skill 写出的内容，发布前建议过一遍检查清单：

这张表可以直接放进 review/publish-checklist.md。

9. 总结

研究写稿这件事，最怕把所有任务都塞给一个模型。

更稳的分工是：

wewrite 负责公众号流程
Deep-Research-skills 负责资料和报告
Humanizer-zh 负责中文口吻
oh-story-claudecode 负责故事感和选题脑暴
marketingskills 负责营销和出海框架

配合 4SAPI 这类大模型API中转站，你可以把低成本模型、强推理模型和多模态模型分开调用，既控制成本，也减少质量波动。