通过飞书任务驱动开发工作流。读取飞书任务(URL 或 task_id),根据任务描述执行开发或分析工作,并通过飞书 IM 向任务负责人发送进度消息,在任务评论区添加重要细节评论。触发场景:用户提供飞书任务链接或 task_id 要求执行任务;用户要求根据飞书待办完成开发工作;用户提供以 applink.feishu.cn/client/todo 开头的链接。
通过飞书任务驱动开发:读取任务 → 理解需求 → 执行工作 → 汇报进度。
Skill 工具加载对应的官方 skill(lark-task、lark-im、lark-doc、lark-whiteboard、lark-wiki、lark-sheets 等),它会注入最新命令签名和错误处理流程。只有在所有 lark-* skill 都无法覆盖时,才退回直接调用 lark-cli 或 lark-openapi-explorer 查原生 API。Skill 选用指南见 reference/lark-skills-guide.md。lark-shared skill 完成认证/权限配置。⚠️ 以下所有 Step 中凡是提到"读取任务"、"发送卡片"、"读文档"等动作,首选路径都是加载对应 lark- skill*。Step 说明中出现的少量
lark-cli命令仅用于快速参考,具体参数和最新用法以 skill 输出为准。命令 fallback 详见 。
从用户输入中提取飞书任务标识,三种格式:
| 输入 | 提取 |
|---|---|
URL applink.feishu.cn/client/todo/detail?guid=xxx | 正则 guid=([a-f0-9-]+) 取 guid |
task_id(如 t101041) | 直接使用 |
GUID(如 1266ec4d-...) | 直接使用 |
调用 lark-task skill 按 GUID 拉取任务详情。重点提取:
summary — 任务标题description — 任务描述(核心工作内容)members.assignee — 负责人 open_idurl — 任务链接task_id — 必须保存,后续 +comment/+complete 等操作命令必需status — 任务状态仅靠 description 通常不够,并行收集以下上下文:
子任务:通过 lark-task 获取子任务列表,理解拆分结构和完成进度
历史评论:通过 lark-task 读取评论,了解需求变更、补充说明、方案讨论。若 lark-task 暂不支持评论列表则跳过并在进度消息中注明
关联文档:从 description/子任务描述中提取飞书链接,按类型调用对应 skill:
| 链接格式 | Skill |
|---|---|
feishu.cn/docx/<token> | lark-doc |
feishu.cn/wiki/<page_id> | lark-wiki |
feishu.cn/sheets/<token> | lark-sheets |
提取正则:https?://[a-zA-Z0-9-]+\.feishu\.cn/(docx|wiki|sheets|doc)/[a-zA-Z0-9]+
综合规划:汇总所有信息制定执行计划,开始执行前向用户确认执行方案
规划确认后、动手执行前,通过 lark-im skill 发送 turquoise 开始执行卡片给负责人。
reference/card-templates.md 的「🚀 开始执行」im +messages-send 仅支持 bot 身份,且 bot 与目标用户需已有单聊关系(见下方「权限处理」的例外说明)按确认方案执行。每完成一个重要阶段,主动推送卡片:
| 执行节点 | 卡片 | 必须包含 |
|---|---|---|
| 分析完代码/需求 | 📋 blue | 分析发现、确认方案、下一步 |
| 完成代码变更 | 📋 blue | 变更文件/行号、内容摘要、验证结果 |
| 遇到阻塞/需要决策 | ⚠️ orange 立即 | 当前进度、阻塞原因、具体问题 |
| 执行出错 | ❌ red 立即 | 出错前进度、错误详情、影响范围 |
摘要必须具体,避免笼统:
| ❌ 笼统 | ✅ 具体 |
|---|---|
| "分析了代码" | "分析了 ast_factor_builder.py 中 verbose 参数的 5 处使用位置,确认第 333 行 display=False 需改为 self.verbose" |
| "完成了修改" | "修改了 vista/agents/ast_factor_builder.py 第 333 行,ruff/basedpyright 均通过" |
向用户报告"任务完成"之前,必须完成 6.1 ~ 6.3 全部事项。
6.1 通过 lark-im 发送 ✅ green 完成卡片,内容包含:
{completion_summary} 完成概述(做了什么、为什么){changed_files} 变更文件列表(精确到行号){execution_summary} 执行回顾(代码变更、设计决策、验证结果、后续建议)6.2 通过 lark-task 在任务评论区添加纯文本技术评论(评论不支持 Markdown 和卡片),内容:
6.3 逐项确认检查清单:
6.4(可选) 经用户确认后通过 lark-task 标记任务完成(+complete)。
执行过程遇到需要用户确认/审核的问题时,立即发送 ⚠️ orange 阻塞卡片通知负责人,不要只在终端里等。
触发场景:
发送阻塞卡片后,终端也会同时等待用户回复,两种渠道任一回复都可推动任务继续。
仅以下场景需先向用户确认再操作:
+complete)前HTTP 400 ... unknown property, property: elements, code: 200621
根因:用了 "schema": "2.0" 但 elements 放在顶层。schema 2.0 要求 elements 必须嵌套在 body 对象内。
修复:把 elements 包进 body,严格复用 reference/card-templates.md 中的基础结构。
unknown flag: --task-guid → +comment/+complete 等操作命令只接受 --task-id,不支持 --task-guidtasks get --params '{"task_guid":"<guid>"}',从返回中提取 task_idtask_id 操作任务 → --task-id "<task_id>"详见 reference/lark-cli-commands.md 第 4、5 节。
标准处理流程:
--as user(需用户已 lark-cli auth login)im +messages-send 仅支持 bot 身份,--as user 无效。遇到 bot IM 权限不足时只有两条路:
im:message:send scopetask:task:read + task:task:writelark-shared skill,它是所有 lark-* 的认证/权限共享基础首选 lark-doc skill。常见操作:
docs +update --mode append(最常用,避免误删原内容)docs +update --mode insert_after --selection-by-title "## 变更记录"docs +create --title "..." --markdown "$(cat report.md)"docs +search,再 docs +fetch--as user完整的 docs 命令签名和 mode 速查见 reference/lark-cli-commands.md 第 6 节。
流程图、时序图、状态机、思维导图、架构图、关系图等一律用 lark-whiteboard skill 完成,不要在 Markdown 中手写 ASCII 图或 mermaid 代码块。
三步工作流:
lark-whiteboard skill 获取白板 DSL 规范lark-doc 在文档中插入占位:docs +update --mode append --markdown '<whiteboard type="blank"></whiteboard>'(需要多张图就重复占位)docs +whiteboard-update 把生成的 DSL 注入对应白板