核心内容

楼主用 Google 老号订阅 Claude Max 数月后于 10 月中旬被封；换较老 Gmail 重新订阅，今早触发认证，用 CN 护照认证后立即被封；再用较新 Gmail 开通 Max，支付成功瞬间被封。其共同点是同一梯子（约 300 元/月）、同一张美国信用卡、同一设备，因此怀疑是设备、卡、网络组合被风控标记。

关键要点

• 支付卡关联：有回复指出同卡号支付的账号只要一个被封，其余可能连带被封；楼主补充换新加坡卡同样失败并被封。
• 环境一致性：有回复提醒系统时区、语言等细节可能被用于识别；建议让 Claude 运行在虚拟机 NAT 模式，固定代理出口 IP，并调好系统时区语言，通过 Google Play 或 Apple 订阅。
• 替代路径：评论提到 OpenRouter、官方 API Key（管 Key 一般不封号，但成本高）、企业 Premium、Copilot（风控较松，Cyber 场景除外），以及转向 Codex。
• 退款：有回复建议向官方申请退款。

评论补充

楼主称 Claude 用于独立开发，收益远超订阅成本，因此暂不敏感价格；另一位开发者称已认真考虑移居海外，认为平台有多种方式判断用户所在地。企业 Premium 用户表示已续费第二月，但无法保证稳定，自己也曾被封掉用了一年的 20x 账号。上述替代方案与稳定性均为个人经验，缺乏官方依据，需自行验证。

核心内容

楼主经父母介绍第一次相亲，见面后觉得对方“正常人”、条件不错，但没有心动，也不知道该聊什么；家人催促“男方要主动”，他因此焦虑。评论区的共识是：不必急于推进关系，先多约出来共同经历，话题会自然产生；同时要调整“讨好者”心态。

关键要点

• 进度自己掌握：长辈心急是长辈的事，按自己舒服的节奏相处（回复 18238125）。
• 线下优先于硬聊：吃饭、逛街、逛公园都行，重点是持续约出来，熟悉后自然有话题（18238239、18238514）。
• 做自己，别预设对方喜好：日常琐事、猎奇内容想发就发，不必先判断“合不合适”（18238293、18238363）。
• 用行动判断意向：能约出来就是有兴趣，频繁拒绝就是没兴趣，不必反复揣测对方心理（18238363）。
• 没话讲就不讲：强行找话题反而刻意，如实说明对方通常能理解（18238293、18238514）。

评论补充

有回复指出楼主把自己放在“下位者”位置、急于讨好，反而削弱吸引力（18238293）；也有人建议把相亲对象当普通朋友，先多接触，不成也多一个朋友（18238402）。关于分享 IT 话题，楼主担心对方不感兴趣，被提醒不要预设（18238363）。

核心内容

作者在国内有公网 IP 的家宽上，用 SSH 反向隧道做代理，跑了约一年，称各种“开大会”期间都稳定；最长一次 8 条 SSH 连接存活 30 天，直到重新拨号。性能上，正向 trojan-go 建联 speedtest 约 400Mbps，走 SSH 反向隧道可达 1400Mbps，接近 CloudFront CDN 接入。作者推测原因是国内有公网 IP 的家宽少、审查重点不在此，且长连接避免了每条业务连接都新建 TCP。

关键要点

• 架构：家庭路由器上的 Mihomo 内置 SSH Server；VPS 上的 agent 作为 SSH Client 主动建 8 条长连接。业务 Channel 由路由器侧 SSH Server 主动向 VPS 打开，VPS 再拨号到目标。
• 实现：基于 golang.org/x/crypto/ssh，Mihomo 新增 ssh-reverse-servers 顶层配置与 ssh-reverse 出站类型，用原子计数器轮询会话，自定义 Channel 类型传递目标地址。
• 并发：每条长连接可承载多个 Channel，agent 全局通道上限默认 4096；多连接用于分散加解密负载，单条业务连接不跨连接拆包，仍受队头阻塞影响。
• 注意：单个 Channel 取消不应关闭共享长连接；加密优先 aes128-gcm@openssh.com。作者明确表示不应宣称 SSH 协议头能保证绕过审查。

评论补充

多位老用户提醒这是“古早”方案：SSH 隧道特征明显，历史上曾被定向封端口、限速或断开，有人称早期被封以分钟计。作者回应称，从泄露的 GFW 代码与研究看，当前审查重点在 TLS/QUIC 前 N 个报文，二元组封禁多为特殊时期临时规则；并附研究报告 https://geedge.report/assets/geedge-tsg-usenix26.pdf。也有回复指出裸 SSH 会出现无规律断连，建议叠加 overlay。结论：可作为有公网 IP 者的备用思路，但稳定性可能依赖运气，不宜大范围依赖。

核心内容

楼主分享了一套家庭网络加固方案，核心思路是减少攻击面、做网络分段、只走 VPN 入内。方案本身可复用，但“固若金汤”的表述被评论区普遍质疑。

关键要点

• 设备与固件：二层/三层设备统一用官方 OpenWrt（一台 x86 软路由 + 两台 N60 Pro 做 AP），只装官方源软件，不用第三方插件。
• 网络隔离：多 SSID + VLAN 划分主人、访客、智能家居（几十个米家设备）、媒体设备四类网络；VLAN 间只放通必要服务，例如媒体网络仅允许访问 NAS 的 Emby，访客与 IoT 网络除 DNS/DHCP 外一律 reject。
• 边界与 IPv6：WAN 入站除 VPN 外全部 drop；仔细配置 IPv6，禁用不必要的 forward。
• 远程访问：只通过 WireGuard VPN 回家。
• 运维习惯：用 AI Agent 跟踪设备漏洞（如 dnsmasq 的 DHCPv6 漏洞后关闭 DHCPv6）；重要数据冷备到独立硬盘；公网服务器 SSH 仅密钥登录、每周检查安全更新、缩减域名与服务数量，PHP 漏洞时先下线网站再更新。

评论补充

• 有回复认为一个 VPN 已挡掉约 99% 攻击，再加独立 WiFi 做内网隔离即可，300 元级路由器也能实现，不必过度设计。
• 安全边界提醒：补丁再新也可能被 0day 打穿，老旧模组中可能存在未被发现的漏洞。
• 可加强项：把密钥登录换成证书登录，配合生物识别与定期重认证/令牌。
• 楼主回应称，除非出现 Linux 内核级 0day，否则无法从公网提权。
• 大量回复调侃索要公网 IP“测试强度”，属玩笑，不构成技术论证。

核心内容

主帖列举了换季找衣服、找螺丝刀、找电工胶布、找会员实体卡、找结婚证护照、找智能门锁备用钥匙等场景，核心问题是：居家物品多且分散，临时需要时难以定位。评论区的共识是，记录本身不是关键，固定归位和用完归还的习惯才是根本；单纯做记录往往因为维护成本高而难以持续。

关键要点

• 习惯优先：多位用户主张“固定东西放固定地方”，如手机放左裤兜、钥匙放右裤兜；有人建议参考 6S 管理，工具箱只放工具、衣橱只放衣服、杂物箱只放杂物，用完立即归还。
• 分类收纳：按类别装箱，标注箱子编号，需要时再翻找，比逐件记录更省事。
• 工具方案：有用户提到自建网页记录物品数量和位置，但发现“记录本身就很麻烦”；也有人推荐自部署 homebox 记录物品，以及用 InvenTree 搭库存系统并配合 MCP 插件；还有用户用开源小智音响接 MCP，对房间储物格做增删查改。
• 适用边界：自己住且习惯好时，脑中索引通常够用；多人同住容易打乱归位，记录才更有价值。记录还能避免“舍不得扔又忘了”的东西被重复购买。

评论补充

有用户尝试文档、开源软件记录后放弃；也有人认为只有别墅等大空间才需要这类服务。总体看，低成本方案是固定归位加分类编号，工具记录适合物品多、同住者多或记性差的人。

核心内容

主帖想给 72V22A 铅酸电自换锂电，因电池仓为 T 型，担心锂电不好放，并明确排除三元锂。评论给出了多个真实换电案例，价格、容量和续航差异较大，可作为选型参考。

关键要点

• 铁锂大容量方案：极核 AE4SE+ 装 72V75A 铁锂约 4200 元，ECO 40 码续航约 220 公里，Sport 80 码约 130 公里；除电池仓外坐桶也可放电池。
• 比亚迪铁锂：64V45Ah 约 2750 元，25 码实际约 100 公里，约 1 公里掉 1% 电，低于销售宣称的 120 公里；官方称质保 5 年、可用 10 年。
• 其他实例：深远 T50 换博邦 5450 共 3300 元；老雅迪换 60V30Ah 约 1300 元；48V24A 锂电用 5 年，解速 40 码续航约 50–60 公里。
• 安装方式：多为商家上门，报电自型号后带电池和工具就地拆装，不建议自己弄。

评论补充

安全上存在分歧：有人因怕锂电起火特意选铅酸，并称见过电瓶车瞬间起火；反驳观点认为起火多为三元锂，磷酸铁锂穿刺实验不易起火。另有用户提醒锂电二手难出，容量买小会后悔。

核心内容

作者把传统二维个人网站改造成三维方块世界，灵感来自《我的世界》《黑客帝国》和元宇宙，并借助 AI 完成开发。世界内可自由移动，包含篮球场、泳池、健身房、工作台、作品展示、昼夜交替和天气系统；二维网页也能内嵌，按 F 查看。方块风性能开销较小，手机可访问。

关键要点

• 技术栈：作者在评论中确认使用 three.js + HTML/CSS/JS，并非游戏引擎。
• 开源模板：项目 homecraft 除个人网站源码外，还提供初始模板、开发调优经验和传送门功能，可 fork 后提交收录，方便互相“串门”。
• 启动方式：一行命令 python3 tools/serve.py 即可运行，其余内容可交给 AI 扩展。
• 实机地址：https://terryhu.cn/ ；源码：https://github.com/terryHu7/homecraft

评论补充

有用户反馈“有点卡”，作者追问是手机端还是电脑端、加载卡还是画面卡；另有用户反馈 D 键无反应，作者称已收到同类反馈并正在修复。说明该项目当前仍存在交互与性能问题，体验前需有预期。

核心内容

作者入职一家传统生产企业，公司此前没有技术部门，因外贸经理用 AI 自建工具获老板认可，决定全公司推广 AI 开发。作者在 HR 经理手下做开发，工具从 TRAE 换到 codex + workbuddy + zed，再被要求直接用 Claude Code 配第三方 API。速度上去了，但 AI 的思考与改动多为英文，作者基本是“回车确认”，只做功能测试，担心误写、误改数据却无从察觉。

关键要点

• 风险根源：领导以“外贸经理半天出功能”为标杆持续压速度，导致代码审查被跳过，责任仍落在开发者身上。
• 可落地的管控：关闭 force-push 权限，通过 Git 查看改动；禁止直接读数据库，只允许提交 SQL 文件并由 CI 自动执行，从而掌握 AI 对数据的修改。
• 流程建议：需求拆细，先与 AI 讨论敲定方案再动手；提供充足上下文；多轮让 AI 自审；上线前由测试跑用例。
• 工具差异：有回复称 Claude 更易无视规范，ChatGPT 更守约束，属个人经验，需自行验证。

评论补充

多数回复认为这是大势所趋，“代码和程序员有一个能跑就行”，建议受不了就换工作，不必试图说服老板。也有观点提醒：不懂技术时即使用最强 AI，过程与结果仍不可控；领导驱动 AI 直接上生产，出事只是时间问题。

核心内容

一位传统行业企业的程序员即将带团队，考虑自费给组员购买 GPT Pro 等 token plan 提升效率；公司内网只部署了 ds-v4-flash-fp8，且保密要求较高。评论区的共识倾向先别买：走公司审批、向上要资源，比个人掏钱更稳妥。

关键要点

• 保密优先：公司保密要求高时，让代码出内网使用外部模型可能构成数据泄露风险，负责人首当其冲。
• 走审批而非自费：先向公司申报资源，批下来再买、费用可报销；公司不批就不折腾，避免“出钱不讨好”。
• 先验证需求：可先小范围试用（如少量 Plus 账号），看谁真的会用，再决定是否扩大。
• 内网模型可能够用：有回复认为 ds-v4-flash 对非高复杂任务已足够，前提是较新版本；也可考虑内网 DeepSeek API 配合 Codex、Claude Code 等工具。
• 管理视角：新 leader 更该先摸清上级与下属的诉求，低成本改善痛点；灵机一动的自费方案可作为思路提出，而非直接执行。

评论补充

有回复提醒，自费配好工具还可能引发员工“被加大压榨”的猜疑，以及进度不达预期后的内耗；也有回复认为传统企业多数程序员仍停留在“跟 AI 聊天”阶段，买了未必有人用。

核心内容

VictoriaMetrics 公开了结构化日志写入基准测试，覆盖 VictoriaLogs v1.53.0、Loki 3.7.8、Elasticsearch 9.5.5、OpenSearch 3.9.0、SigNoz v0.145.0 与 ClickStack 2.39.1。测试在单台 8 vCPU/32GB 机器上运行，日志每行 30–40 个字段、约 930 字节，共 5,000 个流，写入速率从 10k 行/秒阶梯升至 180k。仓库与结果均可复现。

关键要点

• 写入上限：Loki 139k 行/秒最高，VictoriaLogs 120k 次之；Elasticsearch、OpenSearch、ClickStack 为 28k–48k；SigNoz 仅 10k，20k 时崩溃。
• 资源成本：40k 行/秒时 VictoriaLogs 与 Loki 各用 1.6 核，ClickStack 4.0 核，Elasticsearch 5.2 核；VictoriaLogs 内存最少，40k 时比 Loki 少约 14 倍。
• 磁盘：存 100 万行，Elasticsearch 占用约为 VictoriaLogs 的 5 倍，OpenSearch 约 10 倍；50k 行/秒保留 30 天，VictoriaLogs 约 7 TiB、Loki 约 12 TiB、Elasticsearch 约 33 TiB。
• 查询权衡：Loki 只索引流标签，统计每应用错误数需 171 秒，VictoriaLogs 为 0.59 秒；Elasticsearch 单词查询极快，但双词短语查询需 175 秒。
• 选型建议：Loki 适合低成本存对象存储、少查询或愿为大量 CPU 付费的场景；VictoriaLogs 适合结构化日志的 Dashboard 与聚合；纯文本日志收益会缩小。

评论补充

读者追问 OpenObserve 与 GreptimeDB 的对比，作者表示已将 OpenObserve 需求转给同事，尚未纳入本次测试。

＞ 注意：测试由 VictoriaMetrics 自建，单节点、结构化日志场景，集群与查询性能待后续文章验证。

核心内容

作者把个人网站从二维网页改造成可自由移动的 3D 方块世界，灵感来自《我的世界》《黑客帝国》和元宇宙。站内包含篮球场、泳池、健身房、工作台、作品展示，以及昼夜交替和天气系统；二维网页也能内嵌，按 F 查看。方块风性能开销较小，作者称手机也能轻松访问。

关键要点

• 项目已开源：homecraft（https://github.com/terryHu7/homecraft），除个人网站源码外还提供初始模板，并内置作者的开发调优经验与传送门等功能。
• 启动方式：执行 python3 tools/serve.py 即可运行，之后可借助 AI 继续搭建自己的世界。
• 在线体验：Terry’s Home（https://terryhu.cn/）。
• 作者表示想法为原创，X 上也有发布。

评论补充

有用户认为形式有趣、有个人特色，并建议加入实时显示其他访客的功能；作者回应称考虑过，但超出自身开发与维护能力。另有用户反馈载具暂时进不去，作者确认该功能尚未开发。整体评论以称赞为主，缺少性能、兼容性等实测数据，实际体验仍需自行验证。

核心内容

作者为发小做了一个快递单号入库出库的小型 Web 应用，前端两页、后端 Go + MySQL，测试环境用 Cloudflare 隧道代理到家里的飞牛 NAS 容器，免费但访问慢且担心被墙。正式部署的核心诉求是：国内访问稳定、成本尽量低。

关键要点

• 轻量应用服务器可行：有用户使用腾讯云南京轻量应用服务器运行 4 年半，部署多个服务，认为稳定性没问题；但续费价格需重点关注，建议活动时续费。
• 备案是稳定访问的前提：若面向国内多人使用，备案加国内服务器基本绕不开，否则访问体验和稳定性难保证。
• 云函数/Serverless 适合起步：laf、Unicloud 等可低成本起步，但量起来后成本可能扛不住，届时再迁移即可。
• 数据库选型可优化：有建议将 MySQL 换成 PostgreSQL 或 SQLite，并考虑阿里云轻量 2C2G 新人价；低访问量场景可用按需休眠、同步到对象存储的架构降低内存占用。
• Cloudflare 方案不适合国内：CF 全家桶加 Worker 成本极低，但海外 IP 在国内访问不稳定，作者明确排除。

评论补充

评论普遍认为此类表单型应用负载不高，轻量服务器足够；分歧在于是否值得为省成本改用云函数或 CF，结论倾向国内稳定优先、先低成本起步再按量迁移。

核心内容

楼主每天只吃一顿饭控制热量，久坐办公，晚上不饿但嘴馋，想找耐嚼、几乎无热量的零食，并担心牛肉干钠高、容易一次吃完。评论区的共识是：与其找零食替代，不如先修正一天一顿的饮食结构，同时给出了若干低热量、可操作的替代选项。

关键要点

• 低热量解馋选项：黄瓜、胡萝卜、小番茄/圣女果（补钾、热量极低）、水煮蛋、牛奶、无糖希腊酸奶、鹰嘴豆（选原味非油炸，高蛋白高纤维低 GI）、真空包装溏心鸡蛋、无糖可乐。
• 坚果存在分歧：有人反对坚果热量高，也有回复称自己吃坚果瘦了 70 斤，说明关键在份量控制。
• 牛肉干：有回复认为钠高多喝水即可，钠代谢较快；但楼主自认容易吃多，需谨慎。
• 饮食结构建议：把一顿拆成三餐、每餐七分饱；按公式算基础代谢，至少吃够基础代谢；饮食清淡少油少盐，配合阻抗训练和适量运动，用黑咖啡抑制食欲。

评论补充

多位回复提醒一天一顿对肠胃伤害大、减重过快会降低代谢并易反弹。也有回复用 DeepSeek、Grok 记录食材热量并参考 USDA 数据，属于可复用的记录方法。

核心内容

作者发布开源 Zotero 插件 Mktero（MIT 协议，支持 Zotero 7–10），目标是把论文 PDF 转成可阅读的 Markdown，并保留与原文的映射关系。右键 PDF 选择「使用 Mktero 阅读 Markdown」后，论文在 Zotero 标签页内变为单栏连续正文。

关键要点

• 版面与内容：双栏按阅读顺序重排，保留公式（KaTeX）、表格、图片、引用、脚注，隐藏刊头、页眉页脚和页码。
• 双向定位：段落、公式、表格、图片保留页码与区域映射，可「在 PDF 中查看」跳回原页原位置；Markdown 中的高亮即 Zotero PDF 注释，双向同步。
• 校对与复制：可修正 OCR 错字（段落、标题、表格单元格），改动单独保存；行间公式复制为 LaTeX，表格复制为 Markdown 或 CSV。
• 批量与导出：支持多选条目或分类后台排队转换，导出到本地文件夹或 Obsidian 库；可选 AI 翻译（原文/译文/双语）。
• 实现细节：OCR 与版面分析交给 MinerU 或 Mistral OCR，本地读取 PDF 文字层修复换页换栏断段，并把 OCR 擅自「改正」的词还原为印刷原文；缓存按内容寻址，同一论文不重复转换。

数据与限制

默认转换会把缓存中没有的 PDF 整份上传到作者运营的转换服务，需登录账号；也可改用自有 MinerU 云端 key、自部署 MinerU 4.0 或 Mistral OCR，自部署时 PDF 不出内网。翻译只走用户自配的 AI 厂商。缓存、校对、凭据以明文存于 Zotero 配置文件夹。已知限制：Beta 阶段，扫描件、三栏及以上、海报类排版阅读顺序可能出错；默认转换与 MinerU 云端单 PDF 上限 200 页；界面仅英文和简体中文。

安装：GitHub Releases 下载 .xpi，在 Zotero「工具 → 插件」中 Install Add-on From File。仓库 https://github.com/tenglvjun/mktero ，隐私说明见仓库 docs/privacy.zh-CN.md。

核心内容

Loon 允许插件加密后，可莉插件后续内容将不再公开源码。主帖作者认为，起因是有人违反协议肆意转发、激怒作者；加密后普通用户只能靠抓包判断插件行为，监督成本大幅上升。作者担心长期风险（如项目转手、偷偷做手脚），倾向自建规则仓库，但认可可莉插件更新快、好用。

关键要点

• 影响面：加密后无法直接审阅插件源码，只能通过抓包分析流量；作者类比“拆掉路边摄像头”，依赖作者良心。
• 迁移选项：评论中有人换回 Quantumult X、Surge、Shadowrocket；主帖作者最终迁移完成，去广告改用其他项目，除高德地图外效果满意。
• 替代来源：有回复提到墨鱼规则站 https://ddgksf2013.top 可一键添加 Loon 相关规则。
• 自维护：多位用户表示固定 App 版本、自己写规则，以规避规则频繁变更和链接失效。

评论补充

• 有用户指出可莉插件存在 bug（Apple Watch 天气不显示、App 闪退），但被解释为未在手表安装 MITM 证书，并非插件本身问题。
• 关于性能，有回复称 Surge 在常见代理 App 中性能最差，并附截图链接，与“Loon 性能差”的说法形成分歧。
• 有用户称作者常在群内挂人、规则三天两头变更、公告群广告多，认为走向闭源是必然；也有人认为索引插件者违约且嘲讽交涉，加密属无奈之举。

限制：以上均为用户主观陈述，加密范围、生效时间和实际影响尚无官方说明，需自行核验。

核心内容

作者用 Rust + egui 开发了开源桌面工具 Browser Harbor（浏览器港湾），用于下载、SHA-256 校验、解压归整、注入便携补丁（Chrome++ / Libportable）并平滑升级浏览器。最新稳定版为 v0.6.8，采用 MIT OR Apache-2.0 双许可证，代码与发行版见 GitHub 及 Gitee 镜像。

关键要点

• 轻量与克制：约 7.4 MB 单可执行文件，无 WebView2 依赖，默认免管理员权限；不驻留后台、不改默认浏览器注册表、不读浏览历史。
• 便携逻辑：运行时配置使用同盘相对路径（如 %app%\..\Profiles），换机或改目录无需重设；工具配置默认在 %LOCALAPPDATA%，可切换为 EXE 旁的便携模式。
• 升级安全：升级时隔离程序与数据，原子替换二进制并支持失败回滚，保留 Profiles、书签、Cookie 与登录状态。
• 覆盖范围：14 款浏览器，Chromium 系 8 款（Chrome、Edge、Brave、Thorium 等，集成 Chrome++ 1.18.x），Firefox 系 6 款（Firefox、Floorp、LibreWolf、Zen 等，注入 Libportable 9.0）。
• 供应链：仅从官方 Omaha、Edge 企业 API、Mozilla 官方或经校验的 GitHub Release 获取，Ed25519 签名清单每日校验 SHA-256，内置镜像，也支持本地离线包校验安装。

评论补充

有回复指出 Chromium 难以便携化主要源于 Cookie 加密，并给出 MinHook + setdll 拦截 DPAPI 的最小实现思路；作者回应称该方案轻巧，但本工具意在覆盖下载、校验、原子更新与多浏览器系兼容的全生命周期管理。另有评论询问是否支持双击关闭标签，未获答复。

核心内容

公司以“研发岗位无持续任务、研发部门停工停产”为由，依据《深圳市员工工资支付条例》第二十八条要求作者待岗：首月正常发薪，次月起只发生活费 2160 元并缴社保，且邮件明确无需到岗、无需考勤。作者补充：研发只剩自己一人、其他部门正常上班、公司有研发项目在外包但无证据。

关键要点

• 法定前提存疑：多位回复指出，停工停产通常要求公司整体性停工停产，而非单个部门；若各部门为独立子公司，才可能单独备案。
• 备案与咨询：有回复建议确认公司是否向人社局申请停工停产备案，并直接致电当地劳动监察大队咨询，成本低、结论明确。
• “无需考勤”是陷阱：有回复提醒该邮件可能被用作旷工或自愿接受待岗的依据，应书面提出异议、保留证据。
• 赔偿基数风险：若长期按 2160 元发放，后续裁员的经济补偿基数可能被拉低，高薪老员工的赔偿差距巨大。
• 路径分歧：一派主张尽快跳槽；另一派主张留下取证、等实际少发工资后申请仲裁，并举报社保、公积金基数问题。

评论补充

有回复称类似操作在现实中常见，即便胜诉也可能面临公司账户无资产、执行困难；作者表示将先书面提出异议，待实际按 2000 元发放后再仲裁。是否合法最终仍需以当地监察或仲裁认定为准。

核心内容

楼主 2018 年配置群晖时按教程停用了 admin 账户，并另建了一个有管理权限的账户。近期群晖被攻击的案例增多，他检查日志后发现大量尝试登录 admin 的记录；由于该账户已禁用，系统返回“帐户 [admin] 已受到保护”。他的建议是：禁用 admin 账户。

关键要点

• 禁用 admin 只是基础：评论普遍认为，仅靠禁用账户、开启 2FA、修改端口、限制登录失败次数，无法抵御漏洞利用。
• 关闭公网暴露最有效：多位用户建议关闭所有外网端口映射，改用 Tailscale 等组网方式远程访问；也有用户提到应关闭 QuickConnect。
• 漏洞风险高于密码爆破：有回复引用 CVE-2024-10441（CVSS 9.8，synoplugind 预认证 RCE），称攻击者可在密码验证前通过用户名注入以 root 权限加载恶意代码，从入侵到植入勒索软件可能只需约 2 分钟。
• 黑群晖同样受影响：有用户称在 7.2.1 上已做全套加固仍中招，并提到 7.4.1 也有案例。

评论补充

有用户表示，自己用域名加 IPv6 直连多年，现已关闭外网端口并改用 Tailscale。整体共识是：不把服务暴露在公网，比任何账户层面的加固都更关键；禁用 admin、开启 2FA 和自动封锁可作为纵深防御，但不能替代隔离。

核心内容

作者在 B 站发布《绝地潜兵 2》MOD 教程，该 MOD 用于辅助获取游戏内蓝币，不读取本地进程内存、不发起网络请求。视频遭卖挂商家先冒充官方、后污蔑 MOD 含木马，最终被锁定下架；B 站上同类 MOD 视频也一并消失，搜索只剩商家卖挂视频。作者的核心疑问是：MOD 是否算外挂、如何继续纯分享、是否涉及盗版。

关键要点

• 对方动机：评论认为商家是担心免费方案分流客源，软硬兼施施压，多为转手贩子，未必有持续报复能力。
• 反制手段：作者已举报对方视频，对方视频同样被下架；可继续走平台举报渠道。
• 换平台分发：评论建议发 Nexus Mods、小黑盒等平台，单一平台举报难以覆盖；但原作者未在 Nexus 发布，且其在 ayakamods 的发布已被下架。
• 借社区扩散：用“卖挂商家举报免费 MOD 分享”为切入点制作视频，打对标签，联系圈内较大 UP 主转发，利用玩家对卖挂的反感。
• 联系官方：若确无收益，可先向游戏官方反映利用机制牟利问题并留存沟通证据；官方不管则保留证据。

评论补充

回复未就“MOD 是否算外挂”给出定论，也未验证木马指控；作者自述用 AI 分析未发现木马，属单方说法。发布时补充封号风险提示，是作者已意识到的缺失。

核心内容

OpenAI 员工 Tibo（@thsottiaux）在 X 上宣布：即日起，所有 Pro 100/200/500 档位及 Business Premium 的使用额度翻倍；此前计划下调的 Pro 200 额度不再下调，Work 与 Codex 用量维持原状。dots 的扩展额度暂时继续提供，且 dot 用量仍与默认额度分开计算。官方称后续还会通过更好的模型和效率优化，持续提升实际可用量。

关键要点

• Pro 500 相当于 50x Day，这是主帖给出的换算。
• 用户实测额度比例出现跳变：有人从 33% 变 66%，有人从 17% 变 57%，也有人称 1% 突然变 50%。
• 有回复提到，此前 X 上曾发起“额度×2”与“取消 5 小时限制”二选一的投票，多数人选了取消 5 小时限制。
• 有用户认为，这次翻倍未必是算力充足，也可能是退订增多、影响预期收益后的应对。

评论补充

有回复指出，Tibo 前一天还表示 Chat 与 Work 能力将在今年内整合，但会谨慎推进；该用户据此推测，OpenAI 可能先给 Pro 翻倍，再收紧 Chat 高级模型或让 Chat 消耗订阅额度，以堵住用 MCP 把 Chat 当本地模型免费使用的做法。此说法仅为推测，未获证实。另有用户提醒，5 小时限制未来仍可能以其他理由回归。

＞ 结论：对 Pro 及 Business Premium 订阅者，这是即时可感知的额度利好；但政策变动频繁，不宜据此做长期用量规划。