swananan

感觉 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 帮我写，平常交流，让对面自己适应，我现在都不担心感情色彩误用了，反正对面会消化掉