为什么坚持 spec → plan → TDD
17 个页面 36 个云函数，没有工程化流程的 AI 生成会越改越乱。先把需求锁进 spec、把计划拆到任务粒度、让测试跑在代码前面——AI 的产出速度才能变成交付速度而不是返工速度。
17 个
页面数
36 个
云函数数
1 人 + AI
开发者
产品案例
从记下一篇日常，到持续追踪成长
不是一组静态页面，而是一条可以在微信里实际操作的家庭记录链路。
输入
家长记录一篇日常，并在日历与生长模块持续补充家庭数据。
交付
已上线小程序，包含记录、日历、生长曲线与家庭共享，可扫码在真机验证。
记一篇
日常、语录、成就与旅行统一记录，支持图片和视频。
成长日历
按日期回看记录，月份切换与每日聚合都在小程序内完成。
生长曲线
体重、身高、头围与出牙分栏，预留 WHO 百分位曲线接档。
如何实现
从输入到交付的完整链路
独立开发者 / 想用 AI 做完整产品的个人 · 个人想做一个功能完整的真实产品，但前后端+运维一人扛不动
- 01
人写需求，AI 出 spec
用自然语言描述场景与痛点，AI 生成结构化设计文档（用户故事/边界/取舍），人拍板确认
- 02
AI 拆计划并逐任务生成
spec 转实施计划，按任务生成页面与云函数代码，TDD 护航，人只做验收
- 03
联调、部署、提审上线
云函数部署云开发环境，真机验证兼容，按微信类目要求提审发布
之前：个人做全栈小程序：周期长、易烂尾
之后：一人 + AI 走完需求到上线全链路
关键判断
不只是做出来，还要知道为什么这样做
人在流水线里的位置
人不是编码者，也不是旁观者：定需求、拍板 spec、验收每个任务，三次介入都在决策点。AI 负责生成与验证，人负责判断与担责。
上线链路的坑 AI 替代不了
云函数环境变量、真机兼容、微信类目审核——这些坑文档里不全有，得一个个踩过去。AI 能生成方案，但「提交审核」这个按钮必须人来按。
技术栈、技能原件与运行信息
技术与 AI 调用链
模型：Claude（代码生成/文档生成）
框架：微信原生小程序 + 云开发（36 云函数）、superpowers 工程化流程（spec→plan→TDD）
链路：人口述需求 → AI 生成 spec 设计文档 → 拆实施计划 → AI 逐任务生成代码+测试 → 云开发部署 → 微信提审上线
提供本地可运行版本，启动方式见项目文档；公开页面不展示本机目录。
可复用场景：个人全栈产品开发、AI 工程化交付流程、微信小程序快速验证
继续验证这个项目
看真实产出，或回到看板比较其他 AI 能力。
微信扫码体验