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

我安装了官方的 IDE 插件，通过 IDE 启动的 Claude 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 。

我试了 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

楼主好人一生平安。

更新：现在为 InsertInlineCompletionAction (在设置中叫做 Insert Inline Proposal) 设置快捷键就行。

请看我的历史发帖： https://v2ex.com/t/1133608

NAS 提供对象存储服务没啥问题，我比较好奇往公网放对象存储的目的是啥？如果对象存储的客户端是固定设备，建议用 VPN 而不是公网，这样会减少安全风险。

astgrep 很不错，用来查找声明或者使用会比较方便 https://ast-grep.github.io/guide/quick-start.html

我的需求跟你几乎一模一样，只是优先级上有区别。感觉你可以参考一下我的 NAS 系统组建方式：飞牛私有云（京东上买的 N100 成品小主机）跟 QNAP （成品 NAS ）

飞牛私有云主要用来支持需求 1 ，4 ，5：

- 飞牛影音非常好用，搭配飞牛 TV 端跟移动端 App 完美满足需求 1 ，而且整个使用过程不折腾。
- 跟成品 NAS 不同，飞牛的系统基于 dedian ，有运维经验的话，可以自己随便折腾，比如我在这台小主机上部署了 openwrt 虚拟机，pass through 物理网卡后当作软路由来用，应该足够满足你的需求 5 ；如果你要求更多的硬件扩展性，在选购主机的时候需要留意下硬件接口。
- 飞牛私有云自带了 docker 管理面板，支持 docker-compose 部署，满足你的需求 4 。我目前在这台 8G 内存的小主机上部署了 26 个容器，主打一个随意折腾。

我的 QNAP 成品 NAS 主要用途就是网络存储跟数据备份，尽量避免折腾：

- 手机上装 QNAP 的 App 就可以备份照片，但是 QNAP 的 App 交互非常难用，还好设置成功一次后就不用再管了
- 相机照片可以通过读卡器插到 NAS 上，按机身的一键导入按钮快速导入，非常好使
- QNAP 自带的文件归档跟相册应用都不错，非常适合整理照片、回顾照片、搜索照片的场景
- 飞牛私有云跟 VPS 上的 Docker 应用数据也会定期备份到这里，万一折腾坏了还可以回滚

关于「低功耗」：

目前我的两台设备每天稳定地耗电 0.7 度，在我能接受的范围之内。


总的来说，我的思路就是把重要的数据都存成品 NAS 上，尽量不去折腾它以减少运维负担；专门用一台机器来折腾各种小玩意儿，万一出现了无法恢复数据的故障，也不会太心疼。

单纯存储方面来说，不管是 WebDAV 、NFS 、SMB ，我感觉 QNAP 还挺好用。我用得最多的 QNAP 就是 HBS 、QuMagie 、Qfiling ，除了 UI 响应慢，都令人满意。但 QNAP 的移动端 App 确实不算好使，尤其是 Qfile Pro 的反直觉交互。

BTW ，我单独买了一个 N100 小主机跑飞牛 OS ，专门用来下载影片、折腾 Docker 应用，刚好就避开了你提到的那些 QNAP 内置废物应用 2333 。

威联通 NAS 上的 QuMagie 支持 AI 自动分类

@kevinhwang #174 > 微信记录（手机清空）转为 https 在线查阅

这要怎么实现啊？