[分享创造] 假到位
写了一篇关于锁的东西。不长。
关于弹子锁里一种叫假到位的状态——弹子卡在差一点的位置，手上的感觉跟到位了一模一样，但锁没开。
从锁写到了人。从人写回了锁。
https://xiaoni.liahuas.top/false-set/
写了一篇关于锁的东西。不长。
关于弹子锁里一种叫假到位的状态——弹子卡在差一点的位置，手上的感觉跟到位了一模一样，但锁没开。
从锁写到了人。从人写回了锁。
https://xiaoni.liahuas.top/false-set/
[NAS] 关于更换操作系统后 TimeMachine 无法备份的解法
最近给 NAS 重装了系统，把绿联刷飞牛 OS ，macOS Time Machine 突然无法备份，提示"备份失败"。密码绝对正确、手动挂载完全正常，但 Time Machine 就是连不上。
实际上，飞牛社区某个不起眼的楼中楼回复给出了下面 AI 耗时 2 个小时自行探索修复的结论，只不过写得不太清楚。
症状
● Time Machine 永远备份失败，系统通知只有一句"备份失败"，提示的是这个：
●
● 在 Finder / 终端里用
● NAS 的 Samba 日志里看不到任何来自 Mac 的认证尝试——失败发生在 Mac 本地，认证包根本没发出去。
环境
● macOS 15.7 (Sequoia)，备份目标为 SMB 共享（本文案例：绿联硬件刷飞牛 OS 后的 Samba ，开启了
● 路由器做了 IP-MAC 绑定，NAS 重装系统后 IP 不变。
排查过程（可直接复用的诊断路径）
1. 拿到真正的报错
注意：很多人的 shell 里
典型输出：
错误 29 只是外层包装，真身是 NetAuth 的 **EAUTH (80)**。
2. 排除 NAS 端
用内嵌密码手动挂载：
能挂上 = 网络/SMB/凭据/共享全通。再去 NAS 上看 Samba 日志（
3. 盯住真正的认证代理 NetAuthSysAgent
Time Machine 以 root 运行，认证走
关键日志：
4. 找到"已知服务器"名单
用
会发现它读取：
打开一看（需要 sudo ）：
只有旧系统的主机名，没有重装后的新主机名，也没有 IP 。
根因
macOS 的 NetAuth 框架维护一份"已知服务器"标记（ ServerMarkers ）。对不在名单里的服务器，
NAS 重装系统后，尽管 IP 没变，但 Bonjour 主机名、Samba 服务标识全变了——在 Mac 眼里这是一台全新的、从未信任过的服务器。而 GUI （系统设置/Finder ）添加凭据的流程不知为何没有把新主机名写进标记（这在重装 NAS 的场景下似乎不会自动发生），于是形成死锁：
● 钥匙串里有正确密码 ✓
● 服务器一切正常 ✓
● NetAuth："这服务器我不认识，不试。" ✗
修复
第一步：把新服务器加进已知名单（键名必须全小写！）
三个坑：
1. 键名全小写——主机名比较是小写的，
2. **用 PlistBuddy 而不是
3. 三个名字（ IP 、Bonjour 服务名、mDNS 主机名）都加上，因为 Time Machine 目的地 URL 可能用其中任意一种。可用
第二步：重新添加备份目的地
系统设置 → 通用 → 时间机器 → 选择备份磁盘 → 选中 NAS 上的 TimeMachine 共享 → 输入账号密码。
然后触发备份验证：
看到
顺手清理（可选）
● 旧 NAS 的标记（本例中的
● 钥匙串里指向旧 NAS 身份的残留条目：钥匙串访问.app 搜 NAS 名字/IP 删掉即可。
● 如果之前用命令行折腾过
深层定性：这是 macOS 的锅，而且能从机制反推出一个惊人结论
三层状态，各自为政
macOS 实际维护三套互相同步不良的认证状态：
最近给 NAS 重装了系统，把绿联刷飞牛 OS ，macOS Time Machine 突然无法备份，提示"备份失败"。密码绝对正确、手动挂载完全正常，但 Time Machine 就是连不上。
实际上，飞牛社区某个不起眼的楼中楼回复给出了下面 AI 耗时 2 个小时自行探索修复的结论，只不过写得不太清楚。
症状
● Time Machine 永远备份失败，系统通知只有一句"备份失败"，提示的是这个：
●
tmutil destinationinfo 正常，defaults read /Library/Preferences/com.apple.TimeMachine 里 RESULT = 29。● 在 Finder / 终端里用
mount_smbfs //user:password@nas/Share 挂载备份共享完全正常——网络、账号、密码、共享配置、NAS 端 Samba 全部无辜。● NAS 的 Samba 日志里看不到任何来自 Mac 的认证尝试——失败发生在 Mac 本地，认证包根本没发出去。
环境
● macOS 15.7 (Sequoia)，备份目标为 SMB 共享（本文案例：绿联硬件刷飞牛 OS 后的 Samba ，开启了
fruit:time machine）。● 路由器做了 IP-MAC 绑定，NAS 重装系统后 IP 不变。
排查过程（可直接复用的诊断路径）
1. 拿到真正的报错
注意：很多人的 shell 里
log 被别名/函数占用，会直接静默失败。统一日志工具请写全路径：tmutil startbackup # 手动触发一次备份
/usr/bin/log show --last 5m --info --debug --style compact \
--predicate 'process == "backupd"' | grep -iE 'error|fail|mount'
典型输出：
[Mounting] Attempting to mount 'smb://app@pdnas._smb._tcp.local./TimeMachine'
[Mounting] NAConnectToServerSync failed with error: 80 (Authentication error)
[BackupDispatching] Backup failed: BACKUP_FAILED_AUTHENTICATION_ERROR (29)
错误 29 只是外层包装，真身是 NetAuth 的 **EAUTH (80)**。
2. 排除 NAS 端
用内嵌密码手动挂载：
mkdir /tmp/tm && mount_smbfs '//user:password@192.168.x.x/TimeMachine' /tmp/tm
能挂上 = 网络/SMB/凭据/共享全通。再去 NAS 上看 Samba 日志（
/var/log/samba/log.*），失败时间点一条记录都没有 → 客户端本地失败。3. 盯住真正的认证代理 NetAuthSysAgent
Time Machine 以 root 运行，认证走
NetAuthSysAgent：/usr/bin/log show --last 2m --info --debug --style compact \
--predicate 'process == "NetAuthSysAgent"'
关键日志：
[Keychain] isKnownServer 0
[MechTypes] CredentialsStage set to 5
[MechTypes] There are no user credentials to add to the MechType session
[NetFS] OpenSession failed 80
isKnownServer 0 —— NetAuth 认为这台服务器"不认识"，直接跳到第 5 阶段，连钥匙串都不查就放弃了。4. 找到"已知服务器"名单
用
fs_usage 跟踪 agent 读的文件：sudo fs_usage -w -f filesys NetAuthSysAgent
# 另一个终端触发 tmutil startbackup
会发现它读取：
/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist
打开一看（需要 sudo ）：
"ugreen-cd13.local" => 1
"ugreen-cd13-2.local" => 1
_migrationVersion => 2
只有旧系统的主机名，没有重装后的新主机名，也没有 IP 。
根因
macOS 的 NetAuth 框架维护一份"已知服务器"标记（ ServerMarkers ）。对不在名单里的服务器，
NetAuthSysAgent 在无交互权限的系统上下文中（ Time Machine 正是如此）直接判定 isKnownServer = 0，跳过钥匙串查询、不发出任何认证包，向上层返回 EAUTH 。NAS 重装系统后，尽管 IP 没变，但 Bonjour 主机名、Samba 服务标识全变了——在 Mac 眼里这是一台全新的、从未信任过的服务器。而 GUI （系统设置/Finder ）添加凭据的流程不知为何没有把新主机名写进标记（这在重装 NAS 的场景下似乎不会自动发生），于是形成死锁：
● 钥匙串里有正确密码 ✓
● 服务器一切正常 ✓
● NetAuth："这服务器我不认识，不试。" ✗
修复
第一步：把新服务器加进已知名单（键名必须全小写！）
PL="/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist"
sudo cp "$PL" "$PL.bak" # 先备份
sudo /usr/libexec/PlistBuddy -c "Add :192.168.x.x integer 1" "$PL"
sudo /usr/libexec/PlistBuddy -c "Add :your-nas._smb._tcp.local. integer 1" "$PL"
sudo /usr/libexec/PlistBuddy -c "Add :your-nas.local integer 1" "$PL"
三个坑：
1. 键名全小写——主机名比较是小写的，
PDNAS.local 写了等于没写（对照名单里原有的 ugreen 条目，全是小写）。2. **用 PlistBuddy 而不是
plutil -insert**——plutil 把键名里的 . 当作嵌套路径分隔符，含点的主机名会静默失败； PlistBuddy 的路径分隔符是 :，点号是安全的。3. 三个名字（ IP 、Bonjour 服务名、mDNS 主机名）都加上，因为 Time Machine 目的地 URL 可能用其中任意一种。可用
tmutil destinationinfo 看你的 URL 用的是哪种。第二步：重新添加备份目的地
系统设置 → 通用 → 时间机器 → 选择备份磁盘 → 选中 NAS 上的 TimeMachine 共享 → 输入账号密码。
然后触发备份验证：
tmutil startbackup && sleep 15 && tmutil status
看到
Running = 1、BackupPhase = Copying 即修复完成。此时再回头抓 NetAuthSysAgent 日志，会看到流程变成：[Keychain] isKnownServer 1
[MechTypes] Next CredentialsStage set to 4
[MechTypes] MechTypes were acquired for the MechType session using credentials
顺手清理（可选）
● 旧 NAS 的标记（本例中的
ugreen-cd13*）：留着无害，想删可以用 PlistBuddy -c "Delete :ugreen-cd13.local" "$PL"。● 钥匙串里指向旧 NAS 身份的残留条目：钥匙串访问.app 搜 NAS 名字/IP 删掉即可。
● 如果之前用命令行折腾过
tmutil setdestination -ap，注意它写的是旧式 /Library/Keychains/System.keychain，而 macOS 15 的 NetAuthSysAgent 查的是新式 system-keychain-2.db——命令行加的条目它可能根本看不到，以 GUI 添加的为准。深层定性：这是 macOS 的锅，而且能从机制反推出一个惊人结论
三层状态，各自为政
macOS 实际维护三套互相同步不良的认证状态：
V2EX
[NAS] 关于更换操作系统后 TimeMachine 无法备份的解法 最近给 NAS 重装了系统，把绿联刷飞牛 OS ，macOS Time Machine 突然无法备份，提示"备份失败"。密码绝对正确、手动挂载完全正常，但 Time Machine 就是连不上。 实际上，飞牛社区某个不起眼的楼中楼回复给出了下面 AI 耗时 2 个小时自行探索修复的结论，只不过写得不太清楚。 症状 ● Time Machine 永远备份失败，系统通知只有一句"备份失败"，提示的是这个： ● tmutil destinationinfo…
在系统设置里输入密码时，GUI 真实连接了 NAS 并验证成功（ NAS 日志有访问记录）、也写入了钥匙串——但没有写信任标记。后端 daemon 只认标记。UI 的"成功"和后端的"信任"是两套语义，这是字面意义上的脱钩。而整个失败链条最终坍缩成一句"备份失败 / 错误 29"，用户能做的所有常规操作（重输密码、删了重加、换 IP 换域名）都够不到真正出问题的那层状态。
时间线复盘：两个诱因叠加
●
● 刷入新 NAS 系统（飞牛 OS ）后，主机名/Samba 身份变更，但 IP 因路由绑定没变——新身份从未进入信任名单（埋雷）；
● 备份在新系统上正常跑了一段时间，直到一次 macOS 更新（机器重启时间吻合）后突然全挂——很可能是该更新引入了 marker 迁移（
反推结论："第一台服务器定律"
把上面的事实拼起来，可以得出一个可检验的强推论：
1. 首次配置 TM 时，某个 onboarding 流程在验证凭据成功后会写入
2. 此后这个文件再无任何面向用户的流程会更新它（实测：设置 UI 里重输密码、删除磁盘再添加、命令行
3. 于是第二台服务器（换 NAS 、NAS 重刷系统、改主机名都会让 Mac 认为是"新服务器"）永远卡在
4. 唯一出路就是手动编辑那个没有文档、不在任何官方排障流程里的 plist 。
限定条件：本结论基于 macOS 15.7 上一次可完整复现的案例 + 完全自洽的机制解释，样本量为 1 。如果你手上有"换 NAS 后第二台 TM 服务器直接从设置里配成功"的反例，欢迎打脸——那至少说明 Apple 在新版本里修了。
实操推论：标记是按主机名字符串匹配的。所以换新 NAS / 重刷系统时，把新主机名（ Bonjour 名）设置成和旧的完全一致，老标记直接命中，大概率可以无感迁移、免疫此坑。
Apple 应该怎么做（三条任选其一即可治本）
1. TM 设置 UI 验证凭据成功时同步写入 serverMarkers ；
2. NetAuthSysAgent 把"钥匙串中存在该服务器的有效凭据"视为 known 的兜底条件；
3. 至少把 "untrusted/unknown server" 作为独立错误暴露给用户，而不是笼统的"备份失败 / 错误 29"。
三条一条都没做，于是唯一的解法落在用户手动编辑内部状态文件上。
诊断工具箱（收藏备用）
注意：
总结
一句话：NAS 重装/更换后，把新主机名（小写）和 IP 加进
时间线复盘：两个诱因叠加
●
serverMarkers.plist 的文件修改时间停留在首次配置旧 NAS 的那天，此后再未被任何流程更新；● 刷入新 NAS 系统（飞牛 OS ）后，主机名/Samba 身份变更，但 IP 因路由绑定没变——新身份从未进入信任名单（埋雷）；
● 备份在新系统上正常跑了一段时间，直到一次 macOS 更新（机器重启时间吻合）后突然全挂——很可能是该更新引入了 marker 迁移（
_migrationVersion = 2）或收紧了 isKnownServer 校验（引爆）。反推结论："第一台服务器定律"
把上面的事实拼起来，可以得出一个可检验的强推论：
在一台 macOS 设备上，只有它这辈子连接的第一台 Time Machine 服务器，能够从系统设置里顺利完成备份。推理过程：
1. 首次配置 TM 时，某个 onboarding 流程在验证凭据成功后会写入
serverMarkers.plist——所以第一台服务器永远顺利；2. 此后这个文件再无任何面向用户的流程会更新它（实测：设置 UI 里重输密码、删除磁盘再添加、命令行
tmutil setdestination，全部不会写标记）；3. 于是第二台服务器（换 NAS 、NAS 重刷系统、改主机名都会让 Mac 认为是"新服务器"）永远卡在
isKnownServer = 0——钥匙串里密码再正确也不会被使用；4. 唯一出路就是手动编辑那个没有文档、不在任何官方排障流程里的 plist 。
限定条件：本结论基于 macOS 15.7 上一次可完整复现的案例 + 完全自洽的机制解释，样本量为 1 。如果你手上有"换 NAS 后第二台 TM 服务器直接从设置里配成功"的反例，欢迎打脸——那至少说明 Apple 在新版本里修了。
实操推论：标记是按主机名字符串匹配的。所以换新 NAS / 重刷系统时，把新主机名（ Bonjour 名）设置成和旧的完全一致，老标记直接命中，大概率可以无感迁移、免疫此坑。
Apple 应该怎么做（三条任选其一即可治本）
1. TM 设置 UI 验证凭据成功时同步写入 serverMarkers ；
2. NetAuthSysAgent 把"钥匙串中存在该服务器的有效凭据"视为 known 的兜底条件；
3. 至少把 "untrusted/unknown server" 作为独立错误暴露给用户，而不是笼统的"备份失败 / 错误 29"。
三条一条都没做，于是唯一的解法落在用户手动编辑内部状态文件上。
诊断工具箱（收藏备用）
# 看 TM 配置和最近一次结果码
tmutil destinationinfo
defaults read /Library/Preferences/com.apple.TimeMachine
# 抓 backupd 报错（/usr/bin/log 全路径，避开 shell 别名坑）
/usr/bin/log show --last 10m --info --predicate 'process == "backupd"'
# 抓 NetAuth 认证流程
/usr/bin/log show --last 2m --info --debug --predicate 'process == "NetAuthSysAgent"'
# 跟踪 NetAuthSysAgent 读了哪些状态文件
sudo fs_usage -w -f filesys NetAuthSysAgent
# 验证"密码本身没问题"（内嵌密码挂载）
mkdir /tmp/t && mount_smbfs '//user:pass@nas-ip/Share' /tmp/t
注意：
mount_smbfs 不带密码在非交互终端下不会查钥匙串，会以空凭据被服务器拒绝（ exit 77 ），不要用它来判断钥匙串条目是否有效——这是排查时最容易踩的假线索。总结
一句话：NAS 重装/更换后，把新主机名（小写）和 IP 加进
serverMarkers.plist，再走一遍系统设置添加备份磁盘，即可恢复。 更深层次上，这是 macOS 设置 UI 与后端认证体系脱钩的 bug——一台 Mac 这辈子只有第一台 TM 服务器能从设置里配成功，换服务器身份后必踩此坑。[分享创造] 做了个支持多级跳板的 SSH 会话中间件，让 AI Agent 能操作堡垒机后面的服务器
为什么做这个
最近工作里，写代码、改文档、点网页这类事，基本已经可以交给 AI Agent 了。但一碰到服务器操作就卡住：
公司一般都有跳板机 / 堡垒机，Agent 没法直接连后面的机器，自动化就断了。
更头疼的是排查问题：经常得先登录服务器，把线上日志拷到本地，丢给 Agent 分析，再拿着它给的步骤回到线上执行。来回倒腾，特别耗时间。
所以做了 Shellink：把「多级跳板之后的那台机器」收成一个稳定会话，让 AI Agent （和人）能直接在上面执行命令、传文件、看历史。
仓库： https://github.com/jie123108/Shellink
中文文档： https://github.com/jie123108/Shellink/blob/main/README.zh-CN.md
Web UI 实时会话（经跳板到达目标机）：
----------------------
Shellink 是什么
一句话：面向 AI Agent 和人类的会话中间件（ session middleware ）。
本地跑一个 daemon ，持有 SSH / 本地 PTY 会话；外面用统一的 CLI （也有 TUI 、Web UI 、HTTP/WebSocket ）去操作这些会话。
不是又一个 SSH GUI ，重点是：
● 会话状态可查询（ CONNECTING / WAITING_INPUT / IDLE …），方便 Agent 决策下一步
● CLI 有稳定的
● 需要人插手时可以切到 MANUAL 模式（比如输入 OTP ）
会话 Dashboard （活跃会话列表）：
----------------------
主要能力
1. 多级跳板 / 复杂登录
很多环境不是一次
说明一下边界：Shellink 本身不负责自动登录。多级跳转、堡垒机菜单、OTP 等交互认证，建议用
2. 跨跳板文件传输
上传/下载走已有的 PTY ，不额外要求 SFTP 。复杂跳板链路上也能把日志拉下来、把脚本推上去——正好对应「拷日志到本地再问 Agent 」那个痛点。
3. 远程编辑
4. 审计与人机协同
会话输入输出可留历史，方便回看 Agent 干了啥；敏感步骤可以人工接管。
5. 给 Agent 准备的 skill
仓库里有
安装二进制（ macOS / Linux ）：
或让 AI 助手直接按文档装：
CLI/TUI 会话视图：
Web UI 默认在本地：
----------------------
安全提醒（重要）
●
● 让 Agent 直连生产有真实风险：建议只读/排查类操作，或先指向非生产环境
----------------------
求试用 & 反馈
欢迎有跳板机 / 堡垒机场景的同学试试。登录脚本本身用 expect 就行；我更想听的是登录之后这块好不好用：
1. 会话与操作：状态是否清晰、命令执行是否稳、跨跳板传文件/远程编辑有没有坑
2. 和 Agent 一起用：接 Cursor / Claude Code 等时，CLI/
3. 人机协同：OTP 等需要人插手时，MANUAL 模式、审计历史是否够用
有问题直接回帖或去 GitHub 提 issue 都行，谢谢。
为什么做这个
最近工作里，写代码、改文档、点网页这类事，基本已经可以交给 AI Agent 了。但一碰到服务器操作就卡住：
公司一般都有跳板机 / 堡垒机，Agent 没法直接连后面的机器，自动化就断了。
更头疼的是排查问题：经常得先登录服务器，把线上日志拷到本地，丢给 Agent 分析，再拿着它给的步骤回到线上执行。来回倒腾，特别耗时间。
所以做了 Shellink：把「多级跳板之后的那台机器」收成一个稳定会话，让 AI Agent （和人）能直接在上面执行命令、传文件、看历史。
仓库： https://github.com/jie123108/Shellink
中文文档： https://github.com/jie123108/Shellink/blob/main/README.zh-CN.md
Web UI 实时会话（经跳板到达目标机）：
----------------------
Shellink 是什么
一句话：面向 AI Agent 和人类的会话中间件（ session middleware ）。
本地跑一个 daemon ，持有 SSH / 本地 PTY 会话；外面用统一的 CLI （也有 TUI 、Web UI 、HTTP/WebSocket ）去操作这些会话。
不是又一个 SSH GUI ，重点是：
● 会话状态可查询（ CONNECTING / WAITING_INPUT / IDLE …），方便 Agent 决策下一步
● CLI 有稳定的
--json 输出，适合脚本和 Agent 调用● 需要人插手时可以切到 MANUAL 模式（比如输入 OTP ）
会话 Dashboard （活跃会话列表）：
----------------------
主要能力
1. 多级跳板 / 复杂登录
很多环境不是一次
ssh user@host 就结束，而是菜单、OTP 、多跳。说明一下边界：Shellink 本身不负责自动登录。多级跳转、堡垒机菜单、OTP 等交互认证，建议用
command 类型的 profile 挂 expect 脚本处理；简单场景也可以用 sshpass（仅密码）或 ssh 的 ProxyJump / ProxyCommand。Shellink 负责把登录完成后的会话管起来（执行命令、传文件、状态、审计）。2. 跨跳板文件传输
上传/下载走已有的 PTY ，不额外要求 SFTP 。复杂跳板链路上也能把日志拉下来、把脚本推上去——正好对应「拷日志到本地再问 Agent 」那个痛点。
3. 远程编辑
shellink session edit 做精确替换，适合改配置一类操作。4. 审计与人机协同
会话输入输出可留历史，方便回看 Agent 干了啥；敏感步骤可以人工接管。
5. 给 Agent 准备的 skill
仓库里有
shellink-cli skill ，Agent 按 CLI 接口操作即可，不必自己实现 SSH/跳板逻辑。安装二进制（ macOS / Linux ）：
curl -fsSL https://raw.githubusercontent.com/jie123108/Shellink/main/install.sh -o /tmp/shellink-install.sh
cat /tmp/shellink-install.sh
sh /tmp/shellink-install.sh
或让 AI 助手直接按文档装：
请帮我安装 Shellink 及其 skills ，参考这份文档： https://raw.githubusercontent.com/jie123108/Shellink/main/AGENTS_INSTALL.md装好后：
shellink cli # TUI ，会按需拉起 daemon
shellink agent-doc # 给 Agent 看的接口说明
CLI/TUI 会话视图：
Web UI 默认在本地：
http://127.0.0.1:7070/shellink/ui/----------------------
安全提醒（重要）
●
command 类型的 profile 会以 daemon 进程用户身份执行你配置的命令，请只在受信任环境跑，并保护好 SHELLINK_TOKEN● 让 Agent 直连生产有真实风险：建议只读/排查类操作，或先指向非生产环境
----------------------
求试用 & 反馈
欢迎有跳板机 / 堡垒机场景的同学试试。登录脚本本身用 expect 就行；我更想听的是登录之后这块好不好用：
1. 会话与操作：状态是否清晰、命令执行是否稳、跨跳板传文件/远程编辑有没有坑
2. 和 Agent 一起用：接 Cursor / Claude Code 等时，CLI/
--json/skill 哪里别扭、缺什么3. 人机协同：OTP 等需要人插手时，MANUAL 模式、审计历史是否够用
有问题直接回帖或去 GitHub 提 issue 都行，谢谢。
[问与答] 3d 打印进阶玩法咨询
目前 p2s, 网站上的模型也都打了遍，大概打了几百个各种的生活用品； 现在有了新的需求，想自己扫描 3d 模型，打印； 请问有啥工具可以用来 3d 扫描的，苹果手机的 lidar 似乎精度不够？
目前 p2s, 网站上的模型也都打了遍，大概打了几百个各种的生活用品； 现在有了新的需求，想自己扫描 3d 模型，打印； 请问有啥工具可以用来 3d 扫描的，苹果手机的 lidar 似乎精度不够？
[分享创造] 做了一个文档解析与记忆工具，专门辅助给传统行业做 AI 落地的老哥
现在 AI+的工作还挺常见的，就像大佬们说的，“所有行业的产品可能都会用 AI 重新做一遍”。最常见的就是各种 agent ，说要用 AI 赋能传统行业啥的，代替人类专家去处理海量的复杂资料、进行深度分析并做出决策。
举个例子，金融行业的“智能审计与尽调 Agent”。
过去，银行或投资机构想要给一家企业贷款或投资，需要人类审计师去读几十份、每份几百页的招股书和财务报表。现在虽然有了 AI ，但把文件一股脑全丢给它是不现实的，且不说烧 token 的问题，这些文档里有无数的跨行、跨列单元格表格，普通工具一拉，表格数据全串行了。如果 AI 把“第一季度利润”和“第二季度支出”的信息碎在一块，那得出的财务分析就完蛋了。
所以，现在要真想开发出一个能干活，还确保正确率的 agent ，就需要一个专业的、AI-native 的解析工具，把复杂的表结构和章节层级完整还原出来。我做的工具 Knowhere 就是干这个的： https://knowhereto.ai/?utm_source=v2ex
它能把复杂量大的文件，解析成按章节、按次序分类的 JSON ，尤其是令 AI 头大的 PDF 、PPT 、图片、表格等格式文件。其次它会把解析好的文档进行结构化，重建文档的标题树，从一级标题到二级、三级，每一块文本都会被挂载到对应的章节路径上。表格和图片也不是单独抽出来当独立附件，而是和内联的上下文文本牢牢绑定，确保 AI 能看到“这张表格是属于哪一段话”。
最后它还会构建一个包含章节树、文本块、摘要、图像描述以及跨文档链接的轻量级记忆图谱，方便 AI 检索和查找。
装了这个插件之后，agent 的表现会比使用原始文档的时候“正常”很多，我们亲测准确度是有提升 25%以上。
之后再给审计 Agent 分配财务分析任务的时候，它就会自己调用 Knowhere 进行对账了，如果它发现某些数据对不上，还能顺着 Knowhere 提供的记忆图谱返回去重新查验证据，确保交出来的审计报告，每个数据都是可追溯、可查验的。
当然，不只是做金融行业的 agent ，像法律、医疗、企业内网等历史问题比较多，资料比较复杂的场景的 AI 应用，都可以用得上。无论历史文档有多么稀奇古怪、排版脏乱差，Knowhere 都能帮 AI 解析得井井有条，在节省 token 的同时，帮 AI 把活干好。
如果有在做 agent 开发的老哥，欢迎使用，我们现在已经开源了，大家多多评论反馈哈，我会及时改进的： https://github.com/Ontos-AI/knowhere
现在 AI+的工作还挺常见的，就像大佬们说的，“所有行业的产品可能都会用 AI 重新做一遍”。最常见的就是各种 agent ，说要用 AI 赋能传统行业啥的，代替人类专家去处理海量的复杂资料、进行深度分析并做出决策。
举个例子，金融行业的“智能审计与尽调 Agent”。
过去，银行或投资机构想要给一家企业贷款或投资，需要人类审计师去读几十份、每份几百页的招股书和财务报表。现在虽然有了 AI ，但把文件一股脑全丢给它是不现实的，且不说烧 token 的问题，这些文档里有无数的跨行、跨列单元格表格，普通工具一拉，表格数据全串行了。如果 AI 把“第一季度利润”和“第二季度支出”的信息碎在一块，那得出的财务分析就完蛋了。
所以，现在要真想开发出一个能干活，还确保正确率的 agent ，就需要一个专业的、AI-native 的解析工具，把复杂的表结构和章节层级完整还原出来。我做的工具 Knowhere 就是干这个的： https://knowhereto.ai/?utm_source=v2ex
它能把复杂量大的文件，解析成按章节、按次序分类的 JSON ，尤其是令 AI 头大的 PDF 、PPT 、图片、表格等格式文件。其次它会把解析好的文档进行结构化，重建文档的标题树，从一级标题到二级、三级，每一块文本都会被挂载到对应的章节路径上。表格和图片也不是单独抽出来当独立附件，而是和内联的上下文文本牢牢绑定，确保 AI 能看到“这张表格是属于哪一段话”。
最后它还会构建一个包含章节树、文本块、摘要、图像描述以及跨文档链接的轻量级记忆图谱，方便 AI 检索和查找。
装了这个插件之后，agent 的表现会比使用原始文档的时候“正常”很多，我们亲测准确度是有提升 25%以上。
之后再给审计 Agent 分配财务分析任务的时候，它就会自己调用 Knowhere 进行对账了，如果它发现某些数据对不上，还能顺着 Knowhere 提供的记忆图谱返回去重新查验证据，确保交出来的审计报告，每个数据都是可追溯、可查验的。
当然，不只是做金融行业的 agent ，像法律、医疗、企业内网等历史问题比较多，资料比较复杂的场景的 AI 应用，都可以用得上。无论历史文档有多么稀奇古怪、排版脏乱差，Knowhere 都能帮 AI 解析得井井有条，在节省 token 的同时，帮 AI 把活干好。
如果有在做 agent 开发的老哥，欢迎使用，我们现在已经开源了，大家多多评论反馈哈，我会及时改进的： https://github.com/Ontos-AI/knowhere
[程序员] 为什么“节省 90% Token”不等于 Coding Agent 总成本降低 90%
最近把几个“Token 节省”插件放到完整仓库任务里做了一个小型配对实验，结论和常见宣传口径差异很大。
任务不是单轮代码补全，而是把 Rust eza 仓库重写成行为兼容的 Python 实现，并通过 52 项 harness 检查。模型、推理档位和 Codex CLI 版本保持一致，每组目前只有 2 次运行：
无插件：78.85% 通过率，平均 666 万 Token ，约 5.28 美元，62.5 轮
Ponytail：通过率 80.77%，Token -7.56%，成本 -8.87%，但耗时 +13.51%
RTK：通过率 76.92%，Token +13.20%，成本 +7.18%，轮次 +44%
更值得注意的是组内波动：无插件两次运行的成本极差/均值是 43.25%，Ponytail 是 51.69%，RTK 是 30.78%。所以 n=2 不能证明插件有因果效果；所谓 8.87% 节省本身还小于自然运行波动。
另一个 140 次 Codex 运行的数据里，缓存输入占总 Token 的 96.46%、总成本的 63.91%；模型输出只占 Token 的 0.38%。因此压缩某段输出 90%，并不能直接外推成完整任务成本降低 90%。RTK 可识别的 shell 返回内容只占全部任务 Token 的 0.1618%，即使完美压缩 90%，直接成本上限仍不到 1%。
我觉得更合理的基准单位应该是“每个成功完成任务的总成本”，同时至少报告重复运行方差、轮次、耗时和最终验证结果，而不是只报局部压缩率。
完整方法、逐次数据和限制：
https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea
https://github.com/Tura-AI/tura
披露：我是 Tura 的维护者，也是这篇分析的作者。这次发的是 benchmark/方法讨论，不是产品发布。也想听听大家认为这类工具最合理的评估分母应该是什么。
最近把几个“Token 节省”插件放到完整仓库任务里做了一个小型配对实验，结论和常见宣传口径差异很大。
任务不是单轮代码补全，而是把 Rust eza 仓库重写成行为兼容的 Python 实现，并通过 52 项 harness 检查。模型、推理档位和 Codex CLI 版本保持一致，每组目前只有 2 次运行：
无插件：78.85% 通过率，平均 666 万 Token ，约 5.28 美元，62.5 轮
Ponytail：通过率 80.77%，Token -7.56%，成本 -8.87%，但耗时 +13.51%
RTK：通过率 76.92%，Token +13.20%，成本 +7.18%，轮次 +44%
更值得注意的是组内波动：无插件两次运行的成本极差/均值是 43.25%，Ponytail 是 51.69%，RTK 是 30.78%。所以 n=2 不能证明插件有因果效果；所谓 8.87% 节省本身还小于自然运行波动。
另一个 140 次 Codex 运行的数据里，缓存输入占总 Token 的 96.46%、总成本的 63.91%；模型输出只占 Token 的 0.38%。因此压缩某段输出 90%，并不能直接外推成完整任务成本降低 90%。RTK 可识别的 shell 返回内容只占全部任务 Token 的 0.1618%，即使完美压缩 90%，直接成本上限仍不到 1%。
我觉得更合理的基准单位应该是“每个成功完成任务的总成本”，同时至少报告重复运行方差、轮次、耗时和最终验证结果，而不是只报局部压缩率。
完整方法、逐次数据和限制：
https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea
https://github.com/Tura-AI/tura
披露：我是 Tura 的维护者，也是这篇分析的作者。这次发的是 benchmark/方法讨论，不是产品发布。也想听听大家认为这类工具最合理的评估分母应该是什么。
[Claude] 一年多没用过 Claude，当初用的时候仅用过 mac 客户端和网页，号被封了
上次用还是 DeepSeek R1 刚出的时期，没用过 Claude Code ，账号没付过费
绑的是英国的 giffgaff 手机号
严重怀疑这家公司会在网络上搜索你的用户名前缀进行身份识别（也可以说是盒），或者对同一个节点的注册账号采取连坐机制，或者是跟谷歌有信息共享（港区谷歌账号）
只是感觉有点搞笑，连发两条消息，搞得像是多稀罕一样
希望能够给大伙分析风控机制提供点信息
上次用还是 DeepSeek R1 刚出的时期，没用过 Claude Code ，账号没付过费
绑的是英国的 giffgaff 手机号
严重怀疑这家公司会在网络上搜索你的用户名前缀进行身份识别（也可以说是盒），或者对同一个节点的注册账号采取连坐机制，或者是跟谷歌有信息共享（港区谷歌账号）
只是感觉有点搞笑，连发两条消息，搞得像是多稀罕一样
希望能够给大伙分析风控机制提供点信息
[分享创造] 做了一个专注电商场景的 AI 工具导航站
大家好，分享一个最近做的导航小站：FlowCay： https://flowcay.com
定位很简单：只收电商相关的 AI 工具，覆盖选品、内容创作、图片/视频、客服、SEO 、广告投放、数据分析、自动化等场景，面向跨境、外贸和国内卖家。
目前还是刚起步，内容还比较少，如果你自己做了电商相关的 AI 工具，或者日常用着觉得特别好用的，欢迎提交过来，会审核后收录。
提交入口： https://flowcay.com/submit
欢迎大佬们提意见～
大家好，分享一个最近做的导航小站：FlowCay： https://flowcay.com
定位很简单：只收电商相关的 AI 工具，覆盖选品、内容创作、图片/视频、客服、SEO 、广告投放、数据分析、自动化等场景，面向跨境、外贸和国内卖家。
目前还是刚起步，内容还比较少，如果你自己做了电商相关的 AI 工具，或者日常用着觉得特别好用的，欢迎提交过来，会审核后收录。
提交入口： https://flowcay.com/submit
欢迎大佬们提意见～
[分享发现] 分享一个小创意，用 Agent 处理工作交接的问题
工作久了，真是什么样的工作交接都能见到。以前光景好，我遇到过不少很 nice 的大佬，交接文档写得超级全，让人看了就能感觉出工作能力很强，拿到也能直接上手。
但近来行情不好，奇葩事件也就越来越多了。有些粗糙的，最后往往就收到一个网盘链接，里面是几十份文档、几个 Notion 页面，文件名看起来还很像：「最终版」「最终确认版」「最新最终版」。
一问呢就说资料都在，可接手的人肯定一脸懵逼：平时到底看哪份？
现在的情况就更麻烦了。很多人每天都在用自己的 AI 助手。一个 Agent 跟着项目跑了大半年，读过 PRD 、客户记录、研究报告，也处理过一堆零碎问题。人一走，账号一关，这...这就没了？不应该吧？
因为我们不是大厂，没那么完备的细则，所以工作交接还是很重要的。但直接把 AI 账号交给接手人？我是不太建议。
一来，聊天里可能混着私人对话、个人习惯、客户信息，还有各种本地缓存。接手一个项目，没道理连前任一整年的聊天记录一起接管。
二来，更别说聊天记录还会过期。三个月前问过「退款政策按哪版执行」，当时的回答也许没问题，今天再翻出来，未必还能用。
所以这个新兴的 AI 助手，又该怎么交接呢？
我的办法是这样的：先把公司真正需要留下的东西单独拿出来。
正式 PRD 、合同、产品规则、研究报告、决策记录——这些归公司维护。个人提示词、聊天历史、说话习惯——这些留在原来的账号里。
至少，先把「工作资料」和「个人使用痕迹」拆开。
然后就是工作资料的处理问题了。
如果只是把它们打包进网盘，那兜兜转转还是会回到第一步：「文件都给你了。」接手人还是得自己找当前版本，自己对表格口径。想用 AI 帮忙查，又得把文件重新传一遍。
一点也不方便。
我估计是没几个人有这个耐心重新看的，普遍都是扔进网盘以后就束之高阁，然后开始自己倒腾摸索了，重复造轮子这一步少不了。
最后是人和工具都换了，资料却还在原地，谁也用不顺，交接了跟没交接一样。
所以这里，我会借助一个常用的文档解析和记忆工具 Knowhere ，来解析这些资料。Knowhere 是复杂、脏乱文档和 AI Agent 之间的 Memory Layer ，把 PDF 、Word 、Excel 、图片丢进去，它会把文档拆成章节、表格、引用，整理成 AI 能查、能追问、还能带回原文出处的资料，确保 AI 真能读懂这些文件；
在解析时，Knowhere 会用树形结构算法恢复文档里的章节关系，重建文档层级，同时对图片和表格做 OCR 和结构化处理，保留来源路径，形成可跨文档导航的记忆图谱。
对交接来说，这很关键。
正式资料可以沉淀在公司维护的文档库里，文件解析之后，章节、表格、引用都会留着，不跟着某个人的账号走，也不被某个工具绑住。后面换人、换工具，照样能查，查的还是同一批资料。
现在，Knowhere 还加上了 MCP 功能，方便外部工具的调用。
比如前任习惯用 TRAE ，接手人习惯用 Codex 。两边连的是同一个知识空间，查到的还是那批 PRD 、合同和研究报告。AI 回答时，还能把对应章节和原文一并带回来。
接手人不需要登录前任的账号，也不用把几十份文件重新喂一遍。换成 Cursor 、Codex ，或其他支持 MCP 的客户端，资料都还在公司这边。
只需要一句简单的提问，比方说：「客户退款按哪份政策执行？」 Agent 就可以把当前文件、对应章节和原文一起返回了。哪份资料还没入库，它也能马上看出来，再回去补。
Knowhere 能把解析后的项目文档，提供给不同 AI 工具查询。
当然，Knowhere 不会把前任脑子里的判断自动保存下来。没整理、没入库的临时想法，人走以后照样会丢。
所以交接单也得跟着改一改。除了网盘链接，最好再写清楚：
- 哪些资料已经进了公司知识空间
- 当前以哪一版为准
- 后面谁负责更新
- 接手人能看哪些内容
这样交完之后，接手人可以直接在自己的 AI 工具里查同一批资料，不必再从「最新最终版」开始猜了。
感兴趣的可以尝试一下：
- 官网体验： https://knowhereto.ai/?utm_source=v2ex
- 开源仓库： https://github.com/Ontos-AI/knowhere
- MCP 文档： https://docs.knowhereto.ai/mcp?utm_source=v2ex
工作久了，真是什么样的工作交接都能见到。以前光景好，我遇到过不少很 nice 的大佬，交接文档写得超级全，让人看了就能感觉出工作能力很强，拿到也能直接上手。
但近来行情不好，奇葩事件也就越来越多了。有些粗糙的，最后往往就收到一个网盘链接，里面是几十份文档、几个 Notion 页面，文件名看起来还很像：「最终版」「最终确认版」「最新最终版」。
一问呢就说资料都在，可接手的人肯定一脸懵逼：平时到底看哪份？
现在的情况就更麻烦了。很多人每天都在用自己的 AI 助手。一个 Agent 跟着项目跑了大半年，读过 PRD 、客户记录、研究报告，也处理过一堆零碎问题。人一走，账号一关，这...这就没了？不应该吧？
因为我们不是大厂，没那么完备的细则，所以工作交接还是很重要的。但直接把 AI 账号交给接手人？我是不太建议。
一来，聊天里可能混着私人对话、个人习惯、客户信息，还有各种本地缓存。接手一个项目，没道理连前任一整年的聊天记录一起接管。
二来，更别说聊天记录还会过期。三个月前问过「退款政策按哪版执行」，当时的回答也许没问题，今天再翻出来，未必还能用。
所以这个新兴的 AI 助手，又该怎么交接呢？
我的办法是这样的：先把公司真正需要留下的东西单独拿出来。
正式 PRD 、合同、产品规则、研究报告、决策记录——这些归公司维护。个人提示词、聊天历史、说话习惯——这些留在原来的账号里。
至少，先把「工作资料」和「个人使用痕迹」拆开。
然后就是工作资料的处理问题了。
如果只是把它们打包进网盘，那兜兜转转还是会回到第一步：「文件都给你了。」接手人还是得自己找当前版本，自己对表格口径。想用 AI 帮忙查，又得把文件重新传一遍。
一点也不方便。
我估计是没几个人有这个耐心重新看的，普遍都是扔进网盘以后就束之高阁，然后开始自己倒腾摸索了，重复造轮子这一步少不了。
最后是人和工具都换了，资料却还在原地，谁也用不顺，交接了跟没交接一样。
所以这里，我会借助一个常用的文档解析和记忆工具 Knowhere ，来解析这些资料。Knowhere 是复杂、脏乱文档和 AI Agent 之间的 Memory Layer ，把 PDF 、Word 、Excel 、图片丢进去，它会把文档拆成章节、表格、引用，整理成 AI 能查、能追问、还能带回原文出处的资料，确保 AI 真能读懂这些文件；
在解析时，Knowhere 会用树形结构算法恢复文档里的章节关系，重建文档层级，同时对图片和表格做 OCR 和结构化处理，保留来源路径，形成可跨文档导航的记忆图谱。
对交接来说，这很关键。
正式资料可以沉淀在公司维护的文档库里，文件解析之后，章节、表格、引用都会留着，不跟着某个人的账号走，也不被某个工具绑住。后面换人、换工具，照样能查，查的还是同一批资料。
现在，Knowhere 还加上了 MCP 功能，方便外部工具的调用。
比如前任习惯用 TRAE ，接手人习惯用 Codex 。两边连的是同一个知识空间，查到的还是那批 PRD 、合同和研究报告。AI 回答时，还能把对应章节和原文一并带回来。
接手人不需要登录前任的账号，也不用把几十份文件重新喂一遍。换成 Cursor 、Codex ，或其他支持 MCP 的客户端，资料都还在公司这边。
只需要一句简单的提问，比方说：「客户退款按哪份政策执行？」 Agent 就可以把当前文件、对应章节和原文一起返回了。哪份资料还没入库，它也能马上看出来，再回去补。
Knowhere 能把解析后的项目文档，提供给不同 AI 工具查询。
当然，Knowhere 不会把前任脑子里的判断自动保存下来。没整理、没入库的临时想法，人走以后照样会丢。
所以交接单也得跟着改一改。除了网盘链接，最好再写清楚：
- 哪些资料已经进了公司知识空间
- 当前以哪一版为准
- 后面谁负责更新
- 接手人能看哪些内容
这样交完之后，接手人可以直接在自己的 AI 工具里查同一批资料，不必再从「最新最终版」开始猜了。
感兴趣的可以尝试一下：
- 官网体验： https://knowhereto.ai/?utm_source=v2ex
- 开源仓库： https://github.com/Ontos-AI/knowhere
- MCP 文档： https://docs.knowhereto.ai/mcp?utm_source=v2ex
[智能家电] 买了套二手房,想改智能开关控三色灯求方案
客厅餐厅卧室的灯都是 3 色温的, 开关一次一个色温, 不知道怎么弄了
如果安装智能开关,还是得手动按,才能变色
我现在想实现得是,白天开关能亮冷色,夜间暖色, 当然语音控制或者 APP 控制,不知道能不能实现
后面要加入 HOMEASSISTANT 到 homekit
客厅餐厅卧室的灯都是 3 色温的, 开关一次一个色温, 不知道怎么弄了
如果安装智能开关,还是得手动按,才能变色
我现在想实现得是,白天开关能亮冷色,夜间暖色, 当然语音控制或者 APP 控制,不知道能不能实现
后面要加入 HOMEASSISTANT 到 homekit
[程序员] 记燃油车油耗有什么好用的软件或者小程序么？
之前使用腾讯出行的加油功能，买完单之后只需要填一个车上显示的总里程，就可以自动记录加油信息了
最近一次用，突然提示记油耗功能下线了，历史数据也没有了
现在还有什么好用的记油耗的软件或者小程序么？
之前使用腾讯出行的加油功能，买完单之后只需要填一个车上显示的总里程，就可以自动记录加油信息了
最近一次用，突然提示记油耗功能下线了，历史数据也没有了
现在还有什么好用的记油耗的软件或者小程序么？
[宽带症候群] tcptun 现在支持 native + raw + reality-quic 了
自动生成 server.json 和 client.json 配置:
android 客户端也支持了
项目地址： https://tcptun.com
自动生成 server.json 和 client.json 配置:
# 生成 native + raw + reality-quic 配置对
$ tcptun config native --quic --server proxy.example.com --port 9443
android 客户端也支持了
项目地址： https://tcptun.com
[程序员] 实测 GPT-5.6 Sol 的 High/Max：修 bug 未必值得上 Max，重写/迁移可能值得
先声明：我是 [Tura]( https://github.com/Tura-AI/tura) 的维护者。这不是独立评测；完整方法、图表和公开产物在文末链接。想请大家重点挑一挑下面这个“按任务形态路由”的结论有没有遗漏。
我把 DeepSWE v1.1 的记录和一次 eza （ Rust → Python 、52 项检查）的行为兼容重写放在一起看。结论不是“Max 总是更强”，而是 Max 多买到了搜索、回滚、再试和 agent 回合；这些回合有没有价值，取决于任务剩下多少不确定性。
| 任务形态 | High | Max | 通过率变化 | 成本 |
| --- | ---: | ---: | ---: | ---: |
| 范围明确的修复（ DeepSWE ，7 个） | 64.3% | 57.1% | **-7.1 个百分点** | 2.53x |
| 功能实现（ DeepSWE ，95 个） | 70.2% | 74.6% | **+4.4 个百分点** | 2.43x |
| 仓库重写（ eza ，3 个 harness ） | 78.8–89.4% | 92.3–94.2% | **+4.8–13.5 个百分点** | 2.27–3.27x |
113 个 DeepSWE 任务的总体平均是：High 69.4%、每任务 $3.47 ； Max 72.7%、每任务 $8.39 。也就是 **+3.3 个百分点，成本 2.42 倍**，输出 token 2.11 倍、输入 2.91 倍、时间 1.90 倍、步骤 1.66 倍。
所以我现在倾向的操作规则是：
1. 已经有 failing test 、定位范围较小的 bug ，先用 High ； High 失败且定位仍不确定再升级。
2. 常规功能实现也是 High 起步，除非一次失败的代价足以覆盖约 2.4 倍成本。
3. 大范围重写或迁移，Max 往往更有意义，因为兼容性、构建、测试和架构路径都还要探索。
4. Greenfield 目前只有“可能更适合 Max”的判断，没有配对的 High/Max 数据，别把它写成已证实结论。
需要强调两个边界：DeepSWE 的 7 个修复任务不足以证明“Max 会让修 bug 变差”； eza 的 High 是每个 harness 两次的均值，而 Max 是一次选定运行。数字适合做路由假设，不适合做万能默认值。
完整分析（ 19 张表和原始图表）： https://turaai.net/blog.html#is-gpt-5-6-sol-max-worth-it
复现数据： https://github.com/Tura-AI/benchmark/tree/main/blog_data/eza-replication-gpt56-max-20260717
如果大家有更合适的任务分桶、成本/通过率指标，或者认为这里的 DeepSWE 划分不够机械化，欢迎直接指出。更希望讨论“什么时候应该升级 effort”，而不是只比较某个模式的单点分数。
先声明：我是 [Tura]( https://github.com/Tura-AI/tura) 的维护者。这不是独立评测；完整方法、图表和公开产物在文末链接。想请大家重点挑一挑下面这个“按任务形态路由”的结论有没有遗漏。
我把 DeepSWE v1.1 的记录和一次 eza （ Rust → Python 、52 项检查）的行为兼容重写放在一起看。结论不是“Max 总是更强”，而是 Max 多买到了搜索、回滚、再试和 agent 回合；这些回合有没有价值，取决于任务剩下多少不确定性。
| 任务形态 | High | Max | 通过率变化 | 成本 |
| --- | ---: | ---: | ---: | ---: |
| 范围明确的修复（ DeepSWE ，7 个） | 64.3% | 57.1% | **-7.1 个百分点** | 2.53x |
| 功能实现（ DeepSWE ，95 个） | 70.2% | 74.6% | **+4.4 个百分点** | 2.43x |
| 仓库重写（ eza ，3 个 harness ） | 78.8–89.4% | 92.3–94.2% | **+4.8–13.5 个百分点** | 2.27–3.27x |
113 个 DeepSWE 任务的总体平均是：High 69.4%、每任务 $3.47 ； Max 72.7%、每任务 $8.39 。也就是 **+3.3 个百分点，成本 2.42 倍**，输出 token 2.11 倍、输入 2.91 倍、时间 1.90 倍、步骤 1.66 倍。
所以我现在倾向的操作规则是：
1. 已经有 failing test 、定位范围较小的 bug ，先用 High ； High 失败且定位仍不确定再升级。
2. 常规功能实现也是 High 起步，除非一次失败的代价足以覆盖约 2.4 倍成本。
3. 大范围重写或迁移，Max 往往更有意义，因为兼容性、构建、测试和架构路径都还要探索。
4. Greenfield 目前只有“可能更适合 Max”的判断，没有配对的 High/Max 数据，别把它写成已证实结论。
需要强调两个边界：DeepSWE 的 7 个修复任务不足以证明“Max 会让修 bug 变差”； eza 的 High 是每个 harness 两次的均值，而 Max 是一次选定运行。数字适合做路由假设，不适合做万能默认值。
完整分析（ 19 张表和原始图表）： https://turaai.net/blog.html#is-gpt-5-6-sol-max-worth-it
复现数据： https://github.com/Tura-AI/benchmark/tree/main/blog_data/eza-replication-gpt56-max-20260717
如果大家有更合适的任务分桶、成本/通过率指标，或者认为这里的 DeepSWE 划分不够机械化，欢迎直接指出。更希望讨论“什么时候应该升级 effort”，而不是只比较某个模式的单点分数。