方法论与洞察

周报整合钉钉周会手册：三轮修复与诊断反转复盘

入档：2026-08-26 来源：2026-08-17~08-25 周报（E:\工作报告\2026\周报\2026-08-17_08-25-周报.md）整合进钉钉《周会记录手册（AI商业组）》8月第4周（8.26）· AI研究模块 · 跳蛛小节（dws doc block 链路） 验证状态：✅ 闭环验证（三轮修复 + 作者终审定版收口）

事实记录（不可修改区）

• 目标文档：alidocs 节点 l6Pm2Db8D4EZdoKXHenyLZPX8xLq0Ee4，落位「跳蛛 → 上周工作总结 / 本周工作规划」两个空小节，约束是不动其他任何人内容
• 第一轮（格式失效）：用 dws doc block insert --text 插入，markdown 完全不解析——**加粗** 成了字面量 \*\*、列表全散。修复：删坏块，改用 doc update --mode append --index N --content-file file.md，该通道正确解析 markdown 为 paragraph + list 块
• 第二轮（图表框架异常）：作者反馈「图表框架异常」（先误打”图标”）。初诊”列表被拆成单块导致编号重置”——核验 JSONML 后诊断反转：6 个规划项全部共享 listId=efdwvdivco7，编号本来就正常渲染；真因是原周报三张表格（关键交付进度 / 数据面板 / 上期规划完成情况）此前按格式白名单压成了行内文本段落。修复：删 3 个扁平段落，用 doc block insert --element '{"blockType":"table","table":{"rolSize":N,"colSize":2,"cells":[[..],[..]]}}' 插真表格（10 行 / 5 行 / 7 行）+ 各配 h5 小节标题 + 商单拍板事项 blockquote
• 第三轮（作者终审定版）：作者手改收口——删掉商单引用块、规划第 6 条（商单 / Codex 自媒体去留）、「待补」段，规划收敛为 5 条。项目收口
• 插入定位技法：同一锚点（「本周工作规划」标题块）--ref-block <id> --where before 正序连续插入，每段都紧贴锚点之前，最终顺序天然正确——与既有「倒序插入法」（--where after 时倒序插）互为镜像：before 配正序，after 配倒序，同锚点都自然有序
• 工具实测补充：dws doc block list --block-id 过滤参数不生效（返回全文档），需自行用脚本过滤；块 ID 跨增删稳定，索引每次操作都漂移，一切定位锚块 ID

一、方法论沉淀

[白名单是场景律，不是全局律]

核心：钉钉格式白名单（禁表格 / 禁引用块 / 修饰只用加粗+代码块）是从教程知识库交付场景提炼的，本次错套到周报进周会手册场景——周报里的表格本来就是作者要看的结构化信息，按白名单压成行内文本反而制造了「图表框架异常」返工。白名单约束的是”这类读者、这类文档”的格式偏好，换了场景（周报 / 汇报 / 数据面板）要重新问一次”这场景里表格要不要保留”。

操作规则：

1. 拿出一条格式规范时先问出处场景：它是”平台约束”（到处适用）还是”场景偏好”（仅原场景适用）；
2. 跨场景复用规范，先看交付物的信息密度类型：教程类线性阅读可压表格为列点，汇报类对照数据必须保表格；
3. 规范文档里写明适用场景边界，不只写规则本身。

[复诊先推翻上一轮归因]

核心：作者说”框架异常，再修”时，第一反应是沿用上一轮的诊断（列表碎裂）继续修——但核验底层数据后发现那个诊断本身就是错的，真故障在另一处（表格被压扁）。上一轮诊断会变成下一轮的锚定偏差：修过的方向天然显得”还没修完”。复诊的正确姿势是把上轮归因也放进怀疑列表，从原始数据（JSONML）重新推导。

操作规则：

1. 用户报障含糊（“图标/图表框架异常”）时，先枚举候选异常源（列表？表格？图片？）再逐个用数据排除，不直接跳到上轮结论；
2. 定位结构类异常以底层数据结构为准（block list --content-format jsonml），不以块数量和表面形态为准；
3. 上轮做过的修复要重新验证”它当时修的是不是真故障”，而不是默认它只修了一半。

[钉钉列表的原生形态：共享 listId 的连续 p 块]

核心：钉钉文档的列表在数据层就是多个独立 p 块共享同一 listId——doc update --mode append 把每个列表项拆成独立块不是 bug，是平台原生形态（周会模板 callout 里的原生列表同样如此）。判断列表是否异常的唯一判据是 listId 是否共享：同 listId = 一个列表（编号自动递增），不同 listId = 多个列表（编号各自从头）。只看”块被拆散了”必然误诊。

操作规则：

1. 排查钉钉列表问题先拉 JSONML 看 list 属性（listId / isOrdered / level / start），不看块数；
2. 手工构造/修复列表：每个列表项是一个带 list 属性的 p 节点，同一列表各项写相同 listId，首项可加 start，level 控制缩进，isTaskList 转待办。

[dws 插表格走 element 通道，别赌 markdown 通道]

核心：doc block insert --element 的 table blockType（rolSize / colSize / cells 二维数组）当场验证稳定可用，表格结构、表头、中文内容全部正确落地；markdown 表格经 doc update --mode append 的解析行为未验证且无必要冒险。表格、callout、分栏这类结构块一律走 element/jsonml 通道。

操作规则：

1. 插表格：--element '{"blockType":"table","table":{"rolSize":行数,"colSize":列数,"cells":[[...],[...]]}}'，cells 含表头行；
2. 长内容 / 含中文引号的 JSON 先写临时文件再 --element "$(cat file.json)"，防 shell 转义错乱；
3. 插完用 block list --start-index --end-index 数 tr 行数、抽 cell 文本校验，success 只证明插进去了。

[AI 交全量结构，作者终审做减法]

核心：终版 diff 显示作者删的是只有作者能删的东西——商单拍板引用块（敏感的向上管理表述）、规划第 6 条（去留事项不想写进公开手册）、「待补」段（承认数据缺口的话）。AI 交付时应给结构完整、信息无损的全量版本（含引用块、含待补标注），把删减权留给作者；不要预判”这个可能不该放”而自作主张瘦身——作者做减法是 30 秒的事，AI 猜错删了要返工一轮。

二、一句话结论

格式白名单跟场景走，复诊先推翻上一轮归因：钉钉列表”一块一项”是共享 listId 的原生形态，判据在数据不在块数；表格走 element 通道插真表格；定位永远锚块 ID（before 正序 / after 倒序）；AI 交全量结构，减法留给作者终审。

如何使用

• 下次往钉钉插结构化内容（周报 / 汇报 / 数据面板）：列表与正文走 doc update --mode append --content-file，表格走 doc block insert --element table blockType，两通道分工使用；
• 接到”还是不对，再修”类复诊反馈：先 block list --content-format jsonml 拉数据重新归因，把上轮结论当假设不当事实；
• 给作者交付手册类内容：全量结构 + 待补/引用块照放，作者终审做减法即收口。

关联文档

• 钉钉知识库交付_格式白名单与终版回填闭环_v1（同域上游：白名单的出处场景——本档补上了它的适用边界：教程交付场景律，不可跨场景硬套）
• dws块级插入_index语义陷阱与倒序插入法_v1（同链路操作层：锚块 ID / 倒序插入 / list 校验；本档补 --where before 正序镜像与 table element 通道）
• 变通方案不等于故障点_v1（同根：归因要落在验证过的证据上——本档是”复诊时上轮归因本身可疑”的又一实例）
• 复盘事实先行原则（事实记录区的纪律来源）
• 04_方法论与洞察索引