目录
[13.1 从工作流到应用：一次范式跃迁](#13.1 从工作流到应用：一次范式跃迁)
[13.1.1 真实场景：一个被遗忘的订阅](#13.1.1 真实场景：一个被遗忘的订阅)
[13.1.2 个人开发者面前的"三座大山"](#13.1.2 个人开发者面前的“三座大山”)
[13.1.3 两种产物的边界：工作流与应用](#13.1.3 两种产物的边界：工作流与应用)
[13.1.4 扣子编程的"想法到实现"能力](#13.1.4 扣子编程的“想法到实现”能力)
[13.2 入口：新建一个编程项目](#13.2 入口：新建一个编程项目)
[13.2.1 从"新建编程项目"说起](#13.2.1 从“新建编程项目”说起)
[13.2.2 三种应用形态：网页、移动、小程序](#13.2.2 三种应用形态：网页、移动、小程序)
[13.3 一句话需求的解构：应用描述五要素](#13.3 一句话需求的解构：应用描述五要素)
[13.3.1 从一段产品化的指令说起](#13.3.1 从一段产品化的指令说起)
[13.3.2 要素一：产品定位与平台命名](#13.3.2 要素一：产品定位与平台命名)
[13.3.3 要素二：数据模型（实体与字段）](#13.3.3 要素二：数据模型（实体与字段）)
[13.3.4 要素三：页面与导航结构](#13.3.4 要素三：页面与导航结构)
[13.3.5 要素四：业务规则与计算逻辑](#13.3.5 要素四：业务规则与计算逻辑)
[13.3.6 要素五：设计与部署约束](#13.3.6 要素五：设计与部署约束)
[13.4 实现过程：一名"数字全栈工程师"的工作日志](#13.4 实现过程：一名“数字全栈工程师”的工作日志)
[13.4.1 第一步：勘探与规划------AI如何理解"做一个应用"](#13.4.1 第一步：勘探与规划——AI如何理解“做一个应用”)
[13.4.2 第二步：技术栈选型------Taro＋NestJS＋Supabase](#13.4.2 第二步：技术栈选型——Taro＋NestJS＋Supabase)
[13.4.3 第三步：后端API------一组规整的RESTful接口](#13.4.3 第三步：后端API——一组规整的RESTful接口)
[13.4.4 第四步：前端三页面与TabBar](#13.4.4 第四步：前端三页面与TabBar)
[13.4.5 第五步：五道验证关卡](#13.4.5 第五步：五道验证关卡)
[13.5 AI协同调试：3个真实的工程现场](#13.5 AI协同调试：3个真实的工程现场)
[13.5.1 现场一：被误删的函数体（formatCost）](#13.5.1 现场一：被误删的函数体（formatCost）)
[13.5.2 现场二：toast函数签名不匹配](#13.5.2 现场二：toast函数签名不匹配)
[13.5.3 现场三：小程序不兼容的小数类名](#13.5.3 现场三：小程序不兼容的小数类名)
[13.6 运行验证：庆贺"续费管家"的诞生](#13.6 运行验证：庆贺“续费管家”的诞生)
[13.6.1 五项验证全部通过](#13.6.1 五项验证全部通过)
[13.6.2 前后端契约匹配验证](#13.6.2 前后端契约匹配验证)
[13.6.3 成品一览：运行界面](#13.6.3 成品一览：运行界面)
[13.6.4 预览与发布：配置小程序AppID](#13.6.4 预览与发布：配置小程序AppID)
[13.6.5 设计目标与实际交付的对照](#13.6.5 设计目标与实际交付的对照)
[13.7 经验总结与迁移应用](#13.7 经验总结与迁移应用)
[13.7.1 七条关键经验](#13.7.1 七条关键经验)
[13.7.2 迁移场景矩阵](#13.7.2 迁移场景矩阵)
[13.7.3 何时用应用生成，何时用工作流编排](#13.7.3 何时用应用生成，何时用工作流编排)
[13.8 小结](#13.8 小结)
[13.9 思考与练习](#13.9 思考与练习)
本章导读
从第7章到第12章，我们一直在跟一种叫作"编排"的能力打交道------把数据分析做成一个会追问的Agent，把行业热点做成一条单链工作流，把全渠道营销做成多模态并行工作流，再把数据采集与数据质检做成线性数据治理流水线。这些案例的共同特征是：我们在"组织节点"，把若干能力像乐高一样拼装成一条会自动运转的流水线，最终交付的是一份结果（一段文案、一张报表、一份可信 CSV）。
但是，当一位朋友半夜给你发来一条消息------"我刚发现自己连续两年在为一个早就不用的视频会员付费，能不能帮我做个小程序，把所有订阅管起来，到期前提醒我"------你交付的就不再是"一份结果"，而是"一个能装进口袋、随时打开、长期使用的产品"。这就是本章要跨越的那道分水岭：从工作流编排，跃迁到全栈应用生成。
本章以一个真实可上线的微信小程序"续费管家"为案例，完整呈现扣子编程"从想法到实现"的能力------你只需用一段自然语言把产品讲清楚，扣子编程就会自主完成技术选型、数据建模、后端 API、前端页面、多端构建、自测验证乃至预览发布的全过程，最终交付一个前后端齐备、三端可跑（H5＋微信小程序＋抖音小程序）的完整应用。
学习目标：（1）理解"工作流编排"与"应用生成"这两类AI原生开发范式的本质差异与各自适用边界；（2）掌握把一句话产品需求解构为可被扣子编程精确执行的"应用描述五要素"方法；（3）看懂扣子编程作为"全栈工程师"从初始化到发布的完整工作日志，尤其是数据建模、前后端契约与多端构建三个关键环节；（4）通过三个真实的AI协同调试现场，建立"AI生成的应用并非开箱即生产"的工程审慎原则；（5）具备把本案例迁移到记账、打卡、清单、预约等大量"个人轻应用"场景的能力。
本章重点：应用生成范式与工作流范式的边界划分、一句话需求的产品化解构方法、全栈技术栈（Taro＋NestJS＋Supabase）的自动协同、前后端契约的一致性验证，以及多端构建与小程序兼容性的工程细节。
13.1 从工作流到应用：一次范式跃迁
13.1.1 真实场景：一个被遗忘的订阅
先讲一个几乎人人都遇到过的小故事。
小薛是一名普通的上班族。某个周末他翻看银行账单，赫然发现一笔每月25元、已经连续扣了 23个月的支出------那是两年前为了追一部剧而开通的某视频平台月度会员，剧追完后他早已不看，却因为"自动续费"一直默默扣费，累计已经花掉近600元。他打开手机，想把所有正在花钱的订阅都数一遍：视频会员有两个、音乐会员一个、云存储一个、健身房年卡一张、还有一个几乎没用过的软件年费......七零八落地散落在不同App、不同的扣费日里，他根本说不清自己每个月到底固定支出多少，更不知道下一笔扣费会在哪一天悄悄发生。
这正是一个典型的"个人轻应用"需求：数据不复杂（就是一张订阅清单），逻辑不烧脑（排序、倒计时、求和），但市面上要么没有趁手的工具，要么功能臃肿、广告缠身。小薛的诉求很朴素------"一个清清爽爽、只为我服务的小程序"。在AI原生开发时代之前，这种"小而美"的需求往往因为开发成本过高而被永远搁置；而扣子编程的出现，让"为自己写一个小程序"重新变成一件可以在一个下午完成的事。
13.1.2 个人开发者面前的"三座大山"
如果让小薛自己动手开发这个小程序，他会立刻撞上横亘在所有个人开发者面前的"三座大山"。
第一座山是技术栈的广度。一个能用的小程序不是一个孤立的页面，它至少需要：前端（页面渲染、交互、状态管理）、后端（接口、业务逻辑）、数据库（持久化存储），三层缺一不可。对应到真实技术，可能是Taro/React写前端、NestJS写后端、PostgreSQL存数据------任何一层对非专业开发者都是一道高墙。
第二座山是多端的割裂。"微信小程序"5个字背后藏着大量平台特有的约束：小程序的样式子集与浏览器不同、TabBar图标要按规范生成、project.config.json要正确配置、还要同时兼顾抖音小程序与H5网页端。一份代码要在多个端上都能跑通，是经验丰富的工程师才驾驭得了的事。
第三座山是"最后一公里"的工程闭环。代码写完只是开始，真正能用还需要：通过类型检查与代码规范（ESLint＋TypeScript）、构建出各端产物、自测每个接口返回正确、确认前端调用与后端响应字段一一对应、检查日志没有报错......这一长串"收尾工序"往往比写功能更耗时，也最容易出错。
三座大山叠加在一起，就是"为什么个人轻应用的需求大量存在、却长期得不到满足"的根本原因。它们不是单一难题，而是一整套需要跨领域协作的系统工程。
13.1.3 两种产物的边界：工作流与应用
要理解本章的范式跃迁，最直接的方式是把"工作流"与"应用"这两类产物摆在一起对照。前几章我们交付的是工作流，本章交付的是应用，二者在多个维度上有着本质区别，如表13-1所示。
表13-1 工作流编排与应用生成的产物边界对比
| 对比维度 | 工作流编排（第 8---12 章） | 应用生成（本章） |
|---|---|---|
| 核心动作 | 组织节点，拼装一条流水线 | 生成产品，搭建完整的前后端系统 |
| 最终产物 | 一份结果（文案／报表／CSV） | 一个可长期使用的应用 |
| 运行形态 | 被触发一次、产出一次 | 随时被用户打开、反复使用 |
| 交付对象 | 下游系统或某次任务 | 终端用户的日常生活 |
| 技术构成 | 节点＋模型＋工具 | 前端＋后端＋数据库＋多端构建 |
| 状态管理 | 通常无状态、单次运行 | 有持久化数据、需长期维护 |
| 验收标准 | 本次输出是否正确 | 各端是否都能跑、能否上线发布 |
从这张表可以看出，应用生成不是工作流编排的"升级版"，而是一个并列的、面向不同问题的全新范式。工作流擅长"把一件确定的事自动做一遍"，应用擅长"把一种持续的需求长期服务好"。一个成熟的AI原生开发者，需要能在这两种范式间精准切换：当用户要的是"算一次"，支持后期时常复用，就搭工作流；当用户要的是"天天用"，就生成应用。
13.1.4 扣子编程的"想法到实现"能力
面对"三座大山"，扣子编程给出的答案被它自己凝练成一句口号------"从想法到实现"。它的能力边界是：你用一段自然语言把产品讲清楚，它就替你翻越全部三座山，自主完成技术选型、数据建模、前后端开发、多端构建、自测验证与预览发布。这整个过程中，我们都不需要写一行代码，只需要在关键节点上确认与微调。
这一能力之所以可能，源于扣子编程把一名资深全栈工程师的工作流程"内化"成了自身的执行链路：它会先像架构师一样勘探项目、规划技术栈，再像后端工程师一样设计数据库与API，接着像前端工程师一样搭建页面与导航，最后作为测试与运维工程师------跑通验证与构建。本章的全部篇幅，就是要把这条"数字全栈工程师"的工作日志完整地展开给大家------既看它如何把一句话变成一个应用，也看它在过程中如何踩坑、如何自我修复。
|--------------------------------------------------------------------------------------------------------------------------|
| 【提示】 应用生成与工作流编排不是替代关系，而是工具箱里的两件不同工具。 判断该用哪一个，只需问一句话：用户要的是"算一次的结果"，还是"天天用的产品"？前者用工作流，后者用应用。本章末尾的13.7.3节会给出一份更细致的决策清单。 |
13.2 入口：新建一个编程项目
13.2.1 从"新建编程项目"说起
一切从扣子3.0更新后的页面开始，主页进入后，聚焦左侧导航。点击对话列表顶部的"＋"号，会弹出新建菜单，其中"新建编程项目------用扣子编程，起个新项目"正是本书所有案例的初始入口，如图13-1所示。它与"新建项目（接入 Agent）""新建视频项目"并列，三者分别对应扣子的3条产品线：Agent编排、视频创作与全栈编程。
图 13-1 扣子编程的"新建编程项目"入口
值得留意的是，图13-1所示左侧的项目列表："续费管家""记账小助手App""每日食选小程序""像素方块世界"......清一色都是用扣子编程做出来的可运行应用。这个列表本身就说明了应用生成范式的高频与多样------记账、餐饮、订阅、小游戏，每一个都是一句话需求催生出的真实产品。
13.2.2 三种应用形态：网页、移动、小程序
进入编程项目后，扣子编程会用一句"扣子编程，从想法到实现------描述你想构建的应用，AI将帮你生成代码、搭建界面、部署上线"作为开场，并给出三种应用形态供你选择：网页应用、移动应用、小程序，如图13-2所示。三者的差异如下：
- 网页应用：在浏览器中运行，适合后台管理系统、数据看板、营销落地页等需要大屏与键鼠操作的场景。
- 移动应用：面向手机原生体验，适合需要调用相机、定位、推送等设备能力，且希望独立分发的产品。
- 小程序：依托微信／抖音等超级App的生态，无需下载、即点即用、天然具备社交分享能力，是个人轻应用与工具类产品最低门槛的发布形态。
图 13-2 "从想法到实现"页面：三种应用形态与需求输入框
对"续费管家"这样的个人工具而言，小程序是最合适的载体------用户在微信里就能随手打开,不必为一个查订阅的小工具专门安装一个App。因此，本案例选择"小程序"形态。图13-2下方的输入框里，已经写好了我们将要发给扣子编程的那段需求；同时可以看到底部的模型选择器（本例使用 Doubao Seed 2.0 Code）与"一键优化"按钮------后者能把口语化的需求自动补全为更规范的产品描述，是新手起步的好帮手。
13.3 一句话需求的解构：应用描述五要素
13.3.1 从一段产品化的指令说起
在前几章里，我们逐步提炼了面向工作流的提示词要素模型（第8章六要素、第9章七要素、第10章八要素，到第11章扩展为九要素）。需要特别说明的是：那一整套模型服务的是"工作流编排"范式，它的核心是"如何把节点的输入、输出、顺序讲清楚"。而本章的"应用生成"是一个全新的范式，它的提示词不再描述流水线，而是在描述一个产品。因此本章不沿用工作流的要素计数，而是另起一套并列的、专门面向应用生成的方法论------应用描述五要素。
本案例发给扣子编程的原始指令如下（也就是图13-2输入框中的那段话）：
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 请帮我生成一个微信小程序，名字叫"续费管家"。用来管理各种付费 订阅和会员（视频会员、云存储、健身卡、软件年费等）。 功能：添加订阅页（名称、费用、计费周期月/年、下次扣费日、 是否自动续费），首页按下次扣费日排序并显示距离到期天数， 到期前3天提醒，统计页展示每月固定支出总额和年度总支出。 可帮用户发现忘记取消的订阅。 |
这段话读起来像是产品经理顺手写下的一句需求，却恰好覆盖了一个应用最关键的五个侧面。把它拆开来看，就得到了"应用描述五要素"------产品定位与平台命名、数据模型、页面与导航、业务规则与计算、设计与部署约束。下面逐一拆解。
13.3.2 要素一：产品定位与平台命名
对应原指令："一个微信小程序，名字叫"续费管家"。用来管理各种付费订阅和会员"。
这半句话同时交代了3件事：平台（微信小程序，决定了构建目标与样式约束）、名称（续费管家，决定了应用标题、TabBar文案与品牌气质）、定位（管理付费订阅与会员，决定了整个应用的核心实体是"订阅"）。产品定位是五要素之首，因为它像一颗种子，后续的数据模型、页面、规则都从这粒种子里生长出来------"管理订阅"这四个字，已经隐含地宣告了"必然有一张订阅表、一个订阅列表页、一个新增订阅的入口"。
括号里那句"视频会员、云存储、健身卡、软件年费等"同样不可小看------它在为后续的"分类"字段提供枚举样本。扣子编程正是据此推断出了"视频／音乐／云存储／健身／软件／其他"这一组分类选项。这印证了一条经验：举例子，是把抽象需求"接地气"的最高效方式。
13.3.3 要素二：数据模型（实体与字段）
对应原指令："名称、费用、计费周期月／年、下次扣费日、是否自动续费"。
这是整段需求中信息密度最高的部分，它实际上是在口述一张数据库表的字段清单。一个有经验的开发者会立刻意识到：这串"名称、费用、周期、扣费日、是否自动续费"就是"订阅"这个实体的属性集合，扣子编程会据此设计出subscriptions数据表。数据模型是应用的骨架------页面是骨架上的皮肤，规则是骨架上的肌肉，没有骨架，皮肉无处附着。
把口语字段翻译成工程化的数据模型，是应用生成最见功力的一步。扣子编程在本案例中设计的 subscriptions表如表13-2所示------它不仅照单全收了笔者提到的字段，还补全了主键、分类、提醒开关、时间戳等笔者没说但应用必备的字段。
表 13-2 "续费管家"的核心数据模型（subscriptions表）
| 字段名 | 含义 | 类型 | 来源 |
|---|---|---|---|
| id | 订阅唯一标识（主键） | UUID | 应用必备（用户未提） |
| name | 订阅名称（如 Netflix） | 字符串 | 用户明确要求 |
| category | 分类（视频／音乐／云存储／健身／软件／其他） | 枚举 | 由举例推断 |
| cost | 费用金额 | 数值 | 用户明确要求 |
| billing_cycle | 计费周期（月／年） | 枚举 | 用户明确要求 |
| next_billing_date | 下次扣费日 | 日期 | 用户明确要求 |
| auto_renew | 是否自动续费 | 布尔 | 用户明确要求 |
| reminder_enabled | 是否开启到期提醒 | 布尔 | 由"提醒"推断 |
| created_at／updated_at | 创建／更新时间 | 时间戳 | 应用必备（用户未提） |
表13-2所示"来源"列尤其值得玩味：9个字段中，只有5个是笔者显式说出来的，另外4个（id、category、reminder_enabled、时间戳）是扣子编程基于工程常识补全的。这正是应用生成的"智能"所在------它不止是把指令翻译成代码，更会用一名资深工程师的直觉把我们没说全的部分补完整。
13.3.4 要素三：页面与导航结构
对应原指令："添加订阅页......首页......统计页......"。
需求中反复出现的"页"字，是在勾勒应用的页面骨架与导航结构。三个"页"------首页、添加页、统计页------恰好构成了一个标准的三Tab小程序：底部TabBar三个入口，分别承载"查看订阅清单""新增一条订阅""查看支出统计"三类核心任务。这是工具类小程序最经典、也最克制的信息架构。
扣子编程据此规划出pages/index（首页/订阅列表）、pages/add（添加订阅）、pages/stats（统计）三个页面目录，并配置一个三项TabBar------分别用House（订阅）、CirclePlus（添加）、ChartPie（统计）三枚图标。需要强调的是，页面与导航的边界一旦在需求里讲清楚，扣子编程就不会画蛇添足地堆砌多余页面；反之，如果需求含糊（"做个能管订阅的小程序"而不说清要哪几个页面），生成的导航结构就可能与我们的预期产生偏差。把页面数清楚、把每页的职责讲明白，是让生成结果可控的关键。
13.3.5 要素四：业务规则与计算逻辑
对应原指令："按下次扣费日排序并显示距离到期天数，到期前3天提醒，展示每月固定支出总额和年度总支出"。
如果说前三个要素决定了应用"长什么样"，那么这一要素决定了应用"怎么算、怎么动"------它是应用的业务逻辑与计算规则。本案例中至少藏着四条规则。
（1）排序规则：首页订阅列表按next_billing_date升序排列，让最快扣费的排在最前。
（2）倒计时规则：每张卡片显示"距今天还有几天扣费"，需要按当前日期实时计算 days_until_billing。
（3）预警规则：到期前3天（含）内的订阅，进入首页顶部的"即将到期"预警区并标记为amber 警示色。
（4）汇总规则：统计页把月付与年付折算到同一口径后，求出"每月固定支出"与"年度总支出"两个总额。
这4条规则是应用真正的价值所在------它们把一张静态的订阅清单，变成了一个会"替你算账、替你盯梢"的智能管家。尤其是汇总规则隐含着一个易被忽略的口径换算：年付订阅要除以12才能并入"每月固定支出"，月付订阅要乘以12才能并入"年度总支出"。把这类口径换算在需求中点明（哪怕只是"折算到每月"几个字），能显著降低生成结果在计算逻辑上出偏差的概率。
13.3.6 要素五：设计与部署约束
第五个要素是前四者的"收口"，它回答两个问题：成品要长成什么气质？要交付到哪里去？在本案例的原始指令中，设计与部署约束大多是隐式的------笔者没有规定配色、没有指定字体，把审美判断交给了扣子编程；也没有明说要部署到哪个具体的微信账号，只是默认了"微信小程序"这个目标平台。
扣子编程会为这类"留白"补上合理的默认值。在设计上，它判断这是一个理财／订阅管理类工具，主色选用了象征"信任与财务感知"的teal（青绿）渐变，预警色选用amber（琥珀），并以卡片式布局组织订阅信息（这部分判断会写进它自动生成的DESIGN.md与design_guidelines.md两份设计文档中）。在部署上，它把构建目标设定为H5＋微信小程序＋抖音小程序＋服务端四端，并预留了在预览区配置开放平台AppID的入口（详见13.6.4节）。
当然，设计与部署约束也完全可以显式声明。如果你对成品有明确预期，完全可以在需求里追加"主色用蓝色、风格极简"这样的约束，扣子编程会照单执行。把这一要素显式化的好处是减少返工------与其等成品出来再说"颜色不对"，不如一开始就把审美讲清楚。
|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 【提示】 应用描述五要素，可作为描述任何应用需求时的检查清单。 （1）产品定位与平台命名------这是什么应用、叫什么、跑在哪个平台。 （2）数据模型------核心实体有哪些、每个实体有哪些字段。 （3）页面与导航------一共几个页面、每页负责什么、如何在页面间跳转。 （4）业务规则与计算------排序、筛选、倒计时、汇总等动态逻辑。 （5）设计与部署约束------成品的气质风格与最终的发布去向。 它与第8~11章的"工作流提示词要素模型"并行存在、各司其职：描述流水线时用后者，描述产品时用本模型。把这5点讲清楚，扣子编程就能把你脑中的应用，忠实地落地为一个可运行的成品。 |
13.4 实现过程：一名"数字全栈工程师"的工作日志
发出那段需求后，扣子编程并没有立刻吐代码，而是像一名经验丰富的全栈工程师接到工单那样，先在"大脑"里盘了一遍整盘棋：这是什么项目、用什么技术栈、先做哪一步、后做哪一步。本节将沿着它真实的执行时间线，完整展开这份"工作日志"。
13.4.1 第一步：勘探与规划------AI如何理解"做一个应用"
扣子编程的第一个动作是"想清楚再动手"。从它的思考过程可以看到一条清晰的任务分解链：它先判断这是一个涉及多页面、需要后端API、需要数据持久化的复杂应用；随即决定走"TabBar三页＋NestJS后端＋数据库"的整体架构；接着把工作拆成可分批执行的阶段------先完成设计文档与数据库 schema，再同步数据库、生成TabBar图标、配置页面，然后开发后端、开发前端，最后统一验证与构建。
这种"先规划、分批次、可回溯"的工作方式，与第11章中扣子编程搭建数据质检工作流时"先查集成、再列节点、后写代码"的严谨一脉相承------无论是搭工作流还是生成应用，AI的专业素养都体现在"不急着写第一行代码"上。它甚至会主动创建DESIGN.md（设计风格思考）与 design_guidelines.md（设计规范）两份文档，把"为什么选teal主色、为什么用卡片布局"这类审美决策白纸黑字地记录下来，让后续的每一个页面都有据可依。
整个开发过程在界面上以"思考过程"与"执行命令／编辑文件／执行SQL"交替滚动的形式实时呈现，右侧预览区则显示"应用开发中"，如图13-3所示。这种全程透明的呈现，让"AI写代码"不再是一个黑盒，你可以清楚地看到它此刻在改哪个文件、跑哪条命令。
图 13-3 "续费管家"项目的开发过程（思考过程与终端命令）
13.4.2 第二步：技术栈选型------Taro＋NestJS＋Supabase
规划之后是选型。扣子编程为本项目敲定的技术栈，是一套在"多端小程序"场景下久经考验的组合，如表13-3所示。
表13-3 「续费管家」的技术栈构成
| 层次 | 技术选型 | 承担职责 |
|---|---|---|
| 前端框架 | Taro＋React | 一套代码编译到H5／微信／抖音多端 |
| UI与样式 | Tailwind+组件库（Card／Badge／Switch等） | 卡片布局、表单控件、统一设计令牌 |
| 图标 | lucide（taro-lucide-tabbar） | TabBar与页面图标 |
| 后端框架 | NestJS | RESTful API、控制器／服务／模块分层 |
| 数据库 | Supabase（PostgreSQL）＋Drizzle ORM | 订阅数据持久化、Schema管理、RLS |
| 校验工具 | ESLint＋TypeScript | 代码规范与类型安全 |
这套选型的精髓在于"一套代码、多端运行"：Taro让同一份前端代码可以同时编译出H5网页、微信小程序、抖音小程序三种产物，从根本上化解了13.1.2节里"多端割裂"这第二座大山。后端选NestJS，因为它的"控制器---服务---模块"三层结构清晰、天然契合RESTful风格；数据库选 Supabase（托管的PostgreSQL），并用Drizzle ORM做类型安全的schema管理，还顺手为 subscriptions表启用了行级安全（RLS）。值得一提的是，由于本应用没有登录体系，扣子编程判断这属于"公共读写"场景，于是采用service_role_key直连、仅启用RLS而不额外编写策略------这种"按需配置、不过度设计"的判断力，正是资深工程师与新手的分水岭。
13.4.3 第三步：后端API------一组规整的RESTful接口
数据库就绪后，扣子编程着手开发后端。它为subscriptions资源设计了一组标准的RESTful接口，并额外补充了两个面向业务的查询接口，如表13-4所示。
表13-4 "续费管家"后端API端点设计
| 方法与路径 | 职责 | 对应前端场景 |
|---|---|---|
| GET/api/subscriptions | 列出全部订阅，按下次扣费日排序 | 首页订阅列表 |
| POST/api/subscriptions | 新增一条订阅 | 添加页提交 |
| PUT/api/subscriptions/:id | 更新某条订阅 | 编辑订阅 |
| DELETE/api/subscriptions/:id | 删除某条订阅 | 首页卡片删除 |
| GET/api/subscriptions/stats | 返回月度／年度总额与分类占比 | 统计页 |
| GET/api/subscriptions/expiring | 返回3天内即将到期的订阅 | 首页预警区 |
这组接口的设计有两点工程巧思。其一是"资源＋派生视图"的分层：前4个是对subscriptions 资源的标准增删改查（CRUD），后两个/stats与/expiring则是把"统计"与"即将到期"这两类高频业务计算下沉到后端------前端只管展示，不必在客户端反复计算总额或筛选到期项，既减轻了前端负担，也保证了多端计算口径的一致。其二是"后端做计算，前端做渲染"的职责分离：GET /api/subscriptions直接返回带days_until_billing（距扣费天数）的数据，前端拿到即可显示，无需自己算日期差。每个接口写完后，扣子编程都会用curl当场自测，确认返回HTTP 200且数据结构正确，再进入下一步。
13.4.4 第四步：前端三页面与TabBar
后端打通后，扣子编程转向前端，按13.3.4节规划的导航结构，平行搭建3个页面。
首页（订阅列表）：顶部是一块teal渐变背景的"本月固定支出"概览卡；其下是"即将到期"预警区（3天内到期的订阅，标了amber警示）；再往下是按扣费日排序的全部订阅，每张卡片展示名称、分类徽标、费用、计费周期与距扣费天数，并支持滑动删除。
添加页（新增订阅）：一个结构化表单------名称输入框、6类分类选择器、费用输入框、月/年计费周期切换、下次扣费日期选择器，以及"自动续费""到期提醒"两个开关，底部是提交按钮。
统计页：月度/年度Tab切换，总额以大字突出展示，下方用进度条呈现各分类占比，并以提示卡片点出"疑似遗忘的订阅"------这正是回应了原始需求里那句"帮用户发现忘记取消的订阅"。
三个页面由底部TabBar串联。扣子编程用taro-lucide-tabbar工具一次性生成了三枚图标------House（订阅）、CirclePlus（添加）、ChartPie（统计），并配上主色 teal-600（#0D9488）的选中态。这里有一个真实的小插曲：它最初想用Home与BarChart3两个图标，发现lucide图标库里并不存在这两个名字，于是即时改用House与ChartPie。这种"尝试---发现不存在---换等价物"的自我纠错，在后面的13.5节里还会反复出现。
13.4.5 第五步：五道验证关卡
功能写完，扣子编程并不会直接宣布"做好了"，而是依次过五道验证关卡。这五关层层递进，从"代码本身合不合规"一直查到"前后端是不是真的对得上"：
（1）pnpm validate：跑ESLint与TypeScript，确认代码规范与类型无误。
（2）pnpm build：同时构建H5、微信小程序、抖音小程序、服务端四端产物，确认每一端都能编译通过。
（3）API测试：用curl逐一调用全部接口，确认都返回HTTP 200。
（4）前后端匹配：逐字段核对前端调用的URL、方法、参数、响应结构与后端是否完全一致。
（5）日志健康检查：通读运行日志，确认没有任何报错。
这五关中，第1关（pnpm validate）和第4关（前后端匹配）最容易暴露问题------它们恰好对应了13.5节将要详述的三个真实调试现场。换言之，"做完功能"到"五关全过"之间，往往隔着若干个需要AI与人协同排查的工程坑。这也正是13.1.2节所说的"第三座山"------最后一公里的工程闭环。
13.5 AI协同调试：3个真实的工程现场
第11章末尾，我们见证过扣子编程主动暴露并修复"股票代码000858前导零被吞成858"的真实bug，并由此得出"AI 生成的工作流并非开箱即生产"的告诫。本章的应用生成同样如此------在"五关全过"之前，扣子编程在屏幕上留下了一长串自我排错的痕迹。本节将精选其中3个最具代表性的现场，让你看清AI是如何像人一样"写错---发现---修复"的。理解这些现场，比单纯欣赏"一句话生成应用"的魔法更重要，因为它决定了你能否在真实项目里信任并驾驭这套工具。
13.5.1 现场一：被误删的函数体（formatCost）
第一个坑出在一次"顺手清理"的过程中。扣子编程原本想删掉一个不再使用的formatDate函数，却在执行字符串替换时，把紧邻的formatCost函数的函数体和右大括号一并删掉了------它把两个函数当成一整块替换掉了，只留下了formatCost的函数签名，函数体凭空消失。
后果是编译器报出一个看似莫名其妙的错误：文件明明只有208行，TypeScript却在第209行报"缺少一个右大括号 }"。扣子编程在思考过程中像侦探一样逐步追查：先怀疑组件函数没闭合、再数大括号深度、最后回看自己刚才那次替换操作，终于锁定真凶------"原来我删formatDate时，把 formatCost的函数体也一起删了"。定位之后修复就很简单：把formatCost的函数体补回去。
这个现场给我们的启示是：AI的"批量编辑"是一把双刃剑，它能高效改动大段代码，也可能在边界处误伤无辜。值得欣慰的是，扣子编程具备从"一个奇怪的报错"反向追溯到"自己上一步的误操作"的能力------这正是它区别于只会"一次性生成、出错就懵"的简单代码生成器的关键。
13.5.2 现场二：toast函数签名不匹配
第二个坑出在对一个工具函数的调用习惯上。扣子编程一开始按自己的"想当然"，用对象形式调用提示弹窗函数------写成toast({ title: 'xxx', type: 'success' });结果TypeScript报错：这个对象参数与toast的真实类型签名不匹配。
它没有强行绕过报错，而是回头去读toast函数的真实定义，弄清了它正确的API：第一个参数是标题字符串、第二个是可选的数据对象，且成功／失败／警告各有专门的方法。于是它把所有调用统一改写成了正确的形式，如下所示。
|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| // 错误用法（与类型签名不符）： toast({ title: 'xxx', type: 'success' }) // 正确用法： toast('已删除该订阅') // 普通提示 toast.success('添加成功') // 成功提示 toast.error('添加失败') // 错误提示 toast.warning('请输入名称') // 警告提示 |
这个现场的教训是关于"API契约"的：当调用一个别人（或别的组件库）写好的函数时，必须以它的真实签名为准，而不能凭借对相似API的印象想当然。扣子编程的处理方式堪称典范------遇到类型报错，不靠"@ts-ignore"之类的手段把错误压下去，而是回到源头读定义、改用法。这种"尊重契约"的素养，与第11章里前后端字段必须逐一对齐是同一种工程美德。
13.5.3 现场三：小程序不兼容的小数类名
第三个坑最具"小程序特色"。前端用Tailwind写样式时，扣子编程顺手写了一批带小数的工具类名，如mt-0.5（上外边距0.5）、px-1.5、py-0.5，以及带透明度简写的bg-amber-50/50。这些在浏览器里都合法，但ESLint校验时报错------微信小程序的样式子集并不兼容这类带小数点的类名与不透明度简化写法。
扣子编程定位到index.tsx、add/index.tsx、stats/index.tsx三个文件里散落的这些小数类名，逐一把它们替换为小程序兼容的整数值或等价写法。例如，把mt-0.5、px-1.5、py-0.5换成gap-2、px-2、py-0这类整数值，把bg-amber-50/50拆写为bg-amber-50配合bg-opacity-50。同时它还修复了add/index.tsx中一处JSX闭合标签的对齐告警。这一类"浏览器能跑、小程序报错"的兼容性问题，是多端开发最典型的暗礁。
三个现场连起来看，揭示了一个核心事实：多端应用的复杂度，远不止于"把功能写对"，更在于"让同一份代码在每个端的约束下都合规"。扣子编程之所以能交付一个真正可上线的小程序，靠的不是"一次写对"，而是"写完之后用pnpm validate/build一遍遍自查、发现不兼容就改到合规为止"这套严苛的收尾纪律。
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 【提示】 AI 生成的应用并非"开箱即生产"，工程审慎不可省略。 无论是第11章的"前导零被吞"，还是本章的"函数体被误删、API签名不符、小数类名不兼容"，都说明同一件事：AI能把应用从0做到95分，但那最后的5分------边界兼容、契约对齐、回归验证------仍需要开发者带着审慎去把关。把pnpm validate/build跑通、把每个接口实测一遍、在目标端的真机或模拟器上验证一次，是任何AI生成应用上线前都不能省的功课。 |
13.6 运行验证：庆贺"续费管家"的诞生
当3个调试现场尘埃落定、五道关卡全部亮起绿灯，扣子编程在对话区给出了它的结项报告："'续费管家'小程序开发完成，已通过全部验证。"报告里既列出了已实现功能，也逐条给出了验证结果，如图13-4所示。
图13-4 开发完成后的功能清单与验证结果
13.6.1 五项验证全部通过
先看图13-4所示下半部分的验证结果。5项检查全部通过，对照如表13-5所示。
表 13-5 "续费管家"的5项验证结果
| 验证项 | 检查内容 | 结果 |
|---|---|---|
| pnpm validate | ESLint代码规范＋TypeScript类型检查 | 通过✓ |
| pnpm build | H5＋微信小程序＋抖音小程序＋服务端四端构建 | 通过✓ |
| AP测试 | 全部接口返回HTTP 200 | 通过✓ |
| 前后端匹配 | URL／方法／参数／响应结构一致 | 通过✓ |
| 日志健康检查 | 运行日志无任何报错 | 通过✓ |
这张表中最有分量的是第2行------一次pnpm build同时构建出四端产物，且全部通过。它意味着我们在13.1.2节谈到的"多端割裂"那座大山，被Taro的"一套代码、多端编译"能力彻底夷平了。
13.6.2 前后端契约匹配验证
上面五项验证中，最体现工程严谨的是"前后端匹配"这一项。扣子编程没有满足于"前端不报错、后端能返回"这种表面正确，而是逐个接口、逐个字段地核对前端的调用与后端的实现是否严丝合缝。以首页列表接口为例，它的核对逻辑大致如下：
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 1. 首页GET/api/subscriptions 前端：Network.request({url: '/api/subscriptions' }) 后端：@Controller('subscriptions') + @Get() → 实际路由匹配✓ 响应：res.data.code===200，res.data.data为数组✓ 字段：id/name/category/cost/billing_cycle/ next_billing_date/auto_renew/days_until_billing ------全部在后端返回中存在✓ |
它用同样的方式核对了/expiring（即将到期）、/stats（统计）、DELETE:id（删除）、POST（添加）等每一个接口，确认前端期望的URL、HTTP方法、请求参数、响应字段无一错位。这种"逐字段对账"的做法，与第11章数据质检工作流中"前后端字段必须一一匹配"的精神完全一致------契约的一致性，是任何前后端分离系统能否真正跑通的生命线。
13.6.3 成品一览：运行界面
文字报告之外，更直观的是成品本身。图13-5是"续费管家"首页的真实运行界面。
图13-5 "续费管家"小程序运行界面（首页）
把这张运行截图与13.3节的需求逐条对照，会发现需求中的每一个字都被忠实地落到像素上：顶部teal渐变卡片大字显示"本月固定支出¥250.67/月"，正是"每月固定支出总额"；其下的"即将到期"预警区中，iCloud+与Spotify带着amber色的到期天数徽标；"全部订阅(4)"区域里，每张卡片都规整地列着名称、分类（云存储·年付/音乐·月付/视频·月付/健身·年付）、费用与到期天数；底部TabBar三枚图标------订阅、添加、统计------一字排开。一句话的需求，长成了一个有血有肉、可以真用的小程序。
13.6.4 预览与发布：配置小程序AppID
成品跑通后，最后一步是把它送到真正的微信生态中。扣子编程在预览区提供了"配置开放平台 AppID 并绑定"的入口，配置面板如图13-6所示。
图13-6 微信小程序AppID配置面板
面板的引导清晰分两步：第一步，打开微信公众平台注册一个微信小程序（面板里附了"小程序注册指引"链接）；第二步，在小程序后台依次进入"开发与服务→开发管理→开发者ID"，复制其中的AppID（形如wx开头的一串字符）回填（回填页面下滑可见）。绑定AppID后，平台会自动获取并展示预览二维码，用微信扫一扫即可在真机上预览。面板还贴心地提示：若希望让其他用户也能扫码体验预览态，需要前往微信平台把对方加入"体验成员白名单"。面板顶部的"微信／抖音"切换，对应的正是13.6.1节里那次pnpm build同时构建出的两个小程序端------这意味着同一个项目，既能发到微信，也能发到抖音。
13.6.5 设计目标与实际交付的对照
我们把13.3节那段需求里声明的核心诉求，与本节的实际交付逐条对照，如表13-6所示。
表13-6 设计目标与实际交付的对照
| 需求声明（来自原始指令） | 实际交付 | 验证 |
|---|---|---|
| 微信小程序、名为"续费管家" | 三端可跑的小程序，标题／TabBar均为续费管家 | 达成 |
| 添加订阅页（名称／费用／周期／扣费日／自动续费） | 结构化表单含全部字段＋6类分类＋提醒开关 | 达成 |
| 首页按扣费日排序、显示距到期天数 | 列表按next_billing_date升序、卡片显示倒计时 | 达成 |
| 到期前3天提醒 | 首页设"即将到期"预警区、amber标记 | 达成 |
| 统计页展示月度／年度总支出 | 月度、年度总额、分类占比进度条 | 达成 |
| 帮用户发现忘记取消的订阅 | 统计页设"遗忘订阅"提示卡片 | 达成 |
六项需求全部达成闭环，且没有出现遗漏或臆造的功能。这条"从一句话到一个上线小程序"的链路，已经具备了交付真实用户的能力。
13.7 经验总结与迁移应用
13.7.1 七条关键经验
"续费管家"体量不大，却完整跑通了"需求---生成---调试---验证---发布"的全链路。以下7条经验，对任何用扣子编程做应用生成的项目都有普遍的借鉴意义。
经验一：把需求当成"五要素PRD"来写，而非一句口号。决定生成质量的，是你把产品讲得有多清楚。用13.3节的五要素（定位与命名、数据模型、页面与导航、业务规则、设计与部署）逐项过一遍，哪怕只多写两句话，也能显著减少返工。模糊的"做个管订阅的小程序"和清晰的"3个页面、订阅表7个字段、按扣费日排序、到期前3天提醒"，得到的成品质量天差地别。
经验二：字段即骨架，举例接地气。数据模型是应用的骨架，把核心实体的字段一次性讲清楚，应用就有了稳固的承重结构。而"视频会员、云存储、健身卡"这样的举例，是把抽象需求落到具体枚举的最高效手段------AI正是据此推断出了6类分类。
经验三：让"算"下沉到后端，前端只管"显示"。本案例把统计总额、筛选即将到期这类计算放进了/stats、/expiring两个后端接口，前端拿到结果直接渲染。这种"后端计算、前端展示"的分工，既保证了多端口径一致，也让前端更轻、更稳。凡是涉及汇总、排序、筛选的业务逻辑，优先考虑放到后端。
经验四：多端的真正难点是"兼容"，不是"功能"。13.5.3节的小数类名问题提醒我们，浏览器能跑不等于小程序能跑。做多端应用时，一定要让pnpm build把每个目标端都真正构建一遍，把"浏览器合法、小程序非法"的暗礁在构建阶段就清理干净。
经验五：前后端契约必须逐字段对账。13.6.2节那份"逐接口、逐字段"的匹配清单是工程严谨的范本。前后端分离系统中，最隐蔽的bug往往不是"某一方写错了"，而是"两方各自都对、但对不上"------URL多了个斜杠、字段名差一个下划线，都足以让接口静默失效。把契约逐字段核对一遍，是上线前的必修课。
经验六：信任AI的自我纠错，但不放弃人的把关。三个调试现场都证明了扣子编程具备"从报错反查误操作"的能力，这值得信任；但13.5节的提示框也强调，最后那5分的边界兼容与回归验证仍需开发者亲自过目。把成品在目标端的真机／模拟器上亲自点一遍，是再聪明的AI也替代不了的一步。
经验七：留白处AI会给默认值，但显式声明能减少返工。用户没说配色，AI就自己选了teal。这种补全能力很强，但若你对成品的气质风格等有明确预期，不如一开始就在需求中写明------与其等成品出来再返工调色，不如把审美设计前置声明。
13.7.2 迁移场景矩阵
"续费管家"的本质，是一个"清单＋排序＋倒计时＋汇总"的个人轻应用骨架。这套骨架几乎可以原样套用到大量同构的生活场景------只需更换数据模型的字段、调整业务规则，就能快速衍生出一个新应用。表13-7给出一组典型的迁移场景。
表13-7 应用生成的迁移场景矩阵
| 衍生应用 | 核心数据模型 | 关键业务规则 |
|---|---|---|
| 证件／保单到期管家 | 证件名、号码、到期日、提醒开关 | 按到期日排序、临期预警 |
| 极简记账App | 金额、分类、收支、日期、备注 | 按日期排序、月度／分类汇总 |
| 药品服用提醒 | 药名、剂量、服用时段、库存 | 定时提醒、库存不足预警 |
| 生日纪念日提醒 | 对象、关系、日期、提醒方式 | 按临近日排序、N天前提醒 |
| 读书／追剧清单 | 标题、分类、进度、状态 | 按状态分组、完成度统计 |
| 设备保修期管理 | 设备名、购买日、保修月数 | 保修剩余天数、临期提醒 |
| 健身打卡计划 | 项目、目标、频率、记录 | 连续打卡统计、完成率汇总 |
从这张表可以看出，"续费管家"并不是一个孤立案例，而是一个可复用的"个人轻应用模板"。凡是符合"管理一组同类条目、按时间排序、临期提醒、按维度汇总"这一模式的需求，都能用同一套五要素描述法、同一套Taro＋NestJS＋Supabase技术栈，在一小时内生成出来。这正是应用生成范式最大的生产力红利------它让"为自己或身边人写一个趁手小工具"这件事，从"奢望"变成了"日常"。
13.7.3 何时用应用生成，何时用工作流编排
学完本章，大家现在的工具箱里已经同时有了"工作流编排"（第8~12章）与"应用生成"（本章）两件利器。本节将给出一份在二者之间做选择的决策清单，如表13-8所示。
表13-8 应用生成与工作流编排的选择决策清单
| 如果你的需求是...... | 更适合的范式 | 典型例子 |
|---|---|---|
| 把一件确定的事自动跑一遍、要一份结果 | 工作流编排 | 每天生成行业热点简报 |
| 让一群用户随时打开、反复使用一个产品 | 应用生成 | 订阅管理小程序 |
| 处理一批输入、产出一批结构化数据 | 工作流编排 | 电商图自动打标、数据质检 |
| 需要持久化存储、长期维护一份数据 | 应用生成 | 记账App、清单工具 |
| 逻辑是"节点串联的流水线" | 工作流编排 | 采集→清洗→仲裁→报告 |
| 逻辑是"多页面＋增删改查＋交互" | 应用生成 | 三Tab的工具类小程序 |
| 既要流水线、又要给人用的界面 | 二者组合 | 工作流产出数据，应用消费展示 |
表13-8的最后一行尤其重要------在真实的复杂项目中，应用生成与工作流编排往往不是二选一，而是组合使用：用工作流在后台默默把数据治理好（如第11章的可信数据集），再用一个应用把这份数据漂亮地呈现给用户。能在两种范式之间精确切换，并把它们编织进同一个解决方案，正是AI原生时代工程师与独立开发者最核心的素养。
13.8 小结
本章以一个真实可上线的微信小程序"续费管家"为案例，完整呈现了扣子编程"从想法到实现"的全栈应用生成能力------笔者只需用一段自然语言把产品讲清楚，扣子编程就能自主完成技术选型（Taro＋NestJS＋Supabase）、数据建模、后端API、前端三页面与TabBar、四端构建、五关验证乃至预览发布的全过程，交付一个前后端齐备、三端可跑的完整应用。
贯穿全章的主线，是一次范式跃迁------从第8~12章的"工作流编排"，跨入"应用生成"。前者组织节点、产出一份结果，后者搭建系统、交付一个可长期使用的产品。本章用表13-1划清了二者的产物边界，又用表13-8给出了在二者间做选择的决策清单：用户要"算一次"就搭工作流，要"天天用"就生成应用，复杂项目则二者组合。
从方法论层面看，本章另起一套专门面向应用生成的"应用描述五要素"------产品定位与平台命名、数据模型、页面与导航、业务规则与计算、设计与部署约束。把这五点讲清楚，扣子编程就能把脑中的应用相当忠实地落地为成品。从工程细节层面看，本章通过3个真实的协同调试现场（误删函数体、API签名不符、小数类名不兼容），揭示了"AI生成的应用并非开箱即生产"这一与第11章"前导零被吞"一脉相承的工程审慎。
把第5和6章的网页与简易应用、第7章的Agent、第8章的单链工作流、第9章的多模态多渠道工作流、第10章的数据采集工作流、第11章的数据质检工作流、第12章的结构化打标工作流，与本章的全栈应用生成放在一起回望，一条清晰的能力进阶之路便浮现出来：从"方便易用的应用""会推理的智能体"，到"能编排的流水线"，再到"可交付的完整产品"。扣子编程的真正价值，正是在于让这条进阶之路上的每一步，都不再以"会不会写代码"为门槛，而只以"能不能把需求讲清楚"为前提。
当"为自己写一个小程序"可以在一个下午甚至短短一小时内完成，软件开发就从少数人的专业技能，变成了人人可及的表达方式。这或许才是AI原生开发时代最深刻的改变------把"实现"的成本压到足够低，从而把舞台，真正还给了"想法"本身。
13.9 思考与练习
- 回顾13.3节的"应用描述五要素"（产品定位与平台命名、数据模型、页面与导航、业务规则与计算、设计与部署约束）。请为"证件/保单到期管家"这一应用，按五要素逐项撰写一段不超过 40行的需求描述，并特别设计：数据模型应包含哪些字段？"临期提醒"的业务规则如何表述才能让 AI准确实现"可自定义提前N天提醒"？
- 13.3.5节指出，统计页的"每月固定支出"需要把年付订阅折算到每月（除以12）、把月付订阅折算到年度（乘以12）。请思考：如果再引入"季付""两年付"等更多计费周期，汇总规则该如何统一表述？请写出一段能覆盖任意计费周期的"折算到每月"的规则描述。
- 13.4.3节展示了本案例把/stats与/expiring两类计算下沉到后端的设计。请讨论：如果改为"前端计算、后端只存数据"，会带来哪些问题（提示：从多端口径一致性、客户端性能、网络流量三个角度分析）？反过来，是否存在某些场景更适合"前端计算"？
- 13.5节呈现了三个真实的调试现场。请从中任选一个（如"小数类名不兼容"），检索后说明：为什么微信小程序的样式子集不支持这类写法？再列举至少两类其他"浏览器合法、小程序非法"的常见兼容性陷阱，并说明各自的规避方法。
- 13.6.2节展示了"前后端逐字段对账"的匹配清单。请为POST/api/subscriptions（新增订阅）接口，仿照该清单的格式，写出一份完整的前后端匹配核对表------逐项列出URL、HTTP方法、请求体字段、响应结构，并标注每一项前端与后端应当如何保持一致。
- 13.7.2节给出了应用生成的迁移场景矩阵。请任选其中一个场景（如"极简记账App"或"药品服用提醒"），用"应用描述五要素"完整地写出它的需求，并画一幅它的页面与导航结构草图（标注每个Tab的名称与职责）。
- 本章把"应用生成"与第8~12章的"工作流编排"界定为两种并行范式。请设想一个需要二者组合的真实项目（例如：用工作流每日抓取并清洗某行业的价格数据，再用一个小程序把价格走势展示给用户）。请画出这条"工作流＋应用"的整体链路图，并说明数据是如何从工作流的产物流向应用的展示层的。
- 把第7章的数据分析Agent、第8~12章的5个工作流，以及本章的全栈应用生成放在一起对比。请用一张你自己设计的二维矩阵（X轴为产物的使用频率：一次性↔长期反复，Y轴为产物的形态：一份结果↔一个系统），标出这7个案例的相对位置，并解释每个位置背后的范式选择逻辑。
