数字资产维护手册

系统方法见教程（tutorial/asset/batch-maintain.md），分类定义和治理原则见本体手册（asset/index.md）。本章提供迭代维护的操作流程和检查清单。

核心策略¶

不要在抽象层规划维护方案。先迭代，从有数据的地方开始。

传统维护思路是"先规划好结构，再填充内容"——但这在知识管理领域行不通，因为你根本不知道什么东西会留下来、什么东西会被抛弃。正确做法是反过来：先有数据，再从数据里长制度。

具体来说，数字资产的迭代式维护分为四步：

第一步：锁定有数据的地方¶

不依赖"应该有什么"的想象。找正在产出的数据流——邮件记录、工单统计、代码仓库日志、对话记录。只要这些数据是真实的、可分析的，它就是你的起点。

判断标准：一条数据如果让你联想到"这里好像有个规律"或"这里好像有问题"——那就是对的起点。不需要规范的数据集，真实的就行。

今天的工作就是从招聘邮件数据开始的。没有设计问卷，没有理论框架，直接拉出 INBOX/SENT 的邮件记录就看到了模式：32% 的申请者只发了附件没写正文，公司发笔试模板时雷同度极高。这些数字不是分析报告的副产品——它们是制度产生的起点。

第二步：从数据中提取问题清单¶

数据不会直接告诉你制度该怎么写，但它会暴露问题。把问题列出来，不要急着想答案。

从数据到问题的转换方法：对每条数据问两个问题——

1. 这个记录反映了什么行为？（如：申请者只发附件没写正文——行为是"不写字"）

2. 这个行为是否应该被制度约束？（不写字不是问题，因为系统能通过附件匹配。但回复语气不一致、模板标准化不足、对外沟通无统一规则——这些是问题）

保留那些"应该被约束"的问题，去掉那些"虽然看起来不规范，但当前业务不需要管"的问题。这一步不需要追求全面，重要的是不要跳过问题直接跳到方案。

第三步：把问题清单转成可检验的标准¶

每个问题都要对应一条可检验的标准。可检验的意思是：任何人拿着这条标准的描述，都能判断当前行为是否符合它。

不可检验的标准：“沟通要友好”——什么叫友好？谁来定义友好？ 可检验的标准：“对外沟通不得包含内部术语缩写，必须全部展开”——谁都能判断这句话违反了没有。

转化的原则：标准不限制定量，但要可判定。 有些标准不需要定量（如"不得有事实错误"），但必须是"有人说你错了就成立"——不可辨驳。

在我们今天的工作中，这一步产出了"零理解负担"原则：没有事实错误、没有理解负担、不做多余修饰。这个原则不是拍脑袋想出来的，是从 463 封邮件里看出来的——那些写得"友好但啰嗦"的邮件，和那些写得"直接但清淅"的邮件，读者理解时间差了两个数量级。

第四步：根据不同资产的定位维护¶

标准出来后，分别更新章程、手册、教程。这三者的定位不同，维护方式也不同：

同步不是事后补的——每次新增标准时，三个文件一起改。改动量可以很小，但必须同时。

迭代周期建议¶

不要在第一次迭代时追求完整。 每次迭代只处理当前数据暴露的问题，不预测未来会有什么问题。

判断标准：如果某次迭代后，章程的条款已经不需要大改，只是小修小补——那就意味着底座铺好了，可以从迭代维护切换到日常维护。

检查清单¶

开始新一轮维护前，对照以下清单：

• 有真实数据吗？ 不是"我感觉"，而是"数据说"

• 问题从行为出发，而不是从概念出发？ 不要写"沟通质量不够好"，要写"X% 的外部沟通邮件包含了未展开的内部术语缩写"

• 每条标准都可检验？ 能找到一条"如果有人说它违反了，你无法反驳"的判定证据

• 三件套同步了？ 章程条款 + 手册模板/清单 + 教程解释，三者一致

• 只解决当前暴露的问题？ 没有试图预测或预防未来的问题

• 写回记录了？ 有价值的发现记下来了，不需要在笔记系统里再回想一遍