我们团队 Issue 在 GitHub，平时在飞书里说话。指派改了、该谁跟进，理论上大家都该知道，实际上经常忘了在群里说一声。后来我在 Cursor 里把「查 Issue、改指派、发飞书」串成固定流程，顺便把命令和 prompt 记下来。前一半是这套事的装法与 Skill；后半段补一点别的——同样是「人在编辑器里、让 Agent 跑终端」，但不一定和飞书有关。

安装飞书 CLI

包名是 @larksuite/cli，我习惯全局安装：

npm install -g @larksuite/cli

装好后终端里可以用 lark-cli。官方仓库里还有一套 AI skills，用 npx 拉下来会装到用户目录，Cursor 里也能用：

npx skills add https://github.com/larksuite/cli -y -g

第一次配置应用我跑的是 lark-cli config init --new。这一步是交互式的：终端会停在那里，浏览器里打开开放平台，按提示走完授权。链接里会带 user_code，有时效，过期了就得重新来一次。我一般是电脑跟前做完这一步，再去做别的。

如果希望少点浏览器、多点脚本，可以用非交互方式，把 App Secret 从标准输入读进去，避免出现在命令行参数里（别人执行 ps 时可能看见）。不同版本子命令略有出入，我这边用过类似下面这种写法，具体还是以你本机 lark-cli --help 为准：

lark-cli config init --app-id '<你的 App ID>' --app-secret-stdin --brand feishu

Secret 和 .env 里的真值照旧：不进 git，也不往聊天里贴。

GitHub 这边先登录好 CLI，gh auth login 一次，后面列 issue、改指派都省事。

Skill 是后来慢慢加厚的

最早只有一条团队约定：飞书里提 issue 时，正文要 @ 到负责人，而且用飞书通讯录里的名字，不要只写 GitHub 登录名。那类内容放在 Cursor 规则里就行，管的是措辞。

真正费神的是另一件事：gh 把指派改完了，飞书最好在同一轮对话里发出去，不然人走了就忘了。后来又写了一个 Skill，把触发条件、发哪个群、出错了怎么办写进去。触发大致是两类，一类是我在这轮对话里用 gh 动过 assignee，一类是我明确说「指派给某某并通知飞书」。发群也分情况：给自己看的摘要走默认环境变量里的群；要喊别人，用研发群，群 ID 在项目里的映射表里查，不要随手写一个。

还有一条是两套凭证不要混着用。仓库里 Python 脚本通常读 .env 里的业务机器人；lark-cli 用的是 lark-cli config show 里那套。有的群只对其中一种机器人开过门，混了会报「机器人不在会话里」一类错误，换一条路一般就能通。Skill 里我抄了一个 lark-cli im +messages-send --as bot 的骨架，配上 --chat-id 和 --markdown，正文写清楚标题、@ 谁、issue 链接即可。后面踩一次坑就往 Skill 里补一段，包括发送失败不要在对话里装成功。

从零写的话，我自己的顺序是先能稳定发出去，再分默认群和研发群，再处理两套凭证和报错。想一次写全往往写不动，分几次反而快。

我在对话框里常打的字

下面是平时会输入的中文，改改仓库、群、人名就能用。不必照抄，只是个语气参考。

跨仓库看自己名下未关闭的 issue，想推到飞书扫一眼：

用 gh 查所有 assignee 是我、state 是 open 的 issue，按仓库分组，摘要用 Markdown 卡片发到默认群，不要贴全文。

在 Cursor 里改指派并通知：

把 issue #123 指派给某同事的 GitHub 登录名，按仓库规则发飞书研发群，按 github-team-map @ 飞书上的负责人，发完告诉我有没有成功。

只查列表、不发飞书：

当前仓库里 assignee 是我的 open issue 列一下，带上链接，不用发飞书。

想先确认指派再发：

改完指派后用 gh issue view 看一下 JSON 里的 assignees，再发飞书。

在 github.com 网页上点 Assign，不会自动触发 Cursor 里的规则或 Skill，那和本地编辑器不是一条链路。如果希望网页上一改就推飞书，要在 GitHub 那边做 Actions 或 Webhook。我大部分指派是在 Cursor 里处理的，所以同轮对话里发飞书对我来说够用。

两个常用 gh 命令

只看当前仓库：

gh issue list --assignee @me

要看所有仓库里指给我、还没关的：

gh search issues --assignee @me --state open --limit 100 \
  --json number,title,url,repository,updatedAt

第二种输出是 JSON，用 jq 或写两行 Python 按仓库分组，再拼飞书内容，比从网页复制粘贴省心。

别的流程：同一套习惯能套上去

Issue 和飞书是我写得最细的一条线，其实 Cursor 里还有不少「每次都要做、可以交给对话里完成」的事，我顺手写几条，篇幅不展开成教程，只当引子。

Git 和 PR。 本地改完要开 PR、看 diff、扫一眼 CI，gh pr create、gh pr view、gh pr checks 都能在终端里走完。我有时直接丢一句：基于当前分支推上去，用 gh 开 draft PR，标题和正文按仓库惯例写。比切回浏览器点表单快，尤其手边已经在跑命令的时候。

测试当门禁。 动了一个模块，我会让 Agent 只跑相关测试，而不是全量 pytest 泡十分钟。前提是仓库里有约定（例如某个目录对应某服务），这点写在 AGENTS.md 或 README 里，Agent 不容易乱猜。改完补一句「跑覆盖这段改动的测试，失败就停」比事后在 CI 里红一片省心。

MCP 浏览器。 若项目开了浏览器类的 MCP，可以请 Agent 打开本地 dev 地址、点一条主路径、截个图。它替代不了正式 E2E，但对「我改了路由有没有 404」这类粗检查够用。我一般不会让无人值守任务依赖浏览器，人在的时候点一轮就行。

统计和日报。 仓库里若有读数据库或日志的脚本（例如按日汇总调用量、错误数），在 Cursor 里跑一遍，把输出收成几行 Markdown，再贴到飞书或存成附件，和 Issue 推卡片是同一类活：终端出结构化结果，人决定往哪发。若你已有 stats 类子命令，可以单独写个小 Skill，写清默认时间范围、别带生产库密码进对话。

多文件重构。 改名、换目录、跟着改 import，我会让 Agent 分步做：先列出会动到的文件，再改，再跑 lint 或类型检查。大块替换最容易漏边角，让它「改完在当前包跑一遍检查」比一次改完再找编译错误稳一点。

文档和迁移。 接口变了，顺手改 OpenAPI、README 或内部文档，可以明确要求「和代码同一 PR、同一轮对话里改完」。数据迁移脚本、一次性 SQL，也可以让它按 AGENTS.md 里对事务、回滚的约定来写，写完你自己审一遍再执行。

这些都不依赖「后台自动跑」，核心还是：规则写清仓库脾气，Skill 写清什么时候该停、该问人，剩下的是你在对话框里下指令的习惯。和飞书那条线一样，值得记进 journal.md 的只有两样——当时用的命令、以及下次别踩的坑。

最后

我还在项目里放了一个 journal.md，偶尔记一下今天试了哪条命令、卡在什么错误码。不是为了发博客，是怕自己过几周忘了当时怎么配通的。飞书、gh、测试、MCP，都可以往里扔一行，以后改 Skill 或翻旧账会轻松一点。