Codegass

你以为我在写文章？不，我只是为了防止自己失忆。Working on my PhD

[Codegass @OsilyWei]

从月初精打细算用Fable，到现在卸载所有skill换用gpt5.6 Sol，感觉自己明显放松了很多，不用再非常紧张的先和pro/opus聊天才敢给最高级智能下达任务了。

巨大解脱。

[Codegass @OsilyWei]

Once again，又在把自己往绝路上逼

[Codegass @OsilyWei]

反之，如果缺乏可靠的验证机制，再强的 tool 和再长的上下文最终都难以让 Agent 具备可复现的表现。

目前市面上虽然出现了大量 Agent，但真正把 Agent runtime 设计得完善、机制严谨、反馈闭环跑通的框架，除了 CC 之外其实寥寥无几。

[Codegass @OsilyWei]

最近在做自己的agent框架，最深的感受就是，tool 和 skill 虽然重要，但它们本质上都是对有限 context window 的一种妥协。真正决定 Agent 能力上限的，其实是 verification system。

只要一类任务能够提供清晰、可量化的 verification feedback，Agent 在这类任务上就能实现高度稳定的准确输出。

[meng shao @shao__meng]

Karpathy 大神最新发布：AI 本质上是「Software 2.0」，判断一个任务或职业是否易被自动化，关键指标是「可验证性」

Karpathy 没有把 AI 简单比作“电力”或“工业革命”等宏观历史事件，而是提出一个更精确的类比：AI 本质上是「Software 2.0」。AI 不再是人类手动编写固定规则的「Software 1.0」，而是通过指定目标（如分类准确率或奖励函数），利用梯度下降等算法在庞大参数空间中自动“搜索”出高效的神经网络，从而自动化数字信息的处理。

自动化任务的“预测指标”转变
Karpathy 用 1980 年代计算时代作为对比：那时，计算机最容易取代的工作是那些算法固定、规则明确的任务，比如打字、簿记或手动计算。这些任务的共同点是“易于指定”——人类能一步步写出精确指令。

如今，AI 的「Software 2.0」时代，判断一个任务或职业是否易被自动化，关键指标是「可验证性（verifiability）」。具体来说：
· 可验证的任务：输出结果能通过客观标准快速评估和反馈。例如，数学题、代码编写、视频观看时长分析，或任何类似“谜题”的问题。这些任务适合强化学习：AI 能在可重置的环境中反复“练习”，高效生成大量尝试，并自动奖励成功案例。结果是，AI 可能超越顶级人类专家的速度和准确性。
· 不可验证的任务：涉及创意、战略决策，或需要整合现实世界知识、情境和常识（如艺术创作、复杂谈判）。这些难以构建可靠的“奖励函数”，AI 只能依赖泛化“魔法”或模仿人类，进展较慢，导致 LLM 的“锯齿状前沿”——某些领域飞速前进，其他则滞后。

经济与就业启示
这个框架解释了 AI 为什么会造成“锯齿状”影响：可验证工作（如编程、数据分析）将加速自动化，可能压缩相关岗位；不可验证领域（如需要人类判断的战略咨询）短期内仍依赖人类，提供缓冲空间。但长远看，Karpathy 表示，随着验证工具的完善（如模拟器或专家验证器），更多任务将落入 AI 掌控。

「Software 1.0」轻松自动化你能指定的事；「Software 2.0」轻松自动化你能验证的事”！

[Codegass @OsilyWei]

到现在为止Grok只做过一笔亏损的交易，还是和deepseek正好相反的

[Codegass @OsilyWei]

@wwwgoubuli 每次都保留全部对话历史不是很容易出现上下文内容污染么？听起来是一个很懒惰的设计啊。

[Codegass @OsilyWei]

@b1antaidaye 这太牛逼了，前排小板凳坐等。

[Codegass @OsilyWei]

烧了500多刀的token写swiftui以后，得出结论是CC工程化能力不如cursor.

[Codegass @OsilyWei]

又是6年了，这次就等着M5 出来换电脑了

[Codegass @OsilyWei]

终于能换电脑了，第一时间下单！顶配又把内存加到了32g，换了i7 CPU，整体看着都很美好，就是这个delivery date 实在有点让人感觉着急。

期待它也能像上一任一样陪我6年。
#MacBookPro2020

[Codegass @OsilyWei]

🥲不是，我平时不发推马老板就认为我是垃圾账号啊，怎么给人评论直接进垃圾信息分组了

[Codegass @OsilyWei]

@wong2_x Cursor的Tab和diff apply都是用的自己微调的llama

[Codegass @OsilyWei]

就我个人的使用体验，复杂的后端项目，在需求文档完整的情况下，Claude code的成功完成率，远远低于Cursor的agent 模式。而且在整个执行过程中，Claude主动测试代码的频率远远低于Cursor agent模式。

[Codegass @OsilyWei]

我觉得最近这个Claude Code hype多少是有点问题的....如果你仔细去看他完成任务以后的cost分解，你就会发现它大量使用了haiku（最低端模型，大概类似4.1 mini）处理command任务，带来的问题就是经常任务执行的不彻底，以及失败以后放弃尝试其他可能性。最后的结果就是经常性超额宣称自己的成果。

[Codegass @OsilyWei]

多模型混合调用的问题在于，高级模型容易被低级模型的错误结果误导，且缺乏有效的校验机制，导致最终结果偏差不断积累。而在这方面，Cursor的做法更为稳健：只要不启用 auto 模式，模型的智能水平就能保持一致。同时，它通过内置的linter和apply model（Cursor 自研模型）帮助agent快速发现并纠正错误

[Codegass @OsilyWei]

在个人电脑上，目前大小和性能最平衡的embedding model应该是非gte-QWen2-1.5B-Instruct莫属了，效果远超openai的embedding.

[Codegass @OsilyWei]

写了一周末的email assistant，结果打开gmail发现Gemini已经内置了🤣

看来任何ai功能都需要重新设计交互来产品化，才能提供新价值，并且让用户觉得有吸引力，不然只会被大厂迅速copy.

[Codegass @OsilyWei]

Exactly! I am switching to Gemini 2.5 pro which is much better.

[Daniel Destefanis @daniel__designs]

@mrabino1 @benhylak In cursor at least it goes wild, ignores prompts instructions, project rules, and will add tons of additional ideas or unasked for features

It will sometimes rewrite entire files, create new ones instead of using old ones, cheat at passing tests etc it really depends

[Codegass @OsilyWei]

O3太妙了，以agent形式训练的推理模型才是未来啊。

明天拿它做个小项目试试。

很久没这么兴奋过了

[Codegass @OsilyWei]

Superhuman也不太行....就没有能把ai和email结合好的邮箱服务么？

筛选邮件就那么难么？

[Codegass @OsilyWei]

@karminski3 😗印象里现在好像都是把thinking token全扔掉不做为上下文。openai有个专门的blog，说了下他们就是这么管理o1上下文的。

https://t.co/IBa7IFBbfK