GitHub新项目Floorplan：让AI帮你画出代码库的连接关系
Floorplan用自然语言展示代码库结构，适合接手陌生项目、梳理模块关系和检查AI生成代码的架构问题。它不是自动理解一切的导航仪，而是一张需要开发者核对的动态地图。
适合：适合需要快速梳理代码库结构、模块依赖和核心调用链的开发者及AI编程用户。
GitHub项目Floorplan在近期获得1765颗星。它的思路很直接：不只告诉开发者代码在哪里，而是先用一句人能看懂的话，把应用各部分怎么连接、谁依赖谁、入口在哪里讲清楚。
这比传统目录树多了一层关系信息。目录树回答“有哪些文件”，Floorplan想回答“这些文件为什么会出现在同一个系统里”。对经常使用Claude、Codex一类AI编码工具的人，这项能力有实际意义。AI写得越快，项目结构越容易藏进文件堆里；此时，一张可交互的代码地图往往比继续追问聊天窗口更有用。
先说结论
Floorplan值得关注，但更适合作为“读项目的第一张地图”，不是替代代码搜索、调试和人工评审的最终答案。
它最有价值的地方，是把代码库从一串文件名变成一张关系图。接手旧项目、梳理陌生仓库、评估AI生成改动时，这张图能先建立整体印象，让你知道应该从哪里读、哪些模块值得优先检查。
它目前采用JavaScript开发，项目介绍强调可交互、可用自然语言理解的应用关系图，并由Claude或Codex参与绘制。这个定位很清楚：重点不是生成一张静态架构图，而是让地图围绕代码库展开。
真正的问题
代码库最大的麻烦，通常不是文件太多，而是边界模糊。
同一个功能可能横跨路由、控制器、服务层和数据库；一个看起来很小的工具函数，可能被多处调用；AI一次生成十几个文件后，目录看起来整齐，实际依赖却可能变得混乱。此时，单看README或目录结构，很难迅速判断整体关系。
传统架构图也未必能解决这个问题。手工画的图往往只表达设计者记忆中的系统，项目改完以后，文档未必同步。自动生成的图虽然新鲜，却可能把文件引用、服务调用和业务边界混在一起，让人误以为图上每条线都同样重要。
Floorplan面对的正是这个矛盾：代码需要结构说明，但结构说明又最容易过期。它把AI用于理解并描述代码库，优势是快；风险也同样明显——只要理解错了，图就会错得很像真的。
怎么做更省力
第一次打开一个陌生仓库，不要急着把生成结果当成完整结论。更省力的做法，是分三轮使用。
第一轮只看全局。确认入口、主要模块、核心数据流和外部依赖，不追问每个细节。目标是先回答“系统由哪几块组成”，而不是“每个函数做什么”。
第二轮再核关系。沿着一个具体功能走，例如登录、支付或内容发布，观察相关模块是否被标成一条清晰链路。发现跳线、孤立文件或含糊描述时，回到代码搜索中核对，不要因为图上没有连接就断定代码无用。
第三轮用于复查。完成较大改动后，再生成一次地图，比较模块边界、依赖方向和入口描述有没有变化。如果地图与代码对不上，应先判断是项目结构混乱，还是地图理解出现偏差。
如果你需要把梳理结果用于团队汇报，可以再借助流程图架构助手，把业务流程或技术关系整理成稳定、易沟通的图示。Floorplan负责帮助理解现有代码，架构助手更适合整理和表达结论，两者分工不同。
哪些坑要避开
第一，别把星标数当成技术指标。一周内获得1765颗星，说明项目受到关注，不等于它已经覆盖所有语言、所有框架或所有规模的项目。可视化结果准不准，最终仍取决于代码库质量、目录组织以及生成过程能否获得必要上下文。
第二，别把AI画出的关系当测试结果。图中出现一条依赖连线，只能说明工具识别到了某种关系，不能证明这条链路运行正常。接口契约、异常分支、权限控制和性能问题，仍要通过代码阅读与实际验证确认。
第三，别让地图替代文档。代码库地图适合回答结构问题，却未必能完整承载背景知识、历史决策和业务规则。尤其是大型项目，部署环境、基础设施与跨仓库依赖往往需要额外信息，不能仅凭一张图下判断。
第四，别默认所有孤立文件都没有价值。实验脚本、构建脚本、迁移文件和暂时停用的模块，都可能在图里显得“不相干”。先确认文件用途，再决定是否清理或重构。
现在就能动手
选一个自己最近接手、但还没完全吃透的小型仓库，先用Floorplan生成关系图。随后只做三件事：标记一个核心入口，沿一个真实功能核对调用链，再列出图与代码不一致的地方。
如果这三步能让你更快读懂项目，它就值得加入日常工具链；如果你仍然需要反复手工搜索才能验证关键关系，也不要勉强依赖。更稳妥的用法，是把它当作AI编码前后的结构检查器：先看全局，再查局部，最后用代码和运行结果收口。