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 是目前唯一解。

保持简单的本质是把大脑当 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. 结论：分得开重要和紧急，才知道当下到底该做什么

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 讲方法。
• 沟通错位的根源：人和人聊不到一起，多半是因为各自停在不同的层。
• 关键动作：先识别对方在哪层，再决定怎么回应。
• 不只工作场景：亲子、朋友、销售、客户全都用得上。

codebase-memory-mcp 是一款纯 C 编写的代码知识图谱 MCP 服务器，给 Claude Code / Codex / Open Code 装上"项目结构感知"能力。

1. 核心定位：用 MCP 把代码库索引成可交互的知识图谱，AI 改代码前能感知调用链、依赖与爆炸半径。
2. 架构特点：零依赖单文件二进制，不依赖 Node / Python 环境，下载即可跑。
3. 能力边界：支持 158 种语言、内置 20+ 语义关系、支持 OpenCypher 图查询。
4. 对比 CodeGraph：提取精度 / 调用图完整性 / 查询能力 三项领先，索引速度落后，平均分几乎持平。
5. 典型场景：快速上手陌生项目、PR 影响半径分析、死函数检测、跨语言特性迁移。
6. 代价：单次索引 20+ 分钟，MCP 集成会占用系统资源，且与 GitNexus 跨仓能力有差距。

刻意练习的本质是高效而可怕的勤奋，核心是反馈，不是努力。

• Ericsson 的定义：通过不断重复训练稍微困难的任务，获得最高效的进步。
• 关键案例：AlphaGo Zero 不学任何棋谱，仅靠"输还是赢"的反馈就以 89:11 碾压 AlphaGo Master。
• 两大要素：稍微困难的任务 + 即时反馈机制，缺一不可。
• 致命误区：重复≠刻意练习，没有反馈的重复只是在强化错误。
• 勤奋的反义：不是"懒"，是"低效"——无反馈的勤奋比躺平更危险，因为它制造进步的错觉。
• 本质动作：找到任务中的"输还是赢"反馈机制，否则练习就是黑盒。
• 一句话：刻意练习不是学会什么，是在能力边缘持续犯错并修正。

Tailwind 是构建时按需生成 CSS 的工具，不是预制类库。 这是它和 Bootstrap、iconfont 这类传统 class 库最本质的区别。

• 本质区别：Bootstrap 是运行时可用的预制 CSS，Tailwind 是构建时扫源码生成
• 类何时存在：Bootstrap 加载即用，Tailwind 必须被构建器扫到源码才生成
• 体积策略：Bootstrap 固定（库大小决定），Tailwind 动态（你用多少决定）
• 跨包坑点：monorepo 子包构建器只扫自己源码，看不到别的包用到的 class
• 配置关键：tailwind.config.js 的 content 必须覆盖到所有源码路径

git worktree 让多分支并行工作，一个目录 = 一个分支。

• 核心机制：所有 worktree 共享一个 .git 数据库
• 典型场景：边修 bug 边开发 feature，不切分支
• code review：独立目录看 PR，不打断当前工作
• 跑长任务：CI、build 不阻塞主工作区
• superpowers 模式：一个 worktree 一个 agent，并行的关键
• 使用注意：同一分支只能被一个 worktree checkout
• 清理规则：删目录不够，必须 git worktree remove