上个月，我正埋头于一个庞大臃肿的企业级代码库中，试图跨六个不同的微服务追踪一个 Bug。就在那时，我发现我的 AI 编程助手简直是个摆设。每当问它关于我们内部身份验证中间件的问题，它都会极其自信地瞎编一些通用的 Express.js 模式，跟我们实际的代码实现八竿子打不着。问题根本不在于模型不行——而在于上下文。这工具压根就不了解我的代码。
正是这种抓狂的经历，让我用上了 Sourcegraph 的 Cody。其他 AI 助手把你的项目当成一张白纸，Cody 则不同，它的核心理念是：上下文就是一切。在开始生成回答之前，它会先利用 Sourcegraph 的代码搜索和智能平台，真正去理解你的代码库。经过几周的摸索和将其融入我的日常工作流，以下是我总结的如何真正把它的作用发挥到最大的经验。
配置：让 Cody 跑起来
首先，得说说那个避不开的问题：Cody 最近转向了纯企业版模式。如果你的公司正在使用 Sourcegraph，你可以通过你们公司的实例来连接。如果你是在搞开源代码，依然可以通过 Sourcegraph.com 使用免费账户来用 Cody。
假设你已经有权限了，那配置过程非常简单。我用的是 VS Code，所以直接从插件市场装了 Cody 插件。按下 Ctrl+P，粘贴 ext install sourcegraph.cody-ai，然后安装就行。装好后需要登录认证。如果你连接的是企业版 Sourcegraph 实例，需要把地址指向你们公司的 URL 并在那里认证；如果用的是 Sourcegraph.com，直接用账号登录即可。
把它连上公司 Sourcegraph 实例的那一刻，我就感觉不一样了。Cody 瞬间就能访问我们整个单体仓库（monorepo）——横跨几十个服务的成千上万个文件。这就是它的“上下文引擎”开始发力的时候了。
Cody 是如何真正读懂你的代码的
这部分确实惊艳到我了。Cody 并不是简单粗暴地把你整个代码库全塞进提示词里——那样既不可能，成本也高得离谱。相反，它采用了一种多层机制来获取最合适的上下文。
向量嵌入（Embeddings）： 对于已经建好索引的仓库，Cody 会创建向量嵌入——也就是你代码的向量化表示。这让它能在整个代码库中进行语义搜索。当你提问时，它搜索的是相关的代码块，而不仅仅是匹配关键词。我问 Cody：“我们在哪里验证 Stripe 的 Webhook 签名？”它直接找出了我们支付服务里那个精准的工具文件，尽管那个函数叫 verifyIncomingRequest，而不是什么“webhook validation”。
本地上下文： 当你在 VS Code 里写代码时，Cody 还会看你当前打开的文件、最近的编辑，以及你周围的文件结构。这对自动补全功能至关重要，这个我后面会细说。
Sourcegraph 搜索： 对于企业版用户，Cody 可以利用 Sourcegraph 的代码搜索功能，在整个组织的代码中查找特定的模式、引用和定义。这正是它在大型代码库中如此致命有效的原因。
核心要点在于：Cody 会根据你的问题，动态组合这些上下文来源。如果是泛泛的问题，可能需要的上下文就少；如果是具体的“我们的代码库是如何处理 X 的”这种问题，就会触发更深度的搜索。
真正改变我工作流的三大功能
1. 智能体聊天（Agentic Chat）：不仅仅是问答
Cody 的聊天功能绝不仅仅是大语言模型（LLM）外面套了层壳。它具备 Sourcegraph 所说的“意图识别”能力——它能搞清楚你是在问常识性问题、在找代码，还是需要执行一个多步骤的操作。
举个真实的例子。我之前在排查为什么我们的后台任务队列会无声无息地丢任务。我打开聊天框输入：
为什么我们的任务队列会丢任务？看一下 worker 的实现和错误处理。
Cody 并没有给我那种“任务失败的常见原因如下”的套话回答，而是搜索了我们的代码库，找到了队列服务里的 worker 文件，发现我们虽然捕获了异常，但没有把失败的任务重新放回队列，并直接把问题定位到了那个具体的 try/catch 代码块。它甚至把周围的代码也展示出来给我提供上下文。
这要是换我自己用 grep 翻，起码得花 30 分钟。Cody 大概 10 秒就搞定了。
2. 自动编辑（Auto-edit）：不再烦人的自动补全
我之前被 AI 自动补全坑怕了——太激进、错得太离谱、还慢。但 Cody 的自动编辑让我刮目相看。它可以补全单行代码，也能补全整个函数，而且因为它有代码库的上下文，它的建议真的会遵循你项目里的代码模式。
当时我正在我们的 Express 应用里写一个新的 API 端点。我刚敲完路由定义和处理函数的第一行，Cody 就把剩下的都补全了：参数校验用的是我们自定义的校验库（而不是什么通用库），错误处理跟我们标准的模式一模一样，甚至连响应格式也是对的。它之所以知道我们的惯例，是因为它在其他文件里见过。
3. 命令与提示词（Commands and Prompts）：高阶玩法
Cody 自带了一些内置命令，本质上就是针对特定任务优化好的预置提示词。在 VS Code 里，你可以通过命令面板或快捷键来调用它们：
/explain— 解释选中的代码/test— 为选中的代码生成单元测试/doc— 生成文档/fix— 针对 Bug 或问题提供修复建议
/test 命令对我来说绝对是个神器。我选中一个函数，运行命令，Cody 就会用我们实际在用的测试框架和工具来生成测试——而不是套什么通用的 Jest 模板。它会从正确的路径导入，使用我们自定义的测试辅助函数，并且遵循我们的命名规范。
你还可以创建自定义提示词，把它们存到提示词库（Prompt Library）里。我为我们团队建了一个叫“Add OpenTelemetry Span”的提示词，选中一个函数后，它会自动用我们特定的链路追踪设置把函数包裹起来。现在团队里任何人点一下就能用。
踩过的坑和意外发现
关于 Cody 让人失望的地方，我也得实话实说。
冷启动问题： 刚装上的时候，我指望它能立刻大显神威。但 Cody 需要先对我们的仓库建索引。对于大型代码库，生成向量嵌入是需要时间的。我们的单体仓库花了几个小时才彻底索引完。在那段空窗期，Cody 的回答明显不够精准。
上下文窗口依然有上限： 即使上下文抓取机制再聪明，有时候 Cody 拉取的相关代码就是不够。有次我问了一个涉及七个文件的复杂数据流问题，Cody 只挑出了其中三个。我只好手动把另外几个文件打开，这样它们才能被算进本地上下文里。
它不会读心术： 如果你的问题很模糊，Cody 的上下文检索也会犯迷糊。我问“身份验证是怎么工作的？”，得到的就是个皮毛概述。但当我问“API 网关里的 JWT 校验中间件，是如何验证由我们的 auth 服务颁发的 token 的？”，我就得到了一个精准且有代码支撑的回答。提问的具体程度至关重要。
几周后总结的实用建议
提问前先打开相关文件。 Cody 会把你打开的标签页作为上下文信号。如果你在排查某个具体模块，先把那些文件打开。
善用
@提及功能。 在聊天时，你可以用@来引用特定的文件或符号，强制 Cody 把它们纳入上下文。当你明确知道答案应该从哪来的时候，这招简直 invaluable（无价）。不断迭代你的问题。 别指望一次就能得到完美答案。先问得宽泛点，看看 Cody 找出什么，然后再细化。比如从“展示一下支付处理的代码” → “在 processPayment.js 里，当 Stripe API 调用失败时会发生什么？”
创建团队提示词。 提示词库绝不仅是个锦上添花的摆设。和你的团队坐下来，找出那些重复性的工作，为它们定制提示词。我们现在有了专门用于添加新 API 端点、创建数据库迁移和写集成测试的提示词。这种一致性带来的回报是巨大的。
信任之前先验证。 有时候 Cody 会极其自信地引用已经被废弃或替换的代码。一定要点进去看看真实的源码。它是个领航员，不是神谕。
客观评价
Cody 最大的优势，同时也是它最大的局限：它的表现完全取决于你们 Sourcegraph 的配置水平。如果你的组织没有用 Sourcegraph 给代码库建索引，你就会失去让 Cody 与众不同的深度上下文。而且最近转向纯企业版模式，意味着那些做私有业余项目的独立开发者基本没戏了。
但对于已经在用 Sourcegraph、或者愿意为之投入的团队来说，Cody 是我用过的上下文感知能力最强的编程助手。它不只是写代码；它写的是你的代码，遵循的是你的模式，引用的是你真实的实现。这就是“帮你省几次敲键盘的力气”和“真正帮你理解和驾驭复杂系统”之间的天壤之别。