2.1 Prompt Engineering：不是咒语，是任务定义¶
Prompt Engineering 关注任务边界是否写到模型难以误解。它解决一次任务怎么说清楚，不解决项目事实缺失和流程失控。
最小四段式¶
Goal:
我要达成什么结果，以及为什么重要。
Context:
相关背景、文件、报错、截图、业务规则。
Constraints:
不能做什么，必须遵守什么，范围到哪里为止。
Done When:
什么现象、测试、命令或验收标准证明完成。
这套结构可以用于网页对话，也可以用于 Codex / Claude Code / OpenCode。区别在于：网页对话用它澄清任务，本地 Agent 用它开始读仓库和制定计划。
Done When 保留英文，是因为它常作为任务模板字段出现。它的意思是“完成条件”：必须能用命令、现象、测试或人工检查验证。
任务示例¶
差的 prompt：
帮我优化登录页面。
可执行的 prompt：
Goal:
让登录页面在提交请求期间显示 loading，避免重复提交。
Context:
登录页在 `src/pages/login`，请求封装在 `src/lib/api`。
Constraints:
不改接口，不引入新状态管理库，不重构认证流程。
Done When:
点击提交后按钮进入 loading；
重复点击不会再次发请求；
成功或失败后恢复；
相关测试通过。
prompt 适合解决的问题¶
适合：
- 单文件或少量文件修改。
- 解释概念。
- 技术方案比较。
- PRD 初稿。
- 明确 bug 的定位入口。
不适合：
- 复杂长任务。
- 多模块协作。
- 需要长期复用的团队规范。
- 需要连接外部工具和内部系统。
- 需要多次验证、回滚和复盘的任务。
常见误区¶
误区 1：prompt 越长越好¶
写得长不代表写得清楚。无关背景会稀释重点，旧结论和新结论混在一起还会误导 Agent。
改成四条硬信息：
- 目标短。
- 约束硬。
- 上下文给路径。
- 验收标准可验证。
误区 2：让 AI 自己猜验收标准¶
如果你不定义完成标准，AI 会把“生成了一些代码”当成完成。
必须写清楚：
跑什么命令。
看到什么结果。
哪些边界必须覆盖。
哪些改动不能出现。
误区 3：把愿望当任务¶
“做一个 Notion”不是任务。
“实现 notes 列表、新建、编辑、删除，不做协作和富文本”才是任务。
本节练习¶
选一个你最近想做的功能，把它改写成四段式 prompt：
GoalContextConstraintsDone When
如果你写不出 Done When，需求还没有清楚到可以交给 Agent。