AI

On my commute I listened to a podcast episode featuring Songlin Yang—nicknamed the mother of linear attention—where she patiently explained the mechanics behind the architecture. The structure is red-hot right now, especially because several frontline Chinese model labs are doubling down on it. I figured it was worth retelling the story in my own words. How Is a Token Generated? To keep things simple, let’s focus on the inference stage of a large language model—the everyday scenario where a user asks a question....

上班路上听了号称线性注意力之母的Songlin Yang的一期播客，小姐姐在里面科普了线性注意力的原理。最近这个结构非常火，特别是国内几个一线大模型厂商都在押注这个赛道。我觉得有必要用自己的话把这件事再说一遍。 一个Token是怎么生成的? 为了简单起见，我们聚焦在大语言模型的推理阶段——通俗点讲就是普通用户向大模型提问这个场景。假设用户问了这么一个问题:“我想元旦去看雪，有什么地方推荐的吗?“用过大模型的人都知道，接下来大模型就会开始一个字一个字地回答你。 大模型回答的每一个字，都可以拆解成以下几个阶段: 1. Tokenization(分词) 简单讲就是把人类的语言变成一串数字，每个数字都是一个编号。比如上面那个问题在ChatGPT处理前会转变成这样一串编号:[37046， 33565， 111， 24186， 6079， 99…]。你会发现这个编号序列的长度和用户输入的问题长度不一样，这是因为这个过程可能会对一些字词进行合并或拆解，不过这个小细节跟我们今天的主线关系不大。 2. Embedding(嵌入) 这个过程很重要也很简单，可以理解成查字典。拿上面的编号去查一个大表，每个编号都会对应一个很长的向量，用来在所谓的"语义空间"表示这个编号代表的token。 理解清楚向量是什么需要一定数学背景，但它起到的作用其实很直观。比如"苹果"和"香蕉"两个词语的编号可能差得很远，一个是888，一个是6666，中间差了几千个别的词，这些词也不知道是些啥，可能是"硅谷”、“大模型"这些跟水果一点关系都没有的词。但变成语义空间的向量就不一样了，好的语义表示可以让近义词的向量之间距离近，无关的词之间距离远，甚至还可以做一些运算。 经典例子是在向量空间里"皇帝”-“男人”+“女人"约等于"皇后”。用这个例子应该能让embedding起到的作用更直观。这个很大的表在模型训练好后是固定的。 3. Transformer处理 Transformer这个词，以往的大众媒体宣传都在借用变形金刚的形象，可能是因为比较酷。其实人家的本意更接近变压器，是在把输入的信息转变成另一种形式来输出。现在的大模型会堆叠好多层的Transformer，也就是做好多次变换，但每一次其实原理都一样。 最开始Transformers结构 这个过程有两个重要的步骤: 第一步:Self Attention(自注意力机制) 大名鼎鼎的自注意力机制，也是本公众号名字的由来。名字很玄乎，做的事情说起来却很直观——把当前上下文中与生成下一个token最相关的信息聚合起来。 具体地说，我们在上一步已经把每个token都转化成了embedding向量。假设当前上下文的长度是L，embedding的维度是d，那就变成了一个$L×d$的矩阵。首先，会对这个矩阵做三种不同的变换，数学上就是乘以三个不同的矩阵，得到三个变换后的矩阵Q(query)、K(key)、V(value)。 现在我们取出第L个Q向量(也就是最后一个)去和1L-1个K里面的向量分别计算相似程度。算完之后我们可以取出最相似的那个K向量对应的V向量来作为预测下一个token最有用的信息。但这种取max相似的做法太生硬了，所以用了一种叫softmax的方法——按照和第L个K向量的相似程度把1L-1个V向量加权求和起来。 可想而知，为了做这个加权求和，我们要做L-1次向量点乘。每生成一个字就要做L-1次，如果生成总长度为n，那这个计算量的量级就是n的平方。现在的大模型已经会思考了，随便就能给你生成几千上万个token，这个计算量就非常巨大了。 Self Attention示意图，原图来自https://newsletter.theaiedge.io/p/understanding-the-self-attention 第二步:FFN(前馈网络) 这一步不是本文重点，是对上面算出来的聚合后的上下文向量做一些变换。用的网络结构叫前馈网络FFN。因为生成下一个token只要处理一个向量，所以计算耗时不大。 但这个网络也很重要，实际上是大模型的全局记忆或永久记忆之所在(自注意力主要是在操作上下文，是工作记忆)。其特点是参数量特别大，因为参数量越大，可以记忆的东西就越多。但参数大也会带来计算量大的问题，于是就有了MoE混合专家网络——把总参数量用很多个专家来撑大，但大家术业有专攻，每次只取几个专家来激活处理。在此先按下不表，有兴趣的朋友可以自行扩展阅读。 4. 输出Token 对变换后的向量，再通过一个分类器分到token集合上，取出概率最大(根据采样方式不同也可以不是最大的)的那个token作为这一步的输出。 如何串起来? 这个也比较容易理解。当用户输入问题之后，我们走完上面的流程就会得到一个新的token。然后我们又可以拿它的id去查embedding，对这个embedding做qkv变换，然后拿这个q去和1~L的k去做softmax拿到聚合后的上下文向量，再经过FFN和分类器就又得到了下一个token。如此循环，直到世界的尽头——啊不，直到输出停止token。 线性注意力解决了什么问题? 自注意力机制在这里最主要的问题是速度，因为O(n^2)的时间复杂度，随着模型输出变长，会越来越慢。 从上面的过程里聪明的你可能发现了一些讨巧的地方，那就是每个位置的token对应的QKV向量如果能保存起来的话，做一次embedding到向量的变换就可以一直用，一劳永逸，省下一些时间。 但这种方法是以空间换时间。GPU上的存储是很宝贵的，而且模型这么大，也需要占据很大的空间。所以现在大家就想办法把这个缓存搬到内存上，甚至是固态硬盘上。于是推波助澜了今年存储股的暴涨(参考镁光、SanDisk以及国内的兆易创新)。 线性注意力就是要解决这个问题。总体的框架并没有变，但是做了一些关键的修改。首先就是把softmax这个函数给干掉，于是这个上下文计算变成这样: $$ \begin{aligned} &&&&\mathbf{o_t} = \sum_{j=1}^t \mathbf{v}_j(\mathbf{k}_j^\top \mathbf{q}_t) &&&&& \mathbf{k}_j^\top \mathbf{q}_t = \mathbf{q}_t^\top \mathbf{k}j \in \mathbb{R}\\ &&&&= (\sum_{j=1}^t\mathbf{v}_j\mathbf{k}_j^\top)\mathbf{q}_t &&&&&\text{By associativity} \end{aligned} $$ 于是可以发现，整个过程可以逐步计算得到了，每一步的计算复杂度跟当前的长度无关，只跟V和K的大小有关。同时，因为括号里的东西是累加的，我们可以不用记录历史的kv了，KV cache完全不需要了。假设称括号里的东西为状态矩阵: $$ \mathbf{S} = \sum \mathbf{v}_i\mathbf{k}_i^\top $$...

This week didn’t revolve around a single theme. It wasn’t a neat follow-up to last week’s “product fundamentals,” nor a deep dive into “triple-speed coding” like 10.19. It felt more like a handful of scattered observations and experiments, each sparking new thoughts. If there’s a shared thread, it’s probably this: in an era where AI rewires productivity, what actually matters? Beautiful view outside the Google office When Productivity Explodes, Taste Becomes Scarce I spent a day at Google’s San Francisco office for an event....

这周没有单一的主题。没有像上周那样聚焦于"产品基本功"，也没有像10.19那样围绕"三倍速编程"展开。更像是几个零散的观察和实践，但每一个都让我有些新的思考。如果非要找个共同点，大概是：在AI改变生产力的时代，什么才是真正重要的? Google办公室窗外美景 当生产力爆炸，品味成为稀缺 这周去了Google三番办公室参加一个活动，虽然内容比较high level，但质量不错。他们总结了AI时代产品的几个变化，我记住了三个： 第一是意图做输入。用户很多时候不需要像以前一样亲自操作，只要把想干什么告诉产品就行。第二是多模态，模型的进步使得理解和操作非结构化数据变得前所未有的容易。第三是自动化，产品可以直接交付结果，而且能在你不使用它的时候继续为你工作，达到更好的效果。 这三点对照起来看，还有很多产品形态会发生变化。特别是第三点"自动化"，我觉得特别值得深挖。ChatGPT只在你问它时为你工作，但优秀的人类都有很强的主观能动性，能在背后下功夫。未来的产品如果能具备这种"主观能动性"，不再是被动响应，而是主动为用户创造价值，那会是质的飞跃。 会上有个观众问了一个很有意思的问题。她是孩子的母亲，自己学计算机出身，很热爱这一行也感受到了红利，但她担心孩子不能再学这个了。嘉宾David Benjamin(Google AI Future Fund的co-founder)说这个问题很难回答，但他的感觉是： 现在是人类历史上生产力最发达的时候，你可以靠说话实现一个app，创作一幅图画甚至视频，品味变得特别重要。而品味是靠很多人文学科比如历史、艺术来培养的。 这个观点我相当认同。当技术实现的门槛被AI大幅降低，差异化就不再来自"能不能做到"，而是"做出来的东西好不好"。什么是好?这就需要品味。而品味的培养，恰恰不是靠刷LeetCode和背设计模式，而是需要更广阔的人文积累。 小团队效率高是有理论基础的 这周听了一个很棒的播客《OpusClip 增长秘诀：如果每个阶段只让我选一件事做》，里面提到的一个观点和我最近的实践高度吻合：创业公司应该多用SaaS服务，不要老想着招人自己干。嘉宾君陶说他自己手上就有十几个SaaS产品在用。 构建用户反馈闭环他们就用了至少4种产品 美国这边真的有太多SaaS服务，而且定价都很便宜。比如我们最近打算给用户发newsletter来提高留存，以往都是找内部的newsletter团队帮忙，但他们事情也蛮多，一般需求得两三天才能消化。这次我直接买了个服务，一个月只要35美元。功能非常完善：所见即所得的模板编辑器、详尽的打开率报表，应有尽有。配置起来花了不到两小时，马上就把邮件发出去了。 还有一个需求是做小搜索模块。搁以前肯定是搞个embedding推理服务，建个ES索引，吭哧吭哧搞一会。这次直接丢Pinecone里，免费套餐就包圆了，只需要往里丢文档和搜索查询，其他全不用管。 这两个还算常规。但其实像用户调研这种看起来很复杂的事情，都有SaaS可以帮你完成从招募、访谈到分析的全流程。 对于创业公司人手不够，如果没有用这些服务，大部分是因为"不知道"。但对于中型公司，可能还有一大原因是思想上的惯性。毕竟有这么多工程师，得安排上活啊。结果可能是搭了一大堆完成度不高的模块，反而在项目过程中消耗了不少时间来修复各种并非主线上的问题——最近我就遇到了好多。最后没能在产品验证、商业验证这些核心问题上花足够的时间。 所以说，小团队做到比更大团队效率高，也许是有理论基础的。组织变大之后如何保持高效率，也是真的需要水平的。 从Build到Growth的转型 听了播客里嘉宾的话，这周花了不少时间试着去找产品的第一批核心用户。以前没怎么做过，发现这事确实很难。 我们试了几个渠道。第一个是从老产品导流，目前看转化率非常低。从逻辑上看这两个产品的人群确实差得比较远，但毕竟是free lunch，所以还是做了。 然后试了去Reddit发帖，带来了几个用户。但这个渠道有一些门槛，不少subreddit都有很严格的发帖审核。我的一个比较生硬的广告让我被管理员永久封号了。这个教训挺深刻：在社区里，你不能只是把产品扔进去就走，而是要先理解社区的文化和规则，建立信任，然后再自然地分享。 不过Reddit也让我发现了一些宝藏。有好多给做产品的人讨论的板块，比如r/alphaandbetausers、r/startup，大家贴自己的产品然后互相给反馈，氛围挺不错的。 目前正在观察Twitter。从帖子的阅读数来看，Twitter的传播速度应该更快。但如果根据播客里讲的，Reddit中某些板块里有核心用户的可能性比Twitter大，后面还是应当加大力气。 这种帖子能带来曝光，但难找到核心用户 AI让创建一个app变得容易，但找到第一批核心用户依然很难——对我来说是这样。OpusClip的君陶他们做得就很好，播客里也有很多可执行的干货。我们之前更擅长build，现在也要往找用户和增长上多花功夫。 这和上周的观察是一脉相承的。10.26那期我说"效率不等于方向"，Composio的CEO虽然英语不好，但在Twitter上孜孜不倦地发视频最终火了起来。现在轮到自己实践，才真正体会到：build只是第一步，让合适的人知道你的产品，可能更难也更重要。 把这周的几个观察串起来看，有个隐隐约约的线索： AI降低了技术实现的门槛。一晚上5700行代码，一周完成三周的工作量，这都是前几周我们亲身体验过的。SaaS服务进一步降低了基础设施的门槛，Mailgun两小时就能配好newsletter，Pinecone免费套餐就能搞定搜索。 但AI并没有降低"做对的事"的门槛。什么是好的产品?谁是你的用户?怎么找到他们?如何和他们沟通?这些问题依然需要品味、判断和大量的实践。 在AI时代，技术实现不再是瓶颈，真正稀缺的是对"什么值得做"的判断，以及把它做好、让合适的人知道的能力。 这可能也解释了为什么小团队效率可能更高：当实现的成本大幅降低，组织的核心价值就从"能调动多少资源"变成了"能多快做出正确的决策"。而决策速度，往往和团队规模成反比。 下周见。

This week I listened to LatePost Chat’s episode “Agents Are Opportunities—and So Are Agent-Building Tools | Starting From OpenAI DevDay.” Henry, the guest, mapped out six major inflection points in the evolution of agent tooling: from ChatGPT’s launch at the end of 2022 to the recent wave of “computer use.” Every leap in model capability exposes a new “body part” that needs strengthening, and each gap spawns a new tool....

这周听了晚点聊的一集播客【Agent是机会，造Agent的工具也是|从OpenAI开发者日聊起】，感觉很好。嘉宾Henry在里面梳理了Agent工具发展的六次主要升级，从2022年底ChatGPT发布，到最近的Computer use能力，每次模型能力的跃迁都会暴露"身体"的短板，催生一波新工具来补齐。 听完之后有种connected the dots的感觉。这两年确实就是这么过来的，每隔几个月就有新的能力出来，每次都会带起一批新公司。LangChain抓住了最早的编排需求，LiveKit赶上了语音交互的浪潮，E2B、Daytona切入了代码执行的沙盒，Browserbase又站在了Computer use的风口上。 这套梳理让我想起了这几周在旧金山Tech Week见到的那些创始人。当时还不知道背后的脉络，现在一对照，才发现他们确实都是在各自的节点上抓住了机会。 左起分别是E2B，Composio，Pokee AI，AGI Inc的Founder LangChain的启示 Henry提到LangChain从最早的编排框架一路演化，现在已经是独角兽，靠Observability & Evaluation实现了几千万美元的ARR。我以前对LangChain的态度比较不屑，觉得它引入了太多复杂的抽象，社区里批评的声音也不少。有技术能力的公司确实不需要那层抽象，反而会让Agent和已有系统的整合变得麻烦。 但现在想想，这其实说明市场需求和技术理想之间存在错位。我比较了解或者说我本身就属于"有技术能力"的群体，但这个群体并不是全部。有大量有实际需求但没有相应技术能力的人，对他们来说，用LangChain几行代码写一个Agent是很不错的选择。 更重要的是，LangChain没有止步于最初的框架，而是紧跟着行业发展推出新产品，相继推出了LangGraph、LangSmith两个新产品，最终找到了现在这个赛道。这种"抱紧赛道，敢于Pivot，横向发展"的路径，和上期Reynold Xin的观点是吻合的。 LangChain团队已经挺大了 Composio的震撼 播客里提到了Composio这家做工具调用的公司，7月份融到了2900万美金。我在Tech Week的panel上见过他们CEO。根据嘉宾介绍，这是一家纯印度班底的公司，人很少，在印度成立，为了离用户更近刚全体搬来旧金山不久。 当时听他和Panel的其他Founder聊，就觉得英语好差，我比较难听懂。那时还不知道他们融了这么多钱，更不知道他们刚从印度搬来。如果你没见过这个人，只是看到融资的消息，至少我个人是会产生慕强情绪的，肯定会仰视。但面对面见过，这种活人感会消灭掉很多神秘感，让人更客观一点。我觉得这种对外界和对自己的客观是很重要的，不卑不亢。 但震撼的不是这个。据说Composio的CEO就是在Twitter上孜孜不倦地发视频，最终火了起来。硅谷的工具型公司也会举办build day、hackathon来让潜在用户接触到自己的产品。 我身边也有团队尝试做过工具调用相关的产品，当时做了个类似mcp.so的MCP server索引，试图通过提供测试报告来做出差异化，并寄希望于通过SEO来获取流量。但事实证明这条路走不通。截止到目前，有用的MCP server（比如各大平台、工具第一方发布的）不需要测，其他MCP server根本不值得测；导致想象中的差异化并没有价值。而且SEO的策略也有非常大的问题。 Composio老哥确实是个搞流量的好手 用户在哪里？ 对比一下就能看出差异。身边的开发者（特别是AI的early adopter）已经比较少用Google了，但AI的社区（Reddit、Twitter、各种散落的Discord频道）却在变得越来越繁荣。与其被动地等搜索引擎的流量，更好的做法是到用户最密集的开发者社区去主动宣传。 搜索流量和社区流量更本质的差异是用户的intent纯度。搜索引擎搜MCP，即使真的点到了你的网页，也并不一定代表他是MCP的真正用户。但如果你办一个限定使用自己产品的build day，在场的开发者会真正地沉浸式用你的产品，可以带来非常多有价值的反馈。在产品的早期，找到真正的核心用户是非常关键的。 一个很有趣的细节是，虽然身边的团队在build MCP index，但日常工作生活中团队里没有一个人是MCP的重度用户。现在反思起来，这是一个巨大的问题，也从侧面反映出对真正用户的理解是很差的。自己必须是用户，或者至少离典型用户很近，不管是不是AI，这都应该是做产品的基本准则。 而Composio的CEO，英语不好，但在Twitter上"不完美但持续输出"。这种状态，其实就是上一波互联网产品的基本practice：尽早发布，尽快迭代。一个产品如果没法launch到真正的用户群体中，获得反馈，进入迭代，基本上就会进入做也不是、停也不是的尴尬状态。LangChain也一样，被人骂不可怕，说明有人用，最怕的其实是无人关心。 效率不等于方向 这让我想起前两周的观察。10.11那期我提到Claude Code让我一晚上写了5700行代码，10.19那期提到AI让我们一周完成三周的工作。效率的提升是实实在在的，三倍速的编程确实让人兴奋。 但从效率提升到产品成功里面还有非常长的路要走。方向错了，工具再强也没用。或者说，当你连用户在哪都不知道的时候，做得再快也只是在错误的路上狂奔。 从10.05那期我提到"东一榔头西一锤子，结果就是毛都没搞出来"。现在回头看，不是我们不够努力，也不是工具不够强大，而是在最根本的问题上——谁是用户、用户在哪、用户需要什么——没有想清楚。 总而言之一句话，做产品的基本功依然重要，甚至比过去更重要。

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....