ARTICLE · 1353185
8 张表、1 个表单、4 条自动化:文档管理落地复盘
最初的诉求很朴素：把散落的公开标准收拢起来，把各类文件整理清楚。真正卡住的却是另一件事——「什么算提交」一直没有定义。这篇不讲工具教程，只记录一次把闸口、表单、视图和自动化真正建出来的过程，以及其中几个差点翻车的地方。本文已做脱敏处理，不对应任何具体机构的内部制度或真实数据。
一、起点：问题从来不是「没有工具」
最初的诉求听起来很朴素：把散在网上的公开标准收拢起来，把外来文件、内部文件、人员材料和生产记录整理清楚。
真正卡住的是另外两件事。一是网上标准太散，不知道该盯哪些源、多久看一次、看到换版算谁的。二是内部文件催上来一堆不合格的：编号写错、版本写「最终版」、附件是 Word 甚至手机照片、签批缺一级；还有相当一部分干脆不交。
我们很快意识到，写更长的催办话术、拉更多的群，都不会改善这两件事。根因是「什么算提交」没有定义：群里甩一个文件就算交了，那么后面所有的校验、退回、升级都失去了着力点。
所以第一步不是选工具，是定一条规矩：只有一个入口算提交，其他渠道传文件一律不算。这条规矩后来贯穿了整套设计。
二、先把台账建对：8 张表各管一件事
在多维表格里建了一个台账，8 张表、111 个字段、41 行占位示例。分工是刻意的：
1. 外部标准源清单：盯哪些官网、多久查一次、谁负责、上次和下次核查日、当前版本状态
2. 外来受控文件清单 / 内部受控文件清单：分类别登记，带受控号、版本、生效日、引用标准、状态
3. 提交与催收任务：整套流程的发动机，状态机、退件原因码、退件轮次、升级级别都在这张表上
4. 人员档案必备项 / 生产文档台账 / 编号规则速查 / 使用说明
有两个取舍值得说。
第一，人员信息只记「齐备状态」。台账里放的是某类材料齐没齐、有效期、存放位置、授权矩阵是否核对过，不写证件号、住址、联系方式、健康信息。那些属于人事系统的敏感层，不该出现在日常协作表里。
第二，建完才发现少了一个字段。最初的任务表有 18 个字段，看着挺全，但没有附件字段——而校验规则里明明写着「非 PDF 退回」。规则和数据模型对不上，规则就是一句空话。后来补了附件、版本号、引用标准、提交人承诺四个字段，字段数从 107 涨到 111。
教训：先拿校验规则反推表结构，别先建表再想规则。
三、提交表单：把「填错」拦在入口
表单叫「文档提交入口」，11 道可见题目、10 道必填：任务编号、名称、责任组、责任人角色、文件类别、受控号、版本号、引用标准、附件、提交人承诺，备注选填。
1. 每题的说明直接写清会怎么被退回。受控号那栏写明格式和「重复占用退回」，附件那栏写明「只收最终版 PDF，Word、截图、手机照片退回」，引用标准那栏写明「引用已废止版本退回」。把 8 个退件原因码翻译成人话，前置到填写界面。
2. 状态、机检结果、三道校验、退件原因码、退件轮次、升级级别等 11 个内部字段，对提交人完全隐藏。提交人只负责把材料交对，不参与判定。
3. 提交人承诺是必填的单选项，不是可有可无的勾。它同时还承担了一个技术作用，后面会讲到。
踩了一个不大但后果不小的坑：开启表单分享时，服务端把访问范围从「组织内」悄悄改成了「任何人」。虽然还要求登录，但外部账号也能打开。发现后单独把范围收回，最终是「组织内 + 需登录 + 不允许匿名」。这类默认值不能假设，改完必须回读一次。
一句话总结这一环：表单不是收集器，是校验器。
四、分组视图：让「不交」变得可见
同一批记录，建了三个视图给不同角色看：
1. 状态推进看板：按状态分栏，给日常拖拽推进流程用
2. 按组红黄榜：责任组 → 状态两级分组，看到组完成率，不点名
3. 逾期与退回专窗：按退件原因码分组、退件轮次降序，专治反复不合格
「到组不点名」是有意的。目的是让进度可见，不是让谁难堪；点名会把协同问题变成人际问题，后面就没人愿意如实填状态了。
五、自动化：4 条工作流，和一个差点翻车的触发器
建了 4 条工作流：新提交自动流转与回执、退件原因码通知、截止前 3 天临期提醒、截止日 18:00 未交自动转逾期。
最值得写下来的是一个差点上线的缺陷。「新提交自动流转」最初监听的是「任务表新增记录」。看起来没毛病，但文档主管人工派发任务时也会新增记录——于是派单会被误判成「已提交」，状态直接被推到「待校验」，整张表的状态机从第一天就是错的。
修法是给触发器加一道条件：只有「提交人承诺」有值才触发。这个字段只有走表单提交才会填，人工派单不填。一个必填项，顺便成了区分两类新增记录的标记。
1. 只启用 2 条。含对人推送的两条保持停用。自动化的风险从来不是不跑，是跑错对象、在错的时间打扰错的人。
2. 所有通知的接收人先只配管理员本人。不进任何群，等接收人、话术、节拍都确认过再放开。
3. 退回只在同一张任务单上迭代，只退不改、不代填、不代签。机器人可以提醒、可以标状态，但绝不能替人把材料补齐。
六、让本地引擎真正连上表
另有一个本地跑的流水线引擎，负责机检、状态机、巡检、催收节拍和指标。要让它把结果写回云端表格，通常得配自建应用凭据。
这次没有等凭据：先把已授权的本机命令行通道做成一条传输层，读、批量写、更新、删除都能走；自建应用直连通道并行写好，等凭据填进去自动切换。
1. 只读操作永远真实执行，连通性测试不能是模拟的
2. 写操作必须显式加提交参数，默认一律拒绝
3. 用「写入一条探针记录 → 回读 → 删除 → 复查零残留」做闭环验证，表最终恢复原状
跑通的结果是：真实读到 8 张表、22 个字段、3 条记录，写入和删除闭环全部成功。而消息侧仍然保持 dry-run，一条都没往外发。
七、复盘：5 条可复制的经验
1. 先定义「什么算提交」，再谈工具。没有唯一入口，后面所有校验都是空转。
2. 拿校验规则反推表结构。规则说要 PDF，表里就得有附件字段。
3. 内部字段对提交人不可见。谁填材料、谁做判定，要分开。
4. 自动化先停后启，消息先发自己。触发器要区分「人新增」和「表单提交」。
5. 每次写能力都配一个可回滚的探测。能证明连上了，又不留脏数据。
最后：工具能建表，改不了协作契约
还有没做完的：责任人目前是文本字段，自动化 @ 不到具体的人；临期之后的第二级、第三级升级还没接；群通知和正式发布通道也还差一次授权。
但回头看，这套东西里最值钱的不是 111 个字段或 4 条工作流，是那条「只有唯一入口算提交」的规矩——表和自动化只是让它变得可执行、可留痕、可追责。
