上下文之战：我们在企业项目中实现 AI 编码的方式

Source: Dev.to

请提供您希望翻译的具体文本内容，我将为您翻译成简体中文并保留原始的 Markdown 格式、代码块和链接。

引言：一个无人解决的任务

想象一下：你需要让分析师具备编码能力。不是“给 ChatGPT 写提示”，而是实际上对一个拥有三年历史、百万行代码的企业产品进行更改。

开发者并没有坐在他们旁边口述每一行代码。他们搭建环境，控制质量，只有在出现问题时才介入。

听起来像科幻小说？我们也这么认为——直到我们尝试了。

为什么这比看起来更难

当程序员使用 AI 助手时，他们可以控制每一步。他们能看到底层发生了什么，并能立刻注意到代码中的异常。

而分析师的情况则完全不同。他们只能看到结果：“表单出现了”或“表单无法工作”。代码质量、架构决策、潜在的 bug——所有这些都隐藏在幕后。

我们决定创建一个能够弥补这种盲区的系统——一个即使 AI 真想“捣乱”也无法“造成麻烦”的系统。

Source: …

工具选择：为何选 Cursor

我们尝试了多种方案（GitHub Copilot、Claude Code、各种 API 包装器），最终因以下几个原因决定使用 Cursor。

多模型支持

Cursor 让我们可以针对不同任务使用不同模型：

flowchart LR
    A[Task] --> B{Type?}
    B -->|Planning| C[Claude Opus 4.5]
    B -->|Implementation| D[Gemini 3 Flash]
    C --> E[200K tokens]
    D --> F[1M tokens]

• Claude Opus 4.5 – 架构规划（智能但在 token 上“昂贵”）
• Gemini 3 Flash – 实现（快速、廉价，且最重要的是拥有 1 百万 token 的上下文）

MCP 集成

Model Context Protocol（MCP）是一种将外部工具与 AI 连接的方式。

灵活规则

Cursor 允许创建 .mdc 文件，其中的规则会根据上下文自动加载。
开发 React 组件 → 加载 React 规则。
编写脚本 → 加载 Node.js 规则。

安全要求：本地运行

我们的安全团队提出了严格要求：开发期间不能访问公司网络，也不能克隆生产数据库。
我们在 MSW（Mock Service Worker） 上构建了完整的模拟系统：

flowchart TD
    A[Frontend App] --> B[MSW Interceptor]
    B --> C{Request Type}
    C -->|API Call| D[Mock Handlers]
    C -->|Static| E[Pass‑Through]
    D --> F[Fake Data Generators]
    F --> G[@faker-js]
    D --> H[Response]

• 超过 50 条处理器，覆盖所有 API 端点
• 使用 @faker-js 的真实感数据生成器
• 完整的业务逻辑仿真

质量门：越严格越好

关键洞察： AI 需要严格的约束。没有这些约束，它会开始“创造”：看到过时的代码 → 重构；注意到潜在的漏洞 → “修复”；发现风格不匹配 → 重新格式化。
在实际操作中，像“向表单添加字段”这样简单的任务，可能会演变成包含 100 000 行代码的 PR。

我们的质量门流水线

flowchart TD
    A[Commit] --> B[commitlint]
    B -->|Pass| C[ESLint]
    B -->|Fail| X[❌ Rejected]
    C -->|Pass| D[TypeScript]
    C -->|Fail| X
    D -->|Pass| E[Vitest]
    D -->|Fail| X
    E -->|Pass| F[Secretlint]
    E -->|Fail| X
    F -->|Pass| G[✅ Push]
    F -->|Fail| X

如果代码未通过这些检查，提交将不会发生。

上下文问题：主要痛点

Context 是几乎让整个项目夭折的关键因素。

• 对于一个只有 10 个文件的简单应用，AI 能看到整个项目并完美运行。
• 对于一个拥有上百万行、三年历史的代码库，AI 只能看到其中的一小块——冰山一角。

在约 30 分钟后，AI 开始“遗忘”，重复错误，提出已经被否决的方案，并破坏刚刚正常运行的功能。

我们踩到的四个陷阱

陷阱 #1：“在简单示例上有效”

实验： 让分析师在一个干净的模板（最小化的 React 项目，参考规则，10 个文件）上创建注册表单。

结果： 15 分钟，一切完美运行。

在真实项目中执行同样任务： 什么都不工作。AI 被依赖关系搞糊涂，使用过时的模式，并与现有代码冲突。

教训： 这并不是 AI “笨”，而是缺乏上下文。

陷阱 #2：AI “修复”了整个项目

任务：添加一个功能。AI 完成了它 并且：

• 将所有 any 替换为具体类型
• “修复”了潜在的漏洞
• 重新格式化了项目的一半
• 更新了过时的依赖

结果：提交包含 100 000+ 行；GitLab 甚至无法显示差异。我们花了 两周 来理清它，产品也被破坏了。

教训： 用规则明确限定 AI 工作的范围。

陷阱 #3：令牌限制

我们最初没有意识到大多数模型的上下文窗口限制在约 100 K 令牌。当代码库超过这个规模时，模型看不到完整的全貌，导致上述问题。

陷阱 #4：对 AI 决策的过度依赖

我们让模型提出架构更改而不进行人工审查。模型的“优化”与长期的设计决策冲突，导致回归。

教训： 对任何高影响力的决策，都要让人类参与。

要点

1. 上下文为王。 对于大型代码库，将问题切分为定义明确、上下文受限的任务。
2. 严格的质量门 是不可谈判的；它们防止 AI 将未经检查的更改直接写入仓库。
3. 模型选择很重要。 使用廉价的高 token 模型进行实现，使用更强大（但更昂贵）的模型进行规划。
4. 安全优先的模拟 让你在本地开发时不暴露生产数据。
5. 人工监督 仍然是必不可少的，尤其是针对架构或安全关键的更改。

通过遵循这些原则，我们将本可能混乱的 AI 辅助工作流转变为可靠、可重复的流程，能够扩展到企业级代码库。

200K Tokens – Not Enough for Enterprise

• 对于企业项目，200 K 令牌只能支持 3‑5 次迭代。
• 超过此后，AI 开始“忘记”对话的开头，提出你已经拒绝的方案，并重复错误。

Lesson: 对于企业工作，你需要拥有 至少 1 百万令牌 的上下文容量的模型。

Rake #4 – 自动模式是陷阱

Cursor 可以自动选择模型。听起来很方便，但实际使用时它常常挑选 价格低廉且上下文窗口小的模型。

我们在意识到严肃工作需要 手动选择模型 之前，浪费了大量时间。

教训： 在规划时使用 Claude Opus，在实现时使用 Gemini Flash。 绝不要依赖自动模式。

我们如何解决上下文问题

在所有的“耙子”之后，我们构建了一个虽不完美但可用的系统。

双层任务跟踪

flowchart TD
    subgraph Jira [Jira – Team Level]
        J1[VP‑385: Add Registration Form]
    end

    subgraph Beads [Beads – Atomic Level]
        B1[bd‑1: Review UserForm.tsx]
        B2[bd‑2: Add email field]
        B3[bd‑3: Write test]
    end

    J1 --> B1
    B1 --> B2
    B2 --> B3

• Jira – 团队的顶层任务（例如 VP‑385: 添加注册表单）。
• Beads – AI 的原子任务：
  • bd‑1：审查文件 UserForm.tsx
  • bd‑2：添加邮箱字段
  • bd‑3：编写测试

Beads 本地存储并同步到 Git，AI 因此始终知道上一次停在了哪一步。

记忆库

为 AI 提供的“外部记忆”，用于存储：

• 当前上下文 – 我们正在处理的内容
• 进度 – 已完成的工作
• 研究 – 发现和参考资料
• 归档 – 已完成的任务

当 AI “忘记”某些内容时，它可以从记忆库中提取所需信息，恢复其理解。

模型组合

我们将工作分配给两个模型：

flowchart LR
    A[Task] --> B[Opus: Planning]
    B --> C[Opus: Spec / TZ]
    C --> D[Gemini: Implementation]
    D --> E[Opus: Review]
    E -->|Issues| D
    E -->|OK| F[Done]

循环： Opus 规划 → Gemini 实现 → Opus 评审。

项目统计（在 feature/msw-mocks 上工作 1.5 周）

已实现功能

• ✅ 完整的 MSW 模拟系统（50+ 处理程序）
• ✅ 带甘特图的时间线调度
• ✅ 质量门（ESLint、TypeScript、Husky）
• ✅ Beads 集成
• ✅ 200+ 单元测试

比较：传统开发 vs. AI 辅助开发

*包括基础设施搭建、学习曲线以及所有的“障碍”。

重要细节： 第一个功能成本高。 我们花了 1.5 周学习工作流、设置规则，并踩到障碍。后续功能的时间约为 ≈10× 更少。

角色演进

• 分析师 – 不再仅仅是“编写规格”。成为必须了解 SQL、使用 Git 并能在基础层面阅读代码的初级开发者。
• 开发者 – 不再仅仅是“编写代码”。成为专注于设计模式而非语言语法的架构师。AI 可以使用 Java、Node.js、Python、Go 等语言编写代码，因此开发者将成为通用专家。

结论与建议

有效之处

• Opus + Gemini 组合 – 智能架构师 + 快速执行者
• 质量门 – 更严格的约束 → 更好的结果
• 两级跟踪 – 团队使用 Jira，AI 使用 Beads
• 记忆库 – 外部记忆以避免丢失上下文
• 数据模拟 – 完全的开发自主性

无效之处

• 模型选择的自动模式
• 没有约束的 AI（它会“修复”整个项目）
• 对企业工作而言上下文窗口 < 1 M 令牌 的模型

入门检查清单

• 搭建本地开发环境
• 实施质量门（ESLint，严格的 TypeScript）
• 创建数据模拟系统
• 连接 MCP（Jira，Context7，记忆库）
• 对分析师进行 Git 和 SQL 培训
• 选择合适的模型（Opus + Gemini）

最终思考

对上下文的争夺尚未结束。上下文窗口不断扩大，但企业项目仍然太庞大，AI 无法完整看到。我们因此需要 帮助 AI 保持专注的系统：任务跟踪器、记忆库和质量门。

我们花费了 15 亿 token 来获得这些洞见。希望我们的经验能帮助你花费更少。

你在大型项目中使用 AI 编码的经验是什么？欢迎在评论中分享！

关于作者

从事 React UI 开发。工具：Cursor IDE、Claude Opus 4.5、Gemini 3 Flash。

标签: ai cursor enterprise programming devjournal