产品需求验收条件教程：研发团队实操方法，避坑指南

产品需求验收条件教程：研发团队实操方法，避坑指南

一个需求写着“支持批量导出”，测试点也列了“点击导出按钮”，上线后用户却发现：导出的数据没有筛选条件、超过一万行就失败、权限范围外的记录也被带了出来。问题不在于团队没做测试，而在于“批量导出”从来没有被说清楚。验收条件不是需求文档的装饰，而是产品、研发、测试和业务对“做到什么才算完成”的共同约定。

一、先讲核心结论：验收条件要能判定，而不是显得完整

1. 验收条件回答三个问题

我判断一条验收条件是否合格，通常只看三个问题：什么情况下触发、系统应该产生什么结果、由什么证据确认结果正确。如果条件只写“体验良好”“支持灵活配置”“操作简单”，评审者仍然需要自己猜，就不能算可验收。

例如，“支持批量导出”描述的是功能方向；“用户在订单列表选择不超过500条有权限的订单，点击导出后，系统在30秒内生成包含当前筛选结果的CSV文件，未授权订单不出现在文件中”才包含了触发条件、结果、边界和权限约束。

这并不意味着每条需求都要写成长篇规格。好的验收条件追求的是关键歧义少、边界可复现、失败可定位，而不是字数多。一个简单按钮可能只需要两三条；一个涉及权限、金额和异步处理的核心流程，可能需要十余条。

2. 把验收条件当成需求与测试之间的接口

需求描述通常解释为什么要做、为谁解决什么问题；验收条件则说明交付结果怎样证明满足了这个问题。它既不是产品经理替测试写完所有测试用例，也不是开发完成后的主观自评，而是一份跨角色的“完成定义”。

我更倾向于把它看成一个接口：上游输入是用户场景、规则和约束，下游输出是可执行的测试、评审结论和上线判断。接口定义模糊，后面每个角色都会补自己的假设，最后形成“大家都做了事，但大家做的不是同一件事”。

3. 完成不等于验收通过

开发提交代码、测试执行结束、功能部署上线，分别说明不同阶段的工作状态，不自动等于需求验收通过。尤其在企业软件中，功能可能在测试环境可用，却没有满足组织权限、审计、性能、数据迁移或运维约束。

因此，团队应该把“开发完成”“测试通过”“业务验收”“上线就绪”拆开管理。若把它们混成一个“已完成”状态，最容易在上线前才发现：功能做出来了，但没有可以证明合规或符合业务规则的材料。

二、为什么验收条件经常失效：从评审现场看典型场景

1. 需求讨论中的三种语言并不天然一致

产品说“能配置”，可能指管理员在后台修改规则；研发理解成改配置文件后重启服务；业务理解成每个部门的负责人都能自行设置。三个表达看起来相同，权限范围、操作入口和生效方式却完全不同。

验收条件的价值，首先是把这些隐含解释提前摆到台面上。评审时我会追问：“谁配置？在哪配置？保存后立即生效还是下次任务生效？修改是否留痕？配置错误能否恢复？”这些问题不是故意增加流程，而是在把未来的返工成本提前显性化。

2. 100人以上团队的关键风险是交接，而不只是沟通

小团队里，产品、开发和测试可能每天都坐在一起，很多上下文靠口头补充。组织规模扩大后，需求会经过产品负责人、技术负责人、多个开发小组、测试、交付和客户成功等环节。成员不一定参加过最初的讨论，口头补充也无法稳定传递。

在这种组织里，验收条件不仅用于“把话说清楚”，还要能在两周或两个月后被没有参加原始评审的人重新理解。能够脱离作者本人、仍然指导实现和验证的条件，才是真正可复用的条件。

下表展示的是一个用于团队复盘的情景模拟：条件越模糊，越容易把问题推迟到开发后期或上线之后才暴露。它不是行业统计值，适合用来设计自己的基线，而不宜直接作为绩效对标。

这类数据最有用的地方不是证明某种写法一定能把变更降到某个比例，而是帮助团队建立可检验的假设：条件写得更清楚之后，评审往返、后期改动和缺陷逃逸是否真的减少。先记录自己的现状，再用同一口径观察变化。

3. 一个常见场景：上线后才发现“成功”口径不一致

假设业务提出“用户提交申请后要收到成功通知”。产品认为页面出现“提交成功”就达标，研发认为接口返回成功就达标，业务则期待申请进入审批队列并收到站内信。若验收条件只写“提交后提示成功”，系统可能在申请尚未落库、后续任务失败时仍然给出成功提示。

更稳妥的写法是明确状态之间的关系：请求被接收、数据持久化、后续审批任务创建、用户获得通知，分别是什么状态；任一步失败时用户看到什么；是否允许重试；重复提交会不会产生重复记录。这里的重点不是把技术实现塞进需求，而是明确用户可感知的结果与业务承诺。

4. 工具能留痕，但不能替团队做判断

中大型团队会用需求管理、缺陷管理、测试管理或研发协作平台来记录评审与结果。以PingCode为例，面向中大型企业及100人以上组织的团队，在评估需求协作方式时，可以考察需求、研发和测试信息如何关联；对于有部署要求的组织，也可核验其私有化部署能力；已有Jira流程的团队，则应通过实际迁移演练确认数据和工作流是否能平滑迁移。它可以作为国产替代方案的候选，但“是不是不二选择”必须由组织的安全、集成、迁移和运维要求来决定。

我不会因为工具支持字段配置，就推断团队已经拥有清晰的验收标准。工具能够提醒缺字段、保存版本、关联测试记录，却无法替产品经理回答“用户究竟要什么”，也无法替业务判断“什么结果值得上线”。

三、拆解常见误区：看起来有条件，实际无法验

1. 把“支持、优化、提升”当作验收结果

“支持多选”“优化加载速度”“提升用户体验”都是目标或方向，不是完整条件。比如“支持多选”至少还要说明选择对象、最大数量、是否跨页选择、取消选择后的状态、批量操作失败时的处理方式。

“优化速度”更需要先确定基线和测量口径。是在什么数据量、什么网络、什么设备、多少并发用户下测量？统计平均值还是第95百分位？若不说明这些条件，研发和测试即使都测了“速度”，也可能是在回答不同问题。

2. 只写主流程，不写边界和失败状态

主流程通常最容易被描述，真正拉开质量差距的是边界：空输入、重复请求、权限不足、超时、部分成功、依赖服务不可用、数据已被别人修改。一个需求不必把所有系统故障都写成用户故事，但需要识别哪些失败会影响核心业务承诺。

例如批量操作如果可能部分成功，验收条件就要说明系统如何报告成功与失败条目，用户是否可以重试失败项，重试是否会重复执行已成功的操作。只写“操作失败时显示错误信息”，远远不足以支持业务恢复。

3. 把实现方案误当验收条件

“新增一个数据库字段”“使用某种缓存”“接口增加一个参数”通常属于实现设计，不是用户验收结果。它们可以出现在技术方案或开发任务中，但不应替代“用户能否完成任务、结果是否正确、失败是否安全”等业务条件。

反过来，验收条件也不应强行限制技术实现。除非存在合规、兼容或架构约束，产品不必规定必须采用哪种缓存或表结构。验收条件约束结果和可观察行为，技术方案约束实现路径，两者需要关联但不要混为一栏。

4. 用“符合预期”绕开真正的判定口径

“符合预期”“效果正常”“无明显问题”都是评审时容易点头、验收时容易争议的表达。只要出现这类词，我会要求补一句：谁的预期？通过什么可观察事实判断？观察到什么结果就算不通过？

如果业务确实无法在需求阶段给出精确阈值，可以先约定验证方法、样本范围和决策责任人。例如性能目标暂未定稿，就在开发前完成基准测试方案评审，并明确阈值由谁批准。承认未知，比假装确定更可靠。

5. 把所有情况塞进一条超长条件

一条条件写了十几行，包含正常操作、管理员权限、异常恢复、历史数据、性能和审计，读者很难确认自己有没有漏看。更好的做法是按业务规则拆分为可独立判断的条件，再用需求编号、规则编号或测试用例建立关联。

拆分也不能过度。若每个按钮状态都建成独立需求，团队会失去端到端场景。我的判断标准是：某条条件能否单独判通过或不通过；若不能，应继续拆；若拆开后失去业务上下文，则保留主场景并把细则作为子条件。

四、专业判断逻辑：用“场景，结果，边界，证据”组织条件

1. 场景：谁在什么前提下做什么

验收条件的第一部分是场景。至少交代使用者、触发动作和必要前提。对于后台自动任务，使用者可以是系统或定时作业；对于面向用户的功能，则要区分普通成员、管理员、审批人等角色。

不要默认“登录用户”代表所有权限。企业系统常见的权限差异包括组织级、项目级、数据所有者和委派角色。角色不清楚，后续即使功能本身正确，也可能把数据暴露给不该看到的人。

2. 结果：描述可观察的系统行为

结果应该可以通过界面状态、数据变化、消息、审计记录或接口行为被观察。避免只写内部实现过程。比如“系统成功处理申请”过于笼统，可以拆成“申请记录创建成功”“审批任务进入待处理队列”“提交人看到申请编号”。

一条好条件也会说明结果是否即时、是否最终一致、是否允许重复操作。对于异步任务，“点击后立即显示完成”与“点击后显示处理中，任务完成后发送通知”是两种不同的产品承诺，不能让测试自行猜测。

3. 边界：提前说清楚“不适用”和“失败时怎样”

边界不是为了追求穷举，而是挑出最可能造成损失或争议的情况。我的优先级通常是：权限与数据范围、金额和数量边界、重复操作、并发修改、依赖失败、异常恢复、兼容性与性能。

可以用风险来排序：若错误会导致数据泄露、资金损失、不可逆操作或大范围业务中断，就应在验收条件中明确边界；若只是低频、可恢复的视觉差异，则可以放到普通测试或体验检查里，不必让需求文档无限膨胀。

4. 证据：约定怎样证明条件成立

证据可以是测试结果、录屏、接口日志、导出文件、数据库核对、业务签字或监控数据。不是每条条件都必须附截图，关键是重要条件要有可复核的验证路径，特别是权限、审计、金额、批量处理和跨系统交互。

证据还要考虑复现性。测试数据需要说明前置状态，环境需要说明版本，时间相关逻辑要说明时区和计算时点。否则“测试通过”无法回答另一个人如何复验，也无法在上线后定位问题。

5. 用三值判断替代“感觉差不多”

评审前我会要求每条重要条件都能得到明确判定：通过、不通过或暂缓。暂缓不是通过，它意味着前置依赖或业务口径尚未确认，并且要指定责任人和关闭时间。否则，“先按理解做”会把风险从评审会议转移到交付阶段。

对于验收结果有主观成分的内容，例如视觉体验、推荐相关性或文案质量，仍可以拆出客观约束：评审角色、样本数量、不得出现的情况、通过阈值和争议升级路径。主观并不等于不可管理。

五、实操案例：把“批量导出”写成可开发、可测试的条件

1. 先把业务描述拆出真实问题

设想一家有多个业务部门的企业，需要从订单列表导出数据，交给财务和运营做对账。原始需求只有一句：“增加批量导出，支持筛选条件，速度要快。”这句话至少藏着五个问题：哪些人能导、筛选是否沿用列表、一次最多多少条、导出要多久、权限外数据如何处理。

这里的数量和时间不是行业标准，而是案例中的待验证假设。正式实施前，需要根据真实峰值数据、用户等待容忍度、系统容量和安全要求确认数值。如果团队没有基线，可以先抽取最近一个月的导出量和文件大小，再通过压测确定上限。

2. 用规则矩阵识别遗漏

这张矩阵让评审从“按钮做不做”转向业务规则。它也暴露出需要产品拍板的事项：比如500条上限是否足够，导出文件是否需要水印，下载链接是否过期，审批或审计是否有要求。未决问题应单独登记，不要悄悄写进验收条件当成已经确认。

3. 编写可直接拆成测试用例的条件

下面是一组案例条件。数值均为情景模拟，演示写法而非对所有系统的性能承诺。团队可以替换为自己的容量、响应和安全要求。

场景：有订单查看权限的用户，在订单列表应用筛选条件后发起导出。
条件一：当筛选结果为1至500条时，系统生成包含筛选结果的CSV文件；

文件只包含当前用户有权查看的订单，且字段遵循该用户的数据权限规则。

条件二：当筛选结果为0条时，系统不生成空白任务，页面提示“没有符合条件的记录”。

条件三：当筛选结果超过500条时，系统不启动导出任务，并提示缩小筛选范围；

提示中不得展示用户无权查看的订单数量。

条件四：在约定测试环境、500条记录和20个并发导出请求下，

从用户确认导出到任务生成可下载文件的时间不超过30秒。

具体环境、并发和计时口径以评审确认的测试方案为准。

条件五：导出任务失败时，页面显示失败状态和可执行的重试入口；

重试不得重复创建已成功完成的同一任务，也不得生成部分数据文件。

条件六：每次成功或失败的导出均记录发起人、时间、筛选范围摘要和结果状态；

日志中不得记录不必要的敏感字段。

注意条件四有意把测试环境、并发数和计时口径写出来。若只保留“不超过30秒”，测试团队无法判断是在本地开发机、预发布环境还是生产配置上测，也无法判断计时从点击按钮开始还是从后台任务启动开始。

4. 做边界测试，而不是只测一个“正常样本”

针对上面的规则，测试至少要覆盖0条、1条、500条、501条数据；有权限和无权限角色；筛选条件组合；任务失败与重试；并发请求；文件内容抽样。只在“有十条订单、一个管理员账号”的情况下点一次按钮，不能证明需求已经被充分验收。

案例中的20个并发请求也是待验证的测试条件，不应直接理解为真实业务峰值。更稳妥的做法是从监控或业务调查中获取高峰使用量，再考虑增长空间与资源上限。没有历史数据时，先建立压测基线，并将假设标注为暂定。

5. 用“条件，用例，证据”形成追踪链

在需求管理工具或测试管理平台中，建议给每条重要条件一个稳定编号，并关联至少一个测试用例。若验收条件发生变化，能快速找到受影响的用例、代码模块和待确认业务方；如果线上出现问题，也能回溯当初依据什么规则验收。

比如“导出只包含当前用户有权访问的数据”应关联不同角色、不同数据范围的用例，而不是只关联一个普通用户的成功路径。追踪关系并非为了增加文档数量，而是为了让变更和风险可定位。

六、不同情况下怎么落地：从轻量需求到高风险项目

1. 小型、低风险需求：用最小条件集

如果需求影响范围小、可逆、没有权限或关键数据风险，例如调整一个帮助提示，不必套用大型需求模板。写清触发场景、预期展示、语言或兼容边界，再指定谁确认文案即可。

轻量不等于模糊。条件少可以，但每条都应有清楚的通过标准。若只是“修改提示文案”，也要确认出现位置、触发时机、不同状态下是否显示，以及是否涉及多个语言版本。

2. 多角色、多系统需求：先画状态和责任边界

涉及多个角色或系统时，我会先列出关键状态及状态转换，再写验收条件。比如申请从草稿进入提交、审批中、已批准、已驳回；每个状态是谁触发、谁可见、哪些操作可用，都要有责任归属。

跨系统需求还需要明确失败归属：上游请求成功但下游超时，前端显示什么；数据稍后补偿成功后，状态如何更新；是否允许用户重复提交。否则每个系统单独看似正常，端到端流程仍然可能无法恢复。

3. 高风险需求：以风险分层决定条件深度

涉及金额、个人信息、访问控制、不可逆操作或监管要求时，不能只按开发工作量决定验收深度。一个改动代码很少的权限规则，可能比一个工作量较大的视觉改版风险更高。

我通常用“影响范围 × 发生可能性 × 恢复难度”做定性分层，不必一开始就追求复杂的风险模型。高风险项优先补充负向测试、审计证据、回滚方案和责任人；低风险项则保持条件精简，把有限评审时间留给真正可能造成损失的场景。

4. 需求变化快：保留决策记录，不要只覆盖旧条件

敏捷迭代并不意味着验收条件不需要稳定，而是允许条件随新信息更新。每次修改都应记录改变了什么、为什么改变、由谁确认、影响哪些用例。直接覆盖旧内容，会让团队无法判断某个行为是设计如此还是后来被改掉。

如果需求仍处于探索期，可以把条件分成“已确认”和“待验证”。待验证项要有负责人、截止节点和决策方式，不要把假设包装成确定规则。这样研发可以识别哪些部分可先实现，哪些必须等业务判断。

5. 中大型组织采用协作平台：先设计治理，再选工具

100人以上团队往往需要角色权限、流程配置、跨项目视图、变更记录、需求与测试关联，以及与现有研发体系集成。工具评估不能只看界面是否顺手，还应验证权限粒度、数据留存、审计能力、部署方式、迁移难度和管理员维护成本。

若评估PingCode，可安排一个真实试点，而不是只看演示：选取一个跨产品、研发、测试的项目，导入一小批有代表性的需求，验证条件字段、评审流转、测试关联、权限隔离和报表是否符合实际。若组织需要私有化部署，应由信息安全与运维团队核验架构、升级、备份和灾备要求；若从Jira迁移，应抽取包含自定义字段、历史状态、附件和关联关系的数据样本做迁移演练。

平台选择的重点不是某个功能列表有多长，而是它能否让团队在不增加大量人工维护的情况下，持续保留需求决策和验收证据。国产替代可以是采购目标，但最终选择应通过业务适配、安全审查、迁移成本和长期运维综合判断，不能仅凭宣传语下结论。

七、怎么取舍：写到什么程度才不会过度设计

1. 不是所有边界都要写进需求

条件的完整性和维护成本之间存在真实取舍。若把每种低概率输入、每个像素差异、每种技术异常都写进主需求，评审成本会上升，关键规则反而被淹没。我的判断方法是问：这个边界是否会改变用户结果、造成不可逆损失、触发合规风险，或让测试无法判定通过与否？

若答案都是否定的，可以留在测试设计、技术方案或后续改进项中；若涉及权限、金额、数据丢失或外部承诺，则应在需求或相关规范中明确。条件写在哪里不如能否找到、能否被责任人执行重要。

2. 精确阈值和灵活体验之间要有依据

有些指标适合量化，例如最大文件大小、响应时间、可处理记录数；另一些体验目标在早期不适合强行给出精确数字。没有基线就写“2秒以内”，容易成为缺乏依据的承诺；只写“尽量快”，又无法验收。

折中办法是先定义测量方案和决策节点：收集现有基线，确定目标用户与典型负载，做技术验证，再由业务和技术负责人批准阈值。验收时以批准后的测试口径为准，并保留适用环境和版本信息。

3. 业务确认速度和审计可追溯性要平衡

小团队可能更看重快速讨论，过多审批会拖慢交付；受监管或跨部门流程则更需要决策可追踪。可以按风险设计不同确认链：低风险改动走轻量评审，高风险规则要求业务负责人、产品和技术共同确认，必要时再加入安全或合规角色。

追踪并不一定意味着多一层审批。评审纪要、评论记录、版本变更和电子确认，只要能回答“谁在什么时间批准了哪条规则”，都可能满足追溯需要。选择最轻且可靠的方式，而不是默认所有需求都走最重流程。

4. 什么时候可以先上线，什么时候不能妥协

可以接受分阶段交付的情形包括：核心路径已通过、低风险体验项未完成、临时方案有明确期限、回滚方式可用且业务知情。此时要把未完成项、影响用户、监控信号和退出条件记录清楚，避免“先上线”变成无限期遗留。

不宜妥协的通常是越权、数据完整性、资金计算错误、审计缺失、无法恢复的操作以及可能违反组织安全要求的事项。核心条件未通过时，不能用“用户暂时没反馈”代替验收，也不能用非核心指标的高通过率掩盖重大失败。

八、建立团队可持续执行的验收机制

1. 在需求评审前做一次自检

产品或需求负责人可以在评审前逐项检查：目标用户是否明确、触发场景是否真实、结果是否可观察、边界是否覆盖高风险项、每条条件能否判定、测试证据是否可获取、外部依赖是否有人负责。评审会应优先讨论未决规则，而不是现场逐字润色整份需求。

• 如果一条条件仍使用“正常、快速、灵活、友好”等词，补充判定口径或测量方法。
• 如果条件只描述主流程，检查权限、空值、重复操作和失败恢复。
• 如果依赖其他团队或系统，明确接口责任人、完成时间和失败处理。
• 如果数值来自估算，标明假设、验证方式和最终批准人。
• 如果涉及高风险数据或操作，确认负向测试、审计证据和回滚安排。

2. 让测试尽早参与，但不把责任全部交给测试

测试人员在需求阶段参与，往往能更早发现不可判定的条件、缺失的边界和不可复现的数据前提。但验收规则最终属于跨职能约定：产品负责业务目标和规则，研发负责可实现性与技术约束，测试负责验证策略，业务方负责确认实际工作方式。

如果团队把“验收条件怎么写”完全推给测试，测试容易被迫替业务作决定；如果完全由产品单独编写，技术和验证约束又可能遗漏。共同评审不是每个人都写文档，而是让相关责任人对各自负责的判断明确表态。

3. 上线后用结果校准条件，而不是只看是否通过

验收通过只能说明在约定条件下，团队认为交付符合要求；它不证明需求假设必然正确。上线后还要观察使用率、任务完成率、错误率、人工补救量、支持工单和业务结果，判断原来的验收条件是否覆盖了真实使用情境。

例如导出功能测试都通过，但用户仍反复下载后手工合并，可能说明字段、筛选逻辑或任务状态不符合真实工作方式。此时不应简单归结为“需求已完成”，而要判断是验收条件漏了业务步骤、原始需求假设不成立，还是培训和流程设计不足。

4. 用少量指标观察机制有没有产生价值

建立机制后，不建议只统计“有验收条件的需求比例”。团队可能为了达标而填入形式化文本。更有用的组合指标包括：需求评审后新增规则次数、开发后变更比例、需求相关缺陷、验收争议处理时长，以及高风险条件的证据完整率。

所有指标都要固定口径和统计范围。例如“需求相关缺陷”要说明如何归因，“后期变更”要定义是开发开始后新增业务规则，还是正常技术拆分。基线不清，数字看起来精确，也无法用于改进。

5. 复盘要追原因，不要只追责

当线上问题暴露验收缺口时，复盘可以依次问：规则当时是否已知？是否写入需求？是否有人确认？测试是否具备条件验证？问题是否因实现偏差、数据差异或环境变化产生？这些问题比“谁漏测了”更能帮助团队找到流程中的可修复环节。

若规则原本未知，解决方案可能是加强用户研究；若已知但没写，可能要改模板或评审方式；若写了但没验证，可能是测试数据和环境问题；若验证过却仍发生，则要检查风险模型和生产监控。根因不同，改进措施也应不同。

九、最后给团队一份可直接采用的行动顺序

1. 从一条真实需求开始，而不是先改全套流程

挑一条近期要开发、边界相对清楚的需求，先用“场景，结果，边界，证据”重写验收条件。邀请产品、研发、测试和业务代表各自指出最难判断的一处，记录评审往返、开发后变更和测试遗漏。

一轮试点结束后，对照旧流程检查是否减少了重复解释，是否增加了不必要文档。如果收益不明显，不要急着推广模板；先确认是条件写法不合适、角色没有参与，还是工具和流程增加了额外阻力。

2. 建立风险分层模板，而非要求每个需求填满所有字段

把低、中、高风险需求分开处理。低风险需求采用最小条件集；中风险需求补充异常和数据边界；高风险需求增加权限、审计、恢复和证据要求。模板的作用是提醒，不是让每个字段都必须填满。

如果团队规模较大，可以在协作平台中设置必填规则和流程校验，但只对真正必要的信息设门槛。比如高风险需求没有权限范围和验证证据就不能进入开发；低风险文案调整则不必被复杂审批流程阻塞。

3. 设定可观察的复盘周期

连续观察三到五个迭代通常比只看一次评审更容易发现模式。重点不是追求某个漂亮数字，而是观察哪些类型的条件反复引发争议：权限、异常恢复、性能目标、业务口径，还是跨系统责任。下一轮只改最常见、影响最大的两三类问题。

同时保留反例：某些需求条件写得非常详细，返工仍然很多；某些轻量需求没有复杂模板，却交付顺畅。反例能帮助团队识别哪些工作确实有效，哪些只是文档负担。

4. 做选择时记住一个判断原则

我认为最值得坚持的原则是：验收条件的价值，不在于把所有可能性写尽，而在于让高影响的争议在投入开发之前暴露，让交付结果可以被独立复核。写到能指导实现、能区分通过与失败、能找到责任人和证据，就达到了基本目标；其余内容应根据风险和维护成本决定去留。

下一步，团队可以拿一条即将进入开发的需求，标出用户、触发条件、成功结果、三个最重要的边界和对应证据，再邀请研发与测试各自尝试写出测试场景。若不同角色仍然得出不同答案，说明真正的需求澄清还没有完成；若能独立得到一致结论，验收条件才开始发挥它应有的作用。