别急着写代码：多项目场景下，为什么「前后端设计」这一步最值钱

别急着写代码：多项目场景下，为什么「前后端设计」这一步最值钱

AI 编程工具普及之后，写代码越来越便宜，"设计"越来越贵。单项目时代你很容易忽视设计——反正 AI 生成快，错了重来成本低。但多项目场景下，设计错误的代价翻倍：接口设计错了，前后端一起返工；表结构错了，数据迁移比写代码贵得多。飞算JavaAI 的智能引导五步里把"设计接口、表结构设计"显式放在"处理逻辑、生成源码"之前，就是这个道理。这篇文章讲讲在多项目场景下，为什么前后端设计这一步最值钱，以及怎么把设计做在前面。

一、一个返工成本对比，看清设计的价值

先算一笔账，用同一个需求的两个做法对比——订单模块加"按支付状态筛选"。

做法A：跳过设计，直接让 AI 生成。

• 第 1 轮：输入需求，AI 生成后端接口 + 前端页面，接口参数 status；
• 上线前评审发现：筛选还应该支持按"支付渠道"过滤，status 单参数不够；
• 返工：后端加参数、前端加筛选维度、表结构可能要加冗余字段、测试用例重写；
• 成本：一场联调 + 一轮回归 + 一次上线延期。

做法B：先设计后端接口定义、返回结构、表结构，再让 AI 生成。

• 第 0 轮：花 10 分钟把接口设计写成"status + channel 双筛选维度、分页、兼容旧调用方"；
• 第 1 轮：把设计丢给 AI 生成，一次成型，评审通过；
• 成本：10 分钟设计 + 一轮生成 + 一轮验收。

两个做法的代码量差不多，成本差在哪？差在返工杠杆：设计阶段改一个字段，成本是改一行字；代码阶段改一个字段，成本是改前后端 + 测试 + 回归。多项目场景把杠杆又放大了一倍——一个接口设计错误，前后端两套代码同时返工。

二、多项目场景，设计错误为什么更贵

单项目场景下，设计错误的影响是局部的：接口没设计好，后端返工，前端受影响有限。

多项目（前后端分离 + Workspace）场景下，一次设计错误沿两条链路扩散：

链路1：接口设计错 → 前后端双返工。

接口是最先固化的契约。设计错了，后端实现要改、前端调用要改、接口文档同步改、测试用例重写。而且按"生成的代码已对齐"的特性，两端代码是一起生成的——设计错，两端一起错，返工也一起返。

链路2：表结构错 → 上线后代价指数增长。

表结构设计错了，返工不在代码层，在数据层：字段类型不对要改结构、缺索引要补、冗余字段要删，生产环境还要考虑数据迁移。表结构的返工成本是"横跨设计、开发、运维三个阶段"的，远高于接口。

所以多项目场景的设计要求更高：不只是"页面能跑"，而是接口契约稳固、数据模型稳固——因为一个错误会同时击穿前后端的整条链路。

还有一种更隐蔽的贵：设计错了，AI 会"忠诚地"放大错误

多项目场景下设计错误的代价还有一个放大机制，很多人没意识到：AI 会把你的设计错误原样放大到两端。

单项目手工开发时，设计虽然错了，但前后端是两个人各自实现的，有时歪打正着能补掉一部分偏差；而多项目模式下，AI 基于同一份（错误）设计生成两端代码，它不会"纠偏"，只会"忠实执行"——你接口契约里写错一个字段名，前端和后端会以同样错误的名字对齐。生成得越彻底，错误的传播越完整，返工时两端要一起改。

这就把"设计先行"从"好习惯"升级成了"必要动作"：设计是唯一能让 AI 在正确方向上自主发挥的输入，输入错了，生成越高效越可怕。反过来也说明，验收时对着设计产物逐条核对，是最便宜的一道防线——在 AI 把错误放大成两套代码之前拦住它，比改两套代码便宜一个数量级。

三、多项目设计，到底设计什么

把"前后端设计"具体化，拆成三件事：

1. 设计接口契约。

明确三件事：

• 路径与语义：POST /order/export 还是 GET /order/export？导出是幂等操作应该用 POST；
• 参数与结构：哪些是必填、哪些可选、分页默认值、返回的包装结构；
• 兼容性：老版本客户端不传新参数时，行为是否和以前一致。

2. 设计数据模型。

接口返回什么，先去看数据要存什么：

• 字段类型：金额用 decimal，状态用枚举还是字符串；
• 索引策略：按状态筛选、按时间排序的字段有没有索引；
• 扩展预留：将来要加的维度（渠道、区域），现在建模就留好。

3. 设计交互边界。

前端不是"数据展示器"，交互边界要设计：

• 空态：筛选结果为空，页面显示什么；
• 加载态：请求中的 UI 状态；
• 错误态：接口报错时前端如何提示、是否可重试。

这三件事的设计产物，是 AI 生成代码的输入。设计得越清楚，AI 生成的代码越接近交付状态——而不是"能跑但哪哪不对"的初稿。

设计三类产物各自的"验收红线"

设计产物写完了，怎么判断写得好不好？给每类一条红线：

接口契约的红线：随便找一个懂业务的同事，让他读了之后能直接说出"这个接口支持哪些调用方式、不传哪些参数会发生什么"。 如果读完还要问你，说明契约写得不完整。契约是给"另一个乙方"执行的，必须是自足的文件。

数据模型的红线：模拟一次"需求变更"来检验。 比如问自己：如果下周要加一个"按区域筛选"，现在的建模要改几张表、几个接口？改动越小，建模越稳。模型设计时"扩展预留"写得好不好，模拟一次变更立马见分晓。

交互边界的红线：把三态（空/加载/错误）各问一遍"页面显示什么"。 任何一态答不上来，边界就是空的。前端"能跑"和"可用"的差距，全在这三态里——生成代码最常丢的就是这三态，你在设计里写死了，AI 才会生成，验收也有依据。

三条红线都过了，再往下给 AI 生成，才叫"设计先行"；没过就往下走，叫"带着半成品设计去赌生成质量"。

四、一个设计流程示例：把设计做在生成前面

用一个完整示例，看"设计先行"怎么落地。需求：订单列表支持按状态筛选，前端列表页加下拉 + 分页。

第1步（5分钟）：写接口契约。

接口：GET /api/order/list
参数：
  status: 可选，枚举 PAID / UNPAID / REFUNDED，不传查全部
  page: 可选，默认 1
  size: 可选，默认 10
返回：
  { code, data: { list, total, page, size } }
兼容性：status 不传时走原有逻辑

第2步（3分钟）：写数据模型要求。

字段：order_status，字符串，索引；查询按该字段过滤时走索引
排序：按 create_time 倒序，该字段已有索引
扩展：预留 pay_channel 维度，本期不做，接口不暴露

第3步（2分钟）：写交互边界。

前端下拉选项：全部 / 已支付 / 未支付 / 已退款
筛选变化时重置页码并重新请求
空结果展示空态：'暂无符合条件的订单'
请求失败：toast 提示，保留上次数据

第4步（生成）：把三份产物丢给智能会话。

“按以下设计实现前后端：接口契约……数据模型要求……交互边界……前后端一起改。”

生成后逐项验收：接口参数对不对、字段名是否一致、空态有没有做、分页重置行为对不对。验收对照的是第 1~3 步的设计产物，不是凭感觉看代码。

同样的设计，交给生成和交给人有什么区别

有人会问：设计都做完了，交给 AI 生成和交给初级开发实现，有差别吗？差别在执行质量上：

第一，AI 不会"漏需求"。你写了四条验收项，它会照着四条生成；初级开发也会照着四条改，但实现细节（比如分页重置时机）可能被遗漏。AI 的"逐条执行"更稳定。

第二，AI 会"顺带对齐"两端。你设计里写了 status 参数，AI 生成后端时会用这个参数，生成前端时也会用这个参数——它天然是两端一致的。人实现时，前端和后端各写一遍，对齐靠人自觉，就容易漏。

第三，AI 不会"自作主张"。初级开发遇到设计没写清的地方，会自己拍脑袋补一个行为，这个"补充的行为"可能和设计意图冲突；AI 在输入没写清时通常会保守处理或在生成后提示你确认——它更"照章办事"。

所以设计先行的收益不只是"少返工"，更是让生成的执行质量可预期——你设计了什么，它就交付什么，验收时你检查的是"设计对不对"，而不是"实现跑偏没有"。

五、为什么"设计先行"和 AI 编程工具天然合拍

过去"设计先行"难以坚持，有个现实原因：手工时代写的代码贵，设计的时间机会成本高——你花 10 分钟设计，不如直接写 10 分钟代码，反正都要写。

AI 编程工具把这个等式改写了：代码生成近乎免费，设计的门槛反而显性化。

• 以前：10 分钟设计 vs 写 1 小时代码，设计机会成本高 → 大家直接写；
• 现在：10 分钟设计 vs 生成 2 分钟代码，设计的机会成本变成"只多 8 分钟，但能让生成结果一次到位" → 设计成了高杠杆动作。

这正好对上那句话：“大模型解决代码问题，AI 编程工具解决工程问题”——代码问题（怎么写）交给大模型，工程问题（设计什么、边界在哪、怎么验收）正是人要投入的地方。多项目场景把这个分工推到极致：一个设计错误击穿两端，设计质量的杠杆被放到最大。

六、给"设计先行"的三个实操建议

建议1：把设计写进需求描述，而不是只在脑子里过。 AI 能读到的只有你输入的内容，设计在脑子里等于没设计。把接口契约、数据模型、交互边界写进需求描述，AI 生成直接对齐，你验收也有了锚点。

建议2：设计产物只写"必须固化的"，不写"可自由发挥的"。 接口参数、字段类型、兼容性必须写死；页面布局、组件选型、内部实现让它发挥。设计管住契约，不管住实现，给生成留空间。

建议3：为"设计变更"留流程。 多项目场景设计错了不丢人，丢了流程才伤：变更接口时，先改设计产物（契约文档/需求描述），再重新生成前后端，让两端在同一份设计上重新对齐。过程化了，“重来一次"的成本就从"双端返工"降到"重新生成”。

设计产物的载体怎么选

说了半天"写设计"，具体写在哪？结合多项目场景的实践，按场景选载体：

场景一：一次性需求的临时设计。 直接在需求描述里写，随需求一起进智能会话。好处是上下文完整，AI 生成时读的就是同一份文本；坏处是不好复用。适合三十分钟内能搞定的中短需求。

场景二：高频复用模块的接口设计。 单独建一份契约文档（Markdown 足够），需求描述里引用它。比如"订单模块的接口契约按 docs/order-api.md 执行，本次需求只新增筛选与导出"。AI 能读到的话，契约就是稳定的输入，不会被每次需求带偏。

场景三：跨团队的核心数据模型。 除了 Markdown，建议在代码里落一份规范定义（如 OpenAPI/Swagger 的 yaml，或带注释的实体定义），让 AI 和人都以代码内的定义为准。数据模型是全局事实，值得用最权威的载体。

载体不用统一，原则只有一条：设计产物要"进得了 AI 的输入"。写在自己笔记里、画在白板上的设计，AI 读不到，等于没有设计。

七、总结：设计是 AI 编程时代最值钱的一步

最后把这篇的价值浓缩成三句话：

1. 代码越来越便宜，设计越来越贵——AI 让生成近乎免费，设计错误却让前后端双返工，杠杆被放大；
2. 多项目场景设计管三件事——接口契约、数据模型、交互边界，这三份产物就是 AI 生成的输入；
3. 设计先行的本质是分工——把"代码问题"交给大模型，把"工程问题"（设计、边界、验收）真正扛起来。

别急着写代码。在多项目场景下，先花十分钟把接口契约和数据模型定下来，再让 AI 生成——你会发现自己拿到的不是"能跑的初稿"，而是"接近交付的成稿"。这十分钟，是整个 AI 编程工作流里性价比最高的一笔投入。