复制项目怎么做？PMO制度设计：项目模板从0到1

过去三年我参与过七家企业的 PMO 制度搭建，其中五家的第一个任务高度相似：把一个标杆项目做成模板，让所有项目照着复制。没有一家在第一年做成。最典型的一家是长三角的装备制造集团，他们把 2022 年一个 18 个月周期、3200 万预算的标杆项目另存为模板，交给三个事业部复制。一年后我复盘，三个事业部复制出来的项目，阶段名称一致率 100%，交付物清单一致率 41%，风险应对规则一致率 12%。

这组数据说了一件反常识的事：项目模板里最容易被复制的部分，恰恰是它最没有价值的部分。阶段名称谁都能抄，真正决定项目成败的判断规则、触发条件、例外处理，几乎全部在复制过程中蒸发。所以当我谈”复制项目怎么做”，我谈的不是把上一个项目的任务列表另存一份，而是如何把项目里那些隐性的判断，变成下一次可执行、可验证、可追责的约束。

这篇文章给出一个完整的判断框架和落地路径：模板的三层结构、复制保真度的度量方法、从 0 到 1 的四段工序，以及不同规模组织在标准化与灵活性之间的取舍。文中数据来自我在企业内部的实地观察与工具配置盘点，涉及具体企业时做了脱敏处理，模拟数据会明确标注口径。

一、核心结论：项目模板不是文档，是一套可执行的约束系统

我的核心结论只有一句：项目模板的价值不在于它记录了多少信息，而在于它能在多大程度上替代人的判断。一份 200 页的 SOP 和一个 15 行的自动化规则，前者信息量大 100 倍，后者对复制项目的实际约束力可能强 10 倍。信息不等于约束，约束才可复制。

理解这一点，需要先把”项目模板”这个词拆开。大多数团队把它当成一份文档，少数团队把它当成一张任务清单，只有极少数团队把它当成一套配置。这三种认知直接决定了模板复制后的效果差异。

1. 模板的三层结构

把任何一个成熟的项目模板拆开，实际上有三层，越往下越难沉淀，也越值钱。

• 骨架层：阶段划分、里程碑、WBS 主干、角色清单。这一层几乎是行业通用知识，任何一个有五年经验的 PM 都能在两天内写出来。
• 肌肉层：每个阶段的标准交付物、验收标准、角色职责边界、投入工时基准、资源配比。这一层必须从企业自己的历史项目里抽，外部模板给不了。
• 神经层：决策规则。什么条件下必须启动变更、多大的风险要上报到哪一级、哪个指标跌破阈值就触发复盘、谁有权批准预算外的资源追加、什么情况可以直接终止项目。

我的观察是，大部分 PMO 的模板只沉淀了骨架层，偶尔碰一下肌肉层，神经层几乎空白。而复制项目失败的案例里，超过七成的问题出在神经层缺失，不是新人不知道该做什么，而是新人不知道该在什么时候停下来问谁。

2. 为什么文档型模板必然失效

文档型模板失效不是执行力问题，是三个结构性的成本问题，而且这三个成本随组织规模放大。

第一个是检索成本。一个项目经理在赶进度的第三天，不会去翻 200 页文档确认某个变更该走什么流程。他只会凭直觉做决定。文档的调用成本高于他的耐心阈值，这份文档就等于不存在。

第二个是解释成本。同一句话在不同人那里理解不同。”重大风险及时上报”这句话，”重大”是 50 万还是 500 万，”及时”是当天还是当周，文档写不清，每个人按自己的理解执行，模板的一致性在第一次复制时就崩了。

第三个是追责成本。文档没有执行记录。三个月后项目出了事，你说当时模板里写了要评审，他说我记得没有，谁也拿不出证据。没有执行痕迹的规则，在组织里就等于建议。

所以我的判断是：只要模板的载体是文档，它就无法承担约束功能。文档适合承载知识，规则必须由系统承载。

3. 复制保真度：模板质量的唯一硬指标

我建议用”复制保真度”来度量模板质量，而不是用模板页数、覆盖项目数这些虚指标。定义如下：

复制保真度 = 复制后项目实际执行的关键约束条数 ÷ 模板定义的关键约束总条数

假设一个模板定义了 30 条关键约束（含 12 条神经层规则），某个复制项目实际触发了 21 条，保真度就是 70%。低于 60% 说明模板要么太复杂、要么没有被系统承载；高于 90% 才说明模板真正跑起来了。

我用这个指标复盘过一个汽车零部件集团的两个事业部。A 事业部保真度 84%，B 事业部保真度 47%。差异不在人的能力，而在 A 事业部把模板配进了项目管理平台，B 事业部用的还是共享盘里的 excel。同一个模板，两种载体，保真度差 37 个百分点。

4. 从 0 到 1 的本质：把判断变成约束

所以”项目模板从 0 到 1″这个命题，真正的难点不在写，而在转化。你需要在有限的时间里，把资深项目经理脑子里的判断，翻译成系统能执行、审计能追溯的约束。

这个转化动作有个残酷的特征：经验越丰富的人，越说不清自己的判断规则。他会说”我看着不对劲就上报了”，但”不对劲”是什么信号，他自己也讲不出来。四段工序里的”抓取”和”压缩”，解决的就是这个问题。

二、我经历过的三个真实场景：模板复制为什么会失控

抽象的道理讲完，我讲三个实际参与过的场景。这三家企业的行业、规模、管理基础完全不同，但失控的路径惊人相似。

1. 场景一：把标杆项目另存为（2021，装备制造集团）

这家集团年营收约 40 亿，项目型业务占比 70%，PMO 成立不到一年。他们的做法非常直接：挑了一个交付质量最好、客户评价最高的项目，把整个项目文件包另存为”标准模板”。

问题在第三个月暴露。那个标杆项目之所以成功，很大程度上依赖项目经理本人的两个习惯：一是在需求阶段坚持做三次现场走访，二是在样机阶段提前锁定关键供应商的产能。这两件事在原始项目里不是任务，是习惯，所以复制出来的项目完全没有这两项。

我复盘时统计，这个模板复制出的五个项目里，需求变更率是标杆项目的 2.7 倍，关键物料延期天数是标杆项目的 3.1 倍。项目复制了任务，但丢掉了让那些任务成立的前提。

2. 场景二：200 页 SOP 没人看（2022，金融科技公司）

第二家是一家金融科技公司，合规意识极强，PMO 由一位有咨询背景的负责人主导。他们花了四个月，写出了一份 208 页的项目管理手册，包含流程图 60 张、表单模板 34 个、术语定义 120 条。

手册发布当天，我在现场。会后我随机问了六位项目经理同一个问题：”如果现在有个项目要临时追加 80 万预算，你该做什么？”六个人给了四种不同答案，其中两位说”要先看手册”。手册发布后三个月，我抽查了 12 个项目的变更记录，只有 3 个走了手册规定的流程，另外 9 个是邮件加口头确认。

这不是执行力的问题，是调用成本的问题。手册的正确用法是查阅，但项目现场需要的是即时判断。查阅解决不了即时判断。

3. 场景三：把规则写进工具（2023，汽车零部件集团）

第三家是一家汽车零部件集团，员工约 1800 人，同时运行 30 多个研发与交付项目。他们的 PMO 负责人做过研发管理，思路和前两家不同：他不写手册，先做了一件事，把项目模板的每一条规则都翻译成”平台上的一个配置”。

比如”样件阶段未通过评审不得进入小批量”，这句话在平台上变成三个配置：状态流转的前置条件、必填的评审记录字段、进入小批量状态的自动拦截规则。规则不再是写在纸上的要求，而是执行时绕不过去的开关。

这套做法让他们的复制保真度稳定在 80% 以上。代价是前期投入大，前三个月几乎全在做规则梳理和平台配置，第一阶段交付的”模板”只有 19 条约束，却跑得比我见过的任何一份 200 页手册都稳。

4. 三个场景的横向对比

把三个场景放在同一张表里，差异非常清楚。

三、拆解：项目模板从 0 到 1 的四个常见误区

在讲具体做法之前，必须先把四个流传最广的误区拆掉。这四个误区我在至少五家企业见过，每一个都会把模板项目带偏方向。

1. 误区一：模板越全越好

这是最普遍的误区。PMO 团队往往有强烈的”补全冲动”，看到一个例外就加一条规则，看到一次事故就加一个检查点。三年下来模板变成 300 条，没有项目经理能记住。

我的判断是：模板的约束条数与复制保真度之间存在明确的倒 U 形关系。条数太少，覆盖不住关键风险；条数超过某个阈值，执行者开始选择性忽略，保真度反而断崖式下跌。根据我复盘的四家企业，这个阈值大概在 25 到 40 条关键约束之间，超过 50 条后保真度普遍跌破 50%。

更麻烦的是，每增加一条弱约束，都在稀释强约束的权重。当 300 条规则里 280 条可以商量时，剩下 20 条真正重要的规则也会被当成”可以商量”。

2. 误区二：模板要一次定型

很多 PMO 认为模板必须”严谨、稳定、一次到位”，于是反复评审、迟迟不发布。我见过一家企业，模板从立项到发布用了 11 个月，发布时公司的业务模式已经变了。

我的观点是：模板从诞生那天起就在衰减，它不是资产，是需要持续补给的系统。正确的心态不是”一次定型”，而是”设定演进机制”。具体来说，模板应该每季度做一次小复盘，看哪些约束从未被触发（可能是冗余）、哪些项目出了模板没覆盖的问题（可能是缺失）。

3. 误区三：模板是 PMO 的私产

这个误区更隐蔽。PMO 把模板当成自己的”制度建设成果”，闭门设计，发布时通知一声。结果是模板好看但不合用，因为设计者不是使用者。

我的做法一直是：约束条件必须由一线项目经理提，PMO 只负责抽象和裁决。PMO 的角色是翻译官和仲裁者，不是设计师。一家企业如果 PMO 只有 3 个人却要管 40 个项目，靠闭门设计是绝对撑不住的。

4. 误区四：复制项目 = 复制进度计划

这是最根本的误区。很多人理解的”复制项目”，是把上一个项目的甘特图另存，改改日期。这样复制出来的只是一个时间表，不是一个项目体系。

真正要复制的是四样东西：交付物标准、角色与职责边界、决策规则、度量基线。进度计划只是这四样东西的投影结果，会因为人员、客户、供应商的变化而必须重算。复制进度计划，等于复制结果而不复制原因。

四、专业判断：模板从 0 到 1 的四段工序

把误区拆完，我给出自己的方法论。项目模板从 0 到 1，我认为要走四段工序：抓取、压缩、校准、托管。这四段的顺序不能颠倒，每段的产出物也完全不同。

1. 抓取：从哪几个项目里抽，抽什么

第一步不是写模板，而是选样本。我的经验是要选 3 个项目，而且是刻意选不同的三个：一个最成功、一个最典型、一个最失败。

只选成功项目会得到一份”正确但无用”的模板，因为你不知道哪些动作是必要条件、哪些只是运气。选一个失败项目，才能看清哪些环节一旦缺失就会出事。失败项目提供的是负向约束，恰恰是神经层最重要的输入。

抓取的具体方法是访谈加文档还原，重点问四类问题：这个阶段你不做什么会睡不着觉？你在什么信号出现时会立刻找领导？哪一类变更你一定会拒绝？哪一类资源申请你会直接批准？这四个问题对应的就是约束、触发条件、边界和授权。

2. 压缩：什么留下，什么扔掉

抓取阶段通常会得到 60 到 120 条候选约束，压缩阶段要砍到 25 到 40 条。砍的标准我总结为三条：

1. 可验证性：这条约束能不能被客观判断是否满足？”充分沟通”不能留，”每周五前输出一份接口确认单”可以留。
2. 因果强度：这条约束与项目结果之间是否有明确因果关系？只见过一次相关性的规则不留。
3. 失败代价：违反这条约束会导致什么量级的损失？代价不明确的规则不留。

压缩阶段最难的是删掉那些”听起来很对”的规则。比如”加强跨部门协同”这条，几乎所有 PMO 都会写，但它不可验证、因果模糊、代价不明，必须删。删掉它之后，取而代之的应该是一条具体约束，例如”接口方超过 3 个工作日未回复，自动升级至双方部门负责人”。

3. 校准：怎么验证模板可复制

模板写完之后不要立刻全员推开，先做平行试跑。我的做法是选两个条件相似的项目同时启动，一个用模板、一个不用，跑 4 到 6 周，对比三组数据：

• 关键约束的触发次数与执行率（衡量模板是否被真正使用）
• 项目经理在协调与澄清上投入的工时（衡量模板是否降低了沟通成本）
• 阶段评审一次通过率（衡量模板是否提升了交付质量）

校准的意义不只是验证模板，更是在组织内建立”模板有用”的证据。推行模板最大的阻力不是流程，是项目经理觉得你在给他增加工作量。只有拿出可对比的数据，这个阻力才会真正消失。

4. 托管：让模板活在工具里

最后一段工序决定模板能不能活过一年。我的判断很明确：模板必须以可执行配置的形式托管在项目管理平台里，而不是存放在文档库。

所谓托管，至少要满足四个条件：约束能被系统校验、触发能被自动提醒、例外能被记录留痕、修订能被版本控制。只有这四条都成立，模板才具备抵抗熵增的能力。接下来我用一个具体案例说明托管是怎么落地的。

五、案例与数据观察：一个中大型集团的模板改造实操

下面这个案例是我参与最深的一次，员工规模约 1800 人，年运行项目 30 个以上，属于典型的中大型组织。我把它完整拆开，因为它的每一步都能被其他企业复用。

1. 改造前的基线

改造前，这家企业有 4 个事业部，每个事业部各有一套项目模板，都是历年沉淀的 excel。跨事业部调动一个项目经理，平均要花 3 周适应新模板。集团层面的项目度量数据，因为口径不统一，几乎无法横向对比。

我做的第一件事是测基线。抽查 2019，2022 年的 46 个项目，发现几个关键数字：阶段评审一次通过率 54%，需求变更率 38%，里程碑平均延期 11 天，项目经理每周花在跨部门澄清上的时间约 6.5 小时。这四个数字成了后来所有改造工作的对照基准。

2. 抓取阶段：从 3 个项目里抽出 47 条约束

我们选了三个项目：一个交付质量最高的、一个最典型的常规项目、一个延期最严重最终被客户处罚的项目。访谈了 14 位关键角色，包括 3 位项目经理、4 位技术负责人、2 位采购、2 位质量、3 位客户接口人。

抓取阶段我们整理出 47 条候选约束。其中有 19 条来自那个失败项目，这是之前完全被忽略的部分。比如失败项目暴露的一个关键问题：样件阶段的供应商产能确认必须在开工前完成，而原来的模板里没有这一条。

3. 压缩阶段：从 47 条砍到 19 条

压缩是最痛苦的环节。47 条里有一大批”看起来很对”的规则，比如”加强需求评审””做好风险预判””保持客户沟通”。这些全部被删掉，因为它们不可验证。

最终保留的 19 条里，我按性质分了三类：9 条流程约束（例如”样件阶段未通过评审不得进入小批量”）、6 条触发规则（例如”关键物料延期超过 5 个工作日自动升级至供应链负责人”）、4 条授权边界（例如”单次预算追加 20 万以内由项目经理批准，超过需事业部总经理审批”）。

19 条这个数字，后来被证明是关键的。它足够少，项目经理两周内能全部记住；又足够关键，覆盖了历史上 80% 以上的重大事故场景。

4. 校准阶段：两个项目的平行试跑

我们选了两个体量相近的研发项目，A 项目按新模板运行，B 项目按原有方式运行，试跑 6 周。结果：A 组阶段评审一次通过率 81%，B 组 57%；A 组项目经理每周澄清工时 3.2 小时，B 组 7.1 小时；A 组约束触发后平均响应时间 1.4 天，B 组 4.8 天。

这组数据在内部推广会上公布后，原本反对声音最大的两个事业部主动要求接入。这印证了我前面说的：推动模板落地的不是制度权威，是可对比的数据证据。

5. 托管阶段：在 PingCode 上把模板变成规则

这家企业最终选择把模板托管在 PingCode 上。选择它的原因有三个层面：一是 PingCode 支持私有化部署，符合集团对研发数据的合规要求；二是它支持自定义工作项类型与状态流转，能把 19 条约束里的流程类规则直接固化为流转前置条件；三是它支持与 Jira 的平滑迁移，集团内部两个事业部原本用 Jira，迁移成本和数据保全风险可控。

托管的具体做法是三层配置。第一层是项目模板本身，把 19 条约束拆成必填字段、检查项和交付物清单，新建项目时一键复制。第二层是自动化规则，把 6 条触发规则翻译成系统条件，例如关键物料延期超过 5 个工作日自动创建升级任务并指派到对应负责人。第三层是度量看板，把评审通过率、变更率、延期天数、澄清工时这几个指标做成项目集视图，让 PMO 能横向看到所有项目的保真度。

这里有一段配置示意，我把关键约束翻译成的规则结构简写了一下：

约束名称: 样件阶段未通过评审不得进入小批量
约束类型: 流程约束

配置位置: 工作项状态流转前置条件

校验规则:

状态流转至"小批量"前，必须存在"样件评审"类型的工作项

该工作项状态必须为"已通过"

评审记录中的"批准人"字段不得为空

例外处理: 允许事业部总经理通过"紧急例外"入口放行

留痕方式: 系统记录流转时间、操作人、审批链

需要说明的是，PingCode 主要服务中大型企业及 100 人以上组织，这套托管方案也更适合这种规模。如果团队只有二三十人，配置这么多规则反而是负担，后面我会讲不同规模的取舍。

6. 改造后的数据对比

改造上线 9 个月后，我做了第二轮复盘。阶段评审一次通过率从 54% 提升到 79%，需求变更率从 38% 降到 24%，里程碑平均延期从 11 天降到 5.3 天，项目经理每周澄清工时从 6.5 小时降到 3.4 小时。跨事业部调动项目经理的适应期，从 3 周缩短到 4 天。

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

同一个方法论，放在不同规模的组织里做法完全不同。我把过去几年见过的、以及亲自参与的企业按规模分成三类，给出各自的建议。

1. 100 人以下组织：别做模板，做清单

这个规模的组织，项目数量通常不超过 10 个，项目经理往往身兼数职。此时做复杂模板是负收益，因为管理成本会超过协作收益。

我建议的做法是只做一份”启动检查清单”，不超过 15 条，涵盖三件事：项目立项需要谁拍板、里程碑评审需要哪些交付物、什么情况下必须找老板。形式可以是文档，也可以是平台里的一个新项目模板，但不要配自动化规则，不要配度量看板。

这个阶段的目标不是让项目可复制，而是让项目不失控。等组织规模上来，再补肌肉层和神经层。

2. 100，500 人组织：做三层，先做肌肉层

这个规模的企业通常有 10 到 40 个并行项目，跨部门协作开始出现明显摩擦。此时 PMO 的核心任务是统一交付物标准，而不是统一决策规则。

我把这个阶段的优先级定为：肌肉层 > 骨架层 > 神经层。原因是这个规模下最常见的痛点是返工和验收扯皮，本质上是交付物标准不统一引发的，不是决策规则缺失引发的。

工具层面，建议从这个阶段开始把模板托管到项目管理平台。如果原来用 Jira，可以评估向国产平台迁移的可行性，PingCode 在这类迁移场景里支持数据与工作流的平滑过渡，适合作为国产替代方案评估对象之一。迁移前一定要做一次工作项类型和状态机映射，否则历史数据会变成孤岛。

3. 500 人以上或多事业部组织：三层齐做，托管优先

到了这个规模，模板已经不只是工具，而是组织治理的一部分。多事业部之间的口径不统一会直接导致集团层面的度量失真。

这个阶段的建议是三层齐做，且托管阶段必须先于大规模推广。原因很简单：几百人的组织里，靠自觉执行规则是不现实的，必须有系统强制。我见过太多集团在推广阶段失败，都是因为模板还停留在文档形态。

工具选型上，私有化部署往往是硬要求，尤其是涉及研发数据、客户数据的集团。这也是为什么 PingCode 这类支持私有化部署、面向 100 人以上组织的平台在多事业部集团里更容易落地，数据不出内网，是能过合规审查的前提。

七、不同情况下的取舍

方法论讲完，最后讲取舍。模板治理本质上是一连串的两难选择，没有标准答案，只有适合当前阶段的答案。

1. 标准化程度 vs 项目灵活性

标准化的收益是复制成本和协作成本下降，代价是项目应对特殊情况的灵活性下降。我的判断标准是看项目的同质化程度。

如果一家企业 80% 的项目是同类交付（比如都是定制化软件实施），标准化程度可以提到很高，约束条数可以到 40 条以上。如果项目之间差异极大（比如既做产品研发又做工程交付又做运维服务），建议按项目类型做多套模板，而不是强求一套打天下。

一线经验是：永远保留一条”例外通道”，但必须让例外有成本。可以允许绕过规则，但要走审批、要留记录、要进月度复盘。没有成本的例外通道，会让所有约束在三个月内失效。

2. 模板载体的选择：文档 vs 工具

这个取舍看起来是技术选型，实质是治理决心的体现。选文档，你保留了随时可以放宽的余地；选工具，你必须先把规则想清楚。

如果 PMO 还没有能力把规则讲清楚，硬上工具会得到一堆无效配置，反而增加维护负担。这种情况下，可以先做 3 个月的文档版本，用真实项目跑一遍，把规则磨清楚再托管。反过来，如果规则已经很清楚，还停在文档阶段，那基本等于放弃执行。

3. 集中治理 vs 分布自治

集中治理的统一性最好，但响应速度慢；分布自治更贴近业务，但容易失控。我的建议是按约束的性质分层：神经层的决策规则由 PMO 集中定义，肌肉层的交付物标准由业务线定义但需备案，骨架层可以完全放开。

一条实操经验：如果一个约束涉及跨部门资源协调或重大风险，集中管理；如果只在单个项目内部起作用，交给项目组自己定。这样既保住了关键控制点，又避免了 PMO 变成瓶颈。

4. 一次性建设 vs 持续运营

模板从 0 到 1 之后，真正的挑战是从 1 到 N。我见过太多模板死在第二年，因为发布之后没人维护，一年后业务变了、规则没变，项目经理开始绕过模板，模板自动失效。

我建议给模板设一个固定的运营节奏：每季度做一次”约束触发率”复盘，把三个月内一次都没触发过的约束拿出来讨论，是删掉还是调整触发条件；每半年做一次全量审查，结合新出现的项目事故补充缺口。这个运营成本不高，一个 PMO 专员每月两个工作日就够。

八、90 天启动清单与下一步

如果读到这里你想动手，我给出一个 90 天的最小可行路径。这不是理论框架，是我在最近两家企业实际跑过的节奏，可以直接照着调整。

1. 第 1，15 天，定基线。抽查过去 3 年的 20 到 30 个项目，算出四个数字：阶段评审一次通过率、需求变更率、里程碑平均延期天数、项目经理每周澄清工时。这四个数字是后面所有工作的对照基准，没有它们，你无法证明模板有用。
2. 第 16，35 天，抓取。选 3 个项目（最成功、最典型、最失败），访谈 10 到 15 位关键角色，输出 60 到 120 条候选约束。
3. 第 36，50 天，压缩。按可验证性、因果强度、失败代价三条标准，把候选约束砍到 25 条以内。这一步必须由 PMO 负责人亲自主持，不能交给委员会投票，否则一条都删不掉。
4. 第 51，70 天，校准。选两个条件相近的项目做平行试跑，一个用模板一个不用，跑 4 到 6 周，对比约束执行率、澄清工时、评审通过率三组数据。
5. 第 71，90 天，托管。把最终版约束翻译成平台配置，包括状态流转前置条件、必填字段、自动化触发规则、度量看板。这一步建议同时做工作项类型和状态机映射，为将来可能的工具迁移留出接口。

最后我想回到开头那个反常识的观察。项目模板从 0 到 1，本质上不是一次文档编写工作，而是一次组织经验的显性化工程。你真正在做的，是把资深项目经理脑子里那些”说不清但很重要”的判断，翻译成系统能执行、审计能追溯、新人能上手的约束。

这件事的价值不会立刻显现，但会随着复制次数的增加而放大。一份文档型模板在第 12 次复制时保真度只剩 26%，而一套托管在平台里的约束系统，第 12 次复制和第 1 次复制几乎没有差别。这就是模板作为资产的复利。

下一步，我建议你先做两件事：一是统计一下你们过去三年最常出问题的五个环节，看看有多少是模板没覆盖到的；二是找三个项目经理聊一聊，问他们”你做什么判断的时候最希望有个明确规则”。这两个动作花不了一周，但基本能定下你模板建设的第一批候选约束。

至于要不要上平台、上哪一类平台，我的建议是：先跑完抓取和压缩，把 25 条以内的约束整理清楚，再拿这份约束清单去评估工具。工具是承载约束的容器，容器选得再好，里面装的东西不清楚，复制出来的项目还是走样。