交付路线图

从想法到可施工计划的鸿沟

当你把产品想法交给模型时，最常见的失败不是模型不理解需求，而是产出物停在「建议做鉴权、建议加搜索」这一层。这些词在演示文稿里成立，在代码库里不成立。你拿到的不是可排期的工程任务，而是方向正确的废话。

更麻烦的是执行阶段。跨越数周的构建会经历多次会话，每次回来都要重新判断做到哪了。如果路线图只存在于对话历史里，进度就等同于记忆，而记忆会衰退、会错乱、在第 20 个会话里彻底失真。

交付蓝图的构造方式

这个技能把输出物定义为交付蓝图，而非战略文档。工作流有四个关键步骤：

• 确立愿景：锁定一句话定位、用户、痛点、技术栈/预算/时间约束，以及最重要的——明确不做什么。
• 定义技术栈：按前端、后端、数据库、鉴权、存储、搜索、托管逐层给出选型与理由。有 deep-research 简报就从中取推荐，否则基于现有栈做有主见的决策。
• 设计数据模型：一次性覆盖完整产品所需的全部表/集合，标注每张表在哪个阶段被用到，避免中途改 schema。
• 规划阶段：每个阶段必须能独立部署、建立在前一阶段之上、可在 1–3 个会话内完成。阶段内部包含目标、依赖、工时、新增内容、数据库变更、API 路由、前端、基础设施、任务清单和完成定义。

阶段拆分遵循固定节奏。阶段 1 是 MVP，硬标准是：如果你不会用它替代现在的工具，MVP 太薄。阶段 2 做实——搜索、筛选、排序、错误处理、空状态、移动端适配、导入导出。阶段 3 及之后做差异化——AI 能力、集成、团队功能。

自主推进与停下来的边界

执行模式下，技能读取 docs/ROADMAP.md，找到第一个未完成的阶段，检查 git log 与代码库现状，然后从第一个未完成任务开始逐项推进。每个任务完成后验证构建、运行、测试；阶段完成后跑完成定义检查，提交 git、部署到生产、对线上应用做快速 UX 审计，然后继续下一阶段。

关键设计是：路线图即授权。完成一阶段不停下来征求许可，有部署目标就部署，小问题记 GitHub issue 后继续。只在三种情况下停下——任务失败且原因未知、缺少凭证/密钥、需要人判断的设计决策。

进度标记写入 docs/ROADMAP.md，使 resume 模式能精确接续，而非从对话记忆里猜测。

适用边界

• 这不是研究工具。纯调研请用 deep-research，它产出的判断依据和这个技能的执行框架不兼容。
• 路线图是执行依据，不替代真实的人工设计决策。遇到需要人判断的地方——比如「要不要支持多租户」、「权限模型选 RBAC 还是 ABAC」——技能会停下来询问，而非自己拍板。
• 它适合启动重要新产品、把模糊想法变成可执行计划、规划跨越多会话的数周构建。不适合修一个已知 bug 或写独立脚本这类小任务。