第 02 章：包不是项目

阅读日期：2026-09-14。书中版本基线：核心分析 v0.66.0，作者自述对照 v0.82.1；本笔记未独立验证源码或发行版本。

设计问题、机制与取舍

包边界服务独立使用者，未形成独立消费需求的功能留在产品内。书中 v0.82.1 快照有七个业务包，六个发布，evals 私有；ai、tui 为底层，agent 依赖 ai，coding-agent 汇合三者，SQLite 为可选存储，server 是实验性宿主。mom、pods、web-ui 已迁出。

构建按依赖拓扑推进，统一版本减少组合负担，但单点修改也要整组升版，部分发布失败仍需处理。导出入口和 provider 子路径限制暴露面。包数量随消费、发布节奏变化，数量本身不是架构目标。

来源：本章原文。这是压缩后的原创读书笔记，完整论证、示例及版本说明请回到原章。

工程应用检查（整理者推导）

在自己的仓库里准备一张“谁会单独使用它”的表：知识文件仓储可能同时被网页和本地 MCP 使用，因此有实际共享价值；某个仅服务一个页面的按钮不必单独发包。判断依据应是现实调用方和变化节奏，而不是文件行数。

新增包前做三个具体检查：它是否能脱离现有 UI 验证；它是否需要独立运行环境；它是否真的有独立发布需求。如果三个答案都是否，先留作同仓库模块通常更容易维护。若引入可选数据库后端，应验证未启用时主应用不会被迫安装或初始化该后端。

统一版本也不能代替发布验证。记录本次发布每个包的结果，并准备版本已被消耗时的恢复办法。依赖无环要靠实际配置和构建检查确认，不能仅凭架构图或目录名字断言。这些检查是整理者对个人项目的应用推导。