即刻App年轻人的同好社区
下载
App内打开
阿晓Ocean
933关注1k被关注3夸夸
对世界保持好奇
阿晓Ocean
4天前
DeepSeek Harness 的“一切皆插件”的设计理念,为 Harness RSI 打下了基础。它的目标应该不是用户体验、用户增长或商业化,而是 Harness 在模型基础上,能让 Agent 距离 AGI 再拉近多少。

现阶段模型的测评常常是在固定 harness 的条件下去看不同模型在各种 benchmark 上的得分。或许未来会有越来越多的 Harness 测评,在固定模型的条件下去看不同的 harness 在各种不同 benchmark 上的得分。

钱一张: 批评 dsh 太自嗨而缺乏“产品”力的人可能没想过 它大概压根就不是为人,而是为 agent 写的 - 和梁“自进化”主题一脉相承 - 万物可装载-确定性依赖与执行-无副作用卸载 - event sourcing 可回溯及实时观测状态 - 对标的不是当日同发的 v4pro;而是其首创 mla moe 的 v1,影响在 v3 才迎来了爆发 想象一下,盛传 ssi ilya 要发一个自进化的大脑;配上这个可自进化的高达🤯

00
阿晓Ocean
2月前
AI 写作第一原则:不刊之论
00
阿晓Ocean
2月前
阿晓Ocean
2月前
wolai 笔记 alpha 内测时就开始用,到现在已经 2000 多天了。3 年前看到 wolai 被阿里收购时,还想着终于不用担心应用倒闭后跑路了。如今看到创始人从钉钉离职的消息,感觉自己真的要转 obsidian 了。
30
阿晓Ocean
3月前
Opus的(逻辑)圆滑像欠拟合,简洁、优雅、直击重点,直到发现现实比推演复杂得多,简洁变成了漏洞百出。

GPT的(逻辑)拧巴像过拟合,全面、深入、滴水不漏,直到发现在钻牛角尖,全面变成了无效浪费。
00
阿晓Ocean
3月前
公路上汽车速度的极限并不取决于工程技术的极限,毕竟赛车的速度会比公路上车速快很多,而取决于在高速下,是否普通驾驭车的人,都能够跟得上车开的速度,是否能够确保整个公路系统安全稳定运行。 最后,对于 AI Coding 来说,会从马车时代,快速跳过人类驾驶,进入自动驾驶时代吗?但似乎准确描述需求比准确描述目的地要困难太多。

阿晓Ocean: 我们需要造一辆车,能够去掉车前的人,但是带上车上的人,以及不会伤害路上的人

00
阿晓Ocean
3月前
最近两天也在思考这个问题,不过最后思考的结果比较悲观,就是纯skill很难做成交易闭环生态。 因为技能是纯文本,无法按照使用量计费,难以杜绝盗版,二创迭代升级之后的价值归因难以清晰划分,都为交易生态的设计提供了巨量的挑战。 最后相对可行的可能会类似于知识星球里的知识付费分享,以及小红书 PDF 攻略的分享,基于社区人与人的信任,局限在小圈子里。

写增长的子木: AI Agent 生态:啥时候像 APP Store 一样,支付等环节闭环? 这样有价值的 Skill 才会更多吧?

00
阿晓Ocean
3月前
经常有人说用户对于模型没有忠诚度,但对Harness或者agent却有忠诚度,因为更好的模型来了之后,我们想要换模型只需要简单切换API即可,但是想要切换Harness,迁移记忆等文件却是更加复杂的事情。

然而我发现如果不是用于商业产品对外服务,而仅是用于自身使用,对于模型也可能存在某种忠诚度。

因为外界的benchmark不代表自身真实工作流表现。自身使用的场景下,通常没有一个完善的自动化测评流程,而是需要在实践中逐渐积累对模型能力边界的把握,积累对模型的信心。当新模型出现之后,特别是不同厂商的新模型出现之后,升级切换模型意味着需要重新花时间探索能力边界,建立这种信任,这可能带来的工作量比记忆迁移的工作量更大(记忆迁移通常只是移动一些 Markdown 文件),所以人们反而可能继续使用已有的熟悉的模型。除非目前使用的模型在某个确定性的痛点上被新模型解决,或者自己所在的行业的整个社区已经形成了明确的共识,才会尝试进行模型的迁移。

比如我目前的主力编程模型还是 GPT 5.4 [1M],在 GPT 5.5 1M 上下文下放到 Codex 之前,不会把 5.5 作为主力模型。

A 社封了 3 次号之后,也暂时没有动力尝试 Opus 4.8

大家有深度使用 Opus 4.8的,可以评论区聊聊对比GPT 5.4和 GPT 5.5 的效果(特别是 Coding 领域)。

阿晓Ocean: 在几个月前,用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 了。

00