开发流程要按任务大小分级

更新于 2026-07-15

**核心判断：现在的问题不是「该不该认真」，而是把「大功能的重流程」套到了「小功能」上 —— 小功能因此很慢（每次都要测试，浪费时间还烧 token）；而真正该强制的（深色模式、原型对齐、状态边界）反而只写在文档里，没变成每次改动都过的硬门槛。**

用户体感（本条来源）

  • 做小功能很慢，感觉每次做一个功能都要测试。
  • 有些错误本可避免却发生了，比如深色模式没适配。
  • 已经做了高保真原型，只是接入前后端却浪费大量时间。

两条待验证的方向

  1. 分级：按任务大小决定验证强度，而不是所有事都走同一种重流程（小改动不写设计文档、不强制全量测试；共享数据层 / API / 安全边界 / 同步逻辑才必须测）。
  2. 原型当合同：UI 改动固定成「先看原型 → 截目标图 → 实现 → 同 viewport 对比」的流程，慢的不是看原型，是没把原型当合同导致返工。见 UI原型保真。

附：验证强度还随「阶段」分级

同一件事，验收前和合并前的验证要求不一样（来源：2026-07-12 关于「验收前是否要 superpowers + 全仓库 lint」的判断）：

  • 验收前：流程技能（brainstorming、spec/plan、TDD、systematic-debugging、verification、code review、worktree）该用 —— 评审确实能抓出真问题（如解析器死循环、错误降级）。
  • 验收前不需要：全仓库 lint。只对改动所在 package 跑 lint + build + 测试即可，覆盖其他未改动 package 价值很低。
  • 合并/生产前才需要：pnpm verify（全仓库 lint + 测试 + 主题 + 完整构建）。
  • 未到阶段不做的：finishing-development-branch、babysit-pr、web-deploy（还没验收、没建 PR）。

分级维度有两个：任务大小（改哪一层）+ 所处阶段（验收前 / 合并前）。两者共同决定验证强度。

附：代码级验证通过 ≠ 可以合并（部署级验证）

来源：2026-07-14 关于「是否需要测试后再合并」的判断。

当改动涉及部署形态变化（新增常驻进程、Docker/Compose、环境变量校验、启动方式）时， 测试通过只能支撑「可以提 PR」，不足以支撑「可以合并 main」。

  • 代码级验证（已完成即可提 PR）：相关包的测试、lint、build、配置解析
  • 部署级验证（合并前必须补）：在目标机器从分支构建镜像 → 日志出现就绪标志 → 真实创建一个任务确认被消费 → 确认结果写回 → 停掉容器再启动，确认任务能继续处理

推荐顺序：推分支 → 建 PR → CI 通过 → 服务器用该分支测试部署 → 验收通过 → 合并 main → 切 main 重建。

两个配套纪律：

  1. 服务器测试要用 staging 的数据库/Redis；若直连当前环境，先停掉本地同类进程， 否则无法判断任务究竟由本地还是服务器处理（见 本地开发脚本可能连生产资源）。
  2. 追踪器里的 issue 在服务器验收通过前保持 In Progress，不因为「代码写完了」就 Done （见 Issue完成由用户验收后再关闭）。

附：验收前的硬检查项（交付遗漏复盘）

来源：2026-07-15 两处交付遗漏。共同点是检查项没被写成「启动前必过」，于是默认它已经成立。

  1. 「代码用新字段」不等于「验收环境已同步 schema」：只验证了代码、测试、Prisma Client 生成，没有把「当前验收所连接的开发数据库已执行 schema 同步」列为启动前硬检查 → 代码先用了新字段，库还停在旧结构。
  2. 超时只加在最里面那一层：给外部 RSS 抓取加了 15 秒限制，却漏掉「浏览器到 /api/feeds」整段请求 → 数据库异常发生在抓取之后时，前端没有第二道保险，一直转圈。超时要覆盖整条请求链路，不只是最内层的远端调用。

可迁移的规则：验证清单要按「数据 / 配置 / 网络」三类，而不是按「我改了哪些代码」列。

另一条流程纪律：用户说「开始完成」后，不应停在检查点把未完成的版本交出去等整体验收。 暂停点不是免责理由 —— 交付不完整的部分要么继续做完，要么明确标出「哪些验收项尚未完成」，不能等对方发现。

相关