AI总写错代码？掌握这5个Prompt技巧，效率提升50%

周五下午四点半，我盯着 Cursor 刚生成的代码，整个人都麻了。

本来只是想让它帮我写个用户登录接口，结果它给我搞了个 300 行的怪物——参数类型全错、数据库连接写死在代码里、还混用了三种不同的错误处理方式。我深吸一口气，删掉重来。第二次，它又把我没让它动的配置文件改得面目全非。

那一刻我突然意识到：问题不在 AI，在于我压根没告诉它”该做什么、不该做什么”。

阿里云 - 开发者上云首选，轻量服务器专享 8.5 折优惠，助力项目快速上线

领取 8.5 折优惠 →推广

你有没有这种感觉？AI 编程工具装上了，热情也很高，但用了一段时间发现——生成的代码要么牛头不对马嘴，要么看起来对但跑起来就炸。反复修改几轮后，还不如自己手写来得快。

说实话，我之前也觉得 Prompt 工程没那么重要，不就是跟 AI 说几句话嘛，能难到哪去？直到我看到同事用同样的 Cursor，写同样的功能，十分钟搞定我折腾一小时的活儿。差距在哪？他的 Prompt 结构清晰、上下文完整、边界明确。

这篇文章会手把手教你 5 个立刻见效的 Cursor Prompt 技巧。不是什么高深理论，都是实战总结出来的”大白话公式”。看完你就知道怎么让 AI 真正读懂你的需求，生成准确、可用的代码。

为什么你的 Prompt 总是”失效”

AI 不是读心术，它只能”看到”你给的信息

很多人以为 AI 很聪明，应该能猜到我想要什么。错了。AI 再强大，也只是个”高级文本补全器”——它只能基于你提供的信息做推理。你没说的东西，它就只能靠”猜”。

这就像你打电话让朋友帮忙买咖啡，只说了一句”帮我买杯咖啡”。他到了店里一脸懵：要美式还是拿铁？大杯还是中杯？加糖吗？最后他只能凭感觉随便买一杯。AI 也一样。

特别是在大型项目里，AI 的”失忆”问题更明显。它的上下文窗口是有限的，没法把你整个代码库都装进”脑子”里。你让它修改一个函数，它可能压根不知道这个函数被其他 20 个地方调用过，一改就崩盘。

常见的三种 Prompt 灾难

灾难1：过于模糊

❌ “帮我实现排序”

这种指令就像给 GPS 输入”我要去北京”——去北京哪里？用什么交通工具？什么时候到？AI 收到这种指令，只能自由发挥。它可能给你写个冒泡排序，也可能调用一个你项目里根本没有的第三方库。

✅ “在 utils/array.ts 文件中添加一个函数，对用户列表按注册时间降序排序，使用原生 Array.sort() 方法，不引入新依赖”

看到区别了吗？后者明确了：在哪个文件、操作什么数据、用什么方法、有什么限制。

灾难2：缺乏上下文

❌ “添加错误处理”

AI：添加到哪里？处理什么错误？用 try-catch 还是错误码？返回什么格式？

这就像医生问你”哪里不舒服”，你只回一个”疼”。医生能给你看病吗？不能。

✅ “在 api/login.ts 的 handleLogin 函数中添加错误处理：

• 捕获网络请求失败（使用 try-catch）
• 返回统一的错误格式 { success: false, error: string }
• 参考现有的 api/register.ts 的错误处理方式”

灾难3：没有约束条件

❌ “优化这个组件的性能”

AI 收到这个指令，可能把你的代码改得面目全非——引入新库、修改状态管理、甚至重写整个组件架构。你想要的只是加个 React.memo，结果它给你来了个大手术。

✅ “优化 UserList.tsx 组件的性能：

• 只能使用 React.memo 或 useMemo
• 不要修改 组件的 props 接口
• 不要引入 新的第三方库”

AI “幻觉”的真相

你有没有遇到过：AI 生成的代码里调用了一个根本不存在的函数？或者引用了你项目里没有的变量？这就是 AI 的”幻觉”。

根据 Cursor 官方的最佳实践研究，提供清晰的上下文信息可以减少 70% 的幻觉问题。为什么？

AI 在信息不完整时会自动”脑补”。你没告诉它现有的代码长什么样，它就根据”常见模式”推测。比如你让它写登录功能，它可能默认你有一个 authService.login() 方法——但你项目里根本没有这个东西。

解决办法很简单：把相关的现有代码明确展示给 AI。

我现在每次写 Prompt，都会先问自己三个问题：

1. AI 知道我在哪个文件操作吗？
2. AI 知道现有代码的结构吗？
3. AI 知道什么能改、什么不能改吗？

这三个问题答不上来，就别急着发 Prompt。

结构化 Prompt 的黄金公式

5W1H 框架：让 AI 秒懂你的需求

记者写新闻有个经典公式：5W1H（Who、What、When、Where、Why、How）。写 Prompt 也能用这套方法。

• What（目标）：你要 AI 做什么？
• Why（原因）：为什么要这样做？（帮 AI 理解意图）
• Where（位置）：在哪个文件/模块操作？
• When（时机）：什么情况下触发？
• Who（对象）：操作的数据对象是什么？
• How（方式）：使用什么技术栈/库？

听起来复杂？其实不用每次都写全。核心是：让 AI 不用猜。

举个例子，你想让 AI 添加一个数据验证功能：

❌ 模糊版：

添加用户输入验证

✅ 5W1H版：

**What**: 在用户注册表单添加输入验证
**Where**: src/components/RegisterForm.tsx
**Who**: 验证用户名、邮箱、密码三个字段
**How**: 使用现有的 Yup 库（已安装）
**When**: 用户点击提交按钮时触发
**Why**: 防止无效数据提交到后端

AI 收到这个指令，基本不会跑偏。

Cursor 官方推荐的结构化模板

Cursor 团队总结了一个更实用的模板，我自己用了几个月，真的好用：

## Goal（目标）
[一句话说明要实现什么]

## Context（上下文）
[当前文件、相关代码、技术栈]

## Current Behavior（当前行为）
[现在的状态是什么]

## Desired Behavior（期望行为）
[你希望达到什么效果]

## Acceptance Criteria（验收标准）
[什么情况下算完成]

## Constraints（约束）
[不能修改什么、必须遵守什么规则]

这个模板最妙的地方在于 Constraints（约束） 部分。很多人写 Prompt 只说”要做什么”，不说”不要做什么”，结果 AI 自由发挥得太过头。

实战案例：React 登录功能

让我用一个真实场景对比一下。假设你要给 React 项目添加用户登录功能。

❌ 模糊 Prompt（新手常见）：

帮我实现用户登录功能

AI 收到这个，可能给你写个 200 行的组件，引入一堆你不需要的库，甚至自己”发明”一个不存在的 API 接口。

✅ 结构化 Prompt（高手做法）：

## Goal
在 React 项目中实现用户登录功能

## Context
- 项目使用 React 18 + TypeScript
- 状态管理：Redux Toolkit
- 已有 API 服务：src/services/authService.ts（包含 login 方法）
- UI 库：Ant Design 5.x

## Current Behavior
登录页面（src/pages/Login.tsx）只有静态 UI，没有交互逻辑

## Desired Behavior
1. 用户输入用户名和密码后点击"登录"
2. 调用 authService.login() 进行身份验证
3. 成功：保存 token 到 Redux，跳转到 /dashboard
4. 失败：显示错误提示（使用 Ant Design 的 message.error）

## Acceptance Criteria
- [ ] 表单验证：用户名和密码不能为空
- [ ] 登录过程显示 loading 状态
- [ ] 密码输入框使用 type="password"
- [ ] 通过 ESLint 和 TypeScript 检查

## Constraints
- **不要修改** authService.ts 文件
- **不要引入** 新的第三方库
- **必须使用** 现有的 Redux slice（src/store/authSlice.ts）

对比一下生成效果：

第一个 Prompt，AI 可能给你这样的代码：

// ❌ AI 自由发挥的结果
import { useState } from 'react';
import axios from 'axios'; // 你没让它装新库，它自己装了

function Login() {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');

  const handleLogin = async () => {
    // 直接调用不存在的 API
    const res = await axios.post('/api/auth/login', { username, password });
    localStorage.setItem('token', res.data.token); // 没用 Redux
  };

  // ... 剩下 150 行你不需要的代码
}

第二个 Prompt，AI 会严格按照你的要求生成：

// ✅ 结构化 Prompt 的结果
import { useState } from 'react';
import { Form, Input, Button, message } from 'antd';
import { useDispatch } from 'react-redux';
import { login } from '@/services/authService';
import { setToken } from '@/store/authSlice';
import { useNavigate } from 'react-router-dom';

export default function Login() {
  const [loading, setLoading] = useState(false);
  const dispatch = useDispatch();
  const navigate = useNavigate();

  const handleSubmit = async (values: { username: string; password: string }) => {
    setLoading(true);
    try {
      const { token } = await login(values.username, values.password);
      dispatch(setToken(token));
      navigate('/dashboard');
    } catch (error) {
      message.error('登录失败，请检查用户名和密码');
    } finally {
      setLoading(false);
    }
  };

  return (
    <Form onFinish={handleSubmit}>
      <Form.Item name="username" rules={[{ required: true, message: '请输入用户名' }]}>
        <Input placeholder="用户名" />
      </Form.Item>
      <Form.Item name="password" rules={[{ required: true, message: '请输入密码' }]}>
        <Input.Password placeholder="密码" />
      </Form.Item>
      <Button type="primary" htmlType="submit" loading={loading}>
        登录
      </Button>
    </Form>
  );
}

看到区别了吗？第二份代码：

• 使用了你指定的 Ant Design 组件
• 调用了你现有的 authService
• 用了 Redux 存储 token
• 有表单验证和 loading 状态
• 没有引入任何新依赖

这就是结构化 Prompt 的威力。

5个立刻见效的 Prompt 技巧

技巧1：先规划，再编码（Plan Mode）

这是我用了之后最惊喜的功能。

以前我都是直接让 AI 动手写代码，结果经常翻车——改了不该改的文件、删了关键代码、逻辑乱七八糟。后来发现 Cursor 有个 Plan 模式（按 Shift+Tab 切换），完全改变了我的工作流。

Plan 模式的逻辑是：AI 先思考，再动手。

具体流程：

Railway - 现代化的部署平台，告别繁琐运维，让代码分钟级上线

立即开始 →推广

1. 你描述需求
2. AI 分析你的代码库，提出问题（比如”你希望保留现有的错误处理吗？”）
3. AI 制定一个行动计划（会修改哪些文件、添加什么功能）
4. 你审核和修改这个计划
5. 确认后，AI 才开始写代码

为什么这么有用？因为它给了你一个”后悔的机会”。

举个例子，上周我让 AI 给项目添加国际化功能。在 Plan 模式下，AI 先给我列了个计划：

计划：
1. 安装 i18next 和 react-i18next
2. 创建 src/i18n/locales/ 目录
3. 修改 App.tsx 添加 I18nProvider
4. 更新所有组件的硬编码文本（约 30 个文件）

我一看第 4 步，立刻叫停：“等等，别动那 30 个文件，我先做 3 个页面试试。“然后修改了计划，AI 才开始执行。

如果没有 Plan 模式，AI 可能已经把 30 个文件全改了，我再想恢复就麻烦了。

实战价值：避免 AI 直接动手搞砸代码，特别适合大型重构和新功能开发。

技巧2：提供具体的代码示例

AI 有个特点：它很擅长”照葫芦画瓢”。你给它看几个例子，它就能模仿你的风格。这在技术上叫 Few-shot Prompting。

场景：你想让 AI 帮你写 API 接口，但你有自己的代码风格和错误处理习惯。

❌ 没有示例的 Prompt：

帮我写一个获取用户列表的 API 接口

AI 可能给你写成这样：

app.get('/users', (req, res) => {
  // 风格完全不是你的
  const users = db.getUsers();
  res.json(users);
});

✅ 提供示例的 Prompt：

帮我写一个获取用户列表的 API 接口，参考以下现有接口的风格：

**示例1**：
\`\`\`typescript
export const getProductById = async (req: Request, res: Response) => {
  try {
    const { id } = req.params;
    const product = await productService.findById(id);

    if (!product) {
      return res.status(404).json({
        success: false,
        error: 'Product not found'
      });
    }

    res.json({ success: true, data: product });
  } catch (error) {
    logger.error('Error fetching product:', error);
    res.status(500).json({
      success: false,
      error: 'Internal server error'
    });
  }
};
\`\`\`

请按照这个风格实现 getUserList 接口：
- 使用 async/await
- 统一的错误处理
- 返回格式：{ success, data/error }
- 使用 logger 记录错误

AI 会生成这样的代码：

export const getUserList = async (req: Request, res: Response) => {
  try {
    const users = await userService.findAll();
    res.json({ success: true, data: users });
  } catch (error) {
    logger.error('Error fetching users:', error);
    res.status(500).json({
      success: false,
      error: 'Internal server error'
    });
  }
};

完美匹配你的代码风格。

小技巧：在项目根目录创建一个 prompts/templates.md 文件，把常用的代码示例存在里面，需要时直接复制粘贴到 Prompt 里。

技巧3：明确”不要做什么”

这个技巧救过我无数次。

AI 默认会尽力”帮你”——但有时候它的”帮助”是你不需要的。比如你让它修复一个 bug，它可能顺便把周围的代码也”优化”了一遍，结果引入新的问题。

根据 Cursor 团队的研究，明确约束条件可以减少 60% 的意外修改。

实战案例：

❌ 没有约束的 Prompt：

修复 UserList 组件的分页 bug

AI 可能会：

• 修改组件的 props 接口（导致父组件报错）
• 重写整个分页逻辑（引入新 bug）
• 引入新的第三方库（增加依赖）

✅ 明确约束的 Prompt：

修复 UserList 组件的分页 bug

**约束**：
- **不要修改** 组件的 props 接口（TypeScript 类型）
- **不要引入** 新的第三方库
- **只修改** handlePageChange 函数内部逻辑
- **不要改动** 样式和 UI 结构

AI 会严格遵守这些规则，只改必要的部分。

还有一个进阶技巧：让 AI 先列出它的假设。

修复分页 bug，在开始前请列出你的假设：
1. 你认为 bug 的原因是什么？
2. 你打算修改哪些代码？
3. 你会引入什么依赖或改变什么接口吗？

AI 会先回答这些问题，你可以检查它的理解是否正确，再让它动手。这招特别适合复杂的 bug 修复。

技巧4：用验收标准作为锚点

这个技巧是从敏捷开发借鉴来的。

在 Prompt 的开头（不是结尾）定义验收标准，AI 会以此为目标进行推理，就像给它设定了”必须达成的目标”。

对比一下：

❌ 没有验收标准：

重构 DataTable 组件的性能

AI：重构成什么样算完成？用什么方法？衡量标准是什么？（它只能瞎猜）

✅ 有验收标准：

重构 DataTable 组件的性能

**验收标准**（必须全部满足）：
- [ ] 渲染 1000 行数据时，FPS 不低于 55
- [ ] 使用 React.memo 和 useMemo
- [ ] 不修改组件的 API（props 和 callbacks）
- [ ] 通过现有的所有单元测试
- [ ] 代码必须通过 ESLint 检查

**当前问题**：
渲染 500 行数据时，FPS 掉到 20，滚动卡顿

AI 会以这些标准为”北极星”，确保每一步改动都朝着这个方向。如果它发现某个优化会破坏测试或改变 API，它会自动避开。

好处：防止 AI 做”看起来有用但实际没用”的改动。

技巧5：区分 Inline Edit 和 Agent Mode

很多人不知道，Cursor 有两种工作模式，用对场景效率能翻倍。

Inline Edit（Cmd+K）：

• 适用：单文件小改动、重构、bug 修复
• 特点：快速、精准、不会跨文件乱改
• 举例：改个函数名、加个参数、修个 bug

Agent Mode（Cmd+I 或 Chat）：

• 适用：多文件推理、新功能开发、架构级改动
• 特点：可以分析整个代码库、跨文件操作、制定计划
• 举例：添加新功能、大规模重构、技术栈迁移

我之前总是用 Agent Mode 干所有事情，结果效率很低。后来发现：简单任务用 Inline Edit，复杂任务用 Agent Mode。

Vultr - 高性能 NVMe 云服务器，32 个全球节点可选，支持一键部署 Docker

查看定价 →推广

决策树：

需要修改多个文件吗？
├─ 是 → Agent Mode
└─ 否 → 需要理解复杂上下文吗？
    ├─ 是 → Agent Mode
    └─ 否 → Inline Edit

举个例子：

场景1：把函数 getUserData 重命名为 fetchUserData
→ 用 Inline Edit：选中函数名，Cmd+K，输入”重命名为 fetchUserData”，秒改。

场景2：添加用户权限管理功能（涉及 Model、Controller、View、Config 多个文件）
→ 用 Agent Mode：它会分析项目结构，问你问题，制定计划，然后跨文件实现。

选错模式的后果：

• Inline Edit 干复杂任务 → 它看不到全局，容易遗漏关联改动
• Agent Mode 干简单任务 → 杀鸡用牛刀，等待时间长，还可能过度发挥

小技巧：如果不确定用哪个，先用 Agent Mode 的 Plan 功能看看它打算改几个文件。如果只改 1-2 个文件，切回 Inline Edit 更快。

进阶技巧：打造你的 Prompt 工具箱

创建可复用的 Prompt 模板

写了一段时间 Prompt 后，你会发现很多任务是重复的——新增 API 端点、添加组件、写单元测试、数据库迁移……

与其每次从头写，不如把常用的 Prompt 做成模板。

我现在的项目根目录都有个 prompts/ 文件夹，里面按任务类型分类：

prompts/
├── api-endpoint.md       # 新增 API 端点模板
├── react-component.md    # React 组件模板
├── unit-test.md          # 单元测试模板
├── migration.md          # 数据库迁移模板
└── refactor.md           # 重构模板

示例：API 端点模板（prompts/api-endpoint.md）

# 新增 API 端点模板

## Goal
在 [模块名] 中添加 [功能描述] 的 API 端点

## Context
- 路由文件：src/routes/[模块].routes.ts
- 控制器：src/controllers/[模块].controller.ts
- 服务层：src/services/[模块].service.ts
- 数据模型：src/models/[模块].model.ts

## Desired Behavior
**请求**：
- Method: [GET/POST/PUT/DELETE]
- Path: /api/[路径]
- Body/Query: [参数说明]

**响应**：
- 成功：{ success: true, data: [...] }
- 失败：{ success: false, error: "..." }

## Acceptance Criteria
- [ ] 遵循现有的错误处理模式（参考其他端点）
- [ ] 使用 async/await
- [ ] 添加输入验证（使用 Joi 或 Zod）
- [ ] 记录错误日志（使用 logger）
- [ ] 通过 TypeScript 类型检查

## Constraints
- **不要修改** 现有的路由配置结构
- **不要引入** 新的第三方库（除非必要且说明理由）
- **必须使用** 现有的数据库连接（不要创建新连接）

需要时，复制模板，填空即可。

团队协作福利：团队成员共享这些模板，大家写出来的代码风格一致，新人上手也快。

使用 Agent Skills（2026 新特性）

这是 2026 年 AI 编程工具的一个大趋势。

简单来说，Agent Skills 就是可以复用的”AI 应用程序”。你可以把最佳实践封装成一个 Skill，需要时直接调用，就像调用一个函数。

举个例子：

我之前写博客文章时，每次都要手动给文章配图。后来我创建了一个 Agent Skill，自动帮我：

1. 分析文章内容
2. 识别需要配图的章节
3. 生成图片提示词
4. 标注插入位置

现在我只需要运行这个 Skill，它就自动完成整个流程。

如何创建 Agent Skills？

在 Cursor 中，你可以在 .cursor/ 目录下创建自定义 Skill：

.cursor/
└── skills/
    ├── code-review.md      # 代码审查 Skill
    ├── test-generator.md   # 测试生成 Skill
    └── api-doc.md          # API 文档生成 Skill

最新动态：2025 年 12 月，Agent Skills 成为开放规范，Claude Code、Cursor、VS Code、GitHub Copilot 等主流工具都已支持。这意味着你写的 Skill 可以跨工具使用。

老实讲，我刚开始觉得 Skills 有点”过度工程化”，直到我在一个多人协作项目中用了团队共享的 Skills——代码质量和效率立刻上了一个台阶。

优化项目结构，辅助 AI 理解

AI 不是人，它理解代码库的方式和我们不一样。一个结构清晰的项目，AI 的表现会好得多。

实用建议：

1. 创建 /prompts 文件夹
   存放常用的 Prompt 模板和代码示例，方便复制粘贴。

2. 使用 .cursor/ 目录存放项目上下文
   创建一个 .cursor/context.md 文件，写明：

   • 项目技术栈
   • 代码风格规范
   • 常用的第三方库
   • 特殊约定（比如”我们用 _ 开头命名私有方法”）

   AI 会自动读取这个文件，理解你的项目特点。

3. 清晰的目录结构和命名
   AI 会根据文件名和目录结构推测代码用途。如果你的文件叫 utils.ts、helpers.ts、common.ts，AI 会懵——这些都是什么？

   改成这样更好：

   utils/
   ├── date-formatter.ts
   ├── string-validator.ts
   └── array-helpers.ts

我有个经验：项目结构越混乱，AI 的幻觉越多。整理好目录结构，不仅人看着舒服，AI 也更懂你。

避坑指南：常见错误与解决方案

错误1：信息过载——一次性给太多

刚开始用 AI 编程时，我犯过这样的错：把整个需求文档、三个相关文件、五篇参考文章全粘贴给 AI，心想”信息越多越好”。

结果呢？AI 被淹没了。

它要么抓不住重点，要么理解偏差，要么干脆超时报错。就像你给一个人同时讲十件事，他记住的反而最少。

正确做法：渐进式披露

阿里云 - 开发者上云首选，轻量服务器专享 8.5 折优惠，助力项目快速上线

领取 8.5 折优惠 →推广

不要一开始就把所有信息倒给 AI，而是：

1. 先说核心需求
2. AI 有疑问时，再提供详细信息
3. 分步骤给出上下文

举个例子：

❌ 信息过载版：

帮我重构用户认证模块。
[粘贴 500 行代码]
[粘贴需求文档]
[粘贴三篇技术文章]
要求：性能提升、安全加固、代码优雅...

✅ 渐进式版本：

第一轮：
我想重构用户认证模块，目标是提升安全性。
当前使用 JWT，存在的问题：token 没有刷新机制。
你需要了解什么信息？

[AI 会问：现在的 token 过期时间是多久？存储在哪里？]

第二轮：
token 过期时间 1 小时，存储在 localStorage。
这是当前的认证逻辑（关键代码）：
[只粘贴核心的 50 行代码]

你打算怎么改进？

[AI 给出方案，你确认后再让它动手]

这样做的好处：AI 能聚焦核心问题，你也能随时纠正它的理解。

错误2：过度依赖 AI，不审查代码

这个坑我踩得最狠。

有一次，AI 帮我写了个数据处理函数，跑起来没报错，单元测试也过了。我看着代码挺工整，就直接合并了。结果上线后发现——这个函数在边缘情况下会返回错误结果，导致用户数据错乱。

AI 生成的代码，特别是”看起来完全正确”的代码，最危险。

警示：AI 生成速度越快，你越需要仔细审查。

我现在养成了习惯，AI 写完代码后，我会问自己三个问题：

1. 边缘情况：空数组、null、undefined、极大值、极小值，处理了吗？
2. 副作用：这段代码会影响其他模块吗？
3. 性能：有没有死循环、内存泄漏、不必要的重复计算？

实用技巧：让 AI 自己审查代码。

请审查你刚才生成的代码，回答以下问题：
1. 如果输入是空数组，会发生什么？
2. 这段代码有性能问题吗？
3. 你使用了哪些假设？这些假设在所有情况下都成立吗？

AI 会重新检查代码，经常能发现自己的问题。

错误3：期望一次性得到完美答案

很多人把 AI 当成”魔法按钮”——输入需求，立刻得到完美代码。这不现实。

AI 更像一个协作者，而不是”全自动代码生成器”。最高效的工作方式是迭代对话：

1. 你描述需求
2. AI 给出初步方案或问题
3. 你确认、修正、补充
4. AI 根据反馈优化
5. 重复 3-4，直到满意

正确示范：

你：帮我实现用户列表的搜索功能

AI：好的，我打算添加一个搜索框，实时过滤用户列表。
    你希望搜索哪些字段？用户名、邮箱，还是其他？

你：搜索用户名和邮箱，但不需要实时过滤，
    点击"搜索"按钮后再触发

AI：明白了。那是前端过滤还是发请求到后端？

你：前端过滤，数据量不大

AI：好的，我会使用 Array.filter()，
    先给你看一下实现计划...

看到了吗？这是对话，不是”下命令”。

技巧：使用 Cursor 的”Show Work”模式（在设置中开启），AI 会展示它的推理步骤，你能看到它是怎么思考的，更容易发现问题。

番外：别把时间浪费在”调教” Prompt 上

最后说个反直觉的建议：不要过度追求完美 Prompt。

我见过有人花 30 分钟精心设计一个 Prompt，结果生成的代码还不如自己写。这就本末倒置了。

Prompt 工程的目的是提升效率，不是展示你的 Prompt 写得多漂亮。如果一个任务你自己 10 分钟能写完，就别花 20 分钟写 Prompt 了。

什么时候值得用 AI？

• ✅ 重复性任务（批量修改、模板生成）
• ✅ 不熟悉的领域（新技术栈、新库）
• ✅ 复杂但有模式的任务（API 端点、CRUD 操作）

什么时候不值得？

• ❌ 简单到闭着眼睛能写的代码
• ❌ 需要深度思考的算法设计
• ❌ 高度定制化、没有参考模式的代码

记住：AI 是工具，不是目的。能快速解决问题才是王道。

结论

写好 Prompt 不是什么高深技术，核心就三件事：说清楚目标、给足上下文、定好边界。

回顾一下这篇文章的 5 个关键技巧：

1. 用 Plan Mode 先规划——给自己一个”后悔的机会”
2. 提供代码示例——让 AI 照着你的风格来
3. 明确约束条件——告诉 AI 什么不能动
4. 设定验收标准——给 AI 一个明确的目标
5. 选对工作模式——简单任务 Inline Edit，复杂任务 Agent Mode

掌握这些后，你会发现 AI 不再是一个”智障助手”，而是真正能提升效率的编程伙伴。我自己用了这些方法后，AI 生成代码的准确率至少提升了 50%，很多重复性工作现在 10 分钟就能搞定。

现在就打开 Cursor，用结构化模板试试看。从下一个功能开始，按照”Goal - Context - Desired Behavior - Constraints”的格式写 Prompt。你会立刻感受到不同。

记住：AI 编程的未来不是”AI 替代程序员”，而是”会用 AI 的程序员替代不会用的”。这个技能差距，就从你写的第一个高质量 Prompt 开始拉开。

18 分钟阅读 · 发布于: 2026年1月29日 · 修改于: 2026年2月4日

Easton

技术开发