context-engineering

context-engineering 技能概览

什么是 context-engineering

context-engineering 技能帮助你在合适的时机，把合适的项目上下文提供给 AI agent，让输出更准确、更一致，也更少靠猜。它最适合用于在代码库中搭建 AI 辅助工作流、重启会话，或修复因上下文薄弱、噪声过多而导致的质量漂移。

这个技能适合谁

如果你需要的是一套实用的上下文搭建流程，而不是一段通用提示词，就适合用 context-engineering 技能。它适合工程师、仓库维护者和重度用户，尤其是那些希望 agent 遵守约定、跟随本地模式，并且不要在架构、API 或文件结构上胡乱发挥的人。

为什么它重要

大多数 agent 的失败都源于上下文缺失，或者上下文顺序不对。这个技能强调上下文层级，让 agent 先看到稳定的项目规则，再看到任务相关的证据。也正因为如此，context-engineering guide 在你想要的是一套可重复系统，而不是临时调 prompt 的时候，尤其有价值。

它和其他方法有什么不同

这不是一份泛泛的 prompt 写作指南。context-engineering 技能的重点在于上下文的选择、排序和复用：哪些内容应该放进 rules 文件，哪些属于 feature 文档，哪些应该来自源文件，以及哪些信息需要从测试输出或报错中刷新。

如何使用 context-engineering 技能

先安装 context-engineering

使用仓库自带的技能安装器，这样 context-engineering install 这一步对应的是官方包来源，而不是复制来的 prompt 片段。仓库里给出的基础命令是：
npx skills add addyosmani/agent-skills --skill context-engineering

从正确的文件开始读

先读 SKILL.md，再沿着仓库树里的链接引用继续追下去（如果有的话）。对这个技能来说，实际的阅读路径通常是：
SKILL.md → 它指向的任何仓库级说明 → 上下文层级相关章节 → rules 文件和任务范围界定相关章节。

把粗略目标转成可用输入

context-engineering usage 这一模式最有效的方式，是同时告诉 agent 三件事：任务、代码区域和约束。比如，不要只说“帮我搭上下文”，而是说“为一个 React app 配置上下文，优先沿用现有约定，并把 rules 保持得足够小，便于反复会话使用”。这样能给技能足够信号，去选择稳定上下文，而不是噪声历史。

有意识地使用层级

context-engineering for Context Engineering 的核心思路，是把上下文按稳定到临时的顺序分层：项目规则、feature 文档、相关源代码，然后是错误或测试结果。实际操作中，这意味着你应该避免把所有内容一股脑塞进一个 prompt。先给 agent 一组最小但足以证明当前约定的文件，再在第一次响应之后补充迭代证据。

context-engineering 技能常见问题

context-engineering 只是一个 prompt 模板吗？

不是。context-engineering skill 更适合被理解为一套决定“什么上下文放在哪里”的工作流。单独一段 prompt 当然也能问出类似结果，但它不会给你同样稳定的 rules、源文件选择和会话重置结构。

什么情况下不该用它？

如果你的任务很小、是自包含的，或者根本不依赖仓库约定，就不必用 context-engineering。如果 agent 只需要一个文件或者一个直接答案，那去搭完整的上下文层级，可能反而是多余开销。

新手能用吗？

可以，只要你已经意识到问题出在上下文质量，而不是模型能力。这个技能最容易上手的时机，是你能明确看出 agent 漏掉了什么：规则、架构、相关文件，还是最近的错误输出。

它适用于所有仓库吗？

不完全适用。它在约定重要、agent 出错代价高的活跃代码库里最有效。如果一个仓库结构很少，或者没有可复用的模式，context-engineering guide 仍然有帮助，但收益会小很多。

如何改进 context-engineering 技能

给技能更强的源材料

最大的提升来自更好的输入选择。提供一小组能真实体现你希望遵循模式的文件，再加上任何应当优先于猜测的规则文件或架构说明。这比把整个仓库一股脑塞进去有效得多。

直接说清失败模式

如果 agent 在漂移，就明确说它是怎么漂移的：API 风格不对、忽略文件夹约定、改动过度，还是漏掉了测试预期。context-engineering 技能更擅长响应你指出的错误行为，而不是只说“上下文更好一点”。

用证据迭代，不要重复同一句话

第一次输出后，把真正重要的错误、lint 失败、测试结果或不匹配点原样反馈回去。这样能改进 context-engineering usage，因为下一轮可以优先引入正确的临时上下文，而不是把同一个请求换个说法再说一遍。

让 rules 保持稳定且有范围

最好的结果来自小而清晰、难以误读、也容易持续加载的 rules。如果规则太宽泛，会削弱整个配置；如果规则太狭窄，又帮不上下一次会话。用 context-engineering 把长期有效的项目规范和一次性任务细节分开。