# Nextclaw Product Blog Storytelling

> 当为 NextClaw 写产品博客、官网短文、发布叙事、功能优势、社区稿或配图 brief，并需要把愿景、证据、用户任务和差异化收敛成可信公开内容时使用。

- Skill: `peiiii/nextclaw-product-blog-storytelling` (Agent Skill)
- Install (CLI): `npx skillmds@latest add peiiii/nextclaw-product-blog-storytelling`
- Raw SKILL.md: https://api.skillmd.com/api/skills/peiiii/nextclaw-product-blog-storytelling/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: peiiii (https://skillmd.com/u/peiiii)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/peiiii/nextclaw-product-blog-storytelling

---


# 产品博客叙事

## 候选与提前成稿

博客不必等到版本发布后才开始。用户明确要求写作，或 Delivery 判断一个已验证结果具备独立用户任务、可核查证据和公开叙事价值时，进入本 skill；changeset 本身不自动等于博客候选。

按事实成熟度选择一个状态：

- 证据或产品边界尚未稳定：只报告候选主题和缺失证据，不创建正文；
- 实现、Validation 与 Review 已稳定：可提前写入 `docs/blog-drafts/YYYY-MM-DD-<topic>.blog-draft.md`；
- 获得正式发布授权：按实际发布日期迁入 `apps/docs/zh/blog` 与 `apps/docs/en/blog`，并同步 index、sidebar 和适用链接。

内部草稿不参与站点构建，也不代表文章已发布。草稿正文只保留未来读者需要看到的内容；候选判断、私有路径、测试会话 ID、发布步骤和内部取舍留在设计、迭代记录或协作回复中。实现或测量环境在成稿后变化时，发布前重新核对全部事实与指标。

需要随产品 changeset 一起发布时，草稿 frontmatter 写入 `releaseBlogTarget: next-stable`、`releaseBlogChangeset` 和 `releaseBlogState: draft`，changeset 使用 `<!-- release-note-blog: docs/blog-drafts/<file>.blog-draft.md -->` 绑定。发布准备时生成中英文正式文章、更新 index/sidebar，并把草稿状态改为 `ready`、补充 `releaseBlogZhPath` 与 `releaseBlogEnPath`。NPM 达到 `NPM_READY` 后，产品发布闭环会阻断仍处于 draft 或缺少正式入口的绑定文章；线上验证完成后再删除内部草稿。

发布关联的功能、优化和结果博客默认采用短篇结果营销稿：标题先写产品、成果和最强可核查数字，首屏直接回答“做成了什么、效果如何”；实现原理只保留理解结果所需的最少内容。只有用户明确要技术复盘、原理说明或产品判断时，才展开为科普或长文。标题可以强，但不能超出测量范围或把开发版本写成已发布。

## 写作流程

1. 对齐 `docs/VISION.md`，明确主题服务统一入口、能力编排、自感知、自治、自进化或生态扩展中的哪一点。
2. 从代码、文档、真实 UI、事件链路、发布记录或用户反馈找证据。证据不足的内容写成方向，不写成已完成事实。
3. 先选传播目标：发布关联的功能与优化使用结果营销短稿；状态报告使用结果摘要；只有用户明确要求时才写观点、科普或长篇故事。
4. 用一句话冻结核心事实，再写它支撑的具体用户任务；模型接入、安装 skill、连接渠道等能力入口本身不是用户任务。
5. 比较竞品前固定产品与版本，使用官方一手资料建立 `能力 | NextClaw | 对方 | 结论`。对方同样具备的能力不能继续称独有优势；文档未提及也不能断言不存在。
6. 区分“自身已有能力、产品重要特点、相对差异”，再核对控制边界、执行层、生命周期、组合方式和成熟度。
7. 写明能力边界和下一步，不把底座、方向或概念图包装成现成功能。
8. 公开正文由 Wiki 中的[用户内容边界](../../wiki/skills/content/user-facing-content-boundary/SKILL.md)约束；分类过程、模板解释和取舍理由留在协作材料，不进入发布稿。

## 默认文章结构

```md
## 摘要

一句话结论 + 3-5 条可核查事实。

## 当前结果

用表格列能力、状态和用户可见结果。

## 能力边界

列尚未完成的范围。

## 下一步

列 2-3 个后续方向。
```

正文短、硬、可核查；多用“当前、已具备、未完成、下一步”，少用情绪转场、排比和“大 V”腔。事实说明可在此基础上扩写；只有用户明确要观点、传播稿或发布故事时，才增加问题、判断、取舍和用户使用路径。

## 配图选择

先写一句“图片必须让用户看懂什么”，再比较至少 2-3 种形式：

- 真实/标注截图：已上线能力的首选，可信度最高；
- 概念化产品图：跨多界面或尚在产品化的能力，必须明确是概念表达；
- 信息图/流程故事板：结构判断、对比、before/after 和用户旅程；
- 抽象氛围图：默认不选，不能替代产品证据。

功能跨多个界面时，截图覆盖真正承担说明责任的入口、管理面和结果面，不能用结果图替代完整链路。可信度和传播性冲突时，以截图作正文证据、概念图作 hero。

配图后自评：视觉焦点是否命中核心亮点；是否有任务、状态、进度、工具或统一工作台等证据元素；去掉标题后能否猜到主题；是否退化为机器人、科幻光效或泛 AI 氛围。未命中就改 brief 或重做。

## 质量门

文章必须有具体用户任务、证据锚点、明确判断和能力边界；普通用户能读懂，技术用户能核查。禁止“革命性、颠覆性、前所未有”、万能产品叙事、纯 changelog 和无证据优势宣称。