你有顶级武器，但可能不会用

你有顶级武器，但可能不会用

最近和同事交流，发现个有意思的现象：公司给大家配了 Coding Copilot，人人都能用，但产品经理们普遍不知道怎么"说话"才能让 AI 生成好结果。

典型场景是这样的：

产品经理：“帮我做个登录页面。”
AI：“好的。”（然后生成了一堆代码，但和你想要的完全不一样）

为啥会这样？因为 AI 不是人，看不到你脑中的原型图，也猜不出你的技术栈和设计规范。

最近我帮团队小伙伴做了个实验：用 AI 生成原型设计。结果发现关键是要先建立结构化框架，就像教 AI 玩乐高——给对说明书，它就能搭出像样作品；说不清楚，它只能瞎搭。

为什么你需要学会"和 AI 说话"

罗振宇在 2023-2024 跨年演讲里讲过一段话：AI 就像是一群无限数量的大学生，真正挑战的是你能指挥多少这样的大学生做事，把事情分解下去并得到可控结果的能力。

这话说到点子上了。

数据不会骗人

看几个关键数据：

什么意思？你会不会写 prompt，直接决定了 AI 工具是帮手还是累赘。

本质：Prompt = 产品决策

有个认知很重要：每次写 prompt，你都在做产品决策。

  • 你描述的功能需求 → 定义了产品边界
  • 你给出的样式要求 → 定义了用户体验
  • 你列出的技术栈 → 定义了实现方案

这和写 PRD 是一个道理。区别是，PRD 写给人看，prompt 写给 AI 看。人能脑补，AI 不能。

吴恩达（Andrew Ng）说过："数据即 PRD。"AI 时代，你需要用具体的数据示例而非冗长抽象的文档来定义产品。

现实：掌握技巧变成核心竞争力

团队人人有 Copilot，但为啥有的人生成的代码能直接用，有的人生成的代码一堆 bug？

差距就在 prompt 技巧上。

这就像当年 Excel 刚普及时，会用 VLOOKUP 的人效率高 10 倍。现在，会写 prompt 的产品经理，协作效率也是数量级的差距。

而且更重要的是：**你能自己改 prompt 迭代，不用等工程排期。**这意味着你可以快速验证想法、快速试错、快速调整方向。

五要素框架：结构化需求描述的套路

好消息是：写好 prompt 是有套路的，不是玄学。

有个现成的套路叫"五要素框架"（5-Pillar Framework），特别好用。

1. Role（角色）：明确 AI 的身份

告诉 AI 它是谁，它就能切换到对应的"人设"。

示例：

  • “你是一名资深前端工程师，擅长 React 开发。”
  • “你是 XX 公司的 UI/UX 设计师，熟悉 Material Design 规范。”

为什么重要：
不同角色的思维方式不一样。你让 AI 扮演前端工程师，它会关注代码实现；你让它扮演设计师，它会关注视觉效果。

2. Goal（目标）：清晰说明要解决什么问题

别绕弯子，直接说你要什么。

好的表达：

  • “为电商网站创建一个商品列表页”
  • “实现一个支持搜索和筛选的用户管理后台”

不好的表达：

  • “帮我做个页面”（什么页面？）
  • “优化一下这个功能”（怎么优化？）

3. Context（上下文）：提供背景信息

这是最容易被忽略，但最关键的一环。

上下文包括：

  • 技术栈：React？Vue？用什么 UI 库？
  • 设计规范：遵循什么设计系统？
  • 业务场景：用户是谁？在什么情况下使用？
  • 已有代码：是新项目还是在现有项目上改？

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
我们的技术栈：
- 前端框架：React 18
- 语言：TypeScript
- 样式方案：Tailwind CSS
- 组件库：Ant Design
- 状态管理：Zustand

设计规范：
- 遵循 XXUI 规范
- 主色调：#13493F（深绿色）
- 辅助色：#C9B037（暖金色）
- 圆角：8px
- 间距：8 的倍数

4. Template（模板）：定义输出结构

告诉 AI 你想要什么格式的输出。

示例：

  • “生成 React 函数组件，使用 TypeScript”
  • “返回完整的 HTML + CSS 代码”
  • “提供组件代码 + 使用示例 + Props 说明”

5. Specifics（具体要求）：明确细节和约束

把你能想到的细节都列出来：

  • 功能需求列表
  • 交互行为（点击、hover、滚动等）
  • 响应式要求（移动端、平板、桌面端）
  • 数据格式（API 返回什么结构）
  • 边界情况（空数据怎么显示、loading 状态、错误提示）

框架总结公式：

1
2
3
4
5
我是谁（Role）
要做什么（Goal）
+ 在什么环境下（Context）
+ 输出什么格式（Template）
+ 具体要求（Specifics）

记住这个套路，你的 prompt 质量能提升一个档次。

好 Prompt vs 差 Prompt：一看就懂的差距

光说理论不够，直接看对比案例。

案例 1：登录页面

❌ 差 Prompt（模糊、抽象）

1
做一个登录页面。

问题：

  • 没说用什么技术
  • 没说要什么功能
  • 没说长什么样
  • AI 只能瞎猜

结果：
可能给你生成个 jQuery + Bootstrap 的老式页面，或者 Vue 3 的组合式 API，完全看心情。

✅ 好 Prompt（具体、结构化）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
使用 React + TypeScript 创建一个登录组件

【技术要求】
- 使用 functional component 和 hooks
- 使用 Tailwind CSS 样式
- 表单验证逻辑独立到 utils/validation.ts

【功能需求】
- 包含邮箱和密码字段
- 邮箱需要格式验证（正则匹配）
- 密码长度至少 8 位，必须包含数字和字母
- 支持"记住我"复选框
- 显示验证错误提示（红色文字，字段下方）
- 登录按钮在表单验证通过前禁用

【样式要求】
- 整体居中布局（垂直水平都居中）
- 卡片式设计，白色背景，带阴影（shadow-lg）
- 遵循 XXUI 规范：
  - 主色调：#13493F（深绿色，用于主按钮）
  - 辅助色：#C9B037（暖金色，用于强调元素）
- 输入框高度 48px，圆角 8px
- 响应式设计：
  - 桌面端：卡片宽度 400px
  - 移动端：卡片宽度占满屏幕（左右留 16px 边距）

【数据交互】
- 点击登录按钮后调用 POST /api/auth/login
- 请求格式：{ email: string, password: string, remember: boolean }
- 成功后跳转到 /dashboard
- 失败显示错误提示

改进点：

  • ✅ 明确技术栈
  • ✅ 功能需求列表化
  • ✅ 验证逻辑说清楚了
  • ✅ 样式具象化（数值都给出了）
  • ✅ 说明了API交互逻辑

结果：
AI 能生成基本可用的代码，改几个细节就能上线。

案例 2：数据表格组件

❌ 差 Prompt

1
生成一个表格，显示用户数据。

问题：

  • 用户数据有哪些字段？
  • 要支持什么功能？（排序？筛选？分页？）
  • 用什么 UI 库？

✅ 好 Prompt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
使用 React + TypeScript + Ant Design 创建用户管理表格组件

【数据结构】
用户对象包含以下字段：
- id: number（用户 ID）
- name: string（姓名）
- email: string（邮箱）
- role: 'admin' | 'user' | 'guest'（角色）
- status: 'active' | 'inactive'（状态）
- createdAt: string（创建时间，ISO 格式）

【表格功能】
- 显示所有字段，列宽自适应
- 支持按姓名搜索（输入框实时筛选）
- 支持按角色筛选（下拉选择：全部/管理员/普通用户/访客）
- 支持分页（每页 10 条，显示总数）
- 状态列显示标签：
  - active 显示绿色标签
  - inactive 显示灰色标签
- 操作列包含：编辑按钮、删除按钮

【样式要求】
- 使用 Ant Design Table 组件
- 搜索框和筛选器在表格上方，左右布局
- 操作按钮使用图标（EditOutlined、DeleteOutlined）

【数据交互】
- 数据从 props 传入（userList: User[]）
- 编辑/删除操作通过回调函数触发：
  - onEdit: (user: User) => void
  - onDelete: (userId: number) => void

改进点：

  • ✅ 明确数据结构（AI 不用猜）
  • ✅ 功能列表详细（搜索、筛选、分页都说清楚了）
  • ✅ 样式有依据（用 Ant Design 组件）
  • ✅ 交互逻辑完整

案例 3：Dashboard 布局

❌ 差 Prompt

1
Make a dashboard.

（英文也一样，模糊就是模糊）

✅ 好 Prompt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Create a React admin dashboard layout

【技术栈】
- React 18 + TypeScript
- Material-UI components
- Responsive design

【布局结构】
1. 左侧边栏（固定宽度 240px）
   - Logo（顶部，高度 64px）
   - 导航菜单（垂直）：Dashboard、Users、Orders、Settings
   - 用户信息卡片（底部）

2. 顶部导航栏（固定高度 64px）
   - 汉堡菜单按钮（移动端显示）
   - 搜索框（居中，宽度 400px）
   - 通知图标 + 用户头像（右侧）

3. 主内容区
   - 顶部统计卡片（4 个，横向排列）：
     - 总用户数
     - 今日订单数
     - 收入统计
     - 增长率
   - 中间数据图表（2 列布局）：
     - 左：订单趋势折线图（Chart.js）
     - 右：用户分布饼图
   - 底部表格：最近订单列表（显示 5 条）

【响应式要求】
- 桌面端（> 1024px）：侧边栏固定显示
- 平板端（768px - 1024px）：侧边栏可收起
- 移动端（< 768px）：
  - 侧边栏默认隐藏，通过汉堡菜单打开
  - 统计卡片改为垂直堆叠
  - 图表改为上下布局

【配色方案】
遵循 XXUI 规范：
- 主色：#13493F（深绿色）
- 辅助色：#C9B037（暖金色）
- 背景：#f5f5f5（浅灰）
- 卡片：白色 + shadow

改进点：

  • ✅ 布局拆解清晰（左中右、上中下）
  • ✅ 每个区域的内容都列出来了
  • ✅ 响应式行为说明白了（不同屏幕宽度怎么显示）
  • ✅ 有配色方案

实战模板：拿来就用的 Prompt 公式

把上面的方法提炼成模板，复制粘贴改改就能用。

UI 组件生成通用模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
使用 [React/Vue] + [TypeScript/JavaScript] 创建 [组件名称] 组件

【背景】
产品类型：[电商/SaaS/内容平台]
使用场景：[用户在什么情况下使用这个组件]
目标用户：[用户特征]

【技术要求】
- 框架：[React/Vue]
- 语言：[TypeScript/JavaScript]
- 样式：[Tailwind/CSS Modules/Styled Components]
- 组件库：[Ant Design/Material-UI/Shadcn]（如果用）

【功能需求】
1. [需求1]
2. [需求2]
3. [需求3]
...

【UI 要求】
- 布局：[描述布局方式，如卡片式、列表式]
- 颜色：[主色调/配色方案]
- 交互：[hover/focus/点击效果]
- 响应式：
  - 桌面端（> 1024px）：[行为描述]
  - 移动端（< 768px）：[行为描述]

【数据结构】（可选）
  interface ComponentProps {
    // 定义 props 类型
  }

【数据交互】（可选）
- API 地址：[URL]
- 请求方式：[GET/POST/PUT/DELETE]
- 请求格式：[JSON 结构]
- 响应格式：[JSON 结构]
- 成功/失败处理：[描述]

【特殊要求】（可选）
- 性能：[加载优化/懒加载要求]
- 无障碍：[ARIA 标签/键盘导航要求]
- 测试：[需要单元测试吗？覆盖哪些场景？]

前端页面生成模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
创建 [页面名称] 页面

【页面功能】
[一句话描述这个页面是干什么的]

【页面结构】
1. [区域1]：[功能描述]
2. [区域2]：[功能描述]
3. [区域3]：[功能描述]

【技术栈】
- 框架：[Next.js/Create React App/Vite]
- 路由：[React Router/Next.js Router]
- 状态管理：[Redux/Zustand/Context API]
- 样式：[Tailwind/Styled Components]

【详细需求】
[按照组件模板，拆解每个区域的需求]

【路由和导航】
- 页面路由：[/path]
- 来源页面：[从哪里跳转过来]
- 目标页面：[点击什么跳转到哪里]

【数据流】
- 初始化时加载：[API 列表]
- 用户操作时调用：[API 列表]
- 数据缓存策略：[是否需要缓存？用什么方案？]

使用技巧：

  1. 先填模板，再微调

    • 不要一上来就自己写，先用模板结构化你的需求
    • 填完模板再根据具体情况删减或补充

  2. 迭代优化，不要期望一次完美

    • 第一次生成的代码不满意？没关系
    • 看看哪里不符合预期，补充具体要求，让 AI 再生成一次

  3. 保存你的常用模板

    • 把团队常用的技术栈、设计规范固化到模板里
    • 每次用的时候只需要改具体需求部分

  4. 建立团队 Prompt 库

    • 好用的 prompt 分享给团队
    • 就像你们有组件库一样，也可以有 Prompt 库

环境配置：让 Copilot 更懂你

除了每次写完整的 prompt，还有个更高效的办法：配置 Custom Instructions（自定义指令）。

这就像给 AI 配了一个"记忆芯片"，让它永远记住你的技术栈和偏好。

什么是 Custom Instructions？

说白了，就是一段固定配置，告诉 AI：

  • 我们用什么技术
  • 代码规范是啥
  • 我希望你怎么输出

配置一次，以后 AI 都记得。

怎么设置？

GitHub Copilot 设置路径（以 VS Code 为例）：

  1. 打开 VS Code
  2. 左下角齿轮图标 → Settings
  3. 搜索 “Copilot Instructions”
  4. 在文本框里填入你的配置

Cursor 设置路径：

  1. Cmd/Ctrl + Shift + P → 输入 “Cursor Settings”
  2. 找到 “Rules for AI” 或 “Custom Instructions”
  3. 填入配置

配置模板示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
# 团队技术栈

## 前端框架
- React 18（优先使用函数组件 + Hooks）
- TypeScript（严格模式）

## 样式方案
- Tailwind CSS（优先使用）
- 不使用内联样式
- 响应式设计：移动优先

## 组件库
- Ant Design 5.x（数据展示类组件）
- Headless UI（交互类组件）

## 状态管理
- Zustand（全局状态）
- React Query（服务端状态）

## 代码规范

### 命名规则
- 组件文件：PascalCase（如 UserProfile.tsx）
- 工具函数：camelCase（如 formatDate.ts）
- 常量：UPPER_SNAKE_CASE

### 组件结构
  // 固定顺序
  1. imports
  2. types/interfaces
  3. constants
  4. component
  5. exports

### Props 定义
- 使用 interface 而非 type
- Props 必须明确类型，避免 any
- 可选 props 使用 ? 而非默认值

### 函数组件
- 使用箭头函数
- Props 解构在参数位置
- 早返回（early return）处理边界情况

## 输出要求

- 生成代码时包含必要的注释
- TypeScript 类型完整
- 考虑错误处理（try/catch 或 error boundary）
- 考虑 loading 状态
- 考虑空数据状态

## 不要做的事

- 不要使用 class 组件
- 不要使用 var，只用 const/let
- 不要使用 any 类型（除非真的必要）
- 不要生成超过 200 行的单个文件（建议拆分）

配置后的效果

配置前：

1
2
3
你："创建一个按钮组件"
AI："好的"（生成 Vue 2 的按钮，或者 jQuery 的按钮，看心情）

配置后：

1
2
3
你："创建一个按钮组件"
AI："好的"（自动生成 React 18 + TypeScript + Tailwind 的按钮，符合团队规范）

一次配置，终身受益。

常见问题 Q&A

Q1：Custom Instructions 和每次写 prompt 有啥区别？

A：Custom Instructions 是"全局规则"，适合放技术栈、代码规范这种不变的东西。具体的功能需求还是要每次单独写 prompt。

Q2：配置太长会不会影响性能？

A：会占用一些 token，但影响不大。建议控制在 500-1000 字以内。

Q3：团队成员的配置能统一吗？

A：可以。把配置文件存到项目的 .github/copilot-instructions.md，然后让大家复制粘贴到自己的设置里。

（注：有些工具支持项目级配置，但 GitHub Copilot 目前还不支持，需要手动同步）

3 个认知转变 + 4 个落地关键点

3 个认知转变

1. 从"模糊表达"到"结构化描述"

以前：

  • “帮我做个好看的登录页”
  • “优化一下这个功能”
  • “改改样式”

现在：

  • 用五要素框架拆解需求
  • 功能列表化、样式数值化
  • 技术栈明确、交互逻辑完整

就像从"我想吃好吃的"变成"我要一份麻辣小龙虾（中辣、去虾线、配米饭）"。

2. 从"期望完美"到"迭代优化"

以前：

  • 写一次 prompt，期望 AI 生成完美代码
  • 结果不满意就觉得 AI 不行

现在：

  • 第一次生成 60 分，正常
  • 看看哪里不对，补充需求，让 AI 再改
  • 几轮迭代后达到 90 分

就像测试软件一样测试 prompt。没有一次过的产品，也没有一次过的 prompt。

3. 从"工具使用"到"战略思维"

以前：

  • 把 Copilot 当"代码补全工具"
  • 遇到问题就问 AI，随机应变

现在：

  • Prompt Engineering 是产品方法论的延伸
  • 把需求结构化本身就是产品能力
  • 能指挥 AI 干活 = 能指挥团队干活

罗振宇那句话说得对：AI 就像是一群无限数量的大学生，真正挑战的是你能指挥多少这样的大学生做事，把事情分解下去并得到可控结果的能力。

4 个落地关键点

1. 结构化 > 随意描述

  • ✅ 使用模板和框架（五要素）
  • ✅ 分点列举而非大段文字
  • ✅ 功能、样式、交互分开描述

2. 具体 > 抽象

  • ✅ 用数据、案例、示例
  • ✅ 避免"优化"、“改进”、"好看"等模糊词
  • ✅ 给出具体数值（宽度、颜色、字号）

对比：

  • ❌ “这个按钮要大一点”
  • ✅ “按钮宽度 120px，高度 40px”

3. 拆分 > 一次完成

  • ✅ 复杂任务拆成小步骤
  • ✅ 每步验证后再继续
  • ✅ 先要结构，再要细节

示例：
不要说：“帮我做一个完整的电商网站”
应该拆分成：

  1. 先做首页布局（header + 商品列表 + footer）
  2. 再做商品卡片组件
  3. 再做购物车功能
  4. …

4. 配置 > 每次重复

  • ✅ 设置 Custom Instructions（技术栈、代码规范）
  • ✅ 建立团队 Prompt 模板库
  • ✅ 常用需求固化成可复用模板

类比：
就像你不会每次做菜都从买锅买碗开始，工具和调料要常备。Prompt 模板也是一样。

回到开头那个问题

还记得文章开头说的场景吗？

产品经理：“帮我做个登录页面。”
AI：“好的。”（然后生成一堆不对的代码）

现在你知道问题出在哪了：不是 AI 不行，是你没说清楚。

掌握 Prompt Engineering，本质是掌握"需求结构化"的能力。
这能力你本来就有，只是没用对地方。

从明天开始，用五要素框架重写一个需求。
你会发现，AI 突然"变聪明"了。

其实不是 AI 变了，是你学会了和它说话。

参考资源

官方文档

社区资源

中文资源

赏

The best way to give someone money, is to be a customer.Whatever they’re selling, just buy it. --纳瓦尔

支付宝

扫一扫，分享到微信

微信分享二维码

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

很惭愧<br><br>只做了一点微小的工作<br>谢谢大家