几条教训
1. 不要依赖 agent 读论文或者高质量博文,
后果:思维深度大幅度下降,灵感触发时机大幅度减少,浪费大量的时间去理解 agent 的垃圾表达。
2. 不要把搞科研/技术学习 和 英语学习混在一起。
后果:效率低下,推进缓慢,失去耐心后放弃,灵感和思考都需要时间积累,混合学英语这个目标会大幅度延迟你的思考,让你的脑子在来个任务上来回切换
3. 不要因为 token 用不完就想着 background 跑点东西,把 token 用掉,不影响你的主线
后果:除非你编了稳定的 workflow,否则即时奖励更强的 vibe coding 一定会吸引你的注意力,打断你的深度思考。
总结,一定要感受自己在 agent 时代下的认知水平的提高速度,到底是加快了,还是不变,还是退步了。如若不然会沉迷于 shallow work,最后认知退化,导致阅读长文字、深度思考都没耐心,人就废了。
和 agent 讨论科研、做 vibe coding 项目的第一件事情,确实是先构建 GLOSSARY.md 即术语表
matt 的思想是对的,在术语表没有定下来的时,直接和 agent 讨论会出现大量生造词,非常难懂,导致浪费时间
分析 Anthropic 2021 内部研究路线图
原文作者 Jared Kaplan,2021 年 7 月的Anthropic 内部文档,附带 24 条同事批注。因为被告而公开。
Jared Kaplan,普林斯顿物理学 Phd,scaling law 共一、GPT3 作者
以下是本人的分析【全文见评论区文章】,我尽可能总结出了 Kaplan 思考问题的方式,试图去理解他们在 5 年前是如何思考 AGI 这个问题的
1. 当目标太大时,找到最有价值的概念验证(proof of concept)进行快速迭代,例子
- AGI 太遥远,所以先把目标定在 coding agent
- coding agent 能力太多,先把目标定在 tool use + RL + LLM
- 能用的 tool 太多,先把目标定在提高 LLM print debugging tool 的调用上
2. 找到问题的核心并且深入思考
- coding agent 可以理解成人类意图到代码的翻译器
- 那么 mid training 的核心就是找到一批数据能够体现**人类的意图和对应的代码之间的联系**
- 由此自然想到大佬们当年提出的要收集的一大堆数据,包括 diffs、PRs、comments、Stack overflow 等等
如果不是被起诉,我们永远都不会知道,Anthropic在2021年就已经完美地预言了现在的AI发展。
我刚看完这份 @AnthropicAI 在诉讼中曝光的内部文件,叫《Concise Research Roadmap》,最后更新于2021年7月。
这份文件由Anthropic联创Jared Kaplan撰写,里面还保留了 @DarioAmodei 、 @NotTomBrown 、 @AmandaAskell 、 @ch402 等一批核心研究人员的内部评论。
文件上甚至还标着「Highly Confidential–Attorneys' Eyes Only」(高度机密,仅限律师查阅)。
我仔细看完之后,真的有点感慨。
因为今天我们讨论的Coding Agent、Tool Use、长上下文、RL、自动化反馈,甚至Agent的安全问题,在这份五年前的研究路线图里,基本都已经出现了。
而且远不只是一些模糊的概念。
首先,Anthropic在2021年就已经明确提出,要做一个具备软件工程师能力的AI助手。
在文件第一页,他们就写道,希望开发一个通用AI助手,可以通过对话帮助用户创建、编辑和解释软件。
包括开发浏览器插件、编写函数、发现Bug、设计API、讨论代码风格和最佳实践等等。
最终目标是让AI展现出一名软件工程师同事所具备的能力。
你会发现,这不就是今天Claude Code正在做的事情吗?
更有意思的是,他们当时就认为,要实现这个目标,需要大规模生成模型、长期记忆,以及通过自动化奖励和人类反馈进行强化学习。
甚至连Roadmap都已经想得非常清楚了。
第二,他们当时就专门把RL for Tool Use列成了一项重要研究方向。
研究的核心是让大语言模型学会使用工具,理解环境和目标,并通过强化学习不断改进。
当时他们提出的具体任务包括搜索、printf调试等,还准备研究工具使用能不能让模型获得比监督学习更好的Scaling效果。
今天Agent领域讨论的一大堆问题,五年前他们就已经开始思考了。
第三,最让我意外的是,他们当年甚至就在讨论Coding Agent的产品形态。
Tom Brown提出,代码仓库浏览是一个简单而有价值的工具,可以从这里开始。
Nelson Elhage则表示,如果AI能够主动查找项目中的类型定义,会是一项很强的能力。
Andy Jones进一步提出了两条不同的路线。
一条是打造最优秀的AI程序员,另一条是先验证AI使用工具的能力。
Dario Amodei的回答是:短期优先后者,长期优先前者。
而且同一份文件里,Sam McCandlish就已经开始担心,如何安全地部署非沙箱化工具。
Dario特别强调了部署阶段执行代码的工具。
你再看看今天围绕Coding Agent的Sand box、权限控制和代码执行安全的一系列讨论。
真的很难不感慨。
第四,他们很早就意识到,模型能力和Alignment不能脱节。
Amanda Askell在评论里担心,如果能力研究集中在代码领域,而对齐研究只关注自然语言,那么未来可能会出现模型能力越来越强,但对齐研究无法充分覆盖这些能力的情况。
所以她强调,两者应该紧密结合。
这其实也是今天Agent安全研究面临的重要问题。
我觉得这份文件最有意思的地方,是它让我们重新认识了Anthropic这家公司。
2021年的时候,ChatGPT甚至都还没有发布,整个行业对大语言模型未来能做什么,都还没有今天这么明确的认识。
但Anthropic的这群研究人员,已经把软件工程助手作为通向AGI的一个具体研究目标,并且围绕模型规模、数据、长上下文、工具使用、强化学习和安全,制定了一套相当完整的研究路线。
至少从今天回头看,他们对技术发展方向的判断,确实非常超前。
而且更值得注意的是,这份文件讨论的很多问题,直到2026年都还没有被彻底解决。
五年前他们在思考如何让AI成为软件工程师的同事。
五年后,我们已经开始讨论,如何让AI独立完成整个软件工程任务,甚至参与改进自己的模型和研发系统(AKA:RSI)。
有时候AI的发展看起来快得不可思议,但仔细回头看,你会发现,有些人其实很早就已经知道自己要往哪里走了。
paper 本身就很有意思
发现让 model 以特定 token 开头作为 cue
可以提高 performance
博客甚至太展示了整个科研的思路,甚至包括作图
最有价值的是,作者先思考要画什么图,然后再设计实验
这种“面向读者”的科研思路大家可能都想到过
我也想到过,但没有得到重视
I wrote a blog post detailing the writing approach I took while working on my recent paper: sophielwang.com/blog/paper-w…
I describe the behind the scenes for how this paper came to be, why and how I storyboarded figures before running experiments, and some figure design tips! :)
上次openai 的 researcher 项目申请的太晚了,到现在还没批下来,干
这次我光速申请!
We are offering 10,000 scientists the highest usage tier in Google Antigravity free of charge for 6 months. Please apply! forms.gle/WvmBbPvRbpKG1BPn9
原来arxiv pdf 转 md 早就有现成的了
这省得我再去调用 minerU 等半天了,好东西
看了下是今年一月刚出的新网站,vibe coding 让这个时代涌现了大量的工具
arxiv2md.org/
open ai 纯抄是吧
抄完 grok bot 抄 jev
dots 号称不消耗 token,反手把pro 额度降低一半
前几天有人说 open ai 在玩朝三暮四
我看没毛病
OpenAI 出了个 Decisions API,背后跑的是 Luna,专门做实时决策
你提前定好问题和几个候选答案,把文本或者图片传进去,它直接告诉你该选哪个
做路由、决定下一步让哪个 agent 来处理,这种有限选项的场景挺合适的
目前还是 limited preview,说是这几天会更大范围开放
xitter.cf/OpenAIDevs/status/2105…
先解决下 grok 4.7 这么笨的问题吧,我都想退订 300USD 了,没啥用,codex 我都想退订了别说 grok 了
BREAKING: X and SpaceXAI are looking to Reboot X Premium into the new X Subscription.
You will get Cursor, Grok, and X benefits all in one unified plan with more benefits and access to be announced.
This is fantastic news!.
Here is what the early access announcement looks like on android.
I dont know when this will go live but know its been something they have been working on for weeks.
发现可以用手机上的 Grok Bot 远程查看和指挥 herdr 里的任何 coding agent session
它会读 herdr 里每个 session(Grok Build、Claude Code、Codex 都行)的屏幕告诉你,还能替你往里面发指令。
环境要求:
1. 电脑上用 herdr 跑你的 coding agent(Grok Build / Claude Code / Codex)。
2. 电脑上装 Grok Bot,并允许它在这台电脑上执行命令。
3. 手机上装 Grok Bot,和电脑登录同一个账号。
给 Grok Bot 发什么:
• 「用 herdr 看一下我电脑上现在有哪些 agent 在跑,各自在干嘛」
• 「某某项目进行到哪了?」
局限:看到的是屏幕快照,不是实时流式输出
好处:不用做任何其他配置,省事
我决心要系统学一下 vibe coding
实践已经够了,现在要补上理论了
然后发现,去年 5 月的时候 karpathy 还在说,开发一个 app 很简单,但是部署很麻烦,到处要配置,而 agent 根本搞不定,他在文末还在质疑,怎么可能 2027 年就能自动化编程呢?
而现在还没到2026 年的四季度,仅仅过去了 16 个月,agent 的发展已经令人有了“天上一日,地上一年”的感觉,16 个月前的 coding 仿佛是几年前的事情
一切发展的太快了...
I attended a vibe coding hackathon recently and used the chance to build a web app (with auth, payments, deploy, etc.). I tinker but I am not a web dev by background, so besides the app, I was very interested in what it's like to vibe code a full web app today. As such, I wrote none of the code directly (Cursor+Claude/o3 did) and I don't really know how the app works, in the conventional sense that I'm used to as an engineer.
The app is called MenuGen, and it is live on menugen.app. Basically I'm often confused about what all the things on a restaurant menu are - e.g. Pâté, Tagine, Cavatappi or Sweetbread (hint it's... not sweet). Enter MenuGen: you take a picture of a menu and it generates images for all the menu items and presents them in a nice list. I find it super useful to get a quick visual sense of the menu.
But the more interesting part for me I thought was the exploration of vibe coding around how easy/hard it is to build and deploy a full web app today if you are not a web developer. So I wrote up the full blog post on my experience here, including some takeaways:
karpathy.bearblog.dev/vibe-c…
Copy pasting just the TLDR:
"Vibe coding menugen was exhilarating and fun escapade as a local demo, but a bit of a painful slog as a deployed, real app. Building a modern app is a bit like assembling IKEA future. There are all these services, docs, API keys, configurations, dev/prod deployments, team and security features, rate limits, pricing tiers... Meanwhile the LLMs have slightly outdated knowledge of everything, they make subtle but critical design mistakes when you watch them closely, and sometimes they hallucinate or gaslight you about solutions. But the most interesting part to me was that I didn't even spend all that much work in the code editor itself. I spent most of it in the browser, moving between tabs and settings and configuring and gluing a monster. All of this work and state is not even accessible or manipulatable by an LLM - how are we supposed to be automating society by 2027 like this?"
See the post for full detail, and maybe give MenuGen a go the next time you're at a restaurant!
我从 Opus 4.6 到 Opus 4.7、Opus 4.8、Opus 5
转到 GPT 5.6 SOL、GPT 6 Astra、GPT 6 Pro
同时间还在用 Grok 4.6、4.7
再转到 Opus 5.5,最后转到 Fable 5.1。
我的看法是,各种 SOTA 模型可以称之为在部分 task 上的专用领先模型,但真正能让你感觉像一个人的模型只有一个,那就是 Fable 5.1。这才是最强的模型。
Anthropic虽然比较恶心,但说实话,它的模型真的是厉害
这个事情其实也挺好的,各种不同领域有特长的专用模型可以对 agent 的使用人员进行分流,避免 Anthropic 显卡的压力太大。
根据以往的经验来看,任何一家厂,当它的显卡压力变大时,都会开始降智。所以,大家在各自擅长的领域上进行分流,是一件好事儿























