让 AI 自己写 Skill：可进化 Agent 的设计原理与最佳实践

## Trigger
When writing new blog posts for hugozhu.site, reviewing existing posts,
or analyzing blog content strategy.

### 1. 场景驱动开篇 (Scenario-Driven Openings)
Open with concrete stories, not abstract concepts.
- **Good:** "上周有个做运营的朋友拿着一个 AI 帮他建的销量预测模型来找我..."
- **Pattern:** Real person + specific situation + dialogue → reveals the problem

### For Opinion Posts (观点文)
1. Hook: Real scenario/story (2-4 paragraphs)
2. Thesis: Clear statement of the core argument
3. <!--more-->
4. Section 一: Problem definition / conventional wisdom
5. Section 二: Analysis / why conventional view is incomplete
6. Section 三: Framework or new mental model
7. Section 四: Practical implications
8. Conclusion: Memorable closing thought

### W1. 技术帖缺乏问题上下文
Some infrastructure posts are too thin — 26 lines with zero "why".
- **Fix:** Always add "为什么需要这个方案" paragraph before code

### Phase 1: Consistency (Immediate)
- [ ] Apply "problem context" paragraph to ALL technical posts
- [ ] Remove AI generation markers from existing posts

| Date | Change |
|------|--------|
| 2026-04-10 | Initial creation. Analyzed 174 posts... |

dependencies: ["writing-style"]

### 不确定信息标注
- 人名不确定：`张三[?]`
- 数字不确定：`500万[?]`
- 不确定就不编，宁可标注 `[?]` 也不写错

## ASR 工具适配
### 飞书妙记：有 speaker 标识和标点，质量较高...
### Whisper：无 speaker 标识，需要根据内容推断说话人切换...
### 通义听悟：有 speaker 标识，中文识别好...
### 讯飞听见：标点较准，长会议可能分段...

---
name: writing-style
description: Hugo Zhu's blog writing style guide for hugozhu.site — style characteristics, structural templates, weaknesses, and improvement roadmap. Evolves with each use.
version: 1.0.0
author: hugozhu
license: MIT
dependencies: []
metadata:
  hermes:
    tags: [blog, writing, content-strategy, hugo, chinese, english]
    related_skills: []
---

# Hugo Zhu's Blog Writing Style Guide

## Trigger
When writing new blog posts for hugozhu.site, reviewing existing posts, or analyzing blog content strategy.

## Author Profile
- **Name:** Hugo Zhu
- **Blog:** hugozhu.site (Hugo + beautifulhugo theme)
- **Content languages:** Primarily Chinese (2026+), previously English
- **Topics:** AI/ML thinking, product methodology, personal cloud infrastructure (Tailscale, CoreDNS, Armbian), Raspberry Pi, networking, software engineering
- **Audience:** Chinese-speaking tech professionals, engineers transitioning to AI, product-minded technologists
- **Publishing rhythm:** ~2-3 posts/week in 2026

## Core Writing Identity: 务实的思考型工程师

Three facets:
- **Engineer:** Deep technical understanding, writes from hands-on experience
- **Product thinker:** User-centric, problem-first, frames things in terms of value and trade-offs
- **Philosopher:** Abstract thinking, first principles, willing to question assumptions

## Style Characteristics (Strengths to Maintain)

### 1. 场景驱动开篇 (Scenario-Driven Openings)
Open with concrete stories, not abstract concepts.
- **Good:** "上周有个做运营的朋友拿着一个 AI 帮他建的销量预测模型来找我，特别兴奋：'你看，R² = 0.89，是不是挺准的？'"
- **Good:** "上周，一个做 ToB SaaS 的朋友跟我吐槽：他花了两周让 AI 帮忙写了一套完整的 CRM 后端..."
- **Pattern:** Real person + specific situation + dialogue → reveals the problem

### 2. 框架构建者 (Framework Builder)
Don't just describe — structure into reusable mental models.
- **Examples:** "任务委托四要素"、"Token 能力边界"、"万物皆可建模吗"
- **Goal:** Create frameworks readers can apply to their own situations

### 3. 反直觉但接地气 (Contrarian But Grounded)
Challenge conventional wisdom with clear reasoning.
- **Examples:** "AI 落地的瓶颈不是技术，是你不会派活"、"不是所有东西都值得建模"
- **Rule:** Back every contrarian claim with real examples AND logical chains

### 4. 结构清晰 (Clear Structure & Logical Flow)
- Numbered sections (一、二、三)
- Bold key takeaway sentences
- Pattern: Problem -> Analysis -> Framework -> Implications/Action items
- Use `<!--more-->` after opening paragraph(s) for Hugo excerpt

### 5. 中英双语标题 (Bilingual Titles)
- Chinese main title + English subtitle (or vice versa)
- Body language: Chinese primary with English technical terms
- This is the established style since 2025

### 6. 有辨识度的文风 (Distinctive Voice)
- Conversational but rigorous — like a smart colleague explaining something
- Uses "我" (first person) and direct address "你" to create intimacy
- Ends with thought-provoking questions or philosophical extensions
- Not afraid of being wrong — values the thinking process over authority

## Post Structure Templates

### For Opinion/Thinking Posts (观点文)

### For Technical/Infrastructure Posts (技术文)

## Current Weaknesses (Areas to Improve)

### W1. 技术帖缺乏问题上下文
Some infrastructure posts are too thin — e.g., tailscale-hostapd post is 26 lines with zero "why".
- **Fix:** Always add "为什么需要这个方案" paragraph before code
- **Good example:** The CoreDNS short DNS post already does this naturally

### W2. 零可视化内容
174 posts with almost no diagrams, screenshots, or architecture visuals.
- **Fix:** Add at least one visual per post
- For technical posts: network topology diagram, terminal screenshot
- For opinion posts: framework diagram (2x2 matrix, flow chart, conceptual model)

### W3. 缺少交叉引用和主题聚合
Overlapping topics don't reference each other — Tailscale, CoreDNS, AI Agent posts are scattered.
- **Fix:** Create topic series ("个人云基础设施"系列, "AI 思考录"系列)
- Add related-post links at the bottom of each article

### W4. AI 生成代码标注
Some posts contain `# generated by AI` comments, undermining credibility.
- **Fix:** Remove generation markers; verify and rewrite any AI-generated code
- If referencing AI-generated concepts, integrate them naturally without attribution

## Improvement Roadmap

### Phase 1: Consistency (Immediate)
- [ ] Apply "problem context" paragraph to ALL technical posts going forward
- [ ] Remove AI generation markers from existing posts
- [ ] Ensure every post has `<!--more-->` in the right place

### Phase 2: Visuals (Near-term)
- [ ] Add at least one diagram/screenshot per new post
- [ ] Retrofit visuals to top 10 most-viewed existing posts
- [ ] Create reusable diagram templates (network topology, framework 2x2, flow chart)

### Phase 3: Knowledge System (Medium-term)
- [ ] Create "个人云基础设施" series page
- [ ] Create "AI 思考录" series page
- [ ] Add related-posts links to existing articles
- [ ] Consider creating topic tags that map to series

## Code Example Conventions
- Python code blocks: use `python` language tag
- Bash/config: use appropriate language tag (bash, yaml, toml)
- Code should illustrate a concept, not just exist — add a 1-line explanation before each block

## Evolution Log

| Date | Change |
|------|--------|
| 2026-04-10 | Initial creation. Analyzed 174 posts across 2013-2026. Identified 6 style strengths, 4 weaknesses, 3 improvement areas. |

## How to Evolve This Skill

After writing or reviewing blog posts:
1. If a new pattern emerges (successful or unsuccessful), add it to Style Characteristics or Current Weaknesses
2. If a weakness is resolved, move it from Current Weaknesses to a "Resolved" section
3. If a new improvement is identified, add it to Improvement Roadmap
4. Update the Evolution Log with the date and what changed
5. Use `skill_manage(action='patch')` to update — never let this skill go stale

---
name: meeting-minutes
description: 从 ASR 录音转写文本整理会议纪要 — 噪声清洗、结构化提取、按 Hugo 写作风格输出。适用于飞书妙记、Whisper、通义听悟等 ASR 产物。
version: 1.0.0
author: hugozhu
license: MIT
dependencies: ["writing-style"]
metadata:
  hermes:
    tags: [meeting, minutes, ASR, transcription, summarization, chinese, agenda, action-items]
    related_skills: [writing-style, lark-minutes]
---

# 会议纪要整理 Skill

## Trigger
当用户提供 ASR 转写文本（飞书妙记、Whisper、通义听悟、讯飞等），要求整理会议纪要时加载。

## 核心设计哲学

会议纪要不是录音的文字搬运，而是**信息压缩 + 决策提取**。这和 Hugo 的博客写作风格一致：框架化、结构化、可执行。

> **好纪要的标准：没参会的人看一遍就知道发生了什么、决定了什么、接下来要做什么。**

## ASR 转写文本的典型问题

### 噪声类型
1. **无标点/错标点**：ASR 输出往往没有正确断句
2. **专有名词错误**：人名、产品名、技术术语经常被识别错
3. **口语化冗余**：嗯、啊、这个、那个、重复表达
4. **多人交叉发言**：没有明确 speaker 标识，或标识混乱
5. **中英混杂**：技术讨论中大量英文术语夹杂
6. **跑题和闲聊**：会议中常有偏离主题的讨论
7. **上下文缺失**：参会人都知道但没明说的背景知识

### 处理原则
- **保留原意，改写表达**：不改写核心信息，但大幅改写表达方式（去口语化、补逻辑）
- **不确定就标注**：人名、数字等关键信息不确定时用 `[?]` 标注，不瞎猜
- **区分事实和观点**：明确哪些是共识决定，哪些是某人观点
- **跑题内容直接删**：不记录闲聊、不相关的讨论

## 会议纪要结构模板

### 标准模板（适用于大多数会议）

```markdown
# [会议主题] 会议纪要

**时间：** YYYY-MM-DD HH:MM
**时长：** XX 分钟
**参会人：** 人名列表
**转写来源：** [ASR 工具名称]

---

## 一、核心结论（TL;DR）

用 3-5 条 bullet points 概括本次会议最重要的结论和决定。
没参会的人只看这一节应该就能知道发生了什么。

- 决定：XXX
- 风险：XXX
- 变更：XXX

## 二、议题讨论

### 议题 1：[标题]

**背景：** 一句话说明为什么要讨论这个。

**讨论要点：**
- [论点/发现/数据]
- [不同意见，如有]

**结论/决定：** 明确的结论或下一步方向。

### 议题 2：[标题]

...

## 三、待办事项（Action Items）

| # | 事项 | 负责人 | 截止时间 | 备注 |
|---|------|--------|----------|------|
| 1 | [具体可执行的动作] | @人名 | YYYY-MM-DD | 可选 |
| 2 | ... | ... | ... | ... |

## 四、遗留问题（Open Questions）

- [ ] 需要后续确认/研究的问题 1
- [ ] 需要后续确认/研究的问题 2

## 五、下次会议

- 时间：[如有]
- 议题：[如有]

# [会议主题] 纪要 — YYYY-MM-DD

## 结论
- 结论 1
- 结论 2

## 待办
- @人名：事项（截止 XX）
- @人名：事项（截止 XX）

## 待确认
- 待确认事项 1

## 结语

AI 时代的"知识管理"不是建 Notion 文档库，也不是写 5000 字的 system prompt。是训练可执行的、能自我更新的 Skill——它们像肌肉记忆一样，在每次使用中积累反馈，在每次反馈中进化。

今天下午创建这两个 Skill 的过程中，我突然意识到：**真正有价值的不是 Skill 文档本身，而是设计 Skill 的那套元能力——知道哪些规则该写进去、哪些不该写，知道在哪里留白让 Agent 自己判断，知道如何在"约束"和"自由"之间找到那个恰到好处的平衡点，知道如何让一个 Skill 依赖另一个 Skill 而不是重复造轮子，知道把每次踩坑固化成可复用的流水线步骤。**

这才是 AI 时代人类的核心竞争力：不是你会不会用 AI，而是你会不会教 AI 学会自己学习。

最后留一个思考题：如果你的 Agent 每天自动更新自己的 Skill，三个月后，它还是同一个 Agent 吗？或者更准确地说——**它已经变成了你。**