我的征尘是星辰大海。。。

The dirt and dust from my pilgrimage forms oceans of stars...

-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆

作者:黄教授

手机视频列表

Anthropic是AI赛道里只适配跑F1赛道的法拉利

视频

音频

原始脚本

Anthropic AI 赛道里只适配 F 一赛道的法拉利跑车。
前同事是法拉利车主俱乐部成员，闲聊时我满是羡慕的向他打听跑车的驾乘体验。
可他反倒半凡尔赛的吐槽起用车成本。
这辆赛道取向的法拉利跑车，原厂热熔胎抓地力极强，却极度不耐磨，仅仅行驶40多英里，损耗就达到报废标准。
他往返一趟旧金山市区，回来就得整套更换轮胎。
单套赛车胎成本动则上千美元，日常通勤的损耗开销根本难以承受。
我当时十分疑惑，一款日常代步完全不实用，使用门槛与维护成本双高的车，为何还会有人购入？他打趣补充，依靠俱乐部会员资格转手溢价。
甚至能抹平车辆贬值亏损，全当消遣。
这段闲聊后来反复出现在我的思考里，对照当下 anthropic 的产品路线，二者逻辑高度相似。
Claude 整套编程体系就是 AI 行业里专为赛道而生的 F 一赛车。
性能极致，但适用人群极窄，使用成本居高不下。
很难大众化铺开。
一天价定价背后并非模型能力碾压，而是独占算力的硬性成本。
市面上通用 AI 订阅服务普遍维持十几至20美元每月。
而 Anthropic 面向重度编程用户的高端套餐定价区间高达200至1500美元。
外界很容易简单推算，10倍定价就意味着10倍利润。
实际并非如此，高额收费绝大部分用来覆盖独占服务器的硬件摊销，暴利只是表象。
OpenAI  Google Gemini 全部采用多租户共享算力架构，服务端无状态设计，海量用户共用 GPU 资源，绘画闲置。
间隔稍久便会清空 kv 缓存，提高硬件利用率，拉低单位成本。
这套方案完全适配大众场景，绝大多数使用者只是闲聊问答。
简单文案生成，单次请求上下文简短，不需要持续锁定算力资源。
可 cloud code 完全是另一套逻辑，它整套 tool use 工具调用 sdk。
核心前提是绘画全程独占算力实力。
一次完整的代码重构、 bug 修复流程会自动触发数十轮原子操作， ls 便利目录。
Cat 读取源码、局部文件编辑、日志检索等。
每一步都需要复用前序操作的 kv 缓存，不能重复上传全部历史上下文。
一旦放开共享多租户模式，缓存频繁销毁，分布读取文件的优势会直接归零。
这就像 f 一热熔胎，赛道环境能发挥全部性能。
放到城市柏油路面只会快速报废。
这套独占算力架构在编程场景能大幅提升准确率，可如果用来处理法国首都在哪这类简单闲聊。
昂贵的专属服务器资源被低价值请求长期占用，厂商只会持续亏损。
各大科技企业并非没有能力复刻这套技术，而是预判这条路线技术门槛不高，而商业风险极高。
只能服务金字塔顶端极少数重度开发者。
二、 Tools 分布读取，贴合编程底层逻辑，却是小众垂直优化。
任何有调试经验的开发者都懂一个基本原则，编程脱离一手实证材料的文字描述毫无价值。
过去处理故障，对于客户只靠口头描述问题，不提供日志与截屏文件。
我会直接拒绝调试。
仅凭他人转述排查代码 bug 等同于盲猜，信息残缺、描述偏差、主观遗漏都会造成大量无效工作量。
只有亲自读取完整代码、运行日志、配置文件，才能精准定位问题。
这正是 Cloud Code 工具调用设计的核心逻辑，不依赖用户批量上传文件。
交由模型自主按需读取，筛选项目内容，把大型开发任务拆解为无数短上下文的微小操作。
一、规避用户输入缺陷。
批量上传整个项目时，往往混杂大量无关代码、冗余配置、海量文本挤占上下文窗口，或是用户遗漏关键文件、粘贴错误代码。
误导模型判断。
二、缓解大模型原生短板。
Transformer 模型准确率随上下文长度拉长指数级下滑，超长文本组合空间极大。
训练素材无法全覆盖，极易产生代码幻觉。
分布读取单文件、局部代码，每一轮推理仅保留极小范围有效信息，出错概率大幅降低。
三、模型层针对性优化。
Anthropic 采用 block 稀疏注意力机制，区分用户自然语言与 iOS  CAT 等工具返回的结构化文本。
两类信息独立计算注意力，机器输出内容不会干扰代码逻辑推理，属于专门为编程场景微调的轻量化优化，并非颠覆性底层理论突破。
同源出自 OpenAI 核心团队的研发班底，人力、算力、试错资源远少于 OpenAI 通用基础模型并不存在数量级的性能超越。
二者真正差距不在模型底座，而是产品路线取舍。
OpenAI 需要兼顾海量普通用户，架构不能牺牲通用兼容性。
Anthropic 主动收缩赛道， all in 专业编程 agent 愿意承担独占算力的高额成本，换取垂直场景精度。
三。
竞品架构的天然短板，反衬专用编程架构的取舍代价。
一、 Gemini，OpenAI 通用 HTTP 请求响应模式。
标准无状态接口，单次问答必须打包全量历史对话。
所有上传代码文件发送至服务端，没有分布自主读取本地文件的能力。
用户只能一次性上传全部项目，要么信息缺失引发幻觉，要么冗余文本填满上下文窗口，模型被无关代码干扰，调试效率低下。
二、 vscode 原生 copilot 插件。
依托 IDE 可直接读取本地文件与法术，看似具备天然优势，实则两套体系互相冲突。
一方面，编辑器插件分配的内存算力。
文件访问权限严格受限，多文件大型重构任务极易进程卡死。
另一方面，代码高亮、实时键盘补全、函数索引检索等面向人类开发者的功能。
对 AI 推理完全无效，只会产生大量冗余文本，占用上下文。
微软也已意识到这套架构缺陷，最近因此推出独立轻量化 Copilot CLI。
脱离 IDE 插件资源束缚，借鉴分布工具调用思路，但依旧保留共享算力架构，坚决不采用 anthropic 的独占服务器方案。
平衡成本与使用体验。
四、 F 一是路线的商业硬伤，市场天花板极低，规模化无从谈起。
能够每月承担数百至上千美元 AI 编程服务成本的个人开发者。
企业技术团队仅占全球开发者总量百分之五以内，受众极度狭窄。
类比只做赛道跑车的车企，放弃海量家用通勤市场。
仅服务少数高端爱好者，增长空间存在硬性上限。
即便 Anthropic 当前单客户客单价极高，账面年化营收亮眼，看似十倍于通用订阅的定价，对应的单用户算力摊销成本同样高出十倍。
高端套餐仅仅勉强覆盖硬件支出，不存在想象中的高额净利润。
而且上市前披露的数据也存在美化空间。
比如仅统计付费重度客户收入，剔除低消耗轻量用户，固定资产、长期算力、硬件摊销不计入短期亏损测算等等。
绝大多数厂商选择观望，折中改造工具调用逻辑，却回避长期独占算力这条路线。
本质是做出了统一商业判断，技术落地没有门槛。
但无法支撑大规模商业化，属于小众细分赛道，风险远大于收益。
我日常使用适配 anthropic 交互协议的 claude code 客户端。
后端接入豆包 Code 模型完成脚本编写、服务器系统配置等轻量化开发，完整复刻分布工具调用的工作流，同时规避海外独占算力的天价开销。
完美匹配个人使用需求。
目前使用体验完全满足了我的需求。
这套实践也让我清晰看清核心真相。
Claude 的强大不是底层模型的天才式突破。
而是不惜成本，垂直极致优化的结果。
它就像赛道专用 F 一赛车，精准、强悍，但天生不适合大众日常使用。
通用大模型厂商选择平价共享算力的家用轿车路线，才是适配绝大多数用户，具备长期规模化潜力的解法。

修正脚本

Anthropic AI 赛道里只适配 F1 赛道的法拉利跑车。
前同事是法拉利车主俱乐部成员，闲聊时我满是羡慕地向他打听跑车的驾乘体验。
可他反倒半凡尔赛地吐槽起用车成本。
这辆赛道取向的法拉利跑车，原厂热熔胎抓地力极强，却极度不耐磨，仅仅行驶40多英里，损耗就达到报废标准。
他往返一趟旧金山市区，回来就得整套更换轮胎。
单套赛车胎成本动辄上千美元，日常通勤的损耗开销根本难以承受。
我当时十分疑惑，一款日常代步完全不实用，使用门槛与维护成本双高的车，为何还会有人购入？他打趣补充，依靠俱乐部会员资格转手溢价。
甚至能抹平车辆贬值亏损，全当消遣。
这段闲聊后来反复出现在我的思考里，对照当下 anthropic 的产品路线，二者逻辑高度相似。
Claude 整套编程体系就是 AI 行业里专为赛道而生的 F1 赛车。
性能极致，但适用人群极窄，使用成本居高不下。
很难大众化铺开。
而天价定价背后并非模型能力碾压，而是独占算力的硬性成本。
市面上通用 AI 订阅服务普遍维持十几至20美元每月。
而 Anthropic 面向重度编程用户的高端套餐定价区间高达200至1500美元。
外界很容易简单推算，10倍定价就意味着10倍利润。
实际并非如此，高额收费绝大部分用来覆盖独占服务器的硬件摊销，暴利只是表象。
OpenAI  Google Gemini 全部采用多租户共享算力架构，服务端无状态设计，海量用户共用 GPU 资源，盘活闲置。
间隔稍久便会清空 kv 缓存，提高硬件利用率，拉低单位成本。
这套方案完全适配大众场景，绝大多数使用者只是闲聊问答。
简单文案生成，单次请求上下文简短，不需要持续锁定算力资源。
可 cloud code 完全是另一套逻辑，它整套 tool use 工具调用 sdk。
核心前提是会话全程独占算力资源。
一次完整的代码重构、 bug 修复流程会自动触发数十轮原子操作， ls 遍历目录。
Cat 读取源码、局部文件编辑、日志检索等。
每一步都需要复用前序操作的 kv 缓存，不能重复上传全部历史上下文。
一旦放开共享多租户模式，缓存频繁销毁，分步读取文件的优势会直接归零。
这就像 F1 热熔胎，赛道环境能发挥全部性能。
放到城市柏油路面只会快速报废。
这套独占算力架构在编程场景能大幅提升准确率，可如果用来处理法国首都在哪这类简单闲聊。
昂贵的专属服务器资源被低价值请求长期占用，厂商只会持续亏损。
各大科技企业并非没有能力复刻这套技术，而是预判这条路线技术门槛不高，而商业风险极高。
只能服务金字塔顶端极少数重度开发者。
二、 Tools 分步读取，贴合编程底层逻辑，却是小众垂直优化。
任何有调试经验的开发者都懂一个基本原则，编程脱离一手实证材料的文字描述毫无价值。
过去处理故障，如果客户只靠口头描述问题，不提供日志与截屏文件。
我会直接拒绝调试。
仅凭他人转述排查代码 bug 等同于盲猜，信息残缺、描述偏差、主观遗漏都会造成大量无效工作量。
只有亲自读取完整代码、运行日志、配置文件，才能精准定位问题。
这正是 Cloud Code 工具调用设计的核心逻辑，不依赖用户批量上传文件。
交由模型自主按需读取，筛选项目内容，把大型开发任务拆解为无数短上下文的微小操作。
一、规避用户输入缺陷。
批量上传整个项目时，往往混杂大量无关代码、冗余配置、海量文本挤占上下文窗口，或是用户遗漏关键文件、粘贴错误代码。
误导模型判断。
二、缓解大模型原生短板。
Transformer 模型准确率随上下文长度拉长指数级下滑，超长文本组合空间极大。
训练素材无法全覆盖，极易产生代码幻觉。
分步读取单文件、局部代码，每一轮推理仅保留极小范围有效信息，出错概率大幅降低。
三、模型层针对性优化。
Anthropic 采用 block 稀疏注意力机制，区分用户自然语言与 ls、cat 等工具返回的结构化文本。
两类信息独立计算注意力，机器输出内容不会干扰代码逻辑推理，属于专门为编程场景微调的轻量化优化，并非颠覆性底层理论突破。
同源出自 OpenAI 核心团队的研发班底，人力、算力、试错资源远少于 OpenAI，通用基础模型并不存在数量级的性能超越。
二者真正差距不在模型底座，而是产品路线取舍。
OpenAI 需要兼顾海量普通用户，架构不能牺牲通用兼容性。
Anthropic 主动收缩赛道， all in 专业编程 agent 愿意承担独占算力的高额成本，换取垂直场景精度。
三、
竞品架构的天然短板，反衬专用编程架构的取舍代价。
一、 Gemini，OpenAI 通用 HTTP 请求响应模式。
标准无状态接口，单次问答必须打包全量历史对话。
所有上传代码文件发送至服务端，没有分步自主读取本地文件的能力。
用户只能一次性上传全部项目，要么信息缺失引发幻觉，要么冗余文本填满上下文窗口，模型被无关代码干扰，调试效率低下。
二、 vscode 原生 copilot 插件。
依托 IDE 可直接读取本地文件与目录，看似具备天然优势，实则两套体系互相冲突。
一方面，编辑器插件分配的内存算力有限，文件访问权限严格受限，多文件大型重构任务极易进程卡死。
另一方面，代码高亮、实时键盘补全、函数索引检索等面向人类开发者的功能。
对 AI 推理完全无效，只会产生大量冗余文本，占用上下文。
微软也已意识到这套架构缺陷，最近因此推出独立轻量化 Copilot CLI。
脱离 IDE 插件资源束缚，借鉴分步工具调用思路，但依旧保留共享算力架构，坚决不采用 anthropic 的独占服务器方案。
平衡成本与使用体验。
四、 F1 路线的商业硬伤，市场天花板极低，规模化无从谈起。
能够每月承担数百至上千美元 AI 编程服务成本的个人开发者。
企业技术团队仅占全球开发者总量百分之五以内，受众极度狭窄。
类比只做赛道跑车的车企，放弃海量家用通勤市场。
仅服务少数高端爱好者，增长空间存在硬性上限。
即便 Anthropic 当前单客户客单价极高，账面年化营收亮眼，看似十倍于通用订阅的定价，对应的单用户算力摊销成本同样高出十倍。
高端套餐仅仅勉强覆盖硬件支出，不存在想象中的高额净利润。
而且上市前披露的数据也存在美化空间。
比如仅统计付费重度客户收入，剔除低消耗轻量用户，固定资产、长期算力、硬件摊销不计入短期亏损测算等等。
绝大多数厂商选择观望，折中改造工具调用逻辑，却回避长期独占算力这条路线。
本质是做出了统一商业判断，技术落地没有门槛。
但无法支撑大规模商业化，属于小众细分赛道，风险远大于收益。
我日常使用适配 anthropic 交互协议的 claude code 客户端。
后端接入豆包 Code 模型完成脚本编写、服务器系统配置等轻量化开发，完整复刻分步工具调用的工作流，同时规避海外独占算力的天价开销。
完美匹配个人使用需求。
目前使用体验完全满足了我的需求。
这套实践也让我清晰看清核心真相。
Claude 的强大不是底层模型的天才式突破。
而是不惜成本，垂直极致优化的结果。
它就像赛道专用 F1 赛车，精准、强悍，但天生不适合大众日常使用。
通用大模型厂商选择平价共享算力的家用轿车路线，才是适配绝大多数用户，具备长期规模化潜力的解法。

英文翻译

In the Anthropic AI track, it's like a Ferrari designed exclusively for F1 circuits.  
A former colleague is a member of the Ferrari owners' club. During a casual chat, I couldn't hide my envy and asked him about the driving experience of a sports car.  
Instead, he half-humble-bragged about the cost of ownership.  
This track-oriented Ferrari comes with factory racing tires that offer incredible grip but are extremely不耐磨. After just over 40 miles, the wear reaches the point of replacement.  
Each round trip to downtown San Francisco requires a full set of new tires.  
A single set of racing tires can cost thousands of dollars, making daily commuting costs unbearable.  
I was puzzled at the time: why would anyone buy a car that is completely impractical for daily use, with high entry barriers and maintenance costs? He joked that by leveraging club membership, he could even sell the car at a premium, offsetting depreciation, treating it as a hobby.  
This casual conversation has repeatedly come to mind when I look at Anthropic’s current product roadmap—the logic is highly similar.  
Claude’s entire programming system is like an F1 race car built specifically for the AI track.  
It delivers极致 performance but serves a very narrow audience, with high usage costs.  
It’s hard to scale to the masses.  
Behind the sky-high pricing, it’s not that the model’s capability crushes competitors, but rather the hard cost of exclusive computing power.  
Common AI subscription services on the market generally cost between $15 and $20 per month.  
Anthropic’s premium tier, targeting heavy programming users, ranges from $200 to $1,500.  
Outsiders might easily assume that a 10x price means 10x profit.  
In reality, that’s not the case. The high fees mostly cover the hardware amortization of exclusive servers—the apparent profitability is just an illusion.  
OpenAI and Google Gemini both adopt multi-tenant shared computing architectures with stateless server designs, allowing massive numbers of users to share GPU resources and utilize idle capacity.  
After a certain idle period, the KV cache is cleared to improve hardware utilization and lower unit costs.  
This approach is perfectly suited for general scenarios, where most users just chat or ask simple questions.  
For simple text generation, single requests have short contexts and don’t require sustained exclusive computing resources.  
But Cloud Code operates on a completely different logic. Its entire tool-use SDK is built on the core premise of exclusive computing resources throughout the session.  
A complete code refactoring or bug-fixing process automatically triggers dozens of atomic operations: `ls` to list directories,  
`cat` to read source files, local file edits, log searches, etc.  
Each step needs to reuse the KV cache from previous operations, without re-uploading all historical context.  
If the shared multi-tenant model were adopted, the cache would be frequently destroyed, nullifying the advantage of step-by-step file reading.  
This is like F1 racing tires: they perform perfectly on the track, but on city asphalt they wear out quickly.  
This exclusive computing architecture significantly improves accuracy in programming scenarios, but if used for simple queries like "What is the capital of France?"  
Expensive dedicated server resources would be occupied long-term by low-value requests, causing continuous losses for the vendor.  
Major tech companies are not incapable of replicating this technology; they foresee that this route has low technical barriers but extremely high commercial risk.  
It can only serve a very small number of heavy developers at the top of the pyramid.

Second, Tools step-by-step reading aligns with the underlying logic of programming but is a niche vertical optimization.  
Any developer with debugging experience knows a basic principle: programming without first-hand empirical material is worthless.  
In the past, when handling faults, if a client only described the problem verbally without providing logs or screenshots,  
I would directly refuse to debug.  
Relying solely on someone else’s description to find code bugs is like blind guessing—information gaps, description biases, and subjective omissions all lead to massive wasted effort.  
Only by personally reading the complete code, runtime logs, and configuration files can you precisely locate the problem.  
This is the core logic behind Cloud Code’s tool-use design: it doesn’t rely on users batch-uploading files.  
Instead, the model autonomously reads as needed, filters project content, and breaks down large development tasks into countless micro-operations with short contexts.  
First, it avoids user input defects. When batch-uploading an entire project, users often include a lot of irrelevant code, redundant configurations, and large text that crowds the context window, or they omit key files or paste incorrect code,  
misleading the model’s judgment.  
Second, it mitigates the native shortcomings of large models. Transformer model accuracy drops exponentially as context length increases. Ultra-long text combination spaces are huge,  
and training data cannot fully cover them, leading to code hallucinations.  
By reading single files or partial code step by step, each inference retains only a minimal range of effective information, significantly reducing error probability.  
Third, it includes targeted model-layer optimizations. Anthropic uses a block sparse attention mechanism that distinguishes between user natural language and structured text returned by tools like `ls` and `cat`.  
The two types of information compute attention independently, so machine-generated output doesn’t interfere with code logic reasoning. This is a lightweight optimization fine-tuned for programming scenarios, not a groundbreaking theoretical breakthrough.  
It originates from the same core team as OpenAI, but with far fewer human resources, computing power, and trial-and-error resources. The general foundational model does not have an order-of-magnitude performance advantage.  
The real difference between the two is not in the model base, but in product strategy trade-offs.  
OpenAI needs to serve hundreds of millions of ordinary users, so its architecture cannot sacrifice general compatibility.  
Anthropic actively shrinks its track, going all-in on professional programming agents, willing to bear the high cost of exclusive computing power in exchange for precision in vertical scenarios.

Third, the inherent shortcomings of competitors’ architectures highlight the trade-offs of the dedicated programming architecture.  
First, Gemini and OpenAI use standard HTTP request-response models—stateless interfaces. Each single Q&A must package the full history of the conversation.  
All uploaded code files are sent to the server; there is no ability to autonomously read local files step by step.  
Users can only upload the entire project at once, leading either to information gaps causing hallucinations, or redundant text filling the context window, with the model distracted by irrelevant code, resulting in inefficient debugging.  
Second, the native Copilot plugin in VS Code.  
Relying on the IDE, it can directly read local files and directories, which seems like a natural advantage, but actually the two systems conflict.  
On one hand, the memory and computing power allocated to the editor plugin are limited, file access permissions are strictly restricted, and large multi-file refactoring tasks easily cause process freezes.  
On the other hand, features like code highlighting, real-time keyboard completion, and function index search—designed for human developers—  
are completely useless for AI reasoning, only generating large amounts of redundant text that consume context.  
Microsoft has also recognized this architectural flaw and recently launched a standalone lightweight Copilot CLI.  
It breaks free from IDE plugin resource constraints and draws on the idea of step-by-step tool use, but still retains a shared computing architecture, resolutely avoiding Anthropic’s exclusive server approach,  
balancing cost and user experience.

Fourth, the commercial shortcomings of the F1 route: the market ceiling is extremely low, and scaling is out of the question.  
Individual developers and enterprise tech teams who can afford hundreds to thousands of dollars per month for AI programming services  
account for less than 5% of all developers worldwide—an extremely narrow audience.  
It’s like a car manufacturer that only makes track sports cars, abandoning the massive commuter market.  
Serving only a few high-end enthusiasts inherently caps growth.  
Even though Anthropic’s current per-customer revenue is very high, and its reported annual recurring revenue looks impressive—the seemingly 10x pricing corresponds to 10x the per-user computing cost amortization.  
The premium tier barely covers hardware expenses; there is no imagined high net profit.  
Also, pre-IPO data may be polished.  
For example, only counting revenue from paying heavy users, excluding low-consumption light users, and not including fixed assets, long-term computing power, or hardware amortization in short-term loss calculations.  
Most other vendors choose to wait and see, modifying tool-use logic in a compromise, but avoiding the long-term exclusive computing route.  
Essentially, they have all made the same business judgment: the technology implementation has no barrier,  
but it cannot support large-scale commercialization—it’s a niche vertical track where risks far outweigh rewards.

In my daily work, I use a Claude Code client that follows the Anthropic interaction protocol.  
The backend connects to Doubao Code model to complete script writing, server system configuration, and other lightweight development tasks. It fully replicates the step-by-step tool-use workflow while avoiding the sky-high cost of overseas exclusive computing.  
It perfectly matches my personal needs.  
My current user experience fully satisfies my requirements.  
This practice has also made clear to me the core truth:  
Claude’s strength is not a genius breakthrough in the underlying model,  
but the result of vertical,极致 optimization at any cost.  
It’s like an F1 race car for the track—precise, powerful, but inherently unsuitable for everyday mass use.  
For general large model vendors, choosing the affordable shared-computing “family car” route is the solution that fits most users and has long-term scaling potential.