我当时也看上了，还问了，说不卖

找一个好点的开源社区（有技术深度，有大佬反馈的那种）
我现在反而比以前更有激情了

一直两个都在高强度使用，我的体感上，claude code 去年写代码不如 codex ，现在开始有点追上来了，不过我还是喜欢 codex

@yk2 现在改了啊，以前是不能的

你能同时拿阿里两个校招 offer ？

@xxiaowangwang tmux 快捷键是这个 ctrl+prefix+z
但还是不够方便，可能我主屏放 tmux 终端，下次我调整开多个 tmux Session 看看

我目前工作流里面，可能比较难受的地方，在于单独小窗口里面，ai cli 输出的信息多，需要翻滚。我一般只能进入 tmux 复制模式，然后开始键盘翻滚，或者让 ai cli 写到独立文件。

我是 terminal 里面用 tmux + vim + ai cli + lazygit ，这些命令独立于 terminal 就可以完美工作。

我看完了项目，感觉我 tmux 也可以纯键盘操控，并发多 ai agent 工作，好奇问问，还有哪些我遗漏的杀手锏功能吗？

读书时候很少遇到，但是到了职场，遇到很多

我好多年前的一个内存写飞（这是我现在喜欢 rust 的原因），当时后果蛮严重，上了微博热搜

感觉 bug 了吧，今天确实量很快

codex 5.4 xhigh
claude code opus 4.6
我都拉满了蹬，写系统编程，感觉以前是 codex 好，现在差不多，codex review 还是更好点

@wwulfric 蛮酷的，我学习了下，这个工具底层机制，应该是依赖了 Python 虚拟机官方设计的调试后门，可以拿来做动态追踪。理论上限制比 ebpf + uprobe 要小。当然，uprobe 只是个媒介，ebpf 也可以考虑尝试 bpftime 之类的手段，来提升效率。

话说回来，我的工具也可以努努力，支持 Python 这种虚拟机语言（得非常努力，并且是若干年后）。但是需要自己去理解 Python 虚拟机实现，去兼容不同版本，去把信息拉出来，终归不如走官方渠道来的标准。

我现在比较大的心愿，就是看看后面能不能把 Rust 支持好了 = -=。

@YanSeven 是的，我最近换成 AI 来写脚本，搞得我已经快忘记语法了（主要是最近一直也没迭代语法相关的功能

我现在直接把语法文档塞到 GhostScope 的工具里面，skill 里面可以让 AI 直接从工具里面获取语法文档，来编写脚本，确保语法怎么迭代，AI 都只会写和现有工具版本支持的脚本。

https://jt26wzz.com/posts/0015-why-we-struggle-with-improvised-speaking/

共勉，我觉得多练就完事了

@subpo 我感觉也差不多，我手里个人 codex 有三个 plus 号，然后公司有无上限的 Claude code 。我经常对比赛马，我个人体感上，纯写代码，codex 还是更靠谱，特别是 review 环节。另外，Claude code 还是偶尔喜欢捏软柿子（尝试回退到简单方案），不过 Claude code 写邮件，写文档，确实蛮好的

我已经坚持很多年后排必系安全带了，因为急停或者碰撞，系了安全带，很可能保住狗命

我不太熟悉这个，插个眼，等大哥回复。

我本来是想 ebpf redirect 是 unix domain socket 场景的优化方案，我看到你出现了 oom 有点震惊，不是有 sk send_buf 之类可以背压保护吗。问了 ai ，说 ebpf redirect 这个实现，直接绕开了这个限制。。。

我又问了 ai ，说 绕开的原因是什么，ai 说，是因为 ebpf redirect 运行在软中断里面，没有进程上下文可以阻塞，我觉得这个很合理，说服了我。

那既然这样，就不适合用 ebpf redirect 方案，去解决这种生产者消费者速率不匹配的场景问题了。

ai 推荐了 splice 和 io-uring 。

以上是我边搬砖（围观 cc ）边水贴问的，耗时不过十几分钟，按我以前的经验，要探索到这个阶段，得花一个晚上。。。

正式邮件都是 ai 帮我写，平常交流，让对面自己适应，我现在都不担心感情色彩误用了，反正对面会消化掉