AI Code 企业落地问题：成本失控与无法持续记忆上下文及解决方案

企业内部落地 AI Code，往往会遇到两个问题：

一是 Token 消耗惊人，账单一路飙升；

二是 AI 记不住项目上下文，已达成共识的项目决策可能被遗忘，已修复的缺陷可能再次出现。

碧桂园的研发团队找到了解决方案：

月度 API 成本从 1,400 降至 166，降幅 88%；

上下文恢复时间从 12 分钟降至 30 秒，降幅 96%。

问题一：大模型消耗成本失控

钱花在哪里了？

研发团队对三个项目的 Token 消耗做了审计分析，发现五个主要痛点。

第一，输出 Token 是"隐形杀手"。

Claude 所有模型的输出 Token 价格均为输入的 5 倍。

比如 Opus 4.6：输入 5/MTok，输出 25/MTok。

很多开发者不了解这一定价结构，导致大量请求产生了冗长输出，成本被无形放大。

第二，上下文无限膨胀。

在多轮对话的开发场景中，上下文会随着对话轮次快速累积。

一个 20 轮的需求讨论可以轻松达到 50,000+ Token，其中 60-80% 是冗余的历史记录。

每一轮对话都在为之前的冗余内容"买单"。

第三，重复规范反复粘贴。

项目编码规范、技术栈约定、API 设计原则，这些静态内容在每次新会话时都需要手动粘贴注入。

以 800 Token 的编码规范为例，日均 4,000 次调用意味着每天白白消耗 320 万 Token 在重复内容上。

第四，全量数据一次性注入。

当 AI 需要理解数据库结构或查询业务数据时，传统做法是将 20,000+ Token 的数据一股脑塞入提示词。

实际上 AI 每次只需要其中 5% 的相关数据，95% 都是浪费。

第五，模型选择"一刀切"。

最初团队全部使用最昂贵的 Opus 4.6 模型。

但实际分析发现，70% 以上的任务属于结构化写作，中等模型 Sonnet 4.6 完全胜任，甚至简单分类任务 Haiku 4.5 就够了。

三个模型之间的价格差异巨大：

五层协同优化体系

定位到五大痛点后，研发团队设计了一套完整的优化体系：

Context（上下文）→ Rules（规则持久化）→ Skill（工作流封装）→ MCP（按需数据获取）→ Agent（自动编排）。

提示词压缩。

核心思路是用更少的 Token 传达相同的信息。

充电桩项目将 3,500 Token 的系统提示词压缩为 1,200 Token 的结构化格式，减少 66%。

优化前（286 Token）：

你是一个专业的客服人员。当用户向你提问时，你需要仔细分析用户的问题，然后提供详细、全面且准确的回答。请确保你的回答包含足够的细节……

优化后（97 Token）：

角色：客服人员
规则：准确简洁 | 不确定时如实说明 | 超出范围建议寻求专业帮助
格式：直接回答 + 后续建议

压缩技巧：删除填充词（"请你"、"你需要"）、使用结构化格式（YAML/键值对）替代自然语言段落、合并冗余指令、善用缩写。

Rules 持久化规范。

通过 CLAUDE.md 文件将项目规范、编码约定等信息持久化存储，每次会话自动加载，无需手动粘贴。

结合提示词缓存（读取成本仅为正常价格的 10%），静态规范的加载成本趋近于零。

充电桩项目将架构规范和代码风格指南写入 CLAUDE.md（约 1,500 Token），配合缓存，日均命中率 96%，读取成本仅为正常的 10%。

提示词缓存。

首次写入缓存多付 25%，此后 5 分钟内读取价格仅为正常价格的 10%。

对于高频调用场景，这是最具影响力的成本节省功能。

模型智能路由。

通过一个轻量级分类器（Haiku 4.5，每次约 $0.0003）分析请求复杂度，将任务路由到最合适的模型：

• • 简单任务（分类/格式化/路由，约 60%请求）→ Haiku 4.5
• • 中等任务（通用问答/内容摘要，约 30%请求）→ Sonnet 4.6
• • 复杂任务（架构设计/Agent 编排，约 10%请求）→ Opus 4.6

下载中心实践：70% 的 PRD 模板填充和用户故事格式化路由到 Sonnet 4.6，仅 30% 的复杂需求分析保留 Opus 4.6，整体成本降低 70%+。

Skill 封装。

将特定任务的提示词、工作流和最佳实践封装为可复用模块。

一条触发指令替代上千 Token 的详细提示词。

下载中心将"PRD 生成"和"用户故事拆分"封装为 Skill，触发指令仅 200 Token，替代手写 1,500 Token 的详细提示词。

MCP 按需获取。

通过标准协议连接外部数据源，让 AI 按需查询而非全量加载。

消息中心通过 MCP 按需读取待测源码文件（800 Token），替代注入完整代码库（50,000 Token），输入 Token 减少 90%+。

Agent 自动编排。

自动加载 Rules、调用 Skill、通过 MCP 获取数据，并将复杂任务拆分为多个子任务——每个子任务仅携带最小必要 Context。

下载中心一个预估 80,000+ Token 的"新增管理员模块"需求，Agent 拆分为 4 个子任务，每个仅需 3,000-5,000 Token 上下文，实际总消耗约 18,000 Token，Context 压缩 78%。

输出约束与批处理。

使用 max_tokens 参数设置上限（分类任务设为 10-50）；要求 JSON 格式输出（比自然语言短 40-60%）。

非实时任务使用 Message Batches API，享受标准价格 50% 折扣。

三个项目的实战数据

充电桩平台架构重构。 日均约 4,000 次 API 调用，最初全部使用 Opus 4.6，月度 API 费用约 $650。

优化措施：

• • 80% 的任务降级到 Sonnet 4.6
• • 系统提示词从 3,500 Token 压缩为 1,200 Token（↓66%）
• • 架构规范写入 CLAUDE.md + 缓存命中率 96%
• • "架构分析"和"需求文档生成"封装为 Skill + 输出约束

结果：月度成本 650 → 57，降幅 91%。

下载中心需求开发。 日均约 10,000 次调用，月度费用约 $300。

优化措施：

• • 智能路由（70% Sonnet + 30% Opus）
• • 提示词从 3,200 Token 压缩为 1,100 Token
• • 需求迭代对话采用摘要+最近 3 轮（上下文从 8K 降至 2.5K）
• • "PRD 生成"封装为 Skill + Rules 缓存命中率 94%

结果：月度成本 300 → 33，降幅 89%。

消息中心技术开发。 日均约 7,500 次调用，月度费用约 $450。

优化措施：

• • 代码补全（67%）→ Sonnet 4.6 实时
• • 测试用例（33%）→ Sonnet 4.6 批处理（↓50%）
• • 项目规范写入 CLAUDE.md + 缓存命中率 97%
• • 通过 MCP 按需读取源码替代全量注入

结果：月度成本 450 → 76.5，降幅 83%。

测试覆盖率从 45% 提升至 82%。

三项目汇总：

问题二：上下文增长，如何让 AI 记住项目？

问题出在哪里？

当前最先进的大语言模型，其上下文窗口能力与实际项目规模之间存在巨大鸿沟：

即使是 1M 上下文窗口，面对 50 万行的大型项目也仅覆盖 12%。

更关键的是，将大量代码一股脑塞入上下文不仅昂贵，而且模型对超长上下文中间部分的注意力会显著衰减。

传统模式：会话级记忆断裂。

每次开启新会话，AI 都需要重新理解整个项目。

开发者打开新会话 → 粘贴相关代码 → AI 花费大量 Token 理解结构 → 完成一小部分任务 → Token 耗尽 → 下次会话重复以上步骤。

量化损失：每次新会话重新理解项目消耗 5-15 分钟 + 2000-8000 tokens。

假设一个项目需要 100 次会话迭代，仅"重新理解"就浪费 8-25 小时 + 20 万-80 万 tokens。

摘要模式：压缩导致的幻觉累积。

部分工具尝试通过日志压缩来延续上下文。但有损压缩带来的信息衰减是指数级的：

关键信息丢失的后果：

架构决策原因丢失导致重复讨论已否决方案，

已修复的 bug 信息丢失导致重复引入旧 bug，

数据模型关联关系丢失导致外键/索引设计错误。

三层架构方案

研发团队从操作系统虚拟内存机制中获得灵感，构建了三层架构。

第一层：持久化存储（磁盘层）。 将所有工程知识以结构化方式序列化到磁盘文件中，实现零信息丢失。

关键设计原则：结构化（按类型分文件、按层级组织）、可索引（明确分类和命名规范）、版本化（纳入 Git 管理，支持回溯和 diff）。

参考目录结构：在项目根目录创建 .ai-memory/ 目录，包含 project.yaml（项目概况）、architecture.md（架构决策）、data-models/（数据模型）、api-specs/（接口定义）、decisions/（技术决策）、tasks/（任务追踪）、modes/（编程模式配置）等。

第二层：上下文交换（调度层）。 核心引擎，负责决定"什么时候加载什么记忆到上下文窗口"。

调度策略包括三个维度：

• • 任务亲和性加载：
• 根据当前任务类型，预判需要哪些工程记忆。例如"实现用户注册 API"时，自动加载 project.yaml + user.yaml + auth.yaml + 编码规范，不加载前端相关文件
• • LRU 淘汰策略：
• 上下文窗口使用率 >80% 时触发淘汰，优先保留当前任务直接相关的代码和接口，优先淘汰已完成的任务记录
• • 增量分层加载：第一优先级（必须）项目概况+任务描述 2K tokens → 第二优先级（按需）数据模型+接口 5K → 第三优先级（延迟）规范+决策 3K → 第四优先级（可选）历史记录 2K

第三层：活跃上下文（内存层）。

大语言模型的 Token 窗口，是唯一能被 AI"看到"和"思考"的空间。

Token 分配参考（以 200K 窗口为例）：

编程状态机与任务追踪

不同类型的编程任务需要截然不同的知识上下文。

为此，在工程记忆架构之上，叠加了编程状态机和原子化任务追踪两项机制。

编程状态机。 按任务类型切换 AI 的"工作模式"，每种模式加载差异化的上下文：

模式切换效率：传统方式（新开会话）需要 5-15 分钟重建上下文；工程记忆方式（模式切换）仅需 2-5 秒加载预定义配置。

原子化任务追踪。

每个需求被分解为原子任务，每个任务有独立的状态追踪。

任务记录包含：任务 ID、标题、状态、所属模式、涉及文件列表（已修改/待编写）、依赖关系、进度检查项、上下文备注、下次加载所需文件列表等。

这样下次 AI 加载这个任务时，能精确知道：

任务做到哪一步了、哪些文件已经改过了、下一步应该做什么、需要加载哪些相关文件——实现了真正的"断点续编"。

八步工作流闭环

将上述各组件串联，形成一个完整的、可循环的开发工作流。

每次迭代都遵循相同的八个步骤，确保每次操作可验证、可恢复。

1. 1. 加载工程记忆： 读取 project.yaml（项目全貌）+ coding-standards.md（代码规范）+ 当前模式配置
3. 2. 读取任务状态： 读取 in-progress.yaml → 找到当前任务 → 解析进度列表 → 确定下一步
5. 3. 加载相关文件： 按任务的 context_files 列表加载源码 + 相关数据模型 + 接口定义
7. 4. 编写代码： 根据任务描述和上下文编写代码，遵循已加载的编码规范，保持与已有代码一致
9. 5. 单元测试： 编写并运行测试，通过→步骤6，失败→分析错误→回步骤4修改
11. 6. Git提交： git commit -m "[TASK-ID] 任务描述 - 完成状态"
13. 7. 标记完成： 更新任务状态至 completed，记录关键决策到 decisions/ 目录
15. 8. 清空上下文： 保存所有状态到磁盘 → 清空当前上下文窗口 → 准备加载下一个任务（回到步骤1）

核心指标对比

基于多个中型项目、每个项目 20+ 任务的模拟实验，三种模式对比：

长期项目效率衰减对比：

关键发现：传统模式和摘要模式的效率随项目规模增长急剧下降，而工程记忆模式几乎保持恒定。

这正是因为工程记忆模式的上下文恢复成本是 O(1) 的——无论项目多大，每次只加载当前任务需要的记忆片段。

如何落地？

分阶段实施路线

多策略叠加效果呈乘法关系——单独节省 50% 的两个策略组合可节省 75%。

最小可行实现

不需要复杂的工具链，只需在项目根目录创建 .ai-memory/ 目录，分三步完成初始化：

第一步：初始化项目记忆。 让 AI 分析当前项目结构，生成 .ai-memory/project.yaml，包含项目名称、技术栈、模块划分、核心业务流程。

第二步：定义编程模式。 在 .ai-memory/modes/ 下创建各模式配置文件（如 backend-java.yaml），定义框架、ORM、编码约定、测试框架。

第三步：每次会话开头加载。 提示 AI 读取 project.yaml 和 tasks/in-progress.yaml，继续未完成的任务。

与现有工具集成

总结

成本控制的核心不是省钱，而是让每一分钱都花在刀刃上：用更少的 Token 做更多的事。

上下文管理的核心不是让 AI "记住"所有东西，而是让它在需要时能"找到"所有东西。

对 AI Code 落地感兴趣的话，还可以参考之前的文章。

介绍业内顶尖企业怎么让给AI 编程创造一个合适的框架：

AI 不是在抢我的工作：Harness 正在重构软件工程｜让 Agent 完成任何复杂任务

你在落地 AI Code 时，遇到什么问题？

欢迎评论区留言。

-END-