迭代复盘落地方案：实施团队开展迭代管理的落地方案案例解析

迭代复盘最常见的失败，不是团队没有开会，而是会议结束后，大家都认同“需求变更多、测试时间紧”，下个迭代却仍然在最后三天集中提测。实施团队要把复盘真正落地，关键不是把会议开得更长，而是让每个问题都能追溯到具体工作流、责任边界和可验证的改进行动。本文以一个中大型实施团队的情景化案例为主线，拆解从数据准备、会议讨论到改进验证的完整做法，并给出适用于不同团队规模与工具条件的取舍建议。

一、先讲结论：复盘不是总结会，而是迭代管理的纠偏机制

1. 复盘的产出不是“认识”，而是可验证的改变

我判断一次迭代复盘有没有落地，不看会议纪要写得多完整，而看下个迭代是否出现了可观察的变化。比如，需求确认时间是否提前，阻塞项是否更快暴露，测试等待时间是否下降，临时插单是否有了明确入口。

“沟通要加强”“提高质量意识”“加强需求管理”都不是可执行的改进项。它们没有指向具体动作，也没有完成时间和验证口径。更合格的写法是：“从下个迭代起，所有新需求进入迭代前，由产品负责人和实施负责人共同确认验收条件；未确认的需求不进入开发排期；在迭代结束时统计验收条件缺失数。”

复盘的最小闭环是：事实数据，问题判断，根因假设，改进行动，下轮验证。少了任何一环，团队都容易把复盘变成感受交换，或把一次性的补救措施误当成流程改进。

2. 实施团队的复盘重点，应从“做了多少”转向“交付为何不稳定”

实施项目的工作通常跨越需求澄清、配置开发、数据处理、客户确认、联调测试和上线保障。团队可能同时服务多个客户，项目优先级又会随现场情况变化。因此，单看完成任务数很容易产生误判：任务做得多，不等于迭代交付可靠；按时关闭工单，也不等于客户已经验收。

我建议每轮复盘至少同时观察三类结果：承诺兑现程度、工作流等待时间、上线或验收后的返工情况。这样才能区分“估算不准”“需求输入不完整”“跨角色等待”与“质量问题”，而不是一概归结为执行不力。

3. 改进项必须有边界，不能把所有问题都塞进下一轮

复盘不是问题收集竞赛。一个团队每轮列出十几项改进，却没有人负责验证，最终只会增加管理负担。对大多数实施团队，我更倾向于每轮选一至三项改进，优先处理会重复发生、会影响交付承诺、且团队有能力控制的问题。

如果问题来自客户决策迟缓，团队未必能让客户立刻改变；但可以改进风险升级时间、决策记录方式和延期预警机制。好的改进项不要求团队控制所有外部条件，而是要求团队明确自己能改变的那一段。

二、背景和真实场景：实施团队为什么更容易在迭代末端失速

1. 多项目并行会让“计划中的迭代”和“实际工作”分离

以下案例是基于常见实施交付模式构造的情景化案例，不代表某一家企业的公开经营数据。团队有 36 人，分成三个交付小组，同时支持多个客户项目。每两周做一次迭代计划，但现场问题、客户补充需求和上线保障任务会不断进入团队工作队列。

迭代开始时，团队通常会依据可用人力安排需求和缺陷；但到中途，成员被临时抽去处理客户环境问题，原计划工作被打断。到了迭代末尾，团队为了兑现承诺，压缩测试与验收时间。表面看起来是“开发进度慢”，实际往往是需求进入规则、优先级变化、跨角色等待和容量估算同时失衡。

实施场景还有一个容易被忽视的变量：同一个任务可能同时依赖客户提供数据、内部产品答疑、开发完成配置和测试环境可用。任务状态写着“进行中”，并不能说明它正在被有效推进。复盘时必须把等待时间和处理时间拆开，否则团队会把外部等待误判成成员效率低。

2. 复盘前先建立基线，否则改进效果无从判断

我会先选取连续三到四个迭代作为观察窗口，记录每轮承诺工作量、完成工作量、临时插入工作、阻塞时长、验收退回和返工情况。单轮数据受客户上线窗口、节假日和重大故障影响很大，不能轻易拿一轮的结果给团队贴标签。

如果团队没有成熟的数据系统，可以先用共享表格或任务看板补齐最基本的字段：事项类型、提出时间、进入迭代时间、开始处理时间、完成时间、等待原因、验收结果。记录不必一开始就复杂，但字段口径必须统一。比如“完成”到底是开发完成、测试通过，还是客户验收，必须事先约定。

下表中的数值用于说明如何组织复盘观察，属于情景模拟，不是行业平均值。真正落地时应使用团队自己的历史记录，并注明统计周期和口径。

3. 数据不是用来排名，而是用来找到可控的交接点

对于实施团队，我很少建议按个人完成任务数做复盘比较。任务大小、客户复杂度、环境条件和依赖数量并不相同，简单排名容易诱导团队拆任务、挑简单事项，甚至隐藏风险。

更有价值的做法，是按工作流阶段看队列和等待：需求澄清后多久能进入开发，开发完成后多久能进入测试，测试发现的问题多久能得到响应，交付后多久能获得客户验收。若工作长期卡在某个交接点，改进就应优先作用于该处，而非泛泛要求所有人“提升效率”。

三、常见误区：看起来开了复盘，实际没有形成管理闭环

1. 误区一：用情绪投票代替事实还原

“这轮太赶”“需求又变了”“测试介入太晚”可能都是真的感受，但它们还不是可验证的结论。团队需要继续问：哪一天发生了变化？变化由谁提出？当时是否替换了迭代内其他工作？测试是在什么条件下介入？有多少事项因此延后？

若没有时间线和任务记录，讨论很容易被最近一次冲突带偏。声音最大的人不一定掌握完整过程，最容易记住的事件也不一定是影响最大的原因。复盘主持人应把“感受”记录为线索，再引导团队找到可核对的事实。

2. 误区二：把未完成事项直接当作团队承诺失败

未完成事项需要按原因拆分：需求在迭代中变化、外部依赖未就绪、工作量估计偏差、质量返工、人员被抽调、优先级被管理层调整。每种原因对应的动作不同。把它们全部归结为“承诺意识不足”，不仅找不到有效措施，还会让成员倾向于少报风险。

与此同时，承诺完成率也不能孤立使用。若团队为了追求高完成率，刻意把工作拆小、只承诺容易事项，指标就失去了管理价值。判断时要同时看客户价值、工作规模、插入工作和验收结果。

3. 误区三：把“所有人都参加”当成“所有人都要发言”

跨职能团队的复盘需要让关键角色参与，但不必让每位成员逐条汇报任务。成员轮流报流水账，会挤压真正分析原因的时间。建议提前收集书面观察，由主持人将问题聚类，会上集中讨论影响最大的两三个主题。

如果团队存在明显的层级压力，可以先匿名收集问题，再由主持人呈现主题与证据。管理者要避免立刻解释或追责，尤其不要在成员刚提出风险时就反驳其判断。否则后续数据会变得“漂亮”，但团队失去发现真实问题的能力。

4. 误区四：改进项写得宏大，导致下一轮无法验证

“优化需求管理”不是计划，而是方向。要把它缩小到一个具体动作，例如“迭代计划会前一天完成需求验收条件检查”，并指定谁负责、在哪个流程节点执行、如何统计结果。

还有一种常见情况，是团队一次选择太多改进项。每个改进都要占用日常交付容量，如果负责人没有时间执行，改进清单只是第二份待办队列。一个迭代先验证一项高影响改进，往往比同时启动六项更可靠。

5. 误区五：把工具上线当作流程问题的解决方案

任务管理工具可以帮助团队统一状态、记录变更、关联需求与缺陷，也能减少人工汇总。但工具不能替代决策规则。若团队没有约定何时允许插单、谁确认优先级、任务何时算验收完成，那么换一套系统后，只会把旧的不一致搬到新界面里。

在组织规模较大、项目并行较多、权限和部署要求复杂时，工具的价值会更明显。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，可用于需求、项目、研发流程和交付协作管理；支持私有化部署，也支持 Jira 平滑迁移。选型时仍要通过实际流程验证权限、字段、历史数据、集成和迁移边界，不能把“支持迁移”理解为所有自定义规则都能无损复制。

四、专业判断逻辑：怎样从问题现象走到正确的改进动作

1. 先判断问题属于结果、过程还是输入

我通常把复盘问题分成三层。结果层包括延期、返工、验收延迟和线上问题；过程层包括等待、交接、测试排队、状态不透明；输入层包括需求模糊、客户资料缺失、环境未准备和优先级不清。

如果只处理结果，团队可能会增加加班或临时测试人力；如果根因在输入，短期结果或许好看，下轮仍会重复失速。分析时要从结果反向追溯过程，再检查输入是否满足工作启动条件。

2. 用时间线和工作流定位瓶颈，不要先找责任人

对每个重点问题，先把关键节点按时间排序：提出、确认、排期、开始、等待、交付、测试、验收。然后标记每个等待区间的原因和责任边界。这里的“责任边界”不是找人背锅，而是弄清楚由谁提供信息、谁作出决定、谁推动下一步。

例如，一项配置工作实际处理只用了半天，却从提出到客户验收经过八天。如果团队只看处理时长，会觉得效率很好；若观察端到端周期，就会看到其中三天在等客户确认字段、两天在等测试环境。改进措施应落在前置确认和环境准备，而不是要求实施人员更快操作。

3. 用“影响、可控、可验证”筛选改进项

我会用三个问题筛选行动：它是否反复发生或造成显著影响？团队是否能控制至少一个关键环节？下个迭代能否通过数据判断变化？三个问题中有两个答不上来，通常不适合作为当前迭代的改进承诺。

改进项还要估算实施成本。新建复杂审批流程、增加多级评审，也许能降低某类风险，却可能让每个普通需求都变慢。对于低风险、可逆的工作，轻量检查表可能更合适；对于数据迁移、权限变更和上线窗口等高风险事项，则需要更明确的审批与回退机制。

4. 区分相关性、原因和偶发事件

某轮测试提前介入后缺陷减少，不足以证明“提前介入一定降低缺陷”。也可能是这轮需求更简单、变更更少，或上线规模更小。为避免过度归因，至少观察连续几轮，并记录会影响结果的条件。

对重大线上事故、合规风险和客户影响事件，不应为了等待更多样本而延迟整改；但仍要把紧急补救与长期改进分开。补丁可以立刻上线，流程规则则应在事后通过记录验证是否真正减少复发。

五、案例拆解：把“最后三天赶工”变成可追踪的改进实验

1. 情景团队的起点：需求都在做，真正完成的却不够稳定

情景团队连续三轮出现迭代末端集中提测。任务看板显示开发事项大多按时进入“完成”，但客户验收和测试结论经常延后。团队最初认为问题是测试资源不足，于是提出增加测试人手。复盘主持人没有马上接受这个结论，而是先抽查了 22 项任务的状态变更记录，并对照会议纪要和缺陷记录还原时间线。

抽查发现，22 项中有 9 项在迭代中途变更过验收条件，7 项存在客户资料或测试数据等待，5 项进入测试时离迭代结束不足两天。部分任务在开发完成后仍有未确认项，只是因为看板状态定义不清，被提前标记为完成。测试人手紧张确实存在，但不是唯一原因。

这一步改变了讨论方向：团队没有立即要求扩编，而是把问题拆成需求入口、工作状态和测试准备三个假设。经过讨论，当前轮先处理最可控且证据最清楚的一项：让验收条件在进入迭代前明确，并为中途变更保留记录。

2. 复盘会议怎么开：先独立书写，再基于证据讨论

会议安排为 75 分钟，参与者包括交付负责人、产品或需求负责人、开发、测试和实施代表。会前一天，主持人从任务记录中整理数据，并让成员各自回答三个问题：本轮最有效的做法是什么？最影响交付的一件事是什么？希望下轮验证什么变化？

会议开始后的前十分钟先确认目标和数据口径，不讨论责任。接着用十五分钟浏览时间线与工作流数据，二十分钟集中分析影响最大的主题，再用十五分钟确定一项改进。最后留十五分钟写清负责人、完成节点、观测指标和复查日期。若问题超出团队权限，单独登记升级事项，不在会上假装可以解决。

1. 会前准备：汇总计划与实际、插单、阻塞、验收退回和缺陷数据，标记数据缺口。
2. 事实回顾：按时间线核对事件，不用“大家都知道”替代记录。
3. 原因分析：围绕一至两个高影响问题追问输入、交接和决策，不急着定责。
4. 行动选择：只选团队可控、影响较大、可在下一轮验证的改进。
5. 结果复查：下一轮计划会先检查行动执行情况，再讨论是否扩大、调整或停止。

3. 改进项如何写：把“加强需求管理”变成有限范围的实验

团队把原始建议“加强需求管理”改为：“迭代计划会前一个工作日，需求负责人和实施负责人共同检查验收条件、客户依赖和测试数据准备；缺少其中任一关键条件的事项进入待澄清区，不计入承诺工作；中途变更必须注明提出方、原因、影响范围和替代事项。”

为了避免流程变成形式，团队只对涉及客户验收或跨系统联调的事项执行完整检查，低风险内部优化采用简化记录。负责人不是抽象的“项目组”，而是具体到需求负责人；复查人是迭代主持人。这样既明确责任，也保留对不同风险事项的弹性。

4. 情景数据如何解释：结果改善不等于因果已经证实

团队观察到，进入迭代前条件完整率从情景基线的 64% 提升到 88%，因条件缺失导致的退回事项从每轮 7 项降到 3 项，迭代中途验收条件变更从 9 次降到 5 次。与此同时，计划工作完成率从 72% 上升到 81%。这些数值是案例推演，用来展示复盘指标之间的关系，不是公开研究数据或通用目标值。

我不会据此直接宣布“流程改进让完成率提升了 9 个百分点”。同一时期，团队也减少了一个上线保障任务，且该轮客户环境较稳定。更稳妥的结论是：前置条件检查执行率提升，相关退回有所减少，方向值得继续观察；还需要后续迭代验证，并记录外部条件变化。

如果验收退回没有下降，但条件完整率明显提高，团队也不应立即否定动作。可能是退回原因本来就不在条件缺失，或检查表项目过于形式化。此时应重新拆分退回类型，而不是为了维持改进方案而挑选有利数据。

5. 为什么没有先增加测试人手：先拆瓶颈，再决定投入

增加测试资源不是错误选择，但应在确认瓶颈确实位于测试处理能力之后再做。如果测试队列持续增长、测试处理时间明显长于开发交付节奏、且等待不是由环境或需求不清造成，增加测试容量或调整测试自动化投入才有依据。

反过来，如果大量任务是临近迭代结束才进入测试，新增测试人员也可能只是把等待从一个队列转移到另一个队列。团队在案例中先改进输入条件和提测节奏，再观察测试排队时间，避免用增加人力掩盖需求准备不足。

六、不同情况下的行动建议：按团队成熟度与交付压力选择做法

1. 团队刚开始做迭代管理：先统一口径，不急着追求复杂指标

如果团队此前主要靠群消息和个人清单协作，第一阶段不必马上建立完整度量体系。先统一事项状态、完成定义和插入工作记录，再连续观察两到三轮。每轮只选一个问题做复盘，避免数据尚不稳定时制定太多规则。

这个阶段最需要的是可见性：谁在做什么、任务卡在哪里、何时发生变更、当前承诺是否仍成立。工具可以从共享看板开始，待字段和流程跑顺后再决定是否迁移到更完整的平台。

2. 多项目并行、超过百人协作：把共同规则与项目差异分开

百人以上组织的主要难点，通常不是没有任务，而是不同项目对状态、优先级、权限和汇报口径的理解不同。建议建立组织级最小规则，例如需求状态、缺陷等级、迭代承诺定义和风险升级路径，同时允许各业务线保留必要的项目字段与审批差异。

在这个规模下，工具选型要关注权限模型、跨项目视图、审计记录、数据迁移、部署方式、接口能力和规模化管理成本。PingCode可作为中大型企业评估的项目管理平台之一，尤其适合需要覆盖需求到交付流程、支持私有化部署或考虑从 Jira 平滑迁移的组织。它是否适合具体团队，应通过真实项目试点验证工作流映射、历史数据完整性、权限配置和用户培训成本，不能只依据功能清单判断。

所谓国产替代，不应只比较功能名称，还要比较迁移风险、内部运维能力、数据治理要求、集成生态和长期总拥有成本。若原系统中的自定义字段、自动化规则或插件很多，迁移前应做分层盘点：哪些必须保留，哪些可简化，哪些应趁迁移机会清理。完整复刻旧流程未必是成功，保留不必要复杂度会把历史问题一并迁走。

3. 客户需求频繁变化：用容量缓冲和变更规则保护承诺

对于现场变化频繁的项目，不宜把全部可用容量都排满。团队可以依据过去几轮临时工作的占比，设置一个可调整的缓冲区，再约定插入工作的等级、决策人和替代项。缓冲比例不是行业标准，应由自己的历史数据校准。

若出现高优先级插单，团队应同时更新被替换工作的交付影响，而不是默默加班维持原承诺。客户和内部管理者需要看到取舍：插入一项工作，意味着延后什么、增加什么风险、由谁确认。

4. 线上风险高或验收严格：把复盘与质量门禁连接起来

金融、制造、医疗及关键基础设施等高风险场景，应把重大缺陷、数据变更、权限调整、回退演练和验收证据纳入复盘。这里的重点不是让所有任务都走最重流程，而是根据影响等级配置不同的检查强度。

重大故障复盘与普通迭代复盘可以共享时间线和改进跟踪方式，但议题不能混为一谈。事故复盘要关注影响范围、发现与响应时间、恢复过程和防复发措施；迭代复盘则关注周期性的交付流程与团队协作。若一次事故涉及多部门，需要明确跨团队行动负责人和升级机制。

5. 远程或分布式团队：把异步准备做扎实

远程协作不一定需要更长的视频会议。会前异步提交观察、在线标注任务记录、提前确认议题，可以让会议集中处理分歧和决策。对跨时区团队，主持人应明确书面结论、决策窗口和未解决问题的跟进人，避免复盘只对同步参会者有效。

异步讨论也要避免堆积长篇意见而无人归纳。主持人应将留言整理为事实、假设、决策和行动四类，并在会议结束后确认哪些观点仍存在分歧。重要改进项须在任务系统中可追踪，而不是只留在聊天记录中。

七、不同情况下的取舍：速度、透明度与控制强度如何平衡

1. 复盘频率：每轮复盘还是周期性主题复盘

每轮都做完整复盘，反馈快，但会增加会议负担；按月或按阶段做主题复盘，成本较低，却可能错过问题刚出现时的证据。团队可以采用轻重结合：每轮用十五至三十分钟快速检查指标和行动，连续三至四轮再做一次深入主题分析。

如果团队正处在流程转型、频繁上线或重大交付阶段，短周期反馈更有价值。运行稳定的团队则可降低会议频率，但仍需保留关键事件复盘和改进项追踪。

2. 指标数量：指标越多，不代表管理越精细

太少的指标可能只看到结果，太多的指标又会造成录入负担和指标驱动行为。建议每轮围绕一个主题选三到五项观察：一项结果指标、两项过程指标，以及必要的风险或质量指标。指标数量应服务于当前判断，而不是为了仪表盘看起来完整。

例如，处理“测试介入太晚”时，可观察开发完成到进入测试的等待时间、提测时验收条件完整率、测试发现问题的分布和最终退回数。若主题是客户决策等待，则不应把缺陷数当作核心结果。

3. 标准化程度：统一底线，不强求所有项目一模一样

组织需要统一数据定义与最低交付要求，否则跨项目比较没有意义；但客户环境、交付方式和风险等级不同，流程细节不能一刀切。对低风险事项，可以允许简化审批；对高风险上线，应要求明确的验收证据与回退计划。

标准化的目标是让关键状态可理解、风险可升级、数据能横向解释，而不是让每个团队填同一份冗长表单。若团队大量时间用于维护流程而非交付，说明控制强度可能超过实际风险。

4. 工具投入：先修复流程，再决定是否需要平台化

小团队、低并行度、简单权限条件下，轻量看板可能足够；当项目数量、角色、审批、审计或数据隔离要求上升，工具整合的收益才更明显。平台选择应评估软件成本之外的配置、迁移、培训、集成和运维成本。

如果正在评估 PingCode 或其他项目管理平台，建议用一个真实业务流程做试点，覆盖需求变更、缺陷流转、跨项目视图、权限隔离和历史数据导入。不要只演示理想路径，还要测试退回、取消、插单、角色变更和跨项目依赖等异常场景。平滑迁移的判定标准应包括关键数据可追溯、重要规则有明确映射、用户能完成实际工作，以及迁移后报表口径可解释。

5. 透明度与安全感：公开流程数据，不公开羞辱性排名

团队需要看见工作流和交付风险，但公开个人排名往往损害心理安全，诱发挑任务和隐藏问题。复盘首先服务于改进系统，不是给成员做绩效审判。若组织确实需要个人绩效评价，应与团队复盘分开设置目标、证据和讨论机制。

管理者要特别注意：成员提出阻塞，不等于成员制造问题；提出坏消息的人，也不应因此承担额外惩罚。只有在风险能够被及时暴露时，复盘数据才有决策价值。

八、落地检查清单：从下一轮迭代开始怎么做

1. 迭代开始前：定义口径与工作入口

在迭代启动前，明确什么事项可以进入承诺范围、什么状态代表完成、紧急插入由谁确认。对重要客户交付，提前检查验收条件、测试数据、环境和外部依赖。若条件不足，记录风险并决定是否接受，而不是默认所有未确认事项都能按期完成。

• 明确本轮目标及不纳入范围的事项。
• 统一“完成”“验收通过”“上线完成”的定义。
• 记录团队可用容量与预留的应急空间。
• 对跨角色依赖标注提供方、承诺时间和升级路径。
• 约定中途变更如何记录、谁有权调整优先级。

2. 迭代执行中：让偏差尽早可见

执行阶段不必等到复盘才发现问题。每日或每周检查阻塞时间、在制品和即将到期的外部依赖；当任务发生范围变化时，更新承诺影响。主持人要关注工作是否长期停在同一状态，而不是只看看板上绿色状态的比例。

• 阻塞超过约定时长时，记录原因并升级，不让状态长期停留在“进行中”。
• 插入工作时同步标明替代事项，避免隐性扩容承诺。
• 测试和实施人员尽早参与高风险需求的验收条件确认。
• 对无法按计划推进的事项及时重新估算，不以沉默维持虚假承诺。

3. 迭代结束后：用数据挑问题，用行动验证结果

结束时先核对数据完整性，再讨论原因。会议纪要应记录事实、判断及尚未确认的假设，并为每个改进项写明负责人、截止时间和复查方式。改进项逾期时，不要只把它移到下一轮；要判断是优先级不足、负责人无权限、措施过重，还是问题判断本身错误。

• 对照计划与实际，说明差异由哪些工作类型造成。
• 拆分处理时间、等待时间和返工时间。
• 按客户影响、质量风险和重复频率排序议题。
• 每轮选取少量行动，明确过程指标与结果指标。
• 下一轮开始时复查行动执行情况，结束时判断是否继续、调整或停止。

4. 需要升级的问题：区分团队能改与组织必须改

有些改进需要跨部门决策，例如客户承诺机制、共享测试环境、产品答疑响应时间或多项目资源冲突。团队可以先改善自身的信息准备和升级时效，但若瓶颈不在团队控制范围内，就应形成简洁的升级材料：事实、影响、已尝试措施、需要的决策和最晚决策时间。

这类问题若长期只在团队内部反复讨论，复盘会逐渐失去可信度。管理者需要对跨团队行动设置负责人和回看日期，不能只要求一线“加强协同”。

九、总结：真正落地的复盘，改变的是下一轮的工作方式

1. 不要把复盘做成找答案，而要做成持续验证

实施团队很容易被“赶紧交付”的压力推着走，于是把复盘当作事后总结，或者在会议上迅速找到一个听起来合理的原因。我的判断是，复盘不必每次都得出确定答案，但必须让团队更清楚哪些事实已知、哪些原因仍是假设、下一步要怎样验证。

当团队能区分处理与等待、计划与插入、开发完成与客户验收，复盘就开始从主观争论转向工作流管理。再通过少量、可控、可验证的改进行动，团队才有机会逐轮降低交付波动。

2. 下一步：从最近一轮迭代选一个问题，做一个小闭环

你可以从最近一轮迭代开始，不必先换工具，也不必先设计完整制度。选一个对客户或交付影响明显的问题，抽查一小批任务的时间线，找出等待或返工发生在哪个节点，再提出一项下一轮能验证的动作。

两轮之后，检查动作是否执行、相关指标是否变化、是否存在其他解释。若效果不明显，就修正假设；若有效，再决定是否扩大到其他项目。迭代复盘的价值不在于证明团队曾经反思过，而在于让下一轮少重复一次已经看见的问题。