刚想到就发了，补一下我自己的话，大概最近有这么两件事……

一个是搞了个用 Metal 和 GPU 渲染 shader 和光追的小型工作台，把一大堆乱七八糟的渲染管线搭了一下，最近的成果大概是把 RTIOW 的那个经典场景成功的跑了起来，帧率还行。

另一个是把 2022 年的一个曾经想要实现（但从来没写完，后来就放弃了）的奇怪的教学用 VM 写完，顺手把当初留下的 coroutine 草稿也实装了，然后看到自己 4 年前手写的 bytecode 真跑起来了还能打--trace 看内存和栈发生了啥，有点奇怪的感觉。

然后回过头想的话要不是最近 Codex 使劲送重置大概我不太会有这个心思搞这两个这么怪的项目，所以也有点好奇大家都有做出什么奇怪的或者不奇怪的项目。不过反过来说，我感觉如果用 AI 蹬出个 CRUD 或者 Web 前端，对我来说大概也蛮怪的，感觉下次要是还有新的重置票子也许就试试蹬个前后端项目好了（

我什么时候看到把 Java 塞进别的语言（包括但不限于 JS/TS 、Go 、Rust 、Haskell……）能不笑出来（

Fable 都取消免费额度的话，感觉会不会重置就没了（

感觉可以，但这个有测试的必要吗？

我这边好像头像的话，大概有相当一部分是猫猫狗狗花草虫鱼或者随便一张图，还有不少动画或影视作品头像，风格画的也有，还有不少没头像的，仔细想的话似乎用自己照片的反而是少数。

不过我在国外的话是不是不太有可比性……毕竟还从来没在中资企业呆过，认识的同事里也没有第二个亚裔（

我自己用的就是随便找的二次元头像（

没有意义了。

如果任何人都可以用 AI 在半小时里用 Rust 生成能跑起来、可读性和性能都还行的 Rust 代码，我为什么要花一大笔时间精力去学习一个被 vendor locked ，表达力极度贫乏，还得付出大量沉没成本，而且可用场景非常受限的 DSL ？

我觉得目前来说不会，因为现在大部分 prompt engineering 甚至连 not even wrong 都算不上，一堆叠床架屋的 prompt framework 的效果是不是真的比简单的自然语言有明显的收益成本比，我是对此有怀疑的。

没感觉换日语或者英文的时候有明显降智的现象，至少在让他给出学术论文和做分析的时候我感觉语言和回答质量没有明显关系。

我自己在刚开始玩 agent 还不熟悉也没有工具链的时候就是让 Codex 去~/.codex/sessions 里面找 jsonl 来读历史讨论串来做 handoff 的。

那时候我用的是 Zed 里面的 Codex ACP ，还没用过任何 Codex 、Claude Code 或者其他的 Agent CLI 或其他应用，一开始用的也就是当 chat 然后可以让 AI 直接动项目代码。不过 Zed 的 Codex ACP 插件 bug 比较多，我那时候用的时候又随便插本地文件把他的格式化渲染搞崩了，在当时的任务里我得从上一个讨论串总结出下一个讨论串的思路，但看着一堆乱码脑壳疼。

然后就让 Codex 帮我去找~/.codex 里面讨论串存在哪里帮我把第一个讨论串的内容捞出来。歪打正着地发现这能用。

后来的话，迁移到 Codex 官方应用后，handoff 、.agents 、skills 这些倒是都有用，但 sessions 里面的 jsonl 作为 ground truth 我觉得是不可替代的。

而且通过 Zed 的 ACP 可以直接把所有 CLI 里面的讨论串拿出来通过格式化 view 去查看，或者输出全量 markdown 原始文本，方便后续审计，不知道这是不是你想要问的？

总感觉还是 Zed 用起来舒服（

没人争论 Rust 吗（

昨晚用剩 20%就睡了想着过两天重置一下，一觉醒来发现又是 100%了。

我用 Fable 拿来做 code review 和架构分析还是蛮好用——不过我直接让他不要用软工那一套来分析。

代码或者比较普通的任务可能没那么好用吧。

比起「全栈」，还不如拿纯前端做切入口，把 web 当成 SICP ，把 JS 当成 Lisp ，从 MDN 文档、DOM 模型、浏览器渲染和生命周期还有 vue/react/solidjs 等框架的核心假设、响应式原理和第一性出发去构建一个「 web 版本的计算机组原课」，这样以后想做复杂前后端项目还是转 infra 还是搞 AI 还是 rewrite in Rust 都不至于从零开始。

在 2026 年的话，「前后端全栈 MVC 框架 JavaredisCRUDsql 」这套路子的话，反而是最容易被 AI 替代的吧。

后端我也觉得没啥意思…当然这可能是我的偏见，但我会觉得 fetch join 、REST 、auth 、redis 、CRUD 最后都是套库堆砌框架，但前端的很多东西，比如把 HMR 和 reactivity 作为 invariant 去保持，再比如什么时候用 rIC/rAF ，什么时候 API 越傻越好，这些 AI 能帮你写，但 AI 没法帮你思考。

对了，不管你喜欢前端还是后端，我想说的是，前端不是只有切图和控件，前端也有一整个 runtime 。

问题：所谓 Fable 的优势，到底是模型能力差异，还是产品叙事把一些本来 GPT Codex 也能做到的东西重新包装成了“质变”？

> 我：或者换个角度讲，如果「一个程序员必须用 Fable 才能做某些 Codex + 5.3-codex or 5.5 xhigh/high 无法做到的事情」，这是因为 GPT 太烂、Fable 太强，还是这个程序员自己烂？

GPT：我会很直接地说：大部分情况下，这不是“GPT 太烂 / Fable 太强”，而是这个程序员的工作方式和任务建模能力不够。

但这里不能粗暴等同于“这个人智力差”。更准确地说，是：

这个人把 coding agent 当成了替代自己判断的黑箱，而不是把它当成一个可调度、可验证、可反驳的执行/推理部件。

在这个前提下，Fable 的“强”很容易变成一种代偿。

真正要看的不是“用了 Fable 才成功”，而是：

拿走 Fable 之后，程序员是否还能描述为什么这么做、如何验证、哪里可能错、下一步该查什么。

如果不能，那 Fable 是轮椅。

如果能，那 Fable 是外骨骼。

因为很多程序员（尤其是 web developer ）的一个很恶劣的习惯就是：

- 我看这里不对，顺手改了
- 怎么这个没 commit ，多可惜

往宽了说，软件开发的方法论的很多假设和培训方法都是在持之以恒地鼓励程序员「顺手、高语境、隐式、模糊」地思考。LLM 自然顺手把这些坏习惯从语料里拿来了。

这还真不能怪 AI 。要怪就怪程序员太顺手了，比如说你们张口闭口顺手一提的业务。

这种「明明有权限但回报说没有权限」一般就是讨论串废了的征兆吧。如果你用的是 5.5 ，那似乎确实有用量下降非常快然后有些地方很不稳定的问题。

@yifangtongxing28 说个更难听的实话，这个老板现在对 op 也没任何价值了。