[程序员] OpenPencil v0.8.0:全面 Rust 化，跨平台稳定性提升；设计能力大幅提升，针对 GLM、DS 等模型特别优化

久等了，经过 2 个月苦战，OpenPencil 的 v0.8.0 终于来了
这次带来全新的体验，彻底解决一些跨平台问题，尤其针对国产模型做了很多特别优化，提升了设计审美的底线！

v0.8.1 地址： https://github.com/ZSeven-W/openpencil/releases/tag/v0.8.1

欢迎兄弟们继续体验、继续拍砖～

[分享发现] [自荐开源] vlaina - 没错就是那个 Catime 作者的新作笔记软件

vlaina.com https://github.com/vladelaina/vlaina

没错没错，你没看错，就是那个写纯 C 的Catime的作者的新作，也是 Catime 半年迟迟没有发布一直在做的事情

提前猜个你会好奇的点： 这个使用什么做的？原生？Electron,没错，既不是原生，也不是 tauri ，而是大家都在抱怨体积大的 Electron ，相信你一定好奇为啥我这把 Catime 之前做到 200kb 的原生开发者为啥不选 tauri 而是 Electron 吧，答案就留到文章的末尾吧 😏

这个是个什么？

一. 传统的 markdown 编辑器，这块也是打磨最多的一个地方

这块是对着友商打磨的，底层是独立从milkdown(可以理解为是 Typora 的开源实现)分叉出来开始打磨的，然后添加大家一些常用的功能

1. 选中文本之后的工具栏，可以实时预览效果 😋

2. / 调出快捷命令 - 这个块是独立实现的（哈哈哈哈，这块折磨了好久 🤯）

3. 右侧 ai 对话侧边栏，可以 @选择当前的文件总结，还可以选中内容拖动放到笔记中，非常适合让 ai 总结然后手动维护，这里你可能会问，为啥不是让 ai 直接修改原文呢？我的想法是笔记是一个有私人意义的地方，你不会希望自己所有的笔记全是 ai 的，然后下回再看的时候还需要再去理解一次

4. 左侧侧边栏

右键左侧侧边栏

大纲

----------------------

双链

白板，这块做棒的是支持数位板，之前买数位板是为了学习板绘，结果一直都在吃灰，没想到居然在这里用上了，哈哈哈哈哈哈哈 🥰

ai 对话部分，基本好用的点都给支持上了

所以为啥不是 tauri

很简单，vlad 用的是 Arch ，如果你有尝试过就会发现......(投降投降)

----------------------

如果喜欢的话点个 star 吧:>

https://github.com/vladelaina/vlaina

当前这也是第一次推广，打磨的也有很快存在不到位的地方，哈哈哈哈哈哈哈但是感觉还是比Catime第一版要好，那个时候 6000 行所有的代码都写到一个 main.c 中

[程序员] 毕业数年，有和我一样学不下去的同行么

因为 AI 的缘故现在有很多现成的聚合网站做教程，知识都触手可得。 但即便减少了个人检索知识的时间，看书依然是个很苦闷的过程，看不懂看不透，代码放那儿了也看不进去。 已经怀疑自己适不适合做程序员这一行了，人在没有天赋的事情上投资，不仅仅是时间成本，还有耗费的精力和情绪。 每每想到有那么几个天纵奇才的人物就觉得自己是否应该换一条赛道----譬如王若度、王永强、詹恩贵、庞众望。强的人我认为就是文曲星下凡，学啥会啥。太糟心了

[OpenAI] 网站才开发到一半， AI 额度就用完了，只能先暂停一下 😅

网站才开发到一半，AI 额度就用完了，只能先暂停一下 😅

半成品放在这里：Magical Meow Meow Cartoon

等补充额度后再继续完善。

[程序员] Vibe Coding 副业四个月：成本超出收益，要放弃吗？

楼主本身是一名程序，Vibe Coding 流行后，我一直觉得，开发的技术门槛会越来越低，每个程序员或许都应该做一个自己的独立项目，放到市场上试一次水。

于是从今年 3 月开始，用业余时间做了一个 A 股新闻事件分析工具“新闻雷达”。

四个月以后，我最大的感受是：技术反而是最容易解决的部分，真正困难的是运营、推广和收费。

做了一个复盘。

项目做了什么

我平时会关注财经新闻。新闻本身很多，费时间的是判断它影响哪些行业和公司，这种关联是否有真实业务依据，以及类似事件过去发生后市场如何表现。

新闻雷达会抓取新闻、过滤噪音，通过 AI 和本地股票及公告数据分析相关公司，再记录事件后的市场表现。3 月 24 日开始开发，5 月 4 日上线第一版。在 V2EX 发了帖子： https://www.v2ex.com/t/1210161

上线后我又不断增加历史事件、自选股、概念、投研和会员等功能。工程越做越完整，功能越来越多。现在回头看，我可能是犯了一个错误：用持续开发代替产品验证。

四个月数据

● 注册用户 384 人；
● 当前会员用户 29 人（含赠送）
● 累计会员收入 1600 元；
● 流量最近日天约 1000 访客
● 最近 30 天流量如图

https://i.imgur.com/cmQmY69.png

成本侧:

● 服务器一年 4000 元；
● DeepSeek Flash 累计费用接近 2000 元，近期约 100 元/天；
● 股票数据相关 API 累计约 2000 元。

想法

如果看成本和收入，项目目前没有跑通：收入没有覆盖成本，近期模型费用推算每个月至少要 3000 ，但每个月收入都达不到。

但是另一方面，项目并不是完全没有反馈：已有 384 位注册用户，出现了真实付费，也积累了约 4.1 万条事件及后验数据。

我感觉目前还是运营推广的不太够？尝试过在很多股票社区推广，效果都不好，统计了一下来源网址，Twitter/X 和 V2EX 的流量是最多的

我目前的动作是停止了功能的更新，开始做用户的增长，但是这块确实不太擅长，想听听大家的建议，下一步应该怎么做？

项目地址：新闻雷达

[程序员] claude 被杀

除了 gpt ，第二个用来备份的工具选啥

kimi code plan

cursor

glm code plan(国际版)

[分享创造] 假到位

写了一篇关于锁的东西。不长。

关于弹子锁里一种叫假到位的状态——弹子卡在差一点的位置，手上的感觉跟到位了一模一样，但锁没开。

从锁写到了人。从人写回了锁。

https://xiaoni.liahuas.top/false-set/

[NAS] 关于更换操作系统后 TimeMachine 无法备份的解法

最近给 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 实际维护三套互相同步不良的认证状态：

在系统设置里输入密码时，GUI 真实连接了 NAS 并验证成功（ NAS 日志有访问记录）、也写入了钥匙串——但没有写信任标记。后端 daemon 只认标记。UI 的"成功"和后端的"信任"是两套语义，这是字面意义上的脱钩。而整个失败链条最终坍缩成一句"备份失败 / 错误 29"，用户能做的所有常规操作（重输密码、删了重加、换 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 有稳定的 --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 似乎精度不够？

[分享创造] 做了一个文档解析与记忆工具，专门辅助给传统行业做 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

[程序员] 为什么“节省 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/方法讨论，不是产品发布。也想听听大家认为这类工具最合理的评估分母应该是什么。

[上海] 大家那里的城市，有没有看到广东揭阳狗狗旺旺的广告牌

我这里有了

第一次看到大家为公益事件这么团结😢

[Claude] 一年多没用过 Claude，当初用的时候仅用过 mac 客户端和网页，号被封了

上次用还是 DeepSeek R1 刚出的时期，没用过 Claude Code ，账号没付过费

绑的是英国的 giffgaff 手机号

严重怀疑这家公司会在网络上搜索你的用户名前缀进行身份识别（也可以说是盒），或者对同一个节点的注册账号采取连坐机制，或者是跟谷歌有信息共享（港区谷歌账号）

只是感觉有点搞笑，连发两条消息，搞得像是多稀罕一样

希望能够给大伙分析风控机制提供点信息

[分享发现] 已入手安克 160w prime 充电头，毕业了

官翻只要 328 元，比咸鱼价格还低，一步到位不折腾

[分享创造] 做了一个专注电商场景的 AI 工具导航站

大家好，分享一个最近做的导航小站：FlowCay： https://flowcay.com

定位很简单：只收电商相关的 AI 工具，覆盖选品、内容创作、图片/视频、客服、SEO 、广告投放、数据分析、自动化等场景，面向跨境、外贸和国内卖家。

目前还是刚起步，内容还比较少，如果你自己做了电商相关的 AI 工具，或者日常用着觉得特别好用的，欢迎提交过来，会审核后收录。

提交入口： https://flowcay.com/submit

欢迎大佬们提意见～

[问与答] 解答世间万物

我发现男人最好的状态是在成为活佛以后。

[宽带症候群] VONR/VOLTE 音质

想问一下目前电信/联通的跨网 VONR/VOLTE 音质，是不是还没有 FaceTime 视频的音质清晰？不拿移动对比，是因为移动在跨网过于垃圾，不需要对比

[分享发现] 分享一个小创意，用 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