附录 B 30 个开箱即用提示词

速查目录

编程类（10 条）

01 项目首次理解

适用场景：刚拿到一个新项目（自己接手别人的代码 / 新公司入职 / 开源项目调研）。 推荐模型：Sonnet 4.5 前置：cd 到项目根目录，确保有 .git/ 和 README.md。

你是一名资深架构师，第一次接手这个项目。请按以下顺序产出一份《项目快速理解报告》：

1. 项目类型与目的（前端 / 后端 / 全栈 / 工具 / 库）
2. 技术栈清单（语言、框架、数据库、部署方式）
3. 目录结构图（用 tree 风格画前 3 层）
4. 关键模块及其职责（≤ 8 个）
5. 入口文件与启动命令
6. 依赖外部服务清单（数据库、第三方 API、消息队列等）
7. 看代码后我最该警惕的 3 个潜在风险（命名混乱 / 缺测试 / 硬编码密钥 / 等）
8. 给我一份"今天该做的 3 件熟悉性任务"清单

输出全部用中文 markdown，控制在 800 字内。引用文件请用 @相对路径 格式。

02 5-Why 找根因

适用场景：测试挂了 / 部署失败 / 用户报错，想找根本原因而不是表面症状。 推荐模型：Opus 4.7（思考深度优先） 前置：把报错或日志贴出来，或 @日志文件路径。

你是一名根因分析专家。我遇到这个问题：

【在这里贴报错或描述现象】

请用 5 Why 法步步推：
- Why 1：表面原因
- Why 2：表面原因之下
- Why 3：再下一层
- Why 4：再下一层
- Why 5：根本原因（系统设计 / 流程 / 人）

每一层都要给出"判定依据"（看了哪个文件 / 跑了哪个命令 / 引用了哪段日志）。最后给出 3 个针对根本原因的修复建议，按性价比排序。

不要直接给修复代码，只做诊断。

03 单文件全函数测试生成

适用场景：想给某个文件加单元测试，但函数太多懒得手写。 推荐模型：Sonnet 4.5 前置：项目里已有测试框架（pytest / jest / vitest 等），用 @文件路径 指定。

请为 @【文件路径】 中的所有公开函数生成单元测试。要求：

约束：
- 测试框架：【pytest / jest / vitest】
- 测试文件位置：【tests/ 或 与源文件同目录的 *.test.ts】
- 命名约定：`test_<函数名>_<场景>`
- 每个函数至少 3 个用例：正常 / 边界 / 异常
- mock 外部依赖（数据库、网络、文件系统）
- 不要修改原函数

格式：
1. 先列出"将要为哪些函数生成测试"清单（dry-run）
2. 等我说"go"再正式写文件
3. 写完后跑一遍测试，给出通过 / 失败统计

04 安全的批量重构

适用场景：要把一个旧 API 名替换成新名 / 重命名一个变量 / 替换一个废弃库。 推荐模型：Sonnet 4.5 前置：项目用 git 管理且工作区干净（git status 没有未提交修改）。

请把项目里所有的 【旧名/旧 API】 替换成 【新名/新 API】。安全要求：

约束（必须严格遵守）：
- 先用 grep / ripgrep 列出所有匹配位置，按"文件 + 行号 + 上下文 3 行"展示
- 排除：node_modules / dist / build / .git / 测试快照文件
- 区分大小写
- 替换时不要破坏字符串字面量内的同名子串
- 替换前给我看 diff，得到我"go"后再写入文件
- 替换完跑测试，失败立刻 git restore 回退该文件

输出格式：
1. 阶段一：匹配清单（含数量统计）
2. 阶段二：等待我确认
3. 阶段三：dry-run diff
4. 阶段四：执行 + 测试 + 报告

05 PR 描述生成器

适用场景：写完一个功能，准备发 PR，不想手写描述。 推荐模型：Sonnet 4.5 前置：在功能分支上，已 commit 改动。

请基于 git diff main..HEAD 生成一个完整的 PR 描述。结构：

## 这个 PR 做了什么
（1-2 句业务语言，让 PM 看得懂）

## 为什么这么做
（背景 / 用户痛点 / 链接到 issue）

## 关键改动
- 文件 1：变了什么
- 文件 2：变了什么
（按文件分组，标注是新增 / 修改 / 删除 / 重构）

## 测试
- 跑了哪些测试，结果如何
- 截图 / curl / 复现步骤（可选）

## 风险与回滚
- 这次改动可能影响哪些场景
- 出问题如何回滚（git revert <commit> 或其他）

## Checklist
- [ ] 测试通过
- [ ] 无破坏性变更（或已在描述中说明）
- [ ] 已更新文档（如有需要）

输出 markdown，不要超过 400 字主体（不含 checklist）。

06 自动 Code Review

适用场景：自己 review 自己的 PR，或给别人提初步意见。 推荐模型：Opus 4.7（找深层问题用 Opus） 前置：当前在分支 feat/xxx，main 已 fetch 到 origin/main。

你是一名 staff 工程师，请 review 当前分支相对 main 的所有改动。

review 维度（按重要性排序，每条都要给"具体文件:行号"）：

1. 正确性
   - 逻辑 bug
   - 边界条件
   - 错误处理
   - 并发 / 异步坑

2. 安全
   - 鉴权 / 授权
   - 注入（SQL / XSS / 命令）
   - 敏感数据（密码 / token / PII）

3. 性能
   - O(n²) 之类的复杂度问题
   - 不必要的网络 / 数据库调用
   - 内存泄漏

4. 可维护性
   - 命名 / 抽象层次
   - 重复代码
   - 注释质量
   - 测试覆盖

5. 风格
   - 项目约定（参考 @CLAUDE.md）
   - lint 通过情况

输出格式：
- 🔴 必改（blocker）
- 🟡 建议改（nit）
- 🟢 加分项（compliment）

最后给一个总评分（A-F）+ 一句话总结。不要客气，但要给出可操作的建议。

07 API 文档生成

适用场景：写完一组 REST API，要给前端 / 客户对接文档。 推荐模型：Sonnet 4.5 前置：API 路由文件路径。

请基于 @【路由文件路径】 生成一份 API 文档。每个端点包含：

- 路径与方法（GET / POST / PUT / DELETE）
- 一句话说明
- 鉴权要求（无 / Bearer Token / API Key）
- 请求参数（path / query / body，含类型 / 是否必填 / 示例）
- 响应（200 / 400 / 401 / 500，含 JSON 示例）
- curl 调用示例
- 常见错误及处理方式

约束：
- 用 markdown 表格
- 字段类型用 TypeScript 风格（string / number / boolean / Date）
- 示例 JSON 要真实可用，不要 "string" / "value" 这种占位
- 全部端点放到一个文件 docs/API.md

如果某个端点参数不清楚，列出"需要我补充信息的地方"清单，不要瞎编。

08 数据库迁移脚本

适用场景：要给现有数据库加字段 / 改约束 / 拆表。 推荐模型：Sonnet 4.5 前置：项目用了 migration 工具（Prisma / Alembic / Flyway / Liquibase）。

请生成一份数据库迁移脚本，需求：

【在这里说"给 users 表加 phone_verified 字段"等具体需求】

约束：
- migration 工具：【Prisma / Alembic / Flyway / Liquibase】
- 必须是可逆的（提供 up + down）
- 不能锁表超过 5 秒（大表加字段用在线 DDL）
- 默认值要有，不能让现有数据违反非空约束
- 如涉及外键，先看下 @【相关模型文件】 确认依赖关系
- 兼容性：本次改动若让旧版本应用读不出新字段，需在 PR 描述里标"先发应用、再发 DDL"或反之

输出：
1. 迁移文件（up + down）
2. 迁移命令（怎么 apply、怎么 rollback）
3. 部署顺序建议（应用 / DDL 先后）
4. 风险点提醒

09 错误日志聚类分析

适用场景：生产环境一天生成几万条 error log，想知道"今天有几类错"。 推荐模型：Sonnet 4.5 前置：日志文件路径，或可访问日志查询的 MCP（Datadog / ELK）。

请分析 @【日志文件路径或时间范围】 中的 error 级别日志，做聚类分析：

步骤：
1. 提取所有 error 行
2. 按"错误类型"聚类（异常类名 + 关键栈帧 + 上下文）
3. 每类给出：
   - 出现次数
   - 首次 / 末次出现时间
   - 一段典型日志样例
   - 推测的可能原因
   - 影响估计（用户数 / 业务流程）
4. 按"次数 × 影响"排序
5. 给前 5 类各推荐一个修复方向

输出 markdown 表格 + 每类一段简要分析。如果数据超过 10 万行，先采样 10% 给我看初步结果，问我要不要继续全量。

10 性能瓶颈诊断

适用场景：某个接口慢 / 某个页面卡 / 某段脚本跑太久。 推荐模型：Opus 4.7 前置：相关代码文件路径。

你是一名性能优化专家。我遇到性能问题：

现象：【在这里描述，比如"GET /api/orders 平均响应 2.5 秒，p99 12 秒"】

相关代码：@【文件路径们】

请分阶段诊断：

阶段一：纸面分析
- 列出可能的瓶颈（数据库 / 网络 / CPU / 内存 / 锁 / IO）
- 按"概率 × 修复成本"排序

阶段二：诊断方案
- 每个怀疑点对应"怎么验证"（哪个 metric / 加什么 log / 跑什么 profile）
- 给出具体命令或代码片段

阶段三：修复方向
- 短期止血（1 天内能上）
- 中期优化（1 周内能上）
- 长期重构（架构层面）

约束：
- 不要直接改代码，只做分析
- 任何"假设"都要明确标出"待验证"
- 引用真实的代码行号

工作类（10 条）

11 周报自动生成

适用场景：每周五写周报，想从 commit / Linear / 邮件里自动汇总。 推荐模型：Sonnet 4.5 前置：装好相关 MCP（GitHub / Linear / Slack / Gmail，按需）。

请帮我生成本周（周一到今天）的工作周报。数据源：

- GitHub：我（@【用户名】）的 PR、commit、review
- Linear：我负责的 issue 状态变化
- 日历（如有）：本周关键会议
- Slack（可选）：我在 #【频道名】 里发的关键消息

输出结构：

## 本周完成
（按项目 / 模块分组，每条 1 行，写"产出"而不是"动作"，比如"上线 X 功能"而不是"提交了 5 个 PR"）

## 进行中
（仍在做但本周未完成的，标预计完成时间）

## 阻塞 / 风险
（需要老板或同事支持的事）

## 下周计划
（按优先级 1-2-3 列）

## 数据
- PR 数：X 个（合并 X，待 review X）
- Issue 完成：X / X
- 评审他人 PR：X 个

约束：
- 不超过 500 字
- 用第一人称
- 项目名脱敏成 P1/P2/P3，最后给我一份"对照表"我自己改
- 别夸张，别抒情，别用 emoji

12 会议纪要 → 行动项

适用场景：开完会，把录音转写或聊天记录扔过来，要 To-Do。 推荐模型：Sonnet 4.5 前置：会议文字稿。

请把以下会议文字稿转换成结构化纪要：

【在这里粘贴文字稿，或 @文件路径】

输出：

## 会议元信息
- 时间 / 时长 / 与会者

## 核心议题
（≤ 3 个）

## 关键讨论
（每个议题 2-3 句要点，不抄原话）

## 决策
（明确"决定 X"，没决定的列入"待决策"）

## 行动项
| Owner | Action | Due | 验收标准 |
| --- | --- | --- | --- |

## 待决策
（需要补充信息或更高层拍板）

## 下次会议
（如约定）

约束：
- 行动项必须有 owner 和 deadline，没说的标 TBD 提醒我补
- 不要把"思考""讨论"误认为"决策"
- 涉及金额 / 客户 / 法律的关键事实原文引用

13 多平台内容改写

适用场景：写了一篇博客，要发知乎、微信、小红书、Twitter / X、即刻。 推荐模型：Sonnet 4.5 前置：原文路径或粘贴。

请把以下原文改写成 5 个平台的版本：

原文：@【文件路径】

平台与风格指南：

1. **知乎**：800-1500 字，结构化（小标题 + 列表），开头一段抛问题或观点，中段论证，结尾总结，最后一句"觉得有用就点赞"
2. **微信公众号**：1000-2000 字，开头"hook"，中间小节用 emoji 分隔（除非用户禁用），结尾"在看 / 转发 / 关注"
3. **小红书**：300-500 字，emoji + 短句 + 分行，标题党（但不夸大事实），结尾 5-10 个 #话题
4. **X / Twitter**：≤ 280 字，一条主推文 + 2-3 条 reply 串
5. **即刻**：500-800 字，第一人称，有故事感，少用结构化，结尾抛个开放问题

约束：
- 核心观点和数据必须一致
- 不要在小红书里说"详见我公众号"——平台不喜欢导流
- X 的链接放最后一条 reply，不放主推文（算法不喜欢）
- 全部输出，每段前用 ### 平台名 分隔

14 竞品监控简报

适用场景：每周看一遍 3-5 家竞品的官网 / 博客 / 招聘页。 推荐模型：Sonnet 4.5 前置：装好 WebFetch 或 Playwright MCP。

请帮我做本周竞品监控。竞品列表与监控点：

| 公司 | 监控页面 |
| --- | --- |
| 【A 公司】 | https://A.com/blog, https://A.com/careers |
| 【B 公司】 | https://B.com/changelog, https://B.com/pricing |
| 【C 公司】 | https://C.com/blog |

任务：
1. 抓取每个 URL 的最新内容
2. 对比上周抓取的版本（@logs/lastweek-snapshot.json，如有）
3. 找出"本周新增 / 重大变化"

输出：

## 一句话本周提要
（30 字内，最重要的一件事）

## 公司 A
- 新博客 / 公告：……
- 招聘变化：……
- 推测意图：……

## 公司 B
（同上）

## 公司 C
（同上）

## 行动建议
- 我们应不应该跟进 X
- 是否需要重新审视我们的 Y

约束：
- 不要抄原文，做"翻译 + 推测"
- 推测要标"⚠ 推测"
- 找不到变化的就写"无显著变化"，不要硬找
- 总长度 ≤ 600 字

15 简历定向优化

适用场景：投某个具体岗位前，让 Claude 把简历改成"对症下药"。 推荐模型：Opus 4.7 前置：原始简历 + 岗位 JD。

我要投这个岗位：

【粘贴 JD 全文，或 @jd.txt】

我的现有简历：@my-resume.md

请：

1. 解析 JD：
   - 必备技能 / 加分技能
   - 隐含要求（不写但能看出来的，比如"快节奏环境"=抗压、"独立完成"=自驱）
   - 关键词清单（ATS 系统会扫的）

2. 评估匹配度（0-100），说明扣分项

3. 改写简历：
   - 标题党：把"实习生"改成"X 项目核心成员"等（基于事实）
   - 项目排序：相关度高的排前
   - 关键词植入：自然嵌入 JD 关键词，不堆砌
   - 数字化：能加数字的全加（"提升 30%""节省 50 小时/月"）
   - 删减：跟岗位无关的项目精简或删掉
   - 长度：1-2 页

4. 给我一份"面试可能被问到的 5 个问题 + 标准回答框架"

输出：
- 修改后的简历（直接 markdown）
- 一份"修改说明"对照表（什么改了 / 为什么）
- 问题清单

16 面试问答自检

适用场景：明天要面试，今晚自己模拟一轮。 推荐模型：Sonnet 4.5 前置：岗位 JD + 你的简历。

你是一位资深面试官，岗位是 【职位名】，公司是 【公司名/类型】。我是候选人，简历是 @my-resume.md。

请按真实面试流程出题：

1. **暖场**（2 题，5 分钟）
   - 自我介绍
   - 为什么投这家

2. **行为面**（4 题，15 分钟）
   - STAR 框架的题，覆盖：
     - 一次失败 / 复盘
     - 与他人冲突 / 化解
     - 主动推动事
     - 学习新技能

3. **专业能力**（5 题，25 分钟）
   - 基于简历项目深挖
   - 1 道开放设计题
   - 1 道算法 / 系统题（视岗位）

4. **反问环节**（建议我问 3 题）

每题给：
- 题目
- 我的"该怎么答的提纲"（不是标准答案，是思考结构）
- 面试官想看到的 3 个信号
- 雷区（千万别说什么）

输出 markdown，不要全部一次性给完——一题一题来，每题等我答完你打分（10 分制 + 改进建议）再出下一题。

17 OKR 季度复盘

适用场景：季度末做 OKR review，要给老板交。 推荐模型：Sonnet 4.5 前置：季度 OKR 文档 + 季度数据。

请帮我做这个季度的 OKR 复盘。

季度 OKR：@okr-q1.md
关键数据：@【数据源文件或 MCP 接口】

输出结构：

## 整体得分
- O1：X.X / 1.0
- O2：X.X / 1.0
- 整体：X.X / 1.0
- 完成度自评：（超预期 / 达成 / 部分达成 / 未达成）

## O1：【目标名】
- KR1.1：定义 → 实际 → 评分 → 一句话归因
- KR1.2：…
- KR1.3：…
- 总结：……

## O2：……（同上）

## What Worked
- 3 件做对的事，及为什么对

## What Didn't
- 3 件没做好的事，及根本原因（不要找借口）

## 下季度调整
- 哪些 KR 要继续 / 调整 / 砍掉
- 流程或方法上的改进

约束：
- 全部基于事实，每条结论都要能指向数据 / 事件
- 不要虚化（"加强了 XX"），要实化（"上线 X 功能、覆盖 Y 用户"）
- 长度 ≤ 800 字

18 Excel/CSV 自然语言查询

适用场景：拿到一个 Excel / CSV，不想写公式，直接问问题。 推荐模型：Sonnet 4.5 前置：文件路径，必要时让 Claude 装 pandas。

我有一个数据文件 @【路径.csv 或 .xlsx】。请：

1. 第一步：先 sample 前 20 行 + 列定义 + 数据类型，告诉我"这是一份关于什么的数据"

2. 第二步：等我提问。我会用自然语言问，比如：
   - 哪个客户上个季度贡献最多？
   - 把华东区销售额按月画个趋势图
   - 找出销售额低于平均值 50% 的产品
   - 谁离职率最高？

3. 第三步：每次回答时：
   - 用 pandas / openpyxl 真实查
   - 给出"我跑的代码"
   - 给出结果（表格 / 图）
   - 一句话洞察
   - 如果数据有问题（缺失 / 异常），主动说

约束：
- 不要乱猜列名，看实际表头
- 涉及金额、人名、客户名脱敏（如需展示）
- 大数据集（>10 万行）先做 sample 再做全量
- 图表用文字 + ASCII，除非我说"画 PNG"

19 合同条款风险扫描

适用场景：拿到供应商 / 客户给的合同，自己看不出哪些条款不利。 推荐模型：Opus 4.7 前置：合同文本（PDF 转文字 / Word / md）。

你是一名企业法务，请审查这份合同（甲方=我们，乙方=对方）：

@【合同文件】

按以下维度扫描，每条标"风险等级"（🔴 高 / 🟡 中 / 🟢 低）：

1. **责任与义务**：是否对甲方过度严苛？
2. **付款条款**：节奏是否合理？滞纳金是否过高？
3. **知识产权**：归属是否清晰？是否包含甲方原有 IP？
4. **保密**：双向还是单向？时长 / 范围合理吗？
5. **违约责任**：违约金 / 终止条件 / 通知期
6. **不可抗力**：定义是否合理？
7. **管辖与仲裁**：法院 / 仲裁机构是否对甲方友好？
8. **解约**：甲方是否有合理的退出机制？
9. **数据 / 隐私**：如涉及个人信息 / 客户数据
10. **变更条款**：单方修改？双方协商？

输出：

## 总体评估
（一句话：建议签 / 修改后签 / 不建议签）

## 红色风险（必须修改）
- 第 X 条：原文 → 风险点 → 建议改成

## 黄色风险（建议谈判）
（同上）

## 绿色提示（可接受但留意）
（同上）

## 谈判优先级建议
（如果只能改 3 条，改哪三条）

约束：
- 不替代专业律师，结尾标注"建议正式签署前由法务最终把关"
- 不引用具体法条（除非我说要）
- 涉及金额 / 期限的全部摘录原文，避免误读

20 长文摘要 + 关键引用

适用场景：1 万字研究报告 / 50 页 PDF / 长视频转写稿。 推荐模型：Sonnet 4.5 前置：文件路径。

请把 @【长文路径】 做"双层摘要"：

## 30 秒版（≤ 100 字）
（最核心 1 个观点 + 1 个数字 + 1 个 takeaway）

## 3 分钟版（≤ 500 字）
- 核心观点 1：…（含支撑论据）
- 核心观点 2：…
- 核心观点 3：…
- 结论与启示

## 关键引用（5-10 条）
| 序号 | 引用原文（≤ 50 字） | 出处（页 / 段） | 我为什么标它 |
| --- | --- | --- | --- |

## 我会问的 5 个深入问题
（这些问题留给作者 / 自己之后查）

## 一句话推荐给谁看
（"产品经理 / 投资人 / 高管 / 不推荐"）

约束：
- 摘要不要"说了什么"，要"说了什么观点 / 给了什么数据"
- 引用要原文不要改写
- 数字必须准确，不确定的标"约"

内容 / 创意类（5 条）

21 旅行行程规划

适用场景：要去某地玩 N 天，懒得自己排。 推荐模型：Sonnet 4.5 前置：装 Brave Search / Tavily MCP（可选，用于查最新信息）。

请帮我规划一次旅行：

- 目的地：【城市 / 地区】
- 时间：【日期范围】
- 人数 / 类型：【2 大 1 小 / 一个人 / 父母同行】
- 预算：【人民币 X 元 / 人，含 / 不含机票】
- 兴趣：【美食 / 自然 / 历史 / 购物 / 摄影】
- 节奏：【松弛 / 紧凑 / 半松半紧】
- 不感兴趣：【博物馆 / 网红打卡 / 户外徒步】

输出：

## 行程概览
（一段话，给整体感觉）

## 每日计划
### Day 1（X 月 X 日 周X）
- 上午：【地点 + 1 句理由 + 时间预估】
- 中午：【餐厅 + 招牌菜 + 人均】
- 下午：…
- 晚上：…
- 住宿：【酒店 / 民宿 + 价格 + 链接（如可）】
- 当日花费估：¥X
- 注意：【天气 / 排队 / 提前订票】

（依次到 Day N）

## 总花费估算
- 交通 / 住宿 / 餐饮 / 门票 / 其他 / 合计

## 需要提前订
- 哪些景点要预约
- 哪些餐厅要订位

## 行李清单
（按目的地天气 + 活动定）

## 备选方案
- 下雨天 / 累了 / 临时改主意时的 plan B

约束：
- 不要列十几个景点然后说"自选"——按时间排满
- 路线尽量减少回头路
- 餐厅必须真实存在（不确定的标⚠）
- 开放时间 / 票价等可能变，提示"出发前查官方"

22 月度账单分类 + 建议

适用场景：导出银行 / 支付宝账单，自己看不出花在哪。 推荐模型：Sonnet 4.5 前置：账单 CSV 或截图。

请帮我分析这个月的账单 @【账单文件】：

1. 按类别分类（餐饮 / 交通 / 住房 / 医疗 / 学习 / 娱乐 / 衣物 / 数字订阅 / 转账给他人 / 其他）
   - 大类下分小类，比如"餐饮"分"早餐 / 午餐 / 晚餐 / 外卖 / 咖啡"
   - 不确定的归"其他"，不要强行归类

2. 输出：

## 总览
- 总收入 / 总支出 / 结余
- 同比上月（如有上月数据）

## 分类明细
| 类别 | 金额 | 占比 | 同比 |
| --- | --- | --- | --- |

## Top 10 单笔
（最大的 10 笔支出，标日期 + 商家 + 金额）

## 异常 / 值得关注
- 重复订阅（可能忘了取消的）
- 单笔过大
- 频次异常增长

## 节流建议
（3 条，要具体可执行，比如"取消 Apple Music 家庭组里没人用的位"）

## 健康度评分
（A-F + 一句话）

约束：
- 涉及具体商家保留（不脱敏，自己看的）
- 转账给亲属 / 朋友单独列
- 投资 / 还款不算"消费"
- 不要说教

23 文件归档机器人

适用场景：桌面 / Downloads 一团乱，每周清一次。 推荐模型：Sonnet 4.5（或 Haiku，简单分类够用）

请整理 @~/Downloads（或指定目录），按以下规则：

约束（先 dry-run，再执行）：

1. 按"类型 + 时间"组织：
   - ~/Archive/2026-04/Documents/
   - ~/Archive/2026-04/Images/
   - ~/Archive/2026-04/Videos/
   - ~/Archive/2026-04/Code-archives/
   - ~/Archive/2026-04/Installers/
   - ~/Archive/2026-04/Misc/

2. 类型识别按扩展名：
   - Documents：pdf / docx / pptx / xlsx / md / txt / epub
   - Images：jpg / jpeg / png / heic / svg / gif
   - Videos：mp4 / mov / avi / mkv
   - Code-archives：zip / tar.gz / 7z（解压后是代码项目的）
   - Installers：dmg / pkg / exe / msi

3. 跳过：
   - 隐藏文件（.开头）
   - 最近 7 天内创建的（可能还在用）
   - 桌面上的文件夹（可能是临时工作区）

4. 命名冲突：在文件名后加 (1)(2)，不要覆盖

5. 流程：
   - 阶段 1：扫描 + 列出"将要做的操作"（move from → to），按操作类型统计
   - 阶段 2：等我说 "go"
   - 阶段 3：执行，每移动 100 个汇报一次进度
   - 阶段 4：完成后给"操作日志"+ 给我一份回滚脚本（万一搞错）

6. 失败处理：
   - 文件被打开 / 锁定：跳过，记入日志
   - 权限错：跳过，记入日志
   - 不要因为单个失败就停

24 学习计划生成

适用场景：想学某个新技能 / 考某个证 / 读完某本书。 推荐模型：Sonnet 4.5

我要学习 【主题，例：日语 N3 / Python 数据分析 / 弹尤克里里】，已有基础：【从零 / 略懂 / 中级】，每天可用时间：【1 小时 / 30 分钟 / 周末 4 小时】，目标完成时间：【3 个月 / 半年 / 一年】。

请生成学习计划：

## 整体路径
- 学完后能做到什么（具体到"可以独立完成 X 任务"）
- 路径分几个阶段，每阶段目标

## 阶段 1：【名字】（X 周）
- 内容大纲（3-5 个主题）
- 推荐资源（书 / 课 / YouTube / 应用，标"免费 / 付费 / 中文 / 英文"）
- 每周作业（小项目 / 习题）
- 阶段验收（怎么判断学会了）

## 阶段 2 / 3 / ...（同上）

## 每日 / 每周节奏
- 周一 / 周二 / ... 各做什么
- 复习 / 实操 / 输入比例

## 防止半途而废的 5 个机制
（具体方法，不要"坚持"这种废话）

## 第一周的具体任务
（精确到天，第一周帮我把"启动"这件事做掉）

约束：
- 资源必须真实存在（不知道的不要瞎编）
- 不要"7 天精通"——给现实可行的节奏
- 把"不要做"也写出来（哪些坑别踩）

25 翻译 + 风格保持

适用场景：把英文文章翻成中文，但要保持原作者的语气 / 比喻 / 节奏。 推荐模型：Opus 4.7（翻译用 Opus 质量明显更好）

请把这段【英文 / 其他语言】翻成【中文 / 其他】：

【原文，或 @文件路径】

约束：
- 风格：【尽量直译 / 信达雅 / 偏口语 / 学术正式】
- 受众：【一般读者 / 专业读者 / 儿童】
- 保留原作者的：
  - 比喻和修辞
  - 段落节奏（不要把短句翻译成长句）
  - 专有名词（人名 / 地名 / 公司名 / 技术术语，第一次出现给中英对照）
- 翻译陷阱处理：
  - 双关 / 笑话：保留原意，括号注"原文双关"
  - 文化典故：必要时加译注
  - 长难句：拆成短句但意思不丢
- 输出格式：
  - 段落对齐原文
  - 每 3-5 段后插一段"译注"（如有需要）

完成后，最后给一段：
- 翻译时纠结的 3 处地方 + 你的处理方式
- 建议作者自己审一下的 3 处地方

通用类（5 条）

26 客户邮件回复草稿

适用场景：客户来了一封"棘手"邮件，不知道怎么回。 推荐模型：Sonnet 4.5

我收到客户的邮件，需要回复：

客户邮件原文：
【粘贴邮件】

背景：
- 客户类型：【大客户 / 普通客户 / 潜在客户 / 竞品客户】
- 当前关系：【良好 / 紧张 / 第一次接触 / 有未结纠纷】
- 我方立场：【完全同意 / 同意但有条件 / 委婉拒绝 / 明确拒绝】

请帮我起 2 个版本：

## 版本 A：稳健版
（更礼貌、更打太极、保留余地）

## 版本 B：直接版
（更明确、更高效、可能更冒险）

每版都包含：
- 主题（subject）
- 称呼
- 正文
- 签名

输出后给一段"我应该选哪版的判断"——基于：
- 客户性格倾向
- 邮件中的情绪指标
- 我方风险承受度

约束：
- 不要"再次为给您带来不便表示歉意"这种 AI 味
- 不要超过 200 字（除非明确需要长版）
- 关键事实 / 数字 / 承诺一定要有依据，不要为了"显得专业"瞎承诺

27 演讲稿大纲

适用场景：要做一个 X 分钟的分享 / 演讲，不知道怎么开始。 推荐模型：Sonnet 4.5

我要做一个演讲：

- 主题：【演讲主题】
- 时长：【15 分钟 / 30 分钟 / 60 分钟】
- 受众：【同事 / 行业大会 / 学生 / 投资人】
- 我的角色 / 资历：【XX】
- 想达成的目标：【教会他们 X / 说服他们做 Y / 让他们记住 Z】

请生成演讲结构：

## 标题（3 个备选）
- 选项 1：……
- 选项 2：……
- 选项 3：……

## 开场（2 分钟）
- Hook（一个故事 / 数字 / 反问 / 误区）
- 自我介绍（≤ 30 秒，只说和主题相关的资历）
- 路线图（接下来要讲哪 3 个点）

## 主体（按时长分配）
### 第一部分：【名字】（X 分钟）
- 核心观点
- 论据（数据 / 案例 / 故事）
- 互动 / 提问点（让听众参与）
- 过渡到下一部分

### 第二部分 / 第三部分（同上）

## 结尾（2 分钟）
- 一句话总结全场
- Call to Action（听众明天能做的一件事）
- 如何继续跟我连接（联系方式 / 资料）

## 配套
- 推荐 PPT 页数 + 每页核心一句话
- 可能被问的 5 个问题 + 准备好的答案
- 演讲前 3 天 / 当天 / 上台前 5 分钟的 checklist

约束：
- 一个观点不要超过 3 分钟（注意力极限）
- 每 5-7 分钟必须有一次互动 / 故事
- 不要"今天我想跟大家分享"这种废开场
- 给一份"演讲全文"是错的，给"提纲 + 关键句"

28 创意头脑风暴

适用场景：想给产品 / 文章 / 活动起名 / 想点子，但脑子空。 推荐模型：Opus 4.7（创意场景 Opus 明显发散性更好）

我要做头脑风暴：

主题：【想给一款"给程序员的咖啡机"起名】

约束：
- 需要 30 个候选
- 风格混合：科技感 / 文艺 / 幽默 / 极简 / 怀旧 各 6 个
- 同时要：好读 / 易记 / 域名可能没被注册（可以猜）
- 不要：撞知名品牌 / 涉及负面联想 / 难发音
- 必须告诉我每个名字的：
  - 字面含义 / 来源
  - 我为什么觉得它合适
  - 潜在的"被解读错"的风险

请输出：

## Top 30 候选
| # | 名字 | 风格 | 含义 / 灵感 | 风险 |
| --- | --- | --- | --- | --- |

## 我的 Top 5 推荐
（从 30 个里选 5 个，给推荐理由）

## 接下来该做什么
- 域名查询：建议查哪几个
- 商标检索：建议查哪几个
- 受众测试：建议怎么做（5-10 人小调研问什么）

约束：
- 不要"AI Coffee" "DevBrew" 这种烂大街组合
- 鼓励用"非英文"语言（比如"墨"、"焙"）
- 鼓励"两个字"的极简风

29 网页内容研究

适用场景：研究一个话题，要从 5-10 个网页里抽信息。 推荐模型：Sonnet 4.5 前置：装好 WebFetch 或 Tavily / Brave Search MCP。

我要研究：【话题，例：2026 年中国 AI 编程工具市场格局】

请：

1. 检索阶段（用 search MCP）
   - 中文搜：5 个关键查询
   - 英文搜：3 个关键查询
   - 列出找到的 15-20 个 URL，标"权威性"（官方 / 媒体 / 个人博客 / 论坛）

2. 等我从清单里挑 8-10 个让你深读

3. 深读阶段
   - 逐个 fetch
   - 每个网页提炼"关键事实 / 数据 / 观点"

4. 综合阶段
   - 跨源对比：哪些事实多源印证？哪些只一处说？
   - 时间线：按时间梳理事件
   - 多视角：不同立场的观点对照

5. 输出研究报告：

## 摘要（≤ 200 字）

## 关键事实 / 数据
| 事实 | 来源 | 时间 | 可信度 |
| --- | --- | --- | --- |

## 多视角分析
- 视角 A：……
- 视角 B：……
- 我的综合判断：……

## 仍需挖掘
- 信息缺口
- 建议下一步去哪查

## 引用列表
（编号 + URL + 一句话定位）

约束：
- 不要把"网友评论"当事实
- 数字必须能追到原始来源
- 推测要明确标"⚠ 推测"

30 打造你的私人 AI 助理

适用场景：想把 Claude Code 配成"长期管你日常的助理"，跑一次性配置。 推荐模型：Sonnet 4.5（配置时） + Haiku（日常运行时）

请帮我把 Claude Code 配成"私人助理"。前置约定：

我的身份：【一行简介，例："产品经理，2 个孩子，35 岁，住上海"】
我每天必做的事：
- 早晨：看邮件、查日历、看市场新闻
- 工作：写文档、回 Slack、参加会议
- 晚上：陪孩子、读书、复盘
我的目标：【这季度的 3 个目标】
我的禁忌：【不喜欢什么 / 不能做什么】

请你完成 5 件事：

1. 起草 ~/.claude/CLAUDE.md
   - 写清我的身份、偏好、禁忌
   - 写清"如果不确定，先问我"
   - ≤ 150 行

2. 起草 3 个 Skill
   - 早晨简报（汇总邮件 + 日历 + 新闻）
   - 周报草稿
   - 每周复盘问答

3. 起草 2 个 /loop 任务
   - 每天 7:30 跑早晨简报
   - 每周五 17:00 跑周报草稿

4. 起草 2 个 Hook
   - PreToolUse：禁止动 ~/Documents/personal/
   - SessionStart：自动 cd 到 ~/Workspace/today/

5. 起草一个 README，告诉我：
   - 装在哪
   - 怎么测试
   - 万一出问题怎么禁用

输出全部用文件块呈现（一个文件一段 ```markdown）。配置完后给我一份"明天早晨会发生什么"的剧本，让我心里有数。

约束：
- 不要装一堆我用不上的 MCP
- 不要让我做"必须每天点一下"的事——能自动就自动
- 涉及隐私的事强制本地处理
- 配置文件全部留中文注释

用提示词的 5 个心法

1. 占位符替完再发——【方括号】 留着不替，结果就跑偏。
2. 复杂任务先 dry-run——99% 的提示词都该先让 Claude "说要做什么"，确认后再 "go"。
3. 结果不满意，先看自己提示词哪里没说清——80% 是输入问题，不是模型问题。
4. 每次跑完顺手优化——把这次的反馈写回模板，下次更准。
5. 建你自己的私人模板库——本附录是起点，不是终点。把你修改过的版本存成 .claude/commands/<name>.md，以后直接 /<name>。

把模板变成你自己的 slash 命令

每条提示词都可以变成 /【命令名】，举个例子，把"01 项目首次理解"存成命令：

mkdir -p ~/.claude/commands
cat > ~/.claude/commands/onboard.md <<'EOF'
你是一名资深架构师，第一次接手这个项目。请按以下顺序产出一份《项目快速理解报告》：
... （此处粘贴模板剩余部分）
EOF

之后任何项目里直接 /onboard 即可调用。

也可以用 $ARGUMENTS 接收参数：

你是一名【$ARGUMENTS】专家，请审查 ...

调用：/expert-review 安全，参数自动注入。