2.1 Prompt Engineering：不是咒语，是任务定义

Prompt Engineering 的核心不是“写得更玄”，而是把任务边界说清楚。

最小四段式

Goal:
我要达成什么结果，以及为什么重要。

Context:
相关背景、文件、报错、截图、业务规则。

Constraints:
不能做什么，必须遵守什么，范围到哪里为止。

Done When:
什么现象、测试、命令或验收标准证明完成。

这套结构可以用于网页对话，也可以用于 Codex / Claude Code。

任务示例

差的 prompt：

帮我优化登录页面。

好的 prompt：

Goal:
让登录页面在提交请求期间显示 loading，避免重复提交。

Context:
登录页在 `src/pages/login`，请求封装在 `src/lib/api`。

Constraints:
不改接口，不引入新状态管理库，不重构认证流程。

Done When:
点击提交后按钮进入 loading；
重复点击不会再次发请求；
成功或失败后恢复；
相关测试通过。

prompt 适合解决什么

适合：

• 单文件或少量文件修改。
• 解释概念。
• 技术方案比较。
• PRD 初稿。
• 明确 bug 的定位入口。

不适合：

• 复杂长任务。
• 多模块协作。
• 需要长期复用的团队规范。
• 需要连接外部工具和内部系统。
• 需要多次验证、回滚和复盘的任务。

常见误区

误区 1：prompt 越长越好

越长不等于越清楚。无关背景会稀释重点。

更好的做法是：

• 目标短。
• 约束硬。
• 上下文给路径。
• 验收标准可验证。

误区 2：让 AI 自己猜验收标准

如果你不定义完成标准，AI 会把“生成了一些代码”当成完成。

必须写清楚：

跑什么命令。
看到什么结果。
哪些边界必须覆盖。
哪些改动不能出现。

误区 3：把愿望当任务

“做一个 Notion”不是任务。

“实现 notes 列表、新建、编辑、删除，不做协作和富文本”才是任务。

本节练习

选一个你最近想做的功能，把它改写成四段式 prompt：

1. Goal
2. Context
3. Constraints
4. Done When

如果你写不出 Done When，说明需求还没清楚到可以交给 Agent。