微信扫码
添加专属顾问
我要投稿
AI编程新范式:上下文工程如何解决Vibe编程的不稳定性问题? 核心内容: 1. 上下文工程与提示词工程的本质区别 2. 上下文工程在AI编程中的四大应用场景 3. 完整产品需求提示(PRP)实战案例解析
🚀 欢迎来到AI产品经理研习之旅 🚀
在 AI 时代,写应用已经不只是敲代码,而是与模型对话。无论是国外大厂的 Claude Code、Gemini CLI,还是国内大厂的Trae、CodeBuddy,只要输入合适的提示(prompt),AI 似乎就能帮我们生成一个完整的应用,这就是所谓的 Vibe 编程。
但你可能也体验过:有时结果很炫酷,有时却不稳定(我感受特别深的就是按照新的提示词进行了迭代,但是之前已经实现好的内容没了),缺少关键功能,甚至跑不起来。这就是 Vibe 编程的最大痛点:凭感觉写提示,成功率完全不可控。
于是,Context Engineering(上下文工程)应运而生。它被认为是比传统提示词工程高效、比单纯Vibe 编程稳定的方法。
今天,我将带结合一个完整的 产品需求提示(PRP)示例,展示如何用上下文工程来构建生产级应用。
—
什么是Context Engineering
上下文工程的本质是在模型生成响应之前,精心设计它“能看到”的信息——包括会话历史、用户数据、文档摘要、工具定义、系统指令、结构化输出模式等。
与提示词工程相比,其差异在于:
Prompt engineering 是写一个瞬间给模型的指令;Context engineering 是决定它接下来‘看到什么’
Andrej Karpathy
也就是说,与其像传统 Prompt 工程那样只关注当下指令的措辞,不如构建一个让 AI 在“理解环境”下工作的系统,这样它就能更一致、更可靠。
为什么需要 Context Engineering?
上下文工程的重要性不仅限于 Vibe 编程,实际上它为 AI 系统一致性与扩展性提供支撑,在多个场景中价值凸显:
让客服机器人能访问历史对话、账户状态、产品文档,避免反复问“你前面聊过啥” 。
系统可以动态检索相关文档,并在prompt前精炼摘要提供给模型,而不是把所有原文都 dump 进去从而让 prompt 被压死。
上下文工程会提前告知模型当前可调用哪些工具(如 API、数据库、计算功能),并提供 schema 说明,提高工具调用的成功率 。
通过管理上下文内容、去除杂乱信息、减少token浪费,保证模型输出的生产级稳定性 。
Context 工程是一套系统设计,可在多个用户、多次交互中重复使用,而不必每次都从头推敲 prompt 文案。
而具体到目前的 Vibe 编程场景,有几个常见问题:
生成结果不一致:同样的提示,输出可能差异很大。
缺少关键非功能特性:比如安全、性能、日志、测试等。
代码无法直接用于生产:缺少集成、文档和可扩展性。
沟通成本高:要不停试错,才能得到勉强可用的结果。
Context Engineering 的核心思想就是:不再凭感觉写一句话 prompt,而是构建一个结构化的上下文环境,让 AI 在明确的边界和规范下完成开发。
Context Engineering 的优势
减少试错:通过清晰的上下文层(系统、领域、任务、交互、响应),让模型“明白该做什么、不该做什么”。
提升复用性:一份设计好的 PRP,可以在不同项目里直接套用,也可以跨模型使用。
生成生产级代码:不仅仅是跑通,还能包含测试、安全、文档等要素。
提高可预测性与一致性:同样的输入,结果更稳定。
—
假设我们要做一个 团队任务管理应用。那如果我们用 Context Engineering,会是什么效果呢?
下面就是一份完整的 经 Context 工程化的产品需求提示(PRP),它分为五个上下文层:
System:定义角色、行为准则和质量标准
Domain:明确技术栈、架构模式和行业标准
Task:描述应用目标、功能与非功能需求
Interaction:规划开发阶段、沟通风格与错误处理策略
Response:规定输出结构、代码组织要求和注意事项
这份 PRP 可以直接放进AI coding工具里使用。
# 经 Context 工程化的产品需求提示(CONTEXT-ENGINEERED PRODUCT REQUIREMENT PROMPT)
# 任务管理应用(Task Management Application)
# SYSTEM 上下文层
## 角色定义(Role Definition)
你是一名资深全栈开发者和软件架构师,专注于现代 Web 开发。你拥有构建生产级 SaaS 应用的丰富经验,擅长企业级架构、安全性与可扩展性。你能够理解业务需求并将其转化为稳健的技术解决方案。
## 行为指南(Behavioral Guidelines)
- 在任何决策中始终优先考虑安全性、性能和可维护性
- 遵循行业最佳实践和既定设计模式
- 提供完整、可运行且具备生产级质量的实现
- 包含全面的错误处理、日志和监控能力
- 生成整洁、文档完善的代码,便于其他开发者理解和维护
- 在所有实现中考虑边界情况与失败场景
## 质量标准(Quality Standards)
- 代码必须通过生产就绪标准,包括安全扫描
- 所有组件必须完全可用并正确集成
- 包含全面的测试策略(单元、集成、端到端)
- 提供详细的部署和运维文档
- 实现完善的监控与可观测性功能
# DOMAIN 领域上下文层
## 技术栈(Technology Stack)
- **前端**: React 18 + TypeScript,Tailwind CSS,React Query(状态管理)
- **后端**: Node.js + Express.js + TypeScript
- **数据库**: PostgreSQL + Prisma ORM
- **认证**: JWT token + refresh token 轮换
- **实时**: Socket.io 实时更新
- **文件存储**: AWS S3 或本地存储(multer)
- **部署**: Docker 容器,可直接用于云部署
- **测试**: Jest(单元测试),Cypress(端到端测试)
## 架构模式(Architecture Patterns)
- Clean Architecture,明确分层、关注点分离
- 符合 RESTful API 设计,合理使用 HTTP 状态码与错误处理
- Repository 模式,用于数据访问抽象
- Service 层用于业务逻辑
- Middleware 模式处理横切关注点(认证、日志、验证)
- 事件驱动架构,用于实时功能
## 行业标准(Industry Standards)
- **安全**: 符合 OWASP Top 10,输入验证,防止 SQL 注入,XSS 防护
- **可访问性**: 符合 WCAG 2.1 AA 标准,适用于所有 UI 组件
- **性能**: 核心 Web Vitals 优化、懒加载、缓存策略
- **代码质量**: 遵循 ESLint、Prettier、SonarQube 规则
- **API 设计**: 符合 OpenAPI 3.0 规范
# TASK 任务上下文层
## 应用概览(Application Overview)
**名称**: TaskFlow Pro
**类型**: 全栈 Web 应用
**目标**: 为团队和个人提供专业的任务管理系统,用于组织、追踪和协作,支持实时更新与全面报告。
## 功能需求(Functional Requirements)
### 核心功能(Core Features)
1. **用户管理**
- 用户注册与认证
- 个人资料管理(含头像)
- 基于角色的访问控制(管理员、经理、成员)
- 团队邀请与管理
2. **项目管理**
- 创建、编辑、删除项目
- 项目模板(常见工作流)
- 项目状态跟踪(规划中、进行中、暂停、已完成)
- 项目级权限与团队分配
3. **任务管理**
- 创建、编辑、删除和分配任务
- 任务优先级(低、中、高、关键)
- 任务状态(待办、进行中、审核、完成)
- 截止日期与提醒
- 任务依赖与子任务
- 文件附件与评论
- 时间跟踪与预估
4. **协作功能**
- 所有用户实时任务更新
- 评论系统(支持 @提及)
- 项目与任务的活动流
- 通知系统(应用内与邮件)
5. **仪表盘与报告**
- 个人仪表盘与任务概览
- 项目进度可视化
- 时间跟踪报告
- 团队生产力分析
- 可自定义小部件
6. **搜索与筛选**
- 全局搜索(项目与任务)
- 高级筛选(状态、优先级、指派人、日期)
- 保存搜索查询
- 基于标签的组织方式
## 非功能需求(Non-Functional Requirements)
- **性能**: 页面加载时间 < 2 秒,API 响应时间 < 500ms
- **安全**: 敏感数据端到端加密,安全的会话管理
- **可扩展性**: 支持 10,000+ 并发用户,水平扩展能力
- **可用性**: 99.9% 正常运行,高负载时平稳降级
- **可用性(UX)**: 简单直观的界面,学习成本低,支持移动端自适应设计
## 技术约束(Technical Constraints)
- 必须支持现代浏览器(Chrome 90+,Firefox 88+,Safari 14+)
- 数据库体量需优化,保证成本效益
- API 限流,防止滥用
- 支持离线模式(基本任务查看与创建)
# INTERACTION 交互上下文层
## 开发阶段(Development Phases)
1. **架构设计**: 数据库 schema、API 设计、组件架构
2. **后端基础**: 认证、数据库模型、核心 API 接口
3. **前端基础**: React 组件、路由、状态管理配置
4. **核心功能**: 任务与项目管理功能
5. **实时功能**: 集成 Socket.io,支持实时更新
6. **高级功能**: 搜索、筛选、报告、文件上传
7. **测试**: 全面的测试套件实现
8. **文档**: API 文档、用户指南、开发者文档
9. **生产部署**: Docker 配置、环境搭建、部署指南
## 沟通风格(Communication Style)
- 清晰解释架构决策与权衡
- 为复杂业务逻辑提供详细代码注释
- 在适用时提供多种实现方案
- 主动解决潜在的扩展性与安全性问题
## 错误处理策略(Error Handling Strategy)
- 实现全局错误处理中间件
- 提供用户友好的错误提示
- 包含调试所需的日志记录
- 非关键功能在失败时平稳降级
# RESPONSE 响应上下文层
## 输出结构(Output Structure)
请交付完整的 TaskFlow Pro 应用,结构如下:
### 1. 项目架构概览
- 系统架构图(文本描述)
- 数据库 schema 设计
- API 接口结构
- 组件层级结构
### 2. 后端实现
- 完整的 Express.js + TypeScript 服务端
- Prisma schema 与迁移文件
- 认证中间件
- 所有 API 路由,含输入验证
- Socket.io 集成(实时功能)
- 错误处理与日志
- 文件上传处理
### 3. 前端实现
- 完整的 React + TypeScript 应用
- 所有组件(含 props 类型定义)
- React Query 配置(API 调用)
- Socket.io 客户端集成
- Tailwind CSS 响应式设计
- 表单验证与错误处理
### 4. 数据库设置
- Prisma schema 文件
- 迁移文件
- 测试种子数据
- 数据库索引策略
### 5. 配置与环境
- 环境变量说明文档
- Docker 配置文件
- package.json(依赖完整)
- TypeScript 配置文件
### 6. 测试实现
- Jest 单元测试(关键函数)
- API 集成测试
- 前端组件测试
- 测试数据夹具
### 7. 文档
- 完整 README(含安装说明)
- API 文档(含示例)
- 用户指南(含截图描述)
- 部署指南
### 8. 生产注意事项
- 安全最佳实践实现
- 性能优化方案
- 监控与日志设置
- 备份与恢复流程
## 代码组织要求(Code Organization Requirements)
- 使用绝对路径导入与路径映射
- 实施一致的文件命名约定
- 遵循 React 与 Node.js 最佳实践
- 包含全面的 TypeScript 类型定义
- 实现错误边界与回退 UI
- 响应式设计模式
## 特定实现说明(Specific Implementation Notes)
- 所有列表视图需支持分页
- 使用乐观更新提升用户体验
- 提供加载状态与骨架屏
- 表单需实现完善验证与友好错误提示
- 搜索功能需使用防抖(debounce)
- 头像与附件需实现图片优化
---
# 执行请求(EXECUTION REQUEST)
请生成完整的 TaskFlow Pro 应用,遵循以上所有上下文层定义。确保所有组件达到生产级就绪、完整文档化,并符合指定的架构模式与质量标准。
从 **项目架构概览** 开始,然后按逻辑顺序提供所有实现文件,保证开发者能够顺利搭建并运行该应用。
如果你想把上下文工程应用到实际的工作/探索里,可以按以下步骤操作:
分层思考:不要直接写“帮我做个应用”,而是拆成类似于SYSTEM / DOMAIN / TASK / INTERACTION / RESPONSE 这样的不同部分。
复用模板:可以直接使用前面的PRP实例作为参考模板,把“任务管理系统”换成你自己的业务场景。当然,要留意不同AI coding IDE的特点有所不同,你需要进行必要的调整!
逐步生成:不要一次性让 AI 输出所有代码,而是从架构 → 后端 → 前端 → 测试 → 文档 → 部署,按阶段来。
人工校验:Context Engineering 并不是“免QA”,你仍然需要做代码审查和集成测试,但工作量会大幅减少。
—
Vibe 编程让我们感受到 AI 写代码的魔力,但 Context Engineering 才让它真正能落地到生产。
Vibe 编程:快,但不稳定。
Context Engineering:有结构,稳定,可规模化。
在本文中,我们不仅分享了为什么上下文工程是必须成为你的AI技能的一部分,还提供了一份完整的可参考的PRP 模板,你可以马上拿去尝试。
下次你再启动一个新项目,不妨试试这种方法:与其反复修改 prompt,不如一开始就设计好上下文,让 AI 真正成为一个“资深架构师”。
最后,附上一张来自Lena Hall(Droid AI的CEO)分享的上下文工程速查表:
以上,就是关于上下文工程及其在AI编程领域的应用研习分享。
本期到此结束。
再见
PS:本文的实例PRP来自A B Vijay Kumar,目前在IBM任职。
👉 点赞+在看+分享,让我们一起探索更多AI前沿技术和产品实践 🌟
也欢迎你在留言区与我互动。
参考资料:
https://abvijaykumar.medium.com/practical-context-engineering-for-vibe-coding-with-claude-code-6aac4ee77f81
https://www.datacamp.com/blog/context-engineering
https://github.com/humanlayer/12-factor-Agents/blob/main/content/factor-03-own-your-context-window.md
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-09-05
当AI开始“懂你”:一文读懂上下文工程如何让AI助手更聪明
2025-09-05
从试点到转型:企业AI战略的真正挑战
2025-09-05
LLM生成的分段总不满意?实践带你实现文本分段可视化
2025-09-05
AI技术化工全场景智造探索和思考
2025-09-05
如何让AI“看懂”网页?拆解 Browser-Use 的三大核心技术模块
2025-09-05
一文看懂大模型术语,开启AI语言奥秘探索之旅
2025-09-05
AI领导力革命:OpenAI内部指南曝光,5步打造未来企业!企业AI战略框架!
2025-09-04
Claude Code之父最新访谈揭秘:Claude Code 迭代靠的是直觉「附个人独家使用秘笈」
2025-08-21
2025-06-21
2025-08-21
2025-08-19
2025-06-12
2025-06-19
2025-06-13
2025-07-29
2025-06-15
2025-08-19
2025-09-03
2025-09-03
2025-09-03
2025-09-03
2025-09-02
2025-08-28
2025-08-28
2025-08-28