Bug / 缺陷复现步骤教程：项目经理数据分析，避坑指南

缺陷单里写着“登录失败，麻烦修复”，开发人员却在自己的环境里连续试了十几次都无法重现；项目经理看板上的缺陷数量还在上升，却说不清哪些问题正在拖慢发布。Bug复现步骤看起来是测试人员填写的一段说明，实际上是把用户现场转化为可验证证据的过程。复现步骤越含糊，团队越容易把时间花在猜测、追问和重复验证上；对项目经理来说，真正值得分析的不是“报了多少 Bug”，而是“多少问题能一次复现、卡在哪个环节、修复后是否可靠”。

一、先讲核心结论：复现步骤是数据入口，不是文字附件

1. 一份有效缺陷单，至少要让别人独立完成复现

我判断一份复现说明是否合格，通常不先看字数，而是看一个结果：没有参与原测试的人，能否仅凭缺陷单，在相同条件下稳定看到同一个现象。如果必须通过聊天追问“你是哪个账号”“这个按钮在哪”“当时选了什么筛选条件”，说明关键上下文还留在报告人脑中。

因此，复现步骤的最低目标不是“描述我做过什么”，而是让另一位成员能重复输入条件、执行操作、观察结果。它需要把环境、初始状态、操作顺序、实际结果和预期结果连成一条可检验的链路。缺少其中任意一环，都可能让后续分析变成猜测。

2. 项目经理应关注复现质量背后的流转损耗

缺陷分析中，我会把复现质量看成一个流程变量，而不是测试人员的写作评分。步骤不完整可能造成补充沟通、重复部署、错误归因和二次回归；这些成本会分散在不同角色的时间里，往往不会出现在“缺陷总数”这一个数字中。

项目经理最需要回答的四个问题是：缺陷能否复现、从提交到确认花了多久、哪些缺失信息最常导致退回、修复后回归是否通过。这四个问题比单看关闭数量更接近交付风险，也能帮助团队判断究竟应该改模板、补环境能力，还是调整质量门禁。

3. 先分清内容完整、现象稳定和业务影响

复现步骤写得完整，不代表问题一定严重；问题影响重大，也不代表报告人一定能立即给出根因。项目经理应把三个维度分开：内容完整度回答“证据够不够”，复现稳定度回答“现象能否重现”，业务影响回答“修复优先级有多高”。

我不建议用一个“缺陷质量分”覆盖所有判断。一个内容完整但只偶发一次的问题，需要进一步采集日志和频率；一个描述简短但阻断核心支付流程的问题，则应先恢复业务，再补齐根因资料。把三者混成一个分数，容易造成形式合规却风险失控。

二、背景和真实场景：缺陷单为什么会成为项目瓶颈

1. 从“现象”到“可执行条件”中间隔着上下文

“保存失败”只是现象标签，不是复现步骤。它没有说明在哪个页面、保存什么对象、字段是否为空、用户具有什么权限、请求是否成功发出，以及失败发生在点击后还是刷新后。开发人员收到这样的描述，往往只能先猜路径，再向报告人确认。

在多人协作、多个环境并行的项目中，上下文更容易丢失。同一功能可能存在测试环境和预发布环境，同一个用户可能被赋予不同角色；页面数据还可能由缓存、初始化脚本或上一次操作残留。复现说明若不记录这些条件，团队看似在讨论同一个 Bug，实际可能在验证不同状态。

2. 典型现场：缺陷数量稳定，待澄清工作却持续增加

设想一个有测试、开发、产品和项目管理角色的版本迭代。测试人员连续提交缺陷，开发人员每天接单，但部分工单被退回补信息。看板显示关闭数逐渐上升，项目群里却不断出现“我这里正常”“请给个账号”“数据是不是刚导入的”等对话。

这时不能直接得出“测试报告能力不够”的结论。实际问题可能是测试环境经常重置、账号权限没有统一记录、工单模板没有必填上下文，或开发人员没有权限查看日志。项目经理要把问题沿流程拆开，判断信息缺口出现在哪个节点，而不是用一句“提高缺陷单质量”结束复盘。

3. 组织规模越大，标准化越重要，但表单不能越做越重

当团队跨多个产品线、地区或交付小组时，不同成员对“复现步骤”的理解容易分化。中大型组织尤其需要稳定的字段定义、状态口径和升级规则。以 PingCode 这类面向中大型企业及百人以上组织的项目管理平台为例，项目经理可以把缺陷流转与迭代、负责人、优先级和验证结果放在同一管理语境下讨论；但工具本身不能替团队决定哪些字段是必要证据。

如果字段太少，信息会散在评论和即时消息里；如果字段太多，报告人会复制粘贴无关内容，填写时间增加，真正重要的信息反而被淹没。我的取舍原则是：把影响复现和决策的内容设为结构化字段，其余证据按风险和场景选填。

下面的数据是用于展示分析方法的情景模拟，不代表行业基准或任何平台的实际统计。项目经理可以把同样的指标换成自己团队连续数周的工单记录。

三、常见误区：看似认真记录，实际仍无法复现

1. 把“操作动作”误当成“完整步骤”

“打开系统，点击提交，出现错误”记录了动作，但没有说明对象、输入和状态。操作步骤需要能被执行，通常应包含入口、对象、关键输入、权限条件、动作顺序和观察点。若操作依赖一条特定数据，也要标明如何找到它，或提供脱敏后的稳定标识。

好的描述不一定很长。比如“以具备编辑权限的账号进入订单详情，打开状态为待审核且含两条明细的订单，将第二条明细数量改为 0，点击保存；页面提示成功，但刷新后数量恢复为原值”比“编辑订单保存异常”多提供了关键条件，也让实际结果可以被验证。

2. 把“预期结果”写成愿望，而不是产品规则

“应该正常”“不应报错”无法用于判断实现是否符合需求。预期结果应来自需求、验收标准、已确认的业务规则或既有行为。如果规则尚未明确，缺陷单应标注“预期规则待产品确认”，不要让开发人员根据个人理解猜测。

否则，团队可能把需求歧义误判为程序缺陷，或者在不同角色之间争论“正常到底是什么”。项目经理可以追问：哪个用户场景、哪条规则、哪项验收标准支持这个预期？回答不出来时，先把问题分类为待澄清，而不是强行给出缺陷严重级别。

3. 截图很多，关键证据却缺席

截图能证明某一瞬间的界面状态，却通常不能单独说明操作顺序、权限上下文、接口响应或数据是否持久化。录屏也有边界：视频里能看到点击和提示，不一定能看到浏览器版本、请求参数或服务端错误。

我会把证据按“能回答什么问题”来组合：截图用于呈现视觉异常，录屏用于还原时序，日志用于定位请求和服务响应，数据标识用于复查记录。敏感信息要先脱敏，账号密码、个人信息和生产数据不能因为排查方便而直接附在工单里。

4. 把偶发问题写成必现，或把“没复现”当成不存在

“稳定复现”不是修辞。报告人应记录尝试次数、成功次数、时间区间以及是否依赖特定网络、设备或数据状态。若执行十次只出现一次，准确描述应是“10 次操作中出现 1 次”，而不是“必现”。

开发人员一次没看到现象，也不能立即关闭缺陷。两方的环境、时间窗口、缓存、权限和数据可能不同。正确动作是对齐条件后再复测；若暂时无法复现，应保留“待补证”或“未复现”状态，并说明已经尝试的路径及尚缺证据。

5. 用严重级别代替复现证据

把优先级标成最高，不会自动补全步骤，也不能替代影响分析。严重程度描述后果，优先级还要考虑用户范围、发生概率、业务窗口、绕行方案和修复成本。两个同级问题可能因为上线时间不同而采取不同处理顺序。

先保证证据足以确认问题，再讨论优先级；先保护关键业务，再补足低风险细节。这不是要求所有工单都填写同样多的内容，而是要求记录精度与决策风险相匹配。

四、专业判断逻辑：把缺陷复现拆成可检查的六个部分

1. 环境：说明“在哪种条件下发生”

环境字段应让另一个人判断是否处于等价条件。常见内容包括版本号、部署环境、浏览器或客户端版本、操作系统、设备类型、网络条件和时间范围。并非每种缺陷都需要填满所有字段，页面样式问题通常需要设备和浏览器，数据一致性问题则更需要版本、请求时间和数据源。

如果团队有多个测试环境，名称本身不够。最好再记录构建号、发布时间或可追溯的版本标识。环境频繁更新时，项目经理应把“缺陷出现在哪个版本、何时发生、何时验证”纳入复盘，否则环境变化可能掩盖真正原因。

2. 初始状态：说明“操作开始前系统是什么样”

复现前的状态经常决定问题是否会出现，例如用户角色、对象状态、记录数量、开关配置、购物车内容或审批节点。描述初始状态时，不必抄录整套业务数据，而要指出影响结果的关键条件，并提供安全可用的定位方式。

若需要账号，优先使用专门的测试账号并说明权限；若需要数据，给出可重置的测试数据标识或准备步骤。不要在缺陷单中长期保存密码或不必要的个人信息。涉及真实业务数据时，应遵循组织的数据保护要求并使用脱敏材料。

3. 操作步骤：每一步只做一个可观察动作

步骤最好按时间顺序编号，一步只表达一个关键动作。避免把“登录、搜索、修改、保存并刷新”全塞进同一条，因为复现失败时无法判断究竟在哪一步偏离。对依赖前一步结果的操作，应描述成功条件，例如“进入详情页后，确认状态显示为待审核，再点击编辑”。

1. 明确入口：从哪个菜单、页面或链接进入。
2. 明确对象：选择哪类记录，如何识别目标数据。
3. 明确条件：账号角色、筛选条件、字段值或开关状态。
4. 逐步执行：按照时间顺序描述点击、输入、提交或等待动作。
5. 明确观察点：记录提示、页面变化、数据变化或请求结果。
6. 描述复现频率：注明尝试次数和出现现象的次数。

4. 实际结果与预期结果：让差异可以被判定

实际结果要写观察到的事实，例如“提示保存成功，刷新后金额恢复为 100”，而不是“功能坏了”。预期结果应写可验证的业务规则，例如“保存成功后，该订单金额应保留为 80，刷新后仍显示 80”。两者之间的差异，就是团队判断问题是否成立的基础。

如果预期依据暂不清楚，应保留待确认标记，并明确负责人和确认期限。项目经理要避免让报告人或开发人员擅自创造规则；对需求解释存在分歧时，拉产品负责人确认，并将确认后的规则补回验收条件或测试用例。

5. 证据附件：用最小充分证据减少往返

附件不求数量多，而求能支撑判断。对于界面问题，可以附截图或短录屏；对于接口问题，可以提供脱敏后的请求标识、状态码和相关时间；对于偶发问题，可增加操作次数、网络变化和客户端日志。附上材料时，最好写一句“该附件证明什么”，避免接收方逐个猜测。

日志应尽量包含关联标识、时间戳和环境版本，不应只截取一段没有上下文的报错文本。需要扩大日志范围时，先确认访问权限、保留期限和敏感信息处理方式。复现越依赖真实用户数据，越需要把安全控制纳入取证流程。

6. 一次检查是否足够：用“复现矩阵”而不是印象判断

同一个问题可能只在特定角色、状态、版本或设备上出现。项目经理可以帮助团队建立小型复现矩阵：把已知关键条件逐项列出，只选择与风险相关的组合，不必机械穷举所有变量。出现不一致时，矩阵能提示下一步是检查权限、数据还是环境。

五、案例与数据观察：项目经理怎样从复现数据找到真正瓶颈

1. 先设定可复算的模拟项目

以下用一个四周迭代的情景模拟说明分析方法：团队共收到 160 条缺陷，经过初步受理后，112 条一次进入验证，32 条需要补充信息，16 条暂时无法稳定复现。数字仅用于演示，不是外部行业统计，也不应作为团队考核的固定目标。

分析时我会保留每条工单的提交时间、首次响应时间、补充次数、首次复现结果、修复版本、回归结论和影响等级。只统计总量，无法区分“缺陷真的变多”与“缺陷信息变差”；只有保留流转过程，才能找到导致延迟的环节。

2. 补充次数比“报告写得好不好”更容易指导行动

如果一条工单平均需要补充 1.8 次，不要马上要求所有人把步骤写得更长。先把补充问题分类：环境信息缺失、数据无法定位、预期不明确、附件不可访问、权限不匹配。每一类对应不同措施，补模板只对其中部分原因有效。

例如，环境信息缺失比例高，可能需要自动带出版本和构建号；数据无法定位，可能需要测试数据准备规范；预期不明确，往往要修复需求验收标准。把根因对应到机制，才能避免将产品、平台和测试流程的问题全部压到报告人身上。

3. 用中位数和分位数看等待，不要只看平均值

从提交到首次确认的平均时间可能被少数长时间挂起的工单拉高，也可能掩盖大多数工单其实很快处理的情况。项目经理可以同时观察中位数、较高分位数和超时比例，判断问题是普遍慢，还是少数严重积压。

还要拆分“等待报告人补充”与“等待开发确认”。如果总周期长，但开发处理时间并不长，真正的瓶颈可能在信息补充或排队；如果首次确认很快、修复周期很长，则应分析技术复杂度、依赖团队或版本窗口。阶段耗时比一个总平均更适合做行动决策。

4. 分层观察比一个总体通过率更接近真实风险

总体首次复现率即使达到较高水平，也可能掩盖高风险类型。例如，界面缺陷很容易重现，权限问题却经常缺少角色信息；如果二者混在一起，团队会误以为流程已经稳定。项目经理应按产品模块、缺陷类别、提交来源、严重程度和环境分层查看，但每次只选择与当前决策相关的维度。

样本量也要一起报告。某模块只有 3 条缺陷，其中 2 条未复现，比例看起来很高，却不足以与 100 条缺陷的模块直接比较。小样本结论适合触发检查，不适合直接用来给团队排名或判断个人表现。

5. 质量改善应同时检查副作用

团队把必填字段从 4 项增加到 10 项后，信息完整率可能上升，但报告耗时、空字段比例和延迟提交也可能增加。因此，改模板不能只看完整率，还要观察首轮可复现比例、平均填写时间、空值率、补充次数和严重问题的响应时间。

如果数据采集功能能自动附带版本、浏览器和时间信息，新增字段的成本会很低；若要求报告人手工填写大量无关环境细节，流程很可能变慢。项目经理应该优先自动化可机器获取的数据，把人的注意力留给业务条件、预期规则和异常解释。

六、从提交到闭环：可直接采用的缺陷复现模板与操作流程

1. 推荐的基础模板

模板应服务于复现和决策，而不是让每个字段都成为报告人的负担。下面的结构可以作为起点，再根据产品类型删减或增加字段。项目经理应让开发、测试、产品和支持角色共同确认字段含义，避免同一字段在不同团队有不同解释。

• 标题：对象或功能 + 关键现象，例如“订单详情保存后金额恢复为旧值”。
• 环境：环境名称、版本或构建号、客户端或浏览器版本，以及必要的设备和网络条件。
• 前置条件：账号角色、数据状态、开关配置及进入操作前必须成立的条件。
• 复现步骤：按顺序编号，每一步只写一个关键动作，并明确目标对象。
• 实际结果：准确记录页面提示、数据变化、错误码或失败发生的时间点。
• 预期结果：引用需求、验收标准或已确认规则；规则不明时标记待确认。
• 复现频率：填写尝试次数和出现次数，偶发问题注明时间或触发条件。
• 附件与证据：添加脱敏截图、录屏、日志或可追溯的数据标识，并说明各附件用途。
• 影响范围：受影响用户、业务流程、是否有绕行方案及上线风险。
• 回归要求：记录修复版本、原路径验证结果、相邻边界和回归证据。

2. 可复制使用的文字示例

以下示例刻意把结果和预期分开，并交代前置状态。团队可以依据实际系统调整字段，不要为了套模板保留与当前产品无关的内容。

标题：订单详情保存后，第二条明细数量恢复为旧值
环境：预发布环境；构建版本 2025.04.12；桌面浏览器当前稳定版

前置条件：使用具备订单编辑权限的测试账号；目标订单状态为“待审核”；订单包含两条明细

复现步骤：

从订单列表打开目标订单详情
点击“编辑”
将第二条明细数量从 3 改为 0
点击“保存”，等待成功提示
刷新详情页，检查第二条明细数量
实际结果：页面提示保存成功；刷新后数量显示为 3。5 次尝试中出现 5 次

预期结果：数量允许为 0 时，保存后刷新仍应显示为 0；规则依据为已确认的字段验收标准

证据：附脱敏录屏、测试数据标识和发生时间；不包含账号密码

影响范围：当前测试订单可通过重新编辑暂时绕行；尚未确认其他订单是否受影响

3. 首轮受理：先确认能否复现，再决定下一步

受理人不需要立刻找到根因，但应在首轮检查中确认工单是否具备最基本的验证条件。若信息足够，就复现并标记结果；若缺失，应一次性列出最关键的待补信息，而不是每次想到一个问题就发一条消息。

1. 快速检查标题、环境、前置条件、操作步骤和实际结果是否齐全。
2. 按提供的路径尝试复现，并记录实际尝试次数和环境。
3. 能够复现时，确认影响和预期规则是否清楚，再分派负责人。
4. 无法复现时，先对齐版本、账号权限、数据状态和时间范围。
5. 仍无法复现时，标明已尝试的条件、缺少的证据和下一次跟进责任人。

4. 修复后验证：回到原步骤，并覆盖与根因相关的边界

修复验证不能只检查“现在看起来好了”。首先按原复现路径回归，确认同一现象消失；然后根据修复原因选择相邻场景，例如不同权限、临界值、空值、重复提交或其他状态。边界范围要与风险相关，不必对每条小改动执行全量回归。

回归记录至少应包含修复版本、测试环境、执行人、原路径结果、补充边界和未覆盖风险。若缺陷无法完全消除但有临时绕行方案，应明确剩余影响、适用条件和后续处理时间，不能仅以“已关闭”替代风险说明。

七、不同情况下的行动建议：不要用一套要求处理所有缺陷

1. 必现且影响核心业务的问题

这类问题优先级通常较高，先确认影响范围和可用绕行，再让团队尽快复现、隔离风险并安排修复。复现步骤仍应保留，但不必因为等待所有附件而延误止损。项目经理需要指定决策人、响应时间、回归范围和对外沟通口径，避免多人同时排查却无人负责结论。

若用户正在遭受实际损失，应先按组织的故障响应机制处理，必要时回滚、关闭入口或限制受影响操作。工单证据可在止损后补全，但时间线、版本和关键业务影响应立即留存。

2. 偶发、无法稳定重现的问题

不要反复要求报告人“再试一次”。先收集出现概率、时间区间、网络或设备差异、关联请求标识和相关日志，并明确谁负责下一次取证。若问题只在特定窗口出现，可协调复现时段或建立临时观测，而不是把工单无限期挂在“处理中”。

偶发问题的判断应结合影响和可观测性。高影响且难复现的问题，可能需要先加监控或日志；低影响且出现率极低的问题，可以先记录趋势、等待更多样本。关闭前应说明证据不足的原因和重新开启条件。

3. 预期规则不明确或需求仍在变化

这类情况不适合让开发人员直接“按感觉修”。项目经理应安排产品负责人确认规则，记录决定时间、适用版本和可能的兼容影响；确认后，将规则同步到验收标准或测试用例。若问题本质上是未定义行为，应标注为待澄清事项，避免缺陷统计被需求讨论污染。

如果业务窗口临近，团队可以先决定是否需要临时保护措施，例如限制某种操作或提醒用户，但必须明确这不是根因修复。后续要跟踪正式规则和验证计划，避免临时方案长期无人负责。

4. 环境、数据或权限经常让团队无法复现

连续出现相同类型的缺失，说明问题可能属于系统性条件管理，而非个人填写习惯。项目经理应检查测试账号、权限申请、环境重置、测试数据生成和版本发布机制。对于每周都要手工确认的条件，优先评估自动采集或标准化准备步骤。

也要检查开发和测试是否有合理的环境访问权限。安全要求不允许开放生产数据，不代表不能提供脱敏副本或可重建的数据集。把权限、安全与可复现性一起设计，比在缺陷讨论中临时共享敏感信息更稳妥。

5. 多团队协作或使用项目管理平台的场景

跨团队协作时，统一字段名称和状态含义比强求每个团队采用完全相同的流程更重要。可以统一环境、复现结果、优先级、验证结论等关键口径，同时允许各产品线添加少量领域字段。使用 PingCode 这类面向中大型组织的项目管理平台时，管理者应先确认其工作流是否能承载这些统一口径，再决定如何配置字段和看板；不要把配置完成误认为流程已经落地。

上线初期可以先选一个模块试行两到四周，记录补充次数、首次复现率、受理耗时和填报负担，再根据真实使用反馈调整。若团队规模尚小、协作链路简单，轻量模板和每周复盘可能更合适，不必一开始就建立复杂审批。

八、不同情况下的取舍：指标、模板和门禁都要设边界

1. 完整度与填写负担之间的取舍

必填字段越多，理论上能收集更多信息，但并不必然提升复现效率。判断字段是否保留，可以看它是否改变复现、优先级或修复决策。如果过去一个月某字段几乎没有被用于排查，且系统不能自动填充，就应重新评估是否设为必填。

对高风险缺陷可以要求更多证据，对普通界面问题则保持轻量。重要的不是所有人填写同样长度的报告，而是风险越高，证据要求越清楚；自动采集能解决的字段，不要转嫁为人工负担。

2. 统一标准与业务差异之间的取舍

跨团队统一有助于汇总分析，但过度统一会抹掉业务差异。一个移动端缺陷需要设备和系统版本，一个数据平台问题可能更关注批次、时间窗和数据源。应当统一核心概念和统计口径，同时允许不同业务域增加必要字段。

如果同一个指标在不同团队的定义不同，就不要直接合并比较。先明确分子、分母、统计周期、暂停状态处理方式和缺陷分类规则；口径未对齐时，数字只适合团队内部观察，不适合管理层横向排名。

3. 追求快速处理与保留审计证据之间的取舍

紧急问题需要快速止损，但快速处理不等于不留证据。至少应保留发生时间、受影响版本、业务影响、临时措施和责任人，待风险稳定后补齐完整复现步骤。若为了速度跳过审批或测试，应把跳过的范围和后续补测安排写清楚。

常规低风险缺陷则可以按标准流程完整验证。项目经理应明确哪些情况允许走快速通道、谁有权批准、何时补做回归，不要让“紧急”成为长期绕开质量机制的借口。

4. 复现率与团队考核之间的取舍

首次复现率适合评估流程是否顺畅，不适合直接作为个人绩效排名。低复现率可能来自复杂业务、环境不稳定、偶发问题或报告信息缺失；若把单一指标绑定个人考核，团队可能少报难题、夸大复现频率，甚至通过缩小统计范围改善数字。

更稳妥的做法是把指标用于团队诊断，并结合样本量、缺陷类型、影响等级和补充原因解释。管理层应追踪趋势和根因类别，而不是只追问某个人为什么没达到目标。指标要促使流程变好，而不是让数据失真。

5. 关闭速度与修复可信度之间的取舍

关闭得快不一定意味着风险消失。若原始场景没有回归，或者修复只在开发环境验证，工单状态可能过早进入完成。反过来，低风险问题也不应被要求做不必要的全量测试，拖慢团队响应。

关闭标准应基于风险：确认原路径、检查与根因相关的边界、记录版本和证据，并对未覆盖部分作出说明。对高影响缺陷增加回归深度，对低风险缺陷保持适度验证，能比统一要求“全部全量回归”更可持续。

九、结尾：把复现质量变成可改善的交付能力

1. 项目经理下一步可以做什么

不要从重写所有模板开始。先抽取最近一个迭代的缺陷样本，统计首次复现结果、补充次数、各阶段等待时间、无法复现原因和回归结论。选择出现最频繁、改善成本最低的一项原因，设计一个小改动，并在下一个迭代观察它是否减少了往返或等待。

1. 统一“首次复现”“补充沟通”“无法复现”和“回归通过”的定义。
2. 抽查不同类型、不同严重度的工单，找出最常见的信息缺口。
3. 优先自动收集版本、时间和客户端信息，把人工字段留给业务条件。
4. 试行轻量模板两到四周，同时观察完整度、填写成本和处理周期。
5. 每个迭代复盘一项流程原因，避免把缺陷数量直接当成个人表现。

2. 最值得坚持的判断

Bug复现步骤的价值，不在于工单看起来规范，而在于它能不能把“我看见了异常”变成“团队可以共同验证、定位、修复和复查的事实”。项目经理的数据分析也不应止步于缺陷总数和关闭率，而要观察证据如何流动、等待发生在哪里、哪类成本可以通过流程设计消除。

复现质量不是写作问题，而是项目上下文是否可共享的问题。下一步先从真实工单中找出最常导致追问的一项条件，改进采集方式，再用同一口径对比改进前后。能让下一个人少猜一次、少等一轮、少漏一个边界，才是这份教程真正要追求的结果。