没人争论 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 自带的舒服，毕竟做单独的客户端很可能会搞出个不同的设计吧。

别的操作系统里直接就能做的事情，还要「推送」，还要「多次暂停」。

这味也太重了。

感觉不如 Type driven ，我对 spec 的态度是不信任。

因为代码和项目复杂后，spec 基本上没人遵守。

其实这个就是模块化、抽象和把复杂项目拆成很多小元件的本意。只可惜软件工程讲究的就是个叠床架屋，所以最后设计模式、架构一个比一个复杂搞得云里雾里，封装和抽象全往加 accidental complexity 去了。

op 这个做法算是用 AI 正本清源了。

其实也想到我自己前段时间工作上遇到的一个事情，但并不是 AI ，大概就是做的项目的 runtime 的 hypothesis 很不好控制，同时又要为 library 和框架的后续可扩展性思考，又要满足客户稀奇古怪的运行时要求，又不希望被客户的屎山业务倒灌把项目搞成 day 0 legacy 。

我那时候的思路倒不是拆 project （毕竟还是我自己在做），而是一个 repo 几个模块互相独立做，UI 和渲染都去掉了，直接在 vue 里写 TSX 打出 div 「看着表格假设他是个可视化组件」，响应式对上了再把渲染库插进来，然后立刻断网把缺的数据和实现全 fake 堵上，直接做出一个跟客户 app 对标的最小 app ，做完立刻把客户那坨狗屎接进来然后看看能不能把这个 app 换成「符合客户要求的最小 app 」。

全程我给我自己的要求是：不写任何「整合、修补、migrate 代码，尤其是对接不同的运行时和框架的，如果有一行，说明我写坏了」。然后就让 TS 类型体操来帮我把这一堆模块串起来。

然后就把去年两个团队定义了一大堆架构都搞不下来的任务一次性打通了。

所以我想，如果 op 那边能保持两个仓库之间有很强的隔离性质，其实这个思路还是蛮好，甚至可能都非常适合 AI 的。我这边那时候做那个项目做完整个人都不好了，要是那时候能让 AI 帮忙分担啥就好了（可惜不能）。

会不会你说的那种「钻研技术」并不是真的对技术和新鲜事物有多么好奇，而是一种结合了 sunken cost fallacy 、路径依赖和自我说服的 cognitive bias ？

然后 AI 把 cost 打成了 0 ，再把 ROI 倒过来了，才让这种 fallacy 显得那么刺眼…与其说是「找不到喜欢的，感觉一切都充满了铜臭味」，我总感觉这更像是 cost and reward 曲线变得 absurd 后，那个 sunken cost 在强词夺理。

或许「学技术做网站，去熬夜钻研技术，看掘金」本身并不是一种真的热爱，而是一种用勤奋和「我 pay 了 cost 」来掩饰吧。

我自己的话，我其实并不信任 AI ，也很不想整天吹 AI ，但我感觉这两年来，尤其是最近半年来，AI 给我带来的反而是一种螺旋升天的感觉。如果说以前我的 backlog 是堆积成山没时间整理只能慢慢做，AI 则是把一大堆积压的陈年 idea ，该 triage 的做了，过期的关了，有的变得 trivial…然后再给我灌了更多的 idea 。

所以「热爱」到底是什么…

你所热爱的就是你的生活吗。

精通 TCP 是吧，那来说说粘包和粘包警察是怎么回事。