技术博客写作专家，专注于 AI、编程、运维等技术领域的深度写作。自动抓取素材、生成配图、输出符合 Hugo 规范的博客文章。使用此 skill 当用户需要：(1) 撰写技术博客文章 (2) 整理技术资料成文章 (3) 介绍新工具/新技术
这不是一个内容生成工具，而是一个观点表达工具。
每篇文章必须能回答：我到底推荐什么？反对什么？读者看完能带走什么判断？
如果写完一篇文章，删掉所有观点句子后文章还能成立——说明这篇文章没有观点，是废品。
content/posts/hugo.toml 中动态获取步骤1 确认需求 → 步骤2 深度研究 → 步骤3 形成判断（⛔） → 步骤4 撰写 →
步骤5 封面图+配图 → 步骤6 质量门禁（⛔） → 步骤7 发布+分发
⚠️ 每一步必须完成后才能进入下一步，不可跳过。特别是"形成判断"⛔ 步骤。
向用户确认：
如果用户已提供，直接进入步骤 2。
用户提供的链接必须认真阅读全文，不可凭标题猜测。按素材类型分流：
bash .claude/skills/youtube-fetch/fetch.sh <url>
# 等几分钟（无字幕视频会自动 whisper 转写）
# 然后 Read cache/youtube/<videoId>/transcript.txt 拿全文
# Read cache/youtube/<videoId>/metadata.json 拿元数据
gh CLI 或 WebFetch GitHub URL这是最常见也是最容易写废的场景。当用户说「参考这个链接/文章，写一篇 X 相关的文章」：
⛔ 绝对禁止：
✅ 必须做：
自检问题：如果读者同时读了参考文章和你的文章，他会觉得"白读了"还是"这两篇互补、各有价值"？如果是前者，回去重写。
ls content/posts/ai/
目的：避免与已有文章重复；找到可以内链的相关旧文。
这是整个 skill 最重要的步骤。不完成这一步，禁止开始写作。
在写任何正文之前，必须先产出一份判断框架，回答以下 6 个问题：
用一句话表达：关于 [主题]，我认为 [判断]，因为 [理由]。
示例：
列出读者可能相信但实际上错误或误导的观点。
示例：
不是引用官方宣传，而是真实的使用经验、benchmark 数据、社区反馈。
示例：
明确的边界条件和 trade-off，不要说"视情况而定"。
示例：
一个具体的行动建议或判断框架。
示例：
不是章节目录，而是论证逻辑：先建立什么认知 → 打破什么误解 → 给出什么判断 → 用什么证据支撑。
示例：
1. 开头：抛出反常识的结论（"模型是 AI Agent 中最不重要的部分"）
2. 建立背景：为什么这个结论违反直觉
3. 核心论证：用 3 个真实案例证明
4. 误区拆解：指出常见的错误做法
5. 实操指南：读者现在就能用的方法
6. 边界说明：什么时候这个建议不适用
在判断框架完成后，用以下标准检查文章是否值得读者花 5 分钟：
认知升级（读者学到了自己没想到的判断）：
读完这篇文章后，读者会改变什么观点或决策？如果答案是"不会改变任何事"，这篇文章不值得写。
可带走的东西（马上能用）：
文章必须包含至少一个读者可以今天就用的具体产物：
- 决策框架/流程图（"遇到 X 就选 Y"）
- 可复制的配置/命令/代码片段
- 速查表/对比表
- 具体的预算/方案建议
避坑价值（本来会踩的坑）：
文章必须包含至少 2 个"如果不读这篇文章，读者可能犯的具体错误"。不是抽象的误区，是会导致浪费时间或金钱的具体坑。
⛔ 如果上面 6+1 个问题任何一个回答是空的或模糊的，禁止进入下一步。回去补充研究。
基于步骤 3 的判断框架写作，不是从零开始"生成内容"。
完整模板详见 references/frontmatter-template.md。
关键规则：
[[params.faqItems]]）第一优先：观点驱动
第二优先：证据支撑
第三优先：反常识价值
第四优先：可带走价值
第五优先：边界诚实
不要一次性生成全文。按章节写，每写完一个章节立即自检并打磨。
写作节奏：
禁止模式：
合格的段落长度：
必须做：
禁止做：
关键词密度：
文章结构：
Meta 优化：
避免的 SEO 错误：
外层反引号数量必须大于内层。
默认工作流：先写英文版完整草稿 → 暂停向用户汇报 → 确认后再写中文版。
为什么不能一次两版全写完：
汇报模板（写完英文版后）：
英文版草稿完成：<文章目录>/index.md
- 字数：约 N 字
- 核心立场：<一句话总结文章观点>
- 章节结构：<H2 列表>
- 主要案例/数据：<3 条>
- 预计配图：<mermaid X 个 / architecture Y 个 / AI 生图 Z 张>
是否按此方向写中文版？有什么要调整的？
用户可能反馈：
例外：用户明确说"一次写完两版"或"只写中文"时跳过这个 checkpoint。
文章写完后，根据内容生成图片。
调用 blog-cover-image skill：
/blog-cover-image <文章目录> --quick
cover.webp，1200×630px，WebP 质量 85第一步：按图表类型选对应的 skill
| 图表类型 | 首选 skill | 输出形式 | 渲染方式 |
|---|---|---|---|
| 流程图 / 决策树 / 时序图 / 状态机 / 思维导图 / ER 图 / 甘特图 / 类图 | mermaid |
```mermaid 代码块 |
Hugo 主题原生渲染（本地 JS） |
| 分层系统架构（User→App→Data→Infra） | architecture |
内嵌 HTML + CSS | Hugo unsafe=true 直接渲染 |
| 富视觉信息卡 / Bento 概览 / 数据看板 / 对比矩阵 | blog-diagram |
AI 生成 WebP |  |
| 概念插图 / 场景化插画 | blog-illustrator |
AI 生成 WebP |  |
| 封面图 | blog-cover-image |
AI 生成 WebP |  |
第二步：按优先级规则决策（文本结构化 > AI 位图）
第三步：调用
# mermaid / architecture —— 让 AI 直接写代码嵌入文章 markdown
# （不是一个独立的 CLI 命令，是写作过程中直接产出）
# AI 生图 —— 独立 skill 调用
/blog-diagram <文章目录> --layout bento-grid --style corporate
/blog-illustrator <文章目录> --quick
专业图表（按需启用，不在默认流程里）：
graphviz 复杂依赖 / 调用图uml 类图 / 时序图 / 活动图 / 组件图network 企业网络拓扑（Cisco / Citrix 图标）bpmn 业务流程 / 集成模式cloud AWS / Azure / GCP / 阿里云架构图（官方图标）archimate 企业架构（TOGAF）infographic KPI 卡片 / 时间线 / SWOTinfocard 编辑风格信息卡canvas 自由定位思维导图 / 知识图谱vega 数据驱动图表（柱状 / 折线 / 热力 / 散点）需要哪种按文件名查阅 .claude/skills/<name>/SKILL.md。
⚠️ 本项目 Hugo 集成规范（已配置到位，直接用，不要改）：
| 配置点 | 位置 | 作用 |
|---|---|---|
| mermaid JS 本地托管 | static/js/mermaid.min.js |
不依赖 jsdelivr CDN，国内读者加载稳定 |
| mermaid 深色主题 | layouts/_partials/mermaid.html |
自定义 themeVariables 让菱形 / 连线 / 分支标签在深色背景高对比 |
| HTML unsafe 开启 | hugo.toml → markup.goldmark.renderer.unsafe = true |
architecture skill 的 HTML 可直接嵌入 |
避坑经验（2026-04 沉淀）：不要用默认的 cdn.jsdelivr.net 加载 mermaid.esm，国内读者会看不到渲染结果；架构图也不要走 AI 生图，mermaid/architecture 的可编辑性和响应式远胜 WebP。
配图规范（不变）：
diagram-xxx.webp / illustration-xxx.webp / cover.webp一篇文章至少要有封面图 + 2 张内容配图。 纯文字长文没有配图会严重降低读者体验和停留时间。
以下检查项必须全部通过，任何一项不通过必须回去修改。
+++）hugo server 打开文章，所有 mermaid 图表正常渲染（不是代码块原文） 引用的文件确实存在于文章目录.webp；mermaid/architecture 代码块可以各写一份但信息量要对等hugo --minify
content/posts/<category>/<YYYY-MM-DD>-<english-slug>/content/posts/ai/2026-04-14-claude-skills-guide/index.md + index.zh.mdcover.webp 和内容配图 ≥ 2 张已就位categories（违反 URL 规则会影响已索引页面）hugo --minify # 生产构建，检查报错
hugo server -D # 本地预览，确认渲染正常（含封面图/配图/FAQ）
构建失败的常见原因和 fallback：
.webp 扩展名/posts/ 开头（不带 content/）git add content/posts/<category>/<article-dir>/
git commit -m "post: <中文标题或主题>"
git push origin code # 推送到 code 分支自动触发 GitHub Actions 部署
等待 2-5 分钟后访问线上 URL 验证：
https://www.heyuan110.com/posts/<category>/<slug>/（英文）https://www.heyuan110.com/zh/posts/<category>/<slug>/（中文）调用 blog-distributor skill 同步到 dev.to / 掘金 / V2EX / HN：
/blog-distributor <文章目录>
⚠️ 只分发已经线上可访问的文章（dev.to 需要 canonical URL 反向引用本站）。
blog-growth → 选题 → blog-writer（本 skill）
│
├── 封面图
│ └── blog-cover-image（AI 生成 cover.webp）
│
├── 文本结构化图（首选，可编辑 / 响应式 / 双语独立）
│ ├── mermaid（流程图 / 决策树 / 时序图 / 状态机 / ER / 甘特 / 类图 / 思维导图）
│ └── architecture（分层系统架构 HTML）
│
├── AI 位图（富视觉场景）
│ ├── blog-diagram（信息卡 / Bento / 对比矩阵）
│ └── blog-illustrator（概念插图 / 场景插画）
│
└── 专业图表（按需）
├── graphviz / uml / network / bpmn / archimate
└── cloud / infographic / infocard / canvas / vega
→ blog-distributor（分发）
决策口诀：能 mermaid 不 architecture，能 architecture 不 AI 生图；一定要 AI 生图时，信息卡走 blog-diagram，插画走 blog-illustrator。
mermaid 画丑了怎么办：用户反馈"图丑 / 看不清 / 布局乱"时，先优化原图不要换技术栈——查 .claude/skills/mermaid/references/aesthetics.md，按顺序检查：① 节点密度（mindmap ≤ 25、subgraph ≤ 5）→ ② 方向 LR/TB（4+ subgraph 必须 TB）→ ③ 主题变量（fontSize/lineColor/theme）→ ④ classDef 三件套（fill+stroke+color）→ ⑤ subgraph 节点数平衡。把原图美化到位远比换成 HTML grid 好——换技术栈 = 推翻重建 = 没听懂"美化"需求。