Monorepo 不需要从 pnpm / Turborepo 开始——npm 7+ 自带的 workspaces 字段就能跑，是真正零成本的入门。

1. 是什么：多项目放一个仓库，不强制任何工具
2. 第 1 档：npm workspaces（npm 7+ 内置），根 package.json 加字段
3. 第 2 档：yarn workspaces（早期方案，yarn 1 时代）
4. 第 3 档：pnpm workspace（当前事实标准，磁盘节省 50%+）
5. 第 4 档：Turborepo / Nx，只有跨包 build 依赖才需要
6. 口诀：包数 <5 npm workspaces，<10 pnpm，10+ 才上 Turborepo

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 用一句话定义自己：核心要小，行为由扩展装配。

1. 核心极简：默认不内置 MCP、sub-agent、plan mode、to-do、权限弹窗
2. 4 个 npm 包：pi-ai / pi-agent-core / pi-coding-agent / pi-tui，单向依赖
3. 最底层是 pi-ai：纯 LLM 适配，零 agent 概念
4. 分层好处：每一层独立 npm 包，按需引入
5. 核心只做四件事：加载扩展、跑 agent 循环、读写 session 文件、提供 TUI

记忆点：Pi 卖的不是「帮你做好了一切」，而是「给你一块可改装的底盘」。

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 之前生产环境慎用，先用作开发工具链加速。