Context Engineering：让 AI 编程从「抽卡」变成「精密制造」

想象一个场景：你对 AI 说「帮我写个登录页面」，它兴冲冲给你吐了一堆代码，一运行——接口路径对不上，样式全乱了，权限校验直接裸奔。气得你摔键盘："这 AI 怎么这么蠢！" 其实，不是 AI 蠢，是你和 AI 之间缺了一份完整的「施工图纸」。Context Engineering 正是来解决这个问题的。

从「提示词工程」到「上下文工程」的范式跃迁

传统的 Prompt Engineering（提示词工程）像写便签：你绞尽脑汁想一句话让 AI 听懂你的意思。但便签太小，写不下项目全局的架构约定、团队的代码风格、API 的调用规范。AI 每次对话都是「失忆」状态，只能靠猜。 Context Engineering 则是给 AI 写一份完整的「剧本」——不是告诉它「做什么」，而是告诉它「怎么做、为什么、参照哪个范例、绕开哪些坑」。这个框架的核心文件叫 INITIAL.md，类似于给 AI 的一张详细需求单：

• 目标（Goal）：你要什么功能，说清楚，包括具体的字段、交互细节
• 范例（Inspiration）：参照哪个现有代码文件，AI 就知道你的代码风格
• 知识（Required Knowledge）：API 文档链接、依赖库说明，AI 不再靠幻觉瞎编
• 坑点（Gotchas）：提前告知 rate limit、认证流程等注意事项，AI 一次做对 这套方法论的核心洞察是：大多数 AI Agent 失败不是模型不够强，而是上下文不够丰富。Context Engineering 的作者 Apoo711 在博客中指出，AI 编程的瓶颈从「模型能力」转移到了「上下文质量」。

PRP 工作流：AI 编程的两段式「精密制造」

该框架将 AI 辅助编程拆解为严谨的两步流程： 第一步：生成 PRP（Product Requirements Prompt） 运行 .gemini/scripts/generate-prp.sh，将你的 INITIAL.md 需求单发送给 Google Gemini。Gemini 不是直接写代码，而是先输出一个详细的「技术蓝图」——也就是 PRP，描述实现思路、文件结构、关键技术决策。这相当于 AI 版的架构评审会议。 第二步：执行 PRP（Agent 执行循环） 运行 .gemini/scripts/execute-prp.sh，AI 开始按照 PRP 蓝图工作。关键在于：这个脚本是一个有人类监督的执行循环——AI 每一步都会停下来，询问你是否批准：批准后才执行命令或写入文件。你可以全程「旁观 + 把关」，避免 AI 跑偏。 这种设计的精妙之处在于：不是让 AI 无限输出，而是让 AI 在约束中精确执行。它解决了 AI 编程最核心的矛盾——「AI 太能跑，你跟不上」和「你管太死，AI 没意义」之间的平衡。

代码架构：标准化的模板工程

从仓库结构看，该框架本身也是一个可复用的编程项目模板：

• .gemini/：存放 AI 工具链脚本（generate-prp.sh、execute-prp.sh）和 PRP 模板文件
• PRPs/：存放 AI 生成的技术蓝图（持久化的执行计划）
• src/：项目源码目录，按功能模块组织（示例含 Python 和 Go 两个语言实现）
• tests/：单元测试，对应 src 下的每个模块
• examples/：代码范例，AI 参照此写新功能
• GEMINI.md：全局规则文档——代码行数限制（500行）、测试 triad 原则、类型注解要求、docstring 规范。这份文档定义了团队与 AI 的「合作契约」。 GEMINI.md 中最值得注意的规则包括：文件不超过 500 行（超了就重构）、每个函数必须写 Google-style docstring、用 Pydantic 做数据验证、用 mypy 做类型检查。这些约束本质上是在给 AI 划定「安全操作区」。

技术栈与依赖

这是一套零运行时依赖的框架：

• Shell 脚本（generate-prp.sh / execute-prp.sh）：调用 Gemini API，使用 jq 解析 JSON、awk 解析 AI 输出、base64 编解码
• Python / Go：示例代码，展示如何在此框架下开发实际应用（天气 CLI、链接检查器）
• Google Gemini API：唯一的外部依赖，需要用户自行申请 API Key 无需 Docker，无需 GPU，直接在终端运行。这使得它的部署成本接近于零——只要有 bash 环境就能跑。

上手体验：门槛低，但需要方法论

优点非常明显：安装极简（export GEMINI_API_KEY，然后直接运行脚本）、流程清晰（两段式工作流，AI 不乱跑）、模板可复用（INITIAL.md/GEMINI.md 模板可以沉淀到团队知识库中）。 但也有明显的局限：不面向非技术用户——你需要知道怎么写 INITIAL.md 需求单、怎么判断 PRP 的质量、怎么在 execute 阶段有效把控。这套工具对使用者的方法论要求较高，适合有经验的全栈工程师或技术 Lead。 另外，该框架极度依赖 Gemini 的输出质量。如果 Gemini 的响应格式不稳定（JSON 解析失败）、上下文窗口不够大（大项目 PRP 可能超限），整个流程就会卡壳。

行业意义：从「AI 辅助」走向「AI 协作」

Context Engineering 的出现反映了一个趋势：AI 编程工具正在从「对话式助手」进化为「可编程的工作流」。不是简单的一问一答，而是有计划、有评审、有执行的闭环系统。 这类框架的兴起意味着：未来团队的核心竞争力不是知道怎么用 AI，而是知道怎么给 AI 设计「工作规范」。Context Engineering 正是这个方向的早期探索者——它没有炫酷的 Web 界面，却用极简的工具链回答了一个本质问题：AI 编程工具怎样才能真正可靠？ 作者 Apoo711 在 2025 年 7 月发布（距今不到一年），已获 84 stars，正处于快速增长期。对于想在团队中推广 AI 编程、但又苦于 AI 输出质量不稳定的开发者来说，这是一份值得深入研究的实战案例。