Concise Summary简洁概述
Rather than writing another rushed "source code deep-dive" post, the author proposes a four-step method for genuinely internalizing any large open-source codebase: run it, trace one feature, rebuild it without AI, then redesign it from scratch.
The core insight is that AI-assisted "reading" produces borrowed understanding that collapses under scrutiny — real comprehension only emerges from running, tracing, and building code yourself.
作者没有跟风写又一篇"源码深度分析"，而是提出一套四步法，帮你真正吃透任何大型开源项目：先跑起来、从功能点切入、二次开发、从零重新设计。
核心观点是：靠 AI 分析代码得到的是"借来的理解"，经不起追问；真正的理解只能通过亲自跑代码、追踪逻辑、动手实现来获得。
Infographic信息图
Run it before you read it
先跑起来，再读代码
Static reading invites false confidence — you guess what a function does and never check. Running the code turns guesses into console.log verification, and lets you set breakpoints, which is far more efficient than eyeballing hundreds of thousands of lines.
光看代码容易产生"我大概懂了"的错觉。跑起来之后，你对函数的猜测能被日志立刻验证，还能打断点、设条件，这比在几十万行代码里用眼睛找逻辑效率高得多。
Enter through one feature, not the front door
以点带线，而非从入口通读
Starting at main() and reading linearly through tens of thousands of lines burns out in days. Instead, pick one feature you care about (e.g. the Agent Loop), trace its full request/response/tool-call cycle, and let adjacent modules reveal themselves naturally.
从入口文件通读几万行代码，三天就会放弃。更好的做法是选一个具体功能点（比如 Agent Loop），完整追踪它的请求-响应-工具调用链路，相邻模块会随着这条线自然浮现。
Rebuild features yourself, without AI assistance
二次开发时刻意不用 AI
Real understanding shows only when you build something yourself. The author recommends reimplementing existing features (a slash command, the memory system) manually — deliberately avoiding AI help, because AI would do the exact reasoning you're trying to internalize.
真正的理解只有动手才能验证。作者建议在成熟项目上做二次开发（比如重做一个斜杠命令或记忆功能），而且刻意不用 AI 辅助——因为 AI 代劳的正是你最需要锻炼的思考过程。
Design it from scratch to see the hidden trade-offs
从零重新设计，看见隐藏的权衡
Cloning an architecture only shows you the chosen path, not the rejected alternatives (legacy constraints, team size, time pressure). Redesigning from scratch on your own terms exposes where your "obviously better" instincts break down — and why the original authors chose differently.
照搬架构只能看到"选了 A"，看不到"为什么没选 B 和 C"背后的历史包袱、团队规模、时间压力。按自己的想法从零设计一遍，你那些"显然更好"的直觉会一动手就出问题，从而理解原作者的取舍。
Detailed Summary详细解读
The piece opens by explicitly refusing the genre it's writing into: within hours of the leak, the internet was saturated with AI-generated "architecture deep-dive" posts, and the author argues that 500k+ lines of source cannot honestly be analyzed that fast — so producing one more such post would just be noise. This framing matters because it sets up the real thesis: the value isn't in summarizing what the code does, but in teaching a transferable method for how to learn from any large codebase, leak or not.
Step one — "run it first" — is framed against the instinct to open files and start reading. The author gives two concrete reasons: static code invites unverified guesses about what a function does, while running code lets you confirm those guesses immediately; and once running, you can log and breakpoint, which is categorically more efficient than manually tracing logic across tens of thousands of lines. Notably, the author flags a safety caveat about the specific runnable fork used — recommending an AI security scan before running third-party restored code — showing practical caution rather than blind endorsement.
Step two — "enter through one feature, not the whole file tree" — targets a specific common failure mode: starting at the entry point and reading linearly, which burns out within days on a codebase this size. The alternative is to pick something concrete you're curious about (the author's example: the Agent Loop), capture the full request/response/tool-call cycle for one round of conversation, and let the surrounding modules reveal themselves as you trace that one thread. The author notes this approach beats the old claude-trace tool now that raw source access allows finer-grained custom logging.
Step three is the pivot from passive to active: hands-on re-implementation of an existing feature (the author cites the newly launched /buddy command and the memory system as examples) without AI assistance. The counterintuitive instruction — don't use AI even though it's faster — is the sharpest claim in the piece: outsourcing the build to AI means skipping exactly the reasoning you're trying to acquire (why this module placement, why this interface shape), so the efficiency gain defeats the learning purpose entirely.
Step four pushes past imitation into understanding *why*: designing a from-scratch version guided only by your own judgment, informally referencing the original architecture. This is where hidden constraints surface — legacy debt, team size, deadlines, technical limits invisible from the outside — because your own "obviously better" choices will break in ways that retroactively explain the original design decisions. The author calls this the hardest and highest-payoff step, marking the transition from "understood" to "could have designed this myself."
A closing appendix pivots to commentary on the leak itself: its practical value is limited (reverse-engineered SDKs go stale the moment Claude Code updates; big labs already had this insight), and open-sourcing outright is implausible for Anthropic given messy production code, hidden anti-distillation logic and telemetry, controlled feature-release timing (e.g. /buddy held for April Fools'), and faster iteration without open-source review overhead. The piece ends by praising Anthropic's blameless post-incident response — attributing the leak to a manual deployment step that should have been automated, not to any individual — and dismissing viral claims that an employee was fired over it as unfounded marketing noise.
文章开篇就明确拒绝了自己本可以蹭的热点：泄漏后几小时内，网上已经堆满了 AI 生成的"架构深度分析"文章，而作者指出 50 多万行代码根本不可能在这么短时间内被诚实地分析清楚，再写一篇只是徒增噪音。这个开场很关键，因为它把文章的真正主张立住了：价值不在于总结代码做了什么，而在于教一套能迁移到任何大型代码库（不管是不是泄漏来的）的学习方法。
第一步"先跑起来"针对的是大多数人拿到代码就开始逐文件阅读的本能反应。作者给出两条具体理由：一是静态阅读容易产生未经验证的猜测，跑起来才能立刻用日志验证对错；二是能跑起来才能打日志、设断点，这比在几万行代码里靠肉眼找逻辑效率高得多。值得注意的是，作者特别提醒了这个具体可运行分支的安全隐患——建议先用 AI 扫描安全问题再运行第三方还原的代码，体现出实用主义式的审慎，而非盲目背书。
第二步"以点带线"针对的是另一种常见误区：从入口文件开始线性通读，面对几十万行代码这么读几天就放弃了。替代做法是挑一个你真正关心的具体功能（作者举的例子是 Agent Loop），完整追踪一轮对话中的请求、模型返回、以及后续处理，周边模块会随着这条线自然浮现。作者还提到，比起之前用过、后来失效的 claude-trace 工具，现在有了源码，自己加日志能做得更细。
第三步是从被动理解转向主动验证的关键节点：不借助 AI，动手重新实现一个已有功能（作者举了刚上线的 /buddy 命令和记忆机制为例）。"哪怕效率更低也不用 AI"这个反直觉的建议是全文最锋利的论点：把开发过程外包给 AI，恰恰跳过了你想获得的思考过程——为什么这样组织代码、接口为什么这样设计——效率提升直接抵消了学习目的。
第四步是从模仿走向理解"为什么"：只凭自己的判断、参考原架构，从零设计一版。这一步会暴露出外部看不见的隐藏约束——历史包袱、团队规模、截止日期、当时的技术限制——因为你自己那些"显然更好"的设计一动手就会出问题，而这恰恰反推出原作者当初为何那样选择。作者称这是最难但收获最大的一步，标志着从"读懂了"到"能自己做出架构方案"的跨越。
结尾附加部分转向对泄漏事件本身的点评：泄漏代码的实际价值有限（逆向出的 SDK 一旦 Claude Code 更新就会过时；大厂早就该逆向的都逆向过了），而 Anthropic 不可能借机开源——代码质量参差、藏有防蒸馏逻辑和用户标识记录等"暗搓搓"的机制、需要控制功能发布节奏（比如 /buddy 是特意留到愚人节）、以及开源审查流程会拖慢迭代速度。文章最后肯定了 Anthropic 事后"不甩锅个人"的处理方式——把泄漏归因于本该自动化却仍是人工操作的部署环节，而非某个员工——并驳斥了"有员工因此被开除"这类蹭热度的营销号说法。
FAQ常见问答
Why not just read an AI-generated architecture summary of the leaked code?为什么不能直接看 AI 生成的架构分析总结？
Because that understanding is borrowed, not earned — it collapses the moment you're asked a follow-up question, since you skipped the tracing and building that would let you actually reason about the design.
因为那是"借来的理解"，一旦被追问就经不起推敲——你跳过了追踪逻辑和动手实现的过程，也就无法真正对设计做出推理。
Isn't refusing AI help in step 3 inefficient, given how fast AI can write code?第三步不用 AI 辅助，效率不是很低吗？
Yes, deliberately — the goal there is learning, not shipping. AI would do exactly the reasoning (module placement, interface design) that re-implementing by hand is meant to teach you.
是刻意为之——这一步的目标是学习而非交付。AI 代劳的恰好是模块划分、接口设计这类你最需要锻炼的思考过程。
What's the actual practical value of the leaked Claude Code source?泄漏的 Claude Code 源码到底有多大实用价值？
Limited — reverse-engineered SDKs based on it go stale as soon as Claude Code updates, and major labs already had equivalent insight. The real beneficiaries are a small group of researchers and small teams learning specific techniques.
有限——基于它逆向出的 SDK 只要 Claude Code 一更新就会过时，大厂该逆向的也早就逆向了。真正受益的是少数深入研究的开发者和小团队，能学到一些具体技术细节。
Why wouldn't Anthropic just open-source Claude Code now that it's leaked?既然都泄漏了，Anthropic 为什么不干脆开源？
Closed source lets them ship messy production code, hide anti-distillation and telemetry logic, control feature release timing, and iterate fast without open-source review overhead — all benefits they'd lose by open-sourcing.
闭源能让他们不用讲究代码质量、暗藏防蒸馏和用户标识逻辑、控制功能发布节奏、还能跳过开源审查流程快速迭代——这些好处一开源就全没了。
Does this four-step method apply only to Claude Code, or to any open-source project?这套四步法只适用于 Claude Code 吗，还是适用于任何开源项目？
The author explicitly states it generalizes to any large open-source project — run it, enter through one feature, rebuild without AI, then redesign from scratch — Claude Code is just the timely example.
作者明确说明这套方法适用于任何大型开源项目——先跑起来、从功能点切入、二次开发、从零重建——Claude Code 只是应景的例子。
In-depth Analysis · Pros & Cons深入解读 · 优缺点
This piece skips the crowded pile of "deep-dive" analyses that appeared within hours of the Claude Code source leak, and instead offers a reusable method for genuinely absorbing any large open-source codebase. It closes with a sharp take on why Anthropic can't simply open-source the project, and a defense of how the team handled the leak internally.
这篇文章没有跟风写 Claude Code 源码泄漏后满屏的"深度分析"文章，而是提炼出一套可复用于任何大型开源项目的学习方法论。结尾还犀利点评了 Anthropic 为何不可能顺势开源，以及团队内部如何处理这次泄漏事件。
- Actionable and generalizable方法具体且可迁移Each step comes with a concrete example (Agent Loop tracing, /buddy re-implementation) and the author explicitly states the method applies to any large open-source project, not just this leak.每一步都配有具体案例（追踪 Agent Loop、重做 /buddy 命令），作者也明确说明该方法适用于任何大型开源项目，而不只是这次泄漏事件。
- Names the real failure mode精准点出真实的失败模式Rather than vague encouragement to "practice more," the piece identifies the specific stall point — reading a lot but never building — which matches a common, recognizable experience for engineers studying large codebases.文章没有泛泛而谈"多practice"，而是精准指出具体的卡壁点——看了很多但没动手写过，这与工程师研读大型代码库时的常见真实体验高度吻合。
- Timely, non-redundant contribution选题避开同质化竞争By explicitly declining to write another AI-flavored deep-dive amid a flood of similar posts, the author adds a genuinely distinct angle to the news cycle instead of repeating what dozens of other writers already published.作者明确拒绝在一堆同质化的"深度分析"文章中再添一篇，转而提供了真正差异化的视角，而不是重复几十篇文章已经说过的内容。
- Balanced take on the leak's significance对泄漏事件影响的判断克制理性The closing commentary avoids both the hype ("this changes everything") and dismissal, giving a measured read on who actually benefits from leaked source and why open-sourcing isn't a realistic alternative.结尾评论既不夸大"这将改变一切"，也不轻视其价值，对谁能真正从泄漏源码中受益、以及为何开源不是现实选项给出了克制而理性的判断。
- No evidence the method scales to unfamiliar domains未验证该方法在陌生领域是否同样有效The author already has deep context on agent architectures, so tracing the Agent Loop was easy for them; a reader unfamiliar with LLM tooling might struggle to even pick a meaningful entry-point feature.作者本身对 Agent 架构已有深厚积累，追踪 Agent Loop 对他来说并不难；但对不熟悉 LLM 工具链的读者来说，可能连该切入哪个功能点都难以判断。
- Safety caveat undermines the recommended fork推荐的可运行分支自带安全隐患The author flags that the runnable fork's security and long-term availability are unverified, yet still recommends it as the practical entry point — a real risk for readers who skip the suggested AI security scan.作者自己承认这个可运行分支的安全性和长期可用性未经验证，却仍将其作为实践入口推荐给读者——如果读者跳过建议的 AI 安全扫描，这是真实风险。
- "Don't use AI" is asserted, not tested against alternatives"不用 AI"的建议缺乏对照实验支撑The claim that AI-assisted re-implementation skips valuable reasoning is plausible but presented as intuition, not backed by any comparison of learning outcomes between AI-assisted and manual re-implementation.AI 辅助会让人跳过关键思考过程这一说法虽然合理，但只是直觉判断，并没有对比"用 AI 辅助"和"完全手动"两种学习效果的实际数据。
- Anthropic-favorable framing on the leak commentary对泄漏事件的评论倾向于为 Anthropic 辩护The closing section largely takes Anthropic's own blameless-postmortem framing at face value, without engaging alternative views on accountability for a leak of this scale, or scrutinizing whether "no one was blamed" is itself verifiable from outside the company.结尾部分基本照单全收了 Anthropic 官方的"不甩锅"叙事，没有讨论关于如此规模泄漏问责边界的不同观点，也没有质疑"没有人被追责"这一说法从外部是否可核实。
Read this if you've ever grabbed a large open-source repo and given up after a few days of unfocused reading — the four-step method (run, trace one feature, rebuild without AI, redesign from scratch) is genuinely actionable and not tied to Claude Code specifically. Treat the closing commentary on the leak and Anthropic's incident response as one practitioner's informed but sympathetic take, not a neutral investigation.
如果你曾经拿到一个大型开源项目，读了几天就因为找不到方向而放弃，这篇文章的四步法（跑起来、切入功能点、不用 AI 二次开发、从零重新设计）值得一试，且不局限于 Claude Code 本身。但结尾对泄漏事件和 Anthropic 危机处理的评论，更接近一位从业者的善意解读，而非中立调查，读的时候留个心眼。
Original Text原文
The English text on this side is an AI translation provided for convenience; the authoritative version is the source in the other language.
Claude Code's source code leaked, and the internet is now flooded with "deep analysis" articles. Some friends asked me to write one too, but the code only leaked a dozen or so hours ago — over 500,000 lines of code — so a thorough analysis is genuinely hard to pull off. But rather than handing someone a fish, I'd rather teach them to fish: I want to talk about how to actually learn a codebase once you get your hands on it.
This approach isn't specific to Claude Code — it applies to any large open-source project.
Step one: get it running
When most people get hold of source code, their first instinct is to open a file and start reading.
Don't rush into that. Get it running first.
The leaked Claude Code code is the result of reversing a source map, and it's missing a lot of scaffolding and private packages, so it can't be run directly. I was planning to sort it out myself, but it turned out someone had already done it (https://github.com/claude-code-best/claude-code) — you can just use that.
Note: I don't know the author of this project — I'm just recommending it because I was able to download and run it without issues. I have no idea how the project will develop going forward, and there's a good chance it'll get taken down. If you're interested, download the code locally as soon as possible, and have an AI check it for security issues before you run it.
Why is it so important to get it running? Two reasons.
First, you get to see the results directly. Code is static on the page; it only comes alive once it's running. When you're reading and think "this function is probably doing X," running it tells you whether you guessed right.
Second, you can add logging and set breakpoints. This is the core technique for the next stage, when you're analyzing specific features. Trying to trace logic through tens of thousands of lines of code with your eyes alone is basically like finding a needle in a haystack. Once it's running, drop in a console.log and the code will tell you what it's doing.
Step two: build outward from a single point, then a line, then an area
Once the project is running, a lot of people make a mistake here: they try to read the whole thing start to finish, beginning at the entry file.
With tens of thousands of lines of code, you'll give up after three days doing it that way.
A better approach is to start from one concrete feature.
Say you're interested in the Agent Loop. Print or capture every API request, look at what the prompt sent to the model looks like, what the model returns, and what Claude Code does with that response afterward. After walking through a single round of conversation, you'll have a concrete grasp of how an agent breaks down a task and calls tools.
I used to do something similar with claude-trace, but unfortunately it stopped working. Now that we have the source code, I can add much finer-grained logging myself.
Once you understand one specific feature, you'll naturally run into the modules it passes through: how input comes in, what processing it goes through, how tool calls get triggered, how the results get stitched back together. That's how the relationships between modules get strung together, one by one.
Don't try to cover too much. Thoroughly understanding one feature is far more useful than skimming ten modules.
Step three: get your hands dirty — leave your own mark on the code
If you only read code, what you learn easily turns into a feeling of "I think I get it" rather than real understanding. The moment you actually try to build something, that illusion falls apart.
That said, there's no need to build something from scratch. For a mature project, the best way to practice is through building on top of it.
For example, Claude Code just released a /buddy command that raises a little pet for you. You could try implementing a similar slash command yourself, or add some new twist to it. Or take Claude Code's memory feature — you could study how it stores and reads memory, then try implementing your own version of that mechanism. Its architecture is already relatively stable, so you're really just filling in logic within an existing framework — the barrier to entry is actually not that high.
When you're building on top of it, try not to use AI assistance.
I know that sounds counterintuitive. AI makes writing code so much faster — why not use it? Because the goal here is different. Your goal is to learn, not to ship. If you let AI write it for you, you skip over exactly the most valuable part of the thinking process: why is the code organized this way? Why does this module live here? Why was the interface designed like this?
Once you can build a feature entirely on your own, start to finish, your understanding of the project shifts from "I've looked at it" to "I've built with it."
After building a few features, you'll become increasingly familiar with the overall architecture — and you might even start feeling that some parts could be done better.
That's exactly the point.
Step four: from imitation to going beyond it
Building on top of the project makes you familiar with its architecture — you know "what it looks like." But one question always remains: why was it designed this way in the first place?
Architectural decisions are usually shaped by a lot of things you can't see: historical baggage, team size, time pressure, the technical constraints of that era. Standing in front of the result, you can see that "A was chosen," but you can't see "why B and C weren't."
The best way to understand that is to build your own version from scratch.
It doesn't need to be feature-complete or cover every case. Based on your own thinking, and referencing the original architecture, redo the design decisions yourself. You'll find that the things you assumed were "obviously the right way to do it" break the moment you actually try them. That's when you understand why the original author made the choice they did.
This step is the hardest, but it's also where you gain the most.
By the time you reach this point, you're no longer just someone who "understands" the project — you're someone capable of coming up with your own architectural approach.
Finally
These four steps sound simple: get it running → start from a single feature → build on top of it → build from scratch. But I've noticed something interesting: most people get stuck between step one and step three — meaning they've looked at a lot, but never actually written any code.
This problem is even more likely in the age of AI. It's so convenient to have AI analyze code for you — in a few seconds you get an "architecture overview." But that kind of understanding is borrowed, and it doesn't hold up under scrutiny.
What methods have you used to learn from open-source code? Is there a project you've truly "chewed through" yourself?
Appendix: a few words on the Claude Code leak itself
The value of the leaked code is limited.
Some people reverse-engineered Claude Code's related logic from the leaked code and built an open-source SDK out of it. Not a bad idea, but this code is a static snapshot — the moment Claude Code updates, you fall behind. Fine for learning, but not realistic as a foundation for a product.
Its impact on the industry isn't as huge as some people are making it out to be either. Ordinary developers don't need to look at this; the big companies that wanted to reverse-engineer it had already done so long ago. The people who actually benefit are a small group of developers and small teams who are genuinely interested in digging deep — they really can pick up some valuable technical details from it.
Some people ask: since it leaked anyway, why doesn't Anthropic just open-source it? I don't think that's going to happen. There are too many benefits to staying closed-source:
Code quality doesn't need to be held to as high a standard. A React file that runs to several thousand lines — nobody knows if it's closed-source, but if it were open-sourced, it would get roasted.
You can quietly slip things in — anti-distillation logic, user-identifier logging, even a bug that "accidentally" breaks third-party prompt caching — with closed source, you don't have to worry about getting caught.
You can control the release cadence. This time around, quite a few hidden features turned up — for instance, /buddy had already been built and was just waiting for April Fools' Day. If it were open-source, that kind of surprise couldn't stay hidden.
You can iterate quickly without going through a heavy code review process — open source comes with a lot more constraints.
One thing is worth mentioning. Anthropic responded to the leak directly, and Boris put it well:
In work, mistakes are always going to happen. But as a team, the most important thing is to reach a shared understanding: when something goes wrong, it should never be pinned on an individual. The real "culprit" is usually our process design, our team culture, or the underlying infrastructure.
This particular issue came from a deployment step that should have been automated but was still being done manually. No individual was blamed, and nobody was fired over it. Any accounts claiming "someone who just joined Anthropic got fired over this" are just clout-chasing rumor accounts — don't believe them.
Face the problem head-on, and improve the process. That's what a real engineering team looks like.
Claude Code 源码泄漏了，满屏都是“深度分析”文章。也有朋友让我写一篇分析文章，但代码才泄漏十几个小时，50 多万行代码，想深度分析清楚还是有难度的。不过授人以鱼不如授人以渔，我更想聊聊：拿到一份开源代码，怎么把它真正学到手。
这套方法不只适用于 Claude Code，任何大型开源项目都一样。
第一步：先跑起来
拿到源码之后，大部分人的第一反应是打开文件开始读。
别急。先跑起来。
这次泄漏的 Claude Code 代码是 source map 还原后的结果，缺了很多脚手架和私有 package，没法直接运行。我本来打算自己折腾一下，结果发现已经有人搞定了（https://github.com/claude-code-best/claude-code），直接用就好。
注：这个项目作者我不认识，只是我可以正常下载运行，所以推荐，后续项目如何发展我并不清楚，而且被下架的可能性很大。有兴趣的可以尽早把代码下载到本地，并让 AI 分析一下代码有无安全问题后再运行。
为什么一定要跑起来？两个原因。
一是你能直观看到运行结果。代码是死的，运行起来才是活的。 你读代码时觉得“这个函数大概是做这个的”，跑一遍就知道你猜对了没有。
二是你可以打日志、设断点。后面分析具体功能的时候，这是核心手段。光用眼睛在几万行代码里找逻辑，跟大海捞针差不多。跑起来之后加个 console.log，代码自己会告诉你它在干什么。
第二步：以点带线，以线带面
项目跑起来了，下一步很多人会犯一个错误：试图从入口文件开始，把整个项目从头读到尾。
几万行代码，这么读下去三天就放弃了。
更好的做法是从一个具体的功能点入手。
比如你对 Agent Loop 感兴趣。那就打印或者收集所有的 API 请求，看它发给模型的 Prompt 长什么样，模型返回了什么，Claude Code 拿到返回之后又做了什么。一轮对话下来，你对“一个 Agent 怎么拆解任务、怎么调用工具”就有了直观的认识。
以前我用 claude-trace 做过类似的事情，可惜后来用不了了。现在有源码了，自己加日志能做得更细。
当你搞清楚一个功能点之后，自然会接触到它经过的模块：输入怎么进来的，经过了哪些处理，工具调用怎么触发的，结果怎么拼回去的。模块之间的关系，就这样一个一个串起来了。
别贪多。搞透一个功能点，比走马观花看十个模块有用得多。
第三步：动手改，在代码上留下你的痕迹
光看代码，学到的东西很容易变成“感觉自己懂了”。一动手就原形毕露。
但从零写一个也没必要。对于一个已经成熟的项目，最好的练手方式是二次开发。
举个例子，Claude Code 刚发布了一个 /buddy 命令，会给你养一只小宠物。你可以试着自己实现一个类似的斜杠命令，或者给它加点新花样。再比如 Claude Code 的记忆功能，你可以研究它是怎么存储和读取记忆的，然后试着自己实现一套记忆机制。它的架构已经相对稳定了，你只需要在现有框架里填充逻辑，入门门槛其实不高。
做二次开发的时候，尽量别用 AI 辅助。
我知道这听起来很反直觉。用 AI 写代码效率高这么多，为什么不用？因为目的不一样。你的目标是学习，不是交付。让 AI 帮你写了，你跳过的正好是最有价值的思考过程：为什么要这样组织代码？这个模块为什么放在这里？接口为什么这么设计？
当你能从头到尾靠自己把一个功能开发出来，你对这个项目的理解就从“看过”变成了“做过”。
多做几个功能之后，你会越来越熟悉它的整个架构，甚至开始觉得有些地方可以做得更好。
这就对了。
第四步：从模仿到超越
通过二次开发你熟悉了项目架构，知道它“是什么样的”。但有一个问题一直留着：当初为什么要这么设计？
架构决策的背后往往有很多你看不到的东西：历史包袱、团队规模、时间压力、当时的技术限制。你站在结果面前，看到的是“选择了 A”，但看不到“为什么没选 B 和 C”。
想搞清楚这些，最好的办法是自己从零搭一个。
不需要功能完整，不需要面面俱到。按照你自己的想法，参考原来的架构，重新做一遍设计决策。你会发现那些你以为“显然应该这样做”的地方，一动手就出问题了。然后你就理解了原作者为什么那样选。
这一步是最难的，但也是收获最大的。
走到这一步，你已经不只是“读懂了”这个项目，而是有能力做出自己的架构方案了。
最后
这四步说起来简单：跑起来 → 从一个功能点切入 → 二次开发 → 从零搭建。但我观察到一个有意思的现象：大多数人卡在第一步和第三步之间，也就是“看了很多，但没动手写过”。
AI 时代更容易出现这个问题。让 AI 帮你分析代码太方便了，几秒钟就给你一份“架构全景图”。但这种理解是借来的，经不起追问。
你用过什么方法学开源代码？有没有哪个项目是你真正“啃”下来的？
附：聊几句这次 Claude Code 代码泄漏本身
泄漏代码的价值，有限。
有人从泄漏的代码里逆向了 Claude Code 的相关逻辑，做出了开源的 SDK。思路挺好，但这份代码是静态的，Claude Code 一更新你就跟不上了。拿来学习可以，拿来做产品基础不太现实。
对行业的影响也没有一些人渲染得那么大。普通开发者用不着看这些，大厂该逆向的早就逆向了。真正受益的是一小部分有兴趣深入研究的开发者和小团队，从里面确实能学到一些有价值的技术细节。
有人问既然都泄漏了，Anthropic 为什么不干脆开源？ 我觉得不可能。闭源的好处太多了：
代码质量不用太讲究。一个 React 文件写了几千行，闭源没人知道，开源出来会被喷死。
可以暗搓搓加料。防蒸馏的逻辑、用户标识的记录，甚至“不小心”导致第三方 prompt caching 失效的 bug，闭源不用担心被抓包。
可以控制发布节奏。这次就发现了不少隐藏功能，比如 /buddy 早就开发好了，就等愚人节开启。开源的话这种惊喜就藏不住了。
快速迭代不用走复杂的代码审查流程，开源的顾忌多得多。
有一件事值得一提。 Anthropic 正面回应了这次泄漏，Boris 说得很好：
工作中，犯错总是在所难免。但作为一个团队，最重要的是要达成一种共识：出了问题绝不该怪罪到某个人头上。真正的“罪魁祸首”往往是我们的流程设计、团队文化，或者是底层的基础设施。
这次的问题出在一个本该自动化、却还是人工手动操作的部署环节上。没有怪到个人头上，也没有因此开除谁。那些号称“刚加入 Anthropic 搞出这事被开除了”的都是蹭热度的营销号，别信。
直面问题，改进流程。这才是一个工程团队该有的样子。
See all posts