| name | blog-draft |
| description | 从想法和资源出发起草博客文章。当用户想要写博客文章、从研究中创建内容或草拟文章时使用。引导完成研究、头脑风暴、大纲制定和带版本控制的迭代式写作流程。 |
用户输入
$ARGUMENTS
你必须先考虑用户输入再继续操作。用户应提供:
- 想法/主题:博客文章的主要概念或主题
- 资源:URL、文件或参考资料(可选但推荐)
- 目标受众:博客文章的读者群体(可选)
- 语调/风格:正式、随意、技术性等(可选)
重要:如果用户请求更新已有的博客文章,跳过步骤 0-8,直接从步骤 9开始。先读取现有的草稿文件,然后进入迭代流程。
执行流程
按以下顺序逐步执行。不要跳过步骤或在需要用户确认的地方未经批准就继续。
步骤 0:创建项目文件夹
-
使用以下格式生成文件夹名:YYYY-MM-DD-短主题名称
- 使用今天的日期
- 从主题生成短小、URL 友好的 slug(小写、连字符分隔、最多 5 个词)
-
创建文件夹结构:
blog-posts/
└── YYYY-MM-DD-短主题名称/
└── resources/
-
创建文件夹后向用户确认再继续。
步骤 1:研究与资料收集
-
在博客文章目录中创建 resources/ 子文件夹
-
对每个提供的资源:
- URL:获取关键信息并保存到
resources/ 的 markdown 文件中
- 文件:阅读并在
resources/ 中总结
- 主题:使用网络搜索收集最新信息
-
对每个资源,在 resources/ 中创建摘要文件:
resources/source-1-[简称].md
resources/source-2-[简称].md
- 等等
-
每个摘要应包含:
# 来源:[标题/URL]
## 要点
- 要点 1
- 要点 2
## 相关引用/数据
- 引用或统计数据 1
- 引用或统计数据 2
## 与主题的关系
简要说明相关性
-
向用户展示研究摘要。
步骤 2:头脑风暴与澄清
-
基于想法和研究资源,展示:
- 从研究中识别出的主要主题
- 博客文章的潜在角度
- 应该涵盖的关键要点
- 需要澄清的信息缺口
-
提出澄清问题:
- 你希望读者获得的核心收获是什么?
- 研究中有哪些重点想强调?
- 目标篇幅?(短篇:500-800 字,中篇:1000-1500 字,长篇:2000+ 字)
- 有哪些要点需要排除?
-
等待用户回复后再继续。
步骤 3:提出大纲
-
创建包含以下内容的结构化大纲:
# 博客文章大纲:[标题]
## 元信息
- **目标受众**:[谁]
- **语调**:[风格]
- **目标篇幅**:[字数]
- **核心收获**:[关键信息]
## 建议结构
### 开头/引言
- 吸引人的开场白
- 背景铺垫
- 论点陈述
### 第一部分:[标题]
- 要点 A
- 要点 B
- 来自 [来源] 的支持证据
### 第二部分:[标题]
- 要点 A
- 要点 B
[继续所有章节...]
### 结论
- 关键要点总结
- 行动号召或最终思考
## 引用来源
- 来源 1
- 来源 2
-
向用户展示大纲并请求批准或修改建议。
步骤 4:保存已批准的大纲
-
用户批准大纲后,将其保存到博客文章文件夹中的 OUTLINE.md。
-
确认大纲已保存。
步骤 5:提交大纲(如果在 git 仓库中)
-
检查当前目录是否为 git 仓库。
-
如果是:
- 暂存新文件:博客文章文件夹、资源和 OUTLINE.md
- 创建提交,消息为:
docs: Add outline for blog post - [主题名]
- 推送到远程仓库
-
如果不是 git 仓库,跳过此步并告知用户。
步骤 6:撰写草稿
-
基于已批准的大纲,撰写完整的博客文章草稿。
-
严格按照 OUTLINE.md 的结构进行。
-
包含:
- 吸引人的引言和开头
- 清晰的章节标题
- 来自研究的支持证据和示例
- 章节间流畅的过渡
- 有力的结论和核心收获
- 引用:所有对比、统计数据和数据点必须引用原始来源
-
将草稿保存为博客文章文件夹中的 draft-v0.1.md。
-
格式要求:
# [博客文章标题]
*[可选:副标题或标语]*
[包含内联引用的完整内容...]
---
## 参考文献
- [1] 来源 1 标题 - URL 或引用
- [2] 来源 2 标题 - URL 或引用
- [3] 来源 3 标题 - URL 或引用
-
引用要求:
- 每个数据点、统计或对比必须有内联引用
- 使用编号引用 [1]、[2] 等,或命名引用 [来源名称]
- 将引用链接到文末的参考文献部分
- 示例:"研究表明 65% 的开发者偏好 TypeScript [1]"
- 示例:"React 渲染速度比 Vue 快 20% [React Benchmarks 2024]"
步骤 7:提交草稿(如果在 git 仓库中)
-
检查是否在 git 仓库中。
-
如果是:
- 暂存草稿文件
- 创建提交,消息为:
docs: Add draft v0.1 for blog post - [主题名]
- 推送到远程仓库
-
如果不是 git 仓库,跳过并告知用户。
步骤 8:展示草稿供审阅
-
向用户展示草稿内容。
-
请求反馈:
- 整体印象如何?
- 哪些部分需要扩展或精简?
- 是否需要调整语调?
- 是否有遗漏信息?
- 具体的编辑或重写建议?
-
等待用户回复。
步骤 9:迭代或定稿
如果用户请求修改:
- 记录所有修改需求
- 返回步骤 6,做如下调整:
- 递增版本号(v0.2、v0.3 等)
- 整合所有反馈意见
- 保存为
draft-v[X.Y].md
- 重复步骤 7-8
如果用户批准:
- 确认最终草稿版本
- 可选:按用户要求重命名为
final.md
- 总结博客文章创建过程:
- 创建的总版本数
- 版本间的关键变更
- 最终字数
- 创建的文件列表
版本跟踪
所有草稿都保留增量版本号:
draft-v0.1.md -- 初始草稿
draft-v0.2.md -- 第一轮反馈后
draft-v0.3.md -- 第二轮反馈后
- 等等
这样可以追踪博客文章的演进过程,并在需要时回退。
输出文件结构
blog-posts/
└── YYYY-MM-DD-主题名/
├── resources/
│ ├── source-1-名称.md
│ ├── source-2-名称.md
│ └── ...
├── OUTLINE.md
├── draft-v0.1.md
├── draft-v0.2.md(如有迭代)
└── draft-v0.3.md(如有更多迭代)
质量提示
- 开头吸引人:以提问、令人惊讶的事实或相关场景开始
- 行文流畅:每段应与下一段自然衔接
- 证据支撑:用研究数据支撑论点
- 引用规范:始终引用以下来源:
- 所有统计数据(例如:"根据 [来源],75% 的...")
- 产品/服务/方案之间的对比(例如:"X 比 Y 快 2 倍 [来源]")
- 关于市场趋势、研究发现或基准测试的事实声明
- 使用内联引用格式:[来源名称] 或 [作者, 年份]
- 语调一致:全文保持一致的语调风格
- 篇幅控制:尊重目标字数要求
- 易读性:使用短段落,适当使用列表
- 结尾有力:以明确的行动号召或引人深思的问题结束
注意事项
- 始终在大纲标注的检查点等待用户批准
- 保留所有草稿版本以便追溯历史
- 当提供了 URL 时使用网络搜索获取最新信息
- 如果资源不足,向用户请求更多信息或建议补充研究
- 根据目标受众调整语调(技术类、通用类、商务类等)