gr-blog-post

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

⚠️ 2C 产品的写作调整

本 skill 默认 dev/B2B 读者。写 2C 教育/医疗/金融（YMYL） 内容时：

E-E-A-T 加重：需可验证作者/审核资质 + 方法论透明页，不能只靠"团队"署名（Google：Trust 是 E-E-A-T 核心）。
选题双轨：红利词（政策/改革/新版）+ 长尾高转化词（题型/场景/分数级）。
Key Stats 表格的数字必须有权威来源、前后一致——YMYL 品类不可编造，否则排名修复极难。
分发渠道换成 2C 社区/短视频（小红书/Reddit/TikTok/Naver 카페），而非 dev blog。

完整 2C 渠道数据库 + 公开来源见 →

gingiris-seo-geo/references/2c-adaptation.md

本 skill 默认面向 dev/B2B 读者。撰写 2C 教育/医疗/金融（YMYL） 类内容时：

强化 E-E-A-T 要求：需提供可验证的作者/审核资质 + 方法论透明页面，不能仅依赖「团队」署名（Google 指出：信任是 E-E-A-T 的核心）。
双轨选题策略：红利关键词（政策/改革/新版本）+ 长尾高转化关键词（题型/场景/分数等级）。
Key Stats 表格中的数据必须具备权威来源且前后一致——YMYL 品类绝不可编造数据，否则排名修复难度极大。
分发渠道切换为 2C 社区/短视频平台（小红书/Reddit/TikTok/Naver 카페），而非开发者博客。

完整 2C 渠道数据库 + 公开来源请见 →

gingiris-seo-geo/references/2c-adaptation.md

gr-blog-post — Jekyll 博客发布

产出的文章必须符合

Iris 文风 5 要素（详见

references/writing-voice-iris.md

）

Iris 文风 5 要素（详情见

references/writing-voice-iris.md

）

时间锚定开场 —— 不说"SEO 很重要"，说"2026-04-10，凌晨 3 点，后台流量归零"
括号旁白 —— 正文一句，括号里挤私货（"...—— 别问怎么知道的"）
em-dash 转折 —— 不用"但是"，用
```
——
```
Key Stats 表格 —— 文章开头或 H2 下第一屏放一个硬数据表，3-5 行
GEO 直接答案段落 —— 文章顶部一段 30-50 字直接回答主问题，方便 AI 爬虫抽取

时间锚定开场 —— 不说「SEO 很重要」，要说「2026-04-10，凌晨 3 点，后台流量归零」
括号旁白 —— 正文一句，括号里补充私货（「...—— 别问怎么知道的」）
em-dash 转折 —— 不用「但是」，使用
```
——
```
Key Stats 表格 —— 在文章开头或 H2 下方首屏位置放置硬数据表，3-5 行即可
GEO 直接答案段落 —— 文章顶部放置一段 30-50 字的内容直接回答核心问题，方便 AI 爬虫抽取

技术 frontmatter 模板

yaml

---
layout: post
title: "主关键词前置，副标题用冒号：不超过 60 字"
date: 2026-04-15 14:30:00 +0800
categories: [seo, growth]
tags: [...]
canonical_url: https://gingiris.tools/blog/2026/04/15/slug/
hreflang_ja: /blog/2026/04/15/slug-ja/
hreflang_ko: /blog/2026/04/15/slug-ko/
post_description: "150-160 字 meta description，含主关键词"
faq:
  - q: "直接问句"
    a: "30-50 字硬答案"
---

yaml

---
layout: post
title: "主关键词前置，副标题用冒号：不超过 60 字"
date: 2026-04-15 14:30:00 +0800
categories: [seo, growth]
tags: [...]
canonical_url: https://gingiris.tools/blog/2026/04/15/slug/
hreflang_ja: /blog/2026/04/15/slug-ja/
hreflang_ko: /blog/2026/04/15/slug-ko/
post_description: "150-160 字 meta description，含主关键词"
faq:
  - q: "直接问句"
    a: "30-50 字硬答案"
---

发布流程

1. 选题

读
```
gr-seo-patrol
```
输出，找"top 30 但没 top 10"的关键词
或读
```
gr-competitor
```
，找对手新打法
❌ 不做重复主题（先
```
site:
```
查站内是否已有）

读取
```
gr-seo-patrol
```
输出内容，寻找「排名前30但未进前10」的关键词
或读取
```
gr-competitor
```
内容，挖掘竞争对手的新打法
❌ 不做重复主题（先通过
```
site:
```
指令查询站内是否已有相关内容）

2. 写初稿

时间锚定开场（当前日期 + 具体场景）
第一屏：GEO 直接答案段（30-50 字）+ Key Stats 表（硬数据）
H2 结构：问题 → 框架 → 案例 → 陷阱 → 下一步
每个 H2 下 200-400 字，不超过 600 字

采用时间锚定开场（当前日期 + 具体场景）
首屏内容：GEO 直接答案段（30-50 字）+ Key Stats 数据表（硬数据）
H2 结构：问题 → 框架 → 案例 → 陷阱 → 下一步
每个 H2 下内容控制在 200-400 字，不超过 600 字

3. 内链

向前：链接 2-3 篇已发布的同主题文章（用主关键词作 anchor）
向后：站内 index / hub 页
权重传导：从流量最大的 3 篇文章加内链到新文

向前链接：关联 2-3 篇已发布的同主题文章（用主关键词作为锚文本）
向后链接：指向站内索引/ hub 页面
权重传导：从流量最高的 3 篇文章添加内链至新文章

4. FAQ Schema

3-5 个问答
问句必须是用户真实搜索句（从 GSC / People also ask 抓）
答案硬、短、可引用

设置 3-5 个问答
问句必须是用户真实搜索语句（从 GSC / People also ask 抓取）
答案要精准、简短、可引用

5. Canonical 策略

默认 self-canonical
如果是同主题系列的分篇 → canonical 指向 master
ja/ko 翻译版 → 自身 canonical + hreflang 互指

默认自指 canonical
如果是同主题系列的分篇文章 → canonical 指向主文章
日/韩语翻译版 → 自身 canonical + hreflang 互指

6. 多语言同步

用
```
scripts/sync-i18n.py
```
（roadmap）从英文自动产日韩草稿
人工过一遍（机翻硬伤 + 文化适配）
日韩版本独立 slug，不复用英文 slug

使用
```
scripts/sync-i18n.py
```
（规划中）从英文自动生成日韩草稿
人工审核（修正机翻硬伤 + 文化适配）
日韩版本使用独立 slug，不复用英文 slug

7. 发布（可执行清单）

目标 repo：

Gingiris-1031/growth-tools

（真站 gingiris.tools，Vercel 部署

origin/main

，写入后 ~50-90s 自动构建）

⚠️ 前置：先过 Gingiris-1031 GitHub 安全规则（memory

gingiris_1031_safety_rules.md

，P0）：

提交身份 =
```
Iris Wei <iris.wei@gingiris.com>
```
（不是机器名/本机 hostname）
单行 commit message：
```
post: {slug} ({lang})
```
——无 Claude trailer、无多段正文
不 burst：能合并就合并成 1 个 commit；>10 commits/小时 = 停下重排

发布 = GitHub Contents API PUT（不要本地

git push

）：

bash

undefined

目标仓库：

Gingiris-1031/growth-tools

（正式站点 gingiris.tools，通过 Vercel 部署

origin/main

，提交后约 50-90s 自动构建）

⚠️ 前置要求：先遵守 Gingiris-1031 GitHub 安全规则（详见记忆库

gingiris_1031_safety_rules.md

，最高优先级）：

提交身份 =
```
Iris Wei <iris.wei@gingiris.com>
```
（不可使用机器名/本机主机名）
单行提交信息：
```
post: {slug} ({lang})
```
——无 Claude 尾注、无多段正文
避免批量提交：能合并就合并为 1 个提交；>10 次提交/小时 = 暂停并重新整理

发布方式 = GitHub Contents API PUT（不要使用本地

git push

）：

bash

undefined

token 只从 secrets.env 读，绝不内联/硬编码进脚本或 SKILL.md

token 仅从 secrets.env 读取，绝不内联/硬编码到脚本或 SKILL.md

source ~/.config/gingiris/secrets.env # 提供 GITHUB_PAT

SLUG="your-post-slug"; LANG="en" FILE="_posts/$(date +%F)-${SLUG}.md" curl -s -X PUT
-H "Authorization: Bearer $GITHUB_PAT"
-H "Accept: application/vnd.github+json"
"https://api.github.com/repos/Gingiris-1031/growth-tools/contents/${FILE}"
-d "{"message":"post: ${SLUG} (${LANG})", "content":"$(base64 < draft.md | tr -d '\n')", "committer":{"name":"Iris Wei","email":"iris.wei@gingiris.com"}}"


> 更新已存在的文件：先 `GET .../contents/{path}` 拿 `sha`，把 `"sha":"..."` 加进 PUT body。

**发布后验证（按顺序全过才算发完）**：
1. [ ] 等 Vercel 部署完成（~50-90s；可 `curl -sI https://gingiris.tools/` 确认站点存活）
2. [ ] `curl -sI https://gingiris.tools/blog/{yyyy}/{mm}/{dd}/{slug}/` → **HTTP 200**（404 = permalink/date/`future: true` 配错，先修再往下）
3. [ ] GSC 手动 Request Indexing（URL 检查 → 请求编入索引；新域抓取慢，这步不能省）
4. [ ] IndexNow 推送到 Bing（大模型 discover 主要走 Bing 索引，见 `gr-geo-cite`）

source ~/.config/gingiris/secrets.env # 提供 GITHUB_PAT


> 更新已存在的文件：先通过 `GET .../contents/{path}` 获取 `sha`，将 `"sha":"..."` 添加到 PUT 请求体中。

**发布后验证（需全部通过才算发布完成）**：
1. [ ] 等待 Vercel 部署完成（约 50-90s；可通过 `curl -sI https://gingiris.tools/` 确认站点存活）
2. [ ] `curl -sI https://gingiris.tools/blog/{yyyy}/{mm}/{dd}/{slug}/` → **HTTP 200**（404 = 永久链接/日期/`future: true` 配置错误，需先修复再继续）
3. [ ] 在 GSC 手动请求索引（URL 检查 → 请求编入索引；新域名抓取速度慢，此步骤不可省略）
4. [ ] 通过 IndexNow 推送到 Bing（大模型发现主要依赖 Bing 索引，详见 `gr-geo-cite`）

hreflang 验收 checklist（发 ja/ko 版或补翻译时必做）

hreflang 验收清单（发布日/韩语版本或补充翻译时必须执行）

背景：i18n 基线曾有多处 hreflang bug（KO self-loop、JA→EN 指
/en/
首页弱链、EN 缺 alternate），后果是日韩索引长期 0（memory
i18n_baseline.md
）。全站修复 commit b667208 后抽检全绿——新文章不要把 bug 加回来。

EN/JA/KO frontmatter 互指：
```
hreflang_ja
```
/
```
hreflang_ko
```
/
```
hreflang_en
```
指向具体对端文章（绝不指
```
/en/
```
首页）
每页 emit 自指 hreflang（ko 页必须有
```
hreflang="ko"
```
指自己，不能出现指自己的
```
hreflang="ja"
```
）
```
x-default
```
存在且指 EN 版
每页 self-canonical（ja/ko 不 canonical 到 EN；带尾斜杠，和 sitemap 一致）
发布后 curl 抽验：

bash

for u in "$EN_URL" "$JA_URL" "$KO_URL"; do
  echo "== $u"
  curl -s "$u" | grep -oE '<link rel="(alternate|canonical)"[^>]*>'
done

背景：i18n 基线曾存在多处 hreflang 漏洞（韩语自循环、日语→英语指向
/en/
首页弱链、英语缺失替代链接），导致日韩索引长期为 0（详见记忆库
i18n_baseline.md
）。全站修复提交 b667208 后抽检全部合格——新文章请勿再次引入此类漏洞。

英/日/韩语 frontmatter 互指：
```
hreflang_ja
```
/
```
hreflang_ko
```
/
```
hreflang_en
```
指向对应语言的具体文章（绝不指向
```
/en/
```
首页）
每页输出自指 hreflang（韩语页面必须有
```
hreflang="ko"
```
指向自身，不可出现
```
hreflang="ja"
```
指向自身的情况）
```
x-default
```
存在且指向英语版本
每页使用自指 canonical（日/韩语版本不将 canonical 指向英语版本；需带尾斜杠，与站点地图一致）
发布后通过 curl 抽检：

bash

for u in "$EN_URL" "$JA_URL" "$KO_URL"; do
  echo "== $u"
  curl -s "$u" | grep -oE '<link rel="(alternate|canonical)"[^>]*>'
done

验收：每页 hreflang 完整（self + 对端 + x-default）且三页双向回链成对，canonical 自指

验收标准：每页 hreflang 完整（自身 + 对应语言版本 + x-default）且三页双向回链成对，canonical 自指

undefined

undefined

8. 发布后 24h

加入
```
gr-seo-patrol
```
监控名单
社交平台分发（推特 / LinkedIn / dev.to，走
```
gr-social-distill
```
）

将文章加入
```
gr-seo-patrol
```
监控名单
在社交平台分发（推特 / LinkedIn / dev.to，通过
```
gr-social-distill
```
执行）

dev.to 二发规则（⚠️ canonical 红线）

dev.to 二次发布规则（⚠️ canonical 红线）

✅ dev.to 文章 canonical_url 必须指向 dev.to 自身（self-canonical），绝不指向 gingiris.tools
- 正确：
```
canonical_url: https://dev.to/iris1031/article-slug-xxxx
```
- 错误：
```
canonical_url: https://gingiris.tools/blog/...
```
  （会让 dev.to 文章被 Google 视为副本，不参与 SERP）
✅ 发布时间差 ≥7 天（不要和 gingiris.tools 同天发）
✅ 末尾加 "Originally published at gingiris.tools" 建立双向 reference
❌ 不要从 Jekyll frontmatter 直接复制 canonical_url 到 dev.to，那个是 gingiris.tools 的地址

✅ dev.to 文章的 canonical_url 必须指向 dev.to 自身（自指 canonical），绝不可指向 gingiris.tools
- 正确示例：
```
canonical_url: https://dev.to/iris1031/article-slug-xxxx
```
- 错误示例：
```
canonical_url: https://gingiris.tools/blog/...
```
  （会导致 dev.to 文章被 Google 视为副本，无法参与 SERP 排名）
✅ 发布时间差 ≥7 天（不要与 gingiris.tools 同日发布）
✅ 在末尾添加「Originally published at gingiris.tools」建立双向引用
❌ 不要直接将 Jekyll frontmatter 中的 canonical_url 复制到 dev.to，该地址属于 gingiris.tools

反模式

❌ 不要用 AI 味重的模板（"In today's digital landscape..."）—— 发布前跑
```
skills/gr-geo-cite/scripts/citability-scorer.py
```
，页面分 ≥ 75 才算过
❌ 不要 H1 堆关键词
❌ 不要忘记 hreflang —— 已发布的旧文补翻译时要回改原文 frontmatter
❌ 不要同一关键词发 3 篇 —— cannibalization 立刻找上门
❌ dev.to canonical 指向 gingiris.tools —— 死链或副本问题，永远 self-canonical

❌ 避免使用 AI 痕迹过重的模板（如「In today's digital landscape...」）——发布前运行
```
skills/gr-geo-cite/scripts/citability-scorer.py
```
，页面得分 ≥ 75 才算合格
❌ 不要在 H1 中堆砌关键词
❌ 不要忘记设置 hreflang —— 已发布旧文补充翻译时需回改原文 frontmatter
❌ 同一关键词不要发布 3 篇文章 —— 会立刻引发关键词 cannibalization（内耗）问题
❌ dev.to 文章的 canonical 指向 gingiris.tools —— 会导致死链或副本问题，必须始终使用自指 canonical

级联推荐

写完 →
```
gr-seo-patrol
```
加监控
发现是系列稿 →
```
gr-blog-post
```
继续产第 2 篇并设 canonical
英文发完 24h → 手动触发日韩翻译

文章撰写完成 → 调用
```
gr-seo-patrol
```
添加监控
若判定为系列稿件 → 使用
```
gr-blog-post
```
继续生成第 2 篇并设置 canonical
英文版本发布 24h 后 → 手动触发日韩翻译

API 依赖

Service	Env var	来源
GitHub PAT	`GITHUB_PAT`	`~/.config/gingiris/secrets.env` （source 后使用，不内联）
DeepSeek / Teamo（翻译）	`DEEPSEEK_API_KEY` / `TEAMOROUTER_API_KEY`	同上

服务	环境变量	来源
GitHub PAT	`GITHUB_PAT`	`~/.config/gingiris/secrets.env` （source 后使用，不内联）
DeepSeek / Teamo（翻译）	`DEEPSEEK_API_KEY` / `TEAMOROUTER_API_KEY`	同上

Citability-by-Design Spec (mandatory for NEW articles, 2026-05-18+)

Citability-by-Design 规范（2026-05-18+ 新文章强制执行）

Rationale: Verified 2026-05-07 that retrofitting old articles hits a ~65-68/100 citability ceiling no matter what (booster passages, surgical rewrites, splitting all produce diminishing returns). Writing new articles from this spec produces 75-85 baseline directly. Spec saves ~3 hours of post-hoc citability fixing per article.

理由：2026-05-07 验证发现，无论采取何种方式（ booster 段落、精准改写、拆分内容）改造旧文章，其可引用性得分上限约为 65-68/100，回报递减。遵循本规范撰写新文章可直接达到 75-85 的基线得分。本规范每篇文章可节省约 3 小时的事后可引用性修复时间。

Per-section structural requirements

各章节结构要求

Every H2/H3 section must satisfy ALL of:

Word count: 134-167 (the AI-extraction sweet spot validated by zubair-trabzada/geo-seo-claude scoring)
- Under 134 → self_containment drops below 10/25
- Over 167 → same penalty for being too long for AI chunks
- Use a word counter as you draft

Opening sentence = definition pattern, one of:

```
[Thing] is [definition]
```
```
[Thing] refers to [scope]
```
```
[Thing] means [unpacking]
```
```
In other words, [Thing] is...
```
```
[Thing] can be defined as...
```

Section contains at least ONE of each:
- ✅ Original research signal: "Our X-launch dataset", "We tracked", "Our 2026 audit measured", "Our analysis of N samples"
- ✅ Specific number with unit: "60K stars", "30 launches", "$79/mo", "67%"
- ✅ Specific named product/tool: "Taplio ($39/mo)", "Surfe", "PH Deck", "Loom" — by name not "[the tool]"

每个 H2/H3 章节必须满足以下所有要求：

字数：134-167（经 zubair-trabzada/geo-seo-claude 评分验证，此为 AI 抽取的最佳区间）
- 少于 134 → 自包含性得分低于 10/25
- 超过 167 → 因内容过长不适合 AI 拆分，同样会被扣分
- 撰写时使用字数统计工具

开篇句采用定义式结构，可选以下任意一种：

```
[事物] 是 [定义]
```
```
[事物] 指的是 [范围]
```
```
[事物] 意味着 [解读]
```
```
换句话说，[事物] 是...
```
```
[事物] 可被定义为...
```

章节至少包含以下各一项：
- ✅ 原创研究信号：「我们的 X 发布数据集」「我们追踪了」「我们 2026 年的审计测量了」「我们对 N 个样本的分析显示」
- ✅ 带单位的具体数字：「60K 星标」「30 次发布」「$79/月」「67%」
- ✅ 具体命名的产品/工具：「Taplio ($39/月)」「Surfe」「PH Deck」「Loom」——必须使用名称而非「[某工具]」

Heading conventions

标题规范

H1 = page title (≤ 70 chars after title-suffix fix from 2026-05-07)
H2 should be question form ~40% of the time:
- ✅ "How do I get cited by Perplexity in 2026?"
- ✅ "What is the GEO three-piece set?"
- ❌ "Perplexity citation strategy"
Each H2 should contain primary keyword or clear question intent

H1 = 页面标题（2026-05-07 标题后缀修复后 ≤ 70 字符）
H2 约 40% 需采用问句形式：
- ✅ 「2026 年如何获得 Perplexity 的引用？」
- ✅ 「什么是 GEO 三件套？」
- ❌ 「Perplexity 引用策略」
每个 H2 应包含核心关键词或明确的问题意图

Article-level requirements

文章级要求

5-12 H2 sections (sweet spot: 7-8)
TL;DR or "Citable Statistics" block IN FIRST H2 (becomes top-scored passage)
FAQ Schema JSON-LD at end (5+ Q&A using exact User-Search-Form questions)
```
last_modified_at:
```
frontmatter (flows through to dateModified schema)
canonical_url self-reference
hreflang_ja / hreflang_ko if multilingual variants exist

包含 5-12 个 H2 章节（最佳区间：7-8 个）
在第一个 H2 中加入 TL;DR 或「可引用统计数据」模块（将成为得分最高的段落）
在末尾添加 FAQ Schema JSON-LD（使用用户真实搜索句式设置 5+ 个问答）
添加
```
last_modified_at:
```
frontmatter（将同步到 dateModified schema）
canonical_url 自指
若存在多语言版本，需添加 hreflang_ja / hreflang_ko

Citability self-check before publishing

发布前可引用性自查

Run before committing the article:

bash

undefined

在提交文章之前运行：

bash

undefined

兼容两种安装位置：优先 monorepo 相对路径，fallback 本机安装

兼容两种安装位置：优先使用 monorepo 相对路径， fallback 到本机安装路径

SCORER="skills/gr-geo-cite/scripts/citability-scorer.py" [ -f "$SCORER" ] || SCORER="$HOME/.claude/skills/gr-geo-cite/scripts/citability-scorer.py" python3 "$SCORER" --file /local/path/to/draft.html


Target: page score ≥ 75. If under 70, revise top 2 weakest passages.

SCORER="skills/gr-geo-cite/scripts/citability-scorer.py" [ -f "$SCORER" ] || SCORER="$HOME/.claude/skills/gr-geo-cite/scripts/citability-scorer.py" python3 "$SCORER" --file /local/path/to/draft.html


目标：页面得分 ≥ 75。若低于 70，需修改得分最低的前 2 个段落。

Anti-patterns (avoid)

需避免的反模式

❌ Long expository paragraphs (200+ words) — split into 2 sections at 134-167 each
❌ Generic transitions ("Now let's discuss...") — replace with definition pattern
❌ Marketing fluff ("the best way to") — replace with measured claims with data
❌ "[Tool name]" placeholders — always cite the specific tool by name + price
❌ Bullet lists with single words — combine into prose with definition + example pattern

❌ 过长的说明性段落（200+ 字）——拆分为 2 个 134-167 字的章节
❌ 通用过渡语（如「现在我们来讨论...」）——替换为定义式结构
❌ 营销话术（如「最佳方式」）——替换为带数据的严谨表述
❌ 「[工具名称]」占位符——始终引用具体工具的名称 + 价格
❌ 仅含单个单词的项目符号列表——合并为包含定义 + 示例的 prose

Real-data benchmark

真实数据基准

Articles from 2026-05-07 audit (without this spec):

Article (old, retrofit)	Score	Pattern
PH playbook master	65	Top passage 74, dragged by 62s
Social listening	68	Best of the 5 (early Citable Stats)
Community directory	62	Lifted from 54 via booster (+12% from 0 to 1 sweet-spot passage)

Predicted from spec (NEW articles):

Spec compliance	Predicted score
All sections 134-167 + definition pattern + 1 original signal	78-85
80% sections compliant, 20% legacy structure	72-77
50% compliant	65-70 (same as retrofit ceiling)

The marginal value of strict compliance is ~10 points vs partial compliance.

2026-05-07 审计的旧文章（未遵循本规范）：

文章（旧版，改造后）	得分	模式
PH 指南主篇	65	顶部段落得分 74，被多个 62 分段落拉低
社交监听	68	5 篇中最佳（提前加入了可引用统计数据）
社区目录	62	通过 booster 段落从 54 分提升（添加 1 个最佳区间段落提升了 12%）

遵循本规范的预测得分（新文章）：

规范合规度	预测得分
所有章节符合 134-167 字 + 定义式结构 + 1 项原创信号	78-85
80% 章节合规，20% 采用 legacy 结构	72-77
50% 合规	65-70（与改造旧文的得分上限相同）

严格合规比分部分合规的边际价值约为 ~10 分。

gr-blog-post

Original

Translation

⚠️ 2C 产品的写作调整

⚠️ 2C 产品的写作调整

gr-blog-post — Jekyll 博客发布

gr-blog-post — Jekyll 博客发布

产出的文章必须符合

产出的文章必须符合

Iris 文风 5 要素（详见 references/writing-voice-iris.md）

Iris 文风 5 要素（详情见 references/writing-voice-iris.md）

技术 frontmatter 模板

技术 frontmatter 模板

发布流程

发布流程

1. 选题

1. 选题

2. 写初稿

2. 写初稿

3. 内链

3. 内链

4. FAQ Schema

4. FAQ Schema

5. Canonical 策略

5. Canonical 策略

6. 多语言同步

6. 多语言同步

7. 发布（可执行清单）

7. 发布（可执行清单）

token 只从 secrets.env 读，绝不内联/硬编码进脚本或 SKILL.md

token 仅从 secrets.env 读取，绝不内联/硬编码到脚本或 SKILL.md

hreflang 验收 checklist（发 ja/ko 版或补翻译时必做）

hreflang 验收清单（发布日/韩语版本或补充翻译时必须执行）

验收：每页 hreflang 完整（self + 对端 + x-default）且三页双向回链成对，canonical 自指

验收标准：每页 hreflang 完整（自身 + 对应语言版本 + x-default）且三页双向回链成对，canonical 自指

8. 发布后 24h

8. 发布后 24h

dev.to 二发规则（⚠️ canonical 红线）

dev.to 二次发布规则（⚠️ canonical 红线）

反模式

反模式

级联推荐

级联推荐

API 依赖

API 依赖

Citability-by-Design Spec (mandatory for NEW articles, 2026-05-18+)

Citability-by-Design 规范（2026-05-18+ 新文章强制执行）

Per-section structural requirements

各章节结构要求

Heading conventions

标题规范

Article-level requirements

文章级要求

Citability self-check before publishing

发布前可引用性自查

兼容两种安装位置：优先 monorepo 相对路径，fallback 本机安装

兼容两种安装位置：优先使用 monorepo 相对路径， fallback 到本机安装路径

Anti-patterns (avoid)

需避免的反模式

Real-data benchmark

真实数据基准

Iris 文风 5 要素（详见
`references/writing-voice-iris.md`
）

Iris 文风 5 要素（详情见
`references/writing-voice-iris.md`
）