AOCI：用代码库压缩索引解决大模型上下文不足，提升大型项目开发效果

视频先用一个比喻说明大模型的上下文瓶颈：把 100 万 token 上下文打印出来只是一叠纸，而 Deepseek Harness 的 35 万行源码约有 500 万 token，能“撑爆”大模型 5 次；Chrome 这类四千万行工业级项目约 5 亿 token，大模型视野连一扇窗户都覆盖不了。于是 AI 开发大型项目时容易局部盲人摸象、只见树木不见森林，改出大量 bug。 作者推荐开源项目 AOCI，因 logo 像草花而称“草花”。其原理是：开发前用大模型对代码库做一次预处理，压缩成高度浓缩的信息，对象不只代码，也包括数据库；之后 AI 可通过这份压缩信息随时了解代码仓库。作者在 Deepseek Harness 二次开发中，让 AI 安装 AOCI 的 MCP 后对部分模块建立索引，AI 选出 427 个核心文件，接近 9 万行代码，约 130 万 token，压缩后约 7.1 万 token，体积缩减 94.5%。压缩文件是高度结构化格式，相当于给 AI 的“代码地图”。 视频解释了一个示例：原始仓库中的 ApprovalPanel.tsx 被压缩后，先有文件名，再有标签 EU7T。标签各字符有含义，第二个字符标记所属模块，U 表示用户交互模块；第三个字符表示重要程度，7 为高重要度；第四个字符表示文件大小，T 表示很小、不到 100 行。后面还有 f、r、a、s 四个重要部分：f 讲文件负责什么，r 讲与其他文件的关联，a 讲对外提供的接口和能力。这样能用最少 token 看清项目架构。 实战对比中，作者把同一个开发需求分别发给使用 AOCI 的仓库和普通仓库，均使用 GPT 1.6，先做开发计划。普通组消耗 602 万 token，AOCI 组消耗 313 万 token，省下近一半。普通组缺少全局地图，会反复抓取大段无关代码来建立基本理解，新建 session 后还要重复；AOCI 补上地图，更快建立全局理解并找到目标代码。代码修改后索引不会全部重读，而是根据 SHA-256 指纹，对修改过的文件重新建立索引。 交付对比显示，两边核心功能都实现，但 AOCI 组改了 80 多个文件，普通组只改了 40 个。差异包括：普通版设置面板字体颜色不对，写了很多看似工整的 CSS 变量，但项目根本没定义过，说明不了解色彩配置规范，存在幻觉；AOCI 组准确调用项目真实存在的主题变量。普通版还直接使用 HTML 原生 button，而没有使用项目通用 button 组件。AOCI 组修改跨越更多模块，覆盖更多细节，甚至同步更新多个文档，并修改了 Deepseek Harness 的 Creative 模式配置文件，让 AI 能自己发现新加功能，实现自己改自己。作者形容 AOCI 组像资深老员工，普通组像第一天干活的新同事。 最后，视频把 AOCI 类比为 TypeScript 用类型定义规范模块调用、Git 规范协作版本，认为它想成为 AI 时代软件仓库的标准契约。一旦这种协议在开发者生态普及，可能撬动新型开发流水线，让 AI coding 告别玩具阶段，迎来工业化大爆发。