企业官网建设流程全解析

1. 前八期做到哪一步了：为什么这一期选择先写功能定义

看潮企业管理软件的功能定义3-1，这周终于过完评审了。先说结论：这一期没有写一行业务代码，但大部分时间都花得值。

先说背景。这门课的编号是编程与数学03-008，项目代号看潮企业管理软件，本质是拿一个从0到1的企业管理系统，把编程基本功和数学建模串起来。前面八期我们按里程碑走完了需求访谈、用户权限模型、核心表结构设计、基础档案模块开发这些阶段。客户管理、商品管理、供应商资料这些基础档案已经能跑起来，采购流程也搭了个雏形。到了这一期，按理说可以闷头写订单接口了，但负责带项目的老师按住了所有人：先把功能定义文档写清楚，再谈写代码。

当时我第一反应是"文档又要写一大堆，代码进度又得拖"。但等我真把3-1文档，也就是销售订单管理模块的功能定义写完，回头再看，才发现这一步是整个项目里最省时间的环节。原因很简单：企业软件里最贵的从来不是写代码，是需求理解不一致导致的重做。你以为你理解的"订单"和业务方以为的"订单"，往往不是同一个东西。

所谓功能定义，就是站在需求和设计之间做翻译。需求文档说的是"销售要能下单，仓库要能备货，财务要能核对金额"，这是业务语言。功能定义要回答的是：订单有几个状态？状态之间谁有权限改？订单号和商品名称是什么规则？金额怎么算、精度保留几位？库存什么时候扣？系统在什么边界条件下该报错？把这些全部落成一条条可评审、可验收的规则，开发人员后面做的事就变成了"照着规则实现"，而不是"边写边猜"。

3-1这个编号也不是随便起的。整个看潮系统的功能模块被分成六个大块：1基础档案、2采购管理、3销售订单管理、4库存管理、5财务管理、6系统设置。每个大块下面再从1开始细分。这次提交的3-1，就是第三大模块的第一份功能定义文档，内容锁死在"标准销售订单"这个子模块上。后续还会有3-2、3-3，分别对应退货售后和订单流程的消息通知。模块编号定清楚之后，文档、代码分支、测试用例都能用同一套编号对齐，后面追问题会省很多力气。

2. 从乱七八糟的需求到功能清单：先做减法再做加法

功能定义不能凭空写。这期的第一步，是把前面需求访谈阶段攒下来的原始记录重新翻出来，逐条映射成功能点。最原始的需求文本长什么样？我举几个真实的例子：

• 销售说："下单的时候最好能看到这个客户以前买过什么、上次什么价格，不然每次都要翻聊天记录"
• 仓库说："订单一审核过，赶紧通知我们去备货，别等我们问了才知道"
• 财务说："系统里的订单金额必须和手工算出来的对得上，别出现一分钱差"
• 客服说："客户打电话问单到哪了，我得能查到进度，不能老去问销售员"

这些原话有一个共同特征：它们描述的是"感受"和"想解决的问题"，不是"系统该有的功能"。功能定义要做的第一件事，就是把每个感受翻译成一个边界明确的系统动作。比如"看到客户以前买过什么"翻译过来是：订单创建界面的客户选择模块，加载该客户最近12个月的订单列表和最后一次成交单价；"赶紧通知备货"翻译过来是：订单状态变更为已审核之后，库存模块的待备货任务池自动生成一条记录，同时触发站内通知。这一步做完，我们得到一份二十九条的功能点草表，有新建订单、选择客户、商品明细编辑、历史价格展示、自动汇总金额、订单审核、库存预占、备货通知、订单查询、订单导出等等。

但这二十九个功能点不能全往下一阶段推，否则又会掉进"什么都想做、什么都没做好"的坑。于是我们借用了数学课上讲到的排序工具，给功能点打分。具体用的是RICE模型的简化版：每个功能点按覆盖范围（多少人用得上）、影响程度（解决多大痛点）、信心指数（我们多确定这个判断）、成本（人天估算）四个维度打分。覆盖范围给1到5分，影响程度给0.5到3分，信心指数给0.5到1分，成本从高分到低分倒着排序。最终得分等于前三个相乘再除以成本。

举个例子，"新建订单"这个功能：销售、仓库、财务、客服四个角色都会间接用到，覆盖面4分；没有它整个系统就是空壳，影响程度3分；判断很确定，信心指数0.9；估算成本12人天。得分是4乘3乘0.9再除以12，结果0.9。"订单导出Excel"覆盖面3分，影响程度1分，信心0.5，成本3人天，得分0.5。高下立判。这个打分过程看起来像是在做数学题，实际上是在逼团队把模糊感觉变成可比较的排序。有了这张排序表，原定二十九个功能点最终砍到了十九个进3-1，剩下十个不是不做，而是明确挪到3-2或者后续迭代。

3. 3-1订单管理功能定义明细：字段、状态机与边界规则

排序完成之后，剩下的就是硬功夫：把十九个功能点逐条拆成字段级和规则级的定义。功能定义文档在这个环节开始长得像一本小型规格说明书，但每一条都有它存在的理由。

3.1 订单主流程：从新建到归档的六步走

3-1覆盖的主流程是标准销售订单，不包含特殊定价、赠品、部分发货这些特殊情况，那些属于3-2的扩展内容。标准流程我们最终定为六个步骤：

1. 销售员创建草稿订单，录客户、选商品、填数量和单价，系统实时汇总金额。此时订单只存在于创建者自己的视图里，别人看不到。
2. 销售员确认提交，订单进入待审核状态。提交之后订单内容不可再随意修改，改需要走变更流程。
3. 审核员打开待审核列表，核对客户信息、价格、金额，通过后订单变为已审核。
4. 订单已审核后，仓库的待备货池出现任务，库存做预占扣减，订单变为备货中。
5. 仓库完成打包出库，订单变为已发货。
6. 客户签收（系统内由客服标记），订单变为已完成。已完成订单保留数据，不再参与日常业务，进入只读状态。

每一步都有对应的角色和权限，不能跳，不能逆。这套流程看起来平淡，但它是整个订单模块的脊椎骨，后面所有字段定义、状态机、验收标准都围着它转。

3.2 订单头与订单行的字段级定义

订单数据结构分成两层：订单头和订单行。这是个经典设计，头记录一张订单的整体信息，行记录每一个商品明细。订单头字段包括订单号、客户ID、下单时间、期望交货时间、订单状态、备注、创建人、审核人、审核时间、金额汇总。订单行字段包括行号、商品ID、商品名称快照、单价、数量、税率、折扣、行小计。

这里必须强调"商品名称快照"这个字段。很多人第一次设计订单表会直接关联商品档案表，订单查询时再连表取名称。这在开发期确实省事，但上线半年就出问题：某商品改了个名字或者被下架，所有历史订单里的名称跟着变，客户对账时发现以前的订单写的是旧名字，而系统显示新名字，扯皮不可避免。正确做法是在订单行里冗余一个商品名称字段，下单时从商品档案拷贝一份进来，之后商品档案怎么改都不影响历史订单。快照的理念不只用于名称，单价、税率也都应该以下单那一刻的值为主。

金额计算规则也在这期定义死了：行小计等于单价乘以数量乘以折扣折算比例，再按税率计算税额；订单金额汇总等于所有行小计之和。看上去是小学数学，但实际工程里最容易出问题的恰恰是这一步。后文还会专门讲浮点精度和舍入规则，这里先不展开。

3.3 订单状态机：谁在什么条件下可以改变状态

状态机是功能定义文档里最不能含糊的部分，因为它直接约束后端接口的写法和前端按钮的显示。我们用了一个非常朴素的状态枚举：

草稿、待审核、已审核、备货中、已发货、已完成、已取消、已驳回、已关闭。

状态迁移规则如下：

禁止任何跨级跳转。比如从草稿直接变成已完成，系统必须拦截。这个规则一旦在代码里写成"后端只允许更新到下一状态"，前端再花哨也绕不过去。还有一条硬约束：已取消、已完成、已关闭这三个终态订单不允许修改任何字段，只能新增关联的售后单据。别小看这条规则，没有它，后面做退货对账时会发现金额怎么都对不上。

3.4 订单号的编码与校验位算法

订单号是订单模块的门面，功能定义里也得写清楚规则。我们采用的格式是：ORDER + yyyyMMdd + 三位当日流水号 + 一位校验位。比如 ORDER20250512016，表示2025年5月12日当天第16笔订单，最后一位是根据前几位算出来的校验位。

为什么要加校验位？因为订单号在业务沟通里会被口头报、被抄写、被复制，前面那串数字只要错一位，查单就会查不到。校验位的作用是让一个简单的数学计算就能识别号码是否写错。我们用的是模10加权算法：把订单号前15位数字从右往左依次乘以权重2和1交替，求加权和，再用10取模得到校验位。举个简化例子，假设主体部分是12345，权重交替后计算结果是1乘1加2乘2加3乘1加4乘2加5乘1等于21，21除以10余数为1，校验位就是9减去1等于8，最终单号是123458。录入时如果有人打成123468，重新算一遍校验位会得到7，和末尾8不匹配，系统立刻提示号码异常。一个简单的取模运算，把人工录入的错单率降了一个数量级，这就是数学直接用在业务里的典型场景。

4. 输出物三件套：流程图、用例表和验收标准

功能定义不能只有文字描述，那样评审时谁也提不出具体意见。3-1文档最终附带了三样东西：一张订单流程图、一套用例表、一份验收标准清单。这三样合在一起，才让"功能定义"从抽象概念变成可执行的任务书。

4.1 流程图：把流程锁死，不给两边留缝

流程图画出来的那天，团队里第一次出现激烈讨论。起因是最初的流程图里，销售员提交订单之后可以直接流转到已审核，因为画图的人觉得单子不大销售额不高，没必要层层审批。但业务方的同学当场反对：哪怕一百块钱的单子，价格没经过审核就不算数，不然月底对账时销售总监没法交代。于是最终流程图在待审核节点加了一个菱形判断框，明确只有审核通过才能进入备货，驳回则回退草稿。

画图工具不重要，重要的是把每个判断分支、每个操作角色都画出来。我们的流程图不是那种只有"新建、保存、提交"三个框的应付式流程，而是具体到"创建订单""修改订单""提交审核""审核通过""备货中""登记发货""标记完成"这些节点，并且每个节点都标了操作角色。流程图挂墙上的好处是，前端开发做页面跳转参考它，后端开发写接口状态引用它，测试用例设计也照着它走。一张图统一了所有人的认知，比二十页的文字描述管用得多。

4.2 用例表：把每个动作的边界条件一栏清

用例表是功能定义文档的正文核心。3-1一共写了二十一用例，按角色分组：销售员侧十个，审核员侧四个，仓库员侧四个，客服侧三个。每个用例包含用例编号、参与者、前置条件、主流程、备选流程、异常分支。

以UC-ORD-001"创建订单"为例，格式大致是：

• 参与者：销售员
• 前置条件：销售员已登录系统，客户档案和商品档案已存在，商品库存为正
• 主流程：进入订单管理页，点击新建订单，选择客户，选择商品并填写数量单价，系统自动计算金额并展示订单汇总，点击保存生成草稿订单
• 备选流程：客户曾经下过单，系统在客户选择后展示历史成交价，销售员可一键带入最近一次成交价
• 异常分支：商品库存不足、客户状态为停用、订单金额超过当前销售员限额，系统均拦截并给出明确的提示文案

用例表的妙处在于，它是给测试组直接用的。测试同学拿到用例表，不需要再自己脑补需求，直接把主流程、备选流程、异常分支一一变成操作步骤，覆盖率立刻上去。

4.3 验收标准：从"能用"到"算过"

功能定义如果没有量化验收标准，开发完到底合不合格全凭感觉。3-1里我们给每个用例配了验收标准，写得非常直白：

验收标准里有一条是后来补的：库存扣减后不允许为负。这条很重要，也是下面要展开说的超卖问题的一部分。没有这条标准，开发可能只在界面层做了库存校验，并发请求一来照样打出负库存。

5. 从定义到编码之间最容易踩的四个坑：现在写文档就是为了以后不返工

功能定义文档里最有价值的部分，往往不是那些顺畅的主流程，而是事先暴露出来的模糊地带。把模糊地带在文档期消灭掉，比在编码期发现再改要便宜十倍。我在这个环节整理出四个我们实际遇到的雷区，每个都在3-1里有对应的规则描述。

5.1 金额字段的精度与舍入：不要被浮点数骗了

这是个老生常谈的坑，但几乎每个项目都会踩一次。计算机里的浮点数没法精确表示大部分十进制小数，0.1加0.2算出来不是0.3，而是0.30000000000000004。企业管理系统里订单金额随随便便几百条明细，连续算下来误差就出来了。财务说的"系统金额必须和手工算的对上"，指的就是这个。

3-1规定，所有金额字段一律使用精确数值类型，数据库里是decimal(12,2)，代码里对应的是十进制运算类型，禁止使用二进制浮点数做金额计算。单价保留四位小数用于记录，展示和汇总统一保留两位小数。每一行明细先算行小计，最后汇总订单总额，不允许从商品单价直接加乘得到总额。舍入规则也定死：四舍五入，每行小计保留两位后再做汇总，汇总结果保留两位。这些规则写进验收标准之后，开发就不用再纠结算法，直接照做。

5.2 交期与时间字段：日历日和自然日的区别

订单上有两个时间字段容易忽略：期望交货时间和下单时间。下单时间好办，存数据库时间戳就行。期望交货时间却有个问题：业务上说的"三天内到货"，到底是自然日的三天还是工作日的三天？如果客户周三下单，业务承诺三天，实际系统给的时间是按周五算还是下周一才算？我们最终定义：订单里的期望交货时间一律按自然日的日历时间计算，但仓库排产计划模块如果需要工作日计算，后续在3-2的功能定义里单独做一套工作日历配置，当前3-1不处理。

还有一个时间衰减问题。商品页面的历史价格展示时间范围，我们定的是最近12个月。这个时间要用下单时间所在月份倒推，不能简单地取当前系统时间减365天，因为业务方说的"一年内"在财务对账时通常指12个自然月。类似的规则还有：订单完成后超过24个月自动归档，查询默认不显示归档订单。这类时间边界如果不写进功能定义，开发会自己猜，十个开发能猜出十种规则。

5.3 库存扣减与超卖：从定义层就想清楚并发策略

订单审核通过后要扣库存，这个规则好定。真正难的是并发场景：两个销售员几乎同时审核通过两个订单，订单里都要买同一个商品，而库存只剩一件，系统怎么处理？如果实现方式是先查库存够不够，够就扣，两个请求同时查到库存为1，都认为够，于是都执行扣减，库存就变成了负数。这是典型的超卖问题。

3-1给的处理策略是：库存扣减必须在数据库层执行一个条件更新，更新语句里带上"当前库存大于等于本单数量"的条件，并在同一事务里完成扣减。如果影响行数为0，说明库存不足，订单不允许从已审核流转到备货中，系统提示销售员补充库存后再处理。这个方案的数学本质，是把"检查库存"和"扣减库存"合并成一个原子操作，让并发请求不可能同时通过检查。文档里写了这个规则之后，后端开发就不会再写出"先查再扣"的代码，前端页面也能依此给出合理提示。

5.4 权限边界：谁能改价、谁能审核、谁能冲单

订单模块的权限定义在功能定义阶段往往被低估，但它直接影响系统安全。3-1的权限规则是：销售员可以创建和编辑草稿订单，但一旦提交进入待审核，就不能再改订单金额和商品明细。审核员可以驳回或通过订单，但审核员不能是自己创建的订单，也就是说创建人和审核人不能是同一个人，避免单人走完全流程。修改销售单价权限分两级：普通销售员只能使用标准价格，销售主管可以在标准价格基础上有上下百分之十的调价空间，超过百分之十的折扣必须额外走特价审批流程。以订单金额超过一万元为界，超过限额的订单强制要求部门主管二次审核。

权限规则全部落成矩阵表，横轴是角色，纵轴是订单操作，交叉点是允许或禁止，没有"视情况而定"这种模糊表述。权限矩阵的作用是让前后端开发能直接映射成接口权限注解和按钮灰化逻辑，也让测试能针对每条权限规则写正向和反向用例。

6. 本期交付物和下一步计划

3-1评审通过之后，交付物清单如下：一份功能定义文档，编号3-1，包含十九个功能点；一张订单主流程图；二十一用例表；一份验收标准清单；权限矩阵表；订单号生成规则说明。整个文档算下来四十多页，每一页都对应后续开发中的具体决策。

评审会上大家吵得最凶的三个点，最后都落成了规则。第一是改价审批，原来销售员希望百分百自由改价，财务坚持必须留痕，最后各退一步，百分之十以内浮动销售员自理，超过百分之十走特价审批，这个规则同时写进了权限矩阵和状态机。第二是库存预占时机，销售希望下单就锁库存，仓库担心锁了不出货积压库存，最终定在审核通过后才扣减，这个折中让两边都能接受。第三是历史订单要不要保留完整商品快照，开发起初嫌字段冗余，一想到财务对账场景，全员同意加快照字段。

这期最大的收获，我个人的体会是：功能定义文档不是一个形式主义的产物，而是一份把业务不确定性压缩掉的契约。编程和数学在这个环节的交汇点也比想象中多，排序打分是加权平均，状态机是离散数学的图结构，校验位是模运算，库存原子扣减是并发控制里的比较与交换思想。这些数学工具在纸上看起来离业务很远，真正落到系统设计里却每天都在发挥作用。

下一期要推进的3-2模块是销售退货和售后处理，牵扯到红冲、退款、退货入库、坏账计提这些更绕的业务。有了3-1这套功能定义的完整流程做底子，3-2开工时我们至少知道该在哪些环节较真、哪些环节可以放心交给后续开发。项目还在继续，看潮的管理软件里的订单模块，已经从一句话需求变成了一张能落地施工的图纸。