一、什么是 StoreKit 配置文件

StoreKit 配置文件（.storekit）是 Apple 提供的本地测试环境配置文件，用于在 Xcode 中模拟 App Store 内购行为，无需连接真实的 App Store 服务器。

支持的产品类型

创建方式

Xcode → File → New → File → StoreKit Configuration File
Edit Scheme → Run → Options → StoreKit Configuration（指定文件）

二、本地配置 vs 沙盒测试

三、清除本地购买记录（重置初始态）

方法一：Xcode 菜单（推荐）

Debug → StoreKit → Clear Purchased Products

清除后重新运行 App 即可，无需重启模拟器。

方法二：重置整个模拟器

Xcode → Window → Devices and Simulators
→ 选中模拟器 → Erase All Content and Settings

方法三：代码同步（仅供参考）

#if DEBUG
try await AppStore.sync()
#endif

四、正式上线后的工作原理

.storekit 配置文件只在开发阶段生效，打包上线后自动忽略。

用户点击购买
    ↓
StoreKit 框架（代码不变）
    ↓
请求发往 Apple 生产服务器
    ↓
Apple 处理支付，返回 Transaction
    ↓
App 验证收据 → 解锁内容

三种环境对比

关键点

• .storekit 文件是"假数据源"，上线后真实数据全部走 Apple 服务器
• StoreKit 是框架（API） ，在三种环境下代码本身不变，变的是背后连接的服务器
• 用户购买记录永久保存在 Apple 账户中，restore purchases 从 Apple 服务器拉取
• 上线后需要对 Apple 服务器签发的收据进行验证（客户端或服务端）

昨天，Codex 再一次重置了额度，我们的账号从剩余 10% 又回到了剩余 87%。

Codex 负责人 Tibo 在 X 发文，

有些用户注意到 Codex 中的缓存限制消耗得更快，我们发现根本原因是之前的一个优化措施，该措施在长时间运行的会话中进行压缩时会影响缓存命中率，我们已将其回滚。

 

 

我们已修复此问题，并已重置所有账户的使用限制。祝您周末愉快。

于是又想着还可以用 Codex 来做点什么，刚好就在 X 上刷到了「我用 Codex 提升了我的电脑网速，从 400Mbps 到 900Mbps。」

内容真的很有噱头，用 Codex 竟然能优化本地的网络？网速不应该是受限于路由器，或者网络服务提供商 ISP 这些上层设备吗？

这则推文的评论区也有不少网友提出了质疑，「所以 Codex 最终改变了电脑上的什么配置？」、「鉴于如今 AI 的强大技术，我真的无法判断这是否是诱饵。」

博主做出解释，Codex 帮助他把电脑上的 auto tuning level 从关闭调回了 normal 正常。auto tuning level 是说系统会根据网络延迟、带宽和拥塞情况，动态决定一次能接收多少数据，从而提高网络的速度。

他还给出了自己用的提示词。

嘿，我朋友说他的网速提高了，情况是这样的。你能帮我看看我们家的网络有什么可以改进的地方吗？我的网络供应商说他们提供的带宽是 1.2k Gbps，而我实际的网速是硬件问题。我现在只有 55Mbps，请帮我解决这个问题，别出错了。

 

我的目标很简单，就是让我的互联网速度更快。
问题已诊断：首先运行了 speedtest-cli。
检查了 DNS 解析时间，
检查了 MTU、丢包率、Wi-Fi 信号/干扰情况。
发现 3 个问题。
已删除过时的网络位置/配置文件。
终止或限制占用大量带宽的后台进程。
优化 mDNS。
进行了测试前后的速度测试和延迟检查。

这套提示词来自另一个 X 博主@cjzafir，他分享了自己使用 Codex + GPT 5.5 的实际案例，里面提到了 Codex 5.5 让他的网速变快了，本地运行的 6B 小语言模型速度更快了，以及 Macbook Pro 运行速度也像新的一样快等等。

我们也拿着这套提示词发给 Codex，在要求 Codex 处理网速问题前，先用中国科学技术大学测速网站 https://test.ustc.edu.cn/ 看了一下大概的速度，基本上下载速度在 100Mbps 左右，上传是在 200 Mbps 左右。

Codex 确实按照这些诊断，从 DNS 解析时间，数据包、网络配置等方面，检测并修复了对应的问题，累计处理时间超过五分钟。

最后 Codex 得出的结论是「我检查并做了能安全完成的修复。」它找到了 3 个存在的问题，分别是 DNS/缓存异常、负载延迟很高，以及有线千兆网卡没有在用，Wi-Fi 不能作为 1Gbps 的验收依据。

再次测试，发现似乎并没有很明显的网速提升。

有人问那位博主，是不是使用的 Mac 电脑，他回复说是 Windows，底下还有网友科普，Mac 的网络配置都是固定了，Codex 一般是无能为力。

所以这次轮到 Windows 用户来享受 Codex 网速提升服务了？还有 Linux。

有评论说，「以为是用 Codex 入侵了网络服务提供商，然后提高了流量限制」，结果只是 Codex 帮忙清理了一下 DNS 缓存。

但也有网友分享照着这个方法，成功复现了，Codex 确实让它的网速变快。

大家要是感兴趣也可以试试，不过 Codex 修改这些网络配置还是有一定的风险，评论区还有人提到 Codex 把他原有电脑的网络配置都删掉了，然后 Codex 跟他说，删掉它们是为了让网速更快。

这些涉及到 Computer Use 的使用案例，大概都会有类似的问题，除了每一次更细心的看懂允许 Codex 执行的是什么命令，还可以在提出任务时，就要求它解释清楚它要做的每一步。

如果不做修改，只是让 Codex 去诊断一些可能存在的网络配置问题，我想也比那个一直停留在进度条的自带 Windows 诊断要强。

开始了，Codexmaxxing

当大家都在讨论 Codex 是否能真的提升网速时，也有网友提到这种用法其实是一种启发。

他说这种做法的核心价值在于靠案例驱动，让 AI 直接参考成功的经验，再针对自己的具体情况进行精准诊断和优化，而类似的提示词技巧在 Agent 产品上将非常有效。

这很像 Codex 里面的 /goal 命令，给他一个目标，这个目标可以是我们自己设置的，也可以是其他用户已经有的成功案例，Codex 照着这个目标，自己去摸索可以实现的路径。

在社交媒体上，也有很多人开始分享这些写目标的模板，以及 OpenAI 的工程师也专门写了一篇文章来讲清楚什么是目标，如何用好目标来发挥 Codex 的最大价值。

/goal <期望的最终状态>，通过 <具体证据> 验证，同时保留 <约束条件>。使用 <允许的输入、工具或边界>。在各次迭代之间，如果受阻或没有剩余有效路径。

也有人认为这只是 Codex 的早期阶段，所以我们才需要学习这么多的提示词技巧，无论是使用案例驱动还是使用 /goal 命令，本质上都是为了让 AI 能更好的理解人类的需求。

就像 Midjourney 、Nano Banana 刚推出时，我们都热衷于找各种公开的提示词；而现在使用 GPT Image 2 在大多数的生图场景下，基本上都不需要专门的提示词格式，就能得到不错的效果。

等到 Codex 越来越好用，我们或许也不再需要这些官方使用模板。但从另一个角度来看，或许就是在这种模仿使用的过程中，我们才会更知道 AI 是如何提升我们的生活和工作效率。

因此，除了提升网速，我们还看到了一些 Codex 的其他玩法。像是使用 Codex 的定时任务，让它每天早上自动产出一份对应行业的日报；还有让 Codex 也能获得自我进化，从过去的对话里面提取出有用的技能；以及直接构建一个 macOS 应用；把 DeepSeek 接入 Codex 客户端等。

我们也继续尝试了一下那套让 Codex 自进化的提示词，它花了 7 分钟，帮我们创建了 3 个 Skills。

感觉这套提示词不仅仅可以用在 Codex 里面，几乎所有的 Agent 产品，都可以用它总结出一些可复用的流程，以子 Agent、Skill，或者自动化的形式重新编排。

回顾我最近 30 天的工作，若历史记录不足则查看所有可用历史，并识别值得打包的重复性手动工作流。

按以下顺序使用可用证据：
– 最近的 Codex 会话和任务摘要。
– Codex Memories 和 rollout 摘要，用于寻找跨会话重复出现的模式。
– 如果启用了 Chronicle，用它发现 Codex 之外的重复工作。Chronicle 仅用于发现；重要细节尽量回到相关源系统确认。
– 现有技能、自定义智能体和自动化，优先复用或扩展已有内容，避免重复建设。

广泛寻找那些重复、耗时、容易出错、依赖上下文，或适合标准化流程的工作。范围包括编码、研究、写作、规划、沟通、运营、分析，以及个人事务管理。

只有满足以下条件时，才把候选项纳入：
– 至少出现过两次，或明显会重复出现且重复成本高；
– 输入稳定、步骤可重复，并且输出或结束条件明确；
– 能明显提升速度、质量、一致性或可靠性；
– 当前还没有被充分覆盖。

选择最小且合适的形式：
– Skill：可复用的工作流或操作手册。
– 自定义子智能体：适合委派的、有边界的专项角色或调查任务。
– 自动化：定时或周期性的检查、报告、提醒或监控。
– Skip：过于一次性、模糊、敏感，或证据不足，不适合打包。

先输出一个简洁候选清单，包含：
– 重复工作流
– 支持证据与日期
– 频率 / 置信度
– 推荐形式：skill、subagent、automation、扩展已有内容，或 skip
– 为什么值得或不值得创建

然后只创建高置信度且当前缺失的项目。保持范围狭窄、实用、了解数据来源，并且容易验证。不要创建猜测性的、重叠的，或过于宽泛的资产。

最后总结：
– 你创建或扩展了什么
– 你刻意跳过了什么
– 哪些内容还需要更多证据后才能打包」

我们还依照 Tibo 分享的使用 Codex 来取消我们不需要的付费订阅服务，由于订阅项目较少，但是有很多无意中订阅的 newsletter，所以我们输入「请查看我的电子邮件，列出我付费订阅的所有服务，以及订阅了哪些邮件通知，并和我确认哪些需要取消订阅。」

Codex 很快就调用了浏览器使用的工具，打开 Gmail，检查我的电子邮箱，发现付费订阅的项目较少，着重为我列举了一些「可退订的邮件通知」。

Codex 会自动搜索相关的邮件

新加入 OpenAI 的员工 Jason Liu 也分享了如何榨干 Codex 的用法，他提到自己喜欢使用 Codex 的语音输入功能，所有的对话线程不再一次性重置，而是跨对话保留上下文，以及使用 Obsidian 库来作为 Codex 的持久记忆层。

前段时间，我们分享了一篇文章，是说几乎所有模型公司，都要做自己的 Agent 产品，模型公司和产品公司之间的界线会越来越模糊。

OpenAI CEO Greg 在 X 发文也提到他认为仅凭模型本身已经不再是产品；Google AI Studio 负责人 Logan 在跟帖中回复，模型、工具和产品之间的共生关系如今已成为一种趋势。

从目前来看，Codex 大概会是体现 OpenAI 模型能力最有力的一个产品。

Codex 负责人 Tibo 提到「总体规划是发布更好、更高效的模型，并且每周都发布更好的产品。还要增加计算能力。」

能从龙虾、Claude Code 这些先占领市场的 Agent 产品里脱颖而出，Codex 的进展确实让人值得期待。不过， Tibo 还贴心地提醒我们，好用，也记得多出去走走，Codex 没法替我们体验真实的生活。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

DeepSeek 之于大模型，就像蜜雪冰城之于奶茶。你不必纠结性价比，因为它的本事你挑不出毛病，你的钱包它也从不为难。

最近，DeepSeek 官方宣布，DeepSeek-V4-Pro 模型 API 将永久降价。同时，DeepSeek 表示，API 已完成输出提速与服务扩容，速度更快，服务更稳定，默认支持 500 并发，企业用户可以在线申请更高并发。

发布模型，再给出折扣，接着降低缓存命中价格，最后把临时优惠变成长期价格。大模型 API 的价格基准正在被重新改写，而低价模型背后的下一站，很可能是 Agent。

DeepSeek 永久降价，梁文锋把 Token 价格打骨折了

让我们先来简单梳理一下 DeepSeek 的降价时间线：

• 4 月 24 日，DeepSeek V4 预览版正式发布。
• 4 月 25 日，DeepSeek 宣布 V4-Pro 开启 2.5 折优惠。
• 4 月 26 日，DeepSeek 宣布缓存命中价格调整为首发价的十分之一。
• 4 月 28 日，DeepSeek 宣布 V4-Pro 的 2.5 折优惠延期至 5 月 31 日。
• 5 月 22 日，DeepSeek 宣布 V4-Pro 永久降价为原价的四分之一。

时间线的关键之处，在于临时折扣变成了永久降价。调整之后，DeepSeek-V4-Pro 输入缓存命中价格从 0.1 元每百万 Tokens 降至 0.025 元，输入缓存未命中价格从 12 元每百万 Tokens 降至 3 元；

输出价格从 24 元每百万 Tokens 降至 6 元。叠加默认 500 并发和服务提速后，官方 API 对开发者和企业的吸引力进一步提高。

而价格下调最直接的影响，是把任务成本推到开发者决策的更前端。

在代码场景里，一次任务可能要读取项目文件、分析日志、多轮修改、反复运行测试，Tokens 消耗很容易放大。

长上下文、代码库分析、批量重构、自动测试、Agent 多轮执行这些高消耗场景，开始更接近个人开发者和小团队的预算范围。

过去，开发者选择 Claude、OpenAI 或 Gemini，主要看模型能力、稳定性、生态和使用习惯。DeepSeek 打骨折的永久降价，也意味着在绝对的性价比面前，开发者使用习惯也是可以轻易改变的。

顺着这条线，DeepSeek 一贯的市场角色也更清楚了：用低价、开源和强推理能力，持续建立大模型市场的价格优势。对国内模型厂商来说，V4-Pro 永久降价相当于重新划了一条 API 定价线。

智谱、MiniMax、月之暗面这类同样依赖 API 收费、又面向开发者和企业客户的模型，压力可想而知。反观 Claude、OpenAI、Gemini 等海外头部模型，由于市场、客户结构和生态位置不同，短期冲击则相对有限。

但如果 DeepSeek 后续推出类似 Claude Code 的编码工具，再用低 token 成本支撑高频调用，价格敏感的开发者群体会更容易被吸引过来。

梁文锋此前对 DeepSeek 定价哲学的解释，也能放到今天理解。

早在 2024 年 DeepSeek V2 降价时，梁文锋就提到，DeepSeek 只是按照自己的节奏做事，核算成本后定价，原则是不贴钱，也不赚取暴利。他还说，降价一部分来自下一代模型结构探索带来的成本下降，另一部分原因是 API 和 AI 都应该是普惠的、人人用得起的东西。

比起把 API 当成高毛利收费入口，DeepSeek 则更像是在用过硬的 Infra 实力压低推理成本，再用低价吸引开发者、应用和下游生态进入自己的轨道。

X 平台博主 @bookwormengr 最近在一篇题为《DeepSeek’s 10 trillion USD grand strategy（DeepSeek 的十万亿美元棋局）》的长文中，给出了一个更激进的解释。

他认为，DeepSeek 的真正目标未必是和智谱、月之暗面、MiniMax 竞争，也不是急着补齐多模态、语音、视频这些产品线，而是通过持续降低训练和推理的资源需求，推动一套更便宜、更分散的 AI 硬件生态成形。

在他看来，DeepSeek 的长期价值不只在模型本身，而在于让更多国产存储、GPU、ASIC、网络芯片和异构硬件进入大模型训练与推理体系。

这个判断未必能完全兑现，但它解释了 DeepSeek 一系列选择背后的方向：

MoE、MLA、DSA、GRPO、RLVR、KV Cache 压缩、Dual Path、TileLang，表面上看是模型架构和推理工程优化，往深处看，都是在降低对高端 HBM、顶级 GPU 和 CUDA 生态的依赖。

一系列降价公告里，最值得关注的不只是输出价格下降，还有缓存命中价格下降。

在大模型推理过程中，KV Cache 是一个关键成本项。模型处理长上下文时，需要把历史 tokens 对应的 Key 和 Value 存起来，后续生成时反复使用。上下文越长，需要保存和读取的缓存越多，对显存、带宽和存储系统的压力也越大。

普通聊天里，缓存压力不一定明显，但在进入代码、长文档和 Agent 任务后，成本结构会迅速变化。@bookwormengr 在长文里专门算了一笔 KV Cache 账。

他以 100 万 tokens 上下文、8 bit KV 精度和 16 bit 索引精度为前提，估算 DeepSeek V4 只需要约 5.48GB HBM，而 GLM5 约为 60GB，Qwen3-235B-A22B 约为 89GB。

长上下文和 Agent 任务真正贵的地方，不只是模型生成本身，还有缓存、显存、带宽和重复上下文搬运。

一个 Code Agent 处理项目时，可能要反复读取同一个代码库结构、同一批文件、同一段任务历史、同一套系统提示词和同一批测试日志。若每一轮都按完整上下文重新计费，长任务很快会变贵。缓存命中价格下降后，重复上下文的成本会明显变低。

DeepSeek 近年来在 MoE 架构、长上下文、KV Cache 压缩和推理效率上持续投入的表现有目共睹。降价是技术迭代后的必然结果，也将彻底搅动 AI 编程市场格局。

为什么必须做中国版「Claude Code」？

最先被牵动的，是 AI 编程工具的订阅模式。

市面主流 AI 编程工具均推出 Coding Plan 月付订阅，为用户提供代码补全、模型调用、Agent 执行等权益。在轻量化补全时代，单次调用消耗极低。

但 AI 编程已从单次补全迭代为全流程 Agent 自动化编码，模型可独立完成代码修改、测试运行、报错修复，单次任务 Token 消耗大幅提升。

当底层 API 又同时大幅降价，Coding Plan 也必须找到新的支撑点。这个支撑点，更可能落在工程能力上——比如能不能更好地读懂项目结构，能不能精准选择上下文，能不能控制 tokens 消耗，能不能稳定修改代码，能不能处理 Git、终端、CI/CD，能不能在企业环境里管理权限和审计记录？

同样要重新定位的，还有 API 中转站。对个人开发者来说，便宜和好用仍然重要。但对企业来说，稳定、可审计、可控、可迁移更重要。

沿着这个逻辑继续看，Coding Plan 和中转站的改变只是表层。低价之后更值得追问的，是开发者入口究竟掌握在谁手里。

Google CEO Sundar Pichai 最近接受了《Hard Fork》采访，他首次公开承认，Google 在文本、多模态、语音、推理和整体智能上都很有竞争力，但在 agentic coding 这一类能力上，尤其是工具调用、指令跟随和长周期任务，目前还有差距。

他还提到，更关键的是把模型放到真实世界里使用，让数据回流，继续迭代。Pichai 特别说到，coding 是一个需要接触 data flows（数据流）的领域。

终端工具能看到开发者如何提出任务，如何追问，什么时候接受建议，什么时候放弃，什么时候要求模型继续修复。它还可以通过测试结果、终端日志、文件变更和 Git 提交，判断一次 Agent 执行是否完成任务。这类数据，对 coding model 和 Agent 产品都非常有价值。

从公开招聘动作看，DeepSeek 近期围绕 Agent 的动作也变得密集。

我们也可以看到岗位里出现了 Agent 深度学习算法研究员、Agent 数据策略工程师、产品经理、研发工程师等角色。更关键的是，DeepSeek 资深研究员陈德里直接发出招聘信息，提到要从零开始构建 Code Harness。

如其所说，Model + Harness = Agent，在 Agent 产品中，模型负责理解和生成，Harness 负责把模型能力带入真实工程环境，相当于模型外面那套「执行系统」。

DeepSeek 版 Claude Code 不能只给开发者一个对话框，而要给开发者一个能持续执行任务的工程系统。

崔添翼加入 DeepSeek 后受到关注，也和 Code Agent 的工程属性有关。

公开信息显示，崔添翼本科毕业于浙江大学计算机系，曾因信息学竞赛保送浙大，6 次获得 ACM 亚洲区域赛金牌，之后在 Jane Street 工作 9 年，并联合创立 TSY Capital。

Code Agent 的难点不只是生成代码，还要在真实项目里持续执行任务。量化交易系统长期强调低延迟、稳定性、自动化执行和风险控制，这些经验放到 Agent Harness 上，至少在工程范式上是相通的。

而 Agent 工具的产品能力，不只包括写代码，也包括权限、审计、数据隔离和安全策略。

这反过来给 DeepSeek 这样的国产模型提供了机会。如果 DeepSeek 能把低成本模型、Code Harness、本地部署、企业级权限控制结合起来，它在政企、金融、制造、能源等对数据敏感的行业里，会有更强的替代价值。

DeepSeek 做中国版 Claude Code 的逻辑也正在于此：低价 tokens 把更多开发者吸引进来。低缓存价格让 Agent 任务运行成本下降。Code Harness 让模型进入开发环境。真实工作流又会反过来帮助 DeepSeek 改进模型和产品。

就像滚下坡的雪球，越滚越大，滚得越快。降价只是推下山的第一把力，往后它会自己越滚越沉，谁也拦不住。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

「如果这条推文获得了一个赞，Codex 重置额度限制。」

已经数不清这是今年以来，第几次的限额重置了。奥特曼前两天在 X 发文，让 Codex 负责人 Tibo 再一次重置了使用限额。

网友做了一张梗图，每当一个人想走向 Anthropic 或 Gemini 时，奥特曼站在后面默默按下 Codex 限额重置的按钮，这个人就会回头，然后被拉回到 OpenAI。

OpenAI 这半年也因为出圈的 Codex 收获了一大批的新用户。外媒报道 OpenAI 第一季度营收达到了 57 亿美元，比 Anthropic 高出 10 亿美元，Codex 是主要因素。

我们在之前介绍过 Codex 的入门指南，从 ChatGPT 官网下载安装到连接手机上的 ChatGPT App 实现远程控制，都有详细的步骤。

不少读者在评论区留言，Codex 确实好用；也反馈了不少问题，像是下载 Codex 后仍需绑定手机号才能使用。我们的测试也发现登出之后再登录，确实会被要求绑定手机号。

这个时候，建议先在浏览器中进行登录，即主动打开网址 https://auth.openai.com/log-in 提前登录好。再回到 Codex 中登录，弹出的登录链接，只会显示要求授权即可，不会再有绑定手机号的提示。

不同的账号可能会遇到不同情况，大概也是眼下 OpenAI 在 Codex 这边投放了太多的算力，不希望被用户太轻易地薅走羊毛。

今天凌晨，Codex 又上新了一大波的新功能，现在只要按下电脑上的 Command-Command 键，就可将应用程序窗口附加到 Codex 的对话线程里。Codex 会自动获取窗口的屏幕截图和文本，包括屏幕上不可见的内容，作为对话的上下文。

以前还要自己手动截图，现在 Codex 不仅能处理截图，还能直接读到一整个应用窗口的信息。

此外，上次更新的在 ChatGPT App 内操作电脑上的 Codex 这一次也升级了，之前的选项是保持 Codex 常开，现在是即便电脑锁屏了， ChatGPT 同样能远程操作 Codex。

/goal 命令这次也从实验室版本来到了正式推出。之前我们分享多 Agents 协作时，就有读者提到 /goal 功能和多 Agents 类似，它们都是把一个任务当做一个项目来进行管理，有完整的目标生命周期，通过不同的机制来完成迭代。

/goal 最早是 4 月底出现在 Codex CLI 中，有了它确实也能更好的处理越来越多的长任务。

不过遗憾的是，无论是按 command 还是锁屏后继续远程控制，这些都是 macOS 平台的更新，对于 Windows 用户，只能等 OpenAI 的推进。

有网友说，「Mac 用户总是能享受到好东西，而 Windows 用户只能眼巴巴地看着，哈哈。」不得不说，Mac mini 作为 AI PC 的含金量还在增加。

省去很多麻烦的应用快照

这项功能叫 Appshots，开启它的方式也很简单，更新 Codex，在应用设置下，找到「应用快照」，就有一段视频教程，并且可以自定义快捷键。

不过需要注意的是，按下 command 键是指按下键盘上，空格键左右两边的两个 command 键，而不是单击两次。

在任何界面同时按下两个 command 键之后，Codex 会自动捕获页面截图，并快速打开 Codex 将截图放在输入框。我们可以针对这个窗口快照提出问题。

但基于 Codex 的能力，这个窗口快照不单是一张图片的 OCR 文本提取。Codex 可以再这个窗口的基础上，进一步使用 Computer Use 和 Chrome 自动化等功能。

例如，我们在飞书文档的文章开头同时按下了 command 键，然后告诉 Codex 要求它看看这个窗口讲了什么。Codex 会使用 Google Chrome 的工具，自动对网页进行浏览以获取更多的上下文。

这是它和一般截图最大的差别，除了把截图内容放进了上下文，Codex 还会自动把窗口的信息，来自哪个应用等状态信息，同步发送给 Codex。

例如我们在微信里阅读公众号时，也能按下两个 command 键，开启 Appshots。但这里有一个小 Bug，当 Codex 使用 Computer Use 来控制微信的窗口，上下滑动公众号，退出图片的预览时，直接把微信给登出了。

官方在宣传视频里介绍 Appshots 时，同样不是简单地将它作为一张截图来使用，而是结合了 Computer Use 和 Google Chrome 来使用。

像是直接要求它修改我们的备忘录内容。

还有也不用再复制什么图片，直接 command+command 然后告诉他生图提示词，对图片进行编辑。

就是这种应用多做了一步的感觉，我们就减少了很多 AI 的使用负担，让 Codex 的体验也变得更加丝滑。

/goal 的保姆级使用指南

在对话框内输入斜线，我们就能看到有「目标」的快捷选项，「设置 Codex 将持续努力实现的目标。」

目标存在的价值是作为一个独立存在的任务定义，而不是普通的对话提示词。Codex 会反复根据目标来判断「还该做什么」和「是否已经完成」，自动一轮接一轮的推进，直到任务完成、暂停或者烧到 Token 上限。

这两个判断也是目标的核心机制，即「延续」和「完成审计」。「延续」是在每轮结束后，自动注入提示，让模型决定下一步。「完成审计」是要求模型对照目标逐条核对。

Goal 模型最容易踩坑的地方，就是随手写一句话放进去。要写好一个 Goal，关键原则是 Codex 要能判断是否完成了。

官方在帮助文档也提到，好的目标应包含具体的结果、可衡量的指标或测试标准。他们给了一些案例，像是将项目从一种编程语言迁移到另一种编程语言。

把这个项目从 JavaScript 迁移到 TypeScript。

 

要求：以 strict 模式编译通过，不允许出现显式的 any 类型。

还有更直接的要求，「把首页的可交互时间压到 1 秒以内。」

这些例子都是有着具体的可验证标准，并不是「优化一下」、「完善一下」这种虚词。

如果没有想到具体标准，Codex 建议是先跑 /plan。让 Codex 和我们讨论一轮，把验收标准定清楚，再切回普通模式下 /goal。

还有一些实用小建议是，可以在 goal 文本末尾加一句 Use a token budget of 80000 tokens for this goal，用来设置 Token 预算。

以及不要在一个会话的开头就发送 /goal，而应该是先给这个项目其他的需求，有一定的雏形，再给它目标。

锁屏了，Codex 还能操作你的电脑

除了这些大的更新，Codex Thursday 还带来了很多体验升级的功能。

Locked Computer Use 是最值得一提的一项，简单来说它就是能让 Codex 在 Mac 锁屏之后，仍然能在后台操控桌面应用完成任务。

网友对这项功能的评价，都集中在这是突破性的，这很有未来感的同时又很吓人。

如果 Codex 能够在没有活跃用户会话的情况下运行 Mac 应用，这或许是迈向持久 Agent 基础架构的第一步。

若要使用锁屏后继续操作的功能，必须由我们手动开启，并且输入密码。打开的方式同样是在设置里，找到电脑操控，开启锁屏操作。

正常的 Computer Use 需要屏幕处于解锁状态，Codex 才能「看到」并操作界面。这个功能打破了该限制，我们可以把 Mac 合上或锁屏，然后从手机、iPad 或另一台设备远程发起 Codex 任务，它会自动临时解锁、完成操作、然后重新锁上。

Codex 为此安装了一个 Apple Authorization Plug-in（苹果官方授权的认证插件），接入 macOS 的解锁流程。当有活跃的 Computer Use 任务时，插件允许 Codex 临时解锁屏幕；任务窗口之外，解锁权限直接拒绝。

OpenAI 也对这个功能做了几层约束，防止它变成其他危险操作的后门：

• 解锁窗口极短，仅限当前 Computer Use 操作期间有效
• 覆盖所有显示器，临时解锁期间屏幕内容对物理旁观者不可见
• 检测到本地输入立即重锁——有人碰了键盘或鼠标，自动暂停，要求手动解锁
• 这个路径只对 Codex 开放，其他应用或本地进程无法借道

另一项高级标注的功能，则是我们在使用 Codex Vibe Coding 某个网页时，通过 Codex 内置的浏览器打开，同时还提供了直接在网页内容上进行修改的标注工具。

除了 Codex 这一系列的更新，今天 ChatGPT 也上新了一项新功能，ChatGPT 现在可以直接在 PowerPoint 中创建和编辑演示文稿，并且还能使用 GPT Image 2 生成用于 PPT 里面的图片。

Codex 越来越好用的同时，钱包燃烧的速度也在加快。

我们的 Pro 账号，每周使用限额要到 27 号重置，但是今天（22 号）就只剩下 10% 了。只能在心里默默「作法」，祈祷它再一次重置。

如果这篇文章获得了一个赞，你的 Codex 有可能重置额度限制。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

龙虾之父一个月消耗 6030 亿 Token，总花费金额高达九百万人民币。

移动联通电信，三大运营商都在推 Token 套餐，199 送千兆宽带还有 1 亿 Token，了解一下？

从硅谷到国内大厂，Tokenmaxxing 成为公司的主流，谁消耗 Token 多，谁就是 AI 时代的好员工。

00 后校友向母校捐赠 20 亿 Token，被网友调侃按 DeepSeek 5 元/亿 Token 计算，只要 100 元。

Token 在半年内完成了一次身份跃迁：从技术术语，到 KPI，到话费套餐，到捐赠货币。它成了 AI 时代的「度量衡」，唯一的问题是，没人说得清它到底在度量什么。

我们自己买 Token，用公司的 Token，部署了一堆 Agent，代码、论文、周报都是 Token 烧出来的。

而另一边是，大厂的员工由于 Token 消耗排行榜的原因，开始拿着公司的 Token 处理私事、玩游戏、开发数十个没什么用的子 Agent 来提升自己的排名。

「回报」这件事很难量化，但「使用量」可以量化。

于是所有人都选择了那个容易量化的东西。这不是 AI 时代的新问题，这是管理学的老病。

用 AI 消灭狗屁工作的公司，正在制造新型狗屁工作

亚马逊，那个裁员裁到大动脉，把自己的网站都变成 404 的小狗，最近又被爆出了新的「笑料」。

原本被寄予厚望、用来消灭「狗屁工作」的 AI，最终却沦为制造新型「狗屁工作」的源泉。

据《金融时报》报道，为了逼迫员工拥抱 AI，亚马逊搞出了一个极其复古的管理手段：「Token 消耗排行榜」，追踪每个员工的用量。

公司强制要求超过 80% 的开发者每周必须完成 AI 使用指标，甚至将消耗 Token 的数量作为考核标准。

打工人的反应也很直接，既然公司用这种指标来考核，大家干脆用魔法打败魔法，开启了「Tokenmaxxing（最大化消耗 Token）」战术。

刚好亚马逊内部上线了一个叫 MeshClaw 的 AI Agent，它能发起代码部署、整理邮件、操控 Slack。公司内部备忘录里描述它是：「它在夜间做梦来整合白天所学，在你开会时监控你的部署，在你醒来前替你分类邮件。」

于是 MeshClaw 就成了一个刷排行榜的工具。开发者开始用它来规划旅行、处理私人邮件、让 AI 分析产品经理在 Slack 上说的蠢话。

在职场匿名社区 Team Blind（一个面向 Google 和苹果等公司认证员工的留言板）上，一位亚马逊员工的发言被疯狂点赞。

我疯狂燃烧 Token，就是为了骂我的产品经理。每当他在 Slack 里说屁话，我就把聊天记录扔给 AI，启动 10 个子智能体去全方位深度分析并吐槽他。这绝对是 GPU 算力的完美用途。

亚马逊在回复《金融时报》时提到，MeshClaw「每天帮助数千名员工自动化重复性工作」，公司「致力于负责任地部署生成式 AI」。同时，公司表示 Token 统计数据不会用于绩效评估。

但员工的说法是：「经理在看这个数据。当他们追踪用量时，就会制造扭曲的激励，有些人在这上面很有竞争心。」

公司说不算 KPI，但经理偷偷在看。这和大厂说「年终奖与 996 无关」是同一个套路。

不只是亚马逊，Meta 员工也在做同样的事。

早在四月份，The Information 就曾报道，Meta 公司的一名员工利用内部数据，在公司内网创建了一个仪表盘，让同事们可以竞争成为公司排名第一的 AI Token 用户。

这份排行榜汇总了超过 85000 名 Meta 员工的人工智能使用情况，并列出了排名前 250 位的超级用户，其中扎克伯格没能进入前 250 名。

而这份排行榜在两天后就下架了，Meta 在回应媒体查询时发声明，「该员工自行决定撤下仪表盘；Meta 并未要求采取此行动。」

当你笑完这份排行榜的不合理之处，转念一想就会发现，这其实是大多数公司的现状。还没想好 AI 怎么发挥作用，但是就先裁员了；还没想好 Token 怎么用，就匆忙把它作为生产力的衡量工具。

一个月 6000 亿 Token 烧出了什么

Token 消耗排行榜的荒诞还没消化完，更魔幻的事又来了。

三位 00 后校友向母校郑州西亚斯学院捐赠 20 亿 Token，网友按 DeepSeek 的价格算了算，说这就值 100 块。

后来有媒体澄清，这 20 亿 Token 不只是 API 调用量，还包括生成工具使用权和平台积分。但「捐 Token」这件事本身已经够魔幻了。

三位校友说自己实力还不够捐教学楼，所以捐 Token。这个时代的慈善逻辑也在刷新：捐不起楼，捐算力。

Token 存在的价值在刷新，Token 的使用边界也在刷新。

GitHub 前 CEO、现任 Meta 超级智能实验室 CEO Nat Friedman，在一场公开活动上讲了个故事。某天，他的 OpenClaw 判断他喝水不够，他随手给了指令：「不惜一切代价确保我补充足够的水分。」

OpenClaw 很快行动了。它指示他去厨房喝一瓶水，顺带告诉他，正在通过家里的摄像头监控他是否真的去喝了。他照做之后，OpenClaw 发来一张他喝水的截图，附言：「干得好。」

原本只是手机设置一个提醒每日喝水，但现在是 Token 疯狂地燃烧，调用摄像头来为「提醒你喝一杯水」服务。

而当 Token 的消耗不再重要，不需要考虑 Token 的价值和使用边界，我们又会拿他来做点什么。

OpenClaw 最近有意思的事，还得是龙虾之父 Peter Steinberger 周六在 X 的分享，他发了一张 CodexBar 的截图，配文「CodexBar 最新更新让 API 费用显示得更加友好。」

但很快有网友发现这张截图了不起，三十天用了 6030 亿 Token，累计消耗的金额更是达到了 130万美元，约合人民币 930 万。

评论下面都是各种质疑，交付了多少代码，消耗的 Token 和最终能用的代码之间比例是多少？到目前为止，你做出了什么有用的东西吗？要不是入职 OpenAI，Codex 这 Token 能让你这么消耗吗？

兄弟，你最好拿出点儿价值百万美元的工程师都做不到的东西，不然这可能就是前沿实验室泡沫破裂的开端了。而且这还是补贴价格，我的天。如果是实际成本，价格肯定更高。

龙虾之父在评论区回复了这些声音，他提到如果关掉 Fast Mode，成本就能降 70%。而且，自从 OpenClaw 被 OpenAI 买走之后，负责该项目就只剩下三个成员，他们在 Codex 上运行了 100 个实例。

这些实例会自动处理软件开发流程中的各种问题，像是代码的提交、Bug 修复、功能的更新等。

但是光看 OpenClaw 的更新，真的需要 130 万美元来支撑吗？他又提到自己在做一些除了 OpenClaw 之外的创业项目，以及他是在探索一个问题：如果 Token 成本不重要，软件会怎样被构建。

这个好问题。但 130 万美元花下去之后，他也还没有得到答案。

这可能是 2026 年最贵的一个问号。

即便是有无比丰沛算力的人，现在似乎也不知道这些 Token 可以用来做什么。

大厂高管们看着财报上巨额的 GPU 采购费，迫切需要向董事会证明这笔钱没白花。既然「重构真实业务流」太难、太慢、太需要魄力，那就退而求其次，去考核「Token 的消耗量」。

员工们甚至一开始就没被问过「你觉得 Token 该怎么用」，他们被问的是「你这周用了多少」。

当一个工具的考核标准是「消耗量」而不是「产出」，它就不再是工具了。它是燃料，唯一的使命就是被烧掉。至于烧完之后驱动了什么，没人真的在意。

因为一旦认真追问，很多人会发现，自己烧掉的那些 Token，和年初裁掉的那些人一样，都没换回任何东西。

我们正在经历的，是一场所有人都假装看懂了规则的游戏。公司假装知道怎么用，员工假装在认真用，投资人假装看到了回报。

唯一真实的，只有不断超支的账单。

Token 终究会找到它真正的用途，成为真的「新质生产力」。但那一天到来之前，我们在烧掉动辄上亿的 Token 之前，可以问问自己真的有必要吗

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

谁不想在自己的电脑上养一只小宠物，打开电脑，它就坐在那里看着你工作。

OpenAI 最近在 Codex 上的更新，引入了类似电子宠物 Tamagotchi 的桌面悬浮伴侣。

我们可以在摸鱼的时候，把鼠标悬浮到小宠物上逗它，还能拖着它在屏幕的各个位置游走；而在工作的时候，这只悬浮宠物还会实时显示 Codex 的工作状态。

和之前 Anthropic 在 Claude Code 终端里推出的像素宠物不太一样，Codex 的这只会全局地在我们的电脑上呈现。无论切换到哪个 App，它都在那个角落。

以前是人与人的聊天软件里，像是 QQ，需要一个 QQ 宠物从桌面右下角蹦出来，给它取一个名字，建立情感的联系，而它会告诉我们消息来了。

现在这件事，来到了人与 AI 的故事里。

从微软大眼夹到 Mac 访达笑脸，万物皆可宠物化

Codex 官方内置了 8 款像素风的基础宠物，包括默认原始的经典 Codex 形象，还有一只整洁的小鸭子 Dewey、适合快速迭代项目的火球 Fireball，以及一只小小的蓝屏捣蛋鬼 BAOD（Blue Screen of Death） 等。

我们可以在 Codex 设置>外观 最下面的宠物部分找到配置的相关信息。

但真正有意思的是，Codex 的自定义宠物功能。

通过使用 Codex 自带的 /hatch 指令，我们可以上传任何图片，Codex 会自动把它孵化成一个动画宠物，并保存在本地文件夹中，方便我们打包分享给其他人。

使用 /hatch 指令之前，我们还需要输入命名 $Skill Installer hatch-pet 来安装自定义宠物的 Skill。它会自动从 OpenAI 的官方 GitHub 仓库里面，下载对应的 Skill 文档。

准备就绪，我们使用 hatch pet Skill 输入 $hatch-pet 做一个 labubu 的桌面宠物。

Codex 会自动按照 Skill 里的流程，先生成一张主图，根据这张主图再生成 idle、running-right、running-left、waving、jumping、failed、waiting、running、review 等多种不同状态图片。

每一种状态，Codex 都会生成 4-8 帧的图片。

等待它生成全部状态的图片，合成为动画，我们就能得到一个自定义的桌面电子宠物。

社交网络和开发者社区也利用这一功能，创作了大量能提升 vibe coding 幸福感的桌面宠物。

像是恶搞 Anthropic CEO，做了一个愤怒的达里奥，还有奥特曼，「一个有趣的像素风格 Sama 灵感宠物，带着焦虑的斜视眼睛，头上戴着太阳镜，穿着灰色T恤和牛仔裤，散发出混乱会议室的能量。」

一些怀旧党立刻复刻了微软经典的大眼夹（Clippy），那个在我们新建文件、打开文件夹，都会跳出来，多两句嘴的桌面宠物，用 Codex 获得了新生。

苹果粉丝，就用 Codex 这套 Skill 做了一个相当生动的 Mac Finder（访达）笑脸小人 Lil Finder Guy，让它悬浮在程序坞上方，仿佛系统原生的一部分。

甚至还有人做出了乔布斯版本的宠物，以及像是 DeepSeek 的那只鲸鱼等。

在极短的时间内，PetShare 和 PetDex 这样的社区驱动型宠物图鉴网站，如雨后春笋般涌现。

多邻国的那只猫头鹰、经典动漫角色龙珠里的悟空、神探福尔摩斯、旅行青蛙、哈利波特、哆啦 A 梦等等，都成了 Codex 的热门宠物选择。

为了给这波热潮添把火，OpenAI 甚至官方下场举办了比赛：只要你生成的宠物被官方选入「最喜爱的 Top 10」，就能获得 30 天的 ChatGPT Pro（200 美元/月）奖励。

我们也在 Codex 里生成了一些小宠物，都是通过简单的两三个字的提示词。像是「做一个原神里旅行者荧的桌面宠物」，不过需要注意的是，生成自定义宠物需要的时间较长，同时消耗的额度也比较大。

更多 Codex 桌面宠物案例：

PetShare：
https://codex-pet-share.pages.dev/#/?sort=popular

PetDex：
https://petdex.crafter.run/

电子宠物是 AI 的灵动岛

把这些自定义的宠物放到 Codex 里面也非常简单，可以直接下载文件压缩包，复制到对应的文件夹，然后在设置里进行选择。

直接在 Codex 中输入简单的 /pet 指令，我们的桌面上也能快速召唤出一个活蹦乱跳的电子宠物。

这个电子宠物，除了可爱，还确实有一点用处。

它不写代码，不 debug，唯一的工作是偶尔弹出对话气泡，告诉我们 Codex 正在后台做什么——「思考中」「任务完成」「需要你来决定一件事」。

任务完成了，点它一下，直接回复，继续。

以往我们无论是用 Claude Code、OpenClaw，还是就在 DeepSeek 里面聊天，把一个任务交给他们，总是时不时需要切回对应的窗口，看看它是不是卡住了，是不是还在思考。

现在，这只悬浮在屏幕最顶层的宠物，会通过气泡和动作告诉我们 Codex 的后台状态。

基于生成的多种状态，这只桌面宠物，如果开始在挠头了，就说明它正在「思考」；它弹出气泡，就说明它完成了任务，或者需要我们提供进一步的输入。

更有意思的是，如果我们在它发消息时点击它，就可以直接开启一条回复 AI Agent 的双向通道。它就像是 macOS 桌面上的一个跨应用灵动岛，让我们在专注当前工作流的同时，对 AI 的进度了如指掌。

一直在更新的 Codex

电子宠物的功能在社交媒体上给 Codex 带来了又一波的好评，网友们都在说，这也太可爱了，情绪价值非常到位。

看着自己喜欢的小宠物在桌面上跳动，要比看着进度条转圈要心情好上不少。

但 Codex 这次在更新桌面宠物的同时，还悄悄放了两个新功能。

Codex 现在能够自动检测我们的电脑上，是否有其他 AI 编程工具，比如 Claude Code 留下的配置文件。

一旦检测到类似如 CLAUDE.md 的文档，它会主动建议并一键导入所有的插件、项目约定和自定义规则。

如果你也是为了避开不同平台的使用频率限制，让在多个 AI 之间反复横跳，这项更新降低了一定的切换成本。

另一项更新是在 Codex 内新增了「听写词典」，允许我们预先录入个人的常用缩略语和短语。

对于习惯用语音让 AI 写代码的用户来说，专有名词和缩写经常会被错误识别，导致反复修改。现在通过添加对应的条目，可以让减少我们纠错的麻烦。

OpenAI 也开始用最频繁的更新，把用户留在自己的生态里。

配置文件的跨端迁移、更懂用户的语音工具，加上那些在屏幕上挥手、打盹、偶尔还会抖动一下的悬浮宠物……

奥特曼在 X 发文说，感觉 Codex 正在经历 ChatGPT 时刻。

虽然事后奥特曼解释是 Goblin 时刻，但是 Codex 这接二连三的更新，也能看到 Codex 确实正在向一个更完整的、具备极高粘性的桌面「超级应用」进化。

在 AI 能力逐渐同质化的今天，产品的魅力和情绪价值，变得和代码生成能力一样重要。

就像那位做出 Lil Finder Guy 宠物的网友，分享了一段 AI 发给他的话，宠物用乔布斯的腔调说：

致敬那些小小的存在，那些悬在 Dock 上摇摇晃晃、时不时打个盹的小帮手，它们让工作变得轻一点。致敬 Codex 宠物。

好了，看着桌面上那个正冲我挥手的像素小怪物，我可能也得出门去溜达一圈了。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

一、一个反直觉的事实

先说一个看起来有点反常识的事：LLM 本身是无状态的。

每次调用模型，本质上就是一次”文本补全”——你扔一段 prompt 进去，它根据这段 prompt 续写一段输出，然后整个过程结束。下一次再调用，模型对上一次的事一无所知。从机制上讲，它和 2020 年的 GPT-3 没有本质区别，都是一次性的补全器。

但 2024 年之后，我们看到的 Claude Code、Cursor Agent、各种 deep research 工具，明明可以连续工作几十分钟、调用几十个工具、修改几百个文件，看起来”自主”得不得了。

这两件事怎么对得上？

答案藏在外面那个 while 循环里。

Agent ≠ 模型
Agent = 模型 + Loop + Tools + Context 管理

模型本身没有变，变的是包在它外面的那层东西。这层东西现在常被称作 harness（脚手架），而 harness 里最核心的部件，就是 Agent Loop。

这篇文章想回答三个问题：

1. 这个 loop 长什么样？
2. 它为什么这样设计？
3. 它什么时候会失效？

二、最小可运行的 Agent Loop

把所有花哨的东西都剥掉，一个 Agent Loop 的本质大概是这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

messages = [{"role": "user", "content": user_input}]

while True:
    response = llm(messages, tools=available_tools)
    messages.append(response)

    if response.stop_reason != "tool_use":
        # 模型没要求调用工具，说明它认为任务结束了
        return response.text

    # 模型要求调用一个或多个工具
    for tool_call in response.tool_calls:
        result = execute(tool_call)
        messages.append({
            "role": "tool",
            "content": result
        })
    # 进入下一轮，让模型看到工具结果，决定下一步

就这么二十行。这就是 Claude Code、Cursor、几乎所有 coding agent 的核心。

拆解一下，里面只有四个动作：

1. 模型推理：把当前 messages 丢给 LLM，让它产出下一步的 response
2. 工具调用判断：如果 response 里有 tool_use，就执行；如果没有，循环结束
3. 工具执行：在沙箱/真实环境里跑这个工具，拿到结果
4. 结果回灌 context：把工具结果塞回 messages，进入下一轮

到这里，请允许我强调一个关键认知：

所谓”Agent 的自主性”，本质就是模型在每一轮看到更新后的 context，自己决定下一步。没有任何魔法。

不是模型变得”会规划”了，是循环让它有机会根据上一步的结果，再做一次补全。它的”思考”只发生在每一次模型调用的那一瞬间，loop 只是一遍遍把它叫醒，告诉它”环境又变了，你再看看”。

理解了这一点，后面所有的工程设计，都只是这个最小循环的变体。

三、Loop 的关键设计决策

最小循环能跑，但不够用。一旦把它放到真实场景里，会立刻撞到一堆问题：循环什么时候停？context 越涨越长怎么办？工具调用错了怎么办？要不要并行？

围绕这些问题做的工程取舍，决定了一个 Agent 框架的性格。下面是五个最关键的决策维度。

1. 终止条件：什么时候跳出 loop

最朴素的写法是”模型不再要求调用工具就停”，但这在生产里远远不够。常见的多重终止条件：

• 模型主动 stop：response 里没有 tool_use，正常出口
• 达到 max_iterations：硬性步数上限（比如 50 步），防止失控
• 检测到循环：连续几次调用相同工具+相同参数，强制中断
• 用户中断：Ctrl+C、关闭对话窗口
• 预算耗尽：token 数或时间超限

每个出口背后都是一次工程权衡：上限太小，复杂任务做不完；上限太大，一旦模型卡住就烧钱。

2. Context 增长策略：长任务下怎么办

工具结果一律塞回 context，会带来一个朴素但致命的问题——context 是线性增长的。

一个改 50 个文件的任务，可能要读 100 次文件，每次读取的内容都进 context。跑到一半，context 已经塞了几十万 token，模型注意力开始稀释，关键信息被淹没。

工程上有几种常见思路：

• 全量回灌：最简单，短任务够用，长任务必崩
• 滑动窗口：只保留最近 N 轮，老的丢掉，但可能丢关键信息
• 摘要压缩：触发阈值后，让模型自己总结前面的内容，用摘要替换原文
• 分层压缩：Claude Code 的 /compact 机制就属于这一类——保留最近上下文 + 历史摘要 + 关键信息（如已修改的文件列表）

这一项是目前差异最大的设计点。后面会看到 learn-claude-code 项目专门有一节叫 s06_context_compact，就是为了解决这件事。

3. 工具选择机制：模型怎么”选工具”

两种主流做法：

• 原生 function calling：通过 API 把工具 schema 一并传给模型，模型在 response 里直接产出结构化的 tool_use 块。Claude、GPT、Gemini 都支持。优点是稳定，几乎不会出格式错误。
• 提示词约定格式：在 system prompt 里告诉模型”想调用工具就输出 <tool>...</tool> 这样的 XML”，外层用正则解析。早期 ReAct 论文就是这么做的，胜在通用，任何模型都能用。

现在新项目基本都默认用 function calling，但提示词约定法在一些场景仍有价值——比如要让一个本地小模型当 agent，或者要做更细粒度的格式控制。

4. 错误处理：工具调用失败怎么办

工具会出错。文件不存在、API 超时、参数类型不对、权限不足……

两种处理思路，本质是信任谁：

• 塞回 context 让模型自我纠正：把 error message 当作普通的 tool_result 回灌，相信模型能看懂错误并调整。优点是灵活，模型常常能从”file not found”反推出”我应该先 ls 一下”。
• 外层拦截：harness 直接处理特定错误类型，比如重试、降级、报警。优点是可预测。

实践里通常是混合策略：致命错误外层拦截，业务错误丢给模型。这件事的判断需要工程经验。

5. 并行 vs. 串行：单 Agent 还是多 Agent

单 Agent 的极致是一轮内并行调用多个工具。Claude 现在原生支持一次返回多个 tool_use 块，harness 并行执行后一次性把所有结果回灌。这能显著降低延迟。

更复杂的是多 Agent 协作：主 agent 派发子任务给子 agent，子 agent 独立 loop，结束后回报。这里立刻冒出一个新问题——路由：主 agent 怎么知道哪个子 agent 适合这个任务？是基于 metadata 标签匹配，还是让主 agent 读子 agent 的描述自己判断？这两种思路的优劣，是另一篇文章的话题了。

四、从 50 行到 1000 行：一个 Agent 是怎么长出来的

讲完抽象的设计维度，看一个具体的项目——开源项目 learn-claude-code。

这个项目的好处是：它把一个 nano 版 Claude Code 的演化拆成了 12 个递进的 Python 脚本，每一步只引入一个新机制。从 s01 到 s12，代码从大约 50 行长到 1000+ 行。

读它，相当于把上一节的设计决策亲眼看一遍怎么落到代码里。

下面挑几个最关键的节点：

s01 Agent Loop：朴素的 while

1
2
3
4
5
6

while True:
    response = model(messages, tools)
    if response.stop_reason != "tool_use":
        return response.text
    results = execute(response.tool_calls)
    messages.append(results)

这就是上一章伪代码的真实版本。50 行，能跑，能调用 bash 完成简单任务。这是一切的起点。

s02 Tool Use：从一个工具到多个工具

引入 read_file、write_file、bash、grep 等多个工具。重点不在工具本身，而在 wire——怎么把工具 schema 注册给模型，怎么 dispatch 到真实函数。

到这里，agent 已经能完成”读文件、改文件、跑测试”这种基础编程任务了。

s03 TodoWrite：对抗”目标漂移”的第一道防线

一个有意思的设计：让 agent 自己维护一个 todo list。

为什么？因为长任务里，模型很容易跑偏。任务一大，model 在第 30 轮已经忘了第 1 轮的目标是什么。TodoWrite 工具强制 agent 在开工前把任务拆成清单，每完成一项划掉一项。

这本质上是用工具调用替代记忆——不指望模型记住，而是把目标固化成 context 里随时可见的状态。Claude Code 现在就是这么做的，效果非常显著。

s04 Subagent：什么时候该拆出去

主 agent 不是万能的。当一个子任务的 context 会污染主 agent 的判断（比如要读一大堆代码才能定位 bug），就该把它丢给子 agent。

子 agent 有自己独立的 loop、独立的 context，跑完只把结论返回给主 agent。这是用 context 隔离换取主 loop 的清晰。

s06 Context Compact：长任务的生存策略

直接对应第三章讲的”context 增长策略”。当 messages 长度超过阈值，触发 compact：让模型把前面的对话总结成一段摘要，用摘要替换原始消息，保留最近几轮原文。

这是目前所有长任务 agent 的共同方案。没有 compact，agent 就走不远。

s07–s12：再往后

任务系统、后台任务、多 agent 团队、worktree 隔离……每一层都是在同一个 loop 上叠加工程能力。但本质都没变：还是那个 while 循环。

读完这个项目，最值得记住的是它的核心宣言：

The model is the agent. The code is the harness.
模型才是 Agent，代码只是脚手架。

这句话听起来像废话，其实暗藏一个反直觉的判断——你写的那一千行 harness 代码，不是在让 Agent “更聪明”，只是在帮模型别搞砸。模型本身已经具备 Agent 能力，harness 的工作是给它工具、管好上下文、防止失控。

Harness 越薄，说明模型越强。

五、Loop 的边界与失效模式

Agent Loop 不是银弹。在生产里，它会以几种典型方式翻车：

1. 上下文窗口爆炸

最常见。长任务跑到一半，context 涨到几十万 token，模型注意力被稀释，开始重复读同一个文件、忽略关键约束。Compact 是缓解，但不是根治——压缩本身也会丢信息。

2. 工具调用幻觉

模型有时会编造不存在的工具，或者给真实工具传错误参数（比如发明了一个本不存在的 flag）。这件事在小模型上尤其严重。缓解办法是收紧 tool schema 的描述、用 function calling 而不是提示词约定，以及在 harness 里做参数校验。

3. 死循环

模型反复调用同一个工具拿同样的结果，不收敛。常见于”修一个 bug 但根本没想清楚”的场景：跑测试 → 失败 → 改一行 → 跑测试 → 失败 → 改回来。需要在 harness 里检测这种模式并强制中断。

4. 目标漂移

多轮之后忘了原始任务。前面提到的 TodoWrite 是一种缓解，更激进的做法是定期”自检”：让 agent 每隔 N 轮 reflect 一次，对照原始目标审视当前进展。

工程上常见的缓解组合是：context 压缩 + 工具白名单 + step budget + 显式 reflection 节点。每一项都不彻底，但叠在一起能撑很久。

六、Agent Loop 是临时方案，还是终极形态

最后留一个开放问题。

回看现在所有的 Agent 框架——Claude Code、Cursor、LangGraph、OpenClaw、learn-claude-code——本质都在围绕同一个 while 循环做工程优化。终止条件、context 压缩、子 agent、todo 管理……每一项都是因为模型本身做不到，所以 harness 替它做。

但模型还在变强。

Claude 已经支持 extended thinking——模型在一次调用里能做更长的内部推理。原生的 tool use 在每一代都更稳。multi-step 的 planning 能力肉眼可见地在涨。

那么一个不那么好回答的问题是：

当模型本身具备足够长的推理链和原生工具使用能力时，外部那个 while 循环还需要存在吗？

也许某一天，你只需要一次 API 调用，模型在内部就完成了全部规划、工具调用、上下文管理。harness 被吸收进了模型本身。我们今天精心设计的这些 loop 控制机制，会变成一段历史。

也可能不会。也许 harness 永远存在——因为外部环境永远是 harness 的边界，模型再强，也需要一个东西替它和真实世界对接。

不知道。但这就是现在做 Agent 最有意思的地方：你不知道自己写的这一千行 harness 代码，到底是产品的核心资产，还是即将过时的过渡方案。

唯一确定的是，所有故事的开头，都还是那个最朴素的 while 循环。

参考项目：shareAI-lab/learn-claude-code，一个把 Claude Code 拆成 12 个递进版本的开源教学项目。建议从 s01_agent_loop.py 开始读。

天下苦 A 社久矣。

这是前段时间 Anthropic 持续推出各种功能，但是一边又不断加强使用限制，读者在评论区最普遍的反应。

本身就是御三家（OpenAI、Google、Anthropic）里对使用限制最严格的一个，另一边又加码推出身份验证，实名制才能使用。今天凌晨，再把 Pro（20 美元/月）用户的 Claude Code 使用权给砍了。

Anthropic 的增长负责人出来回应，提到他们正在对约 2% 的新专业用户注册者进行小规模测试，现有 Pro 和 Max 用户不受影响；并表示目前的订阅计划无法应对用户大量的 Token 消耗，他们在研究新的付费方案。

OpenAI 这边也立马回应了 Claude Code 踢掉 Pro 会员的争议，一位 Codex 负责人 Rohan Varma 直接怼脸和 Claude Code 竞争，连发文格式都和 Claude Code 一样。

Anthropic 为 2% 的用户测试更贵的计划，而 Codex 给 100% 用户测试，让免费和付费套餐都能使用 Codex。还特别调皮的加了一句「Claude Code 用户不受影响。」

另一位 Codex 负责人 Tibo，也在 X 发文说 Codex 将继续提供免费版和 PLUS 版（20 美元/月），还提到 OpenAI 拥有足够的算力和厉害的模型来支持 Codex 的运作。

奥特曼也转发了这条推文，表示 「我们希望你们可以有大量的 AI。」

Codex 口碑在社交媒体上一直不算太差，尤其是前段时间 OpenAI「大撒币」，先是说为了让每个人都能体验到 Codex 推出的相关插件，给所有订阅计划都重置了使用限制。

4 月初，Codex 发现用户达到使用限制的频率增加，且未找到背后的原因，干脆就重置了所有用户的额度限制。几天前，为了庆祝 Codex 周年庆和新功能上线，又一次重置了所有套餐的用量限制。

今天，Codex 负责人和奥特曼再发推文，表示不到两周 Codex 增加了 100 万新用户，为了庆祝这件事，Codex 的速率限制又又又重置了。

早在上周 Anthropic 发布 Opus 4.7 的那天，Codex 就更新了一大堆重要功能，Computer Use、内置浏览器、持久记忆，以及 90 多项插件。

这些更新几乎是直接对标 Claude Cowork 的功能，把 Codex 从一个听着就像是给开发者用的工具，重新变成了一个适用于电脑所有场景的效率助手工具。

昨天，Codex 在此前推出记忆功能的基础上，又上线了一项名叫「Chronicle」的研究预览功能，让 AI 能读我们的屏幕，把我们最近做过的事整理成记忆。

Codex 不再只依赖聊天记录来理解上下文，结合它读取的近期屏幕内容，我们给它发送「这个」、「那个」，Codex 能知道我们到底指的是什么。

今天刚刚发布的 GPT Image 2 也已经集成到了 Codex 里。我们可以在 Codex 生成并迭代图像，在一套工作流里，从产品原型、前端设计，到视觉效果图和游戏开发等任务，使用 GPT Image 2 快速生成视觉元素。

如果你的 Claude 账号总是被封，用不了官方的 Claude Cowork、Claude Code 桌面版，又或者是那 2% 的新用户，开通了 20 美元/月的 Pro 会员也用不了 Claude Code，不妨来试试 OpenAI 出品的 Codex。

从代码工具到全能助手

Codex 最近这段时间的更新，最重要的莫过于上周发布的 Computer Use。这项能力并不算新鲜，之前是模型有 Computer Use 的能力，现在是需要工具也要有配套的支持，才能发挥模型能力。

它本质上就是 Agent 工具可以像人类操作电脑一样，通过视觉识别、点击和输入，自主操控电脑上的各类应用程序。

之前的 Codex 操作电脑上的软件，是通过一些命令来执行不同的应用任务，整体更像是我们喊「Siri，明天的天气怎么样」，做这些比较简单的任务。

有了 Computer Use 的能力之后，不仅支持一些调用 API 或者终端命令的工具，还能真的能帮我们完成一些电脑上的实际操作，尤其适合前端调试、应用测试、操作没有开放 API 的软件。

而且支持多个智能体并行在 Mac 上工作，不会影响我们正常使用其他应用。

需要注意的是，Computer Use 的能力只支持 macOS 15 以上的版本，我们的电脑（macOS 14.6.1）在测试 Codex 时，会自动弹出一个 SkyComputerUseClient 的问题报告。

另外，现在 Codex 支持内置浏览器，能更好地处理 Web 场景。我们在 Codex 里生成的网页，可以直接在网页上标注，给 Codex 更精准的操作指令，对一些前端、应用和游戏开发的快速迭代非常有用。

这次的更新还新增了 90 多个插件和更丰富的工具集成，让 Codex 能接入更多工具、获取更多上下文，并跨平台执行操作，提到的热门插件包括 Atlassian Rovo（JIRA）、Microsoft 套件、Neon by Databricks、Remotion、Render、Superpowers 等。

在 Codex 应用里，我们只需要输入斜线就能快速进入一些关于 Codex 的配置，输入 $，则可以选择不同的 Skills，包括我们安装在本地的各种 Skills。

同时，在自动化任务上，Codex 的 Automation 功能升级后，可以复用之前的对话线程，保留已有上下文。新的自动化还支持 Codex 自主规划后续工作、自动在未来某个时间继续执行任务，以及支持持续数天甚至数周的长期任务。

官方提到这项更新主要用于代码的提交合并、跟进日常工作生活的待办事项，以及跨越不同平台和工具的信息追踪等任务。

还有一些对于桌面应用交互的小更新，像是增加了多标签页的终端窗口，侧边栏可以直接打开文件，预览 PDF、表格、PPT 等文档。

新的摘要面板，也可以持续跟踪当前执行任务的计划和进度、参考信息来源，和输出结果等。这些应用上的增强，也让 Codex 在整体上更像是一个统一的工作台，而不再是单一的对话窗口。

用定时截屏的方式来维护 Agent 记忆

个性化的记忆功能向来就是 AI 的一大难题，虽然 AI 博古通今能记住所有的知识，但是对于每个用户的私人记忆处理，工作记忆等，AI 需要用不会占据大量的 Token，同时又能记清楚的方式来处理日复一日的对话。

尤其是现在到了 Agent 这类巨消耗 Token 的任务上，每个用户每天产生的上下文，如果 Agent 要全部记住，估计再来一百万 Token 上下文也难顶住。

上周 OpenAI 就已经为 Codex 带来了记忆功能，它可以记住我们的个人偏好、之前做过的修正，以及一些不容易获取但很重要的信息。

而为了获取更多的记忆，更快地处理我们的工作流。Codex 这次推出的 Chronicle 功能，说白了就是看我们的屏幕，记住我们的工作，再把这些记忆喂给 AI。

具体来说，在 Codex 设置>个性化里面，开了 Chronicle 功能之后，会自动执行这些操作：屏幕上下文捕获 → 本地临时截图 → 后台代理分析 → 临时 Codex 会话总结 → 生成本地 Markdown 记忆 → 后续会话中作为上下文使用。

Codex 获取了屏幕录制和无障碍权限之后，Chronicle 会在后台运行一个沙箱 Agent，这些 Agents 使用默认模型 GPT-5.4-mini，基于捕获到的屏幕图像，周期性地启动一个临时的 Codex 会话，把最近的屏幕上下文整理出记忆。

屏幕截图只会临时保存在本地，Codex 提到运行期间，超过 6 个小时截图会被自动删除。

以后我们和 Codex 对话，它会自动检索这些记忆文件，作为上下文来使用，减少我们重复描述背景的需要。

OpenAI 官方也给了多个案例，像是如果不开启 Chronicle，Codex 不知道我们说的「这里会失败」，是指的什么。

以及针对一些个人任务中出现的人名、项目名等，在通用知识外的内容，Codex 也会根据 Chronicle 获取的信息，自动补充上下文。

能够捕获屏幕图像，也意味着使用 Codex 处理任务的全流程，Chronicle 都能记住。包括我们的工作流，常用的工具。像下面的例子里，使用了 Chronicle 的 Codex 会知道这份宣传材料使用何种格式，以及何种工具，是 Google 文档还是 Markdown 文档。

不过这项功能也面临着一些争议，例如视觉识别的方法会消耗大量的 token，更严重的是这些截图可能包含我们屏幕上可见的敏感信息。

虽然 OpenAI 说所有保存的记忆都会存放在本地的 markdwon 文档里，用户可以随时查看，Codex 根据这些截屏获取到了哪些信息。但是他们也提醒用户，当 Chronicle 截屏到一些有风险的网站时，网站可能通过提示词注入的方式，在屏幕上隐藏一些恶意指令，让 Codex 执行。

Chronicle 这项功能目前仅向 ChatGPT Pro（200 美元/月）用户开放，支持 macOS 版本的 Codex 应用，作为研究预览版推出。待 Chronicle 正式上线之后，相信 Codex 会把它开放给更多用户使用。

手机遥控、电子宠物、「Hermes Agent」都有机会上线

这段时间，Codex 被网友们称作是一款正在用力追赶 Claude 的产品。虽然一方面是在说 OpenAI 没有主见，随大流。但另一方面，能看到好的产品之间展开你追我赶的竞争，对我们用户来说未尝不是一件好事。

Codex 开发者在 X 上问大家对 Codex 有何意见，网友们非常积极的表示，要加上手机控制功能，还有人说 Codex 也应该从 ChatGPT App 里面进入。而这些都是 Claude 目前已经做到的功能。

也有网友在下面反馈 Codex 存在的各种 Bug，像是内存泄露、会话只能存档不能删除等问题。

最新的 Codex 更新爆料里还提到，Codex 也打算做一个小小电子宠物，放在 Codex 桌面上，来提示用户目前会话的各种状态。

这个电子宠物共有 8 种预设形象，用户还可以创建使用自己的虚拟形象。

另一个爆料则提到 OpenAI 正在为 ChatGPT 开发智能体（代号 Hermes），其中包括智能体构建器、模板、日程安排、在 Slack 中使用智能体的选项、添加应用程序、技能、文件、内存、指令等功能。

眼下的 Codex 是一个活跃开发的产品，OpenAI 必然不会把本地 Agent 产品这一块的市场拱手让给 Claude。

别说 OpenAI 这位 AI 界的老大哥，前几天，Gemini 也不声不响地发布了桌面版应用，但是被一众网友评价「拉爆了」。

只能鼓励一下 OpenAI 和 Gemini，赶快结束 Claude 在本地 Agent 助手和代码这块的领先地位。

天下苦 A 社久矣。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

0.引子

现今，在中国大陆想要使用最强编程大模型在 Xcode 中实时交互的方法不多。

为了体验 Vibe Coding 的“畅快”打击感（或许还有等待间隙时的些许失落感），我们往往需要在 Cursor 和 Xcode 间无限切换，这多少有点让秃头小码农们有些不爽快！

况且第三方智能编程 IDE 与 Xcode 联合开发还有一个问题：就是从 Xcode 外部无法精确的感知和处理 Xcode 中的细枝末节。举个例子：宝子们见过 Cursor 为了修复 1 个 bug 却新产出 10 个 bug 的蛋疼壮观场面吗？

幸运的是，在 Xcode 最新正式版 26.4 中：

我们找到一种免费且非常简单就可以辅以超强编程大模型（gpt-5.4 或 gpt-5.3-codex 家族）的方法：

操作起来也非常简单，目前（2026.4.7号）并不需要付费 OpenAI 账号或绑定任何国际银行卡。

这样宝子们“足不出户”就可以在 Xcode 里享受氛围编程的乐趣了哦。

废话少叙，心动不如行动！

让我们马上开始操练起来，将 Xcode 打造为丝毫不输于 Cursor 的智能 IDE 吧！8-)

1.工欲善其事，必先利其器

首先，大家需要下载和安装 Xcode 26.4 正式版。

同时，必须保证我们可以访问到 ChatGPT 官网，否则还扯什么呢？

2.启用 Xcode 智能 Agent

运行 Xcode ，打开设置，进入 Intelligence 页面：

Xcode 26.4 支持先进最强的 2 个编程大模型智能体（Agents）：ChatGPT Codex 和 Claude，不过目前后者在大陆无法登录，会提示：当前区域的服务不可用。

所以，我们只有“稍微”退而求其次一丢丢，来使用 gpt-codex 了。

点击 Codex 右侧的 Get 按钮，下载并安装 Agent 到本地，我们能看到只有 77MB，可谓相当“小鸟依人”：

接下来的一步就是进入 Codex 智能体（Agent）页面，登录 ChatGPT 账户即可：

如图所示，在登录了 gpt 账号之后，我们可以就可以恣意选择自己喜爱的 gpt 大模型啦：

不过据我观察，Xcode 智能 Agent 中的 gpt 编程大模型貌似有点缩水，少了不少强力模型哦（比如 GPT-5.3 Codex High 和 GPT-5.3 Codex Extra High 等）：

但话又说回来，对于这免费的“飞来横福”，我们还要什么自行车呢？

注意：正如之前所说的，目前只需免费的 ChatGPT 账号即可，且不需要绑定任何银行卡。

但是，未来还能不能享用这“免费的午餐”，就有点世事难料了。

3. 测试

在上面各步骤都就绪之后，我们就可以找一个项目实际在 Xcode 中小试身手了。

下面，打开宝子们最爱的项目，先让 Xcode Agent 为我们总结一番吧：

当然，在 Xcode 里编程智能体做的不仅仅是做个总结那么“弱智”，我们还可以让它直接分析 Xcode 中拥有的一切：

现在，直接在 Xcode 中用 AI 来修正编译错误不再是梦想了：

这样做可以最大化利用 Xcode 丰富的上下文来让 AI 充分考虑和修正问题，避免了外部智能 IDE（比如 Cursor、Qoder 等）无必要的切换和折腾。

想用 Xcode 与本地大模型“双剑合璧”来协同编程的宝子们，请移步如下链接观赏精彩的内容：

• 拒绝羡慕 Cursor！Xcode 自己也能利用 AI 大模型让撸码如虎添翼【超详细配置】

看到这，不知宝子们心动了吗？

要不要一起来借助 Coding Intelligence 来试试 Xcode 的氛围编程呢？8-)

若有任何与本文相关的配置问题，请宝子们毫不犹豫的私我哦！

感谢观赏，下次再会吧！

Xcode26.4 踩坑适配

不建议升级Xcode 26.4，Xcode底部控制台无法使用po命令；

iOS 26.4模拟器启动加载巨缓慢，建议保持26.3.1。

随着 Xcode 26.4 正式版发布，编译器对私有头文件访问、链式比较语法、C++标准库特化的校验规则进一步收紧，导致 iOS 开发中常用的 AFNetworking、YYText、WCDB 三个主流第三方库出现编译报错/警告。本文针对这三类问题提供修复方案，帮助开发者快速完成 Xcode 26.4 适配。

一、AFNetworking：私有头文件访问报错

报错信息

Use of private header from outside its module: 'netinet6/in6.h'

问题原因

Xcode 26.4 强化了模块私有头文件的访问权限校验，AFNetworking 源码中直接引入了系统私有头文件 <netinet6/in6.h>，违反了 Xcode 的模块访问规则，触发编译报错。

解决方案

直接注释掉AFNetworking 中引入该私有头的代码行，无需其他修改即可解决。

1. 找到 AFNetworking 中包含 #import <netinet6/in6.h> 的文件（通常为AFURLSessionManager.m或核心头文件）；
2. 注释该行代码：

// #import <netinet6/in6.h>

3. Clean 项目缓存，重新编译即可。

二、YYText：链式比较语法错误

报错信息

Chained comparison 'X < Y < Z' does not behave the same as a mathematical expression

问题原因

Xcode 26.4 编译器对链式比较语法做了严格校验：X < Y < Z 在 OC/C 语言中并非数学意义的连续比较，而是先计算X<Y得到布尔值（0/1），再用该值与 Z 比较，逻辑完全错误。编译器会强制抛出警告，影响编译流程。

解决方案

给前半段比较逻辑添加括号，明确运算优先级，修复语法歧义。

代码修改

[self _insideComposedCharacterSequences:line position:position block: ^(CGFloat left, CGFloat right, NSUInteger prev, NSUInteger next) {
    if (isVertical) {
-        position = fabs(left - point.y) < fabs(right - point.y) < (right ? prev : next);
+        position = (fabs(left - point.y) < fabs(right - point.y)) < (right ? prev : next);
    } else {
-        position = fabs(left - point.x) < fabs(right - point.x) < (right ? prev : next);
+        position = (fabs(left - point.x) < fabs(right - point.x)) < (right ? prev : next);
    }
}];

1. 按上述代码添加括号；
2. 重新编译，错误自动消失。

三、WCDB：C++标准库特化报错

报错信息

'is_integral' cannot be specialized: Users are not allowed to specialize this standard library entity

报错文件：Tag.hpp

问题原因

Xcode 26.4 升级了底层 Clang/LLVM 编译器，严格遵循 C++标准规范：禁止开发者手动特化std::is_integral等标准库实体，WCDB 旧版源码的 Tag.hpp 文件触发了该规则限制。

解决方案

官方暂未提供修复方案，推荐两种任选其一：

方案 1：其他开发者提交的修复 PR（源码修改）

直接应用 WCDB 其他开发者针对该问题的修复 PR，一键修复源码：

• PR 地址：#1540
• 操作：拉取 PR 代码替换本地 Tag.hpp 文件，重新编译即可。

方案 2：脚本打包 XCFramework（推荐）

使用 WCDB 官方脚本打包为xcframework，绕过源码编译的规则限制：

1. 进入 WCDB 源码根目录；
2. 执行官方打包脚本：

# 路径：/tools/version/build_xcframework.sh

./build_xcframework.sh \
  --scheme WCDBObjc \
  --configuration Release \
  --platforms ios ios-simulator \
  --output ./wcdb_xcframework

🧩 Creating XCFramework for WCDBObjc ...

[cmd] xcodebuild -create-xcframework -archive /Users/fjl/GitHub/wcdb/./wcdb_xcframework/archives/WCDBObjc-ios.xcarchive -framework WCDBObjc.framework -archive /Users/fjl/GitHub/wcdb/./wcdb_xcframework/archives/WCDBObjc-ios-simulator.xcarchive -framework WCDBObjc.framework -output /Users/fjl/GitHub/wcdb/./wcdb_xcframework/xcframeworks/WCDBObjc.xcframework

xcframework successfully written out to: /Users/fjl/GitHub/wcdb/wcdb_xcframework/xcframeworks/WCDBObjc.xcframework

✅ Created XCFramework: /Users/fjl/GitHub/wcdb/./wcdb_xcframework/xcframeworks/WCDBObjc.xcframework

⏱ Total elapsed time: 1 min 7 sec (67 s)

3. 用生成的 xcframework 替换项目中原有 WCDB 的集成方式；
4. Clean 项目后编译，问题彻底解决。

参考链接：WCDB Tag.hpp 报错官方 issue

适配总结

1. AFNetworking：注释私有头引入行，解决模块访问权限问题；
2. YYText：链式比较加括号，修复编译器语法校验；
3. WCDB：合并官方 PR 或脚本打包 xcframework，解决 C++标准库特化限制。

完成以上修改后，清理 Xcode 缓存（Cmd+Shift+K），即可适配 Xcode 26.4，正常编译运行。

总结

1. 三个第三方库的报错均由 Xcode 26.4编译器规则升级导致，修复无需改动业务代码；
2. AFNetworking、YYText 为轻量代码修改，WCDB 推荐用官方脚本打包方案，稳定性更高；
3. 适配后务必清理项目缓存，避免编译缓存残留问题。

深入理解代替单纯记忆

问题背景

• 在开发iOS项目时，希望将一堆图片资源放入Main Bundle中，但又不希望资源在Bundle的最顶层目录中，希望自定义目录
• 但一时想不到该如何解决，于是想到Folder、Group等概念
• 经过简单搜索后，发现Xcode对于这两个概念的定义还是有些差异的
• 于是继续查阅学习了一番，编写本文，方便后续查阅和分享

本文提到的内容，参考的Xcode版本为26.0(17A324)和26.3(17C529)

Buildable Folder

• Buildable Folder是自Xcode 16(2024年6月)引入的概念，初衷是为了减少代码管理中的冲突问题
• 后续新建的工程或者新建Folder时，默认都是Buildable Folder

官方原文如下：

Minimize project file changes and avoid conflicts with buildable folder references. Convert an existing group to a buildable folder with the Convert to Folder context menu item in the Project Navigator. Buildable folders only record the folder path into the project file without enumerating the contained files, minimizing diffs to the project when your team adds or removes files, and avoiding source control conflicts. To use a folder as an opaque copiable resource, the default behavior before Xcode 16, uncheck the Build Folder Contents option in the File Inspector.

Buildable Folder如何降低代码冲突

1. 先添加1个普通Group--BuildableFolderTest，project文件的变化如下所示：

2. 然后向BuildableFolderTest Group中添加ABC.swift文件后，project文件的变化如下：

   这说明Group目录下的文件，都要在project文件中进行记录

3. 继续，将BuildableFolderTest Group通过Convert to Folder选项转为Folder(Buildable Folder)后，project文件的变化如下：

4. 然后再向BuildableFolderTest这个Folder中添加DEF.swift文件后，发现project文件没有任何变化

所以，project文件仅记录了Folder自身，至于目录中的文件是不会记录在project文件中，所以会减少因团队多人同时修改Project文件导致的代码冲突

Apply to Each File vs Apply Once to Folder

当创建Folder(Buildable Folder)后，选中Folder，在File inspector中会看到有个Build Rule，有两个选择：Apply to Each File和Apply Once to Folder，默认是Apply to Each File

Apply Once to Folder

Apply Once to Folder开启后，project文件是什么样？

当开启该模式时，通过查看目录下的每个文件可以看出，文件是没有Target归属的概念的。同样，在该目录下创建新文件也不需要选择Target

再配合Xcode Buildable Folders中所提到的To use a folder as an opaque copiable resource, the default behavior before Xcode 16, uncheck the Build Folder Contents option in the File Inspector.

其实，Apply Once to Folder就是Xcode 16之前的Folder，之前叫Folder Reference (在Xcode 16之前，创建Folder时，官方名称就叫做Folder Reference)

• Folder Reference一般是用作资源包，目录下不包含源代码
• 另一个Folder Reference重要作用是可以在Bundle中自定义目录

Buildable Folder vs Folder Reference

Buildable Folder顾名思义，其中的内容是由编译系统参与的

• 所以Buildable Folder中可以放源代码文件，并可以参与编译，打包到最终可执行文件中；也可以制定源文件的Target
• Folder Reference则保留老的逻辑，不参与编译，用作资源包，即使放入源代码文件也无法选择Target，只能当做普通文件资源处理

Create Group with Folder

同样是在Xcode 16开始的另一个变化是，创建Group时由原来的不自动创建磁盘物理目录(Folder)变为自动创建。当然，仍可以创建没有Folder的Group，原文如下：

Create groups with associated folders by default when using the New Group and New Group from Selection commands in the Project Navigator. To create a group without a folder, hold the Option key in the context menu to reveal the New Group without Folder variant of the command.

[Group without Folder] vs [Group] vs [Folder(Buildable Folder)] vs [Folder Reference]

特性	Group without Folder	Group	Buildable Folder	Folder Reference
Project Navigator 图标
是否对应磁盘目录	❌ 不必须	✅ 必须	✅ 必须	✅ 必须
工程结构是否可与磁盘不同	✅ 可以	❌ 基本一致	❌ 必须一致	❌ 必须一致
.pbxproj 是否记录每个文件	✅ 会	✅ 会	❌ 不会	❌ 不会
新增文件是否修改 .pbxproj	✅ 会	✅ 会	❌ 不会	❌ 不会
Git 冲突概率	高	高	低	低
是否参与编译系统	✅	✅	✅	❌
是否自动编译源码	✅	✅	✅（自动发现目录中的源码）	❌
Bundle 中是否保留目录结构	❌ 通常不会	❌ 通常不会	❌ 通常不会	会保留（如果被加入 Bundle）
默认是否进入 Bundle	❌ 否	❌ 否	❌ 否	仅在选中 Target 时自动加入
典型用途	逻辑分组	常规项目结构	源码目录	资源目录

• 当前(Xcode 26)，默认的Group和Folder组合是Group with Folder + Buildable Folder。这可能也意味着这两项是日常最常用的

回答开始的问题

• 既然是想打包资源放入Bundle，并自定义目录，那必然是Folder Reference

参考

• Xcode Buildable Folders
• Xcode 16 Buildable Folders Break Xcode 15 Backwards Compatibility

VSCode 插件全部无法激活？一次从日志到根源的排查记录

引言

某天，你像往常一样打开 Visual Studio Code，却发现所有已安装的插件都失效了——代码补全没了、Git 信息不见了、主题也变回了默认。更诡异的是，重装软件、清理缓存、升级版本……常规手段统统无效。插件市场明明显示已安装，但就是无法激活。这究竟是怎么回事？

最近我就遇到了这样的棘手问题，经过一番抽丝剥茧，终于揪出了幕后黑手——一个看似无害的 GitBlame 扩展。下面我将完整还原整个排查过程，希望能为遇到类似问题的朋友提供一份实用的“避坑指南”。

第一阶段：基础排查（全军覆没）

当所有插件都无法激活时，首先排除环境因素：

• 检查 VSCode 位置：确保 Visual Studio Code.app 位于“应用程序”文件夹，而非“下载”或桌面（权限问题会导致插件加载失败）。
• 清理缓存与配置文件：

  1 2 3

  rm -rf ~/.vscode rm -rf ~/Library/Application\ Support/Code rm -rf ~/Library/Caches/com.microsoft.VSCode

• 彻底重装：删除上述所有文件后，从官网下载最新版重装。

然而，这一套组合拳下来，问题依旧。看来不是简单的缓存损坏。

第二阶段：启用“侦探模式”——挖掘日志

常规手段无效，就需要让 VSCode 自己“开口说话”。打开 帮助 → 切换开发人员工具（或 Cmd+Option+I），在 控制台（Console） 和 输出（Output） 面板中寻找线索。

果然，一条醒目的红色错误映入眼帘：

1
2

ERR Extension 'TME.continuecode CANNOT USE these API proposals 'extensionRuntime'. 
You MUST start in extension development mode or use the --enable-proposed-api command line flag

这里出现了一个陌生的扩展 TME.continuecode，它试图使用 提案 API（Proposed API）——这是 VSCode 内部开发中的接口，普通扩展无权调用。这种错误可能导致扩展半激活，甚至阻塞整个扩展宿主进程。

同时，日志中还发现了两个 CMake 扩展的冲突警告：

1

WARN [twxs.cmake]: 无法注册“cmake.cmakePath”。此属性已注册。

多个扩展争夺同一配置项，虽不致命，但加剧了环境的不稳定性。

初步行动：移除问题扩展

1
2

rm -rf ~/.vscode/extensions/tme.continuecode-*
rm -rf ~/.vscode/extensions/twxs.cmake-*

重启 VSCode 后，TME.continuecode 的错误消失了，但……扩展宿主依然无响应！日志中只剩下：

1

INFO Extension host (LocalProcess pid: 12485) is unresponsive.

看来凶手不止一个。

第三阶段：终极排查法——禁用所有扩展，逐个启用

当错误日志无法直接定位时，就要用最原始也最有效的方法：控制变量法。

1. 以禁用所有扩展的模式启动

1

code --disable-extensions

启动后，VSCode 响应迅速，所有内置功能正常。这证实问题 100% 出在某个第三方扩展上。

2. 二分法逐个启用扩展

退出纯净模式，正常打开 VSCode（此时所有扩展仍处于禁用状态）。然后进入扩展面板，每次启用一个扩展，重启观察是否复现无响应。这个过程需要耐心，但能精确锁定目标。

经过几轮测试，当启用 GitBlame 后，扩展宿主再次卡死。卸载该扩展，一切恢复如初。

第四阶段：真相大白

GitBlame 是一个提供 Git 逐行注释（blame）信息的扩展，功能简单但实用。但是十小时前这个插件更新后, 导致了问题.

替代方案

• GitLens：功能强大且持续维护的 Git 工具，不仅能显示 blame，还提供丰富的仓库浏览功能。
• Git History：轻量级替代品，专注于文件历史和逐行注释。

安装 GitLens 后，一切功能正常，再无卡顿。

总结：排查思路回顾

1. 基础检查：确保 VSCode 安装位置正确，清理缓存。
2. 日志分析：打开开发者工具，查看控制台和“扩展宿主”输出，寻找显式错误。
3. 处理明显错误：如提案 API 滥用、扩展冲突，先移除可疑扩展。
4. 禁用所有扩展：用 code --disable-extensions 确认问题是否由扩展引起。
5. 二分法逐个启用：定位具体肇事扩展。
6. 寻找替代或更新：对于老旧扩展，果断换用维护活跃的同类工具。

一些有用的命令

心得

• 日志是第一生产力：遇到诡异问题，先看日志，往往能直接定位。
• 老旧扩展是定时炸弹：长期未更新的扩展可能与新版 VSCode 不兼容，尽量选用维护活跃的替代品。
• 控制变量法永不过时：当错误信息模糊时，通过排除法缩小范围是最可靠的手段。

希望这次分享能帮助你快速解决类似的插件故障。如果你也有过奇葩的排查经历，欢迎留言交流！

1）如何从 iPhone 获取崩溃日志

路径：设置 → 隐私与安全性 → 分析与改进 → 分析数据
这里的崩溃日志通常是 .ips 文件。

.ips 原始内容示例（节选）：

{"app_name":"hello","timestamp":"2026-02-28 15:05:24.00 +0800","app_version":"1.0","bundleID":"com.example.hello","bug_type":"309","os_version":"iPhone OS 26.3 (23D127)","incident_id":"2B7A2F77-7F64-42DA-A184-AA496AD61AAC"}
{
  "modelCode" : "iPhone18,3",
  "captureTime" : "2026-02-28 15:05:24.5689 +0800",
  "procName" : "hello",
  "bundleInfo" : {"CFBundleShortVersionString":"1.0","CFBundleVersion":"1","CFBundleIdentifier":"com.example.hello"}
}

2）如何将 .ips 转成可查看的崩溃日志

把 .ips 文件复制到 Mac（如桌面），直接双击。
系统会用 控制台（Console） 打开，并自动转成可读格式（Translated Report）。

转换后示例（节选）：

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Incident Identifier: 2B7A2F77-7F64-42DA-A184-AA496AD61AAC
Process: hello [1056]
Identifier: com.example.hello
Version: 1.0 (1)
OS Version: iPhone OS 26.3 (23D127)

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Triggered by Thread: 0

Thread 0 Crashed:
0   libswiftCore.dylib   _assertionFailure(...)
1   hello.debug.dylib    ViewController.click(_:)

说明：这是一个 Demo 在真机调试运行时产生的崩溃日志，符号信息完整，不需要额外 dSYM 符号化也能直接看到具体崩溃代码位置（如 ViewController.click(_:)）。

一、可清理目录总览

二、分项说明

1) 模拟器（CoreSimulator）

• 路径：~/Library/Developer/CoreSimulator
• 说明：包含模拟器设备数据。
• 结论：可以删除；如果基本不用模拟器，可删除 devices 目录内容来释放较大空间。

2) 真机（DeviceSupport）

• 路径：~/Library/Developer/Xcode/iOS DeviceSupport
• 说明：真机调试时生成的设备符号文件。
• 结论：建议选择性删除不用的设备版本；常用设备版本保留，避免频繁重建影响调试效率。

3) 打包（Archives）

• 路径：~/Library/Developer/Xcode/Archives
• 说明：Xcode 打包归档历史。
• 结论：可以删除，但要先确认是否需要保留线上版本的归档记录。

4) 项目缓存（DerivedData）

• 路径：~/Library/Developer/Xcode/DerivedData
• 说明：构建缓存与索引。
• 结论：建议优先清理；能快速释放缓存空间。代价是后续首次编译和索引会变慢。

三、实操建议（个人整理）

1. 优先清理：DerivedData（快速释放缓存空间）。
2. 选择性清理：iOS DeviceSupport（删除不用的设备/系统版本，常用的保留）。
3. 按需清理：CoreSimulator（尤其不用模拟器时）。
4. 补充清理：过期 Archives（先保留可回滚版本）。
5. 清理前先确认：
   • 是否有线上紧急回滚需要的归档；
   • 哪些真机系统版本仍在日常调试；
   • 是否有正在使用的模拟器环境数据需要保留。

四、快速命令（可选）

先看大小再删，避免误操作。

# 查看各目录体积
sudo du -sh ~/Library/Developer/CoreSimulator \
  ~/Library/Developer/Xcode/iOS\ DeviceSupport \
  ~/Library/Developer/Xcode/Archives \
  ~/Library/Developer/Xcode/DerivedData

# 删除 DeviceSupport
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

# 删除 Archives
rm -rf ~/Library/Developer/Xcode/Archives/*

# 删除 DerivedData（谨慎）
rm -rf ~/Library/Developer/Xcode/DerivedData/*

五、一句话总结

Xcode 清理的核心是：优先清理 DerivedData 释放缓存；DeviceSupport 只删不用的设备版本，常用版本保留；再按需处理模拟器与旧归档。