模板阶段最佳实践：跨部门团队项目模板入门指南，常见问题

我在过去三年里跟踪过 40 多个跨部门项目模板的落地过程，从 60 人的创业团队到 3000 人规模的制造业集团都有。一个反复出现的数字是：跨部门项目模板上线第一个月的遵循率通常在 80%，95%，第三个月掉到 40%，55%，第六个月还能坚持按模板走的项目不到 20%。很多团队把这件事归因为”执行力不行”，但真正的问题几乎都埋在模板阶段本身，模板设计的时候就没有回答”谁在什么条件下把什么交给谁”这个问题。

这篇文章不讲模板的定义，也不讲”模板很重要”这类正确的废话。我想讲的是：模板阶段到底应该产出什么、哪些设计会在三个月后必然失效、在中大型组织里一套跨部门模板要长成什么样才能活得久，以及当你准备把它落到工具里时，会遇到哪些具体的坑。

文章里的数据来自三类来源：我自己参与的落地项目回访记录（2023，2025 年，样本约 40 个跨部门项目）、与 PMO 和研发效能负责人的访谈，以及公开的行业调研结论。凡是模拟推演的数据，我都会明确标注。

一、核心结论：跨部门项目模板的第一产出不是模板

如果你只想记住一句话，那就是：跨部门项目模板阶段真正要交付的，是一份被工具固化的协作契约，而不是一套好看的任务结构。任务结构是结果，契约才是资产。这两者的区别决定了模板能不能活过第三个月。

1. 契约的三要素：交接物、验收标准、责任主体

我在回访时问过一个很直接的问题：”如果不用工具里的模板，你们的跨部门项目会怎样？”回答大致分两类。一类是”会乱，因为不知道对方交付什么、什么时候交”，这类团队说明模板确实固化了契约。另一类是”其实也还好，就是记录分散一点”，这类团队的模板基本上只是个记录壳子。

差别就在三件事上：每个跨部门节点有没有明确交接物（一份图纸、一个接口文档、一份测试报告）、有没有明确的验收标准（什么状态算通过）、有没有明确的责任主体（谁签字、谁兜底）。这三件事写进去了，模板就有骨架；没写进去，模板再漂亮也是空壳。

2. 模板复杂度上限由”最低填写意愿”决定，不是由流程完整性决定

这是我最想强调的一条反常识判断。模板的复杂度不是由流程需要多少信息决定的，而是由参与协作的团队里填写意愿最低的那一方决定的。一个跨部门项目涉及五个团队，只要其中一个团队的成员觉得”这个字段跟我没关系”，整个模板的填写质量就会被拉下来。

我见过一个典型的案例：某公司的跨部门项目模板设计了 26 个必填字段，覆盖了硬件、固件、测试、供应链、质量五个专业视角。上线后第三个月，实际填写完整度只有 38%，而供应链团队贡献了大部分的空值，因为那些字段的问题他们确实答不上来。模板不是不完整，是超出了填写者的能力边界。

3. 模板必须版本化，否则它会在半年内变成”历史文件”

模板不迭代就必然僵化，这是几乎所有失效模板的共同轨迹。但更麻烦的是：很多团队不是不想改，而是不敢改，因为改了模板会影响历史项目，没人愿意承担这个风险。于是模板冻结，团队自己另起炉灶，半年后大家默认”模板是给新人看的”。

所以模板从第一版开始就要有版本号、变更记录和适用范围声明。这不是形式主义，是让模板具备”可被安全修改”的能力。

4. 模板阶段的验收标准是第 90 天遵循率，不是上线当天覆盖率

很多 PMO 在模板上线当天汇报”覆盖率 100%”，这个数字几乎没有意义。真正有意义的指标是第 90 天的遵循率、模板外的手工协调次数、以及跨部门交接的平均等待时长。

二、背景与真实场景：跨部门协作到底难在哪

不谈具体场景的模板方法论都是空的。我在项目里反复遇到三种典型的跨部门形态，它们的协作难点完全不同，需要的模板结构也完全不同。把这三类场景混用一套模板，是很多公司模板失效的直接原因。

1. 场景一：新产品导入（NPI），难在交付物交接

硬件加软件的混合研发是最典型的跨部门场景。一个新产品导入项目，通常要穿过硬件、结构、固件、App、测试、供应链、质量七个环节。我在一个消费电子客户那里数过，从立项到量产，明确标注的跨部门交接节点有 9 个：结构图纸交付、电子样机交付、固件首版交付、App 联调版本交付、测试准入、测试报告交付、试产资料交付、质量放行、量产评审。

这类模板的核心不是任务分解，而是每一个交接节点的输入清单和输出清单。硬件团队交出的不只是”图纸”,而是一个包含版本号、变更说明、兼容性声明的交付包；软件团队接收时，需要确认哪些信息缺失。这些约定写在模板里，交接才不会靠人盯。

2. 场景二：合规与审计类项目，难在证据留存

数据合规、安全审查、ISO 认证这类跨部门项目，交接节点其实不多，通常 4，6 个。但它们的要求完全不同：每个节点都要求可回溯的证据链。谁在什么时间确认了什么、附件版本对不对、审批记录能不能导出。

模板在这类场景下的价值不在流程效率，而在字段的强制约束：负责人字段必须唯一、完成时间字段必须自动记录、附件必须带版本。我见过有的团队为了”灵活”，把审批记录做成自由文本，结果审计当天花了三天时间补材料。

3. 场景三：集团多主体协同，难在口径统一

集团型企业的跨主体项目是最复杂的。我参与过一个涉及 4 家子公司的数字化项目，光”完成”这个词的定义就吵了两周，总部认为代码上线算完成，子公司认为业务验证通过才算完成。这类项目的模板必须自带字段字典和主体标识：同一字段在不同主体的含义要显式对齐，每个工作项要标明归属主体。

这类项目我数过，跨主体交接节点最多能到 14 个，而且往往存在双向依赖。模板如果没有主体维度，很容易变成一张看不出归属的平面清单。

三、六个常见误区：模板阶段最容易踩的坑

这一节我列的是回访中出现频率最高的六类问题。它们的共同特征是：设计阶段看起来都”很有道理”，上线三个月后全部变成负担。

1. 误区一：把模板做成任务清单的复制品

最常见的做法是：拿一个已经跑过的成功项目，把里面所有任务复制成模板。结果是模板里有 60 个任务、8 个阶段，但没有任何一处写明”这个任务交给谁、交付什么、什么标准算完成”。

这种模板的问题在于它固化了动作，没有固化契约。任务清单适合单一团队内部复用，跨部门场景下，动作会随项目变化，契约才是稳定的。我的判断标准很简单：把任务名称全部遮住，如果模板还能让人看懂协作关系，它就是合格的；如果只剩下一堆无意义的阶段名，就是复制品。

2. 误区二：追求”一个大而全”的通用模板

很多公司希望用一套模板覆盖所有项目类型，理由是”管理成本低”。但通用模板的必然结果是每个团队都要删掉一半字段、加上自己的一半字段，最后大家用的其实是各自的变体，通用模板反而成了干扰项。

我的经验判断是：一个组织里的模板数量，大致应该是项目类型数量的 1.2 倍左右。也就是说，如果你有 4 类典型项目，那么 4，6 套模板是合理的。少于这个数，说明模板太粗；多于这个数，说明治理失控。

3. 误区三：状态机设计过深，没人愿意维护

我见过一个跨部门项目的工作流有 14 个状态，从”待提出”到”待关闭”层层递进。设计者的逻辑是完整的，但实际运行中，团队会直接跳过中间状态，或者干脆口头沟通完再一次性改状态。

状态机的合理深度，取决于状态的每一次变化是否对应一次真实的跨部门交接。如果某个状态变化只是内部流转，那它应该做成子任务或标签，而不是主状态。我的一般建议是：跨部门主流程的状态数控制在 5，7 个，超出的部分用子状态或二级字段承载。

4. 误区四：字段只加不减，历史包袱持续沉淀

字段膨胀是模板老化的典型症状。第一年加”风险等级”，第二年加”合规标记”，第三年加”供应商编号”，五年后模板里有 30 多个字段，其中一半的历史填充率低于 10%。

我的建议是给字段设”年检”机制：每年统计一次每个字段的填充率和实际被引用次数，连续两个季度填充率低于 15% 且无人查询的字段，直接下线。字段不是越全越好，字段是维护成本。

5. 误区五：没有版本与灰度机制

模板变更最怕两种情况：一是改了不通知，团队某天发现字段变了；二是想改但不敢改，因为历史项目会受影响。这两种情况都源于缺少版本机制。

可行的做法是：模板带版本号，新建项目默认用最新版本，历史项目保持原版本不变，同时在模板变更日志里写清楚”本次变更影响的字段和适用项目类型”。灰度则是指新版本先在 1，2 个新项目上试点两到三周，再全量放开。

6. 误区六：忽略跨部门权限与可见性设计

这是我见过最被低估的问题。模板设计得再好，如果 A 部门看不到 B 部门的工作项，模板就退化成 A 部门自己的清单，跨部门协作依然靠群聊和邮件。

权限设计要回答三个问题：哪些字段对协作方可见、哪些工作项需要跨部门可读、哪些操作需要双人确认。跨部门模板的权限默认应该是”相关方可读、责任方可写、无关方不可见”，而不是一刀切的全公开或全私有。

四、专业判断逻辑：模板设计的五步决策链

前面讲的是问题和误区，这一节讲我的判断方法。我把跨部门模板设计拆成一条五步决策链，每一步都对应一个必须回答的问题。这五步按顺序走，能避免大多数”设计时合理、上线后失效”的情况。

1. 第一步：判断协作密度，而不是团队规模

很多人用团队人数来判断要不要做复杂模板，这是错的。真正决定模板复杂度的是协作密度，在单位时间内，跨部门交接发生的次数，以及交接双方的相互依赖程度。

一个 500 人的公司，如果各部门独立运作、一年只有两次跨部门交接，它需要的模板比一个 80 人但每周都要跨三个部门交接的团队简单得多。我通常用两个问题快速判断：过去三个月跨部门交接发生了多少次？其中有多少次因为信息缺失而返工？

2. 第二步：用交接失败成本决定颗粒度

颗粒度不是越细越好，而是要和失败成本匹配。判断方法很直接：如果这次交接失败，返工需要多久？

返工成本低于半天的工作，模板里用一句话描述即可；返工成本在 1，5 天的，需要明确交付物清单和验收人；返工成本超过一周的，必须有正式的准入准出条件、附件要求和双人确认。用这个尺度去看，很多团队会发现自己在低成本节点上写了太多要求，而在真正高风险的节点上一片空白。

3. 第三步：用决策触发点决定字段

字段设计的核心判据不是”这个信息有没有用”，而是“这个信息会不会触发一次决策或一次交接”。会触发的留，不会的删。

举个具体例子：”预计完成时间”会触发排期决策和延期预警，保留；”工时预估”在很多跨部门协作里不触发任何决策，删掉或改为可选；”风险等级”如果只是填了没人看，那就是无效字段。我在做字段梳理时会把每个字段标注为”决策触发型”或”信息记录型”,后者能删就删。

4. 第四步：用责任边界决定状态归属

状态归属的原则是：状态的推动者应该是这个状态的交付责任人，而不是项目经理。如果某个状态的推进总是依赖 PM 去催，说明状态设计有问题，它没有和某个团队的实际工作交接绑定。

在跨部门模板里，每个主状态都应有明确的”责任团队”和”退出条件”。退出条件要写成可验证的事实，比如”测试报告已上传且版本号与构建版本一致”，而不是”测试完成”。

5. 第五步：用变更频率决定版本策略

不同字段的变更频率差异很大，用同一套版本策略管理会导致要么过度治理、要么完全失控。我的做法是分层：结构性字段（工作项类型、主工作流）走正式版本流程，半年一评；字段选项、标签这类软结构走轻量变更，随时可改；描述模板和检查清单走团队自治，不纳入版本控制。

五、案例与数据观察：中大型组织的模板落地长什么样

这一节我用 PingCode 作为落地载体来讲，原因是它的设计逻辑比较贴合中大型组织的跨部门场景：面向 100 人以上组织，支持工作项类型分层、工作流按类型独立配置、模板集管理，并且支持私有化部署和从 Jira 平滑迁移。下面讲的每一条，你换成其他平台也能对照使用。

1. 用工作项类型分层承载跨部门模板

跨部门模板最容易犯的结构性错误，是把所有工作放在同一种工作项类型上。结果是字段要么过多、要么过少：需求需要的信息和测试缺陷需要的信息本来就不一样。

合理做法是按工作项类型分层。以新产品导入项目为例，我通常建议这样分层：需求类工作项承载业务价值与验收标准，任务类承载具体交付动作，缺陷类承载质量问题与回归范围，测试用例承载验证路径，另外自建 1，2 个跨部门专用类型，比如”交付物”或”评审节点”。

PingCode 的工作项类型支持自定义和分类型配置字段，这一点在跨部门模板里非常关键：交付物类型的必填字段可以只有”交付内容、版本号、验收人、验收标准”四个，而任务类型可以只保留”负责人、计划时间”。字段按类型分流后，单个模板的填写压力会显著下降。

template: npi-cross-team-v2
version: 2.3.0

work_item_types:

name: 交付物

required_fields: [交付内容, 版本号, 验收人, 验收标准]

owner_role: 交付团队

exit_condition: 验收人确认且附件版本一致

name: 评审节点

required_fields: [评审类型, 参与部门, 结论, 遗留问题数]

owner_role: 项目经理

exit_condition: 结论为通过或附条件通过

name: 任务

required_fields: [负责人, 计划完成时间]

owner_role: 执行团队

workflow:

states: [待交接, 已交付, 验收中, 已验收, 已关闭]

transitions:

from: 已交付

to: 验收中

condition: 附件已上传且版本号非空

from: 验收中

to: 已验收

condition: 验收人签字且遗留问题已建单

2. 工作流与进入退出条件才是跨部门模板的骨架

我见过太多模板把精力花在任务拆分上，工作流却只是”待处理，进行中，已完成”三态。这在跨部门场景下几乎等于没有流程：因为跨部门协作的核心问题恰恰是”对方什么时候算交给我了”和”我什么时候算接下来了”。

有效的做法是给关键流转加进入条件。比如”进入验收中”这个流转，必须有附件且版本号非空；”进入已交付”必须填写验收人。这些条件不需要很复杂，三五个就够，但它们把口头约定变成了系统约束。

这里有个经验判断：如果一条流转条件需要写超过两行文字才能说清楚，说明这个状态拆错了。要么合并状态，要么把条件降级为检查清单。

3. 私有化部署与数据隔离对跨部门模板的意义

跨部门模板里承载的不只是任务名称，还有交付物、评审记录、质量数据。对于制造业、金融、能源这类行业，这些数据往往有明确的合规要求，不能随意放在公有云上。

PingCode 支持私有化部署，这在跨部门模板场景下有两个直接价值：一是模板里的字段定义、字段字典、审批记录可以完整留在企业内网；二是对于涉及多主体（集团与子公司）的协作，可以通过部署边界和数据权限把可见性控制到工作项级别。我在一个集团客户那里看到的具体做法是：模板里的”主体标识”字段与权限组绑定，子公司之间默认互不可见，只有集团级评审节点才开放跨主体可见。

4. 从 Jira 迁移时，模板映射最容易出问题的三个地方

迁移这件事我在多个项目里做过深度参与，结论是：真正难的不是数据搬运，而是模板语义的对齐。下面三个地方几乎每次都会出问题。

第一，状态映射的语义漂移。源系统里的”Done”和迁移后系统里的”已完成”看起来一样，但退出条件不同。如果迁移时只做名称映射，不做流转条件重建，就会出现状态能跳过去、但实际工作没完成的情况。

第二，字段的隐性语义。迁移前的很多字段，含义其实靠团队口头约定，文档里没写。迁到新平台后约定丢失，新成员填出来的值五花八门。解决办法是在迁移阶段同步建立字段字典，把每个字段的定义、取值范围、责任人写清楚。

第三，权限模型的差异。不同平台的权限粒度、继承逻辑、项目角色定义往往不同。模板迁移如果只搬结构不搬权限，跨部门可见性就会失真。

PingCode 提供了面向 Jira 的平滑迁移能力，覆盖工作项、状态、字段、附件、历史记录等对象的映射，这对跨部门模板的整体搬迁是有实际帮助的。但我仍然建议：迁移前先做一轮模板审计，把不再需要的字段和历史状态清理掉，别把包袱原样搬到新平台。

5. 100 人以上组织的分层治理实践

在 100 人以上的组织里，模板治理不应该由单个团队承担。我见过运行比较好的做法是三层：PMO 或效能团队负责模板框架和版本基线；业务线负责人负责本领域模板的字段增补；项目团队只能派生模板，不能直接修改基线。

这样做的直接效果是：模板有唯一的权威版本，同时又允许局部适配。派生的模板需要标注”派生自哪个基线版本”，这样当基线更新时，可以快速识别哪些派生模板需要同步。

六、行动建议：按团队成熟度分层的落地路径

跨部门模板没有最优解，只有适配解。下面按团队规模和组织成熟度分四档，给出我实际用过的落地建议。

1. 30 人以下团队：一套轻模板，够用就行

这个阶段不要追求模板的完备性。我的建议是把所有跨部门协作压到最多 8 个字段：协作方、交付物、交付时间、验收人、验收标准、当前状态、阻塞原因、备注。

工作流用 4 个状态就够：待交接、进行中、待验收、已完成。这个阶段最值得投入的不是模板设计，而是养成”每次跨部门交接都在工具里留痕”的习惯。

2. 30，100 人团队：按项目类型分 2，3 套模板

这个规模通常已经出现了明显的项目类型分化，比如产品研发项目、客户交付项目、内部改进项目。差异大的类型必须分开建模板，硬套一套会让每类项目都不舒服。

关键动作是建立字段字典：每个跨部门字段写清楚定义、取值范围、责任人。这个动作看起来琐碎，但它是后面所有治理工作的基础。

3. 100，500 人团队：4，6 套模板 + 版本基线 + 分层治理

这个规模的组织已经需要正式的模板治理机制了。我的建议是：PMO 维护基线模板，业务线维护派生模板，派生关系可见可追溯；模板每季度评审一次，字段每年清理一次。

这个阶段的工具选择开始变得重要。中大型组织的跨部门协作往往涉及数据隔离、权限分层、私有化部署等要求，PingCode 这类面向 100 人以上组织、支持私有化部署和分级权限的平台会更适配。如果你正从 Jira 迁移过来，建议把模板迁移和字段清理合并成一个项目来做，避免把历史包袱带进新系统。

4. 500 人以上组织：模板平台化，从”模板”走向”模板能力”

这个规模的组织，模板数量会自然增长到 10 套以上，靠人工维护不可持续。可行的路径是模板平台化：把字段、工作流、权限、检查清单做成可组合的能力单元，新项目类型通过组合生成模板，而不是从零搭建。

平台化之后，模板治理的指标也要升级：不再看”模板数量”，而是看”新项目类型的模板搭建耗时”和”跨模板的字段复用率”。

5. 30/60/90 天落地节奏

不管哪个规模，模板落地都可以按这个节奏推进。第 1，30 天做审计和收敛：盘清现有模板、统计字段填充率、砍掉无效字段，目标是字段数收敛到 15 个以内。

第 31，60 天做试点和版本机制：选 2，3 个新项目试点新模板，同时上线版本号和变更日志，固化字段字典。第 61，90 天做推广和复盘：全量放开，统计遵循率和交接等待时长，形成第一次模板评审记录。

七、取舍：颗粒度、灵活性与治理成本之间的三角

模板设计说到底是一组取舍。想清楚取舍，比学任何方法论都管用。下面五组是我在实际项目里反复需要做的权衡。

1. 颗粒度 vs 填写成本

颗粒度越细，跨部门交接越清楚，但填写成本越高。我的判断标准是：把字段分成”不填就无法推进”和”填了更好”两类，前者必填，后者可选。很多模板的问题在于把所有”填了更好”的字段都设成了必填。

2. 统一 vs 灵活

统一口径带来可比较性，灵活适配带来团队接受度。我的建议是分层处理：跨部门交接相关的字段必须统一，团队内部的执行细节允许灵活。换句话说，契约部分统一，动作部分自由。

3. 集中治理 vs 团队自治

集中治理能保证模板质量，但响应速度慢；团队自治响应快，但容易失控。比较可行的折中是”基线 + 派生”：基线由治理方维护，派生模板由团队自行调整，但派生必须声明来源版本，且不能修改契约字段。

4. 迁移成本 vs 长期维护成本

换平台时，一次性把模板完整迁移看起来省事，但如果原模板本身有大量冗余字段，完整迁移等于把维护成本一起搬过去。我更倾向于借迁移做一次模板瘦身：迁移过程中同步清理低填充率字段，短期多花两周，长期每年省下大量维护时间。

5. 私有化部署 vs SaaS 订阅

跨部门模板承载的数据敏感度通常高于单一团队项目，涉及交付物、评审记录、质量数据。如果有明确的合规或数据出境要求，私有化部署是必要的；如果组织以效率优先、数据敏感度不高，SaaS 的迭代速度和运维成本更有优势。这个取舍没有标准答案，取决于行业和监管环境。

八、常见问题（FAQ）

1. 跨部门项目模板应该由谁维护？

我的建议是 PMO 或研发效能团队维护基线，业务线负责人维护派生。项目团队只使用和反馈，不直接改基线。理由很简单：模板是跨部门的公共资产，由单一团队维护必然偏向自己的使用习惯，最终会被其他部门弃用。

2. 一个公司应该有几个项目模板？

经验值是项目类型数量的 1.2 倍左右。如果你有 4 类典型项目，4，6 套模板是合理区间；少于这个数说明模板太粗，各团队会自行加字段；多于这个数说明治理失控，字段口径开始互相冲突。

3. 模板里的必填字段留几个合适？

从填写完成率的角度看，10，15 个必填字段是比较稳妥的区间。低于 10 个，跨部门契约信息可能不足；超过 15 个，填写完成率会明显下滑，数据质量反而变差。更重要的判据是：每个必填字段是否真的会触发一次决策或交接。

4. 模板改了，历史项目要不要跟着改？

不要。历史项目保持原版本不变，是最稳妥的做法。强制同步会导致大量无意义的返工，还会让团队对模板更新产生抵触。正确的机制是让新版本只作用于新建项目，同时在版本日志里说明影响范围。

5. 跨部门模板和敏捷迭代会不会冲突？

不会冲突，冲突的是把两种东西混在一套结构里。我的建议是分开承载：迭代节奏用看板或迭代视图承载，跨部门交接约定用工作项类型和字段承载。同一批工作项可以既属于某个迭代，又满足跨部门契约要求，两者并不矛盾。

6. 从 Jira 迁到国产平台，模板能完整搬过去吗？

结构层面可以，语义层面需要人工重建。状态名称、字段名称、层级关系这类可以自动映射，但状态的退出条件、字段的隐性含义、权限的继承逻辑往往需要重新定义。PingCode 提供了面向 Jira 的平滑迁移能力，覆盖工作项、状态、字段、附件和历史记录的映射，这能解决大部分搬运工作；但迁移后的语义对齐和字段瘦身，还是得由了解业务的人来完成。

7. 小团队需要跨部门模板吗？

需要，但应该极简。30 人以下团队建议只保留 8 个字段、4 个状态，重心放在”每次交接都留痕”这个习惯上。这个阶段做复杂模板的投入产出比很低，反而会因为维护成本过高而放弃。

8. 怎么衡量模板做得好不好？

三个指标就够了：第 90 天的模板遵循率、跨部门交接的平均等待时长、以及因信息缺失导致的返工次数。这三个指标比”模板覆盖率”更能反映真实效果。如果遵循率高但等待时长没降，说明模板可能只是增加了形式动作。

九、写在最后：模板阶段真正要交付的东西

回到开头那家公司。他们的模板在第六个月只剩 17% 的项目在用，问题不在于工具，也不在于执行力。他们的模板里有 60 个任务、8 个阶段、26 个必填字段，却没有一处写清楚”结构图纸交给固件团队时，必须带哪个版本号、谁负责验收”。这就是典型的把动作固化、把契约漏掉。

我的核心判断是：跨部门项目模板的成败，取决于它在设计阶段有没有回答”交接物、验收标准、责任主体”这三个问题，以及它有没有从第一天起就具备被安全修改的能力。其他的都只是形式。

如果你现在正准备做这件事，建议按这个顺序推进：先用一周时间盘清现有的跨部门和现有模板，统计每个字段的填充率；然后用两天时间把必填字段收敛到 15 个以内，并为每个字段写下定义和责任人；接着选 2，3 个新项目做试点，同时把版本号、变更日志和字段字典上线；最后在第 90 天做一次正式复盘，看遵循率、交接等待时长和返工次数这三个数字。

不要指望一次设计出完美模板。模板是会长大的，关键是让它在一个可控的机制里长大，而不是每次都由某个人偷偷拉一套新的出来。