--- name: nextclaw-product-blog-storytelling description: 当为 NextClaw 及关联产品写博客、官网短文、发布叙事、功能优势、社区稿或配图 brief，并需要把用户兴趣、愿景与证据收敛成可信公开内容时使用。 --- # 产品博客叙事 ## 候选与提前成稿 博客不必等到版本发布后才开始。用户明确要求写作，或 Delivery 判断一个已验证结果具备独立用户任务、可核查证据和公开叙事价值时，进入本 skill；changeset 本身不自动等于博客候选。 按事实成熟度选择一个状态： - 证据或产品边界尚未稳定：只报告候选主题和缺失证据，不创建正文； - 实现、Validation 与 Review 已稳定：可提前写入 `docs/blog-drafts/YYYY-MM-DD-.blog-draft.md`； - 获得正式发布授权：按实际发布日期迁入 `apps/docs/zh/blog` 与 `apps/docs/en/blog`，并同步 index、sidebar 和适用链接。 内部草稿不参与站点构建，也不代表文章已发布。草稿正文只保留未来读者需要看到的内容；候选判断、私有路径、测试会话 ID、发布步骤和内部取舍留在设计、迭代记录或协作回复中。实现或测量环境在成稿后变化时，发布前重新核对全部事实与指标。 需要随产品 changeset 一起发布时，草稿 frontmatter 写入 `releaseBlogTarget: next-stable`、`releaseBlogChangeset` 和 `releaseBlogState: draft`，changeset 使用 `` 绑定。发布准备时生成中英文正式文章、更新 index/sidebar，并把草稿状态改为 `ready`、补充 `releaseBlogZhPath` 与 `releaseBlogEnPath`。NPM 达到 `NPM_READY` 后，产品发布闭环会阻断仍处于 draft 或缺少正式入口的绑定文章；线上验证完成后再删除内部草稿。 发布关联的功能、优化和结果博客默认采用短篇结果营销稿：标题先写产品、成果和最强可核查数字，首屏直接回答“做成了什么、效果如何”；实现原理只保留理解结果所需的最少内容。只有用户明确要技术复盘、原理说明或产品判断时，才展开为科普或长文。标题可以强，但不能超出测量范围或把开发版本写成已发布。 ## 写作流程 ### 宣传内容的有效吸引门 官网、广告式短文与品牌故事先判断题材是否值得表达，再润色。目标是在有限注意力内，让尽可能多的潜在用户理解与自己有关的真实价值，产生进一步了解或尝试的意愿；不是平均好感、信息量或无关点击。此门不强加给技术说明与状态报告。 - 先冻结一句“哪些潜在用户共同在意什么→产品如何回应→用什么可核查细节证明→希望他下一步做什么”。群体不同先找共同处境，不堆场景列表，也不把单一故事当成整个产品。 - 场景选择须对应用户明确的目标受众或可说明的需求假设；不能因为亲情等题材容易写就认定有代表性。受众假设被用户否定时先退场该题材，不继续用通用标题包装原故事；年龄本身不证明某个需求普遍。 - 对候选问：去掉亲情、猎奇和氛围，产品价值还在吗？换掉产品名字后是否仍是空泛好话？结果配得上承诺吗？访客能记住哪一个具体变化？可迁移到竞品不等于没价值，但不能冒称独有。 - 文字、视觉与动作共享一条因果链；交互应帮助理解、证明协作或兑现结果，不能靠多点几次消耗注意力。先给最重要的意思，证据按需展开。 - 概念、示例和未上线能力必须可辨识；不靠虚构事实、夸大自主程度或与产品无关的情绪吸引。不能把完整、流畅、漂亮当成有效吸引的证据。 - 无真实用户数据时，只给出可反驳的吸引假设与AI审查结论。后续用同条件的少量目标用户比较“以为它是什么、记住什么、为何愿意继续”，再观察适用的真实行为；不伪造覆盖率或转换提升。题材本身无力时允许放弃，不继续包装。 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 和无证据优势宣称。