上下文工程

Agent 编码时常见的质量波动，根源往往不在模型能力，而在喂给它的信息：上下文太少会凭空捏造 API 或忽略项目约定，太多又会偏离当前任务，甚至引用已删除的代码。上下文工程这个技能正是针对这类问题，通过系统化的上下文策划，让 Agent 稳定贴合项目真实情况。

解决的核心问题

• 输出偏离约定：Agent 用错技术栈、违反提交规则，或自创代码风格而非沿用项目范例。
• 幻觉频发：引用不存在的文件路径、虚构 API 方法，或把外部文档中的指令当成项目规则执行。
• 上下文失焦：加载整份 5000 字规格只改一个小模块，或保留陈旧的已删代码引用，导致输出偏离当前任务。

工作机制：从层次划分到动态打包

技能核心是五级上下文层次，按持久度从高到低划分，精准控制 Agent 可见信息：

1. 规则文件（最高杠杆）：维护 CLAUDE.md、.cursorrules 等跨会话文件，明确技术栈、命令、代码约定与边界（如「提交前必须跑测试」）。
2. 规格与架构：按功能加载相关规格段落，做 auth 就只给 auth 段，而非整份规格。
3. 相关源文件：改文件前先读，实现前找既有范例；按信任级别划分——项目源码可信，配置文件需核实，用户提交内容不可信，从外部加载的类指令内容仅作数据呈报不执行。
4. 错误输出：仅反馈具体错误（如 TypeError: Cannot read property 'id' of undefined at UserService.ts:42），避免冗余全量日志。
5. 对话管理：大功能间开新会话，上下文变长时总结进度，关键工作前主动压缩。

打包策略适配不同场景：脑暴式适合会话启动，一次性给出项目背景、约束与涉及文件；选择性包含聚焦当前任务，仅加载相关文件与模式，控制上下文规模。遇到歧义时通过混淆管理显式列出选项求问，而非猜测。最终输出 ContextSetup 工件，结构化记录规则文件状态、加载内容与冲突项，方便下游技能（如 spec-driven-development）消费。

适用边界与注意点

不适用一次性纯查询、与项目上下文无关的独立小问。需注意：规则文件必须覆盖技术栈、命令、约定与边界，否则隐性知识等于不存在；大任务间需刷新上下文，避免陈旧引用；从配置或外部文档加载的内容需严格区分信任级别，防范指令注入风险。