Hi there 👋

This week a teammate and I ran a deep experiment: we handed almost the entire coding workload of a new project to AI. The outcome was stunning—we wrapped up in a single week what normally takes us three. Yet behind that unprecedented velocity were a few counterintuitive truths that quickly surfaced. The Cost of Efficiency and Cognition on Overdrive When coding hits three times its usual speed, the first thing to tire out isn’t your hands—it’s your brain....

这周，我和同事进行了一场深度实验，几乎完全依靠AI编程来推进一个新项目。结果令人震撼，我们在一周内完成了过去需要三周的工作量。然而，在这前所未有的效率背后，一些反直觉的真相也浮出水面。 效率的代价与注意力的过载 当编程进入三倍速，我首先感受到的不是疲惫的双手，而是过载的大脑。任务的节奏被极大地压缩了：设计、体验、修改功能的循环快得让人应接不暇。虽然有Rate limit来让人强制休息，但当注意力频繁切换的强度也和效率一样达到了过去的三倍，这本身就成了一种新的认知负担。 我的同事采用了更极端的并行策略，他同时在三个目录上开了3个独立的工程分支用Claude Code开展工作。这虽然进一步推高了速度，但也带来了新的挑战，比如时常需要去解决代码合并时的冲突。这让我意识到，在AI时代，工具的速度与人类管理上下文的能力之间，需要寻找新的平衡。这点来看Openai的产品能力还是更强一点，早早就有web版，让每个任务都有独立的上下文。 软件工程范式的静默革命 AI编程的强大，正在悄然改变我们习以为常的软件工程范式。过去，我们花费大量心思在设计复用、规避技术债上。而现在，我们可以更大胆地选择直接重写代码，因为执行的代价已经大大降低。 这种“轻装上阵”的感觉非常好，每个新项目都能从最贴合当前需求的代码开始，历史包袱不再沉重。我们甚至实践了一次：当依赖的其他部门API无法及时修改时，我们干脆利落地自己重写了一个。 这让我联想到在周末华源年会上听Databricks的Co-founder Reynold Xin说的一个观点，未来我们或许会进入一个“个性化软件”的时代，每个公司都能拥有为其深度定制的后台系统。这就像短视频重塑内容行业一样，AI正在让软件开发的节奏和模式发生根本性的变化。 Reynold Xin真是平易近人的大佬 人的进化：从实现者到定义者 那么，在AI承担了大量实现工作的未来，人的价值在哪里？ 华源年会上AMD的VP建议年轻人成为全栈工程师，我认为这个方向是靠谱的，但关键中的关键，是向上聚焦。最重要的“栈”将不再是技术实现，而是需求洞察与产品设计——包括商业模式、用户流程和交互体验。实现环节，可以大胆地交给AI。 未来的软件行业，可能会像如今的视频创作领域一样，门槛降低，创意勃发。从只有大工作室能制作视频，到今天无数UP主的百花齐放。当实现的工具变得普及，比拼的核心就变成了谁的创意更好，谁更懂用户。 Ed Chi, Yangqing和Ramine Roane的Panel质量挺高 寻找属于人的节奏 这一周的实践让我深刻感受到，我们正处在一个生产力范式转换的奇点上。AI带来的不仅是效率的直线提升，更是对整个工作节奏和人类角色的重新拷问。 正反馈来得飞快，半天就能看到一个新功能从无到有，这无疑是激动人心的。但只要最终决策者是人，我们的注意力和认知节奏就设定了生产力的天花板。如何在AI的“永动”和人类的“深度思考”之间找到属于我们的黄金平衡点，将是下一个阶段我们都需要探索的课题。 模型训练的迷思与公开模型的洪流 最后再聊一聊模型的训练。 在年会下午的路演上，我发现许多公司都在谈论收集数据、训练自己的专属模型。但这与我近两年的切身经验有些冲突。 路演上大部分是种子轮或pre-seed轮的公司，在业务方向尚未明确、用户反馈循环还没有建立起来的探索期，自训模型很可能是一种负担。它会让团队尝试新方向的步伐变得沉重。我的一个切身体会是：如果利用现成的货架模型加上优秀的产品设计，都无法达到一个及格的基线，那么指望通过自训模型来扭转局面，通常是非常困难的。 更何况，公开模型的进化速度一日千里，性能和价格都在以惊人的速度变得更好。回顾两年前，我们完成一次模型的微调并上线，周期至少一个月，而需求可能早就变了。在今天，至少需求验证阶段拥抱公开模型的洪流，或许比闭门造车更为明智。

I tried a different workflow this week: let the AI interview me first, then spin my answers into a story. Two big moments stood out—catching the vibe coding wave with Claude Code, and feeling the AI heat in San Francisco during Tech Week. Vibe Coding Sends Productivity into Orbit Trying vibe coding wasn’t a spontaneous whim. I’ve long used Copilot mainly for inline completion, occasionally switching to its chat mode, and I relied on Codex to build a few standalone features....

这周决定换个写法，先让AI把我刚经历的一切梳理成问题，然后再把答案拼接成故事。主题集中在两个瞬间：一个是抓住 vibe coding 这股风，另一个是在三番的 Tech Week 感受到的AI热浪。 Vibe coding 让效率坐火箭 尝鲜 vibe coding 其实并不是一个突如其来的决定。之前一直在用 Copilot 当补全工具，偶尔切换到问答模式解题；Codex 则帮我撸过一些独立功能。本周被同事疯狂安利，终于认真试用了 Claude Code。真正的契机是最近开了几个需要完整端到端体验的 side project：算法做完了，总得有个前端去展示。以前这种需求我会用 Gradio 将就一下，但扩展性、体验都差点意思。现在模型写前端的能力明显升维，索性试试看。 事实证明，Claude Code 的体验的确对得起“vibe coding”这三个字。不只是模型本身换挡提速，更是整套产品设计承载起了新的工作流。同样的问题扔在 Copilot 的 agent 模式里用Claude Sonnet 4.5就是搞不定，在 Claude Code 里却能稳稳落地。工程化能力、上下文调度、交互节奏，这些外围细节直接决定了“模型能力”能否发挥出来。 Claude Code：第一次把额度用爆的工具 这是第一次我把一个 20 美元的月度套餐刷出“session limit”。用 Claude Code 紧张工作三个小时就打满了 session，周额度瞬间消耗 16%。这在 Copilot、Codex 身上从未发生过。站在生产力角度也能感受到质变：一个晚上交付了 5700 行代码。我保守估计这相当于以前一周在非常熟悉领域的输出。算一笔账：硅谷中级程序员十来分钟的工资，换来“整周产出”，到底是 AI 便宜还是人类昂贵？更讽刺的是，在国内就算找水平一般的外包，一人天也得四百块人民币。 三小时就到Session Limit 当然，“高效率人士效率更高”只是结论的一面。另一个严肃的问题是：我们需要重新审视自己的技能栈和时间配置。木桶理论正在被改写——如果某块短板 AI 可以补，那就别再死磕了。比如后端程序员为了独立开发硬啃前端，如今的 ROI 已经低得可怜。我的 vibe coding 达人朋友甚至拿 Claude Code 写完了申请日本签证所需的材料并用浏览器填表提交，证明这类工具已经具备了让人眼前一亮的通用性。 调教模型的门槛正在上升 Claude Code 能够“稳”还有一个被低估的原因：我特意读了官方的最佳实践博客，照着写了 CLAUDE....

Went to the Silicon Valley 101 Alignment conference today. After being a listener for several years, I finally saw Jane and Qian in person. Did not expect the scale to be this big—absolutely packed, and not just Chinese attendees; plenty of international friends too. As Xiaodi Hou said: Silicon Valley really is the promised land. The collective hunger for new tech and new chances is just awesome. Got quite a lot out of today....

今天去参加了硅谷101的Alignment大会，作为好几年的听众，终于亲眼见到了Jane和Qian。 没有想到今天规模这么大，现场真是人山人海，而且不只有华人，外国友人也有不少。 就像侯晓迪讲的，硅谷就是promised land，对新技术新机会的追求热情和氛围真的很棒。 今天收获还是不少，首先是有感于自ChatGPT发布以来，他们的订阅数竟然涨了如此之多。我在前几天也简单看了一下“数字生命卡兹克”的数据，虽然没有硅谷101那么成功，但毫无疑问也是借AI东方崛起的典型代表。 作为一个打酱油的技术自媒体，以及似有若无的AI从业者，不免有虚度光阴的感觉。 另一方面，作为一个近几年都没有什么增长的内容产品参与者，心里更加不是滋味。 AI这个内容机会绝对也是对我们敞开大门甚至还蛮适合的，但我们只会竹篮打水靠运气的搞法在内容的把握和执行上真的连门都没有入。 硅谷101近几年的订阅数 有几个印象比较深的panel(观点): 第一个panel羽北讲的关于数据效率的角度很有意思。如果学习的效率足够高（像人一样高），那就可以有属于每个人的AI（每个人的数据都不一样），看起来thinking machines有往这个方向发展的意思？ Bill主持的强化学习的panel。首先Bill比知乎头像圆润不少。另外这个Panel是最detailed的，Zheng Wen前面都在I agree，最后展望竟然也是三分之二嘉宾觉得分层推理未来可期，Process reward可能要死灰复燃？总体听下来现在RL这个领域好像没有什么非共识？虽然很早就做了不少SFT，但是没有进一步做RL一直是自己比较大的遗憾，后面还是要找机会补上这一课。 沐神的keynote也有不少干货，这是我第一次听沐神讲东西，感觉现场发挥比论文精读之类录播视频略差一些。他讲例如即使做垂直模型也要保证通用任务水平不要降低太多、对于要求细致的问答系统AI很容易犯错都比较符合自己之前工作里面积累的认知，他们最后放的metrics增长也很亮眼了，半年追上GPT-4o，8个月超过专业人类。以我的感觉这个速度还是很合理的，再快可能比较难（要么没价值），再慢创业公司也玩不太下去。所以各位老板们，在定义好问题之后，要有给团队6-8个月时间开发的预期。 侯晓迪的keynote全场最另类，大谈如何在afterhype活下去。第一次听他讲东西，挺吸引人的，类似的还有panel里的胡渊明。他们虽然很年轻，但都已经在自己领域耕耘多年，也都或多或少经历过高潮和低谷，此时专注和执着就开始散发出魅力，也会体现出价值。在此Echo一下硅谷101，他们也是积累多年借势爆发。反观我们，其实也在不错的赛道上，但东一榔头西一锤子，结果就是毛都没搞出来。 新技术新产品 本周的product hunt感觉有些平淡，比如第一名的定位是lovable for slides，有点为垂直而垂直的意思，lovable 做slides很难吗，感觉这么一写，这个产品的天花板都被自己拉低了。Strata这个MCP产品感觉是长在工具调用的一些共识上的，也确实是一个痛点。这里面其实是有很多技术的空间可以发挥，把 One MCP server for AI agents to handle thousands of tools 做好并不容易。但对于MCP的价值我一直比较怀疑，严谨认真的Agent开发者一定会把很多时间花在Tool上，搞一层MCP并没有什么价值，也不会搞thousands of tools。能用好几十个tools已经非常非常强大了。 PH上周榜单 Thinking Machines发布了一个叫Tinker的产品，是个Post training的平台。我感觉随着最近一些高水平开源模型的发布（比如openai oss，Qwen next等），Post training要迎来新的春天了。总的来说，我相信基础模型的能力总会来到增长缓慢的一天，那时候就像羽北说的，不易公开获取的个性化数据价值就会变大，结合水涨船高的开源模型，后训练会变得更加有效。他只说了训练的效率，serving的效率靠Lora来解决确实是一个很好的方案。不太可能部署一大堆”稍微不同“的完整模型，那样显存的效率太低了。很有可能下一代的openrouter就是从标准化模型路由，进化到支持个性化模型部署和路由？ 立个Flag 决定开一个“每周AI观察”系列，每周至少写一篇文章。因为这个日新月异的AI时代真的有太多值得记录和交流的东西。希望大家监督并多多批评指正。

ACL 2025年5月的ARR cycle已经出分了，估计这会儿学术圈又忙起来了，作者在忙着写rebuttal，AC在忙着找紧急审稿。而我这个审稿人却感觉格外的轻松，因为这次看的论文分都太低了，估计作者都不会来rebuttal，自然我也不用再回复作者。 这一次给我分的都是RAG和Hallucination方向的论文，我一共审了5篇，打分情况是3篇2分，2篇2.5分。说实话，总体上我已经抬一手了，全凭良心打的话，还要更低一点。 给不熟悉ARR评分标准的读者稍微补充一下，ARR是5分制，分以下9档： 5 = Consider for Award: I think this paper could be considered for an outstanding paper award at an *ACL conference (up to top 2.5% papers). 4.5 = Borderline Award 4.0 = Conference: I think this paper could be accepted to an *ACL conference. 3.5 = Borderline Conference 3 = Findings: I think this paper could be accepted to the Findings of the ACL. 2.5 = Borderline Findings 2 = Resubmit next cycle: I think this paper needs substantial revisions that can be completed by the next ARR cycle....

The scores for ACL 2025’s May ARR cycle have been released, and I imagine the academic community is busy again—authors scrambling to write rebuttals, area chairs frantically searching for emergency reviewers. Yet as a reviewer, I feel exceptionally relaxed because the papers I reviewed scored so low that I doubt the authors will even bother with rebuttals, which means I won’t need to respond either. This round, I was assigned papers in RAG and Hallucination directions....

The recent “Dawn of the East” hype around Manus.im sparked significant attention. However, its evolution over the past few days has been dramatic, with numerous open-source projects attempting to replicate it. OpenManus, one of the earliest clones, claims to have replicated it in just 3 hours, though its parent team MetaGPT has been working on agents for much longer. I believe both impressive performances and failures are normal at this early industry stage....

前几天号称“东方破晓”的Manus.im着实火了一把。但这几天的演进也充满戏剧性，已经有一大堆开源项目来复刻他们。OpenManus算是比较早的一个，号称3小时就复刻了，但其实他们背后的MetaGPT团队已经搞Agent很久了。我感觉目前的产品惊艳或者翻车都很正常，整个行业才刚开始。但OpenManus这样的项目是一个很不错的学习Agent开发的切入点，它足够简单，也覆盖了足够多的东西。这篇文章是我的一个学习笔记外加一些思考，跟大家交流。 事先说明，开源代码库变化很快，我是2025年3月7号下载的，所有内容都基于当时的版本。先来看一下整个工程的结构： . ├── LICENSE ├── README.md ├── README_zh.md ├── app │ ├── __init__.py │ ├── agent │ │ ├── __init__.py │ │ ├── base.py │ │ ├── manus.py │ │ ├── planning.py │ │ ├── react.py │ │ ├── swe.py │ │ └── toolcall.py │ ├── config.py │ ├── exceptions.py │ ├── flow │ │ ├── __init__.py │ │ ├── base.py │ │ ├── flow_factory.py │ │ └── planning.py │ ├── llm....