基于日程、待办、文档等数据源自动生成结构化日报，支持提交到钉钉日志

日报生成助手

触发条件

当用户需要生成日报时触发此技能。典型场景：

• "帮我写今天的日报"
• "生成今日工作总结"
• "结合日程和待办写日报"
• "用新东区泛企业团队日报模板提交"

核心原则

1. 用户画像先行：首先获取用户基础信息，确定报告语气和工作视角
2. 聚焦当天工作：时间范围为当天（或最近1-3天），而非双周维度
3. 多数据源融合：结合日程、待办、文档、群聊等多维度信息，构建完整工作画像
4. 严格遵循模板：按照四段式结构组织内容（拜访客户、重要进展、MaaS覆盖、明日计划）
5. 简洁务实：避免空泛描述，每条内容控制在合理长度

执行流程

步骤1：获取用户画像（必选）

通过 ei-search-server::get_related_info 工具获取用户基础画像信息：

aone-kit call-tool ei-search-server::get_related_info '{"param": {"bizDomain": "workclaw"}}'

提取关键信息：

• 花名/姓名：用于报告署名和语气风格
• 职级/角色：判断工作视角（架构师/SA/研发等）
• 团队/BU：明确组织归属
• 直属上级：了解汇报关系
• 最近编辑文档：辅助理解当前工作重点

用途：

• 确定报告的语气风格和叙述视角
• 从最近编辑文档中提取潜在的工作重点线索

步骤2：确定时间范围

关键规则：时间范围为当天（或根据用户需求调整为最近1-3天）。

计算方法：

• 获取当前日期作为基准
• 例如：当前是2026-07-14，则时间范围为 2026-07-14T00:00:00+08:00 至 2026-07-14T23:59:59+08:00

使用完整ISO-8601格式：YYYY-MM-DDTHH:mm:ss+08:00

步骤3：获取日程信息（必选）

dws calendar event list --start "<今天>T00:00:00+08:00" --end "<今天>T23:59:59+08:00"

• 提取关键会议：客户拜访、方案沟通、技术研讨、内部会议等
• 重点关注：外部客户会议、技术方案评审、项目推进会议
• 将会议信息转化为工作内容描述

认证说明：

• 在 real 模式下，dws 命令的认证由宿主应用（钉钉）自动管理，无需手动执行 dws auth login
• 如果返回"未登录"错误（not_authenticated），直接重试该命令即可，系统会自动刷新 token
• 可使用 dws auth status 确认当前登录态

失败降级：

• 如果多次重试后仍无法获取日程，记录此情况并继续执行后续步骤
• 在日报中基于待办事项和文档信息推断客户活动，不编造日程内容

步骤4：获取待办事项（必选）

dws todo task list --status "all" --format json

• 获取已完成和进行中的待办事项
• 筛选当天创建或更新的待办
• 重点关注：已完成的客户任务、技术调研任务、方案编写任务
• 将待办完成情况转化为工作成果描述

步骤5：获取相关文档（必选）

推荐方法：从用户画像获取最近编辑文档

通过 ei-search-server::get_related_info 获取用户最近编辑的文档列表，然后筛选当天的文档：

aone-kit call-tool ei-search-server::get_related_info '{"param": {"bizDomain": "workclaw"}}'

从返回的 content.data.recentEditDocs 中提取当天更新的文档：

• 检查每个文档的 updateAt 字段（毫秒时间戳）
• 筛选条件：当天0点至23:59的时间戳范围
• 记录文档标题、更新时间、链接等信息

优势：

• 覆盖范围广，包含用户所有空间的最近编辑文档
• 直接反映用户实际工作内容，准确度高

补充方法：使用 dws doc list

如需获取特定文件夹或知识库中的文档，可使用：

dws doc list --folder <folder_id> --limit 50

适用场景：

• 需要查询特定客户文件夹中的文档
• 需要遍历项目文件夹的子目录

注意事项：

• 优先使用用户画像方法，覆盖率更高
• 如OAuth限制无法读取正文，仅记录文档标题和更新时间
• 文档标题可作为工作成果的佐证（如"编写了XX技术方案"）

步骤6：获取群聊消息（可选但推荐）

触发条件：当用户希望从钉钉群聊中补充客户沟通细节时执行。

核心价值：群聊消息往往包含即时的客户反馈、技术问题解决进展、项目协调信息等，能丰富日报的"重要进展及问题"字段。

6.1 多数据源综合提取客户名称

不要仅从"今日拜访客户"字段提取，应从以下三个维度综合提取客户名称列表：

1. 日程中的客户会议：从步骤3获取的日程中提取 summary 字段包含的客户名称（排除内部会议如"周会""日会""例会"等）
2. 待办事项中的客户名：从步骤4获取的待办 subject 字段中提取客户名称（如"爱普生""珞博智能""立讯通讯"等）
3. 文档标题中的客户名：从步骤5获取的当天更新文档标题中提取客户名称

去重合并后得到最终的客户名称列表。

示例：

• 日程："立讯通讯CIO团队线上沟通TB后续合作" → 提取"立讯通讯"
• 待办："hi 柳非老师，前两天反馈的珞博测试cosyvoice-v3.5-plus的日语发音问题..." → 提取"珞博"
• 文档："notes_42.怪兽充电" → 提取"怪兽充电"

6.2 按客户名搜索群聊

对每个客户名称执行群聊搜索：

dws chat search --query "<客户名称>" --format json

从返回结果中提取所有相关群的 openConversationId 和 title。

关键注意：必须使用 dws chat search 返回的真实群ID，严禁手动映射或猜测ID，避免客户归属错位。

6.3 批量探测哪些群今天有消息

为避免全量读取触发限流，先快速探测（limit=1）：

dws chat message list --group <openConversationId> --time "YYYY-MM-DD 00:00:00" --limit 1 --format json

检查返回的 result.messages 数组是否为空，仅保留有消息的群。

限流处理：

• 如果返回 RATE_LIMIT_ERROR，等待 3-5 秒后重试该群的探测
• 连续 3 次限流错误则跳过该群，记录到"未能获取群聊信息的客户"列表中
• 每探测 5 个群后主动等待 2 秒，降低触发限流的概率

6.4 读取有消息群的完整内容

对探测到有消息的群，拉取当天完整消息：

dws chat message list --group <openConversationId> --time "YYYY-MM-DD 00:00:00" --format json

限流处理：同样遵循 6.3 的重试策略。

6.5 提取关键信息并总结

从消息中提取有效文字内容（过滤图片消息、纯表情回复）：

• 识别涉及具体客户的讨论
• 提取技术问题、方案确认、进度同步等关键信息
• 按客户归类总结，格式："客户名：聊天中提炼的进展"

示例：

立讯通讯：跟进GUI模型RT问题，客户当前调用的是默认公开模型而非260125版本，已协调客户确认调用方式
珞博智能：WAIC大会流量超预估应对方案讨论（分钟级告警+AI网关Fallback降级）；确认PTU包天计费开启时间

6.6 融合到日报

将聊天总结追加到对应客户的"重要进展及问题"条目后，用分号分隔。

容错说明：

• 如果某些客户的群聊因限流未能获取，在日报末尾添加注释："注：部分客户群聊信息因系统限流未能完整获取"
• 明确告知用户哪些客户的群聊信息缺失，避免误导

注意事项：

• 本步骤为可选操作，若用户未明确要求可跳过
• 群数量较多时建议分批处理，每批间隔2-3秒避免限流
• 跨客户协作群（如东浩兰生群讨论珞博项目）需根据实际内容判断归属

步骤7：数据融合与结构化

按以下四段式结构组织内容（对应"新东区泛企业团队日报"模板）：

今日拜访客户

内容来源：从日程和待办中提取客户相关的活动

写作要求：

• 只写客户名称，不要添加描述或说明
• 如有多个客户，分点列出
• 内部会议不计入（如团队例会、内部评审等）

示例格式：

1. 爱普生
2. 珞博智能
3. 外服信

重要进展及问题

内容来源：从待办完成情况、文档更新、群聊消息中提取关键成果

写作要求：

• 严格遵循"客户名：进展"格式
• 突出当天的重要工作成果
• 如实记录遇到的问题和挑战
• 每条内容简洁明了，避免冗长
• 如有群聊补充信息，用分号追加到对应客户条目后

示例格式：

1. 爱普生：完成TTS接入方案设计，输出技术架构图并通过客户确认
2. 珞博智能：解决模型部署中的显存溢出问题，优化推理参数配置；WAIC大会流量超预估应对方案讨论
3. 天马微电子：需求变更频繁，需建立需求冻结机制以避免反复调整

MaaS场景覆盖

内容来源：从客户沟通和文档中提取MaaS相关场景

写作要求：

• 必须写清具体场景名称，不能只写大类（如"语音场景"）
• 格式："具体场景名：客户+应用描述"
• 说明场景与客户业务的结合点
• 如有新增场景或突破，重点标注

示例格式：

1. 智能客服语音播报：爱普生客服系统接入TTS能力，实现订单状态语音通知
2. 知识库问答：珞博智能内部文档检索系统基于Qwen3大模型构建
3. 工业质检视觉识别：迪恒显示生产线缺陷检测方案进入POC测试阶段

明日计划

内容来源：从待办未完成项、日程中明天的会议、客户明确提出的下一步需求中提取

写作要求：

• 严格遵循"客户名：具体事项"格式
• 列出明天计划完成的具体任务
• 标注任务的优先级或紧急程度
• 如有客户约定，注明时间和地点

示例格式：

1. 爱普生：输出TTS方案最终版并提交客户确认
2. 珞博智能：跟进流量切换实施进度，确认测试环境准备情况
3. 外服信：完善MaaS场景方案，准备下次沟通材料

步骤8：生成报告文件

使用 create_file 生成Markdown格式的日报：

• 文件名格式：YYYYMMDD_daily_report.md（使用当天日期）
• 保存路径：当前工作目录

步骤9：迭代优化

根据用户反馈进行修改：

• 如需补充细节，读取当前报告并修改对应部分
• 如需精简内容，压缩每条描述的字数
• 使用 modify_file 进行精确替换

步骤10：提交钉钉日志（可选）

触发条件：用户明确要求"用XX模板提交日志"或"发到钉钉日志"时执行。

新东区泛企业团队日报模板信息：

• 模板名称：新东区泛企业团队日报
• 模板ID：18c35ee861e44d6304edab1405f99d7f
• 字段定义（4个文本字段）：

提交流程（严格按顺序执行，不可跳步）：

1. 确认模板可用（若不确定模板是否存在）：

   dws report template get --name "新东区泛企业团队日报" --format json

从返回中提取 report_template_id 和 result.report_template_fields[]。

1. 拆分报告内容：将生成的日报按上述4个字段拆分为JSON数组，写入临时文件：

   [
     {
       "key": "今日拜访客户",
       "sort": "1",
       "type": "1",
       "content": "<第一部分完整内容>",
       "contentType": "markdown"
     },
     {
       "key": "重要进展及问题",
       "sort": "2",
       "type": "1",
       "content": "<第二部分完整内容>",
       "contentType": "markdown"
     },
     {
       "key": " MaaS场景覆盖",
       "sort": "3",
       "type": "1",
       "content": "<第三部分完整内容>",
       "contentType": "markdown"
     },
     {
       "key": "明日计划",
       "sort": "4",
       "type": "1",
       "content": "<第四部分完整内容>",
       "contentType": "markdown"
     }
   ]

• key 必须与 template get 返回的 field_name 完全一致（注意"MaaS场景覆盖"前面有空格）
• sort 对齐 field_sort，传字符串如 "1"
• type 对齐 field_type，1=文本类，传字符串如 "1"
• contentType 文本类用 "markdown"

1. 提交日志：

   dws report entry submit --template-id <templateId> --contents-file <tmp.json路径> --format json

• 长内容必须走 --contents-file，避免shell引号转义破坏JSON
• contents JSON大小限制为10MB，不支持分批次提交

1. 获取查看链接：submit成功后会自动反查详情并追加 dingtalkOpenMarkdownLink，直接使用该字段生成可点击链接：

   [在钉钉中查看日志](dingtalk://...)

• 禁止把raw dingtalk://... URL原样写进回复，必须包成markdown link

常见错误处理：

• PARAM_ERROR：跳过第1步直接编templateId，或跳过第2步用LLM经验编key名 → 必须重走 template list → template get → entry submit
• INPUT_INVALID_JSON：--contents 或 --contents-file 内容非合法JSON → 检查数组结构，每项必须是object且含5个字段
• INPUT_FILE_NOT_FOUND：--contents-file 路径不存在 → 先确认sandbox OS与路径风格，改写到可移植目录
• 连续≥3次返回PARAM_ERROR → 停止重试，降级建议用户在钉钉客户端手动填写

内容格式规范（关键）：

钉钉日志文本字段对 Markdown 嵌套列表渲染支持有限。必须在提交前将报告内容扁平化：

• 主条目：保持 1. 2. 3. 编号，每个客户独占一行
• 子项：全部改为 - 开头的独立行，不要使用 a. b. c. 或 i. ii. iii.
• 禁止：同一行内用分号连接多个子项
• 缩进：子项可使用两个空格缩进表示层级关系，但必须独占一行

注意事项：

• 本步骤为可选操作，默认不执行；仅在用户明确要求时才触发
• 不同团队的日志模板字段可能不同，提交前必须先 template get 确认字段定义
• 如果用户指定的模板不在可用列表中，需先确认模板名称是否正确，或建议用户选择现有相近模板

常见陷阱

1. 不要编造数据：如果无法获取邮件或文档正文，如实说明限制
2. 时间范围必须是当天：不是简单的"过去几天"滚动窗口，除非用户明确要求
3. 时间格式必须完整：使用 YYYY-MM-DDTHH:mm:ss+08:00 格式
4. JSON解析降级：遇到截断或嵌套结构时，用shell命令而非复杂脚本
5. 避免流水账：不要简单罗列所有会议和待办，要提炼重点
6. MaaS场景要具体：明确标注涉及的AI能力类型（语音/视觉/大模型等）
7. 用户画像先行：必须先获取用户画像再开始数据收集，确保报告语气和视角正确
8. 群聊ID必须真实：严禁手动映射群ID，必须使用 dws chat search 返回的真实ID，避免客户归属错位

工具使用规范

• ei-search-server::get_related_info：获取用户画像（第一步必选）
• dws calendar event list：获取用户日程（补充时间线和会议细节）
• dws todo task list：获取待办事项（补充任务完成情况和未来计划）
• dws doc list：获取文档列表（补充工作成果佐证）
• dws chat search：按客户名搜索群聊（获取真实群ID）
• dws chat message list：拉取群聊消息内容
• execute_shell + python3 -c：解析JSON数据
• read_file / modify_file / create_file：生成和修改报告
• grep_search：在已有文件中搜索特定内容

输出质量检查

在完成前确认：

• [ ] 是否先获取了用户画像？
• [ ] 时间范围是否为当天（或用户指定的时间）？
• [ ] 是否融合了日程、待办、文档、群聊的补充信息？
• [ ] 四个字段是否都有内容填充？
• [ ] MaaS场景是否明确标注了AI能力类型？
• [ ] 是否有编造的数据或信息？
• [ ] 群聊ID是否来自 dws chat search 而非手动映射？
• [ ] 提交时key是否与模板字段完全一致（包括空格）？