我曾深陷在一个庞大得让人头秃的微服务架构里，死活搞不明白为什么从 user service 发起的计费请求突然开始返回 403 了。权限验证（auth）的逻辑像大杂烩一样散落在三个代码库、一个共享库，还有一层现在团队里没人写过的中间件里。经过两小时靠 grep 敲击驱动的开发、在无数浏览器标签页里来回切换、顺着函数调用一路追查却处处碰壁之后，我意识到：面对这种跨代码库的“地牢探险”，我平时的那套工作流已经彻底失效了。
正是这种抓狂的经历，让我遇到了 Sourcegraph Cody。之前我也用了一阵子普通的 AI 编程助手，但它们总像是在“失忆”——写点模板代码贼溜，但对我手头正在搞的真实代码库却一问三不知。Cody 承诺了不一样的东西：一个真正懂你整个代码库的助手。下面是我配置它的过程，以及这一路踩过的坑。
在 VS Code 中配置 Cody
安装过程很简单，但有个关键步骤很容易被一笔带过。
首先，在 VS Code 插件市场安装 Cody 插件。直接搜索“Cody”（发布者是 Sourcegraph），然后点击安装即可。
我就在这儿踩了第一个坑：我跳过了登录步骤，以为直接开敲键盘就能跑起来。结果根本不行。Cody 需要 Sourcegraph.com 账号来处理代码智能和嵌入向量（embeddings）。你可以直接在插件界面免费注册一个。
登录后就能用免费版了。写这篇文章时，免费版每天允许在 Sourcegraph.com 上最多查询 50 次，外加 IDE 里的本地代码库上下文。就我的日常工作来说，这个免费额度居然出奇地够用，当然重度用户可能就得看看付费套餐了。
那个没人告诉你的界面布局调整
默认情况下，Cody 会装在左侧的主侧边栏里——跟你的文件资源管理器（Explorer）挤在一起。前十分钟我就被这设计逼疯了。调试的时候，我通常会打开一堆文件，还要不停在 Explorer 面板里找实现代码。在 Explorer 和 Cody 之间来回切换，直接把我的工作流给打断了。
解决办法很简单：把 Cody 的图标拖到右侧的辅助侧边栏。在 VS Code 里，你可以通过 查看 > 外观 > 辅助侧边栏（View > Appearance > Secondary Side Bar）来打开它。把 Cody 放在右边，你就能左边看文件树，右边看聊天框，两不耽误。听起来是个小改动，但它从根本上提升了这工具的实用度。
自动补全：让人上瘾的入门功能
装好之后，你最先注意到的肯定是 Cody 的自动补全。你敲着代码，Cody 就会猜你接下来要干嘛——有时补全一行，有时直接生成一整块逻辑。
一开始我是持怀疑态度的。我也用过其他自动补全工具，感觉特别碍事，老是瞎建议我不想要的东西。但 Cody 的建议感觉不一样，主要是因为它结合了周围代码库的上下文，而不只是盯着当前文件。据说它的补全接受率高达 30%，说实话，跟我的体验差不多。大概有三分之一的时候，它给的建议正是我想要的。
我的建议是：别硬凑。如果建议不是你想要的，接着敲你的就行。Cody 适应得很快，不会跟你较劲。
聊天：Cody 真正大显身手的地方
自动补全固然好，但真正的杀手锏是聊天界面。在这里，Cody 对代码库的感知能力让它和普通的 AI 助手完全不是一个量级。
不用再把代码片段复制到浏览器标签页里去问了，我可以直接在 IDE 里提问：
@repo 为什么从 user service 调用 billing service 会返回 403？
这里的 @repo 命令是关键。它告诉 Cody 在回答前先去整个代码库里搜罗上下文。Cody 利用 Sourcegraph 底层的代码智能来构建他们所谓的“代码地图”——本质上就是你代码库的嵌入向量，让助手能根据上下文知道各种代码是怎么串联起来的。
对于本地项目，Cody 会动态构建这些嵌入向量。对于 Sourcegraph.com 上的开源代码库，嵌入向量是预先算好的，这意味着响应更快、更准。你可以去查哪些代码库启用了嵌入向量，甚至可以通过他们的 Discord 申请生成新的。
真正实用的日常工作流
用了 Cody 几周后，这些是我保留下来最常用的流程：
1. 熟悉代码库（Codebase Onboarding）
以前加入新项目时，我经常要花好几天看 README 和顺藤摸瓜找 import 链。现在我直接问 Cody：
@repo 给我大致讲讲鉴权流程。从哪开始的，中间有哪些主要检查点？
它的回答把跨四个文件的中间件链、token 验证和角色检查逻辑都梳理出来了。虽然不算完美——它漏掉了一个我们用于管理员路由的自定义装饰器——但它让我在五分钟而不是五小时内，就在脑子里建起了一个能用的心智模型。
2. 生成单元测试
选中一个函数，右键，让 Cody 生成测试。它会拉取类型，从上下文里理解依赖关系，然后生成像模像样的测试用例。通常能有 60-70% 的测试是直接能用的，剩下的我再微调。
3. 生成文档
我讨厌写文档。Cody 生成的文档虽说不完美，但作为初稿绝对够用。我选中一个模块，让它写 JSDoc 注释，然后再修改润色确保准确。
4. 带上下文的调试
这就是前面计费服务的场景。我不再瞎猜了，而是让 Cody 顺藤摸瓜查鉴权流程，找出到底在哪抛出的 403。它直接把我指向了一个我之前都不知道存在的中间件层，那玩意儿在检查一个已经废弃的 header。二十分钟，问题解决。
@ 命令是你最好的朋友
Cody 支持几个上下文命令，会改变它拉取信息的方式：
@repo—— 搜索整个代码库@file—— 聚焦当前文件@symbol—— 针对特定的函数或类
我一开始就犯了个错，光顾着敲问题，没指定上下文。结果回答全是套话，毫无用处。等我开始刻意使用 @repo 和 @file 后，回答的质量简直有了质的飞跃。
选择合适的模型
Cody 允许你选择底层使用的大模型。这比我想象的要重要得多。Claude 模型通常更擅长处理大上下文窗口——Cody 搭配 Claude Sonnet 最高支持 1M token 的上下文窗口。对于快速的自动补全，用个更轻快的小模型就够了；但对于复杂的代码库查询，你需要一个真能消化那么多上下文的模型。
我现在会根据任务切模型：自动补全和简单提问用快模型，深度挖掘代码库时用 Claude。
实话实说的局限性
Cody 不是魔法，有些真实的局限你必须心里有数：
跨代码库的上下文有限。 Cody 可以跨多个代码库检索上下文（最多 10 个），但这需要 Sourcegraph 企业版。如果你用的是免费版跑本地项目，那就只能局限在单代码库的上下文里。就拿我那个计费服务的问题来说，我不得不把那个共享库作为一个单独的工作区打开，然后再独立去问它。
嵌入向量生成不是瞬间的事。 对于本地代码库，Cody 需要构建嵌入向量，项目大的话挺耗时间。打开项目后的第一次查询可能会比较慢。
幻觉依然存在。 因为有真实的代码上下文，Cody 比普通 AI 助手更靠谱，但它依然会信誓旦旦地给你编造函数名或者瞎解释逻辑。一定要自己核实。
免费版每天 50 次查询的限制是硬性的。 在疯狂 debug 的日子里，我确实撞到过这个墙。虽然每天会重置，但你安排工作时得把这个因素考虑进去。
它不能代替你理解代码。 这话听起来像废话，但我真见过有开发者把 Cody 的回答当圣旨。它是个研究助手，不是神谕。它的回答只是起点，不是最终定论。
总结
Cody 已经在我的 VS Code 里稳占一个常驻位置了。它的杀手锏不是自动补全，甚至也不是聊天，而是对代码库的感知力。当你能问“这东西在哪用到了？”或者“这两块是怎么连起来的？”，并且得到一个基于真实代码而非训练数据的回答时，那是真管用。
话虽如此，你最好把它当成一个用来理解代码库的“强力工具”。如果你的主要需求就是生成模板代码或者问点通用编程问题，更便宜甚至免费的替代品完全够用。Cody 的核心价值就在于理解复杂的、已有的代码——就这一点而言，它目前是我用过的最好用的工具。
从免费版开始用，把 Cody 移到右侧边栏，刻意多用 @ 命令，并且永远对照真实代码核实它的回答。这套工作流，让我从一个怀疑论者变成了天天都离不开它的日常用户。