上篇 Claude Code 源码深度架构分析 发出去之后，没想到突然火了。很多朋友来问我是怎么在这么短的时间内分析完 51 万行代码，还生成质量这么高的分析报告的。
泪目，居然还收到了打赏
首先感谢大家的肯定。起初我只是在内网写了篇帖子，简单讲了下核心思路，后来越来越多朋友希望能拿到原始的 Skill，认真考虑后，决定把自己花费大量心血反复打磨的这套 Skill 开源了。
Skill 支持三种安装方式：
# npx 一键安装
npx skills add yzddmr6/repo-analyzer
# Plugin Marketplace
/plugin marketplace add yzddmr6/repo-analyzer
# 手动 Git Clone
git clone https://github.com/yzddmr6/repo-analyzer.git ~/.claude/skills/repo-analyzer
装好之后，跟 Claude Code 说一句“帮我分析一下 xxx 项目”就行了。
开源主要出于两点考虑：
一是 AI 技术发展太快了，很多人还没找到正确的节奏。我目前可能只是稍稍多懂一点，希望能帮到大家。我知道这个 Skill 有很多不完美的地方，权当抛砖引玉，希望能给大家一些启发。
二是在我看来，我个人的核心竞争力，也不是一个 Skill 能代替的。物物而不物于物。保持 open，增加输入，才会让自己变得更强。之前写过不少开源项目，每次开源之后获得的反馈和成长，远比藏着掖着要多。
但授人以鱼不如授人以渔。光给一个 Skill 不够，今天更想跟大家分享的是这套东西背后踩过的坑，以及一些核心的思考。
时代真的变了
首先，人工是不可能在一个小时内分析完 51 万行这么多代码的，Claude Code 源码深度架构分析 这篇文章从标题，到分析，到里面的图片，100% 是 AI 生成的。
整个分析过程我就只输入了一句话：帮我用 repo-analyzer 这个 skill，深度分析一下这个项目。
分析完成后，我又用另一套 Prompt 模板把报告里的 Mermaid 图表转成了 Notion 风格的配图，最后加了那张花了 200 刀的狗头截图。就这些。
整体技术栈是 Claude Code + Opus 4.6 + Skills + Agent Teams/SubAgent。配图的 Prompt 模板网上有很多，找一个自己喜欢的风格调一下就行，跟分析本身是解耦的，不同文章可以套不同模板。
最终运行结果长这样：
7 个 subagent 全部完成，总成本 $223，实际运行时间 1 小时 34 分钟。7859 行代码变更，632 行被删除——这是交叉验证阶段发现问题后返工的痕迹。
51 万行代码，人工分析少说一个月以上。现在一个多小时就搞定了。
以前觉得不可替代的人类智力劳动，用 token 就能量化了。不再受碳基生物生理上的限制，只要你有钱，理论上可以分析得更快、更深入。
AI 带来的，是千百倍的效率提升。
起源：用魔法打败魔法
我自己平时就喜欢研究各种开源项目的实现和设计思路，之前也写过不少开源项目。
最早的起因是想分析 OpenClaw 的架构。但是发现那个项目代码又臭又长，人工根本看不完。于是就想，能不能用 AI 来加速这个过程？
直接让 AI 分析的效果很差。要么写流水账，“这个模块有三个类，分别是……”，像在给你念代码；要么偷懒跳过大段代码，只分析了个皮毛就告诉你“分析完了”；要么泛泛而谈，换个项目名字一样能用。
从那时候开始，我就一直在打磨这套分析流程。花了很多心血，到现在至少迭代了 20 多轮。
还记得除夕夜的晚上，旁边放着春晚，我还在电脑前优化。
一点点摸索出来一套方法论，然后把它沉淀成了这套 Skill。
核心流程
Skill 整个分析流程分 8 步。
第一步，项目获取与初始化。 先把项目拉下来。支持 GitHub URL、owner/repo 简写、本地路径，基本上你能想到的输入方式都支持。
第二步，规模评估与分析策略选择。 看看项目大概有多大，是个什么类型的项目，适合用什么方式来分析。不同规模的项目分析深度不一样——小项目可以逐行看，大项目得有取舍。
第三步，外部调研与文档研读。 先不急着看代码。先读一遍项目文档，搞清楚它是干什么的、解决什么问题。然后用搜索工具查一下网上对这个项目的评价、横向对比和社区讨论。这一步很重要，因为很多设计决策的“为什么”不在代码里，在项目的官网、博客和 RFC 文档里。
第四步，特征识别与自适应提问。 基本了解项目之后，Skill 会自动识别项目的关键特征，然后针对性地问你想关注什么。
这个问题列表不是固定模板，而是根据项目特征动态生成的。比如分析 Claude Code 的时候，它识别出这是一个 51 万行的 TypeScript CLI 项目，有完整的 agent/subagent 多层协作体系，有自研的 Ink TUI 框架——于是问你最关注哪些方面。不同项目问的问题完全不一样。这一步会持续多轮对话，让 AI 真正搞明白你想让它干什么。
第五步，分析规划生成。 根据用户需求生成分析规划。项目一般比较大，肯定会超出上下文窗口，所以需要把分析计划拆开，按模块划分，方便后面让 Agent Teams 并行分析。
第六步，Agent Teams/SubAgent 并行深度分析。 这是最吃资源的一步。把项目按业务模块拆分，每个模块分配一个独立的 subagent 并行分析。一是加速，二是上下文隔离，每个 agent 专注于自己负责的模块，不会被其他模块的信息干扰。
注：这里 Skill 中默认是 SubAgent，其实也可以用 Agent Teams 的方式。经过我的测试 SubAgent 效果更稳定。
光分析的原始草稿就有将近 20 万字符：
7 个模块的草稿加起来 184,388 个字符。这个信息量靠人工来写，怕是要写到天荒地老。
第七步，交叉验证与质量管控。 这一步是踩了坑之后才加的。
之前有一次，agent 告诉我分析完了。但报告质量明显不对，很多地方一笔带过。我问它分析了多少代码，它说重点代码都分析完了。我换了个问法：大概分析的代码比例是多少？agent 说 30%。
30%。它自己觉得“重点代码都看了”，实际上七成的代码连碰都没碰。
AI 认为的“重点”和你认为的，可能完全不是一回事。就跟带人一样，不设可量化的指标，对方永远觉得自己做得不错。
所以我专门加了这一步：用主 Agent 强行校验每个子 agent 的代码阅读覆盖率。每个 subagent 写完草稿必须附带覆盖率明细表——哪些文件读了、读了多少行、覆盖率多少。不达标就返工。
第八步，多源融合与最终报告。 最后由主 agent 根据各个子 agent 的模块分析结果，结合外部调研和用户要求，汇总成最终的分析报告。
报告默认输出 Markdown + Mermaid 图表，如果想要更好看的配图，可以再用图片生成的模板把 Mermaid 转成对应风格的架构图：
品味决定上限
光有流程还不够，51 万行代码你有很多角度可以写，但怎么才能写出有深度有启发的东西，而不是流水账？很多朋友发现自己分析出来的效果总是不够好。
这块我研究了挺久，总结了三点：
1、关注设计哲学而不是实现细节。 拿 Claude Code 源码分析来说，我不关心它底层用什么函数传参、类怎么划分。我关心的是它背后的设计理念——为什么要这么做，利弊是什么，为了什么场景做了哪些妥协。在 Skill 里我给 AI 的一个核心要求就是：不要写流水账，要分析设计选择背后的原因和取舍。
2、加入反思。 告诉模型分析的时候要时刻反思：如果让你来做，你怎么做得更好？我的目的不是复刻一个 Claude Code，而是希望自己构建 Agent 的时候能从别人的设计里吸取灵感。架构层面的思考比具体实现重要得多。
3、叙事连贯。 毕竟是给人看的，不能像字典一样按字母排列模块。要有叙事线，让读者跟着数据流或者问题链一路读下去，而不是每个模块孤零零地摆在那。
有个比喻我觉得非常恰当：AI 是一个尝不出咸淡的顶级大厨。他有着绝对的技术能力，但它不知道什么是好的。你的品味决定了它的上限。你得告诉它你要什么菜、什么口感。
我之前一直以为，AI 写的文章是垃圾、废话的代名词。后来才发现，我不是不喜欢看 AI 的文章，我只是不想看低质量的垃圾文章，跟 AI 没有关系。
决定这一切的，就是你的品味。
写在最后
搞这套流程的一个原因在于，现在信息泛滥、噪音泛滥，新技术新概念层出不穷，靠人肉去筛选消化根本跟不上。
用 AI 来降低信息的熵值，把自己的前额叶留给真正有价值的思考，我觉得这才是正确的打开方式。
我们有幸活在一个挺有意思的时代，每天都有新的好玩的技术出来。但可能最重要的还是判断力和决策力——知道什么是好的，然后做出正确的选择。
如果觉得这个项目对你有用，欢迎 star 和分享：https://github.com/yzddmr6/repo-analyzer
更多架构分析与 AI 实践心得，欢迎来云栈社区一起探讨。
发表于 3 小时前
|
查看: 5|
回复: 0
