AI与大模型

2026 年 5 月，Meta FAIR 联合斯坦福、哈佛发布了 ProgramBench——让 AI 从零重建 200 个真实软件项目。结果：Claude Opus 4.7、GPT-5.4、Gemini 3.1 Pro，9 个顶级模型，完整通过率全部为 0%。 同一时期，SWE-bench Verified 上，AI 的得分已经超过 72%——在已有代码库里修 bug、加功能，AI 已经比大多数中级程序员更靠谱。 72% 和 0%。同一个 AI，同一周发布的数据。修别人的代码很强，从零建一个系统却完全不行。 这就是理解"AI 会不会拉平程序员水平"的关键入口。答案不是简单的"会"或"不会"——而是在什么维度上拉平，在什么维度上极化。 “拉平"是真的，但只拉平了冰山一角 AI 确实消灭了一类差距。在"写代码"这个维度上，初级和高级之间的差距确实缩小了。 Andrej Karpathy 在 2025 年 2 月创造了"Vibe Coding"这个词——完全沉浸在氛围中编程，用自然语言描述需求，AI 负责生成代码，你甚至可以忘记代码的存在。这个词迅速成为 2025 年编程圈最火的词，不是因为它酷，而是因为它描述了一个真实发生的事情。 一个不会正则表达式的产品经理，用 AI 可以写出复杂的文本匹配；一个从未用过 React 的后端工程师，用 Cursor 可以搭出一个可用的前端页面。这些以前需要专业技能门槛的事情，现在确实被拉平了。 更具体地说，AI 拉平的是这些能力： 语法记忆：不用背 API，知道"做什么"就够了 模板代码：CRUD、配置文件、脚手架，AI 几秒生成 跨领域编程：后端写前端、前端写脚本，AI 帮你跨越语言壁垒 调试效率：报错贴进去，AI 直接指出问题 这些是真实的。否认这些，就是否认现实。 但这些只是"冰山一角” Frederick Brooks 在 1986 年的经典论文《没有银弹》中，把软件开发的困难分为两类： 本质复杂性（Essential Complexity）：问题域本身的复杂度——需求的不确定性、业务概念的抽象、系统边界的划定、模块间的依赖关系 偶然复杂性（Accidental Complexity）：实现工具带来的额外复杂度——语法错误、环境配置、API 记忆、样板代码 AI 消灭的是偶然复杂性。而且消灭得很彻底——语法错误几乎为零，API 不用查了，样板代码一键生成。 ...

每一次技术革命，都有人喊"人要被替代了"。每一次都没发生。 原因很简单：技术提升了人的能力，但人的欲望总是先一步抵达下一个不可能。马车变汽车，人不会觉得"够了"，而是想去更远的地方。算盘变计算机，人不会觉得"算够了"，而是想算更复杂的问题。 能力追着欲望跑，欲望永远领先半步。这个动态平衡，保证了人始终被需要——因为永远有新的"想做但做不到"的事情，需要人去想办法。 AI也不例外。AI能写代码了，人不会因此"不需要写代码了"，而是想写更复杂的系统；AI能生成视频了，人不会因此"不需要做视频了"，而是想做更长的电影、更互动的叙事。AI替代的不是人，是人不想做的部分。 而它打开的，是人想做的更多。 所以裁员是个伪焦虑。工作不会减少，只会变化。真正的问题在别处。 AI的加速度，不均匀 AI让很多事变快了。但不是所有事都按同一个倍率变快。 生成一段文本，从1小时变成10秒——快了360倍。审核这段文本是否正确，从5分钟变成——还是5分钟。因为审核需要理解语境、判断逻辑、权衡取舍，这些认知活动不能被加速。 写一个App原型，从3个月变成3天——快了30倍。但验证这个App是否有人需要、是否该投入资源、上线后如何运营——这些决策还是需要同样的时间。因为决策依赖于市场反馈、用户访谈、经验判断，这些东西有它们自己的节奏。 AI加速了生产，但没有加速判断、决策、和意义。 这就产生了一个结构性的张力：供给端在以指数速度膨胀，而消化端——人的认知、判断、决策——还是线性的，甚至有时候是常数的。 以前，10个想法出来，你有时间一个个评估、筛选、放弃大部分、推进少数。现在，100个想法同时涌出来，你还是要一个个评估——但你的时间和认知带宽没有变成10倍。 你不会因此被裁掉。但你开始应付。 应付的代价是累积的 应付不是偷懒。应付是你用更少的认知资源处理更多的决策。 每一次应付，你都跳过了深度思考——不是不想，是来不及。来不及想清楚这个方案的漏洞就上线了，来不及验证这个数据的可靠性就引用了，来不及评估这个决策的长期影响就拍板了。 短期看，没什么。AI帮你兜底了——它生成的代码大部分是正确的，它的分析大部分是合理的，它的建议大部分是可行的。你的应付，大部分时候不会出事。 但"大部分时候"不等于"总是"。 每一次应付，你都在积累一种看不见的债：对AI输出中那小部分错误、偏见、和幻觉的债。 你没有时间去识别它们，它们就混在你的决策里，进入你的产品、你的方案、你的战略。 这不是某个人的问题。当整个组织都在用AI加速运转，所有人都在应付时，这些微小错误的积累速度也在加速。而错误的积累是非线性的——一个错误的数据输入下一个决策，产出一个更大的错误，再输入下一个决策…… 你不会被裁掉。你会在岗位上，看着某个由无数微小失误累积而成的系统性崩溃发生，而你会困惑——“每一步都没什么大问题啊？” 更深的债：你自己在退场 还有一种债，更隐蔽。 当你日复一日地用AI生成、自己审核的模式工作时，你在慢慢退出一件事：构建。 构建和审核是两种根本不同的认知活动。构建需要你从零开始，面对空白，做出每一个选择——这个结构怎么搭，这个逻辑怎么走，这个表达怎么组织。每一个选择都在锻炼你的能力，加深你对领域的理解。 审核只需要你做判断——对或错、好或坏、用或不用。判断当然也需要能力，但它不需要你"从无到有"。它锻炼的是评价能力，不是创造能力。 当你的工作日中，构建的比例越来越小，审核的比例越来越大，你的能力结构就在悄悄倾斜。你还是那个"懂行的人"，但你的"懂"越来越像鉴赏家的"懂"，而不是匠人的"懂"——你分得出好坏，但你越来越做不出好的。 这不影响你现在的绩效。在AI辅助下，你的产出甚至比以前更好。但你正在变成一个越来越难以离开AI的人。不是因为你不会做，而是因为你已经习惯了不去想"怎么做"——AI替你想了，你只管选。 你的判断力还在。但判断力需要锚定在构建力上，否则它会漂移——你越来越难判断AI给出的是不是真的好，因为你自己已经很久没有从零做到好了。 不要做AI时代的流水线工人 前面说的应付、退场、被加速——你以为这是因为AI太快了，你跟不上。但问题不是速度，是位置。 看看你的一天：AI生成→你审核→修改prompt→AI再生成→你再审核。循环往复。 这和工业时代的流水线工人有什么区别？工人拿起零件→检查→拧螺丝→放下→拿起下一个。动作不同，模式相同。你不是AI的主人，你是AI流水线上的一个环节。 流水线工人不需要理解全局，不需要创造力，只需要在固定位置做固定判断。换一个人来，培训三天，也能做同样的审核。 你以为你在"驾驭AI"，但你的节奏已经被AI塑造了——AI生成什么，你就审什么；AI多快，你就得多快。你不是在用工具，你是工具链的一部分。 工业时代的流水线工人，后来怎样了？被流水线本身自动化了。AI时代也一样——当AI的自我审查能力提升（这件事正在发生），“人审AI"这个环节会被优化掉。更致命的是：你审了三年AI输出，你的"技能"是判断AI生成的优劣——但这个技能的前提是AI在生成。AI不需要你审了，你的技能归零。离开流水线，你什么也不会。 你为什么在流水线上？不是因为AI太强，是因为你没有自己的方向。没有方向的人，自然会被推到流水线上——流水线不需要你有方向，只需要你有反应速度。有方向的人不一样，AI只是帮他更快地到达，他的节奏不是AI决定的，是他的方向决定的。 没有方向，AI是你的流水线；有方向，AI是你的工具。 同一个AI，区别只在这一个东西上。 结语 现在回来看这个标题：AI时代的风险不是裁员是猝死。 裁员是你被踢出系统，猝死是你在系统里变成流水线上的环节——被加速、被掏空、技能归零，而你以为自己在驾驭AI。 整个社会还在讨论"AI会不会让我失业”。但真正该问的是：你每天的工作，有多少是你自己想做的，有多少是AI推到你面前的？ 如果答案是后者居多——你不是在用AI，你是AI流水线上的人形质检员。而质检员的结局，历史已经写好了。

今天，几乎所有的 AI Agent 都需要"动手"——写代码、查数据库、操作文件系统、调用 API。Agent 不能只思考，必须行动。而行动，就需要工具。 目前，Agent 获取工具有两条路径：CLI（命令行） 和 MCP（Model Context Protocol）。这不是两种"人机交互方式"的对比——在 Agent 场景下，人是退到幕后的。这是同一个 Agent 的两种工具接入模式，它们决定了 Agent 能做什么、怎么做、以及做的时候有多安全。 这篇文章要回答一个核心问题：当 Agent 需要操作外部世界，CLI 和 MCP 分别给了它什么？两者如何共存？ 一、Agent 需要什么样的工具接口 在讨论 CLI 和 MCP 之前，先理解 Agent 对工具接口的核心需求： 可发现性：Agent 需要知道"我能做什么" Agent 的第一个问题永远是：我现在有哪些工具可用？ 如果 Agent 不知道自己有 git 命令，它就不会尝试提交代码。如果 Agent 不知道有一个"查询订单数据库"的 MCP Tool，它就不会去查。工具的可发现性决定了 Agent 能力的天花板。 可组合性：Agent 需要把多个工具串起来 Agent 很少只用一个工具完成任务。“查一下最近的 bug 报告，然后写个修复，再跑一遍测试”——这涉及数据库查询、文件编辑、命令执行三个工具的组合。 工具之间能否无缝组合，决定了 Agent 是"能干活"还是"只能做单步操作"。 可靠性：Agent 需要可预测的执行结果 Agent 做决策的前提是：如果我调用这个工具，我会得到什么。工具返回结果的格式越确定，Agent 的推理越可靠。 一个返回结构化 JSON 的工具，和一个输出格式随心情变化的命令行工具，对 Agent 来说是天壤之别。 安全性：Agent 需要被约束 Agent 拿到工具就像人拿到车钥匙——你希望它开车去超市，不希望它飙车撞墙。工具接口的设计决定了你能给 Agent 多大的自由度，以及出事时能不能兜住。 ...

问题：AI编码的成功为什么难以复制？ 越来越多的团队在尝试AI辅助编码。但一个普遍现象是：成功案例很多，成功复制却很难。 某个项目用AI写代码效率翻倍，换个项目就不行了；某个工程师用AI很顺手，换个人就各种踩坑。问题出在哪？ 本质是上下文的缺失，也是驾驭能力的缺失。 AI编码不是简单的提问-生成代码，而是需要三层上下文的支撑：编程环境上下文、项目上下文、需求上下文。任何一层的缺失，都会导致AI生成的代码无法落地。 平台要解决的核心问题，就是让这三层上下文可复制，让AI可被有效驾驭。 理论基础：从Prompt到Harness的三阶段演进 第一阶段：Prompt Engineering（提示词工程） 时间：2022年底至2024年初 核心理念：关注说什么 在这个阶段，所有主流的AI教程都着重讲解如何创建一个完美指令——角色扮演、Few-shot、Step-by-step等技巧。用户是绝对掌控者，模型是基于单条指令完成任务的被动执行者。 模型没有记忆、没有工具，每一次交互都是独立的条件概率生成。 第二阶段：Context Engineering（上下文工程） 时间：2024年至2025年初 核心理念：关注配置环境 随着模型上下文窗口的扩充（从4K到128K/200K tokens），业内开始形成共识：相较于研究提示词如何遣词造句，更重要的是以系统性框架（RAG知识库、系统提示词、Memory记忆系统、工具调用接口）为模型构建信息环境。 用户从直接发号施令者转变为情境构建者——负责判断当前情况，提供信息与资源；模型则在给定的上下文环境中，自行判断如何应对。 第三阶段：Harness Engineering（驾驭工程） 时间：2025年初至今 核心理念：关注让什么发生 随着Claude 4.6、GPT-5.4 Codex、Gemini 3.1 Pro等具备深度Agentic能力的模型成熟，新的范式被提出——Harness Engineering（驾驭工程）。 “Harness"在英语中意为马具/缰绳。它不是动力本身，但它决定了动力能否被稳定地使用。AI像一匹很快的马，但需要一套缰绳才能被驾驭。 核心定义：设计一套环境与机制，使AI Agent能在可控边界内持续自主工作。 核心理念：人类引导，智能体执行（Humans steer, Agents execute） 驾驭工程的四个核心动作 Harness Engineering的核心可以概括为四个动词： 1. Constrain（约束）：设定边界 问题：AI会产生幻觉，会偷懒，会写出看似能跑实则一团糟的代码。 解决方案：通过不变量约束，而不是微观管理实现细节。 具体做法： Guardrails护栏：定义AI不可逾越的行为边界 权限分级：不同场景下AI的能力范围 沙箱隔离：Docker容器隔离，任务完成后销毁 架构约束：强制执行依赖方向（如 Types→Config→Repo→Service→Runtime→UI） 2. Inform（告知）：提供信息 问题：AI只能访问运行时上下文中的知识，其他都等于不存在。 解决方案：把上下文推回仓库，结构化组织信息。 具体做法： 渐进式披露：给AI一张地图（AGENTS.md），而不是1000页说明书 结构化docs/目录：设计文档、产品规格、技术参考 可观测性数据：日志、指标、追踪（LogQ、PromQL） UI能力：Chrome DevTools协议，让AI能读取界面、截图、导航 3. Verify（验证）：检查结果 问题：AI生成的代码未必符合要求，需要验证。 解决方案：建立评估机制，让验证自动化。 具体做法： Evals评估：为每个产品领域和架构层打分 智能体评审：AI评审AI的代码 结构测试：验证架构依赖是否合规 CI任务：校验知识库是否最新、结构是否正确 4. Correct（纠正）：修正问题 问题：发现问题后，如何让系统自我修复？ ...

引言：同是AI，两种待遇 腾讯悄悄内测QClaw，微信终于接AI了。 表面看，这只是腾讯又一次产品更新。但如果你还记得半年前字节跳动推豆包手机时微信的态度——冷处理、功能限制、入口不给——你就会意识到： 同样的AI，两种待遇。 这不是技术问题，不是合规问题，甚至不是用户体验问题。 这是商业本质。 一、入口之争：寸土不让 1.1 豆包手机想干什么？ 字节跳动推豆包手机，核心目的只有一个：当入口。 想象一个场景： 用户不打开微信，直接对豆包说：“帮我订个外卖”、“给老王转100块”、“今天的新闻有什么？” 豆包完成一切。 这对微信意味着什么？ 夺权。 微信的核心价值是什么？不是聊天功能，不是朋友圈，不是小程序。 是14亿用户的入口。 用户每天打开的第一个App，决定了一切。谁控制入口，谁就控制了流量分发权、商业变现权、数据主权。 字节跳动想做这个"谁"。 腾讯能答应吗？ 当然不能。 1.2 为什么QClaw被捧，豆包被卡？ 答案已经呼之欲出： QClaw姓腾讯，豆包姓字节。 不是因为技术好坏，不是因为合规问题，不是因为用户体验。 是因为入口控制权。 QClaw嵌入微信，入口仍在腾讯手里，流量仍在腾讯体系内流转。 豆包手机试图绕过微信，成为独立入口，把流量引向字节系。 前者是"内部赋能"，后者是"外部夺权"。 腾讯的选择，顺理成章。 二、护城河逻辑：能生儿子，绝不养外人 2.1 微信为什么焦虑？ 表面看，微信如日中天：14亿用户，日活超10亿，几乎是中国人的"数字身份证"。 但马化腾比谁都清楚：流量见顶，用户时长被瓜分。 抖音崛起，短视频抢走了用户时间； 小红书崛起，种草抢走了商业转化； 现在的AI，更要抢走"入口"。 如果AI成为用户的第一触点—— “帮我订外卖”、“给我推荐电影”、“转100块给老王”—— 用户还需要打开微信吗？ 这才是微信最大的恐惧。 2.2 护城河的三层防线 微信的护城河，不是聊天功能，而是三层防线： 第一层：社交关系链 朋友在微信，你不得不来 这是最坚固的防线 第二层：生态绑定 小程序、视频号、支付、公众号 用户的生活被微信"绑架" 第三层：入口垄断 用户打开手机的第一选择 AI时代，这一层最脆弱 QClaw的使命，就是加固第三层防线。 当用户可以直接在微信里用AI完成一切——为什么要打开别的App？ 能生儿子，绝不养外人。 这是护城河逻辑的精髓。 三、QClaw vs 豆包：降维打击 3.1 两条路线的对比 维度 豆包手机 QClaw 形态 硬件+AI 软件+AI 入口 独立手机 嵌入微信/QQ 用户门槛 换手机 无需任何改变 流量来源 从零开始 直接承接14亿用户 生态绑定 无 微信全家桶 谁更容易赢？ ...

引言：一个看似疯狂的问题 “有没有可能，人完全不需要读AI生成的代码？” 这个问题听起来很极端，甚至有点危险。毕竟，代码是系统运行的基础，不看代码怎么知道AI写对了没有？ 但如果我们换个角度思考： 你会去读编译器生成的汇编代码吗？不会，因为你信任编译器。 你会去读框架的源码吗？很少，因为你信任框架的测试。 你会去读数据库的存储引擎代码吗？不会，因为你信任它的ACID保证。 每一次技术进步，都是在减少人需要"看底层"的场景。 这篇文章要探讨的是：在什么条件下，人可以完全信任AI生成的代码，而不需要去阅读它？ 一、现状：人为什么要读AI生成的代码？ 1. 不信任AI的理解能力 需求：实现用户登录功能 AI理解成了： - 用户输入账号密码 → 验证 → 返回结果 人实际想要： - 用户输入账号密码 → 验证 → 生成JWT → 记录登录日志 → 返回结果 问题：AI理解的需求，可能和人真实意图有偏差。 2. 担心实现细节有问题 # AI生成的代码 def login(username, password): user = db.query(f"SELECT * FROM users WHERE username='{username}'") if user and user.password == password: return {"token": create_token(user)} return {"error": "登录失败"} 问题： SQL注入漏洞 密码明文比对（应该用bcrypt） 没有登录失败限制（可能被暴力破解） 人不看代码，怎么知道这些细节没问题？ 3. 维护的需要 三个月后，需求变了：登录需要支持手机验证码。 如果当初的代码是AI生成的，人没看过： - 哪个文件负责登录逻辑？ - 代码结构是什么样的？ - 哪些地方需要修改？ 4. 责任归属 AI生成的代码上线后出了bug，造成了损失。 老板问：谁审查的？ 你：我没有看代码，直接让AI部署的。 老板：？？？ 人看代码，本质是在承担审查责任。 ...

传统 RAG 的困境 如果你用过 RAG（检索增强生成），应该熟悉这套流程： 文档切片（chunking） 向量化（embedding） 存入向量数据库 查询时检索 Top-K 相似片段 喂给 LLM 生成答案 这套方案有个致命问题：切片粒度很难把握。 切太小，语义不完整；切太大，噪音太多。更麻烦的是，向量相似度检索本质上是模糊匹配——它能找到相关的内容，但不一定能找到精确的内容。 比如你问项目预算在第几章？，向量检索可能返回一堆提到预算的片段，却无法告诉你精确的章节位置。 PageIndex 的思路：给 AI 一张地图 PageIndex 的核心理念很简单：不用向量，用结构。 它把文档解析成一棵层级树： 文档 ├── 第一章 概述 │ ├── 1.1 项目背景 │ └── 1.2 目标与范围 ├── 第二章 技术方案 │ ├── 2.1 架构设计 │ └── 2.2 技术选型 └── 第三章 实施计划 这棵树直接放在 LLM 的上下文窗口里。检索时，LLM 像人一样读目录找答案： 问题：架构设计在哪？ → LLM 定位到 第二章 > 2.1 架构设计 问题：项目总体目标是什么？ → LLM 定位到 第一章 > 1.2 目标与范围 这就是 推理即检索（Reasoning-based Retrieval）。 ...

2026年2月，一个让开发者困惑的消息：OpenAI 收编了 OpenClaw。 困惑的点在于——这项目看起来没技术含量：调用 LLM API、连 WhatsApp、操作文件，哪一项不是现成的技术？凭什么 Meta、xAI 都要抢，扎克伯格亲自下场？ 更让人不解的是，Peter Steinberger 本人也说：这只是一个周末业余项目，用 Codex 几个月就写出来了。 如果技术不是重点，那巨头到底在抢什么？ 一、一个反直觉的开场 在回答这个问题之前，让我们先看一个有趣的平行案例。 Sam Altman 在回顾 OpenAI 十年历程时说过一句话： “我觉得站在创新前沿的代价就是你会犯很多蠢错误，因为你深陷战争迷雾之中。” 这句话看似在解释失败，实则揭示了创新的本质——真正有价值的发现，往往来自"在黑暗中摸索直到找到光"。 OpenAI 的成功产品 ChatGPT，按 Altman 自己的说法，“确实是个意外”。他们原本计划用 GPT-4 发布聊天产品，但担心"同时推出会像是通过了图灵测试"，才先用 GPT-3.5 试水。 这个"意外"改变了世界。 这个故事和 OpenClaw 有什么关系？ 关系在于：两者都揭示了一个被忽视的真相——在 AI 时代，技术正在快速商品化，真正稀缺的是对场景的洞察力。 二、Peter 的选择：一个清醒的判断 2026年2月14日，情人节。Peter Steinberger 在博客上宣布加入 OpenAI。 很多人困惑：OpenClaw 不是正火吗？GitHub 19.6 万颗星，三个月。三大云争相上线一键部署，网易直接推出国产版。整条产业链两周内形成。 这么火，为什么要走？ Peter 的解释是：他想让他妈妈也能用上 Agent，加入 OpenAI 是最快的路。 这个解释很坦诚，但它掩盖了一个更深的逻辑：OpenClaw 所在的那一层，正在被吸收。 不是 OpenClaw 不好。恰恰相反，正因为 OpenClaw 太好了，它证明了"个人 Agent 编排"这件事是可行的，于是 OpenAI、Anthropic、Google 都开始亲自下场做同样的事。 当最顶级的玩家开始认真做一件事，独立创业者就没有空间了。 Peter 选择加入 OpenAI，某种程度上是一个清醒的判断：与其在一个正在被吸收的层里继续建造，不如去更高的地方。 ...

前言 AI Agent 正在成为软件架构的重要组件。但如何让 Agent 能够被远程访问，是一个容易被低估的技术决策。 不同的协议选择，会直接影响： 用户体验：延迟、流畅度 开发成本：实现难度、调试复杂度 运维成本：资源占用、可扩展性 应用场景：能做什么、不能做什么 本文从技术角度深度分析几种主流协议，帮助你做出最佳选择。 协议全景图 ┌─────────────┬──────────────┬──────────────┬─────────────┐ │ 协议 │ 连接类型 │ 通信模式 │ 适用场景 │ ├─────────────┼──────────────┼──────────────┼─────────────┤ │ HTTP/REST │ 短连接 │ 请求-响应 │ API 服务 │ │ WebSocket │ 长连接 │ 全双工 │ 实时交互 │ │ SSE │ 长连接 │ 单向推送 │ 流式输出 │ │ gRPC │ 长连接 │ 全双工 │ 内部服务 │ │ SSH │ 长连接 │ 终端交互 │ CLI 工具 │ └─────────────┴──────────────┴──────────────┴─────────────┘ 一、HTTP/HTTPS + RESTful API 1.1 工作原理 最传统的方式。客户端发送 HTTP 请求，服务器返回 Agent 的响应。 ...

前言 2026年2月25日，路透社的一则报道在科技圈炸开了锅： DeepSeek 发布 V4 之前，打破行业惯例，没有向英伟达和 AMD 提供早期访问权限，而是让华为等中国芯片厂商提前数周开展适配工作。 这条新闻的分量，不在于技术突破，而在于选择的姿态。 打破的惯例 AI 行业有一条不成文的规则：模型厂商会优先与英伟达合作，确保新模型在主流硬件上高效运行。这不是商业偏好，而是生存本能——英伟达占据了 AI 芯片市场 80% 以上的份额，你的模型如果不能在 CUDA 上跑得好，基本等于废了一半。 DeepSeek 之前也是这么做的。它的 V3、R1 等模型都与英伟达工程师紧密合作，确保在 H100、H800 上有最佳性能。 但这次不一样。 V4 发布之前，DeepSeek 没有联系英伟达和 AMD，而是让华为等中国芯片厂商提前几周拿到模型进行适配。这是对行业惯例的公然违背。 英伟达和 AMD 拒绝置评。DeepSeek 和华为未予回应。 沉默本身，就是一种态度。 选择的背景 这不是一个孤立的技术决策。理解这个选择，需要看更大的背景。 美国芯片出口管制的困局 2025年12月，特朗普政府宣布允许英伟达向中国出口 H200 芯片，但有附加条件： 保障美国"国家安全" 美国政府获得25%的分成 消息一出，英伟达要求供应链增产 H200，预判中国需求旺盛。 然而两个月过去了，H200 对华销售数量为零。 美国商务部官员在国会听证会上承认：“据我了解，截至目前，数量为零。” 原因很简单：国务院坚持更严格的限制，许可证审批陷入僵局。英伟达方面"十分沮丧"，有知情人士直言"国务院把事情变得非常困难"。 中国客户的观望 在许可条件不明朗的情况下，中国客户没有向英伟达下达订单。部分供应商已暂停生产 H200 的关键组件。 这不是短期的波动，而是供应链重构的开始。 当未来充满不确定性，企业会本能地寻找替代方案。华为昇腾、寒武纪、摩尔线程——这些曾经被视为"备胎"的国产芯片，正在从边缘走向中心。 DeepSeek 的考量 DeepSeek 为什么做出这个选择？ 1. 用户在哪里，适配就优先到哪里 DeepSeek 在 Hugging Face 上的模型下载量已超过 7500 万次，中国是重要市场。如果 V4 发布时，华为昇腾芯片的用户能获得更好的性能体验，这对 DeepSeek 的生态建设是利好。 ...

前言 2026年2月25日，一条新闻在AI圈刷屏： Kimi K2.5 上线不足20天，累计收入已超过2025年全年总和。 同一周，另一个消息鲜有人注意： 智谱AI招股书披露：云端部署业务毛利为零。 两家公司，同一个行业，两种命运。 这不是个案，而是整个大模型行业的缩影——在价格战、开源潮、出海竞争的三重挤压下，有人突围，有人挣扎，有人注定出局。 本文将基于最新的公开数据和报道，深度解构国内外AI大模型厂商的真实生存局面。 一、行业的"烧钱悖论" 1.1 成本结构：为什么赚钱这么难？ 大模型的核心成本来自三块： 成本类型 说明 量级 训练成本 一次完整训练的算力消耗 数千万-上亿美元 推理成本 每次API调用的GPU消耗 持续、可变 人力成本 顶尖AI研究人才 百万美元/年/人 以GPT-4为例，业界估计其训练成本约1亿美元。但这只是开始——每次用户提问，OpenAI都要消耗GPU算力。 推理成本的残酷现实： 过去3年，AI推理成本下降了超过99%。 但即便如此，当你的API价格降到OpenAI的1/10时，你可能仍在亏本。 1.2 收入困境：价格战没有赢家 2025年下半年，国内大模型行业进入"自杀式价格战"： 阿里云、百度提供免费长文本服务 DeepSeek API价格持续下探 各家Coding Plan套餐定价低于成本 智谱AI的招股书数据很说明问题： 云端部署业务毛利为0——这还是按原价售卖API的情况下。 换句话说，智谱每卖出1元钱的API服务，成本就是1元。不算研发、不算人力，仅算力成本就吃掉了全部收入。 这不是智谱的问题，是整个行业的问题。 二、谁在赚钱？突围者的共同密码 2.1 Kimi的"降维打击" 2026年2月25日，腾讯新闻披露了一组令人咋舌的数据： 月之暗面（Moonshot AI）核心数据： K2.5发布20天，收入超过2025年全年 全球付费用户环比增长4倍 海外收入首次超越国内 估值突破100亿美元，成为国内最快"十角兽" API定价比OpenAI低6-10倍 Kimi做对了什么？ 策略一：全面开源 + MIT协议 K2.5采用MIT开源协议，这是最宽松的开源许可——开发者可以商用、可以闭源、几乎没有任何限制。 更重要的是：全面兼容OpenAI API接口。 海外开发者无需重写代码，仅需替换一行URL即可无缝切换。 这种"无感替代"策略，让Kimi在GitHub、Hugging Face等国际社区迅速渗透。 策略二：放弃国内免费流量，专注海外付费市场 2025年，Kimi做了一个当时被质疑的决定： 砍掉Ohai、Noisee等C端泛娱乐产品线，将资源集中于基座模型与Agent研发。 当时国内同行都在做"免费聊天机器人"抢用户，Kimi却选择了另一条路。 事实证明，这个选择是对的： 国内用户习惯了"免费"，付费意愿低 海外开发者更愿意为高质量API付费 OpenAI的高定价给竞争对手留出了空间 策略三：技术差异化 ...

2025年初，Anthropic 推出了 Claude Code。这不是一个普通的代码补全工具，而是一个代理式（Agentic）编程助手——它能理解整个代码库、执行 bash 命令、查看 Git 历史、运行测试，甚至自主规划多步骤任务。 研究显示，使用它能让开发速度提升 5 倍以上。 很多人开始问一个尖锐的问题：如果 AI 能帮我们写代码，内部编程框架还有必要存在吗？ 这篇文章不谈炒作，只回答一个问题：AI 编程工具和内部框架，到底是什么关系？ 一、事实：Claude Code 的当前实力 1.1 它能做什么？ 根据 Anthropic 官方文档和开发者社区反馈，Claude Code 的核心能力包括： 1. 理解整个代码库 不是局部补全，而是项目级理解 能追踪跨文件的依赖关系 能理解代码的设计意图 2. 代理式工作流 不只是"写代码"，而是"完成任务" 你说"帮我构建一个 React 组件"，它会： 3. 终端集成 能执行 bash 命令 能查看 Git 历史 能运行测试和构建 4. 上下文记忆 通过 CLAUDE.md 文件记录项目细节 能记住代码风格、常见问题、团队规范 5. Skills 模块（2025年新功能） 可重用的工作流 支持市场共享 可构建自定义代理 1.2 它不能做什么？ 1. 不理解业务战略 它能写代码，但不能决定"应该做什么" 2. 不负责长期维护 生成的代码需要人工审查和改进 3. 不知道你的框架规范 除非你明确告诉它（通过 CLAUDE.md 或提示词） 4. 不能替代架构设计 ...

前言 2026 年 2 月 21 日，一条看似低调的消息在科技圈炸开了锅： OpenAI 将 2030 年算力支出目标从 1.4 万亿美元下调至 6000 亿美元。 降幅 57%。直接腰斩还多。 如果你关注 AI 行业，应该记得几个月前 Altman 还在高调宣称要投资"万亿级基础设施"。当时整个行业都在讨论：算力缺口有多大？GPU 还要涨多少？数据中心建得够不够快？ 然后，OpenAI 自己踩了刹车。 这不仅仅是数字的调整，更是整个行业心态转变的信号。 一、发生了什么？ 让我们先看看具体数据： 算力支出目标调整 原计划：2030 年投入 1.4 万亿美元（约 9.68 万亿人民币） 调整后：6000 亿美元（约 4.15 万亿人民币） 降幅：57% 估值调整 原估值：8300 亿美元 调整后：7300 亿美元 降幅：12% 财务目标 2030 年营收预期：超 2800 亿美元 2025 年实际收入：131 亿美元（超原目标 100 亿） 2025 年资金消耗：80 亿美元（低于预估 90 亿） 融资情况 新一轮融资规模：超 1000 亿美元 战略投资者占比：90% 主要投资方：软银、英伟达（最多 300 亿）、亚马逊 表面上看，这是 Altman 对此前"激进承诺"的修正。但更深层的问题是：为什么需要修正？谁在推动修正？ ...

假期有闲暇学习一下AI相关的知识，尝试着想用公众号对接DeepSeek做一个问答，当做一个BlogAgent，又不想写太多的工程类的代码，想着AI这么强大，能不能直接用AI生成代码。没有看阿里，百度的产品，直接试用了豆包的AI编程，通过这两天的试用，AI惊人的生产力着实让我惊掉下巴。 一、项目级代码生成 我一开始描述，要求 实现一个微信公众号的后台服务代码，可以接收用户信息，并且回复。 豆包直接生成了一个Python的代码，实现了微信公众号的后台接口，并且实现了签名认证，并且给出了详细的代码说明和注意事项。 然后我又要求使用Java+Spring Boot实现，它竟然给我实现了了一个完整的Maven项目。代码下载下来是真的可以跑的。 二、根据要求重构代码 在仔细看了下整个工程，代码就是一个Spring Boot的启动类，再加一个Controller。稍显不足的是，关于签名的代码，放在了Controller里，导致代码很乱。我随即发了一个优化建议： 把WechatController里的通用公共代码抽出去 这货竟然完全听懂了，乖乖的提取了一个Utils类，把签证签名，XML解析等相关的操作放了进去。 我又对比了下微信的API文档，我疑问道： POST接口不需要验证签名吗？ 它竟然立马意识到自己的错误，修正了自己的错误： 三、根据要求增添内容 我继续下达着我的命令： >请生成Spring Boot的配置文件 >再加入log4j2的日志框架，把相关的异常打到日志里 >把参数搞成对象，把解析xml改成通用的反序列化拦截器 >响应体也可以搞成对象，使用序列化拦截器 >把token改成配置项形式，放在配置文件里 >使用langchain4j集成调用deepseek。当微信用户发来消息以后，转发给deepseek，然后把响应给微信用户 >Spring Boot的方式初始化langchain4j 并且把相关代码抽出去单独的类，整个项目包名改成com.zhaoyanblog.agent项目名称微blog-agent >帮我在pom里设置国内的maven仓镜像地址 >集成对wordpress的访问，当微信用户请求“wp:” 开头的信息时，搜索WordPress里的文章，返回给用户。 >微信返回的消息 要是一个包含文章的摘要富媒体链接，业务点击消息可以跳转到网站。WordPress的网站地址zhaoyanblog.com。要放在配置文件里。 关于微信的Token也放在额外的类里，不要放在controller里 >请对工程使用Spring boot的方式配置accesslog， >配置文件里的注释在IDEA里是乱码，请修正. …… 它就像一个不知疲倦的程序员，不断的实现着产品经理提出的需求 四、帮我修正Bug 有关freemarker模版的问题，开始我希望把markdown改成HTML。它一开始给我的代码其中有这样一段： <p class="text-gray-800"><span class="speaker-highlight">DeepSeek</span>：<#noescape>${conversation.getContentAsHtml()}</#noescape></p> 但是我真实跑起来的时候，它报这样的错误 #noescape with no matching #escape encountered 它直接给我了解决方案，并解释了原因： <span class="speaker-highlight">DeepSeek</span>：${conversation.getContentAsHtml()?no_esc}</p> 但是好像还不行，我直接把报错信息再贴给它 ?no_esc can't be used here, as the current output format isn't a markup (escaping) format: undefined(mimeType=null, class=f.c.UndefinedOutputFormat) 这次它给的答案，完美解决了问题： 五、竟然提示我遵守规范 ...