企业官网建设流程全解析

1. 需求评审会上“说着说着就吵起来”的那张需求卡

上周的需求评审会，产品经理放出一张卡片：“支持订单扩展特征。”研发组长问了一句：“扩展特征是什么？订单模块现有的功能不都上线了吗？还要加哪些？”产品经理答：“就是一些可选增强，比如合同价、赠品、审批，具体我再细化。”会议室安静了两秒，然后开始了熟悉的拉锯。会后我才意识到，问题不是需求没想好，而是“扩展特征”这个说法本身没有一个能被拍板的定义。它既不是普通功能描述，也不是用户故事里的验收要点，它是夹在“基础能力”和“未来可能性”之间的一块灰色地带。

我在团队里推了一个做法：凡是涉及扩展特征的需求，一律用“用例（Use Case）”的方式定义。标题就叫“定义扩展特征【用例】”。这里的“用例”不是测试用例，而是需求工程里的用例——描述谁在什么场景下、通过系统和系统产生哪些交互、最终拿到什么结果。用用例给扩展特征做定义，核心价值只有一个：把“以后可能要做”变成“现在可以说清怎么做才算做完了”。这篇文章就围绕这个做法展开，适合正在做产品规划、需求分析、后端设计或者测试设计的同学，特别是那些被老板一句“这个功能先按扩展特征预留一下”折磨过的人。

1.1 扩展特征到底是什么：我习惯先给一个“能拍板”的定义

先说结论：我理解的扩展特征，是系统在基础主流程之外、可独立评估和启用的一组可选能力，它服务于特定角色、特定业务条件或特定小众场景，平时不干扰大多数用户的主路径，一旦条件满足便被触发或开放。

举个例子更好懂。订单创建是电商系统的基础主流程：选商品、填地址、提交订单、支付。它是系统存在的根本，任何用户都要走。那么“企业客户在下单时可以自动匹配合同价”“运营配置赠品后，订单中出现赠品行”“金额超过阈值时先走审批再下单”这些东西算什么呢？它们不是主流程的必需步骤，而是根据客户类型、订单内容、金额区间等条件“长出来”的能力单元。这就是扩展特征。

一个合格的扩展特征应当满足三个条件：

• 非必需：基础流程不依赖它也能闭环；
• 有明确触发条件：什么角色、什么业务状态、什么配置项会导致它生效；
• 可独立验收：能单独测、单独上线、单独关闭，不会把主流程搞断。

很多团队把扩展特征当作“普通功能的加强版”，写在PRD的某个角落里，最后开发只能靠猜。我不建议这么做。扩展特征最好被当成一个独立的能力单元来定义，而不是主流程的补充说明。

1.2 为什么常规需求模板装不下扩展特征

传统的需求描述方式大概分两种：一种是功能列表式，比如“系统支持订单修改”“系统支持多级审批”；另一种是用户故事式，比如“作为销售，我希望在提交订单时能上传附件，以便补充证明材料”。

这两种方式处理普通需求够用，但处理扩展特征都有明显短板。功能列表式的问题在于它只描述“系统要做什么”，没有描述“在什么条件下做”，也没描述“做完对用户有什么价值”，于是扩展特征常常变成一堆散装功能点。用户故事式的问题在于它强调“谁的诉求”，但扩展特征往往有两个甚至多个参与角色，比如“运营配置了赠品规则、普通用户看到赠品行、库存系统扣减赠品库存”，一个用户故事根本装不下，硬写就会变成一段没人看得懂的复杂句子。

另外，扩展特征天然和“分支”绑定：条件A触发一个行为，条件B触发另一个行为，条件C直接拒绝。常规模板没有给分支留出结构化的位置，于是大家习惯在需求文档里写一大段“如果……那么……否则……”，读起来累，开发还容易漏。用例恰好解决了这个问题：它用基本流和扩展流把“正常路径”和“分支路径”分开，每个分支都能单独评审、单独排期、单独测试。

1.3 用例恰好是扩展特征最合适的容器

为什么不是流程图，不是状态机，而是用例？我的体会有三点。

第一，用例天然以“用户可感知的价值”为核心。扩展特征最容易犯的错就是做成“技术预埋”，比如“预留接口”“设计成可扩展”，但用户根本感知不到。用例强行把视角拉回业务：这个特征到底让哪个角色获得了什么结果？写不出来的话，这个扩展特征就不该存在。

第二，用例的扩展流适合承载“边界情况”。扩展特征之所以是扩展特征，恰恰是因为它在主流程之外的边界里运行。用例的基本流模拟主流程全景，扩展流逐个覆盖异常与分支，正好对应扩展特征的触发逻辑。

第三，用例的“场景感”适合作为开发和测试的沟通桥梁。开发看用例知道代码要写在哪个扩展点，测试看用例知道要准备哪些数据、走到哪一步断言什么。相比之下，一句话功能描述很难做到这一点。

所以我现在的习惯是：当需求文档里出现“可选”“增强”“预留”“特定场景下”这些词时，就单独给这个能力开一个用例定义，而不是让它挂在主流程下面。这是“定义扩展特征【用例】”的第一原则。

2. 先想清楚：扩展特征和用例到底谁服务谁

有一个问题我每次评审都会问：这是一个扩展特征，还是一个用例？很多人分不清。扩展特征是能力本身，用例是描述能力的载体。一个扩展特征通常对应一个为主用例或附加用例；但反过来，一个用例里可以有多个扩展点，不一定每个扩展点都要上升到扩展特征的级别。

2.1 扩展特征在系统中的位置：从主流程长出来的可选能力

把系统想象成一条主干道。基础流程是成年人每天通勤走的那条路：红绿灯、斑马线、公交站都稳定存在。扩展特征则是高峰期的潮汐车道、特殊天气下的融雪撒布、有贵宾来访时的临时管制——它们平时不在主流体验里，一旦条件被满足，就会被激活，而且激活后会对通行规则产生一定约束。

这种“位置感”对设计很重要。它决定了我们怎么实现扩展特征：是在主流程里加if，还是把扩展特征做成独立模块、通过配置开关接入？我的经验是，只要扩展特征被识别出来，第一步就要明确它与主流程的交互方式：

• 插桩式：主流程里预留扩展点，特征触发时插入一段处理逻辑；
• 旁路式：主流程跑完，扩展特征独立异步处理，例如下单后触发风控审核；
• 覆盖式：扩展特征改变主流程的某个子步骤，例如企业用户不再进入标准价格计算。

这三种方式对系统架构、测试范围和数据一致性的影响完全不同。在用例定义阶段，至少在“影响范围”里写清楚是哪种交互，否则开发拿到需求时又要重新做架构决策。

2.2 一用例一特征：粒度划分的实操判断方法

实操时我最常被问：“赠品管理算一个扩展特征，还是‘赠品校验’和‘赠品库存扣减’算两个？”我的判断标准有三个，全部满足才算一个独立扩展特征：

• 它是否有一个完整的业务目标，能给某个角色带来可独立描述的价值；
• 它是否可以被单独启用或关闭，而不会影响其他扩展特征；
• 它是否可以用一组触发条件、一个基本流、若干扩展流完整描述。

拿赠品举例。“运营可以配置赠品规则”和“用户下单时能看到赠品行并自动扣减赠品库存”，这两件事虽然都围绕赠品，但前者是后端的配置能力，后者是C端场景能力，触发角色不同、业务目标不同、验收方式也不同。硬塞进一个用例，会导致配置任务和下单场景互相干扰。我的建议是拆成两个用例：一个叫“配置赠品规则”，一个叫“订单准予赠品校验”，前者服务于运营，后者服务于用户。

反过来也有合并的场景。比如“订单金额变更后重新计算税额”和“订单金额变更后重新计算优惠”，如果它们在同一业务规则下被触发、结果又都落到“订单金额重新计算”这个目标上，拆成两个用例反而会让规则分散。此时更应该用一个用例“订单金额变更后的价税重算”，把税额、优惠、合同价都作为该用例下的业务规则。

2.3 扩展关系（extend）与扩展特征的关系：别把UML符号和业务语言混在一起

用过UML用例图的同学都知道“扩展关系（extend）”这个符号：一个用例在某些条件下插入另一个用例的扩展点。扩展特征在建模时经常被表达成扩展关系，这没问题，但我要提醒一个误区：不要把UML里的“扩展”直接当成业务文档里的“扩展特征”。

UML的扩展关系描述的是用例之间的引用逻辑，比如“登录”用例在“用户未设置密保问题”时扩展到“设置密保”用例。业务语言里的“扩展特征”更强调能力的可选性和独立性。两者有关联但不完全等价。建模图上可以把扩展特征画成扩展关系，但在PRD和用例说明里，我更倾向直接写清触发条件、前置条件和业务规则，而不是画一堆符号让业务方猜。

我见过最糟糕的文档：画了一张密密麻麻的用例图，扩展关系箭头满天飞，但每个扩展点对应什么规则、什么时间被触发，一句都没写。结果评审会一半时间在解释箭头，另一半时间在争论“这到底算不算扩展”。用例图可以用，但它只是索引，不是定义。真正的定义要落在用例描述里，落到每条可执行的业务规则上。

3. 给扩展特征写用例：我用的五段式模板

给扩展特征写用例，我有一套固定的模板，它不是教科书上的标准格式，而是我结合实际项目迭代过很多版的写法。核心思路是把“场景”“逻辑”“规则”“验收”“影响”五类信息拆开，避免揉在一段话里。

这个模板看起来不算薄，但真正写起来，一个扩展特征通常只需要半页纸到一页纸。如果超过两页还写不完，说明这个“特征”粒度太大，应该拆。

3.1 先把触发场景写具体：扩展特征最怕“到时候再说”

模板里我最看重的是“触发场景”。很多扩展特征之所以最后变成没人维护的僵尸功能，就是因为触发场景写得像诗：“当用户可能需要优惠时”“在特殊情况下触发”。这种描述等于没写，开发没法编码，测试没法造数据。

触发场景建议按照“谁 + 在什么业务状态下 + 遇到了什么条件”的公式写。拿合同价来举例：

• 错误写法：当客户有合同价时。
• 正确写法：销售在企业客户提交订单的结算页选择“合同价优先”模式，且该客户编号在价格系统中存在生效的合同价记录时。

这两句话的差别，不只是信息量，而是可执行性。前者没法判断“有合同价”到底以什么数据为准；后者把角色、操作位置、数据条件都限定了，开发和测试拿到就能动手。

另外，我要求触发场景必须包含“为什么此时需要这个特征”的业务意图，不能只写技术条件。技术条件只描述“系统能做什么”，业务意图解释“为什么这个条件算数”。比如合同价的业务意图是企业客户与电商平台签了框架协议，价格必须按协议走，不能被标准价体系覆盖。写清楚意图之后，后续如果有新人接手需求，也不会改错规则。

3.2 基本流和扩展流的写法：用分支而不是用步骤描述策略

基本流不要写得像“用户点了一下，系统弹了个框”这种伪步骤。基本的写法要求每个步骤都有“谁发起了什么动作 + 系统如何处理 + 产生了什么结果”。更重要的是，基本流只写扩展特征被激活后的正常过程，不要试图在基本流里把所有真实系统的判断都铺开。

举个例子，某系统要做“订单逾期提醒”的扩展特征。如果基本流写成：

1. 系统定时扫描订单。
2. 如果订单逾期，生成提醒。
3. 如果用户未读，再次提醒。
4. 如果用户已读，停止提醒。
5. 如果订单已支付，取消提醒。

这就错了，这不是基本流，而是把五个分支揉成了一段伪代码。我会这么拆：

1. 系统对状态为“待支付”且超期3天的订单生成“订单逾期提醒”。
2. 系统判断目标用户消息通道偏好，选择站内信或短信。
3. 系统发送提醒并记录发送日志。

扩展流则拆成：

• 3a. 通道发送失败：系统重试1次，仍失败则写入失败队列。
• 2a. 消息通道偏好为空：系统默认使用站内信。
• 1a. 订单逾期超过7天：系统升级提醒文案并增加紧急标识。

这样拆分的好处是，测试用例可以从基本流和扩展流直接生成：基本流一条主路径，每个扩展流至少两条用例（正常分支+回退分支）。没有这种结构化写法，测试同学很容易漏掉“订单已支付但提醒还没取消”这种边界。

3.3 业务规则单独成表：把“如果”抽出来

扩展特征往往携带着一堆容易打架的规则。比如合同价、阶梯价、会员价、促销价同时存在，到底哪个优先？这种问题如果散落在基本流和扩展流里，每次评审都会重复讨论。我的做法是把所有规则集中到一张规则表里，每条规则有编号、有优先级、有冲突处理方式。

规则表单独放，能让业务方快速发现遗漏。有一次评审，业务方看到R04才想起来：“对，有些客户是续签合同的，旧合同和新合同重叠期我们都按新合同算，系统之前一直没处理。”这句话就是规则表的价值。没有规则表，这种问题可能会在上线之后被客户投诉才发现。

4. 从用例到验收：扩展特征怎么才算“定义完成”

定义扩展特征如果停留在“把用例写出来”，还差一步：写验收标准。对普通需求，验收标准可能列一两条就够了；对扩展特征，因为它是从主流程分支出来的、触发条件复杂，验收标准必须覆盖所有扩展流和冲突规则。

4.1 可测试的验收标准：每个扩展流都要有可观察结果

我给每个扩展特征用例写验收标准时，用的是Given-When-Then结构，并且要求每个扩展流至少对应一条验收标准：

• Given：给定某角色、某状态、某数据条件；
• When：当用户执行某动作或系统进入某状态；
• Then：系统产生哪个可观察结果。

以合同价为例：

• Given：企业客户“A公司”在价格系统中存在生效合同价，商品“X”的标准售价为100元，合同价为90元；
• When：销售提交包含商品X的订单；
• Then：系统按90元计算订单金额，订单明细中显示合同价来源标记，价格服务日志记录“合同价命中”。

这个标准能指导测试直接造数据、验结果。如果我只写“支持合同价”，开发说实现了，测试说没测过，上线后出了问题，责任根本扯不清。

我在实际操作中还会要求每条验收标准都写“通过/失败可观察结果”，比如“返回错误码 409，提示文案是……”而不是写“系统应该合理处理”。扩展特征之所以出问题，往往就出在“合理”两个字上，每个人对合理的定义都不同。

4.2 影响面分析：扩展特征的改动可能波及哪些主流程

扩展特征不是孤岛。它挂在主流程上，一旦激活，就可能改变主流程的状态、数据、权限和外部接口行为。用例定义阶段如果不做影响面分析，开发排期一定会爆，联调时才发现需要动别的模块。

我常用的影响面分析是从用例的参与者反推：用例里出现了哪些角色，就会影响哪些权限；出现了哪些数据实体，就会影响哪些表；出现了哪些外部系统，就会影响哪些接口调用。

还拿合同价举例，看起来它只在“订单金额计算”一步生效，但影响范围其实很大：

• 订单表：新增“合同价版本号”“合同编号”字段；
• 价格服务：新增合同价查询接口，增加缓存失效策略；
• 发票服务：开票金额可能和订单金额一致，但如果合同价包含免税条款，发票税率要变；
• 对账服务：财务对账需要合同价明细，不能只看优惠价；
• 报表中心：销售业绩报表按什么价格口径统计，需要业务确认。

这些影响如果不在用例的影响范围字段里写出来，开发和测试只会盯着价格计算本身，等到联调阶段，发票、对账、报表全跳出来，项目延期几乎是必然的。所以我的原则是：扩展特征的用例评审，必须带一个影响范围清单，逐个模块确认本轮改不改、怎么改。

4.3 优先级和版本规划：如何判断扩展特征现在做还是以后做

扩展特征的一大诱惑是“既然迟早要做，不如现在就做”，结果往往是主流程还没稳，扩展点先堆了一堆。我的判断标准很简单：优先做能直接提升核心业务目标转化率或规避重大风险的扩展特征，其余往后排。

具体打分维度我列过一张表：

这套维度放到一个具体的扩展特征上，结论常常一目了然。比如“企业客户合同价”触发频率高、不做会造成大量人工改价单、依赖的价格表早就存在，那就该排进近期版本；“预售订单尾款批量通知”半年才用一次，完全可以先不做系统自动化，用短信平台加名单导入临时撑着。

5. 实战中的坑：扩展特征用例常见的四个误用场景

模板和流程聊了不少，最后说几个我在真实项目里踩过、也看别人反复踩的坑。每一个都跟“扩展特征”和“用例”的定义方式有关。

5.1 把非功能需求当扩展特征

有同事拿了个需求来：“我们要给订单查询加一个扩展特征，要求查询并发量能支撑1000 QPS。”我说这不是扩展特征，这是性能需求。扩展特征改变的是用户可见的行为路径，性能需求是质量约束，它作用在包括主流程在内的一切流程上，不能作为一个有触发条件的可选能力去验收。

非功能需求如果被包装成扩展特征，通常的后果是：测试没有上下文，不知道拿什么数据、什么场景去验证1000 QPS，最后只能压一下接口看个大概；业务方也误以为性能是可选的，上线高峰期一慢就甩锅给“扩展特征没做优化”。

我的建议是，性能、安全、审计、可靠性这类横切关注点不要放进用例模板里，而是在用例的影响范围里标注相关质量要求，或单独拆成一条技术需求处理。

5.2 用“可能”两个字替代触发条件

“当用户可能需要审批时”这种话，在需求评审里出现频率高到惊人。但“可能”意味着无法测试。每当我看到这类描述，都会把它打回：谁是触发者？用户在哪个界面、哪一步操作会走到这个分支？审批开关是全局配置还是按部门配置？

我曾经跟进过一个合同审批扩展特征，需求文档写着“特殊合同需要审批”，结果上线前测试问：“特殊合同怎么定义？金额超过多少算特殊？还是合同类型是采购类就算？”产品经理和业务方来回扯了一周。如果在定义用例时把触发场景写成“合同金额大于等于20万元，或合同类型属于‘关联交易’时，提交合同后进入审批流程”，这个问题就不存在。所以我对团队的要求是：触发条件里不允许出现“可能”“大概”“某些情况”等不确定词。

5.3 把角色权限判断塞进基本流

扩展特征经常涉及高级角色，比如管理员、财务审核人。有些人写用例时习惯在基本流里写：“用户提交订单，如果是管理员，则显示审核按钮；否则不显示。”这其实意味着“审核”本身是一个独立的扩展特征，而不是主流程的一个if。

正确的做法是拆开：普通用户和运营管理员分别走不同的用例或不同的触发场景，“管理员审核订单”单独定义成一个扩展特征用例。这样角色权限的差异就不会污染主流程的基本流，开发和测试也能分别覆盖两类角色的路径。否则，基本流里挂满if，主流程的可读性会迅速崩塌，后续每个人加需求都在同一个用例上打补丁，最后那个用例变成没人敢动的屎山。

5.4 没人负责的待定规则

扩展特征用例写到一半，业务规则里出现“待财务确认”“优惠叠加规则后续补充”，这种情况我见得太多。扩展特征是边界能力，规则一旦模糊，做出来的行为一定和业务预期有偏差，而且因为它是扩展特征，主流程测试大概率覆盖不到，问题往往到灰度阶段才暴露。

我处理待定规则有两个办法。第一，设置默认规则并标注有效期：在规则表里写清楚“本次上线按方案A实现，方案B作为配置文件预留，业务方需在15天内确认”，逾期自动按方案A为准。第二，如果规则实在无法确定，建议这个扩展特征不要进入本版本，等规则确定后再定义用例。启动一个规则不明确的扩展特征，无异议是给项目埋雷。

另外说一个实践中容易忽略的点：扩展特征的用例尽量由需求方和研发一起在用例上签字确认，至少确认触发条件和业务规则两栏。很多团队评审理用例只过一遍，没人签字，后面需求变更了就互相推。扩展特征本来就游离在主流程之外，更需要白纸黑字兜住。

最后分享一个体会。我刚开始推“定义扩展特征【用例】”的时候，团队觉得这是在增加工作量，一个几行的需求非要写成一页用例，效率太低。但坚持了两个迭代之后，变化很明显：需求评审会上争论变少了，开发和测试不再频繁追问“这条件到底怎么触发”，上线之后扩展特征的返工率也降了不少。扩展特征这东西，最大的风险从来不是“做不出来”，而是“照着模糊的定义做出来后，发现全做偏了”。花一天把用例写清楚，省的往往是一周甚至一个月的无用功。