让 CC 梳理项目架构

真实项目教程：让 Claude Code 梳理项目架构，输出入口、模块、调用链、数据流、依赖边界和架构图文本说明。

项目架构梳理不是让 CC 画一张漂亮图。

真正有用的架构梳理，要回答：请求从哪里进来，数据怎么流动，模块之间怎么依赖，哪些边界不能乱破坏。

什么时候需要架构梳理

适合这些场景：

• 刚接手一个老项目。
• 要做跨模块需求。
• 准备重构前。
• 准备接入新功能前。
• 团队新人需要快速理解项目。
• 项目文档长期缺失。

如果只是改一个按钮文案，不需要做架构梳理。

架构梳理提示词

请只读梳理当前项目架构，不要修改文件。

请输出：
1. 项目整体类型和技术栈。
2. 启动入口和主要运行流程。
3. 核心模块列表。
4. 模块之间的依赖关系。
5. 主要数据流或请求链路。
6. 配置、环境变量和外部服务边界。
7. 测试、构建、部署相关入口。
8. 当前架构中最需要人工确认的部分。

要求：
- 不要编造没有代码依据的结论。
- 不要深入无关细节。
- 用适合团队文档的方式输出。

如果项目很大，可以限定范围：

这次只梳理【订单模块 / 用户模块 / 前端路由 / 后端接口层】的架构。

架构梳理要分层

不要让 CC 把所有文件平铺成清单。更有用的是分层：

这样梳理出来的架构，后面才能指导修改。

让 CC 输出架构文本图

很多时候文本图比复杂图片更实用。

请把刚才的架构梳理转换成文本架构图。

格式示例：
用户请求
-> 路由入口
-> 页面/控制器
-> 服务层
-> 数据访问层
-> 数据库或外部服务

要求：
1. 每一层标出关键文件。
2. 标出跨模块依赖。
3. 标出高风险边界。

这样生成的内容可以直接放进 README 或团队文档。

如果文本图太复杂，让 CC 先输出“主路径”，不要一次画所有分支：

请只画最核心的一条业务主路径，暂时不要展开所有异常分支。
每个节点只保留关键文件和职责。

主路径清楚后，再补异常分支和边界条件。

梳理数据流

对于前端项目：

请梳理这个页面的数据流。

页面：
【页面路径或组件名】

请说明：
1. 数据从哪里来。
2. 哪些组件负责展示。
3. 哪些状态会变化。
4. 用户操作会触发什么。
5. 接口错误或空数据怎么处理。
6. 如果要改这里，最可能影响哪些文件。

对于后端项目：

请梳理这个接口的调用链。

接口：
【接口路径或方法名】

请说明：
1. 路由入口。
2. 参数校验。
3. 业务逻辑。
4. 数据库或外部服务调用。
5. 异常处理。
6. 权限和安全边界。

梳理依赖边界

架构梳理最有价值的部分，是依赖边界。

继续追问：

请分析当前模块的依赖边界。

要求：
1. 这个模块依赖哪些内部模块。
2. 哪些外部服务或配置会影响它。
3. 哪些依赖是强耦合。
4. 哪些依赖改动风险高。
5. 如果要重构，应该先隔离哪部分。

这能为后续重构和需求开发提供依据。

找出架构里的危险边界

架构图最重要的不是好看，而是标出不能乱碰的地方。

让 CC 继续检查：

请在架构梳理中标出高风险边界。

重点：
1. 权限和认证边界。
2. 数据写入边界。
3. 外部服务调用边界。
4. 缓存和异步任务边界。
5. 配置和部署边界。
6. 修改这些边界前需要哪些确认。

有了危险边界，后面做需求时才知道哪些文件必须谨慎。

输出团队文档

最后让 CC 生成团队文档：

请把架构梳理结果整理成团队文档。

结构：
1. 项目概览
2. 核心模块
3. 请求/数据流
4. 依赖边界
5. 风险区域
6. 新人接手建议
7. 后续需要补充的资料

要求：
- 面向团队成员阅读。
- 不要写无法从代码确认的结论。
- 对不确定内容标注“待确认”。

架构文档怎么验收

不要因为 CC 输出了一篇长文就算完成。至少检查：

• 入口文件是否准确。
• 核心模块是否遗漏。
• 调用链是否能在代码里找到证据。
• 数据流是否符合实际业务。
• 不确定内容是否标注待确认。
• 是否指出高风险边界。
• 新人能否按文档找到关键文件。

可以让 CC 自检：

请审查刚才的架构文档是否有无证据结论、遗漏入口或过度推断。
发现不确定内容时，请标注待确认，不要强行写成确定结论。

架构梳理后的下一步

架构梳理完成后，通常有三条路线：

不要把架构梳理当成终点。它的价值是帮助后续任务更稳。

验收结果

学完后，应该能做到：

• 让 CC 梳理项目整体架构。
• 让 CC 输出模块关系和数据流。
• 找到关键入口和高风险边界。
• 把架构说明沉淀成团队文档。
• 区分已确认结论和待确认信息。