来源：[标题/URL]-创锋一号

来源：[标题/URL]

【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto

要点

要点 1
要点 2

与主题的关联

简要说明其相关性

完成后**向用户展示研究摘要**。 ### 步骤 2：头脑风暴与澄清 基于想法与已研究的资源，向用户展示： - 从研究中识别的**主要主题**； - 博客文章的**可能切入角度**； - 应该覆盖的**关键点**； - 仍需澄清的**信息缺口**。 随后提出澄清问题，例如： - 你希望读者最终带走的核心结论是什么？ - 研究中有没有哪些点是你希望重点强调的？ - 目标长度是多少？（短：500–800 字，中：1000–1500 字，长：2000+ 字） - 有没有哪些内容你希望排除？ **在继续之前，等待用户回复。** 这一步与步骤 0、步骤 3、步骤 8 共同构成 Skill 中的"人工审批门控"，确保 AI 不擅自替作者做内容决策。 ### 步骤 3：提出提纲 创建一个结构化提纲，`SKILL.md` 给出了完整模板骨架，包含**元信息**与**建议结构**两部分： ```markdown # 博客文章提纲：[标题] ## 元信息 - **目标读者**：[谁] - **语气**：[风格] - **目标长度**：[字数] - **核心结论**：[关键信息] ## 建议结构 ### 开场/引子 - 开场钩子思路 - 背景铺垫 - 论点陈述 ### 第一部分：[标题] - 关键点 A - 关键点 B - 来自 [来源] 的支撑证据 ### 第二部分：[标题] - 关键点 A - 关键点 B [继续列出所有部分...] ### 结论 - 关键点总结 - 行动号召或最终思考 ## 需要引用的来源 - 来源 1 - 来源 2

向用户展示提纲，并请求批准或修改意见。仓库中配套的 03-skills/blog-draft/templates/outline-template.md 是这一步骤的可落地方案：它把"元信息"扩展为表格（含目标读者、语气、目标长度、核心结论、SEO 关键词），把"建议结构"细化为带复选框（- [ ]）的钩子选项清单，并新增"Notes for Drafting"（写作注意事项）与"Sources to Cite"（来源与用途映射）两个板块，方便直接复制填写。

步骤 4：保存已批准的提纲

用户批准提纲后，将其保存为博客文章文件夹中的OUTLINE.md，并确认已保存。

步骤 5：提交提纲（如果在 git 仓库中）

检查当前目录是否为 git 仓库；
如果是：暂存博客文章文件夹、resources 和OUTLINE.md，使用如下提交信息创建 commit：

docs: Add outline for blog post - [topic-name]

推送到远程仓库；如果不是 git 仓库，则跳过此步骤并告知用户。

从这一步可以看到，blog-draft 把"版本控制"内建为流程的一部分——这与 claude-howto 仓库"用 Claude Code 驱动文档工程"的整体定位一致，文档本身就是由 git 管理、可回滚、可协作的资产。

步骤 6：撰写草稿

基于已批准的提纲撰写完整草稿，要求：

严格按照OUTLINE.md的结构进行编写；
包含：有吸引力的引言和开场钩子、清晰的章节标题、来自研究的支撑证据和示例、段落间自然流畅的过渡、强有力的结尾和核心收获；
引用：所有比较、统计数据和事实性陈述都必须引用原始来源；
将草稿保存为draft-v0.1.md。

草稿的格式规范如下：

# [博客文章标题] *[可选：副标题或标语]* [包含行内引用的完整正文...] --- ## 参考资料 - [1] 来源 1 标题 - URL 或引用 - [2] 来源 2 标题 - URL 或引用 - [3] 来源 3 标题 - URL 或引用

引用要求是这一步骤的硬性标准：

每个数据点、统计信息或比较都必须带有行内引用；
使用编号引用[1]、[2]等，或命名引用[Source Name]；
在文末的参考资料部分链接这些引用；
示例："研究表明，65% 的开发者更偏好 TypeScript [1]"；"React 在渲染速度上比 Vue 快 20% [React Benchmarks 2024]"。

配套的 03-skills/blog-draft/templates/draft-template.md 给出了文章正文的结构化骨架：标题 → 副标题/标语 → 作者与日期 → 开场钩子 → 背景与论点 → 分节正文（支持引言引用块、关键结论加粗提示）→ 结论 → 参考资料，并预留作者简介与相关文章推荐位，可以直接作为成稿模板使用。

步骤 7：提交草稿（如果在 git 仓库中）

与步骤 5 同理，暂存草稿文件并提交：

docs: Add draft v0.1 for blog post - [topic-name]

步骤 8：向用户展示草稿以供审阅

向用户展示草稿内容并询问反馈：

整体印象如何？
哪些部分需要扩展或压缩？
是否需要调整语气？
是否缺少关键信息？
有没有具体编辑或重写建议？

等待用户回复。这是最后一个强制门控点。

步骤 9：迭代或定稿

如果用户要求修改：

记录所有修改请求；
返回步骤 6，并做以下调整：
- 将版本号递增（v0.2、v0.3 等）；
- 纳入所有反馈；
- 保存为draft-v[X.Y].md；
- 重复步骤 7–8。

如果用户批准：

确认最终草稿版本；
如用户要求，可重命名为final.md；
总结博客文章创建过程：一共创建了多少个版本、各版本之间的关键变化、最终字数、创建了哪些文件。

四、版本跟踪与输出文件结构

SKILL.md强调所有草稿都会以递增版本号保留：

draft-v0.1.md— 初始草稿
draft-v0.2.md— 第一轮反馈后
draft-v0.3.md— 第二轮反馈后
以此类推

这样做的好处是可以跟踪博客文章的演变过程，并在需要时回退——这与重构领域"小步提交、随时可回滚"的安全实践一脉相承。

最终整个流程产出的文件结构为：

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（如果还有更多迭代）

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析