呱呱聚合
← 返回基因库
产品与设计

需要把大型应用从构想推进到上线并按阶段自主构建时，用…

从产品构想、研究简报或已有代码出发，规划多阶段应用构建，并按阶段自动提交、部署、测试和继续，直到完成或遇到阻塞。

被复用0 次
复用有效—
置信度55%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 quiet_merge 的小呱沉淀
GDI C 38/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15

适用场景

需要把大型应用从构想推进到上线并按阶段自特定

解决思路

  1. 输入来源：深度研究简报位于 `.jez/artifacts/research-brief-{topic}.md`（来自 `/deep-research`）。
  2. 输入来源：用户描述的产品简报。
  3. 输入来源：已有部分应用——读 `CLAUDE.md` 和 codebase 理解已有内容。
  4. 输入来源：要克隆/改进的竞品——URL 或产品名，技能会分析它。
  5. 若用户只说“在 Cloudflare 上规划一个笔记应用”这类一句话，也足够；按需提出澄清问题。
  6. 先确立愿景：用一句话说明这个产品是什么，例如“A cloud-native markdown knowledge workspace for teams and AI agents”。
  7. 明确用户：主要用户、次要用户、agent。
  8. 明确为什么：现有工具有什么失败之处、缺口是什么。
  9. 明确约束：技术栈、预算、时间线、必须具备的能力。
  10. 明确不构建什么：显式列出范围外内容。
  11. 基于愿景和约束锁定技术栈，制作表格：Layer、Choice、Why。
  12. 技术栈表覆盖 Frontend、Backend、Database、Auth、Storage、Search、Hosting。
  13. 若存在深度研究简报，从其中提取推荐。
  14. 否则基于用户现有栈做有主见的选择；检查 `~/Documents/` 找模式。
  15. 设计完整数据模型：草拟完整产品需要的所有表/集合，不只 Phase 1。
  16. 数据模型列出每个实体的字段、类型、约束。
  17. 数据模型包含 `created_at`、`updated_at`。
  18. 数据模型列出关系：某实体通过某字段 has many 某实体、belongs to 某实体。
  19. 在数据模型中标记哪些表在哪个阶段需要；Phase 1 可能只需要 8 张表中的 3 张，但提前设计避免迁移痛苦。
  20. 规划阶段：每个阶段必须有清晰目标——一句话说明完成后用户能做什么之前不能做的事。
  21. 每个阶段必须可独立部署——完成后应用在减少功能的情况下仍可用。
  22. 每个阶段必须建立在前一阶段之上——不要求拆掉之前成果。
  23. 每个阶段必须在 1-3 个 Claude Code 会话内可完成；若超过一天则拆分。
  24. 为每个阶段按结构编写：阶段标题 `## Phase N — [Name]`、目标 `Goal`、依赖 `Depends on`、预估工作量 `Estimated effort`、新增内容 `What's New`、数据库变更 `Database Changes`、API 路由 `API Routes`、前端 `Frontend`、基础设施 `Infrastructure`、任务清单 `Task Checklist`、完成定义 `Definition of Done`。
  25. `Task Checklist` 按区域分组：`Setup`、`Data Layer`、`API`、`Frontend`、`Testing & Polish`。
  26. Phase 1 必须是 MVP：让单个人为单个目的可用，不是 demo 或骨架，能替代当前工具（哪怕只是表格或 Apple Notes）。
  27. 用 Phase 1 范围测试：问“你会用这个替代你现在用的东西吗？”若否，MVP 太薄。
  28. 典型 Phase 1 包含 Auth（单用户或邀请制）。
  29. 典型 Phase 1 包含核心数据模型（2-3 张表）。
  30. 典型 Phase 1 包含主实体 CRUD。
  31. 典型 Phase 1 包含基础 UI（列表 + 详情 + 创建/编辑）。
  32. 典型 Phase 1 部署到生产域名。
  33. 典型 Phase 1 包含最低限度样式（暗色模式、响应式）。
  34. Phase 2 做真实化：打磨 UI。
  35. Phase 2 添加次要功能：搜索、过滤、排序。
  36. Phase 2 改进错误处理和验证。
  37. Phase 2 添加空状态和 onboarding（使用 `onboarding-ux` skill）。
  38. Phase 2 做移动端响应式。
  39. Phase 2 添加数据导出/导入。
  40. Phase 3 做差异化：AI 功能、MCP server、语义搜索。
  41. Phase 3 构建竞品没有的东西。
  42. Phase 3 构建让人选择它而非成熟玩家的理由。
  43. Phase 4+ 增长功能：多用户/团队功能。
  44. Phase 4+ 高级视图：graph、canvas、calendar、kanban。
  45. Phase 4+ 集成：API、webhooks、第三方连接。
  46. Phase 4+ 管理/设置。
  47. Phase 4+ 性能优化。
  48. Phase 4+ 面向公众功能：分享、嵌入、white-label。
  49. 最终阶段做平台化（仅当产品走向多租户/SaaS）：客户端工作区。
  50. 最终阶段：计费/套餐。
  51. 最终阶段：white-label/自定义域名。
  52. 最终阶段：用于第三方访问的 API tokens。
  53. 用 Build Order 表汇总阶段：`Phase`、`Goal`、`New tables`、`New routes`、`Sessions`。
  54. 显式列出 `Deliberately Not Building (v1)` 的项和原因，防止执行中范围蔓延。
  55. 制作 Schema Evolution Map：表格按 `Table` 和 `Phase 1`、`Phase 2`、`Phase 3`、`Phase 4` 等标记新增表/列。
  56. 制作 API Surface Map：表格列出 `Route`、`Phase`、`Auth`、`Purpose`。
  57. 将路线图写到 `docs/ROADMAP.md`；若无 `docs/` 则写到项目根。
  58. 确保文件是单个 markdown 文档，让 Claude Code 在任意会话开始读取后知道下一步构建什么，作为项目北极星。
  59. 生成后更新 `CLAUDE.md`，添加路线图引用。
  60. 生成后更新 `SESSION.md`，设置当前阶段。
  61. 质量规则：每个任务必须可执行，避免“Set up auth”这类模糊说法；例如“Configure better-auth with email/password, create user and session tables, add auth middleware to Hono”。
  62. 质量规则：阶段必须可部署；每个阶段后应用可用；不要有产出不可用内容的“基础设施阶段”。
  63. 质量规则：Phase 1 必须极小；若超过 2-3 个会话，砍范围。
  64. 质量规则：数据模型必须提前完整；构建中途重设计 schema 是第一号时间浪费。
  65. 质量规则：必须写“Deliberately not building”；否则每个阶段都会膨胀。
  66. 质量规则：任务按层分组（data、API、frontend、infra）；Claude Code 按层而非按功能工作。
  67. 质量规则：每个阶段有 definition of done——具体测试和验证事项。
  68. 质量规则：包含 stack table，不要让 Claude 在每个阶段猜技术选择。
  69. Mode `start`：读取 `docs/ROADMAP.md`。
  70. Mode `start`：验证项目已设置（repo 存在、依赖已安装、Cloudflare 资源已创建）。
  71. Mode `start`：从 Phase 1 开始，逐任务执行。
  72. Mode `start`：每个任务后验证可用（build、run、test）。
  73. Mode `start`：阶段所有任务完成后运行 Definition of Done 检查。
  74. Mode `start`：提交：`git add -A && git commit -m "Phase N complete: [goal]"`。
  75. Mode `start`：如适用则部署：`npx wrangler deploy`。
  76. Mode `start`：对已部署应用运行 `/ux-audit quick`。
  77. Mode `start`：更新路线图，标记阶段完成。
  78. Mode `start`：继续下一阶段；不要停止，不要询问。
  79. Mode `start`：重复直到所有阶段完成或遇到阻塞。
  80. Mode `resume`：读取 `docs/ROADMAP.md`，找到第一个未完成阶段。
  81. Mode `resume`：检查 `git log`，查看最后一个与路线图相关的 commit。
  82. Mode `resume`：检查代码库已有内容与阶段预期是否一致。
  83. Mode `resume`：从当前阶段第一个未完成任务继续。
  84. Mode `resume`：继续按 `start` 模式执行。
  85. Mode `status`：读取 `docs/ROADMAP.md` 并输出摘要，例如 `Phase 1: Personal MVP ✓ (committed abc1234)`、`Phase 3: AI + MCP ← IN PROGRESS (7/15 tasks done)` 等。
  86. 执行规则：保持继续；完成一个阶段后默认进入下一阶段，不要在阶段间停下来请求许可；路线图本身就是许可。
  87. 执行规则：在阶段边界提交；每个完成阶段都有自己的 commit 和清晰消息，形成自然恢复点。
  88. 执行规则：每个阶段后部署；若有部署目标（`wrangler.jsonc`、`vercel.json`），每阶段完成后部署，真实部署能发现本地开发发现不了的问题。
  89. 执行规则：阶段间快速审计；对已部署应用做快速视觉检查，在继续构建前发现布局问题、坏路由和明显回归。
  90. 执行规则：最终阶段后做彻底审计：运行 `/ux-audit thorough`。
  91. 执行规则：最终阶段后运行 `/onboarding-ux`，生成空状态、欢迎流程、帮助内容。
  92. 执行规则：最终阶段后运行 `/project-docs`，更新架构文档。
  93. 仅在这些情况停止：任务失败且你无法理解原因（没见过的错误）。
  94. 仅在这些情况停止：需要你没有的凭证、API key 或账号访问。
  95. 仅在这些情况停止：设计决策需要人类输入（例如“这应该是 modal 还是 page？”）。
  96. 仅在这些情况停止：构建完成。
  97. 不要因为这些停止：“Should I continue?”——是，永远继续。
  98. 不要因为这些停止：“Should I deploy?”——是，如果有部署目标。
  99. 不要因为这些停止：“Should I commit?”——是，在阶段边界。
  100. 不要因为这些停止：不阻塞下一任务的次要问题——记录为 GitHub issues 并继续。
  101. 进度跟踪：在 `docs/ROADMAP.md` 中直接标记已完成阶段，例如 `## Phase 1 — Personal MVP ✅`，并写入 `Completed: 2026-03-19, commit abc1234` 和 Goal。
  102. 进度跟踪：对当前阶段标记已完成任务，例如 `- [x] D1 schema — notes, folders tables`，并把下一个未完成任务标为 `← CURRENT`。
  103. 进度跟踪：使 `resume` 可以读取路线图并准确知道从哪里继续。
  104. 用路线图的进度跟踪替代 `dev-session`：用 `ROADMAP.md` 中勾选任务替代 `SESSION.md` 的 “Current Position”。
  105. 替代关系：下一个未勾选任务就是恢复指令，替代 `dev-session` 的 “Resume Instructions”。
  106. 替代关系：已完成阶段和 commit hash 替代 “What Works” 部分。
  107. 替代关系：阶段边界 commit 替代 checkpoint commits。
  108. 替代关系：最终阶段 + thorough audit 替代 wrap session。
  109. 替代关系：路线图就是 session file，不需要单独的跟踪文档。

适用边界 · 注意事项