有一类事情在团队里反复出现：你在终端里装好了一个 CLI，在 Cursor 里跑通了一条「查 Issue → 发飞书」的脚本，过两周要写给同事看，却发现只记得结果，不记得当时卡在哪个交互步骤上。对话窗口里的记录会沉掉；脑子里的版本又会自动美化。

我最近在仓库里单独维护了一份工作流自动化日志（markdown，按日期追加），专门记「当时为了什么、用了哪条命令、哪一步必须人手点浏览器」。这篇文字就是把其中几条抽出来，串成一篇对外也能读的笔记。它不算教程目录，更像出差回来整理报销单：顺序未必漂亮，但每张票据都对得上号。

为什么要记在仓库里，而不是记在脑子里

编辑器里的 Agent 很擅长执行，却不替你保管长期记忆。把可复用步骤写成结构化片段（场景、工具版本、要点、踩坑、能不能写进文章），好处是显式的：下次换机器、换同事接手，仍然能从文件里恢复上下文，而不是从聊天记录里考古。

飞书开放平台对外提供大量服务端 API（文档里常提到「标准化接口」「机器人」等能力），GitHub 则把 Issue、PR、搜索等能力收进官方的 GitHub CLI（gh）里——两者都适合跟脚本拼在一起。真正费时间的往往不是「调 API」，而是初始化与权限：哪一步必须打开浏览器、哪一步可以用管道喂密钥、哪一步在 CI 里根本跑不了。日志里把这几类写清楚，后面成文就快很多。

飞书 / Lark CLI：装得上只是第一步

一条典型路径是全局安装官方 CLI，再拉 GitHub 上的 AI skills，最后做应用配置：

npm install -g @larksuite/cli
npx skills add https://github.com/larksuite/cli -y -g
lark-cli config init --new

config init --new 会阻塞到你在浏览器里完成开放平台侧配置；终端里会打印带 user_code 的链接，时效一过就得重来。这类步骤不适合丢给无人值守的定时任务——它假设屏幕前有人。

如果更在意脚本化与可审计性，可以改用非交互方式，把敏感信息走标准输入，避免出现在进程列表里（示例思路，具体参数以你当前 CLI 版本为准）：

lark-cli config init --app-id '<APP_ID>' --app-secret-stdin --brand feishu

Skills 安装器往往把多域 skill 落到用户目录（例如 ~/.agents/skills/lark-*）并链到 Cursor 等工具；装完看一眼官方给出的安全或依赖扫描摘要没有坏处。原则还是老样子：真实密钥只进 .env 或密钥管理，不进仓库、不进聊天、不进这篇博客。

GitHub：单仓列表与跨仓搜索不是一回事

只看当前仓库时，gh issue list --assignee @me 足够顺手。但一旦你要的是「GitHub 上所有指派给我、且仍打开的 Issue」，就要换 gh search issues。官方手册里写明了子命令与筛选参数（见 gh search issues）。一条可用的骨架如下：

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

@me 对应当前 gh auth 登录用户。输出用 JSON 解析后，按 repository.nameWithOwner 分组再推送，就不容易漏掉别的仓里的单子——这点和「只在某个 repo 里 list」差别很大，也是我在日志里单独记了一笔的原因。

把 Issue 摘要推到飞书时，用 Markdown 卡片收束信息（编号、标题、状态、链接、短摘要）比贴大段正文更耐看；移动端扫一眼就能决定要不要回电脑。

飞书机器人：「用户态 CLI」和「应用凭证」不是同一条路

日志里还记了一条容易混淆的经验：lark-cli doctor 若提示未做用户登录，并不等于你不能发群消息——应用凭证 + 群 chat_id 走业务机器人，往往仍可用；个人单聊又是另一套接收方 ID 与权限模型。团队里若同时存在「我自己用 CLI 调试」和「服务账号机器人推卡片」，最好在文档里把两条路径画清，免得排障时来回换赛道。

编辑器规则、Skill 与 Webhook：边界要写清

我在项目里遇到过一类需求：希望「凡是 Issue 被指派 / 改指派，就发飞书并 @ 负责人」。Cursor 里的 规则（rules） 可以约束文案与步骤，但它不是常驻后台进程——你在 github.com 网页上点 Assign，并不会自动触发编辑器里的任何东西；若要在「平台事件发生」时稳定送达，需要 GitHub Actions、Webhook 或组织级机器人，那是另一条工程量。

换句话说：Agent 在同一轮任务里执行了 gh issue edit … --add-assignee，可以约定它必须顺手发飞书；但「网页上一指派就响」必须靠平台侧集成。把这条边界写进 Skill 或内部文档，能少掉一半「我以为规则会自动跑」的误会。

加载配置时优先在脚本里用 dotenv_values 或等价方式读 .env，避免依赖 shell 的 source .env 在陌生环境下静默失败——这类小细节写在日志里，将来接飞书开放平台机器人发消息时会省心很多。

小结与延伸阅读

把自动化实践记进仓库，不是为了堆文档篇幅，而是给未来的自己留可执行的上下文：哪一步必须人手，哪一步可以脚本，哪一步在 CI 里做不得。飞书侧可参考开放平台的开发者文档总览；GitHub 侧除了 gh，也可以读一读 CLI 手册里对 search 子命令的说明，避免把单仓命令和全局搜索混着用。

日志里还空着几栏：MCP 与浏览器工具在回归里的用法、统计类 CLI 和飞书日报的衔接——等真有可复述的踩坑再补。若你也在用类似方式记「流水账」，或许可以试试同一套字段：场景、工具、步骤、结果、原则、能不能写成博客——最后一栏看起来很功利，却最常逼你把废话过滤掉。