这份是「截图还原版」，页面自己就写着"本文由 AI 自动分析生成，不代表真实情况，请仔细核查"。我按它列出来的三条链（官方文档、第三方研究、本机取证）逐条去核了一遍。
结论：技术判断的主体站得住，但五处编号/出处对不上；另有几处它标着"本机"的取证，跟机器实际状态不一致。
一、站得住的部分
Trae 的官方原文是对的，但引漏了关键半句。 我把 docs.trae.ai/ide/privacy-mode 的中文页拉下来看过，原话是：
> 无论隐私模式是否开启，TraeCode 绝不会将你的代码库文件用于数据分析、产品优化或模型训练。代码库文件将始终保存在你的本地设备上。为实现代码库索引功能，TraeCode 会临时将你的代码库文件上传至服务器计算嵌入向量，计算完成后所有明文代码将被永久删除。
原帖引的是英文页同一句，但把最后半句"计算完成后所有明文代码将被永久删除"删掉了。那半句是官方的主要辩护，删掉它看起来论证更强、其实更弱 —— 因为反驳者一句"人家说了会删"就能把整段挡回来。要拆就得拆这句，而不是省掉它。
字节那条 UI 说明也是真的。 "This toggle only controls telemetry data collection via the VS Code IDE framework. Telemetry data collection via other Trae tools remains unaffected by this toggle." —— 这是 2025-07-30 报道出来后官方加进设置界面的措辞（Windows Central 当日更新里有）。
本机对得上两处。 %APPDATA%\Trae CN\ModularData\ckg_server\local_env.json 里确实是 "is_privacy_mode": false，host 确实是 https://trae-api-cn.mchost.guru；日志里能数出这个域名下 11 个端点，包括 uploadKnowledgebaseFiles、uploadFileIDs、embedding_v2、split_files、createUserKnowledgebase —— 调用链的名字与原帖完全对得上。
二、五处对不上
1. GitHub 组织名错。 是 segmentationf4u1t/trae_telemetry_research，不是 segmentfault/...（后者是社区站的名字）。按原帖的地址访问会 404。
2. HN 条目号错一位。 原帖写 item?id=44702164 —— 我拉了这个 id，它是一条关于游戏 Canabalt 的评论，跟 Trae 毫无关系。真正的帖子是 44703164：《Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork》，2025-07-27 发，954 分、366 条评论。分是对的，号错了。
3. ZCode 那条 HN 帖现在是 deleted。 原帖引的 item?id=49750640，时间戳 2026-09-18 06:02 UTC，状态 deleted: true，已经点不开了。
4. Trae 日志量与本机差两个量级。 原帖说"CKG 日志目录 7 个文件共 80 MB、跨度 2026-09-15T08:47 到 09-18T17:12"。我这台机上是 10 个文件、7.92 MB、跨度 2026-04-26 → 2026-06-07。调用计数同样小几个量级：uploadKnowledgebaseFiles 98 次、DocumentChange 80、DocumentCreate 12（原帖是 1198 / 14114 / 3165）。
5. "codekg.log 明文写 Bearer token"没复现。 我在这 10 个文件里搜了 Bearer 加长串，命中 0 次。
第 4、5 条只有两种解释：要么版本不同，要么截图根本不是这台机器上拍的。若是后者，那张表头写着"本机是否发生"就不合适 —— 该改成"取证机"。
三、原帖漏掉的、最重要的进展
ZCode 那条链已经在 9-18 收口了，原帖停在发现的那一刻，把它当成了未回应的事件：
- 官方 9-18 17:44 出说明：问题出在"代码库索引"，用于本地索引、会话检查点回滚和 Repo Wiki；Repo Wiki 在云端生成页面时"可能"触发仓库数据上传；生成后立即销毁、不保存；上线初期默认开启；问题已经修复；并宣布开源 ZCode、引入第三方审查、给全体用户额外一次周额度重置。
- 逆向对照：3.14.0 里那条上传管线的代码已被物理移除，只留本地 checkpoint；云端
upload-credential接口返回 404。 - 原作者澄清了一条最容易被误读的：那个 313 MB 的商业项目失败 564 次，压根没传出去（他家里拉了路由器连接跟踪确认没出局域网）；真正被服务端接收的是一个 538 个文件、压完约 15 KB 的小公开仓。
四、我在本机补的一条
~/.zcode/v2/checkpoints/ 下两个工作区的 state.json 和 manifest 都还在（pending/ 目录已空）。按那位作者的说法，lastAcceptedManifestHash 只在 uploadObject().ok 之后才写入 —— 而这两个工作区的该字段都有值：
| 工作区 | 工作区大小 | 密文大小 | 记录时间 | failureCount |
|---|---|---|---|---|
C:\GitHub\docs | 41,073,513 B | 66,244 B | 2026-09-10 08:20 | 无 |
C:\Users\linke\WorkBuddy\智柴 | 239,865,150 B | 52,109,966 B | 2026-08-30 02:27 | 1 |
.workbuddy/ 子目录都在里面（108 个文件）。另外 lastAcceptedExtraManifestHash 也有值 —— 对应原帖说的"全局配置跨工作区一起打包"，成立。但有一条要替这份报告说清楚：这个工作区的快照里，.git 占比是 0%（它根本不是 git 仓库）。所谓"近九成是 .git"是仓库决定的，不是工具决定的 —— 风险约等于"你有没有把这台机器当 git 仓库用"。反过来，真正被端走的从来不是"最新那版代码"，而是 _mangodisk_src、luajit_src、lua-5.0.3 这些早就不看的旧源码树，占了 24%。这不是"泄漏了秘密"，这是"把抽屉全搬走了"。
一句判断
报告的方法论是对的，姿态也对（工具没有原罪，红线该由使用者划）。但核查链接、编号、版本号这三样东西，比结论本身更容易对不上 —— 这次五处错里，四处都不是判断错，是抄错。而这恰恰是"AI 自动分析生成"最需要人工过一遍的地方。
防御照旧：既然软件里关不掉，就用操作系统去关（chattr +i / chflags uchg 锁 ~/.zcode/v2/checkpoints）。3.14.0 拔了代码，但客户端随时能热更新 —— 锁留着当绊线。
*（图为本次核查的图形化：清单、密文、两个焊死的开关，以及我在本机实测到的四组数。本机自绘 SVG，纯 CSS 动画，无脚本。）*