blog-draft

name	blog-draft
description	从想法和资源出发起草博客文章。当用户想要写博客文章、从研究中创建内容或草拟文章时使用。引导完成研究、头脑风暴、大纲制定和带版本控制的迭代式写作流程。

用户输入

$ARGUMENTS

你必须先考虑用户输入再继续操作。用户应提供:

• 想法/主题:博客文章的主要概念或主题
• 资源:URL、文件或参考资料(可选但推荐)
• 目标受众:博客文章的读者群体(可选)
• 语调/风格:正式、随意、技术性等(可选)

重要:如果用户请求更新已有的博客文章,跳过步骤 0-8,直接从步骤 9开始。先读取现有的草稿文件,然后进入迭代流程。

执行流程

按以下顺序逐步执行。不要跳过步骤或在需要用户确认的地方未经批准就继续。

步骤 0:创建项目文件夹

1. 使用以下格式生成文件夹名:YYYY-MM-DD-短主题名称

   • 使用今天的日期
   • 从主题生成短小、URL 友好的 slug(小写、连字符分隔、最多 5 个词)

2. 创建文件夹结构:

   blog-posts/
   └── YYYY-MM-DD-短主题名称/
       └── resources/
   

3. 创建文件夹后向用户确认再继续。

步骤 1:研究与资料收集

1. 在博客文章目录中创建 resources/ 子文件夹

2. 对每个提供的资源:

   • URL:获取关键信息并保存到 resources/ 的 markdown 文件中
   • 文件:阅读并在 resources/ 中总结
   • 主题:使用网络搜索收集最新信息

3. 对每个资源,在 resources/ 中创建摘要文件:

   • resources/source-1-[简称].md
   • resources/source-2-[简称].md
   • 等等

4. 每个摘要应包含:

   # 来源:[标题/URL]
   
   ## 要点
   - 要点 1
   - 要点 2
   
   ## 相关引用/数据
   - 引用或统计数据 1
   - 引用或统计数据 2
   
   ## 与主题的关系
   简要说明相关性
   

5. 向用户展示研究摘要。

步骤 2:头脑风暴与澄清

1. 基于想法和研究资源,展示:

   • 从研究中识别出的主要主题
   • 博客文章的潜在角度
   • 应该涵盖的关键要点
   • 需要澄清的信息缺口

2. 提出澄清问题:

   • 你希望读者获得的核心收获是什么?
   • 研究中有哪些重点想强调?
   • 目标篇幅?(短篇:500-800 字,中篇:1000-1500 字,长篇:2000+ 字)
   • 有哪些要点需要排除?

3. 等待用户回复后再继续。

步骤 3:提出大纲

1. 创建包含以下内容的结构化大纲:

   # 博客文章大纲:[标题]
   
   ## 元信息
   - **目标受众**:[谁]
   - **语调**:[风格]
   - **目标篇幅**:[字数]
   - **核心收获**:[关键信息]
   
   ## 建议结构
   
   ### 开头/引言
   - 吸引人的开场白
   - 背景铺垫
   - 论点陈述
   
   ### 第一部分:[标题]
   - 要点 A
   - 要点 B
   - 来自 [来源] 的支持证据
   
   ### 第二部分:[标题]
   - 要点 A
   - 要点 B
   
   [继续所有章节...]
   
   ### 结论
   - 关键要点总结
   - 行动号召或最终思考
   
   ## 引用来源
   - 来源 1
   - 来源 2
   

2. 向用户展示大纲并请求批准或修改建议。

步骤 4:保存已批准的大纲

1. 用户批准大纲后,将其保存到博客文章文件夹中的 OUTLINE.md。

2. 确认大纲已保存。

步骤 5:提交大纲(如果在 git 仓库中)

1. 检查当前目录是否为 git 仓库。

2. 如果是:

   • 暂存新文件:博客文章文件夹、资源和 OUTLINE.md
   • 创建提交,消息为:docs: Add outline for blog post - [主题名]
   • 推送到远程仓库

3. 如果不是 git 仓库,跳过此步并告知用户。

步骤 6:撰写草稿

1. 基于已批准的大纲,撰写完整的博客文章草稿。

2. 严格按照 OUTLINE.md 的结构进行。

3. 包含:

   • 吸引人的引言和开头
   • 清晰的章节标题
   • 来自研究的支持证据和示例
   • 章节间流畅的过渡
   • 有力的结论和核心收获
   • 引用:所有对比、统计数据和数据点必须引用原始来源

4. 将草稿保存为博客文章文件夹中的 draft-v0.1.md。

5. 格式要求:

   # [博客文章标题]
   
   *[可选:副标题或标语]*
   
   [包含内联引用的完整内容...]
   
   ---
   
   ## 参考文献
   - [1] 来源 1 标题 - URL 或引用
   - [2] 来源 2 标题 - URL 或引用
   - [3] 来源 3 标题 - URL 或引用
   

6. 引用要求:

   • 每个数据点、统计或对比必须有内联引用
   • 使用编号引用 [1]、[2] 等,或命名引用 [来源名称]
   • 将引用链接到文末的参考文献部分
   • 示例:"研究表明 65% 的开发者偏好 TypeScript [1]"
   • 示例:"React 渲染速度比 Vue 快 20% [React Benchmarks 2024]"

步骤 7:提交草稿(如果在 git 仓库中)

1. 检查是否在 git 仓库中。

2. 如果是:

   • 暂存草稿文件
   • 创建提交,消息为:docs: Add draft v0.1 for blog post - [主题名]
   • 推送到远程仓库

3. 如果不是 git 仓库,跳过并告知用户。

步骤 8:展示草稿供审阅

1. 向用户展示草稿内容。

2. 请求反馈:

   • 整体印象如何?
   • 哪些部分需要扩展或精简?
   • 是否需要调整语调?
   • 是否有遗漏信息?
   • 具体的编辑或重写建议?

3. 等待用户回复。

步骤 9:迭代或定稿

如果用户请求修改:

1. 记录所有修改需求
2. 返回步骤 6,做如下调整:
   • 递增版本号(v0.2、v0.3 等)
   • 整合所有反馈意见
   • 保存为 draft-v[X.Y].md
   • 重复步骤 7-8

如果用户批准:

1. 确认最终草稿版本
2. 可选:按用户要求重命名为 final.md
3. 总结博客文章创建过程:
   • 创建的总版本数
   • 版本间的关键变更
   • 最终字数
   • 创建的文件列表

版本跟踪

所有草稿都保留增量版本号:

• 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 时使用网络搜索获取最新信息
• 如果资源不足,向用户请求更多信息或建议补充研究
• 根据目标受众调整语调(技术类、通用类、商务类等)