核心内容

主帖提出：Vibe Coding 的瓶颈已从模型能力转向人与 LLM 的沟通速率，语音输入（可达 300+ WPM）比键盘更快。作者推荐用电视蓝牙语音遥控器作为低成本物理语音控制器，并配合开源 macOS 工具 Voice Input Buddy 打通硬件与输入法。

关键要点

• 硬件选择：小米蓝牙语音遥控器 2 / 2 Pro（RC001 / RC003）、Google Chromecast 遥控器（G9N9N，ATVV 16kHz）；Google TV Streamer 与 Apple Siri Remote 仍在规划中。
• 工作原理：遥控器 BLE 压缩音频经工具解码为 16kHz PCM，送入基于 BlackHole 定制的虚拟麦克风；语音键触发输入法快捷键，松手结束录音，转写落在光标处。工具本身不含识别模型。
• 输入法配合：微信输入法、豆包输入法、网易叭哥说、Typeless / VoiceCursor，以及 macOS 原生听写或本地 Whisper。
• 按键复用：方向键、确认键可映射为 Tab（采纳补全）、Cmd+Z 或终端唤起，常用 Prompt 可一键上屏。
• 隐私设计：零音频保留、零遥测、SecureInput 自动降级，GPL-3.0 开源，需 macOS 14+。

评论补充

有用户期待支持 Apple Siri Remote，作者回应若需求多会考虑；另有用户设想将其扩展为可 TTS 朗读的“AI 对讲机”，作者表示那属于另一类产品，当前工具只做硬件与语音输入软件之间的桥接。

核心内容

BeatBrowser 是一个 MIT 开源的 Chrome 扩展加本地 Node 桥接，让 Codex、Claude Code、Cursor 等 Agent 通过 MCP 操作你日常使用、已登录的 Chrome，不导出 Cookie、不迁移 profile，也没有云服务和遥测。

关键要点

• 架构：Agent 经 stdio MCP（另有 CLI 和 Node SDK）连接本地桥接 ws://127.0.0.1:18899，桥接带 token 校验和本地审计日志，再经 WebSocket 连到 MV3 扩展，由扩展走 CDP 操作选定的 Chrome profile。
• 任务隔离：每个任务开独立窗口（TaskSpace），每个 owner 最多 4 个未结束任务、每任务最多 16 页；点进任务窗口后自动化暂停，可在侧边栏选择接管、继续或停止。
• 状态与清理：任务记录持久化，扩展重载后未完成任务恢复为暂停；浏览器重启后需显式关联页面；一键清理只关 Agent 开的页面，人工关联或接管过的页面受保护。
• 工具能力：共 24 个 MCP 工具，act 支持批量步骤及 repeat、if、assert；learnings 把站点笔记存在本地 ~/.beat-browser/learnings/，供下次复用。
• 安装：需 Node.js 20+、Chrome 116+，执行 npm install --global @beatapi/beat-browser@1.4.1，先 beat-browser install --dry-run 预览，再 beat-browser install，手动加载扩展后用 beat-browser doctor --json 验证。

评论补充

有用户提到此前用 chrome-server-mcp 直连常莫名连不上，侧面说明本地桥接方案的价值；另有评论指向 Playwright Extension 和 ego lite 作为可对比方案，其中 ego 在 Mac 上 GPU 占用高、风扇噪音大的问题尚未解决。

限制

扩展需手动加载、未上架商店；同一 profile 共享 Cookie，多身份需开多个 Chrome profile；暂停挡不住已发出的动作；最小化窗口的有头截图、富文本编辑器和文件选择器支持不完整；扩展权限较大（debugger、 ），应只接信任的 Agent；主要在 macOS 验证，Windows/Linux 缺完整测试。

核心内容

主帖对比网页端和 APP 端的日常问答（医疗报告、X 光片、IT 运维答疑，不写代码），认为 Gemini 整体更好用，并询问是否是自己用法不对。评论普遍认可这一体感，但把差异归因到具体场景，而非模型绝对强弱。

关键要点

• Gemini 的优势：表达自然、废话少，能凭少量关键词猜出意图；世界知识覆盖面广，适合脑暴和泛问答。
• GPT 的优势：细节准确、幻觉相对低，能精确定位到具体帖子与文件路径。有用户举例：ROG Ally 掌机 MCU 驱动装不上，只有 GPT 一次给出 Reddit 上的解法；Gemini 需被提示日期和帖子位置才找到。
• 主要风险：Gemini 倾向讨好用户，被质疑就顺着改口，一本正经胡说的概率偏高；ChatGPT 防御性话术重，常附加“不排除某隐患”，反而增加判断成本。
• 选择建议：只想要一句话结论、不想写复杂提示词，用 Gemini；要深究原理、核对细节或写脚本解决问题，用 GPT。

评论补充

有用户指出 Gemini 网页端不主动联网，需明确要求搜索；也有人认为其“又懒又蠢”。另有实践者称在同一话题里持续追问并反馈测试结果，Gemini 能逐步产出可用的动态 QoS 方案，但它迷信网络信息、结论反复，仍需自行验证。也有用户认为日常聊天豆包更好用。

核心内容

有用户发现 Mac 硬盘空间异常减少，用 du -sh 定位到 /Library/Application Support/ToDesk/dumps 占用 152G。经 Codex 排查，该目录累计约 162.8 GB、共 215,257 个 .dmp 文件，从 9 月 14 日起持续累积，检查时仍在生成（最近文件间隔约 10 秒），近期每天增加约 5–6 GB，疑似 ToDesk 持续发生异常。

关键要点

• 排查方法：用 du -sh 逐层定位大目录，再让 AI 工具汇总文件数量、时间跨度和增长速度。
• 处理方式：删除 dumps 文件只能暂时缓解；多位用户反馈彻底卸载 ToDesk 后问题消失。
• 有用户称自己生成了约 500GB dump，卸载后 MacBook Pro 反而不再卡顿。
• 评论提到可尝试清理工具 LittleClean。

评论补充

多位用户遇到同款问题，并确认是 Codex 帮助定位的；有人改用其他远程工具替代 ToDesk。结论是：Mac 空间莫名减少时，优先检查应用支持目录下的日志与 dump 文件。

核心内容

作者每天在公司与家里各插一次外接屏，macOS 会把窗口挤回内建屏，需手动拖回。已有工具 Stay 能恢复窗口位置，但无法恢复窗口所在的桌面（Space），于是作者开发了开源工具 LayoutKeeper（GPL-3.0），只做三件事：

关键要点

• 认屏：用显示器 EDID（厂商、型号、序列号）区分不同屏幕，每块屏各存一份布局，无需手动切换场景。
• 连桌面一起记：保存窗口所在的外接屏桌面序号，恢复时一并放回；该功能需 macOS 26+，依赖 SkyLight 私有接口，仅需“辅助功能”权限，不用关闭 SIP 或注入 Dock。
• 插上自动恢复：每块屏首次使用时询问一次，之后插线自动执行。
• 0.6.7 重写自动恢复，一次插屏只跑一轮；支持恢复未见过的显示器；Chrome 窗口改按用户 profile 匹配。
• 0.6.8 改用 macOS 系统通知，点击可打开恢复结果；移除“拔线后自动删空桌面”和“桌面已移到内建屏”提示，因为 macOS 移动桌面后再删除会导致桌面重新编号，旧版本升级后该功能被强制关闭。

局限

仅支持一块外接屏；跨桌面恢复需 macOS 26+（同一桌面内位置恢复 macOS 14+ 即可）；依赖私有 API，系统大更新后可能失效，启动时会自动检测并关闭该功能；Finder 窗口无法跨桌面移动。仓库：https://github.com/tumingke0/LayoutKeeper

评论补充

有用户表示“这个有用，明天回去试下”，但尚无实际使用反馈。

核心内容

作者开源了一款安卓应用「勿追踪」（StopTrackingMe），目标是在分享链路中自动去除链接里的追踪参数，减少分享者隐私被大数据关联、甚至被反查的风险。主帖引用了 Must Be Cool 的链接检测页面作为背景参考。

关键要点

• 自动化方式：用户点击分享后弹出悬浮窗，应用借助无障碍权限点击分享链接，解析并去除参数后进入二次分享面板；也支持等待用户手动点击悬浮窗。
• 图片二维码：用 ML Kit 识别图片中的二维码链接，去除追踪参数后重绘图片。
• 分享形态：接入微信、QQ SDK，可像原应用一样以卡片形式分享；因未上架、未备案，当前分享到微信限制为 100 次/天。
• 规则可订阅：软件与规则分开维护，规则可通过 GitHub Release 的 rules.json 或镜像地址订阅，也支持自定义规则导入。
• 耗电：常驻后台的无障碍应用按 5000mAh 电池估算，每日后台耗电约 0.1%（4-5mAh）。
• 下载：提供免登录网盘与 GitHub Release 两种渠道。

评论补充

有回复指出，卡片上显示「勿追踪」字样可能让接收方觉得奇怪，作者表示正在考虑改名。另有回复提出更轻量的替代方案：多数分享链接会进入剪贴板，可做一个快捷设置磁贴，用户复制后点一下，应用读取剪贴板并替换参数，只需 BIND_QUICK_SETTINGS_TILE 权限；作者承认此前不了解该方案，表示将补充此功能。

核心内容

有用户报告：Mac 解锁时远程连接正常，锁屏一段时间后手机端 Codex/ChatGPT 显示 Mac 离线或连接超时，手机用流量或 Wi-Fi 均会出现。问题并非锁屏后立即发生，其中一次在锁屏约 126 秒时复现。

环境为 macOS 27.0.1（构建号 26A434）、Surge Mac 6.11.0（构建号 12560），MacBook Pro 接电源、保持开盖，远程连接与保持唤醒均已开启。

关键要点

• 复现时 Mac 仍锁屏，物理网卡的直连 TCP、DNS、TLS 测试正常，但经 Surge 本地代理的请求出现 CONNECT 超时，经系统隧道的请求也超时。
• Surge 进程出现 PROC_FLAG_SUPPRESSED 标志，同期 ChatGPT 及相关服务进程没有该标志，因此怀疑 Surge 被系统后台节能机制抑制。
• 临时处理：仅对 Surge 禁用 App Nap，执行 defaults write com.nssurge.surge-mac NSAppSleepDisabled -bool YES，然后退出并重开 Surge；未更换节点或调整策略组。
• 处理后连续锁屏约 20 分钟，未再观察到抑制标志，桌面端云连接未再中断，结束时 Mac 仍锁屏且代理与云端访问正常。
• 撤销命令：defaults delete com.nssurge.surge-mac NSAppSleepDisabled，再重开 Surge。

评论补充

有两位用户回复“相同问题+1”，其中一位建议 Surge 增加对应设置项，说明该现象并非孤例。

作者强调验证范围有限，这只是排查线索和临时办法，尚不能认定为普遍适用的修复；且此前相同用法未出现问题，是在更新 macOS 系统后才开始出现。

核心内容

作者用 AI Agent（文中称 pi gpt-6.1-sol）对 X、虎扑、酷安三个 APK 做逆向，目标是去掉信息流广告。整体流程是：让 Agent 读 APK、定位广告逻辑、改包重装，遇到问题再连电脑做动态调试。作者强调自己主要用这几个 App 浏览、很少发言，是否会触发风控封号尚不确定，并因法律风险未公开逆向产物，只放出 3 篇 AI 整理的笔记链接：https://blog.diaodaquan.dpdns.org/posts/

关键要点

• X：APK 未加壳，分析后基本一步到位。
• 虎扑：使用网易加固，Agent 分析加固逻辑后破解 dex 压缩算法、抽出原始 dex；改包安装后闪退并提示“请在官方渠道下载正版 app”，动态调试定位到会读取 assets/nedig.properties 并写入共享拒绝标志，修改后恢复正常。
• 酷安：同为网易加固，复用虎扑目录下生成的脚本和文档后很快抽出 dex；去广告后接口报错，原因是 libauth.so 不接受新证书，魔改该文件后正常。
• 可复用的经验是：把前一个 App 的脚本与文档沉淀下来，能显著加速同类加固 App 的处理。

评论补充

有回复质疑 X 近几个月开始检测改包、可能无法登录；作者回应自己改的版本仍可登录。该点只有单一来源，需自行验证。

＞ 提醒：修改并重装第三方 App 可能违反服务条款、带来账号与法律风险，本文仅作技术记录。

核心内容

旧 iPhone 残值低、留作备机时，存放方式主要影响电池寿命和应急可用性。主帖给出两种方案：一是长期开机，电量降到约 20% 就充电；二是充到约 50% 后关机，定期开机补电。由于机型较老，即使升级到最新 iOS 也没有充电上限功能。

关键要点

• 关机派：建议充到 50%–60% 后关机，每月或每三个月开机补一次电，避免长期接电源带来的风险。
• 开机派：认为开机更稳定，可当固话或应急机使用；有人用 7 Plus 装宽带卡在家当固话，约 3 天充一次。
• 自动化方案：用 HomeKit 智能插座配合自动化，按手机电量开关插座，间接控制充电。
• 电池维护：有回复建议备机上岗前做两三次完整充放电循环，让系统重新学习实际容量，日常不必浪费循环次数。

评论补充

有回复提到拆机外接充电管理模块来限制充电上限，但楼主认为拆机难度大、不采用。也有回复称关机后几天就没电，与“关机更省电”的经验相反，说明旧机电池状态差异较大，需按实际自放电情况调整补电频率。

核心内容

广西电信用户发现，每次重启接口、路由器或光猫触发重新拨号后，PPPoE 会先分配到 10.x 内网地址（如 10.102.111.137，DNS 为 192.168.29.29），此时除 QQ 外基本无法上网；等待数分钟再次拨号才能拿到 116.8.x.x 公网地址和正常 DNS（202.103.225.68）。该现象在放弃多拨、正常使用后仍会出现，作者怀疑与运营商限制多拨的策略有关。

关键要点

• 异常与正常拨号的差异体现在本地 IP、远端 IP 和 DNS三处，日志可作为投诉证据。
• 作者实测拨号间隔：22:05 至 22:08 连续多次均拿到 10.x，22:12 再拨才恢复公网 IP。
• 作者已排除 IPTV 专网可能：广西电信 IPTV 段为 10.133、DNS 为 113.17.187.97/98，与本次 10.10x 段及 DNS 均不符，且家中未开通 IPTV。

评论补充

• 有回复建议扫描二层广播域内的 PPPoE 服务器，怀疑存在多个接入点被随机选中，可尝试固定指派某一台。
• 作者扫描后确认只有一台 NE40E-X16，无其他 BRAS/vBRAS，该假设未获证实。
• 另有回复提出可能是运营商策略：短时间内多设备拨号会先给 10.x 并需冷却十几二十分钟，与作者观察到的“等几分钟再拨”吻合。
• 实用建议：保留 10.x 现场直接投诉无法正常上网，比事后描述更有说服力。

结论

目前无定论，但可复用的做法是：记录拨号日志与 IP/DNS 对比、排除 IPTV 段、确认 PPPoE 服务器数量，并在异常状态未恢复时立即报障。