一期多花九千建的三张表，二期省下四万二

二〇二四年四月接的一个单子，客户是做实验室耗材的经销商，代理十一个品牌，在用的产品目录是一份 Excel，一千四百多个 SKU，市场部两个人维护。预算八万，需求说得很清楚：一期只要展示型官网，在线询价和客户中心留到第二年二期再做。

方案会上最先吵起来的不是首页长什么样，是这一千四百个产品放在哪。

那九千块钱的分歧，写在报价单上只有一行字

市场部的想法很实际：产品当文章发，一个产品一篇，图文混排，谁都会改，两周能录完。技术这边坚持要单独建 product 表，字段拆开——品牌、类目、SKU 编码、规格参数、包装单位、起订量、库存状态、价格可见性。其中后四个字段一期页面上根本不显示，纯粹空着。

代价是多六个工作日，报价从七万一涨到八万。老板问了一句很关键的话：二期要做询价的时候再改，行不行？

技术上当然行，改字段随时能改。真正拦路的是那一千四百条已经录进文章正文里的数据，要把型号、规格、单位从一段图文里拆回结构化字段，是纯人工活。按一条三分钟、还要逐条核对规格表算，七十个小时起步，中间出错还得返工。这句话说完，老板同意了那九千块。在网站建设的报价单上，它只被写成一行「产品数据结构化处理」，看不出任何分量。

建了用户表，但一期连登录入口都没有

一期没有会员体系、没有登录、没有购物车，页面上任何地方都点不出账号两个字。表还是建了，七个字段：主键、手机号、企业名称、客户编码、密码哈希、创建时间、状态。

关键在「客户编码」。这家企业内部有一套用了六年的进销存系统，所有老客户在里面都有编号。二期要做订单进度查询，网站账号必须能和系统里的客户对上，否则查出来的订单是谁的都说不清。这个字段一期全是空的，但表结构和唯一索引先立在那儿。

建表本身只花了半天。真正耗时间的是想清楚「二期的账号要跟谁对齐」，前后开了两次会，每次一个半小时。分期做网站建设时这一步最容易被跳过：先确定二期的数据要跟谁对齐，再决定表怎么建，顺序反了就白建。会上还否掉了一个提议——有人建议顺手把收货地址表也建了，被否的理由是：地址字段怎么拆取决于二期用哪家物流的接口，那时候连物流商都没选。

页面是服务端直出的，却还是先做了两个接口

一期整站服务端渲染，产品列表页直接查库输出 HTML，这是最快也最省事的做法。技术这边多做了一步：把产品列表和产品详情单独做成两个 JSON 接口，页面自己再去调这两个接口取数。多花三天，首屏响应从一百八十毫秒变成两百四十毫秒左右。

理由不复杂。二期的询价车、订单状态查询一定是异步的，如果一期数据出口是直出，二期等于把取数逻辑重写一遍，还要长期维护两套可能不一致的口径。在网站建设的分期规划里，接口层是最容易被当成过度设计砍掉的一项，因为它在一期完全看不出效果。

也留错了一块，四天工时打了水漂

同一次评审里，还给产品表和文章表都加了英文标题、英文内容和语言标识字段，路由也改成支持 /en/ 前缀。起因是老板提过一句「以后可能做外贸」。四天工时，折算大约五千元。

二期开工时，外贸计划早就搁置了，这批字段一条数据都没有，反倒在后来的数据备份、字段校验和后台表单里持续制造干扰，新来的运营还问过为什么每篇文章下面有两个空白输入框。

这块钱的教训不是「不该预留」，是判断标准用错了。它确实是数据层的东西，但它对应的业务方向当时根本没有时间表，只是一句设想。

二期开工的头一周

二〇二五年一月启动二期，原本预估十二万、四十五个工作日，实际做下来七万八、二十六个工作日。省掉的部分很集中：产品数据零迁移，直接在原表加四个字段，一天搞定，原计划两万六的数据清洗预算完全没花；账号对接内部系统，因为客户编码字段和索引现成，五天完成，原估十二天；前端询价车直接复用一期那两个接口，全程只新增了三个接口。

还有一件当时没算进去的事：二期换了服务商，原团队人手排不开。新团队第一周只干了两件事——读一期交付的数据字典文档、跑通本地环境，第三天就提交了第一个可运行版本。换作没有那份文档、靠读源码倒推业务规则，同等体量一般要五到八个工作日才敢动手改。

分界线不在功能清单上，在数据形态和功能形态之间

回头看，值得在一期预留的是数据形态，不值得的是功能形态。数据形态指表结构、字段拆分粒度、主键外键关系、编码规则这类东西，它的改动成本随数据量和时间往上走——一千四百条时改要七十小时，等目录长到五千条就是两百五十小时以上。功能形态指登录页长什么样、询价车放在哪个位置、按钮走什么颜色，这类改动成本基本恒定，早做晚做差不多，早做反而容易做错，因为二期的真实需求还没长出来。

多语言字段之所以留错，是因为它虽然属于数据形态，业务方向却是悬空的。所以判断线还要再加一道：只有当二期需求已经写进计划、时间落在十二个月以内，数据层的预留才算成立。超出这个范围的设想，记进文档就够了，不必落到表里。

另一条是预留必须有交付物。一期结项时交了一份四页的字段说明，逐条写清哪些字段现在是空的、为什么留、二期打算怎么填。换服务商那次，这份东西比源码注释管用得多。不少网站建设项目分期做砸，不是败在没预留，是留了没人知道，第二年接手的人看见一堆空字段，第一反应是清理掉。

这家企业今年三月开始筹备第三期，想接一个经销商分销板块。这回他们自己在需求文档里加了一节，标题写着「本期不做但需要预留的字段」，列了六条。其中四条被开发驳回了，理由是分销返佣用哪种模型还没定，字段形态定不下来，硬留就是第二个多语言字段。剩下两条通过：订单表加一个来源渠道字段，产品表加一个分销价字段，加起来半天工时。分期做网站建设能到这个状态就算顺了——知道该问什么，也肯承认有些问题现在还答不上来。