问题：AI 项目的高不确定性
AI 项目和传统软件项目有个根本区别：
你在选题时不知道 AI 能不能真的做到。
传统项目："做一个 CRUD 后台" → 确定性 99%，能做完。 AI 项目："用 AI 做智能客服" → 做到第三周发现：这个场景的对话质量达不到上线标准。
这意味着选题变更（Pivot）是正常行为，不是"没想清楚"的表现。
但完全自由的 Pivot 也有问题：
- 有人每两周换一个方向，最后什么都没完成
- 有人一直在"探索"，从不进入"执行"
- 截止日前一周还在想"要不要换"
Pivot Protocol 框架
三个时间窗口
| 窗口 | 时间 | 允许做什么 | 不允许做什么 |
|---|---|---|---|
| 探索窗口 | W03-W07 | 换题、换方向、换技术栈 | — |
| 收敛窗口 | W07-W09 | 缩小范围、砍功能 | 换题、换方向 |
| 冻结窗口 | W09-W10 | 完善、polish | 任何范围变更 |
Pivot 触发条件
不是"想换就换"——需要满足条件：
条件 1 最关键: "做不了"和"不想做了"是两回事。你需要展示具体证据——试了什么、为什么失败——而不是"感觉不行"。
Pivot 审批流
不是自己说了算——需要导师确认：
- 学员提交 Pivot 申请（含：当前方向失败证据 + 新方向 POC）
- 导师评估（新方向是否可行？时间是否够？）
- 确认或建议调整
为什么需要导师介入？ 因为很多时候"做不了"其实是"卡在某个点上了"——导师的经验可能帮你绕过，不需要换整个方向。
选题红线
Pivot Protocol 之前还有一道防线——选题红线：
| 红线 | 说明 | 示例 |
|---|---|---|
| 🚫 不做玩具 | 不能是"娱乐性"的 demo | "用 GPT 写诗/画画" |
| 🚫 不做巨石 | 一个人 4 周做不完的 | "做一个完整的 AI 客服系统" |
| 🚫 不做伪 AI | 核心逻辑没有 AI 参与的 | "用 if-else 做'智能推荐'" |
Pain-Storming: 选题前用 AI 辅助做痛点挖掘——从自己的日常工作中找到真实的、大小合适的痛点。
实际效果
8 周课程中：
- 35% 的学员做了 Pivot — 这是健康信号（说明在探索窗口内发现了问题并调整）
- 0% 在冻结窗口后要求换题 — 协议生效
- Pivot 后完成率 = 100% — 说明 Pivot 是有效的方向修正，不是逃避
典型 Pivot 案例
| 原方向 | 失败原因 | Pivot 后 |
|---|---|---|
| AI 自动化测试生成 | 生成质量不够,需要大量人工修正 | AI 辅助测试用例设计(半自动) |
| 智能排期系统 | 数据不足,AI 模型无法训练 | AI 辅助排期建议(规则+LLM) |
| 全自动代码审查 | 误报率太高 | AI 辅助代码审查(人+AI协作) |
共同模式: 从"全自动"Pivot 到"人机协作"——这本身就是 AI 项目成熟度的体现。
设计原则总结
| 原则 | 说明 |
|---|---|
| Pivot 是权利 | 不惩罚换方向，鼓励早发现早调整 |
| 证据驱动 | "做不了"需要有证据，不是感觉 |
| 时间窗约束 | 越晚 Pivot 成本越高，所以设截止日 |
| 导师护航 | 区分"真做不了"和"卡住了" |
| 范围递减 | 时间越少，允许的变化越小 |
核心洞察：AI 项目管理的最大误区是"确定了就别改"。真正的问题不是"改不改"——是"何时改、改多少"。Pivot Protocol 把"变更"从混沌的"想换就换"变成了有结构的"窗口+条件+审批"。