IT社区推荐资讯 - ITIndex.net

DeepSeek再放大招，推理速度狂飙85% 怎么做到的？

Mon, 29 Jun 2026 20:35:43 CST

6月27日，DeepSeek公开DSpark技术报告和DeepSpec代码库。DeepSeek-V4的底座模型没有变，新增的是一个服务端推测解码模块：DSpark。DeepSeek在HuggingFace模型页里把话说得很直白：V4-Pro-DSpark和V4-Flash-DSpark"不是新模型"。这两个页面指向的是同一个模型检查点，加上推测解码模块后的服务版本。

这意味着，DSpark没有让模型突然变聪明。它瞄准的是模型上线之后，怎样更快、更便宜地把答案吐出来。

技术报告称，DSpark已部署在DeepSeek-V4的线上服务系统中。在真实用户流量下，相比此前的MTP-1生产基线，也就是DeepSeek上一代线上推测生成方案，V4-Flash的每用户生成速度提升60%到85%，V4-Pro提升57%到78%，前提是匹配吞吐条件。

这里的"快"也要收住口径。 它主要指生成阶段，也就是模型持续输出token的那一段速度，不等于所有用户请求的端到端响应时间都同步快了85%。 长提示词的预填充、检索、工具调用、排队和网络延迟，仍然会影响用户实际等多久。

模型上线后，还有一笔推理账

这件事没有新模型发布热闹，但它更接近AI公司每天面对的现实： 模型训练完之后，成本没有结束。

聊天机器人、代码助手、智能体和搜索式产品，每一次调用都在继续消耗GPU时间。模型慢一点，用户等得久一点；推理贵一点，厂商就更难把高质量模型开放给更多场景。

AI行业过去两年更习惯讨论训练成本：一家公司要买多少GPU、建多大的集群、花多少钱训练下一代模型。但模型真正变成产品之后，另一类成本会不断冒出来：推理。

训练像一次大工程，推理更像水电费。 只要用户还在问问题、智能体还在跑任务、代码助手还在生成补丁，模型就要继续消耗算力。

大模型服务最后都会回到两个指标：速度和单位token成本。API定价页面通常按输入token和输出token收费，企业内部也会把不同模型、缓存、路由和上下文长度拆成成本项。

DSpark不能直接等同于降价，但如果同样的GPU集群能在相近吞吐下让用户更快拿到答案，它意味着同样的硬件可以服务更多用户，或者同样的用户体验可以用更少的卡来提供。

"先猜，再验"

推测解码的思路，可以粗略理解成"先猜，再验"。

大模型生成文本时，通常是一个token接一个token往外吐。前一个token出来，后一个token才知道该接什么。这种方式稳，但慢。推测解码会让一个更轻的草稿模块提前猜出一段候选token，目标大模型再批量验证。猜对的部分直接接受，猜错的位置再修正。

小模型不能替大模型做决定。最终接受哪些token，仍然由目标模型校验；正确实现下，它改变的是生成方式，不改变目标模型的输出分布。 加速来自让大模型批量验证候选，而非逐步生成。

DSpark改的，是草稿怎么生成

论文没有只停在"先猜，再验"这层解释。它重点处理了草稿怎么生成。

现有的草稿策略大致分两类。自回归草稿器更稳，因为后一个token会看见前一个token，但草稿变长，延迟也就跟着上去。而并行草稿器更快，可以一次猜出一整段，但每个位置各猜各的，后面的token容易和前面脱节，接受率越往后越容易下滑。

DSpark选择折中。 论文题目里的关键词是"半自回归生成（Semi-Autoregressive Generation）"，它先用并行方式提出一段候选，再用一个轻量顺序层修正后续token的条件关系。这样既保留并行生成的速度，又让后面的候选能看到前面已经猜了什么。

另一个关键点，是验证多长一段。

候选token猜得越多，不一定越省。如果明知道后半段很可能被拒绝，还交给大模型验证，就是把GPU时间花在低价值位置上。 DSpark会看候选的置信度，也看当前系统负载，动态决定验证长度。 GPU空一些，可以多验；负载高时，就把算力留给更可能被接受的部分。

论文标题里的"置信度调度（Confidence-Scheduled）"，说的就是这件事。

DSpark站在已有技术路线之上

DSpark站在推测解码已有路线之后，更像是DeepSeek把这条技术路线推到线上服务后的公开参照。

SpecInfer早在2023年就把小模型预测、token树（token tree）和并行验证放进大模型服务系统里；Medusa在2024年提出给模型加多个解码头，一次预测多个后续token；EAGLE系列则围绕草稿模型和动态草稿树（draft tree）继续提高接受率。vLLM、SGLang、TensorRT-LLM这类推理框架，也早就把推测解码当作降低延迟的重要工具。

DSpark的位置，在于它把几个生产问题放到一起处理：草稿怎么生成，候选怎么保持连贯，验证长度怎么随负载变化，线上真实流量下速度到底能提高多少。

论文里反复出现的关键词，也从"模型能力提升"转向每用户生成速度（per-user generation speed）、匹配吞吐（matched throughput）、服务等级协议（SLA）这些服务侧词汇。

这也解释了为什么不能只挑最大的数字看。论文里确实还有661%、406%这样的高倍吞吐数据，但它们来自更严苛的每用户速度目标：在那种设定下，旧基线本身已经接近服务能力的边界，DSpark的相对优势会被放大。

真正能说明常态收益的，还是前面那组数字：匹配吞吐、真实流量分布、对比对象是MTP-1。

DeepSpec能复现什么

DeepSeek同时开源了DeepSpec。这是一套用于训练和评估推测解码草稿模型的代码库，包含数据准备、训练和评估流程，也放出了Qwen3、Gemma等模型上的相关检查点。

不过， 开源不等于"下载即复现"。 项目文档里提示，默认Qwen3-4B配置下，目标模型缓存可能接近38TB；默认训练脚本假设单节点8张GPU；如果要对齐论文结果，训练设置必须严格一致，特定领域还需要对草稿模型做额外微调。

外界可以验证方法的一部分，也可以把DeepSpec移植到其他开源模型上，但DeepSeek-V4线上服务里的那组速度提升数字，仍然来自DeepSeek自己的硬件规模、流量分布和生产系统调度。

开源的是方法，不是环境。

社区最关心的是复现边界

X上的讨论没有停在叫好，更像一群工程师在追问：这套办法到底怎么跑、能不能复现、边界在哪里。

AI研究者Ravid ShwartzZiv把DSpark概括为两类草稿器的折中：并行草稿器快，但接受率沿候选块衰减；自回归草稿器稳，但延迟随草稿长度上升。他特别提到DSpark加入的两个组件：置信度判断头和负载感知调度器，并补了一句关键边界："和所有推测解码一样，它是无损的。"

工程师更关心的是能不能跑起来。vLLM贡献者Rafael Caricio称自己在双DGX Spark GB10上把DeepSeek-V4-Flash的DSpark模式跑通，单流解码约60 tok/s，大约是MTP-1的1.5倍。

他同时提到，真实代码会话暴露了合成基准测试看不到的问题：瓶颈不只是计算核心的速度，而是长上下文下草稿接受率会明显下滑。

Tech2Wild也给出了相近方向的现场数据，显示V4-Flash-DSpark已有人在特定vLLM环境里试跑。但这类结果高度依赖硬件型号、框架补丁版本、上下文长度和并发设置，换一套环境结果可能完全不同。

也有人专门提醒边界。AcingAI在X上指出，DeepSeek报告里的高倍数仍然是"自家硬件、自家MTP-1基线、匹配吞吐条件下"的结果，外部尚未完整复现。

这提醒我们，DSpark的一部分优势来自负载感知调度，而调度效果天然依赖生产环境的流量规模和硬件配置。

同样的能力，更少的算力

南华早报在6月28日的报道中，把DSpark放在推理瓶颈、芯片压力和用户等待时间里看。这个角度比"DeepSeek又发了什么模型"更接近产品现实。

AI公司还会继续比模型能力，但当能力差距被压缩，谁能把同样的能力更快、更便宜地交付出去，也会成为竞争的一部分。

DeepSeek这类公司尤其需要把这件事讲清楚。DeepSeek一直把低成本、高效率作为外界理解它的重要入口，从模型训练叙事到API价格，最被关注的不是它有没有再堆一个更大的参数规模，而是它能不能把同等能力做得更便宜。

DSpark延续的正是这条线：它不证明V4突然更聪明，它证明V4在服务用户时可以少浪费一部分推理算力。

如果把视角再放宽一点，推理优化也会影响开源模型生态。开源模型过去常被认为"便宜"，但真正部署时，显存、吞吐、并发、延迟和运维复杂度都会变成成本。

一个模型能开源，只说明大家能拿到它；能不能便宜地服务大量用户，还要看推理栈能不能跟上。

DeepSpec放出Qwen3、Gemma等检查点，说明这件事已经不只停在DeepSeek-V4自己身上。迁移到什么程度，还要看社区适配、框架支持和硬件兼容的实际进展；但从目前公开信息看，DeepSeek已经让这条路线走出了自家模型。

DSpark的价值就在这里。 它给V4增加了一层更接近生产系统的推理服务工具，而不只是一个新能力标签。

接下来值得看的，已经不止是DeepSeek自己能跑多快，还包括这条路线能被多少人走通。DeepSpec已经放出检查点和训练流程，推测解码正在从一家公司的工程选择，变成开源推理降低成本的通用手段， 前提是其他框架和硬件能跟上。

查看评论

从日报到 OKR：我是如何用 Claude + Obsidian 构建工作记忆系统的

Thu, 25 Jun 2026 22:13:00 CST

零、背景

每次到写 OKR、绩效总结的时候，很多人都会遇到一个问题：

这半年到底做了什么？

明明每天都很忙，但真正开始写总结时，却发现很多事情已经记不清了。

我也经历过这个阶段。

从大学开始，我就一直保持记笔记的习惯。

这些年陆续使用过：

Evernote
印象笔记
有道云笔记
VSCode + Markdown
Obsidian

工具一直在变，但核心需求始终没变：

如何把每天的工作沉淀下来，并在需要的时候快速形成总结。

2023 年开始，公司出于数据安全考虑，禁止使用外部云笔记记录工作相关内容。

于是我开始尝试使用 VSCode 记录纯文本 Markdown 笔记。

由于使用纯文本格式，我顺便引入了 Git 来管理笔记版本。

到了 2026 年，公司内部提供了大量 Claude Token。

于是我开始尝试：Obsidian 负责记录，Claude 负责整理。

经过半年实践，我已经实现了：

自动生成每日总结
自动生成周报
自动生成月报
自动生成季度总结
自动生成半年总结
自动生成 OKR 材料

效果远超预期。

本文分享一下我的实践过程。

一、把每天的工作都沉淀下来

每天早上，我会通过快捷键 Ctrl + D 自动创建当天的工作笔记。

这份笔记既是：

Todo List
工作日志
项目记录
临时备忘录

也是我一天工作的驱动中心。

一天中所有待处理事项，我都会优先记录到这份笔记中。

例如：

业务需求
技术方案
Bug 修复
故障处理线
临时会议
待跟进事项

都会先写下来。

我的原则很简单：所有事情先记录，再处理。

这样做有两个明显好处：

1）不会因为临时事项打断当前工作流
2）不会遗漏后续需要处理的任务

完成一个任务后，我会及时补充：

当前进度
处理结果
最终结论
后续计划

然后再开始下一项工作。

久而久之，每天的笔记就成为了最完整的工作记录。

二、用 AI 自动生成每日总结

有了完整的原始记录后，总结工作就可以交给 AI 来完成。

通常在下班前，或者第二天早上，我会执行一个 Prompt，让 Claude 自动分析当天笔记并生成日报。

Claude 会自动提取：

当天完成事项
当前进行中的工作
遇到的问题
关键结论
后续待办

相比手工编写日报，这种方式不仅节省时间，而且覆盖更加全面。

不过生成之后，我不会直接保存。

而是会再进行一次人工 Review。

重点检查：

是否遗漏重要事项
是否理解错上下文
是否总结错误
数据是否准确

确认无误后，才作为正式的每日总结保存下来。

这一步非常重要，后面会专门讲。

三、用 AI 构建总结金字塔

很多人使用 AI 的方式是：让 AI 直接帮我写月报。

这种方式的问题在于：如果原始数据不完整，最终生成的内容也不会准确。

我的做法正好相反。

我把总结过程设计成一个逐级聚合的结构：

    每日笔记
    ↓
每日总结
    ↓
每周总结
    ↓
每月总结
    ↓
季度总结
    ↓
半年总结
    ↓
OKR总结

与每日笔记类似，我也配置了快捷键：

Ctrl + W：生成周总结模板
Ctrl + M：生成月总结模板
Ctrl + Q：生成季度总结模板
Ctrl + H：生成半年总结模板

这些快捷键只是负责生成对应模板。

真正的总结工作仍然由 Claude 完成，都配置成 command 了。

这样就形成了一套完整的工作记忆体系：

日总结来源于日笔记
周总结来源于日总结
月总结来源于周总结
季总结来源于月总结
半年总结来源于季总结

最终再结合公司的 OKR 模板，自动生成绩效总结材料。

整个过程几乎不需要重新回忆过去发生过什么。

因为所有信息都已经沉淀在系统中了。

四、AI 总结最容易忽略的问题：垃圾进，垃圾出

刚开始使用 Claude 时，我犯过一个错误。

生成总结后只是简单看一眼。

觉得差不多就保存。

结果到了月总结阶段发现：

很多内容已经出现明显偏差。

例如：

项目状态错误
工作量统计偏差
已完成事项被认为仍在进行中
某些关键成果被遗漏

后来我才意识到一个经典原则：垃圾数据，只能得到垃圾总结

如果每日总结出现错误：

    日报错误
    ↓
周报错误
    ↓
月报错误
    ↓
季度总结错误

误差会不断累积和放大。

尤其是在 AI 自动聚合总结的场景下，这个问题会更加明显。

因此后来我增加了一个固定流程：

    AI生成总结
      ↓
人工Review
      ↓
修正内容
      ↓
保存归档

每次大约投入 5～10 分钟。

但收益非常明显。

经过修正后的每日总结，会成为后续所有总结的可信数据源。

这样生成的周报、月报、季度总结与实际工作内容几乎完全一致。

也让后续 OKR 总结变得非常准确。

五、AI 最大的价值，不是帮你写总结

很多人认为：AI 的价值是帮自己写日报、周报。

但半年实践下来，我最大的感受是：AI 真正的价值，不是生成文字，而是帮助建立工作记忆。

以前写 OKR 时，经常会出现这样的情况：

做过但忘了
做了很多却说不出来
明明很忙却无法量化成果
总结时只能靠回忆拼凑

而现在：

打开半年总结即可看到：

做过什么
完成了什么
哪些仍在推进
哪些已经延期
哪些工作投入最多

所有信息都有据可查。

对于管理者来说：这是工作复盘工具。

对于工程师来说：这是个人成长记录。

对于需要写 OKR 的人来说：这是一份自动积累的成果档案。

回头看这半年，我最大的收获是建立了一套能够长期积累的工作记忆系统。

工具本身并不重要。

真正重要的是：用尽可能低的成本，把每天的工作沉淀下来，并持续形成可复用的知识资产。

这或许才是 AI 时代最值得建立的能力。

六、最后

目前这套流程已经覆盖：

日总结
周总结
月总结
季度总结
半年总结
OKR 总结

后面我还计划继续完善：

自动生成项目总结
自动生成个人成长报告
自动生成技术成果汇总
自动统计各项目的时间投入分布
自动生成年度总结

等后续完善后，再单独写文章分享具体实现细节与效果。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse
公众号 ID：tiankonguse-code

高盛警告AI泡沫：首个削减支出的巨头出现时，全市场将重新定价

Tue, 23 Jun 2026 20:32:00 CST

　高盛警告AI泡沫：首个削减支出的巨头出现时，全市场将重新定价

article.author.display_name

卜淑情

高盛警告，AI市场已如一根被拉伸的橡皮筋，市场对负面信号的持续漠视终将迎来临界点。一旦任何一家主要科技巨头率先削减AI支出，整个AI板块的估值逻辑将面临全面重构；同时低成本AI模型崛起，正挑战当前“高投入换增长”的逻辑。

AI资本支出热潮正在积聚系统性风险。高盛策略师警告，AI市场已如一根被拉伸的橡皮筋，市场对负面信号的持续漠视终将迎来临界点——一旦任何一家主要科技巨头率先削减AI支出，整个AI板块的估值逻辑将面临全面重构。

高盛全球银行与市场部门策略师Rich Privorotsky在周二的研报中指出，过去数周市场几乎无视了AI资本支出交易中出现的所有负面信号。他特别点出一个日益扩大的结构性背离：超大规模云计算商（hyperscalers）持续加码支出承诺，股价却持续跑输大盘；与此同时，以英伟达和台积电为代表的AI硬件股却逆势上涨。这一背离本身即是市场定价失真的信号。

科技股的压力已在市场层面有所体现。韩国综合股价指数（Kospi）在创下收盘新高次日即重挫10%，三星电子和SK海力士分别下跌逾12%；纳斯达克期货下跌约2.5%，美光科技盘前跌超7%，英特尔跌6.5%。

橡皮筋效应：支出承诺与回报预期的裂口

Privorotsky以"橡皮筋"比喻当前AI市场的内在张力。

他指出，亚马逊、Alphabet、Meta等超大规模云计算商在持续加大AI资本支出的同时，股价表现却持续落后，显示市场对其投资回报的信心正在悄然动摇。

问题的核心在于，当前整个AI板块的定价建立在一个单一假设之上：随着推理需求增长，资本支出将永远只升不降。"'略微减少'这一可能性，根本没有被任何人的预期所纳入，"Privorotsky写道。

这意味着，一旦预期出现哪怕微小的逆转，市场的重新定价幅度将远超线性预期。

东方低成本模型：颠覆西方定价逻辑的变量

高盛的警告背后，有一个具体的技术趋势正在加速演进。

Privorotsky指出，中国、日本等地区的技术进展正在大幅压低AI软件的运行成本，而这一变化目前尚未反映在超大规模云计算商的支出预测中。

据行业媒体报道，中国的GLM-5.2大语言模型完全基于华为处理器训练，使用了10万颗华为芯片，全程未涉及英伟达产品。这一案例直接指向一个核心风险：如果前沿智能可以在东方以西方一小部分的成本开发出来，那么当前西方科技巨头的巨额AI投入，将面临严重的过度投资风险。

"最大的资本配置者，同时也是过度投资风险敞口最大的群体，"Privorotsky警告称。

多重压力叠加，科技股估值承压

摩根大通国际市场情报部门的Federico Manicardi和Victoria Campos也对科技板块发出类似警示，并梳理了当前压制科技股的多重因素：过高的市场预期、亢奋的市场情绪、自由现金流匮乏、首席技术官们对飙升的token成本产生抵触、向低价模型的转型趋势、来自华盛顿的严苛限制，以及债务和股权供给的增加。

两位策略师还特别提示，编排（orchestration）、模型融合（model fusion）、量化压缩（quantization）等技术方向的进展同样值得关注，"因为这些进展指向效率的持续提升，以及定价能力的潜在逆风"。

谁会第一个踩刹车

在高盛的分析框架中，当前AI资本支出周期的"断裂点"，很可能来自某一家核心支出方的理性觉醒——当其意识到，将更少的资金投入AI、转而回报股东，才是更优的资本配置选择。

Privorotsky的警告指向一个市场尚未充分定价的尾部风险：在所有人都押注AI支出只增不减的当下，第一个踩下刹车的巨头，将成为触发全市场重新定价的引爆点。届时，从芯片制造商到云计算平台，整个AI产业链的估值逻辑都将面临重新审视。

风险提示及免责条款

市场有风险，投资需谨慎。本文不构成个人投资建议，也未考虑到个别用户特殊的投资目标、财务状况或需要。用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。

喷嚏网官方App :【安卓】在豌豆荚、360手机助手、小米应用商店，搜索：喷嚏阅读；【ios】App store里搜索：喷嚏网官方阅读；

喷嚏网官方网站：http://dapenti.com (海外访问：https://dapenti.com)

每天网络精华尽在【喷嚏图卦】喷嚏网官方新浪围脖

LLM 究竟是如何工作的？

Sun, 21 Jun 2026 11:09:44 CST

Machine Learning Transformers LLM Neural Networks AI

本文带你走一遍 LLM 的工作原理。现代 LLM 大多是由 transformer 块反复堆叠而成的，因此理解了 transformer 机制，你就掌握了大部分。

我将覆盖现代基于 transformer 的 LLM 内部的核心机制，避开那些复杂的数学。别误会，你应该学数学，但本文可以作为一个入门。

大多数现代 LLM 共享同一套 transformer 家族的骨架。差异来自于各自的训练数据、规模和配置选择，以及在此之上的后训练。读完本文后，你应该能够阅读许多现代 LLM 论文或模型卡，并知道每个部分在讲架构中的哪个组件。

路线如下：

Token——一串文本如何变成一组整数序列
Embedding——这些整数如何获得含义
位置编码——模型如何知道 token 的顺序
Attention——token 之间如何交换信息

多头注意力——模型如何同时追踪多种关系
前馈网络——模型存储结构的主要所在
残差流与层归一化——是什么让深层堆叠可训练
预测下一个 token——模型实际输出什么，以及生成循环如何运作
架构 vs 训练权重——现代 LLM 之间广泛共享什么，以及什么不同

文中穿插了一些简短解释（tiny explainer），无论你的背景如何都能跟上。

Tokenization（分词）

模型不直接阅读文本。它们读取整数 ID。这一步将你的提示转换为一组整数序列。

这个转换步骤叫做 tokenization（分词）。一个 tokenizer（分词器）接收一个字符串并产生一组整数序列，其中每个整数指向固定词汇表中的一个条目。现代 LLM 的词汇表通常包含数万到数十万个条目。

简短解释：token ID
token ID 是模型用于某个词汇表条目的整数。模型处理的是数字，而不是书写的单词本身。

Token 通常不是完整的单词。它们通常是子词片段。单词 "tokenization" 可能被拆分为 ["token", "ization"]。"running" 可能被拆分为 ["run", "ning"]。原因在于效率。全词词汇表太大，且无法泛化到新词。字符级词汇表又太小，迫使模型从零开始学习最简单的模式。子词分词则处于中间地带。最常见的片段成为单独的 token，罕见或新颖的词则由更小的片段组合而成。

简短解释：词汇表（vocabulary）
词汇表是分词器的固定片段列表。每个片段有一个 ID，模型只能直接接收来自该列表的 ID。

这种权衡在意想不到的地方表现出来。经典例子：问 LLM "strawberry" 中有几个 R。LLM 过去常常回答错误。这不是模型不会计数。而是模型不直接操作字母，它只操作那些恰好拼写出一个单词的 token ID——而这个单词人类会逐字母拆分。

不同的模型家族使用不同的分词器。GPT 模型使用 BPE（Byte Pair Encoding）变体。SentencePiece 在 LLaMA 风格的模型中很常见。选择影响计算量（更少的 token 意味着更少的工作）和多语言覆盖等，但基本形式相同：文本进，整数出。

现在提示已经是一组整数序列，下一步是赋予这些整数含义。

Embedding（嵌入）

一个像 1024 这样的 token ID 只是一个行索引。它本身没有任何意义。赋予它意义的是一个巨大的表，叫做嵌入矩阵（embedding matrix）。

每个模型都有一个。它对词汇表中的每个条目都有一行，每行是一个长长的数字向量。每行的长度就是模型的隐藏维度大小（hidden size）。在许多 7B 级别的模型中，这意味着每个 token 对应 4,096 个数字。更大的模型通常使用更宽的向量。

简短解释：向量（vector）
向量就是一个数字列表。在 transformer 中，每个 token 变成一个向量，这样模型就可以用它做数学运算。

当分词器把整数交给模型时，模型查找那一行并用向量替换它。那个向量就是 token 的嵌入（embedding）。它是模型对该 token "含义" 的表示，是在训练过程中学到的。

简短解释：嵌入矩阵（embedding matrix）
嵌入矩阵是一个查找表。token ID 进，学到的向量出。

这些嵌入的一个有趣特性是，语义上相似的 token 最终会得到相似的向量。"king" 的向量在空间中接近 "queen" 的向量，"Paris" 的向量接近 "France" 的向量。这一切都不是硬编码的。它是在足够多的文本上训练后涌现出来的，模型学会这些位置是因为它们能让模型更好地预测文本。

你可以对嵌入做算术运算，有时候确实有效。著名的例子是 king − man + woman ≈ queen。嵌入空间的几何结构携带着真实的语义结构，尽管没有人告诉模型要以这种方式构建它。

有一点需要明确：在这个阶段，每个 token 都被它的嵌入替换了，但嵌入本身不包含 token 在序列中的位置信息。"dog" 的向量无论在提示的第一个还是第五个位置，都是同一个向量。这是个问题。

这就是位置编码要填补的空白。

Positional Encoding（位置编码）

纯粹的 self-attention 没有内置的词序表示。没有某种位置信号，它无法直接知道 "dog" 在 "bites" 之前而不是之后。

词序会改变含义。所以模型需要另一个组件。它需要一种方式将每个 token 的位置注入到数学运算中。

简短解释：位置编码（positional encoding）
位置编码是模型获取顺序信息的方式。它告诉模型每个 token 在序列中的位置。

最初的 transformer 论文（Vaswani et al. 2017）的解决方案是给每个位置赋予自己的数字模式，并在任何其他处理之前直接加到每个 token 的嵌入上。位置 1 有一种模式，位置 5 有不同的模式，位置 100 有另一种模式。这些模式来自不同频率的正弦和余弦波。这样一来，位置 1 的 "dog" 的嵌入就不同于位置 5 的 "dog" 的嵌入，仅仅因为加在它上面的位置模式不同。

这能够工作，而且选择正弦编码的部分原因是它们可以外推到超出训练时见过的序列长度。但加法式的位置方案仍然有两个随着模型规模扩大而变得重要的问题。

首先，嵌入必须在同一组数字中同时承载含义和位置。能塞进去的东西是有限的。

其次，尤其是学到的绝对位置嵌入（learned absolute position embeddings）不能干净地泛化。如果你训练的提示最长 2,048 个 token，模型在训练时从未见过位置 5,000，那个位置的嵌入就不是以同样的方式学到的。

现代模型大多使用一种不同的方案，叫做 Rotary Position Embeddings（RoPE），由 Su et al. 于 2021 年提出，现在被 LLaMA、Mistral、Gemma、Qwen 和大多数其他开源权重家族所使用。直觉是：RoPE 不是将位置信息加到每个 token 的向量上，而是将 Query 和 Key 向量旋转一个取决于 token 位置的角度。位置 1 的 token 转一个小的角度，位置 100 的 token 转一个更大的角度。当两个 token 在后面的 attention 中被比较时，重要的是它们 Query 和 Key 旋转的差值，这编码了它们相距多远。

简短解释：RoPE
RoPE 代表 Rotary Position Embeddings。它不是加一个位置向量，而是旋转 Query 和 Key 向量，使相对距离在 attention 中显现出来。

实际的优点是真实的。RoPE 自然地编码相对位置（这更接近 attention 实际需要的东西）。它能更好地泛化到更长的上下文。而且它不给模型增加新的参数。

即使有了好的位置编码，现代 LLM 仍然有一个已记录在案的"迷失在中间（lost in the middle）"问题（Liu et al. 2023）。它们使用长提示开头和结尾的信息比使用中间的信息更可靠。这就是为什么像"把重要上下文放在前面"或"在末尾重复关键信息"这样的提示工程技巧确实有用。模型并不是同等地使用你提示的每个部分。

有了 token 含义和位置都编码完成，下一个问题是：token 实际上如何交换信息？

Attention

这就是赋予这个架构名字的机制。Attention。

在每个 transformer 层内部，attention 做一件事。它让每个 token 查看它被允许看到的其他 token，并决定哪些对接下来发生的事重要。

它通过同时给每个 token 赋予三个角色来实现。每个 token 被转换成三个新的向量，称为 Query、Key 和 Value（Q、K、V）。

简短解释：Q、K、V
Query 表示"我在找什么"，Key 表示"我匹配什么"，Value 是匹配成功时被传递的信息。

Query 问："我从其他 token 那里在寻找什么？"
Key 说："这就是我提供给正在看我的 token 的东西。"
Value 携带："这就是匹配发生时被传递的东西。"

同一个 token 同时扮演全部三个角色。Q、K、V 的变换是学到的矩阵，所以模型在训练过程中会弄清楚每个 token 应该寻找什么以及它应该提供什么。

匹配通过相似度分数来发生。每个 token 的 Query 与它被允许看到的每个 token 的 Key 进行比较，使用缩放点积（scaled dot product）。直观地说，这衡量了两个向量的对齐程度。缩放使得数字在 softmax 之前保持稳定。

简短解释：点积（dot product）
点积是一种简单的方法，用于给两个向量的对齐程度打分。对齐程度越高意味着匹配越强。

然后，匹配分数通过 softmax 转换为权重。Softmax 接收任意一组数字，将它们转化为总和为 1 的类概率分布。匹配分数更高的 token 获得更高的权重，然后用这些权重取 value 向量的加权平均。

简短解释：softmax
Softmax 将原始分数转化为加起来等于 1 的权重。大分数得大权重，小分数得小权重。

举个例子。考虑句子 "The cat that I saw yesterday was sleeping." 当模型处理 "was" 时，它需要弄清什么在睡觉。"was" 的 Query 向量与它被允许看到的 token 的 Key 向量进行比较。与 "cat" 的点积很高，因为模型已经学会像 "was" 这样的动词需要一个主语，而像 "cat" 这样的主语会产生与之对齐良好的 Key 向量。与 "yesterday" 的点积很低。Softmax 将这些分数转化为权重，"cat" 得到高权重，"yesterday" 得到低权重。然后模型对相应的 value 向量取加权和，所以 "cat" 的 value 主导了结果。"was" 的新表示现在主要由 "cat" 的 value 塑造。这就是几个位置之前的 token 如何成为被指代对象。

有一个 GPT 风格语言模型特有的约束，即它们从左到右生成文本。位置 5 的 token 只能关注位置 1 到 5。它不能关注位置 6、7、8 的 token，因为它们还没被生成。这叫做因果掩码（causal masking）。实现很简单：未来 token 的匹配分数低到经过 softmax 后权重几乎为零。

简短解释：因果掩码（causal masking）
因果掩码隐藏未来的 token。它阻止 decoder-only 语言模型在预测下一个 token 时向前偷看。

可解释性研究中最有趣的发现之一是关于一种专门的注意力头，叫做 induction head（归纳头），由 Anthropic 在 2022 年发现。这些头学会了在提示中发现 "A B … A" 这种模式，并预测接下来的会是 B。当模型第二次看到 "A" 时，归纳头回溯到上一次 "A" 出现的地方，看到它后面是什么，然后复制那个。它们是已知的最清晰的上下文学习（in-context learning）机制之一——LLM 从你的提示中捕捉到一个模式并继续它的能力。

简短解释：归纳头（induction head）
归纳头是一种注意力头，它注意到提示中重复的模式并帮助延续它们。

Attention 有一个巨大的成本。在全注意力（full attention）中，每个 token 与它被允许看到的所有 token 比较，所以提示长度加倍，工作量大约翻四倍。这就是为什么长提示运行成本高，以及为什么最近很多研究都在关注让 attention 更高效（FlashAttention、稀疏注意力、线性注意力）。

但一个注意力头只给模型提供一种关于关系的学到的视角。

Multi-Head Attention（多头注意力）

一次 attention 传递给模型提供了一种决定哪些 token 对其他 token 重要的方式。这还不够。语言中有许多同时发生的关系。主谓一致。代词及其指代的名词。句子之间的长距离引用。词序和局部短语。

多头注意力通过并行地运行多次 attention 来解决这个问题，每个并行的传递在它自己较小的空间中操作。每个并行传递被称为一个头（head）。

简短解释：注意力头（attention head）
一个注意力头是一次独立的 attention 传递，拥有自己学到的投影。

这部分经常被描述错误——包括在大量教程中。每个头并不是获取原始 token 向量的字面切片。每个头有自己学到的投影矩阵，将完整的 token 向量映射到它自己较小的 Q、K、V 向量。所以如果一个模型每个 token 有 4,096 个数字和 32 个头，每个头通常在 128 维空间中工作，但那 128 个数字是完整 4,096 的学到的投影，而不是固定的切片。是同一 token 的不同"视角"，而不是它的不同分块。

每个头独立运行它的 attention 传递。然后所有头的输出被拼接（concatenate）起来，经过一个最终的线性层，将它们混合回一个完整大小的向量。模型也学习那个最终的混合。

有意思的是，不同的头往往最终部分地专门化。模型从未被告知每个头应该做什么。专门化是在训练中自然涌现的。研究人员发现了追踪语法的头（将动词连接到宾语、冠词连接到名词）、弄清代词指代哪个名词的头、追踪位置模式的头、归纳头，以及更多。一个 transformer 层可能有 32 个头。一个现代前沿模型有几十层。所以一个典型的 LLM 总共有数千个注意力头，每个都贡献自己学到的视角。

有一个实际的成本问题驱动了近期的架构变化。每个头需要将所有已生成 token 的 Key 和 Value 向量保存在内存中，这样当生成新 token 时模型不必从头重新计算所有内容。这叫做 KV 缓存（KV cache），它是在长上下文长度下运行 LLM 的主要内存成本。

简短解释：KV 缓存（KV cache）
KV 缓存在生成过程中存储旧的 Key 和 Value 向量。它省去了模型每增加一个 token 就重新计算整个提示的工作。

现代 decoder-only LLM 大多使用一种变体，叫做 Grouped-Query Attention（GQA）。不是每个头都有自己的 key 和 value，而是头分组共享相同的 key 和 value 头。LLaMA-2 70B 有 64 个 query 头但只有 8 个 key/value 头。Mistral 7B 有 32 个 query 头和 8 个 key/value 头。结果几乎是全多头注意力相同的精度，但内存压力和推理成本大大降低。

简短解释：GQA
Grouped-Query Attention 允许多个 query 头共享更少的 key/value 头。这在保持多个 query 视角的同时削减了 KV 缓存内存。

Feed-Forward Network（前馈网络）

在 attention 完成 token 之间的信息混合之后，每一层还有第二步，但谈论它的人少得多。前馈网络。

如果说 attention 是 token 之间互相交谈，那么前馈网络是每个 token 独立地做更多处理。它对每个 token 的向量独立运行，没有跨 token 的混合。

前馈网络按顺序做三件事：

将 token 的向量扩展到更大的尺寸（原始 transformer 使用 4x，而现代 SwiGLU 模型通常使用不同的扩展尺寸）。
应用一个非线性函数。
将向量压缩回原始尺寸。

中间那个非线性步骤做了某件值得理解的具体事情。非线性是一个弯曲其输入的函数。最简单的，ReLU，对任何负数输出零，对正数原样传递。

简短解释：非线性（non-linearity）
非线性是一个函数，它阻止网络坍塌成一个大的线性变换。

没有它，FFN 只是两个线性层叠在一起，而堆叠纯线性数学会坍塌。两个线性层连续排列在数学上等价于一个线性层，一百层线性层连续排列仍然等价于一层。非线性阻止了这种坍塌，它是 FFN 能够做到比单次矩阵乘法更丰富的事情的原因。

原始 transformer 使用 ReLU。GPT 和 BERT 转向 GELU。现代模型如 LLaMA、Mistral 和 PaLM 使用 SwiGLU。扩展-然后-压缩的结构保持不变。被迭代改进的是非线性本身。

密集 transformer 模型的大部分参数都在 FFN 中，而不是 attention 中。大部分权重位于前馈层中。

而这些参数不是泛化的。它们承载了模型存储的大部分事实和语义结构。研究人员发现 FFN 内部的某些神经元与特定的概念或事实强烈关联。一个神经元可能在埃菲尔铁塔相关的文本上强烈激活。另一个在编程语言上。另一个在过去式动词上。当模型"知道"巴黎是法国的首都时，这个事实由特定层中的 FFN 权重和激活来表示。

这种存储记忆的特性有一个有趣的推论。研究人员已经弄清楚了如何在训练好的模型中直接编辑某些事实而无需重新训练。像 ROME（Rank-One Model Editing）这样的方法可以通过对特定 FFN 权重矩阵进行目标低秩编辑，将"埃菲尔铁塔在巴黎"改为"埃菲尔铁塔在罗马"。然后模型会倾向于生成与编辑后的关联一致的文本。

一些现代前沿模型已经开始用称为 Mixture of Experts（MoE）的东西替换密集 FFN。不是每层有一个前馈网络，模型有许多并行的 FFN（称为 experts），以及一个微小的路由网络来选择哪些 expert 处理每个 token。Mixtral 8x7B 每层有 8 个 expert；对于任何给定的 token 只有 2 个被激活。总参数量大幅增加，但每个 token 的计算量增长慢得多，因为只有少数几个 expert 在运行。这就是如何在不成比例地扩展推理成本的情况下扩展参数规模。

简短解释：MoE
Mixture of Experts 意味着模型有几个前馈网络，并将每个 token 只路由通过其中少数几个。

Mixtral 8x7B 总共有 467 亿参数，但每个 token 只用大约 129 亿。对于非常大型的模型，这已经成为一个常见选项，因为它让你在不断增加参数规模的同时不让推理成本成比例增长。

Residual Stream and Layer Normalization（残差流与层归一化）

残差流使得模型是"加法式"的而不是"替换式"的。在 attention 运行之后，或前馈网络运行之后，结果通常不替换 token 的向量。它被加到上面。逐个位置地加。新向量等于旧向量加上子块的输出。

简短解释：残差连接（residual connection）
残差连接将块的输出加回它起始时的向量。它为信息和梯度提供了通过网络的捷径。

跨越三十、五十或一百层，每层的贡献累积起来，而不是简单地覆写前一个向量。这个运行中的和被称为残差流（residual stream），它有一个奇特的性质。原始输入嵌入仍然有一条到达后面层的直接加法路径，与沿途每个子块的贡献混合在一起。

残差连接不是为 transformer 发明的。它们来自 ResNet（He et al. 2015），最初用于图像识别。动机是深层网络无法训练。训练信号在穿越许多层回来时变得太弱（或有时太强）。模型实际上无法从自己的错误中学习。添加一条捷径路径让信号直接从输出流回输入。突然间你可以训练有数百层的网络了。Transformer 继承了同样的技巧。

在现代可解释性研究中，残差流已经成为核心对象。每个组件——每个注意力头、每个前馈网络、甚至最后的反嵌入步骤——都从残差流读取并写回其中。

第二部分，层归一化（layer normalization），存在的原因要实际得多。没有它，残差流将无法保持稳定。流经数十次加法的数字倾向于要么爆炸式增长，要么坍缩到零。无论哪种情况，训练都会失败。层归一化在每个子块之间将每个 token 的向量重新缩放到一个受控的范围。

简短解释：层归一化（layer normalization）
层归一化重新缩放 token 向量，使其数字在模型训练期间保持在一个稳定的范围内。

原始 2017 年的 transformer 在每个子块之后应用归一化（post-norm）。这对于浅层模型有效，但随着深度增加变得更难可靠训练。现代 transformer（GPT-2 以后，LLaMA、Mistral）通常在每个子块之前应用归一化（pre-norm）。这是使得非常深的 transformer 更容易训练的变更之一。

归一化函数本身也变了。许多现代开源模型（LLaMA、Mistral、Gemma、Phi）使用一种更简单的变体，叫做 RMSNorm。原始层归一化同时做两件事：将每个向量向零平移，然后重新缩放数字的大小。RMSNorm 去掉了平移步骤，只保留缩放。经验上，缩放承载了大部分好处，同时计算成本更低。

简短解释：RMSNorm
RMSNorm 是一种更便宜的归一化方法，在不先减去均值的情况下重新缩放向量大小。

这就是那些不光彩的基础设施。没有残差连接，非常深的模型会变得极难训练。没有层归一化，运行中的和可能爆炸或坍缩。有了两者，你就能得到数百层深的模型。

Next-Token Prediction（下一个 token 预测）

在所有 attention 和前馈处理层完成之后，模型对序列中的每个 token 都有一个向量。在生成过程中，要预测下一个词，它只取最后一个 token 的最终向量。

那个最后的向量被转换为每个可能的下一个 token 对应一个数字。如果词汇表有 100,000 个 token，那就是 100,000 个数字。这些数字叫做 logits。它们还不是概率。它们可以是任何大小，正数或负数。

简短解释：logits
Logits 是每个可能的下一个 token 的原始分数。只有在 softmax 之后它们才变成概率。

Softmax 将这些 logits 转化为模型在可能的下一个 token 上的概率分布。和之前一样的操作，在模型中的不同位置。

模型通常不每次只选最高概率的 token。解码设置控制输出的确定性或多样性程度。Temperature 改变分布的尖锐程度。Top-k 和 top-p 将选择限制在最合理的一组下一个 token。这就是为什么同一个模型在一种设置下可以感觉精确，在另一种设置下可以更有创意。

简短解释：temperature
Temperature 控制采样期间的随机性。低 temperature 使模型更保守；高 temperature 使输出更多样化。

一旦选出一个 token，它就被添加到输入中。模型在更长的序列上运行下一步，通常重用 KV 缓存，这样就不必从头重新计算整个前缀。新 token 的新 attention。新前馈。新最终向量。新预测。循环继续，直到模型输出一个序列结束 token 或达到长度限制。一整段话就是这个循环，一次一个 token。

这个单一目标——预测下一个 token——是基础 LLM 的核心训练信号。基础模型不是被训练来做事实准确性、对话能力、推理或编程的。它被训练来预测海量文本中的下一个 token。之后的后训练才能将模型调整为指令遵循、偏好、安全性和对话行为。

有一个值得了解的重大效率创新。它叫做投机解码（speculative decoding）。一个小型快速模型提前提出几个 token。大模型并行地验证它们。如果提出的 token 在大模型的概率下被接受，就接受它们。如果没有，就回退到大模型。做得正确的话，输出分布与单独运行大模型一致，但循环可以快得多。

简短解释：投机解码（speculative decoding）
投机解码使用一个小型草稿模型向前猜测，然后让较大的模型一次验证几个猜测的 token。

下一个 token 预测循环是架构中最简单的部分，但它是让整个系统运作起来的东西。

Architecture vs Trained Weights（架构 vs 训练权重）

我们已经走过了核心机制：token、嵌入、位置编码、attention、多头注意力、前馈网络、残差流与归一化，以及输出侧的下一个 token 循环。这就是基本架构的一遍遍历。

那么 GPT、Claude、Gemini 和 LLaMA 之间实际有什么区别？公开细节各不相同，而闭源模型不会公布所有的架构选择。但在本文所覆盖的层面，它们大致处于同一 transformer 家族的设计空间之中。

大多数现代基于 transformer 的 LLM 使用相同的大致结构：分词、嵌入、位置编码、堆叠的 transformer 层（每层有多头注意力和前馈网络）、残差流、层归一化，以及下一个 token 预测。

模型之间的不同在于：

训练权重本身——从不同的训练数据、在不同的规模上学习而来。
配置：层数、词汇表大小、头数、参数量、MoE 还是密集。
后训练：指令微调、基于人类反馈的学习、在基础模型之上应用的安全控制。

简短解释：权重（weights）
权重是模型内部学到的数字。训练会改变这些数字，直到模型能很好地预测文本。

2023-2025 年的"现代 transformer"技术栈在许多严肃的前沿和开源权重模型上收敛到了一组共同的选择，尽管不同的团队是独立达到这些选择的。Pre-norm 布局。RMSNorm。RoPE。SwiGLU。Grouped-Query Attention。在一些最大型的模型中使用 Mixture of Experts。这些都不是一次性发明的。它们是在原始 2017 年设计之上大约五年的精炼中累积起来的。

未来走向

Transformer 家族架构的收敛在机器学习历史上是不寻常的。在这个领域的大部分历史中，每个问题都有自己的专门网络。图像识别用一种。语言用另一种。音频用第三种。视觉和语言团队几乎不共享方法。

现在 transformer 风格的模型出现在语言、视觉、音频和多模态系统中。Transformer 吸收了该领域的很大一部分。

这可能会改变。Mamba 和其他状态空间模型是可信的替代方案，特别是对于非常长的序列。混合架构正在被探索。Mixture-of-Experts 已经以五年前会被认为是异域的方式改变了前沿上"架构"的含义。

但本文中的核心机制——token、嵌入、位置编码、attention、前馈网络、残差流与归一化，以及下一个 token 预测——是持久的部分。即使架构发生变化，这些也是任何序列模型必须以某种形式解决的问题。

如果你读到了这里，你现在可以阅读许多现代 transformer 论文或模型卡，并知道每个部分在讲哪个组件。这就是目标。

原文来源：0xkato, "How LLMs Actually Work", June 1, 2026, https://www.0xkato.xyz/how-llms-actually-work/

00 卷首语：当 Karpathy 说他半年没写一行代码

Sun, 21 Jun 2026 21:20:27 CST

"I don't think I've typed like a line of code probably since December, basically, which is an extremely large change."
从去年十二月起，我基本上一行代码都没写过，这是一个巨大的变化。

——Andrej Karpathy，No Priors 播客，2026 年 3 月

半年没写一行代码

2026 年春天的一个午后，Andrej Karpathy 坐在播客录制间里，用他标志性的、几乎不带任何修辞起伏的语调，说出了一句让整个软件行业安静下来的话。

他已经半年没有亲手写过一行代码了。

不是两周，不是一个月。是从去年十二月开始，一天都没有。

在任何一个其他时代，这句话如果出自一位顶尖程序员之口，只意味着一件事：他离开了这个行业。但 Andrej Karpathy——OpenAI 联合创始人、前特斯拉 AI 总监、计算机视觉领域最具影响力的研究者之一——并没有离开。恰恰相反，他正处在职业生涯中产出最高的时期。他以自然语言驱动 AI Agent，完成从创业项目到开源探索的全部开发工作——一人之力推动着过去需要一个完整团队才能完成的迭代节奏。英语成了他新的编程语言，而 AI 成了他的编译器。他只是不再亲手写代码了。

这是一个关于杠杆的故事。

2026 年 5 月 19 日——Karpathy 宣布了一个消息： 他加入了 Anthropic。 "我认为未来几年在 LLM 的前沿将会特别具有塑造性，"他写道，"我非常兴奋能加入这个团队，重新回到研发工作中。我仍然对教育充满热情，并计划在适当的时候继续我的相关工作。"这个消息之所以意味深长，不在于一个人换了东家——而在于这位"半年没写一行代码"的工程师选择加入的公司，正是 Claude Code 的缔造者，而他返回的还是软件开发的前线。从 OpenAI 到特斯拉到独立探索，再到 Anthropic，他的轨迹恰好画出了 AI 软件工程从实验室到产品、从工具到基础设施的完整弧线。

在那期播客以及随后的多次深度访谈中，Karpathy 展开了一幅比他那句名言本身更为深邃的思想图景。他将软件工程的历史划分为三个时代—— 软件 1.0、软件 2.0、软件 3.0——并以此解释了他所看到的这场变革的本质。

软件 1.0 是人类编写明确的代码规则。你告诉机器每一步怎么做，机器照做。这是过去半个多世纪的编程范式。软件 2.0 是人类通过创建数据集来训练神经网络，让模型从数据中学到规则。这是过去十年的深度学习范式。而软件 3.0，Karpathy 说，编程变成了**提示（Prompting）**本身——上下文窗口成了控制这个新型计算设备（LLM）的杠杆。他说，LLM 已经不再是传统意义上的"程序"，而是一种全新的计算机：你输入一段文本，它输出一段文本，但这中间执行的是人类无法逐行追踪的、基于大规模统计模拟和强化学习的涌现计算。他称之为 "召唤幽灵"——我们构建的不是具有动物般内在动力的智能体，而是基于统计模式的模拟产物。它们能在瞬间重构十万行代码或发现零日漏洞，却会在常识问题上给出荒谬的建议。它们的智能是"参差不齐的"（Jagged Intelligence）：在可验证的领域（编程、数学）突飞猛进，因为强化学习能给明确的验证奖励；而在不可验证的领域，它们依然脆弱。

正是基于这种认识，Karpathy 提出了一个他亲自命名的概念区分： "氛围编程"（Vibe Coding）与"智能体工程"（Agentic Engineering）。 Vibe Coding 的意义在于「拉高下限」——它让任何人，无论是否具备专业背景，都能让 AI 生成一个能跑的应用。这是一种民主化，也是一种诱惑。但 Agentic Engineering 的核心是「守住上限」——它是一门新的工程学科，要解决的问题是如何协调那些强大但带有随机性、容易出错的 AI 智能体，在不引入漏洞、不牺牲质量的前提下大幅提升开发速度。

Karpathy 的措辞很克制，但判断很锋利： 掌握 Agentic Engineering 的工程师带来的效率提升，将远远超越过去所谓的"10 倍工程师"。

这意味着人类的角色将发生根本性的重塑。开发者不再需要死记硬背 PyTorch 的张量维度或 NumPy 的 API 细节——这些都可以放权给拥有"完美记忆力"的 AI 智能体。但放手细节的同时，人类必须提升另一个维度的能力：品味、判断力、架构直觉、系统审美。人类与智能体共同制定详细的规格说明，然后智能体来填充底层实现。Karpathy 用了一个工业时代的比喻来总结： 人类不再是打字员，而是工头。

但他说出的最重要的一句话，也许是这句旁人转述给他的格言：" 你可以外包你的思考，但不能外包你的理解力。"机器可以生成代码、总结文档、分析数据，但人类始终是那个决定"为什么要建这个系统"和"如何指导智能体"的人。利用 AI 工具来增强自身的理解力，而不是用 AI 来替代自身的思考——这才是 Agentic Engineering 的终极壁垒。

从软件危机到智能体崛起

过去两年间，软件工程领域发生的变化，比过去二十年加起来还要剧烈。这不是修辞。这是一场从「工具辅助人类」到「人类指导工具」的根本性反转——程度的加深叠加方向的逆转。

时间线拉长一些，才能看清这件事的历史分量。

1968 年，北大西洋公约组织在德国加米施召开了后来被载入史册的 NATO 软件工程会议。在那次会议上，"软件危机"（Software Crisis）作为一个正式术语被提出——软件项目的失败率居高不下，成本超支成为常态，交付日期一再推迟。那次会议催生了"软件工程"这个学科本身。当时的解决方案是用工程化的流程约束创造力：瀑布模型、需求规格、阶段评审、文档驱动。

半个多世纪以来，这个基本框架没有变过。敏捷运动拆掉了瀑布的刚性阶段门，但保留了"人写代码、流程管质量"的核心假设。DevOps 打破了开发与运维的墙，但写代码的人依然是写代码的人。

直到 AI 编码 Agent 的出现。

2022 年，GitHub Copilot 让程序员第一次体验到了"AI 帮你写下一行"的感觉——它是一个聪明的自动补全工具。2025 年，Claude Code、Codex、Cursor、OpenCode 等一系列工具将这种体验升级为"AI 帮你写一个函数"。到了进入 2026 年，这些工具已经进化为能够自主理解整个代码库、管理完整开发流程、甚至学习私有 API 和内部框架的工程 Agent。

变化的斜率不是线性的。它在加速。

先行者们看到了同一件事

Andrej Karpathy 不是唯一一个感受到这场震荡的人。如果你仔细聆听，你会发现来自不同背景、不同时代、不同编程哲学的声音正在汇成同一个和弦。

2025 年，Anthropic 的 CEO Dario Amodei 在一次公开访谈中给出了一个让很多人不以为然的预测：AI 将在三到六个月内编写 90% 的代码，十二个月内编写几乎全部代码。批评者说这是营销。投资者说这是讲故事。但到了 2026 年，这个预测正在被一个又一个的数据点验证。Claude Code 的用户不仅仅是"使用 AI 辅助编码"——他们在与一个能够自主探索代码库、提出架构方案、执行完整功能开发的 Agent 协作。人类工程师的角色正在从"写代码的人"转变为"定义目标、审查产出、做架构决策的人"。

Y Combinator 总裁兼 CEO Garry Tan 用一个对比数字让整个硅谷沉默了。他公开了自己作为同一个工程师、同样高强度工作状态下，2013 年和 2026 年的 GitHub 贡献数据：2026 年的逻辑代码行产出是 2013 年的 八百一十倍。这不是百分比增长，这是数量级的跃迁。他在全职运营 Y Combinator 的同时，用自己开发的 gstack 方法论，在六十天内交付了三个生产级服务和四十多个功能。他自己这样说："Same person. Different era. The difference is the tooling."同样的人，不同的时代。差别只在于工具。

Garry Tan 的数字让人震撼。2026 年 5 月的硅谷 AI Ascent 大会上，Claude Code 的缔造者 Boris Cherny 给出的画面则让人恍惚。Cherny——Anthropic 的工程负责人（Engineering Lead）、Claude Code 的创造者——走上台，平静地描述了他现在的日常工作： 他不再写代码。他审查代码。 他曾经同时运行大约一千个 AI Agent，并在一天之内合并了一百五十个拉取请求。今天的开发者，Cherny 说，本质上是一支临时工模型大军的"工程经理"。

但 Cherny 也没有回避最棘手的问题： AI Agent 编写补丁的速度，已经远远超过了人类组织验证它们的能力。 这就是"验证差距"（Verification Gap）。模型经常在工作真正完成之前表现得"非常自信"——你既不能完全不信任 Agent，那样你会失去速度；也不能完全信任 Agent，那样你会失去质量。他给出的答案简洁得近乎冷酷： 委派任务前的判断力，给予信任前要求证据的能力，合并代码后的责任感。 敲击键盘的速度和记忆 API 的数量不再重要。判断力、验证力、责任感才是新的硬通货。这三项能力构成了 AI 时代工程师的新技能栈。

但也许最令人动容的转变来自 Redis 的创造者 Salvatore Sanfilippo——社区里人们叫他 antirez。在程序员群体中，antirez 代表了一种几乎已经消失的浪漫：他相信每一行代码都应该经过人手的雕琢。他曾经写道："I love writing software, line by line. My career was a continuous effort to create software well written, minimal, where the human touch was the fundamental feature."他热爱一行一行地写代码。他的整个职业生涯都在追求一种极简的、充满人性触感的软件美学。

然而，就是这个人，在 2025 年坦承："Facts are facts, and AI is going to change programming forever."事实就是事实，AI 将永远改变编程。

antirez 没有选择抵制。他选择理解。他提出了一个至关重要的概念区分—— "Automatic Programming"（自动编程）与 "Vibe Coding"（氛围编码）是两回事。Vibe Coding 是把需求丢给 AI，接受它吐出的一切，不做审查，不做设计。而真正的 Automatic Programming 需要人类的直觉、设计判断、持续引导和对软件系统的深刻理解。AI 是放大器，不是替代品。他用 AI 在一周内完成了 DS4 项目的开发，让它成为了当时最流行的本地 AI 体验工具。但他审查了 AI 生成的每一行代码，做出了每一个关键架构决策。

AI 放大了一切——包括你的工程缺陷

这些声音——Karpathy 的平静陈述、Amodei 的大胆预测、Garry Tan 的冰冷数据、Cherny 的工程坦率、antirez 的审慎拥抱——来自完全不同的方向，却指向同一个结论：**软件工程的范式正在发生五十年之变。**一个人的产出可以等于过去一个团队。自然语言正在成为最强大的编程接口。写代码这项技能，正在从"必须自己动手"变成"必须自己动脑"。

但如果你仔细听，在这些声音下面，有一个更深层的矛盾正在浮出水面。

AI 让"写代码"变得前所未有的容易，却让"写好软件"变得前所未有的困难。

任何人都可以用一句话让 AI 生成一个能跑的应用。这就是 Vibe Coding 的诱惑：你不需要理解数据结构，不需要考虑边界条件，不需要设计错误处理——你只需要说"给我做一个"。AI 会给你一个。它甚至看起来还不错。但当这个应用需要维护、需要扩展、需要与团队协作、需要经受生产环境的流量冲击时，Vibe Coding 的产物往往暴露了它的本质：一团不可测试、不可重构、不可理解的代码浆糊。

AI 可以让你以一百倍的速度写出代码。它也可以让你以一百倍的速度积累技术债务。AI 可以让你一小时交付一个原型。它也可以让你一周后完全无法理解自己的代码做了什么。AI 不会救你——它会放大你。你给它清晰的架构，它还你整洁的代码；你给它模糊的意图，它还你一团浆糊。它暴露你的工程能力，也同等精确地暴露你的工程缺陷。

这就是为什么，在 AI 让编码门槛降到历史最低点的时刻， 工程化的价值反而达到了历史最高点。

当开发速度不再稀缺，工程化就是最后的壁垒

如果你的木工房里突然出现了一把能以一百倍速度切割木材的激光刀，你最需要的是更精确的测量工具、更严格的工艺流程、更可靠的安全护栏——而不是更快的刀。软件工程同理。当执行的速度被 AI 提升到前所未有的高度时，决定质量的是执行之前的规划、执行之中的约束、执行之后的验证。执行本身不再稀缺。

这正是过去两年间涌现的一系列新方法论试图解决的问题。

Matt Pocock——TypeScript 社区最受尊敬的工程教育家之一——提出了 Skills 系统的概念。他的核心洞见：Prompt 是临时的，Skill 是持久的。你不需要每次都对 AI 解释"如何做代码审查"，你只需要给它一个 Skill。/diagnose 系统化调试、/grill-me 启动前对齐、/tdd 红-绿-重构——每一个 Skill 都是针对 AI 编程中特定失败模式的工程化解药，小而聚焦，模型无关，鼓励改造。

如果说 Skills 解决的是"单次交互的质量"，那么 Spec-Driven Development 解决的就是"跨次交互的一致性"。OpenSpec 和 Spec-Kit 代表的 SDD 方法论将规格文档变成了人类与 AI 之间的一份"合约"——在写代码之前先写规格，你不需要审查 AI 的每一行思维过程，你只需要审查它在规格层面是否履约。

Ralph Loop 将这个逻辑推到了极致：让 AI Agent 在循环中持续改进自己的代码，直到满足验收标准为止。Frank Bria 设计的双条件出口门机制要求 AI 既要说「我做完了」，还要显式发出退出信号。因为 AI 的自我评估不可信，需要多重验证。

Garry Tan 的 gstack 则展示了一种完全不同的想象力：将 Claude Code 变成一个拥有二十三个专家角色的虚拟工程团队。CEO 审查战略、工程经理审查架构、QA 审查质量、安全官审查漏洞——整个 Sprint 从 Think 到 Reflect 被构建为一条七阶段审查流水线。一个人就是一支军队。

superpowers 框架——全球已获超过十五万颗星标——将这些 Skills 组织成了一整套方法论库。而 jnMetaCode 的中文增强版 superpowers-zh，则为中国开发者补充了国内代码托管平台适配、中文排版规范、Conventional Commits 本地化等原创能力。

这些方法论背后的共同逻辑是什么？

用结构化知识驾驭非结构化 AI 能力。

Prompt 消失在对话历史里，Skill 留在你的工具链里。Vibe Coding 的产物不可复现，Spec-Driven 的产出有据可查。一次性的 AI 对话无法保证质量，闭环工作流让每一次产出都经过验证。

为智能体构建运行环境

2025 年末，一个被称为"Harness Engineering"的新概念开始在 AI Agent 开发者社区中流传。它的核心关注点不是写 AI 模型，不是做产品功能，而是构建编码 Agent 的底层运行基础设施——工具系统、权限模型、hooks 机制、配置管理层级。社区逐渐认识到：如果说 Prompt Engineering 是"教会 AI 说什么"，Skill Engineering 是"教会 AI 做什么"，那么 Harness Engineering 就是"为 AI Agent 构建安全可靠的运行环境"。

这是一个信号。它意味着 AI Agent 的开发正在从一个"试试看"的实验阶段，进入一个需要专业工程实践的成熟阶段。正如游戏引擎架构之于游戏开发、编译器设计之于语言工具开发，Harness Engineering 正在成为 AI Agent 产品开发中的专门工程领域。它代表了从"能用的 Agent"到"可靠的 Agent 产品"之间那条必须跨越的工程鸿沟。

关于这本书

我是一名在软件工程领域工作了近30年的程序员。过去两年里，我和许多同行一样，眼睁睁看着自己熟悉的那个世界——手写代码、逐行调试、Code Review——被 AI 一步步重构。我参与了多个 AI 驱动的开源项目，也亲手构建了一套名为 Goal Workflow 的 AI 研发工作流技能集。这本书中的每一个方法论，我都亲自实践过；每一个结论，都来自真实的项目迭代而非纸上推演。

这本书的写作动机，正是源于上述所有这些变化的交汇点。

全书分为三个部分。

第一部分——原理篇（第 1–11 章）——是全书的主体。我们从软件工程范式的五十年之变出发，逐一考察当前最具代表性的方法论：Matt Pocock 的 Skills 系统、OpenSpec 与 Spec-Kit 的规格驱动开发、Ralph Loop 的自主循环引擎、Garry Tan 的 gstack 虚拟团队方法、superpowers 技能框架、autoresearch 的全自动化开发流程，以及 Goal Workflow 的目标驱动研发闭环。然后将这些方法论放在一起对比、碰撞、融合。在此基础上，我们深入 Harness Engineering——为 AI Agent 构建安全可控运行环境的专门工程领域，以及用 Kanban 编排 AI Agent 项目的实践。这一部分帮助你构建属于自己的 AI 研发体系。

第二部分——技能篇（第 12–17 章）——聚焦 AI 软件工程的实用技能与工具链。我们考察 Anthropic 官方插件如何为 Agent 注入领域知识与工程工作流，Understand-Anything 如何构建代码知识图谱，UML 在理解 AI 生成代码中的新用途，AI 时代的重构方法论，Go 语言的 AI 开发工具链，以及 autoreview 与 Crabbox 带来的自动化代码审查与远程验证。这一部分是从方法论到日常工程实践的桥梁。

第三部分——实战篇（第 18–23 章）——以一个真实的 Go 语言项目 goscapy 为载体，完整演示前两部分的方法论和技能在真实项目中的落地执行。从项目背景理解到 PRD 规划，从 /goal 迭代实现到 /review-it 自动化审查，从 /ship-it 交付合入到 Bonus Skills 的增强工具链——每一步都是实战，每一步都有真实代码和真实决策。goscapy 是一个纯 Go 实现的网络协议库，多协议支持、跨平台兼容，在生产环境中运行。这不是一个玩具项目。

但需要说清楚的是：这不是一本「如何使用 AI 工具」的操作手册。工具每天都在变。今天的 Claude Code 明天就不长这样，后天又会出现全新的工具形态。这是一本关于「 如何在 AI 时代思考软件工程」的方法论著作。

声明式编程的古老智慧

回到 Karpathy。

在那期播客里，除了那句被广泛引用的"半年没写一行代码"之外，他还说了另一句话，没那么出名，但同样重要。他说，使用 AI 编程的体验让他想起了一个古老的计算机科学概念： 声明式编程。你不需要告诉计算机"怎么做"，你只需要告诉它"要什么"。

SQL 是声明式的——你说"给我这些列、从这个表、满足这些条件"，数据库引擎自己决定执行计划。在 AI 时代，整个软件开发正在变成声明式的：你说"给我一个支持多协议、高并发、跨平台的网络包处理库"，AI Agent 自己决定架构、选择模式、实现细节。

但声明式编程有一个前提：声明本身必须是精确的。模糊的 SQL 查询返回模糊的结果。模糊的需求描述产生模糊的软件。

这就是为什么，在 AI 可以帮你写出一切的时代， 知道"要什么"比知道"怎么做"更重要。而"知道要什么"——定义清晰的验收标准、设计合理的架构约束、建立可验证的质量门——正是软件工程这门学科用半个世纪沉淀下来的核心能力。

这些能力从来没有过时。它们只是在等待一个让它们变得至关重要的时刻。

那个时刻就是现在。

欢迎来到 AI 时代的软件工程。

挪威将禁止小学生使用生成式人工智能

Sun, 21 Jun 2026 03:37:14 CST

挪威首相斯特勒6月19日表示，为防止对学习产生负面影响，挪威将禁止小学生使用生成式人工智能工具，同时限制人工智能工具在高年级学生教育中的使用。根据挪威政府公布的方案，6到13岁的小学生原则上不得使用人工智能工具；14到16岁的初中生可在教师的严密监管下谨慎使用此类工具。17到19岁的高中生应学习如何恰当地使用人工智能工具，以便为后续的高等教育和未来的职场环境做好准备。（央视新闻）

用Qwen 3.6 35B本地模型作为主力编程工具替代Claude或GPT

Wed, 17 Jun 2026 08:59:06 CST

基于 Hacker News 上的这个热门讨论（关于是否有人在日常编程中用本地大模型完全替代 Claude/GPT），以下为您归纳出的几条 本地大模型最佳实践以及该讨论的 主要内容概述。

一、本地大模型（Local LLM）编程的 5 条最佳实践

选择最适配的混合架构模型（如 Qwen 3.6 35B） 讨论中多位资深用户指出， Qwen 3.6 35B（激活 3B 参数的混合专家模型 MoE） 是目前本地编程的“黄金甜点位（Sweet Spot）”。它在 128GB 或 36GB RAM 的设备（如 Mac Studio、Strix Halo 笔记本）上运行极快，且代码能力表现优异。对于更复杂的任务，可配合 Qwen 3.5 122B（激活 10B）作为后备。
启用“保持思考”配置（Preserve Thinking）以优化缓存 在使用推理/思考模型（如带有 <think> 标签的模型）进行多轮对话或 Agent 自动化编程时，默认的模板可能会在下一轮对话中丢弃之前的思考链（CoT），导致每一轮都要重新计算完整的 KV 缓存（Context Reprocessing）。 最佳实践是在大模型后端（如 llama.cpp）中开启 preserve_thinking: true，这能大幅提升多轮对话中的缓存命中率，避免卡顿。
使用 Vulkan 后端提升 AMD/Intel 硬件性能 在特定硬件（如 AMD Strix Halo 笔记本）上运行 llama.cpp 时，部分用户反馈 使用 Vulkan 后端甚至比官方的 ROCm 还要快且更稳定。硬件平台的后端选择（Vulkan vs ROCm/Metal）应根据实际本地测试来决定。
精确提示与迭代开发（Iterative Development），不当“甩手掌柜” 本地模型（如 Qwen 3.6 35B）相比于闭源的顶尖模型（如 Claude 3.5 Sonnet / Opus），更像是一个 需要密切指导的“初级程序员（Junior）”。最佳实践是 不要指望它一次性生成成千上万行代码，而是采用“讨论设计方案 -> 达成共识 -> 迭代编写单个功能 -> 运行测试”的循环模式，且提示词必须极其精确、消除歧义，否则模型会为了偷懒选择最糟糕的架构（例如直接在 HTML 里塞满 CSS）。
量化（Quantization）和容器化沙箱（Sandboxing）安全
- 安全： 配合 Agent 框架（如 Pi 编程脚手架）时，务必将本地模型和执行环境 容器化（Docker）并进行沙箱隔离，限制其仅能访问当前工作目录，防止断网环境下本地脚本误操作或泄露敏感凭证。
- 量化： 不要盲目相信社区的激进量化。量化对代码质量影响极大（MoE 架构对量化的耐受度稍好），建议在可能的情况下优先选用更高精度的版本（如 FP8 等）。

二、帖子主要内容概述

这个帖子（Ask HN）的核心议题是： “有没有人真正把本地模型作为主力编程工具，完全替代了 Claude 或 GPT？” 评论区的技术人员对此展开了深度讨论，主要内容可概括为以下几点：

完全替代的可能性与实际体验： 多数硬核开发者表示 完全可以替代，尤其是在注重 隐私、离线开发和完全免费的场景下。有用户分享了他们纯靠本地模型（Qwen3.6 35b + Pi 框架）重构整个 Django+Wagtail 网站主页和博客的成功经历。
本地模型 vs 闭源大模型的差距： 用户普遍认为，Claude Opus 或 Sonnet 就像一个能帮你思考架构的“高级工程师（Senior）”，能带来 15 倍的效率提升；而本地模型则是一个需要你时刻盯着的“初级工程师”，能带来约 5 倍的效率提升。虽然本地模型更容易陷入逻辑死循环或在调用编辑工具时出错，但考虑到它 完全免费且纯离线，这种表现已经令人惊叹。
技术层面的深究（KV缓存与Attention机制）： 讨论中有很大一部分篇幅在硬核切磋本地运行的底层 Bug。大家深入探讨了为什么模型在多轮对话中会频繁触发“重新处理上下文（Re-processing context）”。多位开发者指出这通常是由于 Prompt 模板不一致、系统提示词每轮被修改（Harness Bug）或没有保存思考链导致的，并给出了具体的 Jinja 模板修改方案和命令行参数。
人机协作哲学的思辨： 开发者们辩论了“AI编程是否会导致代码质量退化”。主流观点认为，AI 不是为了让人变懒去生成一堆垃圾代码（Vibe Coding），而是作为“自动化 Google”和实时常驻的专家。高水平的开发者可以通过与本地 AI 讨论、审查其方案并编写大量测试，实现“控制权在人，生产力乘数在 AI”的高质量开发。

问HN：有没有人用本地模型替换Claude/GPT进行日常编码？

Tue, 16 Jun 2026 17:23:00 CST

Greenpants 11小时前 |下一个 [–]

我确实这么做了！我非常重视数据隐私，也希望LLM（生命周期管理）能够免费运行。我使用的是Pi编码框架，但将其容器化并沙盒化，以确保它完全离线运行。在我的Mac Studio（配备128GB内存）或MacBook（配备36GB内存）上，我使用Qwen3.6 35b版本，只启用了30亿个活动参数，因此运行速度非常快。我用Django + Wagtail对网站的首页和博客进行了彻底的重新设计。后者很有意思，因为Wagtail的知名度相对较低，所以代理程序在没有联网的情况下，有时无法识别Wagtail并进行开发。当情况变得更加复杂时，我会使用Qwen3.5 122b版本。不过，启用100亿个活动参数后，速度明显变慢了。

我注意到它与 Claude 等大型模型相比有一些不同之处。首先，你必须非常清楚自己要问什么，并且要精确；它不会为你做太多思考。如果留下任何假设，它就会选择最简单的路径来实现目标（例如在 HTML 中使用 CSS），而这通常并非架构上的最佳方案。

它经常陷入循环，而且令人惊讶的是，它经常会错误地调用编辑工具，之后它会花费大量的思考标记并重新读取文件，而不是重试（尽管系统提示建议这样做）。

将代理式 Qwen3.6 35b 与 Claude Opus 进行比较，就像一个知识面广但经验不足的初级开发人员，需要你指导他，而一个资深开发人员则会与你一起思考架构。如果 Opus 能带来 15 倍的速度提升，那么本地且完全离线的 Qwen 也能带来 5 倍的速度提升。考虑到它是完全免费的，这仍然让我感到难以置信 :)

lambda 10 小时前 |父级|下一级 [–]

这跟我目前的配置非常相似。树莓派运行在一个容器里（我允许它访问网络，但不允许它访问任何凭据或其他资源，只允许它访问我当前正在编辑的目录和我的 ~/.pi 目录），并与另一个容器里的 llama.cpp 程序通信。我的笔记本电脑是华硕 Strix Halo，配备 128 GiB 统一内存。

我从未真正使用过前沿模型，我不相信在编程中使用专有工具，所以我无法进行比较。

我仍然对人工智能持怀疑态度，所以我做的测试和研究比实际使用要多得多。这意味着我花了很多时间试图破解各种模型，探究它们的优势和劣势等等。

但我发现，当我真的尝试将其用于智能体编码时，Qwen 3.6 35B-A3B 绝对是我最常使用的版本。

对于其他聊天任务和翻译，我经常使用 Gemma 4 31B。

音频方面，我将使用 Gemma 4 12B。

我手头还有一些其他型号的机器，时不时会试用一下（Qwen 3.5 122B-A10B、Qwen 3.6 27B、Nemotron 3 Super 122B-A12B、Step 3.7 Flash 和 Minimax M2.7，它们的量化参数都比较激进；如果我想要速度超快但不太智能的机器，我会选择 GPT-OSS 120B），但到目前为止，Qwen 3.6 35B-A3B 确实是这种配置下进行编码的最佳选择。

chakspak 10小时前 |根|父|下一个 [–]

希望这不算跑题，但你的配置听起来跟我一样，都是在 ROCm 上运行 Strix Halo 和（我猜是）llama.cpp，我发现 Qwen 的混合模型无法处理提示缓存，而是每回合都重新处理整个上下文。我想知道你是否解决了这个问题，以及你是怎么解决的？

lambda 10 小时前 |根|父|下一个 [–]

我主要用 Vulkan 而不是 ROCm。奇怪的是，Vulkan 实际上速度更快一些。我也会切换着试用，差别并不大，但我主要还是用 Vulkan。

我确实遇到过每回合都要重新处理上下文的问题。部分原因已经在上游的 llama.cpp 文件中修复了；请确保你的代码已更新到最新版本。

但造成此问题的另一个重要原因是，旧版 Qwen 模型不支持保留思考过程。这意味着，每次你进行一长串工具调用并穿插思考时，一旦你轮到你进行下一次对话，它就必须重新处理所有这些思考过程，因为它会丢弃所有推理信息。

然而，Qwen 3.6 现在支持保留思考过程。这需要更多解释，因为你并非每回合都丢弃思考过程，而是更好地利用缓存，避免每次都需要重新处理整个回合。

我的 models.ini 文件中，Qwen3.6 模型的相关配置如下：

chat-template-kwargs = {"preserve_thinking": true}

虽然偶尔还是会遇到需要重新处理的问题，但更新到最新版本并启用 preserve_thinking 功能已经帮了大忙。

thefroh 38分钟前 |根|父|下一个 [–]

我有点惊讶，preserve_thinking 在这里居然会对缓存产生影响。至于实际能力/智能，是的，我想在多轮推理设置中保留过去的推理轨迹确实会有帮助。

但对于缓存而言，你所做的只是省略了最近生成的一小部分助手消息，这对缓存命中率几乎没有影响。

ndom91 9小时前 |根目录|父目录|上一页|下一页 [–]

+1 使用 llama.cpp Vulkan 版本和 Qwen 模型 - 运行效果比 ROCm 版本好得多。

我得试试 preserve_thinking 这个函数。

jderekw 6小时前 |根|父|下一个 [–]

感谢分享。我主要使用 Qwen 3.6 和 Qwen Coder 运行 ROCm，运行效果好得多。您说的“运行效果好得多”是指稳定性、性能还是其他方面？

dnautics 8小时前 |根目录|父目录|上一页|下一页 [–]

Qwen混合模型不支持提示缓存，而是每次都重新处理整个上下文。我想知道您是否解决了这个问题，以及如何解决的？

这不正是 LLM 的工作原理吗？或者你的意思是它会重新计算整个键值缓存而不是保存旧的键值缓存？如果是这样，问题很可能出在你的执行器（例如 llama.cpp、vllm）的配置或功能上？

lambda 7 小时前 |根|父|下一个 [–]

因此，这个问题的一种表现形式是，大多数局部模型并没有针对保留回合间完整推理过程进行训练。每个回合，它们都会跳过将前几个回合的推理过程传递给局部逻辑模型（LLM）。所以，如果在一个回合中，你有一个很长的交错推理和工具调用链，模型响应了你的指令，然后你又发出一个新的指令来修复某些问题，那么它现在必须重新处理所有这些工具调用，而推理过程已经被剥离。

Qwen 3.6 终于完成了启用和禁用思维保留功能的训练，因此您可以选择启用思维保留功能。启用此功能会消耗更多上下文信息，但可以避免对较长的代理回合进行重新处理，而且思维保留功能还可以避免在后续回合中重复进行某些相同的推理。

除此之外，现代的LLM模型并非只使用完全注意力机制（显然，注意力机制并非万能）。完全注意力机制的计算和存储成本非常高（O(n^2)）。而且，完全注意力机制在某些推理方面表现不佳；例如，它难以追踪随时间变化的值。因此，如今大多数模型都采用各种形式的局部注意力机制，这些机制具有固定长度，并会随着模型的运行而更新；例如滑动窗口注意力机制、Mamba-2状态空间模型等等。

但注意力机制的一个优势在于，你可以通过截断键值缓存并重新开始来回溯和重新处理数据。其他形式的局部注意力机制则无法做到这一点；因为在序列的早期阶段，你已经丢失了状态。

为了让你无需重新计算缓存就能回溯，你的引擎会在不同时间点保存局部注意力状态的快照。这样，如果你需要回溯并重新计算缓存，就可以从最后一个快照开始。然而，这些快照可能会变得很大，你无法保存太多，所以有时你需要回溯到很远的时间点才能找到某个快照，或者所有快照都已过了你需要回溯的时间点，你只能从头开始。

llama.cpp 中存在一些特定的错误，导致这种情况比预期更频繁地发生；例如，它曾经不会在包含图像的回合之前拍摄快照，因此，如果您有一个图像密集型的代理工作流程，该问题加上缺乏保存思维意味着您经常需要返回并从头开始。

有些问题已经修复，有些问题则通过保留现有思路来解决。但有时仍然存在一些问题；例如，一个难以解决的问题是，自回归生成的词元在进行预填充时解析结果并不总是相同。举例来说，你可能生成了两个词元“pre”和“fill”，但实际上“prefill”也是一个单独的词元，因此分词器会使用它。所以，当你在下一轮再次发送该词元时，分词器会发现解析结果出现偏差，并需要从该偏差点重新计算。或许可以忽略这个问题，直接使用缓存中非完全贪婪的分词方法，但我确实看到过 llama.cpp 代码因此需要进行一些缓存重新计算。

carterschonwald 6小时前 |根|父|下一个 [–]

这是框架问题，不是模型问题。例如，我有一个自己的推理框架，它强制持久化 cot。

dnautics 6小时前 |根目录|父目录|上一页|下一页 [–]

等等，SOTA 型号也用类似 Mamba 的 SSM 芯片吗？我还是第一次听说。

荷兰语 5小时前 |根|父|下一个 [–]

Qwen 3.5 及以上版本使用门控 DeltaNet，该网络交替使用注意力层和 SSM 层：

https://sebastianraschka.com/llms-from-scratch/ch04/08_delta...

verdverm 1小时前 |根目录|父目录|上一页|下一页 [–]

llama-cpp 对 qwen/gemma 模型存在 bug，请改用 vLLM。

pdyc 34分钟前 |根|父|下一个 [–]

是什么漏洞？它会影响哪些方面？

LoganDark 9小时前 |根目录|父目录|上一页|下一页 [–]

你使用的是什么框架？有些框架（例如 OpenCode）每回合都会修改系统提示符，因此无法与键值缓存一起使用。

到目前为止，我使用 Pi 的体验最好，但它缺少一些你可能习惯的功能（例如计划模式、子代理、MCP 客户端支持）。

mahadevank 1小时前 |根目录|父目录|上一页|下一页 [–]

非常感谢您的评论。我之前用的是Qwen3，但不知道A3B混合专家模型。现在用起来好多了，谢谢！

fjdjshsh 4小时前 |根目录|父目录|上一页|下一页 [–]

我仍然对人工智能持怀疑态度。

就编码而言，这意味着什么？

在我看来，这听起来像是对电饭煲持怀疑态度。有些人不喜欢用电饭煲，有些人则喜欢。

femto113 2小时前 |根|父|下一个 [–]

对我而言，区别在于：米饭只需要吃一次，而代码可能需要保存几十年。用人工智能编写任何必要时可以轻易丢弃的代码，远比让它做出我和任何继承代码的人都必须承担后果的选择要轻松得多，尤其是在外包这些选择会降低我对这些选择后果的理解的情况下。

HWR_14 2小时前 |根目录|父目录|上一页|下一页 [–]

我猜他们的意思是他们不确定这样做是否真的能加快速度。考虑到我不知道他们想做什么，这或许也情有可原。

adyavanapalli 10 小时前 |父级|上一页|下一页 [–]

对于编辑工具，您应该考虑实现基于哈希的方法，即对每一行代码进行哈希处理，并在进行替换时引用该哈希值。您可以在这里阅读有关该方法的更多信息：https://blog.can.ac/2026/02/12/the-harness-problem/

我没有做太多基准测试，但根据我的个人经验，我发现它的编辑错误确实更少。结果可能因人而异。

pieterk 6小时前 |根|父|下一个 [–]

是的，我用过一段时间，根据我的经验，它最初可能会让你获得几个百分点的有用上下文，所以质量感觉会更高一些，但是当你之后因为任何原因耗尽了这种质量时，事情就会以更滑稽的方式开始崩溃，所以绝对要谨慎购买。

ojr 6小时前 |父级|上一页|下一页 [–]

我可以用自己搭建的框架配合 Gemini 3 Flash 用上大约 8 年，而且成本仍然不超过一台 128GB 的 Mac Studio，隐私的代价实在太高了。代理流程卡住的问题虽然可以解决，但我更喜欢开发速度。

5小时前被忽略 |根|父|下一个 [–]

被低估的观点，感谢分享！

不是每个人都能立刻在硬件上投入巨资（有能力的人更应该如此），所以选择租赁是一个完全可以接受的策略。

下午 1 小时前 |根|父|下一个 [–]

如果你能将代码和数据发送给服务提供商，那就没问题。但我们有些人做不到。

westoque 4小时前 |父级|上一页|下一页 [–]

将代理 Qwen3.6 35b 与 Claude Opus 进行比较，就像一个知识面很广的初级工程师，你需要指导他，而一个高级工程师则会与你一起思考架构。

这就是我使用前沿模型的原因，因为它代表的是资深同事而不是初级同事。如果你为了保护隐私而使用初级同事，我认为你会错过针对特定任务的最佳见解。

physix 4小时前 |根|父|下一个 [–]

我面临的难题是成本。

面向消费者的尖端机型订阅服务性价比极高，而且价格也得到了大幅补贴。但如果您在企业环境中工作，这种方式就行不通了。您需要升级，而升级成本会显著增加。

此外，基于利用廉价订阅的 SDLC 在未来可能会崩溃，无论是从成本角度还是可用性问题（例如 Mythos）。

因此，从战略角度来看，在法学硕士项目上采取本地化策略，并通过正确的方法取得优异的成绩是非常重要的。

bxk76 3小时前 |根目录|父目录|上一页|下一页 [–]

由于大脑带宽有限，即使是最好的洞见也可能被高估。即便爱因斯坦整天坐在你旁边指导你，有限理性理论仍然适用。

electronsoup 10 小时前 |父级|上一页|下一页 [–]

它经常陷入循环，而且令人惊讶的是，它经常错误地调用编辑工具。

我发现，使用更高级的量化算法（例如 Q8）可以避免这种情况，虽然运行速度稍慢，但总体上可以节省时间并减少数据变更。

使用 3.6-27b 比 3.6-35b 还要慢，但我发现精度提升非常值得。

girvo 6小时前 |根|父|下一个 [–]

没错。对我来说，每秒解码的令牌数并不是最重要的：任务完成的实际耗时才是。而且，在我基于GB10的华硕电脑上，即使Qwen 3.6 27B使用了MTP协议，Step 3.7 Flash at IQ4_XS在所有实际代码库的编码任务评估中都胜过了后者。

Qwen似乎更擅长根据模糊的提示一次性解决问题，而且效果还不错，但这绝对不是我使用这些工具的目的！

如果用户尝试调整，会发现它对 KV 缓存中 K 部分的量化非常敏感。F16 K 和 Q8 V 消除了许多原本会遇到的循环。

llama.cpp 中关于 Step Flash 也存在回归问题，量化后的 KLD 和困惑度比以前更差，即使量化参数完全相同。非常奇怪，但至少目前正在调查中！

地质爱好者 5 小时前 |父级|上一页|下一页 [–]

我的经历几乎完全一样。我发现我需要非常仔细地规划，把事情分解成一个个独立的小步骤（我可以让qwen来做这件事）；而且（我自己）还需要写出非常清晰的设计稿。如果依赖qwen来填充很多细节，就会导致“即将编写”的循环。

是的，无法编辑确实很奇怪。我已经更新了 AGENTS.md 文件，限制了编辑（而不是重写），这稍微有所帮助。

gwerbin 4小时前 |父级|上一页|下一页 [–]

我注意到Gemma和Qwen的编辑工具都存在同样的问题。也许是我使用的采样器设置不正确，但很高兴知道我不是唯一遇到这个问题的人。会出现很多不匹配的空格之类的问题，模型最终会进行十六进制转储，并且可能要尝试五六次才能将一个5行的函数编辑成一个250行的Python文件。

所有这些模型似乎都会陷入冗长的思考循环，有时甚至会使前沿封闭模型的标记数量增加三倍，这在推理速度本来就比较慢的情况下（在我的 Macbook 上）会非常痛苦。

pieterk 6小时前 |父级|上一页|下一页 [–]

没错，它真的非常实用。

当问题的所有约束条件都已确定时，它可能比 Opus 更有用。模型中包含的“知识”较少（我为 80 亿量化指标分配了 48GB 内存），因此它需要考虑的因素也更少。

在过去的几周里，我已经相当了解它的局限性，我认为它是一个优秀的代码搜索/替换/生成引擎*。

它还具备“上下文脚本生成”流程，因此可以轻松地帮助您自动化您用文本描述的任务，以及您提供的示例命令、工具或技能*。

*可以把它 + Pi 看作是 grep 或 shell 之上的 NLP 抽象层，而不是包罗万象的万能工具 + 世界知识。

ltononro 9小时前 |父级|上一页|下一页 [–]

你从事哪种类型的编程工作？你会持续关注前沿模型，以便对比差异并不断重新评估吗？还是你觉得长期使用一个性能有所削弱的模型就足够了？（我没有评判的意思，只是想了解你的框架。）

Greenpants 9小时前 |根|父|下一个 [–]

我的一些工作是为一个欧盟组织做的，该组织目前还没有关于人工智能使用的明确规则或指南。虽然我见过一些同事开发者公然将源代码放到类似 Claude 的外部模型中，但我始终坚持原则，不会这样做。我确信，所有在我本地离线的 Pi 容器沙箱中运行的代码都不会离开机器，因此不会导致数据泄露。我这样做是为了安心。

每当有新的、功能强大的本地LLM（≤130字节）发布，并且授权允许商业用途时，我都会（非正式地）进行一些实验。至于我的模型比Opus需要更多的工作，我并不介意继续琢磨如何正确构建架构。无论如何，这迫使我时刻关注正在开发的内容，这是一件好事。

kordlessagain 3小时前 |根|父|下一个 [–]

我看到了你的评论，现在就把 Pi 添加到 Nemesis8 中，谢谢！

https://github.com/DeepBlueDynamics/nemesis8

psychoslave 51分钟前 |根目录|父目录|上一页|下一页 [–]

您能否详细说明一下如何搭建这样的装置？

我对树莓派不太熟悉，也不确定你指的是哪种容器。是像 Docker 这样主流的容器，还是像 BSD jail 这样更传统的容器？

我开始尝试使用本地化的 LLM（生命周期管理工具），通过 Ollama 和 Lemonade 来实现。这足以让我发出包含代码片段的简单提示，并进行小范围的代码重构。不过，我仍然在努力让它们与外部工具（例如我的 IDE）协同工作，以便能够将其提升到代理级别，并访问完整的代码库。

这主要是为了工作，因为他们大力推广使用LLM，不过有了他们提供的新副驾驶许可证，我甚至不到一周就能把所有代币积分都用光。

这个工具或许有用，但以我的经验来看，如果没有严格的防护措施和循环测试，它就难以发挥作用。我怀疑后期模型也会像某些机构那样，投入大量代币去钻研各种无稽之谈，而不是像人们预期的那样，利用其庞大的资源和实验平台，直接进行正确的实现。或许激励机制并没有帮助模型提供者减少代币销售，或许驯服这个“野兽”实在太难了，即使是拥有近乎无限资源的顶尖人才也无能为力。

总之，抱歉跑题了，但我很想得到一个关于如何在代理级别上使本地 LLM 工作的逐步教程，包括使其正常工作需要哪种硬件。

0xbadcafebee 10 小时前 |父级|上一页|下一页 [–]

该测试框架和LLM参数对于获得更好的结果和减少循环至关重要。调整这些参数，您可以在不影响性能的情况下基本消除循环（这有点复杂，但您可以借助最先进的AI来指导，其实并不难）。该测试框架还应该能够更智能地应对故障；例如，它可以跟踪错误率和平均调用持续时间，并返回额外的上下文信息或提示。Pi易于扩展，作者建议您对其进行修改，以使其更适合您的用例。

awllau 3小时前 |父级|上一页|下一页 [–]

根据你的解释，对于我这样一个完全不懂工程的人来说，完全离线学习似乎不太现实？我经常和语言学习导师们进行来回讨论，而我本人既不会读也不会写代码。

spullara 6小时前 |父级|上一页|下一页 [–]

我觉得目前只有这套配置才比较适合本地使用。我找了个代理人，按照这个人的方案帮我配置好了：

https://ikyle.me/blog/2026/how-to-setup-a-local-coding-agent...

我所做的一项更改是将上下文长度从 64k 改为 256k。

hparadiz 10小时前 |父级|上一页|下一页 [–]

我完全同意你的看法。简直不可思议。这技术简直跟魔法无异！我一时兴起，在一台用了十年的双路至强服务器上，用 Opencode 和 Qwen 运行了一些基本任务。我给它布置了一个简单的任务，比如“先用 ffprobe 测试，然后把这个 webm 文件转换成 mp4”，它居然在完全没有网络外部调用的情况下就完成了。要知道这可是十年老硬件啊！任务只用了三分钟就完成了。你可能会说三分钟？切！但我敢打赌，你自己试试就知道了。你至少得花十分钟在网上搜索命令行参数，然后才能设置好命令。我甚至让它根据初始的 ffprobe 测试结果，实时优化了所有参数，找到了最佳方案。

bluerooibos 7小时前 |根|父|下一个 [–]

> 一台使用了10年的双路至强服务器……硬件也是10年前的。

等等，你的电脑配置是什么？内存有多大？

我一直在考虑入手一台 2018 年的翻新 Mac Mini，配备 64GB DDR4 内存，但我读到的所有资料都表明，它的速度会比我的 16GB M1 Pro Macbook 慢得多。

hparadiz 7小时前 |根|父|下一个 [–]

我继承了一台配备双路至强处理器和 256 GB DDR4 内存的机器。然后，我用几种不同的模型对这台机器的硬件进行了多次测试和基准测试。

我一直想写篇博客文章，不过算了，这就是医学博士。

https://gist.github.com/hparadiz/f3596d00a62d8ebb2dadcc46ee5...

Qwen3.5 9B 表现最佳。

你当然仍然可以用它来做一些基本操作，比如让 OpenCode 将视频文件从一种格式转换为另一种格式。但说实话，你最好还是买两块 AMD 显卡。比如说，两块 7900XT 的性能会好得多。

jmuguy 10小时前 |父级|上一页|下一页 [–]

鉴于您对这方面的了解，您认为我们会看到功能达到 Opus 水平的开源模式吗？依我之见，如果/当这种情况发生时，我会百分之百停止使用 Anthropic。

Greenpants 10小时前 |根|父|下一个 [–]

这么说吧。我最初接触本地语言学习模型的时候，ChatGPT 还在使用 GPT-3.5。我当时很惊讶，我那台只有 8GB 内存的 MacBook 居然能运行 openhermes2.5-mistral：一个拥有 70 亿参数的模型，居然能生成勉强说得通的短篇故事。简直不可思议！

两年后，我正在运行 Qwen3.6 35b 的代理程序，用于开发代码库的初始版本并自动运行测试，从而不断改进自身。当年我从未想过 LLM 能发展得这么快。

我相当肯定，两年后，我们就能拥有参数量在 300 亿到 1000 亿之间的、质量与 Opus 目前的模型相媲美的模型。但到那时，Opus 6.3 的推理能力将会更加出色，我们仍然会对这些模型感到惊叹。展望未来固然重要，但我们也不要忘记欣赏当前本地模型已经取得的卓越成效 :)

jmuguy 10小时前 |根|父|下一个 [–]

哈哈，我这么问是因为我大部分时间都只想要Opus，并不需要其他任何东西。而且我担心Anthropologie很快就会被迫公布所有这些产品的真实价格。

Greenpants 9小时前 |根|父|下一个 [–]

运行本地 LLM 的另一个好处是，不会出现云服务提供商突然对相同甚至更少的模型使用量收取更高费用的情况。

这只是个人看法，但我更倾向于资本支出（CapEx）而不是运营支出（OpEx）。如果你能预先购买一台运行良好本地LLM的设备，你就能安心，因为你的配置不会随着时间推移而突然改变，而且只会越来越好。

lambda 10 小时前 |根目录|父目录|上一页|下一页 [–]

如果基准测试结果可信，Qwen 3.6 35B-A3B 的性能已经超过了 Claude 4 Opus。

现在，一些开源模型在某种程度上会进行一些性能优化，参数更多的大型模型总是给人一种功能更强大的感觉。但无论如何，你现在笔记本电脑上的这个模型可以说可以与 Claude 4 Opus 相媲美。我个人没用过 Claude 4 Opus，所以无法进行比较。Claude 4 Opus 似乎仍然可以在 OpenRouter 上找到，如果你感兴趣的话，可以试用一下并自行比较。

某些专有云平台的运行能力可能永远都比笔记本电脑强。在多GPU集群上使用TB级显存可以完成的任务远超笔记本电脑。因此，对于那些追求极致性能的用户来说，Anthropologie可能是他们唯一的选择。

但就目前而言，你可以在笔记本电脑上运行的模型与 Vibecoding 和 Claude Code 刚兴起时流行的云模型相当。

MrScruff 10小时前 |根|父|下一个 [–]

你真的需要对这些基准测试结果持保留态度。我从最初的 Llama 就开始测试本地 LLM，但我试过的所有 LLM 中，没有一个能和 Opus 相提并论。

lambda 9 小时前 |根|父|下一个 [–]

是哪一款作品？它们肯定比克劳德3号作品要好。

总之，欢迎大家在 OpenRouter 上进行对比测试。我很想看到有人能写出测试结果，对比一下现代本地规模的开源模型和大约一年前的前沿模型，最好是使用标准基准测试之外的其他测试方法。

mapontosevenths 8小时前 |根|父|下一个 [–]

YouTube 上有个叫 Bijan Bowen 的人，他一直在测试各种模型（开放式和前沿式），测试内容包括一系列单次或多次编程练习。你几乎可以观看他对比任何两个你可能感兴趣的模型的结果。

我跟他没有任何关系，只是喜欢他的风格，觉得挺实用。我知道他的方法不够严谨，但对我来说已经足够好了，而且我发现他举的例子跟我实际遇到的情况非常吻合。

lambda 7 小时前 |根|父|下一个 [–]

好的，看来他用 Claude 4 Opus 和 Qwen 3.6 35B-A3B 都进行了浏览器操作系统测试。

克劳德 4 部作品：https://youtu.be/J7omabtqnBM?t =193

Qwen 3.6 35B A3B：https://youtu.be/gVU-DQeqkI0? t=215

Qwen 3.6 的功能比 Claude 4 Opus 多得多。

显然，这只是对一个简单的玩具操作系统进行的一次单次测试，但确实，这次测试表明，本地运行的 Qwen 3.6 的性能显著优于一年前的前沿型号 Claude 4 Opus。

MrScruff 9小时前 |根目录|父目录|上一页|下一页 [–]

我通常会比较开源/低成本模型和闭源模型。我经常使用 DeepSeek/GLM，它们还不错，也能完成一些实际工作，但当你切换回 Opus 甚至 Sonnet 时，差距就非常明显了。3B 主动参数 MoE 模型根本无法相提并论。

lambda 7 小时前 |根|父|下一个 [–]

是的。我当时指出的是，本地3B活跃模型比一年前的前沿模型表现更好。

这种趋势会持续下去吗？谁也说不准。前沿模式和本地模式都可能会继续改进。哪一个会先达到S型曲线的顶峰？这很难说。但你现在在本地能做的事情，肯定比一年前在前沿模式能做的事情要好，而一年前就已经有很多人在大量使用前沿模式了。

然而，到了11月，大多数人都认为前沿模型已经足够好用，可以满足大部分工作的需求。本地模型还不够完善（这里“本地”指的是“在当前内存和GPU价格下，能够在1万美元以下的系统上以合理的速度和量化能力运行”）。最大的开放权重模型正在逐步完善，但这些模型需要类似8台H100服务器的配置才能流畅运行。

如果同时比较不同型号的内存，前沿技术和本地内存之间可能永远存在差距，毕竟TB级的HBM内存比GB级的DDR内存功能强大得多。但是，本地内存的性能能否达到足以满足实际工作需求的水平呢？对很多人来说，答案是肯定的。

shimman 2小时前 |根目录|父目录|上一页|下一页 [–]

同意，但就目前的价格而言，Deepseek 和 GLM 在我看来显然更胜一筹。这个周末我只花了 5 美元就买到了这两款产品，而如果买 Anthropic 的产品，我可能要花 20 到 30 美元（而且这还是在有巨额风投补贴的情况下）。

对于网站开发（或其他任何需要大量训练数据的领域）来说，它绝对是首选。就其成本而言，它无可匹敌。美国公司无法在竞争激烈的市场中立足，这就是为什么它们如此依赖美国政府的保护和企业福利。

zozbot234 10小时前 |根目录|父目录|上一页|下一页 [–]

人们似乎对“Opus级”的含义都无法达成一致（最新的Opus显然很弱），但DeepSeek Pro、Kimi和GLM都相当强大。

computerex 10 小时前 |根|父|下一个 [–]

就我个人经验而言，在网页设计方面，没有任何其他工具能与 Opus 相提并论。在处理极其复杂的高性能计算/模型推理开发任务时，也没有任何其他工具能与 Opus 相媲美。我曾使用 Opus 开发过这个项目：https ://github.com/computerex/dlgo

OpenAI 曾经提供过 2 倍使用量，但我仍然使用 Opus，因为它效率更高。

lambda 6 小时前 |根|父|下一个 [–]

哪部作品？

自 2024 年推出 Claude 3 Opus 以来，Anthropic 一直在发布名为 Opus 的型号。

自那时以来，Opus 的功能已经大大增强。

本地模型远胜 Opus 3，在大多数基准测试中甚至超越了 Opus 4。

当然，如果和最新的 Opus 4.8 甚至 4.6 相比，它们还不够完善。但是 4 和 4.8 之间的性能差距非常大。

jkells 5小时前 |根|父|下一个 [–]

我不能代表其他人，但去年11月前沿模型发生了重大变化。我记得是Opus 4.5和GPT 5.2。

我口语中常说的“作品级别”实际上指的是作品4.5级或更高级别。

lambda 5小时前 |根|父|下一个 [–]

没错。本地模型目前还没达到那个水平。那些需要价值数万美元的硬件才能流畅运行的大型开源模型，性能已经基本达到那个水平了，但大多数家用模型还达不到。不过考虑到差距，如果本地模型继续改进，预计到今年11月就能达到那个水平。

rvnx 10小时前 |根目录|父目录|上一页|下一页 [–]

对我来说，完全同意。更进一步说，如果他们继续走现有的路线，随着时间的推移，人们会停止使用 Anthropic。

越来越多的专业化、超高性能芯片将涌入消费市场。尤其是在新的硬件代工厂开始生产之后（当然，前提是我们在此期间没有死于第三次世界大战）。

10 年后，当连基本电脑都配备 128 GB 内存，手机也拥有超级优化的机型时，Anthropic 还有什么意义呢？

直接用Gemma/Gemini/Siri之类的就行了。

色情内容和未经审查的模特也正在推动本土模特的发展。

人们的需求并不是呈指数级增长，而是遵循渐近线（存在上限）。

真正的革命是离线机器人和自动驾驶汽车，但低层移动机器人已经发展到相当极限了。

对于程序员来说，Anthropic 目前提供的改进幅度大约只有 3%，无论是在已知的测试中（例如这只骑自行车的鹈鹕），还是在基准测试内部泄露的问题上。

还行，但算不上革命性的（《寓言》更好，但用起来很不方便，因为想得太多，一个提示就要花 20 分钟）。

dotancohen 8小时前 |父级|上一页|下一页 [–]

> you really need to know what you're asking, and be precise

能否分享一些最近的提示，帮助其他HN用户提前了解如何接近Qwen？如果您不方便在这里发布，我的Gmail用户名和我的HN用户名相同。

谢谢。

Greenpants 8小时前 |根|父|下一个 [–]

很高兴你问到这个问题。我已经开始写一篇关于如何更好地利用本地模型的博客文章了。一旦我整理出足够完整的列表，就会分享出来。如果其他读者也想分享他们的技巧和窍门，请告诉我们！

就目前而言，我脱口而出地说：

- Prompt Engineering 的一些技巧和窍门也适用于此（例如，在你的问题中提供完整的相关上下文，以及代理应该执行的具体任务，例如推理、修改单个文件或尝试一次性修复复杂的任务（不推荐））。

- 如果您已经知道代理人应该查看哪些文件，请告知他们，以便节省时间和了解背景信息。

- 在我个人的工作流程中，我会写下解决问题所需的许多原子性待办事项。在写下这些事项的过程中，我会注意到我所做的假设，或者注意到这些待办事项还可以进一步分解成（原子性的）子任务。

最好自己去感受一下 Qwen 是如何处理你的代码仓库的。我发现，如果我不指定开发架构，它就会进行一些快速而粗糙的修复。如果我不告诉它删除调试语句，它也不会删除。这就是“要精确”的含义——Claude Opus 可能会替你思考，并按照你的最佳利益行事。较小的 Qwen 模型只会执行你要求的操作，不会做更多。它们具备设计知识，但你必须明确地要求它们“激活”这部分知识。

motbus3 9小时前 |父级|上一页|下一页 [–]

尝试使用 DeepSeek V4 闪存

timmit 6小时前 |父级|上一页|下一页 [–]

我买了一台 48GB 内存的 MacBook，但不知为何连 20b 型号都运行不了，我很惊讶你们本地居然有 35b 型号。

klardotsh 5小时前 |根|父|下一个 [–]

4-5 位量化模型应该很适合你的设备。你可以看看 HuggingFace 上的 Qwen3.6-35B-A3B-MTP-GGUF [1]。他们最近还提供了一个很棒的 UI 工具，可以帮助你了解哪些量化模型可以在你的硬件上运行。

添加 KV 缓存后，Full Octane 几乎不可能安装在 128GB 以下的机器上。

[1]: https://huggingface.co/unsloth/Qwen3.6-35B-A3B-MTP-GGUF

nyxtom 9小时前 |父级|上一页|下一页 [–]

您是否发现，更加注重规格说明有助于更好地指导项目？

rjblackman 3小时前 |父级|上一页|下一页 [–]

或许你可以试试 oh-my-pi，因为它声称通过使用独特的补丁格式来改进编辑调用。

GardenLetter27 10小时前 |父级|上一页|下一页 [–]

该程序能否检查工具调用是否失败，并将其传递给小型模型进行修正，而不会阻塞主上下文？

lambda 10 小时前 |根|父|下一个 [–]

问题是，要进行正确的修复，真的需要所有上下文信息（也许失败的工具调用是对一个文件进行编辑，而该文件最后一次被修改是在上下文的开头），所以你需要要么让这个较小的模型一直运行并进行提示处理，要么在它对整个会话进行提示处理时等待很长时间。

此外，有时工具调用错误是因为某个文件被替换掉了；较大的模型可能能够更好地找出问题并进行修复。

最后，在 Pi 中，您始终可以使用 `/tree` 命令跳转到一系列工具调用失败之前的状态，并可根据需要添加摘要，以便模型了解发生了什么。Pi 的 `/tree` 命令在管理上下文方面非常强大。

8 小时前 |根|父|下一个 [–]

我经常看到的一个例子是，在项目中创建 Jira 工单时，如果自定义字段被标记为必填项，系统会尝试创建工单，但缺少该字段，导致工具调用失败。LLM 需要访问完整的上下文信息，才能生成文本并填充到“为什么这次会议不能以电子邮件形式进行？”字段中。

Greenpants 10小时前 |根目录|父目录|上一页|下一页 [–]

我其实相当肯定，直接重试工具调用通常就能修复编辑调用。但这些模型经过训练，需要一段时间才能“思考”出问题，所以它们会假定编辑问题更加根本，从而浪费不必要的令牌来填充上下文。

我会进一步试验 AGENTS.md 规则对本地 Pi 代理的有效性。我觉得与 Claude 模型相比，较小的（本地）LLM 模型对上下文窗口中的元素（例如精确指令）的关注度不足。

amelius 9小时前 |父级|上一页|下一页 [–]

听起来很酷，别误会我的意思，但我认为对大多数人来说，门槛应该比 HTML/CSS 更高。

喷嘴装置 2 小时前 |根|父|下一个 [–]

我使用 Mac Studio 上的本地 LLM 来编写和运行 F# 单元测试套件，以及其他一些我不想自己做的枯燥的项目杂务。

q3k 8小时前 |根目录|父目录|上一页|下一页 [–]

我喜欢启动一整排服务器，就为了让某个糟糕的、有bug的TUI生成一行bash代码，把我的测试运行器注释掉。

我们真的生活在一个极其愚蠢的时代。

krainboltgreene 3小时前 |父级|上一页|下一页 [–]

就像一个知识面很广的初级员工，你需要指导他，而不是一个能和你一起思考架构的高级员工。

我不想冒犯你，但你的领英个人资料显示，你从事编程工作的时间加起来（往多了说）也就8个月左右（职位是人工智能工程师）。其余时间充其量也只是与编程沾边。你怎么能真正了解这两种情况呢？

SoftTalker 2小时前 |根|父|下一个 [–]

自从前雇主要求所有人创建LinkedIn个人资料后，我就再也没登录过或查看过它。所以我的个人资料现在已经过时大约20年了。

krainboltgreene 2小时前 |根|父|下一个 [–]

他的观点非常新颖。但并非每个人都像你一样。

yieldcrv 9 小时前 |父级|上一页|下一页 [–]

它经常陷入循环。

与我的经验相符，而且是决定性因素。

此外，上下文窗口的大小也太小了。我再也无法同时操作 65,000 个窗口了，因为即使只是阅读代码的文件结构也会超出窗口大小，让我一无所获。这绝对是一门独特的艺术。

现在对我来说，上下文窗口数量达到 20 万个或以上就可以了。

我昨晚看到一篇论文，应该对这个问题有很大帮助。

Greenpants 9小时前 |根|父|下一个 [–]

我明白这对某些人来说是无法接受的；这确实需要耐心。

在 Pi 中，/new 绝对是我最得力的助手，也是我最常用的命令。对于简单的任务（无论如何，我都会将复杂的任务分解，因为我不信任小型本地 LLM 能帮我完成这些任务），模型不需要太多上下文信息，因为我对自己的代码库非常熟悉：“我需要特性 X。请查看文件 1、2 和 3 进行修改。”

kennywinker 9小时前 |根目录|父目录|上一页|下一页 [–]

如果你的显存足够，Qwen3.6-35b 可以很好地处理 256k 的上下文。我目前只用了 16GB 显存，运行的是 128k 的上下文。

horsawlarway 11小时前 |上一页|下一页 [–]

个人使用可以。

我放弃了每月 100 美元的 Claude 订阅，转而运行指向 unsloth studio 的 pi 线束，根据心情使用 qwen (unsloth/Qwen3.6-35B-A3B-MTP-GGUF) 和 gemma (unsloth/gemma-4-26B-A4B-it-GGUF) 型号。

我有一台大约 5 年前组装的机器，里面装了两块 RTX3090 显卡（反正我本来就打算组装一台新的游戏机器，而且 llama 显卡刚发布，所以我又加了一块二手的 3090 显卡），这两款显卡（UD-Q4_K_XL 量化）都能达到约 150tok/s 的速度，并且可以在不退出显存的情况下使用完整的 300k 上下文长度。

说清楚点——它不如克劳德。但它是免费的，而且差得也没那么严重，所以差别不大。

就我个人而言，免费比每月 100 美元好。

我还有一个指向同一推理服务器的 openclaw 实例，它非常适合用于本地模型（这确实是一个可靠的用例）。

一些示例项目

- 适用于安卓电视的替代启动器（带有儿童使用情况监控和追踪功能）

- 为我的 Kubernetes 集群服务定制的管理门户

- 定制化家庭助手集成/自动化（最近集成了一些用于电源监控和切换的 Shelly 设备）

- 购物清单管理和膳食计划（主要通过 OpenClaw）

- comfyui 中一些用于 3D 资产生成的自定义工作流程。

---

简而言之，如果你想通过软件赚钱……我可能还是会建议你使用付费服务商。不过，本地软件也能实现很多很棒的功能。

根位置 11 小时前 |父级|下一级 [–]

两块 RTX3090 显卡大约 4400 美元。不包括任何电费或其他部件费用，相当于 3.6 年每月 100 美元，克劳德。

9小时前 |根|父|下一个 [–]

假设 100 美元/月的 Claude 订阅服务在三年后仍然存在。

booi 6小时前 |根|父|下一个 [–]

三个月后它还能存在，我们就很幸运了。

horsawlarway 11小时前 |根目录|父目录|上一页|下一页 [–]

是的，现在不是购买硬件的好时机。

我买的时候，每个花了850美元。而且我反正也需要一台来玩游戏。

我估计下一个买入的好时机将在24-36个月后，具体取决于人工智能泡沫的走向。

---

我还要补充一点，我个人不太喜欢苹果的硬件（与其说是硬件问题，不如说是他们的公司理念问题），但是他们采用统一内存（或AMD最新的统一内存产品）的机器速度与我的3090显卡相当，而且可能是目前更好的本地LLM入门级产品。

这个笑话的由来是这样的：硅谷的软件开发商为了开发 OpenClaw 而买光了所有的 Mac mini。

你可以花大约 2000 美元买到一台配备 48GB 统一内存的 M4 Pro Mac mini。如果你不打算用这台机器做太多其他事情，那么它就是我目前会选择的经济型推理设备。现在花一年时间使用 Claude，就能在接下来的十年甚至更长时间里几乎免费地获得大约 150tok/s 的运算速度。

如果你想要性能更强的处理器，并且愿意多花一点钱，那就选择新款的 Ryzen AI Max+ 395 机器。

你的电费也会降低。

我最后的建议是，现在就去买一块RTX 3090显卡。你可以用更少的钱买到性能更好的显卡。

tracker1 8小时前 |根|父|下一个 [–]

如果你愿意选择 AMD 的产品，那么与 Nvidia 相比，AMD Radeon Pro R9700 的价格确实很有吸引力。

felooboolooomba 7 小时前 |根|父|下一个 [–]

Radeon显卡也能运行LLM吗？

lloyd-christmas 2小时前 |根|父|下一个 [–]

我用一块 R9700 显卡运行 qwen 27B:Q4 @ 130k 上下文，线程速率为 50 t/s，还有一块 7900XT 显卡作为它的子代理运行 mellum 12B:Q8。R9700 在低功耗和降频方面表现非常出色。它的设计功耗是 300W，我的这块被限制在 210W，性能下降只有 8%。如果我家里有其他地方可以放我的台式机，我会把它的功耗提高到 240W，性能也不会有任何损失。

freetonik 11小时前 |根目录|父目录|上一页|下一页 [–]

如果你喜欢玩PC游戏的话，那也意味着多年的顶级PC游戏体验。

augusto-moura 10小时前 |根|父|下一个 [–]

双RTX 3090对于游戏来说性能过剩，你完全可以用更少的钱在最高画质下流畅运行市面上所有已发售的游戏。

drnick1 10小时前 |根|父|下一个 [–]

一块 RTX 3090 对于游戏来说绝对不算性能过剩。如今，它甚至勉强能在一些新出的游戏中达到 4K 分辨率 60 帧。但令人惊讶的是，我的这块 3090 显卡现在可能还和我四年前买的时候一样值钱。

arcanemachiner 6小时前 |根|父|下一个 [–]

现在它可能更值钱了。

9小时前 |根目录|父目录|上一页|下一页 [–]

对于游戏来说，拥有第二张显卡其实并没有什么好处。

5小时前低血糖 |根目录|父目录|上一页|下一页 [–]

我无法以 240Hz 刷新率和路径追踪运行 4K HDR 的《赛博朋克 2077》，帧率只有 120fps 左右。我的显卡是 Blackwell 6000。我买它不是为了玩游戏，但有些游戏和配置确实会遇到显卡瓶颈的情况。我甚至连 8K 电视都没有。

googletron 10 小时前 |根目录|父目录|上一页|下一页 [–]

什么？

kakacik 10小时前 |根|父|下一个 [–]

据我所知，英伟达显卡现在协同工作（以前称为SLI）的效果并不好。所以那说法不属实。

此外，两代之前的处理器意味着光线追踪性能很差，路径追踪甚至可能根本无法进行。我几乎可以肯定，如果不开启DLSS升频器，它无法在所有设置都调到最高的情况下流畅运行原生4K分辨率的《赛博朋克2077》。

himata4113 10小时前 |根|父|下一个 [–]

你可以将第二张显卡用作分担任务的显卡，用于图像放大、帧生成等等。

爱尔兰咖啡 9 小时前 |根|父|下一个 [–]

当我不运行模型时，我会将第二个虚拟机以直通配置连接到 Windows 虚拟机，用于各种用途，通常是玩游戏。

driverdan 5小时前 |根目录|父目录|上一页|下一页 [–]

如果你花2200美元买一块3090显卡，那你就是个冤大头。它们根本不值这个价。

氟化处理 1 小时前 |根目录|父目录|上一页|下一页 [–]

去二手市场看看，别去新市场。肯定有一些价格比新车便宜得多。

jmuguy 10小时前 |根目录|父目录|上一页|下一页 [–]

或者，把游戏设置调到最高，玩《Satisfactory》会获得非常棒的体验，这是无价的。

matheusmoreira 6小时前 |根目录|父目录|上一页|下一页 [–]

这些GPU还可以玩视频游戏或挖掘加密货币。它们之后还可以出售。

我们应该拥有物品，而不是租赁。我们都应该尽一切努力阻止传说中的2030年计划的实施。

tripleee 10 小时前 |根目录|父目录|上一页|下一页 [–]

基督显卡的价格已经疯了

AMD显卡在LLM模式下的性能如何？一块9070显卡售价约为600美元，配备16GB显存。

9小时前 |根|父|下一个 [–]

就我个人经验而言，我不会为了编程而使用 16GB 的存储卡——常用的模型体积略大，难以达到合理的运行速度。

lambda 9 小时前 |根目录|父目录|上一页|下一页 [–]

应该效果不错。内存带宽是令牌生成的最大瓶颈，644 GB/s 的带宽在 9070 上应该能很好地完成任务，而提示符处理更依赖于计算能力，Nvidia 在这方面往往更胜一筹。

16 GiB 的内存容量不够用，所以你可能至少需要 2 倍的内存，最好是 3 倍的内存，然后你还需要一块能够承受这种容量的主板、电源等等。

tracker1 8小时前 |根|父|下一个 [–]

根据你所在地区的不同，你可以花大约 1200-1400 美元买到一块配备 32GB 显存的 R9700，这对于 AI 应用来说可能比两块 9070(xt) 更好。

lambda 7 小时前 |根|父|下一个 [–]

是的，当然。

nyrikki 11小时前 |根目录|父目录|上一页|下一页 [–]

使用三块 1080ti 显卡和稀疏配置可以达到 60tps，我估计两块 16GB 的 5060ti 显卡也能达到同样的效果，价格在 1200 美元左右。一块 3090 显卡就足以搭建一个实用的系统，即使是在老旧的 AM4 主机上。

flowerthoughts 10小时前 |根目录|父目录|上一页|下一页 [–]

3.6年后，它们很可能仍然值3000美元。除非出现新的芯片制造厂，能够大量生产芯片，从而扰乱市场。即使人工智能泡沫破裂，我也不认为我们会看到高显存GPU的价格暴跌。

kpw94 10小时前 |父级|上一页|下一页 [–]

> gemma (unsloth/gemma-4-26B-A4B-it-GGUF) 模型

既然你正在运行量化（在 UD-Q4_K_XL），请查看“qat”模型（unsloth/gemma-4-26B-A4B-it-qat-GGUF）！

- https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF（6月 9日更新：新增MTP支持。）

- https://blog.google/innovation-and-ai/technology/developers-...

me_bx 9小时前 |根|父|下一个 [–]

今日学到：

量化感知训练 (QAT) [...] 能够在保持与 bfloat16 相似质量的同时，显著降低加载模型所需的内存。

SubiculumCode 7 小时前 |根目录|父目录|上一页|下一页 [–]

QAT模型的编码能力如何？自从发布以来，我一直在寻找相关评价，但没找到太多。

twothreeone 10小时前 |父级|上一页|下一页 [–]

> unsloth/Qwen3.6-35B-A3B-MTP-GGUF

实际上，我也在本地尝试过完全相同的模型……尽管只是在 128k 上下文的单个 3090 上，使用 Q4_K 量化时，我得到了大约 40-60tok/s 的速度。

最让我恼火的是，在处理中等复杂程度的实际编程任务时，输出结果的质量实在太差。在“提示/感觉”和“手动实现”之间来回切换实在太麻烦了，因为你每隔几分钟就得扪心自问：是不是我的操作“不对劲”或者这个模型本身就太笨了。

它似乎也无法很好地处理从“底层实现细节”到“高层设计”的过渡，例如，它无法轻松渲染表格之类的元素。使用 Claude 时我没有遇到这个问题……所以我觉得目前来看，它还不是一个可行的替代方案。我真心希望几个月后情况会有所改变。

哦，我用“aider”替换了 Claude CLI，这可能也不是最佳方案……我不确定。当然，MCP 市场很有用，不过理论上你也可以随着时间的推移手动替换它们。

horsawlarway 10小时前 |根|父|下一个 [–]

我一般不会自己动手实现模型，尽管确实有些时候我会停下来，在任务进行过程中进行纠正。

它倾向于进行更长时间、更重复的思考，再一次——它绝对不是作品 4.7/4.8。

我一直使用 pi.dev 作为我的框架，并且惊喜地发现它非常好用（我曾经使用过 aider，但只是很短的时间，而且是很久以前的事了——所以我无法真正进行比较）。

我觉得克劳德现在的状态和一年前差不多——大部分课程需要更多地采用“结对编程”的方式，而不是“让它运行几个小时”。

即使在工作中使用像 Opus 这样的工具，我也非常喜欢频繁的“人机交互”式工作流程。我对很多事情都有自己的看法，而不断强调模型应该停下来询问意见，似乎能让我获得更好的结果，而无需“重新迭代”。

我做过不少管理工作，我觉得现在的工作量大概相当于一个初级开发人员一天的工作量，而我每五分钟就能完成。就像初级开发人员一样，你需要经常引导项目回到正轨。

Opus现在给我的感觉更像是一个中级工具。我可以把一部分工作交给它然后“离开”，但如果我全程在线监控/指导，产出效果会更好。

unethical_ban 9 小时前 |根目录|父目录|上一页|下一页 [–]

我对这些东西完全不了解，这是我从事IT行业以来第一次感觉自己如此落后。

我使用 Claude Opus 快速有效地编写了一些 100-200 行的脚本，这些脚本与供应商的 API 集成，而且它几乎一次性就完美地完成了这两个脚本。

我想知道，对于很多这类本地模型来说，人工智能辅助的范围是否应该缩小：先设计好工具和功能定义，然后让人工智能一次实现一个？有人严格按照这种方法来做吗？

gonzalohm 11小时前 |父级|上一页|下一页 [–]

通过添加第二个 GPU，每秒令牌数是否翻了一番？还是增幅远小于此？

horsawlarway 11小时前 |根|父|下一个 [–]

推理速度并没有实质性变化。它基本上只是允许我添加更多上下文信息或更大的模型。

单个 RTX-3090 的运算速度大致相同，但其显存容量不足以容纳 300k 的全部运算量。

有时候这很重要，但很多时候并不重要。

就速度而言，MOE 型号表现出色。现代型号性能提升的最大优势在于采用了 MOE 架构。

我从 Gemma-4 31B 密集型模型和 Gemma-4 26B MOE 模型（均为 Q4 量化）中获得了非常相似的质量，但 MOE 版本运行速度约为其 3 倍（150tok/s 对 46tok/s）。

mirekrusin 11小时前 |根目录|父目录|上一页|下一页 [–]

你添加额外的GPU是为了增加显存，而不是为了提升速度。

agup792 11小时前 |父级|上一页|下一页 [–]

听起来很棒。如果我手头有闲置的显卡，我肯定会这么做。不过，不然的话，感觉成本会很高。

anhtqweb 8小时前 |父级|上一页|下一页 [–]

购物清单管理和膳食计划听起来很有意思。您能否详细介绍一下您的使用场景？

bluejay2387 11小时前 |上一页|下一页 [–]

我大约 90% 的编码工作都是在 Qwen 3.6 27b 和 OpenCode 上完成的，还用到了一些自定义技能和 Semble。它虽然不如 CC 或 Codex 那么智能，但足以完成我的大部分工作。我最初并没有打算取代 CC 和 Codex（我有一块 RTX 6000 显卡，所以 TPS 对我来说已经足够快了，不过 RTX 6000 最初是用于其他工作的）。我只是想尝试一下，看看在编码方面，Qwen 能达到怎样的前沿水平，结果还不错，所以我就继续用了。对于非常复杂的问题和需要优化 UI 的地方，我仍然会用到 Codex，因为这似乎是 Qwen 最薄弱的环节。我并不推荐大家使用 Qwen，因为我觉得大多数人都没有 RTX 6000，而且成本相当于多年的 CC 或 Codex MAX 订阅，但至少这看起来是可行的。也许再过几年，它就真的会变得实用了。

其他说明：我不得不将紧凑目标设置为 75%，上下文窗口大小为 256k，因为一旦对话长度达到 100k 左右，我就会发现质量和速度开始下降。这个问题在 150k 左右时变得非常严重。我也尝试过 Qwen 3.5 122b，但它在编码方面似乎比 3.6 27b 差很多，尽管它的模型更大。也许是因为我使用的是 4 位量化器，或者是我配置不正确？我知道 3.6 是较新的版本，但我没想到它的性能会超过上一代更大的模型。Gemma 4 31b 在其他任务方面表现不错，但至少就我个人经验而言，Qwen 在编码方面更胜一筹。Nemotron Super 120b 在很多方面都很出色，但它在编码方面似乎也不如 Qwen。这让我非常惊讶。

河北 11 小时前 |父级|下一级 [–]

我也是，我用的是 Qwen 3.6 27b (Q6 quant) 版本，搭配 llama.cpp 脚本，运行在 RTX 5090 显卡上，现在只用 pi 代理。因为是本地运行，所以我完全不用担心代币定价、配额、时间段或者数据敏感性等问题。我把 GPU 的功耗从 600W 限制到了 450W，这样系统在推理过程中几乎不会发出任何噪音。

我已经变得非常“懒惰”（这是好事），以至于除了编程之外，我还开始用这个模型来处理许多日常琐事：

* "commit this on a branch, push, create a PR and assign $nickname for review"

* "Use the Stripe CLI to download all open and overdue invoices and reconcile them with this CSV export from our bank account."

* "Use these Elasticsearch credentials to summarise what kind of operations are causing load at the moment."

* "Tell me if our codebase already supports X and where it's implemented."

amarshall 7小时前 |根|父|下一个 [–]

您使用的上下文长度和键值缓存量化值（如果有）是多少？以及 MTP 模式？

lloyd-christmas 1小时前 |根|父|下一个 [–]

我不是你问的那个人，但我有一块 9700，显存和你的一样。在上面运行 Q6 测试，使用未量化的键值，上下文信息量为 50k。加上 `-ctv q8_0` 参数后，上下文信息量增加到 70k。我通常使用未量化的键值，在 50 t/s 的线程速率下（mtp 3），以 130k 的上下文信息量运行 Q4 测试。需要说明的是，我使用的是 PCIe 4.0 x8 通道，所以速度会略慢一些。我发现量化键值会导致工具调用时 JSON 数据损坏，而且几乎无法恢复，但具体情况可能因人而异。

bo1024 11小时前 |父级|上一页|下一页 [–]

Qwen3.5-122B 实际上是 Qwen3.5-122B-A10B。A10B 表示这是一个“专家混合模型”，其中每次只激活 10B 个参数。而 Qwen3.6-27B 是一个“密集模型”，其中所有 27B 个参数始终处于激活状态。因此，对于许多任务而言，27B 密集模型的性能通常优于 122B-A10B 模型。

用户43928 8小时前 |父级|上一页|下一页 [–]

我被迫在工作中使用 Qwen 3.6 27b，发现它几乎毫无用处。与其让它引入另一个混乱的机制或把调试搞得一团糟，还不如手动完成所有工作。

除了用作更智能的搜索功能外，感觉使用 Sonnet 以下的软件都是在浪费时间。

令我感到奇怪的是，你居然会提到 Codex 的 UI 优化，因为它的 UI 水平出了名的差，远不及 Claude Opus。Altman 曾明确表示，他们正在努力改进，以期在下一代产品中实现这一目标。

sejje 8小时前 |根|父|下一个 [–]

它可能擅长分析和审查、编写文档、提交 Git 代码等等——即使它不擅长编码。

所有那些繁琐的杂务。

用户43928 7小时前 |根|父|下一个 [–]

糟糕的人工智能文档编写和提交记录并不理想，尤其是在团队合作中。

同事们提交的合并请求描述明显马虎且经常不准确，我几乎觉得受到了冒犯。

也就是说，我发现人工智能在处理很多繁琐的工作方面很有用，例如解决合并冲突或将更改拆分为单独的合并请求。

尤其是后者，我在处理小型模型时遇到了很多问题，它们会把我想移动的更改搞得一团糟。即使尝试了第二次，GPT 5.4 mini 也未能成功地将 10-20 行代码移动到另一个文件而不对其进行任何修改。

htrp 11小时前 |父级|上一页|下一页 [–]

为什么是 27b 而不是 35b？教育部在编码方面真的差那么多吗？

electronsoup 10 小时前 |根|父|下一个 [–]

是的，相同尺寸下，MoE的性能确实稍逊一筹，但即使启用CPU内存卸载，通常也能以可观的速度运行更大的MoE。高密度模型确实需要100%占用显存。

amarshall 7小时前 |根目录|父目录|上一页|下一页 [–]

可以对 MoE 的总参数和有效参数取几何平均值，以获得与密集模型参数近似等效的质量。因此，sqrt(35*10)≈18.7。

MoE 的权衡之处在于，在总尺寸相同的情况下，它的性能较差但速度更快。

codinhood 12小时前 |上一页|下一页 [–]

我觉得你很难得到什么“真正”的答案。现在不用最新最好的模型的机会成本实在太高了。

我每个月都会研究这个问题，得出同样的结论：目前来看，要让本地模型（以及相关的编码工具）的性能接近 Claude Code 的 Sonnet/Opus 版本，所需的时间、精力和成本都太高了，根本不值得。如果真的值得，那它早就成为新闻热点了。

并不是说我否定了可能已经有人解决这个问题，我只是想用奥卡姆剃刀原理来避免钻牛角尖。

pyeri 11小时前 |父级|下一级 [–]

机会成本错失恐惧症（FOMO）这种心态总有一天会达到饱和点，而我认为我们已经过了那个点。神话类模型完全是另一种东西，它在推理方面非常先进，但对于大多数开发者试图解决的问题领域来说用处不大。

目前的 Sonnet/Opus 版本（约 4.8）很可能最终会成为企业用户普遍使用的版本。虽然本地化版本尚未推出，但可以通过 NVIDIA、OpenRouter、Groq 等 API 使用 DeepSeek、Kimi、GPT、MiniMax 等系列产品提供的经济型替代方案，这些方案的性能与 Sonnet 非常接近。

codinhood 10 小时前 |根|父|下一个 [–]

对，这正是我要等的。

就我个人而言，我认为我们还没达到那个阶段。虽然我确实认为模型改进已经开始趋于平缓（达到局部上限），但我并不确信局部模型已经能与sonnet/opus相媲美。差距仍然很大。但我很期待这些模型能够达到那个水平。

phyzix5761 3小时前 |父级|上一页|下一页 [–]

谁要承担机会成本？对于所有企业和工程师来说，支付前沿模型的费用都变得异常昂贵。

mark_l_watson 10 小时前 |父级|上一页|下一页 [–]

听起来这个结论也正确。我正在尝试过渡到一个分层系统：本地系统，然后是带有商业厂商 API 的 OpenCode 系统（例如 DeepSeek v4 闪存），最后是 DeepSeek v4 Pro 系统。

通过分层部署的方式，我们可以逐步过渡到更多本地运行，同时仍然能够完成所需的工作。实际上，我的本地配置比两个月前好得多，比六个月前更是好太多了——而且硬件配置都没变。

sakopov 11小时前 |父级|上一页|下一页 [–]

这似乎就是答案。组装一台配备不错显卡的电脑要花费 2000 美元以上，而且效果也不尽如人意。还不如继续使用每月 100 美元的 Claude 子版块，直到开源替代方案的性能能够与目前的顶级型号相媲美。

gunapologist99 7小时前 |父级|上一页|下一页 [–]

与其考虑奥卡姆法则，不如考虑帕累托法则？

如果你真的相信它会在未来几年内实现，那么你现在就可以开始尝试了（而且，是的，你会非常惊讶，特别是对于较短/较小的项目或模块化良好的大型项目）。

MadrasThorn 10小时前 |父级|上一页|下一页 [–]

但它在加速硬件创新方面表现出色。

jrm4 12小时前 |父级|上一页|下一页 [–]

但你实际上是在用每秒代币数来衡量机会成本，对吧？

我认为，例如每秒令牌数（乘以或乘以私有模型的感知质量）是否真的意味着“更好或更有用的输出”，还有待观察。

我强烈怀疑事实并非如此。（不过我也强烈怀疑这一点很难衡量，因为在这里弄虚作假的动机太强了。）

codinhood 11 小时前 |根|父|下一个 [–]

如果你认为模型指标未必能转化为有用的输出，我同意。我衡量模型成功与否的标准并非如此，这也不是我想表达的重点。我尝试在实际项目中搭建模型并进行测试。

我的意思是，如果本地模型在实践中真的能与 Claude Code 相媲美，就不会出现这样的讨论帖了。这对用户来说显而易见，而且会造成巨大的混乱。如果个人和公司可以在本地运行模型并持续获得类似的结果，为什么还要花几百甚至几千美元购买 Claude Code 呢？

我每个月都会重新考察当地的生态系统，希望答案有所改变。但到目前为止，我的经验表明情况并没有改变。

jrm4 5小时前 |根|父|下一个 [–]

例如，我亲眼目睹微软维持垄断地位长达十多年，我的经验表明，“质量永远胜过炒作”这句话根本没有任何道理。

克劳德很有可能只是在炒作中占了上风。

拉斯顿伯里 11 小时前 |根目录|父目录|上一页|下一页 [–]

我认为他们指的是，节省下来的时间（用于完成本地模式无法完成的事情或纠正其错误）的机会成本，与订阅成本之间的权衡。

pierotofy 12小时前 |上一页|下一页 [–]

是的。Llama.cpp + Qwen3.6-35b (MTP) + OpenCode 功能强大，仅需一块 RTX 3090 显卡即可运行，速度比大多数云端模型都快。画质堪比 8-12 个月前的边缘模型。详细设置信息请访问 https://github.com/pierotofy/LocalCodingLLM/

jacobgold 11小时前 |父级|下一级 [–]

“质量就像是运行8-12个月前的尖端模型一样。”

这对于业余爱好者来说听起来很棒，但恕我直言，直到六个月前（2025年12月25日）发布的Opus 4.6版本，我们才拥有了一个足够好的模型，可以供专业人士用作其编码代理的主要驱动工具。这似乎才是值得努力达到的目标。

kelnos 4分钟前 |根|父|下一个 [–]

我不确定你说的“主要驱动程序”是什么意思，但我发现即使是Sonnet在编码任务中也相当有用，大约在 12-14 个月前（当时我太抠门，不愿意每月支付超过 20 美元，而 Opus 很快就达到了我的限额）。

当然，我现在从 Opus 中获得的价值要大得多，但我完全可以理解有人出于隐私（或其他）原因，决定将自己限制在 8 到 12 个月前的 Opus 性能范围内。

兄弟 11 小时前 |根目录|父目录|上一页|下一页 [–]

我非常同意，正是那个版本让这些工具变得足够好，能够显著提高我的工作效率。我必须承认，在那之前我对人工智能编程一直持怀疑态度。

dnautics 10 小时前 |根|父|下一个 [–]

对我来说（可能是因为我使用的语言），我在九月份左右经历了一个相当大的高峰，在一月份左右经历了一个巨大的高峰。

我现在使用的项目库是由 Claude 在九月份完成最终完善的 OT 库。

故事 5 小时前 |根目录|父目录|上一页|下一页 [–]

使用一些本地模型，您已经可以在子任务上达到 Opus 4.6 的性能水平。因此，您需要选择合适的代码编写、计划编写、代码测试等模型，以满足您的预期目标，并使用允许为不同子任务调用不同 LLM 的编码工具。例如，人们使用 StepFun 3.x 或 DeepSeek4-Flash 进行计划，使用 Qwen3.6-27B 进行编码。

alexandra_au 2小时前 |根目录|父目录|上一页|下一页 [–]

你的日期和型号都错了，是 2025 年 11 月发布的 Opus 4.5 改变了一切，Opus 4.6 于 2026 年 2 月发布。

jacobgold 2小时前 |根|父|下一个 [–]

你说得对。12月的时候感觉确实不一样了，但Opus 4.5实际上是在2025年11月24日发布的。

https://www.anthropic.com/news/claude-opus-4-5

Projectiboga 11小时前 |根目录|父目录|上一页|下一页 [–]

所以，在本地开放模式下，可能需要 6 到 8 个月才能达到可用水平？当然，最先进的技术会领先一年，按照目前的速度，相当于一代技术。

pierotofy 11小时前 |根目录|父目录|上一页|下一页 [–]

我工作时使用它。

jacobgold 11小时前 |根|父|下一个 [–]

如果你喜欢那样当然没问题，但很难想象在有质量更好、价格相对于员工成本而言更低的产品可供选择的情况下，这会是一个完全理性的选择。或者你的使用场景有什么特殊之处？

vector_spaces 11 小时前 |根|父|下一个 [–]

并非所有工作都需要每个环节都做到如此精细的优化，而且可能还存在一些你完全看不到的限制。有些限制我很容易想象：比如，父母所在的行业监管严格，他们的IT团队行动迟缓且疑神疑鬼，而这是一种安全且不引人注意的变通方法，输出结果对他们来说“足够好”，而且他们觉得不断调整也很有趣。

无论如何，我认为在对这个人处境缺乏了解的情况下，如此居高临下地评判他，并没有什么益处。即使你完全了解情况——也应该尊重他人，不要妄加评判，或者至少把评判放在心里。让别人觉得自己很愚蠢，只会让人对你接下来要说的任何事情都失去兴趣。

pierotofy 10小时前 |根目录|父目录|上一页|下一页 [–]

在我看来，不理性的是，你竟然认为你必须租用工作工具，同时还要将雇主的所有知识产权暴露给第三方。这只是个人观点不同而已。

jacobgold 10小时前 |根|父|下一个 [–]

我并不认为你“必须”租用工具，但这无疑是2026年务实的选择。我和大家一样都希望这种情况能够改变，而且我相信这种情况迟早会发生。

lokar 11小时前 |根目录|父目录|上一页|下一页 [–]

这难道不取决于你的用途吗？功能较弱的系统可能足以应对样板代码、适度的重构等等。毕竟，不是每个人都会一次性构建完整的功能。

epolanski 6小时前 |根目录|父目录|上一页|下一页 [–]

你们为什么不愿意花点时间努力，反而总是追逐最新最潮的东西呢？

你们一定是那种用 React 和 Tailwind 写网站，假装自己是工程师，对所有事情都发表意见的人吧。

trueno 11小时前 |父级|上一页|下一页 [–]

我有一台128GB的MacBook Pro（M4 Max），一直想折腾一下这些东西，但实在抽不出时间。这里有没有用类似配置的Mac用户能分享一下经验？

我总是看到关于本地化的精彩辩论，但这个领域的规则一直在变化，而且所有相关的术语对我来说都很陌生。我很想了解那些有客观经验的人，在选择本地化产品时，他们觉得失去了什么（或者得到了什么），这样我才能自己判断这些东西是否适合我。

brycesub 11小时前 |根|父|下一个 [–]

如果你有一台128GB的Mac，你真的应该试试Redis创建者开发的这个项目：https://github.com/antirez/ds4。这可能是最接近最先进的本地LLM+代理编码方案了。

__mharrison__ 8小时前 |根|父|下一个 [–]

今天早上刚在我的DGX Spark上试用了一下。速度比Frontier系列慢一些，但我每月200美元的周套餐额度在还剩3天的时候就用完了……

（不应该在高模式下进行重构工作）

trueno 9小时前 |根目录|父目录|上一页|下一页 [–]

这真是太有趣了，谢谢你让我注意到它。

lostlogin 10 小时前 |根目录|父目录|上一页|下一页 [–]

谢谢。

htrp 11小时前 |根目录|父目录|上一页|下一页 [–]

使用你的 ClaudeCode 子程序，并让它为你进行设置。

dirkolbrich 8小时前 |根目录|父目录|上一页|下一页 [–]

我的机器跟你的一样。你可以看看https://omlx.ai/，这是一个“macOS 原生 MLX 服务器”。pi.dev 则提供带有 MCP、网络搜索和子代理扩展功能的代理。

atomicnumber3 11小时前 |父级|上一页|下一页 [–]

我也是。我再也不想用克劳德了。

pierotofy 11小时前 |根|父|下一个 [–]

没错。去他妈的 Anthropic、CloseAI 以及这个领域所有其他唯利是图者。

akulbe 10小时前 |根|父|下一个 [–]

我有一台配备 96GB 内存的 M2 Max MacBook Pro。对于这种配置，您会选择哪些型号和配置？

monirmamoun 9小时前 |根|父|下一个 [–]

下载 LM Studio 来试用，它能让你搜索模型……试试 4 位、5 位或 6 位的 Qwen3.6-35B-A3B（6 位 XL 版本近乎完美），然后用 Pi Coder 或其他外接工具来访问它……你也可以试试 Unsloth Studio，先用同样的模型试试。LM Studio 稍微容易上手一些，Unsloth 的质量可能更好。顺便说一句，这两个软件的质量都不算特别好（也就是说：它们崩溃或运行异常的频率太高，不适合作为完整的生产解决方案，但可以用于本地编程）。下载这两个软件后……你就可以在 Hugging Face 上搜索模型了。只需输入 qwen 即可开始搜索……然后就可以开始尝试了。你需要使用 LM Studio 和 Unsloth 提供的 HTTP 接口将树莓派编码器线束连接到引擎 API，所以请确保你找到了相应的 URL 并启用它……例如 127.0.0.1:1234/api 就是一个典型的 IP 地址（localhost）和端口号（1234 是 LM Studio 使用的端口）。

daveidol 11小时前 |父级|上一页|下一页 [–]

你是直接在文档中提到的那台 Windows 机器上进行开发工作，还是通过另一台机器远程访问它？我这么问是因为我有一台闲置的 RTX 3090 显卡，装在游戏台式机里，但我没有用它来做任何开发工作（我用的是 Macbook Pro）。

snake_n_my_boot 9小时前 |根|父|下一个 [–]

我的配置和你类似，一直用它来学习和研究开源模型。我在游戏台式机上运行 Ollama，然后从我的 MacBook 上用 OpenCode 访问它。目前为止，一切都很顺利。

lelandbatey 11小时前 |父级|上一页|下一页 [–]

我用过，挺好，工作能完成，但我知道他们说“是真的”的时候是认真的。

“质量就像运行8-12个月前的边缘模型一样。”

别指望它能写出像《大作》那样的巨著，它更像是一首俳句。如果你对它进行精细的管理，就能取得显著的成果。但如果你把它当成一个被困在盒子里的人，它就会一事无成。

迪拉 11 小时前 |父级|上一页|下一页 [–]

是我做错了什么吗？还是ollama已经彻底变质了？

我在https://ollama.com/search上查看，排名前几位的型号，例如 kimi-k2.7-code，都带有“云”字样，但我似乎无法通过 ollama 获取它们。

我以为 ollama 的全部意义就在于它不是云？

satvikpendem 11 小时前 |根|父|下一个 [–]

不建议使用 Ollama。请使用 llama.cpp。

hoherd 11小时前 |根目录|父目录|上一页|下一页 [–]

一两个月前我也遇到过同样的情况。一位朋友发给我这篇文章，让我受益匪浅。https ://sleepingrobots.com/dreams/stop-using-ollama/

jmorgan 11小时前 |根目录|父目录|上一页|下一页 [–]

较大的模型可以在 Ollama 的云端使用，因为大多数人没有运行 500B-1T 参数模型的硬件。

jubilanti 9 小时前 |根目录|父目录|上一页|下一页 [–]

我以为 ollama 的全部意义就在于它不是云？

起初确实如此，但后来开发者们意识到他们拥有庞大的用户群，可以从中获利。这和开源软件的历史一样悠久……

toyg 11小时前 |根目录|父目录|上一页|下一页 [–]

没错，你说得太对了。Ollama 正拼命想复制 Cursor 的成功模式——就像这个领域里的其他 3791 个项目一样。

dominotw 11小时前 |父级|上一页|下一页 [–]

如果我想现在就购买所有硬件，并且考虑到增加的电力成本，整套设备需要多少费用？

sosodev 12小时前 |上一页|下一页 [–]

这个问题的问题在于它涵盖了非常广泛的功能和预期。如果你只会运行一个 8B 的模型，却期望它擅长氛围编码/一次性解决问题，那你肯定会遇到麻烦。

如果你的模型规模能达到约 300 亿，你会发现，在任务范围合理且定义明确的情况下，它们的表现非常出色。目前，我发现 Gemma4-31B 和 Qwen3.6-27B 是这个范围内最好的模型。你可以使用 MoE 模型来加快推理速度，但它们在大多数任务上的表现明显更差。它们可以处理小规模的单次/VIBE 编码任务，但在指导下表现会更好。

如果你真的想要体验前沿科技，你可能至少需要 128GB 的内存，以及强大的计算能力或足够的耐心。大多数人既没有足够的钱，也没有足够的耐心来运行这些本地模型。

本地模型的使用需要的耐心远不止等待令牌那么简单。要让所有组件都针对您的工作流程和硬件进行正确配置和运行，需要花费大量精力。

argee 12小时前 |父级|下一级 [–]

我在我的MacBook（M4 Pro，48GB内存）上使用Gemma 4 26B A4B来学习Rust（以及提出其他各种各样的问题）。我不相信它能在IDE/框架中胜任一次性完成除最细微的更改之外的任何工作。尽管如此，它的速度和性能都足以胜任小型到中型任务的“副驾驶”角色，让你能够专注于驾驶，同时又不超速行驶。考虑到几年前的情况，这确实令人惊叹。

如果不是这样，我想我根本不会用人工智能来编程。（我不想仅仅因为断网就感觉自己停滞不前或束手无策。）

用户43928 8小时前 |父级|上一页|下一页 [–]

我使用较小模型（在本例中特指 GPT 5.4 Mini）的经验是，它们无法在不修改文件并引入错误的情况下，一次性将 10-20 行代码更改移动到另一个文件。

我并不指望它绝对可靠，但我想至少在你指出差异之后，他们第二次就能做对。结果却并非如此，它斩钉截铁地告诉你，现在的代码完全一样了，只是在差异中又加入了一个不易察觉的错误。

我不明白在什么情况下这些垃圾模型才算合格。或许它们能勉强应付几分钟，但最终结果肯定不对。在我看来，它们充其量只适合用于更智能的搜索或自动补全功能。

4小时前 |根|父|下一个 [–]

与其让机器人去做，自己去做岂不是更快？

Kostic 11小时前 |上一页|下一页 [–]

出于个人需要，我将 VSCode 与运行 Qwen 3.6 27B 或 Gemma 4 31B 的 llama.cpp 连接起来，这足以让我取消云订阅。

Qwen 在我的第一块 GPU 上运行，q4@176k 上下文从 70 tok/s 到 50 tok/s，使用 MTP，对于编码来说相当不错。

另一方面，Gemma 同时使用两个 GPU，运行 q8@64k 上下文，进行文档情感分析、摘要生成、校对和翻译，速度稳定在 25 tok/s。速度稍慢，但对于批量工作流程来说足够用了。一旦 llama.cpp 开始支持带有张量分割模式的 MTP，速度可能会更快。

因为我不用自己掏钱，所以现在还在用 Frontier 的 LLM 教材，而且这些教材显然更好。希望一年左右我们就能用上 Sonnet 4.6/Opus 4.5 的 30B 级教材。

编辑：请求处理速度从 800 t/s 开始，逐渐下降到 400 t/s。大多数情况下，我的初始请求包含大约 16k-24k 个 token，需要 60 到 90 秒才能处理完毕。速度不算快，但可以接受。

fitzn 3小时前 |父级|下一级 [–]

你在 VS Code 中使用哪个扩展程序连接到本地的 llama.cpp 文件？还是通过 GitHub Copilot 进行身份验证，然后指向 localhost？或者还有其他方法？

khimaros 2小时前 |根|父|下一个 [–]

我专门为 vscode/llama.cpp 制作了这个：https://github.com/khimaros/mortar

arjie 13小时前 |上一页|下一页 [–]

虽然不是“本地”编码，也不是交互式编码，但分享出来或许有用。我用的是两块 RTX Pro 6000 Blackwell 显卡，运行 DeepSeek V4 Flash。原始速度是 160 tok/s，但这是推理模型。我的应用场景是让它自动生成代码，然后另一个系统自动审查这些代码。

我偶尔会用它和树莓派一起编写一些代码，速度非常快，但让我继续使用 CC 和 Codex 的主要原因还是习惯。

akersten 11小时前 |父级|下一级 [–]

我有两块 RTX Pro 6000 Blackwell 显卡。

你在哪里找到/订购的这些东西？我找到的所有网站要么缺货，要么只卖给企业，要么就是其他方面不太靠谱……

arjie 8小时前 |根|父|下一个 [–]

我经营一家小型企业（https://technologybrother.com），运营一些小型SaaS项目，所以我通过企业销售渠道订购了GPU。如果注册有限责任公司（LLC）是障碍，那么注册费用相对较低。好处是，如果你拥有合法且需要GPU的企业，你可以加入英伟达的Inception Program，享受相当不错的折扣。

zackify 4小时前 |根目录|父目录|上一页|下一页 [–]

Microcenter 是最方便的地方，但几乎所有商家在你发邮件给他们并拥有有限责任公司 (LLC) 后都会卖给你。不过，Microcenter 是购买最便捷的地方，但几乎所有商家在你拥有有限责任公司后都会向你出售商品。

CamperBob2 3小时前 |根目录|父目录|上一页|下一页 [–]

根据我的经验，Central Computer 是一个不错的资源：https://www.centralcomputer.com/all-products/ai-components/a...

我跟他们没有任何关系，只是从他们那里订购过几次东西。

轻子 12 小时前 |父级|上一页|下一页 [–]

你测量过这套设备的耗电量吗？我想知道你一个月要花多少钱。

ux266478 11小时前 |根|父|下一个 [–]

远没有你想象的那么贵。在我住的地方，1.2千瓦的电费大约是每小时0.12美元，而且这还是满负荷运转的情况下。如果你有不错的太阳能发电系统，晴天的话电费就只占很小一部分。

最贵的部分是前期硬件成本和房屋所需的电气系统升级费用。

轻子 5 小时前 |根|父|下一个 [–]

我每小时电费大约 0.19 美元，而我仅仅用了一半的电量，就运行着一个大型机械硬盘 RAID 阵列、一些虚拟机和监控摄像头。电费让我不得不重新考虑一下我的电子产品消费习惯。你可能比我挣得多得多。

mtone 8小时前 |根目录|父目录|上一页|下一页 [–]

以下是使用两块 RTX Pro 6000 显卡进行 DeepSeek-V4-Flash 基准测试的结果：

- Prefill: ~10K tok/s

- Decode: 190 | 375 | 980 tok/s (for 1 | 4 | 16 concurrent requests)

- GPU power draw during benchmark: Average: 585W | Max: 849W | Limit: 1200W with undervolt. Idle PC is 125W.

我要求它根据缓存提示和解码的实际组合，计算以下内容，以适应代理开发场景。

仅电力（每千瓦时 0.08 美元）

Usage | IN price | OUT price | Monthly cost

Concurrency=1 | $0.040/M | $0.080/M | $8.65 to $38.88 (5% to 100% active)

Concurrency=4 | $0.024/M | $0.044/M | up to $48.67 (cheaper per token but higher power draw)

三年总拥有成本为电费 + 2 万美元（涨价前价格）。在实际生产环境中，如果目标是 24/7 全天候 4 个并发请求，我需要向用户收取多少费用才能实现收支平衡？

A) API 盈亏平衡定价（预计每月 20 亿输入 + 10 亿输出吞吐量）：

IN price OUT price

Self-hosted $0.121/M $0.363/M

OpenRouter (budget) $0.098/M $0.196/M

OpenRouter (DeepSeek) $0.140/M $0.280/M

B) 盈亏平衡订阅（用户每天活跃约 1.5 小时）：

1 user: $563/mo (oh, hai)

25 users: $23/mo

100 users: $6/mo

arjie 4小时前 |根|父|下一个 [–]

我赞同你的评论，非常棒！你用的是什么算法才能达到 190 tok/s 的速度？我的算法在 c=4 时能达到 400 tok/s，但 c=1 时速度比你慢。

mtone 1小时前 |根|父|下一个 [–]

我正在使用来自 RTX6K Discord 社区的 `voipmonitor/vllm:lucifer` Docker 镜像，该镜像在其他评论者提供的链接中也有讨论。它基于这个 PR：https://github.com/vllm-project/vllm/pull/43477

CamperBob2 1小时前 |根目录|父目录|上一页|下一页 [–]

我不是原帖作者，但我使用https://github.com/local-inference-lab/rtx6kpro/blob/master/...中的配方，在 c=1 的情况下，用 4 张 6k 显卡，最高能达到 260 个 token/秒的输出速度。平均速度大概在 200 左右。

或许有办法让 2 位量化版本在其中一对机器上运行得更快。

stymaar 11小时前 |上一页|下一页 [–]

是的，Qwen3.6-35B-A3B 安装在 Strix Halo 128GB (Bosgame M5) 上。

我的显卡显存对于这种型号来说绰绰有余，但Qwen从未发布过Qwen3.6的122B版本，而这才是最适合我硬件的型号。不过，我的电费几乎可以忽略不计，这毕竟是笔记本芯片，性能也确实如此，待机时几乎不耗电，即使在高负载运行时也只略高于120瓦。

对我来说，Qwen3.6 的效果出乎意料地好，我仍然偶尔使用 Clause，但只满足我大约 10% 的需求，这使我即使使用最便宜的套餐也能很好地控制在配额之内。

速度：~800tps 提示处理速度和 50tps 令牌生成速度（无推测性解码）。

manmal 11小时前 |父级|下一级 [–]

你试过 27B 密闭版本吗？它更适合编码。

anana_ 11小时前 |根|父|下一个 [–]

可惜的是，在 Strix Halo 或任何类似的统一内存架构下，由于内存带宽太小，运行高密度模型会非常慢……但我同意，27B 的确更胜一筹。

stymaar 10小时前 |根|父|下一个 [–]

没错。所以我很失望没有推出 122B 版本，虽然是 27B 版本，但那是给 Strix Halo 用户用的。

garethsprice 9小时前 |上一页|下一页 [–]

我用的是 OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM，在 Ada 4000（20GB 显存）上生成，速度是 55 tok/秒（比听起来慢，因为 OpenCode 添加了很多上下文信息）。打算有空的时候研究一下 pi，最近经常听到有人提起它。

我使用 Opus 生成计划，然后由本地代理商执行，最后由 Opus 进行验证。因此，我还没有完全实现本地化，但这些模型正日益成为我生产工作流程的一部分。除非你是喜欢花时间和金钱进行折腾的业余爱好者，否则现在可能还不值得这么做。

这套配置当然不如Opus或其他高端车型那么“好”，但对于越来越多的重复性任务来说已经“足够好了”。你没必要开劳斯莱斯去超市，一辆二手卡罗拉就能把你送到目的地。

它还支持一些使用前沿LLM（尤其是代币成本上涨的情况下）成本过高的新工作流程——例如，我晚上会使用Chrome开发者工具的MCP，并设置上述流程，以用户身份进行几个小时的模糊测试，看看它是否会破坏某些功能。我甚至让它支持多模态，可以检查屏幕截图，这真是让我大吃一惊（当然，我的钱包可没遭殃，因为Claude加上屏幕截图可是要烧钱的）。

“落后前沿技术12-18个月”的说法差不多，这跟我当年用GPT-4O和基础硬件时的情况差不多。我估计再过12-18个月，我们就能拥有Opus级别的模型，可以在本地运行，成本低于5000美元……但前沿模型将会发展得更快（除非政府阻挠）。真是令人期待。

jodoherty 10小时前 |上一页|下一页 [–]

我使用树莓派和 RTX Pro 6000 Blackwell 运行 Gemma 4 31b 来进行所有代理编程。

我觉得它很有用。

这个业余项目体现了我目前在工作中规划和处理项目的方式类似：

https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md

https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...

你必须在你的方案中运用大量的精心架构和测试驱动开发（TDD）。通过尽早解决难题并将其封装在一个简单易用的界面中来消除技术风险。

我发现，如果用电脑编写，某些项目的完成速度可以提高 2-3 倍。对于一些枯燥乏味或范围过广的项目，电脑还能帮助我快速整合和尝试各种想法，从而节省 5-10 倍的时间。

设置方面，我会在使用 nvidia/Gemma-4-31B-IT-NVFP4 的 vLLM 和使用 unsloth/gemma-4-31B-it-qat-GGUF 的 llama.cpp 之间切换，并启用 MTP 协议。我将 GPU 功耗限制在 400W。

我目前的 llama.cpp 配置的令牌生成速度在 60-150 个 t/s 之间，具体取决于 MTP 草稿的接受率。预填充速度在 1500-4000 个 t/s 之间，具体取决于上下文的长度/深度。

土豆 55 分钟前 |上一页|下一页 [–]

我有一台内存很大的Mac，但考虑到Deepseek比我本地运行的任何程序（包括Deepseek本身的大量量化版本）都好得多，而且运行成本极低，我甚至觉得电费都太不划算了。它便宜得简直不可思议！

jborak 10小时前 |上一页|下一页 [–]

我使用 4 块 RTX 5070 显卡和第一代 AMD Threadripper (1950X) 处理器，搭配 llama.cpp 运行 Qwen3.6 27B (MTP) Q6_K 版本，作为树莓派的日常主力机运行良好，速度大约在 50-60 toks/秒。我还连接了一些其他应用程序，例如 OpenWeb UI，最近还设置了 Bifrost（一个 LLM 网关），作为我所服务模型的主要接入点。

我尝试过其他模型，例如 Qwen3.6 35B A3B，但发现 27B 模型在编码方面更适合我。虽然它是密集模型，速度较慢，但质量似乎要好得多。在我的系统上，Qwen3.6 35B A3B 的推理速度约为 130-140 toks/秒（非 MTP），这速度简直快得惊人！

运行 Qwen3.6 27B 并不需要 4 个 5070 显卡，三个甚至两个就足够了。不过，我使用了 MTP（多标记预测）来加速 27B，这会占用更多内存，因为草稿模型需要自己的上下文。

另一点需要注意的是，你使用的工具都有各自的系统提示，这些提示会在每次对话时加载到模型中。当我启动 Pi 时，模型启动后运行非常流畅。但当我通过 Hermes CLI 与 LLM 交互时，速度就慢得多。这是因为 Hermes 的每次提示都会将大量信息（技能、工具等）加载到上下文中，并且这些信息会一直保留到对话结束。

我喜欢在家运行模型以保护隐私，而且我也喜欢没有配额限制，不用担心使用量。如果未来是“循环工程”，那么使用云模型将会消耗大量的代币和资金。

我的系统待机功耗约为 200W，推理负载高时约为 350-450W。解码（生成标记）效率并不高，而且在推理过程中，GPU 的空闲时间比你想象的要长。像 Diffuse 这样的技术进步或许可以：1）加快解码速度；2）让你更有效地利用空闲的 GPU 资源。

zakisaad 7小时前 |父级|下一级 [–]

我很好奇——为什么你的四核配置都选择了 5070 显卡？

乍一看，它们相当偏向计算（而不是显存），这对游戏玩家来说很好，但对运行 LLM 来说却不太好。

（我的台式机里用的是5070显卡）

HappySweeney 13小时前 |上一页|下一页 [–]

我配备了傲腾内存和充足的内存，所以尝试运行一些完整的模型来编写一些函数，并通宵测试，因为我的吞吐量大约是 0.7 t/s。我目前常用的测试方法是更新一个标量函数，将一个位矩阵转置为使用 AVX512 编码的矩阵。所有云模型都能轻松应对这种情况。Kimi 2.6 和 GLM 5.1 都彻底失败了。

mgsram 7小时前 |上一页|下一页 [–]

我使用本地 LLM 大约一年了，现在主要在配备 512G 内存的 Mac Studio 上使用 GGUF 的 Qwen3.6 27b 密集模型，并以开源框架和 llmster（LM Studio）作为基础。我也用过 Qwen 3.6 35B-A3B，但密集模型的精度更高，代价是每秒处理次数 (tokens/sec)。使用 Qwen3.6 27b，我通常能达到每秒 25-40 个 tokens。最初我用它们开发一些简单的工具，但最近三四个月，我开始使用 Qwen3.6 27b 进行 C/C++（汽车软件栈）和 Python（工具）的生产级编码工作。

每秒令牌数可能较少，但这反而有助于我保持合适的节奏。对于全新开发/重写项目，我的工作流程是与 Sonnet 配合进行设计/架构、推理和制定详细的执行计划。然后，我根据精确的提示，逐步完善这些内容，这样就能完成工作。对于现有项目，则通常需要根据实际情况做出判断。有时，我发现本地模型的功能有限，这时我就会使用 Claude Code。

我最近使用 Qwen 3.6 完成的一些工作包括：1. 完全用 C 语言重写了电源管理服务，并参考了现有的 C++ 代码；2. 开发了一个工具，用于解析 Excel 格式的复杂规范内容；3 . 开发了一个工具，用于将中日韩内容翻译成英文，以便输入到 KG 系统中。

russelg 5小时前 |父级|下一级 [–]

既然你有 512GB 的存储空间，或许可以考虑运行 deepseek4：https://github.com/antirez/ds4

cuttysnark 12小时前 |上一页|下一页 [–]

我通过在工作流中串联“代理”来构建本地模型，取得了一些成功。每个代理都有不同的提示，并根据其角色使用不同的 Ollama 模型。项目经理、模式代理（qwen3:14b）等使用的模型与编码代理（qwen2.5-coder:7b）使用的模型不同。每个步骤之间都有一个协调器和一个 Playwright 任务，该任务会尝试将错误反馈给引入前一个代码块的代理。只有无错误的代码块才会被转发到下一个工作流步骤。

最大的改进可能是加入了一个后端代理服务定义，该定义指示模式代理只根据任务生成清单，并将其传递给下一个代理。

简而言之，我将任务拆分成许多部分，并定义了一个工作流程，其中每个代理人只能执行非常具体的操作，之后他们的工作才能被传递给下一个人。这既能保证他们的工作内容清晰明了、能力出众，又能让我有机会在工作流程完成度较低（例如25%或90%）时进行干预。

pianopatrick 10 小时前 |父级|下一级 [–]

我希望有人能对这种工作流程进行基准测试和竞赛，这样我们就能弄清楚哪些方法行之有效。

例如：“这里有一块消费级GPU。只使用这块GPU，但无论你使用什么模型和工作流程，看看你在xyz基准测试中能取得怎样的成绩。”

参赛者最多有 1 小时的时间，得分依据是回答问题的百分比、正确问题的百分比以及完成的总时间。

例如“本地人工智能挑战赛”

鼠妇 9 小时前 |父级|上一页|下一页 [–]

你（或其他人）有没有尝试过让智能体之间进行竞争？例如，给两个模型相同的编码任务，或者给同一个模型使用不同的随机种子，然后让评审员选择更好的结果。

有人认为人脑的运作方式类似：数千个微型大脑皮层柱，每个柱对情况都有略微不同的看法，在多数规则制度下进行投票。

wsintra2022 6小时前 |上一页|下一页 [–]

读完这些评论，我实在分不清哪些是人工智能供应商的机器人发的劝阻帖，哪些只是用户对本地人工智能模型的负面体验。在我看来，Qwen 3.6 版本，270亿字节，8000个量化模型，运行在64GB内存的Mac Studio上，这难道不令人难以置信吗？不，它不是Frontier General那种超级垃圾，它只是好用而已。就是这样，它很好用。它是免费的，而且是私有的，它能让一个经验丰富的工程师从懒惰变成真正的懒惰，这就是它的魔力所在。我用llama.cpp和opencode，经常会遇到这样的情况：规划一些代码修改，然后让它运行。之后就可以走开了。在吊床上放松一下，洗洗碗，撸一发，随便干点什么。用tmux和ssh登录进去看看。这就是它不可思议的地方。如果有人跟你说它不好，那就好好想想他们的动机。我跟它没有任何利益关系。我只是喜欢轻松自在地偷懒而已。

epolanski 6小时前 |父级|下一级 [–]

软件“工程”领域充斥着麻省理工学院 LeetCode 高手，他们编写的 React+Tailwind 代码存在内存泄漏，毫无用处，标准极低。

GodelNumbering 10 小时前 |上一页|下一页 [–]

作为一名每天都与LLM（生命周期管理）人员交流的人，我认为OSS（开源软件）前沿模型加上一个好的框架已经足够了。对于本地部署而言，我们还需要一到两代硬件（而且由于硬件公司目前主要面向数据中心市场，短期内可能难以实现），才能完全过渡到本地部署。

我的经验是，目前限制因素不是模型本身，而是笨拙的替代方案，这些方案缺少一些奇怪的功能，导致在队列管理、中断、子代理、目标等方面的人体工程学设计不佳。

coder543 10小时前 |父级|下一级 [–]

我完全同意。

更令人恼火的是，OpenCode 甚至没有尝试正确地支持本地 LLM。

让 OpenCode 运行起来是可能的，但配置起来极其繁琐且需要手动操作。我写了一个脚本来自动将我的 llama-server 配置转换为 OpenCode 配置，这有所帮助，但并非理想之选。

我认真考虑过利用空闲时间写一本《又一个编码工具》（Yet Another Coding Harness）。我有一些想法，可以把它做得更好。

zackify 4小时前 |根|父|下一个 [–]

你一定要试试 pi.dev，它几乎可以满足你的所有需求。我用 Opus 来定制和调整它的部分功能。由于整个系统都是通过 API 驱动的，因此它是目前最好的框架。

wsintra2022 7小时前 |根目录|父目录|上一页|下一页 [–]

我的经历完全不同。我用的是64位Mac Studio，运行Qwen2.7b 8K。只用了十分钟就设置好了，只需要阅读一些文档，Unsloth会一步一步地引导你完成操作。对于Opencode，只需要编辑一个文件就可以了。除了偶尔出现的LLM相关问题之外，我没有遇到任何其他问题。操作起来一点也不繁琐，也不笨重。

horsawlarway 11小时前 |父级|上一页|下一页 [–]

π还不错。

我使用过 claude、cursor 和 pi 的命令行代理，以及我自己不时编写的几个自定义测试框架作为实验（如果把 gastown 也称为测试框架的话，我想从技术上讲也算一个）。

Pi 一切正常。

它满足了我的需求，自带的工具种类齐全，可以很好地与其他工具集成，而且通常不会妨碍我的工作，所以我现在很少想起它了。

如果你能以不错的速度运行约 300 亿个模型，我想大多数人都会惊喜地发现树莓派的功能有多么强大。

添加一些扩展程序（例如https://pi.dev/packages/pi-mcp-adapter?name=mcp和https://pi.dev/packages/pi-web-access?name=search），我就可以获得网络工具（例如 Perplexity 搜索），以及访问 MCP 来执行诸如驱动 Chrome（https://browsermcp.io/）或 Firefox（https://github.com/mozilla/firefox-devtools-mcp）之类的操作。

还不错。它能和补贴后的顶级机型相提并论吗？不能。它是免费的，而且功能也很强大吗？是的。

就我个人而言，我使用树莓派 SDK（ https://pi.dev/docs/latest/sdk）玩得非常开心。

其他所有供应商都会为此收取 API 访问费（例如每月数千美元）。

12小时前疯狂 |父级|上一页|下一页 [–]

听说pi.dev不错，但我还没试过。它或许能解决你提到的那些缺失功能。

bityard 11小时前 |根|父|下一个 [–]

pi.dev 更像是一个代理开发工具包。它本质上是一个底层框架，你可以在上面花费数小时、数天甚至数周的时间来构建自己的代理或编码框架。它就像是 claude 的 vscode 之于 neovim。

horsawlarway 11小时前 |根|父|下一个 [–]

我的意思是——基本体验就很好，内置了非常合理的文件访问和编辑工具，还有 bash。

是的——如果你愿意尝试，它会发展出很多可能性。

我其实觉得拿 Claude 和 VS Code 做比较不太恰当，因为 VS Code 和 Pi 一样，都是“自带扩展”的。而 Claude 则更像 Visual Studio。它界面厚重，设计理念比较固定，几乎无法自定义，但对于支持的工作流程来说，用起来确实很流畅。

cheekygeeky 12小时前 |上一页|下一页 [–]

我们的软件开发人员（我见过的最聪明的人）正在使用 OpenCode 和 Tmux 以及开源模型。他说 DeepSeek 是他编码时的首选模型（他称之为“相当不错”）。他的配置是：一台 i9 处理器，两块 3090 显卡，128GB 内存。https ://www.msn.com/en-us/news/technology/china-s-open-deeps...

pianopatrick 10 小时前 |上一页|下一页 [–]

我希望有人能对这种工作流程进行基准测试和竞赛，这样我们就能弄清楚哪些方法行之有效。

例如：“这里有一块消费级GPU。只使用这块GPU，但无论你使用什么模型和工作流程，看看你在xyz基准测试中能取得怎样的成绩。”

参赛者最多有 1 小时的时间，得分依据是回答问题的百分比、正确问题的百分比以及完成的总时间。

例如“本地人工智能挑战赛”

bravetraveler 10小时前 |上一页|下一页 [–]

我基本上只用“自然”算法，任何少量的LLM（低密度内存模型）使用都仅限于本地。我的128G Strix系统，搭配密度不算很高的Qwen或Gemma变体，可以达到50-80 tok/s的输出。即使Anthropic/OpenAI等平台是最后发布的本地模型（这种情况发生的概率很低），我也不会订阅它们；完全没必要。完全不需要，而且模型内工具的使用也足以满足我的货币需求。

zftnb666 2小时前 |上一页|下一页 [–]

我用DeepSeek V4 Flash通过API替换了Claude。虽然不是本地的，但质量达到了95%，价格却只有5%。差不多了。

jrflo 1小时前 |上一页|下一页 [–]

如果不占用那么多内存的话，我很乐意这么做。而且，如果你不在乎数据保存，那么为了提升质量，每月多花20到100美元也是值得的。

pdyc 1小时前 |上一页|下一页 [–]

是的

辅助工具 - pi+子代理自定义扩展

型号 - qwen3.6 35ba3b q4km

硬件配置：英特尔 Arrow Lake 处理器，配备 32GB 内存

服务器 - llama.cpp vulkan

性能 - 产量 15-18 吨/秒，峰值功率 50-150 吨/秒

计划和任务创建仍然使用 Claude/GPT，但代码没有改动。所有编码工作都是在这个框架下完成的。

这是使用此设置 easyanalytica.com 制作的一个项目示例，其复杂度中等。

CuriousRose 4小时前 |上一页|下一页 [–]

本地人工智能应用（与代码编写无关）中一个同样重要的问题是，如果查询内容的时效性很重要（例如新软件包的功能、文档等），那么要确保框架拥有快速且最新的数据。托管模型在网络搜索方面表现出色，我认为这对输出质量至关重要。

由于硬件限制，我不再使用本地托管模型，但我确实对我的 OpenCode 和 OpenRouter 连接的开放模型附加了一定程度的搜索匿名化。

我的 Macbook 上运行 OrbStack，其中设置了以下 docker 容器，以通过基于 Mullvad 的 gluetun 进行路由。

- Firecrawl - 快速网页抓取

SearchNG - 元搜索

- CloakBrowser - tursile 绕过 Playwright 的替代方案

如果你想让代理轮换更复杂一些，你可以设置多个 Playwright 实例，每个实例在不同的位置使用自己的 Mullvad WireGuard 密钥。

acc_297 12小时前 |上一页|下一页 [–]

最近我一直在想，如果使用一个中等规模的模型，然后在云端或本地环境中，针对每个提示进行基于人类反馈的强化学习（RLHF），会不会有所帮助？我不知道尝试手动微调模型以适应你的使用习惯，是会毁了它还是会有帮助。理想情况下，如果你足够勤奋，就可以去除一些让普通用户难以使用的模型特性，例如过于谄媚、过于冗长、喜欢用类比解释等等。

但也许一个人的及时反馈永远都不够。我不确定你需要多少反馈（我知道一些在大公司工作的人购买了内部代理，这些代理针对内部文件等进行了微调……但显然这些代理最终会出现奇怪的行为，而且不一定比标准模型更有用）。

我希望能够编辑智能体给出的每一个回复，然后根据它实际生成的文本和我编辑后的文本之间的差异进行微调。就我个人而言，我会删除很多形容词，尝试将回复提炼成核心内容。但我担心，根据欧文·埃文斯和其他一些对齐研究人员的研究，这样做有时可能会使智能体产生难以预测的倾向。

htrp 10 小时前 |父级|下一级 [–]

Cursor 正在这样做（我认为他们使用的是 Fireworks 作为服务提供商）。

https://cursor.com/blog/real-time-rl-for-composer

rolisz 12小时前 |父级|上一页|下一页 [–]

我对类似的方法很感兴趣。我打算把它应用到我的 OpenClaw 代理上。

关于欧文·埃文斯的作品：我认为他做了SFT。推特上有人说RL不太容易受到他展示的那些技术的影响。我想试试。

grmnygrmny2 10小时前 |上一页|下一页 [–]

仅分享一下我的看法——我出于伦理原因反对使用 OpenAI 或 Anthropologie 的产品，所以一开始我对本地模型（LLM）并不热衷。本地模型解决了我的大部分（虽然并非全部）伦理顾虑，因此我已将其用于工作和个人项目约一个月了。

我拥有的硬件（32GB Mac 和一台配备 10GB 3080 显卡的游戏 PC）只能让我达到 Qwen3.6-35B-A3B 的各种量化水平，但这已经足够了（200-400 PP，20-30 TG）。

花了不少时间才学会如何充分利用它——有些事情需要一些指导或引导——但它确实非常实用。由于我之前没用过 CC，所以无法比较，但它在从嵌入式 C++ 到 Vue 的各种项目中都是一位出色的助手或结对程序员。我希望自己能运行 27B，因为有时这个模型似乎无法完全理解某些事情，但这种情况非常少见。对于很多任务来说，它能节省大量时间，并且在给定非常模糊的指令时，能够非常有效地挖掘和修复 bug。

我使用树莓派作为我的外设。

henrixd 4小时前 |上一页|下一页 [–]

我一直大量使用 Qwen3.6-27B-UD-Q4_K_XL.gguf 模型和 Pi 代理（https://pi.dev/）进行本地任务和编码。我使用了 llama-cpp-turboquant 分支，并从另一个分支中挑选了一些自定义的 MTP 补丁。

我在 V100 32GB（~900GB/s 内存带宽）上运行此程序，上下文窗口为 200,000，--spec-type mpt --spec-draft-n-max 3 --spec-draft-n-min 0 --cache-type-k turbo3 --cache-type-v turbo3 仅列举最相关的部分。

我通常能达到 45-60 t/s 的速度。我相信切换到 ik_llama.cpp 分支和 Qwen3.6-27B-IQ4_NL.gguf 模型可以稍微提高速度，但是它不支持 Turbo Quant，而且还有其他一些缺点。

nfrankel 12小时前 |上一页|下一页 [–]

我试过了。理论上可行：https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...

当然，结果取决于模型，也取决于你的电脑配置。可惜我的电脑性能不够。

Kobalt 12小时前 |上一页|下一页 [–]

用 qwen 3.6 27b 密集型诗歌写出来的效果相当不错。我觉得它和（克劳德）俳句 4.5 差不多，或许和十四行诗也差不多，具体还要看任务要求。

kadoban 12小时前 |父级|下一级 [–]

出于好奇，你用什么工具来处理事情？

Kobalt 2小时前 |根|父|下一个 [–]

我使用的是Claude代码。你可以把它用在任何你想要的模型上。

kandros 12小时前 |父级|上一页|下一页 [–]

我宁愿去问肉铺老板编程任务，也不愿去问俳句。

Kobalt 2小时前 |根|父|下一个 [–]

我觉得Qwen运行起来就像十四行诗一样优美，运行失败时就像俳句一样令人失望。所以它不太稳定，但总体来说还不错，对吧？它在很多方面仍然非常有用，而且我可以直接在我的MacBook上运行它。一旦你了解了它的能力范围，就能很容易地将任务分解成它能够可靠且优雅地处理的小块。但我仍然喜欢参考SOTA模型。此外，你还可以让SOTA模型编写一个开发计划，这个计划基本上就是一系列提示，用于生成每个部分，然后让本地模型按照这个计划执行。

我应该提一下，不要低于 q6 运行，我更喜欢 q8。

papichulo4 11小时前 |根目录|父目录|上一页|下一页 [–]

同意。Anthropic 现在修改了 `/model` 目录下模型定义的措辞，说明 Opus 用于日常使用，而 Sonnet 用于常规任务。

显然，十四行诗和俳句之所以保留在之前的版本编号中是有原因的。

不过，令人鼓舞的是，情况正在迎头赶上。我们不能指望2万美元的本地部署方案能与200亿美元的计算集群相媲美。

_bobm 8小时前 |上一页|下一页 [–]

但是，各位，当你们提到 Claude/GPT 模型时，你们有没有想过这些“模型”到底是什么？

有一天，我在想GPT如何才能让思考过程逐一发送，并在发送的开头加上对每个思考过程的Markdown摘要。仔细想想吧。

事实上，请思考这些操作、API 端点，并观察它们的输出。

这些所谓的SOTA模型并非表面看起来那样，其基础设施与本地模型根本无法相提并论。由于这些项目的规模庞大，需要进行极其复杂的协调工作。但正是这些严峻的限制催生了创新，一种无人提及的创新。

我不会说我们无法迎头赶上，但通过 llama 和 vllm 服务本地模型只是整个过程的第一步。实际上，我认为真正需要的是我上面提到的那种流程的复制。

目前最先进的模型是由多个模型深度协同运作而成，并非单一模型。因此，任何单一模型都无法赶上它们，除非它首先通过训练来复制这种协同运作，然后或许再通过模型架构的改进来实现。

最后，我敢打赌，作为这种编排设置中的模型之一，SOTA“模型”作为通用模型，其功能并不比qwen 3.6强大多少。

我相信，如果你改变一下视角，你就会开始注意到“魔法”的规模。

JSR_FDED 45分钟前 |父级|下一级 [–]

这一切听起来都很神秘。

_bobm 12分钟前 |根|父|下一个 [–]

是的，但事实并非如此。

XCSme 7小时前 |父级|上一页|下一页 [–]

SOTA模型是多个模型协同运作的深度协调，它并非单一模式。

我不明白，为什么你会觉得情况就是这样？

GPT 如何才能让思考过程逐一发送，并在发送的开头附上思考过程的 Markdown 标题摘要？

你能举个例子吗？

_bobm 7小时前 |根|父|下一个 [–]

你能举个例子吗？

当然可以，将 OpenCode 连接到 OpenAI/ChatGP 端点即可使用。你会注意到每个“回合”都有多个“思考”部分。

我把这些都用引号括起来，因为……它们都是精心策划的一部分。例如，我们无法确定某个回合中所谓的思考部分究竟是思路总结，还是仅仅是伪装成思考的简单回应。

进一步注意语调、用词和句式。注意句子结构。注意“思考部分”的结构和顺序。

配乐相当复杂。

我不明白，为什么你会觉得情况就是这样？

因为并非所有代币都一样。如果你把昂贵的代币浪费在琐碎的任务上，你就会破产。这就是原因。

正如我所说，如果你观察这些 API 端点的输出，你就会注意到这一点。

XCSme 6小时前 |根|父|下一个 [–]

你会注意到每个“回合”都有多个“思考”环节。

我原以为那只是代码框架对输出进行了压缩。现在很多模型不再返回完整的逻辑推理过程（为了避免蒸馏攻击）。所以，没错，我们得不到原始的逻辑推理过程输出，但我认为它只是逻辑推理的总结，而不是复杂的流程编排或不同的模型。

不过我同意，现在的云模型确实有点像个黑匣子，不仅晦涩难懂，而且还会随着时间推移而变化。一些公司似乎会在不通知用户的情况下更改模型功能，甚至暗地里提供完全不同的模型。通过 OpenRouter 实现的情况更糟，一些提供商提供的是开源模型，其中一些提供的是高度量化的版本，甚至是完全不同的模型。

_bobm 6小时前 |根|父|下一个 [–]

我不太清楚“压缩输出”在我们讨论的语境下具体指的是什么。Opencode 是开源的，你可以自己去了解它的具体功能。

我上次查看时，OpenAI 甚至在回复中已经以 Markdown 格式发送了思考部分的摘要，因此 OpenCode 必须删除格式以使其符合他们的喜好。

现在很多模型不再返回完整的思路链（以避免蒸馏攻击）。

他们说，这样做是为了避免蒸馏攻击。在某种程度上，这确实没错。我的意思是，这会产生一个副作用，而这个副作用（取决于你愿意往哪个方向想）可能是一件好事，也可能是这一切的“主要原因”。

其副作用是拼接推理过程、代理请求等等，这在规模化应用中带来了巨大的好处。

这就是我最初的观点：开放式模型和SOTA模型就像苹果和橘子一样无法直接比较。那么，本地模型什么时候才能赶上它那连形状都不合适的单人床架呢？答案是：永远不会。

这完全是两码事。

XCSme 5小时前 |根|父|下一个 [–]

所以，您的意思是说，本地模型可能比我们想象的要好？因为通过一些额外的协调/处理，我们可以改进结果？

_bobm 5小时前 |根|父|下一个 [–]

是的，本地化模式已经具备了所有必要的条件，它们拥有所有先决条件。

但他们缺乏的是正确的方向和方法。这种缺失体现在多个层面：COT（成本运营时间）、输出结果、模型基础设施以及模型编排等方面。

这是anthropic一年前说的话：

最后，我们为 Claude 4 模型引入了思维概要功能，该功能使用更小的模型来精简冗长的思维过程。这种概要功能仅在约 5% 的情况下需要——大多数思维过程都足够简短，可以完整显示。需要原始思维链以进行高级提示工程的用户，可以联系销售部门了解我们全新的开发者模式，以保留完整访问权限。

3abiton 5小时前 |上一页|下一页 [–]

我想几乎每个人都提到了 Qwen，那轮到我了。我的配置是 Qwen 3.6 35B Q8 (MTP)，运行在 Strix Halo 主板上，使用 llama.cpp 库。处理速度大约在 40-50 t/s 左右。性能真的非常出色，它的能力总是让我感到惊讶。我直接在 zsh 中使用 forge-code。长时间处理超过 150k 的上下文时，它的性能会开始下降，甚至出现错误。

ozten 2小时前 |上一页|下一页 [–]

是的，对于注重隐私和安全的客户项目，但不适用于企业合同：

针对 Infomaniak 托管的开源软件模型的开源代码：Qwen3.5-122B-A10B-FP8、Kimi-K2.6。

我使用 API 密钥进行计费。就我当时的生产力而言，它的表现就像 2025 年 12 月一样。

mitchell_h 12小时前 |上一页|下一页 [–]

试过了。上下文窗口不够大。

coder543 10小时前 |父级|下一级 [–]

Qwen3.6-27B 支持 100 万个令牌的上下文窗口。

当然，要运行这样的上下文窗口，你必须拥有合适的硬件，因为在我的 DGX Spark 上，使用 q4_k_xl 型号的完整 f16 KV 缓存来运行它需要大约 100GB 的内存。

利萨斯 12 小时前 |父级|上一页|下一页 [–]

我的结果也差不多（我的 RTX 4070 只有 12GB 显存）。我很好奇 24/32GB 显存能否显著提升性能，使其具有实际应用价值。

tobyhinloopen 11小时前 |根|父|下一个 [–]

分别在内存和CPU上进行测试。

虽然速度慢，但还是可以运行的。

lysace 11小时前 |根|父|下一个 [–]

评估模型的好主意，谢谢。

deadbabe 12小时前 |父级|上一页|下一页 [–]

提问要更直接，不要使用开放式问题。

carlossouza 2小时前 |上一页|下一页 [–]

这应该是一个每月都会提出的重复性问题。

moezd 10小时前 |上一页|下一页 [–]

还没到那一步。如果没有苹果原生的游戏机制或性能不错的GPU，即使拥有大量的内存和线程，你也只能获得大约每秒30-50个令牌，而且这还是在关闭所有逻辑思维的情况下。如果没有这些优化，你的模型会因为MCP（模型控制点）、技能和代理描述而疲于奔命，你可能要等到油漆干透才能看到第一个输出令牌。本地模型服务意味着你必须在上下文窗口中争夺每一个令牌，这与Claude/GPT/Copilot等产品所倡导的行业发展方向截然相反。

amarshall 7小时前 |父级|下一级 [–]

思考并不会改变输出速度。Anthropic 的模型平均输出速度约为 40–60 吨/秒。

heisenbit 8小时前 |上一页|下一页 [–]

我觉得配置起来确实挺费劲，不过在这个过程中我也学到了很多东西。我主要用的是 qwen/qwen3.6-35b-a3b mlx 镜像，搭配我的 48GB M4 MacBook Pro，刚好够用，可以运行 Docker 开发容器和其他一些基本程序。我用 LM Studio 来运行，并通过 VSCode 来操作。系统提示改进了工具集成（我为此咨询了 GPT），效果显著。之前它不会进行任何修改，而是不断地重新生成代码，结果往往适得其反。

为了避免噪音和发热，即使插着电源，我的MacBook Pro也大多使用低功耗模式。全功率模式或许能让速度提升一倍，但功耗也会大幅增加。

它的功能：简单的页面重构。它和其他模型的不足之处：拆分 Pinia 商店，而 GPT-5.4 可以轻松做到。我认为，通过更多优化、工具使用指南以及一些配套支持工具，其性能可以进一步提升。

thesuperbigfrog 3小时前 |上一页|下一页 [–]

这里有一个效果不错的方案：

https://discourse.ubuntu.com/t/use-workshop-to-run-opencode-...

bijowo1676 10小时前 |上一页|下一页 [–]

我见过一种很有意思的方案，就是使用昂贵的 Frontier 模型来编写和更新应用程序的 Markdown 文档，例如规格说明、产品需求、架构等等。

但随后使用廉价/本地模型来实现规范。

Markdown 比数百个源代码文件更能有效地压缩信息，并且更容易适应上下文窗口。

但这需要进行第二遍和第三遍打磨，才能使粗糙的边缘变得平滑。

有人试过吗？

milchek 7小时前 |上一页|下一页 [–]

我试过用36GB的MacBook Pro，但除了做一些非常基础的工作之外，效果并不理想。对我来说，问题在于即使是小内存版本，上下文也很快就会耗尽，而且运行速度也比较慢。要想获得像样的性能，我想你需要128GB的内存，这意味着要在硬件上投入更多资金。到那时，问题就变成了：你是愿意订阅使用高端机型，还是把钱花在自己组装设备上？当然，对于那些注重隐私的用户来说，唯一的选择就是花钱购买更高端的机器。

毒素 6 小时前 |上一页|下一页 [–]

我没有。我们在工作项目中使用 OpenSpec，目的是在不花费太多钱的情况下模拟本地设备。我使用托管的模型，并用最新的热门本地模型支付费用。

大多数小型局部模型无法正确调用工具，但较大的模型现在已经能够正确调用工具了。

本地环境忽略的一点是，大多数高效的工程师都会同时运行多个带有 Git 工作树的命令行聊天窗口。我通常会同时运行大约 3 个工作树和多个命令行聊天窗口。

SupLockDef 10 小时前 |上一页|下一页 [–]

本地开发对我来说并不陌生。我仍然在编写代码，但是 Qwen3-coder:30b 在我那台配备 GTX 1070 显卡和 16GB 内存的老电脑上运行起来非常流畅。

我主要把它当作谷歌搜索工具，用来查找忘记的信息或编写一些样板代码。

我混合使用了非 Harness 聊天工具来提高回复速度，并使用 opencode / vim-ai 来编写样板代码。

每月预算为 0 美元。

jboss10 8小时前 |父级|下一级 [–]

你试过 qwen3.6 或 pi 吗？

SupLockDef 7小时前 |根|父|下一个 [–]

由于某些原因，3.6 在我的旧电脑上运行速度太慢，所以我又换回了 qwen3-coder。

我确实在我的主力台式机上试用了 3.6 版本。感觉不错，但和 Coder 版本相比并没有太大区别，所以我仍然在使用我的旧电脑。

jderekw 7小时前 |上一页|下一页 [–]

我日常使用的平台是 AMD Lemonade，最初用的是 Ollama，后来换成了 LMStudio，现在统一使用 AMD Lemonade，它能很好地监控内存、CPU、GPU 和显存。Lemonade 的多模型功能让运行 LLM、语音转文本、NPU 和图像生成等应用栈变得非常简单。该平台也兼容 Nvidia、Apple、Intel 和 AMD 的芯片组。

v3ss0n 4小时前 |上一页|下一页 [–]

是的，Qwen 3.5 122b+ dgx 运行效果非常好，我现在不再订阅任何云 API 了。我会发布一个我在运行 Long Horizons 9 天后完成的项目。

anubhav200 11小时前 |上一页|下一页 [–]

是的，llama.cpp、qwen27b、35b、claude 的代码。Llama-cpp-manager 用于管理 llama.cpp 配置（https://github.com/anubhavgupta/llama-cpp-manager）。

anubhavgupta 1小时前 |父级|下一级 [–]

机器配置：CPU：Intel 275HX；GPU：Nvidia 5090 Mobile（24GB）；内存：64GB

anubhavgupta 1小时前 |根|父|下一个 [–]

还有一点，我还把它和 Whisper-NPU 一起使用，Whisper-NPU 是一款语音转文本实用程序，它在 Intel 275hx 的 NPU 上运行，不占用任何 GPU 资源。

anubhavgupta 1小时前 |根|父|下一个 [–]

Whisper-NPU（https://github.com/anubhavgupta/whisper-npu）

BiraIgnacio 11小时前 |上一页|下一页 [–]

我尝试了一段时间，使用 llama.cpp + Qwen + Mac Pro，但结果非常差（质量和速度都很差）。

我考虑过投资更好的硬件，但算了一下，对我来说购买 DeepSeek 更划算（是的，我知道不是每个人都能做到这一点）。

sj_tech 6小时前 |上一页|下一页 [–]

我使用 Qwen 3.6 35B A3B 进行智能编程，并配合 GitHub Copilot VSCode 扩展。硬件配置是 128GB 的 Mac Mini。对于这个尺寸的机型来说，这似乎还算合理，但我注意到当问题过于庞大时会出现循环问题。你可以用它来处理一些你熟悉的操作（这样可以节省时间）。

zaptheimpaler 11 小时前 |上一页|下一页 [–]

我尝试在配置相对较低的电脑（16GB 显存 + 32GB 内存）上运行 gemma-4-26B-A4B，看看它能否帮我读取/整理邮件，结果不太理想。这个模型光是搜索合适的工具就消耗了 24K 个令牌，然后把邮件内容直接导入到上下文中。我尝试用代码模式保存上下文，但是代码模式无法保存文件，所以没用。我打算切换到 SSH 模式连接到我的开发容器。我对这方面还不太熟悉，所以可能哪里操作错了。

Rzor 1小时前 |父级|下一级 [–]

Gemma 4 在工具调用方面存在一个问题，谷歌似乎在两三天前修复了这个问题。我记得看过相关的报道。

anana_ 11小时前 |父级|上一页|下一页 [–]

或许可以试试其他型号？根据我的经验，Gemma 31B 型号以下的机床调用刀具的频率似乎不够高。

一些基准测试结果似乎也支持这一观点[0]

当然，很多因素取决于你如何使用它（推理参数、工具、提示等），但模型本身也非常重要。

[0]: https://artificialanalysis.ai/models/open-source/small?model...

NetOpWibby 11小时前 |上一页|下一页 [–]

我期待着把克劳德·费布尔带回家。到那时我才会考虑换掉克劳德（谁知道他们的下一代产品会是什么样子，费布尔在我拥有的三天里表现非常出色）。

trueno 11小时前 |父级|下一级 [–]

我们不断提高对“本地化”的满意度标准。一开始是在家使用 Sonnet 就足够了，然后是 Opus，现在又变成了神秘的领先模型，而这个模型运行在基础设施上，我们根本无法在家实现。

无聊 11 小时前 |上一页|下一页 [–]

人工智能实验室是否会始终确保至少有一年的差异化？我猜想其背后的商业前提是，每次新版本发布都会带来阶跃式变化，从而防止此类行为的发生。

snoman 7小时前 |父级|下一级 [–]

如果政府从今以后要限制对前沿机型的获取，即使新发布的机型是阶跃式变化……但实际上并非如此……那么它可能更接近于订阅模式所能提供的服务。

dabinat 12小时前 |上一页|下一页 [–]

有证据表明，模型融合可以达到前沿级别的性能（例如 OpenRouter Fusion）。我想知道这是否是更现实的选择：将 Opus 与本地模型结合使用，以节省令牌成本。

rvnx 10小时前 |父级|下一级 [–]

我开始相信，不断增加思考代币才是有效的捷径（这就是《神鬼寓言》的由来）。

ndom91 10小时前 |上一页|下一页 [–]

虽然不是百分百，日常工作中我仍然主要用 Claude。但我一直在尽可能地在我的框架桌面主板（Strix Halo）上使用 Qwen 3.6 和 Gemma 4。

我一直在开发一款用于本地LLM推理的运维工具。它包含了代理、API密钥、请求日志记录、模型重写等等诸多功能。

https://github.com/ndom91/llama-dash

tumetab1 13小时前 |上一页|下一页 [–]

还没有，我在苹果 M4 上试用了 Gemma 4，但是每秒传输数比云端版本低得多。

此外，缺乏企业级工具来帮助选择合适的模型，以及缺乏工具来运行本地LLM，这都无济于事。

bArray 10 小时前 |上一页|下一页 [–]

我正在基于 LiquidAI/LFM2.5-1.2B-Instruct [1] 构建自己的程序。我在本地 CPU 上运行它，性能尚可。目前我用它来解决一些小问题，但每天都在扩展它的功能。

[1] https://huggingface.co/LiquidAI/LFM2.5-1.2B-Instruct

derekered 8 小时前 |上一页|下一页 [–]

我用的是配备 48GB 内存的 MacBook Pro M5，上面装的是 Qwen 3.6 版本，专门用来处理那些我特别注重隐私的工作，比如写日记。效果很棒！虽然我没有直接的对比数据，但对目前的结果很满意。

russelg 4小时前 |父级|下一级 [–]

我的配置跟你一样，你用的是27B还是35B-A3B？我发现27B慢得根本没法用（大概10-15吨/秒，更别提预灌料时间了）。

drnick1 6小时前 |上一页|下一页 [–]

- 您认为目前最适合在高端消费级GPU上运行的编程模型是什么？（假设可以使用RTX 3090/4090。）

您推荐使用哪种技术栈？Llama.cpp + OpenCode？

anonymousiam 12小时前 |上一页|下一页 [–]

这条帖子是在你发帖询问HN之后不久发布的：

我的家庭实验室人工智能开发平台

https://news.ycombinator.com/item?id=48542433

ryandrake 12小时前 |上一页|下一页 [–]

这类帖子里的细节总是让我有点失望。即使有人回复，也总是不够具体，无法自己尝试。比如“我用的是 Qwen 3.5，效果很棒！” 好吧，但是你用的是什么量化版本？Llama 参数是多少？上下文大小是多少？你用的是哪款 GPU，显存大小是多少？你是把它部署在单独的服务器上，还是直接运行在本地开发机上？你用的是什么编码代理工具，它是如何配置/连接到模型的？

riazrizvi 11小时前 |父级|下一级 [–]

如果你已经知道怎么做，这里最多也就是从一两个帖子中获取一些市场信号。大部分回复都是垃圾。

猪里脊肉 11 小时前 |父级|上一页|下一页 [还有 2 页]

codelion 3小时前 |上一页|下一页 [–]

在本地使用 qwen3.6 27b 和 Claude 代码，对于简单的编码任务运行良好。

xhinker2 10小时前 |上一页|下一页 [–]

是的，我有。1. 两块 RTX 3090 显卡，运行 Linux 22.04 系统。2. 运行 Qwen3.6-27B Q6_K_XL GGUF 固件。3. 使用我自己搭建的 AZPal 线束，并连接了 Hermes Agent，运行良好。4. 很多时候，它解决了 Codex 无法解决的问题。

https://medium.com/p/f237d575e861

mv4 11小时前 |上一页|下一页 [–]

我一直在我的双 Nvidia Spark 集群上使用 MiniMax M2.7 和 vllm。速度很慢（<20 tps），但对于我的大多数使用场景来说都够用了。

cmrdporcupine 3小时前 |父级|下一级 [–]

我刚才查了一下，应该可以在我的单个 Spark 实例上用 3 位量化运行这个程序吧？也许可以？取决于上下文大小？假设 3 位量化不会完全破坏程序的性能。

whartung 10 小时前 |上一页|下一页 [–]

苹果即将发布的 M5 处理器能否从根本上改变这种局面？

我正等着把我的上一代英特尔 iMac 换成新款的 M5 mini，希望能在本地运行一些测试程序。我设想，随着这个领域的发展，未来可能会出现一场小型（呵呵）军备竞赛，大家每年都会用 M(X-1) 换 M(X)。

devmor 58分钟前 |上一页|下一页 [–]

我觉得这东西用处不大。克劳德的速度已经慢得几乎无法胜任任何严肃的任务了，除了繁琐的底层工作之外，如果不进行并行处理，我根本不会考虑用它。

它之所以经济实惠，唯一的原因是如果你不支付 API 费用，它就能享受大幅折扣。

627467 9小时前 |上一页|下一页 [–]

所以，每个人的情况都不一样，但是运行这些本地模型到底有多“免费”呢？就像在橱柜里放一台耗电量巨大的机器一直开着一样？

这样会对硬件造成多大的损耗？

此外，如果隐私是运行本地模型的主要原因，为什么不使用 venice.ai 或类似的服务呢？

Lwerewolf 12小时前 |上一页|下一页 [–]

mbp16 m5 最大 128gb，防呆/DS4，deepseekv4-flash。适用于相对密集（例如每个项目少于 2 万行代码）的 C 代码库，这些代码库本质上是一系列定制的专用存储、HTTP 服务器、网络基础设施、媒体转换器等。

通过 Pi 运行，带有自定义提示（基本上是“不要盲目猜测，隔离事物，使它们可追踪和可测量，然后验证”），并且位于一个相当严格的 bwrap 设置之后 - 除了 ~/.pi、cdw 和单独的 tmpfs 之外的所有内容都只读绑定，除了网络之外的几乎所有内容都取消共享 - 对于网络，我使用一个网络命名空间，该命名空间只允许到特定 IP 和端口（即推断 MAC）的 TCP 连接 - 即 netns exec 进入 bwrap。

就我目前的工作而言，我无法将它与最先进的（SOTA）或更高要求的模型相提并论——毕竟这是政策层面的。话虽如此，在一系列测试用例中——它显然不是 gpt-5.5，也肯定落后于 k2.6/glm/ds4-pro，但它绝对可用。当然，在这样的代码库中，别指望能一次性完成任务或盲目信任它——你需要询问它、引导它，时不时地重启上下文以“重新掷骰子”，并保持上下文的简洁等等。与任何更小的模型（包括所有常见的本地 qwen 模型）相比——在一个测试用例中，它能够识别出 memfd 和 mmap 用于设置具有自然循环处理的环形缓冲区（在末尾对第一页进行双重映射），而不会告诉我“这是为了在进程间共享内存”或其他一些无稽之谈。

性能如本文档中的表格所示： https://github.com/antirez/ds4 ……在“低功耗”（30瓦）下性能略低于一半。两者都可用。

julianlam 6小时前 |上一页|下一页 [–]

当然。

Qwen 3.6 35B-A3B 运行于 Framework 13 系统，配备 32GB 内存。

运行 llama.cpp，每秒处理 15 个词元。输出代码和文本的速度比我解析的速度快。

qu0b 8小时前 |上一页|下一页 [–]

我在两块 RTX 6000 Pro 显卡上使用 DeepSeek V4，效果非常好。Opus 速度太慢，所以我让 DeepSeek 完成大部分工作，Opus 只用于验证和辅助规划。

我还没试过，但我刚买了一台 128GB 内存、M5 Max 40 核的笔记本电脑，希望它能胜任（如果不行，这台笔记本电脑本身也不错，我其实需要那么多内存来处理一些非 LLM 相关的事情）。

kristianpaul 9小时前 |上一页|下一页 [–]

Qwen3.6 35B 在技嘉 aitop（Spark 克隆版）上，但请非常具体地说明您的问题以及应该如何解决。

Nemotron super 3 110B 在 1M 上下文长时间振动编码会话中表现良好

我也使用没有延长线的树莓派线束。

jmward01 11小时前 |上一页|下一页 [–]

有没有人保存过自己的 CC 会话数据，以便将来用于训练自己的模型？我很想构建一个能够基于 CC 会话进行微调的系统，而良好的 CC 会话记录是第一步。

abidlabs 10小时前 |父级|下一级 [–]

是的！https://huggingface.co/changelog/agent-trace-viewer

jmward01 10小时前 |根|父|下一个 [–]

我之前没注意到他们这么做。我一直避免向 Hugging Face 上传数据。这些都是非常私人的信息，而且我还没仔细看过他们的隐私政策之类的。我这就去看看。

shironnnn_ 10小时前 |上一页|下一页 [–]

我使用 SpecKit，通过付费的 Claude 方案，创建了一个非常详细且具有高度针对性的计划。

然后我通过命令行界面（CLI）将其传递给本地 LLM（例如：Qwen / Gemma 4）。这可以通过在 Mac 上使用 llm-mlx（或在任何硬件配置足够的机器上使用 ollama）来实现，它们提供与 Aider（CLI）或 Visual Studio Code 兼容的 OpenAPI 端点，以便与智能编码助手协同工作。

付费产品虽然有优势，但如果您不介意更多地参与到过程中，并且期望值不高，那么付费产品就不是必需的。

mark_l_watson 10 小时前 |上一页|下一页 [–]

我想说我完全在本地运行程序，但实际上我每周会累计使用 Opus 和 Gemini Pro 3 到 4 个小时。我也喜欢用 DeepSeek v4 闪存配合 OpenCode 来处理一些小型快速任务。

我刚刚出版了一本免费在线书籍《本地编码代理的崛起》[1]，书中记录了我使用并乐于使用的配置。我使用 little-coder（基于树莓派构建），在小型 Python 和 TypeScript 应用程序方面效果很好。但在 Common Lisp 和 Clojure 方面，我却难以获得理想的结果。

对我来说，所有本地 LLM 基础编码代理的问题都是运行速度慢。

[1] https://leanpub.com/read/local-coding-agents

ecshafer 12小时前 |上一页|下一页 [–]

我使用一些托管在服务器上的模型，不是本地的，而是用 Ollama 自托管的。这些模型包括 gemma-4、glm 4.7 flash 和 qwen 3.6。glm 在智能编码方面表现最佳。但我仍然认为它们都达不到 GPT 5.5 或 Opus 4.8 的水平。

wuschel 12小时前 |上一页|下一页 [–]

我想知道是否有人能够使用低端型号进行编码以外的活动，例如使用功能有限的个人笔记管理器——以及这些型号的内存硬件要求是什么。

anuramat 9小时前 |上一页|下一页 [–]

我想知道大家都在使用哪些编程语言；我猜小型模型在 bash/python 方面表现应该不错，但在 rust 之类的语言上就差很多了。

47 12小时前 |上一页|下一页 [–]

我所有个人项目都使用本地的 Pi 和 Qwen 3.6 27b 系统，显卡是 4090。日常工作我仍然使用 Claude，因为公司付费，而且我的雇主也要求我使用它。除此之外，我很少用到它。

redox99 11小时前 |上一页|下一页 [–]

那些可以在家运行的模型（比如 Qwen 35B）与 Opus 或 GPT 5.5 根本无法相提并论。差距非常大。唯一能与之媲美的开源模型参数量都在 1T 左右，所以别指望在家就能运行。

这就像开一辆破车。它通常能把你从A点送到B点，有些人还会试图说服你这没什么大不了的。但事实并非如此。

除了绝对需要保护隐私、纯粹出于娱乐目的，或者像飞机上这样的特殊应用场景之外，没有其他合乎逻辑的理由。如果你觉得 Codex 的 20 美元补贴太高，你完全可以试试用中国产的 API，它们的性能远超这些小型模型。

pbasista 10小时前 |父级|下一级 [–]

> 你可以在家运行的模型（例如 Qwen 35B）与 Opus 或 GPT 5.5 相差甚远。

这种描述是基于某些客观事实或标准吗？

kube-system 10 小时前 |根|父|下一个 [–]

是的，目前没有任何一款35B模型能在几乎任何方面胜过前沿模型。

redox99 10小时前 |根目录|父目录|上一页|下一页 [–]

根据我运行的 OpenRouter 的私人测试提示。

xgulfie 9小时前 |父级|上一页|下一页 [–]

我不需要开法拉利去上班

orangeisthe 8 小时前 |根|父|下一个 [–]

但你需要最好的工具才能完成这项工作。

cayley_graph 5小时前 |根|父|下一个 [–]

你需要合适的工具，才能经济高效地完成工作，兼顾成本和质量。这就是“最佳”的含义。我们不会给每位工程师提供所有资源，只会提供最合适的。

我怀疑很多人会意识到，为了实现最高的边际生产力提升，实际花费的资金比所需资金多出数百万美元，并会据此重新分配资金。谁愿意把更多的钱花在开发人员工具上，而不是奖金上呢？

orangeisthe 13分钟前 |根|父|下一个 [–]

当然。我订阅了 Codex，每月 20 美元，一直用得很好。偶尔流量用完的时候，我会切换到另一个备用的每月 20 美元的订阅服务。

这比目前任何自托管模型都更经济实惠，而且效果也好得多。

hegdeezy 11小时前 |上一页|下一页 [–]

我在本地试过了，但考虑到我住的地方电费很高，我觉得大概一年左右才能收回成本。不太划算，不过也许以后搬家以后会考虑吧！

agentbc9000 7小时前 |上一页|下一页 [–]

Kimi K2.7 非常好——我一直在测试它，它真的非常好，达到了 Fable 5 的水平。

bentt 7小时前 |父级|下一级 [–]

多说点！

_davide_ 12小时前 |上一页|下一页 [–]

我以前在我的 Strix Halo 上混合使用远程和本地的 minimax 2.7(q3) 算法，它以 30 tg 和 220 tokens pp 的速率运行……速度有点慢，但能离线运行的感觉真好。可惜的是，M3 算法的参数量达到了 Opus .8 的水平，高达 460 字节，甚至连 128GB 的内存都装不下，更别提运行大型上下文了。Strix Halo 感觉就像个 AI 玩具。https ://kyuz0.github.io/amd-strix-halo-toolboxes/

sosodev 12小时前 |父级|下一级 [–]

我的Strix Halo开发板最近性能大幅提升，不再像玩具了。这得益于MTP、更优的量化以及整个技术栈的整体性能改进。例如，我可以用大约30tg和200pp的精度运行Unsloth的Gemma4-31B 4位QAT模型。我觉得速度完全可以接受，尤其因为它的精度接近满格，足以应对我运行的各种任务。

我觉得用这台机器做家庭服务器的工作也很有帮助。它在所有传统工作负载方面都表现出色。然后我还可以借助人工智能来辅助处理一些自动化任务。我对此感到非常满意。

_davide_ 10 小时前 |根|父|下一个 [–]

你当然可以用它来处理一些工作负载，但一旦涉及到大型代码库的复杂性，运行时间就会变得极其漫长，而且经济效益也差得离谱，电费都快赶上订阅费了。我很喜欢它能让我以防万一某个陌生人突然断线，还能让我安心地在本地运行程序，而且它还能提供 100% 的私有推理，但要说它能成为我日常工作的主要驱动力？我真想一枪崩了自己。

catapart 8 小时前 |上一页|下一页 [–]

这个问题有点棘手，但既然说到这儿了：有没有人用 16GB 显存做过类似的事情？我一直在用 LM Studio 完成项目，但它的效率肯定还有提升空间。在尝试让模型理解如此少的标记问题时，浪费了很多时间。

Rzor 1小时前 |父级|下一级 [–]

我用的是RX 9060 XT 16GB显卡，配置是google/gemma-4-26b-a4b-qat，软件是LM Studio。上下文65k，GPU上23层，CPU上7层，模型在内存中，使用了内存映射。我的计算速度是23-33 tks。三天前开始尝试（用的是gemma-4-e4b），虽然我不太明白这些设置的具体含义，但即使量化之后，26B的渲染速度在几个小项目中也明显提升了不少（“用bash脚本里的ffmpeg创建一个图像转换器”、“创建一个带有真实物理效果的canvas动画，不使用任何库”[1]）。

速度比我阅读的速度快，但感觉慢得要命。我觉得 40-50 tks 的速度应该更舒服，希望我很快就能在 llamacpp 上达到这个速度。

[0] - https://pastes.io/9gaARxE8

[1] - https://jsfiddle.net/pou4nbh9/1/

模型：https://huggingface.co/google/gemma-4-26B-A4B-it-qat-q4_0-gg...

SugarReflex 6小时前 |上一页|下一页 [–]

有人用Aider吗？有没有其他好用的命令行替代方案？

AH4oFVbPT4f8 11小时前 |上一页|下一页 [–]

我使用 Ollama + Hermes 开发环境，运行在配备 128GB 内存的 M5 Max 处理器上，采用 .NET 框架，并以 Qwen 3.6:35b-a3b 作为主要开发模型。我可能会使用 27b 版本来规划开发任务。

xeonax 11小时前 |父级|下一级 [–]

.NET 在这期间做了什么？

AH4oFVbPT4f8 9小时前 |根|父|下一个 [–]

抱歉，我的意思是，我正在使用 .NET C# 进行设置。

chungus 7小时前 |上一页|下一页 [–]

是的，虽然严格来说不算被替换，因为我从来没用过那两款产品，我不喜欢把代码发送到他们的黑盒子里。我有两块24GB的AMD显卡，是从本地市场上的游戏玩家那里买的，其中一块用40厘米的延长线连接。我用的是Qwen 27B，对它的性能非常满意。Q8的上下文是135k（只是个大概数字，我可以把它推到256k）。我喜欢用Qwen 35B3A来绘制我们公司相对复杂的代码库/基础设施的完整代码路径。

我觉得它太好了，我现在会在本地市场上搜寻价格合适的 24GB 显卡，这些显卡似乎没有被矿工之类的人使用过，以便组装一台更大的矿机来进行并行执行。

功耗也完全不是问题，人工智能的工作负载与游戏截然不同。

tldr llama.cpp-vulkan with opencode on total 48GB VRAM AMD cards on arch bight.

SkitterKherpi 12小时前 |上一页|下一页 [–]

到目前为止，这种情况总是让人感觉下一版本的本地模型只是勉强够用而已。

euroderf 9小时前 |上一页|下一页 [–]

有人用只有 8GB 内存的 Mac 成功完成过这个操作吗？帮朋友问的。

jwr 11小时前 |上一页|下一页 [–]

我尝试了很多很多次，而且还会继续尝试。但我就是觉得这事儿不可能实现：我们能在自己的机器上运行的那些小型模型（我用的是M4 Max Mac，所以目前勉强能运行qwen3.6-35b-a3b或者gemma-4-26b-a4b-qat）跟Opus/Fable这种大型模型根本没法比。差远了。我觉得很多人都在自欺欺人。

当然，你可以利用本地模型为简单场景生成看似合理的代码。但与我使用 Claude Code 和 Opus/Fable 解决大型代码库中复杂设计问题的方式相比，这根本不值得我花费时间。

jmichaelson 11小时前 |上一页|下一页 [–]

我目前正在研究这个问题。我的方法是，使用高度优化的框架（pi.dev）以及合适的后端知识库（一个自定义的、可自动更新的、包含大量质量控制层的 wiki），可以很好地满足我 Claude Max 20x 订阅的大部分使用模式。我使用 Gemma 4 26B QAT，由 llama.cpp 的一个自定义分支提供服务，每个 QAT 包含 4-8 个 256k 的上下文槽，Q8 级别。如果框架能够稳定运行，这是一个非常好的模型。在如今动辄百万个上下文窗口的时代，256k 的上下文可能看起来很小，但对于我的工作（科学编程）来说已经足够了。每月 20 美元的 Ollama-cloud 订阅可以让我很好地利用前沿模型来处理复杂的规划或调试问题（所有这些都集成到我高度定制的 pi 安装中）。

我仍在进行优化（确切地说，是和 Claude 一起），但测试结果非常令人鼓舞。我很担心公司（以及政府）会控制对人工智能的访问，所以本地化是最佳方案。

salutonmundo 6小时前 |上一页|下一页 [–]

它叫做你那该死的脑子。

anubhav200 11小时前 |上一页|下一页 [–]

是的，llama.cpp、qwen 27b 和 35b，以及用于管理模型配置的 llama-cpp-manager。（https://github.com/anubhavgupta/llama-cpp-manager）

Razengan 12小时前 |上一页|下一页 [–]

相关问题：是否存在可行的分布式人工智能模型？

就像我们之前推出的 SETI at Home、Folding at Home、BitTorrent 等项目一样，人们显然愿意将自己的计算机资源贡献给分布式项目。

也许在 dAI 网络中，任何人都可以提交内容进行训练，而每个运行“节点”的用户都可以拥有自己的自定义私有条件，以决定接受哪种类型的内容进行训练或推理。

例如，不喜欢动漫的人可以选择“永远不接受与动漫相关的内容或查询”，这样他们的节点基本上就会选择不接收任何与动漫相关的数据或问题。

joshuamoyers 12小时前 |父级|下一级 [–]

我认为要实现可行的每秒处理数（tokens/s）或使算术强度足够高是非常困难的，因为现有的训练和推理过程中很多都受限于内存带宽。不过，从概念上讲，构建一个分布式的慢速流水线是完全可行的。

SimianSci 11小时前 |父级|上一页|下一页 [–]

这种情况在相当长的一段时间内不太可能以任何有意义的方式发生。

（简而言之：分布式模型计算所需的硬件水平目前只有数据中心才能真正实现。）

令牌生成规模庞大，对单个GPU的要求极高，往往会超出PCIe等消费级互连的带宽承受能力。这从根本上意味着，如果没有强大的基础设施，将模型的计算任务分布到广阔的距离上将是一项艰巨的挑战。

举例来说，当我们把一个模型的计算任务分配到同一台工作站上的两张独立显卡上时，这并不意味着模型的计算带宽会翻倍。实际上，带宽的提升幅度很小，大约只有 20% 左右（具体数值取决于模型），因为接口（消费级硬件上的 PCIe 接口）很快就会因为两块 GPU 之间频繁的数据复制而饱和，成为瓶颈。而且请记住，这是 PCIe 接口在本地传输时发生的，其传输速度（取决于主板的代数）通常上限在 20-35 GB/s 左右。

模型性能很大程度上取决于是否拥有速度最快、带宽最高的单卡，以便最大限度地减少数据传输操作，因为模型运行所需的数据量极其庞大。我简直无法想象，如果模型计算所需的复制操作必须在不稳定的网络速度下进行，模型将会变得多么缓慢且无法使用。由于全球网络速度分布不均，性能损失将非常显著，而且网络不稳定还会导致数据验证开销增加。

分布式人工智能的梦想距离实现还有很长的路要走。

wmedrano 10 小时前 |上一页|下一页 [–]

不，但我用的是 GLM5.1 而不是 Claude/GPT。

drnick1 9小时前 |上一页|下一页 [–]

您推荐使用 Ollama 还是 bare llama.cpp？

jboss10 8小时前 |父级|下一级 [–]

llama.cpp 速度更快，而且是开源的。Ollama 的历史褒贬不一。我使用 llama-swap 来模拟 Ollama 的使用体验。

shironnnn_ 9小时前 |父级|上一页|下一页 [–]

如果在 MacOS 上，我推荐 llm-mlx，它目前渲染 token 的速度比 llama.cpp 快 10%-15%。

如果你想在花大价钱购买显卡之前先试一试，那就运行一个适合你的目标显卡运行的程序，但要联网运行。

devin 11小时前 |上一页|下一页 [–]

这里有人在用 TinyGrad 吗？

板极电压 5 小时前 |上一页|下一页 [–]

我会在本地运行一些非常小的模型来进行代码补全和编写样板代码。我偶尔还会用 Claude 在网页浏览器里运行，因为它免费，但一旦它停止服务，我就会立刻停止使用它。他们休想从我这里赚到一分钱。

hacker_homie 6小时前 |上一页|下一页 [–]

我在一台搭载 AMD AI Max 处理器的笔记本电脑上运行 QWEN 3.6，速度大概在 6-10 tok/s，速度慢到我可以跟着操作。它的设计存在一些问题，处理大量代码时会比较吃力。除此之外，它还是个不错的编程伙伴。

epolanski 6小时前 |上一页|下一页 [–]

我没有使用本地版本，而是升级到了 DeepSeek v4。

不过，等我入手一台 256GB 以上的 MacBook 后，我打算改用本地的存储设备。

局部推理足以帮助我完成日常工作，而且不会让我变成法学硕士的助手。

w10-1 10 小时前 |上一页|下一页 [–]

我用 oMLX（用于缓存）在 32GB 的 M1 max 上运行许多模型（但主要是 Gemma-4），而且是用 Xcode 运行的（天哪！）。就每秒响应时间而言，我认为在很多情况下它的响应速度比我大声读出提示符还要快（而且我并没有一直轮询 Claude 状态页面）。

我花了几个月时间精心维护AI、工具、技能和MCP服务器，但现在主要只是用它们来编写代码。我发现自己懒得用Claude了（但还是继续付费“以防万一”）。

这之所以可行，部分原因在于我的提示具有非常具体的目标、限制和建议的阶段性步骤，因为我希望代码完全按照我自己的编写方式呈现，并且我希望在特定时刻参与决策。我认为速度提升幅度在 2-4 倍，而不是像凭感觉编写全新项目那样达到 10 倍。问题不在于编码速度，而在于构建既复杂又正确且灵活的系统（即方向性准确性）。例如，智能体可以帮助我们放弃效率较低的 API 结构，而不是固守局部最优解。

其中一个缺陷是，我仍然在编写对人类来说简洁易懂的代码，但现在看来这可能是一种浪费。LLM（语言学习管理）或许更乐于接受一个 API 中包含 10 个以上的参数，而不是大量的配置对象和便捷封装器。

系统2 12小时前 |上一页|下一页 [–]

在我买到80GB显存的显卡之前，我不会尝试这么做。本地的LLM（法学硕士）总是缺少一些需要更大显存的显卡才能运行的东西。

ColonelPhantom 6小时前 |父级|下一级 [–]

哪些型号的显卡需要 80 GB 显存？在我看来，主流型号的显存都在 300 亿左右（例如 Qwen3.6、Gemma 4），而大型型号（例如 MiniMax、MiMo、StepFun、Deepseek）的显存则高达数千亿，80 GB 显存显然不够用。

如果你的机器配备 128GB 内存，例如 DGX Spark、Framework Desktop 或 M5 Max，勉强可以达到后一类游戏的低端配置，不过这些机器通常速度并不快。而对于前一类游戏，你只需一台配备 3090 或 5090 显卡的机器就能轻松流畅运行，甚至 5060 Ti 也完全可以。

CamperBob2 38分钟前 |根|父|下一个 [–]

没错。只买一块 RTX 6000 显卡意义不大。想要运行一些 5090 运行不了的程序，至少需要两块。你可以想象，情况会如何发展。

christkv 12小时前 |上一页|下一页 [–]

等待https://github.com/antirez/ds4稳定下来，以支持 strix halo。

sometimelurker 9 小时前 |上一页|下一页 [–]

是的，我用的是小型 MTP qwens 和 pi。

jay_kyburz 7小时前 |上一页|下一页 [–]

有人知道怎么在 Strix Halo 128GB 上和 Qwen3.6 聊天吗？

如果我给它一页上下文信息，它能生成链表或者识别出错误的 CSS 代码吗？

有没有什么在线平台可以让我和家里运行的模型进行交流，看看它的性能如何？

major505 11小时前 |上一页|下一页 [–]

是的。我每天都在我的 MacBook m1 (16GB) 上使用 Owen，它运行在 Ollama 里。效果不错。速度不算特别快，而且我需要创建一个自定义镜像，将模型的初始温度设置为零，这样我就不会过度依赖它的各种花招，但它一周内都能正常工作。

Der_Einzige 9小时前 |父级|下一级 [–]

许多人对智能体编码的不满实际上源于采样设置选择不当，但世界还需要几年时间才能真正理解这一点。top_p 和 top_k 参数虽然效果不佳，但却被刻意保留，因为后续方法会进行相干高温采样，而出于对齐和安全考虑，相干高温采样是绝对不允许的。

即使使用小型模型，也能获得良好智能体输出的秘诀是什么？Llamacpp 支持一种鲜为人知的采样器，名为“top-n sigma”。你应该使用它，将其设置为 1，并将 temperature 设置为任何你想要的值（可以是无穷大），你的模型就能神奇地在你的最大上下文窗口内运行。这是因为长时间的上下文生成本质上是一个采样问题。

thrownaway561 9小时前 |上一页|下一页 [–]

我只用DeepSeekV4 Fast……它超级便宜。目前我的月使用量是……

67M 输出 51M 输入

总计 0.83 美元。

我真的不明白为什么人们不使用DeepSeek。

ThomasGlanzmann 8小时前 |父级|下一级 [–]

我也一样。90% 的任务我都用 deepseekv4 快速完成，如果遇到不行的，我就用 deepseekv4 pro。我用 crush 作为代码助手，但移除了被屏蔽的命令，因为我还要做很多系统管理工作。我很喜欢它。7 周才花了 8 美元，而且用途非常广泛，编程、系统管理、替代谷歌搜索、投资等等，几乎无所不能。

codemk8 6小时前 |父级|上一页|下一页 [–]

你是说 deepseek-v4-flash 吧？我也是。我用它来给我的 Hermes 代理商充值。它太便宜了，我有时都觉得“愧疚”。我甚至多投了一些钱，就为了确保他们不会倒闭。

ThomasGlanzmann 46分钟前 |根|父|下一个 [–]

是的，我指的就是 deepseek-v4-flash。

jeffrallen 10小时前 |上一页|下一页 [–]

我在公司提供的远程GPU上使用Qwen 3.6。运行良好。虽然速度慢但很稳定，工作效率高，能完成任务。可能更擅长诊断问题而不是编写新代码，不过也无所谓了。

syngrog66 5小时前 |上一页|下一页 [–]

我预先用我的大脑、vim、各种其他命令行/图形用户界面工具等组合方式替换了它。

gigatexal 11小时前 |上一页|下一页 [–]

我试过了。我实在无法接受它让我的 M3 Max MacBook Pro 14 原本安静得像耳语一样，性能却提升了这么多。最佳方案是使用 Claude Code 来处理中国版模型。Deepseek V4 Pro 非常非常出色。但我只是个偶尔使用 AI 的本地用户，每月 20 美元的 Claude 订阅费就足够了，而且我发现自己越来越频繁地使用它。

cyanydeez 11小时前 |上一页|下一页 [–]

从未启动。使用 wither qwne3-xoder-nezt 或 qwen3.6 35b

如果你正打算购买一台新电脑，那么很容易就能找到购买 128GB 显存的理由。

dude250711 12小时前 |上一页|下一页 [–]

是的，这里是在天然湿件基材上运行本地模型。

推荐配置：充足的营养、适量的咖啡因和安静的环境。

表现——目前未以代币衡量：大致处于平均水平。

jasongill 12小时前 |父级|下一级 [–]

我在 Claude Code 流行之前就开始运行这个技术栈了。它运行尚可，但我发现它速度非常慢；尽管上下文窗口很大，它似乎经常会迷失方向，陷入无休止的循环（或者只是浪费令牌尝试使用网页浏览器），一耗时数小时，而且很难回到正轨。我甚至尝试启动了两个子代理，但即使经过多年的尝试，它们的编码能力仍然几乎为零，所以至少目前看来，这似乎是在浪费资源，但也许随着时间的推移，这个模型会有所改进。

bananadonkey 8小时前 |根|父|下一个 [–]

我的子代理已经循环运行了近十年，至今一行代码都没写过。绝对不会再投资其他代理了……

HPsquared 12小时前 |父级|上一页|下一页 [–]

我个人每小时大约能获得 50 个代币。

tyingq 10 小时前 |上一页|下一页 [–]

有人尝试过“通过网络租用GPU”这种方式吗？这种方式在任何应用场景下都具有成本效益吗？

kertoip_1 13小时前 |上一页|下一页 [–]

只需将 OpenRouter 连接到您的编码代理工具即可自行尝试。所有相关的 OpenRouter 模型都已包含在内。每个人的需求和期望都不同。

dada216 12小时前 |上一页 [–]

本地部署？不是。主要通过 OpenCode Go 订阅使用 GLM 吗？是的，我仍然通过 OpenRouter 的 API 使用 Gemini/Claude/GPT 来完成一些相关任务，API 令牌费用每月最多 20 美元。

免责声明：我是一名 Linux 基础架构/k8s 开发人员，我编写生产代码，但主要是粘合代码，而且主要使用 golang 编写。

补充说明：我们从中获得的最大价值来自“文档智能”，而这部分内容全部出自 Gemma 和 Qwen 在 H100/H200 项目中的贡献。

产品经理必装的10个Skills：从需求到落地的全链路AI武装

Thu, 11 Jun 2026 20:39:25 CST

作为一个每天和PRD、竞品分析、用户访谈打交道的产品经理，我一直在寻找能让工作更高效的方法。最近深入研究了 WorkBuddy 的 Skill 生态，发现里面藏着不少专为PM设计的”神器”。今天这篇文章，我把实战验证过的10个Skills整理出来，每个都配有真实使用场景和案例，看完你就知道该装哪些了。

一、Product Manager Toolkit —— PM的”瑞士军刀”

解决痛点：需求优先级混乱、客户访谈不会问、PRD写不全

这个Skill堪称产品经理的”百宝箱”，内置了RICE优先级排序、客户访谈分析、PRD模板、探索框架、上市策略等一整套方法论。安装量366次，18颗星，是PM类Skill里口碑最好的之一。

实战案例：

上周我负责的一个功能有5个候选需求，每个需求方都说自己的最急。我把5个需求的Reach（覆盖用户数）、Impact（影响程度）、Confidence（信心度）、Effort（开发成本）输入进去，RICE模型直接算出优先级排序。结果显示一个”看起来很重要”的需求实际得分排第4，而一个小功能改进排到了第2。

我把这个排序拿给开发负责人看，他当场同意按这个顺序排期——因为这不是”我觉得”，而是模型算出来的。

使用技巧：

客户访谈分析模块特别适合整理用户反馈录音/文字，自动提取痛点、爽点、痒点
PRD模板不是让你直接生成PRD，而是提供结构化框架，逼你把每个模块都想清楚
探索框架可以帮你在需求早期做快速验证，避免后期大返工

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=product-manager-toolkit"

二、Competitive Analysis —— 竞品分析的”专业外包”

解决痛点：竞品信息收集慢、分析维度单一、输出报告耗时

这个Skill专注于深度竞争分析，能帮你绘制竞争对手画像、发现市场空白、理解竞品策略、对比自身产品定位。它不是给你一个简单的”竞品对比表”，而是引导你做系统性的竞争情报分析。

实战案例：

我们团队准备进军一个新的垂直领域，我对这个领域的竞品了解仅限于用过的两三个产品。用Competitive Analysis Skill，我输入了领域关键词和已知竞品，它帮我梳理出了8个直接竞品和5个间接竞品的定位矩阵、核心功能差异、定价策略、用户评价情绪分析。

最让我意外的是，它发现了一个我完全没有注意到的市场空白——头部竞品都在做”大而全”，但中小客户的”轻量专用”需求没人满足。 这个洞察直接影响了我们的产品定位策略。

使用技巧：

触发关键词：”分析我的竞争对手””竞争格局””与竞争对手对标”
建议先手动列出已知竞品，再让Skill补充你可能遗漏的竞品
分析报告出来后，一定要人工验证其中的数据，尤其是用户评价部分

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=competitive-analysis"

三、User Research —— 用户研究的”方法论教练”

解决痛点：问卷设计不专业、访谈问不到点上、反馈数据不会分析

很多产品经理做用户研究就是”发个问卷、找个用户聊聊”，但问卷怎么设计才能避免引导性偏差？访谈脚本怎么写才能挖出深层需求？这个Skill提供了一整套用户研究的方法论支持。

实战案例：

我们有一个老功能使用率一直上不去，团队内部讨论了很久，有人说UI太丑，有人说入口太深，有人说用户根本不需要。我拿着这个模糊的问题去找User Research Skill，它帮我设计了一个”任务完成度+满意度+NPS”的三段式问卷，还生成了一份5人深度访谈的脚本。

访谈执行后发现， 真正的问题根本不是UI或入口——而是用户根本不知道这个功能能解决他们的问题。 这个功能的名字太技术化了，用户看到名字就划走了。我们改了个更直白的名字，使用率两周内提升了47%。

使用技巧：

问卷设计模块会帮你检查是否有双重提问、引导性选项等常见问题
访谈脚本会根据你的研究目标自动调整深度——探索性研究和验证性研究的脚本结构不同
反馈分析模块可以帮你做情感分析和主题聚类

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=user-research"

四、Data Analysis —— 数据驱动的”分析助手”

解决痛点：Excel操作繁琐、数据洞察挖掘慢、可视化门槛高

产品经理天天跟数据打交道——DAU、留存、转化、漏斗、AB测试……但这个Skill不是教你写SQL或Python，而是帮你把”分析思路”变成”可执行的分析流程”。

实战案例：

上个月我们上线了一个新功能，老板说”看看效果”。我把后台导出的CSV丢给Data Analysis Skill，它先帮我做了数据清洗（发现日期格式不统一、有几行缺失值），然后自动做了基础统计、趋势分析、异常检测。

最关键的是，它发现了一组我肉眼完全看不出的关联—— 在周三下午3-5点使用该功能的用户，次日留存率比其他时段高出23%。 深入分析后发现，这个时段正好是用户完成某项核心工作流后的”空闲窗口”。我们据此调整了功能推送策略，把原来全时段的推送改成了周三下午定向推送，整体留存提升了8%。

使用技巧：

上传数据前先让Skill帮你做”数据健康检查”，避免脏数据导致错误结论
不要只问”分析这个数据”，要问”我想验证XX假设，该用什么分析方法”
可视化结果出来后，让Skill帮你解读”这个数字对业务意味着什么”

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=data-analysis"

五、PRD Writer —— PRD撰写的”结构教练”

解决痛点：PRD结构混乱、遗漏关键模块、上下游理解不一致

这个Skill专门帮产品经理写结构化的PRD，但注意—— 它的价值不是”替你想”，而是”逼你想全”。它会引导你回答”为什么做””做什么””怎么做””怎么验证”四个核心问题，确保PRD的每个模块都有据可依。

实战案例：

我之前写PRD有个坏习惯——重”功能描述”轻”业务目标”。有一次我拿着一份”功能很全”的PRD去评审，开发问”这个按钮放在这里，预计能提升多少转化率？”我答不上来。

后来用PRD Writer Skill，它在开头就逼我填写：

业务目标：提升新用户首单转化率15%
成功指标：7日内新用户下单率
失败回退条件：如果上线两周内转化率提升<5%，则回滚

这些模块的存在，让PRD从”功能说明书”变成了”业务方案书”。 开发不再只是”实现功能”，而是”为实现业务目标负责”。

使用技巧：

不要把PRD Writer当成”代笔工具”，把它当成”检查清单”
每写完一个模块，用它的”一致性检查”功能，确保前后逻辑不自相矛盾
异常流程和边界条件是最容易遗漏的，PRD Writer会专门提示你补充

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=prd-writer"

六、Meeting Minutes —— 会议纪要的”自动秘书”

解决痛点：会后忘记决议、行动项跟踪混乱、信息同步不到位

产品经理的日程表上，会议占据了40%以上的时间。但很多时候，开完会大家各忙各的，会上说好的事情没人跟进。Meeting Minutes Skill能把杂乱的会议内容整理成结构化的纪要，包含决策点、行动项、负责人、Deadline。

实战案例：

我们有个跨部门项目，涉及产品、开发、设计、运营四个团队，每周一次同步会。以前会后我手动整理纪要，至少要花30分钟，还经常漏掉一些讨论细节。

用了Meeting Minutes Skill后，我把会议录音或速记文字丢进去，它自动输出：

会议基本信息（时间、参会人、议程）
达成的决策（带上下文，说明”为什么做这个决定”）
行动项（负责人+截止日期+优先级）
待确认事项（需要会前补充的信息）
下次会议议程建议

最让我惊喜的是”决策上下文”这个模块。 以前纪要只写”决定做A”，过两周有人问”为什么不做B？”大家都不记得了。现在纪要里自带决策依据，翻出来就能回答。

使用技巧：

会前把议程输入进去，会中按议程记录，会后让Skill帮你整理
行动项一定要包含”负责人+截止日期”，缺一个就不算完整的行动项
复杂会议建议开启”决策追踪”模式，自动关联之前的相关决策

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=meeting-minutes"

七、Mind Map —— 思维整理的”可视化工具”

解决痛点：思路混乱、逻辑关系理不清、方案对比不直观

产品经理经常需要梳理复杂的产品结构、用户流程、决策树。Mind Map Skill能把你的Markdown大纲或文字描述自动转换成结构化的思维导图，支持多种布局风格。

实战案例：

我们有一次要做一个”会员体系重构”的大项目，涉及等级体系、权益设计、积分系统、续费策略四个子模块，每个子模块下面又有十几条细则。我在文档里写了三页文字，自己看得都晕。

用Mind Map Skill，我把文字大纲丢进去，它生成了一个四分支的思维导图。一看图我就发现了问题—— 积分系统和权益设计有两处逻辑冲突，文字版看了三遍都没发现。

我把这张图贴到评审PPT里，老板和开发负责人一眼就看懂了整体架构，评审效率比之前提升了至少一倍。

使用技巧：

建议先写文字大纲再转导图，不要直接”画”导图，容易遗漏
对比不同方案时，用”水平布局”把两个方案并排展示
导图生成后，让Skill帮你检查”是否有遗漏的分支”或”是否有循环依赖”

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=mind-map-skill"

八、Product Framework —— 产品架构的”设计工具”

解决痛点：产品架构设计缺乏方法论、技术方案看不懂、与开发沟通有鸿沟

这个Skill专门帮产品经理设计并可视化产品框架，包括分层架构、价值链、能力图谱、竞争定位。它不是给技术架构师用的，而是给产品经理用来”把产品逻辑结构化”的。

实战案例：

我们要做一个B端SaaS产品，我对技术架构一窍不通，但产品架构必须我自己定。用Product Framework Skill，我输入了业务场景和用户旅程，它帮我生成了三层产品架构图：

表现层：用户直接看到的界面和交互
业务层：核心业务流程和规则引擎
数据层：数据模型和基础服务

每层下面又细分了能力模块。拿着这张图去和技术负责人沟通，他很快理解了产品方向，还根据技术可行性帮我调整了业务层的模块划分。 以前需要开三次会才能对齐的事情，一张图就解决了。

使用技巧：

产品架构不是技术架构，重点在”业务能力的分层”，不要陷入技术细节
能力图谱模块可以帮你识别”核心能力”和”可外包能力”，对MVP规划很有用
竞争定位模块适合做差异化分析，找到自己产品的独特价值点

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=product-framework"

九、Socratic Business Model Canvas —— 商业模式的”追问教练”

解决痛点：商业模式画布填不满、底层逻辑没想透、关键假设没验证

传统的商业模式画布就是一张表格，让你填空。但这个Skill用的是 苏格拉底式追问——它不给你标准答案，而是通过一系列层层深入的问题，逼你把每个模块的底层逻辑都想清楚。

实战案例：

我有一次要为一个内部创新项目写商业计划，用了传统的画布模板，20分钟就填完了，但自己看着都觉得”假大空”。

改用Socratic Business Model Canvas后，它开始问我：

“你说你的价值主张是’提升效率’，具体提升哪类用户的什么效率？”
“你的收入来源是订阅费，用户为什么要持续付费而不是用一次就走？”
“你说你的关键资源是技术团队，如果核心成员离职，这个资源还成立吗？”

这些问题让我意识到，我之前填的12个模块里，有4个是未经验证的假设，有2个根本站不住脚。 重新梳理后，商业模式变得扎实多了，投资人评审一次就过了。

使用技巧：

不要急着”填完”，每个问题都值得停下来认真想
建议团队一起做，不同角色对同一个问题的答案往往不一样
把最终的假设清单单独列出来，标注哪些已验证、哪些待验证

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=socratic-business-model-canvas"

十、PM Toolkit – Excalidraw —— 产品思维的”可视化翻译器”

解决痛点：想法在脑子里转、讲不清楚、团队理解不一致

这个Skill能把产品经理的”Why、What、How、用户旅程”等思维过程，自动转换成可编辑的Excalidraw图表。安装量356次，10颗星，是可视化类Skill里最受欢迎的产品PM工具。

实战案例：

有一次我要向大老板汇报一个新方向的探索结论。准备了一页文字说明，自己觉得逻辑很清晰，但老板看了说”太抽象，能不能画个图？”

我把文字说明丢给PM Toolkit – Excalidraw，它生成了四张图：

Why：用户痛点场景图
What：产品价值主张图
How：核心功能架构图
用户旅程：从发现到使用的全流程图

我把这四张图贴到汇报材料里，老板看了第一张图就说”这个问题我们确实要解”，看到第三张图就开始讨论资源投入了。 文字材料他压根没细看——图已经说明了一切。

使用技巧：

适合在方案讨论阶段快速出图，不需要设计师参与
用户旅程图建议按”阶段-触点-情绪-痛点-机会”五列来组织
生成的图可以直接导出为PNG或SVG，插入PPT或文档

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=thought-to-excalidraw"

安装建议：按工作阶段按需取用

这10个Skill覆盖了产品经理从需求发现到产品落地的完整链路。但我不建议一次性全装上—— 按需取用，效率最高。

工作阶段	推荐Skill	核心价值
需求探索期	Product Manager Toolkit + User Research	快速验证需求真伪
竞品调研期	Competitive Analysis + Product Framework	找准差异化定位
方案设计期	Mind Map + PM Toolkit – Excalidraw	把思路可视化
需求文档期	PRD Writer	确保PRD结构完整
数据验证期	Data Analysis	用数据说话
商业规划期	Socratic Business Model Canvas	把商业模式想透
日常协作期	Meeting Minutes	让会议有产出

最后提醒一点：Skill是工具，不是替代品。它们帮你提高效率、减少遗漏、结构化思考——但产品决策的 judgment，永远在你自己手里。

本文作者@Lucas ，前字节、腾讯 AI产品经理。

我是怎样使用 AI 构建 E2E 测试体系的？ | Viking

Mon, 08 Jun 2026 09:04:04 CST

问题

TinyShip是一个支持 Next.js、Nuxt.js、TanStack Start 三套前端框架组成的 monorepo，同时支持 PostgreSQL 和 SQLite，也就是说每改一个功能，有 6 种不同的组合可能出问题。当开发任何新功能的时候，保证应用完成新功能并起没有 regression 是非常重要的，假如手动测试工作量难以估量，我是开发基础的功能以后，在添加后续的功能的时候，发现没有 E2E 的测试，几乎是非常麻烦的，尤其是针对一个多框架多数据库支持的应用，流程都相似，重复性非常高，所以这里必须有一个开发新功能的时候的测试和验收流程。

基石

TinyShip 的基石是 E2E 测试，我认为在 AI Coding 时代，任何产品的基石都是测试，User Cases 比代码更宝贵。AI 让代码迭代速度从天变成小时，你一天可能重构 10 次，添加 20 个功能，每次改动都可能意外破坏现有功能。

虽然感觉 E2E 有点重，但是还是毅然将它们加上了，事实证明，有了 AI 的辅助任何看起来很繁琐的任务都实施起来都不难。我让它通过路由和页面分析核心交互，确定一些必须覆盖的关键流程（Critical User Journeys），然后编写 case，加上修改测试和我去 Review，总共也就只花了两天时间。它模拟真实用户在浏览器中的完整操作，保证 核心的流程必须 100% 有 E2E 覆盖，这样任何修改提交和后续的修改就有一个重要的依靠，对后续的功能开发是重要的。

五阶段流程

有了 E2E 的覆盖，我确定了一新的开发新 feature 的流程， TinyShip 开发新功能的时候定了五个阶段：Spec → Code → Verify → Test → Green，我将这套标准写入到根目录的 Agents.md 下面，这样 AI 可以第一时间按照我的流程完成功能。

核心思路是先想清楚要测什么，再写代码，然后用 agent-browser 走一遍视觉确认，最后写 Playwright 测试。顺序很重要。这套流程在 Agent 的 Plan 模式下就会被激活，伴随着技术方案的创建，在开始 build 以后会完成接下来的步骤。

       ┌─────────┐   ┌─────────┐   ┌──────────┐   ┌─────────┐   ┌─────────┐
│  SPEC   │──▶│  CODE   │──▶│  VERIFY  │──▶│  TEST   │──▶│  GREEN  │
│ 定义验收 │   │ 实现功能 │   │ 视觉确认  │    │ 写 E2E  │    │ 全通过  │
│ 标准     │  │         │   │          │    │ 测试    │    │        │
└─────────┘   └─────────┘   └──────────┘   └─────────┘   └─────────┘

Spec：先想清楚要测什么

每做一个新功能，第一步是让 AI 在 tests/e2e/TEST-CATALOG.md里写一段验收标准。就是用自然语言描述：打开哪个页面、点哪里、期望看到什么。例如之前已经有的一个用例，除了自然语言描述，还可以增加结构化字段。

       ## 8. 个人资料更新测试
**文件：** `specs/profile-update.spec.ts` ｜ **优先级：** P1

验证仪表盘中编辑个人资料的完整流程：进入编辑模式 → 修改姓名 → 保存 → 验证更新。

> 所有测试共用一个浏览器上下文（`beforeAll` 注册），按串行顺序执行。

| # | 测试名称 | 具体流程 |
|---|---------|---------|
| 1 | 个人资料标签页显示用户名和编辑按钮 | API 注册用户 → 访问 `/dashboard` → 验证用户名可见 → 验证 "Edit" 按钮可见 |
| 2 | 可以进入编辑模式并修改姓名 | 访问 `/dashboard` → 等待用户名加载 → 点击 "Edit" 按钮 → 验证 `#name` 输入框可见 → 清空并填入新姓名 → 点击 "Save" → 等待编辑模式关闭（"Edit" 按钮重新出现） → 验证新姓名显示在页面上 |

Code：写代码

这个没什么好说，按清单写代码。但写的时候要注意一点：保持三个 app 的一致性。互相充用的逻辑在 libs/*里实现，路由层尽量薄。这样 E2E 测试写起来也省事，三个 app 的测试逻辑基本一样。

Verify：用 agent-browser 预演一遍

代码写完了，页面跑起来了，接下来不是写测试，而是先用 agent-browser走一遍，agent-browser 是 Vercel Labs 专门为 AI Agents 设计的浏览器自动化 CLI。

为什么要使用 agent-browser ？

为什么多这一步？

首先因为 Playwright 测试是脆的——选择器经常要调。如果界面有明显的 UX 问题，写测试也是浪费，后面还得改。多次跑会非常慢，而且浪费 token。

agent-browser 基于 Rust + Playwright 底层，首先它极致节省上下文和 Token。传统 Playwright 或 Puppeteer 给 AI 喂一页 HTML/DOM 树，动辄几千到上万 token，很快就占满上下文。它使用语义化、精简的 Accessibility Tree + 简洁引用（如 @E_1、@E_3 - button “生成图片”），输出非常 compact，能节省 80%+ 的 token。并且它有 AI-First 设计，使用自然语言指令它理解的很好。

       # agent-browser 的返回举例，很有趣，只保留交互元素，没有 DOM tree，节省大量 Token。
- textbox "输入提示词" [ref=e1]
- button "选择文件" [ref=e2]  (上传按钮)
- combobox "模型选择" [ref=e3]  (下拉框)
- button "开始生成" [ref=e4]

# 交互采用上面的 ref 来实现，完全不用写 CSS 选择器。
agent-browser click @e4

在 Verify 阶段用 agent-browser 走完真实流程后，我们已经拿到了可靠的元素引用和实际 DOM 结构，此时再写 Playwright 测试的选择器成功率极高，基本一次就能稳定。而且三个框架的测试代码也可以高度复用，只需少量调整。

Test：写 Playwright E2E

UI 确认没问题了，才开始写 Playwright 测试。这时候选择器都知道了——哪个按钮是 [data-slot="select-trigger"]，哪个列表是 role="listbox"，哪个输入框的 placeholder 是啥。

为什么不在写代码之前就写好测试？

BDD 不就是先写测试的吗？

试过，不行。

E2E 测试跟单元测试不一样。单元测试是测试一个函数，输入输出都是纯数据，你可以在写代码之前先写测试。但 E2E 测试依赖真实的 DOM 结构—— [data-slot="select-trigger"]这种选择器，你不知道 UI 会长什么样之前根本写不了。而且三个框架（Next.js、Nuxt.js、TanStack Start）渲染方式不一样，同一个选择器可能在一个框架里有效，在另一个里失效。

所以我的做法是：用 BDD 的思维——先想清楚验收标准——但测试代码放在 UI 成型之后再写。

Green：三个 app 都跑通

最后一步，启动 Next.js app，跑一遍测试。然后换 Nuxt.js，再跑一遍。再换 TanStack Start，再跑一遍。三个都绿了，再切数据库，PG 和 SQlite，6 次测试都通过，这个功能才算做完。

切 app 和数据库让 AI 来，不需要手动，一个 app 跑完，切换另一个，跑相同的测试。

E2E 不在 CI 上跑

E2E 测试有个特征： 我不让它在 CI 上跑。

CI 上只跑 typecheck 和 build。为什么？几个原因：

慢。全量 E2E 跑完一个 app 大概 6 分钟，三个 app 要 18 分钟，再加上两个数据库 36分钟，CI 上排队这么久不划算。
依赖多。支付相关的测试需要 Stripe CLI 以及不同支付平台的各种环境变量，由于支持的服务非常多，要配置的环境变量很多。CI 上配这些要么麻烦，要么不安全。
CI 的目的是快速反馈——类型对不对、能不能编译。E2E 解决的是另一个问题：交互流程有没有坏。这俩不是一回事。

所以 E2E 我现在只在本地跑，每次发版前，三个 app 各跑一遍。

三种情况跑 E2E

E2E 不是天天跑全量的。我只在这几种情况跑：

情况	跑哪些
做完一个功能	只跑相关的 spec 文件
发版前	全部 spec，三个 app 都跑
大重构	全部 spec，三个 app 都跑

小修小补，跑个 typecheck + build 就够了。全量 E2E 是发版和重构是否才跑。

如果你也有多框架的项目，或者也头疼人肉测试成本太高，可以试试这套流程。

AI裁员陷阱：一场集体理性的经济自杀

Sun, 31 May 2026 22:44:16 CST

【AI裁员陷阱：一场集体理性的经济自杀】

沃顿商学院最新论文用数学推导出了一个恐怖闭环：企业用AI干掉员工提高效率，竞争对手被迫跟进。在微观上，每个老板都做出了最符合自身利益的理性选择；但在宏观上，被裁掉的员工恰恰也是市场上的消费者。

当全行业同时加速自动化，结果就是生产力无限飙升，而全社会的消费需求直接归零。这就是经典的“囚徒困境”在AI时代的放大版：大家都在拼命造出能生产一切的机器，却顺手消灭了所有能掏钱买单的顾客。更绝的是，模型测试了全民基本收入、资本税等各种药方，全部失效，唯一有解的只有“自动化碳税”——让企业在用AI替代人类时，必须为自己破坏的那部分市场需求当场买单。

这不是科幻，而是正在发生的纳什均衡。当个体理性叠加成集体疯狂，通往无限繁荣的快车道，稍不留神就会变成通往经济死局的传送带。

arxiv.org/abs/2603.20617

大公司的 AI 账本，没有一笔算得过来

Thu, 28 May 2026 21:09:14 CST

今年四月，Uber 的 CTO 发现了一件事：公司全年的 AI 工具预算，四个月就花完了，这件事是整个硅谷「token 消耗大比拼」的一个典型例子，我们之前也写过。

但就在几周后，Uber 的 COO Andrew Macdonald 在播客里给同事「补了一刀」： token 消耗和交付给用户的功能之间的联系，还不存在。

▲ Andrew Macdonald 图片来自：Business Insider

Uber 在去年底部署了 Claude Code，95% 的工程师每个月都在用，70% 的提交代码来自 AI，使用率惊人，账单也惊人。每个工程师每月的 API 调用费在 500 到 2000 美元之间，同一个人用同一个工具，同一天的消耗差异可以达到十倍。CTO 不得不说自己要推到重来，「因为我以为够用的预算，已经被吹走了」。

他们花了很多钱让 AI 写代码，但花的钱和最终产出之间，看不到因果关系。 钱确实花了，代码确实写了，但用户体验提高了多？新增了多少有用的功能点？问就是不知道。

另一个方向的同一个问题

Uber 的困境是钱花了，成效没出来，但很多公司选择的是另一条路，由于看到了 AI 的潜力而大举裁员，认为 AI 可以代替

不是给人买 AI 工具，而是用 AI 代替人，这条路的账算得过来吗？

Gartner 今年发布了一份调查，覆盖 350 家年收入超过十亿美元的全球企业，结果发现：80%的企业在部署 AI 后都裁了人。 可是裁员率和 ROI 之间，完全没有相关性，裁得多的公司和裁得少的公司，回报率几乎一样。

这个结果反直觉，但仔细想想又很合理。裁员省的是人工成本，但省下来的钱并没有变成新的业务价值。它只是让财报上的数字好看了一个季度，而不是让公司真的变得更强。Gartner 的结论很直接： 裁员可以腾出预算，但不创造业务价值。

AI 驱动的裁员，ROI 是零，为什么老板们还在做？本质上，裁员不是经营决策，是信号。对投资人说「我们在用 AI 了」的效果，和对董事会说「我们的运营效率在提升」的效果，都比真实的 ROI 重要得多。

Fortune 的分析把这叫做「AI washing」，用 AI 做借口裁员，实际上纯粹是在砍成本充利润，和 AI 能不能替代这些岗位，没有一点关系。

一个悖论

这样看，AI 会带来管理上的自相矛盾：用 AI 替代人，省了工资，但 ROI 没提升；给人用 AI，效率似乎提升了，但预算先爆了。

AI 工具的计费模式和传统软件完全不同。传统软件是按席位收费的，每个人每年多少钱，写进合同里，可以预测。但 AI 工具是按 token 收费的，用多少算多少，而且每个人的用量差异巨大。Uber 的数据显示，同一个工程师同一天的消耗可以相差十倍。这意味着传统的 IT 预算模型完全失效了，你没法在年初预测年底会花多少。

这像什么呢？ 像从固定费率的健身房会员卡，换成了按次计费的私教。你以前每个月交 299，去不去都那么多。现在每次去都要单独付费，去得越勤花得越多，而且你的员工各自去得多勤你完全无法控制。

不用吧，怕被淘汰；用吧，账算不过来。

钱去了哪里

Gartner 其实在报告里很克制地提了一句预测：到 2028 年到 2029 年，自主化业务反而会净增工作岗位。这听起来像没什么用的安慰，实际上它暗示的是现在裁掉的人，未来可能还得重新招回来。只不过到时候他们的岗位叫「AI 协调员」或者「模型运营」之类的，工资可能也不一样了。

打工人被裁了，公司也没赚到更多，预算还爆了。钱去了哪里？当然是 AI 公司的营收里。Anthropic 今年的年化收入已经突破十亿美元，OpenAI 更高。当 Uber 的 CTO 说「预算飘走了」的时候，那些被吹走的预算正好落在了 Anthropic 的账户里。

这是一个经典的淘金热结构。真正赚钱的从来不是淘金的人，是卖铲子和牛仔裤的人。现在的铲子是 API，牛仔裤是 token。每一家公司都在拼命用 AI，拼命让员工用 AI，拼命用 AI 替代员工——而 AI 公司在所有这些拼命的每一个环节里都在收钱。

AI 没有在省钱，它在换一种花钱的方式。

以前花在人身上，现在花在模型上；以前花在工资里，现在花在 token 里；以前花得可预测，现在花得无法控制。甚至，以前花的钱留在了员工手里，他们会拿去消费、娱乐、还房贷，钱在经济体里循环。

现在花的钱，直接进了几家硬件密集型、融资密集型的 AI 公司的账上，变成了下一轮 GPU 采购和下一轮融资的底气。

所以当你看到「某公司宣布用 AI 优化人力结构」的新闻时，可以翻译一下：我们把给员工的钱转给了 AI 公司，但我们并不确定这笔交易是否划算，我们只是知道，如果不做这笔交易，投资人会不高兴。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

全球车企唯一！比亚迪半导体产业覆盖芯片全流程、全链路量产中国首款4nm制程智驾芯片

Thu, 28 May 2026 22:40:19 CST

DoNews消息 2026年5月28日，比亚迪召开“敢为”智能化战略发布会，董事长王传福表示：“电动化上半场看电池，智能化下半场看芯片。”由此，比亚迪重磅发布中国首款4nm制程智驾芯片——璇玑A3，加速推进智能化下半场进程，引领全球汽车行业智能化变革。

此外，继为智能泊车安全兜底后，比亚迪再次率先承诺为城市领航安全兜底1年，并宣布全系车型均可搭载天神之眼B 辅助驾驶激光版，选装价格12000元，开创全民城市领航时代，让好技术人人可享、人人放心享！

从人的真实需求出发比亚迪设立智能化下半场三大目标

过去几年，全球迎来新一轮人工智能发展浪潮，感知硬件、芯片的发展速度超乎想象，这些推动着汽车从单纯的出行工具进化为能主动思考的智能生命体。从人的真实需求出发，比亚迪为汽车智能化的下半场设定了三大目标：实现“零交通事故”，让辅助驾驶成为“超级司机”，让AI成为“超级秘书”。比亚迪将持续投入超1000亿的研发资金，解决交通安全问题，提升人类福祉。

二十四年厚积薄发比亚迪自研中国首款4nm制程智驾芯片

本次发布会上，比亚迪重磅发布中国首款4nm制程智驾芯片——璇玑A3，已开启规模化量产，支持L3、L4自动驾驶，通过三颗芯片的高效协同，实现超2100TOPS的总算力，同时兼顾功耗控制与算力利用率。作为中国首款自研4nm智驾芯片，它代表中国智驾芯片的最高水平：车规级4nm，不仅制程最先进，行业第一；而且单位算力功耗最低，较同级产品低20%。璇玑A3可结合比亚迪自研算法，深度优化，算力利用率提升100%，让辅助驾驶的反应更快，处理复杂问题的能力更强，安全上限更高，实现辅助驾驶全链路可控。

早在2002年，比亚迪就组建了自己的芯片团队——IC设计部，即比亚迪半导体的前身。24年来，比亚迪布局芯片、久久为功，先后做到车规级IGBT和SiC功率芯片技术国内最早量产装车，并两度荣获国家科学技术进步奖。至今，比亚迪已推出2000多款芯片产品，应用在智能汽车、消费电子、家用电器、工业设备、光伏储能五大领域。在更为严苛的车规级领域，比亚迪已成为中国最大的芯片企业，如今，已覆盖13大类，有567款芯片产品，广泛应用于46个国内外汽车品牌。

比亚迪之所以能够推出璇玑A3，在于其背后的研发底气：目前，比亚迪芯片研发团队超7000人，累计投入超千亿，拥有4大研发基地和5座晶圆制造工厂。其中，成都工厂是中国最大的、专注车规级的12英寸晶圆工厂。论及芯片制造流程，从产品定义、架构设计、电路设计、版图设计、晶圆制造、封装到测试七大步骤，比亚迪全面覆盖，是全球唯一一家拥有芯片全流程、全链路制造能力的车企。

比亚迪开创全民城市领航时代率先承诺为城市领航安全兜底

2025年2月，比亚迪推出“全民智驾”战略，宣布全系车型标配天神之眼辅助驾驶系统。此次发布会，比亚迪贯彻“让好技术人人可享”的理念，宣布开创全民城市领航时代：全系车型均可搭载天神之眼B 辅助驾驶激光版，选装价格12000元。此外，天神之眼C 的功能即将迎来重大升级，预计今年12月OTA。

去年7月智能泊车安全兜底推出后，天神之眼智能泊车功能的使用率从最开始的21%，提升至现在的93%，并且智能泊车事故率几乎为零。基于对天神之眼技术的信心和对消费者负责的态度，比亚迪再次率先承诺为城市领航安全兜底：即日起一年内，天神之眼A、天神之眼B 的新用户自提车之日起，老车主OTA升级至天神之眼5.0 后，均可享为期1年的城市领航兜底。用户在合规使用城市领航功能时，若发生有责任交通事故，应由本车承担的直接经济损失（包括车辆维修费用、第三方财产损失、人身伤害损失）将由比亚迪直接进行兜底赔付。

对比行业常见的智驾险，比亚迪的城市领航兜底全部免费、没有上限，且不会影响来年的商业险保费。自此，比亚迪成为全球首个城市领航和智能泊车安全“双兜底”的企业，用实打实的行动，让辅助驾驶真正融入用户的日常出行和生活，让用户收获安全体验。

比亚迪持续用技术改变世界。在电动化的上半场，比亚迪用第二代刀片电池及闪充技术一举攻克“充电慢”“低温充电难”的世界性难题；而在智能化的下半场，比亚迪致力于实现“零交通事故”的目标：将用天神之眼不断刷新辅助驾驶能力的上限，用兜底给予用户使用辅助驾驶的信心，用高算力智驾芯片布局未来的智能汽车体验，用实力守护每一位用户出行的驾乘安全。比亚迪董事长王传福表示：“真正的‘敢为’，从来不是无所畏惧，而是心怀对生命、对规则、对技术的敬畏，明知难而为之，始终做难而正确的事，敢为人先，一路向前！”

大模型强化学习阶段的后训练在做什么

Mon, 25 May 2026 15:01:34 CST

大模型强化学习阶段的“后训练”，通常是指在模型已经完成预训练（以及可能的监督微调）之后，再通过强化学习进一步优化模型的行为和输出。这个过程的核心目标是：让模型的输出更符合人类的偏好、价值观、安全性要求以及特定任务的目标。

简单来说，预训练让模型学会了“接话”的能力——根据上文预测下一个词；而强化学习后训练则教它“什么话该说、什么话不该说、怎么说更好”。

具体在做什么，可以分解为以下几个关键环节：

学习“偏好”与“准则”：模型需要理解人类的偏好。研究者会训练一个奖励模型，这个模型的作用就是给大模型的回答打分。这个奖励模型的训练数据，就是大量的人类标注数据——比如，对于同一个问题，人类标注者会对比两个不同回答，选出哪个更好、更安全、更有用。
通过“试错”优化策略：大模型（此时被视为一个“智能体”）针对一个输入，会尝试生成一个回答。之后，奖励模型会对这个回答打分（给出奖励值）。强化学习算法（最著名的是PPO，近端策略优化）会根据这个奖励值，调整大模型的参数，让它更倾向于生成能获得高奖励的回答，避免生成低奖励的回答。
平衡“探索”与“守成”：训练过程中，模型不能随心所欲地乱试（可能会生成胡言乱语）。强化学习算法通常会加入一个KL散度惩罚项，强制要求模型的新策略不能离它的“初始版本”（通常是监督微调后的模型）太远。这就像给模型加了一根“狗绳”，防止它在优化过程中彻底走偏，失去基本的语言能力。
针对特定任务优化：根据最终应用场景，后训练可以有不同的侧重点。例如：
- 提高有用性：让模型更愿意遵循指令、提供更详细准确的答案。
- 提高安全性：让模型学会拒绝回答有害、不道德或危险的问题。
- 提高真实性：减少“幻觉”，让模型在不确定时承认不知道。
- 对齐特定风格：让模型的回复语气、长度、格式符合产品需求。

一个非常典型的例子就是ChatGPT的训练过程：

第一步：预训练一个基础模型（GPT-3.5/4）。
第二步：监督微调（SFT），用人工写的高质量问答对训练模型学会对话格式。
第三步（这里就是强化学习后训练）：使用RLHF（人类反馈强化学习）。具体做法是：
- 让模型针对大量问题生成多个回答。
- 人类标注员对这些回答进行排序/打分。
- 用这些排序数据训练一个奖励模型。
- 用PPO算法，让模型通过不断生成回答并获取奖励模型反馈来优化自己。

核心价值：没有强化学习后训练，大模型可能只是一个能力很强但不怎么听话的“天才儿童”。而通过这个阶段，模型变得可控、可靠、有用。它解决了预训练模型“学富五车但不懂规矩”的问题。

与其他训练阶段的区别：

预训练：学习语言结构和世界知识（学什么）。
监督微调（SFT）：学习对话格式和简单指令（学着怎么回答）。
强化学习后训练：学习价值判断和策略选择（学会判断什么才是好的回答）。

所以，大模型的强化学习后训练，本质上是一个价值观对齐和行为优化的过程，是让通用大模型变成能直接服务用户的生产力工具的关键一步。

美国AI 基建全是鬼故事

Mon, 25 May 2026 10:22:13 CST

作者

@edzitron

调查了美国在建的数据中心得出了结论：AI 基建全是鬼故事。下面是文章精华总结：目前地球上没人建成过 1GW 的园区，英伟达却卖了 300 万块 Blackwell。（GW 就是功率单位，1GW = 10亿瓦。在数据中心里，它衡量的不是‘算力’，而是‘能吃多少电’；）这些芯片在哪？在仓库里吃灰吗？建一个数据中心要多久？到底有多少真正上线了？这两个简单的问题，回答起来却难得出奇。为什么？因为超大规模厂商（Hyperscalers）既不披露数量，也不披露可用容量。过去一周，作者试图寻找 2023 或 2024 年开工并已竣工的数据中心，结果是一无所获。大多数项目要么深陷审批泥潭，要么就是个“部分启用”的烂摊子，却对外宣称“已投入运营”。事实很简单：目前没人建成过 1GW 的数据中心。 Stargate Abilene 吹嘘 1.2GW，两年过去了，只有两栋楼亮着灯，约 103MW。第三栋楼建好了，但里面空空如也。就连亚马逊那个所谓的 2.2GW 项目，30 栋楼里只有 7 栋在用，却被 CNBC 和亚马逊自己包装成“全面投入运营”。这就是骗局，赤裸裸的。然后是微软。纳德拉说过去两年新增了 4GW，本季度又加了 1GW。我也希望能信，但我找不到。作者通过卫星看了威斯康星州的 Fairwater 项目。微软说 400MW，但按照每兆瓦 1400 万美元的成本，33 亿美元的投资只对应 235MW。卫星图像显示，那地方基本上就是几块混凝土板。当地报纸说，里面还在做启动测试，根本没上线。作者在北卡罗来纳州、俄亥俄州、巴西、威尔士找了一圈。要么还在挖土，要么连土都没开始挖。微软的公关要么不回，要么就在胡扯“进度超前”。这导致了一个荒谬的结论：如果微软真的建了 4GW，那它必须秘密建成了十几个巨型园区，且没有一家媒体报道。这不可能。微软在过去六个月里，连 500MW 都没上线。那些所谓的“1GW 新增产能”，要么是会计魔术，要么是还没通电的空房子。这就引出了英伟达的问题。黄仁勋说过去四个季度出货了 600 万块 Blackwell（实际是 300 万颗，他把双核算进去了）。 300 万块 Blackwell 的功耗是 3.6GW。如果这些芯片真的在跑，我们需要 35 个 Stargate Abilene 那样的园区。但它们在哪？它们不在。它们堆在仓库里吃灰。 Blackwell 需要全新的散热和电力，旧数据中心装不下。这就是为什么 Supermicro 有价值 14 亿美元的 GPU 积压在库存里，也是为什么 Oracle 取消了 10 亿美元的订单。 Anthropic 租借 xAI 的老数据中心就是一个绝望的信号。那是马斯克用燃气轮机搞出来的、污染严重的“弗兰肯斯坦”怪物，里面塞满了老芯片。如果真有那么多崭新的千兆瓦级数据中心上线，Anthropic 为什么要急着去租这种垃圾？总结一下这场闹剧：微软、谷歌、Meta 在过去三年烧了 8000 亿美元 Capex。他们声称拥有数 GW 的产能。实际上，真正跑起来的可能只有几百 MW。英伟达把未来 2-3 年的 GPU 都卖出去了，但这些芯片没地方放。 OpenAI 和 Anthropic 承诺了 7480 亿美元的未来支出，但这取决于这些鬼数据中心能不能建成。感觉不对劲吗？是的。这感觉就像 2000 年的互联网泡沫，或者 2022 年的 FTX。我们正处于一个基础设施与财务数据完全脱节的时代。折旧费用已经开始暴涨，但当那几百亿的账单真的到来时，大家会发现，我们建的不是算力帝国，而是一片由混凝土板和公关稿组成的鬼城。我不相信有超过 100 万块 Blackwell 在运行。你们呢？看完这篇，你再看美股估值会觉得脊背发凉。 #AIBubble #Stargate #Microsoft https://wheresyoured.at/where-are-all-the-data-centers/…

AI 为什么会编程——原理、历史与未来

Wed, 20 May 2026 16:13:07 CST

我们来回顾一下AI Coding。

2021 年那会儿，AI Coding还基本是学术圈的论文话题，圈内程序员把它当作编程的辅助工具。GitHub Copilot 那年第一次发出来，火过一阵子，争议主要还是”这玩意到底该不该用，会不会让我变笨”。

到 2026 年 4 月，画面发生了剧变：GitHub 上每天约有 13 万 5000 个公开提交（commit）由 Claude Code 直接产出，约占全平台公开提交的 4%；OpenAI Codex CLI 重启一年，周活开发者破 300 万；Cursor 母公司 Anysphere 这两年的 ARR 从 0 跑到 20 亿美元，是 SaaS 历史上最快的曲线。

短短四五年，这件事完成了从”论文话题”到”日活千万级生产力工具”的跃迁。

我自己写专业代码超过十年，过去三年每天都跟这些工具打交道。这篇文章想用我的视角，把三个被反复问到、但很少有人系统答过的问题一次说清楚：

AI 凭什么会写代码？
这件事在过去五年是怎么发生的？
接下来几年，每个人真的能自己造 App 吗？

我会按”原理、历史、未来”的顺序讲下来。不需要技术背景。

一、原理：从史前到现在

1.1 史前时代：补全工具走的两条路

ChatGPT 之前，让机器写代码这件事走在两条路上。

一条是程序员用论坛式平台或者工具自助。Stack Overflow 这类问答社区做的是”全人类积累过的报错和解法都摆在这里”。你写一段代码报错，把错误信息贴上去，社区里有人答。中国对标的是 CSDN，1999 年起步的中国软件开发者社区，到 2024 年累计 4000 万注册用户、1200 万月活，是整个国内程序员的”中文外脑”。我自己 2014 年学编程时，每天工作流就是写代码、报错、复制粘贴去 Stack Overflow 搜，把答案改一改贴回去。这个流程在 ChatGPT 出现之前用了整整 15 年。

IDE 这一层也在试图帮人。Microsoft Visual Studio（1997 年首发）的 IntelliSense、IBM 主导的 Eclipse（2001 年开源）的 Content Assist、JetBrains IntelliJ IDEA（2001 年）的 smart completion，都是当年”智能提示”的代表。但它们本质是查字典：你打 str.，IDE 列出 String 类的所有方法。它不”理解”你想干什么，它在”查表”。

加载图片

52 KB

另一条是学术界的程序合成（program synthesis），目标是用形式逻辑从规约（specification）反推出代码。这条路从上世纪 70 年代算起，被困在玩具级别整整半个世纪。半个世纪里几乎只跑出来一个工业级成果，是 Microsoft Research 的 Sumit Gulwani 主导的 FlashFill，2013 年集成到 Excel 里，根据你给的几个例子自动猜出整列的变换规则。但这套思路要求形式化规约或纯净例子，对自然语言无能为力。

加载图片

20 KB

program synthesis

2020 年前后还出现过神经网络版本的代码工具，比如 Microsoft 的 CodeBERT（2020 年 9 月）、Salesforce 的 CodeT5（2021 年），都属于智能一点的自动补全。它们的根本限制还是不懂自然语言。你没法跟它对话，它也只能补一行代码，没法接一个任务。

把这几条线放一起看，问题的本质就浮上来了：要让机器真正会写代码，前提是它得先懂自然语言。这件事 2018 年之前，没人做出来。

1.2 转折点： GPT 系列怎么改局面

转折点是 GPT 系列。OpenAI 2018 年 6 月提出一种思路：先用海量自然文本做预训练，让模型学会”猜下一个词”的通用能力，再针对具体任务微调，GPT应运而生。GPT 全称 Generative Pre-trained Transformer，GPT-1 只有 0.117B（billion）参数，是个研究原型；GPT-2（2019 年 2 月）涨到 1.5B；GPT-3（2020 年 5 月）直接做到 175B，比 GPT-2 大 100 倍。规模上去之后，”懂自然语言”这件事第一次跨过了门槛。从这条线往代码迁移，就有路可走了。

写代码的模型和聊天的模型用的是同一种 Transformer 网络，做的是同一件事：看着前面已有的 tokens，预测下一个 token 该是什么。一段 Python 代码在模型眼里，和一段中文小说一样，都是 token 序列。模型并不”知道”自己在写代码，它只是沿着前面的上下文做最大概率的下一个 token 预测。

举个具体例子。最简单的斐波那契函数长这样：

def fib(n):

if n < 2:

return n

return fib(n - 1) + fib(n - 2)

模型生成它的过程，就是一个 token 接一个 token 往下猜。给定 def fib(n): 这一行之后，下一个最高概率的 token 是换行加缩进；再下一个是 if；再下一个是 n；再下一个是 <；再下一个是 2；再下一个是 :；再下一个是 return；这样一直猜下去，直到整个函数收尾。把成百万行 GitHub 代码看过几遍之后，这种”猜下一个 token”的概率分布天然就编码了语法、惯用法、变量命名、注释风格。

1.3 为什么代码这种语料特别适合模型训练

但代码这种语料特别适合被模型学会，原因有几条。

最直观的一条是代码的规律性极强。for i in range(10): 后面缩进了就是循环体，规则是死的，比自然语言稳定得多。同一个意思，自然语言可以有十种说法，代码基本只有两三种写法。这让模型从有限语料里学到的”压缩后的规则”密度远超普通文本。

再深一层，代码有客观对错。给一段函数和一组测试用例，跑一下测试就知道对错。这件事自然语言完全没有：一首诗写得好不好、一段散文动不动人，没有自动判分器。代码的这个性质后面会变成核武器。

还有一层是数据本身。每个开源仓库的 README、每段函数前的 docstring、每条 commit message，都是免费的”自然语言 ↔ 代码”对照语料。这是 GPT-3 之后所有代码模型都在吃的数据红利，量级远超人工标注能造出来的对照集。

最早一批走这条路的人，是把代码当作专门技能来训的。OpenAI 2021 年拿 GPT-3 在 GitHub 上 100 多 GB 的公开代码继续训练（这种做法叫 continued pretraining），得到 Codex 这个衍生模型。Codex 在 HumanEval（OpenAI 自己造的 164 道编程题数据集）上做到 28.8% 的首次通过率，是当年的 SOTA。那一阵 OpenAI API 里 code-davinci 和 text-davinci 就是两个独立的模型，前者写代码，后者写文。

GPT-4 时代之后，这条分家又合上了。Anthropic、OpenAI、Google 都在通用大模型的预训练数据里直接大量混入代码（公开估计占比 20% 到 40%），不再有专门的代码模型，统一一个 Claude / GPT / Gemini 既写文又写代码。

为什么会合并？因为出现了一个反常识的发现：训练里加大量代码，模型在数学、逻辑、甚至自然语言任务上都会变强。这件事最早是 DeepMind、Google Brain、OpenAI 几家在 2022 到 2023 年陆续观察到的。解释其实很直观：代码这种语料强迫模型学习”严格逐步推理”的思维方式，每一步必须严格成立，不然下一步就崩。这种思维一旦学到手，会迁移到非代码任务上。换句话说，代码训练已经成了让通用模型变聪明的核心成分之一，远超出”顺带做的副业”这个定位。

1.4 RLVR ：从”会写”到”能写对”

代码模型独有的杀手锏，是基于执行反馈的强化学习。具体的训练流程是这样：让模型生成一段代码，扔到一个真实的运行环境里跑，看测试用例通过几个，把结果（pass / fail）作为奖励信号回传给模型，让它下一次写得更好。这套方法叫 RLVR（Reinforcement Learning from Verifiable Rewards，可验证奖励的强化学习）。”可验证”是关键词：奖励信号不来自人类标注（贵、慢、有偏差），来自机器自动判分（廉价、可大规模、客观）。代码、数学题、形式化逻辑这几类任务都满足”可验证”，是 RLVR 最适合的场景。

加载图片

30 KB

DeepSeek 2025 年初放出来的 R1 模型把这条路推到极致：先用强化学习在数学和代码上把推理能力训出来，再迁移回普通对话场景，在多个 benchmark 上追上同期的闭源前沿模型。Claude Code、OpenAI o3 / Codex 这条线背后的训练大头，也都是 RLVR。这件事 2024 年之后才成为主流，是代码能力在过去两年涨这么快的核心原因。

整理一下。今天的代码能力是两件事的合成。一件是代码训练把通用大模型整体推到了一个新台面，让”先把问题分步、再每一步成立”这种思维方式渗进了模型的默认行为。另一件是在代码、数学、推理这类有客观对错的任务上叠加了大量基于真实执行的强化学习，把模型从”会写”训到”能写对”。这两条合起来，才是 AI 编程的真正引擎。

二、 AI Coding 公司发展史

2.1 起源：双雄站位与早期工具（ 2020 - 2022 ）

GPT-3 在 2020 年 5 月发布，175B 参数，规模上去之后，OpenAI 第一次有了把模型卖给开发者的底气。2021 年 7 月，他们拿 GPT-3 在 GitHub 公开代码上继续训练，得到 12B 参数的 Codex 衍生模型，搭载到 GitHub 推出的 Copilot 里。这是 AI 第一次进入程序员的”肌肉记忆”。每天敲 Tab 几百次接受补全建议，这个习惯就是从那个夏天开始的。

加载图片

25 KB

但 Copilot 当时形态有限：上下文窗口只有 2k 到 8k token，看得到的是当前文件局部，被动响应你不打字它不动。它适合补一行，不适合做一件事。

模型这一边，Anthropic 几乎同时起步。它的两位掌舵者是 Dario 和 Daniela Amodei 兄妹，2020 年底从 OpenAI 出走，2021 年 1 月把公司做出来，团队带走了一批 GPT-3 时代的核心研究员（Tom Brown、Jared Kaplan、Sam McCandlish 等人）。Anthropic 把”模型的诚实性、可控性、对长上下文的理解”作为差异化方向，这套底色后来变成 Claude 在代码任务上的天然优势：长代码库读得进去、复杂指令听得懂、对自己不确定的部分愿意说”我不确定”。

2022 年 11 月 OpenAI 发出 ChatGPT，AI 编程的形态从”补全工具”变成”对话伙伴”。但那时 ChatGPT 编代码经常一本正经地胡说八道，自信地编一个不存在的 API。同期出现的 Claude 系列，体感上的代码准确率明显高于 ChatGPT，是工程师圈里的”小众选择”。

ChatGPT 起飞之后，一整套”程序员的外脑生态”开始被重写。Stack Overflow 是受冲击最直接的一家：2008 年 9 月由 Joel Spolsky 和 Jeff Atwood 创立的全球程序员问答社区，2017 年峰值时每月新问题超过 30 万、月访问量超过 1 亿、累计注册用户破 1000 万。但 ChatGPT 之后，每月新问题数从 2017 年峰值的 30 多万一路掉到 2023 年的约 8.7 万、2024 年不到 6 万；到 2025 年 12 月只剩下不到 4000 个新问题，回到 2008 年刚上线时的水平。CSDN 也在掉。专做 AI 代码补全的早期创业公司 Kite，2014 年成立、是最早一拨 AI 编程工具，2022 年 11 月关闭，留下一句”我们是早了 10 年的产品，技术那时还没到”，500,000 月活也没能把它撑活下来。Codecademy、W3Schools 这一类教程站的流量也在持续下滑。

加载图片

45 KB

2.2 范式革新：编辑器革命到智能体时代（ 2023 - 2026 ）

2023 年 GitHub 把 Copilot 扩到对话，发出 Copilot Chat。但侧边栏聊天加 IDE 主区写代码，体验是分裂的，AI 始终被关在角落里。

真正改整个范式的是 Cursor。母公司 Anysphere 是 4 个 MIT 学生 2022 年起步做的，关键判断是把 VS Code 整个 fork 出来重写。fork 比做插件难得多，但能让他们改编辑器本身的交互。Cursor 真正的技术贡献是 codebase indexing，把整个项目全量向量化，让 AI 第一次能”看见整个项目”。这套范式后来定义了行业标准：模型用别人的（Anthropic / OpenAI），工程层是自己的（项目索引、上下文组织、UI 工作流）。

加载图片

59 KB

2024 年 10 月 Claude 3.5 Sonnet 升级版发布，SWE-bench Verified（一个由人工核对过的真实 GitHub bug 修复 benchmark）上的分数从前一代的 33% 跳到 49%。”AI 真的能写代码”这件事从这一刻第一次成立。Cursor 的体验在那几个月发生质变，工程师圈从 Copilot 大批往 Cursor + Claude 迁移。我自己 2024 年底切过去，三个月之内代码产出感觉翻了一倍。

接下来 2024 到 2025 年，整条线从”IDE 内的补全”往”智能体（agent）”方向跳了一步。Devin 是 Cognition Labs 2024 年 3 月发的，第一个把自己定位成”AI 软件工程师”的产品。营销大于实际，但定调了”端到端任务级 agent”的产品形态：给它一个目标，它自己去拆任务、写代码、跑测试、改 bug。

加载图片

71 KB

从那之后，最近一年的竞争主要落在三家头部产品之间。Codex 这个名字 OpenAI 用了第二次：第一次是 2021 年作为 GPT-3 衍生模型，作为 Copilot 的引擎；2023 年被弃用迁到 GPT-4；2025 年 4 月 16 日以”产品名”重启，这次是 Rust 写的命令行 agent。重启势头很猛，2026 年 3 月周活做到 200 万，4 月跳到 300 万，环比涨 50%；ChatGPT 企业版里 Codex 用户从 1 月到 4 月翻了 6 倍。

加载图片

402 KB

Claude Code 在工程师圈的渗透更深。Anthropic 2025 年发出来之后，靠 Claude 在长代码库上的天然优势，2026 年初做到约 25 亿美元年化收入（ARR），每天产生约 13 万 5000 个公开 GitHub 提交，占全平台公开提交的 4%。SemiAnalysis 预测它到 2026 年底会涨到 20% 以上。

Cursor 自己的体量也在快速涨。2026 年 2 月做到 20 亿美元 ARR，4 月在以 500 亿美元估值融资，是 SaaS 历史上从 0 跑到 20 亿美元最快的曲线。

剩下几家也有特点。Windsurf（前身 Codeium）是另一个 AI 原生 IDE，2025 年中被收购之后情况变复杂。GitHub 老牌玩家也追了上来，把 Copilot 升级成 Agent Mode 和 Coding Agent，老用户自然转化过去。

整体看下来，今天工程师圈的格局：资深程序员主流是 Cursor + Claude Code 组合，IDE 写代码加命令行跑大任务。

2.3 国内赛道和外行使用

主线之外，有两条值得单独说：国内厂商，以及面向非程序员的外行赛道。先说国内。

国内这个赛道是和海外平行展开的，几家大厂各占一席，开源那一拨也有自己的位置。

字节做的 Trae 是国内体感最接近 Cursor 的 AI 原生 IDE，2024 年底前后上线，初期对个人完全免费的策略让它在国内开发者圈渗透很快。Trae 接的是字节自家的豆包大模型，在中文项目和中文注释场景下，体感比直接用 Cursor 顺。同期字节还有一个更早的产品叫 MarsCode，定位偏向云端 IDE，跟 Trae 形成内部分线。

阿里的通义灵码是国内最早一批的 AI 编程助手，2023 年发布，作为 VS Code 和 JetBrains 系列 IDE 的插件存在，背后接通义千问 Qwen 系列模型。它在阿里云生态内的企业客户里渗透最深：钉钉、阿里云的内部团队和云上客户大量在用。Qwen 系列也是国内开源大模型里代码能力最强的一档。

百度的文心快码（Comate）有一个值得单独说的特性：SPEC 模式，强制先写需求文档、再让 AI 按文档写代码，把”PRD → 设计 → 开发”这条工程流程装进了 IDE 里。这套打法在国内大厂的内部研发场景里挺受欢迎，因为大厂的代码标准和合规审查严，AI 自由发挥的代码很多过不了 review。文心快码是国内少有的、走出工程化深度差异化的一家。

剩下几家。腾讯的 CodeBuddy 接的是混元大模型，主要走腾讯云生态。智谱的 CodeGeeX 是国内最早一批专门的代码模型，2022 年起就在做，今天也是国产代码 LLM 里开源版本最完整的一家。华为的 CodeArts 捆绑在华为云的 DevOps 套件里，主打央企和大型国企客户。

整体看下来，国内的真正优势在三条：中文场景适配明显更好、和国产云绑得紧、企业级落地路径短，加上个人版基本免费。短板也实在：前沿模型能力仍落后 Claude Opus 系列和 GPT-5 系列，在复杂多文件、跨仓库的智能体任务上还有可见差距。差异化的真正空间在两条，一是模型能力本身继续追，DeepSeek、Qwen、智谱都在做；二是把具体行业流程吃进工具里，文心快码的 SPEC 模式就是这个方向。

再说外行赛道。Vibe Coding 这一类工具的定位是让非程序员也能造 App：你用自然语言描述需求，AI 直接给你一个能跑的应用。这条线最近一年起得很快，每家有自己的切入点。

Lovable 是这一波里跑得最猛的。瑞典人 Anton Osika 2024 年做出来，从 0 到 4 亿美元 ARR 用了不到一年，全公司只有 146 人。它的产品形态是一个聊天框加实时预览：你说一句”我要一个看板，能拖拽卡片，能跟 Slack 同步”，Lovable 直接给你生成前端加 Supabase 数据库的全栈应用，几分钟内在浏览器里跑起来。

加载图片

69 KB

StackBlitz 做的 Bolt.new 走的是另一条路：在浏览器里写完整全栈应用，不依赖任何本地后端，跑在浏览器内嵌的 WebContainer 里。你描述需求，它生成代码、装依赖、运行起来，全程不用本地装环境。Bolt 在创业者和教育场景里渗透得特别快。

加载图片

43 KB

Vercel 的 v0 切的是 UI 设计这个口子。你给它一段描述或一张草图，它生成一个 React 组件，能直接拖到你已有的项目里。v0 不试图做整个 App，在前端组件这一段做得最精，是设计师和前端的高频工具。

加载图片

26 KB

Replit Agent 是老牌在线 IDE Replit 2024 年 9 月发的智能体产品，强调”从需求到部署，一个 agent 跑完”。Replit 的优势是它本来就有完整的云端运行环境，agent 跑完直接就在云上跑起来。Base44、Mocha、Glide 这些更新的入局者，定位偏企业内部小工具，主要解决”5 个人的小团队想要一个内部表单或仪表盘”这种长尾需求。

把整条外行赛道压一句：Vibe Coding 已经把造 demo 的成本砸到地板。一个有产品 sense 的人凭一个想法做出来一个能展示的 demo，过去要一周以上，现在一个下午就行。但从 demo 到真正能用的产品中间还隔着整个软件工程行业的活，这个鸿沟留到第三章细说。

三、展望未来

3.1 做 App 是个系统工程， AI 编程只解决了一环

现在经常可以看到这样的口号，让不懂一行代码的外行，可以直接做出一个app，躺着数钱。我们先不说需求端，我们来看技术方面。

外行直接造 App 这个口号，有真的部分，也有需要打折的部分。先看一眼以前在公司里做一个像样的功能是什么样。

软件工程把做软件这件事拆成几个阶段，是有正式标准的。最权威的一份是 ISO/IEC/IEEE 12207《系统与软件工程：软件生命周期过程》，1995 年首发，2017 年更新到现行版，给软件全生命周期定义了几十个标准过程。各国大学的软件工程教材讲的也是这套生命周期：需求、设计、开发、测试、上线、运维。

国际标准之外，国内大厂也把这套生命周期落地成了自己的工程规范，且不少是公开的。阿里巴巴 2017 年发出《阿里巴巴 Java 开发手册》（项目代号 P3C），分编程规约、异常日志、单元测试、安全规约、工程结构、MySQL 数据库六大维度，配套 IDE 插件累计下载超过 160 万次。美团技术博客（ tech.meituan.com）专门写过大量灰度发布、故障复盘、产品上线流程的实操文章。国外更彻底的是 GitLab，把整个公司的研发流程开源做成公开手册（GitLab Handbook，几十万字）。这些材料让外部读者能直接看到大厂内部的研发节奏，骨子里都遵循同一套生命周期。

一个像样的功能在大厂里走的流程是这样：需求阶段（PRD + 评审）、设计阶段（UI/UX + 评审 + 技术方案 + 技术评审）、开发阶段（任务拆分 + 前后端开发 + 联调 + 代码评审）、测试阶段（自测 + QA + bug 循环 + UAT）、上线阶段（灰度 + 全量 + 监控应急）、验证回收（数据验证 + 复盘 + 归档）。一个像样的需求走完这条流程，少则两周，多则两三个月。

这条流程每一环都是在堵一个真实的坑。PRD 评审堵的是做出来不是想要的，技术评审堵的是架构上选错了半年后推倒重来，代码评审堵的是代码能跑但维护不了，QA 堵的是上线就崩，灰度堵的是出 bug 影响所有用户。每一环都是过去几十年血泪经验的沉淀。

回到 AI 这边，它今天能直接吃掉的环节其实不止写代码这一个。把每个阶段、每个子环节里 AI 真正能切多少，挨个过一遍。

加载图片

50 KB

3.1.1 需求阶段（ PRD + 评审）

PRD 这一段 AI 已经能做不少活：把零散想法整理成结构化文档（背景、用户画像、流程图、验收标准），扫已有功能找冲突点，列边界条件，甚至自动生成数据埋点和 A/B 实验设计。但 PRD 评审会本身 AI 替不了。评审要 4 到 6 个不同岗位的人坐下来吵：业务方关心 ROI 和发布节奏，产品关心用户体验，工程关心实现成本和技术债，QA 关心可测性。这种跨岗位的拉锯和共识形成，需要的是组织协调，AI 帮不上忙。

3.1.2 设计阶段（ UI/UX 和技术方案）

设计阶段实际有两条线：UI/UX 和技术方案，每条线各带一次评审。

UI/UX 这条线被 AI 吃得最透。v0、Figma AI 这类工具几分钟就能从一句话生成一个能跑的 React 组件，样式系统都能配好。设计评审里的形式化检查，比如风格有没有对齐、组件有没有复用已有库，AI 也能跑一遍。但一个交互到底符不符合品牌调性、用户走完这一步下一步会做什么，这种判断还是要资深设计师拍板。

技术方案这条线 AI 也已经很有用。给它一段需求，它能列出三套候选架构，把吞吐、延迟、成本对比清楚。但最后选哪一套要人来定，因为选型背后是一堆 AI 不知道的组织约束：团队熟悉哪个栈、有什么合规要求、对外承诺了什么 SLA、关键人员稳不稳。技术评审会上的辩论更是如此，往往是为什么不用 X、为什么不用 Y、为什么这次必须做 Z，每一句背后都有一段团队历史。AI 没坐过这些会，跟不上节奏。

3.1.3 开发阶段（编码与评审）

开发阶段是 AI 真正的主战场，但里面也有 AI 切不动的硬骨头。

先说 AI 能直接做的。任务拆分这一步 Claude Code 已经能从 PRD 直接生成 issue list 和依赖图。前后端开发是 Cursor + Claude / Codex 的核心使用场景，资深工程师里 2 到 10 倍的效率提升是普遍体感。联调（前后端打通接口）AI 能自动起 mock server、跑契约测试、扫接口签名不一致。代码评审 AI 也能做静态分析、规约检查、潜在 bug 标记。

但代码评审里有一层 AI 跟不上：架构判断。这次改动会不会让模块边界变模糊、这套抽象未来三年好不好维护、这个解耦在团队的下一阶段规划里是不是合理，这种 review 还是要资深 reviewer。

更硬的骨头是跟外部世界打交道的那一段。要接一个第三方 API（微信支付、Stripe、Google Maps），AI 能把调用代码写得很标准，但 API key 怎么申请、商务怎么谈、KYC 怎么过、回调地址怎么备案，这些步骤要真人去走流程。要做权限管理（OAuth、SSO、公司内部 IAM、云上 RBAC），AI 能写规则和代码层，但谁该有什么权限、合规和 GDPR 是不是过得了、出事谁负责，仍然是组织决策。这一类卡点跟 3.2 节要说的”非程序员造 App”碰到的问题是同根源的。

整体看下来：开发阶段纯代码部分 70% 到 80% 的活 AI 能直接做，剩下的 20% 到 30% 一部分是架构判断和疑难调试，另一部分是接外部 API、做身份和权限这类需要走人工流程的硬骨头。

3.1.4 测试阶段（自动化与人工验收）

测试阶段是 AI 的第二大主战场。

自测和 QA 这两步 AI 几乎全包。自测里 AI 自动生成单元测试和集成测试，覆盖率比人手写的高很多。QA 阶段 AI 能跑全量回归、做 fuzzing（用随机输入压测程序找崩溃点）、扫边界条件。fuzzing 以前因为成本高、回报低很少做，AI 把它的边际成本降到几乎为零。

bug 循环 AI 也已经在闭环。从错误堆栈定位代码、生成修复 patch、提交 PR，不少团队 80% 的 P3 / P4 级 bug 在 AI 流水线里直接走完。

UAT（用户验收测试）AI 替不了。这一步要真用户在真场景里点一遍，看产品和用户预期对不对得上。代码正确性的所有测试 AI 都能跑，但产品贴不贴用户需求，只有用户自己能判断。

3.1.5 上线阶段（执行与决策）

上线阶段分两段：执行和决策。

执行这一段 AI 已经能完整接管。灰度发布的细节（按比例放量、按地域放量、按用户 cohort 放量）和全量发布的步骤都能自动跑。监控告警、异常检测、针对预定义场景的自动回滚也都已经成熟。

决策这一段还是人在拍。灰度跑到 10% 之后核心指标抖动了，要不要继续推、要不要 rollback、要不要先 hold 住调查，每一个动作都要权衡：往前推一格 5% 的回滚成本，往后推一格全量的风险。这种 go/no-go 决策光看仪表盘是拍不出来的，背后还有业务节奏、合作方协调、市场窗口一堆 AI 看不见的因素。

更难的一类是没见过的事故。第三方依赖挂了引发级联故障、某个区域机房断电、某次安全事件需要紧急下线，这种没在 runbook 里的情况，处置方案还是要 oncall 工程师来定。

3.1.6 验证回收（数据验证 + 复盘 + 归档）

数据验证 AI 可以拉指标、生成可视化、给三到五种可能的归因解释，但”这个功能转化率没达到预期，是用户不需要、还是入口太深、还是定价错了”这种判断要产品经理结合定性数据来决定。复盘会 AI 替不了，复盘的核心是组织学习：这次教训怎么变成下次的工程规范、谁该承担什么责任、流程要不要改，这是人对人的事。归档环节 AI 完全可以自动化，文档结构化、链接知识库、生成检索索引，这些是 AI 干得最干净的活。

把六个阶段连起来看一张图。

加载图片

59 KB

今天 AI 在整个研发流程里能直接替的工作量，按子环节加权大概是 50% 到 60%。开发和测试两个阶段占的份额最大，各自有 70% 到 85% 的活 AI 能直接做；需求、设计、验证回收这几段，AI 能切的子任务多在 30% 到 50%；上线阶段里执行部分几乎 100% 自动化，但 go/no-go 决策仍是 0%。

换个说法：AI 已经把每个阶段”做完”的成本拉到很低，每个阶段”拍板”的那一下还得人来。

剩下的 40% 到 50% 的人工部分，再往下能不能继续被 AI 吃掉？这是判断未来若干年走向的关键问题。里面分两类。

第一类是技术上还差一截、但有路可走的：基于团队历史的架构选型、复杂归因、跨多文件 / 多仓库的疑难调试、未见过事故的应急处置。这些今天 AI 做不到，主要是上下文不够长、对组织语境不熟悉、对长期演进缺乏概念。模型继续涨上下文、加上长期记忆、在团队代码库里持续训练，五年内有希望吃掉这里面的一大半，把流程整体推到 70% 到 80% AI。

第二类是技术再涨也吃不动的：跨人共识、承担责任、对接真实世界（KYC、商务谈判、合规审批、法律责任）。这些卡点的根子在制度，跟模型能力没关系。要 AI 真正接手，前提是 AI 能作为法律主体存在，能签合同、能持账户、能为后果负责。已经有创业公司在做”为 AI agent 持有账号、承担责任、买保险”的法律实体，但这条路涉及法律、监管、社会接受度，时间窗口是 5 到 10 年。一旦走通，剩下的 20% 到 30% 也会被吃掉，软件研发就会进入下一个范式：人只剩出题人和最终拍板人两个角色，其它全是 AI。

短期内（未来 2 到 3 年）整个流程从现在的 50% 到 60% AI 推到 70% 到 80% AI 是大概率事件，途径是模型能力持续进步加上工具链填齐。要再往上走到 90% 以上，模型本身已经不够用了，得靠制度突破。

这件事有学术背书。IEEE 的 SWEBOK V4（2024 年 10 月发布的软件工程知识体系）列出 18 个知识域，AI Coding 主要覆盖其中的”软件构造”和部分”软件测试”，剩下 16 个知识域（需求工程、软件架构、软件安全、软件维护、软件配置管理、软件工程经济学等等）AI 只能做辅助。把每个 App 当作一棵树，AI 砍下了最高最壮的一根树枝，剩下的根、干、其他枝条还得人来扶。

工程师视角下，这个迁移已经在重新定义人和机器的分工。我自己的体感是这样：人定义问题、把关结果、处理复杂部分；AI 写代码、跑测试、修常规 bug。从 2022 到 2026，code review 的粒度也在变。2022 年程序员每行代码都自己看；2024 年看的是 PR 级别的 diff；2026 年越来越多场景下，看的是 issue 级别的结果（这个 bug 修好了吗，这个功能跑通了吗）。工程师没失业，但工作内容里写代码这部分的占比快速下降，判断、审查、验收的比重上来。

3.2 是否会有”外行一键造 App ”的神器

回答这个问题，先把上一节那张大厂研发全流程图拿过来，对照看一遍：对于一键造 App 的场景，哪些环节其实根本不需要 AI 替，可以直接省掉。

需求阶段 :

几乎可以全省。你一个人就是需求方加决策方加用户，脑子里有想法直接说就行，不需要 PRD 文档化、不需要跨部门评审、不需要业务对齐会。

设计阶段 :

大幅简化。UI/UX 让 AI 自动生成，接受厂商的默认风格就行，没有品牌调性的拉锯。技术方案这一段在 Vibe Coding 工具里被默认死了：Lovable 给你 Next.js + Supabase， Bolt.new 给你 WebContainer + 内嵌 Vite，你没得选，也不用选。技术评审会因此整个消失。

开发阶段 :

保留，但只剩 AI 写代码这一段。没有任务拆分会，没有联调（前后端是同一个生成的栈），没有代码评审（你自己看跑不跑得起来就行）。

测试阶段 :

大幅退化。自测等于你自己点几下，QA 和 bug 循环退化成”我用着舒不舒服”，UAT 在自己用的场景下根本没有这一步。Lovable 直接在浏览器里跑，崩了重生成。

上线阶段 :

几乎全省。一个人用谈不上灰度，全量等于”自己打开网址访问”，监控应急对应不到这个规模。出问题重新生成一次就完事。

验证回收阶段 :

也基本不存在。没数据可验证（用户就你自己），没复盘会议，归档让 AI 自己干。

省下这些之后，一键造 App 的真实流程就剩三步：你描述需求 → AI 生成加部署 → 你自己用。这条精简流程能不能 100% AI 化？答案要分两类场景看，每一类还要再分一层。

3.2.1 自己用的、一次性的、内部的小工具

这一类今天确实已经基本 AI 化了。但内部其实分两种架构。

最干净的一种是纯前端、跑在浏览器里、关掉就没的。Anthropic 的 Artifact、OpenAI 的 Canvas、Vercel 的 v0、 Bolt.new 都属于这种。它们生成的工具没有后端、没有数据库、没有用户登录，就是一段 HTML + JavaScript 在浏览器里跑，stack 简到只有 React + Tailwind 一两个文件。临时计算器、UI 原型、数据可视化、文档格式转换是典型场景，今天确实是一句话描述、几分钟拿到、连账号都不用注册，AI 一条龙包圆。

复杂一点的是有简单后端、能存数据、可能多人用的。Lovable 的”前端 + Supabase”组合是典型代表，stack 大概是 Next.js + Tailwind + Supabase（数据库 + Auth）+ Vercel 部署，跟我自己在 indie 项目里用的标准技术栈基本一致。这一类的代码 AI 能 100% 写，但人还要做几件 dashboard 操作：去 Supabase 注册账号、新建 project、复制 URL 和 key；去 Vercel 把 repo 接进去、粘环境变量、点 Redeploy。AI 打不开浏览器控制台，所以这一段卡在那里。个人记账带云端同步、小型内部审批流、几个朋友共用的协作小工具属于这一档。

两种加起来，个人和内部小工具的场景今天已经接近 95% AI 化，剩下的 5% 是 Human 在控制台粘几次 key。

3.2.2 给别人用的、能上 App Store 或者能收钱的正式 App

这一类的现实情况是：AI 能把代码 95% 以上写完，人主要做的是控制台点击和审批走流程。展开看，控制台点击里又分技术性的和制度性的两层。

技术性那一层，AI 写代码、人配凭证。一个标准的 indie App stack（Next.js + Supabase + Stripe + Resend + Vercel）跑起来，AI 这边做的事大约是：写所有 TypeScript 代码、写 Prisma schema、跑 db push、写 Stripe checkout 和 webhook 处理、写邮件模板、装依赖、git push 触发部署。人这边要做以下的 dashboard 操作（只是一个范例）：

Supabase 建 project、配 OAuth providers（粘 Google / GitHub 的 Client ID + Secret，这俩还得自己去 Google Cloud Console 和 GitHub OAuth Apps 申请一遍）、配 redirect URL
Vercel Import GitHub repo、粘环境变量、改 Build Command、改完 env 手动 Redeploy
Stripe 建 Product、拿 Price ID、上线后建 Webhook endpoint、复制 Webhook Secret 粘回 Vercel
Resend 拿 API key、验证自己的发件域名

接外部 API 走的也是这条路。AI 把调用代码写好，但 API key 怎么拿、商务怎么谈、webhook URL 怎么备案、回调地址怎么注册，要人去对应平台的控制台走流程。AI 今天打不开浏览器，绕不过去。

制度性那一层，是 AI 永远办不到的：

KYC 实名认证（得拿身份证加银行账号去注册主体）
业务资质（要在国内做支付，得 ICP 备案、营业执照、有时还要对接支付牌照）
法律责任（用户数据被泄、被骗、被侵权，得有人去承担）
App Store 上架（Apple、Google 不给 AI agent 开发者账号，每年的实名加年费要人）

两层加起来，给别人用的正式 App 今天大约是 90% AI 加 10% Human dashboard。”一句话造一个真 App”严格说做不到，但已经做到了”一句话加 10 次粘 key”造一个真 App。

这跟”外行直接造 App”那个口号对得上吗？大致对得上技术性那一层，对不上制度性那一层。一个完全没接触过编程的外行，理论上跟着 Lovable 加 Stripe 加 Vercel 的引导文档走，可以发出来一个能收钱的 SaaS。但前提是 ta 愿意去办公司、过 Stripe KYC、签合规文件、当法人。这一段跟 AI 能力没关系，看的是 ta 愿不愿意当老板。

3.2.3 未来两条路

那剩下的人工部分，再往下能不能继续被 AI 吃掉？分两条路看。

技术这条路负责吃 3.2.1 里剩的 5% 和 3.2.2 里技术性那一层的 10%。AI 自己还在快速吃掉精简流程里剩下的活：自动连支付、自动过 OAuth 授权、自动部署加域名加 HTTPS、自动监控自动回滚。更关键的是，浏览器 agent 已经走到了产品化阶段，比如 Anthropic 的 Computer Use、OpenAI 的 Operator，让 AI 能代为登录 Supabase、Vercel、Stripe 这些控制台、点点点、粘 key、Redeploy。一两年内，3.2.1 那两种自己用的小工具会基本 100% AI 化；3.2.2 里 10 几次 dashboard 操作的大半也会被浏览器 agent 接管，正式 App 的技术性那一层从今天的 90⁄10 推到 95⁄5 是大概率事件。

制度这条路要慢得多，负责吃 3.2.2 里制度性那一层。AI 法人能不能成立、能不能持账户、能不能签合同、出事怎么追责，这些是法律和监管要解决的问题，跟模型能力没关系。已经有创业公司在做”为 AI agent 持有账号、承担责任、买保险”的法律实体，但要走通，需要立法、判例、社会接受度同时到位，时间窗口是 5 到 10 年。一旦走通，给陌生人用、能收钱、能上架的真 App 也会被一键造工具吃掉，软件分发的整个版图就要被重写。

一句话：自己用的小工具今天已经一键搞定；给别人用的真 App 今天做到一句话加 10 次粘 key，1 到 2 年内浏览器 agent 把粘 key 那一段也吃掉，5 到 10 年后 AI 法人成立，最后的制度卡点也才被跨过去。

加载图片

234 KB

3.3 这一波 AI 编程会重塑 PC / 手机 App 生态吗

会，但重塑的方向跟很多人的直觉相反。先把几条变量摆清楚。

3.3.1 供给 100 倍，需求还是 1 倍

3.1 和 3.2 已经把”造一个 App 的门槛”讲透了。今天 Lovable 加 Vercel 加 Stripe 这一套下来，过去要 5 个人 6 个月的活，1 个人 1 个周末就能跑出来。供给侧的产能至少翻 10 到 100 倍。

但需求侧没动多少。每个人每天还是 24 小时，平均盯着手机的时间已经 5 个小时左右，再上去基本到顶。一个人手机上常用的 App 就是 10 到 20 个，装的 60 到 100 个里大半冷启动一次就再也没点过。这是过去十年很稳定的结构。

供给翻 100 倍、需求不变，结果只能是中间那层被拍扁。具体哪一层会被拍扁，要分类型看。

最先扛不住的是工具型长尾 SaaS。报销系统、内部仪表盘、个人记账、记单词、计步器、临时表单生成器，这些过去靠卖年费活着的小工具，今天用户自己用 Lovable 半小时就能撸一个。SaaS 公司收 100 美元一年还在解释功能，AI 生成的版本免费且更贴合自己的需求。这一层大面积消失只是时间问题。

垂直行业 SaaS 复杂一点。给律所做的合同管理、给医院做的排班、给小学做的家校沟通，这些有行业知识沉淀的产品没那么容易被一句话生成。但它们也会承压：客户内部的 IT 部门可以拿同样的 AI 工具生成一个内部版本，不再付月费。这一层会被价格战打到很薄，可能砍掉一半的市场容量。

社交、内容、电商、地图这一层基本不动。这一层的价值不在代码，下一节单独说。

3.3.2 头部 App 不会被取代，反而更强

微信、抖音、淘宝、Google Maps、Instagram、WhatsApp 这一类头部 App，AI 编程动不了它们的根。原因有四条。

网络效应。微信的价值 90% 来自其他 10 亿用户在上面，你做不出一个只有你一个人用的微信。Lovable 一个晚上能给你生成一个长得像微信的 App，但里面没有任何一个你想聊天的人。

数据沉淀。抖音过去 8 年攒下来的用户行为数据是它推荐算法的真正护城河。一个新的”AI 生成的短视频 App”零冷启动，没有任何数据，推荐系统从第一天起就比抖音差几个数量级。

内容和供给生态。淘宝有几百万商家、上亿 SKU、稳定的物流和支付。AI 生成的”我的购物 App”打开里面什么都没有。

分发入口。Apple、Google、Meta、ByteDance 把着用户每天打开手机时第一眼看到的位置，这一层 AI 编程根本碰不到。

更反常识的是，AI 编程会让这些头部 App 的优势更深。它们内部用 AI 提速 10 倍迭代，用 AI 处理客服、做推荐、生成内容、做反作弊，规模优势加上 AI 让产品质量进一步拉开。过去一个新创业者还能靠”做得比微信好”这种梦活几年，AI 编程时代连这个梦都没了。

3.3.3 长尾 App 退化成按需生成的 capability

把 3.3.1 和 3.3.2 合起来推一格，几年后的手机格局可能是这样。

头部 App 大约还是 20 到 30 个，跟今天差不多，但每个都更强、更难被替代。微信、抖音、淘宝、银行 App、地图、邮箱、相机这一类，仍然是装着、长期用、跨年攒数据的形态。

中间那一层（工具型 / 单功能 / 长尾）从今天的几十个塌掉，剩下不到 10 个。日历、笔记、密码管理这种个人数据持续累积的还会留，但绝大多数小工具被替代。

替代它们的是临时生成的 Capability。你跟手机里的 AI 助手说”我想记一下这次旅行的开销”，AI 现场给你拼一个表单加表格加简单图表，旅行结束你就把它删了，下次旅行再生成一个新的。Anthropic 的 Artifact、OpenAI 的 Canvas、Apple Intelligence 的 App Intents 已经在做这件事，只是还没普及到所有用户。

这种 Capability 的特点是：用完即弃、个人定制、零安装、无月费、不进 App Store。它跟今天的 App 是两种完全不同的形态。

3.3.4 重构后的生态：三层结构

把上面的拼起来，未来几年的 App 生态大概是这样的三层。

头部层。微信、抖音、淘宝、Apple、Google、Meta 这些。它们靠网络效应、数据、内容生态站稳。AI 编程让它们更强，没让它们变弱。这一层的玩家数量在收缩，每家份额在变大。

助手层。这一层会冒出来。用户的入口从打开某个 App 变成跟 AI 助手说一句话。AI 助手会调用底层模型现场生成一次性的小工具，或者调用某个头部 App 的 API 做事。这一层目前的雏形是 ChatGPT、Claude、Apple Intelligence、Google Gemini 这类通用助手。谁能占住这一层是未来几年最大的战场，因为它有可能蚕食 App Store 的分发地位。

模型层。Anthropic、OpenAI、Google 三家加上 DeepSeek、阿里 Qwen、字节豆包，靠卖 token 和能力赚钱。AI 编程的繁荣首先让这一层赚到钱，因为每一次 Capability 生成、每一次助手调用都在烧 token。

这个新生态对几类玩家的意义不一样。头部 App 平台还在涨，模型层在涨。中间冒出来的 AI 助手层是兵家必争之地，可能会有 1 到 2 家新巨头出来，也可能被现有的几家瓜分。原来做长尾 SaaS 的公司最难过，除非能赶在生态成型前转型成助手层的 Capability 提供商，或者垂直深耕成行业内的”小头部”。

普通人的视角：手机里仍然有 20 到 30 个常用 App，跟今天差不多；多出来一个 AI 助手随叫随到给你拼临时工具；少了一堆装了一次再也没打开过的鸡肋 App。打开手机的第一动作从找那个 App 的图标变成跟 AI 说一句话，这是 iPhone 之后入口形态最大的一次迁移。

加载图片

82 KB

四、结语

把整篇文章压成几条能记住的话。

原理。

AI 会写代码，靠两件事的合成。一件是代码训练把通用大模型整体推到了一个新台面，让”先把问题分步、再每一步成立”这种思维方式渗进了模型的默认行为；这件事最反常识的一面是，代码训练的真正受益者远不止写代码这个任务，整个语言模型的逻辑能力都被它拉高。另一件是 RLVR（基于真实执行反馈的强化学习），让模型从”会写”训到”能写对”，在过去两年把代码能力推上了今天的水平。代码的三个特性（规律性强、有客观对错、自带文档）决定了它天然适合被模型学会，也是 AI 整体变聪明的核心训练成分。

公司发展史。

从 2021 年 7 月 OpenAI 把 Codex 塞进 GitHub Copilot 的肌肉记忆，到 2022 年 11 月 ChatGPT 起飞顺手把 Stack Overflow、Kite、Codecademy 这些前 AI 时代的程序员外脑生态拍扁，再到 2024 年 10 月 Claude 3.5 Sonnet 升级版让”AI 真的能写代码”第一次成立、Cursor 的 codebase indexing 定义新的 IDE 范式，再到 2024-2025 智能体转向、最近一年 Codex CLI 加 Claude Code 加 Cursor 三家头部之间几十亿美元 ARR 的竞速。国内字节 Trae、阿里通义灵码、百度文心快码、智谱 CodeGeeX 几家平行起步；外行赛道 Lovable、 Bolt.new、v0、Replit Agent 把”造 demo”的成本砸到地板。这五年是 AI 产品形态进化最快的领域之一。

系统工程。

软件工程是一条 ISO/IEC/IEEE 12207 标准定义、阿里 P3C 和美团技术博客落地过、SWEBOK V4 用 18 个知识域涵盖的完整生命周期：需求、设计、开发、测试、上线、验证回收。AI 今天能直接替的工作量，按子环节加权大约 50% 到 60%。开发和测试两个阶段被 AI 吃得最透（各 70% 到 85%），需求、设计、验证回收这几段 AI 能切的子任务多在 30% 到 50%。剩下 40% 到 50% 的人工部分里，技术能吃的还有一截（架构选型、复杂归因、疑难调试），几年内有希望把整体推到 70% 到 80% AI；制度性那一层（跨人共识、承担责任、对接真实世界）则是法律和监管要解决的事，跟模型能力没关系。软件工程的复杂性被重新分配了，没有消失。

一键造 App。

自己用的、一次性的、内部的小工具今天已经基本一键搞定（95% AI 加 5% 控制台粘几次 key）。给别人用的、能上 App Store 或者能收钱的正式 App 今天大约是 90% AI 加 10% Human dashboard，能做到”一句话加 10 次粘 key”造出来，但前提是 ta 愿意去办公司、过 KYC、当法人。再往下走两条路：1 到 2 年内浏览器 agent（Computer Use、Operator）把粘 key 那段也吃掉；几年后 AI 法人若能成立，剩下的制度卡点才会被跨过去。

生态。

供给端 AI 编程让产能翻 10 到 100 倍，需求端基本没动，结果是中间层被拍扁：长尾 SaaS 大面积消失，垂直行业 SaaS 被砍掉一半。头部 App（微信、抖音、淘宝、Apple、Google、Meta）不会被取代，反而靠网络效应、数据、内容生态、分发入口加上 AI 提速变得更强。长尾 App 退化成按需生成的 Capability：用完即弃、个人定制、零安装、不进 App Store。几年后的格局可能是三层叠在一起：头部 App 平台层、AI 助手加 Capability 层、模型层。打开手机的第一动作从找 App 图标变成跟 AI 说一句话，这种入口形态的迁移，强度可以跟 iPhone 那一次相比。

下一步的位置。

这场新分工里有几条路可走：当一个能跟 AI 协作的工程师，承担越来越多的判断、审查、验收角色；当一个能驾驭 AI 工具解决真实业务问题的产品人，把哪些流程让 AI 替、哪些环节由人拍板想清楚；当一个用 AI 把过去十人才能做的事一个人做完的创业者，赌一把 AI 助手加 Capability 这个新生态的位置；或者转型做行业内的”小头部”，垂直深耕到 AI 编程复制不了的领域知识里去。每条路都比五年前宽得多，但”白手起家做下一个微信”这种梦确实没了：AI 编程让头部更深、让长尾几乎被替代，中间冒出来一个全新的 AI 助手层等着被占住。

一句话：AI 让造软件这件事的下限大幅抬高，上限仍由人决定。新版图里最大的赢家是头部 App、模型公司，加上少数能在助手层占住位置的玩家，剩下的人要在新分工里找到自己的杠杆点。

作者其它文章

本文参考文献

Raising the bar on SWE-bench Verified with Claude 3.5 Sonnet (Anthropic, 2024-10) - Claude 3.5 Sonnet 升级版 49% 数据
SWE-bench Verified Leaderboard (BenchLM) - 2026 年 4 月 SWE-bench Verified 排行
SWE-bench Pro Leaderboard (Scale) - SWE-bench Pro 排行榜
Why 46% Beats 81%: SWE-bench Pro Leaderboard (Morphllm, 2026) - SWE-bench Pro vs Verified 解读
OpenAI Codex (AI agent) - Wikipedia - Codex 历史 + CLI 重启时间线
OpenAI Codex Statistics 2026 (Gradually) - Codex 300 万周活
Claude Code Statistics 2026 (Gradually) - Claude Code 4% GitHub 提交
Cursor's Anysphere nabs $9.9B valuation (TechCrunch, 2025-06) - Cursor 早期数据
Cursor in talks at $50B valuation hitting $2B ARR (TNW, 2026-04) - Cursor 最新估值
As Lovable hits $200M ARR (TechCrunch, 2025-11) - Lovable 增长曲线
Guide to the SWEBOK v4.0 Has Been Released (basicinputoutput, 2024-10) - SWEBOK V4 发布与 18 个知识域
SWEBOK Evolution (IEEE Computer Society) - SWEBOK 官方信息
CodeBERT GitHub (Microsoft) - CodeBERT 仓库与时间线
CodeT5 GitHub (Salesforce) - CodeT5 仓库与时间线
ISO/IEC/IEEE 12207:2017 Systems and software engineering — Software life cycle processes - 国际软件生命周期标准
阿里巴巴 Java 开发手册（P3C） - 阿里 2017 年公开的工程规约 + IDE 插件，六大维度
美团技术团队官方博客 - 灰度发布、故障复盘、产品上线流程的实操文章
GitLab Handbook - GitLab 公司全流程开源研发手册

纯编程岗位已完，能做可验证奖励强化学习的都会完

Wed, 20 May 2026 16:09:08 CST

为什么 AI 会先吃掉程序员，而不是产品经理

如果你还在用职业名判断 AI 风险，先停一下。

姚顺宇在访谈里给过一个反直觉判断：AI 最先高速改变的，不一定是人类觉得简单的工作，而是反馈最清楚的工作。

这个判断落到职业上，最扎眼的例子就是程序员。

过去很多人以为，AI 会先替代那些重复、低门槛、标准化的工作。客服、简单文案、资料整理，听起来都比程序员更容易被自动化。

程序员是高门槛脑力劳动，写的是复杂系统，按这个直觉，它不该这么早站到第一排。

结果最早被 AI 工具改写工作方式的，偏偏是代码世界。Cursor、Claude Code、Copilot 和各种代码智能体（coding agent），让很多人第一次感觉到，AI 不只是会聊天，它真的开始接一段工作了。

但姚顺宇恰恰把 AI 编程（AI coding）拿出来当第一批爆发的 AI 原生场景。原因不在写代码低端，也不在产品经理更高级；关键是代码世界有测试、编译、运行结果、日志和版本记录。

模型做完以后，环境会告诉它哪里错了。

AI 不按职业声望排队，它先进入那些能被清楚定义、快速验收、低成本纠错的任务。

程序员只是第一排。AI 盯上的，是所有职业里能被拆成输入、输出、标准和反馈的可验收执行层。

职业替代榜单太粗了

这几年，关于“AI 会先替代谁”的讨论很容易变成一张职业榜单。

程序员排第几，产品经理排第几，设计师、运营、咨询、律师、会计又排第几。这个游戏好玩，因为它简单，像看 K 线图。每个人都想知道自己的职业是不是已经破位，隔壁职业是不是先跌。

但职业名太粗了。

同样叫程序员，有人每天接明确需求，改一个局部函数，跑一下测试，然后提代码；也有人要理解业务目标，拆系统边界，决定哪些依赖不能动，最后对整个系统结果负责。

同样叫产品经理，有人按模板写产品需求文档（PRD）、整理会议纪要和竞品截图；也有人要判断用户到底卡在哪里，定义指标，协调资源，承担版本取舍。

这两组人被同一个职业名盖住了。你说“程序员会不会被替代”，或者“产品经理会不会被替代”，其实像是在问“车会不会坏”。卡车、赛车、出租车、自行车都被塞进一个词里，答案当然会很混。

姚顺宇那条判断有用的地方，就在这里。它把问题从职业名换成了任务结构：

一个任务做完以后，环境能不能告诉模型做对了没有；
这个信号能不能被重复收集、训练和纠错；
失败以后，能不能低成本再试一次。

这件事有没有成败信号，可以叫任务可评价性。成败信号越清楚，AI 越容易练；反馈越脏、越晚、越主观，模型就越难稳定进步。

所以 AI 不认识你的岗位头衔。它不关心你在公司系统里叫工程师、产品经理、运营，还是策略分析师。

它只看这件事能不能被定义，能不能被执行，能不能被验收，失败以后能不能继续修。

代码世界像一座提前铺好的练习场

写代码对人很难，但对训练系统很友好。

这句话听起来有点别扭。因为我们习惯把“人觉得难”直接等同于“机器也应该觉得难”。但模型学习一件事，和人类职业声望不是同一套坐标。

对模型来说，难点不只在任务本身有多复杂，还在于环境能不能把错误及时推回来。

代码世界恰好在这件事上非常慷慨。你写完一段代码，能不能编译，测试能不能过，类型检查有没有报错，运行结果对不对，日志里有没有异常，性能有没有下降，版本记录里改了哪些文件，这些信号都会露出来。

很多时候，它们不是人类主观评价，而是工具链直接给出的反馈。

一个代码智能体修改了某个函数，测试失败了，它至少知道失败在哪里；命令跑不通，它能看到报错；依赖不对，它能读依赖配置文件；改坏了别的模块，版本控制和测试能把影响暴露出来。

这个过程当然还需要人审查，但它已经比很多知识工作更接近“做一步，看反馈，再修一步”的闭环。

再往外看，GitHub 和开源生态又给了代码世界大量任务、上下文和修改历史。一个模型不只是看到最终答案，还能看到别人怎么提交议题（issue）、怎么改缺陷（bug）、怎么做代码审查（review）、怎么围绕一个仓库（repo）迭代。

仓库本身就像一台状态机，文件、提交、测试、讨论和文档把上下文记录下来。

好代码当然也有争议。架构是否优雅、命名是否合适、抽象是否过度，这些不可能完全自动判断。但相比很多产品判断，代码仍然更容易形成可重复的质量标准。

能不能运行，是否通过测试，是否引入明显回归，是否符合接口约束，这些东西足够让模型反复练。

所以程序员先站到第一排，并不是因为这份工作低端。恰恰相反，软件工程复杂到一定程度，才给了 AI 足够多的可学习信号。

代码世界像一座提前铺好的练习场：有题目，有上下文，有工具，有错误提示，有回滚，有复盘。

这也解释了为什么代码智能体的体感来得这么快。关键不只是模型“会写代码”，还在于它被放进了一个能持续纠错的环境。

写错了，能看到；看到了，能改；改完了，还能再跑。

产品经理不是安全，只是反馈更脏

那是不是产品经理就安全了？

不是。

这个误读很常见：程序员先危险，产品经理暂时没事。这个判断太便宜，也不符合姚顺宇的原意。

产品经理工作里有大量结构化子任务，都会被 AI 改造：

写产品需求文档；
整理用户访谈；
总结会议；
生成竞品分析；
做数据初筛；
拆需求列表；
写埋点方案；
生成原型说明。

这些事情本来就有模板、有输入、有输出、有交付格式。它们不可能长期停在纯人工状态。

这里有个很残酷的分界。

你是在写文档，还是在定义问题？你是在整理别人已经说清楚的东西，还是在把没人说清楚的东西变成判断标准？

前者会越来越像执行任务，后者才更接近产品经理的责任位置。

但姚顺宇说难的，是完整产品判断。他在访谈里反复指向一个问题：好产品的奖励信号（reward signal）不清楚。

翻译成人话，就是你做完一个产品决定以后，很难立刻知道它到底对不对。

一个功能上线以后，用户会不会用，为什么不用，是因为入口太深、文案不清楚、需求本身不成立，还是因为市场时机不对？

一个留存指标变了，是功能带来的，还是渠道、活动、季节、竞品、价格、品牌一起搅出来的？

一个产品方向看起来失败，是判断错了，还是资源没跟上，还是组织执行变形了？

产品反馈经常晚、脏、主观。晚，是因为它需要时间显现；脏，是因为混进了太多变量；主观，是因为用户心理、审美、组织目标和商业取舍都会进入判断。

做出来以后，大家才知道它好不好，而且经常不是一眼就知道。

所以产品经理的护城河不是写文档，也不是开会。文档会被生成，会议会被总结，竞品会被整理，数据会被初筛。

产品经理（PM）难被完整训练的部分，是把模糊目标变成可验证的问题、标准和取舍。

程序员和产品经理的差异，不是“谁会被替代，谁不会”。更准确的说法是：代码世界更早暴露了未来所有知识工作的重构方式；产品世界的核心判断更难训练，但它的外围执行层一样会被重构。

AI 提效以后，工作未必变少

很多人以为，AI 写代码以后，程序员会轻松一点。

这个期待很正常。过去写一个功能要两天，现在半天能做出来，剩下的时间似乎应该还给人。你可以早点下班，可以多想一会儿架构，可以把拖了很久的文档补上。

听起来挺好的。

但姚顺宇谈 AI 编程时，给出的体感更接近另一种结果：想法实现得更快以后，人会试更多方案，跑更多实验，做更多判断。

AI 提效先改变的，是尝试成本。尝试成本一降，高竞争环境通常不会把省出来的时间留给你，它会把更多尝试塞进同一天。

过去一个方案要两天，团队可能只试一个。现在一个下午能试三个，领导、同事、你自己都会自然地问：那为什么不多试几个？

过去一个 bug 修起来很费劲，大家可能先忍一下；现在模型能快速定位和修改，就会有更多边角问题被拉进待办。

过去没人敢开太多实验，因为每个实验都要人力；现在实验成本低了，判断成本就会上升。

工作没有少，只是从“手写实现”迁移到了“定义任务、组织上下文、审查结果、比较方案、承担验收”。

手从键盘上少敲了一些，脑子里的窗口反而开得更多。像系统里同时跑了很多线程，每个线程都很快，但你要负责调度、抢占、回滚和判断优先级。

这件事不会只发生在程序员身上。任何职业一旦能把执行切成小闭环，节奏都会被同一股力量推快。

运营可以更快生成活动方案，研究员可以更快整理文献，产品经理可以更快写需求和原型说明，创作者可以更快生成多个标题和版本。

每个环节都快一点，最后不一定换来轻松，可能换来更高的工作密度。

AI 未必先让人失业。它可能先让同一份工作变得更密。

这才是很多人已经感受到、但还没说清楚的变化。

AI 工具越好用，工作越不像消失，而像被压缩。原来一天里只能跑一个版本，现在一天里要看三个版本。原来一个人只要交付结果，现在还要解释为什么选这个结果、为什么不用另外两个结果、哪里可以继续迭代。

真正危险的是可验收执行层

问题不是程序员会不会消失。这个问题太大，也太容易吵。

有人会拿顶级工程师反驳：他们当然不会被替代；有人会拿初级岗位反驳：很多局部实现已经被模型接走了。

两边都能找到例子，然后继续争职业名。

更有用的问题是：一个职业里，哪些部分只是在明确标准下完成局部执行？

只接局部任务、写局部实现、无法定义需求、无法审查跨文件影响、无法承担系统验收的人，价值会被压缩。

这未必是因为他们不努力，更因为他们那部分工作越来越像可切分、可派发、可回收的任务。

模型只要能拿到足够上下文，再通过测试、编译、日志和代码审查得到反馈，就会不断逼近这部分执行层。

对应到产品岗位，风险也一样存在。

只按模板写 PRD、整理材料、做浅层竞品分析、把别人说过的话包装成页面的人，也会被压缩。因为这些任务可以被拆成输入、输出和格式要求，可以快速验收，也可以低成本重做。

姚顺宇那条判断在这里完成了职业转译：AI 优先进入的，不是某个职业名，而是职业内部可验收、可拆解、可低成本纠错的执行层。

再压一层，可以变成三个指标：

第一，验收速度：做完以后多久知道对错。
第二，纠错成本：错了以后能不能快速重来。
第三，责任位置：你是在执行标准，还是在制定标准。

前两个越高，第三个越低，风险就越近。

如果你的工作能被拆成输入、输出、标准和反馈，它就会开始变得像代码。

它比“程序员危险”更准确，也更难躲。因为它把所有职业都拉进来了。

运营里有像代码的部分，研究里有像代码的部分，咨询里有像代码的部分，设计里有像代码的部分，产品里也有像代码的部分。

所谓“像代码”，重点不在产出物是不是代码，而在任务结构：输入清楚，输出清楚，验收清楚，失败可以重跑，迭代成本很低。

只要这个结构出现，AI 就有了练习场。

职业名会给人一种安全错觉。你以为自己站在某个行业、某个岗位、某个头衔后面。

结果 AI 看见的是另一张图：哪些地方有清楚任务，哪些地方有反馈信号，哪些地方失败了能改，哪些地方上下文已经结构化。

人的价值会往反馈责任迁移

被压缩的是纯执行，不是所有人的价值。

问题在于，你有没有从执行层往反馈层迁移。

人的价值会往上游和下游迁移。上游是定义任务、组织上下文、设定边界。下游是审查结果、设计验收、承担取舍。

中间那段纯执行，会被越来越多的 AI 工作者接走。

这里说的 AI 工作者（AI worker），就是你能调度来做具体任务的 AI 工作者。它可能是一个代码智能体，也可能是一个能整理资料的助手，一个能跑分析的工具，一个能生成方案的模型。

它不是传统意义上的员工，但它会占据越来越多的执行位置。

程序员的迁移路径很清楚。过去的价值可能更多体现在手写实现上：理解需求、查上下文、设计方案、写代码、调试、交付。

AI 进入以后，这条链会重排。人要更擅长定义任务边界，给模型足够上下文，知道哪些文件不能动，知道结果如何验收，知道一个局部修改会不会影响系统其他部分。

这不是说写代码不重要。你看不懂代码，就很难审查模型写出来的东西；你不理解系统，就不知道模型哪里在胡来。

只是写代码不再是唯一中心。更稀缺的是你能不能组织一批 AI 工作者去做事，然后对结果负责。

产品经理的迁移路径也类似。PM 的价值不在于把一句需求扩写成三页文档，而在于把模糊目标变成可验证的问题、指标、实验和复盘。

你能不能判断“用户说想要”背后到底是什么需求；能不能把一个方向拆成几次低成本验证；能不能定义成功标准；能不能在数据不好看时判断是方向错了、执行错了，还是反馈还不够。

无法验收，就是 AI 协作里的最高优先级问题（P0）。

一个任务如果没有成败标准，就很难交给 AI 稳定执行。你让模型“做得好一点”，它只能猜。

你让模型“把这段接口改到测试通过，并且不改变现有调用方”，它就有了边界。

你让模型“写一个更好的产品方案”，它只能拼常识。

你让它“针对新用户首日留存下降，提出三个可在两周内验证的假设，每个假设要有指标、实验和失败判据”，它才有可能进入真正的协作。

下一阶段稀缺的，已经不只是会写代码或懂产品的人，而是能管理 AI 工作者的人。

这里的管理，和开会、发号施令、传统管理岗都不是一回事。

管理的意思是：能定义目标，分配任务，提供上下文，识别失败，更新标准，最后承担结果。

你不是因为站在 AI 上面而安全，而是因为你负责 AI 还不能稳定负责的那部分：目标、标准、取舍和验收。

不要先问学 AI 编程还是学产品

所以以后不要先问，学 AI 编程更安全，还是学产品更安全。

这个问题仍然停在职业名上。

它像问“我应该买科技股还是消费股”，但完全不看公司现金流、估值、行业周期和管理层质量。职业名只是股票代码，决定风险的是底层资产。

你可以先问五个问题。

第一个问题：你的结果能否自动验收？代码能跑测试，表格能对账，数据能校验，格式能检查，交付物能被明确打分，这类任务更容易被 AI 练习。

第二个问题：任务能否拆成小闭环？一个大目标如果能被拆成很多小任务，每个任务都有输入、输出和完成标准，就更容易被分配给 AI 工作者并行执行。

第三个问题：上下文是否结构化？文档、代码、数据、历史记录、接口、约束都清楚，AI 就更容易接手。

如果上下文全在某个人脑子里，模型很难稳定工作，但这不代表安全，只代表组织还没把上下文整理出来。

第四个问题：失败能否低成本纠错？失败以后能重跑、回滚、复盘、再试，AI 就会进步得更快。

如果失败一次成本很高，反馈很慢，风险就会晚一点暴露。

第五个问题：你是否拥有标准设定和取舍责任？

前四个答案越是“是”，而最后一个答案越是“否”，你手里的那部分工作就越容易站在第一排。

反过来，如果你能定义问题、组织上下文、设定验收、承担取舍，AI 进入以后，你反而会被放大。

你能让一个模型变成十个执行线程，让模糊问题变成可验证任务，让失败变成下一轮反馈。

这种人不会因为 AI 能写代码或写文档就消失，至少不会在同一条线上被简单压缩。

职业榜单还是会继续流行。原因也简单：它把复杂的任务风险压成身份命运，方便转发，方便站队，也方便让人暂时松一口气。

但真实的 AI 改造不按这个逻辑走。它不先问你是什么职业，而先问你的工作能不能被评价、复盘和重来。

姚顺宇的判断给这篇文章留下的，不是一张职业排名，而是一套更冷静的看法：

不要把职业名当护身符，也不要把某个工具当灾难本身。

AI 改造工作的顺序，更像是在寻找反馈最清楚的地方。

哪里能定义任务，哪里能观察过程，哪里能验收结果，哪里能低成本纠错，哪里就会先被推快。

程序员只是第一排。问题是：你的工作有没有正在被改造成 AI 喜欢的形状？

参考与引用来源

感谢张小珺完成这场对姚顺宇的长访谈。本文关于 AI 编程、产品判断、反馈信号和工作重构的理解，主要来自这场公开访谈；我在文中负责把这些判断转译为职业风险和个人工作方法框架。

张小珺 / Yao Shunyu 访谈：《Let Me Go a Little Crazy! Training Models at Anthropic & Gemini》
Cursor 官方文档：Cursor Docs
Anthropic 官方文档：Claude Code Docs
GitHub 官方文档：GitHub Copilot；GitHub Docs 中关于 repositories、issues、pull requests、reviewing proposed changes 的说明
Productboard：Product Requirements Document glossary
Atlassian：Understanding incident severity levels

手搓一个 Agent 驱动的项目 Wiki 生成方案

Mon, 18 May 2026 08:00:00 CST

背景

最近我一直在折腾项目文档生成的事情。之前写过两篇关于 deepwiki 的文章： deepwiki-rag-principle 讲了 RAG 原理， deepwiki-optimize-line-number 聊了给代码加行号的优化。

经过几轮迭代，搞了两个优化：

代码加上行号前缀
基于 Proto 文件生成确定性目录

这两个优化背后其实是同一个思路： 把确定的东西明确告诉 AI，不确定的才让 AI 来发挥。

类型	内容	处理方式
确定的	代码行号	直接给 LLM 标注好
确定的	gRPC 接口列表、目录结构	代码解析，不经过 LLM
不确定的	函数功能解释	交给 LLM 归纳
不确定的	项目架构分析	交给 LLM 总结
不确定的	代码关联关系	交给 LLM 推理

LLM 擅长理解、归纳和总结，但精准计算和结构化数据生成这块确实不太行。分开处理，各取所长，效果就好很多了。

这些都是用开源的 deepwiki-open 来做的。

问题

虽然最终生成的内容效果还不错，但还有个让人头疼的问题：

需要为整个项目生成总结性的内容，比如项目架构、流程图、ER 图等。

这些数据得根据之前已经生成的内容来总结，但 deepwiki 的架构是每个页面独立生成的。而 ER 图这种，我们希望是基于已生成的内容再汇总生成。

在现有架构下实现这个比较困难，索性换个思路。

新方案

日常用 Claude Code（后面简称 CC）的时候发现，它可以精准定位到具体业务逻辑所在的代码片段，也能帮我们分析项目、提炼内容。

这不就是个完美的 Wiki 系统吗？直接让 CC 分析项目内容，生成静态页面，就能得到一个精准的 Wiki 了。

CC 也是通过一些内置 tools 来实现精准代码检索的，不需要 deepwiki 那种向量数据库，架构简单很多。

这里简单聊下 CC 的代码搜索原理。传统 RAG 方案会先把代码向量化存入数据库，然后通过语义相似度检索。但 CC 并没有走这条路，而是直接用了一套 工具驱动（Tool-based）的检索机制：

工具	功能	使用场景
`Read`	直接读取文件内容	已知文件路径时
`Bash(grep)`	基于正则匹配搜索代码	按关键字/符号查找
`Bash(find)`	遍历文件系统	发现文件、按模式筛选
`LSP`	语言服务器协议导航	跳转到定义、查找引用
`Agent`	子 Agent 并行搜索	大规模代码库分治检索

这种设计的巧妙之处在于：LLM 不依赖向量化后的”模糊记忆”，而是像人类开发者一样，通过 精确的工具调用来定位代码。比如要找某个函数定义，CC 可能会先 grep 找到候选文件，再用 Read 精读确认，最后用 LSP 验证引用关系——整个过程是 确定性的、可解释的。

想了解更多细节可以参考 Anthropic 官方文档： Claude Code Overview

后续 repo 有更新，只需要让 CC 读取 git log 变更记录，自动更新修改的内容就行。

提炼 Skill

考虑内部项目众多，为了让其他项目也能复用这个能力，我把生成静态网站的过程写成了一个 Skill。其他项目只需要在 CC 里调用这个 Skill 即可。

目录结构大概长这样：

     ├── SKILL.md      
├── skill.json      
├── templates/      
│   ├── page-architecture.md      
│   ├── page-er.md      
│   ├── page-features.md      
│   └── page-service.md      
└── wiki/      
    ├── 01-系统架构.md      
    ├── 02-核心功能.md      
    ├── 03-ER图.md      
    ├── index.html      
    └── service/      
        └── *.md

优缺点对比

deepwiki

优点：

可以一键生成整个项目，生成过程中不需要人工干预

缺点：

无法精准调整某个页面
对于需要汇总已生成数据的需求，架构无法满足

Claude Code 方案

优点：

可以精准调整每一个页面
数据可以做到非常精准

缺点：

无法一键生成结果，需要多轮对话调试
如果部署到服务器上，需要外部工具对 CC 进行管理

总结

其实这两个方案并不冲突，可以看成不同阶段的选择：

项目初期需要快速搭个文档框架 → deepwiki 一键生成
项目成熟需要精准可控的文档 → CC 方案慢慢打磨

CC 方案的核心优势在于 可控性。虽然要多花点时间调试，但生成的内容质量确实更高，特别是涉及到跨文件关联分析的时候。

当然，CC 方案目前还不能完全自动化，这是最大的限制。不过随着 CC 生态的发展，相信后面会有更好的解法。让子弹飞一会。

马斯克花 100 亿想清楚一件事，不做 coding agent 就是等死

Mon, 18 May 2026 22:10:38 CST

1.

OpenAI 的两大宿敌 Anthropic 和马斯克，放下心中成见之后终于在月初结盟了。

在此之前，Anthropic 和马斯克的关系并不融洽：今年 2 月，马斯克还在自己的 X 账号指责 A 社「woke」「邪恶」「反人类」（misanthropic），说这家公司「仇视文明」。

事后来看，这次攻击并非马斯克清新脱俗的性格使然，而是 Anthropic 所做的某些事情触碰到他的神经，事出有因。

在此之前，xAI 内部使用 Cursor 工作，但是今年年初员工发现，Claude 模型突然在 xAI 的 Cursor 公司账号里不能使用了。

当时还在 xAI 上班的联合创始人吴宇怀，在全员信里是这么说的：「Anthropic 更新了政策，要求 Cursor 不得向其主要竞争对手提供 Claude 模型调用能力。」

当时，吴宇怀在信中写了一句话，颇为有趣：

「这是坏消息也是好消息。我们的生产力会被影响，但这也敦促我们开发自己的编码产品和模型。」

为什么当时 xAI 的高层认为，开发自己的编码产品是关键？

后来发生的事情，大家都知道了。xAI 的联创团队悉数跑路，马斯克一气之下对 Cursor 使用了钞能力必杀：

上个月底，SpaceX 和 Cursor 共同宣布，将在编程和知识类工作 AI 模型的训练上，展开前所未有的战略合作；并且，SpaceX 还获得了以 600 亿美元收购 Cursor 的权利，或向后者支付 100 亿美元合作费用。

注意编程这个关键定语，后面还会 call back.

2.

最近，我看了一条 Cursor 早期投资人、Anthropic 大喷子、T3 创始人 Theo Browne 的视频。

本来点进去是看他喷 A 社和 SpaceX 怎么蝇营狗苟，结果没想到，却看到了关于 SpaceX + Cursor 合作的，一个既另类却又极度合理的分析：

不说 600 亿的收购，就只说 100 亿的合作费—— Theo 在视频里表示，自己认为「哪怕只是交换到 Cursor 的用户数据，这 100 亿也值回票价了。」

所以是什么数据？如果你也去看 Theo 这条视频，他会讲得非常清楚。但为了节约时间，我们在这里简单概括一下：

我们和 AI 的对话是一来一回的，你提出问题/需求，他给你解答；coding agent 同理，只不过返回的是代码。

一次高质量的对话，整个过程，包括用户提示、模型思考、agent 规划、输出代码、验证 ——所有这些东西合起来，可以称为一个完整的 Agentic Loop——就成为了高价值的训练数据，再喂给模型去进行强化学习，就能进一步提高模型在实战场景下的表现水准。

Cursor 有的，SpaceX 想要的，就是这些数据。

可这些数据从哪里来呢？

答案很简单：作为模型厂商，这种高质量数据的最直接来源，只能是你自己开发的 coding agent 产品——也即 Anthropic 的 Claude Code、OpenAI 的 Codex、Kimi 的 Kimi Code。

现在你应该明白了，为什么被 Anthropic「封号」之后，吴宇怀会在全员信里提出开发 xAI 自己的 coding 产品和模型这件事了。这件事 xAI 在当时已经看清楚了：

没有自己的编码产品，就没有高质量的强化学习数据；没有高质量的数据，就训练不出真正实战能力强的 coding 模型。

虽然有点暴论，但现在我们可以点题了：模型厂商想做出来真正能打的编程模型，做自己的 coding agent 产品是唯一的路径。

3.

大语言模型像个水晶球，用全网的语料训练出来，似乎能够解答万物，但并不代表它在所有问题上都能给出高质量的答案。

用 GitHub 上数以亿计的代码条目训练，当然也能训练出 coding 模型。这是「学习结果」的逻辑，也是没问题的。毕竟编码任务的结果是可以验证的：代码能不能运行，测试能否通过，结果摆在那里。

但是，通往结果的过程，是一个涉及多步骤决策、错误纠正、意图对齐的复杂链条。每一次用户的接受、拒绝、补全、撤销、追问、甚至当模型好几次都搞不定或者完全搞错时的辱骂——都是这一链条上的过程信号。

强化学习有两种监督方式，一种叫做结果监督，只看最后是否跑通。但是结果监督会催生「奖励黑客」的现象：模型为了能跑通可能写出冗余、脆弱、带逻辑漏洞的代码，但因为测试过了，模型以为自己学对了。

而另一种叫做过程监督，对推理路径上的每一步进行打分。上述这些过程信号，只有在 coding agent 运行环境里才能诞生。GitHub 仓库里只有结果，哪怕是去看单独的提交历史，看 PR，都找不到有效的过程信号。

在缺乏有效、自主可获得的过程信号的时候，一些模型厂商会采用「蒸馏」的方式，这个事情大家应该已经知道了。

蒸馏的逻辑很简单，给同样的输入，老师模型输出什么，学生模型就学着输出什么。 但是通过蒸馏，即便可以获取到思维链，得到的仍然更接近于结果，而非被蒸馏的老师模型内部的概率分布。

一旦学生在推理中偏离了老师的轨迹，哪怕一个 token 不符合，都有可能发生偏离。

这背后是强化学习的基础限制：策略梯度定理要求，优化样本最好由当前正在优化的模型自己去产生。这种数据叫做 on-policy 数据。而通过蒸馏别家模型，在别人的产品里产生的数据，来训练自己模型，都属于 off-policy 数据。模型当然可以从中学到东西，但学不到老师模型内部的概率分布信息。

而像 Cursor 这样自己就是 coding agent 产品的公司，掌握着最真实、有效、高质量的训练数据。Cursor 产品本身，就是 coding 模型在实战环境中的最佳训练场。

我们可以通过 Cursor 年初的「翻车」，来证明这个逻辑。

4.

APPSO 读者应该记得，年初 Cursor 发布了 Composer 2，号称「下一代专用编程模型」，技术报道写的相对保守，也没有提供具体的模型底座信息。

结果很快，网友就在公开代码片段里发现了 Kimi 的模型 ID，截图传遍了开发者社群，逼得 Cursor 副总裁 Lee Robinson 出面澄清：「Composer 2 确实是从开源底座出发的。最终模型大约只有 1/4 的算力来自底座，剩下 3/4 是我们自己训出来的。」

几小时后，Cursor 联创 Aman Sanger 也跟着发了一条道歉：「一开始没提 Kimi 底座是个失误。」

五天后，Cursor 放出了完整的 Composer 2 技术报告，显示底座的确是 Kimi K2.5，授权方则是 Firworks AI，大致流程是在 K2.5 上做训练，再继续做大规模强化学习（RL）。

但关键之处在于，Composer 2 的 RL 是运行在真实的 Cursor 会话当中，使用与生产部署完全相同的工具和 harness。

Cursor 将这套流程叫做「实时强化学习」(real-time RL)，也即将模型的 checkpoint 直接部署到 Cursor 生产环境中，观察用户的响应，收集数据，聚合成奖励信号——最快可以每 5 个小时迭代一次模型版本，然后继续部署到 Cursor 里，循环往复。

最极致的案例是 Cursor 的自动化代码补全功能 Tab，每天处理超过 4 亿次请求，每当用户输入字符、移动光标时，模型都会预测下一步动作，如果预测置信度高，则显示建议，用户按下 tab 即接受自动补全。

该功能采用的是在线强化学习，在行业内极具特色。Cursor 可以以极高的频率（最快可达每一个半小时到两小时）更新 Tab 的模型能力给用户，直接在产品内收集 on-policy 数据进行训练。

这种高频、接近实时的反馈回路，让 Tab 可以学习到极其微妙的用户意图。Cursor 方面透露，这种方法让 Tab 建议的拒绝率降低 21%，接受率提高了 28%。

回到 Composer 模型本身。在事情搞清楚了之后，一些 Kimi 员工也删掉了之前吐槽的的推文，Kimi 官方账号发表了祝贺。

一家估值 600 亿美元（基于马斯克给的数字），不做自己的模型基座的 coding agent 应用层公司，仍然可以通过产品自身的数据飞轮，RL 出超越基座模型的专有编程模型。

所以与其说 Cursor 翻了车，不如说这反而是 coding agent 产品重要性的绝佳例证。

Cursor 在另一篇关于实时 RL 的文章里写到：「（训练编程模型）最大的困难在于建模用户。Composer 的生产环境里不只有执行命令的计算机，还有监督和指导它的人。模拟计算机容易，模拟使用它的人却很难。」

这句话，现正在逐渐成为了在编程模型方面走在前沿的模型厂商之间的共识。如果你去看 benchmark 榜单和用户普遍评价，会发现哪些头部的厂商都在发力做自己的 coding agent/编程产品。区别只在于谁离用户更近。

我们以 SWE-bench、LLM-Stats 等相对权威的榜单为例，Claude、GPT、Gemini、Kimi 等模型基本霸榜前十，清一色都是有自己开发 coding agent 产品（包括 CLI、IDE、集成 coding agent 的桌面客户端）的模型厂商。

在部分榜单上会出现少数反例，如 Meta (Muse Spark)、DeepSeek 等，没有开发自己的 coding agent。

不过你会发现，这些反例模型，在更加接近真实场景、避免污染的更权威 benchmark 上就很难上榜了。以 DeepSeek 为例，它在 SWE-bench bash only 上分数是 70%，排名第九，在 SWE-bench Pro 上分数却掉到了 15% 左右。

OpenRouter 的真实流量数据可以解释这种反差：该平台 2025 年报告显示，Claude token 消费 80% 以上用于编程和技术任务，而 DeepSeek token 消费主要集中于闲聊和角色扮演。

没有自家 coding 产品的厂商，在一些 coding 任务 benchmark 上能挤进头部，但在更难的真实工程 benchmark 上，在用户用 token 消费投票的真实流量中，都会原形毕露。

不仅是 Cursor，Anthropic 在 2025 年 11 月发的一篇论文里，也明确透露自己在做一模一样的事情：「我们在 Anthropic 自家的真实生产编程环境上做训练。」也即 Anthropic 把自己员工使用 Claude Code 的交互数据，反哺给 Claude 模型用来训练。

5.

在 AI 的演进历程中，生产要素的定义发生了深刻的位移。传统三大核心要素——算力、研究、训练数据，虽然在总量上持续增长，但在结构上已经出现了严重的失衡。

今天的各大 AI 巨头显著提高了在算力上的资本支出 (CapEx)，让算力基建成为了当前舆论的主旋律。但实际上，特别是在编程范畴内，随着 GitHub 仓库、StackOverflow 等互联网公开代码数据被基模厂商「竭泽而渔」式地利用，模型在代码生成与逻辑推理上的边界开始逐渐显现。

这也是为什么，行业共识正在逐渐转向一个冉冉升起的新战略高地：

对于任何希望掌握顶级代码能力的模型厂商而言，建立自有的 coding agent 产品早已不再是可选的商业路线，而是确保底层模型可以持续进化的核心生命线。

正如前面 APPSO 论证的那样，单纯学习公开数据等于只学习成功者的结局，却无法了解成功的路径，这绝对不是正确的成功学应该有的样子。在真实的编程环境中，知道发生了什么错误、怎样发生的、如何正确地理解和高效地实践需求等等——了解正确过程的价值，远超于得到正确结果本身。

只有拥有自己的编码产品，模型厂商才能获取高质量的「过程监督」信号，从而在编码/推理能力的下一阶段竞争中，确保自己仍有技术护城河——

否则就不得不像 SpaceXAI 那样，花钱去跟 coding agent 产品公司去合作。

然而并不是所有模型厂商都跟马斯克一样有钱，以及 2026 年开始的巨头势力划分、结盟与领地的争斗会变得更加激烈，当一家缺乏自主 coding 产品的模型厂商终于回过味来的时候，恐怕已经没有足够的合作伙伴可以挑选，合作的价格也将水涨船高。

美国模型巨头的情况大家普遍比较熟悉了，在此不赘述。APPSO 也注意到，国内的主流模型厂商和 AI 巨头当中，绝大部分都已经在 coding agent 产品上有所布局。

国内巨头公司主要以原生 AI IDE 或 IDE 插件的思路在做：字节跳动去年很早就布局了 TRAE、阿里巴巴的 Qoder、腾讯的 CodeBuddy、百度的文心快码 Comate 等。

AI 小龙公司中，月之暗面是最早开发独立 coding agent 产品的公司，主要以 CLI 界面的 Kimi Code 为主—— 不过 Kimi 此前有透露过，在原生编程产品这件事上，CLI 不会是终局。

另一种实现思路是模型厂商自行提供 API 服务、Coding Plan。这样，不论用户使用何种 AI 开发环境，模型厂商都可以通过服务器端的 API 记录来获取最大程度接近于原生 coding 产品的过程数据。

但这也只是接近，并非完全相同。核心在于，服务器端 API 的请求-响应日志，与深度继承的产品交互轨迹相比仍有很大差距。

自建产品的厂商（例如 Cursor、Claude 桌面端、Codex）拥有最直接的显式反馈信号，而 API 侧是相对模糊的隐式推断。简单来说，API 侧能看到用户请求和响应，但用户最后是否采纳了这段代码、代码能否跑通、引发了什么样的 bug，API 侧对此是一无所知的。他们无法了解到用户最终行为这一关键的标签，从而无法实现最高质量的强化学习。

形而上来讲，语言即世界，代码即方案。代码可以表达这个世界上绝大多数的任务，代码也会成为头部的放大器，让最顶尖的人才放大数倍的生产力。

只有最顶尖的 coding 模型才配得上最顶尖的人才。如果领先的模型厂商不重视 coding，势必将会掉出第一梯队。

当然，事实上每家模型厂商都不会不重视 coding——而是说，在新的范式下，哪些没有自主可控的原生 coding agent 产品，极有可能逐渐落后于有产品的厂商。

就在前几天，MiniMax 也发布了桌面客户端产品的重大更新： 带有全新多 agent 编排架构的 Mavis 功能，并且也让客户端显著改善了对 coding 任务的支持。

此前 MiniMax 只是推出了桌面端，但没有加入原生 coding 和 agent 功能。

紧接着，在 5 月 15 日，阿里巴巴正式发布了 Qoder 1.0——这个产品从 IDE 的形态正式升级为一个完整的 Agent 产品（阿里的官方叫法是智能体自主开发工作台）。

与此同时，xAI 的 Grok Build CLI，也终于正式推出了。

没错，就是 xAI 年初被 Anthropic 和 Cursor 封号之后，他们自己捣鼓出来的那个 coding agent.

这不，又多了好几个现成的案例。

看来，大家都认为 Cursor、Codex 和 Claude 桌面端走在正确的道路上。

6.

把话题从 coding 扩展到 agent 本身，情况也是一样的。

编码任务的轨迹数据，在公开语料中确实还是能找到一些的（比如 GitHub 的提交记录/PR，尽管质量并不高）。但是 agent 任务的轨迹数据，包括并不限于移动和点击鼠标、操控触屏、填写输入框等，却无法在公开语料中找到。

所以我们会看到，即使在 agent 操作的最小实现路径——浏览器插件上，这么个看起来一点都不高端的东西，几乎每家模型厂商都会做自己的。

OpenAI 早在 2025 年 1 月就做了 Operator——与其说它是一个「AI 自动操作浏览器」的产品，不如说本质上就是一个大规模的数据收集装置。每一位试用 Operator 的用户，都在免费为 OpenAI 提供 on-policy 数据。

后续 OpenAI 还衍生出 ChatGPT Agent 以及新版 Codex 桌面端；Anthropic 也是同理；最近 Kimi 不声不响地也做了一个叫做 WebBridge 的项目，其实就是一个浏览器插件。

即便是在过去两年里动作最克制的中国模型巨头深度求索，也在最近开始展露出对 Agent 的兴趣。

CEO 梁文锋此前接受采访时曾经提到这样的观点：数学和代码是 AGI 天然的试验场，有点像围棋，是一个封闭的、可验证的系统，有可能通过自我学习就能实现很高的智能。

这句话的潜台词，是 DeepSeek 一直把 coding、Agent 当研究试验场，而非商业化方向。

但是在今年 3 月，DeepSeek 一次性放出了十几个 Agent 相关岗位，包括首次出现的模型策略产品经理（Agent 方向）等。当时的 JD 职责涵盖「主导 Agent 评测体系以及训练数据方案的设计」，要求中包括「深度使用 Claude Code、Manus」等产品。

APPSO 注意到，近期深度求索发布了 Agent 产品经理、Harness 产品经理等职位招聘信息——很显然，DeepSeek 要做独立、原生的 Coding/Agent 产品了。

此前资料显示，DeepSeek V3.2 的训练过程中引入了近两千个合成的 Agent 训练环境和八万多条复杂指令。但是看起来，靠合成的训练数据只能带 DeepSeek 走到这里了，剩下的是合成不出来的部分：真实用户在真实环境里的真实成功和失败，必须靠自家的 agent 产品才能拿到。

DeepSeek 以一种极度克制的方式做了三年模型以及模型产品（直到上个月才终于在官网加入了多模态能力）。但是在今天来看，在编码类任务上，DeepSeek 拿 SOTA 越来越难了，即便此前拿到也会在不久后被超越。

当主力依靠研究的路径支撑不住飞轮的时候，DeepSeek 终于行动了。

7.

最后，我们回到开篇的故事。

根据 The Information 援引知情人士报道，在接受马斯克 600 亿收购/100 亿美元合作的同时，Cursor 表示不会与 xAI 合作开发新的模型，而是仍将聚焦于优化自己的 Composer 模型。

这可能意味着，即便被马斯克买通甚至收购，Cursor 仍然要保留自己数据飞轮的主体性。

数据归属的本身，是最关键的隐藏博弈点。

当所有顶级模型厂商都做了自己的产品，所有顶级产品也都开始训练自己的模型，「模型公司」和「产品公司」之间本就不太清楚的界限，似乎越来越不存在了……

这场博弈也才刚刚开始。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

你生活的地点与你衰老的速度相关

Mon, 18 May 2026 23:37:43 CST

根据发表在《Cell》期刊上的一项研究，研究人员通过分析欧洲、东亚和南亚的 322 名健康人去构建迄今最详尽的遗传祖先和环境如何塑造人类生物学特征的图谱。通过招募居住在不同大洲、具有相同遗传背景的人群，科学家得以以前所未有的清晰度，将 DNA 的影响与环境的影响区分开来。研究人员发现，无论搬到哪里，种族背景会对免疫系统、新陈代谢和肠道菌群产生深远影响。南亚人表现出更高的病原体暴露水平。欧洲人的肠道微生物多样性更丰富，且与心脏病风险相关的化合物含量更高。跨州迁移会改变主要的代谢途径，改变肠道微生物的平衡。研究的一大发现是你生活的地点与你衰老的速度相关。居住在亚洲外的东亚人比东亚人生物年龄更大。欧洲人则相反，居住在欧洲外的欧洲人生物年龄更小。

IT社区推荐资讯 - ITIndex.net

DeepSeek再放大招，推理速度狂飙85% 怎么做到的？

从日报到 OKR：我是如何用 Claude + Obsidian 构建工作记忆系统的

零、背景

一、把每天的工作都沉淀下来

二、用 AI 自动生成每日总结

三、用 AI 构建总结金字塔

四、AI 总结最容易忽略的问题：垃圾进，垃圾出

五、AI 最大的价值，不是帮你写总结

六、最后

高盛警告AI泡沫：首个削减支出的巨头出现时，全市场将重新定价

LLM 究竟是如何工作的？

Tokenization（分词）

Embedding（嵌入）

Positional Encoding（位置编码）

Attention

Multi-Head Attention（多头注意力）

Feed-Forward Network（前馈网络）

Residual Stream and Layer Normalization（残差流与层归一化）

Next-Token Prediction（下一个 token 预测）

Architecture vs Trained Weights（架构 vs 训练权重）

未来走向

00 卷首语：当 Karpathy 说他半年没写一行代码

半年没写一行代码

从软件危机到智能体崛起

先行者们看到了同一件事

AI 放大了一切——包括你的工程缺陷

当开发速度不再稀缺，工程化就是最后的壁垒

为智能体构建运行环境

关于这本书

声明式编程的古老智慧

挪威将禁止小学生使用生成式人工智能

用Qwen 3.6 35B本地模型作为主力编程工具替代Claude或GPT

一、 本地大模型（Local LLM）编程的 5 条最佳实践

二、 帖子主要内容概述

问HN：有没有人用本地模型替换Claude/GPT进行日常编码？

产品经理必装的10个Skills：从需求到落地的全链路AI武装

一、Product Manager Toolkit —— PM的”瑞士军刀”

二、Competitive Analysis —— 竞品分析的”专业外包”

三、User Research —— 用户研究的”方法论教练”

四、Data Analysis —— 数据驱动的”分析助手”

五、PRD Writer —— PRD撰写的”结构教练”

六、Meeting Minutes —— 会议纪要的”自动秘书”

七、Mind Map —— 思维整理的”可视化工具”

八、Product Framework —— 产品架构的”设计工具”

九、Socratic Business Model Canvas —— 商业模式的”追问教练”

十、PM Toolkit – Excalidraw —— 产品思维的”可视化翻译器”

安装建议：按工作阶段按需取用

我是怎样使用 AI 构建 E2E 测试体系的？ | Viking

问题

基石

五阶段流程

Spec：先想清楚要测什么

Code：写代码

Verify：用 agent-browser 预演一遍

为什么要使用 agent-browser ？

Test：写 Playwright E2E

为什么不在写代码之前就写好测试？

Green：三个 app 都跑通

E2E 不在 CI 上跑

三种情况跑 E2E

AI裁员陷阱：一场集体理性的经济自杀

大公司的 AI 账本，没有一笔算得过来

另一个方向的同一个问题

一个悖论

钱去了哪里

全球车企唯一！比亚迪半导体产业覆盖芯片全流程、全链路 量产中国首款4nm制程智驾芯片

大模型强化学习阶段的后训练在做什么

美国AI 基建全是鬼故事

AI 为什么会编程——原理、历史与未来

纯编程岗位已完，能做可验证奖励强化学习的都会完

为什么 AI 会先吃掉程序员，而不是产品经理

职业替代榜单太粗了

代码世界像一座提前铺好的练习场

产品经理不是安全，只是反馈更脏

AI 提效以后，工作未必变少

真正危险的是可验收执行层

人的价值会往反馈责任迁移

不要先问学 AI 编程还是学产品

参考与引用来源

一、本地大模型（Local LLM）编程的 5 条最佳实践

二、帖子主要内容概述

全球车企唯一！比亚迪半导体产业覆盖芯片全流程、全链路量产中国首款4nm制程智驾芯片