文档更新
This commit is contained in:
@@ -4,6 +4,12 @@
|
||||
|
||||
| 日期 | 时间 | 服务器 | 备份文件 | 状态 |
|
||||
| ---------- | ----- | -------- | ----------------------------------- | ---- |
|
||||
| 2026-03-26 | 22:02 | Mac Mini | openclaw-macmini-20260326220236.tar | ✅ 成功 |
|
||||
| 2026-03-26 | 22:02 | Ubuntu2 | openclaw-ubuntu2-20260326220236.tar | ✅ 成功 |
|
||||
| 2026-03-26 | 06:28 | Mac Mini | openclaw-macmini-20260326062835.tar | ✅ 成功 |
|
||||
| 2026-03-26 | 06:28 | Ubuntu2 | openclaw-ubuntu2-20260326062850.tar | ✅ 成功 |
|
||||
| 2026-03-25 | 22:03 | Mac Mini | openclaw-macmini-20260325220303.tar | ✅ 成功 |
|
||||
| 2026-03-25 | 22:03 | Ubuntu2 | openclaw-ubuntu2-20260325220303.tar | ✅ 成功 |
|
||||
| 2026-03-24 | 22:00 | Mac Mini | openclaw-macmini-20260324220009.tar | ✅ 成功 |
|
||||
| 2026-03-24 | 22:00 | Ubuntu2 | openclaw-ubuntu2-20260324220009.tar | ✅ 成功 |
|
||||
| 2026-03-20 | 06:19 | Mac Mini | openclaw-macmini-20260320061934.tar | ✅ 成功 |
|
||||
|
||||
183
openclaw/xinghui/AI研究工作流-观自.md
Normal file
183
openclaw/xinghui/AI研究工作流-观自.md
Normal file
@@ -0,0 +1,183 @@
|
||||
# 00后双非电商专业毕业，每周4场AI沙龙，我的能力从何而来？
|
||||
|
||||
> 作者：观自 (@longdechen12) - 认证账号
|
||||
> 来源：X (Twitter)
|
||||
> 发布时间：2026年3月25日 22:43
|
||||
> 链接：https://x.com/longdechen12/status/2036816359343222971
|
||||
> 收藏：11.9万 Views, 572 Likes, 1223 Bookmarks
|
||||
|
||||
---
|
||||
|
||||
说实话，我也是现学现卖。
|
||||
|
||||
但我有一套流水线，能让我三个小时以内摸透一个领域最核心的东西。
|
||||
|
||||
去年靠这套方法，录制了国家工信部 AI 智能体证书的课程，搭建了湘江集团整套的矩阵运营系统，近期六位数的费用刚到账。
|
||||
|
||||
今天把这套方法论完整公开。看完之后，你也能搭建属于你自己的内容变现流水线。
|
||||
|
||||
过去我也是受大家帮助走过来的，所以希望在稍微有经验的时候，能给大家带来一些启发和灵感。
|
||||
|
||||
如果你刚在 AI 领域起步，12 个月前的我就是你最佳的抄袭对象。
|
||||
|
||||
---
|
||||
|
||||
## 省流版工作流
|
||||
|
||||
**多平台信息源 → 全部转成 Markdown → 喂进 NotebookLM 知识库 → Claude Code 批量提问 + 保存答案到本地 → 基于问答创作自己的内容**
|
||||
|
||||
---
|
||||
|
||||
## 先看效果
|
||||
|
||||
我现在研究任何领域，准备每一场线下分享，直接和 Claude Code 对话。
|
||||
|
||||
它会基于两三百篇优质文章，或一个博主的全部视频，或某个关键词下的视频进行回答。所有回答都能完整保持真实性。
|
||||
|
||||
我基于这些回答去创作自己的内容，还能接各种 skill，直接转成文章、口播逐字稿、AI 工具最佳实践手册……可以无限延伸。
|
||||
|
||||
---
|
||||
|
||||
## 为什么大部分人没办法深入研究一个领域？
|
||||
|
||||
我观察下来，卡在三个地方：
|
||||
|
||||
### 第一，不会提问
|
||||
没有好问题，就不会有好答案。你连该问什么都不知道，AI 再强也帮不了你。
|
||||
|
||||
### 第二，答案不可信
|
||||
现在好多 AI 已经被投毒了，没办法基于完整的知识库生成内容，真实性无法保证。你拿着幻觉去讲课，是要翻车的。
|
||||
|
||||
### 第三，知识没有沉淀
|
||||
和 AI 在浏览器窗口对话，问题和答案没办法被留下来。下次需要调用，还得重新问一遍。更别说怎么基于这些问答去进一步扩展内容了。
|
||||
|
||||
**这三个问题，我的工作流全部解决。**
|
||||
|
||||
---
|
||||
|
||||
## 整体框架：IPO 模型（输入 → 处理 → 输出）
|
||||
|
||||
我用最简单的模型来拆——IPO：输入、处理、输出。每个普通人都能理解，每个普通人都能落地。
|
||||
|
||||
---
|
||||
|
||||
## 第一步：喂料——打破信息壁垒（耗时：0.5~1 小时）
|
||||
|
||||
大模型掌握了尽可能多的信息，但好多信息存在壁垒。平台之间的壁垒，付费与免费之间的壁垒，传播媒介之间的壁垒——有的是视频，有的是文章。
|
||||
|
||||
**怎么打破？** 我们以终为始，将所有来源尽可能转化为 AI 最擅长理解的 Markdown 文档。
|
||||
|
||||
### 网页类：三个插件解决一切
|
||||
|
||||
**油管 → YouTube to NotebookLM 插件**
|
||||
|
||||
这个插件支持一键导入一个油管博主的全部视频逐字稿到 NotebookLM 知识库，你可以把它理解为国内的 Get 笔记。导入后就能在知识库里对这个博主的全部视频进行提问，适合研究对标博主的整套内容体系。你也可以基于关键词搜索后依次导入，适合研究某个领域的优质内容。使用方法很简单，直接安装插件配置好即可。
|
||||
|
||||
**推特 / 公众号 / 网页 → Obsidian 剪藏助手**
|
||||
|
||||
推特长文、公众号文章、普通网页，都可以一键剪藏为本地 Markdown。你还可以搭建 RPA 程序进行批量剪藏——比如我要分析飞书的开发案例，搭建好 RPA 后把电脑放在那，它就能自己工作了。
|
||||
|
||||
**飞书文档 → Cloud Document Converter**
|
||||
|
||||
飞书文章容易被设置权限，Obsidian 剪藏助手搞不定。这个插件能帮你破除权限限制，直接以 Markdown 形式保存到本地。
|
||||
|
||||
基本上这三个插件就能解决所有网页文档的剪藏。
|
||||
|
||||
### 视频类：链接提取 or 文件提取，总能搞定
|
||||
|
||||
**链接提取：**
|
||||
B 站长视频、小宇宙播客等，直接把链接发给 Get 笔记，就能提取全部逐字稿。抖音也一样，Get 笔记支持一键提取抖音博主全部逐字稿，但都是在线的。我用 Claude Code 做了一个 app，支持一键将抖音博主全部视频的逐字稿导入本地。
|
||||
|
||||
**文件提取：**
|
||||
有些视频没有链接，或者链接不支持直接提取。最简单的方法是先用下载狗、GreenVideo 等工具把视频下载下来，再上传到通义听悟进行逐字提取。这是底层通用方案——所有视频归根结底都是文件，只要有源文件，一定能提取出来。
|
||||
|
||||
**这样就完成了喂料。**
|
||||
|
||||
---
|
||||
|
||||
## 第二步：消化——NotebookLM × Claude Code 联动（耗时：1~2 小时）
|
||||
|
||||
所有输入的内容都可以放到 NotebookLM 知识库里。
|
||||
|
||||
### 为什么选 NotebookLM？三个原因：
|
||||
|
||||
1. **绝不产生幻觉** - 完全基于你喂进去的真实材料生成内容，每个答案都能在原文中找到溯源，右上角标注好位置，点击就能跳转查看。
|
||||
|
||||
2. **接的是 Gemini 模型，长文本处理效果很好** - 好多 AI 你上传几十个文档它就不知道里边说的什么了，NotebookLM 可以上传 300 个文档。
|
||||
|
||||
3. **输出格式丰富** - 支持音频、视频、幻灯片等多种格式。
|
||||
|
||||
### 核心玩法：让 AI 帮你提问
|
||||
|
||||
处理环节最大的问题，还是前面说的——好多人不知道怎么提问。
|
||||
|
||||
**我的方法是：直接让 AI 帮我提出一系列好的问题。**
|
||||
|
||||
描述一个主题，让 AI 生成一系列问题，然后 NotebookLM 基于知识库给出答案，保存到本地。就像学术研究里的"交叉质询"——AI 提问，知识库举证，我来审判。
|
||||
|
||||
### 怎么实现的？
|
||||
|
||||
首先给 Claude Code 接上 NotebookLM 知识库。直接复制这个链接发给你的 Claude Code，让它帮你安装，按步骤完成认证登录即可。
|
||||
|
||||
> https://github.com/PleasePrompto/notebooklm-skill
|
||||
|
||||
安装好后，和网页端一样提问就行了。我日常的用法是：让它帮我批量生成问题，批量作答。我只需要看对应的问题和答案。它相较我而言能生成更全面更深入的问题。
|
||||
|
||||
我还增加了一个要求：不只是在线提问，而是把问题和答案以本地文件的形式保存下来，方便以后直接做成知识库。
|
||||
|
||||
### 为什么不直接用 Claude Code 读文档？
|
||||
|
||||
很多人问：Claude Code 也可以基于这些文档生成内容，为什么还要接 NotebookLM？
|
||||
|
||||
**核心原因是省钱。**
|
||||
|
||||
直接用 Claude Code 读几百篇文档，极其耗费 token。接上 NotebookLM 知识库后，Claude Code 只负责提问，拿到答案后保存到本地就行了，token 消耗大幅降低。
|
||||
|
||||
**这样处理环节就搞定了。**
|
||||
|
||||
每次我只需要提要求，它就帮我扩展问题、调用知识库、生成答案并保存到本地。我可以直接查阅，下次还能将其作为新的知识库材料。**知识是会复利的——你的库越厚，下次研究的起点就越高。**
|
||||
|
||||
---
|
||||
|
||||
## 第三步：表达——用 AI 做研究，用人做表达（耗时：1~2 小时）
|
||||
|
||||
拿到问题和答案后，实操方面的内容，我会直接去实践一遍。
|
||||
|
||||
如果要讲认知层面的内容，我用自己的理解整理成 Xmind 思维导图，再进一步整理为幻灯片。
|
||||
|
||||
但好多人是直接让 NotebookLM 生成幻灯片、生成逐字稿，然后去现场放在幻灯片注释里直接念。
|
||||
|
||||
**我不喜欢这种方式。** 真正体验过你就知道，这根本行不通。很死板，就是个念稿的，自己都不知道自己讲的是什么，而且当每页都是重点的时候，就没有重点了，根本不关心听众是否理解。
|
||||
|
||||
### 我的做法是：
|
||||
|
||||
1. **先写 Xmind 逐字稿，保证表达框架是我的** - 这样我不需要去顺应 AI 生成 PPT 的垃圾框架。
|
||||
|
||||
2. **用语音输入法（闪电说）或者语音转文字（千问录音）** - 照着思维导图，把我对内容的理解自己输出一遍。这个过程活人味很足，得到的是一篇完全符合我表达风格的逐字稿。稍微修改一下，到时候直接即兴讲就行。
|
||||
|
||||
3. **手搓 Keynote 幻灯片**
|
||||
|
||||
> 我一直有个观点：如果你觉得 NotebookLM 生成的幻灯片好的话，要么你压根不懂表达，要么你只用过 PowerPoint。
|
||||
|
||||
**手搓的好处：** 完全符合我的表达逻辑，手搓过程本身就是梳理内容的过程，同时能控制好观众的注意力，因为它足够简约，使用动画渐进式显现，观众的眼睛会完美契合你的演讲节奏。
|
||||
|
||||
有时间我也可以给大家分享一下我是如何制作幻灯片的。
|
||||
|
||||
---
|
||||
|
||||
## 闭环
|
||||
|
||||
从喂料到消化到表达，全套闭环就是这样。如果有想研究的领域，有想分享的内容，完全可以用这套工作流完成知识变现。
|
||||
|
||||
> **用 AI 做研究，用人做表达。**
|
||||
|
||||
这篇内容就是基于我 Xmind → 口播逐字稿的方法论写出来的。有些环节由于篇幅原因没有最细化，大家可以在评论区反馈：哪里写得好，哪里没写全，方便我以后做更详细的分享。
|
||||
|
||||
---
|
||||
|
||||
## 关于作者
|
||||
|
||||
> 我是观自，00 后，一个农村小伙，AI 领域的创业者，刚来到推特。
|
||||
> 专注于 AI 赋能培训与 AI 自动化运营系统定制。
|
||||
|
||||
阅读过程中对于 AI 有任何问题，或者有插件方面的需求，都可以联系我。
|
||||
52
openclaw/xinghui/Bright-Data-MCP-技能配置.md
Normal file
52
openclaw/xinghui/Bright-Data-MCP-技能配置.md
Normal file
@@ -0,0 +1,52 @@
|
||||
# Bright Data MCP 技能
|
||||
|
||||
是的，Bright Data 有相关的技能，主要通过 MCP (Model Context Protocol) 的形式与 OpenClaw 集成。
|
||||
|
||||
这种集成允许 OpenClaw 调用 Bright Data 强大的数据采集能力，特别是其处理反爬、解锁复杂网站（如 Cloudflare 保护页面）的功能。
|
||||
|
||||
## 🤖 Bright Data MCP 技能
|
||||
|
||||
这个技能的核心是 **brightdata-mcp** 服务器。配置后，你可以通过自然语言指令让 OpenClaw 去爬取指定网站的数据，而无需自己编写复杂的爬虫代码或配置代理。
|
||||
|
||||
### 主要功能：
|
||||
|
||||
- **自动化爬虫**：将你的自然语言需求（如"抓取某电商网站的商品名称和价格"）转换为具体的爬取任务。
|
||||
- **反爬处理**：自动处理网站的反爬机制，如验证码和动态渲染，保证数据抓取的稳定性。
|
||||
- **结构化输出**：将抓取到的原始数据清洗并整理成结构化格式（如 JSON、CSV）。
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ 如何配置
|
||||
|
||||
配置 brightdata-mcp 与配置其他 MCP 服务器类似，但需要提供你的 Bright Data API 凭证。
|
||||
|
||||
### 1. 获取 API Key
|
||||
|
||||
首先，你需要登录 Bright Data 账户，在后台获取你的 API Key 和 Account ID。
|
||||
|
||||
### 2. 添加 MCP 服务器
|
||||
|
||||
使用 openclaw 命令行工具添加 brightdata-mcp 服务：
|
||||
|
||||
```bash
|
||||
openclaw mcp add --transport stdio brightdata npx -y brightdata-mcp
|
||||
```
|
||||
|
||||
在某些配置中，可能需要通过环境变量传递凭证：
|
||||
|
||||
```bash
|
||||
openclaw mcp add --transport stdio brightdata npx -y brightdata-mcp
|
||||
```
|
||||
|
||||
然后，你可能需要手动编辑配置文件（~/.openclaw/openclaw.json），在 brightdata 服务的配置项下添加 env 字段来设置 BRIGHT_DATA_API_KEY 等环境变量。
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 安全提示
|
||||
|
||||
请注意，Bright Data 是一个功能强大的商业数据服务。在使用其技能时，务必遵守相关法律法规和网站的使用条款，合法合规地进行数据采集，切勿用于任何非法用途。
|
||||
|
||||
---
|
||||
|
||||
*记录时间：2026-03-25*
|
||||
*来源：星辉与比利的对话*
|
||||
685
openclaw/xinghui/Claude-Code-最佳实践.md
Normal file
685
openclaw/xinghui/Claude-Code-最佳实践.md
Normal file
@@ -0,0 +1,685 @@
|
||||
# CLAUDE CODE 最佳实践：从"能用"到"真的好用"
|
||||
|
||||
> 作者：Mr Panda (@PandaTalk8)
|
||||
> 来源：X (Twitter)
|
||||
> 发布时间：2026年3月23日 15:03
|
||||
> 链接：https://x.com/pandatalk8/status/2035975664730575325
|
||||
> 收藏：456.4K Views, 1577 Likes, 3583 Bookmarks
|
||||
|
||||
---
|
||||
|
||||
我用 Claude Code 大半年了，踩过的坑比写过的代码还多。
|
||||
|
||||
一开始我以为 Claude Code 就是一个"更高级的 Copilot"——在终端里打字，它帮我写代码，完事。后来才发现，这东西的上限远比我想象得高，但前提是你得知道怎么用。
|
||||
|
||||
这篇文章结合官方文档和实战经验，整理了我认为最重要的使用技巧。有些是血泪教训，有些是读文档才知道的隐藏功能。
|
||||
|
||||
---
|
||||
|
||||
## 一、CLAUDE.MD：最被低估的功能
|
||||
|
||||
如果你只记住这篇文章的一件事，就记这个：**写好你的 CLAUDE.md**。
|
||||
|
||||
CLAUDE.md 是 Claude Code 在每次对话开始时自动读取的指令文件。它就像你给一个新同事写的 onboarding doc——你希望他知道什么，你就写什么。
|
||||
|
||||
很多人不写 CLAUDE.md，或者随便写两行。结果就是每次对话都要从头解释项目结构、编码规范、技术栈选择。这就像每天早上都要重新给同事介绍一遍公司。
|
||||
|
||||
### 一个好的 CLAUDE.md 应该包含什么
|
||||
|
||||
```markdown
|
||||
# 项目名称
|
||||
|
||||
## 构建和测试命令
|
||||
- 安装依赖：npm install
|
||||
- 运行测试：npm test
|
||||
- 单个测试：npm test -- --grep "test name"
|
||||
- 格式化：npm run format
|
||||
|
||||
## 编码规范
|
||||
- Python 使用 ruff 格式化，行宽 88
|
||||
- 测试用 pytest，每个 service 对应一个测试文件
|
||||
- API 路由文件名用复数：users.py, orders.py
|
||||
- 提交信息用英文，格式：type(scope): description
|
||||
|
||||
## 架构决策
|
||||
- 选 Tailwind 而不是 CSS Modules，因为团队统一了这个规范
|
||||
- 用户权限校验在 middleware 里做，不要在每个路由重复写
|
||||
- Redis 缓存的 key 前缀统一用 `app:v1:`
|
||||
|
||||
## 常见陷阱
|
||||
- 数据库连接池上限是 20，别在循环里开新连接
|
||||
- 不要 mock 数据库，上次 mock 测试通过但生产迁移失败了
|
||||
```
|
||||
|
||||
### 有几个关键原则：
|
||||
|
||||
1. **第一，写 Claude 从代码里读不出来的东西。**
|
||||
项目的"为什么"比"是什么"更重要。你不需要解释 React 怎么用，但你需要告诉它"我们选 Tailwind 是因为团队统一了这个规范"。
|
||||
|
||||
2. **第二，控制在 200 行以内。**
|
||||
官方文档明确提到，CLAUDE.md 太长会导致 Claude 忽略规则。用 markdown 标题和列表，保持可扫描性。
|
||||
|
||||
3. **第三，不要放频繁变化的内容。**
|
||||
详细的 API 文档、逐文件描述这些东西不适合放在 CLAUDE.md 里。放链接就好。
|
||||
|
||||
### CLAUDE.md 的四级层级
|
||||
|
||||
Claude Code 支持四级 CLAUDE.md，按优先级从高到低：
|
||||
|
||||
我的全局 CLAUDE.md 里通常会写：
|
||||
|
||||
```
|
||||
- 我是一名全栈工程师，不需要过度解释基础概念
|
||||
- 回复尽量简洁，不要加无关的客套话
|
||||
- 代码改动后不要总结你做了什么，我会看 diff
|
||||
- 优先用简单方案，不要过度工程
|
||||
```
|
||||
|
||||
这四行，能省掉你几百次重复纠正的时间。
|
||||
|
||||
### 进阶：用 .claude/rules/ 组织规则
|
||||
|
||||
当项目大了之后，一个 CLAUDE.md 文件塞不下所有规则。官方提供了一个更优雅的方案：把规则拆到 .claude/rules/ 目录下。
|
||||
|
||||
```
|
||||
.claude/rules/
|
||||
├── testing.md # 测试规范
|
||||
├── api-style.md # API 编写风格
|
||||
└── frontend.md # 前端约定
|
||||
```
|
||||
|
||||
更强大的是，你可以用 YAML frontmatter 把规则限定到特定文件：
|
||||
|
||||
```yaml
|
||||
---
|
||||
paths: ["src/api/**/*.ts", "src/routes/**/*.ts"]
|
||||
---
|
||||
API 路由必须包含输入验证和错误处理。
|
||||
所有新端点需要在 tests/api/ 下添加集成测试。
|
||||
```
|
||||
|
||||
这样这条规则只在 Claude 访问匹配的文件时才会加载，节省上下文空间。
|
||||
|
||||
---
|
||||
|
||||
## 二、提示词的质量决定产出的质量
|
||||
|
||||
这听起来像废话，但我见过太多人这样用 Claude Code：
|
||||
|
||||
> "帮我写一个登录功能"
|
||||
|
||||
然后对着生成的一大坨代码发愁——这不是我想要的啊。
|
||||
|
||||
好的指令应该包含三个要素：**目标、约束、上下文**。
|
||||
|
||||
差的指令 vs 好的指令：
|
||||
|
||||
- 差："给用户列表加个搜索功能"
|
||||
- 好："在 src/pages/UserList.tsx 的表格上方加一个搜索框。搜索走后端 API /api/users?search=xxx，不要前端过滤。用 debounce 300ms，样式和现有的 Filter 组件保持一致。"
|
||||
|
||||
区别在哪？好的指令减少了歧义。Claude Code 不需要猜你要前端搜索还是后端搜索，不需要猜 debounce 时间，不需要猜样式规范。
|
||||
|
||||
### 官方推荐的提示技巧
|
||||
|
||||
1. **用 @ 引用具体文件**
|
||||
Claude Code 支持用 @文件路径 直接把文件内容拉进上下文。比起说"那个认证相关的代码"，直接写 @src/auth/login.ts 精确得多。你甚至可以指定行号范围：@src/auth/login.ts#5-30。
|
||||
|
||||
2. **贴截图和图片**
|
||||
用 Ctrl+V 可以直接粘贴图片。调试 UI 问题时，贴一张"现在长这样"和"我想要这样"的截图，比文字描述有效十倍。
|
||||
|
||||
3. **给验证标准**
|
||||
不要只说"帮我修这个 bug"，而是：
|
||||
|
||||
> "修复登录超时后无法重新认证的问题。修复后，用户在 token 过期后点击任意按钮应该自动跳转到登录页。测试用例在 @tests/auth.test.ts 里，修完后跑一下确认通过。"
|
||||
|
||||
给 Claude 一个可以自我验证的标准——测试用例、截图、预期输出——它就能自己检查工作质量，减少来回修改。
|
||||
|
||||
4. **明确"不要做"的事**
|
||||
Claude Code 有时候会过度热心——你让它修一个 bug，它顺手把周围的代码也重构了。明确说"只改这个函数，不要动其他代码"，能省很多事。
|
||||
|
||||
### 模糊指令也有用武之地
|
||||
|
||||
并不是所有时候都需要精确的指令。探索性任务用模糊指令反而更好：
|
||||
|
||||
- "这个文件有什么可以改进的地方？"
|
||||
- "帮我理解一下这个模块的架构"
|
||||
- "这段代码有什么潜在问题？"
|
||||
|
||||
但到了实现阶段，切回精确模式。
|
||||
|
||||
---
|
||||
|
||||
## 三、PLAN MODE：先想清楚，再动手
|
||||
|
||||
Claude Code 有一个 Plan Mode，这是我认为最被低估的工作流。
|
||||
|
||||
### 怎么进入 Plan Mode
|
||||
|
||||
三种方式：
|
||||
|
||||
```
|
||||
# 启动时直接进入
|
||||
claude --permission-mode plan
|
||||
|
||||
# 对话中切换（按两次 Shift+Tab）
|
||||
Shift+Tab Shift+Tab
|
||||
|
||||
# 在提示词里说 "先不要改代码，帮我做个计划"
|
||||
```
|
||||
|
||||
在 Plan Mode 下，Claude Code 只能读取文件、搜索代码，**不能做任何修改**。它会探索代码库，分析你的需求，然后给出一个详细的实现计划。
|
||||
|
||||
### Plan Mode 的正确打开方式
|
||||
|
||||
关键操作：**按 Ctrl+G 可以在你的编辑器里打开并编辑计划。**
|
||||
|
||||
这意味着你可以：
|
||||
1. 让 Claude 生成初始计划
|
||||
2. Ctrl+G 打开计划，删掉你不同意的部分，补充你自己的想法
|
||||
3. 切回正常模式（Shift+Tab），让 Claude 按修改后的计划执行
|
||||
|
||||
改一个计划只需要一句话，改已经写好的代码要十倍的时间。
|
||||
|
||||
### 推荐的复杂任务工作流
|
||||
|
||||
官方推荐的标准流程是四步：**探索 → 规划 → 实现 → 验证**。
|
||||
|
||||
```
|
||||
1. 进入 Plan Mode
|
||||
2. 让 Claude 阅读相关代码："读一下 src/auth/ 下的代码，理解 session 处理逻辑"
|
||||
3. 请求计划："制定一个 OAuth2 迁移方案"
|
||||
4. Ctrl+G 审查和编辑计划
|
||||
5. 切回正常模式
|
||||
6. "按照计划实现，写完跑测试"
|
||||
7. 让 Claude 对照需求自查
|
||||
```
|
||||
|
||||
### 什么时候不需要 Plan Mode
|
||||
|
||||
- 改一个变量名
|
||||
- 修一个明显的 typo
|
||||
- 加一行日志
|
||||
|
||||
判断标准很简单：如果这个任务的实现方式只有一种，直接做。如果有多种选择，先规划。
|
||||
|
||||
---
|
||||
|
||||
## 四、子 AGENT：CLAUDE CODE 的分身术
|
||||
|
||||
子 Agent 是 Claude Code 的一个强大机制——它可以启动独立的 AI 进程来并行处理任务，每个子 Agent 有自己的上下文窗口，不会污染你的主对话。
|
||||
|
||||
### 内置的子 Agent 类型
|
||||
|
||||
| 类型 | 能力 | 用途 |
|
||||
|------|------|------|
|
||||
| Explore | 只读 | 快速搜索代码库探索、找文件、找定义 |
|
||||
| Plan | 只读 | 研究分析Plan Mode 下的代码分析 |
|
||||
| General | 完整能力 | 复杂的多步骤任务 |
|
||||
|
||||
### 子 Agent 最大的价值：隔离上下文
|
||||
|
||||
当你让 Claude 跑测试、分析日志、搜索大量文件时，这些操作会产生海量输出，塞满你的上下文窗口。用子 Agent 来做这些事，输出留在子 Agent 的上下文里，只有摘要返回给你。
|
||||
|
||||
比如：
|
||||
|
||||
> "用子 Agent 跑一下全量测试，把失败的用例列出来"
|
||||
|
||||
> "用子 Agent 搜索所有使用了 deprecated API 的文件"
|
||||
|
||||
### 后台运行：Ctrl+B
|
||||
|
||||
按 Ctrl+B 可以把子 Agent 放到后台运行。你可以继续和 Claude 聊其他事，等后台任务完成后会自动通知你。
|
||||
|
||||
适合：
|
||||
- 跑测试套件（通常需要几分钟）
|
||||
- 大范围代码搜索
|
||||
- 不紧急的代码审查
|
||||
|
||||
### 自定义子 Agent
|
||||
|
||||
你可以在 .claude/agents/ 目录下创建自定义 Agent：
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: code-reviewer
|
||||
description: 代码审查专家。代码改动后自动触发。
|
||||
tools: Read, Grep, Glob, Bash
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
你是一位资深代码审查者。检查以下维度：
|
||||
- 代码清晰度和可读性
|
||||
- 错误处理是否完整
|
||||
- 有没有暴露敏感信息
|
||||
- 输入验证
|
||||
- 然后在对话中用 @code-reviewer (agent)" 调用它。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、上下文管理：最容易被忽视的关键
|
||||
|
||||
Claude Code 的上下文窗口虽然大（最多 1M token），但它不是无限的，而且上下文管理直接决定了输出质量。
|
||||
|
||||
### 上下文里都装了什么
|
||||
|
||||
- 你的对话历史
|
||||
- Claude 读取的所有文件内容
|
||||
- 命令执行的输出
|
||||
- CLAUDE.md 文件（每次都加载）
|
||||
- Memory 文件（前 200 行）
|
||||
- 加载的 Skill 和 MCP 工具定义
|
||||
|
||||
### 五个实用策略
|
||||
|
||||
1. **/clear ：一件事做完就清**
|
||||
不要在同一个对话里又修 bug 又加功能又重构。/clear 会清空上下文但保留 CLAUDE.md，相当于一次免费的重启。
|
||||
|
||||
2. **/compact ：手动压缩上下文**
|
||||
当对话变长时，输入 /compact 让 Claude 自动总结和压缩之前的对话。更好的用法是**给压缩加一个焦点**：
|
||||
|
||||
/compact 专注于 API 改动和测试结果
|
||||
|
||||
这样 Claude 在压缩时会优先保留你关心的内容。
|
||||
|
||||
3. **/context ：看看上下文被谁吃了**
|
||||
输入 /context 可以看到当前上下文的使用情况——哪些文件占了多少 token，MCP 工具定义占了多少。我经常发现一些没用的 MCP server 占了大量空间。
|
||||
|
||||
4. **用子 Agent 隔离噪声**
|
||||
跑测试、分析日志这些操作会产生大量输出。让子 Agent 去做，主对话的上下文保持干净。
|
||||
|
||||
5. **在 CLAUDE.md 里写压缩保留指令**
|
||||
你可以告诉 Claude 压缩时必须保留什么：
|
||||
|
||||
```
|
||||
# 压缩指令
|
||||
压缩上下文时，始终保留：
|
||||
- 已修改文件的完整列表
|
||||
- 测试命令和结果
|
||||
- 关键的架构决策
|
||||
```
|
||||
|
||||
### Memory vs CLAUDE.md
|
||||
|
||||
**Memory 适合存什么：**
|
||||
你的偏好（"这个人喜欢简洁回复"）、项目约定（"部署有个特殊步骤"）、历史决策（"上次选了方案 A 是因为 X"）。
|
||||
|
||||
**Memory 不适合存什么：**
|
||||
代码细节、Git 历史、临时状态——这些从代码和 Git 里获取更准确。
|
||||
|
||||
用 /memory 命令可以查看和管理所有已加载的 Memory。
|
||||
|
||||
---
|
||||
|
||||
## 六、权限管理：安全和效率的平衡
|
||||
|
||||
Claude Code 提供了五种权限模式，用 Shift+Tab 在对话中循环切换。
|
||||
|
||||
### 权限规则配置
|
||||
|
||||
在 .claude/settings.json 里，你可以精细控制每种工具的权限：
|
||||
|
||||
```json
|
||||
{
|
||||
"permissions": {
|
||||
"allow": [
|
||||
"Bash(npm run *)",
|
||||
"Bash(git commit *",
|
||||
"Edit(src/**/*.ts)",
|
||||
"Read(*.md)"
|
||||
],
|
||||
"deny": [
|
||||
"Bash(rm -rf *)",
|
||||
"Edit(.env)"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
规则优先级：deny → ask → allow（deny 最优先）。
|
||||
|
||||
这意味着你可以大胆地 allow 常用命令，同时用 deny 保护敏感文件。比如 .env 文件，无论如何都不应该被编辑。
|
||||
|
||||
### 设置文件的层级
|
||||
|
||||
和 CLAUDE.md 类似，settings 也有多级：
|
||||
|
||||
```
|
||||
组织策略（最高优先级）
|
||||
↓
|
||||
CLI 参数
|
||||
↓
|
||||
.claude/settings.local.json（本地，不提交到 Git）
|
||||
↓
|
||||
.claude/settings.json（项目级，团队共享）
|
||||
↓
|
||||
~/.claude/settings.json（全局，个人）
|
||||
↓
|
||||
默认值（最低优先级）
|
||||
```
|
||||
|
||||
我的建议：把团队共享的规则放 .claude/settings.json，个人偏好放 ~/.claude/settings.json，敏感配置放 .claude/settings.local.json（记得加到 .gitignore）。
|
||||
|
||||
---
|
||||
|
||||
## 七、HOOKS：让规则变成铁律
|
||||
|
||||
CLAUDE.md 里的指令是"建议"——Claude 大部分时候会遵守，但偶尔会忘。Hooks 是"铁律"——无论如何都会执行。
|
||||
|
||||
Hooks 是在特定生命周期事件上自动触发的 shell 命令。配置在 settings.json 里。
|
||||
|
||||
### 关键事件类型
|
||||
|
||||
| 事件 | 触发时机 |
|
||||
|------|----------|
|
||||
| PreToolUse | 工具执行前 |
|
||||
| PostToolUse | 工具执行后 |
|
||||
| Notification | 通知事件 |
|
||||
| Stop | 对话结束时 |
|
||||
|
||||
### 实用示例
|
||||
|
||||
**自动格式化——每次编辑后运行 Prettier：**
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"PostToolUse": [{
|
||||
"matcher": "Edit|Write",
|
||||
"hooks": [{
|
||||
"type": "command",
|
||||
"command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**保护关键文件——阻止修改生产配置：**
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"PreToolUse": [{
|
||||
"matcher": "Edit|Write",
|
||||
"hooks": [{
|
||||
"type": "command",
|
||||
"command": ".claude/hooks/protect-files.sh"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Hook 命令返回 exit code 0 表示允许，exit code 2 表示阻止。这意味着你可以写任意复杂的判断逻辑。
|
||||
|
||||
**上下文压缩后重新注入关键信息：**
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"SessionStart": [{
|
||||
"matcher": "compact",
|
||||
"hooks": [{
|
||||
"type": "command",
|
||||
"command": "echo '用 Bun 不用 npm。提交前跑 bun test。'"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
这解决了一个常见痛点：对话太长被压缩后，之前提过的重要指令可能丢失。用 Hook 可以在每次压缩后自动重新注入。
|
||||
|
||||
### Hook 的四种类型
|
||||
|
||||
| 类型 | 说明 |
|
||||
|------|------|
|
||||
| command | 执行 shell 命令，从 stdin 读取 JSON |
|
||||
| http | 向 URL 发送 POST 请求 |
|
||||
| prompt | 单次 LLM 调用，做 yes/no 判断 |
|
||||
| agent | 启动一个子 Agent 进行验证 |
|
||||
|
||||
---
|
||||
|
||||
## 八、GIT 工作流：用好 WORKTREE
|
||||
|
||||
Claude Code 能执行 Git 命令，这是一把双刃剑。但官方提供了一个很好的安全网：Worktree。
|
||||
|
||||
### Git Worktree：隔离的工作空间
|
||||
|
||||
```
|
||||
# 在隔离的 worktree 中启动 Claude
|
||||
claude --worktree feature-auth
|
||||
claude --worktree bugfix-123
|
||||
|
||||
# 自动生成名字
|
||||
claude --worktree
|
||||
```
|
||||
|
||||
Worktree 会在 .claude/worktrees/ 下创建一个独立的 Git 分支副本。Claude 在里面怎么折腾都不影响你的主分支。退出时：
|
||||
|
||||
- 如果没有改动 → 自动清理
|
||||
- 如果有改动 → 提示你保留或删除
|
||||
|
||||
这对于探索性任务特别有用。不确定某个重构方案能不能行？开个 worktree 试试，不行就扔掉，零风险。
|
||||
|
||||
### 几个 Git 铁律
|
||||
|
||||
1. **永远不要让 Claude Code 自动 push**
|
||||
它可以 commit，但 push 这个动作应该由你来确认。一旦 push 到远端，回退成本就大了。
|
||||
|
||||
2. **频繁 commit**
|
||||
做完一个小功能就 commit。用 /rewind 可以回退到任意一个 checkpoint，但前提是你有 commit 记录。
|
||||
|
||||
3. **警惕破坏性操作**
|
||||
如果 Claude Code 要执行 git reset --hard、git push --force、rm -rf，一定要再脑子里过一遍后果再批准。这些操作没有 undo。你也可以在权限规则里直接 deny 掉这些命令。
|
||||
|
||||
4. **从 PR 恢复上下文**
|
||||
这会自动加载 PR 的改动和讨论作为上下文，非常适合 code review 或者继续别人的工作。
|
||||
|
||||
```
|
||||
claude --from-pr 123
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 九、快捷键和命令速查
|
||||
|
||||
这些快捷键我每天都在用，强烈建议记住：
|
||||
|
||||
### 最常用的快捷键
|
||||
|
||||
| 快捷键 | 功能 |
|
||||
|--------|------|
|
||||
| Ctrl+C | 中断 Claude |
|
||||
| Ctrl+V | 粘贴图片 |
|
||||
| Ctrl+G | 编辑计划 |
|
||||
| Ctrl+Shift+Enter | 提交文件（不确认） |
|
||||
| Shift+Tab | 切换权限模式 |
|
||||
|
||||
### 最常用的斜杠命令
|
||||
|
||||
```
|
||||
/compact [焦点] # 压缩上下文，可指定保留重点
|
||||
/clear # 清空对话，重新开始
|
||||
/context # 查看上下文使用情况
|
||||
/memory # 查看和管理 Memory
|
||||
/rewind # 回退到某个 checkpoint
|
||||
/resume [名称] # 恢复之前的对话
|
||||
/model # 切换模型
|
||||
/effort [级别] # 设置推理深度：low/medium/high/max
|
||||
/init # 自动生成 CLAUDE.md
|
||||
/mcp # 管理 MCP 服务器
|
||||
/permissions # 查看权限规则
|
||||
/cost # 查看 token 消耗
|
||||
```
|
||||
|
||||
/init 对新项目特别有用——它会自动分析你的代码库，帮你生成一个 CLAUDE.md 的初稿。虽然通常需要手动调整，但比从零开始快得多。
|
||||
|
||||
---
|
||||
|
||||
## 十、EXTENDED THINKING：让 CLAUDE 想深一点
|
||||
|
||||
对于复杂问题，你可以开启 Extended Thinking 模式，让 Claude 在回答前花更多时间推理。
|
||||
|
||||
### 怎么用
|
||||
|
||||
```
|
||||
# 快捷键切换
|
||||
Option+T (Mac) / Alt+T (Windows/Linux)
|
||||
|
||||
# 或者用命令
|
||||
/effort high # 更深入的推理
|
||||
/effort max # 最大推理深度
|
||||
/effort low # 简单任务，省 token
|
||||
```
|
||||
|
||||
### 什么时候该用
|
||||
|
||||
- 复杂的架构决策
|
||||
- 棘手的 debug（多个可能原因需要排除）
|
||||
- 多步骤的重构方案设计
|
||||
- 权衡多个方案的利弊
|
||||
|
||||
### 什么时候不需要
|
||||
|
||||
- 简单的代码修改
|
||||
- 格式化、重命名
|
||||
- 已经很明确的 bug 修复
|
||||
|
||||
小技巧：在提示词里写 ultrathink 可以强制触发最高推理深度，不需要手动调整 effort 设置。
|
||||
|
||||
---
|
||||
|
||||
## 十一、MCP SERVER：让 CLAUDE 连接外部世界
|
||||
|
||||
MCP（Model Context Protocol）让 Claude Code 能和外部工具通信——GitHub、数据库、Slack、Notion 等等。
|
||||
|
||||
### 快速添加
|
||||
|
||||
```bash
|
||||
claude mcp add github -- npx @anthropic-ai/mcp-server-github
|
||||
claude mcp add postgres -- npx @anthropic-ai/mcp-server-postgres postgresql://localhost:5432/mydb
|
||||
```
|
||||
|
||||
### 配置文件
|
||||
|
||||
MCP 配置在 .mcp.json 里：
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"github": {
|
||||
"type": "stdio",
|
||||
"command": "npx",
|
||||
"args": ["@modelcontextprotocol/server-github"],
|
||||
"env": {
|
||||
"GITHUB_TOKEN": "$GITHUB_TOKEN"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 注意上下文开销
|
||||
|
||||
每个 MCP server 会额外消耗 100-500+ token 的工具定义。用 /mcp 命令可以查看每个 server 的开销，禁用不用的 server。
|
||||
|
||||
我的经验：不要贪多。常用的 2-3 个 MCP server 就够了。装太多，上下文空间被工具定义吃掉，反而影响代码分析的质量。
|
||||
|
||||
---
|
||||
|
||||
## 十二、IDE 集成：不只是终端
|
||||
|
||||
### VS Code
|
||||
|
||||
安装 Claude Code 扩展后，你可以在 VS Code 里直接使用 Claude，而不需要切到终端。
|
||||
|
||||
几个好用的功能：
|
||||
- **并排 diff 视图**：Claude 的改动以 diff 形式显示，一目了然
|
||||
- **Option+K / Alt+K**：快速插入当前文件的 @引用
|
||||
- **多标签对话**：在不同的标签页里开多个独立对话
|
||||
- **Cmd+Shift+Esc**：快速打开新的对话标签
|
||||
|
||||
### JetBrains
|
||||
|
||||
IntelliJ、PyCharm、WebStorm 等 JetBrains 全家桶也有 Claude Code 插件，在 Plugins 市场搜索 "Claude Code" 安装即可。
|
||||
|
||||
---
|
||||
|
||||
## 十三、审查代码：信任但要验证
|
||||
|
||||
Claude Code 写的代码质量总体不错，但你不能盲目信任。
|
||||
|
||||
### 几个常见问题
|
||||
|
||||
1. **过度工程**
|
||||
你让它写一个简单的工具函数，它给你搞出一个完整的抽象层，带泛型、带接口、带工厂模式。杀鸡用了牛刀。
|
||||
|
||||
解决方法：在 CLAUDE.md 里写上"优先用简单方案"，或在指令里明确说"不需要抽象"。
|
||||
|
||||
2. **幻觉 API**
|
||||
它有时候会用不存在的 API 或者过时的语法。尤其是小众库的新版本。
|
||||
|
||||
解决方法：跑测试。这也是为什么指令里应该包含验证标准。
|
||||
|
||||
3. **改动范围膨胀**
|
||||
你让它改一个函数，它把整个文件都重构了。
|
||||
|
||||
解决方法：明确说"只改 X，不要动其他代码"。或者用 /freeze 命令限制编辑范围到指定目录。
|
||||
|
||||
### Writer/Reviewer 模式
|
||||
|
||||
官方推荐的一个高级模式：用两个独立的会话分别扮演"写代码"和"审查代码"的角色。
|
||||
|
||||
两个会话有独立的上下文，Reviewer 不受 Writer 的思路影响，能发现 Writer 的盲点。
|
||||
|
||||
```
|
||||
会话 A（Writer）："实现 API 限流中间件"
|
||||
会话 B（Reviewer）："审查 @src/middleware/rateLimiter.ts 里的限流实现，重点看边界情况、竞态条件、一致性"
|
||||
会话 A："修复审查反馈：[粘贴 B 的输出]"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 十四、不要用 CLAUDE CODE 做的事
|
||||
|
||||
说了这么多"应该怎么做"，最后聊聊"不应该做什么"。
|
||||
|
||||
1. **不要让它做你完全不了解的事**
|
||||
如果你对 Kubernetes 一无所知，不要让 Claude Code 帮你写部署配置然后直接用。你无法审查你不懂的东西。
|
||||
|
||||
2. **不要在没有版本控制的环境下用**
|
||||
没有 Git 就没有回退的能力。Claude Code 的改动可能覆盖你的文件，没有版本控制就是裸奔。
|
||||
|
||||
3. **不要一口气扔一个巨大的任务**
|
||||
> "把整个项目从 JavaScript 迁移到 TypeScript"
|
||||
|
||||
这种指令等于让 Claude Code 自由发挥。结果不可控。拆成小步骤，每一步确认后再做下一步。
|
||||
|
||||
4. **不要指望一次就完美**
|
||||
迭代是正常的。用 /rewind 回退，用精确的反馈描述"哪里不对"。
|
||||
|
||||
---
|
||||
|
||||
## 总结
|
||||
|
||||
Claude Code 的核心使用哲学其实很简单：**它是一个极其能干的协作者，但不是自动驾驶。方向盘始终在你手里。**
|
||||
|
||||
按重要性排序，我的建议是：
|
||||
|
||||
1. **写好 CLAUDE.md** — 一次投入，每次对话都受益
|
||||
2. **给精确的指令** — 目标 + 约束 + 验证标准
|
||||
3. **用 Plan Mode** — 复杂任务先规划再动手
|
||||
4. **管理上下文** — /clear、/compact、子 Agent
|
||||
5. **控制权限** — deny 危险操作，allow 常用命令
|
||||
6. **频繁 commit** — 保留回退能力
|
||||
|
||||
做不到这些，Claude Code 只会更快地帮你制造混乱。
|
||||
|
||||
**工具的价值，永远取决于使用它的人。**
|
||||
|
||||
---
|
||||
|
||||
> 以上结合了 Claude Code 官方文档和实战经验。如果你有更好的实践，欢迎交流。
|
||||
447
openclaw/xinghui/Product-Manager-Skills-完整使用指南.md
Normal file
447
openclaw/xinghui/Product-Manager-Skills-完整使用指南.md
Normal file
@@ -0,0 +1,447 @@
|
||||
# Product Manager Skills 完整使用指南
|
||||
|
||||
> 作者：沈盟 (程序员猫舍)
|
||||
> 来源：Telegra.ph
|
||||
> 发布时间：2026年3月27日
|
||||
> 链接：https://telegra.ph/Product-Manager-Skills-%E5%AE%8C%E6%95%B4%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97-03-26
|
||||
|
||||
---
|
||||
|
||||
## 1. 总体概述
|
||||
|
||||
### 1.1 什么是 Product Manager Skills？
|
||||
|
||||
这是一套**产品管理框架的数字化封装**，包含 46 个独立但相互关联的技能（Skill），每个技能对应产品管理工作中的一个具体环节。
|
||||
|
||||
**核心理念**：
|
||||
> 用户不是买产品，而是"雇佣"产品来完成某项工作（Jobs-To-Be-Done）。
|
||||
|
||||
**设计目标**：
|
||||
- 📚 将经典产品管理方法论（JTBD、OST、精益 UX 等）转化为可执行的 AI 工作流
|
||||
- 🔗 打通产品发现→定义→交付→验证的完整链条
|
||||
- 🎯 避免"功能工厂"陷阱，确保团队解决正确的问题
|
||||
|
||||
### 1.2 与 JTBD 的关系
|
||||
|
||||
JTBD (Jobs-To-Be-Done) 是这套技能体系的**核心思想基础**：
|
||||
|
||||
```
|
||||
JTBD 理论 → 理解用户"雇佣"产品完成的工作
|
||||
↓
|
||||
产品发现 → 搞清楚用户真正的需求是什么
|
||||
↓
|
||||
产品定义 → 决定做什么来解决这些需求
|
||||
↓
|
||||
产品交付 → 把解决方案做出来
|
||||
↓
|
||||
产品验证 → 检查是否真的解决了问题
|
||||
```
|
||||
|
||||
这 46 个技能就是沿着这个链条展开的**工具箱**。
|
||||
|
||||
### 1.3 技能分类总览
|
||||
|
||||
46 个技能分为 5 大类：
|
||||
- 📊 用户研究类 (5 个)
|
||||
- 📈 市场分析类 (6 个)
|
||||
- 🎯 产品定义类 (8 个)
|
||||
- 📝 文档输出类 (6 个)
|
||||
- 📋 战略规划类 (7 个)
|
||||
- 🎓 高阶能力类 (14 个)
|
||||
|
||||
---
|
||||
|
||||
## 2. 技能全景图
|
||||
|
||||
### 2.1 产品管理工作流地图
|
||||
|
||||
```
|
||||
阶段 1: 产品发现 (Discovery)
|
||||
目标：搞清楚用户是谁？问题是什么？值不值得做？
|
||||
─────────────────────────────────────────────
|
||||
proto-persona → jobs-to-be-done → customer-journey-map
|
||||
初步画像 用户待办 用户旅程
|
||||
|
||||
↓ ↓ ↓
|
||||
|
||||
company-research → discovery-interview → tam-sam-som-calculator
|
||||
竞品调研 访谈准备 市场规模
|
||||
```
|
||||
|
||||
```
|
||||
阶段 2: 产品定义 (Definition)
|
||||
目标：搞清楚做什么？不做什么？优先级？
|
||||
─────────────────────────────────────────────
|
||||
problem-framing → opportunity-solution-tree → prioritization-advisor
|
||||
问题画布 机会方案树 优先级建议
|
||||
|
||||
↓ ↓ ↓
|
||||
|
||||
positioning-statement → epic-hypothesis → user-story-mapping
|
||||
定位陈述 史诗假设 故事地图
|
||||
```
|
||||
|
||||
```
|
||||
阶段 3: 产品交付 (Delivery)
|
||||
目标：怎么写文档？怎么拆任务？怎么验收？
|
||||
─────────────────────────────────────────────
|
||||
prd-development → user-story → storyboard
|
||||
需求文档 用户故事 故事板
|
||||
|
||||
↓ ↓ ↓
|
||||
|
||||
press-release → epic-breakdown → lean-ux-canvas
|
||||
新闻稿 史诗拆分 精益 UX
|
||||
```
|
||||
|
||||
```
|
||||
阶段 4: 产品验证 (Validation)
|
||||
目标：做得怎么样？要不要调整？下一步？
|
||||
─────────────────────────────────────────────
|
||||
business-health-diagnostic → feature-investment-advisor → roadmap-planning
|
||||
业务诊断 投资建议 路线图规划
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心技能详解
|
||||
|
||||
### 3.1 jobs-to-be-done（用户待办任务）
|
||||
|
||||
**核心功能**：系统性地探索用户真正想完成的工作，而非表面需求。
|
||||
|
||||
**解决的问题**：
|
||||
- 用户说的"想要更快"到底是什么意思？
|
||||
- 为什么有些功能上线后数据没变化？
|
||||
- 如何避免做错功能？
|
||||
|
||||
**输出结构**：
|
||||
```markdown
|
||||
## Jobs-to-be-Done 分析
|
||||
|
||||
### 1. Customer Jobs（用户想完成的事）
|
||||
#### Functional Jobs（功能层面）
|
||||
#### Social Jobs（社会层面）
|
||||
#### Emotional Jobs（情感层面）
|
||||
|
||||
### 2. Pains（痛苦）
|
||||
#### Challenges（障碍）
|
||||
#### Costliness（代价）
|
||||
#### Common Mistakes（常见错误）
|
||||
#### Unresolved Problems（未解决问题）
|
||||
|
||||
### 3. Gains（收益）
|
||||
#### Expectations（期待）
|
||||
#### Savings（节省）
|
||||
#### Adoption Factors（采用因素）
|
||||
#### Life Improvement（生活改善）
|
||||
```
|
||||
|
||||
**使用示例**：
|
||||
- 场景：老板说"用户想要更快的开票速度"
|
||||
- 调用 jobs-to-be-done 后发现：
|
||||
- 表面需求："更快开票"
|
||||
- 真实 JTBD："从完工到收款的整个流程别耽误"
|
||||
- 真正机会：自动催款 + 收款跟踪，而不是"一键开票"按钮
|
||||
|
||||
---
|
||||
|
||||
### 3.2 opportunity-solution-tree（机会方案树）
|
||||
|
||||
**核心功能**：从模糊的需求到结构化的探索，避免"功能工厂"陷阱。
|
||||
|
||||
**解决的问题**：
|
||||
- 老板/客户直接说"我要这个功能"怎么办？
|
||||
- 如何确保团队在解决问题，而不是盲目堆功能？
|
||||
- 如何系统性地探索多种解决方案？
|
||||
|
||||
**输出结构**：
|
||||
```
|
||||
期望结果 (Outcome)
|
||||
│
|
||||
├── 机会 1 (问题/需求)
|
||||
│ ├── 方案 1 (实验)
|
||||
│ └── 方案 2 (实验)
|
||||
│
|
||||
├── 机会 2 (问题/需求)
|
||||
│ ├── 方案 1 (A/B测试)
|
||||
│ └── 方案 2 (可用性测试)
|
||||
│
|
||||
└── 机会 3 (问题/需求)
|
||||
└── ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3.3 prd-development（产品需求文档）
|
||||
|
||||
**核心功能**：将发现阶段的洞察转化为工程可执行的 PRD 文档。
|
||||
|
||||
**输出结构**：
|
||||
```markdown
|
||||
# [功能名称] PRD
|
||||
|
||||
## 1. 执行摘要
|
||||
## 2. 问题陈述（谁？问题？证据？）
|
||||
## 3. 目标用户与画像
|
||||
## 4. 战略背景（业务目标、市场机会、竞争格局）
|
||||
## 5. 方案概述
|
||||
## 6. 成功指标
|
||||
## 7. 用户故事与需求
|
||||
## 8. 不在范围内
|
||||
## 9. 依赖与风险
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3.4 prioritization-advisor（优先级建议）
|
||||
|
||||
**核心功能**：根据团队阶段和上下文，选择合适的优先级框架。
|
||||
|
||||
**推荐框架**：
|
||||
| 场景 | 推荐框架 |
|
||||
|------|----------|
|
||||
| 早期创业 | ICE |
|
||||
| 成长期 | RICE |
|
||||
| 企业/数据成熟 | WSJF |
|
||||
| 简单快速 | MoSCoW |
|
||||
|
||||
---
|
||||
|
||||
### 3.5 user-story（用户故事）
|
||||
|
||||
**输出格式**：
|
||||
```markdown
|
||||
### 用户故事 [ID]
|
||||
|
||||
#### 用例（Mike Cohn 格式）
|
||||
- **作为** [用户角色]
|
||||
- **我想要** [执行的动作]
|
||||
- **以便于** [期望的结果/价值]
|
||||
|
||||
#### 验收标准（Gherkin 格式）
|
||||
- **场景**: [场景描述]
|
||||
- **给定**: [前提条件]
|
||||
- **当**: [触发事件]
|
||||
- **那么**: [期望结果]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 技能协作工作流
|
||||
|
||||
### 4.1 标准产品开发生命周期
|
||||
|
||||
```
|
||||
阶段 1: 发现 (Discovery)
|
||||
1. proto-persona → 定义目标用户
|
||||
2. jobs-to-be-done → 发现真实需求
|
||||
3. customer-journey-map → 绘制旅程
|
||||
4. tam-sam-som-calculator → 评估市场
|
||||
5. discovery-interview → 用户访谈
|
||||
|
||||
产出：用户洞察文档 + 机会评估报告
|
||||
|
||||
阶段 2: 定义 (Definition)
|
||||
6. problem-framing-canvas → 定义问题
|
||||
7. opportunity-solution-tree → 探索方案
|
||||
8. prioritization-advisor → 选择框架并排序
|
||||
9. positioning-statement → 产品定位
|
||||
|
||||
产出：优先级排序 + 产品定位文档
|
||||
|
||||
阶段 3: 交付 (Delivery)
|
||||
10. prd-development → 写 PRD
|
||||
11. user-story-mapping → 故事地图
|
||||
12. user-story → 写用户故事
|
||||
13. storyboard → 画故事板
|
||||
14. press-release → 写新闻稿
|
||||
|
||||
产出：PRD + 用户故事 + 故事板
|
||||
|
||||
阶段 4: 验证 (Validation)
|
||||
15. business-health-diagnostic → 上线后评估
|
||||
16. feature-investment-advisor → 决定下一步
|
||||
17. roadmap-planning → 更新路线图
|
||||
|
||||
产出：健康度报告 + 更新后的路线图
|
||||
```
|
||||
|
||||
### 4.2 技能调用依赖关系
|
||||
|
||||
```
|
||||
jobs-to-be-done
|
||||
↓
|
||||
problem-framing-canvas
|
||||
↓
|
||||
opportunity-solution-tree
|
||||
↓
|
||||
prioritization-advisor
|
||||
↓
|
||||
prd-development
|
||||
↓
|
||||
user-story-mapping
|
||||
↓
|
||||
user-story
|
||||
↓
|
||||
storyboard
|
||||
```
|
||||
|
||||
### 4.3 常见协作模式
|
||||
|
||||
| 模式 | 适用场景 | 技能链 |
|
||||
|------|----------|--------|
|
||||
| A: 新功能开发 | 完整流程 | proto-persona → jobs-to-be-done → OST → prioritization → PRD → user-story → storyboard |
|
||||
| B: 体验优化 | 聚焦旅程 | customer-journey-map → problem-framing → user-story-mapping → user-story → PRD |
|
||||
| C: 快速验证 | MVP 路线 | problem-framing → OST → lean-ux-canvas → press-release → user-story |
|
||||
| D: 季度规划 | 战略视角 | business-health-diagnostic → product-strategy-session → altitude-horizon → roadmap |
|
||||
|
||||
---
|
||||
|
||||
## 5. 完整案例演示
|
||||
|
||||
### 案例背景
|
||||
- **公司**：一款面向自由职业者的在线发票 SaaS
|
||||
- **问题**：用户流失率高，老板要求"提升用户体验"
|
||||
- **角色**：产品经理
|
||||
|
||||
### 第 1 步：理解用户（jobs-to-be-done）
|
||||
|
||||
**输入**：
|
||||
- 产品类型：在线发票工具
|
||||
- 目标用户：自由职业者（设计师、开发者、顾问）
|
||||
- 表面问题："用户说开票太麻烦"
|
||||
|
||||
**关键洞察**：
|
||||
> 用户说的"开票麻烦"，真实意思是"从完工到收款的整个流程太折腾"。真正的机会是**自动催款 + 收款跟踪**。
|
||||
|
||||
### 第 2 步：探索方案（opportunity-solution-tree）
|
||||
|
||||
**期望结果**：提升用户留存率 20%
|
||||
|
||||
**机会探索**：
|
||||
- 机会 1：用户忘记催款 → 方案：自动提醒
|
||||
- 机会 2：客户弄丢发票 → 方案：自助查询
|
||||
- 机会 3：对账麻烦 → 方案：自动对账
|
||||
|
||||
### 第 3 步：确定优先级（prioritization-advisor）
|
||||
|
||||
**推荐框架**：RICE
|
||||
|
||||
**评分结果**：
|
||||
1. 自动催款提醒 RICE = 45
|
||||
2. 发票自助查询 RICE = 32
|
||||
3. 自动对账 RICE = 28
|
||||
|
||||
### 第 4 步：写 PRD（prd-development）
|
||||
|
||||
产出完整的 PRD 文档，包含执行摘要、问题陈述、目标用户、成功指标、用户故事等。
|
||||
|
||||
### 第 5-7 步：拆故事 → 画故事板 → 验证结果
|
||||
|
||||
最终成果：
|
||||
- 收款周期缩短 36%
|
||||
- 续费率提升 18%
|
||||
- 用户满意度显著提升
|
||||
|
||||
---
|
||||
|
||||
## 6. 使用手册
|
||||
|
||||
### 6.1 安装与配置
|
||||
|
||||
- **位置**：~/.openclaw/workspace/skills/
|
||||
- **技能数量**：46 个
|
||||
- **占用空间**：约 2MB
|
||||
|
||||
### 6.2 如何调用技能
|
||||
|
||||
在 OpenClaw 会话中：
|
||||
- **方式 1**：直接提及技能名
|
||||
- "帮我用 jobs-to-be-done 分析一下发票工具的用户需求"
|
||||
- **方式 2**：描述任务，AI 自动匹配
|
||||
- **方式 3**：使用技能前缀
|
||||
- "/skills prd-development 我要写一个 PRD"
|
||||
|
||||
### 6.3 新手入门路径
|
||||
|
||||
**第 1 周：掌握核心 5 技能**
|
||||
- Day 1-2: jobs-to-be-done（理解用户）
|
||||
- Day 3-4: user-story（拆分需求）
|
||||
- Day 5: prd-development（写文档）
|
||||
- Day 6: prioritization-advisor（排优先级）
|
||||
- Day 7: 复习 + 实战练习
|
||||
|
||||
**第 2 周：扩展技能栈**
|
||||
- Day 8-9: opportunity-solution-tree
|
||||
- Day 10-11: customer-journey-map
|
||||
- Day 12: problem-framing-canvas
|
||||
- Day 13: user-story-mapping
|
||||
- Day 14: 完整项目实战
|
||||
|
||||
### 6.4 最佳实践
|
||||
|
||||
**✅ 应该做的**：
|
||||
1. **先理解问题，再跳方案** - 先用 jobs-to-be-done，再用 opportunity-solution-tree，避免直接写 PRD
|
||||
2. **文档是活的，不是交付物** - PRD、用户故事都是"活文档"，随着认知更新而更新
|
||||
3. **技能是框架，不是答案** - 技能帮你结构化思考，真正的答案来自用户调研和数据
|
||||
4. **组合使用，效果最佳** - 单个技能有用，组合使用威力更大
|
||||
|
||||
**❌ 应该避免的**：
|
||||
1. 跳过发现阶段 - 错误：直接写 PRD；正确：先做 JTBD 分析
|
||||
2. 把技能当 checklist - 错误：机械地填充模板；正确：理解背后的思考框架
|
||||
3. 一次性用所有技能 - 错误：每个项目都用 46 个技能；正确：根据项目阶段选择
|
||||
4. 忽视验证环节 - 错误：功能上线就结束；正确：用 business-health-diagnostic 验证
|
||||
|
||||
---
|
||||
|
||||
## 7. 常见问题
|
||||
|
||||
**Q1: 这些技能适合什么类型的产品？**
|
||||
- ✅ SaaS 产品（B2B/B2C）
|
||||
- ✅ 互联网产品（App、Web）
|
||||
- ✅ 数字化转型项目
|
||||
- ⚠️ 硬件产品（部分技能适用，需调整）
|
||||
- ❌ 纯内容产品（如博客、视频）
|
||||
|
||||
**Q2: 小团队/个人开发者需要用这么多技能吗？**
|
||||
不需要全部。建议：
|
||||
- **个人开发者**：jobs-to-be-done + user-story + prd-development（3 个核心）
|
||||
- **小团队 (<10 人)**：+ opportunity-solution-tree + prioritization-advisor（5 个）
|
||||
- **中型团队**：根据项目需要灵活组合
|
||||
|
||||
**Q3: 技能和敏捷开发是什么关系？**
|
||||
互补关系：
|
||||
```
|
||||
产品技能 敏捷开发
|
||||
─────────────────────────────
|
||||
发现需求 → 产品 Backlog
|
||||
写 PRD → Sprint 规划
|
||||
用户故事 → 迭代开发
|
||||
验证结果 → Sprint 回顾
|
||||
```
|
||||
|
||||
**Q4: 技能输出的文档可以直接用吗？**
|
||||
可以，但建议：技能输出的是**框架和初稿**，需要结合具体业务填充细节，和团队 review 后定稿。
|
||||
|
||||
**Q5: 如何评估这些技能的效果？**
|
||||
看三个指标：
|
||||
- **需求准确性**：上线后是否解决了真实问题？
|
||||
- **团队效率**：沟通成本是否降低？
|
||||
- **业务结果**：核心指标是否提升？
|
||||
|
||||
**Q6: 技能会更新吗？**
|
||||
是的。技能来源于：
|
||||
- 经典产品管理理论（JTBD、OST 等）
|
||||
- 最新实践（AI 产品、上下文工程等）
|
||||
- 社区反馈
|
||||
|
||||
**Q7: 可以和 OpenClaw 的其他功能结合吗？**
|
||||
可以！例如：
|
||||
- 用 `searxng` 做竞品调研 → 输入 `company-research`
|
||||
- 用 `browser` 抓取用户反馈 → 输入 `jobs-to-be-done`
|
||||
- 用 `message` 推送 PRD 给团队 → `prd-development` 输出后
|
||||
|
||||
---
|
||||
|
||||
> 来源：由"微信搬运工"搬运（点击进入：https://t.me/wxbyg）
|
||||
@@ -45,10 +45,13 @@
|
||||
|
||||
---
|
||||
|
||||
## Obsidian 笔记路径
|
||||
## Obsidian 笔记目录
|
||||
|
||||
- **Obsidian 笔记目录**: `/Users/weishen/Library/Mobile Documents/iCloud~md~obsidian/Documents/weishen/`（以后提到 obsidian 笔记目录即指此目录）
|
||||
- **Obsidian 笔记目录**: `/Users/weishen/Workspace/nexus`（以后提到 obsidian 笔记目录即指此目录）
|
||||
- 子目录包含：knowledgebase、yunjiang 等
|
||||
- **Git 配置**: SSH 免密提交
|
||||
- remote.origin.url: `ssh://git@192.168.3.189:2222/admin/nexus.git`
|
||||
- 可直接 `git add` → `git commit` → `git push`
|
||||
|
||||
---
|
||||
|
||||
@@ -94,7 +97,7 @@
|
||||
|
||||
## 同步规则
|
||||
- **Workspace MEMORY.md** 更新时，自动同步复制到个人笔记目录：
|
||||
`/Users/weishen/Library/Mobile Documents/iCloud~md~obsidian/Documents/weishen/openclaw/yunjiang/MEMORY.md`
|
||||
`/Users/weishen/Workspace/nexus/openclaw/yunjiang/MEMORY.md`
|
||||
|
||||
## 每日必做 - 记忆习惯
|
||||
|
||||
@@ -122,4 +125,27 @@
|
||||
|
||||
---
|
||||
|
||||
*Last updated: 2026-03-21*
|
||||
## 2026-03-24 工作经验与教训
|
||||
|
||||
### 完成的功能
|
||||
1. **修复 easymde 模块名** - settings.py 中 'easy_mde' 改为 'easymde'
|
||||
2. **EasyMDE 高度自适应** - 添加 minHeight 和 maxHeight 配置
|
||||
|
||||
### 经验教训
|
||||
1. **Django 第三方包名** - PyPI 包名可能与模块名不同，需要核实（如 django-easymde → easymde）
|
||||
2. **EasyMDE 配置** - 通过 easymde_options 字典传递前端配置，支持 vh 单位
|
||||
3. **Django 静态文件** - STATIC_ROOT 是目标目录，第三方包自带的 static 文件自动被找到
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-25 工作经验与教训
|
||||
|
||||
### 完成的功能
|
||||
1. **Smart Trip Quote 客户演示提纲** - 编写客户演示讲解提纲，保存至 Obsidian 笔记
|
||||
|
||||
### 经验教训
|
||||
1. **文档输出流程** - 任务结果输出到 Obsidian 笔记目录，需要确保目录存在且 git 已配置
|
||||
|
||||
---
|
||||
|
||||
*Last updated: 2026-03-25*
|
||||
|
||||
Reference in New Issue
Block a user