GiantHard

> 我个人理解是，只要 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 。

我试了 playwright-mcp 跟 chrome-devtools-mcp ，主要场景是用 claude code 帮我执行 UI 测试，这俩 mcp 主要用 Accessbility API 给 LLM 描述页面的状态，在 playwright-mcp 中，这个功能叫 snapshot ；而现有的系统在可访问性方面做的不太好，以至于 GLM 4.5/Claude Sonnet 4 都会被很简单 UI 交互卡住，例如，滚动 Antd 4 Tree 组件的虚拟列表，我手动截图页面让 LLM 识别的话，LLM 都能知道应该用滚轮事件向下滚动，但如果只提供 Snapshot 的话，这些模型会被卡住很久并最终撂挑子。所以个人感觉在 UI 测试的场景中，还是基于视觉（ screenshot ）的方案更优。

最近再调研的时候，发现 Google 整了一个新的 Computer Use 模型，能够基于截图跟浏览器交互，看演示视频的效果还不错，但是限定只能用 gemini-2.5 的一个实验性版本。

@IchinoseChiya #19 相较于专业的计算机行业而言，NAS 、软路由本身算是非主流社区，非主流小圈子有一些「不专业」的语言习惯很正常，反过来说，正是使用这些「不专业语言」的人出于相互认同，才构成了游离在主流声音之外的一个个非主流的小社区。

当有人尝试用主流社区的专业语言帮助游离在主流之外的非主流社区重建话语体系的时候，从非主流社区的内部看来，是在破坏这个社区成员之间的共识。

FFvMY4GcqkYcB6snFurVbc3AdJsWvLwcr5kDrLFYCpeK

楼主好人一生平安。