Apr 7, 2026

用 lark-cli + Claude Code 搭建 BUG 每日提醒系统

作为游戏开发团队的程序，每天要面对好几个项目、几百条 BUG。靠人工去飞书表格里翻？太累了。

今天花了一上午，用 lark-cli + Claude Code 搭了一套自动化 BUG 管理工具链。记录一下过程和踩的坑。

要解决什么问题

我们团队的 BUG 跟踪记录放在飞书知识库的电子表格里，每个项目一张表，字段长这样：

问题描述	需求版本	类型	优先级	跟进人	当前状态	反馈时间	备注说明
xxx功能闪退	v1.2.0	BUG	P0	张三	新增	2026/03/28	偶现

痛点很明确：

没有主动提醒 — BUG 表更新了，但没人盯着看，P0 BUG 可能放了好几天没人管
负荷不均 — 某个人堆了 18 个 BUG，别人只有 3 个，没有全局视角
我自己的 BUG 散落在多个项目表里 — 每天要打开好几个表找自己该修什么

工具选型：为什么是 lark-cli

之前用 MCP（Model Context Protocol）做过类似的事情，但有个问题：依赖太重，要跑 MCP Server，配 feishu-mcp-server，还要编译。

lark-cli 是飞书的官方 CLI 工具，一行 npm install -g @larksuite/cli 就装好了。核心能力：

lark-cli sheets +export --spreadsheet-token xxx --file-extension csv  # 导出表格
lark-cli im +messages-send --chat-id oc_xxx --markdown "..."          # 发群消息
lark-cli api GET /open-apis/wiki/v2/spaces/get_node --params '{...}'  # 任意 API

够用了。导出 CSV → AI 分析 → 发消息，全程 CLI 搞定。

第一个坑：Wiki 嵌套的电子表格

我们的 BUG 表地址长这样：

https://xxx.feishu.cn/wiki/AbCdEf12345...?table=tblXxXxXxXxXx

注意这是个 wiki 链接，不是直接的 sheets 链接。wiki_token 不能直接当 spreadsheet_token 用。

需要先调飞书 API 解析 wiki 节点：

lark-cli api GET /open-apis/wiki/v2/spaces/get_node \
  --params '{"token":"GCFPwy92vi..."}' --as user

返回里的 obj_token 才是真正的 spreadsheet_token。而且 obj_type 是 sheet，但 sheet 里的子表 resource_type 是 bitable——飞书的嵌套结构确实有点绕。

第二个坑：Windows Git Bash 路径扩展

在 Windows 的 Git Bash 里执行：

lark-cli api GET /open-apis/wiki/v2/spaces/get_node

/open-apis 会被 MSYS 当成本地路径，扩展成 C:/Program Files/Git/open-apis/...。

解决方案：加环境变量前缀。

MSYS_NO_PATHCONV=1 lark-cli api GET /open-apis/wiki/v2/spaces/get_node ...

这个坑在 Windows 上用任何带 / 开头路径参数的 CLI 工具都会遇到。

第三个坑：飞书消息卡片格式

本来想用 interactive 类型发漂亮的卡片消息，结果报错：

unknown property, property: elements, path:

飞书的卡片消息格式在 im +messages-send 里似乎需要特定的包裹结构。最后改用 --markdown 发送，效果其实也不错——飞书的 markdown 消息支持加粗、列表、引用，够用了。

最终方案：两个 Skill

Skill 1: lark-bug-reminder（每日定时推送）

放在项目目录 .claude/skills/lark-bug-reminder/ 下，支持多表配置：

{
  "sources": [
    { "id": "project-a-bug", "source_name": "星际矿工BUG跟踪记录", ... },
    { "id": "project-b-bug", "source_name": "泡泡大冒险BUG跟踪记录", ... }
  ]
}

每天 9 点，Windows 定时任务触发 run-bug-reminder.bat，Claude Code 自动：

遍历每个 BUG 表，用 sheets +export 导出 CSV
AI 分析 B1-B8 风险规则（P0 未关闭、无跟进人、滞留超 7 天、负荷堆积…）
用 im +messages-send --markdown 发到飞书群

推送内容长这样：

🐛 星际矿工BUG跟踪记录 | 2026-04-07

🔴 需要立即关注
1. 11 个 P0 BUG 未关闭 — 最长已滞留 13 天
2. 李四负荷过重：18 个未关闭 BUG

📋 BUG 概况
共 509 条 | 未关闭：54 | P0: 11 | P1: 14

🔍 滞留明细（按跟进人分组）
李四（14 个滞留）
  🔴 [P0] 魔王挑战失败点看广告没反应 — 10天
  ...

💡 AI 建议
1. 李四需要减负，建议转交部分 P1

Skill 2: my-bugs（查询我的 BUG）

放在全局 ~/.claude/skills/my-bugs/ 下，任何项目里都能用：

/my-bugs dixin v1.2.0

过滤出分配给我的未关闭 BUG，按优先级排序。选择某个 BUG 后，自动下载截图、综合分析，然后可以直接帮忙改代码。

一键安装脚本

换电脑后不想重新配一遍，写了个 setup-bug-reminder.bat：

@echo off
:: 1. 自动安装 lark-cli（如果没有）
:: 2. 配置飞书应用凭证
:: 3. 引导完成两次浏览器授权
:: 4. 创建 Windows 定时任务

双击运行，2 分钟搞定。

授权机制

lark-cli 的 user 身份授权用的是 Device Flow——执行 auth login 后会输出一个链接，浏览器打开、点确认就行。scope 是增量的，多次 login 的权限会累积。

这个项目最终需要这些 scope：

操作	scope
读 wiki 节点	`wiki:node:read`
导出表格	`docs:document:export`
下载文件	`drive:file:download`
读表格元数据	`sheets:spreadsheet.meta:read`
发群消息	`im:message:send_as_bot`（bot 身份，无需 login）

总结

整套工具链的技术栈非常轻：

lark-cli — 飞书 API 的 CLI 封装
Claude Code Skill — 用 Markdown 文档教 AI 执行流程
Windows 定时任务 — 每天触发
一个 bat 文件 — 入口脚本

没有后端服务、没有数据库、没有 Docker。CSV 导出 → AI 分析 → 发消息，简单粗暴但够用。

关键收获：AI 不只是写代码的工具，更是自动化工作流的粘合剂。 把 CLI 工具的输入输出用自然语言串起来，就是一个强大的自动化 Agent。