热点内容

V2EX 2026-10-28 昨日新帖报告

1 肾癌术后M1 NED:医生建议免疫联合治疗,AI建议随访,该信谁

核心内容

楼主父亲8年前做过右肾透明细胞癌手术,两年前发现右侧腰背部包块,经CT、MRI、PET/CT怀疑肾癌转移,但未发现其他明确病灶。腰背部肿瘤已扩大切除,切缘阴性,病理及免疫组化确认肾细胞癌转移;术后影像无明确残留或其他转移,属于转移灶切除后的无瘤状态(M1 NED)。

医生建议立即使用“特瑞普利单抗+阿昔替尼”辅助治疗,理由是影像可能漏掉微小转移。AI(GPT6.1)依据NCCN和EAU指南认为:单个转移灶完整切除后不符合现有辅助免疫治疗研究的主要适用条件,特瑞普利单抗联合阿昔替尼主要用于有活动性晚期病灶者,现阶段获益与停药标准不明确,严密随访或再次多学科会诊更符合证据。

关键要点

  • 争议核心是M1 NED状态下是否应立即联合治疗,而非有无转移。
  • 楼主补充EAU指南为2026年版,并担心医生职业素养与利益输送。
  • 现实约束:父亲不愿再就医,医保外每月费用一万多元。

评论补充

多数回复建议多找几家医院、多位专科医生交叉验证,而非只信单一AI或单一医生;有回复强调AI不能背锅、人体差异大,需由专科医生判断指南适用性。也有回复建议先自学基础,再以“多信源验证”的姿态与医生沟通决策依据。

原链接:面对重大医疗决策, AI 和医生意见不同,我该信谁?回复 194 · 收藏 19

2 开源 DLNA 投屏接收器 LeanCast:5MB、无广告、支持安卓5.0+

核心内容

作者因 Fire TV 上的商业投屏 App 广告过多,自写并开源了 DLNA 投屏接收器 LeanCast(Apache-2.0,仓库:https://github.com/addozhang/leancast )。手机视频 App 点 [TV] 选中即可播放,无广告、无账号、全程局域网内。

关键要点

  • 实测可用平台:B 站、腾讯、优酷、爱奇艺、央视频、夸克;支持 4K 硬解,遥控器长按快进可阶梯加速。
  • 纯 Kotlin、无原生库,APK 约 5MB,安卓 5.0+ 电视和盒子可装,Fire TV 实测通过。
  • 特性列表、设备矩阵与下载见中文 README:https://github.com/addozhang/leancast/blob/main/README.zh-CN.md
  • 作者已发布 v0.2.1 修复“只有声音没有视频”:慢电视上播放器实例创建晚于界面启动,画面未挂载;修复版在界面状态变化时补挂画面。
  • 注意:v0.2.1 换用正式签名,装过旧版需先卸载再装,设置会重置,需重新开启开机自启。

评论补充

有索尼 Android 10 用户反馈上述无声无画问题,作者定位并修复,说明兼容性仍在迭代。另有用户询问内嵌字幕与切音轨,作者明确不做,建议由平台侧处理;对 B 站、央视私有协议的支持请求,作者以法律风险为由拒绝。评论中还提到同类开源项目 castbay 与 MiracastReceiver,可作备选对比。

原链接:造了个开源 DLNA 投屏接收器:起因是商业投屏 app 实在用不下去回复 17 · 收藏 35

3 经典电视剧为何少有官方高清修复:审核、成本与收益

核心内容

主帖提出一个常见疑问:B 站上大量 MV 能被高质量修复,为什么经典电视剧却少有官方高清修复?发帖者设想由出品方牵头、修复者竞标、平台会员付费观看,认为这样既能合法收费,又能提升成片质量。

评论区的共识是:这不是单纯的技术问题,而是审核、版权归属、责任主体和商业回报共同作用的结果。

关键要点

  • 审核与片源:有回复指出,片源变化可能触发重新审核,老剧按现行标准未必能完整放出;也有回复以影院放映修复老电影为例,认为审核未必是主要障碍,分歧仍在。
  • 责任与收益:剧组早已解散,谁负责修复、谁承担版权与内容责任、能带来多少实际收益,都缺乏明确答案。多条回复把根本原因归结为“不能从中获利”。
  • 成本被低估:高质量修复接近二次创作,成本不低;低质量超分又难获认可。MV 时长短、成本低,不能直接类比电视剧。
  • 平台主导:有回复提到优酷修复过老三国、老 TVB 剧,高清化多由平台推动而非版权方。
  • 技术争议:部分回复认为超分辨率是从缺失信息中“生成”,观感可能不自然;也有人期待本地 AI 实时高清化,类似游戏的 DLSS/FSR。

评论补充

有回复提到国内 App 清晰度可能不如 YouTube,但片源是否一致未获证实。整体看,官方修复能否推进,取决于版权、审核、成本与变现渠道能否同时打通。

原链接:那么多经典电视剧怎么不进行官方高清修复呢回复 73 · 收藏 6

4 用 Google 表单 + Apps Script 搭建零成本自动发码系统

核心内容

独立开发者做 Giveaway 时,手工私信发码容易错发漏发,Typeform、Jotform 等免费版提交额度低,明文贴码又会被爬虫扫走。作者用 Google Forms + Sheets + Apps Script 搭了一套零成本、Serverless 的自动发码流程,并给出了完整脚本与部署步骤。

关键要点

  • 流程:用户提交邮箱 → 表单触发脚本 → 加锁 → 校验每日限额与邮箱唯一性 → 从 Codes 表取第一个空闲码 → 回写邮箱与时间戳 → 用 GmailApp 发信;达到限额则关闭表单,次日由定时触发器重开。
  • 防并发撞码:用 LockService.getScriptLock() 加互斥锁,配合 SpreadsheetApp.flush() 落盘后再释放。
  • 防刷与限额:邮箱去重;DAILY_LIMIT = 100 对应 Gmail 免费账号每日 100 封硬限制,超额前主动 setAcceptingResponses(false)。
  • 表头兼容:中文界面下邮箱列名为“电子邮件地址”,脚本用中英文关键词加邮箱正则双重匹配,避免静默失败。
  • 时区:在项目设置中校准 Time zone,全球活动建议用 UTC,保证每日截断与重开时间一致。

评论补充

有回复建议改用 Supabase 免费配额加 Cloudflare Pages 自建,认为数据库 500M 足够且无明显并发上限;也有人推荐另一免费发码服务 promies.net。另有回复指出原文缺少配图、阅读门槛高,作者建议把文章交给 AI 辅助逐步部署。这些替代方案均未在评论中给出验证细节。

原链接:零成本!用 Google 表单 + Apps Script 搭建全自动独立分发码/优惠码系统回复 5 · 收藏 12

5 小米智能门锁5号电池耗电快:排查与电池选择

核心内容

楼主的小米智能门锁(带摄像头,摄像头由锂电池供电)4 节 5 号电池不到 3 个月就没电,想买 1.5V 充电电池,又担心是“智商税”。多数回复的经验是:正常门锁一年以上才换一次电池,3 个月耗尽属于异常,应先排查原因,而不是急着换充电电池。

关键要点

  • 先排查异常:多位用户建议报修或联系售后,怀疑电路漏电、芯片故障;也有人提到近期固件更新后耗电变快,可留意版本变化。
  • 屏幕可能是耗电大户:带屏幕、摄像头的型号耗电更快,可尝试关闭屏幕观察一段时间。
  • 电池本身:有人提醒市面上存在假南孚;普通碱性电池(如南孚、小米彩虹)正常可用一年左右。
  • 充电电池:有回复推荐爱乐普,但主帖担心的“充几次就坏”没有直接使用证据,结论待验证。

评论补充

有用户称基础指纹款两三年才换一次电池,带屏款明显更费电;也有人认为“不能用南孚”的说法是产品偷工减料。综合看,先确认是否漏电或固件问题,再考虑换电池类型更稳妥。

原链接:小米智能门锁, 5 号电池总是很快用没电回复 59 · 收藏 0

6 HelloGitHub 第127期:42个开源项目精选

核心内容

本期《HelloGitHub》第 127 期汇总了 42 个开源项目,覆盖 C、C#、C++、Go、JavaScript、Kotlin、Python、Rust、Swift 及 AI 等方向,多数项目可直接下载使用或自托管,适合作为工具选型与学习参考。

关键要点

  • 本地与隐私优先:colibri 用纯 C 实现 MoE 推理,最低 8GB 内存、无需 GPU 即可跑 GLM、Kimi、DeepSeek、Qwen,并提供兼容 OpenAI/Anthropic 的 API;Filee 支持 200 多种格式离线转换;PicLite、omni-tools 均在本地处理文件。
  • AI 编程配套:magpie 通过本地网关转换接口格式,让 Claude Code 用 Kimi、Codex 用 DeepSeek;EditHere 把截图批注转成 AI 可读 JSON;impeccable、diagram-design 等 Skills 用于约束 AI 生成界面的同质化问题。
  • 基础设施与安全:gocryptfs 提供 Go+FUSE 加密文件系统;pocket-id 支持 Passkey 的自托管 OIDC/OAuth 2.0;英伟达 OpenShell 为 AI 智能体提供内核级隔离沙箱。
  • 硬件与性能:gpu-unlock 解锁 RTX 30 系 FP16/BF16 速率,文中称 RTX 3090 Ti 的 BF16 从 87.5 提升到 157.4 TFLOPS,大模型预填充提速 14%~36%;tilelang 用 Python 写 GPU 算子。

评论补充

回复仅有“先赞后看”“给力”等简短支持,未提供使用反馈或事实核验,项目效果与数据仍需自行验证。

原链接:《HelloGitHub》第 127 期回复 6 · 收藏 9

7 多设备开发同步:用 Git 分支与远程开发替代文件同步

核心内容

提问者在家里电脑、单位电脑和笔记本之间频繁切换,因任务未完成而不愿或忘记提交代码,导致换设备后代码不同步。他曾用 Nextcloud 同步代码并保留 .git 目录,但同步 .git 经常报错,且产生大量冗余文件。

关键要点

  • 不要用文件同步工具同步代码库:多位回复者认为 Nextcloud 同步 .git 是错误方向,Git 本身已能解决版本与同步问题。
  • 及时提交到开发分支:未完成的工作可提交到独立分支,或使用 WIP: XXX 形式的提交信息,合并前再 squash 整理,避免污染主分支。
  • 远程开发是主流方案:用 VS Code Remote、SSH 或远程桌面连接一台固定主机(性能与网络最好的那台),各终端只负责接入,从根源上避免多份代码。
  • 网络接入方式:可用 Tailscale、内网穿透或网易 UU 等工具连接工作机,保持工作机 24 小时开机。
  • 临时导出方案:可用 git bundle create 将当前分支导出到云端,再在另一台设备导入。

评论补充

评论普遍反对“重复发明轮子”,认为随手 pull/commit 比第三方同步更可靠;也有回复提到用远程开发机统一运行 Codex CLI 等工具,但指出公司项目可能不允许把代码放到远程开发机。

> 共识:优先用 Git 分支管理未完成代码;若设备切换频繁,远程开发比文件同步更稳。

原链接:项目开发多设备同步的问题回复 25 · 收藏 5

8 DeepSeek V4.1 Flash 1017 登顶 OpenRouter:实测体验与成本讨论

核心内容

主帖称 DeepSeek V4.1 Flash 1017(10 月 17 日快照)在 OpenRouter 用量榜登顶,第三方追踪站记录一周 35.4 万亿 token,OpenRouter 工具调用合集页近 7 天超 40 万亿。模型为 MIT 协议、稀疏 MoE、CED 架构,输入约激活 8B、输出约激活 16B,原生图像理解,KV cache 压到上代 Flash 约四分之一,上下文 1,048,576;OpenRouter 标价输入 $0.0182/百万 token、输出 $1.80/百万 token。

关键要点

  • 官方自报跑分:Terminal-Bench 4.0 为 42.3(GPT-5.6 Sol 39.9、Opus 5 51.8),DeepSWE v1.1 为 77.0,Automation-Bench 为 60.5,HLE 无工具 42.6。
  • 主帖自列疑点:对比对象非最新旗舰;Artificial Analysis 独立测得 Terminal-Bench 26.8%、综合智能指数 39.5,与官方差距大;限时免费接入可能抬高用量。
  • 主帖设想:把它当 agent 循环、仓库杂活、长文档的默认 worker,难题再升级闭源旗舰。

评论补充

多数回复认可其速度与成本,有人称“不瞎猜、很少打断”,适合个人 agent 与轻量编程;有用户实测认为它达不到 GPT-6.1 Sol 水准,更佳用法是 GPT-6.1 Sol 指挥、DS 干活。也有人质疑免费流量为何计入 OpenRouter,并询问 OpenRouter 是否比官方 API 便宜。

原链接:DeepSeek V4.1 Flash 1017 一周跑了 35 万亿 token 登顶 OpenRouter,你们 agent 默认模型换了吗?回复 29 · 收藏 3

9 deepseek-v4.1-flash-1017 死循环:渠道与工具调用兼容问题

核心内容

有用户在使用 deepseek-v4.1-flash-1017 时,模型长时间处于 think 状态,并反复输出 ` 、 ` 等工具调用标记,形成死循环。发帖人补充:走阿里云渠道、用 opencode,前几天正常,之后开始频繁复现。

关键要点

  • 渠道差异明显:多位回复者称官方 API、火山、OpenRouter 未遇到;英伟达渠道、中转站和网页端出现过类似循环。
  • 疑似量化版本:多人推测低量化版本更易出现“雷霆大思考”式循环,建议改用 API 或官方渠道。
  • 工具调用不匹配:DSML 参数输出异常可能与 Agent 的工具调用方式不兼容有关;有 Agent 会因 todo 未完成而强制继续,工具持续出错便陷入死循环。
  • 可尝试的修法:换 Agent 或 harness;在 Agent 侧打补丁翻译工具调用;中转站场景可尝试在配置中追加 "compat": { "allowEmptySignature": true } 关闭认证相关校验。

评论补充

官方 API + Claude Code 重度使用者称未复现;本地部署 qwen 在 deepseek harness 上出现类似输出,打补丁后修复。整体看,问题更可能出在渠道、量化与 Agent 兼容层,而非单一模型缺陷,但缺少系统性验证。

原链接:deepseek-v4.1-flash-1017 经常陷入死循环,有人有类似经历么回复 25 · 收藏 1

10 Me2Cloud:从家庭网络测17家云361个区域真实延迟

核心内容

Me2Cloud 是一个开源、可自部署的云区域延迟测试工具,解决“机房测速网站测不到家庭宽带真实体验”的问题。请求由浏览器直接发往各厂商公开 API,覆盖 AWS、Azure、Google Cloud、阿里云、腾讯云、华为云、火山引擎、百度智能云、Oracle、IBM、Vultr、DigitalOcean、Linode、Hetzner、OVH、Scaleway、Naver 共 17 家、361 个区域。

关键要点

  • 用 HTTPS 而非 ping:浏览器无法发 ICMP,且运营商对 ICMP 与 TCP 限速策略不同;HTTPS 有服务器处理开销(AWS 约 0–5ms、阿里云约 8ms、华为云 OBS 约 20ms),近距离结果会略高于 ping。
  • 防代理干扰:检测出口 IP、时区、WebRTC 与 HTTPS 出口是否一致,异常时提示并提供 Clash/Mihomo、Surge、sing-box 等直连规则;规则只列实际用到的 413 个域名,不用通配符,避免误伤 S3/OSS 流量。
  • 限速防 WAF:同域名并发 1、间隔至少 250ms、单次最多 21 个请求、连续失败 3 次跳过。
  • 隐私与部署:无后端、不登录、数据只存浏览器;分享链接把结果压缩进 URL,图片用 canvas 本地生成。MIT 协议,纯静态,可用 npx wrangler deploy 部署到 Cloudflare Workers。
  • 局限:只代表测试点本地网络,不代表用户;测的是公开 API 而非具体虚拟机,CN2 GIA 等线路可能不同;不测带宽和 UDP,建议晚 8–11 点复测。

评论补充

有用户反馈“网页选不了地区”,属待核验的功能问题;作者说明直连规则为自动生成,多数工具可直接引用规则集。

原链接:[开源发布] : Me2Cloud,从你自己家的网络,测到各大云 360+ 个区域的真实延迟(开源,可自部署)回复 3 · 收藏 2

11 ip2geo:零依赖 Go IP 归属地库,IPv4 查询快 14~58 倍

核心内容

作者开源了 Go 库 ip2geo(MIT,v0.1.0),用于替代 geoip2-golang 查询 IP 归属地。起因是 City() 单次约 1.7µs,耗时主要在解码 mmdb 数据结构,而实际只需国家、省份、城市、经纬度、时区几个字段。做法是把 MaxMind GeoIP2/GeoLite2 City 或 DB-IP 的 .mmdb 一次性转成紧凑的 .geoc 文件,之后直接在其上查询 IPv4/IPv6。

关键要点

  • 性能(Apple M3 单核,500 万随机 IPv4,5 次取中位数):geoip2-golang City() 1768ns;ip2geo city profile 119ns(14.5×);country profile 30.5ns(58×)。IPv6 在 country profile 约 42ns,city profile 约 260ns。基准代码在仓库 bench/ 可复现。
  • 读取端零第三方依赖,Lookup 零内存分配,*Reader 并发安全。
  • 三档 profile:country(3.5 MiB)、region(26 MiB)、city(116 MiB),以 123 MiB 的 GeoIP2-City 为源。
  • 也可不转换,用 mmdb.Open 直接读 .mmdb 在内存建索引(启动约 2 秒),API 风格接近 geoip2-golang。
  • 附带 CLI ip2geo build / ip2geo lookup;Release 提供基于 DB-IP Lite(CC BY 4.0)构建好的 .geoc,无需注册 MaxMind 即可试用。

评论补充

有读者询问是否用空间换时间、把数据全放内存,主帖未直接回应;另一读者推荐了自部署的同类项目 https://github.com/hezhizheng/goip 。

原链接:[开源] ip2geo:零依赖的 Go IP 归属地查询库, IPv4 查询比 geoip2-golang 快 14~ 58 倍回复 2 · 收藏 5

12 ToDesk 占用 188G 硬盘:用户反馈与远程工具替代方案

核心内容

有用户发现 ToDesk 长期占用约 188G 硬盘空间,导致 1TB 磁盘快速写满;发帖者称去年安装后仅用过几次,客户电脑只装了 ToDesk,因此一直保留。多位回复者表示遇到同类问题,有人 256G 磁盘被占满后卸载。

关键要点

  • 问题表现:有回复称升级 macOS 27 后 ToDesk 不兼容,在 /Library/ 下的 dumps 文件夹持续写入,即使进程关闭仍产生文件;升级到最新版后问题缓解,但该用户已改用 UU 远程。
  • 排查建议:若磁盘异常减少,可检查 ToDesk 的日志或 dumps 目录及安装目录体积,不用时卸载而非仅退出。
  • 替代方案:评论提到 RustDesk(开源、局域网可 P2P 打洞)、UU 远程(被认为较干净)、向日葵(被指越来越难用)。
  • RustDesk 限制:有回复指出其解决不了底层网络问题,跨运营商直连易卡,自建服务端最好部署三线 BGP 中转。

评论补充

讨论共识是 ToDesk 收费后体验下滑、占用问题非孤例;分歧在于替代品选择,RustDesk 强调开源可控但依赖网络条件,UU 被认为当前较干净但可持续性未知。

原链接:今天才发现 todesk 吃我 188g 硬盘回复 13 · 收藏 2

13 用 GPT 开发网页和 APP 时提升 UI 美感的实用方法

核心内容

主帖的痛点是:用 GPT 默认生成的界面字体过粗、布局混乱、配色难看。评论给出的共识是:不要指望模型凭空产生审美,而应给它明确的约束和可参考的素材。

关键要点

  • 提供参考图:从 dribbble 找设计图直接交给模型,或自建 design guide,把 design token、推荐版式和范例风格固定下来。
  • 先定 CSS 框架:指定 TailwindCSS 这类声明式框架,再要求整理通用组件样式库,之后通过排列组合复用。
  • 使用成熟设计系统:在项目中安装 shadcn 等设计系统,要求 Agent 优先使用其组件,非必要不自行生成新组件。
  • 尝试现成 skill:评论提到 impeccable,它会在初期给出几种风格供选择,并可在此基础上调整。
  • 积累审美词汇:美是主观的,日常积累 UI/UX 词汇与审美,再把自己的偏好明确告诉模型。

评论补充

多位回复者强调“约束优先于自由生成”:框架、设计系统、参考图三者结合,比反复用自然语言描述“好看一点”更有效。impeccable 的实际效果来自个别用户的初步试用,尚无更多验证。

原链接:请教一下使用 GPT 开发网页、APP,怎么提升 UI 美感回复 6 · 收藏 5

14 公司多人用AI会拖慢办公网络吗:带宽、连接数与QoS分析

核心内容

多人使用 AI 是否拖慢办公网络,关键不在总带宽,而在连接数和上行带宽。多数回复认为纯文本交互的流量很小,远低于视频;但部分 AI 客户端会建立大量长连接或频繁请求,可能耗尽路由器/NAT 的连接数上限,导致卡顿。

关键要点

  • 带宽:文本对话占用有限;有用户实测 sub2api 近 30 天总 Token 28.71B,上游走自建 HTTP 代理月流量 600GB+,说明规模化使用后流量不可忽视。
  • 连接数:多位用户指出 agent 客户端会大量占用连接数,是更常见的瓶颈;专线通常无碍,家庭宽带(连接数约 2000)容易出问题。
  • 排查与缓解:可通过 QoS 给高优先级业务限流、调整 tcp/udp timeout 回收连接;并发能力不足只能升级设备。有案例是 10 台 PLC 各产生 1400+ DNS 并发,撑爆 16384 上限。

评论补充

分歧在于影响程度:有人认为 AI 流量远小于视频、不会卡;也有人遇到某国内 AI 客户端占满连接数导致网络崩溃。若公司用的是家庭宽带而非专线,风险明显更高。

原链接:公司内使用 ai 的人多了, 是否会导致办公上网网络卡顿?回复 20 · 收藏 0