89e89d4aa3
Add Chinese (Simplified) translations for all documentation, organized under a dedicated zh/ directory that mirrors the English folder structure. Co-authored-by: tanqingkuang <tanqingkuang@users.noreply.github.com> Translations originally contributed by @tanqingkuang in #45. Restructured from *-CN.md suffix pattern into zh/ directory to prevent the EPUB builder (scripts/build_epub.py collect_folder_files) from picking up Chinese files via glob("*.md") inside module folders.
275 lines
8.0 KiB
Markdown
275 lines
8.0 KiB
Markdown
---
|
||
name: blog-draft
|
||
description: 根据想法和资料撰写博客草稿。适用于用户想写博客、基于研究创建内容，或起草文章的场景。流程会引导你完成调研、头脑风暴、提纲编写和带版本控制的迭代撰写。
|
||
---
|
||
|
||
## 用户输入
|
||
|
||
```text
|
||
$ARGUMENTS
|
||
```
|
||
|
||
在继续之前，你**必须**先考虑用户输入。用户应提供：
|
||
- **想法/主题**：博客文章的核心概念或主题
|
||
- **资源**：用于研究的 URL、文件或参考资料（可选，但推荐）
|
||
- **目标读者**：这篇博客是写给谁看的（可选）
|
||
- **语气/风格**：正式、轻松、技术向等（可选）
|
||
|
||
**重要**：如果用户是在请求更新一篇**已有博客文章**，请跳过步骤 0-8，直接从**步骤 9** 开始。先阅读现有草稿文件，再继续迭代流程。
|
||
|
||
## 执行流程
|
||
|
||
请按顺序执行以下步骤。**不要跳步，也不要在未获得用户批准的情况下继续执行标明需要确认的步骤。**
|
||
|
||
### 步骤 0：创建项目文件夹
|
||
|
||
1. 使用以下格式生成文件夹名称：`YYYY-MM-DD-short-topic-name`
|
||
- 使用今天的日期
|
||
- 根据主题生成一个简短、适合 URL 的 slug（小写、连字符连接，最多 5 个词）
|
||
|
||
2. 创建文件夹结构：
|
||
```text
|
||
blog-posts/
|
||
└── YYYY-MM-DD-short-topic-name/
|
||
└── resources/
|
||
```
|
||
|
||
3. 在继续前，先向用户确认文件夹已创建。
|
||
|
||
### 步骤 1：研究与资源收集
|
||
|
||
1. 在博客文章目录中创建 `resources/` 子文件夹
|
||
|
||
2. 对于每个提供的资源：
|
||
- **URL**：抓取关键内容并保存到 `resources/` 下的 markdown 文件中
|
||
- **文件**：读取并在 `resources/` 中做摘要
|
||
- **主题**：使用网络搜索收集最新信息
|
||
|
||
3. 为每个资源在 `resources/` 中创建摘要文件：
|
||
- `resources/source-1-[short-name].md`
|
||
- `resources/source-2-[short-name].md`
|
||
- 以此类推
|
||
|
||
4. 每个摘要都应包含：
|
||
```markdown
|
||
# 来源：[标题/URL]
|
||
|
||
## 要点
|
||
- 要点 1
|
||
- 要点 2
|
||
|
||
## 相关引文/数据
|
||
- 引文或统计 1
|
||
- 引文或统计 2
|
||
|
||
## 与主题的关联
|
||
简要说明其相关性
|
||
```
|
||
|
||
5. 向用户展示研究摘要。
|
||
|
||
### 步骤 2：头脑风暴与澄清
|
||
|
||
1. 基于想法和已研究的资源，展示：
|
||
- 从研究中识别出的**主要主题**
|
||
- 博客文章的**可能切入角度**
|
||
- 应该覆盖的**关键点**
|
||
- 仍需进一步澄清的**信息缺口**
|
||
|
||
2. 提出澄清问题：
|
||
- 你希望读者最终带走的核心结论是什么？
|
||
- 研究中有没有哪些点是你希望重点强调的？
|
||
- 目标长度是多少？（短：500-800 字，中：1000-1500 字，长：2000+ 字）
|
||
- 有没有哪些内容你希望排除？
|
||
|
||
3. **在继续之前，等待用户回复。**
|
||
|
||
### 步骤 3：提出提纲
|
||
|
||
1. 创建一个结构化提纲，包括：
|
||
|
||
```markdown
|
||
# 博客文章提纲：[标题]
|
||
|
||
## 元信息
|
||
- **目标读者**：[谁]
|
||
- **语气**：[风格]
|
||
- **目标长度**：[字数]
|
||
- **核心结论**：[关键信息]
|
||
|
||
## 建议结构
|
||
|
||
### 开场/引子
|
||
- 开场钩子思路
|
||
- 背景铺垫
|
||
- 论点陈述
|
||
|
||
### 第一部分：[标题]
|
||
- 关键点 A
|
||
- 关键点 B
|
||
- 来自 [来源] 的支撑证据
|
||
|
||
### 第二部分：[标题]
|
||
- 关键点 A
|
||
- 关键点 B
|
||
|
||
[继续列出所有部分...]
|
||
|
||
### 结论
|
||
- 关键点总结
|
||
- 行动号召或最终思考
|
||
|
||
## 需要引用的来源
|
||
- 来源 1
|
||
- 来源 2
|
||
```
|
||
|
||
2. 向用户展示提纲，并**请求批准或修改意见**。
|
||
|
||
### 步骤 4：保存已批准的提纲
|
||
|
||
1. 用户批准提纲后，将其保存为博客文章文件夹中的 `OUTLINE.md`。
|
||
|
||
2. 确认提纲已保存。
|
||
|
||
### 步骤 5：提交提纲（如果在 git 仓库中）
|
||
|
||
1. 检查当前目录是否为 git 仓库。
|
||
|
||
2. 如果是：
|
||
- 暂存新文件：博客文章文件夹、resources 和 `OUTLINE.md`
|
||
- 使用如下提交信息创建 commit：`docs: Add outline for blog post - [topic-name]`
|
||
- 推送到远程仓库
|
||
|
||
3. 如果不是 git 仓库，则跳过此步骤并告知用户。
|
||
|
||
### 步骤 6：撰写草稿
|
||
|
||
1. 基于已批准的提纲，撰写完整博客草稿。
|
||
|
||
2. 严格按照 `OUTLINE.md` 的结构进行编写。
|
||
|
||
3. 包含：
|
||
- 有吸引力的引言和开场钩子
|
||
- 清晰的章节标题
|
||
- 来自研究的支撑证据和示例
|
||
- 段落之间自然流畅的过渡
|
||
- 强有力的结尾和核心收获
|
||
- **引用**：所有比较、统计数据和事实性陈述都必须引用原始来源
|
||
|
||
4. 将草稿保存为博客文章文件夹中的 `draft-v0.1.md`。
|
||
|
||
5. 格式：
|
||
```markdown
|
||
# [博客文章标题]
|
||
|
||
*[可选：副标题或标语]*
|
||
|
||
[包含行内引用的完整正文...]
|
||
|
||
---
|
||
|
||
## 参考资料
|
||
- [1] 来源 1 标题 - URL 或引用
|
||
- [2] 来源 2 标题 - URL 或引用
|
||
- [3] 来源 3 标题 - URL 或引用
|
||
```
|
||
|
||
6. **引用要求**：
|
||
- 每个数据点、统计信息或比较都必须带有行内引用
|
||
- 使用编号引用 [1]、[2] 等，或命名引用 [Source Name]
|
||
- 在文末的参考资料部分链接这些引用
|
||
- 示例：“研究表明，65% 的开发者更偏好 TypeScript [1]”
|
||
- 示例：“React 在渲染速度上比 Vue 快 20% [React Benchmarks 2024]”
|
||
|
||
### 步骤 7：提交草稿（如果在 git 仓库中）
|
||
|
||
1. 检查是否处于 git 仓库中。
|
||
|
||
2. 如果是：
|
||
- 暂存草稿文件
|
||
- 使用如下提交信息创建 commit：`docs: Add draft v0.1 for blog post - [topic-name]`
|
||
- 推送到远程仓库
|
||
|
||
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` - 第二轮反馈后
|
||
- 以此类推
|
||
|
||
这可以跟踪博客文章的演变过程，并在需要时回退。
|
||
|
||
## 输出文件结构
|
||
|
||
```text
|
||
blog-posts/
|
||
└── YYYY-MM-DD-topic-name/
|
||
├── resources/
|
||
│ ├── source-1-name.md
|
||
│ ├── source-2-name.md
|
||
│ └── ...
|
||
├── OUTLINE.md
|
||
├── draft-v0.1.md
|
||
├── draft-v0.2.md（如果有迭代）
|
||
└── draft-v0.3.md（如果还有更多迭代）
|
||
```
|
||
|
||
## 质量建议
|
||
|
||
- **钩子**：以问题、令人惊讶的事实或贴近读者的场景开头
|
||
- **衔接**：每一段都要自然连接到下一段
|
||
- **证据**：用研究数据支撑观点
|
||
- **引用**：以下内容务必引用来源：
|
||
- 所有统计数据和数值（例如：“根据 [Source]，75% 的……”）
|
||
- 对产品、服务或方案的比较（例如：“X 的速度比 Y 快 2 倍 [Source]”）
|
||
- 关于市场趋势、研究发现或基准测试的事实性陈述
|
||
- 使用行内引用，格式为：[Source Name] 或 [Author, Year]
|
||
- **语气**：全程保持一致
|
||
- **长度**：尊重目标字数
|
||
- **可读性**：使用短段落，并在适当位置使用项目符号
|
||
- **CTA**：以明确的行动号召或发人深省的问题收尾
|
||
|
||
## 备注
|
||
|
||
- 始终在上述需要确认的节点等待用户批准
|
||
- 保留所有草稿版本，方便追踪历史
|
||
- 如果提供了 URL，使用网络搜索获取最新信息
|
||
- 如果资源不足，询问用户补充，或建议进一步研究
|
||
- 根据目标读者调整语气（技术、通用、商业等）
|