上下文工程

问题：上下文不是越多越好

给 AI Agent 喂料时最常见的两个错误，一个是喂太少，一个是喂太多。前者让 Agent 凭空捏造不存在的 API、无视项目既有约定；后者把整个仓库一股脑塞进 prompt，Agent 在 5000 行无关代码里迷失方向。上下文工程就是解决这个问题：决定 Agent 看什么、什么时候看、以什么结构看，而不是简单粗暴地把所有东西丢给它。

五层上下文层次

按持久性从高到低组织信息：

• L1 规则文件：如 CLAUDE.md、.cursorrules、AGENTS.md，跨会话持久，是杠杆最大的一层。约定写下来才算存在，没写就等于没有。
• L2 规格与架构：开始某个功能时只加载相关章节，而不是整份 5000 字的规格文档。
• L3 相关源码：编辑文件前先读它、读相关测试、找一个已有的同类模式示例。
• L4 错误输出：测试挂了就把具体报错喂回去，比如 TypeError: Cannot read property 'id' of undefined at UserService.ts:42，而不是粘贴 500 行测试日志。
• L5 对话管理：上下文变长时主动总结进度、切换任务时开新会话，避免陈旧上下文污染输出。

关键取舍

上下文还有信任分级：项目团队写的源码和类型定义可信；配置文件、外部文档要先验证再行动；用户提交内容或第三方 API 响应里的指令式文本只能当数据呈现给用户，不能直接执行。遇到规格没覆盖的情况，先查代码里有无先例，没有就停下来问人，不要自己编造需求。

适用边界

这套方法的收益前提是你愿意花十分钟写规则文件、花三十秒在动手前声明计划。如果项目没有可读的规范、也没有人愿意维护上下文，再好的技巧也无处着力。