路线阶段：AI Vibe Coding 第 2 章。
本章目标：把提示词从“灵感输入”升级为“可执行任务说明书”。
学习目标
完成本章后，你应该能做到：
- 将模糊需求拆成 AI 可执行的最小任务单元。
- 在提示词中明确输入、约束、输出与验收标准。
- 用结构化输出减少遗漏与歧义。
- 通过可验证断言降低返工率。
为什么提示词经常失效
常见失败原因：
- 目标太大，一次让 AI 完成端到端复杂改造。
- 约束缺失（性能、兼容、不可改范围）。
- 输出格式不固定，难自动检查。
- 验收条件不明确，只能“靠感觉”。
任务分解框架
推荐 4 层拆分：
Epic：业务目标（例如“重构关卡结算页”）。Feature：功能块（数据聚合、UI渲染、埋点）。Task：可独立提交的小任务。Check：每个任务对应验收断言。
原则：每个 Task 最好控制在 1~4 个文件变更。
提示词契约模板
[目标]
为结算页新增“本局升级路径”模块
[输入上下文]
- 文件A: 结算数据聚合
- 文件B: 结算面板UI
- 文件C: 升级事件定义
[修改范围]
只允许改 A/B/C，不允许改战斗系统
[硬约束]
- WebGL内存增量 < 5MB
- 不新增第三方依赖
- 保持旧接口兼容
[输出要求]
1. 列出修改文件
2. 给出关键代码片段
3. 给出测试步骤
4. 给出风险点
[验收断言]
- 构建通过
- 3个结算场景显示正确
- 无新增 lint 错误结构化输出协议
建议 AI 输出统一为：
Changes：文件级改动清单Why：每处改动理由Validation：已执行验证Risks：剩余风险
这样方便后续自动收敛到 PR 模板。
约束注入技巧
1. 明确不可改区域
不要改 xxx 模块 要具体到文件/目录。
2. 明确兼容要求
例如：
- 保持公开接口签名不变
- 保持存档版本兼容
- 保持现有埋点字段不变
3. 明确性能预算
例如：
- 每帧不新增 GC 分配
- UI 刷新频率不高于 20Hz
可验证断言设计
避免“看起来正常”，要写可执行断言：
npm run build必须通过- 指定页面截图比对通过
- 指定单测用例通过
- 指定关键日志出现
提示词示例：坏 vs 好
坏提示词
帮我优化结算页，做得更酷一点。好提示词
目标：新增“本局升级路径”时间线
范围：仅改结算聚合与结算UI
约束：不改战斗逻辑，不新增依赖
输出：文件清单 + 代码 + 测试步骤 + 风险
验收：构建通过，3个结算样例截图一致与工作流联动
- Planner 先输出任务契约。
- Builder 按契约执行并产出结构化结果。
- Reviewer 根据验收断言快速判定。
- CI 自动执行断言脚本。
常见坑
坑 1：一次提示词塞太多目标
应拆成多个可提交任务，降低失败面。
坑 2：约束只写“尽量”
AI 很难判断“尽量”的边界，必须量化。
坑 3：没有失败路径
要写清“如果找不到文件/无法验证应如何返回”。
本月作业
完成你团队的提示词标准化：
- 固化一版“任务契约模板”。
- 选 5 个真实任务试跑并统计一次通过率。
- 复盘失败任务，补齐缺失约束。
下一章：AI Vibe Coding 03《上下文工程：如何给 AI 恰到好处的信息密度》。