Claude Code 3个月造出"屎山代码"

AI写代码的速度已经卷到按小时计费。Claude Code、Cursor、Codex这些工具能在几小时内搭完整个项目，而且每个月都在变强。

但有个问题被严重低估了：AI工具只管代码能跑，不管架构死活。

它们生成的代码通过测试、顺利编译，但几周几个月后，代码库悄悄堆积起一种"建筑债务"——循环依赖、数据层直接调用API层、50个导出的上帝模块、无人清理的死代码。人类没察觉，AI代码审查也漏过。

TrueCourse的作者就是在自己的项目里踩了这个坑。AI代理写代码越来越快，但他仔细审查后发现：本该隔离的服务紧紧耦合，本该分层的边界互相渗透，却没人盯着系统整体。

于是他动手做了这个开源工具。

从"能跑就行"到"架构健康"：TrueCourse查什么

TrueCourse是一套CLI+Web UI组合，专门抓JavaScript/TypeScript代码里人和AI都漏掉的结构性、语义性问题。

架构违规层面，它盯循环依赖、层级越界、上帝模块、死模块、服务间紧耦合。代码智能层面，它找空catch块吞错误、共享可变状态导致的竞态条件、函数名与行为不符、Math.random()生成令牌或eval()处理动态输入这类安全反模式。

跨服务追踪是它的绝活：自动检测请求流如何穿越服务边界，并可视化为端到端链路。数据库分析则能识别Prisma、TypeORM、Drizzle等ORM，生成ER图，检查缺失索引和schema问题。

技术路线上，它把确定性规则（基于AST的静态分析）和AI深度审查结合起来。用户可以自选LLM供应商，也可以直接用Claude Code——不需要API key。

第一次运行只需一行命令：npx truecourse analyze。它会启动本地服务器，嵌入PostgreSQL数据库（无需Docker），引导配置LLM。终端打印违规项，Web UI自动弹出交互式依赖图。点击任意节点，能看到连接关系、违规详情、带内联标记的源码。

双界面设计：给人看，也给AI用

这个设计是刻意的。TrueCourse有两套界面：

Web UI给想可视化探索代码库的开发者——依赖图、内联代码查看器、分析仪表盘、diff模式。CLI则面向AI编码代理、CI流水线、自动化场景，输出结构化数据供代理消费。你可以从Claude Code里跑analyze，再进UI审结果。

两套界面共享同一分析引擎和分析历史。

实际跑起来，TrueCourse会生成几类关键报告。架构健康度用0-100分量化，按循环依赖、层级违规、模块复杂度、耦合度、死代码加权计算。模块依赖图用D3.js力导向布局，节点大小对应代码行数，颜色区分服务边界，红色虚线标违规连接。

跨服务请求流用桑基图展示，宽度对应调用频率，悬停显示平均延迟和错误率。数据库schema以交互式ER图呈现，外键关系自动连线，缺失索引用橙色警告标出。

一个典型场景：某微服务代码库跑完分析，发现订单服务直接调用用户服务的私有数据库——本应该走API的。TrueCourse在依赖图上把这条线标成红色，附上代码位置，并指出这破坏了"服务间通过契约通信"的架构原则。

AI编码时代的"架构守门人"

TrueCourse的差异化在于定位。它不是替代AI编码工具，而是给它们补一道架构安检。

现有工具链的分工大致这样：GitHub Copilot、Cursor们负责生成代码片段；Claude Code、Devin们负责端到端任务执行；ESLint、TypeScript编译器抓语法和类型错误；SonarQube、CodeClimate做传统静态分析。

但架构层面的问题——服务边界侵蚀、隐式依赖蔓延、技术债务累积——这些工具要么不碰，要么覆盖不全。TrueCourse填的就是这个空。

它的技术实现也有讲究。AST分析用Babel解析器处理JS/TS，生成代码的完整语法树，再遍历查找违规模式。AI审查层把代码片段和架构规则一起喂给LLM，让它判断语义层面的问题——比如函数名promiseSecureToken但实际用Math.random()，这种"说一套做一套"的代码。

性能上，中型代码库（约10万行）首次分析约2-3分钟，增量分析30秒内。分析结果存本地PostgreSQL，支持历史对比和趋势追踪。

开源策略选了MIT协议，代码在GitHub公开。作者明确表示欢迎贡献，但核心架构规则集由维护团队把控——"确保质量门槛不滑坡"。

社区反响超出预期。发布两周，GitHub star数破4000，Hacker News讨论帖热度前三。最集中的反馈是："终于有人做这个了"——太多开发者被AI生成的"能跑但腐坏"代码困扰，却缺乏工具化解决方案。

也有质疑声。部分人担心AI审查层本身依赖LLM，可能产生误报或漏报；另一些人觉得架构规则难以统一，不同团队的最佳实践差异很大。作者的回应是：规则集可配置，团队可以自定义层级定义、耦合阈值、忽略模式，但默认规则基于广泛接受的软件工程原则。

更实际的挑战来自集成深度。TrueCourse目前专注JS/TS生态，Python、Java、Go的支持在路线图但无时间表。数据库分析也只覆盖主流ORM，原生SQL或小众工具识别有限。

但这些没挡住早期采用者的热情。已有团队把它塞进CI流水线，每次PR跑架构健康度检查，分数下降就阻断合并。也有人在Claude Code工作流里固定跑analyze，让AI代理先审结构问题再改代码。

一个被反复提到的细节：TrueCourse的diff模式。它能对比两次分析结果，高亮新增违规和修复项。这对追踪AI编码会话的"架构副作用"特别有用——你让AI加了个功能，它顺手破坏了两个服务边界，diff模式让这种隐性成本显性化。

回到最初的问题：AI写代码快，但谁来检查架构？TrueCourse给了一个答案，但可能不是唯一答案。随着AI编码工具普及，"架构即代码""架构可测试"这类理念会不会成为标配？你的团队现在怎么保证AI生成的代码不变成明天的技术债务？