我管了四年的合同模版库，一直以为它挺整齐。
2022年我在公司推人力合同电子化，从模板到流程，从编号到归档，基本都是自己一点点搭起来的。几百个 Word 和 PDF 躺在电脑文件夹里，按主体年份分层、按类型归档、按项目编号，平时找一个文件，十秒之内大概率能定位。
我甚至一度觉得，这套东西虽然谈不上什么专业系统，但放在中小公司里，已经算是一笔很有价值的资料资产。
最近一段时间，我开始大量使用各种 AI Agent。跑通了几个流程之后，越用越顺手，也逐渐有了一点“什么都可以交给 AI 试试”的底气。
于是我突发奇想：这套合同库我已经管了四年，自己当然觉得很熟，但如果让 AI 从一个完全陌生的视角重新扫一遍，会不会发现一些我早已经习以为常、其实根本没有真正治理过的问题？
说干就干。
结果三天下来，原本以为只是做一次文件整理，最后坑越挖越大……变成了一套电子签管理系统的重构。
这三天大致完成了七层工作：
- 打通腾讯电子签、钉钉和本地文件库三端的技术入口。
- 对本地几百个历史合同文件建立资产台账，做 Hash、正文提取、重复识别、相似度比对和版本关系判断。
- 开始真正物理治理文件，包括归档、移动、重复副本处理和目录收口。
- 以腾讯电子签生产环境为事实基线，把本地库重构成“生产模板研发项目库”。
- 把模板修改、上线、下线等规则正式写成制度和申请流程。
- 在没有钉钉 OA 审批权限的情况下，用多维表格和工作流搭了一套实际可运行的轻量审批系统。
- 把反复验证过的能力整理成 Agent Skill，让后续类似项目不用再重新试命令、翻日志、踩同样的坑。
只看结果，这几天做的是一套电子签系统治理。
但对我来说，更有价值的是整个过程本身。
第一天：先把家底摸清，也走了一段弯路
第一天的工作量其实很大。
腾讯电子签
先把生产环境 API 跑通，确认了集团企业体系、模板列表、子企业代理查询能力，也验证了集团主账号能够读取成员企业自己的模板。
钉钉
定位了“人力法务文档共享群”，确认了群文件空间、目录结构，以及钉钉知识库、群文件、在线文档等能力。
本地合同库
几百个 Word、PDF 和其他历史文件全部建立资产台账，开始计算 Hash、提取正文、识别重复、判断相似度和版本关系。
第一轮处理了 348 个业务文件，其中 281 个进入正文治理链路，覆盖率超过 80%。
从技术角度看，这一步做得其实很完整。
但也是在这一天，我慢慢发现方向有问题。
最开始的想法很自然：
历史文件这么乱，那就把它们全部整理清楚。
于是开始建立：
- 哪个文件是什么版本；
- 两个文件之间是什么关系；
- 哪个是地区派生；
- 哪个是主体派生；
- 哪个是合集；
- 哪个是历史版本。
AI 很擅长这种工作。
只要继续做下去，它可以不断增加字段、不断建立关系、不断完善分类，最后形成一个极其完整的历史文件数据库。
但做到一半以后，我突然意识到：
这很可能只是一个非常精细的“文件历史图书馆”。
里面什么都有，也都能追溯。
但未来真正维护电子签模板的人，仍然不知道：
- 生产上到底用的是哪个；
- 对应的开发源文件在哪里；
- 下次要修改哪个 Word；
- 一个生产 PDF 到底是单独开发的，还是由多个组件拼出来的。
后来我才意识到，第一天最大的偏差，其实不是分类方法错了，而是治理对象选错了。
我要管理的，不应该是 348 个物理文件。
真正要管理的，是那些具有实际业务意义的模板对象，以及它们的：
开发源、生产版本、历史版本、组件关系和状态。
文件只是资产，不应该天然成为整个治理体系的中心。
历史文件的价值也不是无限的。
如果一个版本已经退出生产，又没有继续维护价值，它只需要被正确归档，而不需要继续参与未来的主要治理。
这个认识改变了后面两天的方向。
第二天：从“管理历史文件”改成“管理生产模板”
真正的转折，是把治理对象从“文件”改成了“生产模板”。
后来确定了一条很重要的原则：
腾讯电子签生产环境中的每一个正式模板，都应该在本地有一个唯一、明确、可维护的开发对应物。
于是整个目录体系重新设计。
不再问：
“本地这 348 个文件应该怎么分类？”
而是反过来问：
“生产环境现在到底有哪些正式模板？每一个模板在本地对应什么？”
最后建立了 59 个生产模板项目。
每个项目都有对应的生产 PDF、项目信息和开发源文件状态。
处理原则也逐渐变得清楚：
- 已经存在唯一 Word 源文件的，直接归入对应项目；
- 生产模板本身是多个文件组成的合集，就按版本族和组件管理；
- 生产上有 PDF，但本地没有可信可编辑源文件的，就列入 Word 高还原重建清单。
最终 59 个生产模板中：
- 6 个已经确认有唯一 Word 开发源；
- 10 个属于组件或合集型项目；
- 43 个需要后续重新建立高还原 Word 源文件。
之前不确定的源文件关系，也逐步清零。
这时候本地库的性质已经完全变了。
它不再是一个“存历史合同的文件夹”。
而开始变成一个真正意义上的：
生产模板研发项目库。
每一个生产模板都可以看成一个独立的小型开发项目：
- 有生产发布物；
- 有开发源文件；
- 有历史版本；
- 有组件；
- 有审计记录；
- 有稳定 ID。
从这一刻开始，这套东西才真正变得可维护。
第三天：从“后台治理”进入“实际使用”
前两天解决的是底层资产问题。
第三天开始解决的是：
这套东西以后到底怎么给人用。
上午：接入聊天机器人
最开始试过本地群机器人。
链路其实已经跑通了，但后来直接放弃。
原因很简单：
如果机器人的“大脑”运行在我自己的电脑上，那么电脑关机、重启以后，它就停止工作。
这种方案不适合作为公司的长期系统。
后来改用钉钉原生智能助理。
建立了“电子签系统助手”，接入合同知识库，并加入“人力法务文档共享群”。
实际测试时，在群里 @电子签系统助手 查询劳动合同，可以直接返回相关模板和文档链接。
到这里，普通使用者已经不需要自己翻目录。
只需要问。
中午：把制度收口
把合同模板修改与发布规则重新整理了一遍，包括：
- 模板修改；
- 临时文档上线；
- 临时文档删除；
- 正式模板下线；
- 验收。
原本分散的纸质申请表也重新做了收口，减少不必要的表单。
下午到晚上：搭在线业务流程
因为没有钉钉 OA 审批系统的权限，我没有继续纠结 OA，而是直接用：
钉钉多维表格 + 自动化工作流
做了一套轻量审批系统。
目前已经建立三张业务表：
- 模板修改审批；
- 临时文档上线及删除审批；
- 模板文档下线申请。
后台对应 6 个工作流。
流程中包含：
- 部门负责人；
- 法务；
- 财务条件分支；
- 产品设计；
- 产品研发；
- 集团办条件分支；
- 验收。
提报人自己选择审批人，每个审批节点限制一个人。
涉及收付款时才进入财务，满足特定条件时才进入集团办。
审批消息可以直接跳转查看申请详情。
提交以后自动生成标题。
附件根据申请类型控制显示。
这一阶段踩的坑非常多：
- 工作流 DSL；
- 按钮数量限制；
- 条件分支 default 节点；
- 字段隐藏；
- 审批人多选；
- 触发循环；
- 管理员视角和普通用户权限差异。
但最后 6 个工作流已经全部进入运行状态。
到这个时候，这个项目已经不再只是“电子签模板治理”。
它开始变成一个真正的内部信息系统。
三天下来，一套完整链路已经成型
现在把这些东西连起来看：
- 生产层：腾讯电子签是真实运行版本；
- 开发层：本地生产模板项目库，负责开发源文件和版本维护；
- 知识层：钉钉知识库，负责制度、模板说明和知识沉淀；
- 查询入口：智能助理，使用者只需要问；
- 流程层：多维表格和工作流，负责修改、上线、下线和审批；
- 审计层：治理台账和日志，负责审计和追溯；
- 自动化层：Agent Skill，把已经验证过的操作能力重复利用。
这三天最重要的成果，并不是做了多少个文件夹、多少个字段或者多少个工作流。
而是终于把过去分散在：
腾讯电子签后台、钉钉群文件、各种 Word 和 PDF、个人电脑目录、聊天记录、人工经验里的东西，逐步收到了同一套治理逻辑里面。
比项目本身更重要的：几个新的工作认识
1. 一个新的技能点：开始保存“Agent 的能力”
过去使用 AI，很多经验其实是一次性的。
这个项目里碰到一个问题，就现场研究一次：
- 钉钉知识库怎么读；
- 群文件怎么操作；
- 腾讯电子签子企业怎么查询；
- 工作流怎么更新；
- 哪些操作必须使用稳定 ID；
- 哪些 API 表面返回成功，实际上根本没有完成修改。
如果这些经验只留在聊天记录里，下次换一个项目，还要重新找。
所以第三天我第一次比较系统地，把已经验证过的操作能力单独抽离出来，做成一个全局的 enterprise-doc-ops Skill。
里面不保存这个项目的数据。
而是保存：
- 怎么做；
- 哪些方法已经验证过；
- 哪些方法已经失败过；
- 权限边界是什么；
- 高风险操作怎么确认；
- 哪些坑以后不要再踩。
以前会保存代码、保存脚本、保存文档模板。
现在开始需要保存：
Agent 的能力。
这对我来说是一个新的技能点。
过去积累经验，可能更多是在脑子里、文档里、代码里。
现在又多了一种形式：
把已经验证过的工作方法，直接做成下一次 Agent 可以加载的能力。
这可能会成为以后个人知识管理非常重要的一部分。
2. AI 可以分工，但“项目负责人”不能外包
这次我同时使用了 ChatGPT 和豆包。
逐渐形成了一种比较自然的分工：
豆包偏执行。
更贴近本机、本地文件、钉钉 CLI 和实际操作环境。
ChatGPT 偏审计和收口。
帮我检查当前方向有没有偏、规则有没有矛盾、项目推进到了什么程度、什么时候应该停下来重新确认主线。
这种分工其实很好用。
但第一天也暴露了另外一个问题。
如果人自己没有清晰主线，那么：
执行 Agent 会努力执行。
审计 Agent 会努力补全。
最后两个 AI 甚至可能一起把一个错误方向做得越来越完整。
第一天浪费的大半天，就是这种情况。
问题不是 AI 做得慢。
恰恰相反，是它做得太快。
如果我说“把所有历史文件都治理清楚”，它真的可以一直做下去。
不断增加字段。
不断建立关系。
不断完善分类。
不断补充治理规则。
但：
越来越完整，并不等于越来越接近目标。
后来我真正想清楚的是：
我要解决的不是过去所有文件之间的历史关系。
我要解决的是：
以后生产模板怎么持续维护。
主线一变，整个项目立刻简单了很多。
所以我现在越来越明确一件事：
AI 可以负责执行，也可以负责审计，但“项目负责人”这个角色不能外包。
目标是什么。
哪些事情值得做。
哪些事情不应该继续做。
做到什么程度算够了。
什么时候必须停止发散、重新收口。
这些判断，最后仍然要由人完成。
3. 日志和阶段收口，比以前更重要
即使没有 AI，复杂工作也应该养成日志习惯。
某个问题为什么这么处理。
某个方案为什么放弃。
当前做到哪里。
下一步是什么。
这些都应该及时记下来。
但 AI 出现以后，这个习惯的重要性至少又提高了一层。
以前一个人一天可能只能完成几个重要操作。
现在 Agent 一天可以：
- 扫描几百个文件；
- 改几十个字段；
- 建立几个工作流；
- 跑很多脚本；
- 测试十几套方案。
如果没有日志，第二天连自己都很难完整复原昨天发生了什么。
更不要说换一个 Agent 继续工作。
很多时候 AI 反复踩坑，并不是 AI 不聪明。
而是前一次失败根本没有被有效沉淀。
所以现在我越来越觉得：
一个项目做到某个阶段，就应该主动收口一次。
把已经确认的事实写下来。
把已经放弃的方案写下来。
把当前版本写下来。
把下一步写下来。
然后把临时脚本、临时文件和临时结论再做一次治理。
日志以前主要是写给未来的自己看，现在还要写给未来接手这个项目的 Agent 看。
否则 AI 执行速度越快，产生的“数字垃圾”也会越快。
4. 不要几年以后再做“数字考古”
这次文件治理还有一个很直接的提醒。
现在之所以要花这么大力气判断某个 2024 年的 Word 和某个 2026 年的 PDF 到底是什么关系，本质原因还是：
当时没有把版本关系管理好。
如果当时就有：
- 稳定模板 ID；
- 开发源文件；
- 生产版本；
- 版本族；
- 变更记录；
那么今天根本不需要重新猜。
AI 确实让这种历史重建变得容易很多。
但最好的办法仍然不是提高考古能力。
而是：
从现在开始，不要继续制造新的遗迹。
最后
项目层面，这三天把一个原本散落的合同模板库，逐步变成了：
资产治理 + 生产模板研发 + 制度流程 + 在线审批 + 智能检索 + Agent 运维
的一套电子签管理体系雏形。
三天当然不可能把电子签系统彻底做完。
现在还有 43 个生产模板需要继续重建 Word 源文件，审批流程也还需要继续跑完整的端到端测试。
但至少从这三天开始，我不再只是知道“合同文件放在哪里”。
而是开始知道：
一套业务系统，应该怎样留下可以继续维护的资产。
更重要的是，我也开始知道，AI 时代自己的工作经验应该怎么留下来。
不只是留在聊天记录里。
而是留在：
日志、版本、规则和 Skill 里。