用AI读源码这件事：前端视角的实战方法论，附Vue3 reactivity源码解读示范
读源码这件事，前端开发者应该不陌生。
学新框架要看源码、理解某个第三方库的行为要看源码、接手一个没人维护的老项目更要翻源码。但说实话，源码读到一半上下文丢了、函数调用链路追踪到后面找不到头绪、第三方库没有文档只能靠猜------这些场景应该每个人都遇到过。
这两年AI工具多了，我开始尝试用AI辅助读源码。一开始踩了不少坑，后来慢慢摸索出几个相对稳定的用法，今天把实际验证过的方法论配合真实代码讲清楚。
1. 先定位再提问：不要把整个文件丢给AI
这是最容易犯的错误------把几百行代码一股脑丢给AI问"这段是做什么的"。
AI的上下文窗口虽然长，但代码量大了之后它容易失焦，回复要么泛泛而谈、要么开始自己编一段你根本找不到出处的逻辑。更关键的是，这样浪费了上下文token，效果反而差。
正确的做法
用IDE的 Go to Definition / Find References 定位到核心函数，只把相关的片段丢给AI。
实战演示：用Vue3 reactive 源码
假设我想理解 Vue3 的 reactive 函数做了什么。先找到函数定义：
typescript
// vuejs/core/packages/reactivity/src/reactive.ts
export function reactive<T extends object>(target: T): Reactive<T>
/*@__NO_SIDE_EFFECTS__*/
export function reactive(target: object) {
// 如果目标已经是readonly代理，直接返回
if (isReadonly(target)) {
return target
}
return createReactiveObject(
target,
false,
mutableHandlers,
mutableCollectionHandlers,
reactiveMap,
)
}这段代码本身不到20行，包含的类型声明和接口定义加起来也就50行左右。
丢给AI的提问方式：
"请解读这个reactive函数的实现逻辑，重点关注：1）为什么第一步要判断isReadonly；2）createReactiveObject各参数的含义；3）false这个标记位的作用是什么？"
比这样问效果好很多：
"reactive函数是做什么的？"（太宽泛，AI会复述文档而非分析代码）
不要这样问：
"帮我分析整个reactive.ts文件"（上下文太散，AI容易乱编）
2. 追问链：连续追问形成探索链路
读源码不是做问答游戏，不是问一句答一句就结束了。好的使用方式是连续追问，每一轮都基于上一轮的回答延伸。
追问链的标准模板
javascript
第一轮：这个函数的入参是什么类型，它做了哪些初步判断？
第二轮：如果入参已经是响应式对象会怎样？走哪个分支？
第三轮：这个分支里的Proxy是在哪里创建的？
第四轮：Proxy的get handler里，为什么要做scheduler判断？每一轮只问一个"深入一层"的问题，不要同时问多个相关但不同层次的问题------问多了AI会选最浅的回答你。
实战演示：用追问链追踪reactive的proxy创建
csharp
我：
reactive函数里的createReactiveObject做了什么？
AI：
createReactiveObject是创建响应式代理的核心函数...
它的第三个参数mutableHandlers是一个Proxy的handler配置对象...
它会拦截对象的get/set等操作来实现依赖收集和触发更新...
我：
那mutableHandlers在哪里定义的？
AI：
在reactive.ts同目录下的baseHandlers.ts中...
它定义了get、set、deleteProperty等handler...
核心逻辑在get函数里，涉及到isRef判断、嵌套reactive等内容...
我：
get handler里的isRef判断具体在哪个条件下触发？
AI：
当访问的属性值是一个ref对象时（通过isRef函数判断），
会自动解包ref并返回其内部值。这个逻辑在get handler中大约第15行附近...这样一层层追问下去，你会获得一条清晰的追踪路径，而且每一步都有代码依据。
追问链的进阶技巧
① 给AI一个假设，让它验证或否定：
"我猜测对数组调用reactive时，会进入COLLECTION分支，请对照代码确认这个猜测，如果不对指出第一个分叉点在哪里。"
这种方式的好处是：你有猜测，AI不会泛泛而谈；如果你猜错了，修正过程本身就是深入理解。
② 告诉AI你读到这里"卡住了"：
"我在追踪proxy的创建流程，但在createReactiveObject的第四个参数那里卡住了------这个WeakMap的作用是什么？它和reactiveMap有什么区别？"
把"卡住"说出来，AI会针对你的具体断点给出分析，而不是重新泛泛概述。
3. 标注"不确定"：让AI帮你做验证性推理
读代码时经常会有这种感觉------"这里逻辑看起来奇怪"或者"这个条件判断可能有问题"。
这时候可以直接把你的不确定告诉AI：
"我不确定这里为什么需要判断
!isObject，如果传进来的是数组会怎样？" "这段代码里如果target是null会走哪个分支？" "这个else分支我觉得永远不会执行，请帮我确认。"
这种"不确定+具体猜测"的方式，比直接问"这段代码的逻辑是什么"效果好很多。
原因在于：你在引导AI做验证性推理 ------验证或否定你的猜测，而不是做描述性推理------把代码表面意思翻译成自然语言。前者能挖到深层逻辑，后者只是换了种表达方式。
实战演示
在reactive源码中有这样一段：
typescript
function getTargetType(value: Target) {
return value[ReactiveFlags.SKIP] || !Object.isExtensible(value)
? TargetType.INVALID
: targetTypeMap(toRawType(value))
}可以这样问AI：
"我不确定这里为什么用
Object.isExtensible(value)来判断是否是无效目标，如果一个普通对象但它的原型被锁定了（Object.preventExtensions），会不会被误判为INVALID类型？"
AI会带你去看 Object.preventExtensions 和 Object.isExtensible 的区别，结合这段代码的具体场景分析这是有意为之还是潜在问题。
4. 用"用户视角"理解第三方库的外部行为
这个技巧适合在理解一个库的API行为时使用，而不是追踪内部实现。
核心思路：让AI站在调用方的角度，从外向内追踪。
比如我想理解 vueuse 的 useLocalStorage 为什么在SSR时会失效，我会这样说：
"作为一个使用useLocalStorage的开发者，我在SSR环境下发现值不同步。请帮我追踪这个函数的实现，找到可能导致SSR场景下行为不一致的原因。"
从"用户视角"切入，AI会倾向于从暴露的API开始追踪，而不是陷入内部的工具函数。对于理解一个库的外部行为特别有用。
5. 结合IDE做交叉验证
AI说的内容不一定完全准确，特别是涉及复杂调用链时。交叉验证非常重要。
我的习惯是：
- AI给出的关键结论，在IDE里用
Go to Definition快速确认 - 如果AI说的函数名在IDE里找不到，那说明AI在编造
- 对于特别重要的结论，同时问两个不同的AI工具，看结论是否一致
这本质上是一种工程思维------不迷信单一信息源，用多个工具交叉核对。
总结
用AI读源码这件事，用对了确实能提升效率，但有几个前提：
- 你得对代码结构有基本的方向感，知道去哪找文件、找哪个函数
- AI是辅助工具，不是替代品，核心逻辑还是得自己理解
- 不要过度依赖，遇到关键逻辑最好在IDE里自己跑一遍
- AI的结论要交叉验证，不轻信
这些方法不一定多新颖，但都是我实际工作里反复验证过的。如果有更好的技巧，欢迎交流。
参考资料
- Vue3 Core 源码 - reactivity 模块（MIT License）
- Vue3 官方文档 - Reactive 响应式原理
- MDN - Object.isExtensible
- MDN - Proxy
- Anthropic - Claude for Code（AI代码辅助工具相关研究）
- GitHub Blog - Developer Experience
以上内容均为技术原理分享，源码引用遵守Vue3的MIT开源协议。