GiantHard

上哪里可以玩啊？

把 vpn 集成进浏览器里面的话，就没法在公网通过 NAS 手机客户端访问了内网服务了，这样的用户体验得下降一大截。

我有一个想法，可以通过某种技术，将 NAS 上的指定端口映射到外网设备 localhost 的固定端口，这样外网客户端就可以通过指定本地端口连回内网 NAS ，而且也不会干扰客户端路由表。

不用 Redis 的架构案例： https://v2ex.com/t/1187618

我安装了官方的 IDE 插件，通过 IDE 启动的 Claud Code 实例跟 IDE 的连接挺稳定的 https://plugins.jetbrains.com/plugin/27310-claude-code-beta-

> 我个人理解是，只要 AI 无法消除幻觉，做到 100% 准确，就始终需要使用者具备判断 AI 是否准确的能力，而非照单全收。在这个例子里面，能断定 AI 可以解释清楚的前提是，你能完全理解以上提及的知识点。否则 AI 自圆其说，也许会把你说服，但却是在扯谎，那就非常糟糕了。

我感觉你这里已经提到了一个比知识面广更重要的特质了，就是不轻易被 AI 说服，或者说，要具有批判性思维。

> 另一方面，在 AI 的知识深度与广度都远超人类的今天，我们这些技术人员应该把精力放在哪里呢？有些迷茫。

如果是为了工资而编程，那么不管有没有 AI ，技术人员是不是都应该把精力放在搞钱上？卖时间的就应该想办法让单位时间更值钱，卖体力的就应该想办法让劳动产出更值钱。

> 最后，这真的不算八股，AI 当然可以解释清楚，但这么一段简单清晰的代码，你还不知所以然的话，那对着 Vibe Coding 出来的屎山，最后只能束手无策了。

确实不算八股，这算 NodeJS 实现细节；但既然 AI 可以解释清楚，为啥还会不知所以然？

我的一个感受是，现在 LLM 的知识广度已经远远超过人类了，考察一个人是否了解一项技术细节意义确实没以前那么重要。

> 只要 AI 不能做到 100% 准确，就需要最终由人来把关，前提是你真的有能力做到这点。

人也做不到 100% 准确，要不然就不会有 QA 团队了。之所以我们需要人类开发者，是因为人类开发者拥有一些 LLM 不具备的优势。

我觉得的人相对于 AI 的一个优势就是读不懂一些晦涩的代码，现在 LLM 读混淆后的 JS 都能把业务逻辑还原得八九不离十，这对于绝大多数人类来说是非常艰巨的任务。但也正是因为这点，人厌恶读起来不舒服的代码，在代码出现坏味道的时候，人的潜意识中就会产生抗拒情绪，这种情绪又会反过来让人避免编写有坏味道的代码：

> 一个合格的开发应当知道一些会引发典型的回调/异步等时序难以确定的场景，然后在正常的开发过程中，别这么用他们

因此，只要 AI 生成的代码还需要人类参与维护，就需要有品味好的开发者充当 AI 代码的质检员，要么拒绝晦涩的代码进入代码库，要么在代码库出现坏味道的时候，能够自己动手或者指挥 AI 去重构、重写。

有些岗位对物理位置有要求，例如：

> This role requires candidates to be based in the European Union.

希望能支持这类筛选条件

有意思，在桌面环境下追求平铺窗口，在终端模拟器下追求堆叠窗口。

@Chuckle #32 如果打算用 Context 传递 Observable 状态，不如用 mobx ，因为 rxjs 的 API 过于庞大（各种 operator, subject ），而 mobx 的 API 则要精简很多（ observable, aciton, autorun/reaction, computed ）。

另外，mobx 还有 babel/swc 的插件 https://github.com/christianalfoni/mobx-react-observer ，可以自动将组件包装成 observer ，代码中会少很多语法噪音。

除此之外，mobx 相比 rxjs 还提供了状态更新 transaction https://mobx.js.org/api.html#transaction ，这在很多时候也是避免由于重复渲染导致性能劣化的有效方法。

不过，选择用 mobx 这样的基于可变数据结构的状态库，就意味着你需要放弃正宗 React 味儿，会大量地打破 rule of hooks 。