很多人用 AI 写代码，真正卡住的地方往往不是模型不够强，而是任务交代得太散。

一句“帮我做完这个功能”丢出去，后面就开始反复补充、纠偏、救火。短任务还行，任务一长，模型很容易只抓住最显眼的部分，后面的约束、边界和验收标准慢慢就散了。

这篇原文讲的 /goal 方法，本质不是偷懒少写几个字，而是让 Codex 在开工前，先把“目标、范围、拆解、风险、验收”整理成一份可以执行的工作协议。

换句话说：不要急着让 Codex 干活，先让它写清楚自己准备怎么干活。

/goal 真正解决的不是 prompt，而是任务定义

过去我们写 prompt，经常把需求描述、执行步骤、注意事项和验收标准揉在一段话里。简单问题没什么影响，但复杂任务里，这种写法很容易让模型跑偏。

更稳的做法，是先让 Codex 给自己写一个新的 /goal。

这个 goal 要把你的意图改写成明确目标，并列出范围、约束、子任务、风险和验收标准。人负责给方向，agent 先把方向翻译成任务。

这和普通 prompt 的差别很大。

普通 prompt 像是“我给你一串指令，你照着做”。而 /goal 更像一次小型项目会：你说想要什么，Codex 先把任务定义、拆解方式、子任务边界和验收标准讲清楚，然后再开始执行。

所以，/goal 不是魔法咒语，它更像 agent 的工作协议。

真正有价值的地方，也不是“让 AI 自己决定一切”，而是让 AI 先把人的模糊意图，整理成可执行、可检查、可更新的计划。

五步工作流：先定义目标，再让 agent 开工

这套方法可以压缩成五步。

第一步，只写意图，不要急着写完整计划。

比如你想做一个 Three.js 第一视角过山车 demo，不需要一上来就把所有实现细节写死。先说清楚最终体验、约束和交付物就够了：循环轨道、下坠、倾斜转弯、倒挂、速度感、地形、天空盒、音效，以及最终交付一个单 HTML 文件。

这一步的重点，是让你先描述“想要什么”，而不是替 agent 过早规定“每一步怎么做”。

第二步，要求 Codex 先给自己写 goal。

这是核心动作。不要直接说“开始做”，而是让它先把任务转换成可执行目标。

可以直接这样写：

For this task, write yourself a new goal first. Turn my request into a concrete objective with scope, constraints, subtasks, and acceptance criteria. Then execute against that goal.

中文也可以更直白：

先不要急着实现。请先为你自己写一个新的 /goal：把我的需求改写成清晰目标，列出范围、约束、子任务、风险和验收标准。确认这个 goal 后，再按它执行。

这一步看起来慢，其实是在减少后面的返工。

第三步，如果任务够大，让它派生子 agent。

长任务往往不是一个线程能顺滑做完的。研究、实现、测试、审查，可以拆成相互独立的部分。

关键不是简单说“并行处理”，而是要求每个子 agent 都带着自己的 dedicated /goal 出发，明确自己负责什么、交付什么、不要碰什么。

可以补上这句：

If this benefits from parallel work, spawn agents for independent pieces. Give each agent its own dedicated /goal, make their deliverables explicit, and synthesize the results when they return.

这样拆出去的不是一堆松散任务，而是一组边界清楚的小工作单元。

第四步，主线程负责汇总，而不是让子 agent 抢方向。

并行 agent 最大的坑，是每个子任务看起来都做了，但最后拼不起来。

所以主线程必须保留“总编”角色：收集子结果，判断冲突，合并方案，决定下一步。子 agent 负责研究、补丁、测试和发现，主线程负责最终取舍。

这句话可以直接加进 prompt：

Keep the main path responsible for coordination. Subagents should return findings or patches, but the main agent must synthesize and make final decisions.

第五步，把 goal 当成可更新对象。

长任务最怕目标漂移。好的做法不是禁止修改目标，而是要求任何修改都必须显式说明。

If the goal needs to change, update it explicitly and explain what changed before continuing.

这样一来，agent 如果发现原目标不完整，可以调整；但它不能悄悄换题。你能看到目标为什么变、变成了什么、后续会按什么标准验收。

哪些任务适合，哪些任务别折腾

这套方法特别适合三类任务。

第一类是长代码任务。只要任务会持续超过 20 分钟，或者你预感中途要补充需求，就值得先让 Codex 写 goal。

第二类是多模块改造。比如前端、后端、测试、文档都要动，最好把研究、实现和验证拆开，让不同 agent 各自带目标工作。

第三类是探索型项目。你并不完全确定技术路线时，先让 agent 把范围、风险和验收标准整理出来，会比直接开写更稳。

不适合的场景也很明确：小修小补、单文件改一行、你已经有非常精确的实现方案。这种时候再写 /goal，反而会多一层仪式感。

我的判断是：任务越长、越复杂，/goal 的收益越明显；任务越短、越确定，它就越容易变成流程负担。

一段可以直接复制的模板

以后做复杂代码任务，可以把第一段换成你的真实需求，后面这段基本保留：

1
2
3
4
5
6
7
8

I want to accomplish the following task:
[在这里写你的真实需求]

Before implementing, write yourself a new /goal. Turn my intent into a concrete objective with scope, constraints, subtasks, risks, and acceptance criteria.

If the work can be parallelized, spawn agents for independent pieces. Give each agent its own dedicated /goal and explicit deliverable.

Keep the main path responsible for coordination and final synthesis. If the goal needs to change, update it explicitly and explain why before continuing.

如果是代码任务，建议再补三条：

1
2
3

Read the existing codebase first and follow local patterns.
Do not make unrelated refactors.
Verify the result with the most relevant tests or checks before finishing.

这三条很朴素，但很管用。它们把 agent 从“自由发挥”拉回到工程现场：先看项目现状，只做相关修改，最后用测试或检查验证结果。

最后，人的角色不是消失，而是前移

/goal 这类用法会让 agent 更像一个能维护上下文的合作者，但它不会自动替你完成产品判断。

你仍然要负责意图：要做什么，为什么做，哪些东西不能碰，结果怎么算完成。

Codex 负责把这些意图整理成工作目标，再把目标拆给合适的执行单元。人的角色不是从流程里消失，而是从“逐字写指令”变成“定义方向和验收”。

可以把这套方法记成一句话：不要只让 Codex 干活，先让它写清楚自己要怎么干活。

最近读到一条关于 Claude Fable 5 的长帖，里面没有继续重复“模型又变聪明了多少”这种叙事，而是把问题往前推了一步：当模型能力继续上升之后，我们使用模型的方式，也必须跟着变。

这件事真正值得关注的地方，不是 Fable 5 又在某个榜单上多拿了几分，而是它让智能体系统的设计逻辑变得更清楚了。

过去我们很容易把注意力放在提示词上：提示词怎么写得更清楚，约束怎么加得更完整，背景信息怎么一次性塞进上下文。但对更强的智能体模型来说，真正能释放能力的，可能不是一条更长的 prompt，而是一个能反馈、能验证、能沉淀经验的运行系统。

如果用两个关键词概括，就是：循环和记忆。

第一个变化：重点从“写提示词”转向“设计循环”

以前用 AI 工具，模型答得不好，我们通常第一反应是改提示词。结果不稳定，就继续加规则；任务复杂一点，就试图把更多材料一次性塞进上下文里。

但现在的问题是，提示词当然重要，却已经不是全部。

对于更强的智能体模型，更关键的是让它处在一个可以自我修正的环境里。也就是说，让模型先行动，再根据真实反馈调整下一步，而不是只靠一次性推理给出答案。

这个反馈可以来自测试、评分标准、日志、运行结果，也可以来自一个独立验证器。Claude Code 里的 /goal，以及 Claude Managed Agent 里的 Outcomes，本质上都是在做类似的事情：给模型一个目标或评分标准，让它持续尝试、观察反馈、修正策略，直到结果达标。

这其实很像工程师写程序。一个工程师不会只靠脑内推演完成所有工作，他会写代码、跑测试、看报错、改实现，然后再跑一遍。循环让模型也进入类似的工程流程，而不是停在“生成一次答案”这一步。

Lance Martin 提到的 Parameter Golf 实验很能说明问题。这个挑战要求智能体修改训练脚本、启动训练、查看日志和分数，再决定下一轮实验方向。它考验的不是模型能不能回答一个问题，而是能不能持续做实验。

在这个任务里，Fable 5 相比 Opus 4.7 对训练流水线的改进大约高出 6 倍。更有意思的是，两者的探索方式也不同：Opus 4.7 更像是在已有方案上调整常量，看到一点收益后继续沿着同一个模板微调；Fable 5 则更愿意做结构性改动，比如尝试架构级变化，而且在短期回退时也能继续推进。

这说明，模型强弱的定义正在变化。它不只是“更会回答”，还要“更会探索”。如果我们仍然把它当成一个问答接口，就很容易浪费它真正的能力。

第二个变化：从临时上下文转向跨会话记忆

另一个更重要的变化，是记忆。

很多时候我们说 AI 有记忆，其实只是把历史内容重新塞回上下文，或者从向量库里检索一些片段。但真正有用的记忆，不应该只是“存下来”，而应该形成一个跨会话的外层循环：模型在一次任务中记录经验，在下一次任务中读取这些经验，并逐步把错误、验证和规则沉淀下来。

这更像人学习新技术的过程。第一次踩坑，可能只记一句“这里容易错”；第二次遇到类似问题，会回头分析为什么错；再往后，才会把它总结成通用规则，下次直接复用，而不是每次重新推导。

Lance 用 Continual Learning Bench 里的任务比较了 Sonnet 4.6、Opus 4.7 和 Fable 5。这个任务要求智能体在可以访问 SQL 数据库的情况下连续回答一组问题。每个问题都是独立会话，但可以共享记忆。

他把有效使用记忆拆成了五个阶段：失败、调查、验证、提炼、查阅。

不同模型大致停在不同位置。Sonnet 4.6 往往停在第一步，会记下一堆失败笔记和开放猜测，但很少真正回头使用。Opus 4.7 能进一步整理 schema 参考，也会标记不确定性，但验证覆盖率不高。Fable 5 在表现较好的运行中，可以把验证覆盖率提升到 73%，并把学到的内容提炼成后续任务可用的规则。

这里的关键不是“记了多少”，而是记忆有没有改变下一次行动。

如果记忆只是堆积材料，那它很快会变成噪音。真正有价值的记忆，是能把失败转化为规则，把一次任务里的验证结果变成下一次任务的默认判断。

智能体系统真正要设计的是什么

读完这条线索后，一个更清楚的判断是：未来智能体系统的重点，可能不是不断追求一个更完美的单次提示词，而是设计一个更好的运行机制。

这个机制至少有两层。

第一层是内层循环。它负责当前任务，让模型围绕目标、测试、日志和评分标准不断修正结果。

第二层是外层记忆。它负责跨任务积累经验，把失败、验证和规则沉淀下来，在后续任务中复用。

也就是说，我们不只是把模型当成生成器，而是在为它搭建一个可以学习和改进的工作环境。

这也会改变我们看待“提示工程”的方式。提示词仍然重要，但它不再是唯一变量。更重要的问题变成了：

• 有没有给模型一个明确、可检查的目标？
• 有没有让模型看到真实反馈，而不是只靠自我感觉？
• 有没有使用独立验证器，避免模型自评偏差？
• 有没有把本次任务中的经验沉淀到下一次任务？
• 有没有把一次性对话，升级成可持续运行的系统？

这些问题比纠结一句提示词怎么写，更接近工程本质。

总结

Claude Fable 5 带来的启发，可以压缩成两句话。

第一，工作方式正在从“提示模型”转向“设计循环”。我们需要给模型目标、反馈和验证机制，让它能在任务中自我修正。

第二，上下文管理正在从“临时塞材料”转向“跨会话记忆”。我们需要让模型把失败、验证和规则沉淀下来，并在后续任务里真正复用。

越强的模型，越不应该只被当成一次性问答工具。它更像一个需要运行环境的工程组件。模型能力提升之后，真正拉开差距的，可能不是谁的提示词更长，而是谁能设计出更好的循环、更可靠的验证，以及更有效的记忆。

摘要：OpenAI 新推出的 Sites，让 Codex 不再只是写代码的助手，而是开始变成一个企业内部建站与轻应用生成工具。你只要用自然语言描述需求，它就能生成可交互、可托管、可分享的网站。这不是又一个 AI demo，更像是 OpenAI 把 Codex 从开发者工具推向企业基础设施的一次跳步。

昨天刷 X 的时候，看到 OpenAI 发了一条推文：Building apps has never been easier。

配套视频不到 1 分钟，演示的是 Codex 如何把一个想法直接变成一个可以分享的交互式网站。第一眼看，很容易觉得这不就是 Vercel v0 加 Replit 的合体吗？

但把 “Intelligence at Work” 发布会和开发者文档看完以后，事情没那么简单。OpenAI 这步棋，表面是建站，底层瞄准的是企业 AI Agent 的工作流入口。

Sites 到底是什么？

先说结论：Sites 是 Codex 的一个插件，能让用户用自然语言描述需求，然后由 Codex 生成一个可交互、可托管、可分享的网站或轻应用。

关键是三个词：交互式、托管、分享。

这和 ChatGPT 帮你写一段 HTML 不在同一个层级。你不用自己找服务器，不用处理部署、域名、SSL，也不用先学 React 或 Tailwind。Codex 生成之后，直接给你一个 URL，扔到工作群里，同事点开就能用。

官方给出的适用场景包括：仪表盘、规划器、评审工作区、项目看板、画廊，以及各种轻量工具。说白了，就是企业内部那些“需要但没人排期做”的小工具。

这个点很关键。每个公司都有类似需求：销售团队想要客户跟进看板，运营团队想要活动进度追踪器，产品团队想要评审页面。过去这些东西永远排在工程资源后面，现在可能只需要描述清楚，就能先跑起来。

OpenAI 官方原话是：With Sites, Codex can turn your work, ideas, and plans into an interactive website or app your team can explore, use, and share with a URL.

这条推文在 X 上拿到约 120 万次浏览、7.9 万点赞和 3.4 千收藏。热度不算炸裂，但评论区的反应很有意思。

Hacker News 上有用户提到，自己非技术背景的妻子已经能用类似工具给销售团队搭出一个很 impressive 的 dashboard，然后感叹：“我有点存在主义危机了，我不再那么特别了。”

也有人把这称作 Codex 对白领工作的一次大更新。另一边，关于模型公司垂直扩张到应用层、“SaaS 末日”和平台依赖的担忧，也随之出现。

技术实现比想象中更深

一开始我也以为 Sites 只是模板建站。但开发者文档里透露出的技术底座，其实更像一个认真面向企业场景的发布系统。

首先是两阶段发布管线。

第一步是保存版本。Codex 会构建可部署站点，并把版本和源代码的 Git commit 关联起来。这一步创建的是可审查的部署候选，不会直接公开。

第二步是部署版本。确认没问题后，才把保存的版本发布出去，拿到生产 URL。

这个设计很软件工程：先审查，再上线，不是一键裸奔。

OpenAI 还在开发者网站上做了 Sites Showcase，展示了 6 个示例项目：Onboarding Hub、Enablement Hub、Pulse Dashboard、Sparkboard、Launch Cal、Event Planning Hub。技术栈覆盖 Next.js、React、Three.js，甚至还有 SwiftUI。

存储方面，Sites 支持两类绑定：结构化数据用 D1，文件和图片等对象存储用 R2。如果只是静态着陆页，可以不接存储；如果是带登录、上传、状态记录的内部工具，就可以同时绑定 D1 和 R2。

运行时也值得注意。Sites 的构建产物是兼容 Cloudflare Worker 的 ES Modules，也就是说它不是随便搭了个自研壳子，而是站在 Cloudflare 边缘计算基础设施上。好处是低延迟、全球分发和弹性伸缩；代价是技术栈和基础设施依赖也更明确。

访问控制则明显是给企业准备的：admins_only、workspace_all、custom 三种模式，分别对应站点所有者、整个工作区，以及指定用户或用户组。

实际使用也很直接，在 Codex 里用 @Sites 触发插件，再描述你想要的内部工具。例如让团队成员提交项目请求、查看负责人、更新状态、筛选列表，并要求用工作区账号登录、保存访问数据。只要需求说清楚，Codex 就会尝试把它变成一个可用页面。

6 大业务插件：OpenAI 想做角色化 Agent 编队

Sites 并不是孤立功能，它和 OpenAI 这次面向 Business / Enterprise 的 Codex 战略绑在一起。

同时出现的，还有 6 个角色化业务插件：

• 数据分析插件：用自然语言探索数据、解释指标变化、创建报告，集成 Snowflake、Databricks、Hex、Tableau。
• 创意制作插件：帮助营销团队生成广告变体、产品图、电商素材，集成 Figma、Canva、Shutterstock、Picsart。
• 销售插件：识别优先客户、准备会议、更新客户记录，集成 Salesforce、HubSpot、Slack、Outreach。
• 产品设计插件：辅助原型制作、审计用户流程，集成 Figma、Canva。
• 公共股权投资插件：分析财报、对比公司、评估投资论点，接入 Moody’s、FactSet、LSEG、S&P、PitchBook。
• 投资银行插件：辅助推介材料、可比公司分析和尽职调查。

这套组合透露出的信息很清楚：OpenAI 不只是想让 Codex 写代码，它想把 Codex 做成按岗位分工的 Agent 编队。

每个插件背后，都是一套预置工作流、一组已经对接好的 SaaS 工具，以及针对特定岗位优化过的提示和操作路径。普通用户不用知道这些，只需要说“帮我准备明天和某个客户的会议”，Codex 就可能拉 Salesforce 的客户数据，生成会议准备材料，最后再通过 Sites 做成一个可交互的客户概览页。

所以 Sites 真正的价值，不是“它也能建站”，而是它成了 Agent 工作流的展示层。

过去团队对齐想法，要写文档、做 PPT、开会讲半天。每个人脑子里的理解还不一定一样。Sites 试图把这种“脑补对齐”变成“现场对齐”：直接生成一个能看、能点、能用的东西，让团队在使用中对齐。

和 v0、Replit、Cursor 比，差异在哪里？

很多人第一时间会把 Sites 和 Vercel v0、Replit、Cursor 放在一起比较。确实，它们都和“从想法到应用”有关，但面向的人群并不一样。

v0 生成 React 组件的能力很强，尤其是 UI 层面。但它输出的是代码，不是企业里马上可分享的成品网站。后续部署、后端、数据和权限，大多还要开发者接着处理。

Replit 更偏全栈，从提示词到部署的链路很顺。但它的核心体验仍然是“用 AI 辅助构建应用”，门槛比 Sites 高一些。

Cursor 则是专业开发者的 AI 编辑器，它增强的是编码过程，而不是把一个业务想法直接变成团队可用的 URL。

Sites 的优势，至少在当前叙事里，是门槛最低。一个不写代码的销售经理，如果能在 5 分钟内把客户跟进看板从想法变成链接，这件事对企业内部效率的冲击会很大。

这也是 Sites 和传统建站工具最大的不同：它不只是帮你“生成页面”，而是试图帮你“完成一段工作”。

OpenAI 的生态策略：不是筑墙，而是修桥

另一个信号也值得看：OpenAI 并没有把 Sites 做成一个孤立封闭的工具。

它提到的合作伙伴包括 Wix、Base44、Replit、Lovable、Figma、Webflow、Emergent。换句话说，OpenAI 不是只想做一个新的建站产品，而是想让 Sites 变成 Agent 工作流与外部工具之间的桥。

VentureBeat 的分析里有一句话很贴切：相比静态 PPT，Sites 承诺让企业以更易消化的方式持续查看最新指标和重要信息。

这句话背后的意思是：Sites 不只是展示页，而是一个“活页面”。它可以接 Figma 设计、Salesforce 数据、Snowflake 数据仓库，再把这些信息变成团队能直接操作的界面。

这是平台策略，不是单点工具策略。

我的判断

好的地方很明显。

从技术上看，Sites 的底座比预期扎实。Cloudflare Workers 运行时、D1/R2 存储绑定、两阶段发布流程、RBAC 访问控制，这些都不是随便做 demo 的配置，而是认真往企业产品靠。

从行业上看，这步棋也聪明。Codex 从 2 月发布以来，周活用户已经超过 500 万，但非开发者只占 20%。Sites 加角色插件，是 OpenAI 把 Codex 往更广泛知识工作者市场推进的钥匙。

但现在我不会给太高分，最多 6 分左右。

第一，它目前主要面向 Business 和 Enterprise。Business 工作区默认开启，Enterprise 还需要管理员在 RBAC 里手动打开。Plus、Pro 和 Free 用户暂时用不上，口碑扩散会受限制。

第二，自定义能力仍有限。站点跑在 OpenAI 和 Cloudflare 的基础设施上，定制空间和开发者掌控感很难和 Vercel v0、Replit 这类工具比。

第三，影子 IT 风险会变大。团队自己生成各种内部应用，效率是提高了，但谁负责维护、谁负责安全审查、谁确认数据权限，都可能变成新的治理问题。

还有使用边界也要注意。Sites 条款里明确禁止处理受 HIPAA 保护的医疗数据、PCI DSS 管辖的支付卡数据，以及资金转移和加密货币交易相关场景。这说明它目前更适合内部工具、原型和轻量工作流，而不是高敏感数据的生产系统。

总体看，Sites 的意义不在于“OpenAI 又做了一个建站工具”，而在于 Codex 正在从写代码走向交付成果。

当年 WordPress 让建站从“写 HTML”变成“选主题”。Sites 想做的事情本质上类似，只是这次用户连主题都不用选，说出来就行。

“我们现在已经基本追平了几个月前的最先进水平。”

Build 大会前夕，微软 AI 执行副总裁兼 CEO Mustafa Suleyman 用这句话，给微软最新一轮自研模型发布定了调。

这次微软在 Build 上一次性推出多款 MAI 系列模型。对一家过去几年深度依赖 OpenAI 的公司来说，这不是普通的产品更新，而是一次很清晰的战略转身：微软正在从“AI 应用整合者”，进一步走向“全栈 AI 基础设施与模型提供者”。

外界把这场大会称作微软的“AI 独立日”，并不夸张。

首个高级推理模型：MAI-Thinking-1

这次发布中最受关注的，是微软首个高级推理模型 MAI-Thinking-1。

据微软介绍，MAI-Thinking-1 是一款“中等规模模型”，拥有 350 亿活跃参数、128K 上下文窗口，总参数规模约 1 万亿。它的设计重点不是单纯堆大，而是在推理能力、效率和低 token 成本之间取得平衡。

微软开发者市场负责人、GitHub 首席运营官 Kyle Daigle 表示，MAI-Thinking-1 主要面向复杂多步骤指令、长上下文推理以及代码生成任务。

过去一年，推理模型赛道基本由 OpenAI o 系列、Google Gemini 推理版本、Anthropic Claude 的扩展思考模式主导。开源阵营里，DeepSeek R1 也曾在 2025 年初明显撼动这一格局。

现在，微软正式入场。

从公开信息看，MAI-Thinking-1 在关键软件工程基准中已经可以对标领先模型；在 SWE Bench Pro 上，其表现与 Claude Opus 4.6 持平。

数学推理方面，它在 AIME 2025 中达到 **97.0%**，在 AIME 2026 中达到 **94.5%**。微软还称，在盲测人工对比评估里，用户对 MAI-Thinking-1 的偏好甚至超过 Claude Sonnet 4.6。

真正被强调的是“从零训练”

相比跑分，微软这次更想强调的是另一件事：MAI-Thinking-1 不靠蒸馏。

微软明确表示，该模型训练数据中不包含任何其他已训练 AI 系统的概率分布或输出序列，也没有使用来自第三方模型的蒸馏数据。

换句话说，它不是靠学习别家模型输出追上来的，而是从预训练阶段就排除 AI 生成内容，使用企业级、干净、具备合规商业授权的数据训练。

微软的说法是，这会迫使模型真正学会任务本身，而不是模仿另一个模型的回答风格。

这件事对普通开发者可能只是一个技术标签，但对企业客户，尤其是医疗、金融、国防以及高监管行业来说，意义会更大。

这些场景采购 AI 时，不只会问模型能不能用，还会问训练数据从哪里来、知识产权是否干净、能不能通过合规审查。

所以，“不使用第三方模型输出”“不碰蒸馏”，很可能会成为微软面向企业客户的一张关键牌。

MAI 模型家族补齐多模态版图

除了 MAI-Thinking-1，微软还发布了另外六款 MAI 系列模型，覆盖图像生成、图像编辑、语音转写、语音合成和编程等方向。

MAI-Code-1-Flash 是一款高效率智能体编程模型，参数规模为 5B，目标是深度集成到 GitHub Copilot、Visual Studio Code 以及微软整体技术栈中。微软称其性能可对标 Haiku，但成本更低。

图像方向，MAI-Image-2.5 及其 Flash 版本支持文生图和图像编辑，Arena 评分已超过 Nano Banana Pro。

语音方向，MAI Transcribe-1.5 被称为当前最强语音转录模型之一，速度是同类模型的 5 倍，并内置支持 43 种语言的领域专有术语。

语音生成方面，MAI-Voice-2 支持 15 种语言的自然语音生成，可通过短语音样本进行声音适配，并加入滥用防护。更高性价比的 MAI-Voice-2-Flash 也即将推出。

这些模型未来都将接入 Azure AI Foundry，以及新的 MAI Playground。微软还表示，开发者将首次可以对部分模型权重进行自定义调优。

这说明微软并不是只补一个推理模型，而是在搭建从基础模型、多模态能力到开发者平台的完整 MAI 生态。

Scout：把模型塞进 Microsoft 365 工作流

模型之外，微软还推出了新的企业智能体 Scout。

Scout 基于 OpenClaw 框架构建，可以在 Microsoft 365 应用之间全天候自主运行，独立完成任务。它能够连接 Teams、Outlook、OneDrive、SharePoint 等应用，并访问聊天、邮件、日历和联系人数据。

用户可以通过 Teams 调用 Scout，它也可以与浏览器交互，并通过 MCP 连接外部应用。微软称，该工具可在云端、桌面端和网页端运行。

微软企业副总裁 Omar Shahine 表示，这类智能体会在后台持续理解用户在各种应用和系统中的工作方式，并在不需要每次提示的情况下主动采取行动。

例如，它可以帮助办公人员协调会议时间、根据后续安排预留日历空档，也可以提前发现决策停滞等风险，让用户在问题变成阻碍前处理。

不过，OpenClaw 此前曾因安全漏洞受到审查。微软这次特别强调，Scout 具备企业级安全与控制能力，“从第一天起就可以在组织中被信任使用”。

目前，Scout 以实验性版本向 Frontier 项目客户开放，需要通过 Intune 策略配置以及主动选择确认。定价暂未公布，也不清楚它未来会纳入 Microsoft 365 Copilot 订阅，还是单独收费。

微软想拿回 AI 底座主动权

过去几年，微软在 AI 领域的优势很大程度来自 OpenAI。Azure、Copilot、GitHub Copilot、Microsoft 365 Copilot，都受益于这段合作关系。

但底层模型高度依赖外部伙伴，也意味着微软在成本、节奏、产品差异化和企业合规上会受到限制。

MAI 系列的发布，正是在补这块短板。

MAI-Thinking-1 代表微软开始拥有自己的高级推理模型；MAI-Image、MAI-Voice、MAI Transcribe 代表多模态能力成型；Scout 则说明微软希望把这些模型真正嵌入企业工作流。

微软不想只做 AI 应用入口，也不想永远只是 OpenAI 时代的最大渠道商。它要把模型、平台、工具链和企业智能体重新握在自己手里。

这也是“AI 独立日”这个说法真正成立的原因。

结语

MAI-Thinking-1 追平 Claude Opus 4.6，是一个醒目的能力信号。

但更值得关注的是，微软正在把模型能力从外部依赖变成内部资产。

从零训练、不使用第三方模型蒸馏、强调企业级干净数据，这些听起来没有跑分那么刺激，却可能正是企业客户最在意的部分。

当企业开始真正采购 AI，它们不会只问“哪个模型最强”，还会问：这个模型从哪里来？数据是否合规？知识产权是否干净？能不能被纳入企业治理体系？

微软这次给出的答案很明确：它要成为一个真正拥有自研模型底座的 AI 平台公司。

2.1.160 距离上一版只隔了 23 小时，但这次并不是走过场。

这一版最核心的动作，是给几类可能被拿来执行恶意代码的路径补上确认提示：shell 启动文件、构建工具配置、git 配置。另一处用户能直接感知的变化，是 dynamic workflow 的触发词从 workflow 改成了 ultracode，输入框里会以紫色高亮显示。

后台会话也修了一批稳定性问题，prompt tokens 则从约 11.6 万降到约 5.8 万，几乎砍半。表面看是一次常规迭代，但安全加固、后台可靠性和提示词瘦身，都是 Claude Code 这种工具越往深处走越绕不开的苦活。

三道安全防线：先把门锁上

2.1.160 最值得认真看的，是安全部分。

这次不是修某一个已经暴露的具体漏洞，而是提前给高风险写入路径加确认。它堵的是同一类攻击模式：通过修改配置文件，把恶意命令持久化到用户环境里。

第一道防线，是 shell 启动文件。

.zshenv、.zlogin、.bash_login，以及 ~/.config/git/ 这类路径，在终端启动或 git 操作时可能自动加载。如果某个 MCP server、skill，或者被污染的自动化流程，往这些地方塞进一行命令，下次打开终端或执行 git 时就可能直接跑起来。

从 2.1.160 开始，Claude Code 写这些文件前会先弹确认。换句话说，不是不让写，而是把“静默写入高危启动项”变成“你想清楚了再让它写”。

第二道防线，是构建工具配置。

在 acceptEdits 模式下，Claude Code 现在写入 .npmrc、.yarnrc*、bunfig.toml、.bazelrc、.pre-commit-config.yaml、.devcontainer/ 等文件前，也会提示确认。

这些文件的危险点在于，它们经常和依赖安装、构建、提交、容器启动绑定。.npmrc 可能影响 install 行为，pre-commit 可以直接跑 shell，devcontainer 则可能在打开项目时触发一整套初始化动作。对于自动接受改动的模式来说，这类路径原本就应该被单独拎出来。

这次加固的意义就在这里：它不是等攻击发生后补洞，而是提前把攻击面降下来。

workflow 改成 ultracode：避免误触，也是在腾位置

另一个很明显的变化，是 dynamic workflow 的触发关键词从 workflow 改成了 ultracode。

这个改名看着小，其实很合理。

workflow 是一个太常见的自然语言词。用户说 “show me the workflow”，或者问“这个 workflow 怎么设计”，都有可能不小心触发 dynamic workflow。2.1.157 刚引入 dynamic workflow 时，Anthropic 还专门做过「Workflow keyword trigger」开关，让不想误触的人关掉。现在直接换成 ultracode，问题就简单多了：这个词几乎不会自然出现在日常句子里。

更重要的是，它还能和 /effort ultracode 保持同一套命名。至于用自然语言描述来触发 workflow 的能力并没有消失，你说“帮我用多个 agent 一起处理这个任务”，仍然可以进入 dynamic workflow 流程。

我更倾向于把这次改名理解为两层意思：一层是减少误触；另一层是给未来的 workflow 编排能力让路。毕竟 workflow 在 MCP、插件和自动化生态里都是常用概念，继续拿它当硬触发词，迟早会撞名。

grep 之后不用再 Read：小改动，但很顺手

这版还有一个体验改进很实用：单文件 grep / egrep / fgrep 现在可以满足 read-before-edit 校验。

以前的流程经常是这样：先用 grep "某函数" src/file.ts 看到了目标位置，准备修改时，Claude Code 又提示“你还没读这个文件”，于是还得再 Read 一遍。现在单文件 grep 结果可以算作已经看过文件，省掉一步。

这个改动只对单文件生效，多文件 grep 仍然不算。逻辑也说得通：单文件 grep 至少能确认上下文来自哪个文件；多文件搜索通常只是定位线索，还需要进一步明确要改哪一份。

后台会话：修的都是日常会踩的坑

后台会话这次修复不少，而且每一个都直接影响使用体验。

最严重的是恢复已完成会话时，对话历史可能丢失，并重新执行原始 prompt。你从 claude agents 里打开一个已经跑完的后台任务，本来只是想看结果，结果它忘了前面的对话，又从头跑一遍，这基本等于白做。

类似的问题还包括隔夜后的后台 session 重新 attach 时丢对话、重新执行原 prompt。对于让 agent 跑长任务的人来说，这种 bug 的杀伤力很大：任务不是不能跑，而是跑完之后结果不可靠。

这次还修了 claude --bg 在高负载机器冷启动 daemon 时偶发 socket missing 的问题；修了 Windows 上 claude rm 后后台 daemon 没退出导致目录删不掉的问题；也修了后台 agent 恢复工作后被错误列在 Completed 下，以及退出 agents 列表时因自动更新检查导致界面冻结的问题。

这些都不是炫技功能，但它们决定后台 agent 到底能不能成为日常工作流的一部分。

Windows 和输入修复：中文用户也能感到变化

Windows 端这次也补了几处痛点。

WSL 下选中复制不再依赖 OSC 52，而是改用 PowerShell interop 写入 Windows 剪贴板。对于 MobaXterm 这类不支持 OSC 52 的终端来说，这个修复很关键。

高 CPU 负载下，附着到后台 session 或在 agent 视图里 Esc、方向键、输入无响应的问题也修了。这个大概率和事件循环被重任务堵住有关，Windows 用户跑大项目时很容易遇到。

还有一个对中文用户很直接的修复：CJK 输入法候选窗不再跑到屏幕左下角，而是回到输入光标附近。候选窗位置不对，看似小 bug，实际会让中文输入几乎不可用。

prompt tokens 砍半：官方没强调，但很值钱

这版最意外的数据，是 marckrenn 统计到的 prompt 变化：prompt tokens 从约 115,652 降到约 58,309，减少 57,343，降幅 49.6%。prompt 文件数也从 81 个降到 42 个，少了 39 个文件，降幅 48.1%。

这个幅度不太像小修小补，更像做了一轮系统提示词合并、去重和压缩。

Token 分布也有变化：tools 占比从 86.1% 升到 87.9%，system-reminder 从 8.2% 降到 7.2%，system 从 3.2% 降到 1.0%，system-data 从 1.1% 升到 2.3%。也就是说，真正被砍掉的主要是系统级指令和重复提示，工具定义本身并没有大幅减少。

这件事 Anthropic 官方 changelog 没有重点提，但对 API 付费用户很实际。每次请求少掉约 58k tokens，用得频繁时就是直接省钱。原文按 Opus 4.8 估算，单次 request 大约能省 0.87 美元。对每天几十上百次调用的人来说，这比加一个小功能更有体感。

这一版的方向

2.1.160 不是那种让人一眼“哇”的版本，但每条改动都落在关键位置。

安全防护走的是预防性路线。现在未必已经有公开案例利用 shell 启动文件或构建配置攻击 Claude Code 用户，但先给这些路径加确认，总比等事后补丁强。上一次 Claude Code 比较密集地做安全加固，是 2.1.101 那次命令注入修复；那次更像修漏洞，这次更像压攻击面。

后台会话的修复量也说明 Anthropic 在认真推进后台 agent 模式。它修的不只是 crash，还有目录锁、列表分类、会话恢复、界面冻结这些细节。只有这些细节稳定下来，多 agent、长任务、隔夜任务才有可能真正成为默认用法。

至于 workflow 改名 ultracode，我不觉得只是换个触发词。它更像是在给后续的 workflow 编排能力留下语义空间：workflow 这个词应该属于更通用的流程系统，而不是一个容易误触的关键词。

从 2.1.157 到 2.1.160 这几版连着看，节奏其实很清楚：插件体系铺底，云平台 auto mode 扩展，内部管线优化，然后补安全和可靠性。每版只做一两件事，但都在把 Claude Code 从“能用”往“可长期托付”推。

升级方式也很简单：Native 安装一般会自动后台更新；如果想立刻应用，可以执行 claude update。Homebrew 用户则是 brew upgrade claude-code。

大模型上下文窗口详解：超长上下文原理与工程取舍，小白也能看懂

在做大模型落地开发时，很多人都会遇到这些问题：多轮对话越聊越乱、长文档喂进去之后模型抓不住重点、超长代码分析越到后面越不准、上下文一多模型像突然“降智”一样开始答非所问。

大多数人会简单地把问题归结为“模型不够强”。但从工程角度看，这些现象背后真正的核心变量，往往不是模型名字，而是上下文窗口（Context Window）。

上下文窗口决定了模型当前这一轮到底能看到多少信息、记住多少信息、基于多少信息做推理。它既是大模型非常底层的一项能力，也是影响 Prompt 设计、长文档处理、RAG 架构和模型选型的关键参数。

这篇文章会把上下文窗口的底层逻辑、优势、短板以及工程上的取舍讲清楚，帮助你真正理解：为什么有时应该上长上下文模型，为什么更多时候反而应该优先考虑 RAG。

一、什么是上下文窗口？

一句话解释：上下文窗口，就是大模型当前这次回答中，最多能“看见、记住、理解”的文本范围。

如果把大模型类比成人，那么上下文窗口有点像人的“瞬时工作记忆”。

人不可能在同一时刻把几万字内容都牢牢抓在脑子里，只能优先关注当前最相关、最重要的一部分信息。大模型也是一样，它每次生成回答时，并不是无限读取所有历史内容，而是只能处理窗口范围内的 token。超出窗口的内容，模型就看不到了。

因此，无论是：

• 系统提示词；
• 多轮对话历史；
• 用户当前问题；
• 上传的文档、代码、资料；
• 输出格式要求与约束条件；

本质上都要一起“挤”进这个窗口里。

窗口越大，模型一次能处理的内容就越多；窗口越小，能容纳的信息就越有限。

Token 是怎么回事？

上下文窗口通常不是按“字数”算，而是按 Token 计算。

Token 可以理解成模型内部处理文本的最小单位。中文、英文、标点、数字在分词后都会转成 token。粗略理解时，很多文章会把 1 token 近似看作 0.75 个中文字符左右，但这只是一个非常粗的经验值，实际会随内容结构变化。

工程上更重要的是知道：窗口容量拼的是 token，不是拼字数。

二、上下文窗口里到底包含什么？

很多刚接触大模型的人，会误以为上下文窗口只计算“用户这一句提问”。

其实远不止如此。

在实际系统里，一个请求通常至少包含三部分内容：

1. 系统提示词

这是模型最开始拿到的全局规则，包括：

• 角色设定；
• 输出格式；
• 风格要求；
• 禁止事项；
• 防幻觉约束；
• 工具调用规范。

这部分虽然用户看不到，但会真实占用上下文窗口。

2. 历史对话

只要是多轮对话，前面几轮的问答记录也会一起带进当前请求中。这部分就是模型看起来“有记忆”的根源。

如果历史内容很多，它会持续吞掉窗口预算。

3. 当前输入内容

包括用户本轮新提问，以及附带上传的文档、参考材料、代码片段等。

这才是大多数人最容易想到的部分，但它往往只是总窗口的一部分，而不是全部。

因此，真正的 token 消耗不是“当前问了多少”，而是：

系统提示词 + 历史对话 + 当前输入 + 预留输出空间

一起构成完整预算。

一旦总量超出窗口上限，系统通常就会开始截断。最常见的是裁掉最前面的历史内容，结果就是：

• 模型忘记最初约束；
• 前面需求丢失；
• 人设失效；
• 输出风格突然变化；
• 对话越聊越跑偏。

三、超长上下文窗口到底强在哪里？

近年来，越来越多模型开始宣传 128K、200K，甚至 1M 级别的上下文窗口。它们之所以被视为更高级的模型，不是因为“数字更大看起来更厉害”，而是它们确实在一些场景中具备非常明显的价值。

1. 可以整文件全量处理

如果窗口足够大，模型就能直接读取：

• 完整论文；
• 合同全文；
• 上万行代码；
• 超长会议纪要；
• 整份调研报告。

这样做的好处是，不需要先把内容切片，也不一定需要额外做检索召回，模型可以直接在全局范围内理解内容之间的联系。

2. 多轮对话不容易失忆

当窗口足够长时，前面几十轮甚至更多轮的对话都还能被保留下来。

这意味着模型更容易记住：

• 初始目标；
• 最开始定义的规则；
• 前面讨论过的术语口径；
• 之前确认过的输出结构。

在复杂协作式任务里，这一点非常重要。

3. 更适合做全局关联分析

很多任务不是只看局部片段就能完成的，而是必须跨章节、跨段落、跨文件做整体理解。

比如：

• 比较合同前后条款是否冲突；
• 找论文结论是否与前文实验设置一致；
• 做整仓代码架构梳理；
• 对长文做统一改写与逻辑复盘。

在这类场景里，长上下文的优势非常明显，因为模型不是在碎片化地看内容，而是在更完整的全局视角下做分析。

四、为什么“窗口越大越好”是个误区？

很多人第一次接触长上下文模型时，会自然得出一个结论：既然大窗口能装更多信息，那肯定越大越好。

但工程实践里，这其实是一个非常常见的新手误区。

长上下文并不是没有代价的，它反而伴随着几个很容易踩坑的硬伤。

1. 成本更高，速度更慢

上下文越长，模型在注意力计算时要处理的内容就越多。

这直接带来几件事：

• 输入 token 成本上升；
• 推理延迟变长；
• 整体调用价格更贵；
• 并发吞吐下降。

如果业务是高频调用、批量调用或在线实时调用，这个差异会非常明显。

所以在很多企业场景里，长上下文并不只是“更强”，它首先意味着“更贵”。

2. 注意力会被稀释

这是最关键、也最容易被忽视的问题。

很多人以为信息越多越好，但实际上，当你把几万字甚至十几万字内容一股脑全塞进模型时，模型并不一定会因此更精准，反而可能更容易忽略真正关键的信息。

因为在超长文本里：

• 冗余信息变多；
• 无关片段变多；
• 关键信息被埋得更深；
• 模型对核心细节的关注度被分散。

这就是所谓的“注意力稀释”。

结果就是：看起来给了更多材料，实际上回答却可能更飘、更泛、更抓不住重点。

3. 幻觉和逻辑混乱更容易增加

长文本本身往往包含更多语义冲突、更多模糊片段、更多跨段关系。

当这些内容一起进入上下文时，模型更容易出现：

• 错误关联；
• 前后矛盾；
• 引用错位；
• 逻辑链路混乱；
• 结论偏离重点。

也就是说，长上下文并不是“自动提升质量”的万能钥匙。很多时候，它只是提供了更大的输入空间，而不是更强的筛选能力。

五、长上下文和 RAG，到底该怎么选？

这是大模型工程里最常见、也最实用的一个选型问题。

很多团队都会在这里纠结：到底应该直接上超长上下文模型，还是用短窗口模型加 RAG？

一个非常实用的判断方式是：你到底是要模型“全量读完”，还是只要它“精准找到相关内容”。

更适合用 RAG 的场景

RAG 更适合这些情况：

• 知识库问答；
• 海量文档中查某个问题；
• 资料持续更新；
• 高频业务调用；
• 大篇幅材料里只需要局部相关内容；
• 企业私有知识需要动态接入。

RAG 的核心思路不是把所有材料一次性塞给模型，而是先通过检索找出最相关的少量片段，再把这些片段交给模型回答。

它的优势在于：

• 成本更低；
• 延迟更稳；
• 相关性更集中；
• 动态知识更新更方便；
• 能有效避免海量冗余信息稀释注意力。

更适合用长上下文的场景

长上下文更适合这些任务：

• 合同全文审阅；
• 论文精读；
• 整仓代码理解；
• 全文统一改写；
• 长报告全局对比；
• 需要跨章节整体关联的复杂任务。

这类任务的问题在于：你不能只取几个片段，因为真正的答案很可能依赖全文结构、段落前后关系、不同章节之间的对应逻辑。

此时如果强行用 RAG 切碎，可能会损失整体语义关系。

一个工程上非常实用的结论

如果问题的本质是“从很多内容里找最相关的一小部分”，优先考虑 RAG。

如果问题的本质是“必须通读完整材料并保持整体关联”，再考虑 长上下文模型。

换句话说：

细碎知识库更适合 RAG，完整文件精读更适合长上下文。

六、上下文窗口的工程最佳实践

理解原理之后，更重要的是如何在系统里真正把它用对。

1. 不要盲目迷信大窗口

在大多数业务里，真正需要整份长文全文理解的情况，并没有想象中那么多。

很多任务其实只是：

• 查一个问题；
• 找一个字段；
• 抽一段信息；
• 根据少量材料回答。

这种场景下，短窗口模型配合 RAG，通常成本更低、稳定性更高、整体性价比也更好。

2. 系统提示词要尽量精简

很多项目一开始就把系统提示词写得特别长，结果关键业务信息还没进来，窗口已经被说明文字吃掉一大块。

所以系统提示词的原则应该是：

• 保留真正有效的规则；
• 删除冗余套话；
• 减少重复约束；
• 把关键规则写得短而明确。

窗口是预算，不要把预算浪费在形式化废话上。

3. 多轮对话要做历史修剪

如果是长期对话系统，不能无限堆历史消息。

更稳妥的做法是：

• 保留任务起点；
• 保留最近关键轮次；
• 删除中间无效闲聊；
• 必要时做摘要压缩。

这样既能保住上下文连续性，又能防止窗口被历史垃圾信息挤爆。

4. 长文档优先考虑切片与筛选

并不是所有长文都要原样整篇喂给模型。

如果任务本身并不依赖全文逻辑，而只是要回答某个问题，那么先切片、再检索、再召回核心片段，通常会比整篇硬塞更有效。

这本质上是在主动对抗注意力稀释。

5. 关键信息要放在模型更容易注意的位置

很多模型对开头和结尾的信息相对更敏感。

因此在实际提示设计中，最好把这些内容尽量前置或后置：

• 核心规则；
• 真正任务目标；
• 不能违反的约束；
• 最终输出格式要求。

不要把最重要的信息埋在一堆冗长背景材料中间。

七、全文总结

上下文窗口决定了大模型的记忆上限、视野上限和理解上限。

但它并不是越大越万能。

短窗口模型往往更便宜、更精准，也更适合和 RAG 组成高性价比方案；长上下文模型虽然更适合全局理解，但代价更高，也更容易受到注意力稀释和长文本幻觉的影响。

真正成熟的大模型工程思维，不是单纯追求“窗口最大”，而是根据任务本质选择最合适的路线：

• 能检索定位的任务，优先 RAG；
• 必须全文理解的任务，再上长上下文；
• 能省窗口的地方，尽量省；
• 能减少冗余输入的地方，尽量减。

当你把上下文窗口的逻辑想清楚之后，Prompt 设计、参数使用、RAG 选型、模型选择，其实都会自然串成一套完整的判断体系。

而这，正是从“会用 AI”走向“能把 AI 落地”的关键一步。

RTX Spark 来了：为什么它可能重新定义个人 PC 的 AI 时代

今天，英伟达的 NVIDIA GTC Taipei 2026 如约而至。

发布会上讲了很多东西，但如果只挑一个最值得单独拎出来讲的，我觉得就是 RTX Spark。

因为它不是一次普通的产品更新，而更像是英伟达在试着回答一个问题：个人电脑诞生 40 年之后，AI 时代的 PC，到底该重新长成什么样。

“A New Line, A New Beginning。”

这句口号放在这次发布里，并不只是营销话术。至少从英伟达给出的路线来看，它想做的并不只是更强的消费级芯片，而是把“本地大模型 + 统一内存 + CUDA + Windows 原生 Agent”第一次比较完整地装进一台个人电脑里。

过去半年，AI 的主要进展几乎都发生在云端。

OpenClaw、Claude Code、Codex 这类产品的背后，本质上还是云端大模型在持续变强。但如果视角回到 ToC 端硬件，你会发现真正有决定性变化的东西并不多。

可问题是，谁不想把大模型和 Agent 真正部署到自己的本地端？

低延迟、隐私保护、无需网络，不只是推理，甚至还可以微调。那种自由又安全的感觉，始终很有吸引力。

所以，这次 RTX Spark 真正打动人的地方，不是它又多了一块新芯片，而是它让“本地 AI PC”这件事第一次显得没那么像概念，而像是一条正在被认真推进的产品线。

RTX Spark，到底给了什么？

如果只看参数，这次的东西已经很夸张了。

• 最高 1 PFLOP 的 FP4 AI 性能
• 20 个 CPU 核心
• 6144 个 GPU 核心
• 128GB LPDDR5X 统一内存
• 官方给出的定位，是可以在本地直接承载 120B 级模型

这组参数最重要的意义，不在于看起来够不够猛，而在于它在个人消费级设备里，第一次比较明确地把“本地跑更大模型”这件事推到了主舞台上。

如果只是云端推理更快，那还是云服务的故事；但如果个人电脑本身开始具备稳定承载大模型和 Agent 的能力，那就是另一条路了。

为什么这次最关键的是统一内存

要理解 RTX Spark，最绕不过去的就是 统一内存。

传统 PC 里，CPU 和 GPU 各有各的内存：

• CPU 用系统内存（RAM）
• GPU 用显存（VRAM）
• 两边交换数据，要通过 PCIe 之类的通道来回搬运

这套架构对很多传统应用没问题，但对本地大模型很不友好。

比如一台机器有 64GB RAM，再搭一张 16GB VRAM 的显卡。你看起来总内存不小，但 GPU 真正能高速访问的，往往还是那 16GB 显存。

一旦模型太大，显存放不下，就只能把一部分权重留在系统内存里。GPU 每次需要这些权重时，就得跨通道去拿，结果就是：理论上能跑，实际上很慢。

统一内存解决的，就是这个问题。

当 CPU 和 GPU 共享同一个大内存池之后，GPU 不再被那点独立显存卡得死死的。对本地大模型、长上下文推理、多模态工作负载来说，这几乎是体验能不能真正上一个台阶的关键差别。

所以这次 RTX Spark 的价值，并不只是“性能更强”，而是它在消费级 PC 上，把统一内存真正推成了 AI 时代的核心卖点。

那为什么不是 Mac，而是 RTX Spark 更让行业兴奋？

说到统一内存，很多人第一反应都是 Mac。

这没错。Apple 早就把统一内存做成了自己的主流路线，而且体验也很好。

但问题在于，统一内存只是其中一半，另一半是 CUDA。

这也是为什么 RTX Spark 会让这么多开发者真正兴奋。

因为对 AI 工程来说，CUDA 从来不只是一个“显卡加速技术”的名字，它是一整套积累了将近二十年的生态。

• cuBLAS 做线性代数
• cuDNN 做深度学习基础运算
• TensorRT 做推理优化
• NCCL 做多卡通信
• 大量开源模型、训练代码、推理框架，默认首先支持的依然是 CUDA

这意味着什么？

意味着今天你去看学术代码、开源模型、工程教程、性能优化经验，默认语境基本都还是 CUDA。AI 工程界的“母语”，到今天依然是它。

而 Apple 的问题并不是统一内存不够好，而是它的 GPU 生态更多是 Metal / MLX 路线。推理层面在很多轻量场景已经不错，但一旦进入训练、微调、复杂工作流兼容这些问题，CUDA 的护城河仍然非常深。

所以 RTX Spark 真正最有杀伤力的点，是它第一次把过去在 PC 端很难兼得的两件事往一起捏：

统一内存的容量优势 + CUDA 生态的工程优势。

它瞄准的并不只是硬件，而是一整套本地 Agent 平台

如果 RTX Spark 只是一块更强的芯片，这次发布不会有这么大反响。

真正值得注意的是，英伟达讲的已经不只是硬件，而是一套完整的平台路线。

从发布信息看，这套路线至少包括三层：

1. 底层硬件

RTX Spark 提供统一内存、高带宽和 CUDA 兼容能力，让本地大模型真正有了更现实的承载基础。

2. 系统层支持

微软会和英伟达一起重构 Windows 对本地 Agent 的支持。这件事非常关键，因为它意味着未来 Windows 可能不是“顺便能跑 AI”，而是开始朝“原生承载 Agent 工作流”去改。

3. 安全与运行环境

无论是 Windows security primitives，还是英伟达提到的 OpenShell，本质都在说明一件事：本地 Agent 不能只是能跑，还得能被认证、隔离、授权和管控。

这点其实很重要。因为真正进入个人生产力和企业环境后，决定一套平台能不能落地的，从来都不只是算力，还包括权限、安全和系统协同。

这意味着什么？

如果你是开发者，这套东西的吸引力会很直接：

• 本地跑更大的模型
• 更自然地做 Agent 工作流
• 更低门槛地试多模态应用
• 更顺滑地接入 CUDA 现有工具链

如果你是创作者，这件事也不只是“AI 生图更快”那么简单。

一旦 Adobe、视频编辑、3D 场景、内容工作流都围绕这种本地 AI 设备做深度优化，那么未来很多创作行为会从“调用云端 AI 服务”，变成“系统原生调用 AI 能力”。这两者的体验逻辑，其实完全不是一回事。

写在最后

RTX Spark 最值得关注的地方，不只是参数强不强，而是它第一次试图把几块长期割裂的能力整合进同一套个人 PC 方案里：

• 统一内存
• CUDA 生态
• 本地大模型能力
• Windows 原生 Agent 支持

如果说过去的 AI 浪潮主要发生在云端，那么 RTX Spark 真正想回答的问题就是：下一波 AI，能不能回到每个人自己的电脑上？

至少从这次发布会看，英伟达给出的答案已经非常明确了。

它想开启的，不只是一个新品，而是一整代 AI 原生个人 PC 的起点。

苹果AI眼镜又跳票：问题不只是硬件，更是Siri还撑不起这副眼镜

苹果的 AI 眼镜又往后挪了。

按照彭博社记者马克·古尔曼的最新说法，这款内部代号 N50 的产品，发布时间已经从原本的 2026 年底推迟到 2027 年底左右，真正到用户手里，大概率要等到 2028 年。这几乎把外界对苹果 AI 眼镜的期待，再次往后推了一整年。

更值得注意的是，这并不是很多人想象中的那种 AR 眼镜。它没有透明显示屏，不负责把数字信息直接叠到现实世界里，而是一副更轻量、也更务实的 AI 眼镜，路线更接近已经上市并跑通市场的 Ray-Ban Meta。

它的工作方式其实不难理解：靠摄像头“看”，靠麦克风“听”，靠扬声器“说”，再把拍照、接电话、放音乐、导航、识别眼前事物这些能力，交给一套更聪明的 Siri 来调度。

问题在于，这件事听上去简单，真做起来却一点都不轻松。

眼镜是直接挂在脸上的设备，重量、续航、散热没有一项能糊弄。稍微处理不好，要么压鼻梁，要么烫耳朵，要么撑不过两小时就没电。摄像头怎么摆才能兼顾视角和隐蔽性，扬声器怎么做到通话清晰又不明显漏音，这些都属于苹果最擅长、但也最耗时间打磨的硬骨头。

但这次跳票，硬件恐怕还不是最核心的原因。

真正拖后腿的，还是 AI，准确说，是 Siri 还带不动这副眼镜。

苹果这两年大力推进 Apple Intelligence，可实际体验大家并不陌生：复杂一点的对话容易卡壳，多轮上下文理解经常断片，视觉识别也还没成熟到让人放心把大量日常交互交给它。对于手机来说，这顶多意味着体验不稳定；可对于一副几乎完全靠语音和感知驱动的 AI 眼镜来说，这会直接决定产品是不是成立。

如果 AI 做不到随叫随到、看得懂世界、也能流畅交流，那这副眼镜最后很可能只会沦为一台更贵的运动相机，或者一个会弹通知的蓝牙耳机。苹果显然不愿意让这样的半成品仓促上市。它宁可延期，也不想先把东西推出去，再让用户替自己补课。

所以这次延期，其实也等于变相承认：Apple Intelligence 的补课还没有结束。

问题是，市场未必会一直等苹果。

从 2023 年开始，AI 眼镜这条赛道已经明显提速。Meta 和雷朋合作的 Ray-Ban Meta 不只是出了第二代，更重要的是，它已经提前教育了一批用户开始习惯“戴着眼镜拍照、直播、呼叫 AI 助手”。国内厂商也没闲着，Rokid 等玩家围绕翻译、支付、提词、会议记录这些更接地气的功能，把产品快速推向市场。哪怕产品还不完美，它们至少先占住了场景，也换回了真实反馈。

如果苹果要到 2027 年底才把产品端出来，别人很可能已经又跑完一到两个完整周期。届时更成熟的不只是硬件本身，还包括软件生态、用户心智和供应链节奏。

苹果当然有自己的打法。过去很多品类都是这样：先让别人探路，等技术、生态和成本都差不多成熟，再用一款体验完成度更高的产品进场，一锤定音。iPod、iPhone、AirPods 都是这么赢的。

可 AI 眼镜和当年的智能手机、无线耳机不太一样。这个市场的窗口期更短，迭代速度更快，大家几乎是在按季度往前冲，没有谁会站在原地等苹果慢慢打磨。等苹果真正入场时，面对的可能已经不是一片蓝海，而是一个格局初步成形、用户习惯已经被别人提前拿走的成熟市场。

这也是这次跳票真正值得注意的地方：它暴露出的不只是苹果硬件节奏变慢，而是 AI 能力本身，尤其是 Siri，还没有准备好承接下一代可穿戴入口。

苹果的底牌当然还在。它依然拥有极强的品牌号召力，也有从芯片到系统再到生态链的完整控制力。但在 AI 眼镜这件事上，苹果这次面对的，不再只是“晚一点也没关系”的传统节奏，而是一个正在高速抢位的新入口。

说到底，AI 眼镜能不能成立，核心不在镜框，而在大脑。现在看，苹果的镜框还没来，真正没准备好的，可能是 Siri。

世界模型第一次有了“存档”？VAST 想用 Project Eden 重写生成式世界的底层逻辑

过去一年，世界模型成了 AI 圈最热的词之一。

很多团队都在说，模型已经不只是会生成视频，而是在朝“生成世界”迈进：一句话可以换来一段连续画面，一个动作或镜头也能触发人物、场景和物体的连贯变化。问题在于，今天大多数被冠以世界模型之名的方案，本质上仍然更像“会动的视频”，而不是真正可以持续存在、被改变、被多人进入的世界。

VAST 最新发布的 Project Eden，想解决的正是这个根问题。它没有继续沿着“下一帧预测”往前卷，而是试图把世界状态推演和视觉呈现原生解耦，让模型先维护一个持续演化的底层世界，再根据视角、动作和交互需求把它渲染成画面。

主流世界模型，为什么更像“视频”而不是“世界”

要理解 Project Eden，先要看清行业里两条主流路径。

第一类是动作条件视频生成。它根据文本、图像、动作指令或相机轨迹生成一段连续视频，优势是演示直观、交互感强，也最容易让用户产生“世界在响应我”的感觉。但问题也很明显：模型预测的仍然是 2D 像素轨迹，世界里到底有什么、物体在哪里、状态怎么变化，往往都被隐式压缩在最近几帧画面中。一旦物体离开视野，模型并没有一个独立的世界状态去保存它，镜头转回时只能根据上下文重新“幻想”。

第二类是静态 3D 场景生成。相比视频生成，它确实更接近“空间”本身，但如果只有静态空间，没有时间维度、物理逻辑和状态转移机制，它依然很难被称为真正的世界模型。一个真正有用的世界，不只是能被看见，还应该能被改变、持续运行，并支持多个用户或多个智能体同时进入。

VAST 的判断很直接：一套合格的世界模型，至少要同时解决两个问题——世界当下的客观状态是什么，以及这个状态如何随着动作、时间和交互持续演化。只有同时具备这两点，世界模型才可能从“生成内容”走向“生成环境”。

Project Eden 真正的新意：先有世界，再有画面

Project Eden 最关键的架构选择，是把“世界本身”和“世界看起来的样子”拆开。

它的第一层是结构化状态层，负责维护一个跨时间持续存在、可被动作更新、可被任意相机位置查询的全局世界状态。这不是一个昂贵的 4D 点云，而是一种更紧凑、兼顾效率和语义丰富度的隐式表征，用来回答“世界里有什么、发生了什么”。

第二层是条件接口层，把底层的全局世界状态转换成适合特定视角使用的局部条件，包括语义信息、几何线索和事件变化。不同玩家看到的不是彼此独立的视频历史，而是同一个世界在不同位置上的不同窗口。

第三层是生成式渲染层。它不再承担完整的世界逻辑推演任务，而是在底层状态与中间条件的约束下，补全纹理、光照、材质和高频动态细节，生成最终画面。这样一来，模型解决问题的方式就从“预测下一帧”改写成了“先推演下一刻的世界状态，再从这个状态渲染当前画面”。前者更像视频续写，后者才更接近世界模拟。

这套架构，直接换来了三种系统级能力

最直观的一项，是环境长程持久化。

在 Project Eden 里，物体离开视野，并不意味着它从世界里消失。它依然存在于底层状态中，并继续按照世界逻辑运转。当用户转身离开再回来时，系统查询的还是同一个世界状态，而不是根据历史视频帧重新拼接一个相似画面。世界第一次有了接近“存档”的感觉。

第二项能力，是场景自由复用与确定性控制。传统视频生成是一条一次性的时间线：生成过了就固定了，难以回退，也难以分支。但在解耦架构里，底层状态是可以被读写和干预的。用户造成的破坏、建造与修改，可以被真实写入世界；后续进入同一场景的其他用户，也会看到一致的结果。内容形态因此从一次性视频，变成了可编辑、可复用、可持续运营的互动空间。

第三项能力，是原生多人和多智能体并发。传统视频世界模型最怕的就是多人同时在线，因为每个玩家都有自己的视角、动作和上下文，一旦每一路都依赖独立的视频历史来生成，算力和一致性就会迅速失控。而在 Project Eden 里，底层状态只有一份，被所有智能体共享；渲染层只需根据各自位置和视角生成画面。这不只是性能优化，更是商业落地的前提。

难点不只在架构，更在数据

Project Eden 背后的数据策略，同样是这套方案能否成立的关键。

VAST 提出了一套分层数据思路，核心是“双态对齐数据”：既包含底层推演态，也包含视觉渲染态。围绕这个目标，他们在数据端部署了两层策略。

L1 是海量互联网视频自标注。VAST 依托自身 3D 基础模型能力，对无标注 2D 视频做反向解构，提取深度、相机位姿和几何轨迹，把单态视频尽量提炼为双态数据。这一层的价值在于覆盖广度和真实世界泛化。

L2 是引擎合成数据。游戏引擎天然具备世界状态和渲染结果同步存在的特点，可以低成本批量生成带有精确 3D 状态标注、动作指令和环境变化的数据。这一层的价值在于逻辑精度与可控性。

这种“互联网数据泛化 + 引擎数据精准化”的组合，说明 VAST 想做的并不是一个只靠 demo 出圈的视频模型，而是一套更接近底层系统的世界生成方案。

Project Eden 更大的想象空间，不只是生成内容

如果只把 Project Eden 看成一个更强的 3D 生成工具，其实低估了它。

它更大的意义，在于有机会成为下一代互动内容的底层基础设施。过去一个可玩、可交互、可多人进入的世界，通常需要美术、建模、动画、关卡、物理引擎和网络同步等复杂流程来搭建。生成式 AI 已经把 3D 资产生产的门槛压低了很多，但“生成一个模型”和“生成一个能持续运行的世界”之间，仍然隔着很大一段距离。Project Eden 想补的，就是这段距离。

从更长远的角度看，它的潜力也不止于内容生产。因为它维护的是稳定的底层世界状态，而不是一次性视频画面，这让它天然适合作为智能体活动的环境底座。对智能体来说，关键从来不只是看到逼真的画面，而是环境能否按一致规则响应动作、保留变化并持续演化。

所以，Project Eden 的价值不只是把 3D 生成推进到交互内容阶段，更在于为世界规则学习、仿真模拟、具身智能和多智能体协同提供一个可以被反复进入、持续实验的环境。

结尾

如果只看表面，Project Eden 像是在做一个更强的 3D 世界生成模型。但更值得关注的，是它把世界模型的问题重新写了一遍：不是继续预测画面，而是先维护世界本身。

一旦这条路线成立，世界模型就不再只是“把视频做得更真”，而是第一次真正有机会从内容生成走向环境生成。从这个意义上说，Project Eden 最值得关注的地方，不是它又做出了一个惊艳 demo，而是它让世界模型第一次更像“世界”，而不只是“视频”。

大模型幻觉彻底复盘：根源、分类与全域规避方案深度汇总

在大模型工程落地中，幻觉问题始终是影响输出准确性、稳定性和可用性的核心障碍。很多人知道模型会“编造内容”，但真正难的是：为什么会编？编错的类型有哪些？又该如何从工程链路上系统性压低出错概率？

如果只把幻觉理解为“模型偶尔答错”，就很容易陷入头痛医头、脚痛医脚的修补方式。实际上，幻觉并不是单一缺陷，而是大模型生成机制、知识边界、推理方式和系统设计共同作用的结果。

本文从底层原理出发，把大模型幻觉的本质、分类以及工业级规避方案完整梳理清楚，帮助你建立一套从参数、Prompt、推理、RAG、微调到后置校验的全链路治理框架。

一、大模型幻觉的底层本质是什么

大模型的核心生成逻辑，并不是“求真优先”，而是“概率优先、通顺优先”。

它不会像人类一样先判断信息真假，再决定是否回答；也不具备真正意义上的现实认知能力。模型所做的，本质上是基于预训练阶段学到的大规模语义分布，持续预测“下一个最可能出现的 token”。

也正因为如此，大模型最天然擅长的是：

• 生成通顺文本；
• 保持语义连贯；
• 模拟合理表达；
• 在不完整信息下补足语言结构。

这套能力在很多场景下非常强大，甚至会体现出推理、泛化和举一反三的涌现能力。但同样的机制，也带来了一个副作用：当知识不足、条件模糊、上下文缺失或逻辑复杂时，模型会倾向于自动补全内容，而不是主动停下来承认“不知道”。

于是，幻觉就产生了。

从工程角度看，可以用一句话概括它的本质：

通顺是模型的本能，真实需要外部约束，幻觉则是通用生成能力的天然副作用。

二、幻觉为什么不可避免

很多人会问：既然幻觉这么麻烦，能不能彻底消灭？

答案通常是否定的。

因为只要模型仍然基于概率生成，它就不可能天然等同于事实数据库、逻辑证明器或规则引擎。它能做的是在大多数情况下“看起来合理”，但不能天然保证“始终绝对正确”。

这意味着：

• 幻觉不能被完全消除；
• 但可以通过系统工程手段持续压低；
• 压低到足够低之后，才能满足生产环境要求。

所以，真正成熟的思路不是追求“零幻觉神话”，而是建立一套分层治理体系，把不同类型的错误分别压制。

三、两大核心幻觉分类：知识型与逻辑型

从工程实践看，大模型幻觉并不是一锅粥。绝大多数问题，都可以归到两类里：知识型幻觉和逻辑型幻觉。

这两类问题成因不同，因此解决路径也完全不同。

1. 知识型幻觉：事实层面的造假或失真

知识型幻觉，指的是模型输出了错误、虚构、过时或根本不存在的事实性内容。

典型表现包括：

• 虚构数据；
• 编造论文、文献、作者；
• 杜撰接口参数；
• 捏造企业制度；
• 输出已经过期的规则；
• 生成不存在的专业结论。

它的根源通常不在“不会说”，而在“没有真实知识依据”。

因为模型的知识主要冻结在训练集截止时间，既不天然拥有实时世界信息，也不天然懂企业内部私有资料。当问题落到知识盲区时，模型又倾向于继续完成回答，于是就会用泛化能力去“脑补”。

2. 逻辑型幻觉：推理链条本身出错

逻辑型幻觉则不同。

它不是因为缺少素材，而是即便素材本身没错，模型在分析、推导和归纳过程中仍然走错了。

典型表现包括：

• 跳步推理；
• 因果倒置；
• 条件判断错误；
• 数值计算失误；
• 前后逻辑矛盾；
• 论证链条断裂；
• 分析结论偏离前提。

这类问题常见于复杂分析、多条件判断、长链推理和需要精确逻辑闭环的任务中。

它的本质原因是：模型往往倾向于一步生成答案，而不是天然按严格的中间步骤展开推导。

所以，知识型幻觉主要是“材料不对”，逻辑型幻觉主要是“推导不对”。

四、为什么单一技巧无法解决幻觉

很多团队在处理幻觉时，会尝试一种“单点修复”的方法，比如：

• 只改 Prompt；
• 只调温度；
• 只做 RAG；
• 只做微调；
• 只做输出校验。

这些方法都有效，但都不够完整。

原因很简单：不同幻觉发生在不同层级。

• 随机发散造成的问题，更适合从参数层治理；
• 回答边界失控的问题，更适合从 Prompt 层治理；
• 推理链条错误，更适合从思维链范式治理；
• 知识缺失，更适合用 RAG 补齐；
• 长期高频稳定性问题，更适合用微调固化；
• 最终生产兜底，则必须依赖规则校验。

因此，真正有效的方法不是单招制胜，而是建立一套六层工业级防幻觉体系。

五、六层工业级防幻觉完整体系

1. 参数层约束：先把随机发散压下来

参数调优是最底层、也是最容易被忽视的一层。

如果模型在生成时随机性过强，就更容易出现无依据扩写、自由联想和低概率错误内容。因此，在准确性优先的任务里，应该优先收敛生成空间。

常见做法包括：

• 降低 Temperature：减少创造性发散，优先输出更高概率、更稳定的结果；
• 收紧 Top_p：缩小候选 token 池，过滤低概率离谱词汇；
• 适度使用重复惩罚：减少无效拼接和混乱复述。

对于知识问答、数据抽取、代码生成、结构化输出等任务，参数稳控往往是第一道防线。

它不能解决所有幻觉，但可以显著降低“随机性幻觉”的发生频率。

2. Prompt 层约束：规范模型回答边界

很多幻觉并不是模型完全不知道，而是模型没有被明确告知：不知道时该停下来，不能硬编。

所以，Prompt 层的重点是给模型建立清晰的行为边界。

高质量 Prompt 通常会包含：

• 诚实性约束：不知道就明确说明，不允许主观杜撰；
• 范围约束：只回答给定范围，不随意发散；
• 格式约束：按预设结构输出，减少混乱表达；
• 示例对齐：用 Few-Shot 让模型学习目标答案范式。

Prompt 工程的价值，不只是“让输出更好看”，更重要的是减少模型擅自扩写、擅自补全、擅自猜测的空间。

3. 推理范式优化：专门压制逻辑型幻觉

对于复杂推理任务，如果仍然让模型直接一步出结论，逻辑型幻觉就很难避免。

这时，需要引入更严格的推理范式，比如 CoT（Chain of Thought，思维链）。

核心思路是让模型：

• 先拆解问题；
• 再逐步分析条件；
• 明确中间推导过程；
• 最后给出结论。

这样做的意义在于，把原本隐藏在内部的一步推理，展开为更可控的多步链条。

当中间步骤被显式化后，跳步、遗漏条件、因果混淆等问题就更容易被压制，也更方便后续人工检查或程序校验。

4. RAG 检索增强：从根上解决知识型幻觉

如果模型不知道事实，仅靠提示词约束它“别编”，效果通常有限。因为模型就算不想编，也没有足够依据去答。

这时最有效的方法就是 RAG。

RAG 的核心价值在于：

• 给模型补充真实资料；
• 把最新信息接入上下文；
• 让私有业务知识进入推理链路；
• 让答案建立在可溯源文档上。

对于企业知识库、私有文档问答、FAQ、产品规则、制度解释等场景，RAG 是目前治理知识型幻觉的最优工程方案之一。

它解决的不是“模型说话方式”，而是“模型回答时到底依据什么知识”。

5. 模型微调：固化长期稳定的严谨行为

RAG 很适合补知识，但对于一些高频、固定、长期运行的业务场景，仅靠外部检索和 Prompt 有时还不够。

例如：

• 行业固定话术；
• 标准化输出口径；
• 高重复率任务流程；
• 稳定不变的结构模板；
• 某些长期需要纠偏的认知习惯。

这时，微调的价值就体现出来了。

微调不是为了让模型知道所有新事实，而是为了让它在长期行为上：

• 更符合业务风格；
• 更稳定遵守输出范式；
• 更少出现已知类型错误；
• 更少依赖超长 Prompt 才能保持一致。

也就是说，微调更适合处理“长期稳定性”问题，而不是替代 RAG 去承接实时知识更新。

6. 规则后置校验：生产环境的最终兜底

即便前面五层都做了，也不能假设模型永远不会出错。

所以，面向生产环境，最后必须加上规则后置校验。

常见做法包括：

• 字段完整性校验；
• 数据范围校验；
• 格式合规校验；
• 黑名单与异常模式拦截；
• 自我反思与二次重跑；
• 多模型交叉校验；
• 程序规则与业务规则联合兜底。

这一层的意义在于：即使模型犯错，系统也要尽量在结果真正落地之前把错误拦住。

在高风险业务里，后置校验不是可选项，而是上线门槛。

六、不同场景下的最优组合怎么选

实际工程里，防幻觉从来不是“一套模板打天下”。更合理的方式是按任务类型组合方案。

1. 通用问答、知识科普

推荐组合：

• 低温参数；
• 诚实型 Prompt 约束；
• 必要时补充引用来源。

目标是减少自由发挥，让模型在不知道时愿意承认边界。

2. 结构化输出、数据抽取、代码生成

推荐组合：

• 保守参数；
• 强格式约束；
• 输出后程序校验。

重点是把回答从“自然语言开放生成”收敛成“可验证结果生成”。

3. 逻辑计算、复杂分析、多条件推理

推荐组合：

• CoT 思维链；
• 低温或中低温参数；
• 必要时拆任务分步执行。

这里的关键是控制推理过程，而不是只盯最终结论。

4. 企业私有业务、知识库问答、文档解析

推荐组合：

• RAG 检索增强；
• 标准化 Prompt；
• 后置规则校验。

这类场景最重要的是“依据真实资料作答”，否则知识型幻觉几乎不可避免。

5. 垂直行业固定业务

推荐组合：

• RAG 负责动态知识更新；
• 微调负责长期风格与范式固化；
• 再叠加业务规则校验。

这是很多成熟企业应用最终会走向的组合方式。

七、全文总结：治理幻觉，本质上是在做系统工程

大模型幻觉并不是一个可以靠单一技巧彻底消灭的问题。

它更像是一个系统性风险，需要你从多个层级分别治理：

• 知识幻觉：靠外部检索补全；
• 逻辑幻觉：靠推理范式约束；
• 随机幻觉：靠采样参数收敛；
• 边界失控：靠 Prompt 标准化；
• 长期不稳定：靠模型微调固化；
• 生产风险兜底：靠规则后置校验。

真正成熟的大模型落地能力，不只是“会调用模型”，而是知道如何把模型放进一整套可控、可验证、可维护的工程链路里。

从神经网络基础、生成机制、涌现能力，到 Prompt 工程、参数调优、RAG 架构、模型微调和全链路治理，只有把这些能力真正串起来，才能完成从“会用 AI”到“能落地 AI”的跨越。

而防幻觉，正是这条工程闭环里最关键的一环。

RAG通俗详解：为什么它是企业大模型落地的首选方案？

在大模型工程落地中，我们已经掌握了 Prompt 工程优化、模型参数调优、结构化输出约束、幻觉规避和微调等核心能力。但一旦进入真实企业场景，很多团队很快会遇到两个绕不过去的问题：模型知识会过时，模型也不懂企业自己的私有数据。

这正是 RAG（Retrieval-Augmented Generation，检索增强生成）成为主流方案的原因。它不要求模型把所有知识都“记在脑子里”，而是让模型在回答问题前，先去检索与当前问题最相关的真实资料，再基于资料生成结果。

从工程视角看，RAG 本质上是把大模型从“通用对话能力”升级为“可接企业知识、可接业务规则、可接实时信息”的生产力组件。本文用通俗但工程化的方式，把 RAG 为什么重要、它解决了什么问题、它与 Prompt 和微调是什么关系，彻底讲清楚。

一、为什么传统大模型很难直接满足企业业务

原生大模型很强，但它天然不是为企业私有业务直接设计的。即使提示词写得再好、微调做得再细，也很难彻底绕开两个底层缺陷。

1. 知识时效性有限

模型的知识主要来自训练阶段看到的数据，而训练数据总有截止时间。也就是说，模型本身并不知道训练完成之后发生的新政策、新流程、新产品说明或最新业务规则。

这会带来一个非常现实的问题：模型看起来很会说，但它说的可能不是今天仍然有效的内容。

在企业场景里，这种过时并不是小问题。比如：

• 最新制度已经更新，但模型仍按旧版本回答；
• 产品参数迭代了，但模型引用的是旧规格；
• 客服口径变了，但模型仍然沿用历史说法。

如果没有外部知识补充，模型就很容易出现“回答流畅但依据陈旧”的情况。

2. 无法天然理解企业私有数据

大模型没有见过企业内部文档、项目资料、操作手册、产品知识库和业务流程文件。它擅长通用知识，但并不天然懂你的组织内部规则。

这意味着，当用户提问涉及企业专属信息时，模型通常只能靠泛化能力猜。

很多团队会尝试两种补救方式：

• 把大量背景信息直接塞进 Prompt；
• 用私有数据做模型微调。

但这两种方法各有明显代价。

前者会导致上下文越来越长，Token 成本快速上升，输出稳定性也会下降；后者则意味着更高的数据准备成本、更长的训练周期，以及更慢的迭代速度。

归根结底，传统大模型的问题可以概括为一句话：懂通识，但不懂实时；会表达，但不懂你的业务。

二、RAG 到底是什么：一句话先讲明白

RAG 的全称是 Retrieval-Augmented Generation，中文通常叫检索增强生成。

它的核心思想其实很简单：

不要强行让模型死记硬背所有知识，而是让模型在回答前先查资料，再根据查到的真实内容生成答案。

所以，RAG 不是在“改造模型的大脑”，而是在“给模型配一个实时可查的外部知识系统”。

如果要用最直白的话区分三种常见方案：

• Prompt 工程：靠指令约束模型怎么回答；
• 模型微调：靠训练改变模型默认行为；
• RAG：靠实时检索给模型提供当下最相关的真实资料。

这也是为什么 RAG 特别适合企业落地：它正好补上了模型在知识新鲜度和私有知识接入上的短板。

三、RAG 的核心工作原理

一个典型的 RAG 系统，通常可以拆成两个核心模块：检索模块和生成模块。

1. 检索模块：先找到最相关的资料

在系统准备阶段，企业会把自己的知识文档、业务手册、FAQ、制度文件、产品说明、接口文档等内容进行处理：

• 文档切片；
• 文本清洗；
• 向量化编码；
• 存入向量数据库或混合检索系统。

当用户发起问题时，系统不会直接把问题丢给大模型，而是先做一次检索：从知识库里找出与问题最相关的若干段内容。

这一步的目标不是“把所有资料都给模型”，而是把真正有用、真正相关、真正能支撑答案的上下文筛出来。

2. 生成模块：基于资料作答，而不是凭空脑补

检索到相关资料后，系统再把这些资料连同标准化 Prompt 一起交给大模型。

此时模型的任务不是凭自身记忆自由发挥，而是：

• 理解问题；
• 阅读检索结果；
• 按要求组织答案；
• 尽量基于已提供资料输出内容。

也就是说，RAG 的关键价值不只是“查到了东西”，而是让模型的生成过程建立在可验证的上下文之上。

如果把它类比为工作方式，传统模型像一个不查资料就直接回答的人，而 RAG 更像一个会先翻文档、再给结论的专业助理。

四、RAG 为什么能成为企业大模型落地首选

RAG 之所以在企业里被大规模采用，不是因为它概念新，而是因为它对真实工程问题确实有效。

1. 能显著降低幻觉

大模型的幻觉，本质上是“在没有足够依据时仍然试图完整回答”。

RAG 的作用是为模型提供可依赖的外部证据。只要检索链路和知识库质量足够好，模型就不必完全依赖自身泛化记忆，而是可以围绕真实文档组织答案。

这会显著减少以下问题：

• 杜撰不存在的业务规则；
• 编造错误数据；
• 混淆版本；
• 把通用经验误当成企业事实。

虽然 RAG 不能从理论上保证“百分之百无幻觉”，但它确实是当前最有效、最工程化的降幻觉手段之一。

2. 支持知识实时更新

企业知识是持续变化的。

产品会变，制度会变，FAQ 会变，业务口径会变，监管要求也会变。如果每次变化都依赖重新微调模型，系统迭代成本会非常高。

RAG 的优势在于：模型本身可以不变，只更新知识库即可。

这意味着：

• 新文档可以快速入库；
• 旧文档可以随时替换；
• 规则更新无需重新训练模型；
• 业务响应速度远快于微调方案。

对于需要高频更新的企业场景，这一点几乎是决定性的。

3. 低成本接入私有业务知识

微调要准备训练样本、跑训练流程、做效果评估，还要承担训练失败或收益不明显的风险。

而 RAG 的接入路径通常更轻：

• 把已有文档整理好；
• 建立切片与检索流程；
• 接上向量库或混合检索；
• 与大模型推理链路集成。

对于多数知识密集型场景，企业更容易拥有文档，却不一定更容易拥有高质量训练数据。因此，RAG 往往比微调更容易启动，也更容易快速看到业务价值。

4. 节省上下文与推理成本

如果把全部业务规则、手册内容、产品说明都塞进 Prompt，不仅 Token 很贵，还会降低上下文利用效率。

RAG 的思路是只把“本次问题真正需要的资料”送入上下文。这样可以：

• 减少无关信息干扰；
• 降低 Token 消耗；
• 提升模型聚焦能力；
• 提高答案稳定性。

从系统设计角度看，这是一种更优雅、也更可扩展的信息供给方式。

五、RAG、Prompt、微调到底是什么关系

很多人在学习大模型工程时，会误以为三者是替代关系。但从工业落地角度看，它们更像是三个不同层级的能力组件。

1. Prompt 工程属于推理层

Prompt 负责解决的是“怎么让模型按要求回答”。

它关注的是：

• 语气和角色；
• 输出格式；
• 任务边界；
• 推理步骤约束；
• 安全与合规表达。

它解决的是输出不要乱的问题。

2. RAG 属于数据层

RAG 负责解决的是“模型回答时依据什么知识”。

它关注的是：

• 私有知识接入；
• 实时信息补充；
• 检索相关性；
• 文档可追溯性；
• 外部知识与当前问题的匹配效率。

它解决的是输出要有依据、内容要准确的问题。

3. 微调属于参数层

微调负责解决的是“模型长期默认行为怎么固化”。

它关注的是：

• 某种稳定风格；
• 某类固定范式；
• 高重复场景的统一口径；
• 特定任务模式的长期沉淀。

它解决的是长期稳定、一致性和默认倾向的问题。

因此，企业最优方案往往不是只选一个，而是：

Prompt 标准化 + RAG 架构 + 少量必要微调。

这套组合兼顾了：

• 低成本；
• 高精度；
• 快迭代；
• 强稳定；
• 可扩展。

六、RAG 的优势、局限与典型适用场景

核心优势

RAG 之所以流行，主要因为它同时具备以下几个工程优势：

• 落地成本相对较低，不必先做大规模训练；
• 能明显改善模型幻觉问题；
• 支持知识库持续更新；
• 特别适合垂直行业和企业私有场景；
• 具备较好的可追溯性，便于解释答案来源。

主要局限

当然，RAG 也不是万能的。

它的效果非常依赖前面的检索质量。如果文档切片差、召回不准、排序不稳，模型即使生成能力再强，也可能基于错误资料得出偏差答案。

此外，RAG 更擅长补知识，不擅长彻底改变模型本身的推理上限和语言风格。也就是说，它能让模型“知道该参考什么”，但不一定能让模型“天生更会思考”。

典型适用场景

RAG 几乎适用于绝大多数企业知识型 AI 场景，例如：

• 企业知识库问答；
• 内部智能客服；
• 私有文档解析；
• 业务手册查询；
• 行业垂直咨询；
• 实时政策与信息问答；
• 内部系统帮助中心；
• 项目资料辅助检索与总结。

只要问题答案主要来自“已有资料”，而不是纯创造性生成，RAG 往往就是优先级极高的方案。

七、结语：RAG 是企业把大模型真正用起来的关键一步

如果说 Prompt 工程是在驯服模型，微调是在重塑模型，那么 RAG 更像是在赋能模型。

它让模型不再只是一个会聊天、会写作、会泛化推理的通用助手，而是开始具备接入企业知识、服务业务流程、回答真实问题的能力。

这也是为什么在当下企业大模型落地实践中，RAG 会成为最主流的技术架构之一。它用相对低的成本，解决了最关键的知识问题，让 AI 从“能演示”真正走向“能生产”。

如果你正在构建企业级大模型应用，那么对 Prompt、RAG 和微调三者的分层理解，几乎就是工程落地能力的核心分水岭。而在这三者里，RAG 往往是最先释放真实业务价值的那个组件。

大模型微调 vs 提示词工程：落地选型终极对比

在大模型落地项目中，开发者几乎都会遇到同一个核心问题：如果想让 AI 效果更好，到底应该优先做 Prompt 工程，还是直接上模型微调？

这个问题之所以容易让人困惑，是因为很多新手会走向两个极端：

• 要么把所有问题都寄希望于提示词，效果不理想就束手无策；
• 要么一上来就想着微调，结果耗费大量数据、算力和时间，提升却并不明显。

事实上，Prompt 工程和模型微调根本不是同一个层级的优化手段。它们的成本结构、适用问题、上线速度和长期维护方式都完全不同。

本文从工程落地视角，把两者的本质区别、优劣、适用边界和组合方案讲清楚，帮助你真正建立一套可落地的选型逻辑。

先搞懂：二者解决的问题根本不是一类

Prompt 工程属于推理层优化。

它不改变模型参数、不进行训练，也不更新权重，而是通过改写输入指令、提供样例、约束输出格式、调节采样参数等方式，尽量激发模型已有能力。

它更像是一种“外部调控”。模型本身不变，但你通过更合理的输入方式，让它表现得更好。

模型微调则属于模型层优化。

它是在预训练大模型的基础上，用你的私有数据继续训练模型，让模型的内部参数发生变化，从而更稳定地适配你的业务知识、风格或任务模式。

如果用一句最通俗的话概括：

• Prompt 工程是在教模型“这次该怎么说、怎么做”；
• 模型微调是在改变模型“以后默认会怎么说、怎么做”。

前者偏临时指挥，后者偏长期固化。

Prompt 工程：为什么它永远是第一选择

在绝大多数项目初期，Prompt 工程几乎都是首选方案。

原因很简单：它便宜、快、灵活，而且往往已经足够好用。

Prompt 工程的核心优势

1. 成本极低

你不需要训练集，不需要 GPU，也不需要等待训练完成。很多时候，只需要修改几段提示词、增加几个示例，或者补充输出规则，就能直接验证新效果。

2. 迭代速度极快

Prompt 的优势在于“即时生效”。

• 今天发现结果不稳定，可以马上改；
• 今天业务规则变了，可以马上补；
• 今天换了场景，可以马上适配。

它特别适合试错频繁、需求变化快的场景。

3. 通用性非常强

同一个基础模型，借助 Prompt 工程可以很快切换到不同任务：

• 问答
• 总结
• 改写
• 文案
• 提取
• 翻译
• 结构化输出

这意味着你不必为每个任务都准备一套训练流程。

4. 不容易“学坏”

因为 Prompt 工程本身不改模型权重，所以它不会带来经典训练问题，比如过拟合、灾难性遗忘或能力退化。

Prompt 工程的核心局限

但 Prompt 工程并不是万能的。

1. 它依赖模型原生上限

如果模型本身就不具备某项能力，仅靠提示词通常无法从根本上补出来。

比如：

• 模型本来就缺某个垂直行业知识；
• 模型对某类极窄任务理解能力不足；
• 模型对高度固定口径的风格始终不稳定。

这种情况下，你再怎么写 Prompt，也可能只能小修小补。

2. 对复杂个性化业务不够彻底

很多业务不是“让模型懂”，而是“让模型永远按统一方式输出”。

如果每次都要在上下文里重复一大堆：

• 专业术语口径；
• 品牌语气规范；
• 固定输出模板；
• 特定业务逻辑；

那么 Prompt 会越来越长，也越来越不稳定。

3. 上下文成本会不断上升

规则越多、样例越多、约束越复杂，Prompt 带来的 token 消耗就越高。

在高频调用场景里，这不仅影响成本，也会影响响应速度与稳定性。

Prompt 工程最适合什么场景

通常来说，以下场景优先考虑 Prompt 工程：

• 日常问答与内容创作；
• 文本处理、分类、总结、提取；
• 通用推理任务；
• 原型验证与快速上线；
• 低频、多变、试错型业务；
• 暂时没有高质量训练数据的项目。

模型微调：什么时候它才真正值得做

微调的价值在于“固化”。

如果 Prompt 工程是在当前调用时引导模型，那微调就是直接改变模型的长期行为倾向。

模型微调的核心优势

1. 能力可以被长期固化

当你希望模型持续适配某种：

• 行业知识；
• 输出风格；
• 业务流程；
• 专用任务逻辑；

微调会比每次写很长 Prompt 更自然、更稳定。

2. 输出一致性更强

Prompt 工程常常会受到上下文、样例、措辞和模型波动影响，而微调可以把很多规则“写进模型倾向”里，使结果更统一。

这对于客服、审核、固定报告生成、标准化文案等场景尤其重要。

3. 节省上下文成本

如果某些规则是长期固定的，微调后就不必每次重复携带。

这意味着：

• token 成本降低；
• 提示词更短；
• 调用链更轻；
• 大规模生产调用更划算。

4. 能补齐垂直业务能力

很多行业场景对口径要求极窄：

• 法务术语；
• 医疗表达；
• 金融风控话术；
• 企业内部专属知识；
• 特定格式化输出模板。

如果这些内容在基础模型里覆盖不足，微调往往更有效。

模型微调的核心局限

1. 成本高

微调不是“点一下按钮就完成”的事情，它通常需要：

• 高质量训练数据；
• 清洗与标注流程；
• GPU 资源；
• 训练与验证时间；
• 上线后的回归测试。

因此它天然适合更严肃、更长期的项目，而不适合轻量试错。

2. 迭代速度慢

Prompt 改一下就能上线，但微调要重新准备数据、重新训练、重新评估。

如果业务口径经常变、规则每周都在调，微调的维护成本会变得非常高。

3. 存在训练风险

微调不是只会带来收益，也可能带来副作用：

• 过拟合；
• 任务能力退化；
• 灾难性遗忘；
• 原有通用能力被削弱。

这意味着它必须建立在较成熟的数据与评估体系之上。

模型微调最适合什么场景

以下情况通常更适合考虑微调：

• 垂直行业知识密度高；
• 长期固定的话术或输出结构；
• 高频重复型业务；
• 明确存在统一专业口径要求；
• 基础模型原生能力不足；
• Prompt 已经优化到上限仍不达标；
• 每次都要塞大量规则，token 成本过高。

工业级选型标准：到底什么时候选谁

在真实项目里，最重要的不是理解概念，而是知道如何判断。

优先只用 Prompt 工程的情况

当项目满足以下特点时，通常先不要急着微调：

• 任务通用，规则不算复杂；
• 业务变化快，迭代频繁；
• 没有足够高质量训练数据；
• 需要快速上线、快速试错；
• 场景多但调用频率不高；
• 更多是在探索，而不是固化。

这类场景里，Prompt 工程往往已经是最优解。

必须认真考虑微调的情况

如果出现以下信号，就说明你可能真的需要微调：

• 业务范式高度固定，且长期不变；
• 已经有大量高质量私有标注数据；
• 输出风格必须高度统一；
• Prompt 无论怎么优化都达不到要求；
• 每次携带规则太长，成本过高；
• 对稳定性、一致性要求明显高于灵活性。

这时候继续死磕 Prompt，往往只会越来越复杂，收益却越来越低。

企业级最优解：Prompt + 微调混合架构

真正成熟的 AI 落地项目，通常不会只押注一种方案。

最常见、也最稳妥的做法，其实是混合架构：

• 微调负责固化能力；
• Prompt 负责动态控制。

也就是说：

微调层负责

• 行业知识沉淀；
• 固定业务风格；
• 标准化输出结构；
• 长期不变的任务逻辑。

Prompt 层负责

• 当前任务约束；
• 临时规则调整；
• 风格细粒度控制；
• 实时纠错与边界限制；
• 防幻觉与格式校验。

这种方案的优势非常明显：

• 比纯 Prompt 更稳；
• 比纯微调更灵活；
• 能同时兼顾长期效果和短期迭代；
• 更适合企业环境下不断变化的业务需求。

所以从行业实践看，混合架构才是很多大模型系统真正的标准形态。

给新手的最终建议

如果你刚开始做大模型项目，最重要的不是急着选“最高级”的方案，而是按顺序做对。

第一阶段：先把 Prompt 工程吃透

对于绝大多数个人项目、小团队项目和早期业务验证来说，仅靠 Prompt 工程就足以解决 80% 到 90% 的问题。

先学会：

• 任务拆解；
• 样例设计；
• 输出格式控制；
• 参数调优；
• 幻觉约束；
• 规则兜底。

这些能力往往比盲目微调更有价值。

第二阶段：Prompt 到上限后，再考虑微调

只有当你已经明确知道：

• Prompt 再怎么优化都不够；
• 业务目标很稳定；
• 数据也足够支撑；

这时再做微调，才是高性价比路径。

第三阶段：长期项目用混合架构

如果项目进入持续运营阶段，稳定部分用微调固化，变化部分用 Prompt 管控，通常才是最合理的组合方式。

总结

Prompt 工程和模型微调不是谁替代谁的问题，而是两个层级完全不同的优化手段。

Prompt 工程的特点是：

• 成本低；
• 迭代快；
• 灵活度高；
• 适合快速落地和广泛适配。

模型微调的特点是：

• 稳定性更强；
• 专属能力更深；
• 能固化长期业务规则；
• 更适合垂直深耕和标准化生产场景。

真正成熟的选型逻辑，不是问“谁更强”，而是先判断：

• 当前问题属于推理层，还是模型层；
• 当前项目更需要灵活性，还是一致性；
• 当前阶段更适合快速试错，还是长期固化。

当你真正理解这套逻辑之后，你面对大模型落地项目时，就不会再陷入“只会写 Prompt”或者“上来就想微调”的两难困境。

因为你已经知道：

Prompt 和微调不是对立关系，而是分层协作、互补组合的工程能力。