前端工程师的 Vibe Coding 最佳实践（二）：上下文工程与提示工程

上一篇讲心法，这一篇全是「招式」。核心就一句话：AI 的输出质量，几乎完全由你提供的上下文决定。 业内甚至有个共识——「Prompt Engineering」正在被「Context Engineering（上下文工程）」取代，因为决定成败的不是你这一句话怎么措辞，而是 AI 在生成时能看到什么。

一、思维模型：把 AI 当成「失忆的天才」

每次对话，想象 AI 都是一个智商超高但刚刚失忆的人。它能看到的只有：

1. 你这次说的话（提示词）
2. 你显式给它的文件 / 代码（@ 引用、选中的代码）
3. 项目里的规则文件（rules / AGENTS.md）
4. 工具自动带上的少量上下文（当前打开的文件等）

它看不到：你脑子里的需求背景、团队的口头约定、上周的讨论、整个代码库（除非检索到）。

所以「上下文工程」的全部工作，就是：在 AI 生成之前，把它做对这件事所必需的信息，准确、精简地放进它的视野里。 多了浪费、干扰；少了它就靠猜，猜就出错。

二、地基工程：用 Rules 文件固化「项目宪法」

一次性说清楚的约定，不要每次都重复说。把它沉淀成规则文件，让每次对话自动携带。

在 Cursor 里是 .cursor/rules/*.mdc，通用约定也可以放 AGENTS.md。这是投入产出比最高的一步——写一次，永久受益。

一个前端项目的规则文件，应该覆盖这些维度（示例）：

# 项目技术栈
- React 19 + TypeScript 5（strict 模式）+ Vite
- 状态管理：优先组件内 state / Context；跨页共享用 Zustand，禁止引入 Redux
- UI：Ant Design 5，禁止再引入其它 UI 库
- 请求：统一走 src/services/http.ts 封装，不要直接用 fetch/axios

# 代码风格
- 组件用函数组件 + hooks，禁止 class 组件
- 文件名：组件 PascalCase，工具函数 camelCase
- 导出优先具名导出，避免 default export
- 不写无意义注释（不要逐行解释代码做了什么）

# 目录约定
- 页面放 src/pages/，可复用组件放 src/components/
- API 封装放 src/apis/，类型放 src/types.ts

# 必须遵守
- 所有异步请求要处理 loading 与 error 态
- 列表渲染必须有稳定 key，禁止用 index 作 key（除非纯静态）
- 可访问性：交互元素要有可聚焦/aria 语义

写规则文件的三条经验：

1. 写「约束」和「偏好」，不写废话。 AI 已经会写 React，你要告诉它的是你们家怎么写。
2. 给正反例。 「用具名导出 ✅ / 避免 default export ❌」比一句抽象描述有效得多。
3. 保持精简、分主题。 一个几千行的巨型规则文件，AI 反而抓不住重点。

三、精准投喂：@ 引用是你的瞄准镜

规则是「全局背景」，而具体任务需要「局部上下文」。用 @ 把相关材料直接拽进对话：

• @文件：让它参照某个已有实现（这是教 AI 写出和你代码库一致风格的最强武器）。
• @文件夹：让它了解某个模块的整体结构。
• @符号（函数/类型/组件）：精确指向某个定义。
• 选中代码再提问：针对性最强。

黄金技巧——「以例代述」：与其用文字描述你想要的风格，不如直接给一个范例文件：

「参照 @src/apis/article.ts 的写法，为评论模块写一个 comment.ts 的 API 封装，接口有列表、新增、删除。」

AI 会自动模仿你的命名、错误处理、类型组织方式。一个好例子，胜过十句形容词。 这也是为什么资深的人用 AI 又快又像「亲自写的」——他们总在喂自己的代码当模板。

四、计划优先（Plan First）：先要方案，再要代码

对任何非平凡的任务，不要一上来就让它写代码。先让它出计划，你审完再让它执行。

你：在动手之前，先给我一个实现计划：
    - 你打算改/建哪些文件？
    - 每个文件做什么？
    - 涉及哪些取舍，有没有多个方案？
    先不要写代码。

为什么这一步价值巨大：

• 错误在最便宜的阶段被拦截。 改一句计划，比改 200 行代码便宜得多。
• 暴露 AI 的错误假设。 它常常会理解偏，计划阶段你一眼就看出来。
• 你重新夺回架构主导权。 方案是你拍板的，AI 只是执行。

很多 AI 工具内置了「Plan 模式 / Ask 模式」，本质就是把这个最佳实践产品化了。复杂任务，永远先 Plan。

五、任务拆解：把「大象」切成「小块」

承接上一篇的「小步快跑」，这里给可操作的拆解维度：

• 按分层拆：类型/数据结构 → API 层 → 逻辑（hooks）→ UI 组件 → 联调。
• 按功能拆：先主流程跑通，再逐个加 分页/搜索/筛选/异常态。
• 按「能否独立验证」拆：每一块都要能单独跑起来或单独测。

一个实用句式：「我们分步来。这一步只做 X，先不要做 Y 和 Z。」 明确告诉 AI 边界，能有效防止它「自作主张」一次性生成一大坨。

六、六种高命中率提示范式（可直接套用）

下面这些是经过反复验证的模板，按场景取用。

1. 规格式（新功能）——目标 + 约束 + 验收

目标：实现一个图片懒加载的 <LazyImage> 组件。
约束：
  - React + TS，复用项目现有的样式方案
  - 用 IntersectionObserver，要在卸载时断开观察
  - 加载前显示占位骨架，加载失败显示兜底图
  - 不引入第三方库
验收：
  - props: src, alt, width, height, className
  - 进入视口才真正加载
  - SSR 安全（服务端不报错）
先给计划再实现。

2. 以例代述式（保持风格一致）

参照 @src/components/UserCard.tsx 的结构和风格，
写一个 ProductCard 组件，展示 商品图/标题/价格/标签，
props 类型完整，交互态（hover/loading）保持一致。

3. 重构式（给出动机和不变量）

重构 @src/pages/Dashboard/index.tsx：
动机：这个组件 500 行太臃肿。
要求：
  - 把数据获取逻辑抽成自定义 hook
  - 把图表区拆成独立子组件
  - 行为和渲染结果必须完全不变（这是硬约束）
  - 不改对外的 props
先列出你打算怎么拆，再动手。

4. 调试式（给证据，不给猜测）

现象：点击提交后页面白屏。
报错（控制台）：
  TypeError: Cannot read properties of undefined (reading 'map')
  at OrderList (OrderList.tsx:42)
相关代码：@src/pages/OrderList.tsx
我已确认接口返回了数据（贴了响应）。
请先给出 2-3 个最可能的原因假设，再定位，最后给修复。

调试的关键是给 AI 运行时证据（报错、日志、复现步骤、输入输出），而不是让它凭空猜。「先给假设再定位」能避免它直接乱改。

5. 解释式（看懂别人/AI 的代码）

逐段解释 @src/utils/scheduler.ts 这个文件：
  - 它解决什么问题？
  - 关键数据结构是什么？
  - 有没有潜在的边界 bug 或性能问题？
用通俗语言，假设我熟悉 JS 但不熟悉这个领域。

6. 评审式（让 AI 审自己/你的代码）

以资深前端的标准，review 这段 diff（@当前改动）：
重点看：类型安全、re-render 性能、内存泄漏、可访问性、错误处理。
按「严重 / 建议 / 吹毛求疵」分级列出问题，给出修改建议。

七、上下文卫生：少即是多

新手以为「给的上下文越多越好」，其实噪音会稀释信号。几条卫生准则：

• 只给相关的文件。 把十个无关文件塞进去，AI 反而抓不住重点。
• 长对话要「重启」。 一个会话聊了几十轮、跑题了、AI 开始忘事，果断开新对话，带上必要上下文重来。比在脏上下文里硬掰更快。
• 任务切换就换会话。 修 bug 的会话别拿来做新功能。
• 及时纠偏。 AI 跑偏时立刻打断纠正，不要等它错到底。一句「停，你理解错了，我要的是……」省一大半时间。

八、模型选择：好钢用在刀刃上

不同任务配不同「档位」的模型，是老手的隐藏技巧：

• 快任务（补全、小改、格式化、简单组件）→ 用快、便宜的模型，追求即时反馈。
• 难任务（架构设计、复杂重构、棘手 bug、跨多文件推理）→ 用最强的推理模型，让它「多想一会儿」。

不要用牛刀杀鸡（慢又贵），也不要用钝刀砍硬骨头（便宜但做不对）。

九、本篇小结

1. 上下文决定成败：把「做对这件事必需的信息」精准放进 AI 视野。
2. Rules 文件固化项目宪法，写一次永久受益，记得给正反例。
3. @ 引用 + 以例代述：用你自己的代码当模板，输出又快又一致。
4. 复杂任务先 Plan：在最便宜的阶段拦截错误。
5. 任务拆解到「可独立验证」的粒度。
6. 记牢六种提示范式；调试要给证据。
7. 上下文卫生：少即是多，脏了就重启会话。

---

下一篇是收口的硬骨头：《质量保障与工程化》——AI 让你写得飞快，但怎么保证这些代码敢上线？评审纪律、测试策略、用工程护栏「绑住」AI、安全红线、前端专项检查清单，以及一份 AI 时代的「完成定义（DoD）」。