敏捷项目Feature教程：产品经理实操方法，避坑指南

敏捷项目里最常见的 Feature 失控，并不是团队不会写需求，而是把“想做的一组功能”误当成“已经定义清楚的产品结果”：排期时看起来范围完整，开发中却不断补规则，上线后才发现用户流程仍然断在关键一步。我的判断是，Feature 的价值不在于名称写得多专业，而在于它能否把用户结果、交付边界、验收证据和拆分路径连起来。

敏捷项目Feature教程：产品经理实操方法，避坑指南

一、先讲核心结论：Feature 是连接产品结果与团队交付的边界

1. Feature 不是更大的 User Story，而是一个可验证的能力切片

团队对 Feature 的定义并不总是相同。有些组织把它用于产品路线图和版本规划，有些规模化敏捷框架则赋予它更明确的层级和验收结构。因此，我不会先争论术语，而会先问三个问题：它为哪类用户解决什么问题？交付后用户能完成什么以前无法完成的事？团队用什么证据判断它有效？这三问答不出来，写成 Feature 也只是标题包装。

在本文中，我把 Feature 定义为：能被用户感知、能独立说明价值、需要多个可交付工作项协作完成，并且可以用明确证据验收的一项产品能力。它通常大于单个 Story，但不应大到成为“重做整个后台”这样的长期项目。一个 Feature 可以横跨前端、后端、测试、数据、安全等工作，但仍要有一个可讲清楚的用户结果。

例如，“新增审批中心”更像功能集合；“业务负责人能够在一个页面查看待审批事项，并完成同意、驳回和补充材料操作”则更接近可验收能力。后者仍需要继续明确角色、状态、权限和异常情况，但它已经能指向用户任务，而不是只列界面或模块名称。

2. 写 Feature 时先写结果，再写范围

我建议产品经理把 Feature 的第一句话写成用户结果，而不是组件名称。可用这个句式起稿：“对于【用户或角色】，当【场景或触发条件】发生时，提供【能力】，使其能够【结果】，并通过【证据】确认是否达成。”它不是必须照抄的模板，而是逼自己把受益人、情境、能力和验证方式同时摆上桌。

比如，“对于需要跨部门审批的业务负责人，当申请进入待处理状态时，能够查看申请背景、处理历史和下一步动作，并在权限范围内完成审批，使申请不再依赖邮件往返；通过任务完成率、处理时长及错误操作记录验证。”这比“做一个审批列表”更能指导设计、研发与测试讨论。

3. 先设边界，再讨论拆分

Feature 的边界不是“这个版本能不能多做一点”，而是“哪些内容是完成用户结果的必要条件，哪些只是增强体验或未来扩展”。边界若没有写清，拆分会议就会变成临场谈判：有人把权限当基础，有人认为可以后补；有人认为移动端必须同步，有人只考虑桌面端。

一个可用的 Feature 至少要让团队知道：价值对象、目标场景、范围内能力、明确不做的事项、验收条件、依赖与风险、负责人和决策时点。这些信息不要求全部塞进长文档，但必须在团队真正做承诺前可查、可讨论、可更新。

二、背景与真实场景：为什么 Feature 特别容易变成“需求大筐”

1. 中大型团队的难点不是缺需求，而是上下游对“完成”理解不一样

在多团队协作里，同一个 Feature 可能同时影响产品、设计、研发、测试、数据、运维和安全。产品经理认为“审批通过”就是完成；研发发现还需处理重复提交、权限校验和并发更新；测试关心撤回后状态如何变化；运维则会问审计日志、数据保留和告警策略。若这些问题直到提测才出现，问题通常不是某个角色“不配合”，而是 Feature 的边界没有提前显性化。

我更愿意把 Feature 看成一个协作契约，而不是一张任务卡。它不替代详细设计，也不要求产品经理预先写完所有技术方案；它的作用是让各角色对“为什么做、做多大、怎样算有效”有共同认识。越是跨团队、跨系统的工作，这份共同认识越能减少返工与口头猜测。

2. 规模越大，依赖越要在 Feature 层被看见

小团队可能坐在同一张桌旁，当场补齐接口约定；但一个 Feature 如果依赖身份系统、消息服务、数据平台和多个业务团队，口头同步就很容易遗漏。此时，Feature 需要显式列出依赖方、输入输出、最晚决策时间、未解决问题及其影响，而不是只在 Story 里写一句“等待接口”。

对于 100 人以上的组织，团队数量增加后，需求流转的等待、重复澄清和优先级冲突往往比单个开发任务更值得管理。产品经理不应把“建立更多流程”当作解决方案；应先识别信息在哪个交接点丢失，再决定是否需要统一模板、跨团队评审或工具化追踪。

3. 敏捷不是省略定义，而是让定义随着证据逐步变准确

敏捷不意味着产品经理必须在开发前预测所有细节，也不意味着团队可以带着含糊目标开工。更合理的做法是分层准备：早期明确问题、价值假设和约束；进入近期计划前明确范围、验收和依赖；开发过程中允许根据反馈调整方案，但要记录调整对目标、成本和风险的影响。

Scrum Guide 2020 强调透明、检视与适应，并没有规定 Feature 必须采用某一种固定模板。这一点很重要：模板只是帮助形成共同理解的工具，不是敏捷本身。团队采用哪种字段，应由实际的协作风险决定。

三、常见误区：这些写法看似完整，实际会拖慢交付

1. 把功能清单当成用户价值

“新增筛选、增加导出、优化列表、支持批量操作”是功能清单，不等于 Feature 的价值说明。功能清单能描述做什么，却没有解释为什么做、服务谁、优先解决哪个问题。结果是团队完成了所有勾选项，用户仍然要绕路完成原来的任务。

改法不是删掉功能，而是给它们建立因果关系。先写用户任务与当前障碍，再写每项能力如何消除障碍，最后判断哪些能力是最小可验证范围。若某个功能既不能支持目标用户完成任务，也不是安全、合规或技术约束所必需，就应重新审视它是否属于当前 Feature。

2. 把 Feature 写成无法在一个可控周期内验证的大项目

“重构客户管理”“全面升级报表平台”“统一所有业务流程”都可能有合理的战略方向，但它们太宽，无法直接用于交付承诺。团队容易陷入长时间开发，期间不断加范围，最后把上线当成唯一验收标准。上线只证明代码发布，不证明用户问题解决。

拆分时不要按组织架构切成“前端一块、后端一块、数据一块”，因为这些切片可能没有任何一个能单独产生可验证结果。更好的切法通常沿用户流程、业务规则、用户类型或风险等级切，让每一片都尽量形成端到端能力。

3. 把验收标准写成实现方案

“页面上增加一个蓝色按钮，点击后调用某接口”把验收绑在具体设计与技术实现上。界面可能在设计评审后变化，接口也可能重构，但用户结果不应因此失去。验收标准更适合描述可观察行为，例如：“拥有审批权限的用户能查看待处理申请；无权限用户不能读取申请详情；审批完成后状态与操作记录一致。”

实现约束当然可以记录，但应与用户行为验收区分。对于合规、安全或技术约束，可单独列成非功能要求或风险控制条件，避免所有内容都挤进一段“验收标准”，让测试难以判断什么是必须验证的结果。

4. 用估算分数代替不确定性管理

Story Point、理想人日或复杂度等级都不能自动回答“我们是否理解了需求”。一个 Feature 估算很小，可能只是因为团队还没发现数据迁移、权限模型或外部依赖。估算数字应当和假设、风险、可用证据一起读，不能单独拿来证明计划可靠。

如果估算分歧很大，我会先找出分歧来自范围、技术方案、依赖还是验收理解，而不是急着让团队投票。估算的主要价值是暴露未知，不是制造一个看似精确的承诺。

5. 把“本期不做”留在会议里

讨论中明确说过“不做移动端”，不等于几周后每个人仍然记得这项决定。没有记录的边界会在需求变更、人员轮换和验收阶段被重新打开，最后形成隐性范围扩张。将不做项、延期项和重新评估条件写下来，比单纯写“范围以需求文档为准”更有用。

不做项最好写成具体对象与条件，例如“本期不支持跨组织代审批；若试点用户中该场景占比超过约定阈值，再评估下一迭代”。阈值应由团队根据业务价值和数据能力设定，不应为了显得严谨而凭空制造数字。

四、专业判断逻辑：从问题证据走到可验收的 Feature

1. 先确认问题是否值得解决

产品经理在写 Feature 前，至少要有一类问题证据：用户访谈中的重复障碍、客服工单、行为数据、业务流程耗时、错误或流失记录、监管要求，或者管理层明确的战略约束。证据不一定一开始就完美，但要注明来源、时间范围和局限，不能把一次个别反馈写成普遍用户需求。

我会把“用户说想要什么”与“用户为什么需要它”分开记录。用户提出的方案可能是一个按钮、一个报表，也可能是某个竞品已有的功能；产品经理要验证的，是背后的任务和阻碍是否真实，以及有没有更简单的解决路径。

2. 再描述结果和验证方式

结果要尽量落在用户行为或业务结果上，而不是“系统支持某功能”。例如“用户能在一个工作台处理申请”是行为结果；“审批时间从几天缩短到几小时”则是业务假设，需要基线与上线后数据验证。不要在没有测量条件时承诺结果数值，可以先定义测量方法，再把目标作为待验证假设。

指标选择要区分产出和结果。交付了多少 Story、做了多少页面属于产出；用户完成任务的比例、平均处理时长、错误操作率才更接近结果。也不要只看平均数：处理时长可能被少数复杂案例拉高，必要时同时观察中位数、分位数或不同用户群体表现。

3. 划出范围与非目标

范围内写必须完成的能力、规则和场景；非目标写当前明确不处理的能力；假设写尚未证实但暂时采用的判断；依赖写外部输入与负责人。四者不要混为一谈。比如“系统已提供统一身份认证”是依赖或假设，不是Feature本身；“支持审批记录追溯”可能是必要能力，也可能是法规要求，应该说明依据。

这里有一个实用判断：如果移除某项能力后，目标用户仍能完成核心任务，且风险和合规要求允许，它可能适合放到后续增强范围；如果移除后任务无法闭环，或会造成数据、安全、责任归属风险，它通常不是可随意削减的“锦上添花”。

4. 把验收标准写成可观察的行为

验收标准可以采用 Given-When-Then 结构，也可以用清晰的条件句。关键不是格式，而是测试人员、产品经理和研发能否对同一条标准得出相同判断。每个重要路径至少要考虑正常流程、权限边界、失败处理和数据一致性；复杂领域还要覆盖审计、性能或可用性约束。

• 正常路径：具备权限的负责人打开待办申请后，能看到申请内容、提交人和当前状态，并完成批准或驳回。
• 权限边界：无权访问该申请的用户不能查看详情或执行操作，系统需给出可理解的反馈。
• 异常处理：申请状态已被其他人更新时，页面不能静默覆盖最新状态，应提示用户刷新或重新确认。
• 记录要求：每次审批动作都能关联操作者、时间、动作和结果，满足约定的审计查询需求。

5. 以 Ready 检查代替“文档写满了”

我不把 Ready 理解为每个细节都已确定，而是把它当作进入近期交付前的一道风险检查。团队可以按自己的复杂度设门槛，但至少要回答：价值和目标是否清楚？范围是否足以估算？关键验收是否可测试？依赖是否有人跟进？风险是否有处理计划？未解问题是否会阻塞开发？

若有一个关键问题暂时无法回答，不一定要停止所有工作。可以先做技术探针、用户验证或小范围原型，把未知变成可评估证据，再决定是否承诺完整 Feature。关键是不要把“尚未理解”伪装成“开发过程中自然会解决”。

五、实操案例：把“审批中心”拆成用户能验证的交付

1. 案例背景：不要从页面模块开始拆

下面是一个用于演示方法的情景案例，并非某家企业的真实经营数据。假设一个 100 人以上的业务组织，多个团队通过内部平台处理采购、合同与费用申请。用户反馈需要在邮件、聊天记录和业务系统之间来回找待办，负责人无法快速判断哪些申请即将超时。团队收到的原始需求是“做一个统一审批中心”。

如果直接接受这句话，团队很容易按页面拆成“待办列表、详情页、审批按钮、统计报表”。我会先把问题改写为：“负责审批的用户难以集中发现和处理待办，信息分散导致处理过程不稳定。”随后再确认哪些用户类型、申请类型和状态是本期重点，并用访谈、工单或现有流程数据确认问题范围。

2. 先确定最小闭环，而不是先承诺所有申请类型

假设团队选择先覆盖采购申请，并验证一个最小闭环：用户登录后看到有权限处理的待办；打开申请能理解背景及必要附件；执行批准或驳回后，状态和操作记录同步更新；申请人能获知处理结果。此时，“统计报表”“移动端批量处理”“跨组织代审批”可以列为候选增强项，但不能未经验证就全部塞进首期。

这个切法有一个重要优点：它不是按页面或技术层分，而是沿着用户的完整任务路径切。用户可以完成一项真实任务，团队也可以观察是否少了跳转、减少了重复询问，以及异常状态是否可控。

3. 用 Story 和任务把 Feature 落到可交付工作

Feature 的下一层可以是用户故事或工作项，具体名称依团队惯例而定。拆分时，我会避免把所有工作都写成“作为用户，我想要……”，因为技术探针、迁移、安全检查等工作有时需要以工程任务或风险工作项呈现。重点是每项工作都能追溯到 Feature 的目标、约束或风险控制。

• 建立待办查询规则：明确用户权限、申请状态和默认排序。
• 展示申请详情：提供审批判断所需的字段、附件和历史记录。
• 执行审批动作：支持批准、驳回及必要的意见填写，并处理重复提交。
• 更新业务状态：确保动作结果与申请状态一致，处理并发更新提示。
• 通知申请人：按已确认渠道发送结果，并避免重复或错误通知。
• 建立审计记录：保留操作者、时间、动作和结果，满足查询约束。
• 补充可观测性：记录失败类型、处理耗时和关键转化节点，为上线评估提供数据。

4. 把数据观察设计进 Feature，而不是上线后临时补埋点

如果团队打算验证“审批更方便”，却没有定义什么叫方便，结果会变成上线后靠几条用户评论判断成败。我会在开发前确认事件口径：待办被打开、详情被查看、审批动作成功、审批失败、用户退出或回到列表。事件还要定义去重、时间范围、用户权限和隐私边界，否则看似精确的仪表盘也可能误导决策。

建议至少同时看过程和结果。过程指标帮助定位转化断点，例如从看到待办到打开详情的比例；结果指标检查用户任务是否改善，例如处理时长分布、一次完成率、错误率。若没有可靠的上线前基线，就先记录基线并明确它的局限，不要在发布后倒推一个“改善百分比”。

5. 用小范围试点验证假设，再决定扩大范围

上线后不宜只问“大家觉得怎么样”。我会先挑选一组业务类型和真实用户进行试点，观察关键路径是否可完成、失败原因是否可解释、支持团队是否能处理问题。试点结束后再把反馈分成三类：阻止任务完成的缺陷、影响效率但有替代路径的问题、用户提出的新增需求。第一类应优先修复，第二类结合成本排序，第三类先验证价值，不要自动并入本期。

对于前述情景，团队可以设定一个试点观察窗口，例如两到四周，并明确样本条件、数据口径和复盘日期。这是计划建议而非通用标准。业务季节性、申请量和用户行为会影响观察结果，样本不足时应报告不确定性，而不是把少量成功案例当作全面有效的证据。

六、工具与协作：什么时候需要把 Feature 管理流程化

1. 工具应解决信息断链，而不是制造更多字段

当团队人数和项目数增加，Feature 可能分散在路线图、需求文档、任务看板、测试记录和发布说明中。若用户结果、验收和开发任务之间没有可追溯关系，复盘时很难回答：这项能力服务哪个目标？哪些工作组成它？哪些验收没通过？上线后观察到了什么？工具的价值在于减少这种查找与同步成本，而不是把同一份信息复制到更多表单。

我会优先检查工具是否支持清晰的层级与关联、字段是否可配置、权限和变更记录是否适合组织治理、是否能连接需求与研发测试流程，以及报表能否按实际角色使用。工具功能再多，如果团队仍靠私聊确认最新版、靠人工拼周报，就没有解决最关键的协作问题。

2. 中大型组织要额外评估治理、部署和迁移成本

对 100 人以上的组织，评估项目管理平台时，不能只看单个产品经理创建需求是否顺手，还要看多团队的权限边界、项目间依赖、统一字段治理、历史数据迁移、审计要求和系统集成。私有化部署需求通常还需要评估升级策略、运维资源、备份恢复、身份认证和安全责任，不能只把“可以私有化”当作整体部署方案已确定。

若团队正在从 Jira 迁移，先盘点项目层级、工作项类型、自定义字段、工作流、权限、附件、历史记录、自动化规则和报表依赖，再做映射与抽样校验。平滑迁移的关键不只是导入数据，而是确保迁移后用户还能找得到原来的信息，关键流程不会因字段映射或权限差异失效。

3. PingCode 可以作为中大型组织的候选平台之一

如果组织要把 Feature、研发工作项、测试协作和交付过程放在一套体系里管理，可以将 PingCode 纳入评估。按照其产品能力说明，PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，并支持 Jira 平滑迁移。对于正在评估国产项目管理平台或替代路径的团队，这些能力值得进入验证清单；但是否适合，仍要由真实流程试点决定，不宜仅凭产品定位或宣传表述下结论。

我建议至少用一个真实 Feature 做小规模验证：从需求建档开始，追踪到 Story、研发任务、测试结果与发布记录；再测试权限、历史数据查询、报表口径、迁移后的字段和异常流程。与此同时，让产品、研发、测试、项目治理和运维分别完成一组任务。若只有管理员觉得好用，普通成员却需要大量绕路，平台并未真正降低协作成本。

4. 用总拥有成本而不是单一许可费用做判断

平台评估要把配置、迁移、培训、集成、运维、版本升级和流程治理都纳入成本。低许可成本不必然意味着低总成本；功能丰富也不必然意味着更适合。若团队当前的问题是 Feature 定义混乱，先统一价值、边界和验收方式，换工具未必能解决；若问题是信息关联断裂、权限难治理或跨团队状态不可见，工具能力才可能成为重要杠杆。

七、不同情况下怎么行动：产品经理的 Feature 工作清单

1. 需求来源不清，先做问题澄清

如果需求来自管理层指令、客户提案或竞品观察，不要急着拒绝，也不要直接拆任务。先问：谁遇到问题？发生频率和影响是什么？现有替代方案是什么？如果不做，具体损失或机会成本是什么？哪些证据支持这个判断？如果暂时没有证据，把它作为假设写明，并安排访谈、数据分析或原型测试。

这一步的交付物可以很轻：一页机会说明、问题证据、目标用户、关键假设和下一步验证动作。目标不是写一份完整商业论证，而是避免团队在还不知道问题是否真实时，先投入大量开发。

2. 价值清晰但方案不确定，先验证关键假设

如果用户问题明确，但不知道怎样解决，Feature 可以先定义探索范围，不必马上承诺完整交付。可通过可点击原型、技术探针、数据样本验证或有限用户测试，回答最影响决策的问题。例如，用户是否理解新的审批入口？现有系统是否能提供可靠状态？外部接口是否支持所需权限？

要为探索设退出条件：验证成功后进入哪一步，验证失败时如何调整，最长投入多少时间或资源。探索不是无期限研究，也不应被包装成已经承诺的功能交付。

3. 目标清楚但依赖未解决，拆出依赖决策

若核心 Feature 依赖其他团队或系统，明确依赖输入、负责人、确认日期、失败影响和备选路径。将“等对方排期”改写成一个可追踪的风险项，并判断是否能先并行完成不受依赖影响的工作。若无法绕开，产品负责人应推动优先级和资源决策，而不是让执行团队在看板上长期挂着阻塞任务。

依赖清单也应随变化更新。接口方案、数据结构或合规要求一旦改变，需要重新评估受影响的验收、估算与发布计划。否则，Feature 看似状态正常，实际关键前提已经失效。

4. Feature 跨多个团队，建立共同验收和分阶段承诺

跨团队 Feature 应有一个共同的用户结果，以及每个团队的交付责任和接口约定。避免每个团队只对自己的局部工作“完成”负责，却无人确认端到端任务是否可用。可以安排联合评审、集成演练或分阶段验收，把最早能验证的端到端路径提前。

如果发布必须一次性完成，应更早安排集成、回滚和风险评审；如果业务允许渐进发布，则可通过受控用户组、功能开关或分批启用降低风险。具体手段取决于系统架构与安全要求，不能为了敏捷而忽略变更控制。

5. 上线后结果不理想，复盘目标而不只复盘执行

如果 Feature 按计划上线但指标没有改善，先区分四种可能：问题判断错了、方案没有解决问题、用户没有采用、测量口径不可靠。不同原因对应不同动作。问题判断错了，重新研究需求；方案效果有限，调整体验或流程；采用率低，调查发现与触达；数据不可靠，先修复埋点与口径再下结论。

不要把所有未达预期都归咎于“推广不足”，也不要把团队按时交付当成价值已实现。复盘应该决定下一步投入，而不是只给项目打分。

八、取舍原则：范围、速度、质量和证据不能同时无限扩张

1. 范围取舍：保住用户闭环，延后低优先级增强

时间受限时，优先保住核心用户任务、必要权限、数据正确性和异常处理。可延后的是不影响核心闭环、可以通过已接受的替代路径处理、且风险可控的增强项。不能把安全、隐私、审计或数据一致性默认为“以后再补”，也不能因为它们不直接出现在界面上，就把它们误判为非核心工作。

范围取舍必须同步更新预期：哪些用户暂不支持、哪些场景有临时方案、哪些风险由谁接受、何时重新评估。只删任务、不改预期，会让用户和管理层仍以为原承诺完整存在。

2. 速度取舍：缩小发布面，不要牺牲必要的验证

想更快验证价值，可以缩小用户群、申请类型或渠道范围，先发布最小可用闭环；也可以先做原型验证交互，再投入工程化建设。相比之下，跳过关键测试、取消回滚方案或不检查权限，虽然可能让发布日期提前，却会将成本转移到事故和修复阶段。

如果必须压缩测试范围，应该明确测试覆盖了什么、没有覆盖什么、剩余风险有多大以及谁批准接受。透明的有限验证比“已经测过”这种模糊承诺更有治理价值。

3. 质量取舍：按风险分配验证力度

不同 Feature 的质量风险不同。影响资金、个人信息、合规记录或关键业务连续性的能力，应增加边界测试、权限验证、审计检查和回滚演练；低风险的文案调整或内部小工具，验证方式可以更轻。所谓质量不是每项工作都进行相同强度的测试，而是高后果风险必须有相称的控制。

产品经理不需要独自承担所有技术判断，但需要推动相关专家尽早参与，并把风险和责任记录清楚。Feature 的价值越高、影响面越广，越不能只用“测试通过”作为唯一上线信号。

4. 证据取舍：宁可报告不确定，也不制造精确感

当样本少、埋点不完整或上线周期太短时，正确结论可能是“目前无法判断”。产品经理可以同时报告已观察结果、样本范围、口径限制和下一步采集计划。没有证据时，不应把模拟数据写成真实成效；指标看似改善，也要检查用户结构、业务季节和版本变化等混杂因素。

这一原则尤其适用于内部复盘和对外案例。展示具体数字有助于决策，但前提是说明来源、统计口径和数据性质。本文案例中的审批指标及图表数值均为情景模拟，用来展示分析方法，并不代表真实客户数据或行业基准。

九、总结：先定义可验证的用户结果，再决定要做多少

1. 用一张 Feature 说明卡开始

如果你正在处理一个含糊需求，可以先花一小时写出一张说明卡：目标用户和场景是什么？当前障碍有什么证据？希望用户完成什么结果？首期范围与明确不做项是什么？怎样验收？依赖和最大风险是什么？上线后用什么数据观察？这张卡不必写得漂亮，但必须让相关角色看完后能指出分歧。

接着组织一次短评审，让产品、研发、测试及相关依赖方分别回答：我理解的用户结果是什么？我认为最大的未知是什么？有什么条件会阻止交付？如果答案不一致，不要急着排期，先把差异转成决策、验证或风险行动。

2. 把 Feature 当作持续更新的决策记录

Feature 不是写完就冻结的合同，也不是想改就改的便签。它应记录关键假设如何被证据支持或推翻，范围为何调整，风险由谁接受，以及上线后的结果如何影响下一步。记录这些变化，团队才能在人员轮换、跨部门协作和后续复盘中保持上下文。

我对 Feature 的最终判断标准很简单：它是否让团队更早发现错误方向、更少依赖口头猜测，并更清楚地证明用户结果。如果只增加文档，却没有改善判断和协作，就应删减流程；如果一张清楚的 Feature 卡让多个角色围绕同一结果行动，它就已经发挥了价值。下一步不要先追求最完美的模板，先挑一个近期需求，写清问题、边界、验收和证据，再用一次真实交付检验这套方法。