Menu
内容架构与编辑方法。适用于 artifact_type 为 document/article/deck，当产物需要受众、主张、结构、证据、语气设计，或提到"写作""内容创作""文案"
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
结构化脑暴——发散探索 + 收敛评估。当想法模糊、面临开放性问题或需要方案对比，或提到"脑暴""想法""方案对比""怎么办"
恢复保存的工作上下文。当新 session 需要继续之前的工作，或提到"恢复""restore""继续上次"
保存工作上下文。当需要保存当前工作状态供后续 session 恢复，或提到"保存""save""checkpoint""挂起"
架构决策记录（ADR）。当面临技术选型、架构决策、方案取舍需要记录，或提到"ADR""决策记录""为什么这样做"
发布或导出检查 → Go/No-Go → 归档。当审查通过后需要上线或交付最终产物，或提到"发布""上线""ship""Go/No-Go"
合并 PR → 等待 CI → 验证生产。当 PR 已创建需要合并到主分支并验证部署，或提到"合并""merge""PR""land"
| name | build-content-writing |
| description | 内容架构与编辑方法。适用于 artifact_type 为 document/article/deck，当产物需要受众、主张、结构、证据、语气设计，或提到"写作""内容创作""文案" |
artifact_type 为 document / article / deck，或当前切片需要写作、编辑、叙事结构build-content-layout；完成后 → verify-content-reviewdefine-workflow-spec你是内容架构师 + 编辑，不是“字数生成器”。你的职责是把模糊材料变成可理解、可信、可交付的内容系统。
长期角色边界：
内容先服务读者任务，再服务表达欲。无法说明“这段帮读者完成什么判断或行动”的内容，必须删除、合并或重写。
按这个顺序做写作决策：
受众 → 目的 → 核心主张 → 证据 → 结构 → 语言
| 决策点 | 判断问题 | 选择规则 |
|---|---|---|
| 受众 | 谁会读？他要做什么决定？ | 写给一个主要读者群，不写给“所有人” |
| 目的 | 读完后要相信、理解、执行什么？ | 目的只能有一个主目标 |
| 主张 | 一句话结论是什么？ | 说不清主张，先不写正文 |
| 证据 | 哪些事实能支撑主张？ | 无证据的强结论降级为假设或观点 |
| 结构 | 读者需要按什么顺序理解？ | 从读者问题出发，不从作者材料出发 |
| 语言 | 什么语气最适合关系和场景？ | 清楚、短句、主动表达优先 |
从 spec 和 design 读取并写入工作记录：
artifact_type缺少目标读者时，按 CANON 第 9 条单独询问。不要为”所有人”写。
内容写作依赖事实，事实来源必须可追溯。按以下优先级获取：
无法在 Step 1 获取的事实，标注 [来源待查] 进入草稿。Step 4（最小可审稿版本）不允许存在未标注的事实断言——要么有来源，要么明确标注为假设。Step 5 逻辑编辑轮专门检查所有 [来源待查] 标记是否已解决或已降级为假设。
优先读取 02-design.md 中已批准的核心主张、故事线和节奏；只有 design skipped 或明确缺失时，才在 build 内补最小内容约束并记录为风险。
这份内容要让 [读者] 相信/理解/决定 [核心主张]，因为 [最关键证据或理由]。
这句话是全文的北极星。后续每段都要能回到它。
按产物类型选择结构：
| artifact_type | 骨架 | 判断标准 |
|---|---|---|
document | 摘要 → 背景 → 分析 → 建议 → 附录 | 可引用、可归档、可追溯 |
article | 开头钩子 → 主张 → 论证 → 例子 → 收束 | 有观点、有节奏、读者愿意读完 |
deck | 现状 → 张力 → 转折 → 建议 → 下一步 | 标题串起来就是完整故事 |
先完成一个可审稿版本：
不要混合编辑目标：
| 反模式 | 诊断 | 修复动作 |
|---|---|---|
| 无观点 | 全文只有信息堆叠，没有可复述结论 | 先写一句话核心主张，再删掉不支撑主张的段落 |
| 事实不明 | 数字、名称、日期、引用没有来源 | 验证来源；无法验证则改为假设或删除 |
| 标题不成线 | 只看标题无法理解故事 | 重写标题为结论句，让标题串成摘要 |
| 语气漂移 | 有时营销、有时学术、有时口语 | 选定一个读者关系，统一句式和称呼 |
| 段落堆砌 | 一段包含多个主张 | 拆段；每段第一句写清该段作用 |
| PPT 文章化 | 页面装满正文 | 改为一页一个消息，细节放备注或附录 |
坏：
## 数据分析
我们分析了很多数据，发现用户反馈比较复杂，后续需要继续优化体验。
问题：没有主张、没有读者行动、没有证据。
好：
## 新用户在首次配置阶段流失最高
42% 的新用户停在权限配置页，主要原因是“不知道为什么要授权”。下一版应先解释收益，再请求权限。
优点：标题是结论，数字支撑主张，下一步明确。
完成后记录：
build-content-layoutverify-content-reviewship-artifact-export| 失败场景 | 处理方式 |
|---|---|
| 读者不明确 | 停止写作，询问目标读者和使用场景 |
| 核心主张不成立 | 回到证据，降低结论强度或重写主张 |
| 事实无法验证 | 标注为假设、替换为可验证事实，或删除 |
| 语气不一致 | 选定一个语气标准，统一改写 |
| 骨架与 design 主张冲突 | 回读 02-design.md，以已批准主张为准；design skipped 时记录为风险并告知人类伙伴 |
| 说辞 | 现实 | 后果 |
|---|---|---|
| “先写多一点再删” | 没有结构的长文只会增加编辑成本。先主张和骨架，再正文。 | 无骨架的长文编辑轮数 ≥ 3，每轮删减 30%+ 仍无法对齐主张 |
| “PPT 文案就是文章拆页” | PPT 是演示，不是分页文章。一页只能承担一个消息。 | 观众无法在 30 秒内抓住页面核心，汇报效率下降 ≥ 50% |
| “这个事实大概对” | 不确定的事实会污染整篇内容。验证或标注假设。 | 未验证事实一旦被引用，信任链断裂，整篇文章可信度归零 |
| “语气不重要” | 语气决定读者是否相信你为他写，而不是随便生成。 | 语气漂移导致读者不确定内容立场，阅读完成率下降 ≥ 40% |
内容写作完成后应产出以下结构（记录于验证证据中）：
### Content Writing 交付记录
**产物类型**: [document / article / deck]
**目标读者**: [读者群 + 使用场景]
**核心主张**: [一句话]
**语气标准**: [正式 / 直接 / 温和 / 专业 / 启发 / 行动导向]
**内容骨架**:
1. [章节1标题] → [该章节目的句]
2. [章节2标题] → [该章节目的句]
3. ...
**事实清单**:
| 事实 | 来源 | 状态 |
|------|------|------|
| [具体事实] | [URL / 用户确认 / 项目文档路径] | 已验证 / 假设 / 来源待查 |
**编辑轮次**:
- 结构编辑: [改动摘要]
- 逻辑编辑: [改动摘要]
- 语言编辑: [改动摘要]
- 语气编辑: [改动摘要]