diff --git a/openclaw/openclaw备份任务.md b/openclaw/openclaw备份任务.md
index 84b2a2da..3087e518 100644
--- a/openclaw/openclaw备份任务.md
+++ b/openclaw/openclaw备份任务.md
@@ -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 | ✅ 成功 |
diff --git a/openclaw/xinghui/AI研究工作流-观自.md b/openclaw/xinghui/AI研究工作流-观自.md
new file mode 100644
index 00000000..26d14912
--- /dev/null
+++ b/openclaw/xinghui/AI研究工作流-观自.md
@@ -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 有任何问题，或者有插件方面的需求，都可以联系我。
\ No newline at end of file
diff --git a/openclaw/xinghui/Bright-Data-MCP-技能配置.md b/openclaw/xinghui/Bright-Data-MCP-技能配置.md
new file mode 100644
index 00000000..ce119846
--- /dev/null
+++ b/openclaw/xinghui/Bright-Data-MCP-技能配置.md
@@ -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*
+*来源：星辉与比利的对话*
\ No newline at end of file
diff --git a/openclaw/xinghui/Claude-Code-最佳实践.md b/openclaw/xinghui/Claude-Code-最佳实践.md
new file mode 100644
index 00000000..c5f2ff5f
--- /dev/null
+++ b/openclaw/xinghui/Claude-Code-最佳实践.md
@@ -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 官方文档和实战经验。如果你有更好的实践，欢迎交流。
diff --git a/openclaw/xinghui/Product-Manager-Skills-完整使用指南.md b/openclaw/xinghui/Product-Manager-Skills-完整使用指南.md
new file mode 100644
index 00000000..9383e979
--- /dev/null
+++ b/openclaw/xinghui/Product-Manager-Skills-完整使用指南.md
@@ -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）
\ No newline at end of file
diff --git a/openclaw/yunjiang/MEMORY.md b/openclaw/yunjiang/MEMORY.md
index e4f20610..be1591ff 100644
--- a/openclaw/yunjiang/MEMORY.md
+++ b/openclaw/yunjiang/MEMORY.md
@@ -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*