| name | product-blog-storytelling |
| description | 当用户要为 NextClaw 写产品博客、短文、官网文章、版本更新说明、宣传叙事、功能优势阐述、发布故事、配图建议，或要求把某个产品点讲清楚、写得更有传播力时使用。用于把产品愿景、真实证据、用户痛点、差异化判断和可发布文案收敛成可复用写作流程。 |
Product Blog Storytelling
目标
把 NextClaw 的产品优势写成可信、简短、有判断力的公开文章，而不是泛泛营销稿。
默认服务对象：
- 文档站博客；
- 官网短文；
- 发布叙事；
- 社区帖草稿；
- 功能优势说明；
- 配图或视觉 brief。
工作流
- 先读
docs/VISION.md 中与主题相关的段落，确认文章服务的是统一入口、能力编排、自感知、自治、自进化、生态扩展中的哪一条。
- 找证据：优先从代码、现有文档、真实 UI 能力、事件链路、发布记录或用户反馈里找支撑。证据不足时，把判断写成方向而不是既成事实。
- 先选择文章模式，不默认写观点文。默认模式是“结果摘要型事实报告”。可以借鉴论文的结构清晰度，但不要照搬“问题 / 方法 / 实验”这类栏目名。
- 定一句核心事实：用一句话说清“当前到底有什么能力 / 底座 / 入口 / 证据”。
- 写用户场景时保持克制，只说明这个事实解决或支撑什么，不写大 V 式情绪段落。
- 写 NextClaw 的差异时基于证据说明，例如事件链路、会话、Agent、工具、自动化、UI 入口；不要先拔高成愿景口号。
- 写边界：不夸大，不说尚未实现的能力已经完成；可以明确“底座已具备，下一步是产品化”。
- 区分讨论材料和最终呈现：分类依据、写作原则、取舍理由可以用于协作讨论，但最终发布稿只呈现读者需要看到的摘要、分类、说明和清单，不把内部讨论过程、模板解释或“为什么这么写”的元话语混进去。
- 输出发布稿：优先短文，结构清楚，段落短，少用套话。
- 如需配图，先写清“这张图必须让用户 get 到什么核心亮点”，再选择视觉表达类型，不默认直接生一张泛 UI 概念图；如果用户要求先忽略图片，则只处理内容结构。
- 至少比较 2-3 种图片形式，说明推荐哪一种及原因；必要时生成/制作多个方向小样再选。
- 配图完成后必须自评：是否一眼传达核心亮点；用户注意力是否落在文章要宣传的点上；是否只是好看但语义泛化。未命中时重出或改 brief。
文章模式
结果摘要型事实报告（默认）
适合早期博客、功能解释、能力梳理、降低表达风险。借用论文结构的约束力，但不写成论文腔：每一段都回答一个明确问题，短、硬、可核查，栏目名仍然使用产品读者容易接受的写法。
结构：
## 摘要
一句话结论 + 3-5 条事实。
## 当前结果
表格列能力、当前状态、用户可见结果。
## 能力边界
列尚未完成的范围，避免夸大。
## 下一步
列 2-3 个后续方向。
要求：
- 只保留干货：事实、状态、边界、下一步。
- 最终正文不解释“为什么这样分组”“不要怎么写”“推荐结构是什么”；这些只属于协作讨论或写作准备。
- 能用表格就用表格。
- 可以在脑内参考论文的“背景 / 结果 / 讨论 / 未来工作”，但正文默认不要直接使用“问题与方法”“实验”“相关研究”等研究论文栏目。
- 用户问题、产品方法和价值可以融入摘要、当前结果或下一步里；只有确实需要展开时才单独成节。
- 多用“当前”“已具备”“未完成”“下一步”，少用“必须”“关键”“本质”“真正”。
- 删除解释性废话和情绪性转场。
- 不模仿大 V，不写散文式排比，不用情绪推进文章。
事实陈述型产品说明
适合比结果摘要稍展开的功能介绍。必须先有事实报告版，再决定是否扩写。
产品判断型短文
适合已有事实清楚、需要解释取舍时使用。必须先有事实报告版或证据列表，再写判断。
发布叙事
适合已上线能力。重点写变化、用户怎么用、验证或发布范围。
备用观点文结构
---
title:
description:
---
# 标题
发布时间：
标签：
开场：直接给判断。
### 用户真正遇到的问题
### NextClaw 已经具备或正在建设的能力
### 为什么这符合个人操作层
### 为什么现在值得表达出来
## 继续阅读
仅当用户明确要观点文、发布故事或更强传播稿时使用上面的结构。默认不要使用它。
配图自评清单
- 核心亮点能否被一句话描述，例如“实时看见每个 Agent 的任务进展”。
- 图里的视觉焦点是否正好落在这个亮点上。
- 图里是否出现了支持亮点的证据元素，例如任务列表、状态点、进度线、工具调用、统一工作台。
- 如果去掉文章标题，用户是否仍大概率能猜到这篇文章在讲什么。
- 是否避免了泛 AI 图常见问题：机器人头像、抽象光效、科幻背景、纯装饰网络、与产品能力无关的氛围图。
图片形式选择
每次配图前先选形式。常见候选：
- 真实产品截图：最可信，适合已经上线且界面足够清楚的能力；风险是截图信息密、视觉不够聚焦。
- 标注产品截图：适合讲具体 UI 能力或教程；用框线、箭头、局部放大强调亮点。注意不要遮挡真实界面。
- 概念化产品图：适合表达已具备底座、正在产品化或跨多个界面的能力；必须避免让用户误以为这是已上线截图。
- 信息图 / 语义图：适合解释判断、对比、架构、流程或“为什么重要”；文字要少，最好用图形关系表达，不要变成海报文案堆叠。
- 流程故事板：适合讲 before/after、用户旅程或任务从发起到完成的变化。
- 抽象氛围图：默认不推荐，只在品牌情绪或文章非常上层时使用；不能替代产品能力表达。
选择规则：
- 已上线且截图能直接看懂：优先真实截图或标注截图。
- 能力跨多个界面或尚未完整产品化：优先概念化产品图或信息图，并在正文/alt 文案里标注为概念表达。
- 文章核心是结构性判断：优先信息图或流程故事板。
- 文章核心是可信产品证明：优先截图，少用生图。
- 如果一种图难以同时兼顾可信度和传播性，可以用截图做正文证据图，用概念图做 hero。
质量标准
- 有明确判断，不只罗列功能。
- 有用户场景，不只讲系统能力。
- 有证据锚点，不空喊愿景。
- 有边界感，不把方向写成已完成事实。
- 能被普通用户读懂，也能让技术用户感到可信。
- 中文默认自然、直接、短句；英文默认清楚克制，不堆 marketing buzzword。
不要这样写
- 不要说“革命性”“颠覆性”“前所未有”这类空词。
- 不要把 NextClaw 写成万能产品。
- 不要只写 changelog。
- 不要用“我们有很多功能”替代“用户为什么需要它”。
- 不要把配图做成抽象光效、机器人头像或与真实产品无关的科幻场景。
