# Demo Runbook：三段 demo 应该怎么做

## 总体原则

这场分享的 demo 不要证明“AI 会写”。要证明三件事：

- 语言调度动作：一句话触发跨工具工作。
- 上下文改变输出：AI 不是只靠公开知识，而是读你自己的业务系统。
- 工作留下记忆：每次工作都沉淀成未来可复用资产。

因此三段 demo 的顺序建议是：

1. Context Intake：从想法进入系统。
2. Docs / Outlook：从行动项到跨工具落地。
3. Growth OS：从内容资产到个人业务系统联动。

## Demo 1：Context Intake

### 要证明什么

普通 AI 把语音变成摘要；Context Intake 把语音变成未来可复用的经营上下文。

### 真实本地资产

- Repo：`/Users/sunyuzheng/Desktop/kedaibiao/context intake`
- 主要命令：`python -m intake_skill run-day --date YYYYMMDD --asr-engine mlx --postprocess-engine codex`
- 产物：
  - `data/YYYYMMDD/transcript_YYYYMMDD.csv`
  - `data/YYYYMMDD/daily_YYYYMMDD.md`
  - `data/YYYYMMDD/daily_YYYYMMDD.html`
  - `data/YYYYMMDD/meetings/*.md`

### 现场讲法

你可以说：

“这是我的个人 context intake。它不是录音转文字工具，而是把每天散落的想法、会议、任务和判断变成 AI 后续能读取的 context pack。”

### 现场动作

如果要真跑：

```bash
cd "/Users/sunyuzheng/Desktop/kedaibiao/context intake"
source .venv/bin/activate
python -m intake_skill dashboard
```

打开 dashboard，展示最近几天已经生成的 `daily_YYYYMMDD.html`，不要现场转录真实隐私语音。

## Demo 2：Google Docs / Outlook

### 要证明什么

行动项不要停在总结里。AI 的价值不是“帮我写邮件”，而是把行动从 transcript 推到 doc、calendar、email 和 owner。

### 现场讲法

“自己做这件事要打开三四个软件。AI 做这件事也许要跑一分钟，但我只要交代一句话，做完它通知我。差别不是速度，而是我不用做 middleware。”

### 推荐演示请求

```text
把今天 context intake 里关于 OPC 分享的 action items 整理成一页 Google Doc，
分享给合作伙伴；同时找明天上午 30 分钟发 Outlook 邀请，
邮件里说明背景、目标和需要准备的材料。
```

### 演示重点

- 生成 Google Doc。
- 邮件正文不是泛泛提醒，而是包含 context。
- 日历邀请里有文档链接和准备事项。
- 这次 action 被记录回 context ledger。

## Demo 3：Kedaibiao / lizheng.ai Growth OS

### 为什么第三个 demo 要换

原来的 `OPC Growth OS` 是一个合理的模拟 demo，但不如你自己的真实业务系统有说服力。你自己的系统已经天然具备一人公司 Growth OS 的所有要素：

- 原始内容：YouTube 视频、字幕、访谈、Voice Memo。
- 内容再生产：YouTube 转播客、shownotes、文章、社媒 slides。
- 分发系统：YouTube playlist、podcast RSS、lizheng.ai。
- 结构化资产：嘉宾页、书页、skill、文章库、transcript library。
- 自动更新：guest metadata sync、playlist automation、site build。

这正好证明 10 倍杠杆不是“写一篇文案更快”，而是内容、产品、分发和网站互相联动。

### 真实本地资产

内容入口：

- YouTube to Podcast：`/Users/sunyuzheng/Desktop/AI/_archive/apps-archive/youtube-to-podcast`
- YouTube playlist/doc：`/Users/sunyuzheng/Desktop/AI/apps/youtube-playlist-doc`
- 频道工具：`/Users/sunyuzheng/Desktop/AI/content/kedaibiao-channel/tools/youtube`
- Podcast sync logs：`/Users/sunyuzheng/Desktop/AI/content/kedaibiao-channel/logs/podcast_sync`

个人主页：

- Site repo：`/Users/sunyuzheng/Desktop/superlinear/sites/lizheng.ai`
- 首页/书页/嘉宾页：`/`, `/book`, `/guests`, `/guests/:slug`
- 嘉宾维护文档：`docs/guests-maintenance.md`
- 主要命令：`pnpm refresh:guests`
- 关键脚本：`scripts/sync-guest-video-metadata.ts`

YouTube 自动化：

- 工具目录：`/Users/sunyuzheng/Desktop/AI/content/kedaibiao-channel/tools/youtube`
- 描述更新：
  - `fetch_all_videos.py`
  - `build_patch_manifest.py`
  - `dry_run.py`
  - `apply_patches.py`
- Playlist：
  - `classify_playlists.py`
  - `create_playlists.py --plan`
  - `create_playlists.py --populate`

### 现场故事线

用一个真实任务做主线：

```text
我刚录完一期和嘉宾的长访谈。
请把它推进成完整增长系统：
1. 做 podcast episode 和 shownotes。
2. 更新嘉宾页 episode metadata。
3. 如果嘉宾是新嘉宾，生成嘉宾页草案。
4. 判断它应该进入哪些 YouTube playlists。
5. 更新 lizheng.ai 首页/书页/skill 相关引用机会。
6. 留下一份 launch checklist 和 context ledger。
```

### 第一轮请求

第一轮不是“帮我写 shownotes”，而是让 AI 读完整业务系统：

```text
你是我的内容增长系统 operator。
请读取本地 repo map，围绕这期新视频生成 launch plan：
- podcast episode title / shownotes
- lizheng.ai guest page update plan
- YouTube playlist update plan
- related book / skill / article links
- launch checklist
- 哪些文件会被改，哪些命令需要 dry-run
不要直接发布，先输出计划和安全检查。
```

### 现场可展示的动作

不要现场写 YouTube 或部署个人主页。先展示 dry-run / plan：

- `tools/youtube/create_playlists.py --plan`
- `tools/youtube/dry_run.py --n 5`
- `pnpm refresh:guests` 的流程说明或过去产物
- `lizheng.ai/docs/guests-maintenance.md`
- `shared/guest-data.ts` 和 `shared/guest-video-metadata.ts`

### 第二轮请求

第二轮证明复利：

```text
不要重新扫描所有文件。
基于刚才生成的 launch plan，把这期内容再派生为：
1. podcast episode
2. guest page update
3. YouTube playlist patch
4. 一条围绕《真本事》的关联推广
5. 一个可加入 skill library 的内容复用 workflow
```

### 强 punchline

第一轮做的是 launch；第二轮做的是 system learning。

如果第一轮留下了好的 context ledger，第二轮不需要你重新解释：

- 这个嘉宾是谁。
- 这期视频属于哪些主题。
- 它和书、课程、skill、文章库有什么关系。
- 哪些步骤需要 dry-run，哪些步骤可以自动化。

这就是一人公司 Growth OS。

## 现场不要做什么

- 不要现场暴露 YouTube token、API key、OAuth 文件。
- 不要现场真的批量修改 YouTube 描述。
- 不要现场全量 populate playlist。
- 不要现场处理私人 Voice Memo 原音频。
- 不要让观众读大量 generated copy。

## 最好展示什么

- 文件夹地图。
- 干净的 change request。
- dry-run 结果。
- 生成的 launch plan。
- 第二轮请求复用第一轮资产的速度。
- 最后展示一句：工作留下记忆，未来的 AI 才会越来越懂你。