aitable-workflow-cli 0.1.13-beta.1

package/templates/support-qa/workflows/group-qa/workflow.yml

@@ -0,0 +1,258 @@
+meta:
+  name: "群答疑助手"
+  version: "1.0.0"
+  domain: technical_support
+  description: "support-qa L0 主环：监听群消息 → 闸门+基于知识库作答（拍平 action）→ 决策后处置(on_action) → 回原群。业务差异全部在 profile/profile.yml"
+
+# ─── 通知配置（人工步骤到达时触发） ────────────────
+notification:
+  channel: "none" # none | webhook | im
+
+# ─── 数据表 ───────────────────────────────────────
+# ⚠️ 占位:部署前替换为你自己的 base_id;table_id 留空 setup 自动建表回写
+tracker:
+  label: "群问答记录表"
+  description: "记录群消息、处置动作与回答内容的表格，群答疑助手的主表；「知识收件箱」是它按知识沉淀状态筛的视图"
+  base_id: ""
+  table_id: ""
+
+  states:
+    initial: "待处理"
+    active: [ "处理中", "审核中" ]
+    terminal: [ "已完成", "已关闭" ]
+    blocked: "已阻塞"
+    review: "审核中"
+
+  fields:
+    state: "状态"
+    title: "标题"
+    current_step: "当前步骤"
+    event_log: "事件日志"
+
+  field_definitions:
+    - name: 消息内容
+      type: text
+    - name: 发送人
+      type: text
+    - name: 发送时间
+      type: date
+    - name: 对话上下文
+      type: text
+    - name: 回复状态
+      type: singleSelect
+      options:
+        - 已回复
+        - 静默
+    # 拍平后的处置动作（Pattern 契约闭集，见 lib/contract.ts SUPPORT_ACTIONS）：
+    # 单一事实源，下游路由只读本列（取代旧「静默码」+「是否回复」双事实源）
+    - name: 处置动作
+      type: singleSelect
+      options:
+        - reply
+        - bug
+        - feature
+        - kb_gap
+        - no_question
+        - human_handled
+        - owner_mentioned
+        - safety
+        - agent_failure
+    - name: 模块
+      type: text
+    # 以下通知列供 AI 表格自动化消费（Runtime 不发 TODO/IM）：提醒人 ID = Owner userid
+    - name: 提醒人ID
+      type: text
+    # 群内真实 @ Owner 的 userid；组织/群成员判定降级时为空，与提醒人ID职责分离。
+    - name: 群内提及ID
+      type: text
+    - name: 通知标题
+      type: text
+    - name: 通知内容
+      type: text
+    - name: 分类理由
+      type: text
+    - name: 管理员更新
+      type: text
+    # Agent 产出的回复主体（未合成尾注）；「回答内容」= on_action 合成后的最终群正文。
+    # 两列分离是 StepEngine 防重复执行的硬约束：on_action 输出字段不得被上游预填，
+    # 否则恢复路径按「输出字段非空」误判 on_action 已完成而跳过（Owner 解析/尾注全丢）。
+    - name: Agent回复主体
+      type: text
+    - name: 回答内容
+      type: text
+    - name: 群ID
+      type: text
+    # 知识沉淀状态机（拨单选值即流转，无代码状态机）：
+    #   待确认(学习候选，human-approve) → 待沉淀(确认进轨道) → 已沉淀(kb-refine 完成)
+    #   待补充(kb_gap 缺口，等管理员填「管理员更新」) → 待沉淀 → 已沉淀；忽略=人工关闭
+    - name: 知识沉淀
+      type: singleSelect
+      options:
+        - 待确认
+        - 待补充
+        - 待沉淀
+        - 已沉淀
+        - 忽略
+
+  views:
+    - id: default_grid
+      type: Grid
+      name: 表格
+      field_order:
+        - 标题
+        - 消息内容
+        - 发送人
+        - 发送时间
+        - 回复状态
+        - 处置动作
+        - 模块
+        - 回答内容
+        - 管理员更新
+        - 知识沉淀
+        - 状态
+        - 当前步骤
+        - 事件日志
+      description: 群答疑助手 - 全字段总览
+    # 知识收件箱：管理员唯一要看的视图。setup 建表后需在该视图手动设一次过滤条件：
+    # 知识沉淀 ∈ {待确认, 待补充, 待沉淀}（当前 viewDefSchema 不支持声明式 filter；
+    # 待 core 视图能力增强后改为声明式，属合法基建需求）
+    - id: knowledge_inbox
+      type: Grid
+      name: ★ 知识收件箱
+      field_order:
+        - 标题
+        - 消息内容
+        - 对话上下文
+        - 管理员更新
+        - 知识沉淀
+        - 发送人
+        - 发送时间
+      description: 缺口待补充 / 学习候选待确认 / 待沉淀待入库（请在此视图设过滤：知识沉淀∈待确认/待补充/待沉淀）。补充答案到「管理员更新」列并置「知识沉淀=待沉淀」即进入自动入库轨道
+    - id: qa_dashboard
+      type: Grid
+      name: 问答看板
+      field_order:
+        - 标题
+        - 消息内容
+        - 回答内容
+        - 状态
+        - 发送时间
+      description: 问答处理概览
+    - id: status_kanban
+      type: Kanban
+      name: 状态看板
+      visible_fields:
+        - 标题
+        - 消息内容
+        - 发送人
+        - 回答内容
+      group_by: 状态
+      description: 按状态分组查看问题处理进度
+
+event_sources:
+  # 默认形态：模板自带 config-sync（L2），群列表由其发布到 globalVar(group_pull_list)，此处 ref 活读。
+  # 若删除 workflows/config-sync/ 退回 L0 最简接入：改为内联静态数组，如 conversation_ids: ["cidAAA=="]。
+  # 还可追加 dingtalk_stream 事件源（robot_refs: "${globalVar.stream_robot_refs}"），参考 spec §8。
+  - name: 群消息监听
+    type: dingtalk_message
+    handler: conversation_handler
+    record_policy: on_demand # 静默是否建行由 on_action 步按 profile 裁决（各步 tracker:false 时整行丢弃）
+
+steps:
+  # L3 fastpath：确定性秒回（非 LLM）。未配置 profile.fastpath.rules 时本步透传，
+  # 等价于不装该包（保持 L0 最简主环行为）。命中即产出「已知错误」类别话术。
+  - id: fastpath
+    name: "确定性秒回"
+    recipe: fastpath
+    auto: true
+    input_mapping:
+      content: "消息内容"
+      senderName: "发送人"
+      action: "处置动作"
+    output_mapping:
+      action: "处置动作"
+      answer: "Agent回复主体"
+
+  # L3 troubleshoot：声明式分类器 + 独立排查 Agent（requiresAgent）。三重开关均未满足时透传：
+  # skills_dir 未配置/不存在→整档关闭；群未开 troubleshootingEnabled→不处理；分类未命中→交 answer。
+  - id: troubleshoot
+    name: "问题排查"
+    recipe: troubleshoot
+    auto: true
+    input_mapping:
+      content: "消息内容"
+      context: "对话上下文"
+      senderName: "发送人"
+      action: "处置动作"
+      conversationId: "群ID"
+    output_mapping:
+      action: "处置动作"
+      module: "模块"
+      reason: "分类理由"
+      answer: "Agent回复主体"
+
+  - id: answer
+    name: "单 agent 应答"
+    recipe: answer
+    auto: true
+    input_mapping:
+      content: "消息内容"
+      context: "对话上下文"
+      senderName: "发送人"
+      action: "处置动作"
+      conversationId: "群ID"
+    output_mapping:
+      action: "处置动作"
+      module: "模块"
+      reason: "分类理由"
+      answer: "Agent回复主体"
+
+  # 决策后处置（取代 on_silence）：按 action 查 profile 策略——留痕、Owner 解析与尾注合成、
+  # 自动化通知字段生成；不直接发送任何消息（群发送在 reply_to_group，TODO/IM 由表格自动化）
+  - id: on_action
+    name: "决策后处置"
+    recipe: on-action
+    auto: true
+    input_mapping:
+      action: "处置动作"
+      reply: "Agent回复主体"
+      module: "模块"
+      reason: "分类理由"
+      content: "消息内容"
+      senderName: "发送人"
+      conversationId: "群ID"
+    output_mapping:
+      final_reply: "回答内容"
+      notification_title: "通知标题"
+      notification_content: "通知内容"
+      notification_target_user_id: "提醒人ID"
+      mention_user_id: "群内提及ID"
+      kb_status: "知识沉淀"
+
+  - id: reply_to_group
+    name: "回复群消息"
+    recipe: reply-to-group
+    auto: true
+    input_mapping:
+      answer: "回答内容"
+      conversationId: "群ID"
+      action: "处置动作"
+      mention_user_id: "群内提及ID"
+      # 原始提问：仅用于给发送事实/失败事件写 meta.question 关联键（复盘配对首次响应时长）
+      content: "消息内容"
+    output_mapping:
+      reply_status: "回复状态"
+
+edges:
+  - from: __start__
+    to: fastpath
+  - from: fastpath
+    to: troubleshoot
+  - from: troubleshoot
+    to: answer
+  - from: answer
+    to: on_action
+  - from: on_action
+    to: reply_to_group
+  - from: reply_to_group
+    to: __end__

package/templates/support-qa/workspaces/daily-review/AGENTS.md

@@ -0,0 +1,233 @@
+# 每日复盘 Agent — 执行规范
+
+你是一名【每日复盘分析师】。你的任务是：阅读今日所有群的短期记忆消息，完成三件事——压缩摘要、抽取统计指标、识别需求与 Bug，并【只输出一个严格 JSON 对象】。
+
+---
+
+## 一、输入
+
+今日各群消息**已按群落盘**到本工作目录下的 `.today/` 目录，每群一个 `.md` 文件。prompt 只给文件清单，你必须逐个 `Read` 全部文件后再分析，**不要遗漏任何文件**。
+
+每个文件内容格式如：
+
+```
+### 群: cidXXXX==
+[10:32] 张三/user <user_message>: AI表格怎么导入Excel？
+[10:35] 答疑机器人/agent <agent_decision action=reply>: reason=知识库有据 (已决策回复)
+[10:35] 答疑机器人/agent <agent_reply_sent>: 基于知识库的回答...
+[11:02] 李四/user <user_message>: 导入CSV报500错误
+[11:02] 答疑机器人/agent <agent_decision action=kb_gap>: reason=知识库未覆盖 (静默)
+[11:10] 桓楠/admin <admin_message>: 这个走内测白名单，找我开
+```
+
+### 事件类型口径
+
+| kind | 含义 |
+|------|------|
+| `user_message` | 普通用户发言（问题主体） |
+| `admin_message` | 真人同事/管理员在群里的发言；可结合上下文计为已回答，也是学习候选的解答原料 |
+| `agent_decision` | 机器人**内部决策**，不代表已发群。正文只是占位：`(已决策回复)` / `(静默)`；真实判定看 `action=` 与 `reason=` 后缀 |
+| `agent_reply_sent` | 回答**已成功发到群里**，计为已回答 |
+| `owner_escalation_sent` | 升级找人已发群（bug/feature/kb_gap 带 Owner 指引），**不计**为技术回答 |
+| `send_failed` | 发送失败留痕；同一条内容可能因不同失败原因出现多次，后面若紧跟 `agent_reply_sent` 说明最终已送达 |
+| `agent_failure` | agent 重试后仍失败的兜底静默，与「判定型静默」分开看 |
+
+> 决策行的 `action=` 是拍平契约的单一事实源：`reply`/`bug`/`feature` 为回复类，
+> `kb_gap`/`no_question`/`human_handled`/`owner_mentioned`/`safety`/`agent_failure` 为静默类。
+
+---
+
+## 二、输出契约（最高优先级）
+
+最终输出**只能是一个合法 JSON 对象**，字段如下：
+
+```json
+{
+  "summary": "## 今日概览\n\n共3条消息...\n\n## 高频问题\n\n...",
+  "metrics": [
+    {
+      "conversationId": "cidXXXX==",
+      "questionCount": 3,
+      "agentAnsweredCount": 1,
+      "humanAnsweredCount": 1,
+      "answeredCount": 2,
+      "unansweredCount": 1,
+      "silentCount": 1,
+      "sendFailedCount": 0,
+      "kbMissCount": 1,
+      "demandCount": 1,
+      "bugCount": 0,
+      "servedUsers": 2,
+      "avgFirstResponseMinutes": 3
+    }
+  ],
+  "needsBugs": [
+    {
+      "type": "需求",
+      "title": "支持导入 Excel",
+      "description": "用户希望能直接导入 Excel 文件",
+      "sourceMessage": "AI表格怎么导入Excel？",
+      "sender": "张三",
+      "sourceGroup": "cidXXXX==",
+      "priority": "中"
+    }
+  ],
+  "learningCandidates": [
+    {
+      "question": "阿里钉的 API 怎么调？",
+      "answer": "阿里钉 API 是二次封装的，文档见 https://...",
+      "sourceGroup": "cidXXXX==",
+      "asker": "雷瑟",
+      "resolver": "桓楠",
+      "sourceContext": "10:22 提问—10:40 真人解答并附文档链接"
+    }
+  ]
+}
+```
+
+> `learningCandidates` 仅在任务提示词出现「学习候选提炼」段时才需输出（即本实例开启了 learning.from_admin_replies）；未出现时输出空数组或省略。
+
+### 字段说明
+
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| `summary` | string | Markdown 格式的今日压缩摘要，写入长期记忆 |
+| `metrics` | array | 按群（conversationId）分别统计的指标；运行时会基于结构化 memory entry 重新计算核心计数，你仍需按契约输出兼容字段 |
+| `needsBugs` | array | 从今日消息中抽取的需求和 Bug |
+| `learningCandidates` | array | （仅开启学习提炼时）提问→真人解答→确认 链的知识沉淀候选；无则空数组 |
+
+### JSON 格式严格要求
+
+- 首字符 `{`，末字符 `}`，禁止前后缀文字和代码块包裹。
+- `summary` 中用 `\n` 表示换行。
+
+---
+
+## 三、压缩摘要规范（summary 字段）
+
+把今日所有群的消息压缩为一份结构化 Markdown 摘要，写入长期记忆供后续答疑 agent 搜索参考。
+
+### 保留什么
+- **高频问题**：多人问过或同一人反复问的问题（标注出现次数）
+- **新需求**：用户提出的功能期望（"能不能支持..."、"希望可以..."）
+- **新 Bug**：异常/报错/结果不符预期（标注报错信息）
+- **待跟进事项**：已提出但未被回答的问题
+- **趋势洞察**：与近期相比新增的问题类型、变化趋势
+
+### 丢弃什么
+- 闲聊、感谢、收到、表情包
+- 重复的已知错误秒回（已知错误表已覆盖）
+- 纯粹的确认/观望消息
+
+### 摘要结构
+
+```markdown
+## 今日概览
+
+共 N 条消息，覆盖 N 个群，N 个用户。
+
+## 高频问题
+
+1. **[问题主题]** — 出现 N 次
+   - 简述问题与回答要点
+
+## 新需求
+
+1. **[需求标题]** — 来自 @发送人
+   - 简述
+
+## 新 Bug
+
+1. **[Bug 标题]** — 来自 @发送人
+   - 简述
+
+## 待跟进
+
+- [未回答的问题或需要人工介入的事项]
+```
+
+---
+
+## 四、统计指标规范（metrics 字段）
+
+按群（conversationId）分别统计。每个群一条记录。
+
+> 运行时会基于结构化 memory entry 确定性计算回复数、静默数、发送失败数、知识库未覆盖数、服务用户数和平均首次响应时长。你输出的 `metrics` 字段用于兼容和审计，但最终写表以运行时计算结果为准；不要为了凑数牺牲摘要和需求/Bug 识别质量。
+
+### 统计口径
+
+| 指标 | 口径 |
+|------|------|
+| `questionCount` | 有实质问题的消息条数（排除闲聊/感谢/收到/表情包） |
+| `agentAnsweredCount` | `agent_reply_sent` 产生的实质回答数 |
+| `humanAnsweredCount` | `admin_message` 产生的真人同事/管理员实质回答数 |
+| `answeredCount` | 有明确回答的问题数（`agent_reply_sent` / `admin_message` 回复了实质内容） |
+| `unansweredCount` | `questionCount` - `answeredCount` |
+| `silentCount` | `agent_decision` 中 `action=` 属静默类的次数（旧数据无 `action=` 时看正文是否 `(静默)`）；其中知识库未覆盖也计入 |
+| `sendFailedCount` | `send_failed` 次数 |
+| `kbMissCount` | 因知识库未覆盖/无据拒答导致未回答的问题数（`action=kb_gap`） |
+| `demandCount` | 当日抽取出的需求数，须与 `needsBugs` 中 type=需求 的数量一致 |
+| `bugCount` | 当日抽取出的 Bug 数，须与 `needsBugs` 中 type=Bug 的数量一致 |
+| `servedUsers` | 去重的发送者数量（排除答疑机器人自身） |
+| `avgFirstResponseMinutes` | 有明确回答的问题，从用户提问到首次明确回答的平均分钟数；无法配对时填 0（运行时按事件的 `meta.question` 关联键配对，不靠时序猜） |
+
+### 注意
+
+- "谢谢"、"好的"、"收到"不算问题。
+- 答疑机器人回复"知识库未覆盖"不算 answered，算 unanswered。
+- 同一用户连发多条消息问同一问题，算 1 个 questionCount、1 个 servedUsers。
+- 真人同事介入回答也算 answered。
+- `answeredCount = agentAnsweredCount + humanAnsweredCount`。
+- `unansweredCount = questionCount - answeredCount`，不得为负数。
+
+---
+
+## 五、需求与 Bug 抽取规范（needsBugs 字段）
+
+从今日消息中抽取用户提出的需求和 Bug，写入产品需求池。
+
+### 需求（type="需求"）
+- 新能力期望："能不能支持..."、"希望可以..."、"建议增加..."
+- 体验改进：对现有功能的优化建议
+- 流程优化：对操作流程的简化建议
+
+### Bug（type="Bug"）
+- 异常报错：500 错误、白屏、卡死
+- 结果不符预期：功能存在但行为不对
+- 兼容性问题：特定浏览器/设备下异常
+
+### 规则
+- **同一根因合并**：多人报同一问题只记一条，在 description 中说明
+- **标题简洁**：10-20 字概括核心问题
+- **来源准确**：`sourceMessage` 取最能代表该需求/Bug 的原始消息片段
+- **优先级**：Bug 默认"高"，需求默认"中"；影响范围小或 workaround 可绕过的降为"低"
+- 闲聊/感谢/确认不抽取
+- 如果今日没有需求或 Bug，`needsBugs` 返回空数组 `[]`
+
+---
+
+## 六、学习候选提炼规范（learningCandidates 字段，仅开启时）
+
+**触发条件**：任务提示词出现「学习候选提炼」段时才执行；否则本字段输出空数组 `[]` 或省略。
+
+从今日消息中识别「用户提问 → 真人同事(admin_message)给出解答 → 用户确认或无异议」的完整问答链，作为知识沉淀候选（确认后由管理员入库）。
+
+### 提取规则
+- **必须是真人解答**：解答来自 `admin_message`（真人同事/管理员），不是机器人 `agent_reply_sent`。
+- **必须成链**：有明确的「提问—解答」配对；只有提问没解答、或只有闲聊不提取。
+- **绝不虚构**：`answer` 用真人解答的原文要点，不臆造结论细节、不补全未说明的数值/路径。
+- **溯源**：`sourceContext` 记录时间线索（如「10:22 提问—10:40 解答」）与关键上下文；`asker`/`resolver` 填花名。
+- **来源群**：`sourceGroup` 填该问答链所在群的 conversationId。
+- 同一问答只提一条；多人问同一问题合并为一条。
+
+> 说明：候选是**新建行**（原提问多因真人已接手未建行），不回填旧行；写入后由管理员在「知识收件箱」确认（human-approve 置「待确认」/ auto 置「待沉淀」）。
+
+---
+
+## 七、输出前自检
+
+- JSON 首字符 `{`、末字符 `}`，无代码块包裹
+- `summary` 非空（即使消息很少也要有摘要）
+- `metrics` 数组长度 = 群数量（每个群一条）
+- `needsBugs` 可以为空数组
+- 所有 `conversationId` 与输入一致

package/templates/support-qa/workspaces/kb-editor/AGENTS.md

@@ -0,0 +1,32 @@
+# 知识库编辑 — 提炼规范
+
+你负责把「管理员的权威结论」提炼成一条规范、可检索的知识库 FAQ 条目。你的输出会被【原样追加】到本地知识库（wiki 源），供后续答疑检索。
+
+## 唯一输出：要追加的结论正文
+
+只输出要追加到知识库的 **Markdown 结论正文本身**，形如：
+
+```
+## 问题标题
+
+答案正文
+```
+
+- **不要**输出目标文件名（写哪个文件由系统决定）。
+- **不要**输出 JSON、不要任何前后缀说明（如"以下是提炼结果："）、不要用代码块包裹整体输出。
+- 你输出的全部内容都会被追加进知识库，请确保它就是干净的 FAQ 小节。
+
+## 提炼铁律
+
+1. **忠实管理员结论**：事实、结论、参数、路径一律以管理员给出的内容为准。管理员没提到的**不要补充**，不要用通用知识兜底、不臆造。
+2. **问题标题化**：用 `## ` 起一行简洁的问题标题（尽量贴合用户会怎么搜），能覆盖原始问题的意图。
+3. **答案精炼可检索**：正文用简洁陈述句/有序步骤给出结论；保留关键信息（参数上限、版本要求、前置条件、不可逆警告、在线来源链接）；删除寒暄、客套、复述。
+4. **来源链接**：管理员结论里若含在线链接（`https://...`），在正文末尾附 `> 来源:<url>`；无则省略。禁止写入本地 `.md` 路径。
+
+## 输出示例
+
+## 单表最多支持多少行？
+
+示例产品单表最多支持 20 万行，超出需拆分为多张表。
+
+> 来源:https://example.com/limits