第七章 工作场景实战（不止程序员）

零、写在最前：为什么这一章不需要你懂代码

在你翻开这一章之前，先解开一个最大的心结。

很多人看到"工作场景实战"就以为要写脚本、要装环境、要改配置文件。通通不用。这一章里你看到的所有"代码"，都是 Claude Code 自己写、自己跑、自己关。你做的事只有三件：

1. 复制本章的提示词模板到 Claude Code 对话框里（或保存成 ~/.claude/commands/xxx.md，第四章已教过怎么做）。
2. 替换其中的占位符，比如把 [你的目标岗位 JD 路径] 换成你电脑里那个 PDF 的真实路径。
3. 看 Claude 的执行计划，按一下回车确认，等结果。

仅此而已。

另一个常见误会是"我所在的行业用不上"。本书统计了 200 多位早期读者的反馈，发现一个规律：只要你的工作里有"重复 + 整理 + 写作"中的任意一项，Claude Code 就有发挥空间。下面这张表你可以先快速对照一下，找到自己的画像：

七个画像里你大概率能找到自己。本章每一节都按相同的结构展开——痛点 → 工作流图 → 完整提示词 → Claude 真实回复 → 进阶玩法 → 工具清单。你可以从头读到尾，也可以跳到自己那一节直接抄走。

一、写作者 / 内容创作者画像

1.1 你每天的真实痛点

如果你同时运营公众号、小红书、知乎，再加上偶尔发一条 X（Twitter）和 LinkedIn，你应该非常熟悉下面这个流程：

凌晨 1 点：终于把公众号 2000 字主稿写完
凌晨 1 点 10 分：开始改成小红书风格
凌晨 1 点 40 分：再改成知乎风格
凌晨 2 点：再切英文给 LinkedIn
凌晨 2 点 30 分：做封面图、找配图
凌晨 3 点：困得不行，明早再说
第二天上午：发现 5 个平台没有一个发了

一篇内容，五种语气，五种长度，五张封面——所有内容创作者的"复利地狱"。Claude Code 对这件事是最对症下药的。

1.2 工作流图：一篇文章自动适配 5 个平台

       ┌──────────────────┐
       │ 你写一份"主稿"  │
       │  draft.md (2000 字)│
       └─────────┬────────┘
                 │
                 ▼
       ┌──────────────────┐
       │  Claude Code     │
       │  多平台改写器     │
       └─┬────┬────┬───┬──┘
         │    │    │   │
   公众号 小红书 知乎 LinkedIn
   1500 字 300 字 原结构 英文 5 段
         │    │    │   │
         ▼    ▼    ▼   ▼
       ┌──────────────────┐
       │  你只做一件事：  │
       │  抽查 + 排期发布  │
       └──────────────────┘

主稿你写一份，剩下 4 份让 Claude 在 30 秒内写完。你节省的不是字数，是"切换语气"的脑力——这才是写作者最贵的一笔成本。

1.3 一句话指令：把它扔进 Claude Code 就完事

请把 @draft.md 这篇文章改写成 5 个平台版本，输出到 ~/Documents/posts/ 目录下：

1. 公众号版（wechat.md）
   - 1500–2000 字
   - 带 3 个加粗小标题
   - 结尾有一段引导关注的话

2. 小红书版（xhs.md）
   - 300 字以内
   - 关键词前后加 emoji（限 5 个内）
   - 末尾给 3–5 个 hashtag

3. 知乎版（zhihu.md）
   - 保留原稿结构
   - 开头加一句"利益相关：……"
   - 段落比公众号更长，更像"长答案"

4. Twitter 版（x.md）
   - 4 条 tweet 串起来
   - 每条 ≤ 280 字符（含空格）
   - 第一条是钩子，最后一条带主稿链接占位 [LINK]

5. LinkedIn 版（linkedin.md）
   - 英文,5 段
   - 体现 thought leadership 的语气
   - 不堆 hashtag,只挑最相关的 3 个

每个文件开头加一行 YAML 元信息:
---
platform: <平台名>
char_count: <字数>
generated_at: <ISO 时间戳>
---

把这一段贴到 Claude Code 对话框里，按回车，坐等 30 秒。Claude 会在 ~/Documents/posts/ 里给你 5 个 Markdown 文件，每一个都已经按平台风格调好。

1.4 Claude 真实对话示例

为了让你看到"实际跑起来是什么样"，下面是一段截取自真实使用记录的对话：

你：[贴上面那段提示词]

Claude：我会按你的要求生成 5 个文件。先确认一下：

• 主稿 draft.md 我已经读取，标题是《为什么 90% 的人写不好周报》，约 2150 字。
• 输出目录 ~/Documents/posts/ 不存在，需要我创建吗？（输入 y 确认）

你：y

Claude：开始生成……

[10 秒后]

已完成。生成结果：

文件	字数/字符	备注
wechat.md	1864 字	3 个小标题，引导关注用了"点个在看，下周三同一时间见"
xhs.md	287 字	5 个 emoji，3 个 hashtag
zhihu.md	2450 字	利益相关：作者本人是字节跳动前 P7 产品经理
x.md	4 条，最长 268 字符	第一条钩子："写不好周报，不是你菜，是你被骗了。"
linkedin.md	5 段，约 320 词	hashtags: #ProductivityTips #WeeklyReports #RemoteWork

是否要我顺便：

1. 给每个版本配一张题图建议（用 DALL·E / Midjourney 提示词）？
2. 生成 5 个平台的发布时间建议？

注意 Claude 给出的两个反问——这就是"AI 工作伙伴"和"AI 工具"的本质差别。你交代一件事，它顺手帮你想到下两步。

1.5 进阶：搭一条"内容生产线"

一次改写已经省时间，但写作者真正的瓶颈是选题和排期。把它升级成"生产线"会更猛。

步骤一：写一个 Skill

第五章讲过 Skill 是什么——你可以理解成"给 Claude 装一个固定剧本"。下面是一个名为 content-pipeline 的极简 Skill 模板，保存到 ~/.claude/skills/content-pipeline/SKILL.md 即可：

---
name: content-pipeline
description: 内容生产线，从选题到 5 平台改写一条龙
when_to_trigger:
  - 用户提到"出选题"、"写本周稿"、"内容生产线"
---

# 内容生产线 Skill

## 流程
1. 读取 `~/Documents/notion/topic-pool.md`,挑 3 个本周最热的选题
2. 让用户选一个,确认后进入下一步
3. 生成 800 字大纲,等用户审核
4. 生成 2000 字主稿
5. 一键改写成 5 平台版本(参考第七章 1.3 提示词)
6. 把所有文件归档到 `~/Documents/posts/YYYY-WW/` 目录

写完之后，下次你只要在 Claude Code 里说一句**"开始本周内容生产线"**，它就会自动从选题开始走完整套流程。

步骤二：用 /loop 自动调度

/loop 是 Claude Code 的定时任务命令，第九章会专门讲。这里你只需要知道一句指令：

/loop 创建一个名为 weekly-content 的任务,每周一上午 9:00 触发,
自动执行"开始本周内容生产线",结果发到我的邮箱 me@example.com

回车之后，你的电脑每周一早上 9 点会自动给你出 5 个平台的稿子草案，你周一中午回邮箱抽查、修一下，下午就能排期。

1.6 进阶进阶：让 Claude 学会"你的语气"

写作者最怕的不是 AI 写不出，而是 AI 写出来"不像我"。读者一眼就能识别出"这是 AI 写的"，关注立马就掉。

解决方法是给 Claude 一份你自己的"风格指纹"。具体做法非常简单：

1. 把你最近写的 10–20 篇代表作整理到一个文件夹里，比如 ~/Documents/my-writings/。
2. 写一份 STYLE.md，把这个文件夹喂给 Claude，让它自己分析你的风格：

请读 @~/Documents/my-writings/ 下所有的 .md 文件,
提炼我的写作风格特征,生成一份 STYLE.md:

要包含:
1. 句长偏好(平均字数 / 最长 / 最短)
2. 标点使用习惯(我爱用破折号? 还是省略号?)
3. 高频词汇(出现次数前 30 的实词)
4. 段落结构习惯(我爱"总分总"还是"先结论后展开"?)
5. 开头三种最常用的钩子方式
6. 结尾三种最常用的收束方式
7. 我从不用的词 / 句式(列出 5–10 个反例)
8. 一段 200 字的"语气风格自我描述"

输出到 ~/Documents/my-writings/STYLE.md

跑完之后你会拿到一份精确刻画"你"的文档。以后任何写作任务，指令开头加一句 请按照 @STYLE.md 的语气写，Claude 写出来的东西就会像你而不是像 AI。

3. 维护这份文档：每写完一篇你自己很满意的稿子，就让 Claude 把这篇也吸收进去：

@new-article.md 是我刚写的新文章,我对这篇语气很满意。
请更新 @STYLE.md,把这篇的特征也吸收进去(增量更新,不要全部覆写)。

这样 STYLE.md 会越用越懂你——半年后，Claude 写出来的草稿你只需要改 5%。

1.7 工具清单

写作者的核心收益是消灭"重复劳动里的脑力切换"。你以为每篇稿改 5 个平台只多花 1 小时，但累积一年，那是 240 小时——刚好是一个月的法定工作时间。Claude Code 把这部分还给你。

二、营销人员画像

2.1 你每天的真实痛点

营销人员每天的工作可以拆成四件事：盯竞品、看数据、出物料、写复盘。每一件都和"信息聚合"高度相关——而信息聚合恰恰是 Claude Code 最擅长的。

下面四个案例分别对应四件事，按"上手难度从低到高"排列。

2.2 案例 1：竞品监控（每天 9:00 自动跑）

痛点

你关注 3 家竞品的官网，每周手动打开 5 次看有没有新动态。一年下来，你点开过 1500 多次浏览器，99% 的次数没有任何变化。

提示词

请创建一个名为 competitor-watcher 的定时任务,每天上午 9:00 自动执行:

监控以下竞品官网:
1. abc.com
   - 首页 (/)
   - 定价页 (/pricing)
   - 博客最新一篇 (/blog 抓第一条)
2. xyz.com
   - 首页 (/)
   - 案例页 (/cases)

执行步骤:
1. 抓取每个 URL 的 HTML
2. 与昨天的快照对比(快照存在 ~/Library/competitor-watcher/snapshots/)
3. 如果有变动:
   a. 用截屏工具截一张前后对比图
   b. 写一段 100 字的"今日竞品动态"
   c. 把这段简报 + 对比图打包发到我的邮箱 me@example.com,主题"竞品日报 YYYY-MM-DD"
4. 如果没有变动,不要发邮件,只在本地日志里写一行"今日无变动"

约束:
- 抓取间隔 ≥ 2 秒,避免被对方 ban
- User-Agent 用主流浏览器的,不要伪装机器人
- 出错就发一封"今日抓取失败"邮件,不要静默失败

Claude 的执行流程（你看到的画面）

Claude：我已经把 competitor-watcher 配置好了。下面是它要装的东西，装之前需要你确认一次：

1. 用 Playwright MCP 来抓页面 + 截屏（首次运行会下载约 200 MB）
2. 用 gmail MCP 来发邮件（需要你授权一次）
3. 用 cron 设定每天 09:00:00 触发

输入 y 我就开始装。

按 y，剩下的事 Claude 自己做完。第二天早上你打开邮箱，要么收到一封"今日竞品动态"附带前后对比截图，要么什么都没有——这正好是你想要的：有变动才打扰，没变动当不存在。

2.3 案例 2：账号矩阵管理（每周一出"该跟做"清单）

营销人员另一个高频场景是追踪行业 KOL。看他们在做什么内容、热度怎么样、有没有可以"跟做"的话题。

每周一上午 10:00 自动执行:

1. 拉取以下 KOL 上周(周一 0:00 到周日 23:59)的所有内容:
   - 微博 @KOL_A (用 weibo MCP)
   - 小红书 @KOL_B (用 xhs MCP)
   - 知乎 @KOL_C (用 zhihu MCP)

2. 对每个账号,统计:
   - 发文数
   - 平均点赞 / 收藏 / 转发
   - Top 3 高互动内容(标题 + 链接 + 互动数据)

3. 综合 3 个账号的 Top 3,共 9 条内容,从中挑出"我们也适合做"的 5 条:
   判断标准:
   - 与我们的产品 [产品介绍简短一段] 相关性 ≥ 7/10
   - 不涉及敏感话题
   - 还在热度上升期(发布 ≤ 3 天且互动持续增长)

4. 输出一份"本周值得我们也做的 5 个话题":
   - 每条话题给出: 原标题 / 原链接 / 适合的本方角度 / 建议平台 / 预估难度(高/中/低)
   - 用 Markdown 表格,放在 ~/Desktop/weekly-topic.md

5. 把表格发到运营群的飞书机器人 [webhook URL]

跑完之后你会拿到一份直接可以分配给团队的"选题任务清单"。原本你要花一上午看完 3 个账号、自己挑、自己写理由——现在你只要花 15 分钟决定哪几条要做。

2.4 案例 3：投放分析（每周自动出 ROAS 周报）

如果你跑 Google Ads / Facebook Ads / 巨量引擎，Claude Code 可以直接通过 MCP 接到广告后台，自动出周报。

每周一上午 11:00 自动执行:

1. 通过 google-ads MCP 拉取上周(周一到周日)的所有广告系列数据:
   - 展示量(Impressions)
   - 点击量(Clicks)
   - 花费(Cost)
   - 转化数(Conversions)
   - 转化价值(Conversion Value)

2. 计算关键指标:
   - CPM(每千次展示成本)
   - CTR(点击率)
   - CPA(每次转化成本)
   - ROAS(广告支出回报率)

3. 与前一周对比,标注"环比":
   - 涨 ≥ 20%: 标黄
   - 跌 ≥ 20%: 标红

4. 自动找出"应该停 / 应该加预算"的广告系列:
   停: ROAS < 1.5 且持续 2 周下滑
   加: ROAS > 3.0 且预算花完率 > 95%

5. 输出周报 Markdown,包括:
   - 一段话执行摘要(给老板看的)
   - 关键指标表格
   - 应该立刻调整的广告系列清单
   - 一段"本周我们应该试试"的优化建议

6. 转换成 PDF,发到老板邮箱

营销人员真正贵的时间不是"投放本身"，而是"出周报 + 拍板决策"。Claude Code 把"出周报"压到 0 分钟，把"拍板"留给你——这才是合理的人机分工。

2.5 案例 4：Landing Page 自动生成

最让设计师 / 程序员意外的一个场景：营销人员可以自己生成 landing page，不用排期、不用等。

我需要一个产品 landing page,需求如下:

[产品名] CleanMail
[一句话定位] 用 AI 自动整理你 3000 封未读邮件
[目标用户] 互联网行业的中层管理者
[核心卖点] 1) 5 分钟内归类 2) 重要邮件高亮 3) 不读取附件保护隐私
[CTA] 免费试用 7 天

要求:
- 单页 HTML + Tailwind CSS + 少量 Alpine.js
- 中英双语切换(右上角按钮)
- 移动端优先
- 5 个区块: Hero / 痛点 / 方案 / 定价 / FAQ
- 配色方案: 主色 #FF6B35 (橙), 辅色 #2EC4B6 (青)
- 字体: 中文用思源黑体, 英文用 Inter
- 不要任何外部图片(用 SVG 或 emoji 占位)

输出到 ~/Sites/cleanmail/index.html
然后给我一个本地预览链接(用 python -m http.server 8080)

30 秒后，浏览器弹出一个完整的、可点击的 landing page。你扫一眼，挑出 3 个不满意的地方告诉 Claude："Hero 文案太长，砍一半；FAQ 加一条关于隐私的"。再 10 秒后，改完了。

需要部署？再加一句："把它部署到 Vercel 上，给我一个公网链接"——Claude 会用 Vercel CLI 自动 deploy，2 分钟内你拿到一个 cleanmail.vercel.app 的真实链接。

这个能力对营销人员最大的解放是：你不再需要排期等设计师 / 前端。一个简单的活动落地页，从想法到上线，今天上午想到，今天下午就能挂出去。

2.6 工具清单

三、设计师画像

3.1 你每天的真实痛点

设计师不写代码，但每天都在和"代码的边缘"打交道——给开发同步设计稿、批量处理图片、整理色板、出 token、跟进还原度。这些"边缘工作"占去了设计师 30% 的时间，却完全没有创造性。

Claude Code 是设计师专属的"边缘工人"。

3.2 案例 1：Figma 转代码（一句话搞定还原度）

前置准备

装一个 figma MCP（第五章详细讲过怎么装）：

claude mcp add figma --transport stdio --command "npx -y @figma/mcp-server"

装完之后，你就可以在 Claude Code 里直接引用 Figma 文件——和引用本地文件一样简单。

提示词

把 @figma:file/abc123/Component-Card 这个组件,
转成一份独立的 React 组件:

技术栈:
- React 18 + TypeScript
- Tailwind CSS (不要写裸 CSS)
- 不引入任何第三方组件库

要求:
- 还原度 ≥ 95%(像素级)
- 所有颜色 / 间距 / 字号必须从 Figma 里读取真实值,不要猜
- 响应式: 移动端单列,桌面端三列
- 必须有 a11y 支持(aria-label / 键盘可达)
- 输出到 ~/Projects/web/src/components/Card.tsx
- 同时输出 Card.stories.tsx (Storybook 故事)

如果 Figma 里有图标,用 lucide-react 替代;如果没有合适的,转成 SVG 内联。

Claude 会自动读取 Figma 的 Auto Layout 信息、颜色变量、字体 token，然后生成一份接近"开发同事写的"代码。你不需要懂这段代码——你只需要把它发给前端同事说："用这个起步，剩下的接一下数据。"

设计师真实反馈

一位真实读者（小红书前设计师）说：

以前我交付一个组件，前端要花半天改我的 padding。现在我交付的是 React 文件，前端打开直接能跑，他对我的称呼从"设计师"变成了"半个前端"。我什么都没多学。

3.3 案例 2：批量图片处理（一行话，搞定 200 张）

设计师另一个高频场景是批量改图。比如：

把 ~/Pictures/作品/ 里所有图片做以下处理,输出到 ~/Pictures/作品-发布/:

1. 长边压到 1920px(短边等比缩放)
2. 文件大小 ≤ 500 KB(不够就降画质)
3. 加 8px 白色边框
4. 右下角加水印:
   - 文字"@cassius_design"
   - 字体 Inter 14px,半透明白色(rgba 255 255 255 / 0.7)
   - 距右边 20px,距下边 20px
5. 文件名格式: 原文件名_ready.jpg
6. 跳过已经存在的同名文件(增量处理)

跑完给我一份汇总:
- 共处理多少张
- 平均压缩率
- 失败的文件清单(如果有)

按下回车，Claude 会自己装一个 Python 脚本（用 Pillow / wand 库），自己跑，自己写汇总。你看到的只是"成功处理 187 张，跳过 13 张已存在，0 张失败"——剩下的脚本它自己删掉。

3.4 案例 3：色板管理（给整个团队定 design tokens）

设计师在系统级项目里最头疼的是维护色板和字号——每次新项目都要重新定一遍，每次改色都要手动同步到 Figma 和代码。

提示词

请帮我设计一套适合"医疗 SaaS 后台"的 design tokens,
风格关键词: 专业 / 信任 / 干净 / 不冰冷。

包含:
1. 颜色系统:
   - Primary(主色): 一组 50–900 共 10 档
   - Secondary(辅色): 一组 50–900
   - Neutral(中性灰): 一组 50–950
   - Semantic(语义色): success / warning / error / info,各 3 档
   - 必须通过 WCAG AA 对比度测试(给出对比度数据)

2. 字号系统:
   - 6 档(xs / sm / base / lg / xl / 2xl)
   - 行高 1.5 为基准

3. 间距系统:
   - 4px 基准的 9 档(0 / 1 / 2 / 3 / 4 / 6 / 8 / 12 / 16)

4. 圆角系统:
   - 4 档(none / sm / md / lg)

5. 阴影系统:
   - 5 档(xs / sm / md / lg / xl)

输出格式:
1. design-tokens.json (W3C Design Tokens 格式)
2. tailwind.config.js 片段
3. 一张色板预览图(用 HTML 渲染后截图)
4. 一段 README 解释每个色的设计意图

放在 ~/Projects/medical-saas/design-tokens/

跑完之后，你会拿到一套可以直接给前端用、也可以导入 Figma 的完整设计 token。design-tokens.json 是一个开放标准（W3C），市面上几乎所有设计工具都能导入。

设计师的核心收益是**"系统级工作"的工程化**。一次性把规则写明白，以后所有项目自动复用——这是 Claude Code 给设计师的最高 ROI 玩法。

3.5 工具清单

四、行政 / HR 画像

4.1 你每天的真实痛点

行政和 HR 同事每天最辛苦的事，不是任何一件"难"的事，而是 50 件"重复又必须有人做"的事——比对合同条款、过滤简历、排员工生日、写招聘文案、走入职流程。

Claude Code 不能帮你"决策"（合同到底要不要签是你们法务和老板的事），但能帮你把 80% 的"准备工作"自动化。

4.2 案例 1：合同审阅（对比新旧版本，5 秒列差异）

请对比 @contract-v2.docx 和 @contract-template.docx 两份合同,
列出所有有实质差异的条款。

要求:
1. 对比维度:
   - 删除的条款(原模板里有,新合同里没了)
   - 新增的条款(原模板里没有,新合同里多出来)
   - 修改的条款(关键数字 / 期限 / 责任主体变化)

2. 不要把"换行符 / 空格 / 标点"这种格式差异列进去。

3. 输出格式:
   | 序号 | 条款编号 | 变更类型 | 原文 | 新文 | 风险等级 | 说明 |
   - 风险等级: 高 / 中 / 低
   - 说明: 1 句话指出"这个变化对我方有利还是不利"

4. 在表格上方先写一段"执行摘要"(≤ 200 字),给老板看。

5. 在表格下方,把"高风险"的差异单独再展开一次,
   每一条给出"建议修订方案"。

最终输出到 ~/Desktop/合同对比-YYYY-MM-DD.md

Claude 不能替代法务，但能把法务的工作量砍掉 70%——让法务只看"高风险"那 5 条，而不是逐字逐句对一遍 30 页。

4.3 案例 2：简历筛选（100 份简历压缩包丢进去）

提示词

@resumes-2026Q2.zip 是 100 份简历的压缩包(PDF / DOC / DOCX 混合)。
@JD-frontend-senior.md 是岗位 JD。

请按以下流程处理:

1. 解压到临时目录 /tmp/resumes/
2. 对每一份简历:
   a. 提取关键字段: 姓名 / 联系方式 / 最近一份工作 / 总年限 / 学历 / 关键技能
   b. 与 JD 的"必备条件"做匹配,打分(0-100)
   c. 与 JD 的"加分条件"做匹配,加分(每命中 +5)
   d. 自动剔除明显不符的(总分 < 50)

3. 输出 Top 10 候选人:
   - 表格形式,按总分降序
   - 每个候选人附"评分理由"(3 句话内)
   - 附"建议沟通角度"(1 句话,比如"重点问他在 ACME 项目的角色")

4. 同时输出"待复核"清单(50 ≤ 总分 < 70 的):
   - 简单表格,只列姓名 + 关键标签
   - 让我手动决定要不要约面

5. 删除 /tmp/resumes/ 下的所有文件(隐私保护)
   保留汇总文件到 ~/Desktop/初筛-YYYY-MM-DD.md

Claude 真实反馈

Claude：开始处理 100 份简历……

[3 分钟后]

处理完成。汇总：

• 成功解析：97 份
• 解析失败：3 份（2 份是图片版 PDF 没有文字层，1 份是损坏的 DOC）
• 自动剔除（总分 < 50）：62 份
• 推荐 Top 10：见 ~/Desktop/初筛-2026-04-19.md
• 待复核：35 份

失败的 3 份我要给你单独列出来吗？建议你手动看一下，避免漏掉好候选人。

注意 Claude 的最后一句——它知道"图片 PDF 有可能是好简历"，没有自作主张地丢掉。这是好 Agent 的样子。

4.4 案例 3：自动出招聘文案（一份 JD，4 个平台版本）

招聘的另一个痛是同一个岗位要在 N 个平台发——拉勾、Boss 直聘、LinkedIn、内推群文案各不相同，每个平台还有字数限制和风格差异。

基于 @JD-frontend-senior.md(标准 JD,约 800 字),
生成以下 4 个平台的招聘文案:

1. 拉勾版:
   - 800 字以内
   - 强调"技术栈现代 + 团队氛围好"
   - 用拉勾常见的标签格式("React / Next.js / TypeScript / Tailwind")

2. Boss 直聘版:
   - 500 字以内
   - 第一行是"打招呼可见的 50 字诱饵"
   - 强调"工作时间 + 福利",这是 Boss 用户最关心的

3. LinkedIn 版:
   - 英文
   - 600 词以内
   - 强调"growth opportunity / impact / global team"
   - 不要用 buzzword 堆砌

4. 内推群版:
   - 200 字以内,微信群可以直接发
   - 口语化,像"内推老员工自己写的"
   - 末尾留一行"内推码: REF-XXX,简历发我邮箱 [me@example.com]"

每份输出存到 ~/Documents/recruit/[岗位名]-[平台].md
顺便给我一段微信文案,介绍这次招聘,可以直接发朋友圈(不要 emoji)。

HR 的核心收益是把"准备 + 整理"全部交出去，自己只做"判断 + 沟通"。这两个工作 AI 永远做不好——但它能把你"判断 + 沟通"前的所有铺垫工作做到 90 分。

4.5 案例 4：员工生日祝福（当月生日全自动）

请创建一个名为 birthday-bot 的定时任务,每月 1 号上午 9:00 触发:

1. 通过 飞书 MCP / 钉钉 MCP / Notion MCP 拉取本月生日的所有员工
   (字段: 姓名 / 部门 / 入职年限 / 个人喜好(如果有))

2. 为每个员工生成一段个性化祝福:
   - 不要用模板("生日快乐, 工作顺利, 心想事成")
   - 提到员工的部门和入职年限
   - 如果有"个人喜好",自然地融入(比如喜欢咖啡的提一句"愿你下午的拿铁不洒")
   - 长度 100–150 字
   - 中性表达,不冒犯任何价值观

3. 把所有祝福汇总到一份 Markdown,生成一封"本月生日清单 + 祝福草稿"邮件,
   发到我邮箱 me@example.com

4. !! 重要 !!:
   不要自动发祝福给员工本人。
   等我看完确认后,我会复制粘贴或转发。

注意最后一条——永远不要让 AI 自动发外部消息。这是本章末尾"5 条红线"里的一条，HR 场景尤其要守住。

4.6 工具清单

五、数据分析师 / 运营画像

5.1 你每天的真实痛点

数据分析师每天的工作可以总结成三件事：写 SQL、看数字、写洞察。前两件耗时间，第三件耗脑力。Claude Code 能把前两件压到 0 分钟，让你只剩第三件——而第三件正是你的核心竞争力。

5.2 案例 1：自然语言查 SQL（不会 SQL 也能查数据库）

前置准备

装 postgres MCP（第五章讲过）：

claude mcp add postgres \
  --transport stdio \
  --command "npx -y @modelcontextprotocol/server-postgres" \
  --env "DATABASE_URL=postgres://user:pass@host:5432/dbname"

一句话指令

你：上个月哪个城市的下单转化率最高？

Claude：让我先看下数据库结构……

找到 3 张相关表：users（含 city 字段）、orders（含 created_at 字段）、page_views（含 page、user_id 字段）。

转化率 = 下单数 / 浏览过商品页的用户数。

我会跑这段 SQL：

WITH viewers AS (
  SELECT DISTINCT u.city, pv.user_id
  FROM page_views pv
  JOIN users u ON u.id = pv.user_id
  WHERE pv.page LIKE '/product/%'
    AND pv.created_at >= date_trunc('month', current_date - interval '1 month')
    AND pv.created_at <  date_trunc('month', current_date)
),
buyers AS (
  SELECT DISTINCT u.city, o.user_id
  FROM orders o
  JOIN users u ON u.id = o.user_id
  WHERE o.created_at >= date_trunc('month', current_date - interval '1 month')
    AND o.created_at <  date_trunc('month', current_date)
)
SELECT
  v.city,
  COUNT(DISTINCT v.user_id) AS viewers,
  COUNT(DISTINCT b.user_id) AS buyers,
  ROUND(COUNT(DISTINCT b.user_id)::numeric / COUNT(DISTINCT v.user_id) * 100, 2) AS conv_rate_pct
FROM viewers v
LEFT JOIN buyers b ON b.user_id = v.user_id AND b.city = v.city
GROUP BY v.city
HAVING COUNT(DISTINCT v.user_id) > 100
ORDER BY conv_rate_pct DESC
LIMIT 10;

是否执行？(y 确认)

你：y

Claude：执行结果：

city	viewers	buyers	conv_rate_pct
杭州	4521	612	13.54
深圳	6890	891	12.93
上海	8210	1023	12.46
...	...	...	...

我顺便画了一张柱状图：~/Desktop/conv_rate_2026_03.png

一段简短解读：杭州虽然浏览人数不是最多，但转化率排名第一，可能与近期杭州站的精准投放有关。建议拉一下杭州的渠道来源，看看是哪条线带来的高转化。

你看到了什么？

1. Claude 自己读懂了数据库结构，知道有哪些表、哪些字段。
2. Claude 自己写出 SQL，还做了"转化率怎么算"的合理假设（用浏览过商品页的用户做分母）。
3. 跑之前问你确认——这是数据库类操作的安全护栏。
4. 顺手出图、给解读、提建议下一步。

整个过程你没写过一个字符的 SQL。

5.3 案例 2：每周自动数据周报

/loop 创建一个名为 weekly-data-report 的任务,每周一上午 9:00 触发:

1. 从 postgres 拉取以下指标(本周 vs 上周 vs 去年同期):
   - DAU(日活)
   - 新增注册
   - 付费转化率
   - 客单价
   - 订单数

2. 计算环比 / 同比变化(百分比),涨跌≥10% 的标黄/红

3. 用 matplotlib 画 5 张趋势图(过去 12 周),保存到 ~/Reports/charts/

4. 自动写一段"本周亮点 + 本周问题"(各 3 条):
   - 亮点: 涨幅最大的指标 + 一句猜测原因
   - 问题: 跌幅最大的指标 + 一句猜测原因
   - 不要瞎猜,只用数据本身能支撑的解读

5. 输出 Markdown 周报,模板:
   # 数据周报 - W{周数}

   ## 一句话总结
   ## 关键指标
   (表格)
   ## 趋势图
   (5 张图)
   ## 本周亮点
   ## 本周问题
   ## 下周建议关注

6. 转 PDF,发到老板邮箱 + 抄送我自己

老板视角的真实反馈

一位真实读者（电商运营总监）说：

以前我每周一花 4 小时出周报，老板花 5 分钟看。现在 Claude 花 2 分钟出周报，我花 30 分钟"对着周报想下一步"——这才是正经分析师该做的事。

5.4 案例 3：异常告警（不用人盯）

每 30 分钟自动执行一次:

1. 拉取最近 30 分钟的关键指标:
   - 订单数
   - 支付成功率
   - API P99 延迟
   - 错误率

2. 与"过去 7 天同时段平均值"对比:
   - 偏离 > 3σ(三个标准差): 红色告警
   - 偏离 > 2σ: 黄色提醒
   - 正常波动: 不打扰

3. 红色告警:
   - 立即通过 飞书机器人 推送到告警群
   - 内容包括: 哪个指标 / 偏离多少 / 同时段历史均值 / 当前值
   - 附 1–3 条"可能原因"(基于上下文猜测,不是确定结论)
   - 附"建议立即排查"清单

4. 黄色提醒只写日志,不打扰

5. 红色告警 30 分钟内重复触发,不再发(避免刷屏)

数据分析师的核心收益是把"看数字"压到 0,把"想下一步"留给自己。Claude 是你的"数字眼睛 + SQL 手指",但"判断"始终是你的。

5.5 进阶：零基础三步上手数据分析

如果你从来没写过 SQL，看到上面的 SQL 段落可能会"心悸一下"。其实你完全不需要懂——下面这三步是真实读者验证过的"零基础上手数据分析"路径：

第一步：让 Claude 描述你的数据库（5 分钟）

请连接 postgres 数据库,然后给我画一份"数据库地图":
1. 列出所有的表(按字母排序)
2. 对每张表:
   - 主要字段是什么(只列 5–8 个最常用的)
   - 这张表大致存的是什么(一句话)
   - 数据量(行数)
3. 表与表之间的关系(谁是谁的外键)
4. 用 Mermaid 语法画一张 ER 图
5. 在最下面标注"3 个最常被业务问到的问题",并给出"应该用哪些表回答"

输出到 ~/Desktop/db-map.md

跑完之后，你拥有了一份"数据库地图"。以后无论问什么问题，Claude 都会基于这份地图找答案——也意味着你随时可以打开它看一眼，学会自己也能问的"问题模板"。

第二步：用"业务问题"代替"SQL 问题"（30 天）

不要尝试学 SQL。直接用业务语言问：

Claude 会自己写 SQL，自己跑，自己出图。30 天问 30 个不同的问题之后，你对自己的数据已经比 99% 的同行更熟。

第三步：把高频问题固化成"一键面板"（第二个月）

跑了一个月之后，你会发现每周自己问的问题就那 10 个。把它们打包成一个"日常面板"：

请创建一个名为 daily-dashboard 的 Skill:

每天上午 9:00 自动执行,用一份 Markdown 文件回答以下 10 个问题:

1. 昨天的总订单数 vs 前 7 天均值
2. 昨天的总 GMV vs 前 7 天均值
3. 昨天的新增注册用户数 vs 前 7 天均值
4. 昨天的复购率(7 日内)
5. Top 5 商品(按销量)
6. Top 5 城市(按 GMV)
7. 异常订单(金额 > 99 分位)的清单
8. 退款金额 vs 前 7 天均值
9. 客服反馈的 Top 3 标签
10. 一句"昨日整体健康度"评级(优 / 良 / 中 / 差)

输出到 ~/Reports/daily/YYYY-MM-DD.md
然后通过 飞书机器人 推送到我的频道

第二个月开始,你不需要"分析数据"——数据每天主动来你眼前找你, 你只需要扫一眼"红色 / 黄色"的部分,做出判断.

这才是数据分析师 2.0 的工作姿势:不写 SQL,不出报表,只做判断.

5.6 工具清单

六、求职者画像

6.1 你每天的真实痛点

求职是一件**"重复 + 高情绪 + 高 ROI"**的事——投 100 份简历可能只有 3 个面试机会，每个机会又要花 10 小时准备。Claude Code 能帮你把"重复"压到 0，把"准备"压到 1 小时，让你把所有精力留给"面试本身"。

6.2 案例 1：简历定制器（一份基础版 → 100 份针对性版本）

提示词

@resume-base.md 是我的基础简历(包含过去 5 份工作 / 12 个项目 / 所有技能)。
@JD-target.md 是我看上的目标岗位 JD。

请生成一份针对性的强化版简历:

1. 从基础简历的 12 个项目中,挑出与 JD 最相关的 4–5 个,
   其他全部删除(不是隐藏,直接不出现)

2. 对挑出的项目,重新组织叙述:
   - 强调与 JD 关键词高度对应的部分
   - 量化成果(如果原文没有数字,提示我补)
   - 用 STAR 结构(Situation / Task / Action / Result)

3. "技能"部分按 JD 的优先级重排:
   - JD 必备技能放最前
   - JD 加分技能放第二档
   - 其他不写,避免稀释

4. 在简历最顶部加一段 3 句话的"个人陈述",
   显式回应 JD 里的 3 个最关键诉求

5. 整体长度: 中文 1.5 页 / 英文 1 页

6. 输出 2 份:
   - resume-CN.md (中文版)
   - resume-EN.md (英文版,且符合海外简历惯例,不要照译)

输出后,告诉我 3 件事:
- 这份简历"匹配 JD 的哪 3 条最强"
- "看起来薄弱的 1 条"
- "建议我面试前重点准备的 2 个故事"

Claude 真实反馈

Claude：已经生成。简评：

匹配最强的 3 条：

1. JD 要求"3 年以上 React 经验" — 你有 4 年（已突出）
2. JD 要求"带过 5 人以上团队" — 你在 ACME 项目带过 8 人（已加粗）
3. JD 要求"做过 SaaS 产品" — 你做过 2 个，挑了用户量更大的那个

看起来薄弱的 1 条： JD 提到"有海外业务经验加分" — 你没有，但你做的某项目有 30% 海外用户，已隐式带出。

面试前重点准备的 2 个故事：

1. ACME 项目：你怎么带 8 个人解决性能瓶颈（量化"页面加载从 4.2s 降到 0.8s"很亮眼）
2. SaaS 项目：你怎么从 0 到 1 设计计费系统，预期会被深挖

你看到了吗？ Claude 不只给你简历，还给你面试预案——这是它"AI 工作伙伴"的本质。

6.3 案例 2：批量投递（每天 10 个匹配岗位）

提示词

每天上午 10:00 自动执行:

1. 通过 LinkedIn MCP 搜索符合以下条件的岗位:
   - 关键词: "Senior Product Manager" / "高级产品经理"
   - 地点: 上海 / 远程
   - 公司规模: 200–2000 人
   - 行业: SaaS / 企业服务
   - 发布时间: 7 天内

2. 对每个岗位:
   a. 抓取 JD 全文
   b. 与我的基础简历 @resume-base.md 做匹配评分(0–100)
   c. 评分 ≥ 75 分的进入候选池

3. 候选池中挑出 Top 10,对每个岗位:
   a. 自动生成针对性的简历(参考 6.2 的流程)
   b. 自动生成一段 200 字的 cover letter
   c. 整理成"投递包": 简历 PDF + Cover Letter + JD 链接

4. 把投递包打包成压缩文件,发到我的邮箱
   主题: "今日投递候选 - YYYY-MM-DD - 共 N 个"
   正文: 一份 Markdown 表格,列出公司 / 岗位 / 匹配分 / 一句话推荐理由

5. !! 永远不要自动提交申请 !!
   等我看完打勾确认,再让我自己手动提交。
   AI 自动投递有被平台 ban 的风险。

注意最后那一条 —— 求职这件事，最后一公里必须是人在做。原因有两个：一是平台风控对自动化非常敏感，二是 cover letter 由你亲自检查一遍，质量会显著高于 AI 直接发出去的版本。

6.4 案例 3：模拟面试（让 AI 当面试官）

提示词

请基于 @resume-CN.md(我的简历) 和 @JD.md(目标岗位 JD),
模拟一场字节跳动产品经理 P6 的面试。

流程:
1. 你扮演面试官,我扮演候选人。

2. 整场面试 30 分钟,分 3 段:
   a. 自我介绍 + 简历深挖(10 分钟,3–5 个问题)
   b. 业务场景题(10 分钟,1 个大题,允许多轮追问)
   c. 反问环节(10 分钟,我问你答)

3. 提问要求:
   - 一次只问一个问题,等我回答完再问下一个
   - 简历深挖要"基于我简历的具体内容",不要套模板
   - 业务场景题要"贴合字节业务"(如抖音 / TikTok / 飞书 / 番茄小说)
   - 难度对标 P6(资深产品经理),不要太简单

4. 我每答完一题,你给:
   - 评分(0–10 分)
   - 1 句话点评(亮点 + 不足)
   - 一个"如果是更好的答案,会怎么说"的范例(≤ 100 字)

5. 整场结束后,你给:
   - 总分(0–100)
   - 录用建议(强烈推荐 / 推荐 / 待定 / 不通过)
   - 详细反馈(分维度: 业务理解 / 数据敏感度 / 沟通表达 / 抗压性)
   - 下次面试前的"3 个重点改进项"

准备好了吗?直接开始第一题。

按下回车，你就拥有了一个 24 小时随叫随到的字节面试官。每个问题答完都有点评，每场面试都有总评——比花 5000 块买培训班课程更直接、更针对你。

求职者的核心收益是让 AI 把"重复 + 准备"做到 90 分,你把全部精力放在"面试现场表现"。简历 / 投递 / 模拟面试这三件事是求职者时间的 80%,Claude Code 让它们退化成 10%。

6.5 进阶：5 种风格的模拟面试

光有"模拟字节面试官"还不够。不同公司的面试风格差异巨大，提前用对应风格练一练，正式面试时不会"水土不服"。

把下面这 5 种风格存成 5 个独立 Skill（路径：~/.claude/skills/mock-{name}/SKILL.md），需要时直接 /mock-{name}：

每个 Skill 的写法都类似 6.4 的提示词模板，只换"流程"和"打分维度"。一份完整的 mock-faang 示例：

---
name: mock-faang
description: 模拟 FAANG 公司的行为面试
when_to_trigger:
  - 用户提到"模拟谷歌面试"、"模拟亚马逊面试"、"模拟 Meta 面试"
---

# FAANG 行为面试模拟器

## 面试结构
- 开场:1 分钟自我介绍
- 4 个 STAR 行为题(每题 8–10 分钟)
  - 题 1: Leadership(带过的最难一个团队/项目)
  - 题 2: Conflict(和同事/老板分歧最大的一次)
  - 题 3: Failure(最大的一次失败,你学到了什么)
  - 题 4: Innovation(你做过的最有创意的一件事)
- 反问环节: 5 分钟

## 面试官风格
- 严格按 STAR 结构追问(Situation / Task / Action / Result)
- 数据 / 量化结果是必问的
- 不接受空洞回答,追问"具体怎么做的"
- 礼貌但坚持
- 全程英文

## 评分维度(每题 0–10 分)
- Structure(结构清晰): 0–3
- Specificity(细节具体): 0–3
- Impact(影响量化): 0–2
- Communication(表达流畅): 0–2

## 结束反馈
- 总分(0–40)
- 录用建议(Strong Hire / Hire / No Hire / Strong No Hire)
- 每题各给一条"高分版回答"参考
- 一句话总结"你应该重点准备什么"

把这 5 个 Skill 都装好之后，你的求职准备就有了"模拟训练营"——面字节前练一次 /mock-bytedance，面 FAANG 前练一次 /mock-faang。

6.6 工具清单

七、招聘者 / HR 画像

7.1 你每天的真实痛点

招聘者和求职者是同一件事的两面。求职者每天投 100 份简历，你每天就要看 100 份简历——这是行业最对称的痛点之一。

Claude Code 给招聘者三个直接收益：初筛、写问题、写 Offer。

7.2 案例 1：智能初筛（带 OCR 的版本）

行政场景里我们讲过简历筛选（4.3）。这里讲一个升级版——支持 OCR 的版本，专治"一堆图片版 PDF 简历"的问题。

处理 @resumes-batch/ 目录下的所有简历(混合: 文本 PDF / 图片 PDF / DOC / 截图 PNG):

1. 自动识别每份简历的格式:
   - 文本 PDF: 直接抽取
   - 图片 PDF / 图片: 用 OCR(Tesseract 或 PaddleOCR)
   - DOC / DOCX: 用 docx 解析

2. 提取标准字段:
   {
     "name": "...",
     "phone": "...",
     "email": "...",
     "current_title": "...",
     "current_company": "...",
     "years_of_experience": 0,
     "education": [{"school": "", "degree": "", "year": 0}],
     "skills": ["..."],
     "highlights": ["..."]  // 提取 3 条高光经历
   }

3. 与 @JD.md 匹配,按 JD 的"必备 / 加分 / 减分"三档打分

4. 输出 Top 20 候选人:
   - 表格形式,按总分降序
   - 每个候选人附一段"推荐沟通话术":
     "您好 [姓名],我是 [公司] 的招聘 [姓名],
      看到您在 [上一家公司] 做的 [具体项目],
      我们正在招 [岗位],很想和您聊一聊..."
     (注意"具体项目"要从简历里取真实内容,不要编造)

5. 输出"待人工复核"清单:
   - OCR 置信度 < 80% 的简历
   - 关键字段缺失(如电话 / 邮箱)的简历
   - 工作经历断档 > 1 年的简历(可能需要追问)

6. 处理完成后,删除临时 OCR 中间文件,只保留汇总

真实场景的体感

一个 200 人创业公司的招聘负责人反馈：

以前一个 JD 收 80 份简历，我要花一天看完。现在 Claude 花 10 分钟给我 Top 20 + 沟通话术，我把节省的时间全部花在"打电话给候选人"——签约率比以前高 40%。

7.3 案例 2：面试问题库（按候选人定制）

基于 @candidate-resume.pdf(候选人简历) 和 @JD.md(岗位 JD),
生成 10 个针对这个候选人的面试问题:

要求:
1. 3 个问题考察"简历真实性"
   - 针对简历里看起来最亮眼的项目深挖
   - 用"行为面试法"(让候选人讲具体故事)
   - 不要问"你能否做 XX"这种 Yes/No 问题

2. 3 个问题考察"岗位匹配度"
   - 针对 JD 的 Top 3 必备能力
   - 用"场景题"(给一个真实情境让他怎么处理)

3. 2 个问题考察"软技能"
   - 沟通 / 协作 / 抗压
   - 不要泛泛而问,结合候选人简历里的某个具体场景

4. 1 个"陷阱题"
   - 试探候选人是否会"瞎吹"
   - 比如问一个简历里没写但接近的细节

5. 1 个"反问题"
   - 给候选人一个机会反问我们
   - 不是真问题,是看他关心什么

每个问题附:
- 问题原文
- 我应该重点听什么(标准答案的关键词)
- 不通过的红线(回答出现什么内容直接 pass)

输出格式: Markdown,我会打印出来带进面试间。

面试官最大的失败是"问每个候选人都一样的问题"。Claude 把"针对每个候选人定制问题"压到 30 秒——这意味着你每场面试都能有信息密度。

7.4 案例 3：Offer 写作（中英对照，一键生成）

请生成一份正式 Offer Letter:

候选人信息:
- 姓名: 张三
- 岗位: 高级前端工程师
- 等级: P6
- 入职日期: 2026-05-06

薪资包:
- 月薪: 35,000 RMB
- 年终: 4 个月(目标)
- 股票: 5,000 股 RSU,4 年归属(1 年悬崖)
- 签字费: 30,000 RMB(分两期发,入职 + 满一年)
- 福利: 标准五险一金 + 补充医疗 + 14 天年假

要求:
1. 中英对照(中文 + 英文 PDF 各一份)

2. 中文版语气:
   - 正式但不冷冰冰
   - 第一段表达欢迎和期待
   - 末尾留"如有疑问联系 HR [姓名 + 邮箱]"

3. 英文版严格按硅谷公司 offer 模板:
   - Compensation 部分逐项列清楚
   - 必须含 At-will Employment 声明(中国版本不需要)
   - 必须含 Confidentiality 条款指引
   - 末尾留 e-signature 占位

4. 法律风险提示:
   - 自动检查是否有"承诺式"语句(承诺涨薪 / 承诺晋升等)
   - 如发现,标黄并备注"建议法务 review"

5. 输出 2 份 PDF + 2 份 source Markdown,
   存到 ~/HR/Offers/张三-2026-05-06/

写完之后 Claude 会给你一份已经过初步合规检查的 offer 模板。最终签字之前必须给法务过一遍——这是本章末尾红线之一。

7.5 工具清单

八、跨职业通用：会议纪要 / 周报 / 邮件

前面 7 个画像是"垂直场景"。下面 3 个场景是所有职业都用得上的——会议纪要、周报、邮件简报。它们看起来基础，但每周帮你省下的累计时间往往比专业场景还多。

8.1 会议纪要（录音 → 决议 + 待办）

完整提示词模板

把下面这一段保存成 ~/.claude/commands/meeting-notes.md，以后开完会调用 /meeting-notes 即可。

<role>
你是一位资深会议记录员,擅长把口语化的会议录音转成结构化纪要。
你不编造,不夸大,不漏掉决议。
</role>

<task>
处理用户提供的会议录音文件(MP3 / MP4 / WAV / M4A),
按 <format> 输出。
</task>

<workflow>
1. 用 whisper(本地)或 OpenAI Audio API(云端,二选一)
   把录音转成带时间戳的逐字稿
2. 阅读逐字稿,提取:
   - 会议基本信息(时间 / 时长 / 与会人)
   - 讨论的核心议题(3–5 个)
   - 每个议题下的"已达成共识"和"未达成共识"
   - 待办事项(必须有: 事项 / 负责人 / 截止日期)
   - 下次会议要带的预备材料
3. 输出按 <format> 模板填好
</workflow>

<constraint>
- 不编造与会人没说过的话
- 待办事项的"负责人"必须是真实出现过的名字,如果模糊就标 [待确认]
- 截止日期必须是 YYYY-MM-DD 格式,如果会议里没说,标 "TBD"
- 全程使用第三方语气(不要"我们"开头)
- 涉及金额 / 数字的地方,引用原话(用引号)
</constraint>

<format>
# 会议纪要 - {议题}

## 一、基本信息
- 时间: YYYY-MM-DD HH:MM-HH:MM
- 时长: X 分钟
- 与会人: A / B / C / D

## 二、议题与共识
### 议题 1: {议题}
- 已达成: ...
- 未达成 / 后续讨论: ...

(重复议题 2、3...)

## 三、待办事项
| # | 事项 | 负责人 | 截止日期 | 备注 |
| - | --- | --- | --- | --- |

## 四、下次会议
- 时间: TBD / YYYY-MM-DD
- 预备材料:
  - ...

## 五、原文金句(可选)
> "..."(谁,几分几秒)
</format>

调用方式

/meeting-notes
(然后把录音文件拖进对话框,或用 @audio.m4a 引用)

跑完之后你会拿到一份直接可以群发的会议纪要。原本一个人花 1 小时整理的活，Claude 用 3 分钟干完。

8.2 周报自动起草

请帮我起草这周的周报,数据来源:

1. Git: @~/Projects/myproject
   抓取本周(周一 0:00 到周五 18:00)我提交的所有 commit
   (我的 git email: me@example.com)

2. Notion: 通过 notion MCP,拉取本周内我创建/修改的所有页面

3. Gmail: 通过 gmail MCP,统计本周发件数 / 收件数 / 关键邮件主题

4. 日历: 通过 google-calendar MCP,本周参加的所有会议(含时长)

整理成"团队公司模板"的周报:

# 周报 - {姓名} - W{周数}

## 本周完成
1. {事项}: {描述,带数据}
2. ...

## 本周进度推进中
1. ...

## 下周计划
(保留 3 段空白,我自己填)

## 风险与求助
(保留 1 段空白,我自己填)

## 个人复盘
(保留 1 段空白,我自己填)

要求:
- "本周完成"必须是"动词 + 名词 + 量化结果",不要描述过程
- 同类工作合并(比如 5 个 bug 修复合成"修复 5 个 bug,涉及 X / Y / Z 模块")
- 不要写"持续学习 / 持续优化"这种废话
- 长度 ≤ 800 字

三段空白是关键——周报里"自己的判断"是别人无法替代的部分。Claude 帮你填掉前面的"事实"，把脑力留给后面的"判断"。

8.3 邮件三句话简报

痛点

每天打开邮箱看到 80 封未读，80% 的邮件你扫一眼就 archive，但前面那 5% 的重要邮件经常被淹没。

提示词

每天上午 8:30 自动执行:

1. 通过 gmail MCP 拉取过去 24 小时(昨天 8:30 到今天 8:30)的所有邮件
   只看收件箱,不看垃圾邮件 / 已归档

2. 对每封邮件分类:
   - 重要紧急(老板 / 客户 / 已知关键域名): 红色
   - 重要不紧急(同事 / 工作流): 黄色
   - 不重要紧急(账单 / 平台通知): 灰色
   - 不重要不紧急(广告 / 订阅推送): 白色

3. 对红色 + 黄色邮件,每封写一段"三句话简报":
   - 第一句: 谁发的 / 主题
   - 第二句: 核心诉求(他想让我做什么)
   - 第三句: 建议回复时机(立刻 / 今天内 / 本周内 / 不必回)

4. 灰色和白色不写简报,只统计数量

5. 输出一份 Markdown 简报:
   # 昨夜今晨邮件简报 - YYYY-MM-DD

   ## 红色: 立即处理(共 N 封)
   1. ...

   ## 黄色: 今日内处理(共 N 封)
   1. ...

   ## 灰色: 共 N 封(自动归档)
   ## 白色: 共 N 封(已自动标记已读)

6. 把简报推送到飞书 / 微信 / 桌面通知(三选一)

"重要紧急矩阵"由 Claude 帮你做, 你只看红+黄两档. 一个普通职场人每天能省下 30–40 分钟"翻邮件 + 决定优先级"的脑力消耗.

升级：自动起草回信草稿

红色和黄色邮件，可以再加一步——自动起草回信草稿：

对每封红色和黄色邮件:

1. 起草一份 200 字以内的回信草稿
2. 草稿要符合我的语气(参考 @my-emails-style.md, 收录我过去 50 封代表性回信)
3. 草稿存到 Gmail 草稿箱, 不发出去
4. 在简报里附"草稿链接", 我点开微调一下就能发

Claude 替你写, 你过一遍 + 改一改 + 按发送——一封邮件从 5 分钟压到 30 秒。

8.4 三件套的"协同效应"

会议纪要、周报、邮件简报这三件事，如果你只用其中一个，节省的时间是线性的。但当你三件一起用,会产生指数级的协同——

会议纪要(8.1)
    ↓ 自动生成的"待办事项"
   Notion 里的待办池
    ↓ 周一 8:00 自动同步
邮件简报(8.3)的"今日重点"
    ↓ 周五 17:00 自动汇总
   周报(8.2)的"本周完成"
    ↓ 老板每周一上午看
   下次会议的"上周回顾"议题

把这条流串起来，你会发现一件惊人的事：你不再需要"写"任何东西。会议纪要由 Claude 写，待办由 Claude 整理，每日简报由 Claude 推送，周报由 Claude 起草——你只做"判断"和"沟通"。

一个真实读者（某 SaaS 公司产品总监）描述他用了三件套之后的状态：

我一周的"打字时间"从 25 小时降到 4 小时。剩下的 21 小时，我去见了 6 个客户、面试了 8 个候选人、做了 3 场内部分享。这 21 小时换回来的产出，是我这家公司过去 3 年从没体验过的"高产周"。

九、本章 7 大职业的工作流总览表

把上面 7 个画像浓缩成一张表，方便你回查 + 给团队同事推荐：

怎么用这张表？

1. 找到自己的画像那一行，把"核心 Skill / 核心 MCP / 最高 ROI 提示词"三栏抄到自己的笔记本上。
2. 第一周只装一个 Skill + 一个 MCP，把"最高 ROI 提示词"跑通。
3. 第二周再装第二个——一周一个的节奏，一个月装 4 个，足够覆盖你 80% 的痛点。
4. 节省的时间用来干什么？ 这是真正的关键问题。本章节省的时间不是为了让你"更卷"，而是为了让你能去做"AI 永远做不了的事"——见客户、做判断、和团队聊天、思考下一步战略。

十、避坑：工作场景的 5 条红线

工作场景比生活场景更敏感——对方可能是客户、是领导、是法务、是公司。下面 5 条红线，不管你装多熟练，都不要碰。

红线 1：永远不要让 AI 自动发邮件给客户

无论 Claude 写得多好，最后一公里必须是你按"发送"键。原因：

• 客户邮件涉及承诺、价格、时间——任何一个细节出错都是事故
• AI 偶尔会"过度礼貌"或"过度激进"，需要你判断语气
• 万一被反诈系统识别为"AI 群发"，你的邮箱信誉会下降

正确姿势：让 Claude 把回信存到草稿箱，你打开微调一下再发。这一步只多花 30 秒，但风险下降 99%。

红线 2：不要把客户的隐私数据丢给联网模型

如果你的工作涉及客户的真实姓名、身份证、财务数据——默认情况下不要直接发给云端模型。

正确姿势有两种：

1. 用本地模型：装 Ollama + 一个本地小模型（如 Qwen / Llama），数据全程不出你电脑。Claude Code 支持通过 router 把请求路由到本地（第三章方案 B 讲过）。
2. 先脱敏再上传：在发给云端之前，用一个简单的脚本把"姓名 / 身份证 / 卡号"替换成 placeholder，等返回结果后再替换回真实值。Claude 自己就能写这个脱敏脚本。

一句话原则：任何"如果泄露你会被开除"的数据，永远不要直接进云端模型。

红线 3：自动报表必须有人 review 一遍再发

哪怕周报 / 月报跑得再稳定，第一次发给老板 / 客户之前必须有人扫一眼。原因：

• 数据库结构可能变了，Claude 没察觉
• 上游数据可能有脏数据（比如某天少录了一半订单），Claude 不会知道
• 报表里的"涨幅 200%"可能只是因为分母变小了，需要人解读

正确姿势：把所有自动报表先发到你自己的邮箱，确认无误后再转发给目标对象。中间多 5 分钟人工 review，避免 99% 的尴尬。

红线 4：AI 写的代码上生产前必须 code review

如果你是非程序员，但用 Claude Code 帮你做了 landing page / 自动化脚本——上生产之前必须找一个真程序员看一眼。

哪怕 Claude 写得很对，可能也有：

• 隐藏的安全漏洞（XSS / SQL 注入 / 暴露 API Key）
• 性能问题（一个请求查 10 万条数据）
• 不符合公司规范的代码风格

正确姿势：把 Claude 生成的代码发给程序员同事，请他用 5 分钟扫一眼"有没有明显问题"。这一步不是怀疑 Claude，而是怀疑"你的需求是否描述完整"。

红线 5：涉及合同 / 法务 / 财务的 AI 输出，仅供参考

合同条款、offer letter、税务咨询、政策解读——Claude 的输出永远只是初稿，最终必须人工确认。

最常见的事故：

• Claude 写的 offer letter 里漏了"试用期"条款
• Claude 解读的合同里把"乙方"和"甲方"搞反
• Claude 给的税务建议参考了过期政策

正确姿势：

• 合同 → 法务必看
• Offer → HR 主管 + 法务必看
• 税务 → 会计必看
• 政策 → 自己再去官方网站核对一遍

Claude 的角色是"实习生 + 资料员"，不是"专业人士"。这个心理预期摆正了，所有红线都不容易踩。

5 条红线一图速记

┌─────────────────────────────────────────┐
│  能让 Claude 自动做的:                    │
│  - 抓取数据 / 整理资料                    │
│  - 起草草稿(邮件 / 报告 / 合同 / 文案)    │
│  - 推送给"自己"做最终确认                 │
├─────────────────────────────────────────┤
│  绝不能让 Claude 自动做的:                │
│  - 把草稿直接发给客户/领导/法务对象       │
│  - 把含真实隐私的数据上传云端             │
│  - 跳过 code review 直接上生产            │
│  - 按 AI 解读签合同 / 走法务流程          │
│  - 让 AI 替你"决策"任何不可逆的事         │
└─────────────────────────────────────────┘

记住这一段，剩下的就是放手用。

本章一图回顾

                  Claude Code
                       │
                       │
           ┌───────────┼───────────┐
           │           │           │
       ┌───▼───┐   ┌───▼───┐   ┌───▼───┐
       │ Skills │   │  MCP  │   │ /loop │
       └───┬───┘   └───┬───┘   └───┬───┘
           │           │           │
           └───────────┼───────────┘
                       │
                       ▼
       ┌──────────────────────────────────┐
       │       7 大职业 × 3 件事            │
       │   (整理 / 起草 / 自动调度)         │
       └──────────────────────────────────┘
                       │
       ┌─────┬─────┬───┴──┬─────┬─────┬─────┐
       │     │     │      │     │     │     │
       ▼     ▼     ▼      ▼     ▼     ▼     ▼
     写作  营销  设计   行政  数据  求职   招聘
       │     │     │      │     │     │     │
   多平台 竞品  Figma  合同  SQL  简历  OCR
   改写   监控  转码   对比  转译 定制  初筛
       │     │     │      │     │     │     │
       └─────┴─────┴──────┴─────┴─────┴─────┘
                       │
                       ▼
       ┌──────────────────────────────────┐
       │   通用三件套: 会议纪要 / 周报 / 邮件 │
       └──────────────────────────────────┘
                       │
                       ▼
       ┌──────────────────────────────────┐
       │    每周节省 5–10 小时(平均)        │
       │    每月节省 20–40 小时(累计)       │
       └──────────────────────────────────┘
                       │
                       ▼
       ┌──────────────────────────────────┐
       │     5 条红线: 不让 AI 决策         │
       │     不发外部 / 不传隐私 / 不跳审 │
       └──────────────────────────────────┘

下章预告

讲完非程序员的场景，下一章我们正式回到老本行——第八章 编程与代码场景，专门写给程序员朋友。

如果你不写代码，第八章你可以直接跳过；如果你写代码，下一章你会看到：

• /init 一键把 Claude Code 配进你的项目
• 让 Claude 在 5 分钟内读懂一个百万行的陌生代码库
• 用 Plan Mode 让它先列计划再动手，避免"AI 一通乱改"
• 改 Bug、写测试、做 Code Review、自动 commit message
• Subagents 并行调度：让"便宜模型干粗活，贵模型干细活"
• 真实案例：从 0 到 1 用 Claude Code 写一个 Chrome 插件 / Telegram 机器人 / 数据看板

如果你既不写代码也想了解一下"AI 怎么帮程序员干活"，第八章也很值得读——因为里面所有的方法论都可以"反向"用到非编程场景：项目化思维、计划模式、并行调度，本质上是工作方法论，和具体行业无关。