核心内容

楼主因 IP 在 US/JP 间乱窜导致 Claude 封号，改用一套固定网络方案后稳定使用 3 个月，核心思路是让所有 AI 流量走单一、稳定的出口 IP，避免频繁切换触发风控。

关键要点

• 自建梯子：AWS Lightsail 东京，5 美元/月、1T 流量，协议用 vless + reality，伪装成 HTTPS 大站，降低 IP 被封概率。
• 固定 AI 出口：所有 AI 服务经 IpRoyal 出站，用 Clash 的 dialer-proxy 指向 AWS 节点，并强制指定 proxy name，禁止手动切换。
• 规则参考：Clash AI 规则参考 https://github.com/szkane/ClashRuleSet 。
• 订阅与账号：安卓 Play 商店 + 招商银行卡订阅；订阅前先用免费网页一两天，检查 setting-account 的登录 session 是否都落在同一目标 region。
• 用量克制：不要用满额度，避免被判定为蒸馏；A 社对国内 AI 厂商蒸馏尤为敏感。
• 其他：使用 TUN 模式（iOS 用 Stash，Mac 上稳定）；作者未改时区与系统语言，以保持环境不变。

评论补充

• 有用户采用类似方案（AWS 东京 + 美国服务器 + Clash 规则 + TUN），并用阿里云香港自建 DNS 防泄露，称稳定 2 年。
• 成本讨论：IpRoyal ISP 约 5 美元/月，作者认为相对 100 美元订阅可接受，也有人认为这层非必需。
• 反例：有用户 200 美元套餐用半年后因额度消耗快被封；也有人称封号当月几乎没用额度，说明该方案并非绝对有效。
• 作者补充：注册邮箱从 Gmail 换成 Outlook；自建可用 sing-box 并调整 TCP 为 BBR。

核心内容

作者以 SwiftUI 小项目 FloatingBottomSheetsApp 为例，给出不打开 Xcode IDE 的完整 iOS 开发环境方案：XcodeGen 用 project.yml 声明工程并生成 .xcodeproj；SweetPad 扩展在 VS Code 内完成构建、运行、调试、热重载；VS Code + Swift 扩展提供补全与格式化。底层仍是苹果官方 xcodebuild 与 lldb，构建产物与签名行为与 Xcode 一致，团队可混用。示例代码见 cyub/sweetpad-demo。

关键要点

• 工程生成：project.yml 声明 target、iOS 17、SPM 依赖与 GENERATE_INFOPLIST_FILE: YES，避免缺 Info.plist 的签名报错；开启 sweetpad.xcodegen.autogenerate 可自动重生成，XcodeGen 2.44+ 支持 syncedFolder。
• 补全与调试：首次构建自动生成 buildServer.json（需 gitignore），SourceKit-LSP 即可补全；launch.json 用 sweetpad-lldb，F5 构建、安装并附加 LLDB。
• 热重载：装 InjectionNext，开启 sweetpad.hotReload.enabled，SwiftUI 加 @ObserveInjection 与 .enableInjection()，保存即刷新且保留状态；仅限模拟器与 macOS，真机、watchOS 不支持。
• 性能与协作：-interposable 仅 Debug 用，Release 关闭；模拟器 UDID 机器相关，团队只固定 scheme。

评论补充

有回复指出该方案更适合前端背景或不愿用 Xcode 的开发者，SweetPad 调试与 Xcode 开箱即用仍有差距，尤其缺少实时资源占用与性能调试；也有回复认可 Xcode 体验差。

核心内容

一位十几年、累计消费约 50 万的京东老用户，账户突然无法登录，手机验证码失效，必须同意京东金融协议并完成人脸识别才能登录。作者付款走第三方、账户无余额，认为人脸识别的唯一用途指向借贷，因此拒绝并转向其他平台。

关键要点

• 客服称人脸识别是“为了安全”，但作者认为其账户无资金风险，诉求不合理。
• 作者已拨打 12345 投诉京东总部，并计划“用脚投票”。
• 替代方案：生鲜改山姆、盒马、小象；电子走官网或天猫；日用品试拼多多。
• 作者对比发现，过去几个月京东日用品价格普遍偏高。
• 有回复称国家规定不得只提供人脸识别一种验证途径，投诉到管局后客服可能提供免刷脸链接。

评论补充

• 多位用户指出淘宝、美团、12306、银行证券等也在采集人脸，认为难以完全回避。
• 有回复认为这是监管要求而非京东单方行为，也有人反驳称更像京东金融自身操作。
• 有用户反映京东 E 卡也被要求实名，否则无法使用，投诉后被冷处理。
• 有用户称京东金融运营风格类似小贷公司，曾发生信息泄露。

＞ 争议点：人脸识别是政策要求还是京东金融推动，评论中未形成共识。

核心内容

作者用三周业余时间、约 600 美元训练了两个本机小模型（Qwen3.5 0.8B 与 4B 微调，MLX），做出 Mac 上的电脑操作 agent「DeskMind 得心」。思路借鉴 Jev：把每一步变成选择题，让模型给选项打分而非生成文字；决策服务沿用 Jev 的 POST /v1/systemone 请求格式，已有 harness 换地址即可接入本机。

关键要点

• 分级决策：0.8B 有把握直接执行（约 0.5 秒），没把握交给 4B（约 3.6 秒）；任务存在两种理解时先反问用户，而非随意选择。
• 自测结果：13 个真机任务各跑 3 次，发布版 38/39，未出现未完成却报「完成」；作者强调题目自出、样本小，逐题结果公开。
• 踩坑：标签平滑设 0.95，导致 0.8B 置信度挤在 0.96 门槛附近，七成步骤被转交 4B，速度偏慢，下轮修正。
• 成本经验：训练先在 Tinker，后转阿里云 PAI，最终按小时租显卡最划算。
• 已知不足：模糊指令（如「整理这个文件夹」）表现差；文件多的文件夹每步需几十秒；仅支持 Apple 芯片，首次需下载约 5.3 GB 模型。

评论补充

作者在回复中给出训练数据来源：公开数据集加自建合成数据、桌面操作数据由 oracle 自动标注、并蒸馏大模型，训练记录见 training.zh-CN.md。有评论质疑帖子由 AI 代写，作者承认 AI 协助完善但大纲与内容自拟；另有评论认为当前自跑模型未必必要，云端方案仍有免费额度，作者回应生产环境不便用 Jev API，同时借此学习训练。

项目地址：GitHub、Mac App、过程与踩坑。

核心内容

B 站 Index LLM 团队开源了翻译模型 Index-Translate，基于 Qwen3.5 Base 训练，支持 150 种文本语言，提供 2B、9B 和 35B-A3B 三种规格。除翻译质量外，还专门训练了指令遵循能力，可塞入术语表、指定文风、要求保留内容与格式，例如翻小说时固定人名和境界名，或要求“别解释，只输出译文”。

关键要点

• 免费 API 已开放，兼容 OpenAI 接口，改现有客户端 base URL 即可接入；附零外部依赖的 Python 调用脚本。
• 网页 demo 可直接试用，权重发布在 Hugging Face。
• 衍生分支：Echo（语音转字幕、带音色克隆的端到端语音翻译）、Homura（给译文设音节预算，适合卡时长场景）、Nailong（长文档翻译，减少分块导致的前后不一致）。
• 相关链接：demo https://index-translate.bilibili.com，调用脚本 https://github.com/bilibili/Index-Translate/blob/main/inference/llm/call_api.py，仓库 https://github.com/bilibili/Index-Translate，权重 https://huggingface.co/collections/IndexTeam/index-translate。

评论补充

有用户反馈该免费 API 配合手机翻译 App 作为默认翻译，速度快且不生硬，优于苹果默认翻译。作者回应称与 Sakura 在小说和文化迁移方面类似，但定位为通用全功能翻译模型，支持小语种与自定义指令约束。关于免费 API 的持续时间，作者表示取决于项目能否争取到资源，未给出明确期限，属待核验信息。

核心内容

楼主因急需给路由器装插件，在 Google 搜索 Xshell 后误入 GitHub 上一个名为 xshell-setup-free 的破解版项目（仅 2 星），解压需密码，Windows 已提示危险仍强行安装。安装瞬间自带杀毒软件闪退，次日 Instagram、邮箱等账号全部被盗，并被用来向好友群发钓鱼链接，随后邮箱收到上百封垃圾邮件。已多次向 GitHub 举报未获回复。

关键要点

• 风险信号被忽略：破解版、GitHub 低星项目、杀毒软件警告、压缩包带密码，四重信号叠加仍继续安装。
• 后果链条：本机被控 → 社交账号被盗 → 通讯录被用于钓鱼传播 → 邮箱被轰炸。
• 补救建议：评论普遍认为中毒后应全盘格式化重装系统，仅靠火绒全盘查杀可能仍有残留。
• 正规来源：Xshell 个人用户可免费使用，官方下载页为 https://xshell.com/zh/all-downloads/ ，无需破解。

评论补充

有用户指出“平日的千般小心比不上偶然的一时情急”，点出紧急状态下判断力下降是主因。另有评论推荐本地免费的 SSH 客户端 https://www.termark.app 。关于是否重装系统，楼主自述已用火绒全盘查杀，但多位回复者建议直接重装。

限制

事件细节均为楼主自述，无第三方取证；病毒样本、具体窃取机制未披露，结论以经验教训为主。

核心内容

主帖反映楼上新租户（一对情侣）常在 23 点后大声唱歌、吵架、打游戏喊叫，沟通效果有限，作者考虑用震楼器对刚。评论区的共识是：沟通对无素质者基本无效，但处理要讲顺序，避免自己先违法。

关键要点

• 推荐顺序：先自行交涉 → 无效找物业 → 再报警，闹一次报一次；报警无效后再考虑震楼器。有回复指出，报过警且对方不听劝阻后再震楼，警察通常不会为难你；未报警直接震楼，对方报警时你可能处于不利位置。
• 投诉渠道：不要只找社区辅警（无记录），用微信 12345 投诉会留痕，深圳会指派附近派出所处理，结果不满意可继续投诉，相关部门有绩效压力；注意保存录音。
• 找房东：租户问题可联系房东施压，有回复称最终靠反复轰炸房东才把人赶走。
• 止损选项：若房子是租的，尽早搬走；自有房则只能长期应对。

评论补充

有回复提醒主动制造噪声可能涉及法律风险，并建议“拾音并扩大”这类规避思路；也有人认为“解决不了就把问题搞大”。多数人认同沟通只对有素质者有效，震楼器是最后手段，且不要承认是自己所为。

＞ 风险提示：震楼器、对骂等做法存在法律与邻里冲突风险，以上为评论观点，非法律建议。

核心内容

主题讨论 Codex 在 macOS 上后台操控应用的技术原理：菜单栏出现电脑图标（右下角带小人头像），被控应用左上角也显示该图标，且操作不阻塞用户正常使用电脑。

关键要点

• 方向被指为 Computer use 类能力，但主帖追问底层实现，认为 Accessibility API 是独占的，可能不是它。
• 有回复给出较具体的解释：使用录屏 API + Accessibility API；非独占的关键在于点击不移动光标，而是直接对目标进程的元素执行动作，输入也不发全局键盘事件，而是设置元素的值、选中文本，因此不抢焦点、不动光标，只需后台运行。
• 有回复称 OpenAI 收购了 Software Applications Incorporated（SAI，苹果快捷指令原创团队），Codex 后台操控 macOS 应用的核心组件用的是 Sky 的客户端程序。
• 开源参考实现被提及：e2b-dev/open-computer-use（https://github.com/e2b-dev/open-computer-use），但明确说明 Codex 不一定使用它。
• Windows 侧类似方案被提及 rdpwrap（https://github.com/sebaxakerhtc/rdpwrap），同样只是类比。

评论补充

关于底层机制，评论存在推测与事实混杂：录屏+Accessibility API 的解释较完整，但未提供官方来源；SAI/Sky 的说法也未经证实。可复用的结论是：后台操控通常靠“读屏 + 直接操作元素”而非模拟全局输入，从而避免抢占焦点。

核心内容

作者用 ChatGPT 从零开发了一款 YouTube 去广告脚本，未使用开源项目，主打 Loon 效果，圈 X 也可用。功能包括首页视频流无广告、视频播放无广告，且节点无需拦截 QUIC。插件地址：https://github.com/teaoea/shell/tree/main/plugins

关键要点

• 圈 X 安装 URL 为 https://raw.githubusercontent.com/teaoea/shell/refs/heads/main/plugins/YouTube/YouTubeNoAds.snippet。
• 作者称主要面向 Loon 开发，路由器场景未测试。
• 有用户反馈打开视频略慢，作者表示自身使用无明显问题。

评论补充

• 有用户指出圈 X 直接转换逻辑组合规则会改变匹配条件，改用 sgmodule 后可用。
• 关于 Surge 模块，评论给出两个可参考的第三方模块链接：https://raw.githubusercontent.com/Aioneas/Surge/main/Module/youtube.aioneas.hide-shorts.sgmodule 与 https://raw.githubusercontent.com/Maasea/sgmodule/refs/heads/master/YouTube.Enhance.sgmodule。
• 有用户询问能否解锁最高画质，主题内未给出结论。

整体属于个人自研工具分享，可复用信息集中在安装地址与平台兼容性，效果与稳定性仍待更多验证。

核心内容

Janus 是一个 MIT 许可的开源 AI Agent 网关（v0.3.5），定位为控制平面：把只有 /api/* 的 OpenCode server 包装成标准 /v1/*，让 OpenAI / Anthropic 兼容客户端（Cursor、Trae、OpenAI SDK、LangChain 等）零改动接入，并统一管理会话、工具、权限与用量。它不重造 Agent / Tool / MCP / Session runtime，这些交给 OpenCode。

关键要点

• 安装：可从 Releases 下载 amd64/arm64/arm/386 预编译包，或源码编译（Go 1.23+），也支持 Docker（distroless 非 root 静态镜像）与仓库自带 systemd 单元。上游需先装 OpenCode。
• 零配置启动：Janus 自动发现或自行拉起 opencode serve（随机端口+密码），客户端只需把 Base URL 指向 http://127.0.0.1:2810/v1、API Key 填 BRIDGE_API_KEY；Anthropic 客户端设 ANTHROPIC_BASE_URL。
• 三种执行模式：native（工具在 Janus 主机执行）、remote-tools（工具在客户端，经内置 MCP 桥，对客户端仍是标准 tool_calls）、none（纯推理）。由 BRIDGE_AGENT + BRIDGE_TOOL_CALLING 决定。
• 虚拟模型 janus：客户端模型名固定填 janus，在 /ui 面板切换默认模型与思考档位，下一条请求原地生效、不重开会话、上下文保留。解析优先级为面板选择 ＞ BRIDGE_DEFAULT_MODEL ＞ 上游默认。
• 自动注入 agent 配置：通过 OPENCODE_CONFIG_CONTENT 注入白名单式配置，避免手写黑名单因 OpenCode 改工具名而失效。
• 可观测：/v1/requests 与 /ui 提供逐条请求的缓存命中率、思考 token、耗时、费用，同时给出 OpenAI 与 DeepSeek 两种缓存 token 统计口径。

评论补充

唯一回复质疑文中“一句话”式表述不像人话，未提供技术性反驳或验证。

核心内容

一位脚掌宽、前三趾几乎等长的用户分享低价宽楦鞋选购经验：特步巴斯克，淘宝约 137 元入手，穿一个月，上过山下过地。

关键要点

• 尺码参考：作者平时皮鞋穿 41，以往需买 43 才勉强合脚；此款买 43 前掌仍有余量，不挤脚。
• 优点：薄底轻便、透气，鞋垫带一点足弓支撑，前掌空间充足。
• 缺点：湿瓷砖上打滑（作者在公共卫生间发现）；石子路硌脚。
• 适用场景：日常与轻度户外，非跑步用途。

评论补充

• 有回复指出打滑问题并非个例，斯凯奇、New Balance 部分鞋款同样存在，北方雪天走瓷砖风险更大。
• 有回复认为该鞋前后落差偏大，体验不佳。
• 另有回复提示：非跑步用途的户外鞋通常本身较宽松，可作为宽脚选鞋的替代思路。

整体看，这是一条有具体价格、尺码对照和实测缺点的低价宽楦鞋参考，但样本仅一人一月，且打滑与落差问题存在争议，选购前建议实地试穿。