没有意义了。

如果任何人都可以用 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 也没任何价值了。

代码复杂度本来就不能用行数来衡量。

我倒是会觉得，这个问题在我这里会换个角度 formulate ，也就是「我是不是必须要牺牲自己的真诚来换一次面试机会」？

如果这样的话，那我会觉得我还挺失败，变成了没用的中年 senior 了。

而且五年也太长了吧（

感觉没啥好的选择，我现在在其他功能都迁移到 Zed 和 CLI 后，IDEA 留着似乎真的就是为了那个 git 插件，不光是 diff 和解决冲突，还有 rebase 工作流、squash 、cherry pick 和随便开分支，比手敲命令还舒服。

而且 JB 最近似乎更新了 interactive 的 UI ，用起来很舒服。

说实话，哪怕官方开源个单独的客户端我也会怀疑会不会没 IDEA 自带的舒服，毕竟做单独的客户端很可能会搞出个不同的设计吧。