钉钉运营自动化工具

我真正解决的，是运营动作在群聊里失去生命周期

群聊是团队最自然的操作入口，却不是可靠的任务系统。一句“这个款今天调整价格”能够快速同步上下文，但如果没有后续结构化动作，它很快就会沉入历史消息；即使有人手动补进表格，记录与提醒之间仍然是断开的。

因此，这个项目没有把成功标准设成“机器人回复正确”，而是要求每一类消息都获得合适的生命周期：问题被回答，动作被记录，标准工作被派生，未完成事项被重新唤醒。

我观察到的不是一个单点效率问题，而是四次信息损耗：提问时答案依赖谁在线，记录时字段依赖谁愿意整理，执行时后续事项依赖谁记得，追踪时表格又与群聊上下文分离。只有同时连接这四个节点，自动化才不会把工作从一个人转移到另一个人。

为什么继续使用群聊，而不是要求所有人先填一张表

运营动作往往发生在讨论过程中。如果把“先打开表格、找到视图、补齐字段”设为入口，记录质量会高度依赖个人习惯；但如果只保留聊天，后续又无法查询与追踪。

我的取舍是让群聊成为输入界面，而不是数据终点。成员继续用原来的表达方式提出问题或记录动作，自动化在后台完成路由和结构化，并把结果反馈到原对话中。这样既不额外制造操作负担，也让信息进入了可维护的状态层。

这并不意味着任何一句话都会被记录。触发需要明确 @机器人，并包含约定的“记录”或“调整”关键词；即时问答也只响应已定义的问题类型。显式触发降低误收集普通聊天的风险，也让成员知道什么时候是在调用工作流。

• 输入足够轻：@机器人加自然语言即可触发。
• 结果可见：成功记录、节点时效和任务入口都会回到群聊。
• 状态可查：真正需要追踪的内容进入多维表，而不是停留在聊天历史。
• 责任不转移：机器人确认“已记录”，不冒充业务负责人确认“已完成”。

核心分工：规则决定流程，AI 只翻译非结构化信息

这套系统没有把所有判断都交给模型。时效、发货、补货等关键词有稳定答案，适合使用确定性分支；款号、操作类型和描述细节存在表达差异，适合由模型整理。模型输出结构化字段之后，写入哪张表、是否派生任务、进入哪个提醒分支，仍由工作流规则控制。

模型 Prompt 只要求提取款号、操作类型、操作内容和当前真实日期，并规定无款号、多款号与严格 JSON 的输出方式。它不接触群聊回复模板、表格地址或人员信息，也不能直接选择任意后续动作。

模型完成语义翻译后，流程再进行参数提取和条件判断。这样即使未来更换模型，业务分支仍然由可见规则表达；如果输出缺字段或无法解析，也可以在写入之前进入异常处理，而不是把错误文本直接存进正式表格。

三条自动化不是三个功能，而是一条闭环的三个阶段

1. 01

   即时响应

   群成员 @机器人后，规则判断是否包含时效、发货或补货。命中后返回维护好的 SLA 或任务入口，未命中进入默认结束，不用生成式回答补全未知答案。

2. 02

   状态沉淀

   当消息明确要求记录或调整时，AI 提取款号、操作类型、完整内容和真实日期；无款号使用明确占位，一条消息包含多个款号则拆成对应记录。

3. 03

   条件分类

   参数提取后由工作流判断新品下单、无款号操作和其他活动。分类依据留在可视化条件分支中，不隐藏在模型自然语言里。

4. 04

   任务展开

   新品下单除了保存基础活动，还创建视觉提案与链接调研两个标准任务，并通过链接款号保持它们与原事件的关系。

5. 05

   群聊确认

   只有写入动作完成后才返回记录成功或节点提示；回复的职责是确认系统已经接住消息，而不是宣称实际业务工作已经完成。

6. 06

   每日扫描

   每天固定时间读取待推进记录，最多处理 100 条并逐条循环；先识别任务类型，再提取款号、活动内容和记录日期。

7. 07

   日期判断

   对需要节点管理的任务计算目标日期，与当天比较后进入早于、等于、晚于或默认分支；日期关系由规则处理，不让模型自由生成提醒时机。

8. 08

   重新激活

   不同日期分支使用不同提醒语义，把款号、活动和时间重新送回群聊，让人能够直接接续原来的运营动作。

一条新品消息，为什么要展开成三个独立工作对象

基础活动回答“发生了什么”，派生任务回答“接下来必须推进什么”。如果把三件事写在同一个长文本字段里，系统只能证明消息被保存，却无法分别跟踪视觉与链接工作。拆成独立对象后，每项工作都可以拥有自己的状态、时间和提醒路径。

这里的自动化并没有试图完成创意或调研本身。它做的是把稳定的流程知识固化下来：每次发生新品下单，都不再依赖某个人重新想起完整检查清单。

三个对象共享同一个链接款号，但保留各自的活动类型与内容。后续如果视觉已经完成而链接调研仍在进行，只需要更新对应任务；基础活动仍然作为事件来源存在，不会因为某个子任务变化而丢失原始语义。

闭环的关键，不是写入表格，而是状态能够再次驱动行动

很多自动化停在“成功写入一行”。但表格只完成了留痕，没有解决推进问题。每日提醒流把活动表当作状态源，重新读取尚未结束的记录，结合任务类型和日期关系决定提醒方式。

因此数据不是归档后的静态结果，而是下一次动作的输入。群聊产生状态，状态驱动任务，任务在时间条件满足后再次产生群消息，这才构成完整的运营闭环。

提醒流不会重新解析原始聊天历史，而是读取已经通过结构化流程写入的活动记录。这样定时任务面对的是稳定字段，不会因为聊天被编辑、引用或上下文过长而产生不同理解；同时任何提醒都能回到对应的记录进行核对。

多维表不是结果展示，而是整个系统的状态层

活动表至少承载五类信息：业务对象、活动类型、原始内容、记录时间和活动状态。款号用于连接同一业务对象的多条活动，活动类型决定后续规则，完整内容保留人的表达，记录时间支持节点计算，状态决定定时流是否继续处理。

字段设计尽量区分事实与派生值。原始操作内容属于事实，操作类型是模型与规则共同产生的分类，提醒日期是由记录时间和任务策略计算的派生值。这样当分类或时间策略改变时，可以重新计算，而不需要篡改原始输入。

每一次机器人回复，都应该对应一个明确系统事实

即时问答回复表示规则命中了已维护答案；记录成功回复表示表格动作完成；节点提醒表示某条开放记录满足了时间条件。回复文案不会使用含糊的“已经处理完毕”覆盖这些不同事实。

这种反馈设计让使用者能够理解系统到底做了什么，也为失败处理留下空间。如果字段解析成功但写入失败，系统不能发送“已成功记录”；如果提醒消息发送失败，活动记录仍然存在，后续可以根据发送状态重试。

• 回复与真实动作完成顺序一致，避免先成功提示、后写入失败。
• 确认消息包含足够的对象和活动摘要，便于发起人发现解析错误。
• 内部任务入口和人员信息保持在受控回复模板中，不由模型生成。
• 默认分支安静结束，未知问题不会制造看似权威的答案。

自动化负责流程完整，人负责业务正确

这条边界让系统承担最适合自动化的部分：重复、结构化、跨时间保持一致；同时把需要经验、上下文和责任承担的判断留给人。

人机边界还体现在可修正性上：模型提取出的类型和内容应该在表格中可见并允许负责人纠正，后续提醒读取修正后的状态。系统追求的不是模型第一次永远正确，而是错误能够被发现、修改并继续进入正确流程。

• 机器人可以识别和整理操作内容，但业务人员仍需确认描述是否准确。
• 系统可以创建标准后续任务，但视觉方案、链接判断和具体调整仍由负责人完成。
• 提醒表示事项需要关注，不代表系统替人判断了优先级或完成质量。
• 未命中的咨询进入默认分支，不用生成式回答填补未知信息。

把失败路径设计成流程的一部分

当前平台原型还没有完整实现上述所有恢复能力，但这些失败路径决定了下一版工程化的优先顺序。先让状态可见和可恢复，再增加更多自动分类，能够避免功能越多、不可解释的中间状态也越多。

我会用哪些场景验证这条工作流

验证不仅检查节点是否执行，还要检查跨流程关系：群聊确认是否对应真实记录，派生任务是否保留来源，提醒是否读取同一状态，失败后重试是否会重复创建。闭环正确性来自这些连接，而不是任何单个节点显示绿色。

• 同一条消息包含一个款号、多个款号和完全无款号三种结构。
• 操作类型使用不同表达方式，但都应稳定进入对应业务分支。
• 新品下单应生成一条基础活动和两条可独立追踪的派生任务。
• 字段缺失、非法 JSON、写入失败和重复触发不得产生虚假成功回复。
• 日期分别早于、等于和晚于当天时，应进入对应提醒路径。
• 完成状态的记录不再进入扫描，开放记录不会因某次提醒失败而丢失。

从内部原型走向稳定工具，还需要补齐哪些工程能力

公开版本只展示匿名字段和合成示例，不包含真实群名、人员、业务链接或运营数据。这个项目展示的是工作流建模、AI 与规则的职责划分，以及从原型继续走向可靠系统时需要守住的工程边界。

演进顺序也有明确优先级：先替换已下线动作并恢复基础写入，再补 schema 与幂等，随后完善日志、分页和时间策略，最后才扩展更多操作类型。这样每一阶段都建立在可验证的状态链路上。

• 输出契约：用具名枚举替换数字指令，并对模型 JSON 增加 schema 校验、缺失字段和多记录测试。
• 可靠写入：为活动与派生任务增加幂等键、失败队列和人工重试入口，避免重复记录或静默丢失。
• 可观察性：记录每次触发、模型解析、条件命中、表格写入与消息发送结果，能够从失败节点继续排查。
• 规模边界：当前提醒流单次最多读取 100 条，数据扩大前需要分页、批次游标与执行摘要。
• 时间策略：把节假日、提醒周期和不同任务的 SLA 显式配置，不依赖定时器默认值。
• 平台迁移：当前原型存在未发布更新，其中一个表格写入动作已被平台标记为下线，需要替换动作并完成回归验证。