企业官网建设流程全解析

三树系统不是替代 CLAUDE.md，而是把 CLAUDE.md 从“一份全局说明书”，升级为适合大型、多模块、长期维护项目的上下文治理体系。

Claude、ChatGPT、Codex、Cline 这类 AI 已经能写代码、读仓库、跑测试，甚至可以协助开发完整功能。

但真正把它们用于长期项目后，很多人会遇到类似问题：

• 让 AI 改一个页面，它先扫完整个仓库；

• 让 AI 修一个接口，它把历史代码当成生产代码；

• 一个任务做完后，经验停留在聊天记录，下一次又从头解释；

• AI 不断重试失败命令，消耗大量时间和 token；

• AI “顺手优化”了用户根本没有要求修改的模块。

模型不够聪明吗？

很多时候不是。

问题在于：AI 缺少项目地图、模块边界和可复用的任务记忆。

我现在用一套很轻量的方法解决这个问题：三树知识系统。

它可以配合 Claude Code、ChatGPT、Codex、Cline、Cursor 等工具使用，不依赖某一个模型。

一、三树系统解决什么问题？

三树系统把项目知识分成三层：

TRUNK（树干） ↓ BRANCH（树枝） ↓ LEAF（叶子）

一句话理解：

TRUNK 告诉 AI 去哪里，BRANCH 告诉 AI 怎么做，LEAF 告诉 AI 以前发生过什么。

二、Claude 和 ChatGPT 最常见的四种问题

1. Claude 很擅长探索，但容易扩大上下文

Claude 在大型代码库中很愿意文件。

这在初次理解项目时很有帮助，但也容易出现：

用户：改首页一个按钮 Claude： - 读取前端页面 - 读取全部组件 - 读取 API - 读取数据库定义 - 读取部署脚本 - 读取历史工单 - 最后才改按钮

三树系统里的 BRANCH 会提前告诉它：

任务：首页 UI 修改 先读： - 首页渲染文件 - 直接组件 通常不要读： - API - 数据库 - 部署脚本 - node_modules - 历史目录 停止条件： - 找到按钮所在模板或组件后立即停止。

这样 Claude 仍然保留分析能力，但不会无限扩大阅读范围。

2. ChatGPT 很会解释，但需要明确“真实代码在哪里”

ChatGPT 在对话、产品设计、方案拆解方面很强。

但真实项目经常存在：

• 新旧仓库同时存在；

• 本地代码和生产代码不一致；

• 历史原型没有删除；

• 研究 API 和生产 API 并存；

• 一个目录里混有数据、脚本、文档和运行文件。

如果没有知识地图，AI 很容易判断错“哪份才是真源”。

TRUNK 中可以明确写：

生产 API： poly-collector/serve_api.py 研究 API： topholders-api/ topholders-bff/ 历史目录： frontend-v2/ compare-prototype/ 禁止读取： out/ *.db *.jsonl node_modules/

这样 ChatGPT 在设计方案或给 VS/Cline 写任务时，不会误把研究服务当成线上生产服务。

3. AI 做完任务后，经验不会自动留下

聊天记录是临时上下文，不是项目知识库。

例如今天 AI 修了一个支付问题，知道：

• 为什么不能直接信任客户端金额；

• 为什么要先服务端验单；

• 哪个文件是支付入口；

• 用什么测试验证；

• 是否已经部署。

下周换一个对话、换一个模型、换一个开发者，这些信息可能全部丢失。

LEAF 就是把一次任务留下来：

Task： 修复支付验单失败。 Why： 部分 Android 购买未 acknowledge，存在自动退款风险。 Files Changed： billing_verify.py billing_ack.py Tests： 验单解析测试、ack 重试测试。 Deployment： NOT DEPLOYED。 New Knowledge： Google Play 未 acknowledge 的购买可能在三天后自动退款。

下一次 Claude 或 ChatGPT 收到类似问题时，可以先读这片 LEAF，而不是重新踩坑。

4. AI 不知道什么时候该停止

这可能是最现实的问题。

AI 常见行为：

• 工具调用失败后重复尝试；

• 为了确认一个小细节继续扫描无关模块；

• 做完需求后顺手重构；

• 遇到不确定信息时猜测；

• 修改生产、删除文件或 Git 清理时风险过高。

所以三树系统应配合一套执行边界：

- 同一种命令连续失败 3 次后停止； - 最多切换 2 种替代方法； - 无法确认时写 UNKNOWN，不猜； - 获得足够证据后停止扩大上下文； - 删除、覆盖、Git 清理、生产操作失败一次即停止； - 主任务完成后不顺手扩大范围。

这会让 AI 更像一个有止损纪律的工程协作者。

三、一个真实使用场景：让 AI 给 VS 写工单

现在很多团队的实际工作流是：

产品负责人 / 开发者 ↓ ChatGPT 或 Claude：理解需求、设计方案、拆解任务 ↓ VS Code + Cline / Claude Code：修改代码、运行测试 ↓ ChatGPT 或 Claude：验收结果、继续下工单

三树系统最适合这种流程。

例如需求是：

首页增加“更多”按钮，跳转到一个独立页面，展示更多实时交易数据，并符合 SEO 标准。

AI 不应该直接让 VS “自己看看怎么改”。

正确的工单应该包含：

目标： 新增 /live/large-trades/ 页面。 入口： 首页 LIVE LARGE TRADES 区块。 数据： 复用现有静态大额交易 feed。 SEO： - 唯一 H1 - title - meta description - canonical - Open Graph - JSON-LD - sitemap 边界： - 不改生产环境 - 不改 DNS、nginx、Cloudflare - 不修改其他站点 - 数据为空时不能编造交易 验收： - 初始 HTML 中必须有页面主体和交易列表 - canonical 正确 - sitemap 可收录 - 无 noindex - JSON-LD 可解析

这就是“AI 作为大脑、IDE Agent 作为执行者”的分工。

四、BRANCH 最有价值的内容：Reading Paths

很多人写文档时喜欢写一大段架构介绍，但对 AI 最有用的通常是 Reading Paths。

例如：

### SEO 页面任务 先读： - BRANCH.md - 页面渲染器 - sitemap 生成器 再读： - 对应页面的 head、canonical、JSON-LD 通常不要读： - 数据库 - 全站发布脚本 - 其他产品目录 停止条件： - 找到 title、description、canonical、正文渲染位置后停止。

Claude、ChatGPT、Cline 都可以遵守这种路径。

它的价值在于把“经验丰富的工程师知道该看哪里”变成机器可执行的规则。

五、适合 Claude、ChatGPT 的目录结构

一个最小可用结构可以是：

project/ ├── PROJECT.md ├── ARCHITECTURE.md ├── KNOWLEDGE_MAP.md ├── WORKFLOW.md ├── KNOWLEDGE_TREE_STANDARD.md │ ├── frontend/ │ ├── BRANCH.md │ └── leaves/ │ ├── backend/ │ ├── BRANCH.md │ └── leaves/ │ └── data-pipeline/ ├── BRANCH.md └── leaves/

建议：

• 新任务先读KNOWLEDGE_MAP.md；

• 进入模块后先读BRANCH.md；

• 修改完成后写一片 LEAF；

• 只有稳定、重复使用的知识才升级到 BRANCH；

• 只有跨模块的长期规则才升级到 TRUNK。

六、不要把三树系统做成“文档负担”

三树系统不是要求把所有代码都解释一遍。

它只记录未来仍然有价值的信息。

判断方式很简单：

只对这一次任务有用？ → 写 LEAF。 以后修改这个模块还会用到？ → 写 BRANCH。 多个模块都会用到？ → 写 TRUNK。

如果一条信息不满足以上任何一种，就不用写。

文档越少越好，但关键路由必须准确。

七、结语：AI 编程的瓶颈不是生成代码，而是上下文治理

Claude、ChatGPT 已经可以帮我们写很多代码。

但在真实项目中，真正决定质量的往往不是“能不能生成一段代码”，而是：

• 它是否知道真实源码在哪里；

• 它是否知道生产和研究代码的区别；

• 它是否只读取必要上下文；

• 它是否知道哪些操作不能碰；

• 它是否能把经验留下给下一次任务。

三树系统提供的不是更复杂的流程，而是一条简单纪律：

先路由，再阅读；先证据，再修改；完成即停止。

如果你正在用 Claude Code、ChatGPT、Codex、Cline 或 Cursor 做项目开发，可以从一个模块开始试试：

1. 建一个BRANCH.md；

2. 写三条 Reading Paths；

3. 每完成一个真实任务，写一片 LEAF；

4. 把全局架构和执行边界放进 TRUNK。

欢迎大家讨论：你在用 Claude 或 ChatGPT 开发时，最常遇到的上下文混乱问题是什么？