product-blog-storytelling

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. 输出发布稿：优先短文，结构清楚，段落短，少用套话。
10. 如需配图，先写清“这张图必须让用户 get 到什么核心亮点”，再选择视觉表达类型，不默认直接生一张泛 UI 概念图；如果用户要求先忽略图片，则只处理内容结构。
11. 至少比较 2-3 种图片形式，说明推荐哪一种及原因；必要时生成/制作多个方向小样再选。
12. 配图完成后必须自评：是否一眼传达核心亮点；用户注意力是否落在文章要宣传的点上；是否只是好看但语义泛化。未命中时重出或改 brief。

文章模式

结果摘要型事实报告（默认）

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

结构：

## 摘要

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

## 当前结果

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

## 能力边界

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

## 下一步

列 2-3 个后续方向。

要求：

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

事实陈述型产品说明

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

产品判断型短文

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

发布叙事

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

备用观点文结构

---
title:
description:
---

# 标题

发布时间：
标签：

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

开场：直接给判断。

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

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

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

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

## 继续阅读

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

配图自评清单

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

图片形式选择

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

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

选择规则：

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

质量标准

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

不要这样写

• 不要说“革命性”“颠覆性”“前所未有”这类空词。
• 不要把 NextClaw 写成万能产品。
• 不要只写 changelog。
• 不要用“我们有很多功能”替代“用户为什么需要它”。
• 不要把配图做成抽象光效、机器人头像或与真实产品无关的科幻场景。