即刻App年轻人的同好社区
下载
置顶
我错了😭，我不应该看衰 OpenAI。 OpenAI 在 12月11日 发布了 GPT-5.2 和 12月18日发布的 GPT-5.2-Codex 才是长程开发的王者： cursor.com
阿晓Ocean: 2025年还有一个月就结束了，提前预测一下今年年度四大模型： 1. Google：最强前端、设计与绘图模型，Gemini 3 Pro 2. Anthropic：最强全栈编程模型，Opus 4.5 3. DeepSeek：最强数学模型，DeepSeek-Math-V2 4. OpenAI：最强……成人？……模型？🐶
2 00
在几个月前，用AI编程最大的痛点是AI的Debug能力很差，所以常常会出现“编程5分钟，Debug一小时”的情况。
当代码大部分由AI撰写时，人类进行调试所花费的时间，往往比调试自己手写代码时要多很多。
但是自从Opus 4.5 在 11 月 24 号发布之后，就能感受到AI Debug能力的明显提升。在一个多月的时间里，我都没有发现Opus长时间（半小时内）未能解决的Bug。现在，AI 编程的瓶颈从 debug，变成了代码审查。
之前用 Codex 5.1 的时候，主要用于代码审查。通常来说，在互评中，Codex 的审核更加严格，而 Claude 则更加宽松（Gemini 则最为宽松）。
但有时候严格提出的问题并非真问题，而是幻觉。同时，之前 Claude 未能解决的 bug，Codex 5.1 也都未能解决。所以我依然怀疑这只是模型输出风格的问题，是偏好问题，而不是Codex能力真的比 Claude 高。
再加上 Claude Code 的产品力比 Codex 要强太多，比如Claude Code 有 Subagent，而 Codex 没有。这样便一直没考虑切换到 Codex。
直到今天确实遇到了一个Opus 4.5 花了 40 多分钟，才勉强“解决”的复杂问题。但它的解法本质是绕过了问题，而非从根本上解决了。用 Codex 5.2，也是 40 多分钟解决了，但解法更加根本。
最近几天用 Codex 5.2 做代码审查，几乎所有的审查发现都是真实存在的。而且比 Opus 4.5 审查得到的结果，无论深度还是广度，都要更强。这两方面都让我对 Codex 5.2 的看法，相比Codex 5.1大为改观。
而我刚刚才得知的一个事实/观点是，Codex的自动上下文压缩能力非常强，在没有 subagent 的情况下，仅依靠自动上下文压缩，就能完成至少 5 小时的长程运行（且顺利完成对应工作量/复杂度的任务）。
看来是时候多用用 Codex 了。
当代码大部分由AI撰写时，人类进行调试所花费的时间，往往比调试自己手写代码时要多很多。
但是自从Opus 4.5 在 11 月 24 号发布之后，就能感受到AI Debug能力的明显提升。在一个多月的时间里，我都没有发现Opus长时间（半小时内）未能解决的Bug。现在，AI 编程的瓶颈从 debug，变成了代码审查。
之前用 Codex 5.1 的时候，主要用于代码审查。通常来说，在互评中，Codex 的审核更加严格，而 Claude 则更加宽松（Gemini 则最为宽松）。
但有时候严格提出的问题并非真问题，而是幻觉。同时，之前 Claude 未能解决的 bug，Codex 5.1 也都未能解决。所以我依然怀疑这只是模型输出风格的问题，是偏好问题，而不是Codex能力真的比 Claude 高。
再加上 Claude Code 的产品力比 Codex 要强太多，比如Claude Code 有 Subagent，而 Codex 没有。这样便一直没考虑切换到 Codex。
直到今天确实遇到了一个Opus 4.5 花了 40 多分钟，才勉强“解决”的复杂问题。但它的解法本质是绕过了问题，而非从根本上解决了。用 Codex 5.2，也是 40 多分钟解决了，但解法更加根本。
最近几天用 Codex 5.2 做代码审查，几乎所有的审查发现都是真实存在的。而且比 Opus 4.5 审查得到的结果，无论深度还是广度，都要更强。这两方面都让我对 Codex 5.2 的看法，相比Codex 5.1大为改观。
而我刚刚才得知的一个事实/观点是，Codex的自动上下文压缩能力非常强，在没有 subagent 的情况下，仅依靠自动上下文压缩，就能完成至少 5 小时的长程运行（且顺利完成对应工作量/复杂度的任务）。
看来是时候多用用 Codex 了。
6 10
非常离谱的体验：现在在 Anti-Gravity 里面，同时用 Claude Code CLI 和 Codex 的 IDE 插件。
Claude Code 经常出现闪烁问题，闪着闪着 Anti-Gravity 就崩掉关闭了。每次 Anti-Gravity 关闭重启之后，Codex 的插件图标就会消失，需要卸载再重装才能看到。
Anthropic 是想留着这个 bug 间接挤掉 Codex 份额嘛 🐶
Claude Code 经常出现闪烁问题，闪着闪着 Anti-Gravity 就崩掉关闭了。每次 Anti-Gravity 关闭重启之后，Codex 的插件图标就会消失，需要卸载再重装才能看到。
Anthropic 是想留着这个 bug 间接挤掉 Codex 份额嘛 🐶
2 11
多数应用都支持多窗口或多标签页。如果AI 成功率足够高，在本地操作过程中，人不必干预 AI 操作的窗口或标签，而在（同一个应用的）另一个窗口干其他活，像豆包手机助手那样，那么也就不存在人和 AI 抢应用/抢界面的问题了。
当然在当前 AI 成功率不够高的情况下，Manus 云端方案会更合理一些，但未来随着可靠性增强，本地方案的体验将逐渐追赶，各有优劣。
而 Claude 则是本地、云端同时在发力。
当然在当前 AI 成功率不够高的情况下，Manus 云端方案会更合理一些，但未来随着可靠性增强，本地方案的体验将逐渐追赶，各有优劣。
而 Claude 则是本地、云端同时在发力。
阿晓Ocean: manus产品理念锐评之二：要想解决 Agent 争夺用户注意力的问题，解决的关键不在于将 Agent 任务放在台前还是幕后，所谓的同步还是异步，而在于提升 Agent 成功的概率，让用户放心。只要当成功率足够高，用户足够放心的时候， UI 设计在台前还是幕后的关系就没那么大了。如果 Agent 的成功率不够高，无论放在台前还是幕后，同步还是异步，都阻碍不了用户想要实时审查、实时干预的冲动。
0 00
Claude Cowork 来了
阿晓Ocean: 按此推断， manus未来的最大竞品将是 claude
1 00
OpenAI 在去年 12 月发布了一篇博客，介绍其 Sora 安卓版应用的极速开发过程。该团队仅由 4 名开发者组成，在 28 天内就完成了 Sora 安卓版应用的开发上线。实际上，他们仅用 18 天就开发完成了内部版本，随后在 10 天内公开上线，最终无崩溃率高达 99.9%。
他们将此归功于 Codex 与 AI 编程新范式，并介绍团队短时间内就消耗了 50 亿 Token。
看到该新闻之后，我首先是相当震惊的，不仅震惊于其开发效率之高，更震惊于其团队对 Token 消耗效率之高。四人团队在 28 天内消耗了 50 亿 Token，相当于一人在一个月内至少消耗 10 亿 Token。
要知道Claude Code 创始人 Boris Cherny，（基于 12 月 27 的）过去 47 天，干了 46 天的活，总 Token 量也“才”325M，相当于 Sora 团队平均值的 1/4，而Boris Cherny是一个会在本地同时运行 5 个终端，远程再同时运行 5 个窗口，做 10 倍并发的狠人。
那么 Sora 团队是如何如此高效消耗 Token 的呢？
首先和模型以及应用关系不大：他们用到的就是 GPT-5.1 CodeX，而应用则是所有人都能访问到的 CodeX 的 CLI、IDE 扩展和网页应用。
其次，方法论似乎也挺普通的，无外乎包括：a) 先写规范以及一些样例代码，然后让 Agent 按照规范和样例做仿写；b) 先写计划，后写实现；c) 开启多个窗口做并行。
至于是否在无人监督的情况下，进行了长时间运行，博客的表达非常暧昧。虽然明说了“近期运作时长已超过 24 小时”，但一是没说是该项目，二是指向了另一个博客，说的是“它在‘某些’任务上连续工作超过 24 小时”，具体情况也没描述。另外该博客也明确说明，长时间运行是“下一步计划”。当前“大多数情况下生成的代码在技术上可以编译，但却偏离了我们的架构和目标。”
直到博客的最后，我终于领悟到了高效开发 Sora “安卓”应用的关键！在团队开发安卓应用之前，Sora 的 iOS 版本早就已经完成了。团队要做的“不过”就是把 iOS 版本转化成安卓版本，也就是将 Swift 实现转化成语义等效的 Kotlin 代码！
这就是 28 天消耗50 亿 token 的秘密，你学会了吗🐶
又被奥特曼装到了😡
（本来平心而论，把整个 iOS 版本转为安卓版本，确实工作量挺大的。但 OpenAI 的这篇博客，总给人避重就轻，故意误导人的感觉。这里调侃一下。）
他们将此归功于 Codex 与 AI 编程新范式，并介绍团队短时间内就消耗了 50 亿 Token。
看到该新闻之后，我首先是相当震惊的，不仅震惊于其开发效率之高，更震惊于其团队对 Token 消耗效率之高。四人团队在 28 天内消耗了 50 亿 Token，相当于一人在一个月内至少消耗 10 亿 Token。
要知道Claude Code 创始人 Boris Cherny，（基于 12 月 27 的）过去 47 天，干了 46 天的活，总 Token 量也“才”325M，相当于 Sora 团队平均值的 1/4，而Boris Cherny是一个会在本地同时运行 5 个终端，远程再同时运行 5 个窗口，做 10 倍并发的狠人。
那么 Sora 团队是如何如此高效消耗 Token 的呢？
首先和模型以及应用关系不大：他们用到的就是 GPT-5.1 CodeX，而应用则是所有人都能访问到的 CodeX 的 CLI、IDE 扩展和网页应用。
其次，方法论似乎也挺普通的，无外乎包括：a) 先写规范以及一些样例代码，然后让 Agent 按照规范和样例做仿写；b) 先写计划，后写实现；c) 开启多个窗口做并行。
至于是否在无人监督的情况下，进行了长时间运行，博客的表达非常暧昧。虽然明说了“近期运作时长已超过 24 小时”，但一是没说是该项目，二是指向了另一个博客，说的是“它在‘某些’任务上连续工作超过 24 小时”，具体情况也没描述。另外该博客也明确说明，长时间运行是“下一步计划”。当前“大多数情况下生成的代码在技术上可以编译，但却偏离了我们的架构和目标。”
直到博客的最后，我终于领悟到了高效开发 Sora “安卓”应用的关键！在团队开发安卓应用之前，Sora 的 iOS 版本早就已经完成了。团队要做的“不过”就是把 iOS 版本转化成安卓版本，也就是将 Swift 实现转化成语义等效的 Kotlin 代码！
这就是 28 天消耗50 亿 token 的秘密，你学会了吗🐶
又被奥特曼装到了😡
（本来平心而论，把整个 iOS 版本转为安卓版本，确实工作量挺大的。但 OpenAI 的这篇博客，总给人避重就轻，故意误导人的感觉。这里调侃一下。）
6 01
