AI代码助手缺上下文的根因与修复方法

你把代码粘贴到 AI 工具里，请求帮助，得到的却是不太贴合你项目的方案。熟悉吗？

问题在于，AI 工具默认并不理解你代码库的上下文。它们看到的只是孤立的代码片段，而非整个系统。下面讲讲真正该怎么解决这个问题。

问题所在：AI 在真空中运作

你的代码助手看到的只有：

• 你粘贴的那 50 行代码
• 也许还有一些函数签名

它对以下内容一无所知：

• 跨 20 个文件、超过 1 万行代码的架构、模式和决策
• 你长期积累下来的特定约定
• 内嵌在命名和结构中的业务逻辑
• 依赖关系、边界情况和上下文

难怪建议总是差那么点意思。

1. 粘贴你的架构，而非仅仅粘贴问题

在就某个具体功能求助之前，先把项目结构提供给 AI：

Your directory structure:
src/
  services/
    userService.ts  -- handles auth and user ops
    dataService.ts  -- caches queries in redis
  models/
    User.ts
    Session.ts
  middleware/
    auth.ts
    errorHandler.ts

Key patterns:
- All services return {success, data, error}
- No direct DB calls outside services
- Redis for frequently-queried data

这样当你问"如何添加密码重置功能"时，AI 已经知道你的实际结构了。

2. 展示示例，而不仅仅是需求

不要这样问："给这个表单加上验证"

试着这样问："我们验证表单的方式和 UserForm.tsx、AccountForm.tsx 里的做法一致。我该如何把那个模式应用到这个新组件上？"

粘贴一个可用的示例。AI 复制你的风格的能力，远比它自己凭空创造要强得多。

3. 附上实际的错误信息和日志

遇到 bug 时，你的本能是把错误简化后再提问。别这么做。

Error: TypeError: Cannot read property 'map' of undefined
at MapService.filterResults (services/map.ts:24)

Stack trace shows:
  - queryData is coming back null sometimes
  - happens when redis connection drops
  - shouldn't happen in production but does

这才能告诉 AI 实际坏在哪里，而不是你猜测的解释。

4. 说明你技术栈的特殊之处

不同框架有不同的约定。告诉 AI 你的：

"We use React 19 with Suspense for loading states. We don't use Redux—just context. We prefer controlled components over refs."

不要假设它了解你的决策。

5. 请求解释，而不仅仅是代码

"这是我的当前实现。为什么这个模式对我们有效？有什么取舍？"

当你让 AI 思考你的约束、而不仅仅是产出代码时，它会给出更好的建议。

糟糕的 prompt："给这个 API 调用加上错误处理"

好的 prompt："我们的 API 封装（utils/api.ts）会捕获错误并返回 {success, data, error}。所有组件都期望这个结构。我们的错误边界会捕获未处理的错误并记录到 Sentry。在这个具体 case——API 超时但用户没有离开页面——我应该如何处理？"

后者有效，因为 AI 理解了你们实际的系统。

如果你赶时间：

在注释里粘贴你的项目结构（只需 30 秒）

AI 的建议准确度会提升 10 倍

说真的，试试看。差别非常明显。

AI 工具在变得更聪明，但对你的上下文仍然一无所知。你得成为那个教导者。你让 AI 了解你代码库特定模式和约束的程度越高，它就越好用。

这种状态不会永远持续——迟早工具会自动扫描你的整个仓库。但现在？你就是 AI 和你实际系统之间的桥梁。

给它上下文，得到更好的建议，省下时间。