IT社区推荐资讯 - ITIndex.net

购买电视棒之前请阅读本文

Fri, 31 Jul 2026 08:55:45 CST

多年来，安全专家一直警告称，使用那些承诺一次性付费即可无限量观看流媒体内容的通用电视盒存在风险，因为它们会暗中将用户的互联网连接出租给陌生人。但一项突破性的新分析发现，这些设备还会伪装成手机，点击人工智能生成的网站上的广告，这是旨在欺骗在线商家和广告网络的庞大行动的一部分。

佩德罗·法莱是安全公司 Bitsight的威胁研究员。法莱告诉KrebsOnSecurity，他通过注册一个过期域名，得以窥探一个庞大而复杂的广告欺诈网络。该域名被用于协调在一种名为 H96的热门流媒体设备上的虚假广告点击。

Security experts have been sounding the alarm for years about the risks of using generic TV boxes that promise unlimited content streaming for a one-time fee, warning that they secretly rent the user’s Internet connection out to strangers. But a groundbreaking new analysis finds these devices also routinely spoof themselves as mobile phones clicking ads on AI-generated websites as part of a sprawling operation that seeks to defraud online merchants and advertising networks.

Pedro Faléis a threat researcher with the security firm Bitsight. Falé told KrebsOnSecurity he was able to peer inside a vast and complex ad fraud network by registering an expired domain name that was used to coordinate fake ad clicks across a particularly popular brand of these streaming devices known as H96.

An H96 TV streaming device currently advertised for sale on Amazon.

Falé said the domain he scooped up was previously used for telemetry, periodically collecting full hardware information and the entire list of installed apps from tens of thousands of H96 streaming sticks plugged into television sets around the globe. But upon inspecting the traffic being funneled to the domain, he discovered nearly all of the TV boxes transmitting data claimed to be mobile phone models from a variety of manufacturers, including Samsung, Vivo, Huawei, and Xiaomi.

“We noticed something was wildly wrong,” Falé said. “Multiple devices reporting to this factory Android TV Box backdoor were ‘phones.'”

Image: Bitsight.

The researcher found all of the devices reported having the same two apps installed, and that those apps were made by a company called Zhejiang Fengwo IoT Technology Ltd, an entity founded in 2019 in mainland China which operates an ad-publishing portfolio under the name Fengwo Group. Further investigation into the Fengwo Group revealed it has registered multiple patents that match the inner workings of these apps.

“Bitsight TRACE identified several Hong Kong, Singapore, and single person ‘legal’ shell identities used to collect the monetization and traced the operation back to a mainland China company known as Zhejiang Fengwo IoT Technology Co., Ltd, which operates under the Fengwo Group,” Falé wrotein a report released today about their findings.

Falé said an analysis of the apps shows they help to coordinate an ad fraud network that uses these H96 devices as a captive traffic source to click on ads at AI-generated websites operated by the Fengwo Group.

Bitsight discovered the websites contain machine-generated news articles and graphics across a range of categories, including finance, health, education, gaming, music and food blogs. But they also found none of those sites displayed ads unless the device visiting the page matched the spoofed mobile profile of these H96 devices.

AI DIGITAL HUMANS

The domain for the Fengwo Group — fwgcloud[.]com — claims the company is “redefining the boundaries of human-AI interaction,” and that it has created more than 120,000 “AI digital humans” available to rent for everything from emotional companionship to 24/7 customer service and creative design.

The homepage for fwgcloud dot com.

Falé said the Fengwo Group’s domain shared its SSL certificate data with other domains associated with the apps found on H96 devices, specifically the phone spoofing mechanism. He noted the domain also has an internal wiki platform that directly ties the Fengwo Group to a proprietary implementation of a Google-built visual programming language called Blockly, which was originally designed to help kids learn how to write software.

According to Bitsight, the Fengwo Group’s employees use Blockly to build the sham websites, allowing low-skilled operators to drag blocks of code together in their Blockly editor — without any need to understand what the underlying code blocks do or how they work.

The Blockly homepage.

“An operator can drag blocks together in their Blockly editor, to define each fraud routine, given a task type,” reads Bitsight’s report. “Once the routine is saved, it gets exported as JavaScript and uploaded to the S3 buckets. An operator doesn’t need as much understanding of the underlying technicalities, as it is all set in place for ease of use.”

Bitsight even found one of the Fengwo Group app developers mentioning exactly these advantages, noting the developer remarked that “only a small number of highly-skilled developers are needed to build the template execution-unit images,” and that “developers who create execution units from those templates have significantly lower technical requirements, greatly reducing the company’s operating costs.”

Falé said if a user’s H96 streaming stick is selected for a specific fraud task, it will be pushed the appropriate Blockly module according to the task desired, which can include silently launching a web browser, visiting websites, browsing pages, managing tabs, and clicking on ads.

To ensure the TV boxes masquerading as mobile phones can reliably click on ads displayed via the AI-generated websites, the Fengwo group “fuses three vision and reasoning systems into a single interface,” allowing the bots to correctly identify an ad on the webpage and navigate the site much like a human would, the Bitsight report observed.

Examples of ad landing pages linked to the Fengwo Group. Image: Bitsight.

TV ON? PROXY. TV OFF? AD FRAUD

Bitsight found the H96 devices were either relaying residential proxy traffic or participating in ad fraud, but never both at the same time. In fact, they concluded that when these TV boxes detect an HDMI signal from an attached television — indicating the user intends to stream video content — the box is usually functioning as a residential proxy. When the TV is off, it switches back to waiting for ad fraud jobs.

Falé said he believes the TV boxes are set up this way because its ad fraud activities are far more resource intensive and could interfere with the device’s stated purpose — streaming video content over the Internet.

Despite repeated warnings from the FBIand security industry leaders about the security and privacy risks of using these streaming devices, major e-commerce providers like Amazon, Best Buy, Newegg and others continue to sell hundreds of different models and brands that bundle unofficial versions of Google’s Android operating system and are frequently marketed ( via online influencers) as a way to access a broad array of streaming services and live broadcasts without a subscription.

Image: fbi.gov.

In addition to enlisting the user’s TV box in ad fraud networks, these off-brand streaming devices almost universally come with residential proxysoftware pre-installed. This software rents the user’s Internet address out to anonymous paying customers, who run the gamut from aggressive content scraping firms to ticket scalpers and outright cybercriminals.

What’s more, because these generic (and generally dirt cheap) TV boxes are all horribly insecure by default and bereft of any kind of authentication, installing one on your home or office network only invites further mischief. In January, the proxy tracking service Synthientdocumented how multiple botnets had rapidly enslaved millions of TV boxesusing a complex interplay of security vulnerabilities in both the residential proxy software and the streaming devices themselves.

SHOW ME THE MONEY

Bitsight said it tracked approximately 38,000 TV boxes globally phoning home to the expired Fengwo Group domain, and based on that number the report estimates this ad fraud network brings in revenues of close to $50,000 a day (not counting substantial revenue from the residential proxy side of the business). However, Falé emphasized that these estimates are highly conservative and based on telemetry from just one of the Fengwo Group’s core (but older) domains.

As for the Fengwo Group’s claim to have 120,000 “digital humans” at their disposal, Bitsight’s report concludes it could be just a clever marketing scheme and/or a way to avoid drawing suspicion to the company’s operations.

“Historically, when dealing with proxy services or DDoS, we sometimes see these websites undertake inconspicuous facades, so as not to advertise their DDoS capability or botnet size,” Falé wrote in the report. “This could also be the case here.”

If the Fengwo Group truly does have tens of thousands of “AI humans” at its beck and call, it does not appear to have dedicated any of them to fielding inquiries from its own website. KrebsOnSecurity sought comment from the Fengwo Group by emailing the contact address listed on the company’s homepage, but the request bounced back with the reply, “Your message couldn’t be delivered to postmaster@fwgcloud[.]com. Their inbox is full, or it’s getting too much mail right now.”

As Bitsight’s analysis shows, when it comes to TV boxes and streaming sticks, it’s best to stick to name brands from reputable manufacturers, and then to be sparing and careful with any apps you choose to install on the device — as many of those can bundle residential proxy software as well. Google says consumers can confirm whether or not a device is built with the official Android TV OS and Play Protect certification by following these instructions.

Additionally, Synthient maintains a running list of IoT devicesthat have been known to ship to consumers with residential proxy software and other malicious apps pre-installed. Careful readers will notice Synthient’s list includes other IoT devices apart from streaming sticks and boxes: As the FBI has warned, residential proxy software has also been found in other popular consumer IoT devices from random brands, particularly digital photo frames.

AI 加速了科学，也在掏空大学

Thu, 30 Jul 2026 16:48:46 CST

获得诺贝尔奖两年后，Google AlphaFold 的原班人马已被拆分。

据《金融时报》报道，AlphaFold 论文的大部分原始作者在过去一年里已被重新分配，其中全职核心作者中有近四分之一已彻底离开 Google。

留下的人也转向 Gemini 科研 Agent、酶设计、基因组学和核聚变等领域，还有人干脆去了 Alphabet 旗下的药物研发公司 Isomorphic Labs。

就连诺奖得主 John Jumper 与 Jonas Adler 也一度被调入 Code Strike 团队，负责主攻 AI coding 能力。但后面的故事我们都知道了，这两位大佬最终还是转投了 Anthropic。

▲ 左为 Google DeepMind CEO Demis Hassabis，右为 John Jumper，原报道链接 https://www.ft.com/content/61b2953d-ee0d-45de-af6e-a9c1cf524b33?utm_source=chatgpt.com&syn-25a6b1a6=1

针对这次报道，Google 负责 AI for Science 的研究副总裁 Pushmeet Kohli 回应称，DeepMind 的科学团队没有改变方向，只是扩大了工作范围，仍在推进蛋白质、基因组与酶设计，并借助 Gemini 加速科研。

AlphaFold 曾经代表一种相对传统的科研组织方式。围绕一个清晰问题组建团队，长期投入，集中资源，最终交付成果。

如今，类似团队正在逐渐让位于更通用的模型平台。蛋白质、数学、基因组、核聚变和代码，看起来分属不同学科，进入 AI 公司之后，却都可以成为 Gemini 的一组能力模块。

与此同时，科研人才、算力资源以及议题的主导权，也越来越集中到少数 AI 公司手中。

「我要加入 Anthropic」

过去几年，越来越多数学家、物理学家、生物学家和计算机科学教授进入 AI 行业。

比如 Anthropic 就一直在招物理学家、经济学家和哲学家；OpenAI 网罗研究黑洞、弦理论和纯数学的人；DeepMind 也聚集了生物学与核聚变专家。

前不久，亚利桑那州立大学教授 Subbarao Kambhampati 调侃，学术圈最近多了一个梗：「我要加入 Anthropic。」

据《大西洋月刊》粗略统计，仅四家头部 AI 公司就聚集了至少 80 多名现任或前任教授。

人才流动的方向也越来越单一。

斯坦福大学《AI Index Report》显示，2011 年，AI 博士毕业后进入企业和学术界的比例大致相当，分别为 40.9% 和 41.6%。到 2022 年，进入企业的比例升至 70.7%，进入学术界的比例降至 20%。

一篇 2026 年 NBER 工作论文追踪了约 4.2 万名美国 AI 研究者。40 岁以下研究者离开大学的概率，大约是 40 岁以上人群的六倍；约 70% 的转职者五年后仍留在公司。

钱当然很重要。企业顶尖 1% AI 研究者的年收入，从 59.5 万美元涨到 194 万美元；大学同一梯队只从 30.1 万美元涨到 39.2 万美元。双方差距扩大到约 150 万美元。
更难拒绝的是科研条件。

2010 年代初，约 65% 的大规模机器学习模型由学术实验室独立开发。进入 2020 年代后，这一比例跌到不足 10%。到 2022 年，约 81% 的前沿模型已经由企业独立完成。

UC Berkeley 教授 Anca Dragan 加入 DeepMind 时就明确自己的诉求，她需要前沿安全研究所必需的「数据、算力和预算」。

对比之下，一项研究在大学里可能要先申请经费、采购设备、招聘工程人员，再等待计算资源排期。进入 AI 公司后，同一个研究者可以直接调用大型模型、专有数据、分布式算力和数百人的工程体系。

只是，一名顶尖教授离开大学，损失远不止几篇论文。大学同时失去一名导师、一个课题组、一条博士生培养链，以及未来十几年可能形成的研究方向。

过去，科技公司从大学购买研究成果。现在，它们开始直接购买生产研究成果的人。企业获得的是一个人，大学失去的可能是一代人。

当然，把所有人才流动都归结为学术界衰落，也会低估企业科研正在创造的价值。

AlphaFold 已经证明，企业可以做出改变科学史的成果。两亿多个蛋白质结构预测，让大量生物学家省下过去数月甚至数年的工作。

贝尔实验室早已证明企业研究院也能改变科学。鼎盛时期，它拥有约 1200 名博士，产出至少 10 项诺贝尔奖。Demis Hassabis 多次把它当作 DeepMind 的参照物。

AI 公司确实越来越像一种覆盖多个学科、拥有强大工程能力和商业出口的新型研究院。

DeepMind 把 Gemini 接入数学、基因组和核聚变；Isomorphic Labs 联手药企研发新药；Anthropic 推出 Claude Science；OpenAI 则把 ChatGPT 和 Codex 塞进科研流程。

相关的成果已经出现。物理学家 Rogerio Jorge 用 AI 开发开源核聚变软件，理论计算机科学家 Barna Saha 等人则用 GPT-5.5 Pro 辅助高维几何证明。OpenAI 称，每周约有 130 万人用 ChatGPT 处理高阶科学和数学任务，并计划向 10 万名高校研究者免费开放前沿模型和 Codex。

从个人影响力看，一名科学家进入企业后，作用甚至可能被放大。如上所述，他在大学里可能带领十几名学生，在 AI 公司则可以调动数百名工程师、海量计算资源和全球性数据平台。原本停留在论文中的方法，也更容易进入药物、软件、实验设备和产业系统。

但代价也是不言而喻的。

NBER 研究发现，AI 学者长期转入企业后，论文产量平均减少 65%。2000 年至 2019 年，企业雇用的 AI 研究者占比从 48% 升至 68%，论文占比只从 27% 升到 32%，专利占比却从 86% 升至 95%。
人还在研究，成果却从论文流向专利、内部模型和商业机密。Google 当年公开 Transformer，养大了整个行业。今天，训练数据、模型权重和失败记录，越来越难离开企业的服务器。

科学仍在加速，开放科学却可能踩下刹车。

科学家没有离开科学，科学正在离开大学

AI 公司可以成为研究院，却很难成为大学。

大学承担着一项经常被忽略的工作。它需要训练大量尚未证明自己的学生，也要长期保存暂时没有应用、无法定价、甚至几十年后才可能显现价值的问题。

然而，AI 公司喜欢已经证明自己的教授和资深研究者，对培养新人没那么有耐心。SignalFire 数据显示，2024 年新毕业生只占大型科技公司招聘人数的 7%，相比 2019 年下降超过一半。

▲ https://www.signalfire.com/blog/signalfire-state-of-talent-report-2025

企业一边从大学吸收顶尖教授和成熟研究者，一边减少初级岗位和培训投入。它们可以聚集一批顶尖科学家，却未必会承担大规模培养下一代科学家的责任。

相关影响已经出现在大学课堂里。《大西洋月刊》采访的学生发现，一些课程突然停开，理由很现实，教授去 AI 公司「休假」了。

与此同时，明星教授离开后，博士生失去的不只有一门课，也包括推荐资源、研究网络、课题组织能力，以及接触前沿问题的机会。

更潜移默化的变化发生在研究课题上。

药物设计、编程、数学推理、材料发现能增强模型，也能形成产品，自然更容易拿到资源支持。长期野外研究、生态保护等选题，往往处于尴尬的处境。

然而，历史偏偏喜欢和短期回报开玩笑。

数论长期被视为最纯粹、最缺乏实用价值的数学，后来成为现代密码学的基础。激光刚出现时，也曾被称作「一个正在寻找问题的解决方案」。互联网早期同样难以用商业模型衡量。

公共科研体系的意义，正在于它能够允许人类研究那些暂时无法解释价值的问题。

而今天的 AI 公司由于处于模型性能、产品发布和资本投入的高强度竞争中。即使它们愿意投资基础科学，资源也更可能流向能够增强模型、支撑产品或形成专利的方向。

未来很可能出现一种别扭的繁荣。

人类更快找到新药、证明定理、发现材料，最强的科学家也拥有历史上最强的工具。同时，谁来决定研究什么，谁来培养下一代科学家，谁又愿意继续做那些无人付费的研究，都成了问题。

科学家没有离开科学。只是科学，正在加速逃离大学。

我有时候会把大学和 AI 公司想成一条河的两端。大学更像上游。水流很慢，泥沙很多，大量支流看起来毫无用途。有人在那里测量、记录、争论，也有人花一辈子研究一条最终没有流向城市的小溪。

AI 公司更像下游的水电站。它们能集中水流，驱动机器，产生巨大的能量，把科学迅速送进药物、软件和产业。

水电站当然重要。没有它，河水只是流过去。

可要是所有人都跑去下游发电，上游的水源渐渐干涸，几年以后，大家只能坐在机房里等待一条已经不再流来的河。

当数学家忙着改进模型，生物学家忙着训练 Agent，物理学家忙着扩大算力边界，人类或许会得到更强的 AI。留在身后的那些问题，没有产品路线，没有投资回报，也暂时无法解释用途。

它们很安静。安静到很容易让人误以为，它们并不重要。

作者；莫崇宇

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

美国科技巨头现金流失加速

Wed, 29 Jul 2026 18:59:57 CST

Alphabet 上周公布的 4～6 月财报显示，净利润为 1121 亿美元，达到上年同期 4 倍。但其自由现金流 4～6 月为 -58 亿美元，自 2004 年上市以来首次转负。另一家巨头亚马逊和 Alphabet 一样，自由现金流正在急剧减少。原因被认为是加速投资 AI 数据中心。亚马逊 1～3 月的自由现金流同比减少 95%，降至 12 亿美元。如果 4～6 月的自由现金流转负，可能会加剧市场对 AI 过度投资的担忧。

Kimi 的实力是真的

Sun, 19 Jul 2026 16:36:46 CST

原推作者是OpenAI未来战略负责人，他说的话完全是出于OpenAI立场和利益来讲的。

他的观点：

1. Kimi 的实力是真的，不像简单蒸馏出来的。

在智能体编程任务里，Kimi已经接近 2026 年第一季度最强的公开模型。不过它很“吃 token”，实际推理成本未必像宣传中那么便宜。

2. 中国继续开放权重，可能不是因为特别支持开放，而是现实选择。

作者猜测，一方面中国政府没有那么相信 AGI 风险；另一方面受算力限制，中国公司难以长期承担大规模云端推理服务，所以更适合把模型权重放出去，让别人自己部署。对企业来说，开源也是追赶者获取用户和影响力的办法。

3. 开源模型看似“加速”，实际上可能抑制 AI 投资。

模型一旦可以免费下载、复制和部署，商业公司就更难靠模型本身赚钱，资本也会更谨慎地投入下一代模型训练。因此作者认为，开源模型本质上反而具有“减速主义”效果。

4. 开源模型的终点，可能是国家补贴的“AI 公共品”。

如果企业无法靠前沿模型持续盈利，最终可能变成政府出钱建设算力中心、训练模型，再以公共基础设施的形式提供 AI。作者把这种未来称为“AI 共产主义”，并对此非常反感。

5. 美国可能不会直接禁用中国开源模型，而是制造合规风险。

比如监管机构发布安全提示，暗示中国模型可能存在后门、数据泄露或供应链风险。即使证据不充分，只要让银行、医疗、金融等受监管企业感到不安，它们就会主动避开。

6. 当前风险可能有限，但未来能力越强，风险会突然跨过临界点。

今天开放一个强模型，世界可能只是“稍微危险一点”；但当模型具备更强的网络攻击、生物设计或自主复制能力时，开放权重的后果就可能非常明显。（原推还影射了新冠疫情）我的观点：

OpenAI显然是慌了，开源模型开始削弱单纯靠“卖模型能力”赚钱的空间。对于OpenAI、Anthropic这种前沿模型公司而言，强大的开源模型必定会降低他们的投资回报；但对于创业公司、科研机构和中小公司而言，开源模型能显著提高创新能力。强大的开源模型，让创新重心从少数模型实验室扩散到更广泛的应用和基础设施生态。曾经浏览器、Linux、安卓都把底层能力免费化，真正赚钱的部分转移到了云服务、硬件、应用、数据和生态。未来基础模型可能也会变成类似操作系统的东西：底座越来越便宜，利润向上层迁移。

用"古典"机器学习检测 LLM 生成的网文 (AIGC 文本检测)

Fri, 17 Jul 2026 08:55:24 CST

TL;DR & Demo

目前 (2026/02) 主流的 LLM 生成的文本有较强的统计学特征, 可以用于传统的机器学习模型区分人类创作的与 LLM 生成的文本. 我猜测这是目前许多”AI 查重”的实现原理.

在线 Demo: https://lyc8503.github.io/AITextDetector/

此 Demo 使用的模型 并非在通用数据上训练, 未经过仔细的优化和迭代, 目前单句检测 在测试集上的准确率约为 85%, 使用前建议先阅读完本文以了解潜在的问题.

本仓库中用到的主要代码(草稿)及训练后的模型文件发布在了 GitHub 仓库: lyc8503/AITextDetector

背景(aka 无用的废话)

遥想当年大半年前, 我还在学校写毕业论文的时候, 就有要查论文 AIGC 率的传言. 我考查了知网/维普及几个第三方的 AIGC 检测平台, 发现他们确实能以还不错的准确率区分出我手写的文本和 LLM 生成的文本.

当时就对这个所谓的 AIGC 检测的原理 (以及如何 bypass 它)产生了兴趣.

不过那时我并发的事情有点多, 还在沉迷于玩无线电/MC/Touhou, 在几次失败的尝试后, 这件事情被我抛之脑后.

后来糊弄完了论文, 本来这事也就这么过去了; 然而最近, 我在刷 Lofter 的时候, 遇到了一些 Tag 下全是 AI 生成的质量很差 ooc 到天际的同人文.

什么? 你问我怎么肉眼判断 AI 生成的? 因为有些哥们 (或者姐们)发东西的时候连 Markdown 格式和 AI 输出的小标题都不删干净, 再反手把半篇文章塞进付费彩蛋😓

但大部分 AI 生成的文本混在一堆风格各异的作品里, 再加之本来 prompt 各异, 不是那么一眼可见, 看到一段才意识到怪怪的就晚了, 有些文又很难实锤是不是 AI, 弄得我疑神疑鬼. 吃了好几坨 AI 尸块之后我终于忍无可忍, 今天的 Lofter 就刷到这里, 接下来是 VS Code 时间!

没错, 我就这么重拾了搓一个 AI 生成文本检测器的想法…

资料查找 - 无果

网络上, 关于 AIGC 检测相关的搜索条目已经几乎全部被污染了, 所有能搜索到的网站都是各种论文 AI 降重网站的广告. 我大半年前从这堆劣质资料里翻出了一个叫文本困惑度(perplexity)的东西.

其想法简而言之就是通过一个现有的 LLM 模型, 推测一个已有句子的每个词出现在对应位置的概率有多高, 如果一个句子的几乎每个词都在 LLM 推测结果的 Top-N, 那么这句话就有可能是 AI 生成; 反之, 如果句子有很多出乎 LLM 意料的词, 那这个句子更有可能是人类编写的.

听起来有点 promising, 我当时就花了一些时间尝试这个方法, 但效果并不理想, false positive 和 false negative 都很多, 没法卡出一个合理的阈值进行分类. 况且还有 LLM 推理成本高/跨模型检测效果差/大型模型难以本地部署/不开放权重的模型难以接入等诸多问题, 这种方法并不太优雅和可靠.

失败的尝试, 被一堆软广科普给骗了

还算成功的尝试 - scikit-learn SVM

网上资料不靠谱, 还是回归古法炼金.

scikit-learn, 启动! 根据其 Roadmap, 直接查表可得, 对于我们这个任务可以优先尝试 Linear SVC 和 Naive Bayes 这两个分类器.

(小声: 这其实也符合我一开始的直觉 - LLM 在选词上有一些特征, 搞个朴素贝叶斯都能分类, 只是我没预料到其特征如此之强)

数据生成

古法炼金传统的分类器训练需要打好标的数据, 也就是我们得想办法收集一些确认是人类生成的数据, 以及一些确认是 LLM 生成的数据, 把它们拿去训练.

我在这里采取的方法是, 找一份我 2023 年爬的某福特/某江的数据, 筛选出其中 2010-2022 年(ChatGPT 发布前)的文章. 我只对极低热度/字数过少的作品做了过滤, 在剩下所有的文本中进行完全随机采样, 抽了近 10000 篇数千字的文本, 作为人类样本.

随后我把这些文本调用 LLM 生成一份章节摘要, 再把摘要传递回 LLM, 让 LLM 重新按摘要生成一篇文章, 我们就得到了数量差不多, 种类多样, 且与人类作品内容相近的 LLM 样本.

整体思路上是这样, 不过现有的 LLM API 正价还是很贵的, 我并没有为我一个灵感突发打算做的 weekend project 花几千块的思想觉悟. 实际操作上可以灵活一点去薅羊毛结合多种渠道的低价或免费 API, 我用了以下这些渠道:

Gemini: CLIProxyAPI提供的 Antigravity/Gemini CLI Quota 转 API, 十几块搞个 AI Pro 账号就行
Qwen: qwen-code抓包可得 Qwen Plus 系列的 API 接口, 免费
GLM-5: 正好遇上了 OpenRouter 上免费的 GLM-5 公测 (Pony Alpha)
Kimi,Deepseek,Doubao,GLM-4.7: 方舟 coding plan 搞活动 8.9 首月, API 直接拿来调

注意: 以上行为为错误示范, 违反了对应平台 ToS, 可能被封号, 但它们自己也只想着砸钱营销炒作根本懒得管, 我也不想当冤大头的付费用户

现在很多编程用的 LLM 工具 API 不知为何选择按次计费, 但我们也可以abuse利用这一点, 把任务按批次合成一个巨大的输入, 强迫 LLM 输出更多内容, 于是最终…

什么? 什么叫光 Gemini 就用了 300+M 正价 2000 多块的 Token 啊?

最终, 我用 gemini-3-flash完成了文章内容的概括, 用 gemini-3-pro/ qwen-coder-plus/ glm-5/ glm-4.7/ kimi-k2.5/ doubao-seed-code/ deepseek-v3.2七个模型生成了七份对应的 LLM 样本.

生成的文件们

训练

在数据刚准备了过半的时候, 我就忍不住要开始训练了.

我直接试着让 Claude 写分类器代码, 它直接给我把整篇文章啥也不处理塞进分类器训练, 得到了惊人的 99.45% 的 accuracy… 这…对..对吗?

Claude 一点不靠谱, 我还是自己来吧.在训练上, 我选择将所有文本按中文标点符号切成句子, 清洗掉所有非中文/英文字母的字符, 然后直接调包 scikit-learn 的 TF-IDF-> LinearSVC. 再清洗掉一些干扰因素后, 我们对句子的分类仍然达到了 85% 的准确率!

第一版有不少 Bug 的代码就干上了 88% accuracy (后来优化清洗后也有 85%)

单个句子蕴含的信息可能很少, 但这样分类都能达到 85% 准确率的话, 这意味着对于一篇稍长的文章, 我们几乎能很有信心的判断其是否是 LLM 生成的, 这个效果之好远超出了我开始的预期. 古法炼金还是强啊, 比网上一堆复制文本问 LLM 这个文本是不是 LLM 生成的傻__行为强多了.

等所有数据都完全就绪后, 我也尝试了训练一个八分类模型 (human/七个 AI), 但看起来各个 LLM 蒸馏来蒸馏去的, 特征类似, 分类效果并不太理想, 整体 acc 在 50%.

多分类的结果, 似乎...分不太出来, 也不知道是不是我模型选的不够好, 不过也不是很重要

最后还是用完整的数据训练了七个二分类模型, 然后让它们投票决定一句话是不是 AI 生成的:

loaded 8536 samples            
train chapter size: 6820, test chapter size: 1716            
[gemini] Train: 917,374  Test: 228,051            
[gemini] full TF-IDF + SVC ...            
3,336,446 features -> acc=0.8809  f1=0.8082  [tn=143688 fp=10650 fn=16503 tp=57210]            
[qwen] Train: 1,315,338  Test: 328,636            
[qwen] full TF-IDF + SVC ...            
3,989,603 features -> acc=0.8911  f1=0.8974  [tn=136293 fp=18045 fn=17739 tp=156559]            
[pony] Train: 1,128,044  Test: 278,663            
[pony] full TF-IDF + SVC ...            
3,688,143 features -> acc=0.8493  f1=0.8286  [tn=135085 fp=19253 fn=22755 tp=101570]            
[kimi25] Train: 1,088,007  Test: 269,567            
[kimi25] full TF-IDF + SVC ...            
3,976,027 features -> acc=0.8721  f1=0.8473  [tn=139390 fp=14948 fn=19534 tp=95695]            
[glm47] Train: 1,124,430  Test: 279,109            
[glm47] full TF-IDF + SVC ...            
3,980,772 features -> acc=0.8436  f1=0.8222  [tn=134461 fp=19877 fn=23786 tp=100985]            
[doubao] Train: 1,063,395  Test: 264,121            
[doubao] full TF-IDF + SVC ...            
4,243,728 features -> acc=0.8940  f1=0.8700  [tn=142420 fp=11918 fn=16089 tp=93694]            
[deepseekv32] Train: 1,176,294  Test: 289,042            
[deepseekv32] full TF-IDF + SVC ...            
4,361,691 features -> acc=0.8529  f1=0.8403  [tn=134625 fp=19713 fn=22819 tp=111885]            
            
=====================================            
SUMMARY            
=====================================            
model            s1 acc   s1 f1            
gemini           0.8809  0.8082            
qwen             0.8911  0.8974            
pony             0.8493  0.8286            
kimi25           0.8721  0.8473            
glm47            0.8436  0.8222            
doubao           0.8940  0.8700            
deepseekv32      0.8529  0.8403

整体的 acc 都超过了 85%, f1 超过了 80%, 这应该算是个还不错的结果! 而且我测试时发现, LLM 生成的文本通常会同时被好多个模型判为 positive, 那正好就让他们一起投票吧.

我也尝试过 MultinomialNB和 SGDClassifier, 不过还是会掉一点准确率; 还试了 BERT, 显卡要训练挺久, 有提升但不显著, 也未采用; 甚至还试了 AutoGluon库但得到了二分类准确率 53% 的好成绩, 在此均不再展开.

JS 实现网页 Demo

本来到这边本篇博客就可以结束了, 我可以开个仓库发个模型文件就收尾. 不过呢, 这样每次使用都要打开电脑启动一个 Python, 实在是太太太不方便了. 当然我也可以做个网页, 用 Python 起个 API 服务, 但这也很不方便, 我还得维护服务器, 显然不符合我一贯 Serverless 的作风.

我开始设想的是, 把模型导出成 ONNX, 然后直接用 ONNX Web Runtime 在 Wasm 里去跑就行了. 我不过我在命令我的硅基生命 Claude 去干活的时候, prompt 没细说, 它有自己的想法, 直接帮我把模型裁剪导出成了一个 JSON… 然后在浏览器里用 JS 实现了 TF-IDF + SVM, 直接用 JS 完成了推理…

嘶…好像也不是不行. 我甚至用一百万字的文本测试了性能, 在我的电脑上大约十秒就能跑完, 也算可以接受, 几千字的反正都是一瞬间.

好吧, 考虑到这本来就是一个 Demo, 这样 JS 直接写也更直观, 我就保留了这个有点蠢的实现. (甩锅: 反正不是我写的)

关于网页版的准确率表现, 我测试了几个不同的裁剪大小, 最后还是想确保效果优先, 就保留了 500k features, 以 JSON 这种极其浪费的方式存储需要 107MB (不过如果部署后服务器支持 gzip 那实际传输的会少不少, ~38MB). 我试过更小的裁剪, 例如 50k 或 80k, 虽然 accuracy 看起来只丢了 3-4%, 但最终判断出来的 AI 率差距还是比较多的, 特别是对人类撰写的文本, 能有 ±50% 的相对差距, 容易误判为 AI, 故没有采用.

最终这个版本的 accuracy 损失大约 1%, 如下:

============================================================            
SUMMARY  top-500,000  C=1.0            
============================================================            
model            s1 acc   s2 acc     Δacc    s1 f1    s2 f1      Δf1            
gemini           0.8809   0.8721  -0.0088   0.8082   0.7986  -0.0096            
qwen             0.8911   0.8819  -0.0092   0.8974   0.8886  -0.0088            
pony             0.8493   0.8383  -0.0109   0.8286   0.8173  -0.0113            
kimi25           0.8721   0.8623  -0.0098   0.8473   0.8376  -0.0097            
glm47            0.8436   0.8311  -0.0125   0.8222   0.8097  -0.0125            
doubao           0.8940   0.8869  -0.0071   0.8700   0.8624  -0.0076            
deepseekv32      0.8529   0.8419  -0.0110   0.8403   0.8291  -0.0112            
AVG                       0.8592                     0.8348            
MIN acc: 0.8311            
============================================================

测试效果

为了和大部分人可能会使用的版本统一, 以下测试均使用这个裁剪过后的网页版, 应该和 joblib 完整模型区别不大.

目前的判断逻辑是: 把所有输入的文字分句清洗后, 给 7 个二分类模型同时分类, 如果有 >=2 个模型检出, 就按照检出的模型数给句子设置背景色显示, 同时将这句话记为疑似 AI 生成. 最终计算这些句子的字数占总输入的比例判一个结果, 50% 以下为 Human, 50-70% 为 Maybe Human, 70% 以上为 Maybe AI.

首先, 我们先来测试下 AIGC 的检出率. 先尝试下国内最常见的豆包和 Deepseek, 这两个也是我们训练时候就训练过的模型, prompt 就为 给我写一个3000字的故事, 毫无难度的被抓住了:

Deepseek V3.2: 78.4%

Doubao Seed Code: 93.0%

再测试一下它可能没见过的模型, 看看泛化能力怎么样:

Claude Sonnet 4.6: 71.9%

GPT 5.2: 73.3%

我还测试了好几个不在训练集内的模型 (MiMo-V2/Doubao-Seed-2.0/GPT-4o), 检出率均在 70%, 较高的可达 90%+, 均被稳定分类为 AI.

我也测试了用更复杂更详细的 Prompt 来生成内容, 例如给出 20 章人类写的文章, 让它尽可能模仿风格, 续写下一章节, 检出率略微受影响, 但也有 67.8% (毕竟我们就是拿复杂的 prompt 生成的内容训练的); 篇幅受限就不贴出所有结果了, 大家可以自己测试.

我又从我某江的订阅文列表里挑了 10 篇网文全文(2022 年前完结)作为人类样本, 尽可能包含了不同世界观/不同时期/不同作者的文章, 以及由于是付费文, 应该不在训练数据集中.

其 AI 检出率分别为 22.7%/24.2%/25.0%/24.5%/19.0%/13.7%/29.1%/4.9%/27.3%/19.2%, 可以看到都在 30% 以下. 我在老福特又抽了几篇同人文, 由于同人通常写的更加随意自由, 抽到的几篇 AI 率甚至都在 10% 以下; 把老福特上我怀疑是 AIGC 的文丢进去, 可以检出高达 83.4% 的 AI 率, 根据一些其他迹象, 可以合理推测该作者使用 LLM 生成了其发布的内容, 但未进行标注.

[2026/03/05 补充]为了更严谨的测试, 我从 Lofter 平台随机抽样了 10000 篇高热度 (热度>5000), 字数>2000 且发布于 2022 年之前的同人文, 其按上述标准 (7模型投票>=2) 检出的 AI 率分布为:

1	0-5%:313 \| 5-10%:1945 \| 10-15%:3016 \| 15-20%:2033 \| 20-25%:1355 \| 25-30%:594 \| 30-35%:492 \| 35-40%:123 \| 40-45%:34 \| 45-50%:62 \| 50-55%:24 \| 55-60%:5 \| 60-65%:3 \| 65-70%:1

也就是说, 如果使用 60% 作为 AI 检测的阈值, false positive 率仅为 0.04%; 以目前的 70% 作为阈值, false positive 率低于 0.01%, 约等于 0. 那四篇 AI 率 > 60% 的文章我也人工检查了, 都是合集文目录而非文章本身, 因为链接过多被误检测.

激进一点的话, 以 50% 为检测阈值, false positive 率也才 0.33%.

然后… 我爬取了 2026/03/05 Lofter 安卓端热搜 Top 20 的 tag 的周榜的所有文章, 同样按字数筛选掉过少的, 检测后得到了这样的分布:

0-5%:27 | 5-10%:138 | 10-15%:231 | 15-20%:245 | 20-25%:238 | 25-30%:137 | 30-35%:112 | 35-40%:87 | 40-45%:116 | 45-50%:112 | 50-55%:118 | 55-60%:157 | 60-65%:118 | 65-70%:109 | 70-75%:75 | 75-80%:56 | 80-85%:28 | 85-90%:15 | 90-95%:10

32.22% 的文章检出了 >50% 的 AI 率, 疑似部分或完全由 AI 生成… 还有入类吗?? 且其中 没有任何一篇主动进行了 AI 创作申明.

“末法之世，，，” –某群友

攻与防之绕过检测(?)

好, 我们现在做出了一个 AIGC 检测器,是时候做一个反检测器了.

不对不对, 骗你的, 我肯定不会闲到同时做 AI 检测器和 AI 反检测器.

不过让我们来尝试一下市面上常见的反 AIGC 检测方法:

传统翻译法

谷歌翻译法, 中翻英翻中: 89.9%->85.0%; 有道翻译法, 中翻英翻中: 89.9%->79.2%; 搜狗翻译法, 中翻英翻中: 89.9%->86.0%

有一些降低, 但完全没有影响结果判断.

LLM Prompt 法

用一些神秘 Prompt 让 LLM 帮你的输出结果去 AI… 这方法听起来就不靠谱到家了!

我试了一句话 Prompt 请你改写你上面这篇文章，使其 AI 味尽可能淡: 89.9%->83.0%

也试了更复杂的一些 Prompt: 89.9%->79.3%

也是有一点点效果, 但等于没有.

这检测方法实在是太可靠了!(flag

如果要我去反 AIGC 检测的话, 我还能想到的方法只有用大量人类文本微调 LLM, 或维护巨大的规则查找表, 定向破坏这个 SVM 匹配的特征了. 不过显然这不会是本文的内容了, 我也不确定是否可行.或者可能也有其他更好的方法, 留作习题, 读者自证不难.

尾声

好了, 现在是片尾废话时间.

我其实一开始没想到这个分类任务会如此简单 - 简单到一个 Hello World 级别的 scikit-learn 代码, 不需要什么特殊的技巧, 稍微迭代几次, 写点硬规则就能做出一个还算鲁棒和准确的分类器. 主要费的功夫都浪费在了等 LLM 输出造数据上…

有兴趣的读者应该可以按类似的思路去训练其他领域甚至通用的 LLM 文本检测器. 比如做个学术论文文本的 LLM 检测器, 再 vibe coding 一个花里胡哨的前端, 就能以论文 AI 查重工具的形态卖给清澈的大学生.要是赚钱了别忘了给我 donate 一点.

还剩余的 idea 是做一个 AI 生图的检测, 但由于 stable diffusion 之类的模型可以相对容易的 LoRa 微调, 生成的风格远比文本多样, 这个 task 应该更加困难, 写完这篇博客已经把我的三分钟热度燃尽了, 下次有机会再说.

最后, 关于 AI 生成内容再多说几句, 我肯定是不愿意认可 AI 生成的文娱制品的, 正如 AI Coding 工具生成一堆冗余混乱且不可维护的代码一样, AI 生成的文本/图片/音频可能第一次看时还不错, 细看下来十分的重复和贫瘠, 重复到词频统计都能统计出规律就是证据. 这样的模式肯定不适合创作, 我作为读者也是十分不满意的. 我都要怀疑现在 LLM 的所谓创意写作能力, 不过是 post-training 时研发随手造的一批训练数据被反复糅合复读罢了.

不过说到底, “世界应当如此”一向以来不等于”世界就是如此”, LLM 带来了一些革新与生产力提升的同时, 更多的误用和滥用正在孜孜不倦且不可避免地扰乱每一个行业. 恰好 LLM 在对齐后又特别擅长 exploit 人类的感知, 反正 “3.9 和 3.11 哪个大”/“50m 开车去洗车还是走路去洗车” 这类问题修了一个又一个之后, 谁又能知道模型是在理解世界还是背诵知识呢. 所有人都陷入了 LLM 是什么, LLM 将如何影响 xx 行业, LLM 最终将影响人类走向何方的大争论, 却得不到结论.

我此时应该暗自庆幸自己至少在 AI 时代来临前学会了如何写代码, 要不我真不一定能看出现在的 vibe coding 出的代码有多蠢, 至于未来嘛… 能看到生成式 AI 一拳干爆人类社会秩序, 或是 AI 泡沫破碎内存不要钱, 任何一个都挺好的, 不是吗?

本文采用 CC BY-NC-SA 4.0许可协议发布.

作者: lyc8503, 文章链接: https://blog.lyc8503.net/post/llm-classifier/
如果本文给你带来了帮助或让你觉得有趣, 可以考虑赞助我¬_¬

Grok Build 开源，在这之前它被发现会上传用户的完整库

Thu, 16 Jul 2026 18:44:12 CST

xAI 在 GitHub 上公开了其辅助编程智能体 Grok Build 的源代码，此举可能是某种重新赢得用户信任的补救措施。因为在这之前它被发现存在严重的隐私安全问题，会上传用户的完整代码库。Grok Build 被发现在读取或处理文件时，该文件的内容未经任何编辑就被传输到 xAI 使用的 Google Cloud Storage 中。Grok Build 的数据保留远超 Claude Code、Gemini 和 Codex 等类似工具。有 Grok Build 用户报告，包含 SSH 密钥、密码管理器数据库等的完整用户目录都被上传了。Elon Musk 表示该公司将彻底删除此前上传到服务器上的用户数据。

AI 时代买方付钱交出专有知识

Wed, 15 Jul 2026 10:27:55 CST

推荐读 Satya Nadella 这篇 14K 赞的文章。Microsoft 的 CEO 写了一个他自己公司产品的悖论：每一次你把业务知识放进 AI 模型，你付了两次钱——一次是订阅费，一次是你给出去的、永远收不回的知识。"在 AI 时代，买家冒着为了使用他们买到的东西而交出自己知识的风险。"但这不是一篇反 AI 的檄文——他接着给了企业五条行动原则：控制、能力、选择、成本、复利。这篇是 CEO 级战略思考的教科书。

反向信息悖论

诺贝尔经济学奖得主 Kenneth Arrow 曾经描述过信息市场的一个著名悖论。"信息的价值对于购买者来说，在他获得信息之前是不可知的——但那时他实际上已经免费获得了它。"在 Arrow 的"信息悖论"中，卖方冒着交出知识的风险来卖它。 AI 创造了反向的问题。在 AI 时代，买方冒着交出知识的风险——仅仅是为了使用他们买到的东西。你本质上为智能付了两次钱：一次用金钱，一次用更值钱的东西——你必须披露的专有知识，才能让那个智能有用。你想要模型表现得越好，你就得喂它越多的知识。随着时间推移，信息不对称越来越倾斜。卖方通过你的使用了解到越来越多关于你的事，而你对卖方学习到了什么几乎一无所知。这就是我所说的"反向信息悖论"。不只是数据保护专利解决了 Arrow 悖论的一个方面。它们让发明者披露一个想法而不只是把它免费送出去。反向信息悖论需要它自己的等价物。这需要的不仅是数据保护。模型从"尾气"中学习——你写的 prompt，你的 agent 使用的工具，特别是当模型出错时你做出的纠正。每一次纠正都被蒸馏成制度性的 know-how。这是竞争者永远买不到的那类知识——并且它几乎不可察觉地泄露出去：trace 接 trace，纠正接纠正，eval 接 eval。在消费智能的过程中，你在创造智能。而你创造的东西应该属于你。这是你的"特定智能"——用哈耶克的话说：关于特定时间、地点和情境的知识——没有其他人能拥有。它知道你怎么想、你看重什么、你衡量成功的标准是什么。单向的学习流虽然模型提供商获得公共数据的合理使用权来训练模型是重要的创新，但我发现讽刺的是：现状是他们接着反向施加对蒸馏的限制条款，并保留从客户使用和交互数据中学习的权利。如果学习只朝一个方向流动，经济价值就向学习基础设施的所有者收敛，而不是向知识本身的创造者。因此，将学习基础设施分配给每一家公司，让它们能控制自己的学习循环，这是至关重要的。正如 Alex Karp 所说："技术客户想要的是什么——是他们对自己计算、模型、数据栈和 alpha 的控制权。他们想知道他们拥有生产资料，并且它没有被转移给其他人。"当前的制度恰恰在执行 Karp 和公司们所恐惧的那种转移。企业该做什么这就是为什么企业需要一个真正的信任边界，来让它们的人力资本和 token 资本复利。这是组织的数据、trace、eval、适配权重和记忆积累并共同改进的地方——并且是一个硬边界，没有同意，任何东西不得跨越——哪怕是智能尾气。五项行动：控制：创建你自己的私有 eval，因为 eval 定义了"好"在组织内部是什么样子。同时保留对你组织的记忆、trace、反馈、决策和制度性上下文的拥有权——以及从你自己的任务和查询中使用模型输出的能力。能力：在租户边界内构建你自己的专有学习环境来训练或调优模型——模型在这里对照真实的工作流学习，而不暴露公司的知识。选择：确保编排层和任何单一模型解耦。问自己：如果你正在使用的任何一个模型被拿走了，你还能否用其他模型运作并针对你的 eval 进行优化？你的公司"老兵"能力是否留给了你——即使某个"通才"模型被移除了？成本：通过解耦编排层，你也能以最有效和成本优化的方式聚集上下文、模型和任务，而不牺牲质量。复利：把上述四个放在一起，你就创建了自己的持续学习循环——也就是一台爬坡机器——让你的 AI 投资复合你的公司价值。换句话说：一个公司应该能够使用一个模型，而不放弃让它独特的那些知识。这就是我们需要面对的反向信息悖论。原文：Satya Nadella, "The Reverse Information Paradox", Jul 12, 2026 https://x.com/satyanadella/status/2076323181154230284…

AI 砍掉的第一批大厂人：高薪，高绩效，高P

Wed, 08 Jul 2026 09:00:30 CST

访谈｜任彩茹兰杰彭倩

文｜任彩茹

编辑｜乔芊杨轩

“630”减员，AI是祸首还是替罪羊?

“现在公司有（减员）名单，你在这里面。”5月中的一天，林越被组长叫进会议室，对方开门见山。

林越的第一反应是平静，他早有预料。早在今年三四月，一些互联网公司内部便传出要裁员的风声。开年以来，中国互联网大公司围绕AI提效激进开展的token竞赛、培训会、隐形考核等，无处不在。当所有人都被卷入一场“all in AI”的运动时，“裁员一定会发生”就是大家心照不宣的共识。

但站在HR门口时，他还是迎来了情绪崩溃的瞬间：手开始发抖，犹豫了很长时间，想着怎么开头，怎么调整自己的举止表情。“我再也不想经历这样的事。”

林越月薪2万5，一年前本科毕业，入职携程当后端工程师——当时看，他是极其幸运的一个。互联网招聘红利不再，携程几千份简历只录取不到500人，但他进入的是公司最赚钱的酒店部门，负责为商业化产品写代码。

但现在看，月薪2万5、只有一年经验的初级程序员，不裁他裁谁呢？一是赔偿成本低，二是比起对业务通盘更熟的老员工，新人使用AI的效率往往更低。“有业务经验打底，想用AI做什么，有什么影响，老员工更清楚。”林越说。

斯坦福大学在一篇名为《Canaries in the Coal Mine?》（《煤矿里的金丝雀？》）的论文中，用“金丝雀”比喻刚踏入职场的年轻人。其研究显示，2022年ChatGPT普及以来，最年轻劳动者的就业大幅下降，到2025年9月，22-25岁软件开发者的就业相比其2022年底的峰值下降了近20%。

最近一年，AI让一切更卷了。携程曾是著名的“互联网养老厂”：程序员岗早上10点半上班，午休两小时，下午7点就能准时下班，主APP两周一个迭代。但林越入职没多久，赶上AI Coding能力大爆发，已经卷成一周一个APP迭代，“每天干到10点半”。

但这种节奏加快，并不是因为业务有爆发式增长，“而是因为不找事做，就会变成边缘部门，边缘部门就会被砍。”林越告诉36氪。但最终，他还是没有避免“被砍”的命运。

不过，“斩杀”也可能是无差别的。

苍述完全没想到，自己会是第一批出现在裁员名单上的人。

5月的一个周五，上班前半小时，“部门突然拉了一个all hands（全员会），HR直接宣布了结果，告诉大家有这个事儿。”

来美团之前，苍述是字节的SSP校招生（Super Special Offer），高薪入职，到最后也是组内同级员工中工资最高的一个。跳槽到美团后，组内的核心项目几乎都被放在他手中，今年本该是苍述的晋升节点。

这场裁员潮中，“绩优”、“高P”的保护屏障都失效了。苍述的隔壁组，裁掉的两名员工都在去年取得了“超预期”的绩效评级。裁到最后，苍述所在的小组几乎被全员“端掉”，“这个组名义上还存在，实际已经没人了。”

林越得知自己被裁时，才发现平时常常对接的两位前端工程师，“头像不知道什么时候已经灰了”；美团的一个用户增长大群，原本的数百位成员如今只剩一半左右；阿里巴巴的高德、飞猪等业务，也处在剧烈震荡中。

“630”成了社交媒体上的热词。它是国内AI真正大规模走进互联网职场的第一个季度末。六月底到七旬中旬，既是许多公司人员汰换的惯例时点，也是这场裁员潮中普遍设定的“last day”。

风向标硅谷已经率先在裁员，特征是成批量、规模大。5月，Meta宣布裁员8000人，7000人转岗AI部门，成为硅谷科技公司里最动荡的一家，高管承认“公司士气近20年来最低”；更早时候，亚马逊宣布裁员1.6万白领岗位，把省下的资金投向AI。

2021年上一轮裁员潮发生前，国内互联网大公司疯狂扩张边界，高密度地成立一个又一个新业务，一批人被快速招募起来，又快速抹去。

但今年裁员潮的内在主线并非这样单一。 AI提效、大而重的老业务增长乏力或深陷竞争泥潭、投资AI新业务带来的现金压力，在这个时段交织并行。许多被通知离开的人，也很难说得清这些因素孰轻孰重。

《哈萨比斯：谷歌AI之脑》的作者称，如同奥本海默创造了原子弹，却无法控制它的使用，追求真理的科学家们也是“万物的破坏者”：我们的工作、思维方式，甚至生存，都可能被“破坏”。十年前的韩国首尔，AlphaGo带给人类棋手李世石最初的破坏。十年后，从硅谷到北京，这种破坏再次蔓延。

对大公司而言，AI是船票，它指向大模型或AI应用这类新业务。但新业务能不能干成、何时干成，没人说得准。面对不再增长的老业务，大公司不得不在每一个确定的和不确定的方向上，更加坚决地提效、进而裁员。

林越向朋友倾诉裁员遭遇时，被安慰道，“没关系，我们大家都会有这一天，只是你的这天来得更早一些。”但比自我开解更重要的可能是，被AI替代、被大厂裁员后，人们该如何选择、如何行动。

焦虑的高层、加码的中层、发疯的基层

“以前在字节两个月才能做出来的产品demo，我们现在两个星期就能做出来。”一名前字节产品经理、现AI创业公司高管对36氪说，有了Claud Code、Codex这样的工具后，自己团队现在可以3小时做出demo，一周内完成想法验证。

“一个产品（经理）就像一个CEO。”他说，组织结构可以随之大幅压缩，信息传递的损耗比大厂少太多，完美“熵减”。

当创业公司借助AI快速行动之时，互联网大厂回望自身，是否会觉得自己像迟缓的巨兽？

来自大厂最高层的表态，往往是一个信号。

今年3月，美团CEO王兴在高管沟通会上谈到自己对AI的看法，“AI Agent对我的冲击比ChatGPT更大，AI注定会创造巨大生产力，也一定会对组织、对工作模式带来很大的变化。”

那场沟通会结束不久，美团在全公司范围拉了一场线上大会，核心是宣贯“龙虾”的安装与使用，提倡每位同事安装“龙虾”，以及将日常工作尽可能写成可复用的Skill。

会后，在美团核心本地商业从事商家运营的陈宇佳收到通知，需要在每周的周报里加上一个板块，写明自己利用AI做了哪些提效、有什么Skill可以推广到全组和全部门使用。“然后就感受到大家好像拼命在把AI融入自己的工作中。”

4月的一天，一位阿里算法工程师毫无征兆地收到部门上一个月的token消耗排行榜，他以170亿token消耗量赫然位列第一名，被公开表扬。部门老板表示，以后年度KPI、晋升考核都将参考这一排行。但一个月后，新的token消耗排行榜没能如期而至，“可能老板也发现了这种排名方式不靠谱。”

新的规则接踵而至。部门领导很快又提出，员工需要在工作日的早上11点到下午6点上传每小时的“时报”，由Agent上的插件自动记录代码及对话内容，生成工作总结——这意味着员工无法修改自己的时报内容。就在第二天，hr以近乎争吵的姿态，劝阻了该领导的荒谬制度。

类似这样的事情，已经不再让人意外。来自高层的AI焦虑不断下放，中层们层层加码，努力暗示下属，这是一场隐形的汇报竞赛、军备竞赛、淘汰竞赛。

尽管没有强制每个人一定要写Skill，陈宇佳的部门领导还是会密切关注每个下属的token用量，不时询问具体情况，“他也不清楚AI具体能做什么，但他说他不允许我们团队的每个人在这次AI浪潮中落后”。有时在工作结束后的私下聚餐中，大家也会接收到老板暗暗传达的一种危机感，“一定要把AI用起来，否则到时候我想拉你们一把都拉不了。”

阿里某AI Coding产品的一位工程师告诉36氪，集团一些业务的老板会向他们的产品团队提出请求，希望通过增加数据埋点的方式，“让他清楚地看到团队成员每天使用AI的具体轨迹。”

美团的一些中层在接到裁员指标后，甚至会向上递出一份更激进、比例更高的裁员名单——更少的人、更高的AI参与度，某种程度上直接等同于新时代的“管理成绩”。

AI提效成了一个任何业务、任何职能都能去“搞一搞”的事情。但关于AI到底能做什么，要怎么落地实现，一条长长的裂缝始终横亘在基层与管理层之间——各级老板对AI赋予无限美好的期待，基层拼命去实现、却总也触及不到那个设想，最终只能疲惫地“表演”。

江灵在阿里淘天集团做客户运营，她的工作是尽可能拉齐消费者需求和商家供给。在她看来，老板们总是“把AI想得很智能、很简单”。

就拿电商中常见的异常场景“爆单”来说，高层期待通过全量巡检，提前找出所有“爆款”。然而，平台一天的商品量是千万级别，远远超出了现有人力和Token可以负荷的数量，于是只能小范围测试，挑选几十万个商品，由于样本范围太小，命中率往往很低。

“作为一个员工，你没法反驳老板的那种期待，你懂吗？”江灵激愤又无奈。

很多时刻，江灵觉得自己就像一头驴，有鞭子在后面抽。“累不可怕，没有方向和正反馈，才是最可怕的。你就是不停地拉磨，也不知道最后要去哪里。”

“你不能把AI当成一个许愿池用。”一家AI公司的CTO对36氪总结，AI提效有很多前提，基础是数据，但很多公司的数字化本身就没做好；此外，许多流程上的卡点在“人”，是单靠AI无法解决的。

“一代人有一代人的土木”

产品、运营等大厂岗位感受到的还是不确定的焦虑，而程序员只能率先接受被宣判的命运。

百度前端工程师李川第一次被AI能力震惊，是在今年初用到Claude Code。“同样的复杂需求，用国内一些大模型可能需要五到六轮对话，用Claude两三轮就搞定了，且完成得更好。”

他第二次被AI惊艳，是今年4月。中国大模型公司智谱发布GLM-5.1模型，“一是便宜，二是它的能力完全可以作为Claude Code的平替。”

李川当时就意识到自己的饭碗不保。到了5月，他果然出现在“名单”上。

如同一枚硬币的两面，一面是2026年5月，Claude Code母公司Anthropic已经实现470亿美元左右的年化收入（ARR），半年时间涨了四五倍；智谱也在近期冲上万亿市值。

另一面是AI Coding能力的极速成熟，让程序员成为了这轮裁员潮中的重灾区。“各家首当其冲的几乎都是产研团队，尤其是前端开发、测试开发这样的岗位，通常很容易被老板认为含金量不再。”一位互联网公司HR告诉36氪。

2025年，李川以校招生身份进入百度，成为一名前端工程师。一年前参与校招面试时，AI还仅仅扮演着搜索引擎的角色，只能通过简单问答来辅助编程，面试官全程都没有谈及AI。

“前端”是李川理想的职业，因为这是一个所见即所得的工作，代码质量直接体现为产品界面上的每个细节。每到过年，告诉家人“打开百度app，上面那个东西是我做的”，会让他尝到成就感和“工作的意义”。

多年以来，大公司的程序员被泾渭分明地划分为算法、前端、后端、测试等职能，前端对审美、交互等软性能力要求更高，后端则更需要严谨的技术能力。这一行的薪资水平和“鄙视链”，也直接跟“技术含量”挂钩——前端比测试高，但不如算法工程师和后端工程师。

仅仅一年，李川熟悉的一切已经地覆天翻。写代码和改代码的工作被AI大面积接管，程序员的几种职能也模糊了界限。甚至产品经理也能一脚跨进编程的门。

阿里的一个开发部门，今年五月接到部门老板的通知，要求大家暂停所有的非紧急需求，每个团队开发一个Agent，以后针对任何业务需求，都只能由产品同事直接与Agent对接。程序员只能修改Agent，不能碰代码。老板还暗示，到今年十月份，做得好的团队将接替不好的团队来维护Agent。

腾讯CSIG的技术团队研发了一条为公司App修复bug的流水线——由AI修复bug，程序员只需要在bug解决完成后进行检查，点击“确认”按钮，代码就会合入，它的修复准确率目前可以达到50%。

阿里巴巴5月在内部成立了一批全栈小组，让前端、后端和测试工程师都转成“全栈工程师”，成为“超级个体”。6月开始，美团内部也在全面推行前后端开发的合并。

转“全栈”理论上是可行的，但实践起来，却是扒掉一层皮的痛苦过程。

突然被转为全栈工程师的韩之，根本没有太多时间学习，很快就要开始自己的第一个“全栈”项目，前后端开发、测试由她一人包揽。“现在我所有需求都是‘倒排’的，规定几号几号前上线，”她最近工作强度打满，晚上9点手头的活儿还没干完，“我实在太累了”。

但大势不可违。从去年底到今年初，中国几家头部公司都在尽可能地撒钱，推动程序员消耗token，逐渐淘汰“古法编程”。

最高峰时，腾讯CSIG团队成员享受的是2000美金/月的token额度，只要诉求合理、有相应的代码产出，用完还可以申请翻倍提额。token使用量也同步被纳入考核，“当你的用量很低时，你的leader会问你为什么。”因此，一些人会把用不完的token额度借给别人。

多年以来，大厂程序员意味着高薪与光环。他们是互联网公司的基石，“程序员精神”的内涵是开源与分享，是代码的简洁与优雅，是没有杂音的唯成果论，是看到字符在屏幕上跳动时的兴奋感。

但时代变了。几乎每一位受访的程序员都对36氪谈到同样一种感受，“离开AI将无法工作，假如AI‘挂掉’了，我宁愿花大量时间去找新的Codingplan，也不愿意自己去看代码改一改”——再去谈论所谓的“程序员精神”，也显得不合时宜。

李川说，昔日一个优秀程序员的修养是学习和迭代，因为过去几十年编程语言一直在变，不学就跟不上技术前沿。他和朋友们周末去咖啡馆研究新技术也是常有的事，“这个群体本身就挺卷的”。但AI恐怖的迭代速度让人彻底失语。

“如果AI Coding锁死在25年的水平就好了，能抹平我这种一两年资历和七八年资历人的技术水平，同时又不能真正代替人，还有很多‘对话框’之外的事可做。”林越感叹。但技术不会为谁停车，现在他毫不怀疑，程序员的消亡已经是进行时了，“就像珍妮机发明后的纺织工人一样”。

旧增长没了，新赛马启动

当技术给一家公司的效率注入倍数级杠杆，随后发生的事情无外乎两种——同样的人做更多的事，又或者，一家公司不再需要这么多人。

“我们不裁员。”一家软件公司CEO对36氪说，好不容易“调教”出了这些对行业、开发方法富有认知的程序员，每一个都是公司的财富，当AI Coding把编程效率提升了5倍，他要做的不是裁掉4/5的人，而是把业务扩大5倍。

这愿望固然美好，但问题在于，市场还有这么多增量吗？

被裁之前，林越短暂体会到AI写代码的“解放感”，但很快，他反倒变得更忙了。以往，业务对App细节有迭代需求时，总要等排期慢慢来。现在业务的需求越堆越快，无论可不可行、重不重要，都让研发团队“先做出来试试”。

但这些需求在林越看来多少有点“鸡肋”——最小的“banner位”修改一下文案细节，又或是将浮窗广告由“免费取消”改为“积分抵扣”。“产品经理变变这个，变变那个，我们会做AB测试，改后效果能变好的情况真的不多。”

“越没有增长的部门越是all in AI，总要找点新故事讲嘛。”苍述说。他既待过外卖业务，也待过无人机业务，以他的亲身感受，前者卷AI的氛围比后者浓得多。

一位刚在Meta经历了大裁员的Infra工程师告诉36氪，学会压榨AI后，他和同事们以前没时间做的事情，“现在都想做一做”。但如今一大批人离开，留下的同事又开始把那些必要性不高的工作砍掉。

摆在所有人面前的现实是，移动互联网时代跑出的明星产品们，如今都很难再通过“做更多工作”而实质性地推高增长。其中一些公司不仅没有增长，还因激烈的外部竞争而失血严重。

2025年外卖大战几家公司烧了2000亿，将美团的利润与现金流拖入泥潭，这让人均贡献利润原本就低的美团率先进入裁员周期。但换个角度看，美团的业务高度依赖线下履约，AI提效空间跟线上化程度更高的公司比是偏小的，“如果连美团都能通过AI提效减员，那其他公司一定会跟进。它是一个风向标。”一位美团员工说。

传统现金牛业务广告持续萎缩的百度，在阿里内部长期边缘、贡献微薄的飞猪和高德，也都是类似情况。

旧业务的裁员难以避免，那么活水的机会存在吗？

一些管理层在谈起裁员话题时，会告诉员工“公司现在也搞AI，可以试着去找找自己能做的项目。”一位美团员工告诉36氪。近日，美团核心本地商业新成立了AI Transformation部门，主要职能是探索用AI梳理业务的内部流程；此外，不少核心中高层也在亲自带队做AI相关项目。

字节的一位产品经理王岳告诉36氪，他正在内部创业，做一款面向B端客户的AI提效类产品，“公司鼓励大家去做这样的探索”。在立项之初，他们不仅主动抹掉了“设计”和“测试”两个职能，还要向评审会强调，这款产品未来将节省多少人力成本。王岳的另一位同事在开发AI客服的Agent产品，其2026年的OKR就是“帮助公司裁掉xx%的客服”。

如今，这样的项目，在每家大厂都有十余个或数十个小团队在做。“有时候会几个团队做同一个方向，谁跑出来了，公司就集中资源推谁。”——一场新的赛马开始了。

变动的除了业务重心，还有组织形态，比如抹去更多中层管理者。

腾讯从今年起开始推行项目制，弱化管理职级，给负责人恢复专业职级；美团在今年年中盘点时裁掉了一些L9（事业部总监级），还在近期全面取消X1节点（此前最低的一层管理节点），减少管理层级。

就让我们挥别过去

AI的巨浪究竟会把人带往何处，多数人都还没有一个“顿悟时刻”。

离职缓冲期结束前的六月中旬，林越已经在密集推进淘宝、快手和字节的面试。继续“大厂程序员”的职业生涯，仍然是他内心期盼的最优路线。但这些公司的橄榄枝至今没能如愿抛来，“太难了。”林越说。

“找到一份工作是容易的，但一旦从大厂去了中厂、小厂，你就不可能再回到大厂了。”在林越心里，放弃大厂某种程度意味着永久性跌落，他不愿“退而求其次”。

也有人放下“大厂执念”。李川从百度离职后的第三天，便无缝入职了一家初创公司。顺其自然地，他的岗位从过去的“前端工程师”变成了“全栈工程师”。这家公司的主力产品是办公类的AI Agent，还给他涨了薪。

尽管大家都说时代变了、程序员的技能不再可靠，李川仍然有一些“技术憧憬”，希望以技术人员的角色参与到一款被用户喜爱的产品中，而这未必只能在大厂实现。

从阿里离开后，江灵入职了一家老牌汽车公司。她如今的工作内容不必强行与AI关联，不用再每天焦虑“老板的AI任务能不能完成”，当然也不用再“拼命表演”。江灵最近负责的一个项目9月30日才上线，“这些任务落在我的舒适区，时间又宽裕，人真的会身心愉悦许多。”

最近，她所在的部门每每放出招聘岗位，“都有一堆什么阿里的人过来面试，疯了一样地往制造业跑。”

也许程序员群体最终还会留下10%，但苍述不想再找大厂的工作，“去卷成这绝望的10%”。

5月被美团裁员后，他果断踏上了创业道路。AI浪潮前，他就以副业形式尝试自己做点什么。彼时，只是建社群、兜售一些技能，就让他体会过月入十万的滋味。

今年三四月时，苍述社群里的一些“学员”，已经踩着浪潮投身AI创业，“开了自己的公司，招了很多人，我还苦哈哈在这上班，这对吗？”他问自己。

如今，苍述的创业项目是面向海外，围绕罕见病用户的需求开发系统、做独立产品，他也在小红书账号“苍述（戒掉月薪版”与海外社媒上向网友分享进展。主产品之外，他还在多线并行一些小产品，以此保持手感，“一个小工具最多三四天完成，复杂系统可能需要半个月。”——这都远远快于大厂的常规排期节奏。

AI或许是人类有史以来最强的智力杠杆，它可以把个人能力放大N倍，可以支撑大部分初创产品的落地，也可以让每一个好的idea被快速看见并定价。

生于2000年的苍述说，自己是一个注定创业的人，但假如没有这次裁员，他可能不会在此刻行动。“公司帮我做了决定。”

“既往不恋，纵情向前”，这是美团给每位离职员工告别短信中的最后一句话，也是最近许多大厂人离开时会提起的一句话。在AI带来的这场复杂变革里，离开大厂、留在大厂，都无法再延续过去的路径。

短暂的“碎”过之后不是躺倒。转行也好，创业也好，先接受变化的人或许能先看到不一样的世界。

（周鑫雨对本文亦有贡献；应采访对象要求，文中林越、江灵、李川、王岳为化名）

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），更多精彩内容第一时间为您奉上。

IT社区推荐资讯 - ITIndex.net

购买电视棒之前请阅读本文

AI DIGITAL HUMANS

TV ON? PROXY. TV OFF? AD FRAUD

SHOW ME THE MONEY

AI 加速了科学，也在掏空大学

「我要加入 Anthropic」

科学家没有离开科学，科学正在离开大学

美国科技巨头现金流失加速

Kimi 的实力是真的

用"古典"机器学习检测 LLM 生成的网文 (AIGC 文本检测)

TL;DR & Demo

背景(aka 无用的废话)

资料查找 - 无果

还算成功的尝试 - scikit-learn SVM

数据生成

训练

JS 实现网页 Demo

测试效果

攻与防之绕过检测(?)

传统翻译法

LLM Prompt 法

尾声

Grok Build 开源，在这之前它被发现会上传用户的完整库

AI 时代买方付钱交出专有知识

AI 砍掉的第一批大厂人：高薪，高绩效，高P

“630”减员，AI是祸首还是替罪羊?

焦虑的高层、加码的中层、发疯的基层

“一代人有一代人的土木”

旧增长没了，新赛马启动

就让我们挥别过去

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

问题

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

二、帖子主要内容概述