38 lines
2.6 KiB
Markdown
38 lines
2.6 KiB
Markdown
# 记忆整理 SOP
|
||
|
||
## 核心原则：存在性编码
|
||
LLM自身是压缩器+解码器。L1只需让它**意识到某类知识存在**，它就能通过tool call自行取用深层内容。
|
||
|
||
**L1本质：用最短词数表达——什么场景下有什么记忆可用（存在性）。**
|
||
|
||
L1两类内容，统一ROI评估：
|
||
- **存在性指针**：指向L2/L3知识的最短触发词
|
||
- **行为规则**：不提醒就会犯的错（致命/高频均可，只要ROI过门槛）
|
||
|
||
ROI = (不放这几个词的犯错概率 × 代价) / 每轮词数成本
|
||
|
||
## 快速判断
|
||
**该留**：反直觉触发词——没提示就想不到去查SOP的场景词。如`tmwebdriver_sop(httponly cookie)`：没有`httponly cookie`这个词，你不会想到取cookie要查tmwebdriver
|
||
**该删**：
|
||
- 名字翻译：`proxy-pool/(代理池)` → 名字自解释，括号是废词，直接`proxy-pool`即可
|
||
- 内容描述：`opencli_sop(66站点CLI,复用Chrome session)` → 实现细节属于SOP内部，不是触发场景
|
||
- 直觉能力：不提醒也能想到 → 0收益，白交每轮成本
|
||
- 冗余：L3已覆盖的规则 / L1其他行已含的片段
|
||
|
||
## 压缩四原则
|
||
1. **命名自解释 > 加描述**：SOP名能说清的，L1不加注释；改名的ROI常高于改L1
|
||
2. **存在性集合最小描述**：多个相近条目若可被同一上位场景覆盖，用集合名表达这类能力的存在，不必平铺子项。如`qq操作/飞书操作/企微操作`→`im操作:*_im_sop`；子项名自解释则只列名不翻译
|
||
3. **条目 = 场景↔方案存在性**：如`视频理解:yt-dlp取字幕`、`fofa(资产测绘)`——场景名是触发词，方案名编码存在性；括号内**只放反直觉触发词**，非反直觉的（纯翻译/内容描述/实现细节）全是浪费
|
||
4. **分层归位**：带行为规则或高频高ROI的条目放上方场景行，纯存在性指针归L2/L3平铺列表
|
||
|
||
## 整理流程
|
||
1. 逐行读L1，按`|`拆片段，先分类：存在性指针 / RULES / 翻译 / 内容描述 / 实现细节 / 冗余
|
||
2. 先清RULES：逐条问“这是全局高ROI，还是特定场景低危险规则？”
|
||
- 全局高ROI → 留
|
||
- 特定场景 / 低危险 → 降级到L3或删除
|
||
3. 再清存在性指针：检查是否在表达**场景↔方案存在性**；场景触发词只在**反直觉**时才加，翻译/内容描述/实现细节删掉
|
||
4. 检查L3文件名是否自解释；能靠改名解决的，不靠L1加描述；最后验证总行数 ≤ 30
|
||
|
||
**红线**：记忆修改是持久性伤害，错误每轮复利。L1只能patch词级别修改，禁overwrite
|
||
产生误导应及时修正L1或记忆更名
|