预计阅读：12 分钟
前几天，我突然想到一个产品方向：
我想做一个轻量版的 AI-HIS 系统给基层医生用。
按照我以前的习惯，这句话大概率会被我扔进备忘录、微信文件传输助手，或者飞书收藏里。然后它会和很多“以后再整理”的想法一样，慢慢沉下去。
这一次，我把它发给了一个飞书机器人。
几分钟后，它回给我一份 PDF：里面有 CEO Review、竞品扫描、最小实现路径，还有一张白板图。
这就是我最近做的一个小项目：给飞书机器人发一句想法，它会自动帮我记录到 Obsidian，调用 Codex 做一次 CEO Review 和竞品扫描，生成一张白板图、一份 Markdown 报告和 PDF，最后再把 PDF 回传给我。
这个项目的名字可以叫 Feishu Idea Catcher。
它不是一个大平台，也不是一个复杂产品。它更像一个我给自己做的“灵感收纳盒 + 初步评审员”。
我真正想解决的问题不是“怎么自动生成一篇报告”，而是“一个念头刚出现的时候，怎样不让它死在备忘录里”。
很多想法不是在电脑前产生的。它可能出现在走路的时候、等电梯的时候、和别人聊天的时候，甚至只是脑子里突然闪了一下。
过去我的做法是：先发给微信或飞书文件传输助手，等有空再整理。
问题是，大部分“等有空”，最后都没有等到。
1、需求其实很朴素：我只是想把灵感先接住
这个项目最早的需求非常简单：
我在任何地方突然有一个想法，可以通过文字或者语音转文字发给飞书机器人。
然后系统自动完成几件事：
- 把原始想法追加到 Obsidian 的 idea list。
- 基于这个想法生成一份简短评审报告。
- 报告里不只说“这个想法好不好”，还要看“有没有人已经在做”。
- 生成一张白板图，把这个想法讲清楚。
- 导出 PDF，并通过飞书发回给我。
这个闭环看起来像一个自动化工具，但它背后的真实场景是：
想法刚出现时，人最需要的不是一个复杂系统，而是一个低摩擦入口。
所以入口必须是我已经每天打开的工具。不是再装一个新 App，不是打开一个网页表单，也不是进一个后台。
最后我选择飞书自建机器人，而不是微信客户端自动化，原因也很明确：飞书开放平台有官方能力，长连接、消息事件、文件上传都能走正规 API；微信个人客户端自动化则存在稳定性和合规风险，没必要为了一个个人工作流去碰可能导致封号的灰色路径。
这也是这个项目的第一条原则：
能用官方 API，就不要自动化个人客户端。
2、MVP 的核心链路：入口轻，处理慢，结果沉淀
最终跑通的 MVP 链路是这样的：
飞书机器人收到想法
-> 本地长连接 listener 接收消息
-> Upstash Redis 入队
-> 本地 worker 拉取任务
-> Codex 生成报告和竞品扫描
-> Codex image2 生成白板图
-> 写入 Obsidian Markdown
-> Chrome headless 导出 PDF
-> 飞书文件 API 回传 PDF
这里最关键的设计是把系统拆成两段：
第一段是 listener，只负责“快”。
它接收飞书消息，做去重，把任务放进队列，然后立刻回复“已进入慢任务队列”。
第二段是 worker，只负责“慢”。
它可以慢慢调用 Codex、做搜索、生成图片、写 Obsidian、导出 PDF、上传文件。哪怕整套流程跑几分钟，也不会卡住飞书回调。
这听起来像工程常识，但对这种 AI 自动化项目很重要。
因为 AI 任务天然不稳定：搜索可能慢，图片生成可能慢，PDF 导出可能失败，网络也可能抽风。如果所有事情都堆在消息回调里，系统很快就会变成一个“看起来自动，实际上经常超时”的玩具。
尤其是飞书这类消息入口，用户希望它马上有反馈。真正耗时的事情，应该交给后台队列慢慢处理，而不是让回调接口一直等着 AI 生成完。
所以我现在更愿意把这类系统理解成：
聊天入口只是触发器，真正的产品在后台队列里。
3、报告不是普通总结，而是一次压缩版 CEO Review
一开始我不想让它只做“总结”。
因为总结很容易变成废话：这个想法有价值、需要进一步验证、建议做 MVP。
这类话没有错，但没有行动价值。
所以这套报告的分析依据，参考的是 Garry Tan 开源的 gstack/plan-ceo-review。
Garry Tan 现在是 Y Combinator 的 President & CEO，也是 Initialized Capital 的联合创始人。他长期站在投资人、创业者和工程管理者的交叉点上看项目：既看愿景，也看产品、工程、上线和失败路径。
这也是我觉得 plan-ceo-review 值得参考的原因。
它不是那种“让 AI 写一篇漂亮商业分析”的模板。它更像一个投资人、创业者和工程负责人一起看项目时会追问的问题清单。
我最看重的是它的 11 个评审维度。Garry Tan 的 review-sections.md 里把评审拆成架构、错误与救援、安全与威胁、数据流、代码质量、测试、性能、可观测性、部署与回滚、长期演进、设计体验等模块，而且强调不要因为觉得某个项目“只是战略”或“只是想法”就跳过实现细节。
这个思路对我很有启发。
一个想法真正会死掉的地方，往往不是愿景不够大，而是输入为空怎么办、API 失败怎么办、用户重复触发怎么办、上线后怎么停、10 倍负载先坏在哪里。
所以我没有把 plan-ceo-review 原封不动搬进来。原版更适合交互式评审，会一步步追问和确认；我的场景是一条灵感消息自动生成 2-4 页 PDF，不能让系统停下来问我十几轮问题。
因此我做的是一个“非交互压缩版”：
- 保留它的 11 个评审维度；
- 把每个维度压缩成“发现 / 建议 / 为什么 / 风险等级”；
- 针对单条想法补上竞品扫描和下一步动作；
- 输出适合手机阅读的中文短报告。
所以我把报告结构改成了一个压缩版 CEO Review。每条想法固定输出几个模块：
- 一句话结论：值得、暂缓，还是不建议。
- 这个想法到底是什么：用户、场景、痛点、10 分钟体验。
- 是否已经有人在做：搜索关键词、竞品/先行者、产品形态、差异化。
- CEO Review：架构、失败路径、安全、边界、测试、性能、可观测性、上线回滚、长期演进、设计体验。
- 最小实现路线：先跑通闭环，再补稳定性，最后产品化。
- 风险与失败信号：什么时候应该停。
- 下一步 3 个动作：只列最小可验证动作。
这个结构的好处是，它逼迫一个想法从“我觉得不错”变成“我下一步该怎么验证”。
一个好灵感不应该直接变成项目，它应该先变成判断。
这也是我做这个工具后的一个感受：AI 最有价值的地方，不是替我兴奋，而是替我降温。
它要帮我看到这个想法的边界、替代方案、失败路径和最小验证动作。
4、“是否已经有人在做”是整个报告里最重要的一节
我后来专门加了一个模块：是否已经有人在做。
每条想法都默认做一次轻量调研，找 3-5 个相关产品、项目、论文、开源库或网页。
这个模块很关键，因为很多想法在脑子里出现时都很新，但一搜就会发现：
- 有人已经做了，而且做得很完整；
- 有人做了一半，但没有覆盖本地场景；
- 有论文和开源库，但没有产品化；
- 有产品，但用户定位和自己的想法不一样；
- 看起来没人做，其实是关键词搜错了。
所以我不希望 AI 只在本地“闭门评审”。
只靠模型记忆的分析，很容易显得很聪明，但不一定接地面。
一个想法是否值得继续，至少要先和现实世界碰一下。
这个项目里，竞品扫描可以由 Codex web search 完成。报告里会保留 URL，并尽量说明它解决什么、和原想法哪里相似、有什么可借鉴。
比如“轻量版 AI-HIS 给基层医生用”这类想法，系统不会只判断“基层医疗信息化有机会”。它会先去看 OpenMRS、OpenEMR、Bahmni、GNU Health 这类开源 EMR/HIS，也会看 AI 临床辅助、农村诊所 AI-CDSS、低资源医疗信息系统这些相邻方向，再判断这个想法到底是一个完整 HIS、一个医生工作台，还是一个更窄的 AI 病历与随访工具。
我没有把它做成深度行业报告，因为那样会太慢。这个阶段只要完成一件事：让这个想法从“孤立脑洞”变成“放在现实坐标系里的判断”。
5、白板图不是装饰，而是强迫自己把想法讲清楚
后来我又加了一张白板图。
一开始图也踩过坑：它容易画成“飞书到 Codex 到 Obsidian”的流程图。
但我真正需要的不是解释这个自动化项目，而是解释用户发来的那个想法本身。
所以我把白板图的职责重新定义为：
白板图要讲清楚这个想法的内涵，而不是炫耀自动化链路。
它应该总结：
- 目标用户是谁；
- 真实痛点是什么；
- 核心体验闭环是什么；
- 最大风险在哪里；
- 最小 MVP 怎么验证；
- 下一步动作是什么。
这张图对手机端阅读尤其有用。PDF 一打开，先看到一张图，大概就知道这条想法值不值得继续看。
下面这张图就是最近一条想法“轻量版 AI-HIS 系统给基层医生用”的自动生成结果。
这条想法的报告结论很有意思：
值得做，但只能从“基层医生的门诊效率工具”切入，不应一开始做完整 HIS。
这个判断对我很有启发。
因为“AI-HIS”这个词很容易把人带进一个巨大系统：挂号、收费、药房、医保、检验、影像、质控、报表，一个都不能少。
但报告把它往回拉了一步：
基层真实痛点不是缺一个“大而全”的系统，而是缺一个低培训、低成本、能把问诊、病历、处方提醒、随访和患者解释快速串起来的工作台。
也就是说，它早期不应该叫“轻量 HIS”，而应该叫：
基层医生的 AI 门诊工作台。
第一版只做几个高频动作：
- 患者建档；
- 语音或文本问诊记录；
- 结构化病历草稿；
- 诊疗提醒和禁忌提示；
- 处方注意事项；
- 随访计划；
- 患者解释话术。
同时边界要非常清楚：
不替医生下诊断，不自动开处方，不替代合规 HIS 和医保接口。
这个收缩非常关键。因为一旦直接做完整 HIS，项目很容易变成长期集成交付；但如果先做“AI 病历与随访闭环”，它就有机会在 2 周内让基层医生真实试用。
这就是我想要的报告效果：不是“帮我肯定一个想法”，而是帮我把想法变窄、变清楚、变可验证。
6、真正难的不是代码，而是长期运行
这个项目里，代码不是最难的部分。
真正麻烦的是这些边角：
- 飞书官方配置到底用长连接还是 HTTP 回调；
- Verification Token 和 Encrypt Key 在长连接模式下其实不需要；
- Codex 报告生成耗时很长，不能放在飞书回调里；
- PDF 要手机可读，标题太长要自动换行；
- Markdown 表格导出 PDF 很容易变形；
- 图片生成不能只输出提示词，必须真的调用 image2；
- 机器人改名不影响链路，因为真正依赖的是 App ID 和 App Secret；
- 本地自动化不能直接让 Codex cron 派生长期联网进程，否则可能遇到 DNS/网络限制；
- 开源时必须把自用版本和干净版本分开，不能把 token、路径、私有 skill 原样发出去。
其中最典型的坑是“自动启动”。
我最初以为，既然 Codex 有自动化能力，那每天早上 6 点执行 npm run local:start，晚上 12 点执行 npm run local:stop 就行。
后来发现不行。
因为自动化任务自己可以执行命令，但它派生出来的长期进程可能继承受限环境，导致飞书和 Upstash 都解析不了。
最后的方案是：
Codex 自动化只负责定时触发，真正的常驻进程交给 macOS launchd 承载。
也就是：
Codex 自动化
-> 到点执行 npm run launchd:start
-> launchd 启动 listener 和 worker
-> 系统用户服务负责长期运行
停止时也是：
Codex 自动化
-> 到点执行 npm run launchd:stop
-> launchd 卸载 listener 和 worker
这个调整之后，本地进程就稳定多了。
这也是我对 AI 自动化的一个新认识：
AI 可以参与调度，但不要让 AI 聊天环境自己承担长期基础设施。
它适合做触发器、控制台、解释器；真正长期跑的东西，还是要交给系统服务、队列和日志。
7、为什么我把它开源，而不是只留给自己
这个项目现在已经是一个可用 MVP。
它支持：
- 飞书官方机器人收集想法；
- Upstash Redis 排队；
- Codex 生成 CEO Review；
- Codex web search 做竞品扫描；
- Codex image2 生成白板图；
- Obsidian 自动归档 Markdown；
- Chrome 自动导出 PDF；
- 飞书文件 API 回传；
- macOS launchd 常驻和定时启动；
- 快速记录模式；
- 开源版敏感信息清理。
我把它整理成了开源项目：
https://github.com/LIUgongxi2046/feishu-idea-catcher
开源版本里，我已经去掉了个人路径、密钥、token、运行状态文件和本机日志，只保留可配置的示例文件和通用说明。
开源时我做了两件事：
第一，把自用版本和开源版本分开。
自用版本保留我本机的 .env.local、飞书配置、Obsidian 路径和运行状态。开源版本只保留 .env.example、通用脚本、文档和安全边界。
第二，把私有白板图 skill 做了一个干净版。
它保留白板图风格规则，但默认不带个人签名、不带本机路径、不带任何密钥。用户如果想加自己的署名，可以通过环境变量配置。
这件事看似琐碎，但很重要。
一个能跑的个人项目，离一个别人敢 clone 的开源项目，中间差的往往不是功能，而是清理、文档和边界。
8、这个项目对医疗 AI 内容工作有什么用
表面上看，这是一个个人效率工具。
但我真正感兴趣的是，它会改变医疗 AI 内容生产的前半段。
过去做一个选题，流程大概是：
看到一个想法，先记下来；有空再查资料；再判断有没有人做；再决定写不写。
现在这个流程可以变成：
发给机器人，让它先生成一份初筛报告。
比如“轻量版 AI-HIS 给基层医生用”这条想法，它自动给出的方向是：
不要一开始做完整 HIS，先做基层医生最痛的 AI 病历与随访闭环。
这对医疗 AI 内容工作也很有价值。
因为它不是只给我一个“可以做”的判断，而是直接把后续内容拆成了可验证的问题：
- 基层医生一天门诊流程里，最耗时间的是哪一步？
- 现有 HIS 为什么更像财务/监管软件，而不是医生助手？
- AI 病历草稿能不能让单次病历书写时间减少 30%？
- 高血压复诊、发热门诊这两个场景，能不能先跑通？
- AI 输出必须怎么设计，才能始终停留在“草稿/提醒”，而不是越界诊断？
这就可以直接变成一个文章系列，也可以变成一个产品验证计划：
- 第一篇：为什么基层医生需要的是 AI 门诊工作台，而不是又一个 HIS；
- 第二篇：AI 病历草稿如何减少基层门诊文书负担；
- 第三篇：慢病复诊和随访，为什么可能是 AI-HIS 的第一个切口；
- 第四篇：医疗 AI 产品里，哪些事情必须让医生最终确认；
- 第五篇：从 5 位基层医生访谈开始，怎么验证这个需求。
每一篇都不只是观点文章，还能反过来服务产品判断。
这就不只是一个单篇选题，而是一个从内容到产品的验证路径。
AI 自动化最有价值的地方，不是帮我多写几段文字，而是把一个模糊念头推到“可以访谈、可以原型、可以试点”的位置。
9、如果重做一次，我会保留这几个判断
第一，入口一定要在用户已经使用的地方。
对我来说是飞书机器人。对别人可能是 Slack、Telegram、企业微信或网页表单。但原则一样：不要让记录想法这件事变重。
第二，长任务必须异步。
只要涉及搜索、AI 生成、图片、PDF，就不要放在消息回调里。先入队，再慢慢处理。
第三，报告结构比模型本身更重要。
同一个模型，如果没有固定评审结构，很容易输出漂亮废话。固定章节会让系统稳定地产生“可比较”的结果。
第四，不要跳过竞品扫描。
想法必须和现实世界碰一下。哪怕只是轻量搜索，也比闭门分析强很多。
第五，本地 AI 自动化要尊重操作系统。
Codex 可以很聪明，但长期运行、定时启动、日志和重启，还是交给 launchd 这种系统工具更稳。
第六，开源前一定要做敏感信息清理。
.env.local、token、App Secret、本机路径、私有 skill、日志、状态文件，都要从开源版本里剥离。
10、下一步我想继续补什么
这个 MVP 已经跑通，但它还只是第一版。
后面我最想补的是三个方向。
第一，语音入口。
真实场景下，很多灵感不是打字，而是语音。下一步可以接飞书语音转文字，或者让用户先用系统语音输入。
第二，多模板。
不是所有想法都需要 CEO Review。有些只需要快速记录，有些适合变公众号选题，有些适合变产品 PRD，有些适合变研究计划。
第三，把“轻量版 AI-HIS”做成一个真实需求验证。
这可能是这个项目自己产出的第一个真正有价值的内容方向。
我会先做 5 位基层医生访谈，只问一天门诊流程、最烦的文书、现有 HIS 最大阻力，以及他们愿意为什么样的工具付费。
然后做一个非常窄的可点击原型，只覆盖建档、问诊记录、AI 病历草稿、处方提醒和随访计划，不碰收费、医保和完整院内系统。
如果这个原型能让基层医生在 10 分钟内学会，并且真实减少病历书写时间，再考虑继续往产品方向推进。
结尾：我现在更相信“小工具先行”
做完这个项目后，我有一个很强的感受：
很多 AI 产品不应该从一个大平台开始，而应该从一个高频、低摩擦、能立刻跑通的个人工作流开始。
先把自己的真实问题解决掉。
先让一个想法能被接住。
先让一条消息能变成一份报告。
先让一个模糊念头能变成下一步动作。
当这个闭环真的对自己有用，再考虑开源、教程化、产品化。
这个飞书灵感捕手对我来说，就是这样的一个小闭环。
它不完美，但它已经开始工作。
而一个已经开始工作的系统，往往比一个还停留在脑子里的宏大产品更值得继续投入。
最后也想问一个具体问题：
如果你每天只能自动化一个“从想法到结果”的流程，你最希望它帮你接住哪一种想法？