当前时间: 2026-04-10 06:04:17
分类:办公文件
评论(0)
发布一个小软件 feidex 预览版康神昨天发布了一个 codex-remote-feishu,那我也发一个这两天做的 feidex (feishu + codex),github直达链接在下面阅读原文。最近开始用 AI 写程序,误打误撞用上了 codex(主要是还能买到廉价token),大概的水平是持续每天输出10000行可以跑的代码。生产力极大提升的同时,有一个很大的困扰是电脑经常被女儿霸占,于是就琢磨能不能用手机调用codex来写,毕竟即使在codex-cli里面,实际做的也就是敲字和批准。前端选型用的飞书,相对于微信来说,富媒体的界面可以更好的显示内容,按钮菜单可以方便快速操作,还可以每个聊天窗口各自连接一个机器,每一项都碾压微信目前比较简陋的临时插件。感谢openclaw,各家都极大的简化了机器人的接入,大致上扫一个二维码就能自动把机器人创建和权限开通之类的问题直接解决。似乎手机编程的所有障碍都被扫除的差不多了。和康神说了一下这个想法,他说他正在自己写,我还嘲笑他说肯定已经有现成的解决方案了,去搜了一把果然到处都是,安装比较出名的 cc-connect顺利装上,结果用了两天发现各种不顺手,权限总是无法审批,天天只能在沙盒里跑抓个页面都不行,于是研究了一下发现 cc-connect 默认是调用 codex json 接口,回合制,所以注定没有权限审批的能力,能把上下两句连上就算给你面子了。再仔细研究一下发现 cc-connect 支持 acp 协议,那就给 codex 套个 acp-adapter,又用了一天,还是很难受,毕竟 acp 是个通用协议,cc-connect 除了飞书又支持一大堆 channel,凡事只要通用,就没法优化到极致。所以最后走上了康神的路线,自己用 codex app-server 协议从头 vibe 了一个 feidex。过程是一个很典型的飞轮过程,先在电脑上用 codex-cli 读codex app-server协议和飞书API协议,做个基本设计,然后开始让他写代码,做了半天,至少你说个hi,codex能回个hi,把各种消息链路打通。然后就可以一半一半,在电脑上做做,在手机上做做,用的过程中有什么不爽的,就记下来让电子牛马慢慢改,自己也在过程中不断加深对codex和飞书协议概念的理解,你才能做出更合理的架构设计,最终达到和 AI 吵架他都吵不过我的程度(今晚花了至少50刀额度来说服AI他对于steer能力的设计是错误的)。在今天下午增加了手机上就可以命令服务器下载新版本更新的能力后,基本所有工作就都在手机上进行,迭代速度大幅提升,最终做了一大堆功能自己都来不及验证。大致说一下一些我觉得做的还可以的特点吧。工作区就是切不同的目录,每个工作区里面可以有多个会话,这个会话和电脑上的 codex session 是对应的,所以你可以在电脑上搞一阵,然后在手机上接管继续(/history可以看到之前所有的对话历史),反之亦可。对话的过程中,你可以选择要不要看 codex 中间啰嗦的 tool call 过程,不看的话就是各种正文 message 一段一段发给你,直到最后高亮的 final message。当然用过 AI 的都知道这个吐字的过程可能很长,codex 执行复杂任务甚至可以长达数十分钟,这个过程里你可以随时在飞书里继续输入,服务会以队列形式等上一条完全完成后自动发送。另外如果中间发现AI走偏了的话,你也可以随时回复AI的消息,这时就不会等他结束,信息会实时插入当前对话过程来纠偏(这个行为就叫steer,前面吵架的点,我说都按root ID来反查对话就行了,AI非要用 parent ID一层一层慢慢查)。沙盒和审批policy完全对齐codex的配置选项,可以随意随时调整,所以过程里很可能碰到权限审批,这时会给飞书发一个卡片,点一点选择就行了,如果纯对话界面的话就很难想象了,难道要不断输入“同意”?为了方便操作,有一堆内置命令切换模型能力之类的,都收在一个叫 /menu 的卡片式菜单里,都可以点击操作,当然自己手动输入 /threads policy 这样的命令也是等价的,再次体现了点击互动比纯手动输入的便利性。所以飞书底部宝贵的自定义按钮区域,就很 happy 的定为 "继续" "/stop" "/menu" 三项就可以了。还有两个从康神codex-remote-feishu那里开源借鉴的能力,肯定也要说一下。一个是加了一些 reaction,这样AI thinking 的时候总有一些小表情在动,至少你知道他还在工作。另一个是传图的时候,服务器端会等待下一条文本,组合在一起发给codex,这样就可以方便扔个截图同时说你照着这个图来搞。而且这个项目整体都从康神那里吸取了很多意见、建议,以及,和而不同,各自vibe。最近有很多人问我在搞什么,你看,磨刀不误砍柴工,天天磨刀也挺有趣。买的 token 总要想办法用掉,总体上感觉这个行业有了新刀之后,生产力会溢出,要砍的柴其实没那么多。所以也别考虑开源用什么license了,别人八成是不会直接用你磨的刀的,能给世界提供一些训练语料就不错了。免责:相关代码和文档都是AI生成的,我没有review过,你要是能跑起来可能是运气,跑不起来是应该的。
基本
文件
流程
错误
SQL
调试
- 请求信息 : 2026-04-10 10:01:49 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/503964.html
- 运行时间 : 0.094959s [ 吞吐率:10.53req/s ] 内存消耗:4,628.56kb 文件加载:145
- 缓存信息 : 0 reads,0 writes
- 会话信息 : SESSION_ID=9a6b4f0313d0818dea7611d5d6290cfa
- CONNECT:[ UseTime:0.000587s ] mysql:host=127.0.0.1;port=3306;dbname=wenku;charset=utf8mb4
- SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.000744s ]
- SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000286s ]
- SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.001877s ]
- SHOW FULL COLUMNS FROM `set` [ RunTime:0.000523s ]
- SELECT * FROM `set` [ RunTime:0.000585s ]
- SHOW FULL COLUMNS FROM `article` [ RunTime:0.000602s ]
- SELECT * FROM `article` WHERE `id` = 503964 LIMIT 1 [ RunTime:0.004459s ]
- UPDATE `article` SET `lasttime` = 1775786509 WHERE `id` = 503964 [ RunTime:0.001106s ]
- SELECT * FROM `fenlei` WHERE `id` = 64 LIMIT 1 [ RunTime:0.000220s ]
- SELECT * FROM `article` WHERE `id` < 503964 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.000432s ]
- SELECT * FROM `article` WHERE `id` > 503964 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.000385s ]
- SELECT * FROM `article` WHERE `id` < 503964 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.005306s ]
- SELECT * FROM `article` WHERE `id` < 503964 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.000579s ]
- SELECT * FROM `article` WHERE `id` < 503964 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.002277s ]
0.096702s