项目立项项目编号教程：管理层落地方案，避坑指南

三年前我接手过一个烂摊子。一家约 1200 人的装备制造企业，研发中心同时存在四套项目编号：OA 立项单上是 XM2021-037，项目协作平台里是 PRJ-2021-037，财务系统里是 2021-037，客户合同附件里又是 GK-21-037。同一个项目，四个部门四张嘴，年底做研发投入加计时，两个财务同事花了 11 个人天，硬是没把这 137 个项目对齐，最后差额 400 多万挂在”待核实”科目上。

这件事让我意识到，项目编号看起来是 IT 字段，实际上是管理权力的编码。谁有权生成编号、谁能改编号、编号作废后怎么处理，这三个问题的答案，直接决定了一家公司的立项流程是”有秩序”还是”看起来有秩序”。

这篇文章不打算给你一份模板了事。我会把过去几年在制造、软件、金融三类组织里踩过的坑摊开讲：编号规则怎么设计才不会三年后推倒重来，立项流程在哪一步最容易失控，以及当规则和现实冲突时，管理层应该怎么做取舍。

一、先给结论：项目编号是主键，不是标签

如果你时间有限，只看这一节。剩下的内容都是在解释、验证和补充这三条结论。

1. 三条硬规则，比任何规则模板都重要

第一条：编号只承担唯一标识职责，不承担信息载体职责。很多人设计编号时第一反应是”让人一眼看出这是哪个事业部、哪一年、什么类型的项目”。这个想法很自然，但它把编号变成了一个复合信息字段，而复合信息字段的每一次业务变化，都会逼着你改编号。

第二条：编号的生成权必须收口到一个系统，且只能有一个。只要有第二个系统能”自己生成一个看起来合理的编号”，一物多号就是时间问题。这不是流程制度能解决的，必须靠技术层面的唯一约束。

第三条：编号一旦对外披露（合同、发票、审计底稿、客户交付文档），就永久冻结，永不回收、永不复用。这一条是审计红线，也是很多团队最容易忽略的一条。项目取消了，编号作废，但这个号码必须留在数据库里占位，不能给下一个项目用。

为什么这三条比”用几位数字””要不要加年份”重要得多？因为前三条是不可逆的架构决策，后三条只是可调整的参数。架构错了，参数再漂亮也救不回来。

2. 三种主流策略的真实表现

我见过组织在三种策略之间反复横跳：纯顺序号（如 0001、0002）、纯语义号（如 BJ-RD-2024-AI-018）、以及主键加语义标签的混合方案。它们的差异不在”好不好看”，而在五年之后你还改不改得动。

3. 管理层真正要拍板的只有两件事

立项评审会上，管理层通常会被拉进”编号规则用几位数字”这种细节讨论，这其实是资源错配。真正需要管理层拍板的只有两件事：编号的唯一权威来源是哪个系统，以及编号一旦对外是否可以变更。

这两件事定下来，剩下的技术细节交给架构师和流程负责人即可。反过来，如果这两件事没定，你会在未来两年内不断被同一类问题反复找上门：为什么客户的号和我们系统里的号不一样？为什么这个项目的号在财务那边查不到？

二、背景：一物多号到底是怎么长出来的

没有一个组织是故意把编号搞乱的。乱，是四个发源地在不同时间点各自”合理地”解决问题后叠加出来的结果。

1. 编号的四个发源地

发源地一：OA 或流程审批系统。立项申请单提交时，审批流引擎为了给单据一个标识，自动生成一个流水号。这个号在设计者看来只是”表单号”，但业务同事会自然地把它当成项目号用起来。

发源地二：项目协作平台。项目创建时需要唯一标识，平台按自己的规则生成。如果平台接入晚于 OA，就会出现”OA 号”和”平台号”两套并存。

发源地三：财务或 ERP 系统。财务需要按项目归集成本，通常会建一套”项目辅助核算编码”，规则往往由财务口径决定，与研发口径无关。

发源地四：业务侧的手工台账。这是最隐蔽也最顽固的一个。销售、交付、售前各自维护 Excel，用自己顺手的方式编号，比如 2024Q1-华东-某客户-01。

这四个发源地的问题不在于它们各自错了，而在于它们之间没有主从关系。当四个系统都能生成编号，且没有任何一个被明确为权威源，一物多号就是必然结果。

2. 编号错乱的隐性成本在哪

编号混乱的直接成本很容易被低估，因为它不体现为某一笔支出，而是分散在很多人的日常摩擦里。我把它归成四类：查询成本、对账成本、审计成本、决策成本。

查询成本最好理解。跨部门要找一个项目的历史资料，得先在四个系统里做一次模糊匹配，平均一次 20-40 分钟。按一个 500 人研发组织每月 60 次跨部门查号估算，一年约 480 人时。

对账成本更贵。成本归集、工时归集、里程碑验收三条线要按项目汇总，编号不一致就必须人工映射，而我见过的人工映射表，通常在第三个月就开始出现维护滞后。

审计成本是偶发但剧烈的。外部审计要抽样核对项目投入，如果编号不统一，取证时间会成倍放大。这是我在开头那个案例里花了 11 个人天的直接原因。

决策成本最隐蔽。当管理层想统计”今年 AI 类项目的总投入”，如果项目类型只写在编号里、没有独立字段，那这个统计就只能靠人工筛选。编号承担了它不该承担的分析职责，分析能力就被锁死了。

3. 为什么组织越大，问题暴露得越晚

一个 80 人的团队用手工台账也能活得不错，因为所有人都在一个群里，信息靠人脑同步。到 300 人，开始出现”这个号是哪个项目”的日常提问。到 1000 人以上，问题不再是提问，而是报表不可信。

这里有个反直觉的规律：编号体系的崩溃不是渐进的，而是阶梯式的。它在某个规模阈值之前几乎看不出问题，跨过阈值之后突然变成全组织的公共议题。中间那段”看起来还行”的时期，恰恰是最危险的，因为管理层会觉得没必要投入改造。

三、七个常见误区

下面七个误区，是我在项目复盘里出现频率最高的。它们大多不是认知错误，而是”当时看起来合理”的选择。

1. 语义化崇拜：把管理信息全塞进编号

我见过最夸张的一套编号是 集团-华东-研发中心-智能硬件部-AI算法组-2024-预研-018，38 个字符。设计者的初衷是”一眼看懂”，实际结果是三层组织调整后，这套编号的含义已经和现实对不上，但没人敢改，因为改了历史数据就断链。

判断标准很简单：如果一个字段在未来三年内可能变化，它就不应该进入编号。组织架构会变，项目类型会变，年度会跨，预算等级会调，这些都不该进编号。

2. 用业务字段代替编号

另一种常见做法是”不用编号，直接用项目名称当标识”。短期内很顺，因为名字好记。但它有三个致命问题：名称会改、名称会重、名称无法做唯一约束。

我遇到过两个不同事业部在同一个季度各立项了一个叫”数据中台建设”的项目，在报表里直接合并成了一个，管理层看到的是”一个 2000 万的项目”，实际是两个 1000 万的项目。

3. 让编号跟着组织架构走

编号里带事业部代码，在组织稳定期是个好设计。但只要发生一次合并、拆分或者职责重组，历史编号立刻变成”旧世界的地图”。

更麻烦的是，编号一旦对外披露过，你就不能重编。于是组织会陷入”新旧两套规则并存”的状态，而且这种并存往往没有明确的终止时间。

4. 允许人工修改编号

只要系统里留了”编辑编号”这个按钮，就一定有人会去点。原因通常很正当：录入错了、客户要求改、领导觉得不好看。但每一次修改都会在下游产生一次断链，而修改者通常看不到下游。

正确做法是：编号生成后不可编辑，只能作废重建。同时把”作废重建”的操作记录纳入审计日志，并要求填写原因。

5. 不做作废占位，直接复用编号

项目取消了，把编号释放出来给下一个项目用，这在数据库层面很自然，在管理层面是灾难。因为历史文档、邮件、会议纪要里还残留着旧编号的引用，复用之后，你无法判断某份三年前的文档指向的是哪个项目。

6. 编号规则没有明确责任人

我问过很多团队”你们的编号规则文档谁维护”，答案通常是”之前是谁谁搞的，他离职了”。规则没有 owner，就会在每一次组织变动中退化。

编号规则应当被视为一份需要版本管理的制度资产：有 owner、有版本号、有变更评审记录、有生效范围说明。这件事的成本很低，收益周期很长。

7. 忽略外部系统的编号约束

很多团队只考虑内部系统，忘了外部约束：客户合同编号体系、供应商协同平台、政府科技项目申报系统、集团合并报表口径。这些外部编号往往无法修改，只能做映射。

所以编号体系设计时，必须留一个”外部别名映射表”，把外部编号和内部主键关联起来。这个映射表的价值，会在第一次外部审计时体现出来。

四、专业判断逻辑：怎么设计一套能用五年的规则

前面讲的是”不要做什么”，这一节讲”应该怎么做”，以及每一步背后的判断依据。

1. 编号只需要回答一个问题

很多人设计编号时想让它回答五个问题。我的建议是：编号只回答一个问题，它是哪个项目，且全球唯一。其他所有问题（哪个部门、哪一年、什么类型、什么优先级），都由独立的属性字段回答。

这个原则有个直接推论：当有人问你”能不能在编号里加上年份”，标准回答是”年份放进独立字段，编号不变”。这不是偷懒，而是把变化的部分和不变的部分解耦。

2. 分层设计：主键 + 语义标签 + 外部别名

我推荐的结构是三层：主键层保证唯一与稳定，语义标签层满足人类可读性，外部别名层对接不可控的外部体系。

主键层设计为短、稳定、无业务含义。语义标签层通过独立的字段（组织、年度、类型、客户）实现，可以在系统界面里和编号并排展示，让人一眼看懂，但它不参与唯一性约束。

外部别名层是一张映射表，记录客户合同号、政府申报号、集团口径号等。这张表允许一对多，因为一个项目可能对应多份合同。

3. 字符集与长度的工程约束

编号的字符集和长度不是审美问题，是工程问题。我总结了几条硬约束，这些约束在跨系统对接和人工录入场景下都验证过。

• 只用大写字母和数字，避免中文、空格、下划线以外的符号，因为很多老系统的字段定义不支持。
• 剔除易混淆字符：O 与 0、I 与 1、S 与 5、Z 与 2。电话口述编号时，这四个混淆点是错误高发区。
• 总长度控制在 16 字符以内。超过这个长度，Excel 手工录入的错误率会明显上升，且在移动端展示会被截断。
• 避免使用连字符超过 2 个。连字符过多会导致不同系统在解析时切分规则不一致。
• 年度只用 2 位纪元位，且纪元位不进唯一性约束，避免跨年项目产生歧义。

4. 生成规则的参考实现

下面这段代码是我在多个项目里用过的最小可用版本。核心思路是：编号只由组织别名、纪元位、全局流水三段构成，且强制做易混淆字符替换。

import re
易混淆字符映射：O->0, I->1, L->1, S->5, Z->2

CONFUSABLE = str.maketrans({"O": "0", "I": "1", "L": "1", "S": "5", "Z": "2"})

def build_project_code(org_alias: str, seq: int, epoch: int = 2024) -> str:

"""

org_alias: 组织别名，如 'RD'、'MFG'

seq:       全局流水，由数据库序列产生，只增不减

epoch:     纪元起始年，仅用于分组展示，不参与唯一性判断

"""

org = re.sub(r"[^A-Z0-9]", "", org_alias.upper())[:4].translate(CONFUSABLE)

era = (epoch - 2000) % 100

return f"{org}-{era:02d}-{seq:05d}"

数据库层面必须加唯一约束，这是编号体系的技术地基。没有这个约束，再好的流程制度都会被绕过。

CREATE TABLE project_code (
code VARCHAR(16) NOT NULL PRIMARY KEY, — 对外主键，一经分配不可变更

org_id BIGINT NOT NULL, — 归属法人或组织

seq_no INT NOT NULL, — 组织内全局流水，只增不减

status CHAR(1) NOT NULL, — A=激活 V=作废 P=预占

issued_at DATETIME NOT NULL,

deprecated_at DATETIME NULL,

source_system VARCHAR(32) NOT NULL — 申请来源系统，便于追溯

);

— 流水号在组织内唯一，防止并发分配重复

CREATE UNIQUE INDEX uk_org_seq ON project_code (org_id, seq_no);

status 字段是这套设计的灵魂。作废的编号保留记录、状态改为 V，永不删除、永不复用。这样既满足审计要求，又不会出现”历史文档指向错误项目”的问题。

5. 权限、占位与审计

编号的权限设计要区分三个动作：申请、分配、作废。申请权可以下放给业务侧，分配权必须由系统自动化，作废权应当收口到项目管理办公室或同等职能。

为什么不把分配权也下放？因为人工分配必然面临”留号”的压力。某个部门觉得下个月有个大项目，想先占一个好看的号，这种需求一旦被满足，编号的连续性就被破坏了。

审计方面，至少要记录四类事件：编号分配、编号作废、外部别名新增、语义标签变更。这四类日志在外部审计时是直接证据，平时也能帮你定位”为什么这个项目在报表里换了部门”。

五、案例：一个 1200 人研发组织的编号重构

这是我在开头提到的那个案例的完整复盘。组织是一家装备制造企业，研发 + 制造 + 交付合计约 1200 人，年立项量约 300 个。所有数据为脱敏后的观察结果。

1. 起点：四个系统，四套编号，两个影子台账

重构前的状态是典型的”四发源地”格局：OA 立项单生成 XM+年度+3位流水，项目协作平台生成 PRJ+年度+3位流水，财务系统有独立的辅助核算编码，销售侧维护一套客户口径编号。

更麻烦的是，我们还发现了两个影子台账：一个在研发管理部的共享盘里，一个在某位资深项目经理的个人笔记里。这两个台账的存在说明，官方系统已经无法满足一线查询需求，这是体系失效的明确信号。

2. 方案：三层结构 + 一次性映射，不做渐进式过渡

我们最终选择的方案是三层结构，主键采用 4 位组织别名 + 2 位纪元位 + 5 位全局流水，总长 13 字符。语义信息全部落到独立字段，外部别名单独建表。

一个关键决策是：不做渐进式过渡，而是选择一个财年边界做一次性切换。渐进式过渡听起来稳妥，但实际上会让新旧两套编号长期并存，一线同事需要同时掌握两套规则，错误率反而更高。

另一个决策是保留”历史编号查询入口”。老编号不作废，而是作为别名登记进映射表，任何人在系统里输入老编号都能直接跳到对应项目。这个功能上线后，一线对新体系的抵触情绪明显下降。

3. 迁移过程：三批次，每批 100 个项目

迁移分三批执行：第一批 100 个在建项目，第二批 100 个近两年结项项目，第三批剩余历史项目。每批迁移后做一次数据校验，校验项包括编号唯一性、成本归集完整性、干系人可见性。

第一批迁移暴露了一个我们没预料到的问题：有 7 个项目的财务归集数据跨越了两个辅助核算编码，说明历史上有人工调整过。这类问题在迁移前很难预知，只能通过实际迁移数据反查。

4. 数据表现：上线 6 个月后的对比

上线 6 个月后，我们做了一次前后对比。需要说明的是，这些数字来自该组织的内部统计，样本量有限，不能直接外推，但趋势是有参考价值的。

5. 工具侧的选择逻辑

这个案例里，项目协作平台承担了编号分配和语义标签展示的核心职责。我们的评估标准有三条：能否强约束编号唯一性、能否自定义编号生成规则、能否承载私有化部署。

第三条对这家企业是硬性要求，因为涉及研发图纸和工艺参数，数据不出内网。我们最终落地的是一套国产项目管理平台方案，支持私有化部署，同时提供了从既有国外协作工具平滑迁移的路径和工具链。

在评估过程中，我们重点验证过 PingCode 这类面向中大型企业（主要服务 100 人以上组织）的项目管理平台。它的优势在于自定义字段和唯一性约束能力比较完整，编号生成规则可以按组织维度配置，本地化部署和迁移支持也比较成熟，适合作为国产替代方案纳入候选。但我也要诚实说一句：工具能解决的是”技术层唯一性”，解决不了”管理层唯一性”。如果组织内部没有就”谁是权威源”达成一致，再好的平台也只是多了一个生成编号的地方。

顺带提一个评估细节：我们在做工具选型时，让每个候选平台跑了同一组 30 个边界用例，包括并发分配、作废重建、跨组织流水、外部别名一对多。这一轮测试淘汰了两个看起来功能很全的平台，因为它们在”并发分配流水号”这个场景下会出现重号。这个测试方法后来成了我们团队的标配。

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

没有一套编号规则适合所有规模的组织。下面按规模给出建议，但请注意，规模只是参考，真正的判断依据是立项频率、组织调整频率、外部对接方数量这三个变量。

1. 50 人以下：先用最简规则，别过度设计

这个规模下，全员在一个沟通群里，编号的主要作用是文档引用。建议采用 2 位组织别名 + 3 位全局流水，总长 6 字符即可。

不要设置语义字段，不要做复杂的审批流，不要买重型的项目管理平台。这个阶段最大的风险是过度设计，一旦规则复杂到需要专人维护，反而会拖慢立项速度。

2. 50 到 200 人：建立唯一性约束，引入系统承载

这个阶段会出现第一个明显信号：开始有人问”这个号是哪个项目”。此时应该做的三件事是：建立编号主表并加唯一约束、明确唯一权威生成系统、停止使用 Excel 手工编号。

编号规则建议 3 位组织别名 + 2 位纪元位 + 4 位流水，总长 11 字符。语义标签以独立字段形式存在，可以在列表页和详情页展示。

3. 200 到 1000 人：三层结构 + 外部别名映射 + 审计日志

到了这个规模，跨部门对账会变成常态。三层结构不再是可选建议，而是必需项。同时必须建立外部别名映射表，因为客户合同号和政府申报号的数量会显著增加。

还要开始考虑权限分层：谁可以申请、谁可以作废、谁可以修改语义标签。这三个动作的权限应该分别配置，不能打包成一个”项目管理员”角色。

4. 1000 人以上或集团型组织：编号治理委员会 + 主数据管理

集团型组织的核心问题不是规则设计，而是多法人主体之间的编号主权。每个法人可能都希望保留自己的编号前缀，但集团报表又需要统一口径。

可行的做法是采用双层编号：集团层主键保证全局唯一，各法人主体保留自己的业务别名。报表在集团层用主键聚合，业务系统在法人层用别名展示。

这个阶段还应该把编号纳入主数据管理范畴，明确数据 owner、数据质量指标和定期巡检机制。编号质量应该作为一项可度量的管理指标，比如重号率、缺失率、映射覆盖率。

七、取舍：当规则和现实冲突时怎么选

规则设计得再完整，落地时也一定会遇到冲突。这一节讲四个必须做取舍的场景，以及我的判断依据。

1. 语义可读性 vs 长期稳定性

这是最核心的一组取舍。可读性满足的是”当下的沟通效率”，稳定性保障的是”五年后的数据连续性”。两者在短期内并不冲突，冲突点出现在组织调整时。

我的判断是：当组织年调整频率高于 30% 时，坚决选稳定性。因为语义编号在每次调整后都要重编，重编意味着历史报表断链，而断链的修复成本远高于当下的沟通成本。

如果组织非常稳定，语义编号的收益确实更大。但要注意，”稳定”是个需要证据的判断，不是感觉。用过去三年的组织调整记录来验证，而不是用”我们这几年挺稳定的”这句话。

2. 全局统一 vs 各主体自治

统一编号的好处是报表可聚合，坏处是需要各主体放弃部分自主权。自治的好处是灵活，坏处是跨主体协作时摩擦不断。

我的建议是分层处理：唯一性必须全局统一，展示口径可以允许自治。也就是说，全局只有一个编号分配服务，但各主体可以在自己的界面里用自己的别名展示，只要底层主键一致。

这个方案的技术实现不复杂，难的是让各主体接受”你看到的号不是系统真正的主键”这个概念。这需要管理层明确表态，否则会在实施阶段被反复挑战。

3. 一次到位 vs 渐进式过渡

很多团队倾向渐进式，因为风险看起来更小。但从我的实际经验看，渐进式过渡在编号这个场景下通常更危险，因为它会产生长期的双轨制。

双轨制期间，一线同事需要同时掌握两套规则，错误率反而更高；而且”过渡期”往往会因为业务压力无限延长，最终变成永久状态。

更稳妥的做法是：用足够长的时间做迁移准备，但在切换时选择一个明确的时间点做一次性切换，同时保留老编号的查询入口作为缓冲。这样既保证了新体系的纯净，又降低了用户的迁移痛感。

4. 自建 vs 采购平台能力

编号分配服务的技术难度不高，理论上自建完全可行。但实际决策时要考虑三件事：并发下的唯一性保证、与项目全生命周期的耦合度、长期维护成本。

如果你已经有成熟的项目管理平台，优先用平台的原生能力，因为编号天然要和项目全生命周期绑定，立项、执行、变更、结项、归档。自建一个独立的编号服务，意味着你要维护两套系统之间的同步逻辑，这个同步逻辑在项目变更场景下最容易出错。

如果你的项目管理平台不支持自定义编号规则和唯一性约束，那自建一个小服务是合理的。但要记住，自建服务的权威性必须和平台对齐，不能让平台也能生成编号。

八、落地检查清单与高频问答

这一节是可以直接拿去用的部分。清单建议在立项体系上线前逐条核对，问答部分是过去几年被问得最多的问题。

1. 上线前必查的十条清单

1. 唯一权威源是否明确：全组织是否只有一个系统可以生成项目编号。
2. 数据库唯一约束是否落地：不是靠流程约定，而是靠 DDL 层面的约束。
3. 编号是否不可编辑：系统界面是否有”编辑编号”入口，如果有，是否已关闭。
4. 作废是否保留占位：作废记录是否物理保留，状态字段是否区分激活与作废。
5. 外部别名映射表是否建立：客户合同号、政府申报号、集团口径号是否已登记。
6. 老编号是否可查：历史编号是否有查询入口，能否直接跳转对应项目。
7. 语义标签是否独立成字段：组织、年度、类型、客户是否都是独立字段而非编号组成部分。
8. 权限是否分层：申请、分配、作废三个动作的权限是否分别配置。
9. 审计日志是否覆盖四类事件：分配、作废、别名新增、标签变更。
10. 规则文档是否有 owner 和版本号：是否纳入制度资产管理，而非某位同事的个人文档。

2. 高频问答

（1）项目编号里到底要不要放年份？

不要放进编号本身，放进独立字段。原因是跨年项目的存在会让年份前缀产生歧义，一个 2023 年立项、2025 年结项的项目，该算哪一年？放进独立字段后，你可以同时维护”立项年度”和”结项年度”两个属性，比在编号里塞一个年份更有分析价值。

如果确实需要一个时间锚点便于人工识别，可以用 2 位纪元位（表示编号体系启用的年份），它的作用是分组而非标记项目年度。

（2）已经乱了五年，还能改吗？

能改，但要接受两个前提：一是历史数据必须做映射，二是映射工作量的三分之一在数据清洗，三分之二在跨部门确认。我的经验值是，1000 人规模组织的完整迁移，映射阶段通常需要 4 到 6 周。

另一个建议是：不要试图让历史编号变”整齐”。历史编号的唯一目标是可追溯，不是好看。把老编号作为别名登记进映射表就可以了。

（3）项目取消后编号要不要释放？

绝对不要释放。作废的编号必须保留占位记录，状态标记为作废。这是审计红线，也是防止历史文档指向错误项目的唯一手段。如果因为编号资源紧张想要释放，说明你的流水位数设计得太短，应该扩位而不是复用。

（4）多组织共用一套编号还是各用各的？

唯一性判断必须全局，展示可以分组织。技术上的实现方式是全局流水 + 组织前缀，或者全局流水 + 组织维度索引。选择哪种取决于你的报表聚合需求。

如果集团报表需要跨法人聚合，全局流水更省事；如果各法人主体有强合规要求需要独立编号段，那就用组织前缀加组织内流水，同时维护一个全局映射。

（5）编号规则多久评审一次？

建议每年一次常规评审，外加两个触发式评审：组织架构重大调整时、立项流程发生变更时。评审的内容不是”要不要改规则”，而是”当前规则是否仍然匹配业务现实”。

绝大多数年份的评审结论应该是”不修改”。频繁修改编号规则本身就是一种风险，因为它会让规则失去权威性。

结语：编号是管理秩序的显影剂

回到开头那个案例。真正让那家企业痛苦的，不是编号不好看，而是没有人对编号的权威性负责。四个系统各自生成编号，每个系统当时都做对了自己范围内的事，叠加起来就成了一场持续数年的对账噩梦。

我在这篇文章里反复强调一个判断：编号不是标签，是主键。这句话听起来像技术细节，但它的管理含义很重，主键意味着唯一、稳定、不可变、有明确的责任主体。一个组织如果连项目编号的唯一性都无法保证，它在其他管理数据上的可信度也值得怀疑。

如果你打算动手，我建议按这个顺序推进：先用第八节的十条清单做一次自评，找出得分最低的两三项；然后只解决最高优先级的那一项，不要一次性推全量改造；改造完成后再跑一次自评，用得分变化验证效果。

最不推荐的做法，是先从”设计一套完美的编号规则”开始。规则可以慢慢调，但权威源的收口和唯一性约束的落地，越早越好。这两件事一旦做成，后面所有的规则优化都有了地基。