钉钉消息任务追踪 · AI表格日报

概述

把每天散落在钉钉各处的「别人派给我的活」和「我派给别人的活」自动收拢成一张可跟踪的 AI 多维表，并推送结构化日报。核心是增量不漏、录入不重、状态不虚、日报可决策。

适用与不适用

• 适用：以本人视角，定时（如每工作日）汇总近 24 小时（或水位至今）与我相关的任务型消息，形成任务台账 + 每日日报。
• 不适用：全量群舆情监控（用 list-all 全量分析类技能）、单人要求事项跟踪（用 msg-requirement-tracker）、会议纪要待办（用 minutes-todo 类技能）。

前置：一次性建表与占位符登记

首次使用需先在钉钉 AI 表格建好主表与配置表，并把所有 ID 登记到本技能的「坐标表」（见 references/coordinates-template.md）。下文所有 <...> 均为占位符，落地时替换为真实 ID；本技能文件本身不得写入任何真实 baseId/tableId/fieldId/姓名/机器人码/文档链接。

主表建议字段（字段类型 → 语义 → 占位符）：

同 Base 建「扫描配置」子表（配置项 <F_CFG_KEY> + 配置值 <F_CFG_VAL>），存一条水位记录 <RECORD_WATERMARK>：配置项=last_scan_time，配置值=上次扫描到的最新消息时间。

选项 ID（singleSelect 写入以选项 ID 为准）占位符：方向 <OPT_DIR_IN>/<OPT_DIR_OUT>；状态 <OPT_ST_TODO>/<OPT_ST_DOING>/<OPT_ST_WAIT>/<OPT_ST_DONE>；来源 <OPT_SRC_AT>/<OPT_SRC_GROUP>/<OPT_SRC_SINGLE>/<OPT_SRC_TODO>/<OPT_SRC_DING>；优先级 <OPT_P0>/<OPT_P1>/<OPT_P2>。

执行流程

1. 取时间、验身份、读水位

• date 取当前准确时间（禁止凭记忆）。
• dws profile list 确认当前身份（本人 userId=<SELF_USER_ID>，corpId=<CORP_ID>）。
• 读水位：dws aitable record query --base-id <BASE_ID> --table-id <TABLE_CONFIG> --record-ids <RECORD_WATERMARK> --format json，取 <F_CFG_VAL> 作为窗口起点。窗口 = 水位 ~ 当前（通常约 24h；中断过则自动拉长到水位，保证不漏）。

2. 拉取 5 路来源（均只保留窗口内）

1. 群里@我：dws chat message list-mentions --start <ISO起> --end <ISO止> --format json
2. DING：dws ding +list --type ALL --format json（只留窗口内；机器人例行通知剔除）
3. 待办：dws todo task list --size 50 --status TODO --format json（只收窗口内新建；finalStatusStage 判完成）
4. 我发出的：dws chat message list-by-sender --sender-user-id <SELF_USER_ID> --start <ISO起> --end <ISO止> --format json
5. 别人发我的：dws chat message list-all --start "<起>" --end "<止>" --limit 100 --page-all --page-limit 60 --format json（--page-all 一次性合并全部分页；本地过滤机器人/告警，只留人工单聊与@我群消息）

翻页要点：list-by-sender/list-all 的 nextCursor 很长（约 256 字符），必须用完整游标，截断会返回空结果；hasMore=false 或最旧一条已早于窗口起点即停止。

3. 归类合并 + 三层防重 + A/B 路由

• 第1层 时间水位：水位之前的消息一律不拉、不录。
• 第2层 来源消息ID：录入前先 record query --field-ids <F_SUMMARY>,<F_MSGIDS> 读全表已有摘要与来源消息ID。候选事项的触发消息 openMessageId 若已出现在任一记录的 <F_MSGIDS> 中 → 不得再单独新建行（含新进展则走 B 类）。
• 第3层 语义防重：消息ID未命中时，将候选摘要与全表已有摘要逐一比对：同一件事（换说法/追问/进展反馈/跨天延续）→ B 类补记原行；确属全新话题 → A 类新建。
• A 类（新事项） record create：cells 必须同时含日期字段、优先级、来源消息ID（该事项全部相关 openMessageId，逗号分隔）、方向、来源、对方/对方名称。
• B 类（已有事项新进展） record update：新进展条目插入 <F_PROGRESS> 顶部（格式以「月-日」开头，如「9-01 对方公告定稿发全员群」），不得改动历史条目文字；同步更新最新时间/状态/消息条数，并把新消息 openMessageId 追加到 <F_MSGIDS>。

4. 存量事项状态自动维护（让状态反映真实进度）

凡走 B 类补记的存量事项，基于最新进展重新判定真实状态并回写 <F_STATUS>：

• 判「已完成」的信号：对方或我方明确收尾表述（已办结/已发布/已审批通过/已解决/已答复闭环/已修复/OK搞定了）；或对应 OA 待办 finalStatusStage=2；流程闭环且无未决追问。
• 有推进未收尾 → 「处理中」；等对方或等我回复、尚未开工 → 「待答复/待处理」。
• 硬约束：判「已完成」必须能在本窗口消息里找到明确收尾表述或待办完成信号；仅凭「没再提」不算完成，保持原状态，严禁臆测误改。
• 本窗口无新消息/无新信号的事项不改状态（仅在日报停滞段体现）。
• 记录所有状态变化明细（事项摘要｜变更前→变更后｜依据简述），供日报「状态变更摘要」使用；A 类新建不计入。

5. 批量写入 + 回读验证

• 用 Python 生成 UTF-8 JSON 文件，record create/update --records-file 批量写入（不内联超长 JSON）。
• 回读验证：record query --record-ids <新/改ID> --field-ids <F_SUMMARY>,<F_STATUS>,<F_PRIORITY>,<F_MSGIDS> 用 --jq 投影核对摘要/状态/优先级/来源消息ID均正确。

6. 推进水位

record update 把 <RECORD_WATERMARK> 的 <F_CFG_VAL> 改为本次拉到的最新消息 createTime（格式 yyyy-MM-dd HH:mm:ss）；本次无新消息则不更新水位。

7. 重复行自检

若表内存在重复行（相同摘要 + 相同日期 + 不同 recordId），保留最新时间较大的一条，record delete 删除重复行，并在日报用一行说明。

8. 生成并推送日报

日报四部分（见 references/report-template.md）：①统计概览（新增X/更新Y/状态变更Z）；②别人派发给我、我派发给别人两个 Markdown 表格；③事项状态变更摘要（无变化写「本次无存量事项状态变更」）；④P0 停滞扫描段（含老板/客户/线上/故障等关键词，或≥2天未闭环；判定前必查后续消息确认是否已闭环）。末尾附明细表与仪表盘链接。

• 推送：dws chat message send --user <SELF_USER_ID> --title '📊 24h任务日报（窗口）' --content '<完整日报>'（正文含换行必须用 --content，不是 --text）；发送后 query-send-status --open-task-id <返回id> 确认 sendStatus=SUCCESS。
• 链接自检：日报内所有表格链接节点段必须与登记的 <DOC_URL_DETAIL>/<DOC_URL_DASHBOARD> 一致，出现其他节点ID一律替换后再发。
• 窗口无增量也推简报（概览0条 + 状态变更摘要 + 存量P0停滞 + 注明本次无新增）。

9. 完成通知（可选）

dws ding message send --robot-code <ROBOT_CODE> --users <SELF_USER_ID> --type app --content '来自<助手名> | 任务完成：任务追踪日报已生成并推送（新增X/更新Y/状态变更Z，P0停滞N）'（ding message send 用 --content）。

录入取舍规则

• 优先级：含老板/客户/线上/故障/加急 → P0；bug/功能异常/用户反馈问题 → P1；咨询/已闭环/例行事务 → P2。
• 不建记录：纯寒暄、确认收到、机器人例行通知（同步完成/告警恢复类）；会议邀请并入相关任务或忽略。
• 附件：默认不处理（不下载、不上传，<F_ATTACH> 留空）；消息里的图片 mediaId 仅用于理解上下文。
• 对方字段：单人写 user（[{"userId":"...","corpId":"<CORP_ID>"}]，数字 userId 用 dws contact user search --query 姓名 获取）；机器人/多人时 user 留空、<F_PEER_NAME> 写明。
• group 字段（<F_SOURCE_GROUP>）在部分环境无法写入：create 不带该字段，改在 <F_DETAIL> 开头加「【来源群：群名称】」文本。

Pitfalls（实测）

• 所有 dws 命令必须直接在 Bash 里逐条调用（host-side hook 才产真结果）；勿用 Python subprocess、勿用管道/重定向/命令替换包装、勿一条命令串接多个 dws。
• dws 输出超 1 万字符会截断并存到 %TEMP%/qoder-hook-output/hook-output-*.txt；用 Read 或 Python 解析该文件。该临时文件可能被清理，需长期留存的数据请落到工作区。
• record update 无 --record-id/--cells，只接受 --records '[{"recordId":...,"cells":{...}}]' 或 --records-file。
• list-all/list-by-sender 游标截断→返回空；用完整 nextCursor。
• dws ding +list 分页可能报 stalled_cursor / nextCursor 没有严格前进 的服务端缺陷，无法翻到更早时段；此时用其余 4 路来源覆盖该时段并在日报备注，不要反复重试卡死。
• singleSelect 传选项 ID 为准；date 传 yyyy-MM-dd 或 RFC3339 或毫秒时间戳均可。
• 严禁 base create 重建表；遇权限/找不到错误，直接通过机器人 DING 上报，不自行重建。

Verification

• 写入后回读：新增记录字段完整（摘要/方向/优先级/状态/来源消息ID/日期齐全），B 类进展新条目在顶部且历史未被改动。
• 水位已推进到本次最新消息时间。
• 全表重复行自检通过。
• 日报发送 sendStatus=SUCCESS，链接节点段正确。

附录A · 坐标登记表模板

源文件：references/coordinates-template.md

坐标登记表模板（落地前填写，勿提交真实值到公共库）

说明：本文件供使用方本地填写真实 ID。发布到团队 Skill 库时，此模板保持占位符状态；真实坐标应存放在各自的定时任务 prompt 或本地私有配置中，不得写入技能正文。

身份

• 本人 userId：<SELF_USER_ID>
• corpId：<CORP_ID>
• 完成通知机器人 robot-code：<ROBOT_CODE>

Base 与表

• Base 名称：<BASE_NAME>
• baseId：<BASE_ID>
• 主表 tableId：<TABLE_MAIN>
• 扫描配置子表 tableId：<TABLE_CONFIG>
• 水位记录 recordId：<RECORD_WATERMARK>

主表字段 ID

配置表字段 ID

• 配置项：<F_CFG_KEY>
• 配置值：<F_CFG_VAL>

选项 ID

• 方向：别人派发给我 <OPT_DIR_IN> / 我派发给别人 <OPT_DIR_OUT>
• 状态：待处理 <OPT_ST_TODO> / 处理中 <OPT_ST_DOING> / 待答复 <OPT_ST_WAIT> / 已完成 <OPT_ST_DONE>
• 来源：群@我 <OPT_SRC_AT> / 群其他 <OPT_SRC_GROUP> / 单聊 <OPT_SRC_SINGLE> / 待办 <OPT_SRC_TODO> / DING <OPT_SRC_DING>
• 优先级：P0 <OPT_P0> / P1 <OPT_P1> / P2 <OPT_P2>

日报固定链接（原样使用，勿推测拼接其他节点ID）

• 明细表：<DOC_URL_DETAIL>
• 仪表盘：<DOC_URL_DASHBOARD>

获取方式速查

• baseId/tableId：dws aitable base list → dws aitable table get --base-id <BASE_ID>
• fieldId：dws aitable table get 返回的列定义
• 选项 ID：dws aitable table get 的 singleSelect 选项，或先建一条记录再 record query 读回
• 人员数字 userId：dws contact user search --query "<姓名>"

附录B · 日报模板与状态判定规则

源文件：references/report-template.md

日报模板与状态判定规则

一、日报结构（推送到本人单聊，Markdown）

标题：📊 24h任务日报（<起> ~ <止>）

📊 24h任务日报（YYYY-MM-DD HH:mm ~ YYYY-MM-DD HH:mm）

一、统计概览
• 窗口说明：（如中断则注明窗口已自动拉长，保证不漏）
• 本窗口新增任务 X 条（别人派发给我 a / 我派发给别人 b），存量补记进展 Y 条，状态变更 Z 条
• 新增优先级分布：P0×? / P1×? / P2×?；状态：待处理×? / 处理中×? / 待答复×? / 已完成×?
• 三层防重执行完毕；全表 N 条自检无重复行（或：删除重复行 K 条）
• 备注：（如 DING 分页缺陷导致某时段未覆盖，已由其他来源补齐）
• 水位已推进至 <本次最新消息时间>

二、别人派发给我（新增 a 条）
| 优先级 | 事项 | 对方 | 状态 | 最新进展 |
|---|---|---|---|---|
| P0 | ... | ... | 处理中 | ... |

三、我派发给别人（新增 b 条）
| 优先级 | 事项 | 责任人 | 状态 | 最新进展 |
|---|---|---|---|---|
| P2 | ... | ... | 已完成 | ... |

四、事项状态变更摘要（本次 Z 条）
| 事项 | 状态变更 | 依据 |
|---|---|---|
| ... | 处理中 → 已完成 | 9-12 对方回复"已发布" |
（无变化时写：本次无存量事项状态变更）

五、P0 停滞扫描（未闭环且≥2天无更新）
1. <事项> — <最新时间>后无更新，<天数>天
（新增 P0 若当日有进展则注明"未停滞"）

📎 明细表：<DOC_URL_DETAIL>
📊 仪表盘：<DOC_URL_DASHBOARD>

二、状态判定规则（自动维护存量事项）

硬约束：

1. 判「已完成」必须有明确收尾证据，仅凭"没再提"不算完成，保持原状态。
2. 本窗口无新消息、无新信号的事项不改状态（只在 P0 停滞段体现）。
3. 状态变化才回写 <F_STATUS>，并同步最新时间/最新进展/消息条数/来源消息ID。
4. 允许「重新打开」：已完成事项若出现新的未决追问，可回退为处理中，并在进展顶部注明。

三、优先级判定

• P0：含老板/客户/线上/故障/加急关键词，或涉及重大决策/资金/合规。
• P1：bug、功能异常、用户反馈的问题、风险预警。
• P2：咨询、例行事务、已闭环小事、宣导/催办类。

四、不建记录（降噪）

纯寒暄、单纯"收到/好的"、机器人例行通知（同步完成、告警恢复、报表已生成）、会议邀请（并入相关任务或忽略）。

附录C · 批量写入JSON结构

源文件：references/records-json-template.md

批量写入 JSON 结构（–records-file）

用 Python 生成 UTF-8 JSON 文件后，dws aitable record create/update --records-file <路径> 写入。禁止内联超长 JSON。

A 类新建（record create）

[
  {
    "cells": {
      "<F_DATE>": "2026-09-11",
      "<F_DIR>": "<OPT_DIR_IN>",
      "<F_SUMMARY>": "事项一句话摘要（含责任人/关键限定）",
      "<F_DETAIL>": "【来源群：xxx群】或【来源：单聊/DING】+ 背景 + 诉求 + 当前处置",
      "<F_PEER_USER>": [{"userId": "<数字userId>", "corpId": "<CORP_ID>"}],
      "<F_PEER_NAME>": "对方姓名（多人/机器人时写全，user 留空）",
      "<F_SOURCE>": "<OPT_SRC_AT>",
      "<F_LATEST_TIME>": "2026-09-12 17:39:05",
      "<F_PROGRESS>": "9-12 最新进展（置顶，月-日开头）",
      "<F_STATUS>": "<OPT_ST_TODO>",
      "<F_MSGCOUNT>": 52,
      "<F_PRIORITY>": "<OPT_P1>",
      "<F_MSGIDS>": "msgAAA==,msgBBB==,todo-123,ding-XXXX"
    }
  }
]

要点：

• 必带 <F_DATE>、<F_PRIORITY>、<F_MSGIDS>（该事项全部相关 openMessageId，逗号分隔；待办用 todo-<id>、DING 用 ding-<id>）。
• <F_ATTACH> 一律不写（留空）。
• <F_SOURCE_GROUP> 若环境不支持写入，则省略该字段，改在 <F_DETAIL> 开头加「【来源群：群名】」。
• 单人对方写 <F_PEER_USER>；多人/机器人省略该字段，仅写 <F_PEER_NAME>。

B 类补记 + 状态维护（record update）

[
  {
    "recordId": "<存量recordId>",
    "cells": {
      "<F_PROGRESS>": "9-14 新进展置顶条目n<原有历史进展原样保留>",
      "<F_LATEST_TIME>": "2026-09-14 08:58:53",
      "<F_STATUS>": "<OPT_ST_DONE>",
      "<F_MSGCOUNT>": 101,
      "<F_MSGIDS>": "<原有ID>,<新增ID1>,<新增ID2>"
    }
  }
]

要点：

• <F_PROGRESS>：新条目插到最顶部，历史条目原文保留不改。构造方式 = 新条目 + n + 查询回来的旧进展全文。
• <F_MSGIDS>：先查旧值，去重后把新 openMessageId 追加（不覆盖）。
• <F_MSGCOUNT>：旧值 + 本次新增条数。
• <F_STATUS>：仅在状态判定有依据时回写（见 report-template.md 状态规则）；无变化则不写该字段（update 未传字段保持原值）。

水位推进（record update 配置表）

[{"recordId": "<RECORD_WATERMARK>", "cells": {"<F_CFG_VAL>": "2026-09-14 09:00:13"}}]

读回旧值（构造 B 类更新前先查）

dws aitable record query --base-id <BASE_ID> --table-id <TABLE_MAIN> 
  --record-ids <id1>,<id2> 
  --field-ids <F_SUMMARY>,<F_PROGRESS>,<F_STATUS>,<F_MSGCOUNT>,<F_MSGIDS>,<F_LATEST_TIME> 
  --format json

输出超 1 万字符会落盘到 %TEMP%/qoder-hook-output/hook-output-*.txt，用 Python 解析构造更新 JSON。