前端工程师的提示词工程实战手册

用了一年多的 AI 编程工具，从 Copilot 到 Cursor 再到 Claude Code，我越来越觉得：决定产出质量的，不是模型有多强，而是你会不会提问。同样一个需求，模糊地丢一句话过去，和把上下文、约束、期望格式讲清楚，得到的结果天差地别。

这篇就把我平时常用的提示词套路整理一下，都是写业务时真能用上的，不讲虚的。

为什么提示词值得专门学

很多人觉得「提示词工程」是玄学，随便聊聊就行。但你换个角度想：模型本质上是在你给的上下文里做概率预测。你给的信息越精确、越结构化，它的搜索空间就越小，命中你真实意图的概率就越高。

模糊的提问就像给同事派活只说一句「把那个页面优化一下」，对方只能靠猜。

一、结构化提示：把需求拆成四块

我习惯把一个复杂提示拆成四个部分：角色、上下文、任务、约束。

# 角色
你是一位资深前端工程师，熟悉 Vue3 和 TypeScript。

# 上下文
我在维护一个后台管理系统，使用 Element Plus，
表格数据通过 axios 请求，接口返回分页结构 { list, total }。

# 任务
帮我封装一个通用的表格 Hook，支持分页、loading 状态、
搜索条件变化时自动重新请求。

# 约束
- 使用 Composition API + setup 语法
- 返回值用 TypeScript 类型标注
- 不要引入额外的状态管理库

这样写出来的结果，几乎不用返工。关键在于「约束」那一块——它把模型从「给一个能跑的方案」逼到「给我想要的那个方案」。

二、Few-shot：用例子代替描述

有些需求用语言描述很费劲，但给个例子模型秒懂。比如你想统一一批接口的命名风格：

请按以下示例的风格，把我给的接口名改成驼峰命名并加上动词前缀：

示例：
  user_list      -> getUserList
  order_detail   -> getOrderDetail
  delete_product -> deleteProduct

现在轮到你：
  role_page
  update_avatar
  export_excel

一两个例子就能把抽象规则讲清楚，比写三段文字都管用。这就是 few-shot 的威力：示例即规范。

三、上下文管理：别让模型「失忆」

前端项目动辄几十个文件，模型不可能全记住。我的做法是分层喂上下文：

• 全局规范放在配置文件里（Cursor 的 .cursorrules、Claude Code 的 CLAUDE.md），每次对话自动带上。
• 当前任务相关的代码手动贴进去，或者用工具的文件引用功能。
• 临时约定在对话里随时补充，比如「这个项目我们用 2 空格缩进」。

一个最小化的 CLAUDE.md 例子：

# 项目约定

- 框架：Vue3 + TypeScript + Vite
- 状态管理：Pinia
- 样式：SCSS，BEM 命名
- 组件文件用 PascalCase，工具函数用 camelCase
- 所有异步请求统一走 src/api 下的封装，不要在组件里直接写 axios

把这些固定规则沉淀下来，就不用每次对话都重复说一遍，模型也不会「忘」。

四、迭代式提问:别指望一步到位

复杂功能我从不一句话搞定，而是分步引导：

第一步:先帮我设计这个组件的 props 和 emits 接口，先不写实现。

确认接口没问题后：

第二步:现在实现组件逻辑,模板部分先用注释占位。

最后:

第三步:补全模板,并加上 loading 和空状态的处理。

分步的好处是每一步都可控,出问题能及时纠偏,不会等它写了 200 行才发现方向错了。

五、几个我常用的小技巧

让它先解释再动手:遇到不确定的方案,加一句「先说说你的思路,我确认后再写代码」,能避免一上来就跑偏。

指定输出格式:要 JSON 就明确说「只返回 JSON,不要任何解释文字」,要 diff 就说「用 diff 格式展示改动」。

给反例:除了说「我要什么」,有时候说清「我不要什么」更有效,比如「不要用 any 类型」「不要引入新依赖」。

复盘式提问:代码写完让它自己审一遍——「检查这段代码有没有内存泄漏或边界问题」,模型经常能揪出自己刚埋的坑。

六、常见踩坑

踩坑	后果	改法
一句话甩需求	结果飘忽,反复返工	补齐角色、上下文、约束
上下文塞太多	模型抓不住重点	只给相关代码,精简
从不给例子	风格对不上	用 few-shot 示例
一次要太多	大段代码难校验	拆成小步迭代
盲目相信输出	引入隐藏 bug	让它自审 + 自己 review

写在最后

提示词工程说到底不是什么高深技巧,核心就一句话:把你脑子里的隐含信息显式地讲出来。你越习惯结构化地表达需求,跟 AI 协作就越顺,顺带着你跟真人同事沟通需求的能力也会变强。

工具会一直变,但「清晰表达意图」这件事不会过时。