netabare

比起「全栈」，还不如拿纯前端做切入口，把 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 了。

而且五年也太长了吧（