添加学习笔记：模型工具调用、学习方法论、律师视频Agent等

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

学习笔记/00-模型工具调用-原点-1.md

@@ -0,0 +1,152 @@
+# 模型工具调用 - 00 原点
+
+> 把"模型使用工具"这件事,完全用我已有的知识树(操作系统 / 进程 / IPC / 网络协议)来理解,不引入新的本体概念。
+
+---
+
+## 两个原点
+
+整个"模型工具调用"机制,只需要两个原点就能展开:
+
+### 原点 1:任何工具 = 一个进程
+
+不管这个工具表面叫什么(`web_search`、`Gmail:search_threads`、`bash_tool`、`create_file`),背后都是某台机器上有一个**进程**在执行它。
+
+差别只在三个维度:
+
+- **位置**:进程在哪台主机上(本机 / 远程服务器)
+- **生命周期**:常驻服务进程 / 一次性 fork 出来的子进程
+- **特权级**:用户态业务进程 / 沙箱容器 / 受限子进程
+
+### 原点 2:模型调用工具 = 进程间通讯(IPC)
+
+模型本身也是一个进程——推理进程,通常跑在 GPU 服务器上。它"使用工具",本质就是**和另一个进程通讯**。
+
+整个工具调用机制,就是在解决 IPC 的几个经典问题:
+
+- **寻址**:怎么找到对方
+- **编码**:参数和返回值怎么序列化
+- **同步**:阻塞等结果还是异步回调
+- **容错**:对方挂了 / 超时 / 网络断了怎么办
+
+---
+
+## 通讯距离:两类 IPC
+
+按通讯双方是否在同一个内核内,工具调用的 IPC 分两大类。
+
+### A. 同主机 IPC(同一个内核)
+
+模型宿主和工具执行进程跑在同一台机器,通讯走**内核提供的本地机制**。
+
+| 内核机制 | 在工具调用里的体现 |
+|---|---|
+| 管道 / stdio | MCP 的 stdio 传输:宿主 fork 一个 MCP server 子进程,通过 stdin/stdout 收发 JSON-RPC |
+| Unix domain socket | 部分 MCP server 用本地 socket,比 TCP 快、有文件系统权限控制 |
+| 共享内存 | 推理框架内部传 KV cache 用,工具调用层基本不用 |
+| fork + exec | `bash_tool` 执行命令:宿主 fork 出 bash 子进程,等它退出后读 stdout |
+| 信号 | 超时 / 取消工具调用时,宿主给子进程发 SIGTERM |
+
+**典型场景**:Claude Code 在我自己电脑上跑——所有工具(读文件、跑命令、编辑代码)都是本地进程间通讯,没有走网络。
+
+### B. 跨主机 IPC(不同内核)
+
+模型在一台机器,工具在另一台,走**网络协议栈**。
+
+| 协议层 | 在工具调用里的体现 |
+|---|---|
+| 传输层 | TCP(可靠);几乎不用 UDP |
+| 安全层 | TLS 加密(远程工具几乎强制) |
+| 应用层 | HTTPS REST(主流);HTTP + SSE(MCP 远程模式);WebSocket(实时);gRPC(企业内部) |
+| 编码 | JSON(主流);Protobuf(gRPC);MessagePack(罕见) |
+
+**典型场景**:Claude.ai 调 Google Drive、Gmail、web_search 这类工具——全部是跨主机 HTTPS。
+
+---
+
+## 完整链路示例:`create_file` 的一次调用
+
+以"用 Google Drive 工具创建一个 .md 文件"为例,完整 IPC 链路:
+
+```
+[模型推理进程]                                          GPU 服务器
+       │
+       │ ① 输出 tool_use JSON(进程内,序列化)
+       ▼
+[Anthropic 宿主进程 / 编排器]                           Anthropic 数据中心
+       │
+       │ ② 路由:这个工具属于 Google Drive MCP
+       │ ③ HTTPS 请求(跨主机 IPC,TLS 加密)
+       ▼
+[Google Drive MCP Server 进程]                          Google 数据中心
+       │
+       │ ④ 翻译成 Drive REST API 调用(又一次跨主机 IPC)
+       ▼
+[Drive 后端服务进程集群]                                Google 数据中心
+       │
+       │ ⑤ 写入存储(底层又是无数 IPC,略)
+       │ ⑥ 返回 file metadata,原路 JSON 回传
+       ▼
+[模型上下文窗口]   ← tool_result 塞回这里,模型继续推理
+```
+
+**关键认识**:每一根箭头都是一次 IPC,只是距离不同、协议不同、可靠性不同。一次"模型用工具",在物理上可能涉及 5~10 次 IPC。
+
+---
+
+## 这个抽象的威力
+
+一旦接受"工具 = 进程,调用 = IPC",很多看起来花哨的东西就回到熟悉的地盘:
+
+- **工具调用为什么有超时** → 远程 IPC 必然有超时,本地阻塞 IPC 也得设上限,跟写网络程序一样
+- **为什么要有权限沙箱** → fork 出去的子进程默认继承父进程权限,不限制就是安全漏洞
+- **MCP 为什么要分 stdio 和 SSE 两种传输** → 对应"同主机 IPC"和"跨主机 IPC",底层机制完全不同
+- **agentic loop 怎么处理工具失败** → 跟写网络程序处理 connection refused / timeout 一模一样
+- **为什么所有大模型 API 都要 JSON 序列化** → IPC 必须有 wire format,JSON 是当前最低公共分母
+- **为什么模型不能直接联网** → 推理进程没有网络栈访问权限(沙箱限制),必须通过宿主进程代理,这就是"工具"的存在意义
+
+---
+
+## 与已有知识树的对照
+
+| 我已有的知识点 | 在工具调用中的对应 |
+|---|---|
+| 进程 | 模型推理进程 + 工具执行进程(通常分离) |
+| 内存 | 上下文窗口 = 工作内存;KV cache = 缓存 |
+| shell / 命令行 | agentic loop 就是 LLM 版的 shell;每次工具调用 = 执行一条命令 |
+| 系统库 | tool 定义 = 库函数声明;调用约定 = JSON Schema |
+| 应用架构 | 客户端 = 模型宿主;服务端 = 工具实现 |
+| 网络协议 | MCP over stdio / SSE / HTTP;OpenAI tool calling over HTTPS |
+| 客户端进程 | LLM runtime,负责把模型输出解析成工具调用并执行 |
+| 服务器端进程 | MCP server / 工具后端 |
+| 监听端口 | 远程 MCP server 监听 HTTPS 端口;本地 MCP 用 stdio 不占端口 |
+| 内核 | 类比"宿主调度器"——决定何时调用工具、何时返回模型 |
+
+---
+
+## 后续要展开的子节点
+
+- `01-本机IPC在工具调用中的体现.md`
+  - stdio(MCP local)
+  - fork+exec(bash 类工具)
+  - Unix socket
+- `02-跨主机IPC在工具调用中的体现.md`
+  - HTTPS REST(主流)
+  - HTTP + SSE(MCP remote)
+  - gRPC(企业)
+- `03-编码与协议.md`
+  - JSON Schema(契约)
+  - JSON-RPC(MCP 用)
+- `04-控制流-agentic-loop.md`
+  - 本质 = REPL + 多轮 IPC
+- `05-横切关注点.md`
+  - 超时
+  - 权限 / 沙箱
+  - 失败重试
+  - 上下文管理(KV cache 当作模型的"工作内存")
+
+---
+
+## 一句话总结
+
+> **模型用工具 = 一个进程通过 IPC 调用另一个进程。** 剩下所有概念(MCP、function calling、agentic loop、tool schema)都是这个本质在不同维度上的展开。

学习笔记/00-模型工具调用-原点.md

@@ -0,0 +1,269 @@
+# 模型工具调用 - 00 原点
+
+> 把"模型使用工具"这件事,完全用我已有的知识树(操作系统 / 进程 / IPC / 网络协议)来理解,不引入新的本体概念。
+
+---
+
+## 两个原点
+
+整个"模型工具调用"机制,只需要两个原点就能展开:
+
+### 原点 1:任何工具 = 一个进程
+
+不管这个工具表面叫什么(`web_search`、`Gmail:search_threads`、`bash_tool`、`create_file`),背后都是某台机器上有一个**进程**在执行它。
+
+差别只在三个维度:
+
+- **位置**:进程在哪台主机上(本机 / 远程服务器)
+- **生命周期**:常驻服务进程 / 一次性 fork 出来的子进程
+- **特权级**:用户态业务进程 / 沙箱容器 / 受限子进程
+
+### 原点 2:模型调用工具 = 进程间通讯(IPC)
+
+模型本身也是一个进程——推理进程,通常跑在 GPU 服务器上。它"使用工具",本质就是**和另一个进程通讯**。
+
+整个工具调用机制,就是在解决 IPC 的几个经典问题:
+
+- **寻址**:怎么找到对方
+- **编码**:参数和返回值怎么序列化
+- **同步**:阻塞等结果还是异步回调
+- **容错**:对方挂了 / 超时 / 网络断了怎么办
+
+---
+
+## 澄清:谁在调用工具?
+
+这是一个非常容易被"模型调用工具"这个说法误导的关键认识。
+
+### "模型调用工具"字面上是误导性的
+
+模型本身是一个**纯函数**:输入 token → 输出 token。它不联网、不读文件、不开子进程。所谓"模型调用工具",物理上**模型只是输出了一段 JSON**,内容大致是:
+
+```json
+{"tool": "bash", "input": "ls -la"}
+```
+
+真正动手执行 `ls -la` 的,是**宿主进程 / 客户端**——也就是 Claude Code、Claude.ai 后端、或者用户自己写的 agent 程序。
+
+### 三层分离的真实架构
+
+```
+[模型(纯推理函数)]      ← 远端 GPU 服务器,只做 token 进/出
+        ↑↓ HTTPS(总是跨主机)
+[客户端 / 宿主进程]      ← 本地或云端,负责"代理执行"工具
+        ↑↓ 各种 IPC(本机 stdio / fork / 远程 HTTPS)
+[工具进程]              ← bash、Drive API、文件系统、MCP server……
+```
+
+**关键点**:一次"工具调用"在物理上**至少涉及两段 IPC**:
+
+- **第一段**:模型 ↔ 客户端(总是跨主机 HTTPS,因为模型在远端 GPU 上)
+- **第二段**:客户端 ↔ 工具(可本机可跨主机,看工具部署位置)
+
+### "客户端"这个词的歧义
+
+"客户端"在不同语境下指**不同的东西**,这是混淆的根源:
+
+- **网络架构里的"客户端"** = 相对于某个服务,发起请求的那一方(位置概念)
+- **产品里的"客户端"** = 用户用的那个 App / 界面(产品概念)
+
+这两个常常**不重合**。讨论工具调用时,要用第一种含义。
+
+### 三种产品形态对比
+
+| 形态 | 界面在哪 | 工具执行进程在哪 | 能读本地文件吗 |
+|---|---|---|---|
+| Claude.ai 网页 | 你的浏览器 | Anthropic 服务器 | 不能(除非上传) |
+| Claude Desktop(不接本地 MCP) | 你的电脑(WebView) | Anthropic 服务器 | 不能(除非上传) |
+| Claude Desktop(接本地 MCP) | 你的电脑 | **你的电脑**(MCP server) | **能** |
+| Claude Code | 你的终端 | **你的电脑**(本身就是 agent) | **能** |
+
+**关键洞察**:问的不是"客户端在哪",而是"工具执行进程在哪台机器上"。
+界面在哪反而不重要——浏览器、WebView、终端都只是"输入输出通道",真正决定能力的是**工具进程的位置**。
+
+### "客户端" vs "agent" 的区分
+
+这两个概念经常混用,但不是一回事:
+
+- **客户端(client)** 是**位置概念**——相对于模型推理服务,谁是发起请求的那一方
+- **agent(智能体)** 是**行为概念**——指"在循环里反复调模型 + 执行工具,直到任务完成"的控制器逻辑
+
+通常 agent 逻辑就跑在客户端里,所以两者经常重合,但不必然:
+
+- 一个简单的客户端只调一次模型、不循环——它是客户端,但不是 agent
+- Claude Code 既是客户端,**也**是 agent(它有完整的 loop)
+
+### 用原点重新表述更准确的说法
+
+> **模型推理是一个进程(在远端服务器),它本身不能执行任何工具。所谓"模型调用工具",物理上是:模型推理进程通过 IPC(HTTPS)把"调用意图"以 JSON 形式发给客户端进程;客户端进程作为代理,再通过另一次 IPC(本地 stdio / fork / 远程 HTTPS)去调用真正的工具进程,把结果回传给模型,继续下一轮推理。**
+
+---
+
+## 远程工具:不是都通过 MCP
+
+容易误解的点:**MCP 不是远程工具的必经之路**。
+
+### 远程工具的两条路
+
+**路径 A:客户端直接调用远程 API**
+
+客户端代码里写死了"这个工具叫 web_search,实现就是去调某个搜索 API",直接发 HTTPS 请求,不经过 MCP。
+
+```
+[模型] → [客户端] ─── HTTPS ───→ [远程 API 服务器]
+```
+
+典型例子:
+- Claude.ai 内置的 `web_search`、`image_search`(Anthropic 后端直接调搜索后端)
+- ChatGPT 的 web browsing、DALL·E
+- 自己用 API + function calling 写的程序,工具实现是自己代码里调的某个 API
+
+**路径 B:客户端通过 MCP server 调用**
+
+客户端只懂 MCP 协议,具体工具是哪个 MCP server 实现的,客户端不关心。MCP server 自己再去调真正的后端 API。
+
+```
+[模型] → [客户端] ─ MCP 协议 ─→ [MCP server] ─ HTTPS ─→ [远程 API]
+```
+
+典型例子:Claude.ai 接 Google Drive、Gmail、Notion;Claude Desktop 接 Filesystem MCP、Obsidian MCP。
+
+### MCP 的存在意义
+
+**MCP 解决的是标准化问题**——让"工具的实现方"和"模型的使用方"解耦。任何 MCP server 都能被任何 MCP 兼容的客户端用,不用每家客户端都重新对接一遍 Gmail / Slack / Notion。这跟 USB 标准化、ODBC 标准化是一个思路。
+
+但如果**工具实现方和模型使用方是同一家公司**,根本不需要 MCP。Anthropic 自己实现的 web_search,直接进程内调就完事了,套个 MCP 反而是给自己加一层 IPC 开销。
+
+### IPC 跳数对比
+
+| 路径 | IPC 跳数 | 跳的内容 |
+|---|---|---|
+| 客户端直连 API | 2 跳 | 模型↔客户端,客户端↔API |
+| 经 MCP server | 3 跳 | 模型↔客户端,客户端↔MCP,MCP↔API |
+
+MCP 增加的那一跳,**换来的是接入标准化**——值不值,看你是不是"第三方"。
+
+---
+
+## 通讯距离:两类 IPC
+
+按通讯双方是否在同一个内核内,工具调用的 IPC 分两大类。
+
+### A. 同主机 IPC(同一个内核)
+
+模型宿主和工具执行进程跑在同一台机器,通讯走**内核提供的本地机制**。
+
+| 内核机制 | 在工具调用里的体现 |
+|---|---|
+| 管道 / stdio | MCP 的 stdio 传输:宿主 fork 一个 MCP server 子进程,通过 stdin/stdout 收发 JSON-RPC |
+| Unix domain socket | 部分 MCP server 用本地 socket,比 TCP 快、有文件系统权限控制 |
+| 共享内存 | 推理框架内部传 KV cache 用,工具调用层基本不用 |
+| fork + exec | `bash_tool` 执行命令:宿主 fork 出 bash 子进程,等它退出后读 stdout |
+| 信号 | 超时 / 取消工具调用时,宿主给子进程发 SIGTERM |
+
+**典型场景**:Claude Code 在我自己电脑上跑——所有工具(读文件、跑命令、编辑代码)都是本地进程间通讯,没有走网络。
+
+### B. 跨主机 IPC(不同内核)
+
+模型在一台机器,工具在另一台,走**网络协议栈**。
+
+| 协议层 | 在工具调用里的体现 |
+|---|---|
+| 传输层 | TCP(可靠);几乎不用 UDP |
+| 安全层 | TLS 加密(远程工具几乎强制) |
+| 应用层 | HTTPS REST(主流);HTTP + SSE(MCP 远程模式);WebSocket(实时);gRPC(企业内部) |
+| 编码 | JSON(主流);Protobuf(gRPC);MessagePack(罕见) |
+
+**典型场景**:Claude.ai 调 Google Drive、Gmail、web_search 这类工具——全部是跨主机 HTTPS。
+
+---
+
+## 完整链路示例:`create_file` 的一次调用
+
+以"用 Google Drive 工具创建一个 .md 文件"为例,完整 IPC 链路:
+
+```
+[模型推理进程]                                          GPU 服务器
+       │
+       │ ① 输出 tool_use JSON(进程内,序列化)
+       ▼
+[Anthropic 宿主进程 / 编排器]                           Anthropic 数据中心
+       │
+       │ ② 路由:这个工具属于 Google Drive MCP
+       │ ③ HTTPS 请求(跨主机 IPC,TLS 加密)
+       ▼
+[Google Drive MCP Server 进程]                          Google 数据中心
+       │
+       │ ④ 翻译成 Drive REST API 调用(又一次跨主机 IPC)
+       ▼
+[Drive 后端服务进程集群]                                Google 数据中心
+       │
+       │ ⑤ 写入存储(底层又是无数 IPC,略)
+       │ ⑥ 返回 file metadata,原路 JSON 回传
+       ▼
+[模型上下文窗口]   ← tool_result 塞回这里,模型继续推理
+```
+
+**关键认识**:每一根箭头都是一次 IPC,只是距离不同、协议不同、可靠性不同。一次"模型用工具",在物理上可能涉及 5~10 次 IPC。
+
+---
+
+## 这个抽象的威力
+
+一旦接受"工具 = 进程,调用 = IPC",很多看起来花哨的东西就回到熟悉的地盘:
+
+- **工具调用为什么有超时** → 远程 IPC 必然有超时,本地阻塞 IPC 也得设上限,跟写网络程序一样
+- **为什么要有权限沙箱** → fork 出去的子进程默认继承父进程权限,不限制就是安全漏洞
+- **MCP 为什么要分 stdio 和 SSE 两种传输** → 对应"同主机 IPC"和"跨主机 IPC",底层机制完全不同
+- **agentic loop 怎么处理工具失败** → 跟写网络程序处理 connection refused / timeout 一模一样
+- **为什么所有大模型 API 都要 JSON 序列化** → IPC 必须有 wire format,JSON 是当前最低公共分母
+- **为什么模型不能直接联网** → 推理进程没有网络栈访问权限(沙箱限制),必须通过宿主进程代理,这就是"工具"的存在意义
+
+---
+
+## 与已有知识树的对照
+
+| 我已有的知识点 | 在工具调用中的对应 |
+|---|---|
+| 进程 | 模型推理进程 + 客户端宿主进程 + 工具执行进程(三层分离) |
+| 内存 | 上下文窗口 = 工作内存;KV cache = 缓存 |
+| shell / 命令行 | agentic loop 就是 LLM 版的 shell;每次工具调用 = 执行一条命令 |
+| 系统库 | tool 定义 = 库函数声明;调用约定 = JSON Schema |
+| 应用架构 | 客户端 = 模型宿主(实际执行者);服务端 = 工具实现 |
+| 网络协议 | MCP over stdio / SSE / HTTP;OpenAI tool calling over HTTPS |
+| 客户端进程 | LLM runtime,负责把模型输出解析成工具调用并代理执行 |
+| 服务器端进程 | MCP server / 工具后端 |
+| 监听端口 | 远程 MCP server 监听 HTTPS 端口;本地 MCP 用 stdio 不占端口 |
+| 内核 | 类比"宿主调度器"——决定何时调用工具、何时返回模型 |
+
+---
+
+## 后续要展开的子节点
+
+- `01-本机IPC在工具调用中的体现.md`
+  - stdio(MCP local)
+  - fork+exec(bash 类工具)
+  - Unix socket
+- `02-跨主机IPC在工具调用中的体现.md`
+  - HTTPS REST(主流)
+  - HTTP + SSE(MCP remote)
+  - gRPC(企业)
+- `03-编码与协议.md`
+  - JSON Schema(契约)
+  - JSON-RPC(MCP 用)
+- `04-控制流-agentic-loop.md`
+  - 本质 = REPL + 多轮 IPC
+- `05-横切关注点.md`
+  - 超时
+  - 权限 / 沙箱
+  - 失败重试
+  - 上下文管理(KV cache 当作模型的"工作内存")
+
+平级旁支(更底层的通用基础):
+- `06-互联网作为IPC基础设施.md`
+
+---
+
+## 一句话总结
+
+> **模型用工具 = 一个进程通过 IPC 调用另一个进程。** 但要注意:模型本身不执行工具,执行者是客户端宿主进程;模型只是输出"调用意图"的 JSON。剩下所有概念(MCP、function calling、agentic loop、tool schema)都是这个本质在不同维度上的展开。

学习笔记/06-互联网作为IPC基础设施.md

@@ -0,0 +1,363 @@
+# 06 互联网作为 IPC 基础设施
+
+> 互联网不是一个新东西,它是"进程间通讯"在全球范围的展开。所有网站、App、API、CDN,本质上都是 IPC 的不同包装。
+
+---
+
+## 一、互联网的本质:全球进程 IPC 网络
+
+> **互联网 = 海量进程通过标准协议(主要是 TCP/IP + HTTP)进行跨主机 IPC 的全球网络。**
+>
+> **网站 / App = 把"内容生产、存储、分发、消费"四个环节用进程 + 数据库 + 通讯协议组装起来的系统。**
+
+四个环节对应的进程角色:
+
+```
+[生产者进程]              比如浏览器/App,上传内容
+       ↓ HTTPS(跨主机 IPC)
+[网关 / 接入层进程]       负责接收、鉴权、路由
+       ↓ 内部 RPC(同数据中心 IPC)
+[业务逻辑进程]            处理请求、决定怎么存、怎么发
+       ↓
+[存储层进程]              数据库 / 对象存储 / 缓存
+       ↓
+[分发层进程 / CDN]        把内容推到全球边缘节点
+       ↓ HTTPS
+[消费者进程]              别人的浏览器/App,下载消费
+```
+
+整个互联网就是这种结构在全球范围内复制了几亿份,每个网站、每个 App 都是这个模板的实例化。
+
+---
+
+## 二、关于"内容集中分发"这个直觉
+
+直觉上,互联网像一个"内容集中和分发工具":
+- 抖音用户上传 → 服务器存 → 别人下载看
+- 新浪门户编辑发文 → 服务器存 → 用户访问
+- Google 抓全网 → 建索引 → 用户搜索
+
+这个直觉**抓住了大部分场景**,但需要修正三点。
+
+### 修正 1:互联网不只是"内容分发",还有"实时双向通讯"
+
+"上传 → 下载"是单向异步模型,但互联网还有大量双向实时场景:
+- 即时通讯(微信、WhatsApp)
+- 音视频通话(Zoom、FaceTime)
+- 多人游戏(王者荣耀)
+- 金融交易(股票下单)
+
+更准确的说法:**互联网是"任意两台联网设备之间的通讯基础设施"**,内容分发是它最常见的应用之一,但不是全部。
+
+### 修正 2:不是"集中",是"逻辑集中 + 物理分散"
+
+抖音的视频实际存在**全球几十个数据中心 + CDN 节点**。你刷抖音时,视频从离你最近的 CDN 节点下载,不是从北京总部。
+
+**CDN(Content Delivery Network,内容分发网络)** 是关键概念:把热门内容**预先复制到全球各地的边缘节点**,让用户就近获取。这是为了:
+- 速度(物理距离 = 延迟)
+- 成本(减少跨洲带宽)
+- 可靠性(一个数据中心挂了别的还能用)
+
+更准确的说法:**逻辑上集中(同一个抖音 App 看到统一内容),物理上分散(数据存多份、就近分发)**。
+
+### 修正 3:数据库 ≠ 所有数据存储
+
+数据库是基础设施没错,但只是存储的一种形式。互联网的存储基础设施实际包括:
+
+| 存储类型 | 适合存什么 | 例子 |
+|---|---|---|
+| 关系数据库 | 结构化数据(用户表、订单表) | MySQL、PostgreSQL |
+| NoSQL 数据库 | 半结构化、海量数据 | MongoDB、Redis、Cassandra |
+| 对象存储 | 大文件(视频、图片、备份) | AWS S3、阿里 OSS |
+| 文件系统 | 服务器本地文件 | ext4、NTFS |
+| 分布式文件系统 | 跨机器超大文件 | HDFS、Google GFS |
+| 搜索引擎 | 全文检索 | Elasticsearch |
+| 缓存 | 热数据快速读取 | Redis、Memcached |
+
+**抖音的视频不会存在 MySQL 里**——它存在对象存储(S3 类)。MySQL 存的是"视频元数据"(标题、上传时间、作者ID)。
+
+---
+
+## 三、网站类型:按内容来源分类
+
+| 类型 | 内容生产者 | 例子 |
+|---|---|---|
+| UGC 平台(用户生成) | 用户 | 抖音、小红书、YouTube、Twitter |
+| PGC 平台(专业生产) | 平台或签约方 | Netflix、新浪门户、爱奇艺自制剧 |
+| 聚合 / 索引平台 | 别人,本平台只收集 | Google、百度 |
+| 电商 / 交易平台 | 商家 | 淘宝、亚马逊 |
+| 工具型 / SaaS | 用户(在云上工作) | Google Docs、Figma、Notion |
+
+**Google 的特别之处**:看起来"只是给你结果",但它**自己存的内容比绝大多数网站都多**——索引了几千亿网页的副本。它的商业模式是"组织全世界信息",存储是手段,分发是产品。所以更准确的分类是"**它存的是别人内容的索引和副本,自己不生产内容**"。
+
+---
+
+## 四、Google 搜索的真实工作方式
+
+容易误解的点:**用户搜索时,Google 不是实时去访问全球服务器**——那样会慢到无法使用。
+
+真实流程是**两个完全独立、异步进行的阶段**:
+
+### 阶段 A(后台,持续不断):爬取 + 建索引
+
+- Googlebot 7×24 小时在全网爬网页,把内容存到 Google 自己的数据中心
+- Google 把这些内容做成**索引**——类似一本书后面的"关键词→页码"索引
+- 这个过程跟用户没关系,提前发生
+
+### 阶段 B(用户搜索时,毫秒级):查索引
+
+- 你输入"Python 教程"
+- Google 不去访问任何外部服务器,而是查自己数据中心里建好的索引
+- 找出最匹配的网页,返回给你
+- 全程在 Google 内部系统里完成,所以才能 0.3 秒返回结果
+
+### 完整三阶段图
+
+```
+阶段 A:爬取(Crawl)              ← 后台持续进行
+   Googlebot 顺着链接爬网页 → 原始 HTML 存到 Google 数据中心
+        │
+阶段 B:索引(Index)               ← 后台持续进行
+   提取关键词、计算页面质量(PageRank 等)
+   建成"关键词→网页列表"的倒排索引
+═══════════════════════════════════════════
+阶段 C:搜索(Search / Serve)      ← 用户触发,毫秒级
+   你输入"Python 教程"
+   → 查询路由到最近的 Google 数据中心
+   → 查倒排索引,找出候选网页
+   → 排序算法(几百个信号)
+   → 返回前 10 条
+```
+
+**关键认识**:你看到的搜索结果**全部来自 Google 自己的副本和索引**,不是实时去原网站抓的。这就是为什么有时候点进去发现页面不存在了——网页已经被删了,但 Google 的索引还没更新。
+
+**类比**:Google 像一个超大的图书馆。爬虫是采购员(去全球买书运回来),索引是卡片目录,搜索是图书管理员查目录(不是跑出去找作者)。
+
+---
+
+## 五、API 的本质
+
+调用 API 的目的是**让别人写好的一段代码帮你干活**。但要注意几个精确化:
+
+### "API" 本身不是代码,是**契约**
+
+- **API(Application Programming Interface)** = 接口契约,规定"你想让我干活,得按这个格式发请求,我会按这个格式回结果"。它是一份规范 / 约定,不是可执行代码。
+- **API 实现** = 真正干活的代码
+- **API 服务器 / 服务进程** = 跑这段代码的进程
+
+类比:
+- API ≈ 餐厅菜单(写明"宫保鸡丁 28 元,要等 15 分钟")
+- API 实现 ≈ 后厨的菜谱和厨师手艺
+- 服务进程 ≈ 厨师本人,真的在灶台前炒菜
+
+### API 不一定涉及网络
+
+按部署位置分:
+
+| 类型 | 调用者 vs 实现者 | IPC 类型 | 例子 |
+|---|---|---|---|
+| 库函数 API | 同一个进程内 | 没有 IPC,直接函数调用 | Python 的 `open()` |
+| 系统调用 API | 用户进程 → 内核 | 软中断陷入内核 | Linux 的 `read()` |
+| 本地服务 API | 两个本地进程 | 同主机 IPC(socket) | Docker daemon |
+| 远程 API | 跨网络两个进程 | 跨主机 IPC(HTTPS) | Google Drive API |
+
+### 一次远程 API 调用的物理过程
+
+```
+[客户端进程]
+   │ ① 把请求按 API 契约打包(序列化成 JSON)
+   │ ② 通过 socket 发出 HTTP 请求(跨主机 IPC)
+   ▼
+[网络]
+   │
+   ▼
+[API 服务器进程]
+   ├─ 监听 443 端口(HTTPS)
+   ├─ 收到请求,反序列化
+   ├─ 调用真正干活的代码(可能再调数据库、其他服务)
+   ├─ 把结果序列化成 JSON
+   └─ 通过 socket 发回去
+   │
+   ▼
+[客户端进程] 反序列化,拿到结果
+```
+
+### 与"模型工具调用"的关系
+
+```
+模型工具调用 ⊂ 远程 API 调用 ⊂ 进程间通讯
+```
+
+模型调用工具 = 模型(通过宿主代理)调 API。"工具"在物理上就是某个 API,工具 schema 就是 API 契约的简化版,MCP server 就是把 N 个 API 重新打包成"模型友好"格式的中间层。
+
+### 关键洞察:边界画在哪决定了开销
+
+**所有"调别人写的代码"的行为,本质都是 IPC 的不同形式**——只是边界画在哪里:
+
+- 同一个进程内调函数 → 几乎零开销,但调用方和被调方必须用同一种语言、同一个内存空间
+- 调系统库 → 跨"用户态/内核态"边界
+- 调本地服务 → 跨进程边界,但同一台机器
+- 调远程 API → 跨进程 + 跨机器边界
+
+**边界画得越远,灵活性越高(可以用任何语言、任何机器),但开销越大(序列化、网络、容错都得考虑)**。这是软件架构里所有"分布式 vs 单体"权衡的本质。
+
+---
+
+## 六、HTTP 在应用层协议中的统治地位
+
+### 占比数据(2025-2026)
+
+- 按网站数量:约 97% 的网站默认走 HTTPS
+- 按互联网流量:HTTP + HTTPS 在某些月份占应用层流量 90% 以上
+- 按 Chrome 浏览:用户 93.2% 浏览时间在 HTTPS 页面
+- 按加密占比:非加密的 HTTP 已被压缩到不到 3%
+
+### 应用层协议生态全景
+
+| 类别 | 协议 | 用途 | 流量占比 / 地位 |
+|---|---|---|---|
+| Web 浏览(主流) | HTTP / HTTPS | 网页、API、视频流、下载 | **80~90%**(绝对主导) |
+| 下一代 Web | QUIC(HTTP/3 底层) | Web 流量,逐步替代 TCP+TLS+HTTP | 7~10%(增长中) |
+| 域名解析 | DNS | 把 google.com 翻译成 IP | 2~3%(请求多但流量小) |
+| 邮件 | SMTP / IMAP / POP3 | 收发邮件 | 1~2%(萎缩中) |
+| 文件传输 | FTP / SFTP | 传文件 | <1%(已被 HTTPS 取代) |
+| 远程登录 | SSH / Telnet | 远程操作服务器 | <1%(但极重要) |
+| 即时通讯 | XMPP / MQTT / WebSocket | 聊天、IoT、实时推送 | <1% |
+| 流媒体专用 | RTMP / RTP / WebRTC | 直播、音视频通话 | 少量但上升 |
+| 企业内网 | SMB / NFS | 局域网共享文件 | 公网少 |
+
+### HTTP 为什么能"垄断"
+
+1. **无状态、文本化、易实现**——比早期二进制协议简单太多
+2. **浏览器只支持有限协议**——HTTP 成了"穿透防火墙最稳的协议"(几乎所有公司都开 80/443 端口)
+3. **REST API 风潮**——所有第三方服务的 API 默认就是 HTTP 上的 JSON
+4. **HTTPS 成了安全默认**——浏览器警告 + Let's Encrypt 免费证书推动全网迁移
+5. **HTTP/2、HTTP/3 把性能短板补齐**——以前 HTTP 慢的痛点都被新版本干掉了
+
+结果:**今天几乎所有"应用与应用之间的通讯",默认都是 HTTP 上跑**。
+- API 调用 → HTTP
+- 看视频 → HTTPS
+- WebSocket(聊天)→ 借 HTTP 升级握手
+- 模型工具调用 → HTTPS
+- MCP 远程模式 → HTTP + SSE
+- gRPC → HTTP/2 上跑
+
+---
+
+## 七、HTTP 不是万能的:四类不适合的场景
+
+技术上几乎所有应用都能强行跑在 HTTP 上,但有四类场景 HTTP **不是次优,而是架构上根本不匹配**。
+
+### 1. 极端低延迟 / 高频小包(游戏、金融交易、音视频)
+
+- 王者荣耀 → UDP + 自研协议
+- Zoom / FaceTime → RTP / WebRTC 跑 UDP
+- 高频交易 → 专用 TCP 或 UDP 协议
+
+**为什么 HTTP 不行**:HTTP 跑在 TCP 上,TCP 是"可靠有序"的——丢一个包要重传,后面的包都要等。这对实时场景是灾难。HTTP 头几百字节,游戏一个状态包可能就几十字节,开销 10 倍以上。
+
+### 2. 物联网 / 嵌入式 / 弱网环境
+
+- MQTT(消息队列遥测传输):头 2 字节,适合传感器
+- CoAP(受限应用协议):跑在 UDP 上的"HTTP 简化版",专为 IoT 设计
+
+**为什么 HTTP 不行**:一个智能水表用电池跑 10 年,HTTP 每次开 TCP + TLS 握手就消耗几秒电量,根本撑不住。
+
+### 3. 系统级、超高吞吐场景(数据库、文件系统、内核)
+
+- 数据库通讯:MySQL、PostgreSQL、Redis 都用自己的二进制协议
+- 分布式文件系统:HDFS、Ceph 用专用协议
+- 进程间通讯:Unix socket、共享内存
+
+**为什么 HTTP 不行**:开销太大、序列化太慢。Redis 处理 10 万 QPS,换成 HTTP+JSON 可能掉到 5000。
+
+### 4. P2P / 无中心架构
+
+- BitTorrent:用户互相传文件,没有中心服务器
+- 比特币 / 以太坊:节点对等通讯,自定义二进制协议
+- 局域网设备发现(mDNS、SSDP):广播,不是请求-响应
+
+**为什么 HTTP 不行**:HTTP 天生是"客户端-服务器"结构,P2P 场景里没有"服务器"。
+
+### HTTP 能力边界图
+
+```
+                      ┌─ 极低延迟 / 实时(游戏、音视频、HFT)
+                      │
+       HTTP 不擅长 →  ├─ 物联网 / 弱网 / 低功耗(MQTT、CoAP)
+                      │
+                      ├─ 系统级 / 高吞吐(数据库、内核 IPC)
+                      │
+                      └─ P2P / 无中心(BitTorrent、区块链)
+
+
+                      ┌─ Web 浏览
+                      │
+                      ├─ REST API / RPC
+                      │
+       HTTP 擅长 →    ├─ 文件下载 / 上传
+                      │
+                      ├─ 视频点播(非实时)
+                      │
+                      └─ 模型工具调用 / MCP / SaaS
+```
+
+---
+
+## 八、技术选型的普适规律
+
+```
+        通用 / 标准化
+            ▲
+            │
+            │
+    效率 ◀──┴──▶ 简单 / 易用
+```
+
+- HTTP 选了"通用 + 简单",牺牲了"极致效率"
+- 专用协议(MQTT、游戏协议)选了"效率",牺牲了"通用"
+- 没有银弹,看需求
+
+**用这个框架可以解释很多设计选择**:
+- 为什么 MCP 本地模式用 stdio 不用 HTTP → 同主机 IPC,HTTP 是给跨主机设计的,本地用 HTTP 是浪费
+- 为什么模型推理框架内部用 gRPC 不用 REST → 高吞吐 + 强类型契约,REST 太松散
+- 为什么音视频实时通话不用 HTTP → 实时性要求,HTTP 不行
+- 为什么 IoT 用 MQTT 不用 HTTP → 设备资源紧
+
+---
+
+## 九、内容生产工具:本地 vs 云端
+
+| | 本地工具 | 云端工具 |
+|---|---|---|
+| 编辑进程在哪 | 你的电脑 | 云端服务器 |
+| 数据先存哪 | 你的硬盘 | 云端数据库 / 对象存储 |
+| 离线能用吗 | 能 | 通常不能(或受限) |
+| 多人协作 | 难(要发文件) | 天然支持 |
+| 计算资源 | 你的 CPU | 云端 CPU |
+| 例子 | Word、Premiere、Photoshop | Google Docs、Figma、Canva |
+
+**注意**:这个边界正在模糊。Word 现在也能云协作(实时协同 + OneDrive 存储);Figma 是 Web App 但用了大量本地 GPU 渲染。
+
+更精确的看法是:**"在哪存"和"在哪算"可以分开**。最现代的设计是:**计算尽量在本地(快)、存储和同步在云端(协作)**——Notion、Obsidian Sync、Linear 都是这个架构。
+
+---
+
+## 十、与"工具调用"知识树的关系
+
+这一篇是**工具调用知识树的更底层基础**。整个 `00-原点` 里讲的"跨主机 IPC",在物理上就是这一篇里的"互联网通讯"。
+
+```
+互联网(本篇) ⊃ 远程 API 调用 ⊃ 模型工具调用(00-原点)
+```
+
+理解了这一层,再回头看模型工具调用,会更清楚:
+- "工具调用"的"跨主机 IPC"几乎都走 HTTPS——因为应用层协议已经被 HTTP 统一了
+- MCP 选了 stdio + SSE 两种传输——分别对应"同主机 IPC"和"基于 HTTP 的跨主机 IPC"
+- 模型推理服务监听 443 端口、用 JSON 编码——跟所有现代 Web 服务一个套路
+
+---
+
+## 一句话总结
+
+> **互联网是全球进程通过 HTTP(主要)进行 IPC 的网络。** 所有网站、API、CDN、工具调用,都是这个本质在不同维度上的展开。HTTP 不是因为最优秀才统治,而是因为它在"通用-效率-易用"的三角里选了大多数场景的最佳折中,生态把它推成了事实标准。

学习笔记/学习方法论.md

@@ -0,0 +1,127 @@
+# 学习方法论
+
+> 一套以"地基-框架-填充-固化"为主线的认知建造工程。
+> 核心隐喻：学习 ≈ 盖房子，不是堆砌知识点，而是有结构地生长。
+
+---
+
+## 一、三个根本问题
+
+学习要依次解决三个问题：**学什么 → 怎么学 → 怎么固化**。
+
+### 1. 学什么：靠缘分
+
+- 强行学不感兴趣的东西，认知吸收率极低。
+- 最好的触发器：**工作、学习、生活中遇到的新奇的、迷惑的、有意识想搞懂的东西**。
+- 这种"自带问题情境"的学习动机，远比"应该学什么"的清单更有效。
+
+### 2. 怎么学：长在地基上
+
+- 新知识必须**生长在已有知识的地基上**，地基通常是你比较熟悉的领域。
+- 地基不是一成不变的：**新知识偶尔会反向更新地基**，因为原来的地基可能不够扎实或不够正确。
+- 所以理想状态是：**地基和新知识一起成长**。
+- ⚠️ 警惕：很多人学新东西时死守旧框架，结果新知识变成飘在表面的标签，没有真正接入认知系统。
+
+### 3. 怎么固化：靠输出和反复
+
+- 看懂 ≠ 掌握。必须经过外显化输出 + 提取练习，才能真正固化。
+
+---
+
+## 二、具体执行路径
+
+### 步骤 1：搭建领域框架
+
+- **目的**：先有一个粗糙但能链接到地基的整体地图，而不是直接钻进细节。
+- **方法**：搜索综述、读一本经典书的目录和前言、问 AI 要一份"领域全貌"。
+- **关键**：这个框架必须是**你能用生活经验想象出来的**，能够挂接到已有地基上。如果完全想象不了，说明地基不够，需要先补地基。
+
+### 步骤 2：大胆输出半成品认知
+
+- 在和 AI 讨论之前，先**按自己的理解输出一遍**，哪怕不完整、不准确。
+- 本质：**把隐性认知外显化**。错误的输出比沉默有信息量得多——错在哪里，直接暴露了地基的裂缝在哪里。
+- 不要怕错。怕错就永远停留在"看起来懂了"的幻觉里。
+
+### 步骤 3：与 AI 讨论、纠错、补齐
+
+- 把半成品扔给 AI，让它**纠正错误、补全空白、提出反例**。
+- 在讨论中不断迭代自己的认知。
+- 这一步可能跨多个会话，允许节奏自由。
+
+### 步骤 4：沉淀为 md 文档
+
+- 讨论到一个阶段后，形成 md 文档作为**阶段性成果**。
+- md 不是流水账，而是**重新组织过的、自己的语言写的**认知结晶。
+- 文档命名建议带编号（如 `00-原点.md`、`01-本机IPC.md`），便于建立体系。
+
+### 步骤 5：反复阅读 + AI 出题考试
+
+- 多看几遍沉淀的 md。
+- 让 AI 出题考试，把成果固定住。
+- **题目类型不要只考事实，要考应用和反例**：
+  - 事实题："X 的定义是什么"
+  - 应用题："给你一个场景，判断它属于 X 还是 Y，理由是什么"
+  - 反例题："什么情况下这个框架不成立"
+- 应用题和反例题能检测你的框架在**边界情况**下是否还成立。
+
+### 步骤 6：迭代
+
+- 重复步骤 1-5，直到熟悉掌握当前模块。
+- 然后进入下一个模块，继续在同一地基上生长。
+
+---
+
+## 三、进阶：多框架交叉验证
+
+掌握一个框架后，**换一本别的书重读**这个领域。
+
+- 此时你已经有了一个稳固的体系，看其他书会**很快、很轻松**。
+- 不同视角能**矫正你以前的知识体系**，补上原框架看不见的盲区。
+- 这是从"掌握"到"通透"的分水岭。
+
+### ⚠️ 警惕：框架污染
+
+不同书/作者的术语体系可能冲突，强行融合会让笔记变成大杂烩。
+
+**做法**：在 md 中明确标注术语映射，例如：
+> 这个概念在 A 书叫 X，在 B 书叫 Y，本质是同一个东西，本笔记采用 X。
+
+这样既保留多视角，又维护自己体系的内部一致性。
+
+---
+
+## 四、方法论结构总览
+
+```
+学什么 ── 靠缘分（工作/生活中的真问题）
+   │
+   ▼
+怎么学 ── 长在地基上（新知识 ↔ 地基 双向更新）
+   │
+   ▼
+执行循环：
+   搭框架 → 输出半成品 → AI 纠错补齐 → 沉淀 md → 反复阅读+考试
+                                                     │
+                                                     ▼
+                                              换框架重读（多视角矫正）
+```
+
+---
+
+## 五、为什么这套方法有效（背后的认知原理）
+
+| 步骤 | 对应的认知原理 |
+|------|---------------|
+| 长在地基上 | 建构主义学习：新知识必须挂接到已有图式 |
+| 大胆输出半成品 | 外显化思维，暴露认知缺口 |
+| 沉淀 md | 用自己的语言重组，深加工 |
+| AI 出题考试 | Retrieval Practice（提取练习），效果远好于反复阅读 |
+| 应用题/反例题 | 检测框架的边界与鲁棒性 |
+| 多框架交叉 | 多视角降低单一框架的认知偏差 |
+
+---
+
+## 六、一句话总结
+
+> **学习不是往脑子里灌东西，而是在已有地基上有结构地生长一座房子；
+> 大胆输出、AI 纠错、沉淀文档、反复考试，然后换一本书再来一遍。**

学习笔记/律师推广视频Agent-练手项目规划.md

@@ -0,0 +1,207 @@
+# 律师推广视频 Agent —— 练手项目规划
+
+> 在正式启动"法律事务处理 agent"大项目之前的练手项目。目标:用 agent 提升律师推广视频的生产质量和效率,在抖音等社交媒体发布。
+>
+> **战略定位**:这不是终极产品,而是"通往法律 agent 大目标的前哨战 + 练手项目"。目标不是赚钱,是练功 + 自用。
+
+---
+
+## 一、对赛道的真实判断(必须先看清)
+
+### 抖音律师赛道现状
+
+- **极度内卷**:头部账号已成型,后入场难度大
+- **同质化严重**:大量 AI 生成内容,用户审美疲劳
+- **平台限流**:抖音对纯 AI 批量生成内容有打压
+- **变现链路弯**:视频流量 → 私信咨询 → 收费转化,损耗大
+
+### 这个项目对自己仍然有价值的理由
+
+- **场景自己最懂**——律师身份是天然护城河,知道什么内容算"好"
+- **技术覆盖面广**——一次练完 agent 工程的大半技术栈
+- **闭环短**——生成 → 发布 → 看数据,反馈循环快
+- **可自用**——做出来先解决自己的发布需求
+- **是大目标的前哨战**——跑通这个,正式做法律 agent 时不会从零
+
+### 重新定位
+
+**不是**"做一个律师视频 SaaS"
+**而是**"做一个练手工具,先解决自己发布需求,顺带验证技术路线"
+
+---
+
+## 二、完整流水线拆解
+
+```
+[选题环节]
+  ├─ 抓热点(法律新闻、热搜、平台热门话题)
+  ├─ 匹配自己专长领域
+  └─ 输出:今日 N 个备选选题
+
+[内容生成环节]
+  ├─ 生成口播文案(法律点 + 钩子 + 行动召唤)
+  ├─ 生成视频结构(开场 / 主体 / 结尾)
+  └─ 生成标题、封面文案、话题标签
+
+[视频制作环节]
+  ├─ TTS 配音(数字人或真人配音音频)
+  ├─ 字幕生成(逐字带强调)
+  ├─ B-roll 素材匹配(法庭画面、文件特写等)
+  ├─ 配乐选择
+  └─ 视频剪辑合成
+
+[发布与反馈环节]
+  ├─ 多平台发布(抖音 / 视频号 / 小红书)
+  ├─ 数据回收(播放量、完播率、互动)
+  └─ 反哺选题策略
+```
+
+---
+
+## 三、技术选型(对齐"地基-骨架"梯度)
+
+| 模块 | 选型 | 学到什么 |
+|---|---|---|
+| 选题 agent | Claude API + 简单 RAG(专长资料库) | 工具调用 / RAG / Prompt |
+| 文案生成 | Claude / GPT(prompt 工程) | 结构化输出、风格控制 |
+| 流程编排 | LangGraph | Agent 工作流核心 |
+| TTS 配音 | 火山引擎 / 阿里云 / ElevenLabs | API 集成、IPC 实战 |
+| 数字人 / 视频 | HeyGen / 剪映 API / D-ID | 第三方服务编排 |
+| 视频剪辑 | 剪映专业版 + 模板 / 或 ffmpeg | 自动化的边界感 |
+| 发布自动化 | 平台 API 或半自动(慎用 RPA) | 知道什么不能自动化 |
+| 数据回收 | 平台数据 API | 闭环思维 |
+
+---
+
+## 四、MVP 路线(分版本迭代)
+
+### v0.1(2 周)——纯文案版
+
+- **输入**:一个法律话题
+- **输出**:60 秒口播文案 + 标题 + 标签
+- **技术**:就一个 Claude API 调用,精心调 prompt
+- **价值**:自己用,验证文案质量
+
+**通过标准**:文案质量好到让自己愿意直接发(不用大改)。
+
+### v0.2(再 2 周)——加上选题
+
+- 从法律新闻抓 → 筛选 → 生成文案
+- 技术:加一个新闻抓取工具 + 简单 LangGraph 流程
+
+### v0.3(再 3-4 周)——加上视频生成
+
+- 文案 → TTS → 数字人或简单字幕视频
+- 技术:对接 HeyGen 或类似服务的 API
+
+### v0.4(再 N 周)——发布自动化与数据回收
+
+- ⚠️ **法律灰区**:抖音禁止机器人发布,违规会封号
+- 建议:先用**半自动**(生成视频后人工上传),不追求全自动发布
+
+---
+
+## 五、关键实操原则
+
+### 1. 平台合规——律师身份不能错
+
+抖音对法律内容有专门审核,以下是硬红线:
+
+- ❌ 不能给具体案件法律意见(可能算"非法执业")
+- ❌ 不能承诺胜诉 / 索赔金额
+- ❌ 不能"搬运"判决书原文(隐私 + 版权)
+- ✅ 必须标注"个案具体咨询律师"之类的免责声明
+
+**Agent 必须在 prompt 里硬编码这些合规规则**,生成的文案要自动过滤违规表达。
+
+**这反而是相对纯技术团队的优势**——别人不知道这些坑,自己知道。
+
+### 2. 真人出镜 > AI 数字人
+
+冷数据:抖音上**纯 AI 数字人律师视频的转化率,远低于真人出镜**。
+
+**建议路线**:自己出镜录原始素材,agent 帮做后期增强(文案、字幕、剪辑、发布)。这样:
+
+- 真人感保留
+- 效率提升
+- 平台不限流
+- 转化率更高
+
+也就是说:**agent 不替代出镜,只替代"写文案 + 剪视频 + 发布"的繁琐工作**。
+
+### 3. 别一开始追求"视频生成"
+
+视频 agent 涉及三件事,优先级要分清:
+
+- **A. 文案 + 字幕 + 标题**——最有价值,LLM 最擅长 ✅ MVP 必做
+- **B. 口播音频**——TTS 已成熟,直接用 ✅ v0.3 加入
+- **C. 视频画面**——最难,效果差 ⚠️ 暂不做
+
+**MVP 只做 A + B**,画面用预录的或者素材库拼。
+做 C 是深坑(Sora、Runway 都不稳定),投产比极低。
+
+### 4. 法律专长 = 差异化护城河
+
+市面 AI 视频工具是通用的(给任何行业用)。这个工具如果内嵌**律师视频内容方法论**,就有本质区别。
+
+可在 prompt 里编码的领域知识:
+
+- 律师视频开场的 5 种钩子模板(问题钩 / 案例钩 / 数据钩 / 反常识钩 / 冲突钩)
+- 法律点讲解的"3 步结构"(定义 → 案例 → 行动建议)
+- 不同领域(婚姻 / 劳动 / 刑事)的风格差异
+- 平台合规规则
+
+**这些只有真正做过律师推广的人才能写出来**。
+
+---
+
+## 六、与"法律 agent 大目标"的关系
+
+```
+当下:技术准备(工具调用 / Python / SDK)
+    ↓
+3-4 个月后:做这个律师视频 agent(MVP → v0.3)
+    ↓ (作为练手项目,练完整 agent 工程)
+6 个月后:正式启动法律事务处理 agent
+    ↓ (技术、工程、产品感都已就位)
+```
+
+**视频 agent 价值**:
+
+- 把所有技术栈跑通一遍
+- 体验"agent 工程"的真实难点
+- 拿到能自用、能省时间的工具
+- 顺手验证一下"AI + 法律行业"的市场感觉
+
+如果做着做着真能商业化,那是惊喜;没做成,经验已经赚到了。
+
+---
+
+## 七、推荐启动节奏(配合学习路径)
+
+| 时间 | 学习重点 | 视频项目动作 |
+|---|---|---|
+| 现在-1 个月 | 完成 00-原点子节点(IPC / agentic loop)、Python + Anthropic SDK 入门、写最小 agent loop | 暂不启动 |
+| 第 2 个月 | Prompt engineering | **启动 v0.1**(纯文案版,只用 Claude API) |
+| 第 3 个月 | 学 LangGraph、RAG | **启动 v0.2**(加选题) |
+| 第 4 个月 | 学 TTS / 第三方 API 集成 | **启动 v0.3**(加视频) |
+| 同步进行 | — | 自己录原始视频,积累素材库,观察"什么样的视频在目标受众里有效" |
+
+---
+
+## 八、综合判断
+
+| 维度 | 判断 |
+|---|---|
+| 商业潜力 | 中等偏低(赛道卷),**自用价值高** |
+| 学习价值 | **极高**——一次性练完 agent 工程核心 |
+| 实现难度 | MVP 不难,完整产品中等 |
+| 时间窗口 | 不急,2-3 个月后启动合适 |
+| 战略定位 | **法律 agent 大项目的前哨战 + 练手项目** |
+| 自身优势 | 法律专业 + 自己是用户 + 懂合规 |
+
+---
+
+## 九、一句话总结
+
+> **这个项目值得做,但不是现在,也不当主产品。把它当成通往法律 agent 大目标的练手 + 自用工具。MVP 只做"文案生成"这一步,跑通了再加选题、加 TTS、加视频。真人出镜、合规底线、领域差异化是三条不能让步的原则。**

学习笔记/律师视频每日选题Prompt-复制即用.md

@@ -0,0 +1,149 @@
+# 律师视频每日选题 Prompt(复制即用)
+
+> 每天打开 Claude,粘贴下面这段 prompt,就能拿到当日 10 条可做视频的法律选题。
+
+---
+
+## 🎯 标准 Prompt(直接复制下面整段)
+
+```
+请帮我生成今日的律师推广视频选题清单。
+
+【任务】
+搜索过去 3 天内中文互联网上的法律相关热点(包括但不限于:新闻案件、新法新规、社会争议事件、判例公布、舆情热点),筛选出 10 条最适合做律师推广视频的选题。
+
+【信息源优先级】
+1. 央媒和官方法律媒体(法治日报、最高法、最高检、新华网、人民网)
+2. 主流财经/新闻媒体(界面新闻、财新、网易新闻、澎湃)
+3. 法律垂直媒体(中国普法、法制网舆情)
+4. 微博热搜(法律相关)
+5. 必要时其他来源
+
+【筛选标准】
+- 时效性:近 3 天内发生或受关注
+- 普通人关心:与生活直接相关的优先
+- 有明确法律点:不要纯舆论 / 纯八卦
+- 有"反差感":颠覆常识、出人意料的优先
+- 避开:过度敏感案件(涉政治、涉宗教、涉个案隐私)
+
+【输出格式】
+对每一条选题,按以下结构给出:
+
+### N. [选题标题,8-15 字,带钩子]
+- **事件**:1-2 句话讲清发生了什么
+- **法律点**:这条视频要传达的核心法律知识(1-2 句)
+- **视频角度**:建议的开场钩子 + 核心结构(1-3 句)
+- **适合方向**:适合什么专业方向的律师做(婚姻 / 劳动 / 刑事 / 商事 / 知识产权等)
+- **流量预期**:高 / 中 / 低,加一句理由
+- **合规提示**:如果有踩线风险(具体个案、未决案件、敏感话题),标出来
+
+【最后】
+- 末尾给我一份"今日选题地图":把 10 条按"流量 × 难度"四象限分类
+  - 高流量 + 低难度:优先做(快速产出)
+  - 高流量 + 高难度:重点做(质量取胜)
+  - 低流量 + 低难度:备用
+  - 低流量 + 高难度:跳过
+- 给出当天 Top 3 推荐(明确说"如果只能做 3 条,做这 3 条")
+
+请直接开始,不需要确认。
+```
+
+---
+
+## 📋 使用说明
+
+### 频率
+建议**每天早上**问一次。早上 7-9 点是法律内容的发布黄金窗口。
+
+### 配套动作
+1. 拿到 10 条 → 看 Top 3 推荐
+2. 选 1-2 条当天能拍的(看你时间)
+3. 把选题给 Claude,让它**生成视频脚本**(下一份 Prompt 见 02)
+
+### 何时升级到自动化
+当你出现以下任一情况,就该把这个流程从"手动问 Claude"升级到"Python 脚本自动跑":
+
+- 你已经稳定每天用了 1 个月以上
+- 你已经能写基础 Python(参考"技术准备路线"的地基阶段)
+- 你想加上"自动发邮件 / Telegram 通知"
+- 你想接第三方 X / 微博 API 拿真实数据
+
+升级方案见 `律师推广视频Agent-练手项目规划.md` 中的 v0.2 阶段。
+
+---
+
+## 🔧 个性化变体
+
+把上面 prompt 里的【筛选标准】根据你的专业方向调整:
+
+### 婚姻家事方向
+在【筛选标准】加一行:
+```
+- 优先婚姻、继承、抚养、家庭暴力、彩礼、夫妻财产相关热点
+```
+
+### 劳动法方向
+```
+- 优先劳动合同、加班、辞退、工伤、社保、灵活用工相关热点
+```
+
+### 刑事辩护方向
+```
+- 优先刑事案件、新司法解释、量刑变化、辩护权利相关热点
+- 注意:不评议未决个案,只讲法律规则
+```
+
+### 商事 / 公司法方向
+```
+- 优先合同纠纷、公司治理、股权、知识产权、合规相关热点
+```
+
+---
+
+## 💡 提升效果的小技巧
+
+### 技巧 1:加入"避免"清单
+你试用一段时间后,会发现 Claude 偶尔给的选题不合你胃口。把这些累积起来加到 prompt 里:
+
+```
+【避免】
+- 过于陈旧的话题(已经被同行做烂)
+- 需要复杂图示才能讲清的话题
+- 需要露脸超过 90 秒的话题
+- ......
+```
+
+### 技巧 2:加入你的"风格"
+```
+【我的风格】
+- 开场要有冲击力,30 秒内必须抛出问题
+- 偏好"反常识"角度而非"科普"角度
+- 结尾必须有行动召唤("私信我"/"评论你的看法")
+```
+
+### 技巧 3:让 Claude 学你
+做了一段时间后,把你**爆款视频的标题和大纲**发给 Claude,告诉它"按这个风格来",它会自动模仿。
+
+---
+
+## ⚠️ 真实局限提醒
+
+这个方案**不能**给你:
+
+- ❌ X(Twitter)平台真实热度排序——X 数据搜索引擎拿不到,需要付费 API
+- ❌ 抖音 / 视频号的真实热度——平台不开放数据
+- ❌ 实时(分钟级)更新——搜索引擎索引有延迟
+
+这个方案**能**给你:
+
+- ✅ 当日 / 近几日的法律热点(覆盖率约 80%)
+- ✅ 适合做视频的角度判断
+- ✅ 比手工刷新闻快 10 倍以上的效率
+
+**这个阶段的目标**:用最低成本验证"AI 选题"对你是否有用。验证通过了再投入做自动化。
+
+---
+
+## 一句话总结
+
+> **当下用这个 prompt + Claude 的搜索能力,已经能解决 80% 的"今天该拍什么"的需求。剩下 20%(平台真实热度、实时性),等你的 agent 工程能力到位了再升级。**

学习笔记/让笔记活起来-必要阻力与第二大脑-v2.md

@@ -0,0 +1,51 @@
+# 让笔记活起来:克服"必要阻力",建立你的第二大脑
+
+和朋友聊做笔记这件事,会发现一个很普遍的问题:很多人的笔记到处都是。
+
+它可能在你手机备忘录里,在你的 flomo 里,在你的 Obsidian 里,也可能在你电脑桌面上某个叫"新建文本文档(3)"的文件里。它非常分散,同时并不能被高效地利用。
+
+作为一个一直有做笔记习惯的人,在还没接触那么多复杂工具之前,我用的是一个功能少到可怜的软件——幕布。但恰恰是在这种极简的限制里,我不断在探索自己对于笔记的应用。
+
+## 最小阻力原则
+
+后来我发现,一个人为什么会出现上述种种问题,很大程度上是因为他在做笔记这件事上,很容易滑向"最小阻力原则"的陷阱。
+
+什么意思呢?就是当你想记点东西的时候,你并不会想要专门打开一份软件,然后正儿八经地把它写进去。你只想赶紧把这即时的思考记下来,却不愿意花那一点点多余的功夫,去把这份笔记放到一个它该去的地方。不管是创建之前还是创建之后,这一点点的整理动作,它就是那个"最小阻力"。
+
+但在最小阻力原则的引导之下,我们会本能地滑向阻力最小的那条路——直接打开一个随手可见的地方,把它丢进去。就像我们以前在草稿纸上到处划,划完这张纸就揉成一团扔在一边。但其实你可能只需要做一件事:把草稿纸折成几块,在每一块里记对应的内容。这样即使你以后想回溯,也能打开这张纸,清楚地找到它们。
+
+## 所以,怎么避免这种情况?
+
+我个人的方法,是在最近的不断修改和摸索中找到的。
+
+### 每周整理你的笔记
+
+首先,每周花一点时间去整理你的笔记,非常有必要。这也是一种复盘的仪式。你整理的是这一周自己随心思考的痕迹。你往往在某一段时间想要找回以前的笔记却找不到,原因就是因为你的笔记是零散的,没有经过整理的。但假设你愿意在每周抽出大概 10 分钟,去把你的笔记稍微归类一下,哪怕是把它放到对应的文件夹里,它可能就会在下一次让你清晰地找到它,并且用上它。
+
+### 规划笔记层级 + 标签交叉管理
+
+而在这个过程中,我逐渐建立起自己的一套方法。
+
+我给自己的笔记大概分了最多三级的文件夹。过多的文件夹只会导致过期的分类,而过期的分类会让这个系统变得太复杂,以至于你下次根本不愿意再进行搜索和整理。这是一部分。同时,我又给自己的笔记加上一个标签库。我能通过这些标签,灵活地找到对应的内容。相较于每周的集中复盘,在日常记录时顺手打个标签,可能是更加轻松、更容易坚持的方式。
+
+### 克服必要阻力
+
+我觉得这里有一个非常重要的点,就是我们在这过程之中,引入了一种我愿意称之为"必要阻力"的东西。
+
+我打开一份软件,有意识地把所有零散的记录归拢到某一个地方去——这个动作,其实就是我们需要去克服的那一点点"必要阻力"。当我们清晰地看见这份阻力,并愿意主动去承接它的时候,你会发现,在不断试验之后,也许只要 10 次,这份阻力就被我们克服掉了。它开始内化成你行为习惯里一个可以轻易跨越的小门槛。到那个时候,它甚至都不再是阻力,而是一个顺手的、下意识的动作。
+
+## 你可以获得的收益
+
+这个过程,也是在锻炼你的决策力。
+
+很多人对于 AI 的讨论,可能只限于把 AI 作为一个搜索引擎去使用。但一个人想要持续地与 AI "抗衡",想要获得那种可以不断"左右互搏"、层叠向上的能力,靠的其实就是决策力。你每一次给笔记归类、打标签,本质上都是在最小单元里做一次决策。这个动作没那么费劲,但它在无声地训练你的判断力。你做一次,就等于在你的决策沙盘里操练了一次。这是任何 AI 都没办法替你完成的"内化"过程。
+
+你当然可以用 agent 或者 AI 来帮你归类,但不可避免的是,你亲手去归类这件事,它有它无可替代的价值。它能让你在越来越依赖 AI 的时代,保持一种不让自己"表达肌肉"萎缩的训练。
+
+现在你会发现,记忆力这件事,在过度使用 AI 的过程中,已经在退化了。有些东西是需要人脑去记忆、去储备,然后再进行输出的。当你的大脑没有足够的知识储备量和话语储备量时,你是难以说出一段完整的文章或者即兴的演讲的。AI 可以给你语句,但它给不了你来自你个人知识储备库里的、有血有肉的即兴见解。
+
+## 所以,回到笔记这件事上
+
+不要让你的笔记仍然散落在各个角落,不要在下一次想找的时候翻遍所有软件都找不到。试着在每周的某个 10 分钟里,去整理一下你自己。去给你散乱的思考一个家,去承担那一点点"必要阻力"。
+
+希望你的笔记可以活起来,为你所用。