零基础，用AI做了个APP，这些坑替你踩了

我有 7 年产品经理经验，开发了一个移动端日程管理应用。技术栈用的都是主流方案：前端 React/NextJS，后端 FastAPI，数据库 Supabase。现在已经有 145 个用户。

V0.dev 做完前端原型后，后面就全用 Cursor 了。前端服务和工具、后端服务、API、身份验证以及 Google 日历导入功能，都是 Cursor 构建的。

Cursor 还负责管理 GitHub，通过 Vercel（前端）和 Render（后端）部署到生产环境。我用的是 Supabase 的 Google OAuth 来处理登录注册和账户管理。

整个应用有 109，667 行代码，基本都是 Cursor 写的。组件占 37%，前端代码 23%，后端 16%，剩下 21% 是各种工具库、服务、上下文、hooks 和类型定义。

总共用了 8.6 亿 Token（包括所有类型，测试文件、markdown 文档都算在内，还包括应用官网的代码）。

有效的方法

详细的架构文档。我准备了一份总体架构图，每次对话都让 AI 先读一遍。另外还有一些子文档，分别记录预期行为和当前实际行为。

角色分工（后来被砍了）。我用了好几个不同角色的 Agent：一个负责排查问题，一个负责修复，两者之间需要交接文档并验证。还有一个构建 Agent 按照标准的 TDD 流程工作。另有一个设计审查 Agent 专门根据移动端交互规范评估界面。还有一个文档管理 Agent 负责优化 markdown 文件，方便 AI 阅读。

/命令工具。太关键了。/process-check 会强制 Agent 在早期阶段先读产品文档、追踪数据流、研究并验证各种疑问和假设，写完测试再开始写代码。/verify-completion 让 Agent 说清楚测试覆盖了多少、结果如何，避免它偷偷在别的地方改架构。/tdd-cycle 用于重构已有功能，要求开始和结束时测试都必须通过。

效果一般的方法

Markdown 文档更新（算是有点用）。我没设固定更新时间，较大改动完成后觉得满意就更新一下。我会手动检查这些文档，在里面调整用户需求和流程。这些文档主要是为了缩小上下文范围，不是为了替代跟我直接对话。

让模型对结果负责。当模型把编码决策抛给我时，我会问它"为什么让我来做你的工作?"这样通常能让模型继续往下规划，或者至少在真正需要我参与时给出足够的背景信息。

全栈测试。这个少不了——单元测试、集成测试和端到端测试。我以前经常在开始编码前跳过测试阅读环节，太容易陷入"看起来在推进"的假象，一直聊天其实没干正事。端到端测试因为身份验证设置的问题，一直没通过。

失败的尝试

提交前钩子测试。一次都没通过，每次都被跳过。原因很简单：AI 写了太多细碎的单元测试和集成测试，数量实在太多。

TypeScript。概念很好，但类型错误多得离谱，因为整个架构不是提前规划好的。代码里到处都是 any 类型。边写代码边修类型错误风险很大。这主要是我的问题，但修类型错误永远比不上把 MVP 尽快交付给用户重要（当然我也可能是错的）。

自动数据库管理。一开始用 Alembic，一直连不上。后来试了 Supabase CLI，Agent 有一半时间连不上（感觉是随机的）。有一次 Agent 还把生产数据库清空了（还好我有备份）。从那以后再也不敢信任它。在 Supabase 里手动运行 SQL 脚本挺好用，还能让我更清楚数据结构。

过度关注后端。我的 MVP 需要在基础功能上做到不输甚至超过 Google Calendar（难度不小!）。

早期"氛围编程"的美好承诺让我走了弯路。服务层、内部 API、时区管理——花了好几周跟 Cursor 较劲，结果反而偏离了真正重要的目标：做一个在某些方面胜过 Google Calendar 的精简 MVP。不过最后还是挺过来了。

有具体问题欢迎深入讨论。