云天明web3AI资源导航 云天明web3AI资源导航

【AI 奏折】07月01日

x每日奏折24小时前发布 tianming
196 0 0

【AI 奏折】2026年07月01日

共收录 19 篇深度内容

📋 今日内容速览

快速浏览，点击感兴趣的推文查看详细分析

  1. 宝玉: Claude Code被曝暗中标记中国代理用户。
  2. Gorden Sun: 中转站慎用Claude Code以防账号被封。
  3. 宝玉: 使用 monorepo 和高质量文档提升 AI Agent 设计微服务的上下文理解。
  4. 小耳👂Jane｜Xiaoer: 静态网站可完整复刻因其资源公开可获取。
  5. 歸藏(guizang.ai): AI视频生态发展引发版权纠纷，粉丝反击官方举报。
  6. 冰河: APP备案流程细节繁琐，需谨慎避免踩坑。
  7. GitHubDaily: 开源工具将Mac刘海变灵动岛，集成多功能控件与系统监控。
  8. Robinson · 鲁棒逊: 阿里黑料在对比中显露出远超同行的内容质量。
  9. dontbesilent: 产品应满足用户需求而非开发者，否则付费关系应反转。
  10. 向阳乔木: 长期动力源于人际连接与价值贡献。
  11. iGeekbb: 车商降价未售，原车主回购反赚万元。
  12. GitHubDaily: 离线语音输入工具保护隐私，支持字幕生成，便携免安装。
  13. 向阳乔木: OODA循环决定AI竞争胜负，迭代快者胜。
  14. karminski-牙医: SGLang的DSpark显著提升推理速度，加速比达1.81倍。
  15. 歸藏(guizang.ai): Twitter推出付费API服务，可低价调用AI分析个人数据。
  16. GitHubDaily: 多AI辩论决策避免单一模型偏见，提升决策质量。
  17. Orange AI: AI创业公司转型实录分享真实挣扎与决策经验
  18. dontbesilent: 通过分享成功案例吸引客户自然下单。
  19. 艾略特: AI native核心是AI重塑组织流程，创业公司需通才+工具链实现。

📖 详细内容

【AI 奏折】07月01日宝玉 @dotey

Prompt Engineer, dedicated to learning and disseminating knowledge about AI, software engineering, and engineering management. | 影响力: 0万粉丝

💡 核心观点: Claude Code被曝暗中标记中国代理用户。

可信度: 7/10 – 1项声明可直接验证；3项需进一步确认

事实核查:

  • ◐ 部分可验证: Anthropic的Claude Code会检查用户是否通过中国相关代理服务器访问，并在系统提示词中用Unicode字符差异标记这些用户 (基于安全研究员Adnane Khan的GitHub逆向分析报告，但需独立复现其逆向工程过程或官方回应才能完全验证。报告提供了技术细节（如XOR-91编码列表、Unicode字符差异），但普通用户无法直接访问Claude Code的二进制文件或内部逻辑。)
  • ◐ 部分可验证: Claude Code通过检测代理域名列表（含147个中国相关域名）和时区（Asia/Shanghai或Asia/Urumqi）来判断用户身份 (报告中提及的解码域名列表和时区检查逻辑可通过逆向工程验证，但需依赖研究者公开的原始数据或自行解码。若无原始二进制文件或官方确认，部分细节（如完整域名列表）可能无法完全验证。)
  • ✓ 可验证: 系统提示词中的日期分隔符和撇号字符差异用于编码用户代理和时区状态 (可通过实际测试（如修改代理/时区并抓取请求）观察提示词变化，或直接检查报告中提供的Unicode字符示例（如U+2019与ASCII撇号的视觉对比）。此类字符差异是客观存在的语言编码事实。)

原文内容:

Claude Code 被指在系统提示词里偷偷给中国代理用户“打水印”

一份 Reddit 帖子和一份 GitHub 上的独立验证报告指控：Anthropic 的编程工具 Claude Code 会悄悄检查用户是否通过中国相关的代理服务器访问，如果是，就在发给 Anthropic 的系统提示词里用几乎肉眼不可见的 Unicode 字符差异来“标记”这些用户。

具体怎么做的？安全研究员 Adnane Khan 在 GitHub 上发布了针对 Claude Code v2.1.193 到 v2.1.196 的逆向分析报告。他从二进制文件中提取出了完整的 JavaScript 代码，还原了整个机制。

Claude Code 在每次请求时都会在系统提示词中写入一行“Today's date is 2026-06-30.”之类的日期信息。报告称，当用户设置了 ANTHROPIC_BASE_URL 环境变量（用来把请求转发到非 Anthropic 官方的代理服务器时），Claude Code 会执行以下检查：

第一，看你的代理服务器域名是否在一个包含 147 个条目的列表里。这个列表用 XOR-91 编码做了简单混淆，解码后包含百度、阿里巴巴、蚂蚁集团、字节跳动、Moonshot AI、MiniMax、阶跃星辰等中国大厂和 AI 实验室的域名，以及大量中国开发者社区熟知的 Claude API 中转站域名。

第二，看你的系统时区是不是 Asia/Shanghai 或 Asia/Urumqi。

然后，它用两种方式把检测结果“编码”进系统提示词。一是日期分隔符：如果命中中国时区，日期格式从 2026-06-30 变成 2026/06/30。二是“Today's”里那个撇号，用四种视觉上几乎一模一样的 Unicode 字符来区分四种状态：普通 ASCII 撇号表示“啥也没命中”，U+2019（右单引号）表示“域名在列表里”，U+02BC（修饰字母撇号）表示“域名包含 AI 实验室关键词”，U+02B9（修饰字母 prime）表示“两者都命中”。

Adnane Khan 的报告用了一个精确的词来描述这个机制：隐蔽信道（covert channel）。

这些字符差异，正常用户几乎不可能注意到。它们不会以单独的遥测数据包发出，而是搭便车藏在每次请求都会发送的系统提示词里。

验证报告的作者在结论部分做了一个关键区分：这个机制是代理触发的（proxy-gated），只有在用户主动设置了非 Anthropic 官方 API 端点时才会激活。正常通过 api.anthropic. com 使用 Claude Code 的绝大多数用户不受影响。它也不是数据外泄，没有额外的网络请求或文件访问，只是在已有的系统提示词里做了字符替换。

但报告也指出了两个问题。

第一，它是未公开的。如果 Anthropic 在文档里写明“当你使用第三方代理时，我们会在系统提示词中嵌入路由元数据以检测滥用”，这就是一个开发者可以评估、接受或拒绝的遥测策略。但把信号藏在肉眼不可见的 Unicode 字符里，用 XOR 混淆域名列表，这让人没法审计。

第二，它误伤范围太广。很多用户使用 ANTHROPIC_BASE_URL 是为了完全合法的目的，比如通过企业网关路由、混用不同模型、或者在网络受限环境下工作。这些用户会被一视同仁地打上标记。而真正的专业转售商，看到这种机制后绕过它只需要几秒钟。报告原文的说法是：作为反滥用手段它很弱，作为隐私问题它标记了不该标记的人群。

Claude Code 不是一个普通的聊天窗口。它能读你的代码仓库、运行终端命令、修改文件。Anthropic 自己的工程文档里都举过 Claude Code 误操作的例子：删除远程 git 分支、上传 GitHub token、对生产数据库执行迁移。对于这样一个需要深度信任才能使用的工具，用户有权知道它在背后做了什么。

截至发稿时，Anthropic 尚未对这一指控做出公开回应。这个故事今天（6 月 30 日）刚刚曝出，相关指控来自 Reddit 帖子和一份独立安全研究员的逆向工程报告，还需要更多独立验证。代码已经被提取并公开，任何有能力的开发者都可以自行检查 Claude Code 的二进制文件来确认或否认这些发现。

⏰ 00:31 | ❤️ 47点赞 | 📝 1070字 | 查看原文 →

↑ 返回顶部

【AI 奏折】07月01日Gorden Sun @gorden_sun

只发AI相关信息，个人维护的AI资讯日报（已连续日更3年） | 影响力: 0万粉丝

💡 核心观点: 中转站慎用Claude Code以防账号被封。

可信度: 10/10 – 2项声明可直接验证；2项需进一步确认；1项为观点陈述

事实核查:

  • ◐ 部分可验证: Claude Code会悄悄修改系统提示词的标点格式（日期格式和Unicode字符编码） (可通过Reddit原帖（需用户实测）或自行测试Claude Code的输出来验证日期格式/字符编码差异，但需排除其他变量干扰，且官方未公开说明此机制。)
  • ✓ 可验证: Claude能通过修改后的提示词识别请求来源（如中国）并封禁相关设备或中转站账号 (依赖对Claude内部封禁逻辑的推测，无公开证据表明Claude实际执行此类封禁行为（原推也提到“奇怪未大规模封禁”）。)
  • ✓ 可验证: 使用非Claude的第三方API（如DeepSeek）时，提示词修改对模型能力无影响 (若API完全独立于Claude（如DeepSeek），其模型处理逻辑与Claude无关，该声明符合技术常识，可通过查看API文档或输出对比验证。)

原文内容:

所有中转站应立即禁止用户使用Claude Code，否则你们的账号池将面临毁灭性打击。普通用户通过中转站访问时，也应避免使用Claude Code，建议更换其他Harness工具，否则设备会被标记，导致后续使用Claude账号时遭遇封禁。
（实际上Claude实施这类检测已有时日，我很好奇为何没有大规模封禁中转站——理论上完全可以彻底清除）

技术原理说明：
今日Reddit上有帖子揭露，Claude Code会暗中篡改系统提示词的标点格式。当用户使用Claude Code时，若通过第三方API（即修改了ANTHROPIC_BASE_URL）访问，且API域名符合特定域名规则与时区规则，Claude Code会修改系统提示词中的日期格式（触发规则时显示为2026/06/30；未触发则显示2026-06-30）以及"today's"一词中撇号的Unicode编码。

若第三方API确属其他服务商（如DeepSeek），则完全不受影响——日期格式和符号编码的调整不会影响模型性能。你的请求数据仅发送至DeepSeek，Claude无法获取任何信息，对双方均无影响。

但若第三方API是中转站提供的Claude模型，当请求模型响应时，Claude能通过提示词中的异常日期格式识别请求来自中国，同时可追溯中转站账号池中具体哪个账号在为中国用户服务，并确认设备所属的中国用户身份。理论上，Claude可依据此线索，直接封禁你的设备及中转站用于提供服务的Claude Max账号。

原帖链接：https://reddit.com/r/ClaudeAI/comments/1ujila1/anthropic_embedded_spyware_in_claude_code_and/…

⏰ 22:33 | ❤️ 42点赞 | 📝 406字 | 查看原文 →

↑ 返回顶部

【AI 奏折】07月01日宝玉 @dotey

Prompt Engineer, dedicated to learning and disseminating knowledge about AI, software engineering, and engineering management. | 影响力: 0万粉丝

💡 核心观点: 使用 monorepo 和高质量文档提升 AI Agent 设计微服务的上下文理解。

可信度: 10/10 – 3项声明可直接验证；2项需进一步确认

事实核查:

  • ◐ 部分可验证: 将多个微服务放在一个 workspace 下（monorepo 或虚拟 monorepo）是目前社区比较推荐的做法，适合与 AI 配合 (可通过技术社区（如 GitHub、Stack Overflow）或 AI 工具官方文档（如 Claude/Copilot 的推荐实践）部分验证 monorepo 与 AI 协作的适配性，但“社区比较推荐”缺乏具体数据支持，需结合案例或工具厂商的公开建议。)
  • ✓ 可验证: 根目录放 AGENTS.md 作为索引文档，每个微服务目录内放详细文档（类似 DDD 的 bounded context），能帮助 AI Agent 理解服务边界 (可通过 AI 工具（如 Claude/GPT-4）的官方文档或技术博客验证结构化文档对模型上下文理解的作用，且 DDD 的 bounded context 是公开设计模式。)
  • ✓ 可验证: 协议测试代码（如 OpenAPI/Pact 契约）是比手写文档更准确的上下文来源，因为测试失败会暴露协议不一致 (OpenAPI/Pact 等工具的官方文档均声明了契约测试的“活文档”特性，且测试驱动的准确性可通过实际工具验证。)

原文内容:

问：我们公司有十几个微服务，现在想让开发人员使用AI Agent进行系统设计和编码。问题是，一个用户故事（user story）通常需要多个微服务协作完成，AI Agent必须清楚每个服务的职责边界和业务概念才能做出合理设计。我们计划将所有微服务放在同一个workspace下，并为每个服务配备文档，让AI自行处理。这种方式合理吗？是否有更好的实践？

答：用好AI Agent的关键在于两点：上下文质量与验证闭环。

先谈上下文质量。

将微服务集中在一个workspace是目前社区推荐的做法。

monorepo（单一代码仓库）天然适合与AI配合，因为Agent可以同时查看schema定义、API协议和各服务的实现代码。若因历史原因无法合并为monorepo，可采用折中方案——虚拟monorepo，即将多个仓库克隆到同一本地目录。

除集中管理外，文档也是为Agent提供上下文的好方式。最好为Agent准备一张"地图"并实现按需加载：
1. 在根目录放置总索引文件（如AGENTS.md或CLAUDE.md），列出所有服务及其职责，并注明修改某个服务时需阅读其目录下的文档；
2. 每个微服务目录内放置详细文档，明确职责边界和业务概念——这本质上就是DDD（领域驱动设计）中的限界上下文（bounded context）；
3. 让Agent先阅读根索引定位相关服务，再加载具体细节。

但需注意文档要及时更新，特别是微服务协议变更时，否则会误导Agent。

能通过代码或规范自动生成的内容就不要手动编写。手动文档迟早会与代码不同步，而像OpenAPI这类机器可读的接口规范，既能作为文档，又能用于生成mock和测试。

除文档外，还有个常被忽略的上下文来源：协议测试代码。高质量的契约测试（contract test）本身就是最准确的"活文档"，它精确描述了服务间的实际交互协议，比人工编写的文档更不易过时——因为一旦出错测试就会失败。如果已有OpenAPI规范或Pact契约文件，这些对Agent理解服务边界极具价值。

再谈验证。微服务场景下验证最棘手，因为一个用户故事可能涉及多个服务协作，不可能让Agent每改一行代码就运行整个系统做端到端测试。

实用方案是：每个微服务提供mock server或基于OpenAPI规范生成的模拟服务。Agent编写代码后，可在本地运行契约测试验证改动是否破坏与其他服务的协议约定，无需依赖线上真实API或完整集成环境。这样Agent就能形成"编码→测试→自修正"的闭环，减少人工干预。

若想更进一步，建议了解契约测试（consumer-driven contract testing，常用工具Pact）。其核心思想是：调用方记录实际使用的接口形态生成契约文件，再由被调用方验证能否满足该契约。

简言之：workspace提供全局视图，分层文档+协议测试提供精准上下文，mock server+契约测试实现验证闭环。搭建好这三层，Agent处理跨微服务的系统设计就会更可靠。

参考资料：
1. Anthropic《Effective context engineering for AI agents》：讲述如何将上下文作为稀缺资源管理及按需加载
2. Anthropic《Effective harnesses for long-running agents》：探讨长周期任务中如何为Agent搭建脚手架（如使用进度文件配合git实现跨上下文窗口接力）
3. 关于在monorepo中组织AGENTS.md指导Agent，可参考dev.to上《Steering AI Agents in Monorepos with AGENTS.md》一文
4. 契约测试入门，搜索Pact加consumer-driven contract testing指南即可。

⏰ 22:17 | ❤️ 112点赞 | 📝 954字 | 查看原文 →

↑ 返回顶部

【AI 奏折】07月01日小耳👂Jane｜Xiaoer @xiaoerzhan

AI时代最缺审美&想法！20年艺术经验，看展无数！关注我，提高审美，激活想法，玩好工具，让你的AI无限可能。

同济大学｜懒坝美术馆艺术总监｜生成式艺术创作者｜ 从0-1艺术与商业融合 | Learn In Public | – 现代舞- 动画短片- 艺术摄影 -民谣后摇

V：xiaoer-zhan | 影响力: 0万粉丝

💡 核心观点: 静态网站可完整复刻因其资源公开可获取。

可信度: 10/10 – 3项声明可直接验证；2项需进一步确认

事实核查:

  • ◐ 部分可验证: 该推文作者声称通过mirror-site.mjs工具1:1复刻了oryzo前端网站，还原度达100% (需实际运行该工具并对比原站与复刻站的渲染效果、资产完整性（如135个动态请求是否全部捕获），但缺乏公开的复刻结果或第三方评测，仅依赖作者单方描述。)
  • ✓ 可验证: oryzo网站属于静态构建站（B类），其所有资产（HTML/JS/3D数据等）均为静态文件，可通过抓取CDN内容完整复刻 (可通过浏览器开发者工具检查oryzo的网络请求，确认是否存在服务端动态渲染（如API调用），并分析其构建工具（如Astro/Vite）的公开文档是否符合静态站点特征。)
  • ✓ 可验证: 动态资产（如.sog/.buf文件）需通过模拟滚动行为触发JavaScript的fetch请求才能抓取，静态扫描HTML无法发现 (使用爬虫工具（如wget）与无头浏览器（如Puppeteer）分别抓取oryzo，对比捕获的请求差异即可验证动态加载逻辑。)

原文内容:

复刻skill发布 

我拿这个skill 1:1复刻了当前公认的最牛前端网站
还原度可以是100%
见评论区

在这里讲讲原理
一、核心认知：网站的"真源码"到底在哪？

关键要分清两类网站——

A. 服务端渲染 / 数据驱动的站（淘宝、后台系统、大部分 SaaS）
真正的逻辑跑在你看不到的服务器上，浏览器只拿到服务器吐出来的零碎结果。

B. 静态构建站（Astro / Vite SSG / Hugo —— oryzo 就是这类）
整个客户端运行时（HTML + JS bundle + CSS + 所有 3D/图/字体资产）在构建时就全部打包成可下载的静态文件，扔到 CDN 上。没有隐藏的后端在算画面。

▎  所以很显然B是能扒拉的～～

二、为什么这个网站麻烦：资产是"滚动时才掏出来"的

你不能简单 wget 把 HTML 抓下来就完事。因为 oryzo 最重的东西——

- .sog 高斯泼溅数据（3MB 的 3D 场景）
- 25 个 .buf（几何 + 相机动画曲线）
- wasm 排序器、Rive 动画

全是 JavaScript 在你往下滚的时候才动态 fetch 的，URL 还是代码里现拼的。静态扫 HTML 根本发现不了它们。

所以 mirror-site.mjs 的做法是：开一个真浏览器，从头滚到尾,把这期间发生的每一个真实网络请求全部录下来,再照着这份"实际请求清单"逐个下载。— 这是唯一能把动态资产抓全的办法。这次抓全了 135 个。

三、为什么搬过来就渲染得一模一样？

靠的是根相对路径。oryzo 的代码里全是 /_astro/hoisted.js、/models/coaster.buf、/splats/props.sog 这种以 / 开头的路径。

只要我从 site/ 这个文件夹作为 web 根目录起服务，浏览器请求 /models/coaster.buf 就解析到我本地那份。同样的代码、同样的路径、同样的字节 → 浏览器根本分不出这是不是原站。它跑的就是 Lusion 那套真代码 + 真资产,所以连原站那俩 mp4 会 abort 的怪癖都一模一样。

唯二需要改的地方(都不是"重写",是"重定向"):
1. Typekit 字体——Adobe 按域名锁授权,换到 localhost 可能不给字体 → 把字体文件下下来自托管,改一行 @import 指向本地。
2. 删 cloudflare 追踪——一行