需求对接完就发布任务，做到一半才发现理解错了：对接需求的四个坑 😭😭😭

本文正在参加 #全新 TRAE 实战体验

赛道：全链路开发实战

导语：最近对需求，发现很多隐藏问题可能会造成返工------都是当时没人问、返工了才知道该问的点。我将情况和 Trae 沟通了一下，Trae 帮我总结成一份清单：今后对需求，就优先确定这些会导致大范围返工的注意事项。

也顺带回答一个常见困惑：前端是不是真的考虑不到后端那么多？

一、遇见的情况

业务背景是 B 端的实验室信息管理系统，订单从下单、检测、出报告，流转链路很长，新增需求 就是其它部门PM提供excel或者群中沟通需求，之前写过一篇文章：PM 丢来 3 个 Excel、12 个功能、4 种情形？用 TRAE Work 30 分钟整理成前端开发文档。

我和 PM 对接完需求，整理成一个一个的任务就发布下去了，看着一切正常。但其实有些细节没人问清，开发做到一半，一沟通才发现理解有问题：

• 用户："这里应该能同时选多个检测项目，怎么只能选一个？" ------ 需求没写细，对需求时也没人问，前后端就都按最直觉的 1 对 1 做了（默认单选谁都会，主动想到多对多的很少）

• 用户："报告里的样品名称怎么变了？我们要的是下单时的名字。"

• 用户："新单子是以上一单为基础的，但合同和样本我要能换绑，怎么锁死了？" ------ 开发理解成了整个单子从头流转到尾，压根没考虑要换绑；

• 用户："这个字段每个环节都要能改，怎么到下游就变只读了？"

• 用户："这个样本上一单已经用过了，怎么还能再选？"

每一句话背后，都是一轮返工：前端改页面，后端改接口和数据结构，测试重跑一遍。

问题出在哪？不在技术难度，而在对需求时少问了几句话。我将情况和 Trae 沟通了一下，Trae 帮我总结出了下面这份清单：今后对需求，就优先确定这些会导致大范围返工的注意事项。

真实截图

二、如何解决

解法不是让前端去学后端，而是把这些容易造成大范围返工的隐藏问题，变成对需求时的固定问题清单，逐条确定清楚。

坑 1：先确定几对几的关系

踩坑现场：需求说"订单里要能选检测项目"就这么一句。

没人追问细节，前端按单选做了下拉，后端按单值存了项目 ID ------ 这不是谁理解错了，而是没人提的时候，前后端都会用最省事的 1 对 1 方案：单值字段、单选下拉，顺着直觉就写了，很少有人主动停下来想 "这里会不会是多对多"。

代码一碰就"对上了"，一路顺利开发。结果做到一半和用户确认细节，一句话就问出来了："实际业务一个订单要同时选多个项目，这怎么只能选一个？"

这句话埋着雷：

• 一个订单只能选一个项目？（1 对 1）
• 一个订单可以选多个项目？（1 对多）
• 一个项目还能被别的订单引用？（多对多）

关系不同，后端的表结构、接口返回形态完全不同，前端的组件也完全不同：

// 1 对多：接口返回里项目是数组，前端用多选/明细表格
{ "orderNo": "SO202601", "items": [{ "id": 1, "name": "水分检测" }, { "id": 2, "name": "灰分检测" }] }

// 1 对 1：项目是单个对象，前端用单选下拉
{ "orderNo": "SO202601", "item": { "id": 1, "name": "水分检测" } }

正确做法：对需求时优先确定几对几的关系，直接把关系说出口 ------ "这里是一个订单对多个检测项目，多对多，项目可复用"，关系一定，后端的建表方案和前端的页面结构就都定了。

坑 2：单子基于之前的单子下单，是整体流转，还是中途可以变更

踩坑现场：需求说"这次下单是基于之前的单子来的"。

单子虽然是基于之前的单子下单，但业务上可能中途需要换样本、换合同 ------ 这种要重点沟通。

开发一听就按最直觉的理解做了：新单子把上一个单子的内容整体带下来 ------ 绑的什么合同、什么样本，就原样用什么，一个单子从头流转到尾，全程不可改。

结果做到一半和用户一确认："新单子上我要能换绑别的合同和样本。"

这时候才发现，"基于前面的单子"这句话压根没人拆开问过：

• 哪些信息是原样带下来、不许动的？
• 哪些只是默认带过来、用户可以换绑的？
• 换绑之后，上游单子要不要受影响？

开发把"整体流转"当成了默认答案，而业务要的是"部分锁定 + 部分可换"。

正确做法：对需求时对着单子上的信息一项项过，问清是整体流转，还是中途可以变更 ------ "这个信息是从上游单子锁定流转下来的，还是默认带出、允许用户换绑的？"

比如：

• 单号、来源单据 → 锁定流转，不许动
• 合同、样本绑定 → 默认继承，但允许换绑，换绑要留痕

坑 3：一个字段之前有，问清是继承还是新增

踩坑现场：单子是从上一个单子流转下来的，新旧单子上都有一个同名字段。

开发想当然认为是继承 ------ 上游带下来的，下游不能随便改，于是做成了只读回显。

结果做到一半一沟通："这个字段每个环节都要能改。" ------ 业务上这个字段每张单子各有一份，每个环节都可以独立编辑。

同名字段，可能是完全不同的两种东西：

• 继承：字段只有一份，下游只是引用上游的值，默认只读，改动要走特殊流程
• 新增：每张单子独立存这个字段，只是名字一样，其实每个环节都可以改

两种理解，后端的存储结构和校验逻辑完全不同，做反了就是返工。

这和坑 2 的换绑是同一类问题，只是对象从"绑定的合同、样本"换成了"字段本身"。

正确做法 ：一个字段之前有，不要想当然认为是继承，问一句："这个字段是继承之前的单子，还是本环节新增的？"这句话的成本是十秒，返工的成本是三天。

坑 4：下游选样本，选过的还能再选吗

踩坑现场：业务上，一个单子可以创建另一个单子，创建的时候要选样本。

开发没问一句：已经被别的单子选过的样本，还能不能再选？就顺手做成了候选列表里随便选。结果用户提出："这个样本上一单已经用过了，怎么还能再选？"

这本质上还是坑 1 那道数据关系题，只是主角从"检测项目"换成了"样本"：

• 样本被一个单子选走就算"占用"，别的单子不能再选？（独占引用）
• 一个样本可以被多个单子重复引用？（共享引用）

而且同一个系统里两种都可能存在：有的场景样本选过就不能再选，比如检测完就消耗掉了，重复选用容易出数据事故；有的场景允许重复选，比如：留样复测，同一个样本本来就要支持多次下单。

到底哪种，必须让产品逐场景说清楚，不能默认。

正确做法：对需求时问"创建下游单子选样本时，已经被别的单子选过的样本还能不能选？哪些场景能、哪些不能？"如果业务上不允许重复选，后端就要在选择时做占用校验，前端要处理"样本已被占用"的拦截提示。

那么，前端真的考虑不到后端那么多吗？

不是能力问题，是视角问题。

后端天然盯着数据结构，前端天然盯着交互和展示------各自盯着自己的一亩三分地，中间的空白地带就成了返工重灾区。

解法不是让前端变成半个后端，而是带一张问题清单去对需求：

1. 几对几的关系确定了吗？（1 对 1 / 1 对多 / 多对多）
2. 单子基于之前的单子下单，是整体流转，还是中途可以变更？
3. 之前就有的字段，是继承之前的单子，还是本环节新增的？
4. 选样本时，被选过的还能再选吗？哪些场景能、哪些不能？

三、专业词汇

词汇	本文语境下的含义
1 对多 / 多对多	两条数据之间的数量对应关系，决定后端建表方案和接口返回的是数组还是单个对象
流转	上游单子的信息随业务流程带到下游单子，"整体流转"指所有内容原样继承且不可改
换绑	下游单子默认继承上游的绑定关系（如合同、样本），但允许解除并重新选择其他对象
锁定流转	该信息从上游单子原样带下来，下游不许修改；与之相对的是"默认带出、可换绑"
继承 / 新增	上游就有的字段，下游拿到后是"继承"（字段只有一份，引用上游的值、默认只读），还是"新增"（每张单子各存一份、默认带出、可编辑），要逐字段问清
独占引用	一个对象（如样本）被某个单子选中后即被占用，其他单子不能再选；与之相对的是"共享引用"，允许被多个单子重复选用
占用校验	选择样本等环节，后端校验该对象是否已被其他单子占用，拦截业务上不允许的重复选用

四、总结

1. 先确定几对几的关系：1 对 1、1 对多、多对多------关系不同，后端的表结构、接口返回形态完全不同，前端的组件也完全不同

2. 整体流转还是中途可变更 ：单子基于之前的单子下单，但可能中途要换样本、换合同，这种要重点沟通，别把"整体流转"当默认答案

3. 继承还是新增 ：一个字段之前有，问清是继承之前的单子，还是新增的，不能想当然认为是继承

4. 选过的样本能不能再选：哪些场景独占、哪些可复用，逐场景问清楚

今后对需求就优先确定这几个会导致大范围返工的问题 ------ 照着清单过一遍，再进入开发！

五、Trae 带来的提效

提速：上面这些点，要是我自己慢慢踩坑、慢慢总结，估计得好久才能攒齐。而把踩过的坑丢给 Trae，几分钟就帮我梳理成了这份结构化的清单。

返工实测减少：按这份清单对需求，多问几句之后，返工次数明显减少了------花几分钟问清楚，比返工几天划算多了。

具体聊天：