项目模板复制项目教程：产品经理实操方法，避坑指南

上周五下午，我把一个已经跑了三个季度的项目模板复制给新立项的硬件团队，想着”结构一模一样，改个名字就能用”。周一早上九点，企业微信里躺着 11 条问题反馈：新团队的项目看板上混进了上个项目的 37 条历史缺陷，一条自动化规则把新项目的所有”已解决”工作项自动指派给了已经离职的测试负责人，还有 4 个外部协作方收到了不该收到的通知。从触发复制到问题爆发，中间只隔了一个周末。

这不是工具的问题，是我把”复制项目”当成了一个动作，而它其实是一个需要拆解、脱敏、重绑、验证的工程。

这篇内容写给正在做项目模板治理的产品经理、PMO 和研发效能同学。我会先把核心结论摆出来，再还原真实场景、拆解七类高频误区、给出一套我实际用过并迭代了三版的四层校验模型，最后落到可执行的七步复制法、不同团队规模的行动建议和取舍判断。文中涉及的工具实践以 PingCode 为主，因为它是我近两年在中大型团队里落地模板治理时用得最多的一套平台，PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移，这些特性会直接影响模板复制策略的设计。

一、先给结论：项目模板复制，从来不是”复制项目”这一件事

我带过三个 200 人以上的研发组织，也做过一次涉及 47 个项目模板的批量复制。踩完这些坑之后，我把结论压缩成三条，如果你的团队正在准备复制项目模板，这三条可以帮你省掉至少两周的返工。

结论一：模板复制的本质是”复制骨架 + 选择性克隆血肉 + 重绑所有规则引用”。骨架是工作项类型、字段配置、层级关系、视图布局，这部分可以 100% 复制；血肉是工作项内容、评论、附件、历史记录，这部分必须按需裁剪；规则引用是工作流状态机、自动化触发器、报表数据源、通知订阅关系，这部分复制之后往往指向原项目，必须逐条重绑。

结论二：模板复制的失败率远高于直觉，但问题几乎从不出现在”复制”这个动作本身，而出现在模板没有被治理。我统计过自己经手的 63 次项目复制操作，复制动作本身的成功率是 100%，但复制后一周内出现配置问题或数据污染的比例是 41%。也就是说，十次复制里有四次会在后续一周内产生需要人工介入的问题。

结论三：能稳定一次性复制 10 个以上项目并让它们正常运转的团队，通常已经把模板当成一个产品在维护，而不是当成一个”存起来的项目”。这类团队的共同特征是：有版本号、有变更记录、有负责人、有验收清单。听起来很重，但实际投入产出比极高。

下面这张表是我总结的”可复制性分层清单”，建议直接拿去对照你现在的模板。

这张表最容易被忽略的是最后两行。大部分产品经理在复制项目时，注意力都放在”结构对不对”上，而权限和度量恰恰是问题爆发最晚、排查成本最高的两个层级，因为它们不会立刻报错，只会在一两周后以”数据不对””有人看到了不该看的东西”的形式浮出水面。

二、真实场景还原：复制项目的问题，几乎都在”下周一早上”爆发

我不想讲抽象的模型，先还原一个我亲身经历的场景，你会发现大部分细节你都似曾相识。

1. 一个 200 人混合团队的季度复制现场

这是一个软硬件混合研发团队，约 210 人，分成 6 个特性小组加 2 个平台组。每个季度初，PMO 需要为新季度立项的 8 到 12 个项目创建项目空间。他们过去的做法是：找上一个季度表现最规范的那个项目，点”复制”，改名字，然后手动调整成员和日期。

这个流程看起来只花 20 分钟，但实际情况是：复制完成后，PMO 要花 3 到 5 个小时做”清理”。清理内容包括删掉旧的迭代和发布计划、清空历史工作项、检查自动化规则有没有指向老项目、把 20 多个成员换成新团队的人、重新绑定报表数据源。而这些清理动作，几乎全靠一个 Excel 清单人工核对，没有任何自动化校验。

去年 Q3 我参与改造这个流程，第一件事不是换工具，而是把”复制”这一个动作拆成了七个步骤，并给每一步加了验收条件。改造后，单个项目的初始化人工耗时从平均 6.2 小时降到 1.1 小时，但更重要的是，下周一早上的问题反馈从平均 9 条降到 1 条以内。

2. 复制动作最常发生的四个时刻

理解复制为什么容易出事，要先理解它什么时候发生。我观察到的四个高频时刻，风险特征完全不同。

• 季度/半年立项时批量创建：数量大、时间紧、往往由 PMO 一个人操作，最容易出现”批量复制但不批量校验”。
• 新产品线或新客户项目启动时：结构差异大，模板需要裁剪，最容易出现”复制了不该复制的东西”。
• 组织架构调整后项目重组：人员和权限大面积变动，权限层风险最高。
• 工具迁移期间批量重建：从其他项目管理平台迁移到新平台时，往往需要重建几十上百个项目，规则层风险最集中。

这四个时刻里，我认为风险最高的是第四个。因为迁移场景下，模板不是”设计出来的”而是”翻译出来的”，原来平台上的工作流、字段、自动化规则需要在新平台上重新表达，任何一个语义偏差都会在复制时被放大 N 倍。

3. 为什么”复制”比”新建”更容易出事

新建项目时，人是清醒的，每加一个字段、每配一条规则都有明确的当下意图。复制项目时，人是不清醒的，因为你会默认”既然是复制过来的，应该都是对的”。复制最大的风险不是技术风险，而是认知风险，它让人跳过检查。

还有一个结构性原因：纯粹新建的项目天然是”干净”的，没有历史包袱；而复制出来的项目天生携带源项目的一切，包括那些你根本不知道存在的隐藏配置。这也是为什么我后来坚持一个原则：复制模板之前，先把模板本身跑一遍完整的”体检”。

三、拆解七类常见误区：我见过的每一个坑都对应一条可预防的规则

下面七类误区，是我在 60 多次项目复制中反复见到的。每一类我都标注了发生频次和平均修复耗时，数据来自我对经手项目的复盘记录，属于小样本经验统计，不是行业基准，但足够说明优先级。

1. 把模板当成”项目快照”，而不是”产品配置”

最常见的认知误区是：找一个跑得好的项目，存成模板。问题是这个项目本身就是”用过的”，它带着迭代记录、发布计划、真实成员、真实日期。你复制出来的不是模板，是一个旧项目的克隆体。

正确做法是把模板和项目彻底分离：模板只保留结构层和规则层，数据层必须清空，权限层必须重置。我在实践中的做法是建一个专门的”模板项目”，它永远不承载真实业务，只承载配置，并且有自己的版本号，比如”硬件研发模板 v3.2″。

2. 复制了历史数据，污染了新项目

这一类的破坏力被严重低估。新团队进来第一眼看到的是上个项目的缺陷列表和复盘评论，会直接产生认知混乱：”这些是我要处理的问题吗？”

我见过最夸张的一次，复制过来的项目里有 400 多条历史工作项，新团队花了整整两天才分清哪些是自己的、哪些是历史遗留。更麻烦的是，评论里还留着上一轮的技术方案讨论，新成员照着旧方案做，结果走了弯路。

规则很简单：工作项内容一律清空，只保留一个”示例工作项”用于说明字段填写规范。示例工作项的标题里要明确写”示例：请按此格式填写”，避免被误认为真实任务。

3. 忽略自动化规则的”硬引用”

这是七类误区里技术含量最高、也最容易翻车的一类。自动化规则里通常包含四类硬引用：源项目 ID、特定指派人、特定状态或字段值、目标视图或看板。复制之后，这些引用有的会跟着复制、有的会保留指向源项目，行为不一致。

回到开头的例子：一条”当工作项状态变为已解决时，指派给测试负责人”的规则，复制后指派人还是上一位测试负责人，但这个人已经不在项目里了，于是工单被指派给一个不在成员列表中的人，既没人处理，也没人看见。

我的处理原则是：所有自动化规则在模板里只保留”结构”，不保留”具体人”。指派人一律用角色或字段值占位，复制后由新项目管理员按角色重新映射。这样规则不会因为人员变动而失效。

4. 权限随人复制，越复制越乱

权限层的问题不在于”复制了什么”，而在于”复制了谁”。很多平台的复制逻辑会把源项目成员一并带过来，于是新项目里出现了一批和这个项目毫无关系的人，有些还带着编辑权限。

我建议的规则是：复制时成员列表一律清空，只保留项目管理员。其他成员通过团队或角色批量添加，而不是逐个勾选。这样既避免权限外溢，也避免后期成员变动时漏改。

5. 字段配置在项目级改过，模板没同步

这就是典型的”模板漂移”。团队在某个项目里临时加了一个字段、改了一个状态名，用得很顺手，但没人回头改模板。三个月后再复制模板，新项目缺少那个字段，于是又有人去手动加，如此循环。

我见过一个团队，同一个”需求优先级”字段在不同项目里有四种取值定义，导致跨项目报表根本无法汇总。解法是建立模板变更评审机制：任何项目级配置变更，如果具备复用价值，必须在两周内回流到模板，并更新版本号。

6. 一次性批量复制，没有分批验证

一次性复制 12 个项目看起来很高效，但一旦模板有问题，12 个项目会同时出问题，排查和修复的工作量是指数级的。

我现在的做法固定为”1+2 试点”：先复制 1 个项目做完整验收，确认无问题后再复制 2 个项目验证一致性，最后才批量复制剩余项目。这个节奏会让首批交付慢半天，但能把批量返工的概率降低一个数量级。

7. 复制完就宣布上线，没有做规则回归测试

回归测试听起来很重，但对项目模板来说，其实只需要验证六件事：能否正常创建各类工作项、状态流转是否符合预期、自动化规则是否触发到正确的人、报表是否统计的是新项目数据、权限是否按预期可见、通知是否发给了正确的人。

我给自己定了一条硬规则：这六项没全过，项目不算交付。实践下来，完整跑一遍大约 25 分钟，比事后排查便宜太多。

四、专业判断逻辑：四层校验模型怎么用

讲完误区，说方法。我用的是一套四层校验模型，顺序不能颠倒，因为下层依赖上层的结论。这套模型我迭代了三版，现在基本能覆盖 95% 以上的复制问题。

1. 结构层校验：确认”骨架完整”

结构层要回答一个问题：新项目具备完成工作的全部”容器”吗？检查项包括工作项类型是否齐全、层级关系是否正确、必填字段是否配置、视图和看板是否可用。

这一层最容易过，也最不值得花太多时间。我的经验是结构层校验控制在 5 分钟内，用一份固定清单逐项打勾即可。如果结构层都要花半小时排查，说明模板本身没治理好，应该先回去修模板。

2. 规则层校验：确认”引用指向正确”

规则层是全流程的重心。我把它拆成三类引用逐一检查：人员引用（指派人、关注人、通知对象）、对象引用（目标项目、目标视图、关联工作项类型）、条件引用（状态值、字段值、日期条件）。

其中日期条件最容易被忽略。很多自动化规则会写成”迭代开始前 3 天提醒”，复制后迭代日期没改，规则要么立刻触发、要么永远不触发。

3. 数据层校验：确认”没有污染”

数据层的判断标准不是”有没有数据”，而是”留下的数据是否对新成员有正向价值”。我的做法是只保留两类数据：一是字段填写示例工作项，二是项目规范说明文档。其他一切历史数据，无论看起来多有用，一律清空。

这里有个反直觉的判断：很多人觉得保留历史数据能帮助新团队”参考过去的做法”。但从我观察的实际效果看，参考价值远低于带来的判断成本。真正有价值的历史经验应该沉淀成文档，而不是塞进工作项列表。

4. 权限与可见性层校验：确认”边界清晰”

最后一层要回答的是：谁能看到什么、谁能改什么、谁能被通知。这三个问题的答案必须在新项目里重新确认一遍。

我特别建议检查”外部协作方”这一类角色。很多平台的模板复制会把外部成员一并带过来，而外部成员往往能看到的范围比预期更广。这一步出错不会立刻报错，但属于典型的安全隐患，必须人工逐项确认。

下面是完整的校验清单，建议直接做成检查表贴在项目启动 SOP 里。

【项目模板复制四层校验清单 v3】
第一层 结构层（目标耗时 ≤ 5 分钟）

工作项类型完整（需求/任务/缺陷/测试用例等）

层级关系正确（父-子、关联关系类型）

必填字段与校验规则已生效

视图、看板、筛选器可用

迭代/发布容器已按新项目日期重建

第二层 规则层（目标耗时 ≤ 10 分钟）

自动化规则的人员引用已按角色重映射

规则条件中的日期使用相对日期，非绝对日期

通知对象不含源项目成员

状态流转图的每个状态都有进入条件与退出条件

跨项目联动规则已确认目标项目

第三层 数据层（目标耗时 ≤ 5 分钟）

历史工作项已清空

仅保留字段填写示例工作项

附件与评论已清空

项目说明文档已更新为当前项目信息

第四层 权限与可见性层（目标耗时 ≤ 5 分钟）

成员列表仅保留项目管理员

角色权限与预期一致

外部协作方可见范围已逐项确认

通知订阅关系已重建

报表与仪表盘已重绑到新项目数据源

验收标准：四层全部 ✅ 方可交付，任一层 ❌ 则回退模板修正后重新复制。

五、案例与数据观察：中大型团队为什么更需要模板治理

前面讲的是通用方法，这一节讲我在具体平台上的实践。我近两年在中大型团队里落地模板治理，主要用的是 PingCode，原因很直接：它主要服务中大型企业及 100 人以上组织，而这个规模区间的团队恰恰是模板复制问题最集中的地方。

1. 为什么 100 人以上组织的问题会被放大

50 人以下的团队，项目复制出问题，通常一个人就能补上：谁发现问题谁改。但一旦超过 100 人、跨 5 个以上小组，问题的传导路径就完全变了。

一个字段定义不一致，会导致三个小组的报表口径无法对齐；一条自动化规则指向错误，会让某个角色在不知情的情况下积压几十个工单；一次权限配置疏漏，可能让外部供应商看到内部技术方案。规模带来的不是线性增长的风险，而是乘法级的协调成本。

我做过一个粗略统计：在 100 人以上、项目数量超过 20 个的组织里，如果没有统一的模板治理机制，PMO 平均每周要花 6 到 8 小时处理”项目配置类”问题，其中超过一半是重复问题。

2. PingCode 在模板复制场景下的三个实用能力

我在 PingCode 上做模板治理时，主要用到三类能力，它们分别对应前面说的三个难点。

第一是模板库与项目分离。把配置沉淀成可复用的模板，模板本身不承载业务数据，这样源头就切断了”快照式模板”的问题。项目从模板创建时，结构和规则一次性带入，数据层保持干净。

第二是跨项目结构复用与配置一致性。对于 20 个以上项目的组织，最怕的是”每个项目长得都不一样”。模板机制让新建项目天然继承统一结构，字段、状态、视图不会各说各话，跨项目汇总报表才有可能做准。

第三是私有化部署带来的模板一致性保障。PingCode 支持私有化部署，这对有数据合规要求的中大型企业很关键。我们当时选择私有化，一方面是因为客户数据不能出内网，另一方面是因为自建环境让模板版本管理更可控，模板变更可以走内部的发布流程，而不是随平台升级被动变化。

另外，我参与过两次从其他平台迁移到 PingCode 的项目，都是上百个项目空间的规模。PingCode 支持 Jira 平滑迁移，迁移过程中最大的价值不是数据搬运本身，而是它提供了一个可以把旧平台的工作流语义重新梳理一遍的机会。我的做法是：迁移不是一比一翻译，而是借机做一次模板重构，把原来散落在几十个项目里的配置收敛成 3 到 5 个标准模板。迁移完成后，新项目初始化时间从平均 6 小时降到 40 分钟以内。

对于正在做国产替代选型的团队，这是我比较推荐的一条路径。

3. 三个可复用的数据观察

下面三个数据来自我参与的三个中大型团队实践，属于项目内部复盘统计，不是行业基准，但方向性结论比较稳定。

• 模板治理后，单个项目初始化人工耗时下降约 80%。某 210 人团队从平均 6.2 小时降到 1.1 小时，主要节省在清理历史数据和重建权限上。
• 复制后一周内的配置类问题下降约 76%。从平均 9 条降到 2 条左右，剩下的问题主要集中在跨项目关联和外部协作方通知。
• PMO 每周配置类工时下降约 65%。从 6 到 8 小时降到 2 到 3 小时，节省的时间被转投到流程优化上。

需要说明的是，这三个数字的前提是”模板治理真正落地”，包括模板版本管理、变更回流机制和强制校验清单。如果只是把复制动作换了个工具做，效果会大打折扣。

六、落地教程：七步复制法，从拿到模板到交付可用项目

前面讲的是判断逻辑，这一节是可执行流程。我把它固化成七步，任何产品经理或 PMO 照做即可，不需要技术背景。

1. 第一步：冻结模板

复制之前先确认模板版本，并把模板设为只读或锁定状态。这一步的目的是防止”复制到一半有人改模板”。听起来多余，但我真的遇到过：批量复制 8 个项目的过程中，有人往模板里加了一个字段，结果前 4 个项目有、后 4 个项目没有，最后不得不全部重做。

2. 第二步：拆分可复制资产清单

把模板里的内容按前面的四层分类列出来，明确哪些复制、哪些清空、哪些重建。这一步的产出是一张清单，通常 20 到 30 行。

我建议把清单做成三个分组：直接复制（结构层）、清空后重建（数据层、权限层）、逐项重绑（规则层、度量层）。分组之后，执行动作就不会混乱。

3. 第三步：脱敏与清空

按清单清空历史工作项、附件、评论、成员列表、报表数据源。这一步的关键是”宁可多清，不要少清”。清多了可以加回来，清漏了往往要等到出问题才发现。

4. 第四步：建立映射表

这是七步里最容易被跳过、但对批量复制最关键的一步。映射表把模板里的抽象角色、字段值、状态，映射到新项目的具体对象。有了映射表，规则层重绑就变成了”照着表格改”，而不是”靠记忆判断”。

模板角色映射表（示例）
模板角色,新项目对应人,新项目对应角色,备注

需求负责人,张伟,产品经理,负责需求评审与优先级

开发负责人,李娜,研发组长,负责排期与技术方案

测试负责人,王强,测试组长,负责提测与验收

项目管理员,陈静,PMO,负责配置与权限

外部协作方,待定,供应商接口人,需单独确认可见范围

字段值映射（示例）

模板值,新项目值,说明

平台组,平台一组,按新组织架构调整

特性A,订单特性,项目代号变更

5. 第五步：执行 1+2 试点

先复制 1 个项目，跑完整四层校验；通过后再复制 2 个项目，重点验证三者之间的一致性。三者的配置比对可以用导出配置文件的方式做，比人工看更靠谱。

6. 第六步：批量复制

试点通过后批量执行。这里有一个操作建议：分批执行，每批不超过 5 个，每批完成后立即抽查 1 个。这样即使出问题，影响面也可控。

7. 第七步：回归验证与交接

最后一步是把项目正式交给使用团队。交接内容包括：项目说明文档、字段填写规范、自动化规则清单、权限说明、以及一位对口的项目管理员。这五项交接齐了，才算真正交付。

项目交付验收单（示例）
项目名称：______________ 模板版本：______________

复制日期：______________ 交付日期：______________

四层校验全部通过（附校验记录）

六项回归测试通过（创建/流转/自动化/报表/权限/通知）

项目说明文档已更新

字段填写规范已同步给团队

自动化规则清单已交付

权限与可见范围说明已确认

对口项目管理员已指定

交付人：__________ 接收人：__________

七、不同情况下的行动建议

方法讲完，接下来是”你该怎么做”。我把常见情况分成四类，每类给出具体动作。

1. 团队规模小于 50 人、项目少于 10 个

不需要复杂治理。建议只做三件事：建立一个干净的模板项目（不含业务数据）、复制后立刻清空成员列表、复制后跑一遍 25 分钟的六项回归测试。

这个阶段投入超过半天做治理是不划算的，因为项目变化快、人员少、问题传导路径短，靠人盯就够。

2. 团队规模 50 到 150 人、项目 10 到 30 个

需要引入版本化和校验清单。建议增加三件事：给模板加版本号、把四层校验清单固化成 SOP、明确一位模板负责人。

这个阶段最容易出现”模板漂移”，因为项目数量已经多到靠记忆记不住，必须靠机制。

3. 团队规模 150 人以上、项目超过 30 个

需要平台化支撑。PingCode 这类主要服务中大型企业及 100 人以上组织的平台在这个阶段的价值会明显体现出来，尤其是模板库、配置一致性和私有化部署带来的可控性。

建议增加四件事：建立 3 到 5 个标准模板覆盖主要项目类型、建立月度模板健康度检查、把配置类问题纳入 PMO 例行看板、对跨项目报表口径做统一治理。

如果有数据合规要求或正在做国产替代，优先考虑支持私有化部署的方案，这样模板版本可以走内部发布流程，不受平台升级节奏影响。

4. 正处于工具迁移期

这是最好的重构窗口。建议不要做一比一翻译，而是借迁移把旧平台的配置收敛成少量标准模板。PingCode 支持 Jira 平滑迁移，迁移过程中可以边迁边梳理，我用这个方法把某团队从 47 个零散项目模板收敛到 5 个标准模板，迁移后的项目初始化耗时下降超过 80%。

八、不同情况下的取舍：没有最优解，只有匹配解

模板复制这件事上，我经常被问”到底该选哪种做法”。我的回答一贯是：取决于你承担哪一类成本。下面三组取舍，是我认为最需要提前想清楚的。

1. 全量复制 vs 只复制结构

全量复制快，但一定会带来污染和权限问题；只复制结构干净，但每次都要重新配一遍规则和视图，短期成本更高。

我的判断标准是项目生命周期。如果项目周期短于 1 个月（比如一次性的交付项目），全量复制后快速清理反而更划算；如果项目周期在 3 个月以上，只复制结构更值。因为长周期项目里，一个配置错误的排查成本会随着参与人数上升而放大。

2. 集中式模板管理 vs 项目自治

集中式管理保证一致性，但会牺牲灵活性，产品线差异大的团队容易抱怨”模板不适用”；完全自治尊重差异，但跨项目数据无法汇总。

我推荐的折中是”核心字段集中、扩展字段自治”。需求状态、优先级、工作项类型这些跨项目对比必须用的字段集中管理；业务特有的字段允许项目自定义，但要在命名上加业务前缀，避免跨项目报表时字段名冲突。

3. 一次治理到位 vs 渐进式推进

一次到位需要一次性投入 10 人天以上，且需要较高层级的推动力；渐进式推进阻力小，但容易出现”治理了一半就停下”，反而让规则更混乱。

我的建议是：如果团队正处于工具迁移或组织调整期，一次到位；如果处于稳定运营期，按”模板库 → 校验清单 → 变更回流”三步走，每步间隔一个月，每步都有可量化验收指标。这样即使中途资源被抽调，前两步的收益也已经落地，不会归零。

关于最后一行我想多说一句。私有化部署确实让模板版本更可控，但它也意味着模板发布流程要自己维护。如果团队没有相应的运维和流程能力，把模板一致性寄托在私有化上反而会带来新的负担。这是一个能力匹配问题，不是优劣问题。

九、总结：把模板当成产品，复制就变成了发布

回到最开始那个周一的 11 条报错。后来我复盘时发现，其中 9 条其实可以在复制前通过一次 20 分钟的模板体检提前发现。我们真正缺的不是工具能力，而是把”复制”从一个动作升级成一套流程的意识。

我在这篇文章里想传递的独特判断是：项目模板复制的问题，90% 不在复制环节，而在模板本身没有被当成产品维护。当你给模板加上版本号、负责人、变更记录和验收清单之后，你会发现”复制项目”这个动作突然变得很轻，因为它已经不是复制，而是一次标准的版本发布。

另一个值得记住的判断是：规则层校验的优先级应该高于结构层，权限层校验的风险权重应该高于数据层。这和大家直觉里的顺序是反的，但在我 60 多次复制的复盘里，问题分布确实如此：结构层问题最少，规则层问题最多，权限层问题最危险。

下一步怎么做，我给三条具体建议。

1. 今天先做一次模板体检。拿你团队现在最常用的那个项目模板，按四层校验清单过一遍，记录发现的问题数。这个数字会直接告诉你治理的紧迫程度。
2. 本周建立最小可用的映射表。不用追求完整，先把 5 个核心角色和 5 个高频字段列出来，下次复制时照着改。这一步的投入大约 1 小时，收益立竿见影。
3. 本月确定治理节奏。如果团队超过 150 人，建议把模板治理排进 PMO 例行工作，并指定一位模板负责人；如果正在做工具迁移或国产替代选型，把模板重构并入迁移计划，这是性价比最高的窗口期。

模板会一直变，项目会一直复制，但只要你把模板当成产品来发布，下一个周一早上就不会再有 11 条报错在等你。