交付团队 AI 提效降本课题一：底座是上下文工程

前言

很多团队推进 AI 提效时，第一反应都是先上模型、先接工具、先做几个演示场景。

但真正进入交付现场之后，我越来越确定一件事：

对于一个承接存量系统、团队成员背景复杂、业务理解不统一的项目组来说，AI 能不能产生稳定价值，关键不在模型本身，而在上下文工程有没有先做起来。

如果没有上下文底座，AI 看见的只是一堆零散代码、局部文档和碎片化对话。它也许能写出一些“像样”的内容，但很难真正理解这个系统为什么这样设计、哪些规则不能碰、哪些改动会牵一发动全身。

所以，这个课题我想先从底座说起。

背景：交付团队真正缺的，往往不是人手，而是统一上下文

这次团队的起点很典型：

• 从集团公司协调五湖四海的成员临时组队
• 承接上家厂商已经建设三年的项目
• 新成员对业务不熟，对技术也不熟
• 团队整体水平参差不齐
• 交接过来的源码工程存在文档缺失、核心包源码缺失、部分能力黑盒等问题

这种情况下，项目最稀缺的资源并不是某个单点技术高手，而是大家是否站在同一个上下文里工作。

没有这层统一上下文，AI 很容易沦为一个局部提效工具：有人拿它补代码，有人拿它查接口，有人拿它写文档，但生成结果彼此口径不一、深浅不一，最终很难形成团队级复用。

而所谓“底座”，本质上就是把这些原本只存在于少数人脑子里的背景、规则、边界和结构，变成团队与 AI 都能持续复用的上下文资产。

为什么我把它叫做“上下文工程”

我现在越来越不愿意把这件事简单叫成“补文档”。

因为文档只是结果形式，上下文工程才是更准确的描述。它强调的不是“写了多少材料”，而是有没有把 AI 真正需要的理解条件搭起来。

AI 真正依赖的，从来都不只是代码本身，而是代码背后的这些信息：

• 业务规则是什么
• 状态边界在哪里
• 领域术语如何统一
• 为什么当前架构是这样设计的
• 如果要改某个功能，应该从哪里下手，风险会扩散到哪里

这些信息如果只存在于核心成员的经验里，AI 就无法利用，新成员也无法快速继承。而一旦把它们系统化，AI 的首稿质量、问答准确率和改动建议的可用性，都会明显提升。

所以我理解的上下文工程，不是“给 AI 喂点资料”，而是持续建设一套能被团队共享、能被 AI 消化、还能反过来支撑交付协作的认知底座。

第一层底座：把项目知识沉淀成团队可复用的 Skill

在交付场景里，我认为第一层底座不是让 AI 直接对着整个仓库盲读，而是先把关键模块的认知结果封装成可复用的技能。

这里我采用的是：

• Claude Code + 私有化部署 minimax 2.5
• Deep Code Reader

Deep Code Reader 解决的不是“帮我总结一下代码”，而是把代码仓库转化为经过验证的 AI 认知型 skill。它不是普通摘要，也不是简单 RAG，而是让 AI 对某个模块形成足够稳定、可验证、可复用的理解。

更具体地说，它产出的不是一段解释文字，而是经过验证的认知技能：AI 在加载这些 skill 之后，可以更像一个真正读过该模块源码的人来工作。

扫描仓库 -> 识别模块和依赖关系 -> 选择要精读的模块
                                  |
                                  v
                        逐模块精读源码 -> 生成 skill
                                  |
                                  v
                       闭卷考试验证（ABC 循环）
                                  |
                                  v
     Agent B（读代码，不看 skill）出考题 + 标准答案
     Agent C（看 skill，不读代码）闭卷答题
                                  |
                                  v
             通过 -> 下一模块；不通过 -> 改进 skill -> 重考
                                  |
                                  v
                     生成全局索引 + 问答验收

这个闭环很关键。因为在交付项目里，最怕的不是“没生成”，而是“生成了但不准”。只有把 skill 做成可验证资产，它才配得上成为团队底座的一部分。

一个模块级 Skill，我更关注这 5 个维度

这 5 个维度的价值在于，它们覆盖了“理解”和“动手”两个阶段。新人可以据此快速建立认识，AI 也可以据此给出更靠谱的问答、分析和改动建议。

Skill 生成与验证过程

Deep Code Reader 生成 Skill 过程截图 1

Deep Code Reader 生成 Skill 过程截图 2

Deep Code Reader 生成 Skill 过程截图 3

Deep Code Reader 生成 Skill 过程截图 4

Deep Code Reader 生成 Skill 过程截图 5

Deep Code Reader 生成 Skill 过程截图 6

Deep Code Reader 生成 Skill 过程截图 7

技术团队全局使用

Skill 在技术团队中的全局使用方式

第二层底座：把大型代码库整理成团队共享的 Wiki

如果说 skill 更适合承载模块级深度理解，那么在大型项目里，还需要另一层底座来解决全局认知问题。

因为面对一个体量较大的存量系统，真正困难的往往不是“看不懂某个函数”，而是：

• 不知道整个系统由哪些部分组成
• 不知道应该先读哪里，再读哪里
• 不知道业务链路和代码结构之间怎么映射
• 不知道问 AI 的时候，应该给它什么范围的上下文

所以，除了模块级 skill，我还需要一套结构化 Wiki 去承接全局视角。

这一层我采用的是：

• Zread + 私有化部署 minimax 2.5

Zread 是一个命令行工具，它会用 AI 自动分析代码仓库，生成结构化 Wiki，并提供内置阅读器，方便团队随时查阅。

它对交付团队很有价值的一点是：先帮我们把“目录感”和“章节感”建立起来，再进入具体细节。这样一来，团队阅读代码的方式就不再是到处跳文件，而是先获得结构，再进入局部。

对我来说，这一层底座至少解决了三件事：

• 先生成结构化文档，再进入细节
• 把“读代码”变成稳定流程，而不是临时发挥
• 为后续 AI 问答和新人上手提供清晰上下文

它的核心流程可以概括成一个两阶段 ReAct 智能体流水线：

第一阶段：目录智能体（Catalog Agent）
读取项目结构 -> 生成结构化目录（章节 + 页面列表，JSON）

第二阶段：页面智能体（并发执行）
每个页面独立运行一个智能体：
1. 通过工具读取相关源文件
2. 将内容综合为 Markdown
3. 保存至 .zread/wiki/

Zread 为大型代码库生成结构化 Wiki

上下文工程真正要做的，是把业务视角和技术视角对齐

无论是 skill 还是 Wiki，如果最后只覆盖技术实现，它的价值都只完成了一半。

因为项目交付里的大量问题，本质上并不是“代码不会写”，而是业务口径不统一、状态定义不一致、异常场景没人说清楚。这也是为什么我会特别强调：上下文底座必须同时覆盖业务和技术两个面向。

两者之间还需要一层共享术语表去打通，确保 AI 在生成设计、代码、测试和说明文档时，业务概念与技术实现使用的是同一套语义。

这件事不能只靠研发单方面整理。业务负责人和产品经理同样需要参与维护业务流程、状态口径、例外场景和验收标准。否则，技术团队即使把代码读得再透，AI 生成的结果也还是可能在业务逻辑层面偏掉。

组合使用后，AI 才会真正变成团队能力放大器

当 Claude Code + Skills + Wiki 组合起来之后，我更愿意把它理解成一套“新人入门开发手册 + 团队协作中枢”。

这时候 AI 的作用才不只是“写一点代码”，而是开始承担更完整的协作角色：

• 帮新人快速进入项目上下文
• 帮老成员减少重复讲解成本
• 帮团队在改动前先看清依赖、边界和风险
• 帮知识传递从“口口相传”变成“资产沉淀”

最终提升的，不只是某个工程师的编码速度，而是整个交付团队对复杂存量系统的理解效率、协作效率和交接效率。

上下文底座组合使用后的团队工作流 1

上下文底座组合使用后的团队工作流 2

写在最后

我现在越来越相信，在交付团队里做 AI 提效，真正应该优先建设的，不是“让模型先干活”，而是“让模型先站到正确的上下文里”。

上下文工程做得越扎实，AI 就越像团队里的有效成员；上下文工程越薄弱，AI 就越容易停留在演示层面。

所以这篇把它定义为“底座”，不是修辞，而是判断。因为只有先把底座搭起来，后面的代码生成、需求分析、测试辅助、问题排查，才有可能真正稳定地产生收益。

下一篇，我会继续验证：Claude + 私有化模型 在存量项目复杂业务逻辑处理中的实际能力，到底能走到哪一步。

附录

• Deep Code Reader
• Zread CLI