出海效率提升：一个飞书群 + AI，十分钟搭好需求池

今天做了一轮代码安全排查，扫出几个要跟进的问题。暂时不想大改，但是问题确实存在需要记录下来。一个选择是写到项目文档，但是要提交代码。一个是加到维护中的多维表格，但是不太适合上下文比较长的问题。

还没开始记就先累了。

灵机一动，我前几天新建了一个飞书的话题群，把平时遇到的零星需求放进去，相当于作为自己的待办，一个需求一个话题，比较清晰，我就试着让 AI 直接把问题写成一个话题发进去。

试下来挺顺畅的，分享给大家。

为什么是话题群

话题群和普通群的区别在于，消息以话题为单位聚合。一个话题就是一个独立的讨论区，回复不会刷进群里，只通知订阅了这个话题的人。

拿它当需求池，约定就一条：一个话题对应一个需求。

临时想到的功能点、用户提的建议、排查出来的问题、半夜冒出来的灵感，随手发一条话题，就算记录完成。要讨论就在话题下面回，上下文天然聚在一起。

飞书官方其实也推荐过用话题群处理问题反馈，思路是一样的：降低反馈成本，发帖即记录。

这套东西对比表格和看板，好处是记录门槛低到几乎为零。没有字段要填，没有状态要选，一句话加一张截图就是一条需求。

让 AI 替你写进去

光是手动发话题，还称不上工作流。关键的一步是让 AI 能直接读写这个群。

飞书今年开源了官方命令行工具 lark-cli，把开放平台的两千多个 API 封装成了两百来条命令，配套的 Agent Skills 装好之后，Claude Code 这类 AI 编程助手就能直接操作飞书。

配置是一次性的。装好 lark-cli，初始化一个应用，再把这个应用的机器人拉进话题群。拉群这一步 AI 自己就能做，用你的身份调一下加群接口就行。

之后的日常使用就是一句话的事。比如今天排查完，我对 AI 说：把这个问题写到需求群里。

它会把问题背景、影响范围、修复计划整理成一条结构化的话题消息，以机器人身份发进群。比我自己手打完整得多。

lark-cli 开源仓库

这一步的价值在于，AI 干完活顺手就把记录做了。以前是做完一件事，还要自己切到另一个工具里补记录，现在记录变成了对话的副产品。

闭环：完成怎么标记

记进去只是一半，做完之后怎么销账。

飞书客户端里有「关闭话题」按钮，看起来是现成的完成标记。但查了开放平台文档，关闭话题没有对应的 API，机器人既不能关闭话题，也读不到哪些话题被关了。

所以我们定的约定是两个动作，都由 AI 完成：

做完一个需求，AI 在话题下回复一条结论，写清楚结果、上线位置和验证情况，这条给人看。

同时给话题的首条消息加一个 ✅ 表情回复，这个给机器看。

表情是能通过 API 查到的，之后让 AI 盘存量，拉出话题列表按 ✅ 过滤，剩下的就是待办。

关闭话题的按钮照样可以点，当成界面上的收纳动作，但完成与否以 ✅ 为准。

闭环流程

适合什么，不适合什么

适合的是临时需求、灵感碎片、排查出来的待跟进项。这类东西的特点是量不大、来得随机、不值得为它维护一套正经的项目管理结构。话题群加 AI 刚好接住：记录零门槛，讨论有上下文，盘点和销账交给 AI。

不适合的是有排期、有依赖、多人协作的正经项目，那还是该用项目管理工具。

配置全程大概十分钟：建一个话题群，装 lark-cli，把机器人拉进群。之后每次想记点什么，跟 AI 说一句就行。