refactor: sync 6 project skills to atomstorm upstream via symlinks
Replace local skill directories with symlinks pointing to atomstorm-claude-skills upstream (b83c4d9): write-article, paper-illustration, my-world, dao-analysis, import-draft, multi-review Also removes stale multi-review and paper-illustration variants. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
lizikk
parent
e12c995c3a
commit
376bf52ccd
1
.claude/skills/dao-analysis
Symbolic link
1
.claude/skills/dao-analysis
Symbolic link
@ -0,0 +1 @@
|
||||
/home/kang/apps/atomstorm-claude-skills/dao-analysis
|
||||
@ -1,129 +0,0 @@
|
||||
---
|
||||
name: dao-analysis
|
||||
description: >
|
||||
Structured 8-layer analysis using Dao-Method-Technique-Tool (道-法-术-器) framework.
|
||||
Output: a structured insight document with 8 orthogonal layers from Why to Do,
|
||||
with measurable metrics and iteration rules.
|
||||
|
||||
USE WHEN: User wants to deeply analyze existing content (article, transcript,
|
||||
concept, experience, system prompt, workflow) to extract layered insights.
|
||||
Trigger phrases: 道法术器分析、深度分析、拆解、8层框架、extract insights、
|
||||
analyze this、break this down、这篇文章为什么火。
|
||||
|
||||
DON'T USE WHEN:
|
||||
- User wants to CREATE new content from a topic → use write-article instead.
|
||||
- User wants to REVIEW/CRITIQUE a draft for publishing quality → use multi-review instead.
|
||||
- User wants to IMPORT an external file into vault → use import-draft instead.
|
||||
- User says "写文章"、"生成草稿" → not this skill (creation ≠ analysis).
|
||||
---
|
||||
|
||||
# 道-法-术-器 结构化分析技能
|
||||
|
||||
## 定位
|
||||
|
||||
将任意信息/素材/经验转化为 8 层结构化洞察体系，从"为何"到"怎么做"到"怎么迭代"，每一层正交、可证伪、可追溯。
|
||||
|
||||
## 路由规则（Use when / Don't use when）
|
||||
|
||||
Use this skill when:
|
||||
- 用户提供一段信息（文章、转写、笔记、经验、概念）并要求深度分析
|
||||
- 用户明确要求"道法术器分析"或"8 层框架分析"
|
||||
- 用户需要从素材中提炼可执行的经验体系
|
||||
- 用户说"分析"、"拆解"、"为什么火"、"extract insights"
|
||||
|
||||
Do NOT use this skill when:
|
||||
- 用户想**写新文章**（从选题到草稿） → use `write-article`
|
||||
- 用户想**审查/批评**已有草稿的发布质量 → use `multi-review` or `/review`
|
||||
- 用户想**导入**外部文件到 vault → use `import-draft`
|
||||
- 用户想**加载 vault 上下文** → use `my-world`
|
||||
- 用户说"写文章"、"生成草稿"、"create a draft" → not this skill
|
||||
|
||||
Edge cases:
|
||||
- "分析一下这篇文章为什么火" → **this skill**（分析 = dao-analysis）
|
||||
- "帮我把这篇文章改写成新文章" → **not this skill**（改写创作 = write-article）
|
||||
- "审查我的草稿质量" → **not this skill**（审查 = multi-review）
|
||||
- "拆解这个 system prompt 的设计思路" → **this skill**（拆解 = analysis）
|
||||
|
||||
## 输入
|
||||
|
||||
用户提供以下信息（支持多种形式）：
|
||||
|
||||
| 字段 | 必选 | 说明 |
|
||||
|------|------|------|
|
||||
| 信息 | 是 | 原文/要点/转写/URL（如提供 URL，先用 `url-to-markdown` 采集） |
|
||||
| 使用场景 | 否 | 分析偏向哪个领域（管理/技术/关系/学习等） |
|
||||
| 偏好语汇 | 否 | `修行`（道家隐喻）或 `中性工程化`（默认） |
|
||||
| 输出范围 | 否 | `full`（全 8 层，默认）或 `quick`（仅 L0-L4 精简版） |
|
||||
|
||||
## 工作流
|
||||
|
||||
### Step 1: 读取素材
|
||||
|
||||
- 若用户提供 vault 内笔记路径，使用 Obsidian CLI 读取
|
||||
- 若用户提供 URL，提示可用 `url-to-markdown` 技能先采集
|
||||
- 若用户直接粘贴文本，直接使用
|
||||
|
||||
### Step 2: 证据提取（E# 表）
|
||||
|
||||
在任何分析之前，先提取 6-15 条证据，每条标注：
|
||||
- 编号 E#
|
||||
- 原句/要点（短摘）
|
||||
- 类型：事实 / 观点 / 比喻 / 推测
|
||||
- 可信度：高 / 中 / 低（一句话理由）
|
||||
|
||||
> 这是整个分析的地基。后续每个层级的每条结论都必须回溯到 E#。
|
||||
|
||||
### Step 3: 逐层分析（L0 -> L7）
|
||||
|
||||
严格按顺序执行，不可跳层。每层的判别问题、输出模板、条数要求详见 `references/framework.md`。
|
||||
|
||||
**层级速览**：
|
||||
|
||||
```
|
||||
L0 无极 ─ 信息边界与缺口（不立论，只定范围）
|
||||
L1 太极 ─ 第一性矛盾（核心张力 A <-> B）
|
||||
L2 道 ─ Why：目的/价值/取舍（D# 命题）
|
||||
L3 法 ─ What：世界模型/因果假设（M# 命题）
|
||||
L4 术 ─ How：原则/策略/决策规则（P# 启发式）
|
||||
L5 器 ─ Do：动作/工具/话术/流程（T# 工具包）
|
||||
L6 指标 ─ 加速度/速度/位移观测链
|
||||
L7 迭代 ─ 复盘模板 + 更新规则 + 7天实验
|
||||
```
|
||||
|
||||
**正交规则**：每层只回答自己的判别问题。若一条内容同时回答两个层的问题，必须拆分为两条分别归层。
|
||||
|
||||
**映射规则**：每个低层产物必须标注来自哪些高层结论（ID 引用链）。
|
||||
|
||||
```
|
||||
E# (证据) -> D# (道) -> M# (法) -> P# (术) -> T# (器)
|
||||
-> 指标
|
||||
-> 迭代规则
|
||||
```
|
||||
|
||||
### Step 4: 收束总纲
|
||||
|
||||
用一句话输出：**"在 X 情境，优先 Y 而非 Z"**，标注对应 D#、M#、P#。
|
||||
|
||||
### Step 5: 输出格式化
|
||||
|
||||
- 使用 Markdown 格式，每层用 `## L{n}` 二级标题
|
||||
- 编号系统贯穿全文：E#、D#、M#、P#、T#
|
||||
- quick 模式：只输出 L0-L4，省略 L5-L7
|
||||
|
||||
## 质量门禁
|
||||
|
||||
| 检查项 | 要求 |
|
||||
|--------|------|
|
||||
| 证据覆盖 | 每个 D#/M#/P# 至少引用 1 个 E# |
|
||||
| 正交归层 | 无跨层混写（一段只回答一个层的问题） |
|
||||
| 可证伪性 | 每个 M# 有明确的"若出现__则不成立"信号 |
|
||||
| 映射完整 | P# 标注来源 D#+M#，T# 标注来源 P# |
|
||||
| 取舍明确 | 每个 D# 有"宁可__也要__"结构 |
|
||||
| 指标可测 | L6 每个指标有记录方式、周期、阈值 |
|
||||
|
||||
任一检查项未通过，回退修正后再输出。
|
||||
|
||||
## 参考资料
|
||||
|
||||
完整的 8 层框架规范（每层的判别问题、输出模板、条数要求、注意事项）：
|
||||
- `references/framework.md` — 在执行 Step 3 时加载此文件获取详细规范
|
||||
@ -1,134 +0,0 @@
|
||||
# 道-法-术-器 八层分析框架 — 完整规范
|
||||
|
||||
> 源自：`00-inbox/2026-03-02-dao-method-technique-tool-framework.md`
|
||||
|
||||
---
|
||||
|
||||
## 总规则
|
||||
|
||||
- **披露顺序不可跳层**：L0 -> L1 -> L2 -> L3 -> L4 -> L5 -> L6 -> L7
|
||||
- **归层判别**：一条内容若同时回答两个层的问题，必须拆分为两条分别归层
|
||||
- **每条洞察要可落地可证伪**：必须有证据、前提、边界、可观测信号
|
||||
- **层间映射**：每个低层产物必须标注来自哪些高层结论（ID 引用）
|
||||
|
||||
---
|
||||
|
||||
## 证据层（贯穿全程：先给 E# 再推导）
|
||||
|
||||
在进入 L1 之前，先输出"证据表 E#（6-15 条）"：
|
||||
|
||||
| 字段 | 说明 |
|
||||
|------|------|
|
||||
| E# | 编号 |
|
||||
| 原句/要点 | 短摘 |
|
||||
| 类型 | 事实 / 观点 / 比喻 / 推测 |
|
||||
| 可信度 | 高 / 中 / 低（一句话理由） |
|
||||
|
||||
---
|
||||
|
||||
## L0 无极：信息边界与缺口
|
||||
|
||||
> 不立论，只定范围。
|
||||
|
||||
输出：
|
||||
1. **主题范围**一句话（覆盖什么、不覆盖什么）
|
||||
2. **缺口清单**：若要推到"可执行经验"，还缺哪些信息（<=3 条追问）
|
||||
3. **风险提示**：这份信息可能有哪些偏见/立场/样本局限（<=3 条）
|
||||
|
||||
---
|
||||
|
||||
## L1 太极：第一性矛盾（统一场）
|
||||
|
||||
> 回答：**"这份信息在解决哪一个核心矛盾/张力？"**
|
||||
|
||||
输出：
|
||||
- **核心矛盾**：A <-> B（用对立结构表达）
|
||||
- **目标方向**：倾向 A 还是倾向 B？为什么（引用证据编号）
|
||||
|
||||
---
|
||||
|
||||
## L2 一（道 / Why）：目的、价值、取舍
|
||||
|
||||
> 判别问题：**"什么值得？为了什么？宁可失去什么也要守住什么？"**
|
||||
|
||||
输出 2-5 条，每条模板：
|
||||
- **道-命题 D#**（一句话）
|
||||
- **取舍结构**：宁可__也要__ / 优先__而非__
|
||||
- **证据引用**：E#...
|
||||
|
||||
注意：这一层只谈"价值与目的"，不谈方法。
|
||||
|
||||
---
|
||||
|
||||
## L3 二（法 / What）：世界模型、因果假设
|
||||
|
||||
> 判别问题：**"世界/人性/组织/关系是如何运作的？因果链是什么？"**
|
||||
|
||||
输出 3-7 条，每条：
|
||||
- **模型/因果命题 M#**（一句话）
|
||||
- **关键变量**：X、Y、Z
|
||||
- **因果方向**：X -> Y（在条件 C 下）
|
||||
- **证据引用**：E#...
|
||||
- **可证伪信号**：若出现__则此模型可能不成立
|
||||
|
||||
注意：这一层只解释"是什么/为什么会这样"，不直接给行动步骤。
|
||||
|
||||
---
|
||||
|
||||
## L4 四（术 / How）：原则、策略、决策规则
|
||||
|
||||
> 判别问题：**"在什么条件下，应当如何选择？"**
|
||||
|
||||
输出 5-12 条，每条：
|
||||
- **原则/启发式 P#**（规则句：如果...就...；优先...而非...）
|
||||
- **前提**：成立需要什么
|
||||
- **边界**：不适用/会反噬的情况
|
||||
- **映射**：来自 D# + M#（必须标注）
|
||||
- **证据引用**：E#...
|
||||
|
||||
注意：这一层给"决策规则"，不写工具模板细节。
|
||||
|
||||
---
|
||||
|
||||
## L5 八（器 / Do）：动作、工具、话术、流程
|
||||
|
||||
> 判别问题：**"我现在就能照着做吗？能否变成清单/步骤/模板？"**
|
||||
|
||||
输出 3-7 个"工具包 T#"，每个包含：
|
||||
- **触发场景**
|
||||
- **目标**
|
||||
- **步骤**（1-2-3...）
|
||||
- **话术/模板**（如适用）
|
||||
- **常见误用 -> 纠偏**
|
||||
- **映射**：来自 P#（必须标注）
|
||||
|
||||
---
|
||||
|
||||
## L6 加速度-速度-位移：指标与反馈
|
||||
|
||||
按"加速度/速度/位移"给指标，形成由高到低的观测链：
|
||||
|
||||
- **加速度指标 A**（驱动变化的变化）：2 个
|
||||
- 例：学习/沟通/决策质量的提升率、冲突升级率变化
|
||||
- **速度指标 V**（行为频率与强度）：2 个
|
||||
- 例：每周复盘次数、关键对话发起次数
|
||||
- **位移指标 S**（结果与状态）：2 个
|
||||
- 例：关系质量评分、项目结果、睡眠/情绪稳定度
|
||||
|
||||
每个指标必须写清：如何记录、周期、阈值、对应哪个工具包 T#。
|
||||
|
||||
---
|
||||
|
||||
## L7 生生不息：迭代律
|
||||
|
||||
输出：
|
||||
1. **复盘模板**（<=5 问）
|
||||
2. **更新规则**（条件句）：
|
||||
- 若出现__（信号/指标）-> 保留/增强/删除/改边界（指向 P# / T#）
|
||||
3. **7 天最小实验**：做什么、记录什么、如何判定有效
|
||||
|
||||
---
|
||||
|
||||
## 最终收束
|
||||
|
||||
用一句话输出总纲：**"在 X 情境，优先 Y 而非 Z"**，并标注它对应的 D#、M#、P#。
|
||||
1
.claude/skills/import-draft
Symbolic link
1
.claude/skills/import-draft
Symbolic link
@ -0,0 +1 @@
|
||||
/home/kang/apps/atomstorm-claude-skills/import-draft
|
||||
@ -1,183 +0,0 @@
|
||||
---
|
||||
name: import-draft
|
||||
description: "Import external drafts into content-forge vault for publishing workflow. Use when the user has an existing draft file from another project or external location and wants to bring it into the content-forge production pipeline. Trigger words: import draft, 迁移草稿, 入库, 导入文章, bring into vault, move to drafts."
|
||||
---
|
||||
|
||||
# Import Draft
|
||||
|
||||
Import external draft files into content-forge vault's `02-drafts/` directory, preparing them for the standard publishing workflow (format → assets → review → publish).
|
||||
|
||||
## When to Use
|
||||
|
||||
Use this skill when:
|
||||
- User has a draft written outside the vault (another project, external file, etc.)
|
||||
- User says "import this draft", "migrate this article", "bring into vault"
|
||||
- Draft needs to go through content-forge publishing pipeline
|
||||
- Draft may need modifications (image paths, frontmatter, etc.)
|
||||
|
||||
Do NOT use this skill when:
|
||||
- Draft already exists in `02-drafts/` → use edit commands instead
|
||||
- User wants to create new content from topic → use `write-article` skill instead
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Read External Draft
|
||||
|
||||
Read the external draft file using the Read tool.
|
||||
|
||||
```
|
||||
Read the file at <external_path>
|
||||
```
|
||||
|
||||
Execution requirements:
|
||||
- Read the complete file content
|
||||
- Note the file location and any embedded resources (images, etc.)
|
||||
|
||||
### Step 2: Quality Check
|
||||
|
||||
Analyze the draft and list issues that need fixing before import.
|
||||
|
||||
Check for:
|
||||
- **Image references**: Are paths correct? Do images exist?
|
||||
- **Frontmatter**: Does it exist? Is it complete?
|
||||
- **Structure**: Is the markdown well-formed?
|
||||
- **Content issues**: Dead links, missing sections, formatting problems
|
||||
|
||||
Output format:
|
||||
|
||||
```markdown
|
||||
## 草稿检查报告
|
||||
|
||||
### 文件信息
|
||||
- 路径: <original_path>
|
||||
- 行数: <N>
|
||||
- 大小: <X>KB
|
||||
|
||||
### 🔴 必须修改（入库前）
|
||||
| # | 问题 | 当前 | 建议 |
|
||||
|---|------|------|------|
|
||||
| 1 | ... | ... | ... |
|
||||
|
||||
### 🟡 建议修改（可选）
|
||||
| # | 问题 | 建议 |
|
||||
|---|------|------|
|
||||
| 1 | ... | ... |
|
||||
|
||||
### ✅ 无问题项
|
||||
- ...
|
||||
```
|
||||
|
||||
### Step 3: Wait for User Confirmation
|
||||
|
||||
**CRITICAL**: Do NOT proceed to write without user confirmation.
|
||||
|
||||
Ask the user:
|
||||
1. Which issues to fix
|
||||
2. Whether to fix now or import as-is
|
||||
3. Confirmation before any vault write
|
||||
|
||||
Output:
|
||||
```
|
||||
请确认：
|
||||
1. 需要修改哪些问题？
|
||||
2. 现在修改还是先入库再改？
|
||||
3. 确认后我将写入 vault
|
||||
```
|
||||
|
||||
### Step 4: Prepare Frontmatter
|
||||
|
||||
Generate standard frontmatter based on content-forge specification.
|
||||
|
||||
Required fields (see `references/frontmatter-spec.md`):
|
||||
- `id`, `title`, `slug`, `status`, `content_type`, `channels`
|
||||
- `language`, `source_urls`, `assets`, `cover_image`, `template`
|
||||
- `owner`, `created_at`, `updated_at`
|
||||
|
||||
Slug generation:
|
||||
- Extract from filename if possible
|
||||
- Or generate from title (lowercase, hyphens, no special chars)
|
||||
- Format: `YYYY-MM-DD-<slug>.md`
|
||||
|
||||
### Step 5: Write to Vault
|
||||
|
||||
Write the draft to `02-drafts/` directory.
|
||||
|
||||
```bash
|
||||
# First cd to vault directory
|
||||
cd /home/kang/apps/content-forge/content-forge
|
||||
|
||||
# Create the draft file
|
||||
obsidian create path="02-drafts/<YYYY-MM-DD>-<slug>.md" content="<DRAFT_WITH_FRONTMATTER>"
|
||||
```
|
||||
|
||||
Execution requirements:
|
||||
- Must cd to vault directory first (obsidian CLI bug workaround)
|
||||
- File must go to `02-drafts/` directory
|
||||
- Filename must have date prefix
|
||||
|
||||
### Step 6: Set Frontmatter Properties
|
||||
|
||||
Set each frontmatter field using obsidian property:set.
|
||||
|
||||
```bash
|
||||
# Required fields
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="id" value="<YYYY-MM-DD>-<slug>"
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="title" value="<title>"
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="slug" value="<slug>"
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="status" value="draft"
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="content_type" value="article"
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="channels" value='["wechat","x"]' type=list
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="language" value="zh-CN"
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="source_urls" value='[]' type=list
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="assets" value='[]' type=list
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="cover_image" value=""
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="template" value="article"
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="owner" value="content-forge"
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="created_at" value="<YYYY-MM-DD>T00:00:00+08:00"
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="updated_at" value="<YYYY-MM-DD>T00:00:00+08:00"
|
||||
```
|
||||
|
||||
### Step 7: Migrate Assets (Optional)
|
||||
|
||||
If the draft has images, offer to migrate them to `05-assets/<slug>/`.
|
||||
|
||||
```bash
|
||||
# Create assets directory
|
||||
mkdir -p /home/kang/apps/content-forge/content-forge/05-assets/<slug>/
|
||||
|
||||
# Copy images
|
||||
cp <external_image_paths> /home/kang/apps/content-forge/content-forge/05-assets/<slug>/
|
||||
|
||||
# Update draft's assets field
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="assets" value='["05-assets/<slug>/cover.png"]' type=list
|
||||
```
|
||||
|
||||
## Output Constraints
|
||||
|
||||
- Always wait for user confirmation before writing to vault
|
||||
- List all issues before asking for confirmation
|
||||
- Generate complete frontmatter, don't skip required fields
|
||||
- Report success/failure clearly after write
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
Before marking complete, verify:
|
||||
- [ ] External draft fully read
|
||||
- [ ] Quality issues listed and categorized
|
||||
- [ ] User confirmed which issues to fix
|
||||
- [ ] Frontmatter generated per spec
|
||||
- [ ] Draft written to `02-drafts/`
|
||||
- [ ] All frontmatter fields set correctly
|
||||
- [ ] Assets migrated (if applicable)
|
||||
- [ ] Final verification: `obsidian read path="02-drafts/<file>"` succeeds
|
||||
|
||||
## Failure Handling
|
||||
|
||||
- File not found: Return `[✗] 文件不存在: <path>`
|
||||
- Vault not accessible: Return `[✗] Vault 不可用，请运行 obsidian vault 检查`
|
||||
- Write failed: Return `[✗] 写入失败: <error>` and do not proceed
|
||||
- User denies confirmation: Stop and wait for further instructions
|
||||
|
||||
## References
|
||||
|
||||
- `references/frontmatter-spec.md` — Complete frontmatter specification
|
||||
@ -1,125 +0,0 @@
|
||||
# Frontmatter Specification
|
||||
|
||||
## Required Fields
|
||||
|
||||
All drafts in `01-topics/`, `02-drafts/`, `03-review/`, `04-published/` must contain these fields:
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: "YYYY-MM-DD-slug" # Unique identifier, matches filename
|
||||
title: "文章标题" # Display title
|
||||
slug: "article-slug" # URL-friendly identifier
|
||||
status: "draft" # inbox | topic | draft | formatting | review | polish | publishing | published | revision | blocked | archived
|
||||
content_type: "article" # article | thread | x-post | wechat-post | infographic
|
||||
channels: ["wechat", "x"] # Target publish channels
|
||||
language: "zh-CN" # Language code
|
||||
source_urls: [] # Original source URLs if any
|
||||
assets: [] # Vault-relative paths to images/files
|
||||
cover_image: "" # Path to cover image
|
||||
template: "article" # Template used
|
||||
owner: "content-forge" # Content owner
|
||||
created_at: "YYYY-MM-DDT00:00:00+08:00" # ISO 8601 timestamp
|
||||
updated_at: "YYYY-MM-DDT00:00:00+08:00" # ISO 8601 timestamp
|
||||
published_at: null # Set when published
|
||||
---
|
||||
```
|
||||
|
||||
## Optional Fields
|
||||
|
||||
```yaml
|
||||
# Cycle tracking
|
||||
cycle_days: null # Days from creation to publish
|
||||
stage_days: # Days spent in each stage
|
||||
inbox: 0
|
||||
topic: 0
|
||||
draft: 0
|
||||
review: 0
|
||||
total: 0
|
||||
|
||||
# Promotion fields (for /promote command)
|
||||
promotion_status: null # null | planned | promoting | converted | paused
|
||||
promotion_channels: [] # ["newsletter", "webinar", "x-thread", "linkedin"]
|
||||
holding_patterns: [] # ["email-list", "youtube", "podcast"]
|
||||
conversion_type: null # null | "lead-magnet" | "webinar" | "product-sale"
|
||||
repurposed_from: null # slug of original content
|
||||
repurposed_to: [] # slugs of derivative content
|
||||
evergreen: false # Can be re-promoted?
|
||||
|
||||
# Write-article skill extensions
|
||||
style: "tech_blog" # tech_blog | opinion | tutorial | social_short
|
||||
audience: "developers" # Target audience
|
||||
tags: [] # Content tags
|
||||
source_notes: [] # Obsidian note paths used as source
|
||||
|
||||
# Review & Polish (managed by /review command)
|
||||
review_status: null # null | pending | in_progress | passed | failed
|
||||
review_issues: [] # [{id, category, severity, description, status}]
|
||||
# category: structure | factual | style | format
|
||||
# severity: critical | high | medium | low
|
||||
review_passed_at: null # ISO 8601 timestamp when review passed
|
||||
polish_status: null # null | pending | skipped | done
|
||||
polish_version: 0 # Incremented on each polish iteration
|
||||
polished_at: null # ISO 8601 timestamp when polish completed
|
||||
revision_count: 0 # Number of revision cycles (max 3)
|
||||
revision_history: [] # [{date, issues_fixed: [], notes}]
|
||||
```
|
||||
|
||||
## Status Workflow
|
||||
|
||||
```
|
||||
inbox → topic → draft → formatting → review → polish → publishing → published
|
||||
↓ ↓ ↓
|
||||
revision ←───────── blocked
|
||||
↓
|
||||
archived
|
||||
```
|
||||
|
||||
### Review → Polish Flow
|
||||
|
||||
```
|
||||
┌─────────────┐
|
||||
│ review │
|
||||
└──────┬──────┘
|
||||
│
|
||||
┌────────────┼────────────┐
|
||||
▼ ▼ ▼
|
||||
┌──────────┐ ┌──────────┐ ┌──────────┐
|
||||
│ passed │ │ failed │ │ revision │
|
||||
└────┬─────┘ └────┬─────┘ └────┬─────┘
|
||||
│ │ │
|
||||
▼ ▼ │
|
||||
┌──────────┐ ┌──────────┐ │
|
||||
│ polish │ │ blocked │◄┘
|
||||
└────┬─────┘ └──────────┘
|
||||
│ ▲
|
||||
▼ │ (revision_count > 3)
|
||||
┌──────────┐ │
|
||||
│publishing│───────────┘
|
||||
└──────────┘
|
||||
```
|
||||
|
||||
### Revision Rules
|
||||
|
||||
- **Trigger**: Critical ≥ 1 OR High > 1
|
||||
- **Limit**: revision_count ≤ 3 per article
|
||||
- **Overflow**: auto → blocked for human decision
|
||||
|
||||
## Field Constraints
|
||||
|
||||
- `id` and `slug` must be unique across all stages
|
||||
- `status` can only progress forward (with exceptions for revision/blocked)
|
||||
- `assets` must use vault-relative paths (e.g., `05-assets/slug/image.png`)
|
||||
- `channels` determines which publish skills to use
|
||||
- `created_at` never changes after initial creation
|
||||
- `updated_at` changes on every modification
|
||||
|
||||
## Naming Convention
|
||||
|
||||
Files: `YYYY-MM-DD-<slug>.md`
|
||||
- Date: creation or import date
|
||||
- Slug: lowercase, hyphens only, no special chars
|
||||
- Example: `2026-03-03-claude-code-auto-memory-deep-dive.md`
|
||||
|
||||
Assets: `05-assets/<slug>/filename.ext`
|
||||
- Assets live in a directory named after the slug
|
||||
- Example: `05-assets/claude-code-auto-memory/cover.png`
|
||||
1
.claude/skills/multi-review
Symbolic link
1
.claude/skills/multi-review
Symbolic link
@ -0,0 +1 @@
|
||||
/home/kang/apps/atomstorm-claude-skills/multi-review
|
||||
@ -1,218 +0,0 @@
|
||||
---
|
||||
name: multi-review
|
||||
description: >
|
||||
Use MCO (Multi-CLI Orchestrator) to run parallel content review across multiple AI agents.
|
||||
Output: structured findings report with severity, consensus/divergence, and actionable fixes.
|
||||
|
||||
USE WHEN: User wants to review/critique an existing draft or topic for quality,
|
||||
accuracy, or readability using multiple AI perspectives.
|
||||
Trigger phrases: 审查、review、critique、多角度审查、cross-check、质量检查。
|
||||
|
||||
DON'T USE WHEN:
|
||||
- User wants to CREATE new content from a topic → use write-article instead.
|
||||
- User wants to deeply ANALYZE content structure (dao framework) → use dao-analysis instead.
|
||||
- User wants to IMPORT an external file → use import-draft instead.
|
||||
- User wants to see vault status → use my-world instead.
|
||||
- User says "写文章"、"生成草稿"、"分析为什么火" → not this skill.
|
||||
---
|
||||
|
||||
# multi-review — Multi-Agent Content Review
|
||||
|
||||
Use MCO (Multi-CLI Orchestrator) to run parallel content review across multiple AI agents, combining perspectives for comprehensive feedback.
|
||||
|
||||
## 路由规则（Use when / Don't use when）
|
||||
|
||||
Use this skill when:
|
||||
- Reviewing drafts before publication (`03-review/` stage)
|
||||
- Evaluating topic quality and angles (`01-topics/` stage)
|
||||
- Cross-checking technical accuracy in tech blogs
|
||||
- Getting diverse feedback on content structure
|
||||
- 用户说"审查我的草稿"、"review this"、"帮我检查质量"
|
||||
|
||||
Do NOT use this skill when:
|
||||
- 用户想**写新文章**（从选题到草稿） → use `write-article`
|
||||
- 用户想**深度分析**内容（道法术器框架） → use `dao-analysis`
|
||||
- 用户想**导入**外部文件到 vault → use `import-draft`
|
||||
- 用户想**加载 vault 上下文** → use `my-world`
|
||||
|
||||
Edge cases:
|
||||
- "审查我的草稿" → **this skill**（审查 = multi-review）
|
||||
- "分析这篇文章为什么火" → **not this skill**（深度分析 = dao-analysis）
|
||||
- "帮我把草稿改好" → **this skill**（改好需要先审查发现问题）
|
||||
- "写一篇新文章" → **not this skill**（创作 = write-article）
|
||||
|
||||
## Prerequisites
|
||||
|
||||
```bash
|
||||
mco doctor
|
||||
# Should show at least 2 providers READY
|
||||
```
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Identify Target Content
|
||||
|
||||
```bash
|
||||
cd /home/kang/apps/content-forge/content-forge
|
||||
obsidian files folder="02-drafts"
|
||||
obsidian files folder="03-review"
|
||||
```
|
||||
|
||||
### Step 2: Read Content to Review
|
||||
|
||||
```bash
|
||||
obsidian read path="<file-path>"
|
||||
```
|
||||
|
||||
### Step 3: Run Multi-Agent Review
|
||||
|
||||
Use MCO to get feedback from multiple agents:
|
||||
|
||||
```bash
|
||||
mco review --repo /home/kang/apps/content-forge \
|
||||
--prompt "Review the content in <file-path> for:
|
||||
1. Clarity and readability
|
||||
2. Technical accuracy
|
||||
3. Structure and flow
|
||||
4. Missing information or gaps
|
||||
5. Suggestions for improvement
|
||||
|
||||
Provide specific, actionable feedback." \
|
||||
--providers claude,codex \
|
||||
--target-paths content-forge/<file-path> \
|
||||
--synthesize \
|
||||
--format report
|
||||
```
|
||||
|
||||
### Step 4: Synthesize Results
|
||||
|
||||
When `--synthesize` is enabled, MCO will:
|
||||
1. Collect findings from all agents
|
||||
2. Deduplicate similar issues
|
||||
3. Track which agent found what (`detected_by`)
|
||||
4. Generate a consensus/divergence summary
|
||||
|
||||
### Step 5: Apply Feedback
|
||||
|
||||
Review the synthesized output and decide which suggestions to incorporate. Update the content manually (Golden Rule: Agents Read, Humans Write).
|
||||
|
||||
## Claude Provider Configuration
|
||||
|
||||
MCO-Plus supports custom configuration for the Claude provider via `--provider-permissions-json`:
|
||||
|
||||
### Switch cc Environment
|
||||
|
||||
Use a different cc-managed API endpoint:
|
||||
|
||||
```bash
|
||||
mco run --prompt "..." --providers claude \
|
||||
--provider-permissions-json '{"claude":{"cc_env":"bigmodel"}}'
|
||||
```
|
||||
|
||||
Available cc environments (check with `cc ls`):
|
||||
- `88` — 88code.org
|
||||
- `bigmodel` — 智谱 BigModel
|
||||
- `cclaude` — cclaude.codes
|
||||
- `relay` — relay.nf.video
|
||||
- `vibe` — vibe.codesuc.top
|
||||
|
||||
### Switch Model
|
||||
|
||||
Specify Claude model:
|
||||
|
||||
```bash
|
||||
mco run --prompt "..." --providers claude \
|
||||
--provider-permissions-json '{"claude":{"model":"opus"}}'
|
||||
```
|
||||
|
||||
Model options: `opus`, `sonnet`, `haiku`, or full model name (e.g., `claude-sonnet-4-6`)
|
||||
|
||||
### Combined Usage
|
||||
|
||||
```bash
|
||||
mco review --repo /home/kang/apps/content-forge \
|
||||
--prompt "Review this content" \
|
||||
--providers claude,codex \
|
||||
--provider-permissions-json '{"claude":{"cc_env":"bigmodel","model":"sonnet"}}' \
|
||||
--target-paths content-forge/02-drafts/<file>.md \
|
||||
--synthesize
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
MCO returns structured findings:
|
||||
|
||||
```
|
||||
=== Multi-Agent Review ===
|
||||
Task: Review <file-path>
|
||||
Providers: claude, codex
|
||||
|
||||
## Findings (deduplicated)
|
||||
|
||||
### Issue 1: [description]
|
||||
- Severity: High/Medium/Low
|
||||
- Detected by: claude, codex
|
||||
- Location: [specific section]
|
||||
- Suggestion: [actionable fix]
|
||||
|
||||
### Issue 2: [description]
|
||||
...
|
||||
|
||||
## Consensus
|
||||
- Points all agents agreed on
|
||||
|
||||
## Divergence
|
||||
- Points where agents disagreed
|
||||
|
||||
## Summary
|
||||
- Total issues: X
|
||||
- Critical: Y
|
||||
- Suggestions: Z
|
||||
```
|
||||
|
||||
## Integration with Content Pipeline
|
||||
|
||||
| Stage | MCO Use Case |
|
||||
|-------|--------------|
|
||||
| `01-topics` | Evaluate topic quality, identify gaps |
|
||||
| `02-drafts` | Pre-review feedback before human review |
|
||||
| `03-review` | Parallel expert review |
|
||||
| `04-published` | Post-mortem analysis for improvement |
|
||||
|
||||
## Example Prompts
|
||||
|
||||
### Draft Review
|
||||
```
|
||||
Review this draft for clarity, accuracy, and engagement.
|
||||
Focus on: technical correctness, logical flow, reader value.
|
||||
```
|
||||
|
||||
### Topic Evaluation
|
||||
```
|
||||
Evaluate this topic idea for:
|
||||
1. Reader interest potential
|
||||
2. Uniqueness vs existing content
|
||||
3. Suggested angles to explore
|
||||
```
|
||||
|
||||
### Technical Accuracy Check
|
||||
```
|
||||
Verify all technical claims in this content.
|
||||
Flag any inaccuracies or outdated information.
|
||||
Suggest corrections with sources.
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
Default providers: `claude,codex` (both ready on this system)
|
||||
|
||||
To add more providers:
|
||||
- `gemini` — requires Gemini CLI installed
|
||||
- `opencode` — requires OpenCode installed
|
||||
- `qwen` — requires Qwen Code installed
|
||||
|
||||
## Reference
|
||||
|
||||
- MCO-Plus Fork: https://github.com/CSZHK/mco-plus
|
||||
- Original MCO: https://github.com/mco-org/mco
|
||||
- cc Skill: `~/.claude/skills/cc/` (Claude Multi-Environment Manager)
|
||||
1
.claude/skills/my-world
Symbolic link
1
.claude/skills/my-world
Symbolic link
@ -0,0 +1 @@
|
||||
/home/kang/apps/atomstorm-claude-skills/my-world
|
||||
@ -1,132 +0,0 @@
|
||||
---
|
||||
name: my-world
|
||||
description: >
|
||||
One-shot context loader for the content-forge Obsidian vault. Loads projects,
|
||||
topics, drafts, knowledge graph, and current priorities into context.
|
||||
|
||||
USE WHEN: User wants to see what's in the vault, check pipeline status,
|
||||
or start a session with full context awareness. Trigger phrases: 加载上下文、
|
||||
vault 状态、我的世界、what's in my vault、load context、show pipeline。
|
||||
|
||||
DON'T USE WHEN:
|
||||
- User wants to CREATE new content → use write-article instead.
|
||||
- User wants to ANALYZE existing content deeply → use dao-analysis instead.
|
||||
- User wants to REVIEW a draft → use multi-review instead.
|
||||
- User wants to IMPORT an external file → use import-draft instead.
|
||||
- User says "写文章"、"分析"、"审查" → not this skill (read-only context loading only).
|
||||
---
|
||||
|
||||
# /my-world — Load My World
|
||||
|
||||
Load the entire content-forge vault context into the current session in one shot.
|
||||
|
||||
## 路由规则（Use when / Don't use when）
|
||||
|
||||
Use this skill when:
|
||||
- Session 开始时需要加载 vault 全量上下文
|
||||
- 需要查看当前 pipeline 状态（哪些选题/草稿/审核中）
|
||||
- 需要了解知识图谱状态（orphans, dead ends, unresolved links）
|
||||
- 用户说"加载上下文"、"vault 状态"、"我有什么在做"
|
||||
|
||||
Do NOT use this skill when:
|
||||
- 用户想**写新文章** → use `write-article`
|
||||
- 用户想**分析/拆解**内容 → use `dao-analysis`
|
||||
- 用户想**审查**草稿质量 → use `multi-review`
|
||||
- 用户想**导入**外部文件 → use `import-draft`
|
||||
|
||||
Edge cases:
|
||||
- "帮我看看 vault 里有什么" → **this skill**（查看 = context loading）
|
||||
- "写一篇关于 XX 的文章" → **not this skill**（创作 = write-article）
|
||||
- "分析一下我的草稿" → **not this skill**（分析 = dao-analysis 或 multi-review）
|
||||
|
||||
## What It Does
|
||||
|
||||
1. Read vault stats (file count, tags, recent activity)
|
||||
2. Scan all active content (topics, drafts, in-review)
|
||||
3. Map the knowledge graph (backlinks, wikilinks, orphans)
|
||||
4. Surface current priorities and blockers
|
||||
5. Present a concise world-view summary
|
||||
|
||||
## Important: Vault Directory
|
||||
|
||||
All `obsidian` CLI commands must run from within the vault directory to auto-detect the vault:
|
||||
|
||||
```bash
|
||||
cd /home/kang/apps/content-forge/content-forge
|
||||
```
|
||||
|
||||
Run all subsequent commands after this `cd`. The `vault=` parameter is unreliable; directory-based detection is the correct approach.
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1: Vault Health
|
||||
|
||||
```bash
|
||||
cd /home/kang/apps/content-forge/content-forge
|
||||
obsidian vault
|
||||
obsidian files total
|
||||
obsidian tags counts sort=count
|
||||
```
|
||||
|
||||
### Step 2: Active Content Pipeline
|
||||
|
||||
Scan each pipeline stage for active items:
|
||||
|
||||
```bash
|
||||
obsidian files folder="00-inbox"
|
||||
obsidian files folder="01-topics"
|
||||
obsidian files folder="02-drafts"
|
||||
obsidian files folder="03-review"
|
||||
obsidian files folder="04-published"
|
||||
```
|
||||
|
||||
For each file found, read its frontmatter to extract `title`, `status`, `content_type`, `channels`:
|
||||
|
||||
```bash
|
||||
obsidian properties path="<file-path>"
|
||||
```
|
||||
|
||||
### Step 3: Knowledge Graph
|
||||
|
||||
```bash
|
||||
obsidian orphans
|
||||
obsidian deadends
|
||||
obsidian unresolved
|
||||
```
|
||||
|
||||
### Step 4: Recent Activity
|
||||
|
||||
```bash
|
||||
obsidian recents
|
||||
```
|
||||
|
||||
### Step 5: Summarize
|
||||
|
||||
Present a concise summary in this format:
|
||||
|
||||
```
|
||||
=== My World ===
|
||||
|
||||
Vault: content-forge (X files, Y tags)
|
||||
|
||||
Pipeline:
|
||||
inbox: N items
|
||||
topics: N items (list titles)
|
||||
drafts: N items (list titles + status)
|
||||
review: N items (list titles)
|
||||
published: N items total
|
||||
|
||||
Knowledge Graph:
|
||||
Orphans: N (notes with no incoming links)
|
||||
Dead ends: N (notes with no outgoing links)
|
||||
Unresolved: N (broken [[wikilinks]])
|
||||
|
||||
Recent: (last 5 files touched)
|
||||
|
||||
Priorities:
|
||||
- (inferred from draft/review status and recency)
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
A structured world-view that gives full context for the session. No files are written — this is read-only.
|
||||
1
.claude/skills/paper-illustration
Symbolic link
1
.claude/skills/paper-illustration
Symbolic link
@ -0,0 +1 @@
|
||||
/home/kang/apps/atomstorm-claude-skills/paper-illustration
|
||||
@ -1,128 +0,0 @@
|
||||
# paper-illustration Skill Architecture
|
||||
|
||||
## File Budget
|
||||
|
||||
```
|
||||
.claude/skills/paper-illustration/
|
||||
├── SKILL.md ~280 行 ~1,800 字 接口层（工作流 + 约束）
|
||||
├── ARCHITECTURE.md ~120 行 ~800 字 架构总览（本文件）
|
||||
└── references/
|
||||
├── illustration-taxonomy.md ~210 行 ~1,400 字 6 种图表类型分类 + prompt 模板
|
||||
├── academic-styles.md ~185 行 ~1,200 字 5 种会议风格规范
|
||||
└── critic-checklist.md ~130 行 ~800 字 5 维度 20 项质量检查
|
||||
─────────────────
|
||||
~925 行 ~6,000 字 总上下文消耗
|
||||
```
|
||||
|
||||
## Progressive Disclosure Architecture
|
||||
|
||||
```
|
||||
Agent 加载顺序（上下文消耗）
|
||||
─────────────────────────────────────────────────────────────
|
||||
|
||||
第 1 层：SKILL.md（必加载，~1,800 字）
|
||||
┌──────────────────────────────────────────────────────────┐
|
||||
│ frontmatter 触发匹配 + 路由规则 │
|
||||
│ 输入要求 2 必填 + 8 可选 │
|
||||
│ 决策树 figure_type 自动检测 │
|
||||
│ 路由表 figure_type → backend 映射 │
|
||||
│ 6 步工作流 摘要+指针，不含详细规则 │
|
||||
│ 8 条 NEVER 零容忍规则 │
|
||||
│ 失败处理 6 种失败模式 │
|
||||
└──────────────┬───────────────────────────────────────────┘
|
||||
│ 按需加载（只在对应 Step 触发时读取）
|
||||
▼
|
||||
第 2 层：references/（按需，~3,400 字）
|
||||
┌────────────────────────┐ ┌───────────────────┐ ┌──────────────────┐
|
||||
│ illustration-taxonomy │ │ academic-styles │ │ critic-checklist │
|
||||
│ │ │ │ │ │
|
||||
│ Step 1 → §1-§6 分类 │ │ Step 3 → 风格参数 │ │ Step 5 → 评估 │
|
||||
│ Step 1 → §7 自动检测 │ │ Step 4 → 色值/字号 │ │ │
|
||||
│ Step 4 → §8 prompt 模板│ │ │ │ │
|
||||
└────────────────────────┘ └───────────────────┘ └──────────────────┘
|
||||
│
|
||||
▼
|
||||
第 3 层：外部依赖（运行时）
|
||||
┌──────────────────────────────────────────────────────────┐
|
||||
│ basic-image-gen skill AI 图像生成 │
|
||||
│ matplotlib/seaborn 代码生成（用户本地 Python） │
|
||||
│ obsidian CLI vault 资产管理 │
|
||||
└──────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 6-Step Workflow x File Dependency Matrix
|
||||
|
||||
```
|
||||
Step 名称 SKILL.md taxonomy styles checklist basic-image-gen vault
|
||||
──── ──── ──────── ──────── ────── ───────── ────────────── ─────
|
||||
1 Retrieve & Classify ✓ 指令 ✓ §1-§7 ✓ obsidian read
|
||||
2 Plan Blueprint ✓ 模板
|
||||
3 Apply Style ✓ 约束 ✓ 全文
|
||||
4 Generate Figure ✓ 路由 ✓ §8 prompt ✓ 色值 ✓ conceptual
|
||||
5 Critic Evaluation ✓ 约束 ✓ 全文
|
||||
6 Archive to Vault ✓ 模板 ✓ obsidian property:set
|
||||
```
|
||||
|
||||
Step 4 是资源消耗峰值——同时需要 taxonomy（prompt 模板）+ styles（色值字号）+ basic-image-gen（外部 skill）。这是合理的：生成阶段是整个 skill 的核心价值所在。
|
||||
|
||||
## Content-Forge Pipeline Integration
|
||||
|
||||
```
|
||||
content-forge 生产线 paper-illustration 覆盖范围
|
||||
──────────────────────────────────────────────────────────────
|
||||
|
||||
S0 选题入库 ──▶ 01-topics/*.md
|
||||
│
|
||||
S2 草稿生成 ──▶ write-article
|
||||
│
|
||||
S4 格式清洗 ──▶ format-markdown
|
||||
│
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ S5 视觉资产 │
|
||||
│ │
|
||||
│ ┌─ paper-illustration ◀── NEW (学术图表) │
|
||||
│ │ Step 1: 读取源笔记 + 分类 figure_type │
|
||||
│ │ Step 2: Figure Blueprint │
|
||||
│ │ Step 3: 风格参数（NeurIPS/ICML/...） │
|
||||
│ │ Step 4: matplotlib 代码 / AI 图像 │
|
||||
│ │ Step 5: Critic 5 维度评估 │
|
||||
│ │ Step 6: 存入 05-assets/ │
|
||||
│ │ │
|
||||
│ ├─ baoyu-cover-image（社媒封面） │
|
||||
│ ├─ baoyu-article-illustrator（博客配图） │
|
||||
│ └─ baoyu-xhs-images（小红书配图） │
|
||||
└─────────────────────────────────────────────┘
|
||||
│
|
||||
S6 审核 ──▶ /review + /multi-review
|
||||
│
|
||||
S8 发布 ──▶ post-to-wechat / post-to-x
|
||||
```
|
||||
|
||||
paper-illustration 与 baoyu-* 系列平级，在 S5（视觉资产）阶段按内容类型路由：学术内容走 paper-illustration，社媒内容走 baoyu-*。
|
||||
|
||||
## Differentiation Matrix
|
||||
|
||||
```
|
||||
paper-illustration baoyu-article-illustrator baoyu-cover-image
|
||||
───────────────── ──────────────────────── ─────────────────
|
||||
目的 信息性学术图表 装饰性博客配图 社媒封面图
|
||||
输出 图片 + 可复现代码 仅图片 仅图片
|
||||
受众 学术审稿人 博客读者 社媒用户
|
||||
文字处理 标签/坐标轴/图例 极少装饰文字 标题文字
|
||||
可复现性 必须（代码输出） 无需 无需
|
||||
后端 matplotlib + AI AI only AI only
|
||||
质量检查 20 项 Critic 无结构化检查 无结构化检查
|
||||
迭代 ≤3 轮 无 无
|
||||
```
|
||||
|
||||
## Architecture Scorecard
|
||||
|
||||
| Dimension | Rating | Notes |
|
||||
|-----------|--------|-------|
|
||||
| Progressive Disclosure | PASS | SKILL.md 摘要+指针，3 个 reference 按需加载 |
|
||||
| Cross-File Consistency | PASS | 图表类型名在 SKILL.md 和 taxonomy.md 完全一致 |
|
||||
| Single Responsibility | PASS | taxonomy=分类, styles=风格, checklist=评估 |
|
||||
| Extensibility | PASS | 新增会议风格只需扩展 academic-styles.md |
|
||||
| Vault Integration | PASS | 读取 obsidian read, 归档 property:set + 05-assets/ |
|
||||
| Quality Assurance | PASS | 20 项 Critic checklist, 18/20 pass threshold, ≤3 rounds |
|
||||
| Context Efficiency | PASS | 总量 ~6,000 字，Step 4 峰值 ~3 源（合理，生成阶段固有复杂度） |
|
||||
@ -1,368 +0,0 @@
|
||||
---
|
||||
name: paper-illustration
|
||||
description: >
|
||||
Generate publication-quality academic paper illustrations from scientific
|
||||
content. 6 figure types: architecture diagrams, data plots, conceptual
|
||||
illustrations, process flows, comparison charts, result visualizations.
|
||||
Outputs AI-generated images (via basic-image-gen) or reproducible code
|
||||
(matplotlib/mermaid/TikZ). Academic style compliance (NeurIPS/ICML/ACL/IEEE).
|
||||
|
||||
USE WHEN: User wants to create academic figures, paper illustrations, or
|
||||
scientific diagrams from vault notes or raw content.
|
||||
Trigger phrases: 论文插图、学术配图、paper figure、scientific illustration、
|
||||
架构图、实验结果图、ablation figure、generate figures for paper、
|
||||
数据可视化、流程图、对比图、概念图。
|
||||
|
||||
DON'T USE WHEN:
|
||||
- User wants decorative blog illustrations → use baoyu-article-illustrator.
|
||||
- User wants social media cover images → use baoyu-cover-image.
|
||||
- User wants infographics for Xiaohongshu → use baoyu-xhs-images.
|
||||
- User wants general AI image generation → use basic-image-gen directly.
|
||||
- User says "封面"、"配图"、"社媒" without academic context → not this skill.
|
||||
---
|
||||
|
||||
# Paper-Illustration: Academic Figure Generation Skill
|
||||
|
||||
## Purpose
|
||||
|
||||
Generate publication-quality figures from scientific content with reproducible code output. Every data-driven figure must be reproducible from code; every conceptual figure must be visually precise.
|
||||
|
||||
Core principle: **Code-first, AI-image fallback** — data figures (plots, charts) always go through matplotlib/seaborn code generation (text accuracy guaranteed); conceptual figures go through `basic-image-gen` (AI excels at creative visuals).
|
||||
|
||||
## Routing Rules (Use when / Don't use when)
|
||||
|
||||
Use this skill when:
|
||||
- User wants **academic-quality** figures for papers, presentations, or technical reports
|
||||
- User says "论文插图"、"paper figure"、"实验结果图"、"ablation study plot"
|
||||
- Content involves data visualization, system architecture, or scientific processes
|
||||
- User needs **reproducible** figure code (matplotlib, mermaid, TikZ)
|
||||
|
||||
Do NOT use this skill when:
|
||||
- User wants **decorative** blog/social illustrations → `baoyu-article-illustrator`
|
||||
- User wants **cover images** for articles → `baoyu-cover-image`
|
||||
- User wants **infographics** for social media → `baoyu-xhs-images` or `baoyu-infographic`
|
||||
- User wants **general AI images** without academic context → `basic-image-gen`
|
||||
- Content has no scientific/technical structure to visualize
|
||||
|
||||
Edge cases:
|
||||
- "帮我画个系统架构图" with paper context → **this skill** (academic architecture diagram)
|
||||
- "帮我画个系统架构图" for blog post → **not this skill** (use baoyu-article-illustrator)
|
||||
- "生成实验对比图" → **this skill** (data-driven, needs reproducible code)
|
||||
- "做个信息图" → **not this skill** (use baoyu-infographic)
|
||||
|
||||
## Input Requirements
|
||||
|
||||
Required:
|
||||
- `source`: Vault note path OR raw text content describing the figure subject
|
||||
- `figure_type`: One of 6 types (auto-detected if omitted, see Decision Tree below)
|
||||
|
||||
Optional:
|
||||
- `venue`: Academic venue style — `neurips` (default) | `icml` | `acl` | `ieee` | `nature`
|
||||
- `output_format`: `code` (default for data types) | `image` (default for conceptual) | `both`
|
||||
- `slug`: Asset slug for vault storage (derived from source note if omitted)
|
||||
- `caption`: Figure caption (generated if omitted)
|
||||
- `data`: Inline data dict/CSV for data-driven figures
|
||||
- `colorblind_mode`: `true` | `false` (default: `true` — always colorblind-safe)
|
||||
- `subfigures`: Number of subfigures (for multi-panel layouts)
|
||||
- `dpi`: Output resolution (default: 300, minimum: 150)
|
||||
- `language`: Label language — `en` (default) | `zh-CN`
|
||||
|
||||
## Figure Type Decision Tree
|
||||
|
||||
```
|
||||
Source content analysis
|
||||
│
|
||||
├─ Contains numeric data / experimental results?
|
||||
│ ├─ Comparing methods/models? ─────────────── comparison-chart
|
||||
│ ├─ Showing trends / distributions? ────────── data-plot
|
||||
│ └─ Showing ablation / metrics table? ──────── result-visualization
|
||||
│
|
||||
├─ Describes a system / model architecture?
|
||||
│ └─ Has components + connections? ──────────── architecture-diagram
|
||||
│
|
||||
├─ Describes a sequential process / pipeline?
|
||||
│ └─ Has ordered steps + decisions? ─────────── process-flow
|
||||
│
|
||||
└─ Describes an abstract concept / metaphor?
|
||||
└─ Needs creative visual representation? ──── conceptual
|
||||
```
|
||||
|
||||
## Figure Type → Backend Routing
|
||||
|
||||
```
|
||||
figure_type Primary Backend Fallback
|
||||
───────────────────── ───────────────────── ────────────────
|
||||
architecture-diagram Mermaid → basic-image-gen TikZ
|
||||
data-plot matplotlib code —（code only）
|
||||
conceptual basic-image-gen SVG description
|
||||
process-flow Mermaid flowchart TikZ
|
||||
comparison-chart matplotlib code —（code only）
|
||||
result-visualization matplotlib/seaborn code —（code only）
|
||||
```
|
||||
|
||||
**Key constraint**: Data-driven types (data-plot, comparison-chart, result-visualization) NEVER use AI image generation. Text on axes, labels, and legends must be pixel-perfect — only code can guarantee this.
|
||||
|
||||
## Mandatory Workflow (6 Steps — No Skipping)
|
||||
|
||||
### Step 1: Retrieve & Classify
|
||||
|
||||
Read source content and classify figure type. Load `references/illustration-taxonomy.md` for classification guidance.
|
||||
|
||||
```bash
|
||||
# If source is a vault note path
|
||||
cd "${VAULT_PATH:-/home/kang/apps/content-forge/content-forge}"
|
||||
obsidian read path="<source_note_path>"
|
||||
```
|
||||
|
||||
Actions:
|
||||
- Read all source material (vault notes, inline data, referenced papers)
|
||||
- Auto-detect `figure_type` using the Decision Tree above (if not provided)
|
||||
- Extract key elements: entities, relationships, data points, labels
|
||||
- Confirm figure_type with user if ambiguous
|
||||
|
||||
Output:
|
||||
```
|
||||
## Figure Classification
|
||||
|
||||
- Source: [vault path or "inline content"]
|
||||
- Detected type: [figure_type]
|
||||
- Key elements: [list of entities/data points]
|
||||
- Confidence: [high/medium/low]
|
||||
- [?] Ambiguous — suggest [type_a] or [type_b], awaiting user choice (if low confidence)
|
||||
```
|
||||
|
||||
### Step 2: Plan the Figure (Blueprint)
|
||||
|
||||
Generate a structured Figure Blueprint describing the visual composition.
|
||||
|
||||
Blueprint format:
|
||||
```yaml
|
||||
figure_blueprint:
|
||||
type: <figure_type>
|
||||
title: "<descriptive title>"
|
||||
caption: "<self-contained caption describing content and key findings>"
|
||||
dimensions:
|
||||
width: <inches>
|
||||
height: <inches>
|
||||
aspect_ratio: "<W:H>"
|
||||
layout:
|
||||
grid: "<NxM>" # for subfigures
|
||||
elements:
|
||||
- id: "element_1"
|
||||
type: "<box|arrow|label|axis|legend|...>"
|
||||
content: "<text or data reference>"
|
||||
position: "<relative position description>"
|
||||
data_mapping: # for data-driven types only
|
||||
x_axis: "<variable name>"
|
||||
y_axis: "<variable name>"
|
||||
series: ["<method_1>", "<method_2>"]
|
||||
error_bars: true/false
|
||||
text_elements:
|
||||
labels: ["<label_1>", "<label_2>"]
|
||||
annotations: ["<annotation_1>"]
|
||||
```
|
||||
|
||||
Constraints:
|
||||
- Every text element must be explicitly listed (no implicit labels)
|
||||
- Data mappings must reference actual data from Step 1
|
||||
- Caption must be self-contained (understandable without reading the paper)
|
||||
|
||||
### Step 3: Apply Academic Style
|
||||
|
||||
Load `references/academic-styles.md` and apply venue-specific styling to the Blueprint.
|
||||
|
||||
Style augmentation adds:
|
||||
- Color palette (hex values, colorblind-safe)
|
||||
- Font family and sizes (axis labels, titles, legends)
|
||||
- Line widths and marker styles
|
||||
- Figure size constraints (single-column vs double-column)
|
||||
- Caption format (numbered, style-specific)
|
||||
|
||||
Output: Enhanced Blueprint with all visual parameters specified as concrete values (no "use default" — every parameter must be a number or hex code).
|
||||
|
||||
### Step 4: Generate Figure
|
||||
|
||||
Route to the appropriate backend based on figure_type.
|
||||
|
||||
#### 4a. Code-based generation (data-plot, comparison-chart, result-visualization)
|
||||
|
||||
Generate complete, runnable Python code:
|
||||
|
||||
```python
|
||||
import matplotlib.pyplot as plt
|
||||
import matplotlib
|
||||
import numpy as np
|
||||
# import seaborn as sns # if needed
|
||||
|
||||
# --- Style Configuration (from Step 3) ---
|
||||
matplotlib.rcParams.update({
|
||||
'font.family': '<font_family>',
|
||||
'font.size': <base_size>,
|
||||
'axes.labelsize': <label_size>,
|
||||
'axes.titlesize': <title_size>,
|
||||
'legend.fontsize': <legend_size>,
|
||||
'figure.dpi': <dpi>,
|
||||
})
|
||||
|
||||
# --- Data ---
|
||||
# <data from Step 1, hardcoded for reproducibility>
|
||||
|
||||
# --- Plot ---
|
||||
fig, ax = plt.subplots(figsize=(<width>, <height>))
|
||||
|
||||
# <plotting code>
|
||||
|
||||
# --- Labels & Legend ---
|
||||
ax.set_xlabel('<x_label>')
|
||||
ax.set_ylabel('<y_label>')
|
||||
ax.legend(loc='best', frameon=True)
|
||||
|
||||
# --- Output ---
|
||||
plt.tight_layout()
|
||||
plt.savefig('<slug>_fig.png', dpi=<dpi>, bbox_inches='tight')
|
||||
plt.savefig('<slug>_fig.pdf', bbox_inches='tight') # vector format
|
||||
plt.show()
|
||||
```
|
||||
|
||||
**Code output rules**:
|
||||
- Print code to terminal (NEVER write .py files to vault)
|
||||
- All data must be inline (no external file references)
|
||||
- Must include both raster (PNG) and vector (PDF) save commands
|
||||
- Must include `tight_layout()` and explicit DPI
|
||||
- Must include all imports at the top
|
||||
|
||||
#### 4b. Mermaid-based generation (architecture-diagram, process-flow)
|
||||
|
||||
Generate Mermaid code, then optionally render via `basic-image-gen` for high-quality output:
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Component A] --> B[Component B]
|
||||
B --> C{Decision}
|
||||
C -->|Yes| D[Output 1]
|
||||
C -->|No| E[Output 2]
|
||||
```
|
||||
|
||||
For AI-enhanced rendering:
|
||||
- Convert Mermaid to a detailed text description
|
||||
- Use `basic-image-gen` with academic-style prompt (from Step 3)
|
||||
- Prompt template: see `references/illustration-taxonomy.md`
|
||||
|
||||
#### 4c. AI image generation (conceptual)
|
||||
|
||||
Use `basic-image-gen` with a carefully engineered prompt:
|
||||
- Include all text elements from Blueprint (labels, annotations)
|
||||
- Specify exact colors from venue palette
|
||||
- Request "clean, minimalist, scientific illustration style"
|
||||
- Specify "white background, no decorative elements, no shadows, no 3D effects"
|
||||
|
||||
### Step 5: Critic Evaluation
|
||||
|
||||
Load `references/critic-checklist.md` and evaluate the generated figure.
|
||||
|
||||
5 dimensions, 20 items — every item scored PASS/FAIL:
|
||||
- **Clarity** (5 items): caption, labels, hierarchy, overlap, whitespace
|
||||
- **Accuracy** (4 items): data fidelity, encoding, axes, error bars
|
||||
- **Style** (5 items): palette, colorblind, grayscale, fonts, size
|
||||
- **Reproducibility** (3 items): code completeness, imports, output config
|
||||
- **Caption** (3 items): content description, key findings, subfigure refs
|
||||
|
||||
Evaluation output:
|
||||
```
|
||||
## Critic Evaluation — Round N/3
|
||||
|
||||
| Dimension | Score | Issues |
|
||||
|-----------------|-------|--------|
|
||||
| Clarity | 4/5 | [!] Legend overlaps data points |
|
||||
| Accuracy | 4/4 | — |
|
||||
| Style | 5/5 | — |
|
||||
| Reproducibility | 3/3 | — |
|
||||
| Caption | 2/3 | [!] Missing key finding in caption |
|
||||
|
||||
Overall: REVISE (16/20, threshold: 18/20)
|
||||
|
||||
Revision actions:
|
||||
1. Move legend to upper-left corner
|
||||
2. Add "Method A outperforms by 12%" to caption
|
||||
```
|
||||
|
||||
**Iteration rules**:
|
||||
- Threshold: 18/20 to PASS
|
||||
- Maximum 3 revision rounds
|
||||
- Each revision must address ALL flagged issues
|
||||
- If round 3 still fails: output with `[!] Quality warning` and list remaining issues
|
||||
|
||||
### Step 6: Archive to Vault
|
||||
|
||||
Store final assets and update vault metadata.
|
||||
|
||||
```bash
|
||||
cd "${VAULT_PATH:-/home/kang/apps/content-forge/content-forge}"
|
||||
|
||||
# Create asset directory (if source is vault note)
|
||||
# mkdir -p "05-assets/<slug>/"
|
||||
|
||||
# For code-based figures: user runs the code, saves output to 05-assets/<slug>/
|
||||
# For AI-generated figures: basic-image-gen saves to 05-assets/<slug>/
|
||||
|
||||
# Update source note's frontmatter (if vault note)
|
||||
obsidian property:set path="<source_note_path>" name="assets" \
|
||||
value='["05-assets/<slug>/<filename>.png"]'
|
||||
```
|
||||
|
||||
Output summary:
|
||||
```
|
||||
## Figure Generation Complete
|
||||
|
||||
[✓] Type: <figure_type>
|
||||
[✓] Backend: <matplotlib|mermaid|basic-image-gen>
|
||||
[✓] Critic: PASS (score/20) — round N
|
||||
[✓] Assets: 05-assets/<slug>/<filename>.{png,pdf}
|
||||
[✓] Code: <printed to terminal | N/A>
|
||||
|
||||
Caption:
|
||||
"Figure N. <caption text>"
|
||||
```
|
||||
|
||||
## NEVER Rules (8 Items — Zero Tolerance)
|
||||
|
||||
1. **NEVER** use AI image generation for data-driven figures (data-plot, comparison-chart, result-visualization). Text on axes, labels, and legends is unreliable in AI-generated images. Always use matplotlib/seaborn code.
|
||||
|
||||
2. **NEVER** use more than 7 distinct colors in a single figure. Beyond 7, use patterns (hatching, markers, line styles) to differentiate series. Color is a scarce resource.
|
||||
|
||||
3. **NEVER** rely solely on red-green distinction. Always include a secondary encoding (shape, pattern, label) for colorblind accessibility. Test with simulated deuteranopia.
|
||||
|
||||
4. **NEVER** output a figure without a caption. Every figure must have a self-contained caption that describes what is shown and highlights key findings.
|
||||
|
||||
5. **NEVER** generate matplotlib code without `plt.tight_layout()` and explicit DPI setting. Clipped labels and low-resolution output are publication-rejection-worthy bugs.
|
||||
|
||||
6. **NEVER** use decorative elements: drop shadows, 3D effects, gradients, bevels, or ornamental borders. Academic figures must be clean, flat, and information-dense.
|
||||
|
||||
7. **NEVER** skip the Critic evaluation step (Step 5). Even if the figure "looks fine", run the 20-item checklist. Visual intuition misses subtle issues.
|
||||
|
||||
8. **NEVER** write code files (.py, .mmd) to the vault. Code output goes to terminal. Only image assets (.png, .pdf, .svg) go to `05-assets/`. Vault is for content, not code.
|
||||
|
||||
## Output Constraints
|
||||
|
||||
- All code output is printed to terminal, not saved as files
|
||||
- Image assets go to `05-assets/<slug>/` with vault-relative paths
|
||||
- Default language for labels: English (override with `language: zh-CN`)
|
||||
- Default colorblind mode: ON (override with `colorblind_mode: false`)
|
||||
- Default DPI: 300 (minimum 150, recommended 300-600 for print)
|
||||
- Caption language matches `language` parameter
|
||||
- Vector format (PDF) always generated alongside raster (PNG) for code-based figures
|
||||
|
||||
## Failure Handling
|
||||
|
||||
- Missing source content: `[?] Missing input: source` — stop and ask
|
||||
- Ambiguous figure_type: `[?] Cannot determine figure type` — present options, ask user
|
||||
- `basic-image-gen` unavailable: `[✗] Image generation failed` — fall back to Mermaid/TikZ code
|
||||
- Data insufficient for plot: `[?] Insufficient data` — request specific data points
|
||||
- Critic fails after 3 rounds: `[!] Quality warning: <remaining_issues>` — output with disclaimer
|
||||
- `obsidian` CLI failure: `[✗] <command> failed: <error>` — stop subsequent steps
|
||||
|
||||
## Reference Files
|
||||
|
||||
- `references/illustration-taxonomy.md` — 6 figure types: structure, routing, prompt templates, decision tree
|
||||
- `references/academic-styles.md` — Venue-specific styles: NeurIPS/ICML/ACL/IEEE/Nature with hex colors, fonts, sizes
|
||||
- `references/critic-checklist.md` — 5 dimensions x 20 items: Clarity, Accuracy, Style, Reproducibility, Caption
|
||||
@ -1,21 +0,0 @@
|
||||
# paper-illustration Reference Files
|
||||
|
||||
This directory contains detailed documentation that supplements SKILL.md.
|
||||
|
||||
## Files
|
||||
|
||||
- `illustration-taxonomy.md` — 6 figure types: structure templates, routing rules, prompt engineering, auto-detection heuristics
|
||||
- `academic-styles.md` — Venue-specific visual parameters: NeurIPS/ICML/ACL/IEEE/Nature with hex colors, fonts, sizes
|
||||
- `critic-checklist.md` — 5 dimensions x 20 items quality evaluation: Clarity, Accuracy, Style, Reproducibility, Caption
|
||||
|
||||
## Loading Rules
|
||||
|
||||
1. **illustration-taxonomy.md**: Load at Step 1 (Retrieve & Classify) and Step 4 (Generate Figure)
|
||||
2. **academic-styles.md**: Load at Step 3 (Apply Style) and Step 4 (Generate Figure)
|
||||
3. **critic-checklist.md**: Load at Step 5 (Critic Evaluation)
|
||||
|
||||
## Guidelines
|
||||
|
||||
1. **Single Source**: Don't duplicate content from SKILL.md
|
||||
2. **Load on Demand**: Claude reads these files only at the relevant Step
|
||||
3. **Cross-References**: Each file notes which SKILL.md sections reference it
|
||||
@ -1,281 +0,0 @@
|
||||
# Academic Styles Reference
|
||||
|
||||
> Loaded by Step 3 (Apply Academic Style). Provides venue-specific visual parameters: colors, fonts, sizes, spacing, caption format. Every value is concrete — no "use default".
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Universal Rules](#1-universal-rules)
|
||||
2. [NeurIPS Style (Default)](#2-neurips-style-default)
|
||||
3. [ICML Style](#3-icml-style)
|
||||
4. [ACL Style](#4-acl-style)
|
||||
5. [IEEE Style](#5-ieee-style)
|
||||
6. [Nature Style](#6-nature-style)
|
||||
7. [Color Palettes Quick Reference](#7-color-palettes-quick-reference)
|
||||
8. [Font Sizes Quick Reference](#8-font-sizes-quick-reference)
|
||||
|
||||
---
|
||||
|
||||
## 1. Universal Rules
|
||||
|
||||
These apply to ALL venues. Venue-specific sections override where noted.
|
||||
|
||||
### Colorblind Safety
|
||||
|
||||
- Primary encoding: color + shape/pattern (never color alone)
|
||||
- Forbidden pairs: pure red (#FF0000) vs pure green (#00FF00)
|
||||
- Mandatory test: simulate deuteranopia — all series still distinguishable
|
||||
- Maximum distinct colors per figure: 7 (use hatching/markers beyond 7)
|
||||
|
||||
### Grayscale Compatibility
|
||||
|
||||
- Figure must remain interpretable when printed in grayscale
|
||||
- Use varying lightness values, not just hue differences
|
||||
- Add patterns (hatching, dots) to filled regions as backup encoding
|
||||
|
||||
### Typography
|
||||
|
||||
- Minimum font size: 8pt at final print size
|
||||
- Label font size: 9-10pt
|
||||
- Title font size: 10-12pt (if shown on figure)
|
||||
- Legend font size: 8-9pt
|
||||
- All text must survive 50% reduction without becoming illegible
|
||||
|
||||
### Resolution
|
||||
|
||||
- Raster output: minimum 300 DPI (600 DPI recommended for print)
|
||||
- Vector output: PDF preferred (no rasterization artifacts)
|
||||
- Always generate both PNG (300 DPI) and PDF
|
||||
|
||||
### Layout
|
||||
|
||||
- Margins: sufficient whitespace around all elements (no clipped text)
|
||||
- Always call `plt.tight_layout()` or equivalent
|
||||
- Grid lines: light gray (#CCCCCC), thin (0.5pt), behind data
|
||||
- Axis spines: visible top and right spines optional (NeurIPS removes them)
|
||||
|
||||
---
|
||||
|
||||
## 2. NeurIPS Style (Default)
|
||||
|
||||
**Page width**: 5.5" (single column), 11.0" (full width)
|
||||
**Figure width**: 5.5" (single), 2.6" (half)
|
||||
|
||||
### Color Palette (seaborn "muted" inspired, 7 colors)
|
||||
|
||||
| Index | Name | Hex | RGB | Use |
|
||||
|-------|---------|-----------|-----------------|-----|
|
||||
| 0 | Blue | `#4878D0` | (72, 120, 208) | Primary / "Ours" |
|
||||
| 1 | Orange | `#EE854A` | (238, 133, 74) | Secondary / Baseline |
|
||||
| 2 | Green | `#6ACC64` | (106, 204, 100) | Tertiary |
|
||||
| 3 | Red | `#D65F5F` | (214, 95, 95) | Alert / Worst |
|
||||
| 4 | Purple | `#956CB4` | (149, 108, 180) | Additional |
|
||||
| 5 | Brown | `#8C613C` | (140, 97, 60) | Additional |
|
||||
| 6 | Pink | `#DC7EC0` | (220, 126, 192) | Additional |
|
||||
|
||||
### Fonts
|
||||
|
||||
- Family: `serif` (Times New Roman or similar)
|
||||
- Body: 10pt, Labels: 9pt, Legend: 8pt, Title: 11pt
|
||||
- matplotlib: `'font.family': 'serif'`
|
||||
|
||||
### Axes
|
||||
|
||||
- Remove top and right spines: `ax.spines['top'].set_visible(False)`
|
||||
- Tick direction: `out`
|
||||
- Tick length: 4pt
|
||||
- Grid: `alpha=0.3, linestyle='--', linewidth=0.5`
|
||||
|
||||
### Caption Format
|
||||
|
||||
```
|
||||
Figure N: <Description>. <Key finding>.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. ICML Style
|
||||
|
||||
**Page width**: 6.75" (single column), 13.5" (full width)
|
||||
**Figure width**: 6.75" (single), 3.25" (half)
|
||||
|
||||
### Color Palette (cooler tones)
|
||||
|
||||
| Index | Name | Hex | Use |
|
||||
|-------|-----------|-----------|-----|
|
||||
| 0 | Dark Blue | `#1F77B4` | Primary / "Ours" |
|
||||
| 1 | Orange | `#FF7F0E` | Secondary |
|
||||
| 2 | Teal | `#2CA02C` | Tertiary |
|
||||
| 3 | Crimson | `#D62728` | Alert |
|
||||
| 4 | Violet | `#9467BD` | Additional |
|
||||
| 5 | Sienna | `#8C564B` | Additional |
|
||||
| 6 | Gray | `#7F7F7F` | Neutral/Baseline |
|
||||
|
||||
### Fonts
|
||||
|
||||
- Family: `serif` (Computer Modern / Times)
|
||||
- Body: 10pt, Labels: 9pt, Legend: 8pt
|
||||
- matplotlib: `'font.family': 'serif', 'mathtext.fontset': 'cm'`
|
||||
|
||||
### Caption Format
|
||||
|
||||
```
|
||||
Figure N. <Description>. <Key finding>.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. ACL Style
|
||||
|
||||
**Page width**: 6.0" (single column)
|
||||
**Figure width**: 6.0" (single), 2.9" (half)
|
||||
|
||||
### Color Palette (warm academic)
|
||||
|
||||
| Index | Name | Hex | Use |
|
||||
|-------|------------|-----------|-----|
|
||||
| 0 | Royal Blue | `#2166AC` | Primary |
|
||||
| 1 | Warm Red | `#B2182B` | Secondary |
|
||||
| 2 | Teal | `#35978F` | Tertiary |
|
||||
| 3 | Gold | `#DFC27D` | Highlight |
|
||||
| 4 | Purple | `#762A83` | Additional |
|
||||
| 5 | Dark Gray | `#525252` | Neutral |
|
||||
|
||||
### Fonts
|
||||
|
||||
- Family: `serif` (Times New Roman)
|
||||
- Body: 10pt, Labels: 9pt, Legend: 8pt
|
||||
- matplotlib: `'font.family': 'serif'`
|
||||
|
||||
### Special Notes
|
||||
|
||||
- NLP figures often include text examples — ensure text is readable
|
||||
- Attention heatmaps: use sequential colormap (`Blues` or `YlOrRd`)
|
||||
- Dependency trees: horizontal layout preferred
|
||||
|
||||
### Caption Format
|
||||
|
||||
```
|
||||
Figure N: <Description>.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. IEEE Style
|
||||
|
||||
**Page width**: 3.5" (single column), 7.16" (double column)
|
||||
**Figure width**: 3.5" (single), 7.16" (full)
|
||||
|
||||
### Color Palette (high contrast, traditional)
|
||||
|
||||
| Index | Name | Hex | Use |
|
||||
|-------|----------|-----------|-----|
|
||||
| 0 | Blue | `#0072B2` | Primary |
|
||||
| 1 | Orange | `#E69F00` | Secondary |
|
||||
| 2 | Green | `#009E73` | Tertiary |
|
||||
| 3 | Red | `#CC79A7` | Alert (pink-red, colorblind-safe) |
|
||||
| 4 | Sky Blue | `#56B4E9` | Additional |
|
||||
| 5 | Vermilion| `#D55E00` | Additional |
|
||||
| 6 | Black | `#000000` | Baseline/Reference |
|
||||
|
||||
**Note**: This is the Wong colorblind-safe palette, recommended for all IEEE publications.
|
||||
|
||||
### Fonts
|
||||
|
||||
- Family: `sans-serif` (Helvetica / Arial)
|
||||
- Body: 8pt, Labels: 8pt, Legend: 7pt, Title: 9pt
|
||||
- matplotlib: `'font.family': 'sans-serif'`
|
||||
|
||||
### Special Notes
|
||||
|
||||
- IEEE is stricter on figure size due to two-column format
|
||||
- Single-column figures: max 3.5" wide — everything must be readable at this size
|
||||
- Prefer subfigure grids over wide panoramic figures
|
||||
- Line width: minimum 1pt (thin lines disappear in print)
|
||||
|
||||
### Caption Format
|
||||
|
||||
```
|
||||
Fig. N. <Description>.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Nature Style
|
||||
|
||||
**Page width**: 3.5" (single column), 7.2" (double column)
|
||||
**Figure width**: 3.5" (single), 7.2" (full)
|
||||
|
||||
### Color Palette (Nature-inspired, elegant)
|
||||
|
||||
| Index | Name | Hex | Use |
|
||||
|-------|-----------|-----------|-----|
|
||||
| 0 | Nature Blue | `#3B4CC0` | Primary |
|
||||
| 1 | Nature Red | `#B40426` | Secondary |
|
||||
| 2 | Nature Green| `#1B7837` | Tertiary |
|
||||
| 3 | Gold | `#F2C14E` | Highlight |
|
||||
| 4 | Teal | `#008080` | Additional |
|
||||
| 5 | Dark Gray | `#404040` | Neutral |
|
||||
|
||||
### Fonts
|
||||
|
||||
- Family: `sans-serif` (Helvetica / Arial)
|
||||
- Body: 7pt, Labels: 7pt, Legend: 6pt, Title: 8pt
|
||||
- matplotlib: `'font.family': 'sans-serif', 'font.size': 7`
|
||||
|
||||
### Special Notes
|
||||
|
||||
- Nature has the strictest size limits — maximize information density
|
||||
- Prefer panel layouts (a, b, c, d) with lowercase bold letters
|
||||
- Panel labels: **a**, **b**, **c** at top-left of each subfigure
|
||||
- Color: used sparingly, key data only — backgrounds always white
|
||||
|
||||
### Caption Format
|
||||
|
||||
```
|
||||
Figure N | <Title in bold>. <Description>. a, <Panel a description>. b, <Panel b description>.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Color Palettes Quick Reference
|
||||
|
||||
### matplotlib Code Snippets
|
||||
|
||||
```python
|
||||
# NeurIPS (default)
|
||||
COLORS_NEURIPS = ['#4878D0', '#EE854A', '#6ACC64', '#D65F5F', '#956CB4', '#8C613C', '#DC7EC0']
|
||||
|
||||
# ICML
|
||||
COLORS_ICML = ['#1F77B4', '#FF7F0E', '#2CA02C', '#D62728', '#9467BD', '#8C564B', '#7F7F7F']
|
||||
|
||||
# ACL
|
||||
COLORS_ACL = ['#2166AC', '#B2182B', '#35978F', '#DFC27D', '#762A83', '#525252']
|
||||
|
||||
# IEEE (Wong colorblind-safe)
|
||||
COLORS_IEEE = ['#0072B2', '#E69F00', '#009E73', '#CC79A7', '#56B4E9', '#D55E00', '#000000']
|
||||
|
||||
# Nature
|
||||
COLORS_NATURE = ['#3B4CC0', '#B40426', '#1B7837', '#F2C14E', '#008080', '#404040']
|
||||
```
|
||||
|
||||
### Choosing "Ours" Color
|
||||
|
||||
Convention: the first color in each palette (index 0, a shade of blue) is used for "our method". This creates visual prominence and is consistent with reader expectations.
|
||||
|
||||
---
|
||||
|
||||
## 8. Font Sizes Quick Reference
|
||||
|
||||
| Venue | Body | Labels | Legend | Title | Min |
|
||||
|---------|------|--------|--------|-------|-----|
|
||||
| NeurIPS | 10pt | 9pt | 8pt | 11pt | 8pt |
|
||||
| ICML | 10pt | 9pt | 8pt | 10pt | 8pt |
|
||||
| ACL | 10pt | 9pt | 8pt | 10pt | 8pt |
|
||||
| IEEE | 8pt | 8pt | 7pt | 9pt | 7pt |
|
||||
| Nature | 7pt | 7pt | 6pt | 8pt | 6pt |
|
||||
|
||||
**Rule of thumb**: If in doubt, use larger font sizes. Reviewers complain about unreadable figures far more often than oversized text.
|
||||
|
||||
---
|
||||
|
||||
*Cross-reference: SKILL.md §Step 3, §NEVER Rules #2 #3 #6*
|
||||
@ -1,185 +0,0 @@
|
||||
# Critic Checklist Reference
|
||||
|
||||
> Loaded by Step 5 (Critic Evaluation). 5 dimensions, 20 items. Each scored PASS/FAIL. Threshold: 18/20 to pass. Maximum 3 revision rounds.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Scoring Rules](#scoring-rules)
|
||||
2. [Dimension 1: Clarity (5 items)](#dimension-1-clarity-5-items)
|
||||
3. [Dimension 2: Accuracy (4 items)](#dimension-2-accuracy-4-items)
|
||||
4. [Dimension 3: Style (5 items)](#dimension-3-style-5-items)
|
||||
5. [Dimension 4: Reproducibility (3 items)](#dimension-4-reproducibility-3-items)
|
||||
6. [Dimension 5: Caption (3 items)](#dimension-5-caption-3-items)
|
||||
7. [Evaluation Output Template](#evaluation-output-template)
|
||||
8. [Revision Protocol](#revision-protocol)
|
||||
|
||||
---
|
||||
|
||||
## Scoring Rules
|
||||
|
||||
- Each item: PASS (1 point) or FAIL (0 points)
|
||||
- Total: 20 points maximum
|
||||
- Pass threshold: 18/20 (90%)
|
||||
- Maximum revision rounds: 3
|
||||
- Each revision must address ALL flagged FAIL items
|
||||
- Items not applicable to the figure type: auto-PASS (e.g., error bars for conceptual figures)
|
||||
|
||||
---
|
||||
|
||||
## Dimension 1: Clarity (5 items)
|
||||
|
||||
| ID | Check | PASS Criteria | Common FAIL |
|
||||
|----|-------|---------------|-------------|
|
||||
| C1 | Caption self-explanatory | Reader understands figure without reading paper body | Caption says only "Results" with no detail |
|
||||
| C2 | Labels readable | All text >= minimum font size at print dimensions | 6pt text on IEEE single-column figure |
|
||||
| C3 | Visual hierarchy | Most important data visually prominent (size, color, position) | All lines same weight, "Ours" indistinguishable |
|
||||
| C4 | No overlapping elements | Labels, legends, data points, annotations do not occlude each other | Legend sits on top of data region |
|
||||
| C5 | Adequate whitespace | Margins around figure, between subfigures, around legends | Elements crammed to edges, no breathing room |
|
||||
|
||||
### How to Fix Common FAIL
|
||||
|
||||
- **C1**: Add "showing that [method] achieves [X]% improvement over [baseline]" to caption
|
||||
- **C2**: Increase font size or reduce figure complexity (fewer elements)
|
||||
- **C3**: Use thicker lines / brighter colors for "Ours", thinner / muted for baselines
|
||||
- **C4**: Relocate legend (outside plot area, or to whitespace region)
|
||||
- **C5**: Add `plt.tight_layout(pad=1.5)` or increase figure dimensions
|
||||
|
||||
---
|
||||
|
||||
## Dimension 2: Accuracy (4 items)
|
||||
|
||||
| ID | Check | PASS Criteria | Common FAIL |
|
||||
|----|-------|---------------|-------------|
|
||||
| A1 | Data fidelity | Plotted values exactly match source data (spot-check 3 points) | Transposed rows/columns, wrong method assigned to line |
|
||||
| A2 | Encoding faithful | Visual encoding matches data semantics (e.g., larger bar = larger value) | Inverted y-axis without indicator, log scale unlabeled |
|
||||
| A3 | Axes honest | No truncated axes without break markers; scale is fair | Y-axis starts at 90% making 1% difference look huge |
|
||||
| A4 | Error bars correct | Error bars represent stated metric (std, sem, CI) and are labeled | Error bars present but unlabeled, or wrong metric |
|
||||
|
||||
### How to Fix Common FAIL
|
||||
|
||||
- **A1**: Cross-reference code data arrays with source table, print values to verify
|
||||
- **A2**: Check axis direction, scale type (linear/log), and legend-to-data mapping
|
||||
- **A3**: Start y-axis at 0, or use axis break (`//`) marker if truncated
|
||||
- **A4**: Add "(mean +/- std, n=5)" to caption or legend
|
||||
|
||||
---
|
||||
|
||||
## Dimension 3: Style (5 items)
|
||||
|
||||
| ID | Check | PASS Criteria | Common FAIL |
|
||||
|----|-------|---------------|-------------|
|
||||
| S1 | Palette matches venue | Colors from venue-specific palette in academic-styles.md | Using matplotlib default colors instead of venue palette |
|
||||
| S2 | Colorblind safe | All series distinguishable under simulated deuteranopia | Red and green lines only differ by hue |
|
||||
| S3 | Grayscale compatible | Figure readable when desaturated (for B&W printing) | Two series both map to medium gray |
|
||||
| S4 | Font compliant | Font family and sizes match venue specification | Sans-serif used for NeurIPS (should be serif) |
|
||||
| S5 | Size compliant | Figure fits within venue column width at stated dimensions | 8" wide figure for IEEE single-column (max 3.5") |
|
||||
|
||||
### How to Fix Common FAIL
|
||||
|
||||
- **S1**: Replace colors with hex values from `references/academic-styles.md`
|
||||
- **S2**: Add secondary encoding (markers: o, s, ^, D, v) alongside color
|
||||
- **S3**: Add line styles (solid, dashed, dotted, dash-dot) as tertiary encoding
|
||||
- **S4**: Update `matplotlib.rcParams['font.family']`
|
||||
- **S5**: Adjust `figsize` to venue constraints
|
||||
|
||||
---
|
||||
|
||||
## Dimension 4: Reproducibility (3 items)
|
||||
|
||||
| ID | Check | PASS Criteria | Common FAIL |
|
||||
|----|-------|---------------|-------------|
|
||||
| R1 | Code complete | Code runs without modification (all data inline, no external files) | References `data.csv` that doesn't exist |
|
||||
| R2 | Imports present | All required imports listed at top of code | Missing `import seaborn as sns` |
|
||||
| R3 | Output configured | Explicit DPI, savefig with bbox_inches='tight', both PNG and PDF | No savefig, or missing DPI, or only PNG |
|
||||
|
||||
**Scope**: Only applies to code-based figures (data-plot, comparison-chart, result-visualization). Auto-PASS for AI-generated figures.
|
||||
|
||||
### How to Fix Common FAIL
|
||||
|
||||
- **R1**: Replace file reads with inline data arrays (`np.array([...])`)
|
||||
- **R2**: Run code mentally — every function call must have its import
|
||||
- **R3**: Add `plt.savefig('fig.png', dpi=300, bbox_inches='tight')` + PDF variant
|
||||
|
||||
---
|
||||
|
||||
## Dimension 5: Caption (3 items)
|
||||
|
||||
| ID | Check | PASS Criteria | Common FAIL |
|
||||
|----|-------|---------------|-------------|
|
||||
| P1 | Content described | Caption describes WHAT the figure shows (not just "Results") | "Figure 1: Comparison." — no detail |
|
||||
| P2 | Key finding stated | Caption highlights the main takeaway for the reader | Describes setup but not conclusion |
|
||||
| P3 | Subfigures referenced | Multi-panel figures: each panel described in caption (a, b, c) | 4 panels but caption only mentions "left" and "right" |
|
||||
|
||||
### How to Fix Common FAIL
|
||||
|
||||
- **P1**: Structure as "Figure N: [verb] [what]. [context]." e.g., "Figure 3: Comparison of training convergence across 5 methods on CIFAR-10."
|
||||
- **P2**: Add final sentence: "Method A converges 2x faster than the strongest baseline."
|
||||
- **P3**: Add "(a) Training loss. (b) Validation accuracy. (c) Inference latency."
|
||||
|
||||
---
|
||||
|
||||
## Evaluation Output Template
|
||||
|
||||
```
|
||||
## Critic Evaluation — Round N/3
|
||||
|
||||
| Dim. | Items | Score | Failed IDs | Issues |
|
||||
|-----------------|-------|-------|------------|--------|
|
||||
| Clarity | 5 | X/5 | [CX] | [description] |
|
||||
| Accuracy | 4 | X/4 | [AX] | [description] |
|
||||
| Style | 5 | X/5 | [SX] | [description] |
|
||||
| Reproducibility | 3 | X/3 | [RX] | [description] |
|
||||
| Caption | 3 | X/3 | [PX] | [description] |
|
||||
|-----------------|-------|-------|------------|--------|
|
||||
| **Total** | **20**| **X/20** | | |
|
||||
|
||||
Verdict: PASS (>= 18) / REVISE (< 18)
|
||||
|
||||
[If REVISE:]
|
||||
Revision actions:
|
||||
1. [Fix for failed item 1]
|
||||
2. [Fix for failed item 2]
|
||||
...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Revision Protocol
|
||||
|
||||
### Round Management
|
||||
|
||||
```
|
||||
Round 1: Initial evaluation
|
||||
↓ REVISE → apply fixes
|
||||
Round 2: Re-evaluate ALL items (not just failed ones)
|
||||
↓ REVISE → apply fixes
|
||||
Round 3: Final evaluation
|
||||
↓ REVISE → output with [!] Quality warning
|
||||
↓ PASS → proceed to Step 6
|
||||
```
|
||||
|
||||
### Rules
|
||||
|
||||
1. Each round evaluates ALL 20 items fresh (fixes can introduce new issues)
|
||||
2. Revision must address every FAIL item — no "defer to next round"
|
||||
3. After round 3, if still < 18/20:
|
||||
- Output the figure with explicit warning
|
||||
- List all remaining FAIL items
|
||||
- Suggest user manual review
|
||||
4. A PASS in any round immediately proceeds to Step 6 (no unnecessary iterations)
|
||||
|
||||
### Quality Warning Format
|
||||
|
||||
```
|
||||
[!] Quality warning: Figure output with 2 unresolved issues after 3 revision rounds.
|
||||
|
||||
Remaining issues:
|
||||
- [S2] Colorblind safety: series 3 and 5 may be confusing under deuteranopia
|
||||
- [C4] Minor legend overlap with rightmost data point
|
||||
|
||||
Recommendation: Manual review before submission.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*Cross-reference: SKILL.md §Step 5, §NEVER Rule #7*
|
||||
@ -1,291 +0,0 @@
|
||||
# Illustration Taxonomy Reference
|
||||
|
||||
> Loaded by Step 1 (Retrieve & Classify). Provides structure templates, routing rules, prompt engineering guidance, and auto-detection heuristics for all 6 figure types.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Architecture Diagram](#1-architecture-diagram)
|
||||
2. [Data Plot](#2-data-plot)
|
||||
3. [Conceptual Illustration](#3-conceptual-illustration)
|
||||
4. [Process Flow](#4-process-flow)
|
||||
5. [Comparison Chart](#5-comparison-chart)
|
||||
6. [Result Visualization](#6-result-visualization)
|
||||
7. [Auto-Detection Heuristics](#7-auto-detection-heuristics)
|
||||
8. [Prompt Engineering Templates](#8-prompt-engineering-templates)
|
||||
|
||||
---
|
||||
|
||||
## 1. Architecture Diagram
|
||||
|
||||
**Purpose**: Show system components and their interconnections. Common in ML papers (model architecture), systems papers (distributed systems), and software engineering papers.
|
||||
|
||||
**Structural template**:
|
||||
- Top-level: input → processing layers → output
|
||||
- Each layer: named box with internal description
|
||||
- Connections: directed arrows with optional labels (data type, tensor shape)
|
||||
- Optional: skip connections, attention mechanisms, residual paths
|
||||
|
||||
**Key elements to extract**:
|
||||
- Named components (encoder, decoder, attention head, loss function)
|
||||
- Data flow direction (left-to-right or top-to-bottom)
|
||||
- Tensor shapes / data dimensions at each stage
|
||||
- Grouping (which components form a module)
|
||||
|
||||
**Backend**: Mermaid (structure) → `basic-image-gen` (polished rendering)
|
||||
|
||||
**Exemplar description** (text-based reference):
|
||||
> A Transformer encoder-decoder diagram: input embeddings feed into N stacked encoder blocks (each containing multi-head self-attention + feed-forward + layer norm), connected by residual arrows. Decoder blocks mirror the structure with added cross-attention. All arrows are labeled with tensor dimensions. Clean white background, consistent box sizing, horizontal flow.
|
||||
|
||||
**Common mistakes**:
|
||||
- Too many components crammed into one figure — split into overview + detail figures
|
||||
- Arrows crossing without clear layering — use consistent flow direction
|
||||
- Missing dimension annotations — reviewers need to verify tensor shapes
|
||||
|
||||
---
|
||||
|
||||
## 2. Data Plot
|
||||
|
||||
**Purpose**: Visualize quantitative experimental results. The most common figure type in empirical papers.
|
||||
|
||||
**Subtypes**:
|
||||
- Line plot (trends over epochs, hyperparameter sweeps)
|
||||
- Bar chart (discrete comparisons, ablation results)
|
||||
- Scatter plot (correlation, embedding visualization)
|
||||
- Histogram (distribution of scores, latency)
|
||||
- Box plot (variance across runs, statistical comparison)
|
||||
- Heatmap (attention weights, confusion matrices)
|
||||
|
||||
**Structural template**:
|
||||
- X-axis: independent variable (clearly labeled with units)
|
||||
- Y-axis: dependent variable (clearly labeled with units)
|
||||
- Legend: method names, consistent with paper text
|
||||
- Error bars / confidence intervals: when multiple runs exist
|
||||
- Grid: light gray, no heavy gridlines
|
||||
|
||||
**Key elements to extract**:
|
||||
- Data values (exact numbers from tables or inline)
|
||||
- Variable names and units
|
||||
- Method/baseline names (must match paper text exactly)
|
||||
- Number of runs / seeds (for error bars)
|
||||
|
||||
**Backend**: matplotlib/seaborn code — NEVER AI image generation
|
||||
|
||||
**Common mistakes**:
|
||||
- Truncated y-axis without break marker — misleading visual
|
||||
- Missing error bars when results vary across seeds
|
||||
- Legend covering data points — move to whitespace area
|
||||
- Inconsistent method colors across subfigures
|
||||
|
||||
---
|
||||
|
||||
## 3. Conceptual Illustration
|
||||
|
||||
**Purpose**: Explain abstract ideas, metaphors, or high-level intuitions that cannot be expressed as data or architecture.
|
||||
|
||||
**Structural template**:
|
||||
- Central metaphor / visual analogy
|
||||
- Labeled regions or entities
|
||||
- Visual encoding of relationships (proximity, size, color)
|
||||
- Minimal text annotations (key terms only)
|
||||
|
||||
**Key elements to extract**:
|
||||
- Core concept and its visual metaphor
|
||||
- Entities and their relationships
|
||||
- Any text that must appear in the figure
|
||||
- Target impression (what should the reader understand at a glance)
|
||||
|
||||
**Backend**: `basic-image-gen` (AI excels at creative visual metaphors)
|
||||
|
||||
**Exemplar description**:
|
||||
> A clean scientific illustration showing knowledge distillation: a large "Teacher" network (detailed, multi-layered structure) on the left, connected by flowing arrows labeled "soft labels" to a smaller, simpler "Student" network on the right. The teacher is rendered in deep blue, the student in teal. White background, no decorative elements, all text in sans-serif font.
|
||||
|
||||
**Common mistakes**:
|
||||
- Too abstract — reviewers need to understand without reading the caption
|
||||
- Decorative clutter (gradients, shadows) — breaks academic norms
|
||||
- Text too small or embedded in complex visuals — must be readable at print size
|
||||
|
||||
---
|
||||
|
||||
## 4. Process Flow
|
||||
|
||||
**Purpose**: Show sequential steps, decision points, and branching logic. Common in method sections and algorithm descriptions.
|
||||
|
||||
**Structural template**:
|
||||
- Start/end: rounded rectangles
|
||||
- Process steps: rectangles with action descriptions
|
||||
- Decisions: diamonds with yes/no branches
|
||||
- Data stores: cylinders or parallelograms
|
||||
- Flow: top-to-bottom or left-to-right, consistent direction
|
||||
|
||||
**Key elements to extract**:
|
||||
- Ordered steps (numbered or sequential)
|
||||
- Decision points and their conditions
|
||||
- Parallel branches (if any)
|
||||
- Loop/iteration indicators
|
||||
- Input/output at boundaries
|
||||
|
||||
**Backend**: Mermaid flowchart (primary), TikZ (fallback)
|
||||
|
||||
**Exemplar description**:
|
||||
> A training pipeline flowchart: "Raw Data" → "Preprocessing" → "Feature Extraction" → diamond "Validation Loss Decreasing?" → Yes: "Continue Training" (loops back) → No: "Early Stop" → "Evaluate on Test Set" → "Report Results". Clean boxes with consistent padding, single-color scheme, directional arrows.
|
||||
|
||||
**Common mistakes**:
|
||||
- Too many steps in one diagram — split into phases
|
||||
- Inconsistent box sizes — standardize width
|
||||
- Missing decision labels (yes/no/condition)
|
||||
|
||||
---
|
||||
|
||||
## 5. Comparison Chart
|
||||
|
||||
**Purpose**: Compare multiple methods, models, or configurations across shared metrics. The "table as a figure" pattern.
|
||||
|
||||
**Subtypes**:
|
||||
- Grouped bar chart (methods × metrics)
|
||||
- Radar/spider chart (multi-dimensional comparison)
|
||||
- Parallel coordinates (many dimensions)
|
||||
- Table with heatmap coloring (for many metrics)
|
||||
|
||||
**Structural template**:
|
||||
- X-axis: methods/models (categorical)
|
||||
- Y-axis: metric value (numerical)
|
||||
- Grouping: by metric or by method
|
||||
- Highlighting: best result bolded or starred
|
||||
- Baseline: horizontal dashed line for reference method
|
||||
|
||||
**Key elements to extract**:
|
||||
- Method names (must match paper text)
|
||||
- Metric names and values
|
||||
- Which method is "ours" (for highlighting)
|
||||
- Baseline/reference method
|
||||
- Statistical significance markers (if applicable)
|
||||
|
||||
**Backend**: matplotlib code — NEVER AI image generation
|
||||
|
||||
**Common mistakes**:
|
||||
- Too many methods/metrics in one chart — split or use table
|
||||
- No baseline reference line — hard to judge improvement
|
||||
- Inconsistent ordering — sort by performance or alphabetically
|
||||
|
||||
---
|
||||
|
||||
## 6. Result Visualization
|
||||
|
||||
**Purpose**: Show qualitative or semi-quantitative results: attention maps, feature visualizations, generated samples, ablation grids.
|
||||
|
||||
**Subtypes**:
|
||||
- Attention heatmap overlay
|
||||
- Feature map / activation visualization
|
||||
- Sample grid (generated vs real)
|
||||
- Ablation grid (each cell = one config)
|
||||
- Confusion matrix
|
||||
- t-SNE / UMAP embedding plots
|
||||
|
||||
**Structural template**:
|
||||
- Grid layout: rows = conditions, columns = samples/metrics
|
||||
- Consistent cell sizing
|
||||
- Row/column headers clearly labeled
|
||||
- Color scale legend (for heatmaps)
|
||||
- Highlight: circles or boxes around key regions
|
||||
|
||||
**Key elements to extract**:
|
||||
- What each row/column represents
|
||||
- Color scale meaning and range
|
||||
- Which samples to highlight and why
|
||||
- Grid dimensions (rows × columns)
|
||||
|
||||
**Backend**: matplotlib/seaborn code (heatmaps, grids), `basic-image-gen` (overlays on real images)
|
||||
|
||||
**Common mistakes**:
|
||||
- Missing color scale legend — uninterpretable
|
||||
- Grid cells too small at print size — ensure readability
|
||||
- No row/column labels — reader cannot identify conditions
|
||||
|
||||
---
|
||||
|
||||
## 7. Auto-Detection Heuristics
|
||||
|
||||
Keyword-based classification from source content:
|
||||
|
||||
| Keywords / Patterns | Detected Type |
|
||||
|---|---|
|
||||
| "accuracy", "F1", "BLEU", "%", table of numbers, "vs", "baseline" | comparison-chart |
|
||||
| "epoch", "learning rate", "loss curve", "over time", "trend" | data-plot |
|
||||
| "architecture", "encoder", "decoder", "layer", "module", "block" | architecture-diagram |
|
||||
| "step 1", "then", "if...then", "pipeline", "workflow", "algorithm" | process-flow |
|
||||
| "ablation", "heatmap", "attention map", "feature map", "t-SNE" | result-visualization |
|
||||
| "intuition", "concept", "metaphor", "analogy", "overview" | conceptual |
|
||||
|
||||
**Confidence scoring**:
|
||||
- 3+ keywords from one category → HIGH confidence
|
||||
- 2 keywords → MEDIUM confidence
|
||||
- 1 keyword or keywords from multiple categories → LOW confidence (ask user)
|
||||
|
||||
**Tie-breaking rules**:
|
||||
- Numeric data present → prefer data-driven types (data-plot > comparison-chart > result-visualization)
|
||||
- No numeric data → prefer structural types (architecture-diagram > process-flow > conceptual)
|
||||
|
||||
---
|
||||
|
||||
## 8. Prompt Engineering Templates
|
||||
|
||||
### For `basic-image-gen` (architecture-diagram, conceptual)
|
||||
|
||||
**Base template**:
|
||||
```
|
||||
Create a publication-quality scientific illustration for an academic paper.
|
||||
|
||||
Subject: {description_from_blueprint}
|
||||
|
||||
Style requirements:
|
||||
- Clean white background
|
||||
- No decorative elements (no shadows, no 3D, no gradients)
|
||||
- Flat design with consistent line weights
|
||||
- Colors: {palette_from_academic_styles}
|
||||
- All text in {font_family}, minimum {min_font_size}pt equivalent
|
||||
- Professional academic illustration style
|
||||
|
||||
Text elements that MUST appear legibly:
|
||||
{list_all_labels_and_annotations}
|
||||
|
||||
Layout: {layout_description}
|
||||
Aspect ratio: {width}:{height}
|
||||
```
|
||||
|
||||
### For architecture diagrams specifically
|
||||
|
||||
**Architecture template**:
|
||||
```
|
||||
Create a clean technical architecture diagram for a research paper.
|
||||
|
||||
Components (left to right / top to bottom):
|
||||
{component_list_with_descriptions}
|
||||
|
||||
Connections:
|
||||
{arrow_descriptions_with_labels}
|
||||
|
||||
Style: flat design, {venue} conference style, colors {hex_values},
|
||||
sans-serif labels, consistent box sizing, white background.
|
||||
No decorative elements. Print-ready at {width}" x {height}".
|
||||
```
|
||||
|
||||
### For conceptual illustrations
|
||||
|
||||
**Concept template**:
|
||||
```
|
||||
Create a minimalist scientific concept illustration.
|
||||
|
||||
Core concept: {concept_description}
|
||||
Visual metaphor: {metaphor_description}
|
||||
|
||||
Must include these labeled elements:
|
||||
{element_list}
|
||||
|
||||
Style: clean, academic, flat design. Colors: {hex_values}.
|
||||
White background, no gradients or shadows.
|
||||
All text must be clearly readable at small print size.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*Cross-reference: SKILL.md §Decision Tree, §Figure Type → Backend Routing*
|
||||
1
.claude/skills/write-article
Symbolic link
1
.claude/skills/write-article
Symbolic link
@ -0,0 +1 @@
|
||||
/home/kang/apps/atomstorm-claude-skills/write-article
|
||||
@ -1,173 +0,0 @@
|
||||
# write-article Skill 生产架构总览
|
||||
|
||||
## 文件体量
|
||||
|
||||
```
|
||||
.claude/skills/write-article/
|
||||
├── SKILL.md ~330 行 ~2,000 字 接口层（工作流 + 约束）
|
||||
└── references/
|
||||
├── material-anchors.md ~150 行 ~1,000 字 素材锚点（四类锚点 + 脚手架 + 编织规则）
|
||||
├── content-quality.md ~275 行 ~1,800 字 质量框架（标题/去AI味/完读率/素材密度）
|
||||
├── writing-styles.md 122 行 ~750 字 风格模板（5 种）
|
||||
└── personas.md 145 行 ~650 字 人格配置（1 个 + 扩展模板）
|
||||
─────────────────
|
||||
~1,022 行 ~6,200 字 总上下文消耗
|
||||
```
|
||||
|
||||
## 渐进式披露架构
|
||||
|
||||
```
|
||||
Agent 加载顺序（上下文消耗）
|
||||
─────────────────────────────────────────────────────────────
|
||||
|
||||
第 1 层：SKILL.md（必加载，~1,600 字）
|
||||
┌──────────────────────────────────────────────────────────┐
|
||||
│ frontmatter 触发匹配 + 依赖声明 │
|
||||
│ 目标 流量池公式 + 质量底线 │
|
||||
│ 输入要求 5 必填 + 7 可选 + style×persona 矩阵 │
|
||||
│ 7 步工作流 摘要+指针，不含详细规则 │
|
||||
│ 输出约束 6 条硬性规则 │
|
||||
│ 失败处理 3 种失败模式 │
|
||||
│ 风格参考 5 个文件指针 │
|
||||
└──────────────┬───────────────────────────────────────────┘
|
||||
│ 按需加载（只在对应 Step 触发时读取）
|
||||
▼
|
||||
第 2 层：references/（按需，~4,200 字）
|
||||
┌──────────────────────┐ ┌────────────────────┐ ┌──────────────────┐ ┌───────────────┐
|
||||
│ material-anchors.md │ │ content-quality.md │ │ writing-styles.md│ │ personas.md │
|
||||
│ │ │ │ │ │ │ │
|
||||
│ Step 1b → §1-§3 │ │ Step 3 → §1 标题 │ │ Step 4 → 选风格 │ │ Step 2 → 激活 │
|
||||
│ 素材锚点+脚手架 │ │ Step 4a → §2 去AI │ │ │ │ │
|
||||
│ Step 4 → §4 编织 │ │ Step 4b → §3 完读率│ │ │ │ │
|
||||
│ Step 7 → §4.4 门禁 │ │ Step 7 → §4 门禁 │ │ │ │ │
|
||||
└──────────────────────┘ └────────────────────┘ └──────────────────┘ └───────────────┘
|
||||
│
|
||||
▼
|
||||
第 3 层：vault 内文件（仅 lizi_kk 风格触发）
|
||||
┌──────────────────────────────────────────────────────────┐
|
||||
│ templates/author-style-lizi-kk.md 详细风格指南 │
|
||||
│ personal-context/ (5 篇) 已发表文章参考 │
|
||||
│ 通过 obsidian read 读取，不占 skill 上下文 │
|
||||
└──────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
架构判定：三层分离合理。SKILL.md 是接口，references 是实现，vault 文件是数据。Agent 不需要一次性加载全部 4,400 字。
|
||||
|
||||
## 7 步工作流 × 文件依赖矩阵
|
||||
|
||||
```
|
||||
Step 名称 SKILL.md content-quality writing-styles personas material-anchors vault 文件
|
||||
──── ──── ──────── ─────────────── ────────────── ──────── ──────────────── ──────────
|
||||
1a 读取素材 ✓ 指令 ✓ obsidian read
|
||||
1b 提取素材锚点 ✓ 约束 ✓ §1-§3 锚点+脚手架
|
||||
2 激活人格 ✓ 格式 ✓ 激活
|
||||
3 标题工程 ✓ 约束 ✓ §1 详细公式
|
||||
4 生成草稿 ✓ 约束 ✓ §2 去AI味 ✓ 选风格 ✓ 口吻 ✓ §4 编织规则 ✓ lizi_kk 模板
|
||||
✓ §3 完读率 ✓ personal-context
|
||||
5 创建文件 ✓ 模板 ✓ obsidian create
|
||||
6 验证 frontmatter ✓ 清单 ✓ obsidian read
|
||||
7 质量检查 ✓ 门禁 ✓ §4 完整清单 ✓ §4.4 素材密度
|
||||
```
|
||||
|
||||
Step 4 是资源消耗峰值——同时需要 5 个参考源。这是合理的，因为生成草稿是整个 skill 的核心价值所在。
|
||||
|
||||
## 跨文件一致性检查
|
||||
|
||||
```
|
||||
检查项 结果 备注
|
||||
─────────────────────────────────────────────────────────────
|
||||
风格数量声明一致 ✓ SKILL.md "5种" = writing-styles.md "5类"
|
||||
persona 数据一致（20000+） ✓ personas.md:27 = personas.md:75
|
||||
frontmatter 字段对齐 CLAUDE.md §4.2 ✓ 14 个必填字段全覆盖
|
||||
门禁清单覆盖所有质量维度 ✓ 基础(4) + 标题(3) + 去AI味(8) + 完读率(6) + 素材密度(6) = 27 项
|
||||
SKILL.md 指针与 content-quality.md 章节对应 ✓ §1/§2/§3/§4（含§4.4素材密度）均有对应引用
|
||||
SKILL.md 指针与 material-anchors.md 对应 ✓ §1-§3(Step 1b) + §4(Step 4) + §4.4(Step 7)
|
||||
material-anchors.md 锚点类型与示例完整 ✓ 4 类锚点均有 personal-context + 苍何爆款双源示例
|
||||
writing-styles.md 每个风格结构统一 ✓ 全部包含 语气/结构/禁忌 三节
|
||||
personas.md 扩展模板完整 ✓ 有 YAML 模板 + 4 步新增指南
|
||||
vault 路径使用 $VAULT_PATH 可配置 ✓ ${VAULT_PATH:-default}
|
||||
```
|
||||
|
||||
## 数据流全景图
|
||||
|
||||
```
|
||||
用户输入 SKILL.md 工作流 输出
|
||||
┌────────────┐ ┌────────────────────────┐ ┌─────────────┐
|
||||
│ topic │ │ │ │ │
|
||||
│ style │──▶ Step 1a: obsidian read ──▶│ 事实边界确认 │ │ 02-drafts/ │
|
||||
│ audience │ Step 1b: 素材锚点提取 ──▶ │ 素材脚手架（≥3锚点） │ │ YYYY-MM-DD │
|
||||
│ source_notes│ Step 2: persona 激活 ──▶ │ 口吻锁定（可选） │ │ -slug.md │
|
||||
│ tags │ │ │ │ │
|
||||
│ [persona] │ Step 3: 标题工程 ──────▶ │ ≥5 候选 → 评分 → 选定 │ │ frontmatter │
|
||||
│ [intensity]│ │ │ │ + 正文 │
|
||||
│ [title] │ Step 4: 生成草稿 ──────▶ │ 素材编织 × 风格模板 │ │ │
|
||||
│ [slug] │ │ × 去AI味 × 完读率 │ │ 27 项门禁 │
|
||||
│ [cta] │ Step 5: obsidian create ─▶│ frontmatter + body │──▶ Step 7 ──▶ │ 全部通过 │
|
||||
│[mat_sources]│ Step 6: 回读验证 ────────▶│ 字段完整性修补 │ └─────────────┘
|
||||
└────────────┘ └────────────────────────┘
|
||||
|
||||
┌──────────────────────────────────────────────────────────────────┐
|
||||
参考文件调用： │ material-anchors.md ← Step 1b, 4, 7 │
|
||||
│ content-quality.md ← Step 3, 4a, 4b, 7 │
|
||||
│ writing-styles.md ← Step 4 │
|
||||
│ personas.md ← Step 2 │
|
||||
│ vault/templates/ ← Step 4 (仅 lizi_kk) │
|
||||
│ vault/personal-context/ ← Step 1a, 4 (亲历锚点 + lizi_kk) │
|
||||
└──────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 与 content-forge 全链路对接
|
||||
|
||||
```
|
||||
content-forge 生产线 write-article 覆盖范围
|
||||
──────────────────────────────────────────────────────────────
|
||||
|
||||
S0 选题入库 ──▶ 01-topics/*.md
|
||||
│
|
||||
▼
|
||||
S1 外链采集 ──▶ url-to-markdown（可选）
|
||||
│
|
||||
▼
|
||||
┌──────────────────────────────────────────┐
|
||||
│ S2 草稿生成 ──▶ write-article │
|
||||
│ Step 1a: 读取素材 + vault 搜索 │
|
||||
│ Step 1b: 提取素材锚点 ◀── NEW │
|
||||
│ Step 2: 人格激活 │
|
||||
│ Step 3: 标题工程 │
|
||||
│ Step 4: 生成草稿 (素材编织+去AI味+完读率) │
|
||||
│ Step 5: 写入 02-drafts │
|
||||
│ Step 6: 验证 frontmatter │
|
||||
│ Step 7: 质量门禁 (27项) ◀── NEW │
|
||||
│ │
|
||||
│ S3 状态标记 ──▶ status: draft │
|
||||
└──────────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
S4 格式清洗 ──▶ format-markdown
|
||||
│
|
||||
S5 视觉资产 ──▶ baoyu-cover-image / baoyu-article-illustrator
|
||||
│
|
||||
S6 审核 ──▶ /review + /multi-review + /challenge
|
||||
│
|
||||
S7 润色 ──▶ polish
|
||||
│
|
||||
S8 发布 ──▶ post-to-wechat / post-to-x
|
||||
│
|
||||
S9 归档 ──▶ 04-published/*.md
|
||||
```
|
||||
|
||||
write-article 覆盖 S2-S3（选题→草稿），是全链路中**上下文消耗最大、创意密度最高**的环节。标题工程和质量门禁的加入，把原来"写完就交"变成了"写完过检才交"。
|
||||
|
||||
## 架构评分
|
||||
|
||||
| 维度 | 评分 | 说明 |
|
||||
|------|------|------|
|
||||
| 渐进式披露 | PASS | SKILL.md 摘要+指针，不再重复 reference 内容 |
|
||||
| 跨文件一致性 | PASS | 数据、字段、章节引用全部对齐 |
|
||||
| 单一职责 | PASS | 每个 reference 文件只管一件事 |
|
||||
| 可扩展性 | PASS | personas.md 有扩展模板，writing-styles.md 可加新风格 |
|
||||
| 可移植性 | PASS | `$VAULT_PATH` 可配置，不再硬编码 |
|
||||
| 质量保障 | PASS | 27 项门禁（基础4 + 标题3 + 去AI味8 + 完读率6 + 素材密度6），任一失败即打回 |
|
||||
| 上下文效率 | WARN | 总量 6,200 字合理，但 Step 4 峰值同时需 5 个源 |
|
||||
|
||||
整体评价：数据结构（5 文件分层）决定了算法（7 步工作流）的优雅——每个 Step 只去找自己需要的 reference，不多加载一个字。material-anchors.md 的加入把质量防线从单层（表达）扩展为双层（内容+表达），Step 1b 的素材脚手架确保"先有素材，再有文章"。唯一的 WARN 是 Step 4 的峰值加载，但这是生成阶段的固有复杂度，没有更简单的方法。
|
||||
@ -1,369 +0,0 @@
|
||||
---
|
||||
name: write-article
|
||||
description: >
|
||||
Generate articles from Obsidian vault topics, optimized for traffic pool entry
|
||||
(click-through × dwell time × completion rate). Output: a publish-ready draft
|
||||
in 02-drafts/ with complete frontmatter, passing 27-item quality gate
|
||||
(material density + title + de-AI + completion rate).
|
||||
|
||||
USE WHEN: User wants to create new long-form content (tech blog, opinion piece,
|
||||
tutorial, social post, lizi_kk-style article) from a structured topic in 01-topics/.
|
||||
Trigger phrases: 写文章、写作、生成草稿、技术博客、观点文、教程、社交短文、
|
||||
article、blog post、draft、人格写作、栗子KK风格。
|
||||
|
||||
DON'T USE WHEN:
|
||||
- User wants to analyze/deconstruct existing content → use dao-analysis instead.
|
||||
- User wants to review/critique an existing draft → use multi-review or /review instead.
|
||||
- User wants to import an external draft into vault → use import-draft instead.
|
||||
- User wants to load vault context → use my-world instead.
|
||||
- User wants to edit an existing draft in 02-drafts/ → use obsidian CLI directly.
|
||||
- User says "分析"、"拆解"、"审查"、"导入" without creation intent → not this skill.
|
||||
---
|
||||
|
||||
# Write-Article：Obsidian 文章写作技能
|
||||
|
||||
## 目标
|
||||
|
||||
用统一流程产出**能进流量池**的可发布草稿。
|
||||
|
||||
核心公式：**点击率 × 停留时长 × 完读率 = 流量池入场券**。三项相乘，任一项为零则全盘归零。详见 `references/content-quality.md`。
|
||||
|
||||
质量底线：
|
||||
- 标题：候选 ≥5 个，评分 ≥18/25
|
||||
- 去 AI 味：零容忍黑名单词汇，人味注入 ≥5 项
|
||||
- 完读率：Hook 前 3 句到位，段间钩子不断，结尾金句+CTA
|
||||
|
||||
## 路由规则（Use when / Don't use when）
|
||||
|
||||
Use this skill when:
|
||||
- User wants to **create new content** from a topic brief in `01-topics/`
|
||||
- User says "写文章"、"生成草稿"、"write an article"、"create a draft"
|
||||
- User specifies a style (tech_blog, opinion, tutorial, social_short, lizi_kk)
|
||||
- User provides source notes and wants a publish-ready draft
|
||||
|
||||
Do NOT use this skill when:
|
||||
- User wants to **analyze** existing content (article, transcript, concept) → use `dao-analysis`
|
||||
- User wants to **review/critique** a draft for quality → use `multi-review` or `/review` command
|
||||
- User wants to **import** an external draft into the vault → use `import-draft`
|
||||
- User wants to **load vault context** or see what's in the vault → use `my-world`
|
||||
- User wants to **edit** an existing draft (fix typos, update sections) → use `obsidian` CLI directly
|
||||
- User wants to **format** a draft for publishing → use `format-markdown` (baoyu skill)
|
||||
|
||||
Edge cases:
|
||||
- "帮我把这篇笔记改写成文章" → **this skill** (creation from notes = write-article)
|
||||
- "分析一下这篇文章为什么火" → **not this skill** (analysis = dao-analysis)
|
||||
- "审查我的草稿" → **not this skill** (review = multi-review)
|
||||
- "把 atomstorm 项目里的文章导入 vault" → **not this skill** (import = import-draft)
|
||||
|
||||
## 输入要求
|
||||
|
||||
必须提供：
|
||||
- `topic`：文章主题（1 句话）
|
||||
- `style`：`tech_blog` | `opinion` | `tutorial` | `social_short` | `lizi_kk`
|
||||
- `audience`：目标读者
|
||||
- `source_notes`：至少 1 个 Obsidian note 路径（vault 相对路径）
|
||||
- `tags`：1-5 个标签
|
||||
|
||||
可选：
|
||||
- `persona`：人格激活（`栗子KK`），深度扮演作者身份
|
||||
- `intensity`：人格强度 `light` | `medium` | `heavy`（默认 medium）
|
||||
- `title`：文章标题（如未提供，Step 3 强制生成候选）
|
||||
- `slug`：文件 slug（英文短横线）
|
||||
- `length_target`：目标字数或段落数
|
||||
- `cta`：结尾行动建议
|
||||
- `publish_channel`：发布渠道
|
||||
- `material_sources`：额外素材文件路径列表（vault 相对路径），用于补充素材锚点
|
||||
|
||||
> **风格与人格联动**：当 `style: lizi_kk` 时，自动加载 vault 内 `templates/author-style-lizi-kk.md` 和 `personal-context/` 参考文章，无需额外指定参数。
|
||||
|
||||
**`style` 与 `persona` 交互矩阵**：
|
||||
|
||||
| 组合 | 行为 |
|
||||
|------|------|
|
||||
| `style: lizi_kk` 无 `persona` | 仅应用风格模板（结构+语言特征），不深度扮演 |
|
||||
| `persona: 栗子KK` 无 `style: lizi_kk` | 人格口吻叠加到所选风格上（如 tech_blog + 栗子KK 语气） |
|
||||
| 两者都设置 | 完整集成：风格模板 + 人格深度扮演（推荐） |
|
||||
|
||||
## 强制工作流（7 步，不得跳步）
|
||||
|
||||
### Step 1a：读取素材
|
||||
|
||||
逐个读取 `source_notes` 中的笔记，并搜索 vault 中相关素材，确认事实边界。
|
||||
|
||||
```bash
|
||||
# 必须先 cd 到 vault 目录（CLAUDE.md §6.1 强制要求）
|
||||
cd "${VAULT_PATH:-/home/kang/apps/content-forge/content-forge}"
|
||||
|
||||
# 读取指定源笔记
|
||||
obsidian read path="<source_note_path_1>"
|
||||
obsidian read path="<source_note_path_2>"
|
||||
|
||||
# 搜索 vault 中相关素材（关键词来自 topic）
|
||||
obsidian search query="<topic关键词>"
|
||||
|
||||
# 读取匹配的 personal-context/ 文章（亲历锚点来源）
|
||||
obsidian read path="personal-context/<matching_article>.md"
|
||||
|
||||
# 读取匹配的 09-viral-examples/ 案例（案例/数据锚点来源）
|
||||
obsidian read path="09-viral-examples/<matching_example>.md"
|
||||
|
||||
# 读取用户额外指定的素材（如有 material_sources 参数）
|
||||
obsidian read path="<material_source_path>"
|
||||
```
|
||||
|
||||
执行要求：
|
||||
- `source_notes` 中每个路径都要读取。
|
||||
- 主动搜索 vault 中与 topic 相关的素材（`personal-context/`、`00-inbox/`、`09-viral-examples/`）。
|
||||
- 未读完素材前，禁止进入写作。
|
||||
- 素材来源优先级见 `references/material-anchors.md` §2。
|
||||
|
||||
### Step 1b：提取素材锚点
|
||||
|
||||
从 Step 1a 读取的所有素材中，提取四类素材锚点并输出素材脚手架。
|
||||
|
||||
详细规则见 `references/material-anchors.md`。核心约束：
|
||||
|
||||
- **总锚点 ≥3**，**Type A（亲历）≥1**，**Type B 或 C（数据/案例）≥1**
|
||||
- 必须输出结构化素材脚手架（格式见 `references/material-anchors.md` §3）
|
||||
- 素材不足时输出 `[?] 素材不足：缺少 <具体类型>`，**禁止进入 Step 2**
|
||||
|
||||
输出格式：
|
||||
```
|
||||
## 素材脚手架
|
||||
|
||||
### Type A 亲历锚点
|
||||
1. [锚点描述] — 来源: [vault路径]
|
||||
...
|
||||
|
||||
### Type B 数据锚点
|
||||
1. [数据 + 来源归属] — 来源: [vault路径或URL]
|
||||
...
|
||||
|
||||
### Type C 案例锚点
|
||||
1. [命名实体 + 分析要点] — 来源: [vault路径或URL]
|
||||
...
|
||||
|
||||
### Type D 观察锚点
|
||||
1. [引用/对话 + 归属] — 来源: [vault路径]
|
||||
...
|
||||
|
||||
### 统计
|
||||
- 总锚点: X 个
|
||||
- Type A: X 个 ✓/✗（≥1）
|
||||
- Type B|C: X 个 ✓/✗（≥1）
|
||||
- 判定: 通过 / [?] 素材不足
|
||||
```
|
||||
|
||||
### Step 2：激活人格（可选）
|
||||
|
||||
如果提供了 `persona` 参数，按 `references/personas.md` 激活对应人格。
|
||||
|
||||
**激活确认格式**：
|
||||
```
|
||||
收到，创作者。'栗子KK' 人格已上线（强度：medium）。
|
||||
|
||||
> 风格预览：说实话，这个坑我踩了不下10次，今天终于有空聊聊。
|
||||
|
||||
等待您的创作指令。
|
||||
```
|
||||
|
||||
**人格参数**：
|
||||
- `persona`: 人格名称（目前支持 `栗子KK`）
|
||||
- `intensity`: `light` | `medium` | `heavy`（默认 medium）
|
||||
|
||||
### Step 3：标题工程
|
||||
|
||||
标题决定 80% 的点击率。**禁止只写一个标题直接用。**
|
||||
|
||||
完整流程见 `references/content-quality.md` §1。核心约束：
|
||||
|
||||
- 生成 **≥5 个候选标题**，覆盖不同公式（经历+数字+痛点 / 成本+悬念+真相 / 反常识 / 99%+反差 / 身份锚定）
|
||||
- 每个候选命中**五要素 ≥3 项**（第一人称"我"、具体数字、张力词、信息缺口、身份锚定）
|
||||
- **评分 ≥18/25**（5 维度 × 1-5 分：好奇心缺口、情绪冲击、身份共鸣、具体度、可信度）
|
||||
- 标题 **≤35 字**（微信折叠阈值）
|
||||
- 禁止学术腔、泛泛而谈、标题党
|
||||
|
||||
输出格式：
|
||||
```
|
||||
候选标题：
|
||||
1. [标题] — 评分: XX/25 — 命中要素: [列表]
|
||||
2. [标题] — 评分: XX/25 — 命中要素: [列表]
|
||||
...
|
||||
|
||||
✦ 最终选定: [标题]（原因: ...）
|
||||
```
|
||||
|
||||
### Step 4：生成文章草稿
|
||||
|
||||
按 `references/writing-styles.md` 选择对应风格模板生成正文。
|
||||
如果激活了人格，同时应用 `references/personas.md` 的人格设定。
|
||||
|
||||
**素材先行原则**（详见 `references/material-anchors.md` §4）：
|
||||
- 正文必须围绕 Step 1b 的素材脚手架构建，每个主要论点必须锚定到具体素材。
|
||||
- Hook 第 1 句必须直接包含 ≥1 素材锚点（优先 Type A 或 Type B）。不是"前 3 句"，是"第 1 句"——铺垫后置。
|
||||
- 每个主要章节（H2/编号段落）至少引用 ≥1 个锚点。
|
||||
- 结尾回扣开头锚点，形成首尾呼应。
|
||||
- 所有事实性断言必须追溯到素材锚点，或标记 `[?]` 待验证。
|
||||
|
||||
**风格联动规则**：
|
||||
- 当 `style: lizi_kk` 时，必须额外通过 `obsidian read path="templates/author-style-lizi-kk.md"` 读取风格指南，并参考 `personal-context/` 目录的已发表文章（这些文件位于 vault 内，需在 vault 目录下执行 CLI）。
|
||||
|
||||
#### 4a. 去 AI 味（强制）
|
||||
|
||||
详细规则见 `references/content-quality.md` §2。核心执行项：
|
||||
|
||||
- **黑名单零容忍**：开头/过渡/结尾废话出现即重写（完整黑名单见 §2.1）
|
||||
- **意义膨胀零容忍**：删除"里程碑意义"、"划时代"、"引领新范式"等空洞修饰（§2.1）
|
||||
- **模糊引用零容忍**：所有"研究表明"、"业内人士"必须给出具体来源，否则删除（§2.1）
|
||||
- **打破 AI 结构**：段落长短交替（每连续 3 段必须有 ≥1 段 ≤2 句话）、打破对称、语气变化、偶尔不完整句、禁止绕路表述（§2.2）
|
||||
- **禁止抽象过度**：每个抽象观点后必须紧跟一个具体场景（含时间/地点/数字/工具名），禁止连续两个以上的纯观点段落（§2.2）
|
||||
- **禁止聚合清单**：禁止在结尾或独立章节使用"我的N个思考/感悟/总结"式编号列表，洞察必须散布在正文中（§2.2）
|
||||
- **人味注入 ≥5 项**：不规则段落、口语化、括号吐槽、具体数字、个人经历、反问句、混合情绪、刻意凌乱等（完整清单 12 项见 §2.3）
|
||||
- **二次审计**：门禁检查后，通读全文自问"哪里一眼看出 AI 写的"→列出→修复（§2.4）
|
||||
|
||||
#### 4b. 完读率优化（强制）
|
||||
|
||||
详细规则见 `references/content-quality.md` §3。核心执行项：
|
||||
|
||||
- **前 3 句 Hook**：反直觉结论 / 真金白银 / 身份挑战 / 悬念制造（禁止背景介绍、自我介绍、目录式开头）
|
||||
- **段间钩子**：每个 section 尾部制造"未完成感"
|
||||
- **小标题有信息量**：不是"第一步"而是"第一步：这个操作让90%的人栽跟头"
|
||||
- **阅读节奏**：每 300-500 字视觉断点，每连续 3 段必须有 ≥1 段 ≤2 句话，代码块 ≤15 行
|
||||
- **结尾工程**：回扣开头 + 金句 + 具体 CTA
|
||||
|
||||
执行要求：
|
||||
- 只使用已读取素材中的事实。
|
||||
- 观点必须有论证链，不得堆砌口号。
|
||||
- 内容结构必须匹配所选风格的"结构"要求。
|
||||
- 人格激活时，口吻必须符合人格的 `voice_signature` 和 `catchphrases`。
|
||||
|
||||
### Step 5：创建草稿文件
|
||||
|
||||
将 frontmatter + 正文一次性写入 `02-drafts/` 目录，减少 CLI 调用开销。
|
||||
|
||||
```bash
|
||||
obsidian create path="02-drafts/<YYYY-MM-DD>-<slug>.md" content="---
|
||||
id: '<YYYY-MM-DD>-<slug>'
|
||||
title: '<title>'
|
||||
slug: '<slug>'
|
||||
status: draft
|
||||
content_type: article
|
||||
channels:
|
||||
- wechat
|
||||
- x
|
||||
language: zh-CN
|
||||
source_urls: []
|
||||
assets: []
|
||||
cover_image: ''
|
||||
template: article
|
||||
owner: content-forge
|
||||
created_at: '<YYYY-MM-DD>T00:00:00+08:00'
|
||||
updated_at: '<YYYY-MM-DD>T00:00:00+08:00'
|
||||
style: '<style>'
|
||||
audience: '<audience>'
|
||||
tags:
|
||||
- '<tag1>'
|
||||
- '<tag2>'
|
||||
source_notes:
|
||||
- '<note1.md>'
|
||||
---
|
||||
|
||||
<ARTICLE_BODY>"
|
||||
```
|
||||
|
||||
执行要求：
|
||||
- 目标目录必须是 `02-drafts/`。
|
||||
- 文件名必须包含日期前缀与 slug。
|
||||
- frontmatter 必填字段对齐 CLAUDE.md §4.2（id, title, slug, status, content_type, channels, language, source_urls, assets, cover_image, template, owner, created_at, updated_at）。
|
||||
- 正文必须是 Markdown，可直接发布或二次编辑。
|
||||
|
||||
### Step 6：验证 frontmatter
|
||||
|
||||
创建完成后，回读文件确认 frontmatter 完整性。
|
||||
|
||||
```bash
|
||||
obsidian read path="02-drafts/<YYYY-MM-DD>-<slug>.md"
|
||||
```
|
||||
|
||||
如果回读发现 frontmatter 字段缺失或格式异常，使用 `property:set` 逐项修补：
|
||||
|
||||
```bash
|
||||
obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="<field>" value="<value>"
|
||||
```
|
||||
|
||||
必填字段检查清单（对齐 CLAUDE.md §4.2）：
|
||||
- `id`, `title`, `slug`, `status`, `content_type`, `channels`, `language`
|
||||
- `source_urls`, `assets`, `cover_image`, `template`, `owner`
|
||||
- `created_at`, `updated_at`
|
||||
|
||||
### Step 7：质量检查
|
||||
|
||||
逐项验证并输出 `[✓]` 或 `[✗]`，**任一项 `[✗]` 时停止交付并修复**。
|
||||
|
||||
完整门禁清单见 `references/content-quality.md` §4。
|
||||
|
||||
#### 基础门禁
|
||||
|
||||
- [ ] 所有 `source_notes` 已执行 `obsidian read`
|
||||
- [ ] 草稿已通过 `obsidian create` 写入 `02-drafts/`
|
||||
- [ ] frontmatter 必填字段完整（Step 6 回读验证通过）
|
||||
- [ ] 不存在事实捏造与无依据断言
|
||||
|
||||
#### 标题门禁（§4.1）
|
||||
|
||||
- [ ] 候选标题 ≥5 个
|
||||
- [ ] 最终标题评分 ≥18/25，命中五要素 ≥3 项
|
||||
- [ ] 标题 ≤35 字
|
||||
|
||||
#### 去 AI 味门禁（§4.2）
|
||||
|
||||
- [ ] 前 50 字无黑名单词汇
|
||||
- [ ] 无"首先...其次...最后"四段式
|
||||
- [ ] 结尾无"综上所述/希望有帮助"
|
||||
- [ ] 无意义膨胀词汇（"里程碑意义"、"划时代"、"深远影响"）
|
||||
- [ ] 无模糊引用（"业内人士表示"、"研究表明"须给出处）
|
||||
- [ ] 相邻段落字数差异 >20%（至少 3 组）
|
||||
- [ ] 人味注入清单命中 ≥5 项（含混合情绪/刻意凌乱）
|
||||
- [ ] 二次审计通过（自问"哪里一眼看出AI"→ 无残留）
|
||||
|
||||
#### 完读率门禁（§4.3）
|
||||
|
||||
- [ ] 前 3 句完成 Hook
|
||||
- [ ] 每个 section 尾部有段间钩子
|
||||
- [ ] 小标题有信息量
|
||||
- [ ] 每 300-500 字有视觉断点
|
||||
- [ ] 结尾有金句 + 具体 CTA
|
||||
- [ ] 全文无超过 15 行的代码块
|
||||
|
||||
#### 素材密度门禁（§4.4）
|
||||
|
||||
- [ ] 素材脚手架已在 Step 1b 输出，总锚点 ≥3
|
||||
- [ ] 亲历锚点（Type A）≥1
|
||||
- [ ] 数据/案例锚点（Type B/C）≥1
|
||||
- [ ] 第 1 句包含 ≥1 素材锚点（非标题，正文首句）
|
||||
- [ ] 每个主要章节引用 ≥1 锚点
|
||||
- [ ] 无未标注来源的事实性断言（或已标 `[?]`）
|
||||
|
||||
## 输出约束
|
||||
|
||||
- 输出仅包含文章草稿及必要元数据，不输出无关解释。
|
||||
- 文章语言默认中文，除非用户显式要求其他语言。
|
||||
- 禁止编造数据、案例、引文、实验结果。
|
||||
- 未确认的事实必须标记 `[?]`，并明确缺失项。
|
||||
- 结构必须符合所选风格规范（见 `references/writing-styles.md`）。
|
||||
- 段落应可读，避免空泛套话与重复表达。
|
||||
|
||||
## 失败处理
|
||||
|
||||
- 缺少必要输入时，返回：`[?] 缺失输入：<字段名>`，并停止写入。
|
||||
- `obsidian` 命令失败时，返回：`[✗] <命令> 失败：<错误信息>`，并停止后续步骤。
|
||||
- 如果无法确定风格，默认使用 `tech_blog`，同时显式告知用户。
|
||||
|
||||
## 风格参考
|
||||
|
||||
- `references/material-anchors.md` — 素材锚点规范（四类锚点 + 脚手架 + 编织规则）
|
||||
- `references/content-quality.md` — 流量池质量框架（标题工程 + 去AI味 + 完读率 + 素材密度）
|
||||
- `references/writing-styles.md` — 5 种写作风格模板
|
||||
- `references/personas.md` — 人格化配置（栗子KK）
|
||||
- vault 内 `templates/author-style-lizi-kk.md` — 栗子KK 详细风格指南（通过 `obsidian read` 读取）
|
||||
- vault 内 `personal-context/` — 已发表文章参考（5 篇）
|
||||
@ -1,273 +0,0 @@
|
||||
# Content Quality Reference
|
||||
|
||||
流量池入场公式：**点击率 × 停留时长 × 完读率**。三项相乘，任一项为零则全盘归零。
|
||||
|
||||
---
|
||||
|
||||
## 1. 标题工程（决定 80% 点击率）
|
||||
|
||||
### 1.1 标题生成规则
|
||||
|
||||
**强制要求**：每篇文章必须生成 ≥5 个候选标题，从中选出最佳。禁止只写一个标题直接用。
|
||||
|
||||
### 1.2 已验证的标题公式
|
||||
|
||||
从 `personal-context/` 5 篇已发表高流量文章提炼：
|
||||
|
||||
| 公式 | 已验证案例 | 结构拆解 |
|
||||
|------|-----------|---------|
|
||||
| **经历+数字+致命痛点** | "做了两年AI Agent，我发现99%的AI Agent项目都死在了Message Flow设计上" | 时间成本 → 数字冲击 → 死因 |
|
||||
| **金钱成本+悬念+真相** | "烧了2000美金在AI写代码上，我发现了一个残酷真相" | 烧钱 → 好奇心缺口 → 真相 |
|
||||
| **数字+反常识+结果** | "我研究了OpenClaw的8个反常识设计，终于明白这个Agent为什么能火爆全球" | 量化研究 → 反常识 → 因果 |
|
||||
| **99%+反差+具体痛点** | "我发现市面上99%教你用Claude Code的，连最基本的CLAUDE.md都不会用" | 全网否定 → 反差 → 具体短板 |
|
||||
| **成本+里程碑+权威背书** | "4个月烧了2万刀Token...Sam Altman预言的超级个体，可能真的来了" | 真金白银 → 成果 → 大佬站台 |
|
||||
|
||||
### 1.3 标题五要素检查
|
||||
|
||||
每个候选标题必须命中 ≥3 项：
|
||||
|
||||
```
|
||||
□ 第一人称"我" — 降低防御感，建立亲近（5/5 篇命中）
|
||||
□ 具体数字 — 99%、2000美金、8个、两年（5/5 篇命中）
|
||||
□ 张力词 — 死在、残酷真相、反常识、不会用、终于（5/5 篇命中）
|
||||
□ 信息缺口 — 读完标题不知道答案，必须点进去（4/5 篇命中）
|
||||
□ 身份锚定 — 目标读者能立刻对号入座（3/5 篇命中）
|
||||
```
|
||||
|
||||
### 1.4 标题禁忌
|
||||
|
||||
- **禁止**：泛泛而谈（"AI 编程的一些思考"）
|
||||
- **禁止**：没有数字的标题（"浅谈 Agent 架构设计"）
|
||||
- **禁止**：学术腔（"基于 XX 的 YY 研究与实践"）
|
||||
- **禁止**：标题党但正文接不住（标题 10 分正文 3 分 = 负口碑）
|
||||
- **禁止**：超过 35 字（微信标题折叠阈值约 35 字，X 更短）
|
||||
|
||||
### 1.5 标题评分表
|
||||
|
||||
生成候选标题后，按以下维度打分（1-5 分），总分 ≥18 分才可使用：
|
||||
|
||||
| 维度 | 1分 | 3分 | 5分 |
|
||||
|------|-----|-----|-----|
|
||||
| 好奇心缺口 | 读完标题就知道答案 | 大概猜到方向 | 完全猜不到，必须点进去 |
|
||||
| 情绪冲击 | 平淡无感 | 有点意思 | "卧槽真的假的" |
|
||||
| 身份共鸣 | 跟我无关 | 有点相关 | "这说的不就是我吗" |
|
||||
| 具体度 | 模糊抽象 | 有方向 | 有数字、有场景、有细节 |
|
||||
| 可信度 | 像营销号 | 像自媒体 | 像真人分享真实经历 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 去 AI 味（决定可信度和停留时长）
|
||||
|
||||
### 2.1 AI 味废话黑名单（零容忍）
|
||||
|
||||
以下表达一旦出现，读者大脑自动切换为"又是AI写的"→关闭页面：
|
||||
|
||||
**开头废话**（前 3 句出现 = 直接关页面）：
|
||||
- "在当今快速发展的XX领域"
|
||||
- "随着XX的不断发展/日益普及"
|
||||
- "在这个XX的时代"
|
||||
- "让我们一起来看看/探讨"
|
||||
- "你是否曾经想过"
|
||||
|
||||
**过渡废话**（段落间出现 = 像在读说明书）：
|
||||
- "值得注意的是"
|
||||
- "不可否认的是"
|
||||
- "众所周知"
|
||||
- "接下来我将从以下几个方面"
|
||||
- "首先...其次...再次...最后"（四段式必死）
|
||||
|
||||
**结尾废话**（最后出现 = 像在交作业）：
|
||||
- "总的来说/综上所述/总而言之"
|
||||
- "希望本文对你有所帮助"
|
||||
- "以上就是关于XX的全部内容"
|
||||
- "感谢阅读，期待你的反馈"
|
||||
|
||||
**意义膨胀**（Significance Inflation — 把平凡事写成史诗）：
|
||||
- "具有里程碑意义的"、"划时代的"、"引领了XX新范式/新潮流"
|
||||
- "深刻改变了XX格局"、"具有深远的影响"
|
||||
- "XX的崛起标志着..."、"在XX进程中扮演着关键角色"
|
||||
- "不可磨灭的贡献"、"开创性的实践"
|
||||
|
||||
> 来源：Wikipedia "Signs of AI writing" — Significance Inflation。AI 倾向于把一切描述为"重大"、"关键"、"深远"，因为统计上这些词在训练数据中最安全。
|
||||
|
||||
**模糊引用**（Vague Attributions — 没有来源的权威感）：
|
||||
- "业内人士表示/指出"、"有观点认为"、"据了解"
|
||||
- "专家普遍认为"、"研究表明"（不指名哪个研究）
|
||||
- "越来越多的人开始..."、"许多开发者发现..."
|
||||
- "有人说"、"据报道"（不给出处）
|
||||
|
||||
> 来源：Wikipedia "Signs of AI writing" — Vague Attributions。对比人类写法："根据 2024 年 Stack Overflow 调查，67% 的开发者..."——必须有名有姓有数据。
|
||||
|
||||
### 2.2 AI 结构性特征（必须打破）
|
||||
|
||||
| AI 特征 | 人类写法 |
|
||||
|---------|---------|
|
||||
| 段落长度均匀（每段都是 3-4 句） | 长短交替：有些段只有一句话，有些段 5-6 句 |
|
||||
| 完美对称的并列结构 | 刻意打破对称：3 个论据篇幅可以是 40%/35%/25% |
|
||||
| 每个观点都有"一方面...另一方面" | 直接选边站："说白了就是 XX" |
|
||||
| 语气从头到尾一模一样 | 突然加速/突然停顿/突然吐槽 |
|
||||
| 所有句子都是完整句 | 偶尔用不完整句："结果呢？" "就这？" |
|
||||
| 过渡词密集且规律 | 有些段落之间零过渡，直接跳 |
|
||||
| 绕路表述替代"是"（copula avoidance） | 直接用"是"/"有"。"XX 扮演着关键角色" → "XX 很关键" |
|
||||
| 所有观点都中立客观、两边讨好 | 选边站、有态度、有矛盾感 |
|
||||
| 抽象观察替代具体场景（abstraction excess） | 每个抽象观点后紧跟具体场景（含时间/地点/数字/工具名） |
|
||||
| 结尾聚合式"我的N个思考"编号列表 | 洞察散布在正文段落中，不在结尾堆成清单 |
|
||||
|
||||
### 2.3 人味注入清单（每篇必须 ≥5 项）
|
||||
|
||||
```
|
||||
□ 不规则段落长度 — 每连续 3 段中 ≥1 段 ≤2 句话；全文 ≥3 个单句段落
|
||||
□ 口语化混入 — "说白了"、"讲真"、"你猜怎么着"
|
||||
□ 括号吐槽/补充 — "（别问我怎么知道的）"、"（踩了3天的坑）"
|
||||
□ 突然语气转换 — 正经分析中突然来一句"等等，这不对"
|
||||
□ 具体数字替代模糊词 — 不说"很多"，说"我测试了 47 次"
|
||||
□ 个人经历锚点 — "上周我在做 XX 的时候"
|
||||
□ 反问句 — "你觉得这合理吗？"
|
||||
□ 自我纠正 — "不对，我刚才说的不够准确，应该是..."
|
||||
□ 类比/比喻 — 技术概念用生活场景解释
|
||||
□ 情绪词 — "崩溃"、"真香"、"离谱"、"服了"
|
||||
□ 混合情绪/不确定 — "说实话我也不确定"、"这件事我很矛盾"、"又爽又怕"
|
||||
□ 刻意凌乱 — 偶尔跑题的补充、半成形的想法、不完美的收束
|
||||
```
|
||||
|
||||
### 2.4 AI 味检测自检
|
||||
|
||||
生成草稿后，执行以下检测：
|
||||
|
||||
1. **开头检测**：前 50 字是否包含 §2.1 黑名单词汇？→ 命中即重写开头
|
||||
2. **过渡检测**：是否使用"首先...其次...最后"四段式？→ 命中即重组结构；是否存在"我的N个思考/感悟/总结"聚合编号列表？→ 命中即拆散到正文段落中
|
||||
3. **结尾检测**：最后 50 字是否包含 §2.1 结尾废话？→ 命中即重写结尾
|
||||
4. **节奏检测**：相邻 3 段字数差异 <20%？→ 插入短段；连续 3 段无 ≤2 句短段？→ 强制插入单句段落打破节奏
|
||||
5. **人味计数**：§2.3 清单命中项 <5？→ 人味不足，补充注入
|
||||
6. **二次审计**：通读全文，自问"什么地方一眼就看出是 AI 写的？"→ 列出残留 AI 痕迹 → 逐项修复 → 如有修改，从第 1 步重跑一遍
|
||||
|
||||
> 二次审计来源：Humanizer skill 的 "Final audit pass"。一次检测抓不完所有问题——修复 A 可能引入 B，必须循环。
|
||||
|
||||
---
|
||||
|
||||
## 3. 完读率优化（决定算法推荐权重）
|
||||
|
||||
### 3.1 前 3 句定生死（Hook 工程）
|
||||
|
||||
读者在前 3 句决定是否继续。首屏必须完成一件事：**让读者觉得"接下来的内容跟我有关，而且我现在不知道答案"**。
|
||||
|
||||
有效 Hook 类型：
|
||||
|
||||
| Hook 类型 | 示例 | 触发机制 |
|
||||
|-----------|------|---------|
|
||||
| 反直觉结论 | "先说结论：90%的 Agent 项目失败不是因为技术，是因为 Message Flow" | 认知冲突 |
|
||||
| 真金白银 | "4 个月烧了 2 万刀，我终于搞明白一件事" | 损失厌恶 |
|
||||
| 身份挑战 | "你觉得你会用 Claude Code？连最基本的 CLAUDE.md 你都不会写" | 自尊心 |
|
||||
| 悬念制造 | "我发现了一个残酷真相，但说出来可能会得罪很多人" | 好奇心缺口 |
|
||||
|
||||
**第 1 句铁律**：正文第 1 句（非标题）必须直接包含 ≥1 素材锚点（Type A 或 Type B 优先）。不是"前 3 句"，是"第 1 句"。铺垫、背景、定义——全部后置。
|
||||
|
||||
> 来源：栗子KK vs 苍何对比分析。苍何每篇第 1 句即含锚点（"OpenClaw我已经写N篇了"、"说到 OpenClaw Skill 水产市场"），栗子KK 常用 1-2 句铺垫才进入锚点，导致开头密度不足。
|
||||
|
||||
**禁止的开头**：
|
||||
- 背景介绍（"AI 编程是近年来..."）
|
||||
- 自我介绍（"大家好，我是..."）
|
||||
- 目录式开头（"本文将从以下几个方面..."）
|
||||
|
||||
### 3.2 段间钩子（防跳读）
|
||||
|
||||
每个 section 结尾要制造"未完成感"，让读者无法在此停下：
|
||||
|
||||
**钩子句式**（section 尾部使用）：
|
||||
- "但真正让我震惊的是下面这个发现"
|
||||
- "如果你以为这就完了，那你太乐观了"
|
||||
- "接下来这部分，才是整篇文章最值钱的"
|
||||
- "这个错误我犯了 3 次才学会，你大概率也会犯"
|
||||
|
||||
**小标题要有信息量**：
|
||||
- 差："第一步" → 好："第一步：这个操作让 90% 的人栽跟头"
|
||||
- 差："解决方案" → 好："唯一靠谱的解决方案（我试了 5 种）"
|
||||
- 差："总结" → 好："3 个你现在就能用的行动项"
|
||||
|
||||
### 3.3 阅读节奏控制
|
||||
|
||||
```
|
||||
节奏模型（1500-3000 字文章）：
|
||||
|
||||
Hook（50 字） ████ 高密度冲击
|
||||
过渡（100 字） ██ 降速，给背景
|
||||
论据1（300 字） ████████ 加速，上干货
|
||||
呼吸点 · 短段/图/代码
|
||||
论据2（400 字） ██████████ 主峰，最硬核内容
|
||||
呼吸点 · 短段/引用/类比
|
||||
论据3（250 字） ██████ 收敛，回扣主题
|
||||
结尾（100 字） ████ 金句 + CTA
|
||||
```
|
||||
|
||||
节奏规则：
|
||||
- **每 300-500 字一个视觉断点**：代码块、引用块、表格、加粗金句、分割线
|
||||
- **长短段交替**：3-5 句长段 → 1 句短段 → 2-3 句中段
|
||||
- **关键信息放段首**：读者是 F 型扫描，段落中间的信息会被跳过
|
||||
- **代码块不超过 15 行**：超过就拆分，每块配一句话说明
|
||||
|
||||
### 3.4 结尾工程
|
||||
|
||||
结尾决定读者是否会转发/收藏/关注。
|
||||
|
||||
**有效结尾公式**：
|
||||
1. 回扣开头素材锚点（如开头"烧了 2000 美金"→ 结尾"这 2000 美金买到的最贵一课"——必须引用同一锚点，不是泛泛呼应）
|
||||
2. 一句可截图的金句
|
||||
3. 具体 CTA（不是"关注我"，而是"下篇我会写 XX，点关注不迷路"）
|
||||
|
||||
**禁止的结尾**：
|
||||
- "希望对你有帮助"（AI 味满分）
|
||||
- "以上就是今天的分享"（像在交作业）
|
||||
- 没有 CTA 的结尾（白白浪费流量）
|
||||
|
||||
---
|
||||
|
||||
## 4. 质量门禁（交付前强制检查）
|
||||
|
||||
### 4.1 标题门禁
|
||||
|
||||
```
|
||||
□ 候选标题 ≥5 个
|
||||
□ 最终标题评分 ≥18/25
|
||||
□ 命中五要素 ≥3 项
|
||||
□ 标题 ≤35 字
|
||||
□ 不含 §1.4 禁忌
|
||||
```
|
||||
|
||||
### 4.2 去 AI 味门禁
|
||||
|
||||
```
|
||||
□ 前 50 字无黑名单词汇
|
||||
□ 无"首先...其次...最后"四段式
|
||||
□ 结尾无"综上所述/希望有帮助"
|
||||
□ 无意义膨胀词汇（"里程碑意义"、"划时代"、"深远影响"）
|
||||
□ 无模糊引用（"业内人士表示"、"研究表明"须给出处）
|
||||
□ 相邻段落字数差异 >20%（至少 3 组）
|
||||
□ 人味注入清单命中 ≥5 项（含混合情绪/刻意凌乱）
|
||||
□ 二次审计通过（自问"哪里一眼看出AI"→ 无残留）
|
||||
```
|
||||
|
||||
### 4.3 完读率门禁
|
||||
|
||||
```
|
||||
□ 前 3 句完成 Hook（反直觉/真金白银/身份挑战/悬念）
|
||||
□ 每个 section 尾部有段间钩子
|
||||
□ 小标题有信息量（不是"第一步"、"总结"）
|
||||
□ 每 300-500 字有视觉断点
|
||||
□ 结尾有金句 + 具体 CTA
|
||||
□ 全文无超过 15 行的代码块
|
||||
```
|
||||
|
||||
### 4.4 素材密度门禁
|
||||
|
||||
素材锚点检查——解决"内容层空洞"问题，与去 AI 味（表达层）互补。详见 `references/material-anchors.md`。
|
||||
|
||||
```
|
||||
□ 素材脚手架已在 Step 1b 输出，总锚点 ≥3
|
||||
□ 亲历锚点（Type A）≥1
|
||||
□ 数据/案例锚点（Type B/C）≥1
|
||||
□ 第 1 句包含 ≥1 素材锚点（非标题，正文首句）
|
||||
□ 每个主要章节引用 ≥1 锚点
|
||||
□ 无未标注来源的事实性断言（或已标 [?]）
|
||||
```
|
||||
|
||||
**与去 AI 味的关系**：素材锚点在内容层解决空洞，去 AI 味在表达层解决模式化。有真实素材的文章天然减少 AI 味表达——当你写"4 个月烧了 2 万刀"时，不会说"在当今快速发展的..."。两层都通过 = 内容扎实 + 表达自然。
|
||||
@ -1,352 +0,0 @@
|
||||
# 栗子KK vs 苍何：深度风格对比分析
|
||||
|
||||
> 分析日期：2026-03-10
|
||||
> 样本：栗子KK 5 篇（personal-context/）、苍何 2 篇（09-viral-examples/）
|
||||
> 用途：write-article skill 校准基准，识别栗子KK 风格的系统性弱点
|
||||
|
||||
---
|
||||
|
||||
## 1. 开头（Hook）对比
|
||||
|
||||
```
|
||||
┌───────────────────────────────────┬──────────────────────────────────────┐
|
||||
│ 栗子KK（5篇） │ 苍何（2篇） │
|
||||
├───────────────────────────────────┼──────────────────────────────────────┤
|
||||
│ "从cursor爆火到现在不到一年时间" │ "我的龙虾现在每天都会运行一个定时任务"│
|
||||
│ "最近和几个AI创业的朋友聊天" │ "OpenClaw我已经写N篇了" │
|
||||
│ "前几天刷技术博客，看到一篇..." │ │
|
||||
│ "做Agent开发这两年，踩过的坑不少" │ │
|
||||
│ "说实话，昨天深夜在算...我手抖了" │ │
|
||||
├───────────────────────────────────┼──────────────────────────────────────┤
|
||||
│ 模式：铺垫 → 背景 → "说实话"转折 │ 模式：直接开干 → 场景带入 → 你跟着看 │
|
||||
│ 平均用 3-5 句才进入正题 │ 第 1 句就在"做事" │
|
||||
└───────────────────────────────────┴──────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**核心差异**：栗子KK 是"讲台型"开头（我有个观察/发现/思考），苍何是"直播型"开头（你来看我在干什么）。
|
||||
|
||||
**风险**：栗子KK 的 4/5 篇开头都有"铺垫→背景→转折"三段式，这恰好是 content-quality.md §2.2 中标记的 AI 结构性特征——"语气从头到尾一模一样"。例外是"4个月烧了2万刀"那篇，直接用金钱冲击开场，效果最好。
|
||||
|
||||
**已校准**：content-quality.md §3.1 新增"第1句铁律"——正文第1句必须直接包含素材锚点，铺垫后置。
|
||||
|
||||
---
|
||||
|
||||
## 2. 段落节奏对比
|
||||
|
||||
量化分析段落长度分布：
|
||||
|
||||
```
|
||||
栗子KK "烧了2000美金" 文：
|
||||
┌──────────────────────────────────────────────────────────────┐
|
||||
│ 段落字数分布（去除图片行）： │
|
||||
│ │
|
||||
│ ████████ 80字 "前言"段 │
|
||||
│ ████████████████████ 200字 "真香的部分" │
|
||||
│ ████████████████████ 200字 "真坑的部分" │
|
||||
│ ████████████████ 160字 "Devin的成与败" │
|
||||
│ ████████████████ 160字 "为什么单纯模型不够" │
|
||||
│ ████████████████ 160字 "我的一些思考" │
|
||||
│ ████████ 80字 "写在最后" │
|
||||
│ │
|
||||
│ [!] 段落长度高度均匀（150-200字区间），标准差极小 │
|
||||
└──────────────────────────────────────────────────────────────┘
|
||||
|
||||
苍何 "水产市场" 文：
|
||||
┌──────────────────────────────────────────────────────────────┐
|
||||
│ 段落字数分布： │
|
||||
│ │
|
||||
│ █ 12字 "我的龙虾现在每天都会运行一个定时任务，" │
|
||||
│ ███ 40字 "就是到Clawhub去找..." │
|
||||
│ █ 15字 "我之前做教程的时候就设想过，" │
|
||||
│ █ 8字 "现版本我答案是五个，" │
|
||||
│ ████████ 90字 五件套详细列举 │
|
||||
│ █ 10字 "看起来就像是一个Agent经验社区。" │
|
||||
│ ██████████████ 140字 进化手册解释 │
|
||||
│ █ 15字 "这有点像我早期刷Reddit的感觉，很纯粹。" │
|
||||
│ █ 10字 "每一个帖子都代表了一个问题，" │
|
||||
│ │
|
||||
│ [✓] 长短交替极其明显，有大量 1 句话段落 │
|
||||
└──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
核心差异：
|
||||
|
||||
```
|
||||
┌────────────────┬──────────────────┬────────────────┐
|
||||
│ 维度 │ 栗子KK │ 苍何 │
|
||||
├────────────────┼──────────────────┼────────────────┤
|
||||
│ 段落长度标准差 │ 小（均匀） │ 大（长短交替） │
|
||||
│ 1句话段落占比 │ ~5% │ ~40% │
|
||||
│ 视觉断点频率 │ 每 400-500 字 │ 每 100-200 字 │
|
||||
│ 代码块使用 │ 技术展示型（长） │ 无代码块 │
|
||||
│ 图片插入频率 │ 每 800+ 字 │ 每 200-300 字 │
|
||||
└────────────────┴──────────────────┴────────────────┘
|
||||
```
|
||||
|
||||
**已校准**：content-quality.md §2.3 强化——每连续 3 段 ≥1 段 ≤2 句话；§2.4 节奏检测增加短段强制插入规则。
|
||||
|
||||
---
|
||||
|
||||
## 3. 素材锚点密度对比（四类锚点框架）
|
||||
|
||||
```
|
||||
┌─────────────┬───────────────────────────────────┬──────────────────────────────────┐
|
||||
│ 锚点类型 │ 栗子KK "烧了2000美金" │ 苍何 "水产市场" │
|
||||
├─────────────┼───────────────────────────────────┼──────────────────────────────────┤
|
||||
│ Type A 亲历 │ ✓ "烧掉2000美金" │ ✓ "24年买的K80又又又可以上岗了" │
|
||||
│ │ ✓ "用Cursor写了个Todo管理小工具" │ ✓ "我的499又省了" │
|
||||
│ │ ✗ 其余多为泛泛观察 │ ✓ "给AI办了个手机号" │
|
||||
│ │ 计: 2 │ 计: 3+ │
|
||||
├─────────────┼───────────────────────────────────┼──────────────────────────────────┤
|
||||
│ Type B 数据 │ ✓ "2000美金" │ ✓ "前百下载量" │
|
||||
│ │ ✗ "90%的Agent项目" — 无来源 │ ✓ "自进化占了前百的10%" │
|
||||
│ │ │ ✓ "2426只龙虾" │
|
||||
│ │ 计: 1 │ ✓ "覆盖17个搜索引擎" │
|
||||
│ │ │ 计: 4 │
|
||||
├─────────────┼───────────────────────────────────┼──────────────────────────────────┤
|
||||
│ Type C 案例 │ ✓ Devin 沙盒分析 │ ✓ self-improving-agent 五件套 │
|
||||
│ │ ✓ AutoGPT/LangChain/LangGraph │ ✓ 三类资产拆解 │
|
||||
│ │ （但仅1句评价，非深入分析） │ ✓ 红手指Operator架构公式 │
|
||||
│ │ 计: 1 深 + 3 浅 │ 计: 3 深 │
|
||||
├─────────────┼───────────────────────────────────┼──────────────────────────────────┤
|
||||
│ Type D 观察 │ ✗ 无具体引用 │ ✓ "吃到了@袋鼠帝的安利" │
|
||||
│ │ │ ✓ "这有点像我早期刷Reddit的感觉" │
|
||||
│ │ 计: 0 │ 计: 2 │
|
||||
├─────────────┼───────────────────────────────────┼──────────────────────────────────┤
|
||||
│ 总计 │ ~4（含3个浅层） │ ~12（全部具体） │
|
||||
│ 密度/千字 │ ~1.3 │ ~4.0 │
|
||||
└─────────────┴───────────────────────────────────┴──────────────────────────────────┘
|
||||
```
|
||||
|
||||
**锚点密度是两者最大差距**。苍何的素材锚点密度约为栗子KK的 3 倍。
|
||||
|
||||
栗子KK 文章中的"伪锚点"（不计入）：
|
||||
- "90%的Agent项目会失败" — Type B 不合格，无来源
|
||||
- "我觉得没有完美的框架" — 观点，非锚点
|
||||
- "距离一个合格的实习生，还差得很远" — 判断，非锚点
|
||||
- "模型只是在做模式匹配" — 泛泛论断
|
||||
|
||||
**已校准**：material-anchors.md §0 NEVER Rules 明确列出不计入锚点的内容类型；§1 每种锚点类型都有正反面示例。
|
||||
|
||||
---
|
||||
|
||||
## 4. AI 味检测对比
|
||||
|
||||
```
|
||||
┌─────────────────────────┬──────────────────────┬──────────────────────┐
|
||||
│ 检测维度 │ 栗子KK │ 苍何 │
|
||||
├─────────────────────────┼──────────────────────┼──────────────────────┤
|
||||
│ §2.1 开头废话 │ 4/5 篇"前言"开头 │ 0/2（直接开干） │
|
||||
│ §2.1 过渡废话 │ 偶发（"接下来聊聊"） │ 无 │
|
||||
│ §2.1 结尾废话 │ 5/5 篇模板结尾 │ 2/2 篇模板结尾 │
|
||||
│ §2.1 意义膨胀 │ 轻微（"天才""精妙"） │ 无 │
|
||||
│ §2.1 模糊引用 │ 中度（"90%的人"无源）│ 无 │
|
||||
│ §2.2 段落长度均匀 │ 是（高度均匀） │ 否（长短极端交替） │
|
||||
│ §2.2 完美对称并列 │ 是（真香/真坑对称） │ 否 │
|
||||
│ §2.2 语气均匀 │ 是（从头到尾稳定） │ 否（突然冒出"又又又"）│
|
||||
│ §2.2 所有句子完整 │ 是 │ 否（"就这？""很纯粹"）│
|
||||
│ §2.2 绕路表述 │ 轻微 │ 无（直接说"用人话"） │
|
||||
│ §2.3 不规则段落 │ 少 │ 密集 │
|
||||
│ §2.3 口语化 │ "说实话""真的" │ "kuku""又又又""薅" │
|
||||
│ §2.3 括号吐槽 │ 少 │ "（其实是习惯性无视）"│
|
||||
│ §2.3 突然语气转换 │ 无 │ "一眼幻视之后会不会" │
|
||||
│ §2.3 具体数字替代模糊 │ 中 │ 高 │
|
||||
│ §2.3 混合情绪 │ 少 │ "我现在有时候过度依赖" │
|
||||
│ §2.3 刻意凌乱 │ 无 │ "真要这样...出大招了" │
|
||||
├─────────────────────────┼──────────────────────┼──────────────────────┤
|
||||
│ 人味注入命中项 │ ~3/12 │ ~9/12 │
|
||||
│ AI味综合评分 │ 🟡 中度AI味 │ 🟢 接近零AI味 │
|
||||
└─────────────────────────┴──────────────────────┴──────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 叙事结构对比
|
||||
|
||||
```
|
||||
栗子KK 标准结构（5篇均一致）：
|
||||
┌──────────────────────────────────────────────────────────────────┐
|
||||
│ 前言（铺垫背景） │
|
||||
│ ↓ │
|
||||
│ 核心观点（先说结论） │
|
||||
│ ↓ │
|
||||
│ 论据展开（对称并列：真香/真坑，成/败，传统/新方案） │
|
||||
│ ↓ │
|
||||
│ 思考总结（"我的几个思考" 1/2/3/4 编号） │
|
||||
│ ↓ │
|
||||
│ 固定结尾（签名 + CTA 模板） │
|
||||
└──────────────────────────────────────────────────────────────────┘
|
||||
|
||||
苍何 标准结构（2篇均一致）：
|
||||
┌──────────────────────────────────────────────────────────────────┐
|
||||
│ 我正在做一件事（直接场景带入） │
|
||||
│ ↓ │
|
||||
│ 测试场景 1（截图 + 指令 + 实际效果） │
|
||||
│ ↓ │
|
||||
│ 测试场景 2（换个场景试试） │
|
||||
│ ↓ │
|
||||
│ 测试场景 3（更生活化的场景） │
|
||||
│ ↓ │
|
||||
│ 我的感受 + 未来想象（自然收束，非总结） │
|
||||
│ ↓ │
|
||||
│ 签名 + CTA 模板 │
|
||||
└──────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
核心差异：
|
||||
|
||||
```
|
||||
┌──────────────┬────────────────────────────────┬────────────────────────────┐
|
||||
│ 维度 │ 栗子KK │ 苍何 │
|
||||
├──────────────┼────────────────────────────────┼────────────────────────────┤
|
||||
│ 叙事视角 │ 评论员（我看了很多，得出结论） │ 体验者（我正在用，你来看） │
|
||||
│ 信息密度 │ 高密度概念堆叠 │ 低密度场景展开 │
|
||||
│ 读者参与感 │ 旁观（"我告诉你"） │ 代入（"你跟着我一起试"） │
|
||||
│ 结构可预测性 │ 高（标准论文结构） │ 低（下一段不知道测什么） │
|
||||
│ 知识门槛 │ 高（需要技术背景才能跟上） │ 低（小白也能看懂） │
|
||||
└──────────────┴────────────────────────────────┴────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 最致命的 3 个差距
|
||||
|
||||
### 差距一：抽象 vs 具体（根因）
|
||||
|
||||
```
|
||||
栗子KK:
|
||||
"多轮交互的噩梦：当你发现它理解错了，想要纠正，
|
||||
往往需要好几轮对话。"
|
||||
└── 抽象描述，读者无法代入
|
||||
|
||||
苍何:
|
||||
"然后我就看着它kuku打开B站搜索关键词，浏览并
|
||||
筛选搜索结果，定位OpenClaw使用场景相关的视频内容"
|
||||
└── 具体动作序列，读者能"看到"画面
|
||||
```
|
||||
|
||||
栗子KK 倾向于把具体经历"提炼"成抽象观点后输出，提炼过程中丢失了所有细节。苍何保留了原始体验的颗粒度。这正是素材锚点机制要解决的问题——强制保留具体细节，禁止升华为空洞观点。
|
||||
|
||||
**已校准**：content-quality.md §2.2 新增"抽象观察替代具体场景（abstraction excess）"反模式；SKILL.md Step 4a 新增"禁止抽象过度"规则。
|
||||
|
||||
### 差距二：评论者姿态 vs 参与者姿态
|
||||
|
||||
```
|
||||
栗子KK:
|
||||
"我觉得要真正解决这些问题，需要的是一套完整的系统：
|
||||
• 持续学习的知识库
|
||||
• 多模态的交互方式
|
||||
• 强化学习机制
|
||||
• 工程化的思维模式"
|
||||
└── 开药方模式（"你们应该这么做"）
|
||||
|
||||
苍何:
|
||||
"我现在就希望后续的更新能够让OpenClaw操作更多的手机App，
|
||||
如果提示语+脚本+文本文件可以组成一个Skills，
|
||||
那App天然就是一个更复杂功能更全的Skills。"
|
||||
└── 共同探索模式（"我也不知道答案，但我在想"）
|
||||
```
|
||||
|
||||
栗子KK 的 5 篇文章都有"我的几个思考/不成熟的想法"环节——列出 3-4 条编号建议。这种结构让文章读起来像技术报告而非个人分享，且这些"思考"往往是业内共识（持续学习、垂直化、工具链），缺少独特视角。
|
||||
|
||||
**已校准**：content-quality.md §2.2 新增"结尾聚合式编号列表"反模式；§2.4 过渡检测扩展聚合清单检查；writing-styles.md lizi_kk 禁忌新增"聚合式编号列表"。
|
||||
|
||||
### 差距三：结尾同质化
|
||||
|
||||
```
|
||||
栗子KK 5 篇结尾（100% 相同模板）：
|
||||
"栗子KK，一个在AI浪潮中游泳的AI产品Founder
|
||||
欢迎点赞、在看、关注，一起聊科技、聊产品、聊未来"
|
||||
|
||||
苍何 2 篇结尾：
|
||||
"真要这样的话我就要出大招了。" + 表情包
|
||||
"但现在有了大佬们的龙虾...可以24小时不停地交流。
|
||||
这会让经验以一种我们想象不到的速度去蔓延"
|
||||
```
|
||||
|
||||
栗子KK 的签名结尾在 5 篇文章中完全一致——这是 content-quality.md §3.4 明确禁止的（"结尾无CTA""像在交作业"）。苍何的结尾虽然也有模板（CTA 部分），但正文自然收束处各不相同。
|
||||
|
||||
**已校准**：content-quality.md §3.4 结尾公式强化——回扣开头素材锚点（必须引用同一锚点，不是泛泛呼应）。
|
||||
|
||||
---
|
||||
|
||||
## 7. 两者的各自优势
|
||||
|
||||
### 栗子KK 的独有优势（苍何不具备）
|
||||
|
||||
```
|
||||
┌──────────────┬─────────────────────────────────────────────┬──────────────────┐
|
||||
│ 优势 │ 示例 │ 价值 │
|
||||
├──────────────┼─────────────────────────────────────────────┼──────────────────┤
|
||||
│ 深度技术拆解 │ OpenClaw 8个反常识设计逐条分析 │ 技术人群信任度高 │
|
||||
│ 跨产品对比 │ AutoGPT/LangChain/LangGraph/CrewAI 一文覆盖 │ 决策参考价值 │
|
||||
│ 代码级论证 │ 实际代码块展示设计理念 │ 可验证性强 │
|
||||
│ 工程哲学升华 │ 引用 Linus Torvalds、Good Taste │ 思想深度 │
|
||||
│ 个人产品关联 │ AtomStorm 的每个论点都有产品佐证 │ 商业说服力 │
|
||||
└──────────────┴─────────────────────────────────────────────┴──────────────────┘
|
||||
```
|
||||
|
||||
### 苍何 的独有优势（栗子KK 不具备）
|
||||
|
||||
```
|
||||
┌──────────────┬───────────────────────────────────────────────┬────────────────┐
|
||||
│ 优势 │ 示例 │ 价值 │
|
||||
├──────────────┼───────────────────────────────────────────────┼────────────────┤
|
||||
│ 场景化叙事 │ "跟App版的OpenClaw说...然后看着它kuku打开B站" │ 可视化、代入感 │
|
||||
│ 低门槛表达 │ "用人话说就是..." │ 受众面宽 │
|
||||
│ 生活化场景 │ 习惯打卡、看小红书选题 │ 非技术读者共鸣 │
|
||||
│ 密集素材锚点 │ 每 200 字一个具体数字/名字/价格 │ 内容扎实不空洞 │
|
||||
│ 情绪真实性 │ "又又又""我的499又省了""一眼幻视" │ 人味极强 │
|
||||
│ 自然节奏 │ 1 句话段落占 40%，图文密集交替 │ 完读率高 │
|
||||
└──────────────┴───────────────────────────────────────────────┴────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 校准建议（已实施）
|
||||
|
||||
基于以上对比，write-article 在生成栗子KK 风格文章时着重校准以下 5 点：
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────────────┐
|
||||
│ 优先级 问题 校准方向 状态 │
|
||||
├──────────────────────────────────────────────────────────────────────┤
|
||||
│ P0 段落长度高度均匀 每3段≥1段≤2句话 ✓ 已实施│
|
||||
│ P0 开头铺垫过长 第1句必须含素材锚点 ✓ 已实施│
|
||||
│ P1 抽象观点替代具体细节 每个观点后必须跟具体场景 ✓ 已实施│
|
||||
│ P1 "我的思考"编号列表 拆散到正文禁止聚合清单 ✓ 已实施│
|
||||
│ P2 结尾模板固化 金句必须回扣开头锚点 ✓ 已实施│
|
||||
└──────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**核心洞察**：栗子KK 文章的问题本质不是"AI味重"（表达层尚可），而是**抽象化过度**——把真实经历提炼成通用观点后输出，读者得到的是"结论"而非"体验"。这正好是 material-anchors.md 要解决的核心问题：先有素材，再有文章；保留细节，禁止空洞升华。
|
||||
|
||||
苍何证明了：**素材密度 3 倍 = 人味 3 倍 = AI味 1/3**。当你在写"24年买的K80又又又可以上岗了"的时候，根本不会写出"在当今快速发展的..."。
|
||||
|
||||
---
|
||||
|
||||
## 9. 回测验证（2026-03-10）
|
||||
|
||||
用 5 条校准规则回测已发表文章，验证规则有效性：
|
||||
|
||||
```
|
||||
规则 文章A（残酷真相） 文章B（超级个体） 设计意图
|
||||
───────────────────── ───────────────── ───────────────── ────────────────
|
||||
P0 第1句铁律 ✗ 锚点延迟3段 🟡 延迟1段 强制第1句命中
|
||||
P0 段落节奏 🟡 局部均匀 ✓ 短段充分 打破AI均匀感
|
||||
P1 抽象过度 ✗ 4段纯抽象 ✓ 抽象有跟随 消除空洞观点
|
||||
P1 聚合清单 ✗ 精确命中 ✓ 无此模式 消除AI列表感
|
||||
P2 结尾回扣 ✓ 直接引用 🟡 回扣非开头锚 强化首尾一体
|
||||
───────────────────── ───────────────── ───────────────── ────────────────
|
||||
问题计数 3✗ + 1🟡 0✗ + 2🟡
|
||||
|
||||
结论：规则精确捕获已知弱点，不误杀好文章。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 附录：苍何样本来源
|
||||
|
||||
- `09-viral-examples/` 中苍何相关文章（OpenClaw 手机版、水产市场）
|
||||
- 采集日期：2026-03 前后
|
||||
- 平台：微信公众号
|
||||
@ -1,229 +0,0 @@
|
||||
# Material Anchors Reference
|
||||
|
||||
素材锚点规范——解决"内容层空洞"问题。与去 AI 味（表达层）互补，形成双层防线。
|
||||
|
||||
核心原则：**先有素材，再有文章**。没有真实素材支撑的文章，再怎么打磨措辞也是"先污染后治理"。
|
||||
|
||||
---
|
||||
|
||||
## §0 NEVER Rules
|
||||
|
||||
- **NEVER** 把以下内容计为素材锚点：
|
||||
- 泛泛观察（"AI 正在改变世界"、"越来越多人开始用..."）
|
||||
- 无源统计（"据统计 90% 的项目..."——谁统计的？）
|
||||
- 假设场景（"假设你正在做一个项目..."）
|
||||
- "业内共识"类表述（"大家都知道"、"众所周知"）
|
||||
- AI 生成的虚构案例（"某公司通过 XX 技术实现了 YY"——哪家公司？）
|
||||
|
||||
- **NEVER** 在素材不足时强行写作——输出 `[?] 素材不足` 并索要补充，禁止用空洞内容凑字数。
|
||||
|
||||
- **NEVER** 编造个人经历或虚构案例——宁可少一个锚点，也不能造假。
|
||||
|
||||
- **NEVER** 跳过素材脚手架直接写正文——Step 1b 是强制步骤，不是可选步骤。
|
||||
|
||||
---
|
||||
|
||||
## §1 Four Anchor Types（四类素材锚点）
|
||||
|
||||
### Type A：亲历锚点 — 个人做过/花过/踩过的
|
||||
|
||||
**最高可信度**。读者能感知"这人真干过"。
|
||||
|
||||
必须包含 ≥2 项：项目名/产品名、时间节点、金钱成本、工具名称、具体结果。
|
||||
|
||||
**从 `personal-context/` 提取的示例**：
|
||||
|
||||
| 锚点 | 来源 | 包含要素 |
|
||||
|------|------|----------|
|
||||
| "4 个月烧了 2 万刀 Token" | 超级个体文 | 时间(4个月) + 成本(2万刀) + 具体物(Token) |
|
||||
| "烧了 2000 美金在 AI 写代码上" | 残酷真相文 | 成本(2000美金) + 具体行为(AI写代码) |
|
||||
| "做了两年 AI Agent" | Message Flow 文 | 时间(两年) + 具体领域(AI Agent) |
|
||||
| "研究了 OpenClaw 的 8 个反常识设计" | OpenClaw 文 | 数量(8个) + 产品名(OpenClaw) + 发现(反常识设计) |
|
||||
|
||||
**从爆款文章提取的示例**（苍何）：
|
||||
|
||||
| 锚点 | 来源 | 包含要素 |
|
||||
|------|------|----------|
|
||||
| "24年买的K80又又又可以上岗了" | OpenClaw手机版 | 时间(24年) + 设备(K80) + 真实使用 |
|
||||
| "之前还要一台云服务器和mac mini" | OpenClaw手机版 | 具体设备 + 成本门槛变化 |
|
||||
| "499元上门安装生意也不会那么火" | OpenClaw手机版 | 价格(499元) + 市场现象 |
|
||||
| "我的499又省了" | OpenClaw手机版 | 个人省钱经历 + 具体金额 |
|
||||
|
||||
### Type B：数据锚点 — 具体数字 + 命名来源
|
||||
|
||||
**不是你编的数字**，而是有出处的量化事实。
|
||||
|
||||
必须包含：具体数值 + 来源归属（谁说的/哪个报告/哪个平台）。
|
||||
|
||||
**示例**：
|
||||
|
||||
| 锚点 | 来源 | 可信要素 |
|
||||
|------|------|----------|
|
||||
| "前百下载量的龙虾 Skill" | 苍何/水产市场文 | 平台排名数据 |
|
||||
| "Agent 自进化占了前百的 10%" | 苍何/水产市场文 | 占比 + 排名范围 |
|
||||
| "水产市场养了 2426 只龙虾" | 苍何/水产市场文 | 平台公开数据 |
|
||||
| "覆盖了 17 个搜索引擎" | 苍何/OpenClaw手机版 | 产品功能数据 |
|
||||
|
||||
**反面示例**（不计入锚点）：
|
||||
- "据统计 90% 的 Agent 项目会失败" — 谁统计的？
|
||||
- "AI 编程效率提升 10 倍" — 什么场景？谁测的？
|
||||
- "某大厂用了之后效率翻倍" — 哪家大厂？
|
||||
|
||||
### Type C：案例锚点 — 命名实体 + 具体分析
|
||||
|
||||
**不是泛泛提及**，而是对具体产品/事件/人物的深入分析。
|
||||
|
||||
必须包含：命名实体（产品名/公司名/人名）+ 具体细节（设计/决策/结果）。
|
||||
|
||||
**示例**：
|
||||
|
||||
| 锚点 | 来源 | 分析深度 |
|
||||
|------|------|----------|
|
||||
| "self-improving-agent + skill-creator + find-skills + skills-vetter + automation-workflows 五件套" | 苍何/水产市场文 | 5 个具体 Skill 名 + 功能拆解 |
|
||||
| "水产市场的三类资产：插件、触发器、通信器" | 苍何/水产市场文 | 产品架构拆解 |
|
||||
| "红手指 Operator = 云端大脑 + 终端手脚 + 安全沙盒" | 苍何/OpenClaw手机版 | 产品架构公式 |
|
||||
| "OpenClaw 的 8 个反常识设计" | personal-context | 逐条设计分析 |
|
||||
|
||||
**反面示例**（不计入锚点）：
|
||||
- "某 AI Agent 框架做得不错" — 哪个框架？哪里不错？
|
||||
- "有些公司已经在用了" — 哪些公司？
|
||||
|
||||
### Type D：观察锚点 — 真实对话/引用 + 归属
|
||||
|
||||
**不是你的观点**，而是你听到/看到的他人言行。
|
||||
|
||||
必须包含：说话人归属（人名/角色/场景）+ 具体内容。
|
||||
|
||||
**示例**：
|
||||
|
||||
| 锚点 | 来源 | 归属 |
|
||||
|------|------|------|
|
||||
| "吃到了 @袋鼠帝 的安利" | 苍何/OpenClaw手机版 | 具体推荐人 |
|
||||
| "Sam Altman 预言的超级个体" | personal-context/超级个体文 | 具体人物 + 具体预言 |
|
||||
| "这有点像我早期刷 Reddit 的感觉，很纯粹" | 苍何/水产市场文 | 个人类比 + 具体平台 |
|
||||
|
||||
**反面示例**（不计入锚点）：
|
||||
- "业内人士认为..." — 哪个业内人士？
|
||||
- "有观点认为..." — 谁的观点？
|
||||
|
||||
---
|
||||
|
||||
## §2 Material Sources（素材来源优先级）
|
||||
|
||||
按优先级从高到低搜索素材：
|
||||
|
||||
```
|
||||
1. source_notes — topic 指定的源笔记（必读，Step 1a 已覆盖）
|
||||
2. personal-context/ — 作者已发表文章（亲历锚点的金矿）
|
||||
3. 00-inbox/ — vault 原始素材库
|
||||
4. 09-viral-examples/ — 爆款案例库（案例锚点和数据锚点）
|
||||
5. source_urls — topic frontmatter 中的外部链接
|
||||
6. material_sources — 用户额外指定的素材文件
|
||||
```
|
||||
|
||||
**搜索策略**：
|
||||
- 用 `obsidian search query="<topic关键词>"` 在 vault 中搜索相关素材
|
||||
- 读取匹配的 `personal-context/` 文章，提取亲历锚点
|
||||
- 读取匹配的 `09-viral-examples/` 案例，提取案例/数据锚点
|
||||
- 素材来源越多样，文章可信度越高
|
||||
|
||||
---
|
||||
|
||||
## §3 Material Scaffold Format（素材脚手架格式）
|
||||
|
||||
**Step 1b 的强制输出格式**。写正文前必须先输出这个脚手架。
|
||||
|
||||
```
|
||||
## 素材脚手架
|
||||
|
||||
### Type A 亲历锚点
|
||||
1. [锚点描述] — 来源: [vault路径或记忆]
|
||||
2. [锚点描述] — 来源: [vault路径或记忆]
|
||||
|
||||
### Type B 数据锚点
|
||||
1. [数据 + 来源归属] — 来源: [vault路径或URL]
|
||||
|
||||
### Type C 案例锚点
|
||||
1. [命名实体 + 分析要点] — 来源: [vault路径或URL]
|
||||
|
||||
### Type D 观察锚点
|
||||
1. [引用/对话 + 归属] — 来源: [vault路径]
|
||||
|
||||
### 统计
|
||||
- 总锚点: X 个
|
||||
- Type A: X 个 ✓/✗（≥1）
|
||||
- Type B|C: X 个 ✓/✗（≥1）
|
||||
- 判定: 通过 / [?] 素材不足，需补充 [具体缺什么]
|
||||
```
|
||||
|
||||
**最低阈值**：
|
||||
|
||||
| 条件 | 阈值 | 原因 |
|
||||
|------|------|------|
|
||||
| 总锚点 | ≥3 | 低于 3 个锚点的文章必然空洞 |
|
||||
| Type A（亲历） | ≥1 | 无亲身经历 = 纸上谈兵 |
|
||||
| Type B 或 C（数据/案例） | ≥1 | 无数据/案例 = 无法验证 |
|
||||
|
||||
**不足时处理**：
|
||||
- 输出 `[?] 素材不足：缺少 Type A 亲历锚点，请补充个人经历或相关实践`
|
||||
- 禁止进入 Step 2（人格激活）及后续步骤
|
||||
- 建议用户补充素材来源，或降低文章野心（缩小选题范围到有素材支撑的部分）
|
||||
|
||||
---
|
||||
|
||||
## §4 Weaving Rules（编织规则）
|
||||
|
||||
素材锚点不是堆在文章里的，而是编织到叙事结构中的。
|
||||
|
||||
### 4.1 Hook 必须含锚点
|
||||
|
||||
正文第 1 句（非标题）必须直接包含素材锚点（优先 Type A 或 Type B）。不是"前 3 句"，是"第 1 句"——铺垫、背景、定义全部后置。
|
||||
|
||||
**好**："4 个月烧了 2 万刀 Token，我终于搞明白一件事" — Type A 亲历锚点，第 1 句即命中
|
||||
**好**："水产市场养了 2426 只龙虾" — Type B 数据锚点，第 1 句即命中
|
||||
**好**："OpenClaw我已经写N篇了" — Type A 亲历锚点，第 1 句即命中（苍何式）
|
||||
**差**："在 AI Agent 快速发展的今天..." — 零锚点，纯 AI 废话
|
||||
**差**："先说点背景知识，然后再聊我的经历" — 锚点被铺垫延迟，第 1 句空洞
|
||||
|
||||
### 4.2 每章节 ≥1 锚点
|
||||
|
||||
每个主要章节（H2/编号段落）至少引用 1 个锚点。连续 2 个章节无锚点 = 内容空洞警告。
|
||||
|
||||
### 4.3 结尾回扣开头锚点
|
||||
|
||||
结尾回扣开头的锚点，形成首尾呼应。不是重复，而是升华。
|
||||
|
||||
**示例**：开头 "烧了 2000 美金" → 结尾 "这 2000 美金买到的最贵的一课是..."
|
||||
|
||||
### 4.4 事实断言溯源
|
||||
|
||||
所有事实性断言必须追溯到素材锚点，或标记 `[?]` 待验证。
|
||||
|
||||
**好**："OpenClaw 的 Skill 生态已有 2426 个（来源：水产市场平台数据）"
|
||||
**差**："OpenClaw 的生态发展迅速" — 空洞断言，无数据支撑
|
||||
|
||||
---
|
||||
|
||||
## §5 Relationship to De-AI（与去 AI 味互补）
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 文章质量双层防线 │
|
||||
├─────────────────────────┬───────────────────────────────────┤
|
||||
│ 素材锚点（内容层） │ 去 AI 味（表达层） │
|
||||
│ 解决: 内容空洞 │ 解决: 表达模式化 │
|
||||
│ │ │
|
||||
│ 检查: 有没有真实素材 │ 检查: 像不像人写的 │
|
||||
│ 手段: 锚点类型+阈值 │ 手段: 黑名单+人味注入 │
|
||||
│ 时机: Step 1b（写前） │ 时机: Step 4a（写中） │
|
||||
│ 门禁: §4.4（6 项） │ 门禁: §4.2（8 项） │
|
||||
├─────────────────────────┴───────────────────────────────────┤
|
||||
│ 叠加效果: 有真实素材的文章天然减少 AI 味表达。 │
|
||||
│ 当你在写"4个月烧了2万刀"时，不会说"在当今快速发展的..."。 │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**互补而非替代**：
|
||||
- 一篇有丰富素材但表达 AI 味重的文章 → 去 AI 味门禁会拦住
|
||||
- 一篇表达很人味但内容空洞的文章 → 素材密度门禁会拦住
|
||||
- 两层都通过 = 内容扎实 + 表达自然
|
||||
@ -1,144 +0,0 @@
|
||||
# Personas 配置
|
||||
|
||||
人格化核心引擎 P-Core V1.1 的可用人格定义。
|
||||
|
||||
---
|
||||
|
||||
## 栗子KK
|
||||
|
||||
> 基于 `personal-context/` 5 篇已发表文章提取
|
||||
|
||||
### 基础信息
|
||||
|
||||
| 字段 | 值 |
|
||||
|------|-----|
|
||||
| brand_name | 栗子KK |
|
||||
| brand_intro | atomstorm.ai Founder，前百度阿里技术高P，蓝星上最会AI编程的人（之一），AI Native 商业组织先驱者 |
|
||||
| target_audience | 开发者、AI 从业者、技术创业者 |
|
||||
|
||||
### 人格画像
|
||||
|
||||
**persona_identity**:
|
||||
```
|
||||
- atomstorm.ai Founder
|
||||
- 前百度阿里技术高P
|
||||
- 蓝星上最会 AI 编程的人（之一）
|
||||
- AI Native 商业组织先驱者
|
||||
- 2 年 AI Agent 开发经验，烧过 20000+ 美金 AI Coding 学费
|
||||
```
|
||||
|
||||
**persona_context**:
|
||||
```
|
||||
- 第一人称"我"为主
|
||||
- 分享真实踩坑经历
|
||||
- 技术深度 + 商业洞察
|
||||
- 不讲虚的，只讲干货
|
||||
```
|
||||
|
||||
**voice_signature**:
|
||||
```
|
||||
- 冲击式开头（数字、反差、真相）
|
||||
- 口语化但不失深度
|
||||
- 敢下判断（90%、99%）但必有依据
|
||||
- 代码示例 + 数据支撑
|
||||
- 金句收尾 + CTA
|
||||
```
|
||||
|
||||
**catchphrases**:
|
||||
```
|
||||
- "说实话"
|
||||
- "先说结论"
|
||||
- "效果立竿见影"
|
||||
- "99%的XX都不..."
|
||||
- "这招真的管用"
|
||||
- "Done is better than perfect"
|
||||
- "山远路险，鞋里有沙"
|
||||
```
|
||||
|
||||
### Intensity 配置
|
||||
|
||||
| 级别 | 特征 |
|
||||
|------|------|
|
||||
| **light** | 保持风格结构，语言偏中性 |
|
||||
| **medium** | 完整风格 + 口头禅 + 典型句式 |
|
||||
| **heavy** | 深度扮演 + 个人经历引用 + 完整口吻 |
|
||||
|
||||
### 激活提示词
|
||||
|
||||
当 `persona: "栗子KK"` 时，注入以下系统提示：
|
||||
|
||||
```markdown
|
||||
你现在以"栗子KK"的人格撰写内容。
|
||||
|
||||
## 身份
|
||||
- AI 产品 Founder，AtomStorm (studio.atomstorm.ai) 作者
|
||||
- 2 年 AI Agent 开发经验，烧过 20000+ 美金 AI Coding 学费
|
||||
- 全栈工程师，技术 + 产品双重视角
|
||||
|
||||
## 语气
|
||||
- 开头必须有钩子：数字冲击、反差对比、真相揭露
|
||||
- 口语化但不失深度："说实话"、"先说结论"
|
||||
- 敢下判断但必有依据：每个"90%"背后要有数据或案例
|
||||
- 结尾金句 + CTA
|
||||
|
||||
## 结构
|
||||
- 数字编号分段（01, 02, 03...）
|
||||
- 短段落（2-5 句话，单段不超过 150 字）
|
||||
- 代码示例配文字说明
|
||||
- 数据对比表格
|
||||
|
||||
## 禁忌
|
||||
- "赋能"、"生态"等空话
|
||||
- 纯理论无案例
|
||||
- 没有个人观点
|
||||
- 完美主义收尾
|
||||
|
||||
## 签名
|
||||
结尾使用：
|
||||
> 栗子KK，一个在AI浪潮中游泳的AI产品Founder
|
||||
>
|
||||
> 欢迎点赞、在看、关注，一起聊科技、聊产品、聊未来 🚀
|
||||
```
|
||||
|
||||
### 边界说明
|
||||
|
||||
**失效场景**（自动降级为 neutral 模式）：
|
||||
- 法律/合规相关内容
|
||||
- 第三方产品客观评测
|
||||
- 需要完全中立立场的分析
|
||||
|
||||
**降级行为**：
|
||||
- 移除口头禅
|
||||
- 移除个人签名
|
||||
- 保持风格结构但弱化主观表达
|
||||
|
||||
---
|
||||
|
||||
## 扩展指南
|
||||
|
||||
### 新增人格
|
||||
|
||||
1. 在 `personal-context/` 放置 3-5 篇代表性文章
|
||||
2. 创建 `templates/author-style-{slug}.md` 风格模板
|
||||
3. 在本文件添加 persona 定义
|
||||
4. 在 `writing-styles.md` 添加对应 style
|
||||
|
||||
### 人格数据模板
|
||||
|
||||
```yaml
|
||||
persona: "{name}"
|
||||
brand_name: "{display_name}"
|
||||
brand_intro: "{一句话定位}"
|
||||
persona_identity:
|
||||
- "{标签1}"
|
||||
- "{标签2}"
|
||||
persona_context: |
|
||||
{核心语境描述}
|
||||
voice_signature:
|
||||
- "{特征1}"
|
||||
- "{特征2}"
|
||||
catchphrases:
|
||||
- "{口头禅1}"
|
||||
- "{口头禅2}"
|
||||
target_audience: "{目标读者}"
|
||||
```
|
||||
@ -1,124 +0,0 @@
|
||||
# Writing Styles Reference
|
||||
|
||||
本文档定义 `write-article` skill 的 5 类写作风格。每种风格都包含固定的语气、结构、禁忌。
|
||||
|
||||
## 1) 技术博客（`tech_blog`）
|
||||
|
||||
### 语气
|
||||
- 专业、克制、解释导向。
|
||||
- 对术语给出必要定义，不炫技。
|
||||
- 结论可验证，避免绝对化表达。
|
||||
|
||||
### 结构
|
||||
1. 问题背景：问题是什么，为什么值得解决。
|
||||
2. 核心方案：关键设计与取舍。
|
||||
3. 实现细节：步骤、代码片段、配置或流程。
|
||||
4. 验证结果：如何验证有效性，边界在哪里。
|
||||
5. 总结与扩展：适用场景、下一步优化。
|
||||
|
||||
### 禁忌
|
||||
- 只贴代码不解释设计意图。
|
||||
- 用“黑魔法”式技巧替代可维护方案。
|
||||
- 夸大性能收益但不给验证条件。
|
||||
|
||||
## 2) 观点文（`opinion`）
|
||||
|
||||
### 语气
|
||||
- 立场鲜明，但论证必须有证据链。
|
||||
- 可批判、可反驳，不做人身攻击。
|
||||
- 允许价值判断，但要明确前提条件。
|
||||
|
||||
### 结构
|
||||
1. 核心论点：开篇直接给结论。
|
||||
2. 论据展开：2-3 个关键论据，逐条论证。
|
||||
3. 反方视角：承认反例或限制条件。
|
||||
4. 立场收束：重申结论并给出行动建议。
|
||||
|
||||
### 禁忌
|
||||
- 情绪输出替代推理。
|
||||
- 稻草人论证（曲解对方观点再反驳）。
|
||||
- 断言“唯一正确答案”却不说明边界。
|
||||
|
||||
## 3) 教程（`tutorial`）
|
||||
|
||||
### 语气
|
||||
- 教练式表达，步骤清晰、可执行。
|
||||
- 默认读者不知道上下文，减少跳步。
|
||||
- 重点是“让读者做出来”，不是展示作者懂多少。
|
||||
|
||||
### 结构
|
||||
1. 目标与前置条件：完成后能得到什么，需要什么环境。
|
||||
2. Step-by-step：按顺序执行，每步只有一个主要动作。
|
||||
3. 结果验证：每步的预期输出或检查点。
|
||||
4. 常见错误：高频坑位与修复方法。
|
||||
5. 收尾：复盘关键点与可选进阶路线。
|
||||
|
||||
### 禁忌
|
||||
- 跳过关键前置条件。
|
||||
- 把多个动作塞进同一步，导致不可复现。
|
||||
- 只给“成功路径”，不提供失败排查。
|
||||
|
||||
## 4) 社交短文（`social_short`）
|
||||
|
||||
### 语气
|
||||
- 短促、有画面感、观点集中。
|
||||
- 首句抓人，结尾可互动。
|
||||
- 避免过度术语化，优先可传播表达。
|
||||
|
||||
### 结构
|
||||
1. Hook：首句提出冲突、反差或问题。
|
||||
2. 核心信息：1-2 个关键观点或故事片段。
|
||||
3. 行动结尾：提问、CTA 或一句可转发结论。
|
||||
|
||||
### 禁忌
|
||||
- 铺垫过长，前 3 句还没进主题。
|
||||
- 一条短文塞入过多观点。
|
||||
- 使用标题党或误导性陈述。
|
||||
|
||||
## 5) 栗子KK风格（`lizi_kk`）
|
||||
|
||||
> 基于 `personal-context/` 目录 5 篇已发表文章提炼，详见 `templates/author-style-lizi-kk.md`
|
||||
|
||||
### 语气
|
||||
- 直接、有冲击力，口语化但不失深度
|
||||
- 敢下判断（"99%"、"90%"），但必有数据支撑
|
||||
- 自信但不傲慢，技术细节 + 类比解释
|
||||
|
||||
### 结构
|
||||
1. **冲击式开头**：直接、有钩子，常用"说实话"、"先说结论"
|
||||
2. **数字编号**：01, 02, 03... 分段清晰
|
||||
3. **短段落**：每段 2-5 句话，单段不超过 150 字
|
||||
4. **必备元素**：个人经历、具体案例、代码示例、数据支撑
|
||||
5. **金句收尾**：名人引用 + CTA
|
||||
|
||||
### 语言特征
|
||||
| 书面语 | 栗子KK风格 |
|
||||
|--------|-----------|
|
||||
| 我发现 | 说实话，我发现 |
|
||||
| 这个问题很重要 | 这个问题我觉得特别典型 |
|
||||
| 效果很好 | 效果立竿见影 |
|
||||
| 很多人不知道 | 99%的教程都不提这个 |
|
||||
| 成功了 | 这招真的管用 |
|
||||
|
||||
### 禁忌
|
||||
- "赋能"、"生态"等空话
|
||||
- 纯理论无案例
|
||||
- 过长的代码块（影响阅读节奏）
|
||||
- 没有个人观点
|
||||
- 完美主义收尾（信奉"Done is better than perfect"）
|
||||
- 聚合式"我的N个思考/感悟"编号列表（洞察必须散布到正文段落中）
|
||||
- 连续 3 段以上长度均匀（每 3 段至少 1 个 ≤2 句话的短段）
|
||||
- 抽象观点无具体场景跟随（每个判断后必须有时间/数字/工具名等细节）
|
||||
|
||||
### 适用场景
|
||||
- 技术深度文章
|
||||
- 产品发布/介绍
|
||||
- 踩坑经验分享
|
||||
- 行业趋势分析
|
||||
|
||||
## 风格选择建议
|
||||
- 需要解释技术方案与实践细节：选 `tech_blog`
|
||||
- 需要表达立场并说服读者：选 `opinion`
|
||||
- 需要让读者可复现地完成任务：选 `tutorial`
|
||||
- 需要快速传播观点或洞察：选 `social_short`
|
||||
- **需要个人品牌风格、技术+实战**：选 `lizi_kk`
|
||||
Loading…
Reference in New Issue
Block a user