上下文工程与仓库感知¶

Context Engineering 已经从 Prompt 工程的附属技能，升级成 AI Coding 和 Agent 岗位的核心能力。

1. 为什么上下文工程是决定性能力¶

大型仓库里真正困难的不是“写一段代码”，而是：

• 找到相关文件
• 理解调用链
• 明白约束和规范
• 只把最有价值的信息提供给模型

上下文给得太少：

• 模型会瞎猜
• 会改错层
• 会编不存在的接口

上下文给得太多：

• token 爆炸
• 注意力稀释
• 重点丢失

所以本质问题不是“多给上下文”，而是“给对上下文”。

2. 仓库级上下文的 6 个来源¶

3. 典型策略¶

真正有效的上下文工程，不是把信息堆得更多，而是按任务类型选择合适的组织策略。

3.1 先导航，再读取¶

不要一上来读完整文件。更合理的顺序是：

1. 看目录树
2. 搜符号
3. 查引用关系
4. 再按行范围读取

这也是为什么现代 AI Coding 产品越来越强调：

• symbol search
• repo map
• file tree
• read by range

3.2 把“读取粒度”设计好¶

差的工具：

• 每次只能返回整个文件

好的工具：

• 支持按行范围读取
• 支持按符号读取
• 支持只拿定义、不拿实现
• 支持搜索后再精读

3.3 pinned context 与增量摘要并存¶

以下信息不应该被摘要掉：

• 用户原始目标
• 当前计划
• 已修改文件列表
• 关键报错
• 未完成事项

而中间过程则适合做增量摘要：

• 为什么放弃方案 A
• 某次搜索或阅读得到的中间结论
• 某轮尝试的失败原因

4. 一个可落地的上下文架构¶

第 0 层：系统规则
  - 安全边界
  - 编码规范
  - 禁止事项

第 1 层：任务锚点
  - 需求
  - 验收标准
  - 当前计划

第 2 层：仓库导航
  - 目录结构
  - 关键模块
  - 相关符号索引

第 3 层：工作记忆
  - 已读文件摘要
  - 已做改动
  - 当前阻塞点

第 4 层：即时检索
  - 当前步骤所需的源码片段
  - 测试输出
  - 命令结果

5. 面试里怎么讲¶

如果面试官问“中大型仓库不能全塞进上下文，怎么办”，一个比较稳的回答结构是：

1. 先承认不能暴力全塞。
2. 强调先让 agent 获得 导航能力 而不是一次性塞满内容。
3. 说明工具粒度决定 token 利用率。
4. 说明哪些信息需要 pinned，哪些适合摘要。
5. 说明如何做结果验证，防止改错仓库位置。

6. 项目交付时至少要展示什么¶

• 你怎么做 repo map
• 你怎么做文件/符号检索
• 你怎么做增量摘要
• 你怎么保留 pinned context
• 这些策略对成功率、token、延迟、错误率有什么影响

如果没有这些证据，你做的往往只是“能跑的 Demo”，不是面试里有说服力的系统。