不写代码，用AI规划生产级应用系统架构

从原型到生产：为什么需要系统架构规划

很多人用 AI 做出原型后就停下来了——大概 95% 的人都止步于此。原型能帮你快速看清产品长什么样，但要变成一个可维护、可扩展、生产级的应用，还差关键一步：在写代码之前，把系统架构想清楚。

本文基于一档开发者节目 Build It 的实操演示。作者 Devin 用 AI Studio 做了个 AI 私人教练应用的原型，然后做了一个反直觉的决定：把原型整个扔掉，从零开始，用一种结构化、刻意的方式重建。在重建之前，他先和 AI 一起用纯英文（不写任何代码）把数据库结构、服务设计和数据流全部规划出来。

这个过程展示了一个重要能力：当 AI 能替你写代码时，真正的稀缺技能是系统思维——想清楚数据长什么样、怎么流动、什么时候该用 AI、什么时候不该用。

规划伙伴：让 AI 当你的架构对话者

演示中使用了一个叫 Google Anti-Gravity 的产品，不需要任何特殊操作就能启动一个 agent。作者创建了一个“规划伙伴”agent，它严格来说只负责一件事：和他讨论想法、挑战他的判断、帮他把想法理清楚、提出关键问题，一起找到最佳方案。

这个 agent 的交付物是一份文档，包含数据结构、数据库结构和服务器设计。数据库选用 Cloud Firestore。

整个对话在“白板模式”下进行，AI 反复强调一句话：软件架构听起来像一碗字母汤，但说到底就是把信息有逻辑地组织起来。这种“先说清楚、再动手写”的流程，正是 vibe coding 与生产级开发之间的分水岭。

核心架构决策：AI 生成还是预建库

规划从最核心的问题开始：训练动作应该是 AI 实时生成，还是从一个预建的库里查询？

作者的判断是混合方案最合理。理由很实际：动作讲解内容从性能角度看是最贵的，token 消耗也最大，但这些动作本身几乎不会变。所以预先建好一个动作库，agent 只负责把动作组合成连贯的训练计划。

这个决策带来的收益很具体：节省大量 AI 计算时间，把延迟从 15 秒降到 2 秒，每次请求都省钱，而且保证教学视频和动作要领 100% 准确、一致。

这个例子点出了整场演示最想传达的一课：要懂得什么时候用 AI、什么时候不用、什么时候提前用。不是所有环节都适合实时调用大模型。

延迟与 token 成本是决定 AI 是否实时调用的两条硬约束。大模型的输出是逐 token 自回归生成的，生成一段长文本往往需要十几秒，耗时大致与输出长度成正比，而首 token 延迟相对固定。这意味着「让模型现写一篇动作讲解」既慢又贵，而「让模型从库里挑几个 ID 并排序」输出极短，速度可提升一个数量级。token 计费同时覆盖输入与输出，把大段静态内容放进提示词同样会持续产生费用。因此工程上的通用原则是：内容稳定、篇幅长、质量要求高的部分预生成并缓存；内容个性化、篇幅短、需要即时响应的部分才实时生成。预生成还有一个隐性收益——可以在离线阶段做人工审核与质量校验，保证上线内容的一致性与准确性。

数据库建模：从动作库到周计划

动作集合：应用的“菜单”

第一步是建立顶层集合 exercises。每个文档代表一个动作，包含 ID、名称、分类、目标肌群等信息。整个库会提前生成好，作为 agent 的素材来源。

训练模块：一条被砍掉的冗余字段

第二步是周计划里的训练模块（block）。初版设计把模块分成 primary、strength、standard 等类型，每个模块下挂一个动作列表。

作者发现一个问题：既然每个模块存的都是列表，哪怕只有一项，也完全可以根据列表长度在应用里判断是单组还是超级组。那个 type 字段是多余的。AI 对此的回应是：你刚碰上了软件工程的一条黄金法则——永远不要存储你能从已有数据推导出来的信息。

周视图：活页笔记本 vs 档案柜

存储一周和它的每一天，有两种方案。

方案一“活页笔记本”：一个文档装下整周，每天的训练嵌套其中。优点是一次数据库调用就能拿到全部信息；缺点是受 Firestore 的文档大小限制（不过训练计划本身很小，影响不大）。

方案二“档案柜”：每周计划一个文档，每天的训练作为子集合。优点是每天互相隔离，改周一只动周一；缺点是打开周视图要读取周文档加每天的文档，多次数据库读操作。

最终选择了活页笔记本方案。作者还提出两处修正：用日期锚定（如“某周起”）替代单纯的周序号；在周和训练里加入预先生成的建议编辑，也就是界面里那些 chips，提前算好存起来。

Firestore 的数据模型是文档型数据库：数据按「集合 → 文档 → 子集合」层级组织，文档以类 JSON 形式存储。它的两个关键约束直接影响了本文的架构选择。其一是文档大小上限 1 MiB，超过就必须拆分，这也是「活页笔记本」方案需要评估训练计划体积的原因。其二是计费与延迟按读写文档数计算，读一个嵌套文档里的多个字段只算一次读，但读取子集合中的 N 个文档就算 N 次读，这正是「档案柜」方案打开周视图时成本更高的原因。此外 Firestore 不支持跨文档事务式的复杂查询，反范式冗余（把常用数据复制到读路径上）是常见做法，本文中「预先生成建议编辑并存储」正属于此类以空间换读性能的取舍。

Agent 端点设计：不要让 AI 重写整周

规划中最关键的部分之一，是 agent 返回数据的形态。

作者打了一个很形象的比方：你在线下跟教练说“我肩膀不舒服，今天能不能换个动作”，你不会期望教练把整个七天文件夹扔进碎纸机，再花十分钟重写你一整周的计划。

所以这里需要两个独立的端点：整周生成和单日修改，因为两者的目标和延迟要求完全不同。如果只是改一天，就不该触发一次整周生成。

那么 agent 怎么知道你想要哪种？答案是工具调用（tool calling）。给 agent 一个工具注册表，它分析对话内容和用户输入，自行决定是直接回答、修改某一天、还是重建整周。这是现代 AI 工程里很关键的一环。

响应返回与人工确认

作者还改变了之前的一个决定：把完整的响应（包括更新后的周或日）返回给客户端，并在聊天里以行内卡片形式展示，卡片带“接受”和“修改”两个按钮，用户点接受才真正写入 Firestore。这样做保护了数据库，避免幽灵覆盖——AI 生成的内容不会在用户未确认时直接落库。

聊天记录存储：找到极端之间的甜点

聊天的存储方式有两种极端：一个文档装一个消息数组（“一卷纸”），或者每条消息一个文档（“档案柜”）。前者加载容易但文档会无限膨胀，后者写入灵活但加载整个聊天是场灾难——得一个个文档去抓。

折中方案是按周分桶的聊天记录，正好与应用本身的周视图结构对齐。每周一个聊天，加载时按周取，既不会无限膨胀，也不用逐条读取。

用户画像与分层记忆：最前沿的设计

训练执行与记录部分比较直接：每次完成的训练存为一条永久文档。但真正有意思的是用户画像和 onboarding 设计。

作者明确表示讨厌 onboarding 向导，甚至因为不喜欢引导流程而放弃过产品。他想要的是零摩擦的对话式引导：打开应用，一个按钮生成训练，另一个按钮“介绍你自己”，然后用户像流水账一样说“我喜欢跑步，想改善心肺，想减点重”，agent 自己从中提取信息并生成第一周计划。

这套设计背后是分层记忆架构：

• 第一层：永久偏好——比如“我每周至少想跑两天”，agent 永远记得。
• 第二层：情境性生理信息——比如“我腘绳肌酸”，只在几天内相关，不该永远追问。
• 第三层：即时对话上下文——比如备战某场比赛，只在当下相关，之后可以淡忘。

更进一步，作者希望记忆是持续、自主更新的。传统 AI 应用的记忆往往是只写的，AI 不断囤积事实直到自己混乱；而真正的私人教练会随着你的生活变化不断更新、纠正、修剪笔记。为此，agent 被赋予在返回回复的同时返回记忆变更的权限。AI 称这是“agentic memory 的圣杯”。

工具调用（tool calling） 是大模型与外部系统交互的标准机制：开发者向模型声明一组可用工具（函数名、参数 schema、功能描述），模型在生成回复时若判断需要执行某个动作，会输出结构化的调用请求，由外层程序实际执行并把结果回传给模型继续推理。它的意义在于把「何时行动、行动几次」的决策权交给模型，而非写死在代码分支里，因此同一套端点可以同时支持闲聊、单日修改与整周重建。实践中需要注意：工具描述要写得足够精确，否则模型会误触发；工具执行应是幂等的或带确认机制；调用链要有次数上限与超时控制，避免模型陷入反复调用。

收尾：系统总览与核心用户旅程

规划文档最后补齐两节：系统总览和核心用户旅程，后者追踪信息如何在各个部分之间流动。整个规格文档至此 100% 完成，下一步才是真正动手建应用。

作者给观众的提醒很到位：如果你一直在 vibe coding，只是不断加功能、靠脑内测试，那“提前想清楚系统”可能是一项需要重新练习的新技能。但正是这种用纯英文、用大脑完成的架构推演，才能让应用更健壮、可维护、可扩展。

常见问题

不写代码做系统规划，会不会脱离实际？ 不会。规划阶段用自然语言把数据结构和数据流定清楚，恰恰能减少后期返工。演示中每个决策都对应具体的数据库结构和性能影响。

为什么不全让 AI 实时生成？ 成本和延迟是硬约束。预建动作库把延迟从 15 秒降到 2 秒，还保证内容一致准确。关键在于判断哪些环节适合实时生成、哪些适合提前生成。

分层记忆难实现吗？ 概念上不复杂，核心是给记忆字段打上不同的生命周期标签，并允许 agent 在回复时附带记忆变更。难点在于如何优雅地修剪过期信息，这正是演示中留待后续迭代的部分。