prompting.md

AI 编程提示词技巧

这不是通用的 prompt engineering 教程，而是专门针对 AI 编程场景的提示词技巧。不管你用 Claude Code、Cursor 还是 Copilot，这些原则都适用。

---

核心原则

1. 具体 > 模糊

AI 不会读心术。你说得越具体，结果越好。

❌ "帮我优化这个函数"
✅ "这个函数处理 10 万条数据时需要 30 秒，
    目标是降到 5 秒以内。
    可以考虑批处理、缓存、或者换算法。
    不要改函数签名。"

2. 约束 > 自由

没有约束的 AI 会发挥过度。明确告诉它什么不要做。

❌ "加个缓存"
✅ "给 getUserById 加缓存。
    用内存缓存（Map），不要引入 Redis。
    TTL 5 分钟。
    不要改其他函数。
    不要加新依赖。"

3. 分步 > 一次

复杂任务拆成步骤，每步确认再继续。

❌ "重构整个认证模块"
✅ "重构认证模块，分三步走：
    第一步：先分析现在的问题，列出来让我确认。
    第二步：给出重构方案（2-3 个选项）。
    第三步：确认方案后再开始改代码。
    现在先做第一步。"

4. 示例 > 描述

给一个例子比描述半天清楚。

❌ "返回值用统一格式"
✅ "返回值统一用这个格式：
    {
      'code': 200,
      'data': { ... },
      'message': 'success'
    }
    错误时：
    {
      'code': 400,
      'data': null,
      'message': '参数 email 格式不正确'
    }"

5. 参考 > 从零开始

指向已有代码比描述风格有效得多。

❌ "写一个新的 API 接口"
✅ "参考 src/api/users.ts 的风格，
    写一个 src/api/orders.ts。
    路由、错误处理、返回格式都保持一致。"

---

常用提示词模式

分析模式（先看后说）

先读 [文件/目录]，分析 [什么问题]。
列出你的发现，不要直接改代码。
等我确认后再动手。

实现模式（明确需求）

在 [位置] 实现 [功能]。
要求：
1. [具体要求 1]
2. [具体要求 2]
参考 [现有文件] 的风格。
不要 [禁止事项]。

修复模式（给证据）

[错误描述/日志/截图]。
先分析可能的原因（不要猜，看代码和日志）。
确认根因后再给修复方案。
只改必要的代码，不要顺手重构。

审查模式（定范围）

审查 [文件/PR]，重点关注：
1. [关注点 1，如性能]
2. [关注点 2，如安全]
3. [关注点 3，如边界情况]
按严重程度排序，给出修改建议。

---

反模式

反模式	为什么不好	改成
"帮我写个网站"	范围太大，AI 不知道从哪开始	拆成具体任务
"优化一下"	优化什么？性能？可读性？体积？	说清楚优化目标和指标
"写最好的代码"	"最好"没有定义	说清楚标准（可测试、可维护等）
一次给 10 个需求	AI 会顾此失彼	一次一个，做完确认再下一个
不给错误信息就说"修 bug"	AI 只能猜	贴上错误日志、复现步骤