Pi 把上下文压缩做成一等公民：自动触发、结构化摘要、可扩展、可手动控制。两种机制——压缩和分支摘要——共用同一套文件跟踪与摘要格式。

1. 触发条件：上下文超阈值或 /compact 触发压缩；/tree 切分支触发分支摘要
2. 核心字段：reserveTokens（默认 16384）、keepRecentTokens（默认 20000）
3. 七段式摘要 schema：Goal / Constraints / Progress / Key Decisions / Next Steps / Critical Context
4. 关键设计：重复 compaction 从上一 compaction 的保留边界开始，磁盘上只有「三块」而非 N 段
5. 累积文件跟踪：read/modified 文件清单跨多次 compaction 累积
6. 可扩展：session_before_compact 钩子允许扩展完全替换摘要生成

DESIGN.md 是 Google Stitch 提出的设计系统规范，把 token 化的视觉语言写进项目根目录。

1. 痛点：AI 写组件超过 5 个，颜色 / 间距 / 圆角就开始漂移
2. 解法：把9 大模块（视觉主题 / 色彩 / 字体 / 组件 / 布局 / 深度 / Do's / 响应式 / Agent 指南）写进 DESIGN.md
3. 格式：YAML Front Matter + Markdown 正文，机器可读 + 人类可读
4. 生态：awesome-design-md 70+ 品牌（9.6 万 Star）+ getdesign.md 索引站 + Chrome 扩展 逆向竞品 + webdesignhot 403 个 CLI 模板
5. 本质：和 AGENTS.md 平行的"视觉约束文件"
6. 局限：直接套别人的设计只适合原型 / 内部工具，自有品牌仍得手写

book-to-skill 把一本书拆成 Claude Code 可按章节调用的 Skill，解决"买了书两个月就忘"的痛点。

1. 痛点：书看完两个月只剩一句"好像讲过"，问 AI 拿到的是东拼西凑的通用建议
2. 解法：一句 /book-to-skill ~/path/to/your-book.pdf 把 PDF/EPUB 转成 ~/.claude/skills/<slug>/
3. 机制：按章节按需加载，不一次性塞全本——更快、更便宜、不幻觉
4. 效果：同一问题，普通 AI 给通用建议；用 Skill 后直接基于原书框架分析
5. 适用：工具书/方法论书/技术书，不适合小说散文
6. 边界：目前一次拆一本，跨书检索、增量更新还没设计

Draw.io MCP 三种方案横评，方式 3 是唯一支持协作画图的解。

1. 方式 1（官方 drawio-mcp）：走 jgraph/drawio-mcp 远程生成，每次都是新文件，原图没法覆盖。
2. 方式 2（官方 Plugin + Desktop）：能本地覆盖原文件，但 不支持实时编辑，要手动 reload。
3. 方式 3（推荐，next-ai-draw-io）：本地起 localhost，真正支持实时编辑，Agent 改一步你能立刻看到。
4. 结论：想让 Agent 协作式画图，方式 3 是目前唯一解。

Pi 把「一次会话」抽象成一颗 JSONL 树。每条 entry 是一个节点，节点之间靠 id 和 parentId 串成父子关系；当前活跃的位置是「叶子」。

1. 存储：JSONL 树形文件，按工作目录分组存到 ~/.pi/agent/sessions/
2. 数据格式：每行一条 entry，类型由 type 字段区分，节点靠 id/parentId 串成树
3. 消息模型分两层：pi-ai 给基础 LLM 类型，pi-coding-agent 扩展出 BashExecution / Custom 等专用消息
4. BashExecution 是 Pi 特有：把 !、!! 命令结构化地放进会话，跟普通 tool result 分开
5. custom vs custom_message：前者只存盘不进入 LLM context，后者进入 context
6. 树形的设计：撑起分支探索、无损压缩、多事件流并行

Pi 把 Session 设计成树而不是线，不是「数据结构的偏好」，而是支撑所有核心能力的基础。

保持简单的本质是把大脑当 CPU 用，不是当硬盘用——多数人天天往脑子里塞新待办、新会议、新群聊，然后问为什么专注不下来。

1. 横向关联：和《重要 ≠ 紧急》同主题——那篇讲怎么判断，本文讲怎么下刀
2. 核心类比：大脑是 CPU 不是硬盘，并发任务有上限
3. 决策疲劳：每件小事都在偷意志力，省决策 = 省大脑预算
4. GTD 真意：inbox zero 是为了卸载大脑，不是为了整齐
5. 核心难点：承认 90% 的事不重要比砍掉它们更难
6. 三把刀：关通知、拒会议、删项目，每把都见血
7. 二阶懒惰：用"做不重要的事"代替"做重要的事"最隐蔽
8. 结论：清空不是为干净，是给重要的事留位置

多数团队里 flag 和 priority 是同一套标签，这是错的——flag 是"重要"，priority 是"紧急"，两个独立维度混着用，最后没人再信这些标签。

1. 概念正交：flag 标注价值，priority 标注时间压力，本质两个独立维度
2. 艾森豪威尔矩阵：4 象限，重要 × 紧急的二维划分，对应 4 种处理方式
3. Covey 第二象限：重要但不紧急才是真正该花时间的区域
4. 常见误判：把领导催当成紧急，把上线崩溃当成不重要
5. GTD 执行维度：情境、时间、精力、优先级四维决策当下动作，不是只看 priority
6. 工程实践：GitHub 一个 priority label 不够，重要 vs 紧急必须分开建
7. 反模式：所有 bug 都标 P0、所有任务都标 important，标签沦为装饰
8. 结论：分得开重要和紧急，才知道当下到底该做什么

Pi 用一句话定义自己：核心要小，行为由扩展装配。本篇先看它最上层的哲学，再落到 4 个 npm 包的源码目录里。

1. 核心极简：默认不内置 MCP、sub-agent、plan mode、to-do、权限弹窗
2. Harness ≠ 模型：LLM 是发动机、Harness 是车辆系统——这一层直接决定成本与效果
3. 两条路径：产品派（Claude Code / Codex）成品房 vs 框架派（Pi）毛坯房
4. 双层扩展：Skill 改方法，Extension 改 Agent 自身运行方式
5. 4 个 npm 包：pi-ai / pi-agent-core / pi-coding-agent / pi-tui，单向依赖
6. 透明可读 → 自改造：Pi 自己读自己的扩展文档、自己写代码修改 Extension
7. 同模型实测：同模型同任务，Pi / CC token 比 51%、耗时 ~80%
8. 核心只做四件事：加载扩展、跑 agent 循环、读写 session 文件、提供 TUI

记忆点：Pi 卖的不是「帮你做好了一切」，而是「给你一块可改装的底盘」——也是一个「让你能看到 Agent 怎么跑的透明壳」。

Bun 是什么：把整套 JS 工具链（运行时、包管理、打包、测试）塞进一个二进制文件的 Zig 全栈运行时。

1. 本质：不只是更快的 Node.js，是整套 JS 工具链的统一入口。
2. 性能：启动比 Node 快 3-4 倍，装包比 npm 快 20 倍以上。
3. 兼容：直接 bun install / bun run 即可运行，现有 Node 项目零修改。
4. 内建：TypeScript / JSX / TSX 原生支持，无需 Babel 转译或额外配置。
5. 场景：本地开发、CI 流水线、Serverless 等对冷启动速度敏感的场景。
6. 建议：1.0 之前生产环境慎用，先用作开发工具链加速。

What、Why、How 不是三个并列问题，是三个递进的层次。

• 不是表达技巧：这是一个观察框架，看人说话落在哪一层。
• 三层定义：What 讲事实，Why 讲动机，How 讲方法。
• 沟通错位的根源：人和人聊不到一起，多半是因为各自停在不同的层。
• 关键动作：先识别对方在哪层，再决定怎么回应。
• 不只工作场景：亲子、朋友、销售、客户全都用得上。