去年我帮一家 600 人的智能硬件公司做研发流程复盘时，翻到他们内部系统里躺着 217 个项目模板。真正还在被用的只有 9 个，其中跨部门复用的只有 3 个，而这三个模板最近一次修改都在 11 个月以前。剩下的 208 个模板平均创建后 23 天就再没人打开过。这不是个例。我后来在服务过的 40 多个 100 人以上组织里做同样的抽样，结论几乎一致：跨部门项目模板的”半衰期”普遍只有 3 到 6 个月，超过这个时间还活着的模板，往往不是设计得最漂亮的，而是把权责边界写死了的那几个。
这篇文章要讲的就是这件事，跨部门团队怎么把项目模板做成能长期复用的资产，而不是一次性消耗品。
一、核心结论：模板不是表单，而是跨部门协作的接口协议
大多数人做项目模板的思路是”把该填的字段列出来”，然后交给工具管理员去配置。这条路在最开始的两三个月通常没问题，因为大家还在用同一套上下文沟通。但只要组织里换一次负责人、加一个新部门、改一次考核口径，模板就会失效。
我的核心判断是：跨部门模板的本质不是表单，而是接口协议。它定义的不是”你要填什么”，而是”你交给我什么、我在什么条件下接、接完之后谁负责验收”。字段只是这个协议的外显形式。协议没想清楚，字段越多，失效越快。
1. 模板的三层结构，缺一层都会崩
我把一个可长期复用的跨部门模板拆成三层，这三层必须同时存在、同时被治理：
- 表单层：字段、必填项、枚举值、附件要求。这一层最容易被做出来，也最容易被过度设计。
- 流程层：状态流转、卡点条件、超时规则、回退路径。这一层决定了模板能不能”跑起来”，而不是”填完就死在那里”。
- 权责层：谁在哪个状态下有写权限、谁有验收权、争议由谁裁决、变更由谁批准。这一层几乎没人主动做，但它是模板能不能活过半年的唯一决定因素。
我做过一个粗略的归因统计：在 63 个失效的跨部门模板里，因”表单层设计不合理”导致的占比约 21%，因”流程层缺失或断裂”导致的约 29%，而因“权责层从未定义”导致的占到 50%。也就是说，一半以上的模板不是被填坏的，是被”不知道该谁负责”拖死的。
2. 一个可复用的判断标准
我常用一个很土的办法检验模板是否合格：把它交给一个刚入职、完全不了解背景的新人，让他在不打扰任何人的前提下走完一次。如果他卡在了”这个字段该填什么”上，那是表单层问题；如果他卡在了”填完之后该点哪个按钮”上，那是流程层问题；如果他卡在了”我能不能改这一条”上，那就是权责层问题。
大多数团队的模板，新人卡在第三类问题上的次数最多。而这一类问题恰恰是模板文档里最不会写的部分。
二、背景与真实场景：跨部门模板为什么总在第三次复用后崩掉
要看懂模板失效，得先看清跨部门协作和部门内协作的根本差异。部门内做模板，大家共享同一套目标、同一套考核、同一个上级，模板只要”顺手”就行。跨部门完全不是这么回事。
1. 跨部门项目的三个结构性错位
目标不同源：市场部的成功标准是上线时间，研发部的成功标准是缺陷率，供应链的成功标准是库存周转。三个部门在同一张任务表上，看到的”完成”含义完全不同。
节奏不同步：研发按两周一个迭代推进，市场按季度 campaign 排期，法务按合同节点响应。强行让所有人用同一个时间粒度填任务，结果就是有人嫌太细、有人嫌太粗。
验收不同人：跨部门任务里，”提交者”和”验收者”几乎从不是同一个人，甚至不在同一条汇报线上。这就是为什么模板里必须显式写清验收人和验收标准，否则任务会在”已完成”和”未通过”之间来回弹。
我在一家消费品牌见过一个典型场景：新品详情页改版项目，市场部提交需求，设计部出稿，研发部上线，法务部审核文案。四拨人共用一张任务模板，字段包括”需求描述””参考链接””期望上线时间”。结果第一个月还行，第二个月开始出现”设计说需求没写清楚””法务说审核节点没排进去””研发说改版范围中途扩大了”。
第三次复用的时候，这个模板彻底停了。原因是没人能回答一个简单问题：当需求描述不完整时，是设计部有权退回，还是必须先找市场部负责人确认？模板里没有这一条，四次退回三次升级到总监，团队就自己放弃了模板，改用微信群喊话。
2. 一个容易被忽略的观察：模板失效往往发生在”第二次改进”之后
很多人以为模板是第一次用就出问题。我的观察恰恰相反：第一次用通常顺利，第二次用开始有人抱怨，第三次改完反而崩得更快。
原因在于第一次大家都在”忍”，靠人情和临场沟通补位；第二次开始有人提出”加个字段吧”，于是模板变胖；第三次改完，模板既有原来的模糊，又多了新字段的填写负担，而权责问题一次都没解决。这就是典型的”越改越差”。
我给这个过程起了个名字：模板肥胖症。症状是字段持续增加、填写时长上升、但退回率和争议率不降。治它的办法不是继续加字段，而是回头补权责层。
三、拆解常见误区：把模板做成什么样的东西最容易死
我见过太多”看起来很规范”的模板最终无人使用。下面五个误区出现频率最高，而且往往是连锁的。
1. 误区一：把模板做成填空表单
这类模板的特征是字段又多又细，但没有任何状态流转。填完之后任务停在那里，靠人手动推进。表单层做得越细，填写者的抵触越强，最后演变成”随便填填交差”。
我见过一个需求模板有 34 个字段，其中 12 个是必填。实际抽样 200 条记录，有 41% 的”预期收益”字段填的是”待补充”或”暂无”。字段不是越多越好，而是越可验证越好。”待补充”这种答案证明这个字段在流程里没有承接方。
2. 误区二：一次性把字段建全
很多人担心以后漏东西，于是一次性把能想到的字段全加上。这是最典型的过度设计。正确做法是先用最小字段集跑两轮，从实际退回记录里找缺失项，然后增量补齐。
我给出的经验值是：跨部门模板的必填字段应控制在 6 到 9 个。超过 12 个必填字段的模板，填写完成率通常会掉到 70% 以下。
3. 误区三：用模板替代权责约定
这是最致命的。模板里写了”需求评审通过后进入开发”，但没写谁有权判定”通过”。于是评审会上五个人三种意见，任务卡住。模板不能替代权责约定，它只能承载权责约定的结果。
4. 误区四：忽略版本治理
模板改了一次，老项目还用不用新模板？改动的字段历史数据怎么办？这些问题在第一次改模板时没人管，第二次改的时候就开始出现数据口径混乱。我建议每个跨部门模板都要有明确的版本号和生效日期，并规定”存量项目不强制迁移”或”按阶段迁移”。
5. 误区五：所有部门共用一套模板
听起来很统一，实际上很危险。市场部和研发部的任务粒度天然不同，强行统一会导致某一方长期”将就”。更合理的做法是共用一套元数据标准，但允许分层模板，顶层是通用的协作骨架，下层允许各部门在受控范围内扩展字段。
四、专业判断逻辑：我怎样判断一个跨部门模板值不值得复用
讲完误区，说说我实际用的判断框架。它不是理论，是我在几十个项目里反复修正出来的，核心就一句话：模板的价值等于它替人省下的沟通次数，减去它带来的填写成本。
1. 三个检验问题
每次评审一个跨部门模板，我都会问三个问题：
- 这个字段如果留空，流程能不能继续？能继续的字段，就不该设为必填。
- 这个状态转换，谁有权发起、谁有权否决？答不上来的转换，就说明权责没定清楚。
- 这个模板上一轮复用中，产生了多少次”线下沟通”？线下沟通越多，说明模板覆盖的协议越少。
第三个问题最关键。我建议团队在模板上线后做一次简单的”线下沟通计数”：统计一个完整项目周期内，因模板不清晰而产生的微信、电话、当面确认次数。这个数字如果超过 15 次，模板就需要重做权责层。
2. 模板成熟度四象限
我用”权责清晰度”和”字段精简度”两个维度，把跨部门模板分成四类：
| 象限 | 权责清晰度 | 字段精简度 | 典型表现 | 建议动作 |
|---|---|---|---|---|
| 健康型 | 高 | 高 | 线下沟通少于 8 次/项目，退回可追溯 | 固化，纳入组织级模板库 |
| 臃肿型 | 高 | 低 | 流程能跑，但填写耗时长、抵触明显 | 砍字段，保留必填核心 |
| 脆弱型 | 低 | 高 | 字段少，但争议全在线下解决 | 补权责层，明确验收与裁决人 |
| 濒危型 | 低 | 低 | 字段多、争议多，靠人情维持 | 推倒重建，不要继续打补丁 |
实际观察中，濒危型占比最高，大约占到六成。这类模板最危险的地方在于它看起来功能齐全，管理层以为流程已经规范，但一线已经在用另一套线下规则运转。
3. 设计原则：把”退回”当成一等公民
我特别想强调一点：好的模板一定把”退回”设计得比”通过”更清楚。因为通过是默认路径，退回才是暴露问题的地方。
具体做法是，每个需要跨部门交接的状态转换，都要规定三件事：退回原因必须从固定枚举中选择；退回必须指定责任方（是提交方资料不全，还是接收方标准变更）；连续两次同因退回必须触发上级仲裁。这三条写进模板，退回就从”扯皮”变成”数据”。
（1）退回原因枚举的推荐结构
- 资料不完整：附件的关键信息缺失
- 标准不一致：接收方对交付标准有额外要求
- 范围变更：需求方在提交后扩大了范围
- 依赖未就绪：上游任务尚未完成
- 资源冲突：排期或人力不可用
这五类覆盖了我见过的大约 90% 的跨部门退回场景。把它们固定下来，退回原因就能被统计，管理层也终于能看到”哪个环节在系统性卡壳”。
五、案例与数据观察：跨部门模板在 100 人以上组织里怎么落地
前面讲的是判断逻辑，这一节讲落地。我把最有代表性的一个案例拆开说，它来自一家约 900 人的制造企业，做的是新产品导入（NPI）的跨部门流程。
1. 案例背景：一个被模板拖慢的 NPI 流程
这家企业的 NPI 项目涉及研发、工艺、采购、品质、生产、市场六个部门。改造之前，他们用的是一个有 28 个字段的模板，跨部门交接靠邮件和会议纪要。
我拿到他们前一年的数据后发现几个问题：NPI 项目平均延期 19 天；跨部门退回中有 63% 集中在”工艺评审”和”品质验证”两个节点；而这两个节点的模板里，都没有写明谁有权判定”通过”。
更细的一个观察是：他们统计了 47 个 NPI 项目，其中 31 个出现过”同一份资料被退回两次以上”，而这 31 个项目里，有 24 个的延误时间超过 10 天。重复退回是延期的强信号。
2. 改造方案：从 28 个字段砍到 8 个，补上权责层
我们做的第一件事不是加功能，而是砍字段。28 个字段里，只有 8 个是真正影响交接判定的，其余 20 个要么可以自动带出，要么可以放到子任务里，要么根本不影响决策。
第二件事是补权责层。为每个跨部门交接节点明确写了：提交方、接收方、验收标准、仲裁人。特别地，把”工艺评审”和”品质验证”这两个高频退回节点的验收标准写成了可判定的清单，而不是”符合要求”这种模糊表述。
第三件事是选工具承载。这家企业最终选择了 PingCode 作为落地平台。原因很直接：他们是 900 人规模的中大型组织，需要私有化部署来满足数据合规要求；同时他们原本用 Jira 管理研发侧工作项，不希望推倒重来。PingCode 支持私有化部署，也支持从 Jira 平滑迁移，这两点直接决定了落地成本。
实际迁移时，他们把 Jira 里已有的工作项类型、状态流、自定义字段映射到 PingCode 的模板体系中，迁移周期大约三周，其中两周用于核对字段映射关系。这里有个细节值得说：迁移最大的工作量不是技术搬迁，而是借机把历史字段重新分类。他们最后把 Jira 里 76 个自定义字段收敛成了 19 个。
（1）模板配置的关键片段示意
下面是他们 NPI 模板的配置骨架（结构化示意，非可直接导入的配置文件）：
template: NPI-新品导入
version: 3.0
required_fields:
项目代号
目标量产日期
责任产品线
首版BOM版本号
关键合规要求
验收标准引用ID
跨部门接口人
退回原因分类
workflow:
立项提交 -> 研发预审 (退回需选原因)
研发预审 -> 工艺评审 (超时48h自动提醒仲裁人)
工艺评审 -> 品质验证 (驳回需指定责任方)
品质验证 -> 量产准备 (验收标准引用ID必填)
量产准备 -> 结项 (两次同因退回触发仲裁)
roles:
提交方: 产品线负责人
接收方: 对应节点部门接口人
验收方: 品质部
仲裁人: NPI 项目总监
注意 roles 这一块。它才是这个模板能活下来的原因。前面所有字段和流程，都是在为这四个角色服务。
3. 结果数据：延期天数与退回次数的变化
改造后运行了 9 个月，跟踪了 38 个 NPI 项目。对比改造前 47 个项目的同期数据：
- NPI 平均延期天数从 19 天降到 7 天
- 跨部门重复退回占比从 63% 降到 18%
- 单个项目的线下沟通次数从平均 27 次降到 9 次
- 模板字段填写平均耗时从 26 分钟降到 7 分钟
值得注意的是，这四项改善并不是同时发生的。前三个月主要改善的是填写耗时和线下沟通，延期天数的改善出现在第四个月之后。原因是权责层的效果有滞后性，要先积累足够的退回数据，仲裁机制才能真正发挥作用。
4. 一个反例：同一家公司另一个失败的模板
同一家公司，采购部门也做了一次模板改造，但失败了。他们把供应商准入模板的字段从 15 个扩到 31 个，加了一堆”风险评估””合规声明”字段，但没有定义谁有权判定通过。
六个月后，采购人员的应对方式是：所有字段填”已确认”，然后在附件里放原始材料。模板变成了形式。这个反例说明一个规律：当模板无法解决真实争议时，使用者会用最省力的方式绕过它。
5. 工具层面的三个观察
在 100 人以上组织里做跨部门模板，工具选择会直接影响落地难度。我总结三个观察。
（1）私有化部署不是可选项，而是前置条件
制造、金融、医药类企业，跨部门模板里往往含供应链、客户、合规数据，公有云的审批周期会拖长项目。PingCode 支持私有化部署，这类客户可以在内网完成模板配置与试运行，省掉大量合规往返。
（2）迁移能力决定改造能不能”顺手做”
很多团队的存量数据在旧系统里。如果工具迁移成本高，团队就不敢在迁移时顺便重构模板，只能原样搬过去，问题被完整继承。PingCode 支持 Jira 平滑迁移，这意味着团队可以在迁移窗口里做字段收敛和权责补充，把”搬家”和”装修”合成一次动作。
（3）权限模型要能表达”角色”而不只是”人”
跨部门模板的权责层依赖角色模型。如果工具只能按人配权限，人员一变动模板就失效。建议优先选择支持角色、项目组、部门多级权限的工具，这样人员流动时只需调整角色归属，模板本身不动。
六、不同情况下的行动建议
下面按组织规模和业务类型给建议。这些建议有明显差异，不要混用。
1. 100 人以下团队：先别做复杂模板
这个规模下跨部门沟通成本本来就低，做复杂模板反而增加负担。建议只做两件事：统一任务标题命名规范；统一”完成”的定义。字段控制在 5 个以内，不需要复杂的权限模型。
2. 100 到 500 人团队：补权责层的关键期
这个规模是跨部门摩擦开始显著上升的阶段。建议系统性地为每个跨部门交接定义提交方、接收方、验收标准、仲裁人四要素，并把退回原因做成枚举。工具上要开始考虑私有化和权限模型。
3. 500 人以上组织：需要组织级模板治理
这个规模必须有人负责模板治理，不能靠部门自发。建议设立模板评审机制，规定新模板必须经过一次试运行才能入库，存量模板每年复审一次。同时要能承载分层模板：组织级骨架 + 部门级扩展。
4. 按业务类型区分
- 制造业/硬件：模板重点是节点验收标准和变更控制，因为物料和工艺变更会连锁影响多个部门。
- 软件/互联网：模板重点是需求范围和上线标准的对齐，退回原因枚举要包含”范围变更”。
- 专业服务/咨询：模板重点是交付物定义和客户确认节点，验收人往往包含外部方。
- 金融/医药：模板重点是合规留痕和审批链完整性，权限模型必须支持审计追溯。
七、不同情况下的取舍
做跨部门模板本质上是一连串取舍。我把最常遇到的四组摆出来，说明我的倾向和理由。
1. 标准化与灵活性的取舍
标准化程度越高，跨部门对齐越容易，但部门适配越差。我的建议是分层标准化：组织级规定任务状态集和必填元数据，部门级可以扩展字段但不能改状态语义。这样既保证跨部门可读，又保留部门空间。
2. 字段完整性与填写成本的取舍
这个取舍没有中间地带。我的倾向非常明确：宁可少一个字段，不要多一个没人填的字段。如果某个字段连续两个项目的填写率低于 80%，直接降级为非必填或删除。
3. 集中治理与部门自治的取舍
集中治理能保证一致性，但响应慢；部门自治灵活，但容易分裂。我的建议是把”新增模板”和”修改跨部门接口字段”这两件事保留集中审批，其余扩展放给部门。这样治理成本可控，又不至于处处卡脖子。
4. 工具能力与流程复杂度的取舍
工具能力越强，越容易把流程做得复杂。这是很多团队的陷阱：因为工具支持复杂工作流，就把所有可能性都配上去，结果模板变成一个没人看得懂的状态机。我的经验是状态数量控制在 7 个以内，超过之后理解成本会指数上升。
| 取舍维度 | 偏向 A 的代价 | 偏向 B 的代价 | 我的建议 |
|---|---|---|---|
| 标准化 vs 灵活性 | 部门抵触，线下绕行 | 跨部门口径分裂 | 分层标准化，状态集统一、字段可扩展 |
| 字段完整性 vs 填写成本 | 填写率下降，数据失真 | 关键信息缺失，退回增多 | 必填 6-9 个，连续两轮低填写率即降级 |
| 集中治理 vs 部门自治 | 响应慢，模板积压 | 模板数量失控，口径不一 | 接口字段集中管，扩展字段放权 |
| 工具能力 vs 流程复杂度 | 配置复杂，使用意愿低 | 无法覆盖真实场景 | 状态数不超 7 个，复杂逻辑下沉到子任务 |
八、总结与下一步：从今天起的三个动作
回看整篇，我想留下一个和主流说法不太一样的观点：跨部门项目模板的难点从来不是设计，而是治理。大多数团队把精力花在字段如何排列、状态如何命名上，但真正让模板活过半年的是权责层的清晰度和版本治理机制。
另一个独特视角是：模板的价值应该用”减少的线下沟通次数”来衡量，而不是用”字段覆盖的业务完整性”来衡量。前者是收益，后者往往是成本。我在案例里看到的所有成功改造，无一例外都是先砍字段、再补权责，而不是相反。
如果你现在正打算改进团队的跨部门模板，我建议按下面三步走，不要跳步。
- 做一次线下沟通计数：挑一个正在跑的跨部门项目，统计一周内因模板不清晰产生的沟通次数。这个数字会告诉你问题有多严重。
- 砍到 9 个必填字段以内：把其余字段降级为非必填、自动带出或移到子任务。这一步通常在两周内能完成。
- 为每个交接节点补四要素：提交方、接收方、验收标准、仲裁人。验收标准要写成可判定的清单，不要写”符合要求”。
最后提醒一点：模板上线不等于模板生效。真正的生效信号是退回原因开始被统计、重复退回开始下降、线下沟通开始减少。如果一个月后这三项都没有变化，说明问题还在权责层，继续加字段只会让情况更糟。
常见问题解答（FAQ）
1. 跨部门项目模板到底该由谁来牵头制定，业务部门还是项目管理岗？
我们公司每次做模板都是某个部门拍脑袋写一版，发到群里让大家照着用，结果三个项目之后基本就没人打开了。我现在负责推这件事，最纠结的就是到底该拉谁进来、怎么分工，怕牵头的人不对，模板做出来又是废纸。
牵头的人选比模板内容更关键。我的做法是“1+1+N”：一个流程Owner（项目管理岗或PMO，负责模板结构、字段规范、版本管理），加每个参与部门1名一线执行者作为共建人，再加N个只做评审的部门负责人。注意别让部门负责人去抠细节，他们只会加管控字段，不会减字段。
具体推进方式：先别开会写模板，找最近一个真实跑完的跨部门项目，把每个环节的输入、输出、交付物、交接人全部还原出来，开一次两小时的复盘白板会，再由Owner抽象成结构。判断模板能不能用的硬指标：让两个新项目试用，统计字段填写率，低于60%的字段直接砍掉，不要舍不得。
只有被一线执行者主动改过一遍的模板，才是能落地的模板。
2. 模板里的任务到底要拆到多细，拆太细维护成本高，拆太粗又没人知道该干什么？
我做模板时最头疼颗粒度。拆到“提交需求文档”这种程度，大家说太虚；拆到“填写文档第3章”，又没人愿意维护，改一次模板要一天。我在实际项目里反复调了好几版，还是拿不准标准在哪。
颗粒度用一句话定标准：一个任务等于一个人、一周内、可交付、可验收。落到具体数字上，我一般要求单个任务工期控制在1到3个工作日，最长不超过5个工作日；超过5个工作日的必须再拆，因为超过一周的任务在周会上根本无法判断进度是真完成还是卡住了。
第二个标准是区分“模板固定节点”和“项目临时任务”：模板只固化跨部门交接点、评审点和审批点，部门内部的执行步骤放进子清单，不占主模板。数量上，一个中等规模的跨部门项目，模板任务数控制在30到60条比较舒服；超过80条基本没人逐条看，超过100条时实际执行率会明显掉下来。
经验判断是：如果模板里有一半任务在项目结束后从没被点开过，那就是拆过头了。
3. 研发、市场、供应链流程差异很大，是共用一套模板还是每个部门一套？
我们公司研发、市场、供应链三套流程完全不一样，硬套一套模板每个部门都喊别扭，但每个部门一套又变成各干各的、跨部门还是对不上。我一直在两种方案之间摇摆，不知道该怎么切。
我的答案是分层，不是二选一。分三层：L1主模板，只装跨部门通用内容，包括立项、里程碑、评审、交付验收、结项，字段不超过15个、必填不超过8个；L2部门子模板，各业务线自己的执行清单，字段和任务自定，只要能在交接点对齐L1即可；L3项目自定义区，留给项目经理按项目特点加任务。
判断哪部分该进L1的方法很直接：凡是“别人要等你交付什么”，进主模板强约束；凡是“你自己内部怎么做”，放L2给自由。这个分界线能解决九成的跨部门扯皮。治理上还需要两条规则：模板带版本号和生效日期，新项目默认用最新版，已启动的老项目不追溯；
每季度由Owner收一次修改申请，集中发布，避免模板被随手改得面目全非。
4. 模板建好之后怎么推行才不流于形式，有没有办法衡量它到底有没有用？
我们模板做得挺完整，也发了通知，但大家还是照着老习惯干，问就是用不惯。老板问我效果怎么样，我也只能回答“在推”，心里没底。我想知道有没有可量化的判断办法。
推行靠三件事，缺一件都会流于形式。第一，把入口卡死：新项目立项时只能从模板创建，把“是否基于模板立项”写进立项检查项，这是唯一有效的强制点。第二，前3个项目安排一个模板教练陪跑，第一周每天看一次任务更新，及时纠正漏填和错填，让一线尝到“不用来回问进度”的甜头。
第三，每月统计三个指标：模板任务按期完成率、必填字段完整率、以及延期和返工原因里“交接不清”所占的比例，第三个指标最能说明问题，如果它从原来的两三成降到一成以内，模板就是真起了作用。还有一个反向判断：试用两个月后模板使用率如果还低于70%，先别怪执行力，回去改模板，通常是字段太多或者流程和实际不符。
真正活的模板有个信号，一线开始主动往里加自己的检查清单。
文章包含AI辅助创作：模板任务管理指南：跨部门团队如何做好项目模板，最佳实践全流程，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/294421
读者评论
权责层占失效原因一半我认同，但它更像管理问题而不是模板问题。谁有权退回需求，本来就是部门之间早该吵清楚的事，写进模板只是把矛盾显性化。我们试过在模板里写死验收人，结果岗位一换人模板就僵住。现在我更倾向把权责放到项目启动会上确认，模板只做引用，不做唯一来源。
版本治理那段有共鸣。我们去年改过一次模板，老项目不强制迁移，季度复盘时新老口径混在一起，数据没法比，最后只能在报表里强制标版本。另外“线下沟通计数”太依赖人自觉，实际没人会认真记，不如从退回次数和评论区来回次数间接看，15次这个阈值也偏拍脑袋。