接手新项目的第一天，我一行代码都没看

深夜的屏幕，是很多程序员认识一个陌生项目的开始。

刚接手那个项目的第一天，我盯着仓库里那几万行代码，脑子里只有三个字：从哪开始。

需求文档是有的，但写得很含糊；前任开发者走的时候，交接文档只写了两页，还基本都是“这个模块要改一下”。我要在两周内动工，没人带，群里问一句，半天没人回。

过去几年我也接过不少老项目，经验告诉我：这种时候最忌讳直接扑进代码里。先看懂业务，比先看懂代码更重要。可问题是——业务逻辑藏在一堆方法调用、状态流转和几乎没人维护的注释里，靠肉眼扫，三天都未必理得清。

于是我做了一个过去不敢做的决定：先别自己硬啃，让 AI 先帮我把它“讲懂”。

01 我一直觉得，业务是“懂”出来的，不是“搜”出来的

其实以前不是没试过用 AI 帮忙。写代码卡住的时候丢一段报错给它，让它定位、改错，早就成了日常。但在“理解一个陌生系统”这件事上，我一直觉得 AI 不行。

理由很简单：业务是“懂”出来的，不是“搜”出来的。代码里那点上下文，一个没有在这个项目里待过的人怎么可能接得住？更别说一个模型。

直到这次，项目太大、时间太紧，我决定赌一把。我把仓库的目录结构、几个核心模块的入口文件，还有那两页交接文档，一起丢给了 WorkBuddy，让它先用自然语言给我讲清楚：这个系统到底是干什么的、数据怎么流、核心业务链路长什么样。

它没有让我失望。

它没有像搜索引擎那样给我甩一堆关键词，而是自己把项目拆开——先列模块，再标注每个模块的职责，然后顺着调用关系画出一条条业务链路，最后回到我丢给它的交接文档，指出哪些地方文档写错了、哪些流程文档根本没提。

那一瞬间我有点恍惚：这不就是我以前理一个老项目时，要花整整一个周末才能做完的事吗？

02 真正让我上头的，是那段“边问边改”

当然，第一次输出只是“骨架”，很多地方是错的、空的。真正让我上头的，是后面那段边问边改的过程。

它说“订单状态机在 X 模块”，我就追问：“那支付回调是走这里吗？”它接住问题，重新沿着代码翻了一遍，回来告诉我不是，真正的入口在另一个服务，还顺手把两处状态不一致的地方标了出来。

我怀疑它某个结论，就指着一处具体代码问：“这段是不是根本没被走到？”它分析后承认判断有偏差，纠正了说法。

说实话，看着它被我问住又改口的样子，比我看到它一次答对还踏实——这说明它不是把记忆里的话吐给我，是真的在跟着代码走。

几轮下来，一个模糊的系统轮廓，慢慢在我脑子里立起来了。等我自己真正开始动手改代码的时候，我已经能说清楚“这个改动会影响哪几个模块、要走哪条链路、有没有牵连其他服务”。那种感觉，就像有人提前替我把地图画好，我只负责在上面开车。

03 该泼的冷水，一瓢都不能少

但我也要泼几盆冷水，不然这篇就成广告了。

爽的地方，是真的。理解上下文快、能顺着调用链往下追、能直接把结论落在具体文件上，这些在“梳理陌生代码逻辑”这件事上，它比我见过的绝大多数结对对象都强。它对“项目级”的把握，已经超过了很多刚入职、两眼一抹黑的初级开发。

翻车的地方，也一点不少。

第一，上下文一长它就容易“断片”，聊到后面它会忘掉前面自己说过的话，我得不停把它拉回来。

第二，生成的代码和它讲解的逻辑，偶尔对不上——它嘴上说得很漂亮，落笔到具体实现时又会偏。

第三，额度是真的不够用，几轮深度梳理下来，我的 Credits 掉得飞快，中段我开始克制地省着问。

最后也是最重要的一条：它“懂”的只是代码和文档，不是业务本身。系统背后那些决策、妥协、历史包袱，代码里没有，它自然也不知道。真正要拍板的地方，还是得靠人。

04 它不是替你接手项目，是帮你进入状态

所以这篇文章，我不是想告诉你“AI 能代替你接手项目”——那是假话。我想说的是另一件事：AI 不能替你“懂业务”，但它能帮你“进入状态”。

它把你从“面对几万行代码的无从下手”里拉出来，先让你看见地图，再让你决定往哪走。至于地图准不准、哪里要绕路，那依然是你的判断。

两周后我如期动了工。回头想想，这个项目真正难的部分，从来不是写那几行代码，而是没看代码之前，先想清楚这个系统到底在做什么。

而这一次，我让一个 AI 搭子，陪我一起把它想清楚了。