AI 编程项目路线图不是一份“让 Agent 修改哪些文件”的待办清单，而是一组可验证的产品结果。真正有用的路线图会连接五件事：用户问题、下一个产品能力、Agent 要执行的任务、证明结果成立的证据，以及决定下一步的市场信号。
这一区别很重要。Coding Agent 可以显著加快实现速度，但不会自动替你判断产品方向。原型做得快是进展，却还不是一个已经发布、能被发现、值得信任的产品。
一眼看懂完整路线图
- 发现：确认某一类人是否真的遇到这个问题，证据来自用户自己反复讲出的具体经历。
- 构建：让用户完成最核心的动作，证据是真实流程跑通，而不只是单元测试通过。
- 发布：让用户能够获得并使用产品，证据是构建、发布和公开读回都成立。
- 学习：通过访谈、支持反馈、搜索或产品数据观察发布后的真实结果。
- 改进：根据证据选择下一个里程碑，而不是只靠开发惯性继续加功能。
这些阶段可以交错进行。唯一不能妥协的是：不能因为 Agent 写了一段自信的总结，就把一个阶段标成完成。
第一步：先写用户结果
先完成这句话：
这个里程碑完成后，某类用户可以在某种条件下完成某个动作。
“实现登录”是技术活动；“回访用户可以安全地重新打开同一个项目”才是产品结果。后一句让 Agent 可以调查多种实现路径，同时不丢失工作的原因。
再补一条明确的非目标，例如“本里程碑不增加团队账号”。路线图不仅要列出要做什么，也要保护当前焦点。
第二步：先定义证据，再拆任务
每个里程碑至少准备四层证据：
- 行为证据：用户可以完成目标动作。
- 质量证据：相关测试、构建与失败场景通过。
- 交付证据：目标页面、安装包或发布物确实可用。
- 学习证据：结果能产生一个足以影响后续判断的信号。
这样可以避免一种常见假完成：某个单元测试绿了，就被当作完整用户旅程已经成立。
第三步：把里程碑变成有边界的 Agent 执行
每次 Agent 执行都应得到：
- 它服务的用户结果；
- 当前代码或运行证据；
- 不能改变的不变量；
- 允许修改的仓库或服务；
- 必须完成的验证；
- 哪些情况必须停下来由人确认。
边界内可以给 Agent 足够自主权；但它不应该悄悄改变价格、删除数据、修改公共合同，或替你选择另一个用户结果。
第四步：留下可持续的交接
一次运行结束时，保存事实，不要倾倒整段对话：
- 改了什么；
- 验证了什么；
- 精确版本、提交或任务身份；
- 还缺什么；
- 下一步安全动作是什么。
长对话会占用上下文，也经常包含已经失效的假设。OpenAI 的 Harness Engineering 实践同样建议给 Agent 一张可导航的地图，而不是一份巨大的说明书：Harness engineering。
第五步：把发布和反馈写进路线图
一份在“代码完成”处结束的路线图，会鼓励独立开发者永远停留在 Build。请明确加入：
- 打包或部署；
- 上手引导和文档；
- 搜索与分发；
- 用户反馈收集；
- 使用情况回顾；
- 下一次基于证据的修订。
独立开发者社区里反复出现同一个经验：真正帮助项目完成的，是明确的完成定义、一条很小的演示路径和几项验收检查，而不只是更强的模型。可以参考这条关于完成 AI 辅助项目的讨论。
可直接复制的里程碑模板
用户结果
本里程碑完成后，[用户] 可以在 [条件] 下完成 [动作]。
本轮范围
- 最小产品行为。
- 必需的数据、界面与交付改动。
本轮不做
- 一个很诱人但相邻的功能。
- 无关清理或重构。
Agent 简报
- 当前证据：
- 不变量：
- 授权范围：
- 停止条件：
完成证据
- 行为检查：
- 自动化检查：
- 最终产物或公开读回：
- 失败场景：
- 学习信号：
会话交接
- 稳定身份：
- 已验证状态：
- 剩余缺口：
- 下一步动作：
路线图应该拆多细？
每个里程碑要大到能产生一个用户可感知的结果，又要小到能在一条连贯链路里验证。不要在路线图里重复列出每次代码编辑；Agent 检查真实系统后再决定实现细节。
可以用一个问题检验：下周打开项目的新会话，能否理解这个里程碑为什么存在、哪些事实已经成立、还缺什么证据？如果可以，这份路线图就在发挥作用。
什么时候不适用？
如果只是一次性实验，而且“证明失败”本身也是有效结果，可以使用更轻的计划。涉及支付、安全、生产数据或不可逆动作时，则需要更严格的授权、恢复和负向验证闸门。
核心原则
路线图不是为了整理 Agent 的忙碌程度，而是为了让产品意图、执行、交付和学习始终连接，直到真实用户结果成立。