product-blog-storytelling

star 215

当用户要为 NextClaw 写产品博客、短文、官网文章、宣传叙事、功能优势阐述、发布故事、配图建议,或要求把某个产品点讲清楚、写得更有传播力时使用。用于把产品愿景、真实证据、用户痛点、差异化判断和可发布文案收敛成可复用写作流程。

Peiiii By Peiiii schedule Updated 6/2/2026

name: product-blog-storytelling description: 当用户要为 NextClaw 写产品博客、短文、官网文章、宣传叙事、功能优势阐述、发布故事、配图建议,或要求把某个产品点讲清楚、写得更有传播力时使用。用于把产品愿景、真实证据、用户痛点、差异化判断和可发布文案收敛成可复用写作流程。

Product Blog Storytelling

目标

把 NextClaw 的产品优势写成可信、简短、有判断力的公开文章,而不是泛泛营销稿。

默认服务对象:

  • 文档站博客;
  • 官网短文;
  • 发布叙事;
  • 社区帖草稿;
  • 功能优势说明;
  • 配图或视觉 brief。

工作流

  1. 先读 docs/VISION.md 中与主题相关的段落,确认文章服务的是统一入口、能力编排、自感知、自治、自进化、生态扩展中的哪一条。
  2. 找证据:优先从代码、现有文档、真实 UI 能力、事件链路、发布记录或用户反馈里找支撑。证据不足时,把判断写成方向而不是既成事实。
  3. 先选择文章模式,不默认写观点文。默认模式是“结果摘要型事实报告”。可以借鉴论文的结构清晰度,但不要照搬“问题 / 方法 / 实验”这类栏目名。
  4. 定一句核心事实:用一句话说清“当前到底有什么能力 / 底座 / 入口 / 证据”。
  5. 写用户场景时保持克制,只说明这个事实解决或支撑什么,不写大 V 式情绪段落。
  6. 写 NextClaw 的差异时基于证据说明,例如事件链路、会话、Agent、工具、自动化、UI 入口;不要先拔高成愿景口号。
  7. 写边界:不夸大,不说尚未实现的能力已经完成;可以明确“底座已具备,下一步是产品化”。
  8. 输出发布稿:优先短文,结构清楚,段落短,少用套话。
  9. 如需配图,先写清“这张图必须让用户 get 到什么核心亮点”,再选择视觉表达类型,不默认直接生一张泛 UI 概念图;如果用户要求先忽略图片,则只处理内容结构。
  10. 至少比较 2-3 种图片形式,说明推荐哪一种及原因;必要时生成/制作多个方向小样再选。
  11. 配图完成后必须自评:是否一眼传达核心亮点;用户注意力是否落在文章要宣传的点上;是否只是好看但语义泛化。未命中时重出或改 brief。

文章模式

结果摘要型事实报告(默认)

适合早期博客、功能解释、能力梳理、降低表达风险。借用论文结构的约束力,但不写成论文腔:每一段都回答一个明确问题,短、硬、可核查,栏目名仍然使用产品读者容易接受的写法。

结构:

## 摘要

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

## 当前结果

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

## 能力边界

列尚未完成的范围,避免夸大。

## 下一步

列 2-3 个后续方向。

要求:

  • 只保留干货:事实、状态、边界、下一步。
  • 能用表格就用表格。
  • 可以在脑内参考论文的“背景 / 结果 / 讨论 / 未来工作”,但正文默认不要直接使用“问题与方法”“实验”“相关研究”等研究论文栏目。
  • 用户问题、产品方法和价值可以融入摘要、当前结果或下一步里;只有确实需要展开时才单独成节。
  • 多用“当前”“已具备”“未完成”“下一步”,少用“必须”“关键”“本质”“真正”。
  • 删除解释性废话和情绪性转场。
  • 不模仿大 V,不写散文式排比,不用情绪推进文章。

事实陈述型产品说明

适合比结果摘要稍展开的功能介绍。必须先有事实报告版,再决定是否扩写。

产品判断型短文

适合已有事实清楚、需要解释取舍时使用。必须先有事实报告版或证据列表,再写判断。

发布叙事

适合已上线能力。重点写变化、用户怎么用、验证或发布范围。

备用观点文结构

---
title:
description:
---

# 标题

发布时间:
标签:

![配图说明](/blog/<asset>.png)

开场:直接给判断。

### 用户真正遇到的问题

### NextClaw 已经具备或正在建设的能力

### 为什么这符合个人操作层

### 为什么现在值得表达出来

## 继续阅读

仅当用户明确要观点文、发布故事或更强传播稿时使用上面的结构。默认不要使用它。

配图自评清单

  • 核心亮点能否被一句话描述,例如“实时看见每个 Agent 的任务进展”。
  • 图里的视觉焦点是否正好落在这个亮点上。
  • 图里是否出现了支持亮点的证据元素,例如任务列表、状态点、进度线、工具调用、统一工作台。
  • 如果去掉文章标题,用户是否仍大概率能猜到这篇文章在讲什么。
  • 是否避免了泛 AI 图常见问题:机器人头像、抽象光效、科幻背景、纯装饰网络、与产品能力无关的氛围图。

图片形式选择

每次配图前先选形式。常见候选:

  • 真实产品截图:最可信,适合已经上线且界面足够清楚的能力;风险是截图信息密、视觉不够聚焦。
  • 标注产品截图:适合讲具体 UI 能力或教程;用框线、箭头、局部放大强调亮点。注意不要遮挡真实界面。
  • 概念化产品图:适合表达已具备底座、正在产品化或跨多个界面的能力;必须避免让用户误以为这是已上线截图。
  • 信息图 / 语义图:适合解释判断、对比、架构、流程或“为什么重要”;文字要少,最好用图形关系表达,不要变成海报文案堆叠。
  • 流程故事板:适合讲 before/after、用户旅程或任务从发起到完成的变化。
  • 抽象氛围图:默认不推荐,只在品牌情绪或文章非常上层时使用;不能替代产品能力表达。

选择规则:

  • 已上线且截图能直接看懂:优先真实截图或标注截图。
  • 能力跨多个界面或尚未完整产品化:优先概念化产品图或信息图,并在正文/alt 文案里标注为概念表达。
  • 文章核心是结构性判断:优先信息图或流程故事板。
  • 文章核心是可信产品证明:优先截图,少用生图。
  • 如果一种图难以同时兼顾可信度和传播性,可以用截图做正文证据图,用概念图做 hero。

质量标准

  • 有明确判断,不只罗列功能。
  • 有用户场景,不只讲系统能力。
  • 有证据锚点,不空喊愿景。
  • 有边界感,不把方向写成已完成事实。
  • 能被普通用户读懂,也能让技术用户感到可信。
  • 中文默认自然、直接、短句;英文默认清楚克制,不堆 marketing buzzword。

不要这样写

  • 不要说“革命性”“颠覆性”“前所未有”这类空词。
  • 不要把 NextClaw 写成万能产品。
  • 不要只写 changelog。
  • 不要用“我们有很多功能”替代“用户为什么需要它”。
  • 不要把配图做成抽象光效、机器人头像或与真实产品无关的科幻场景。
Install via CLI
npx skills add https://github.com/Peiiii/nextclaw --skill product-blog-storytelling
Repository Details
star Stars 215
call_split Forks 34
navigation Branch main
article Path SKILL.md
More from Creator