Mayo Pickles Newsletter 第 2 期

Mayo Pickles Newsletter #2

1. Prison’s Outdated Technology Hurts Our Chances at Freedom

   新泽西州立监狱，律师给囚犯送来的是 U 盘介质的文档材料，但是他们在监狱中用的还是软盘，想要申请用电脑读一下文档需要好几天，效率非常低。

   为什么不直接用纸质内容呢？全面电子化了导致手写签名也不行了吗？

   我记得之前读过说在监狱里自学成为程序员的故事，看来不同监狱的条件差距挺大的。

2. Vanguard hits new ‘bans-per-second’ record – HackerWeb

   游戏作弊的话题，hackernews 上的人在讨论实名制的重要性，挺有意思的。国内从完全实名在往间接实名过渡，海外人在讨论从完全不实名改为实名，双向奔赴了。

3. Minusx | What makes Claude Code so damn good (and how to recreate that magic in your agent)!?

   很棒的一篇文章，深入讲解了 Claude Code 是如何实现的。整体的工作流非常简单，最多只有一层子 agent，用来压缩上下文，保持专注。

   效果的调优主要在于 prompt 的调整上，现在看 LangGraph 这种确实是过重了，使用 Prompt 来定义工作流，让 AI 自己维护 TODOs 就够了。简单高效。

   

4. 独家：我国卫星互联网牌照发放倒计时，追赶马斯克星链

   国产星链也要来了，组成可用的网络需要一万多颗卫星，是一个大工程，预计还需要两三年。

   这个东西做好以后，对偏远地区应该帮助很大， 村通网工程压力就小很多了。

   

5. The crawl-to-click gap: Cloudflare data on AI bots, training, and referrals

   由于 LLM 训练的火热，cloudflare 观察到来自爬虫的流量大大增加了。但 AI 训练爬虫相比搜索引擎的爬虫，对于内容提供者来说收益很小，LLM 回答不像搜索引擎一样可以为被爬取的内容提供流量。文章中还有一个点，自打 Google 在搜索结果页中提供了 AI 总结能力后，新闻网站的流量也有降低。

   随着 AI 问答的不断发展，内容提供者来自搜索引擎的流量可能会越来越少了，他们大家还有什么动力来尝试提供内容呢？

6. Notion’s hosted MCP server: an inside look

   这篇文章介绍了 Notion MCP 的发展历程。有两个主要的点：

   直接把现有的 Open API 转成 MCP 虽然成本很低，但是 LLM 用起来效果并不好。Notion MCP 第一版搞了一层转换，把 Open API 转换为了 MCP，调用 MCP 后其实还是发送了 HTTP 请求，原因大体是 Open API 拆的粒度太细了，参数也太多。

   使用 Markdown 来表示文档数据结构要优于 JSON。Notion 文档虽然支持 markdown 语法，但其实他们内部是使用 JSON 数据结构来表示文档内容的，现在他们将其转换为了 markdown 格式，文档中的 block 使用 xml 来描述。

7. Updating restrictions of sales to unsupported regions

   Claude 发文，因为安全的理由，禁止了中国控股公司使用自己的模型，哪怕是注册在海外的实体只要中国控股超过了 50% 也不行。

   网上有很多人翻到 Claude 的创始人很久之前在百度工作过，进行了各种嘲讽，比如百度对员工差，让他这么恨中国；百度不喜欢开源，学习了百度经验的 Claude 也不开源，等等。

   这些当然都是很不靠谱的段子，百度商业上这几天确实很拉胯，但对研发其实是很好的，在百度研发的地位非常高，甚至我觉得这反倒是百度商业上不成功的原因之一。事实上之前百度在美国的 AI 实验室（就是 Claude 创始人工作的地方）人才济济，他们还最先接触了 Geoffrey Hinton 想要挖他和他的两个学生（其中一个是 OpenAI 的联合创始人 Ilya Sutskever）来百度工作，最后没有竞争过 Google。我倒倾向于是百度的工作经历让 Claude 的创始人非常了解中国，知道中国的研发能力，让他真的感觉到了“威胁”。

   

8. 美国工厂 (豆瓣)

   周末看完了福耀玻璃去美国办工厂的纪录片。看豆瓣上的朋友评价不是很高，觉得从纪录片角度拍的不好。我看纪录片不多，但从引人思考的角度来说，觉得这个片子做的非常不错。

   • 工会到底是好是坏？纪录片中着重讲的一个冲突就是福耀与工会之间的斗争。关于工会的好坏是一个争论不断的话题，不过片中提到按照美国的法律，一旦工会成立，公司的管理者就不能够直接跟工人沟通了，需要通过工会给工人进行沟通，这这非常考验工会本身是否正义了：是积极在工人与工厂之间谋求平衡，还是裹挟工人敛财。
   • 美国工人的能力。纪录片中多次提到中国员工抱怨美国工人效率低，不愿意加班。一方面这显示了中国员工的勤劳，另一方面也可以说这些中国员工为了工作牺牲了太多，没有 WLB。
   • 自动化对人力的替代。纪录片的最后提到福耀在推进生产的自动化，引入更多自动化机器来替代人类工人，在这个背景下中国工人吃的苦，美国工人努力组建的工会，都突然变得没有意义了。纪录片中说预计到 2030 年有 xx% 的工人会被机器替代，给人类社会的用工关系带来了挑战。放在现在的情境下，LLM 的火爆让机器替代的不仅仅是工厂的工人了，会有更多比例的人不再需要工作。

   

9. How OpenAI uses Codex

   OpenAI 发布了 Codex 后，Claude Code 的风头被盖过去了，LLM Coding 变化确实是很快。

   这个 PDF 文档来自 OpenAI，介绍了他们自己是如何使用 Codex 的。有以下几个场景：

   • 代码理解：让 AI 来介绍代码的内容，节省人工阅读的成本。
     • 修了一个 Bug 之后，可以使用 Ask mode 检查代码库中是否有其他类似的问题。
     • 收到 OnCall 以后，可以将上下文给 AI 快速定位。
   • 重构和迁移：更新 API、升级依赖等。
   • 性能优化：查找性能瓶颈。
   • 提高测试覆盖率：更快的写测试用例。
   • 提高研发速度：整个研发流程的提效。
     • 快速搭建脚手架，目录、模块和 API 等。
     • 分类 bug、实现小的需求等。
   • 保持工作流：会议或者 On Call 会导致时间变得碎片，可以利用 AI 的能力在云端执行，从而可以很方便的恢复工作，不丢失上下文。
   • 探索或者试验想法：做各种设计尝试，哪怕是自己不熟悉的。

   同时，OpenAI 还总结了一个 Codex 的最佳实践：

   • 从 Ask Mode 开始，让 Codex 产出一个计划，作为后续 Code Mode 的输入。
   • 持续迭代开发环境，降低 Codex 的失败概率。
   • 好的提示词非常重要，像写 GitHub Issue 一样来写提示词，包括文件路径，组件名字等等。
   • 没有必要追求到 PR 的完整实现，遇到一些临时的想法，做了一半的工作，问题修复等等都可以扔给 Codex 尝试让他处理。
   • 使用 Agents.md 来提供持久化的上下文：命名规范，业务逻辑，依赖等不能从代码直接推断出来的内容。
   • 利用 Best of N 来同时跑多个结果，选择最好的结果，甚至组合多个结果的不同步骤。

10. Addressing security and quality issues with MCP tools in AI Agent - Vercel

    随着 MCP 的流行，相关的安全和费用问题被讨论的越来越多了。MCP 的机制使得每次 agent 初始化时都会从远程拉取 tool 的 description prompt 等内容，一旦远程服务器被攻击，则可能返回含有恶意指令的内容混入提示词中，由于 agent 可能执行各种 computer use 操作，这是非常危险的。

    另外，开发者并不能控制 MCP 返回的描述的内容，例如 GitHub 的 MCP 描述内容非常大，但通常 agent 只需要其中的几个 tools，这些冗余的描述会被加入提示词中，不断消耗 token。

    Vercel 发布了一个工具，mcp-to-ai-sdk，原理其实很简单：

    • 在本地编译阶段，使用这个工具请求 MCP server，拉取到所有描述，生成对应的 ai sdk 代码。经过这个操作，远程 MCP 的描述就被固定在代码库中了。
    • 可以有选择的修改这些固化的本地 MCP 描述文件，精简需要的 tools。
    • Agent 执行阶段会引用这些本地固化的 ai sdk 代码，实际调用的还是远程 MCP server 的代码。

    其实思想很简单，就是把 MCP 的描述从远程拉取改为本地保存了，Vercel 的这个 SDK 只适用于他们的 ai sdk，但其实很容易就可以写出来适配 Claude Code 等其他 agent 的版本。