第一节 起点
本节从 LLM（Large Language Model，大语言模型） 的本质讲起：它是什么、在算什么东西、为什么「大」会带来质变，以及这条技术线是怎么一步步走到今天的。有了这些，你再看 ChatGPT、Claude、API 文档里的「上下文长度」「Token 计费」就不会懵。
语言模型在干什么？
语言模型（Language Model，LM） 的核心任务只有一件事：在给定前面一段文字的前提下，预测「下一个词」最可能是什么。
比如，模型现在看到的是“今天天气很”，那么它就需要估计下一个位置出现『好』、『冷』、『怪』等词各自的概率。把它接在原文后面，再拿「原文 +新词」继续预测再下一个，如此往复，就是自回归生成——你看到的「AI一个字一个字蹦出来」，底层就是在反复做预测下一个词。
所以 LM 没有在「查数据库」或「背答案」，它是在用学到的统计规律，根据当前上下文猜下一个最像人写的 「词」是什么。能对话、能写代码、能翻译，都是在这一套「下一词预测」的基础上，通过不同的提示（Prompt）和训练方式「涌现」出来的能力。
Token：模型眼中的「最小单位」
事实上，模型不直接处理「字」或「词」，而是处理 Token。因为在计算机的底层世界里只有 0 和 1，我们输入或输出的「字」「词」最终都要变成数字，才能参与计算与存储；完成这件事的组件就叫 Tokenizer（分词器 / 词元化器）。
Tokenizer 负责两件事：
编码：把一段文字按某种规则切分成若干“片段”，再根据词表（Vocabulary）查出该“片段”对应的一个整数（即 token id），于是整段话变成一串数字；
解码：模型生成的一串 token id 再通过同一套词表反查，还原成人类可读的文字。
所以你看到的「AI 一个字一个字蹦出来」，在模型侧其实是「一个 token id 接一个 token id 地预测」，再由 Tokenizer 解码成字。不同模型用不同的 Tokenizer 和词表，同一句话在不同模型里切出的 token 数量、甚至切法都可能不一样，这也是为什么「同样一段中文，在 A 模型算 100 个 token、在 B 模型可能算 120 个」。
Token 是词表里的最小单位，可能对应整词（如「苹果」）、可能对应子词（如「苹」「果」分开），英文里常见把长词拆成子词（如 “unbelievable” → “un”, “believ”, “able”），这样词表不用无限大，也能通过组合处理没见过的词。这种「子词」切分方式（如 BPE、SentencePiece 等）被 GPT、Claude、Llama 等主流模型广泛采用。
Token 与字数的大致关系：英文约 1 token ≈ 4 字符或 0.75 个词；
中文约 1 token ≈ 1～2 个汉字（因分词和词表设计而异）。
为什么你总要关心 Token？
因为上下文长度（context length）和 大模型计费 都按 Token 算。
例如「上下文 128K」表示模型一次最多看 12 万多个 Token；API 按「输入 + 输出」的 Token 数收费。
所以同样一段话，中文往往比英文更耗 Token，长文档、长对话会很快吃满上下文，这是后续用 RAG、分段、摘要的原因之一。
可以去 OpenAI tokenizer 计算某段文案对应的Token数量，当然Anthropic、Google等模型厂商也有自己的计算工具，可以自行去搜索。
上下文
大模型能力很强，但没有记忆。它不会记住你上一句说了什么、上一轮聊了什么；每一次你发出一条新消息，对模型来说都是一次全新的输入。因此要维持「连续对话」，就必须在每一次请求里，把整段沟通过程（之前的问答、你给过的背景）连同当前这一条问题一起交给模型。
也就是说，上下文（Context）= 我们每次调用时塞给模型的「全部相关信息」——系统提示、历史对话、你贴的文档或代码、以及当前问题，经 Tokenizer 转成的一串 token。模型既不记得上次聊了什么，也不会主动去读你没塞进来的东西；所以能持续对话，是因为产品或 API 在背后帮你把「历史 + 新问题」拼成一段上下文，每次请求都整段重发。
上下文长度（Context Length） 就是这段「整段内容」最多允许多长，用 Token 数量表示（如 128K、1M）。对话轮次一多、文档一长，上下文就会占满这个上限，再长就塞不下，只能截断、摘要或分段（这也是 RAG、长文档分段等做法的由来）。各家会给出自己的上限，你在产品里看到的「支持 128K / 1M」指的就是这个。
大模型幻觉的本质
幻觉（Hallucination） 指的是模型生成的内容看起来通顺、合理，但与事实不符，或与你给的上下文、真实世界不一致（例如编造不存在的书名、日期、代码 API）。本质原因在于：大模型做的是「根据上文预测下一个 token 的概率分布」，它没有「先查证再回答」的机制，也没有「知道什么、不知道什么」的边界——它只是在按训练中学到的统计规律，生成「在给定上文下最像人写的下一个词」。当训练数据里没有准确信息、或上下文里没提供、或模型把相似但错误的知识混在一起时，就会产出逻辑上说得通但事实错误的内容。换句话说，幻觉不是 bug，而是这种「下一 token 预测」范式的固有特性；减轻幻觉要靠更好的训练数据、检索增强（RAG）、让模型「先检索再生成」、以及用户对关键信息自行核实。
从「小」语言模型到「大」语言模型
早期的 统计语言模型（如 n-gram）只做「前 N 个词 → 下一个词」的计数，词一多、上下文一长就存不下、算不动。神经网络语言模型（2000 年代起）用向量表示词、用网络拟合概率，能泛化到没见过的组合，但模型仍然很小，上下文也短。
Transformer（2017） 改变了架构：用 自注意力（Self-Attention） 替代 RNN，让序列里任意两个位置都能直接交互，并行计算、长距离依赖 都好很多，成了后来几乎所有 LLM 的底座。同一年代，「预训练 + 微调」 成为主流：先在海量 raw 文本上只做「预测下一个 Token」（无监督/自监督），再在少量标注数据上针对具体任务微调。这样同一套参数可以服务多种任务，模型开始往大里做——参数从几亿到几十亿、几百亿，这就是 Large Language Model（LLM） 的「Large」：参数量大、训练数据大、算力大。
为什么「大」会带来质变？
实践和后来的 Scaling Laws 表明：在架构和训练方式大致不变的前提下，把模型规模、数据量、算力一起往上推，很多能力会「涌现」——没专门教过的任务（推理、代码、多语种）也会明显变好。所以今天的 LLM 不是「为对话专门写了个程序」，而是「下一词预测」模型，做大之后，在对话、代码、翻译等场景下都表现好了。
GPT 与 BERT：两条路线
2018～2019 年，两条清晰的路线出现：
- GPT-1（OpenAI，2018）：自回归——从左到右依次预测下一个 Token，训练目标就是「给定前文，预测下一个」。解码时也是从左到右一个一个生成，天然适合生成（写文章、对话、代码补全）。上下文是「单向」的：当前词只能看到左边的 Token。
- BERT（Google，2018）：双向编码 + 掩码——随机把句子里一些词盖住（Mask），让模型用「左右两边」的上下文去猜被盖住的词。训练时能同时看到前后文，理解/分类 很强，但不直接做从左到右的生成，要生成需要额外接一层或改结构。
后来产业里通用对话、写作、代码生成几乎都走 GPT 这条自回归路线（GPT-2、GPT-3、ChatGPT、Claude、Llama 等），因为用户要的是「接着写、接着说」；BERT 更多用在检索、分类、填空式理解。所以当你听到「LLM」时，绝大多数指的是 GPT 这类自回归大模型，而不是 BERT 系。
演化过程
规模与能力齐飞
2020 年前后，GPT-2、GPT-3 把参数量推到数亿、上千亿，并验证了「规模上去，能力会涌现」——不用改架构，只要把模型和数据做大，很多任务表现会突然上一个台阶。Scaling Laws（缩放定律）被反复讨论：大家开始相信，继续堆算力、堆数据，还能再涨一波能力。
多模态与代码
同一时期，模型不再只吃文本：图像、语音逐渐被纳进同一套框架（多模态），代码也被当作「一种语言」纳入预训练（GitHub 等代码库），所以今天的模型才能既聊天又写代码又看图。
开源与闭源两条线
闭源方面，OpenAI、Google、Anthropic 等持续迭代 GPT、PaLM、Claude；开源方面，LLaMA（Meta）、ChatGLM、Qwen、DeepSeek 等让「自己训、自己部署」成为可能，国内外都在卷模型和生态。
ChatGPT 前夜
OpenAI 在 GPT-3 之后做了 InstructGPT：用人类反馈（RLHF）让模型更听话、更符合人类偏好，并做成对话式产品。这为 2022 年底的 ChatGPT 做好了技术和产品准备——只差临门一脚，把对话界面和体验做到普通人愿意天天用。
爆发点
2022 年底：ChatGPT 破圈
2022 年 11 月，ChatGPT 正式对外发布。和以前「调 API、写脚本」不同，这次是人人都能打开的网页对话：问啥答啥、写邮件、写代码、翻译、总结，体验顺滑。短短几个月用户破亿，从极客玩具变成全民话题，「AI 大模型」第一次大规模进入普通人视野。
从技术到生态
ChatGPT 成功之后，大厂和创业公司一起上：Google 推 Bard/Gemini，微软把 GPT 接进 Bing 和 Office，Anthropic 推 Claude，国内文心、通义、Kimi、豆包等齐发。编程助手（Cursor、Trae 等）、多模态（识图、语音、视频）、Agent / Workflow / MCP 等概念在 2023～2025 快速落地。模型在变强，产品形态也在变多：从「单轮问答」到「多步执行、调用工具、流水线自动化」。
所以：起点 是 Transformer 和预训练范式，演化 是规模、多模态、开源与对话式交互的积累，爆发点 是 ChatGPT 把这一切推到台前并引爆生态。下面就从「当前格局」说起，把模型、产品、编程助手和进阶能力串起来。
当时中国团队的产品发布路径
在海外 GPT、BERT、LLaMA 相继开卷的同时，国内大模型也有一条清晰的跟进与突围路径，大致可以按时间线捋一捋：
- 2020～2022（ChatGPT 前）：以探索与跟进为主。百度、阿里、腾讯、华为等早有 NLP 与预训练布局（如 ERNIE、PLUG、盘古等），但面向公众的「对话式大模型」产品还不成气候；学术与工业界更多在做模型规模、中文语料、垂直场景的积累。
- 2023 年初起（ChatGPT 破圈后）：通用对话产品密集发布。百度推出文心一言，阿里推出通义千问，智谱推出 ChatGLM，百川、MiniMax、月之暗面（Kimi）、零一万物等陆续发布对话或开源基座模型。先闭源 ToB/ToC，再开放 API 或开源部分版本，是常见打法。
- 2023 下半年～2025：开源与性价比成为一条显性路线。深度求索（DeepSeek） 发布 DeepSeek-V2/V3，走开源、强推理与编码、极低 API 定价的路线，在社区里常被和「蒸馏」「小模型高能力」绑在一起讨论（见下节）。同期，阿里的 Qwen、字节的 豆包、智谱的 GLM 等也在持续迭代开源或闭源版本。
整体上，中国团队的产品路径可以概括为：先有闭源大模型与 ToB 能力，再在 ChatGPT 引爆后快速推出对话产品与 API，随后通过开源基座、垂直场景和「小模型 + 蒸馏 / 压缩」打出差异。
为什么 DeepSeek 被称为「蒸馏」？
蒸馏 在这里指的是 知识蒸馏（Knowledge Distillation）：用一个大而强的模型（教师模型）的输出去教一个小而省算力的模型（学生模型）学成类似能力，从而在少很多参数、少很多显存和推理成本的前提下，尽量保留对话、推理、代码等表现。
为什么叫「蒸馏」？
像把液体蒸馏提纯一样，把「大模型里的知识」提炼、压缩到小模型里，丢掉一部分容量换效率和成本，所以业内管这类技术叫蒸馏。DeepSeek 为什么常被和蒸馏绑在一起？
一方面，深度求索在技术路线里大量使用了蒸馏与压缩：例如用大参数教师模型（或强闭源模型）生成高质量数据、再训出小参数学生模型，或者用多教师、动态权重的蒸馏框架（如 DMTD）做「大压小」。这样得到的模型在 7B、几十 B 规模就能逼近更大模型的效果，API 定价极低、推理快，所以大家一提「高性价比、小模型强能力」就会想到 DeepSeek，并自然联想到蒸馏。
另一方面，社区里也常把「用 GPT-4 / Claude 等强模型当老师，训出小模型」笼统称为蒸馏；DeepSeek 的公开技术与产品形象（小参数、强推理、便宜）和这一印象高度吻合，所以 DeepSeek 被称为蒸馏，既指他们确实在做蒸馏与压缩，也指大家把它当作「靠蒸馏/压缩做出性价比」的代表。
总结一句：DeepSeek 的「蒸馏」= 用大模型当老师、小模型当学生，把能力和知识压进更小、更省钱的模型里，所以你看到的高性价比、小体积强能力，背后往往有蒸馏或类似压缩手段。
第二节 当前格局
本节围绕当今热门大模型，按用户/场景和主要公司两条线介绍：谁在做、谁在用、选型时看什么。模型与产品会持续更新，以下以当前常见认知为准，具体以各厂商官网为准。
按用户/场景：谁在用、用什么
不同用户对大模型的需求不一样，先对号入座，再往下看公司会更快。
| 用户类型 | 典型需求 | 常见选择 |
|---|---|---|
| 个人用户（ToC） | 日常聊天、写作、查资料、简单多模态（发图、语音） | ChatGPT、Claude、Gemini；国内：文心一言、通义千问、Kimi、豆包 |
| 开发者 | 写代码、调 API、长上下文、API 价格、本地/自托管 | GPT-4o、Claude、DeepSeek、Qwen、Llama；Cursor/Trae 等助手内置模型 |
| 企业 / ToB | 集成进产品、私有化、合规、数据不出域、SLA | 各家企业版（Azure OpenAI、文心/通义企业版）；开源商用：Llama、Qwen、DeepSeek、GLM |
| 研究 / 开源社区 | 开源协议、可复现、基座强、做微调与二次开发 | Llama、Qwen、DeepSeek、GLM、Mistral 等开源系列 |
同一家公司往往既有 ToC 产品也有 API/企业方案，先想清楚自己主要是哪类用户，再看下面的公司表就有侧重点。
主要公司及代表模型（按热度排名，版本以当前最新为准）
以下海外、国内表格均按市场热度与常见排名排序；所列模型版本号为撰写时的最新主流版本，发版频繁，具体以各厂商官网与 API 文档为准。
海外（按热度从高到低）
| 排名 | 公司 | 当前主流/最新版本 | 简要特点 | 主要面向 |
|---|---|---|---|---|
| 1 | OpenAI | GPT-5.4、GPT-5.3-Codex、GPT-5.2 Instant | 对话与多模态标杆，原生支持计算机使用与长上下文（如 1M Token）；GPT-4o 已停用 | ToC、开发者、企业（含微软生态） |
| 2 | Anthropic | Claude Opus 4.6、Claude Sonnet 4.6、Claude Haiku 4.5 | 长上下文（如百万 Token）、安全与对齐强，写作与代码体验好；Arena 等榜单位居前列 | ToC、开发者、企业 |
| 3 | Gemini 3 Pro、Gemini 3 Flash、Gemini 2.5 Pro / 2.5 Flash | 多模态与搜索、Workspace 整合；思考型模型，综合评测热度高 | ToC、开发者、企业 | |
| 4 | xAI | Grok 4.1 Thinking | 与 X（Twitter）深度结合，强调实时信息与推理，竞技场排名靠前 | ToC、部分开发者 |
| 5 | Meta | Llama 4（Scout、Maverick）、Code Llama | 开源可商用，超长上下文（如千万 Token）、原生多模态；社区与生态大 | 开发者、企业、研究 |
| 6 | Mistral AI | Mistral Large、Mixtral、Codestral | 欧洲团队，开源与闭源并存，多语言与性价比 | 开发者、企业 |
| 7 | Apple | Apple Intelligence（端侧 + 云端模型） | 强调隐私与端侧推理，与 iOS/macOS 深度集成 | 苹果设备用户 |
| 8 | Amazon | Titan、Bedrock 托管多模型 | AWS 上自有模型 + 托管 Claude/Llama 等，面向企业上云 | 企业/云用户 |
国内（按热度从高到低）
| 排名 | 公司 | 当前主流/最新版本 | 简要特点 | 主要面向 |
|---|---|---|---|---|
| 1 | 月之暗面 | Kimi K2.5、Kimi K2-0905、Kimi K2 Thinking | 超长上下文（如 256K）、长文档与多模态；K2.5 开源、具备 Agent 与推理能力 | ToC、重度阅读、开发者 |
| 2 | 阿里巴巴 | 通义千问、Qwen3-Max-Thinking、Qwen2.5 系列 | 通义为产品与 API，Qwen 开源基座；万亿参数思考模型，综合能力靠前 | 开发者、ToC、企业 |
| 3 | 百度 | 文心一言、文心大模型（如文心 4.0 / 5.0） | 搜索与知识、多模态，ToC/ToB 铺开早，中文与情感理解强 | ToC、企业 |
| 4 | 字节跳动 | 豆包、Doubao-1.5-pro、扣子（Coze） | 豆包对话与 API，扣子为 Bot/工作流平台；语音与稀疏 MoE 有优势 | ToC、开发者 |
| 5 | 深度求索 | DeepSeek-R1-0528、DeepSeek-V3-0324、DeepSeek Coder | 开源 + API 定价极低，推理与代码强；R1 思考深度与数学表现突出 | 开发者、企业、研究 |
| 6 | 智谱 AI | GLM-4、ChatGLM 系列 | 开源 ChatGLM + 闭源 GLM-4，中英文与代码均衡 | 开发者、ToC、企业 |
| 7 | 零一万物 | Yi 系列、万知 | 开源与闭源并行，李开复团队 | 开发者、ToC |
| 8 | 商汤科技 | SenseChat 5.5 | 中文生成与多模态，NLG 等评测领先 | ToC、企业 |
| 9 | 腾讯 | 混元、混元图像 3.0 等 | 与微信、云等结合，偏 ToB 与内部 | 企业、内部 |
| 10 | MiniMax | 海螺、ABAB | 多模态与对话 | ToC、企业 |
| 11 | 华为 | 盘古大模型 | 政企、制造等垂直，国产化与落地 | 企业/政企 |
| 12 | 科大讯飞 | 讯飞星火 | 语音与多模态，教育、办公等 | ToC、企业 |
表格会随各家发版变化，以官网与最新文档为准；这里做按热度的格局速览，方便按公司和用户类型缩小范围。
设计师、产品与创意行业常用 AI 产品
除了上文中的通用对话大模型，在设计、图像、视频、产品与文档等岗位上，已经有一批相对成熟、面向具体场景的 AI 产品，下面按类别做简单介绍（以当前常见认知为准，具体以各产品官网为准）。
图像生成
| 产品 | 开发方 | 简要介绍 | 典型场景 |
|---|---|---|---|
| Midjourney | Midjourney Inc. | 以艺术感与风格化见长，社区与提示词文化成熟；通过 Discord 或网页使用，迭代到 V6 等版本，适合情绪板、概念图、插画与品牌视觉 | 品牌设计、概念艺术、海报、社媒配图 |
| DALL·E 3 | OpenAI | 与 ChatGPT 深度集成，文字渲染与指令跟随好，自然语言描述即可出图；适合需要图中带准确文字、或与对话流程结合的场景 | 营销素材、产品示意图、带文案的 Banner |
| Stable Diffusion | Stability AI 及开源社区 | 开源可本地部署，生态插件多（ControlNet、LoRA 等），可精细控制构图、姿态、风格；对算力与调参有要求 | 游戏/影视概念、二次元、定制化出图、私有化部署 |
| 通义万相 | 阿里巴巴 | 国内常用文生图/图生图产品，与通义生态打通，风格与中文提示词支持较好 | 国内团队做 Banner、插画、营销图 |
| 文心一格 | 百度 | 百度旗下文生图，与文心大模型整合，适合中文描述与国风等风格 | 营销、插画、配图 |
| 即梦 | 字节跳动 | 字节系 AI 图像/创意产品，与豆包、剪映等有联动，适合短视频与社媒素材 | 短视频封面、创意素材 |
视频生成
| 产品 | 开发方 | 简要介绍 | 典型场景 |
|---|---|---|---|
| Sora | OpenAI | 文生视频模型，支持长时长、多镜头与较强物理一致性，逐步开放 API 与产品入口 | 短片、广告、概念视频、剧情片段 |
| Runway | Runway | Gen-3 等版本，视频生成与视频编辑（擦除、延长、风格化）一体，在影视与广告行业使用广泛 | 广告片、短视频、电影级预览、素材延展 |
| Seedance | 字节跳动（Seed 团队） | Seedance 2 支持图/视频/音频+文本多模态输入，口型与音画同步好，强调「开场—动作—收束」的短视频叙事；国内可直接使用 | 广告、社媒短视频、营销视频、口播与讲解类内容 |
| 可灵 | 快手 | 国内主流 AI 视频生成与剪辑工具，与快手生态结合，适合短视频与信息流素材 | 短视频、信息流、UGC 辅助 |
| 即梦 | 字节跳动 | 除图像外也支持视频生成与剪辑能力，与剪映、豆包等打通 | 短视频、模板化视频 |
设计 / UI 与排版
| 产品 | 开发方 | 简要介绍 | 典型场景 |
|---|---|---|---|
| Figma AI（含 Figma Make） | Figma | 在 Figma 内集成 AI：自动布局、组件建议、文本生成交互原型（Figma Make）等，与设计稿与协作流程深度结合 | UI/UX 设计、高保真原型、设计系统、团队协作 |
| Canva AI | Canva | 魔法设计、智能抠图、文生图、模板推荐等，上手快，适合非专业设计师快速出图与排版 | 海报、PPT、社媒图、简单品牌物料 |
| Adobe Firefly | Adobe | 与 Photoshop、Illustrator、Express 等 Adobe 全家桶整合，图生图、扩图、矢量与排版一体化，适合已有 Adobe 工作流的团队 | 平面设计、摄影后期、品牌物料、企业设计流程 |
产品与文档
| 产品 | 开发方 | 简要介绍 | 典型场景 |
|---|---|---|---|
| Notion AI | Notion | 在笔记/知识库内写文档、总结、翻译、扩写、列提纲；与 Notion 页面与数据库深度绑定 | 需求文档、会议纪要、知识库、产品说明 |
| Perplexity / Kimi 等 | 见上文大模型表 | 用搜索+生成做行业调研、竞品与市场综述，长文档阅读与总结（如 Kimi）适合写 PRD 前的背景研究 | 市场调研、竞品分析、PRD 背景与参考 |
| ChatGPT / Claude / 文心 / 通义等 | 见上文大模型表 | 写 PRD、用户故事、测试用例、接口说明等；复杂逻辑与多轮修改时，用强推理模型（如 Claude、DeepSeek-R1）效果更好 | 需求文档、用户故事、接口文档、评审材料 |
以上按图像、视频、设计工具、产品文档四类做了归纳；实际工作中往往是「大模型 + 垂直 AI 工具」组合使用（例如用 Midjourney 出概念图、用 Figma 做界面、用 Runway/Seedance 做视频、用 Notion + ChatGPT 写文档）。
闭源 vs 开源
- 闭源（如 GPT-4o、Claude、文心、通义、Kimi）：能力与体验通常更稳，多模态与安全投入多；数据在厂商侧，需考虑合规与隐私；按调用或订阅付费。
- 开源（如 Llama、Qwen、DeepSeek、GLM、Mistral）：可自托管、数据可控、可微调与二次开发，适合对隐私和成本敏感的场景；需自备算力与运维，能力依赖基座与投入。
不少团队会混合用：对外产品用闭源保体验，内部或敏感场景用开源部署。
产品与模型别搞混
很多人会把 ChatGPT 和 GPT-4.5（或 GPT-4、GPT-4o）混在一起说，其实一个是产品名，一个是模型名：ChatGPT 是你打开网页或 App 用的那个对话产品，GPT-4.5 是它背后用来「算」的那套参数与算法。一个产品里可能在不同场景用不同模型（例如免费用较小模型、付费用 GPT-4.5），同一个模型也可能被多个产品调用（例如微软 Bing、Copilot 也会用 GPT 系模型）。
第三节 与大模型的沟通
前面两节把「LLM 是什么」「现在有哪些模型和产品」都捋了一遍，但真要用起来，还有一道坎：怎么跟大模型说清楚你的需求。模型没有读心术，你给什么它就按什么理解和生成；说得好，一次出好结果，说得糊，来回改几轮还是跑偏。本节就讲和大模型沟通的基本思路，不玩玄学，只讲能立刻用上的东西。后面用 Cursor、Trae 等编程助手时，本质也是在「跟模型沟通」，这一节打底，第四节再上工具会顺很多。
Prompt 是什么？
Prompt 就是你发给大模型的那段话——可以是问题、指令、一段背景说明，或者「角色 + 任务 + 约束」的组合。模型根据这段文字（以及当前对话里之前的轮次）来理解你要什么，再生成回复。所以：你表达得越清楚、越结构化，模型越容易给到你想要的结果。
很多人第一次用会习惯性问一句「帮我写个登录」或「这段代码有啥问题」，太简略，模型只能猜你的技术栈、语言、运行环境、代码风格，猜错了就白跑一趟。把「用什么语言、在什么项目里、要达成什么效果、有什么限制」简单写几句，效果会明显不一样。
说清楚比说得多更重要
和大模型沟通，信息量要够，但别堆废话。重点是「角色 + 任务 + 上下文 + 约束」四块说全，而不是写小作文。
- 角色：一句话告诉模型「你是什么身份」或「从什么角度回答」。例如：「你是一个有十年经验的 Android 开发，熟悉 Kotlin 和 Jetpack。」
- 任务：具体要它做什么。例如：「帮我在
home/dialog包下写一个抽奖弹窗，样式参考我发的这张图。」 - 上下文：和任务相关的关键信息——文件路径、技术栈、已有代码的约定、接口名等。缺了这些，模型只能瞎猜。
- 约束：不要什么、必须用什么、格式要求等。例如：「用自绘 View 实现，不要用多个 ImageView 拼」「中奖概率加起来必须是 100%」。
把上面四点用自然语言写几行，往往比发一大段模糊描述管用。分点写、用小标题（如「要求」「约束」），模型也更容易按你的结构来答。
常见坑：太泛、太碎、缺约束
- 太泛：「帮我优化一下」「这段代码有问题吗」——模型不知道你要的是性能、可读性、修 bug 还是加注释，只能给一个「平均」答案，经常不对味。
- 太碎：一次只丢一行代码、一个函数名，没有任何背景，模型不知道在什么项目、什么场景下用，生成的代码容易和你的工程对不上。
- 缺约束：不说明「用 Kotlin」「不要用已废弃的 API」「必须兼容 API 21」，模型可能按默认习惯来，结果你要大改。
改进方式就是：哪怕多写一两句，把角色/任务/上下文/约束点一下，再让模型生成，省的是你后面好几轮返工。
多轮对话：拆任务、逐步收窄
复杂需求不要指望「一句话搞定」。更稳的方式是：先给一个清晰但不太长的一轮说明，看模型输出，再根据结果追问、补约束、纠偏。
例如：先让模型「用 Kotlin 写一个带转盘动画的抽奖 View，支持 4 个奖品、概率可配」。等它给出第一版，再补充「转盘要缓动减速停、指针指向的奖品高亮」「把概率改成从资源读取」……这样一轮轮收窄，比一次性写一大段需求、模型理解偏了再推倒重来要高效。
多轮时有个小技巧：把上一轮里你认可的部分或需要修改的点说清楚（例如「上一版的 onDraw 逻辑保留，只改一下奖品数据的来源」），避免模型「忘记」前面约定或重复你已经否掉的方案。
大模型的计费规则
用 API 或带额度限制的产品时，计费会直接影响你怎么用、用多长上下文、多长回复。了解基本规则，可以少踩坑、按需选模型和套餐。
按 Token 计费
绝大多数大模型按 Token 计费（第一节讲过，Token 是模型眼中的「最小单位」）。一次请求里通常有两部分：
- 输入 Token（Input）：你发的提示词 + 系统提示 + 对话历史 + 塞进去的文档/代码等，模型要「读」的都会算进输入。
- 输出 Token（Output）：模型生成的那段回复，一个字一个字蹦出来的都算输出。
一般规律：输出比输入贵。因为生成时要自回归地一个一个算，算力占用更大；输入可以批量编码，相对便宜。所以长回复、多轮长对话、或者让模型「先想再答」的思考型模型，输出 Token 会很多，账单更容易上去。
国内外头部模型厂商的 API 价格（参考）
下面列出海外两家（OpenAI、Anthropic）与国内两家（阿里通义、DeepSeek）的 API 价格，均为按百万 Token 计费的官方/公开报价，便于对比。价格可能随厂商调价变动，具体以各厂商官网或最新文档为准。
海外
| 厂商 | 模型 | 输入（/百万 Token） | 输出（/百万 Token） | 备注 |
|---|---|---|---|---|
| OpenAI | GPT-5.4 | $2.50（缓存 $0.25） | $15.00 | 上下文 1M；定价页 |
| OpenAI | GPT-5 mini | $0.25（缓存 $0.025） | $2.00 | 轻量、低成本；同上 |
| Anthropic | Claude Opus 4.6 | $5.00 | $25.00 | 旗舰；定价页 |
| Anthropic | Claude Sonnet 4.6 | $3.00 | $15.00 | 常用性价比型号；同上 |
| Anthropic | Claude Haiku 4.5 | $1.00 | $5.00 | 高吞吐、低成本；同上 |
国内
| 厂商 | 模型 | 输入（/百万 Token） | 输出（/百万 Token） | 备注 |
|---|---|---|---|---|
| DeepSeek | DeepSeek-V3.2（Chat） | 2 元（缓存命中 0.2 元） | 3 元 | 人民币；定价页 |
| DeepSeek | DeepSeek-V3.2（Reasoner） | 4 元（缓存命中 1 元） | 16 元 | 思考模式，输出更长；同上 |
| 阿里云 | 通义千问（Qwen） | 约 0.5 元起（因型号不同） | 按型号 | 部分型号曾官宣 0.5 元/百万 Token 档位；以阿里云百炼/开放平台为准 |
以上仅为文本推理类 API 的典型价格；Batch、缓存、区域等可能有额外规则或折扣，请以官网为准。
为什么 Token 这么贵？成本占比大致怎样？
大模型按 Token 收费，背后是实打实的算力和运维成本，业内评估大模型 TCO（总拥有成本） 时，一个经典的成本拆分逻辑如下：
1. 核心成本构成
- 芯片 / GPU（含显存、算力）：约 50%
- 核心痛点： 硬件采购成本（CAPEX）极高，且面临 3-5 年的快速折旧压力。
- 关键资产： 除了算力本身，高性能显存（如 HBM3e）和互联带宽是主要溢价点。
- 电力消耗：约 20% ～ 30%
- 隐形支出： 不仅是芯片运行耗电，还包括巨大的散热（液冷/空冷）开销。
- 能效比： 机房的 PUE 指标直接决定了运营成本的下限。
- 基础设施与人力：约 20%
- 硬件配套： 高速网络交换机（InfiniBand）、存储系统及机房空间租赁。
- 研发运维： 包含算法优化（如算力利用率提升）及万卡集群的日常维护。
2. 训练 vs. 推理：成本重心的移位
| 维度 | 训练 (Training) | 推理 (Inference) |
|---|---|---|
| 主要成本项 | GPU 折旧 + 网络带宽 | 电费 + 显存占用 |
| 成本特征 | 一次性、爆发式的高投入 | 持续性、随并发量增长的边际投入 |
| 优化核心 | 提高算力利用率 (MFU) | 降低单次 Token 的生成成本 |
3. 行业洞察
- 硬件即门槛： 芯片成本占比最高，意味着资本密集度极高，中小玩家更倾向于租用算力。训练与大规模推理级 (数据中心)芯片通常不零售，以 8 卡服务器 或 整机柜 形式销售，顶级整机如 DGX B200（含 8 张 B200）的起售价通常在 50 万美元（约 360 万人民币）以上。
- 电力即瓶颈： 随着模型参数增加，电力供应和散热能力正在成为算力中心扩张的物理上限。
- 软件即杠杆： 优秀的算法团队通过模型量化、剪枝和推理引擎优化，可以将同样的硬件产出提升数倍，从而大幅摊薄单位成本。
总结： 算力是入场券，电力是生命线，而算法优化则是决定最终利润率的胜负手。
第四节 AI Agent
前面说过，大模型很聪明，但没有记忆，每次对话你都要把「整段沟通过程 + 新问题」一起塞进上下文；而且模型不能主动查你的日历、读你的文件、改你的代码，只能根据你这次贴进对话框的内容来生成文字。
可现实里的需求往往是：
帮我把这份需求文档拆成任务列表并排期
根据会议录音写一份纪要再发邮件给参会人
按我描述把这个功能从零实现出来
这些都不是「问一句、答一句」能完成的，需要多步规划、查数据、调工具、执行操作、根据结果再决定下一步。单靠「你贴一段、模型回一段」做不到，必须有一种系统能理解你的目标 → 自己拆步骤 → 调用各种工具（查库、读文件、改代码、发请求等）→ 多轮执行直到完成。
这种系统就是 AI Agent（智能体）。
AI Agent 会理解并拆解目标、决定先做什么后做什么、在需要时调用 MCP/搜索/执行等工具获取信息或执行动作、根据执行结果反思或重试，直到任务完成或你叫停。
常见的 AI Agent 有哪些
下面只列有代表性软件的几类；边界会越来越模糊，这里按常见叫法粗分。
- 通用对话 / 任务型：ChatGPT 的 Advanced 模式、Claude 的 Projects 等，接上联网/文档/日历后可帮你做规划、写作、信息整理。你给一个目标（如「整理我本周待办并按优先级排序」），它可能去查待办、日历，再生成清单或建议。
- 个人 / 桌面执行型 Agent：能真正替你执行操作（读文件、回邮件、订票、写代码、修 bug 等），而不只是给建议。近期爆火的 OpenClaw（因图标像龙虾，常被叫「龙虾」或「养龙虾」）就是这一类：开源、可部署在本地或云端，能 24 小时跑任务、跨应用订票订酒店、自动写代码修 bug、运营账号等，用得越久越按你的习惯来。大厂也做了同类产品，如腾讯的 QClaw / WorkBuddy、小米的 miclaw、字节的 ArkClaw 等。是的，龙虾（OpenClaw）也是 AI Agent 的一种，属于「能执行、能调工具、多轮干活」的那一类。
- 编程助手（代码 Agent）：面向写代码、改代码，能读项目文件、改多份代码、执行终端、接 MCP（Figma、数据库、Git 等）。你给的目标类似「把这个需求实现出来」「把这段从 Java 迁到 Kotlin」，它自己规划步骤、读文件、改代码、遇错再试。代表产品有 Cursor、Trae、GitHub Copilot 等，本节后面会重点说这类。
- 办公 / 写作：微软 Copilot for Microsoft 365、Notion AI 等，能根据邮件、日程、网盘文档帮你生成周报、会议纪要、邮件草稿，或按流程汇总、改写。
此外还有各类企业用的客服 / 问答 Agent、钉钉/飞书/企微里的协同与审批类 Agent 等，形态很多，不一一列。你只要记住：Agent = 能「自己规划步骤 + 调工具 + 多轮执行」的 AI 系统；
编程助手
AI 编程助手本质上仍然是一个中介 / 协调者，但这个中介和背后的大模型之间往往会有多轮来回，而不是「一轮组织上下文 + 一次调用就搞定」。更贴近的过程是：你在输入框里提交需求或指令，助手先把这句话（加上一点必要背景）交给大模型，让大模型先读懂需求、帮忙拆解和出一个大致计划；助手再根据这份计划去决定「应该看哪些文件、哪段代码、哪些文档」、如何组织成下一轮要给模型看的「相关上下文」，然后带着这些上下文再次、甚至多次调用大模型，让它生成或修改具体代码。每一轮拿到的输出，助手都会解析结果（例如改了哪几个文件、有没有语法问题、还差哪些步骤），必要时再触发下一轮调用，最后把一整组改动以 diff 的形式落到编辑器里，替你完成增删改。
也就是说：你只负责说清楚要什么，选哪些范围参与这次请求；助手负责「组织上下文 → 调模型 → 解析并落码」这一整条链路。此外，很多助手还支持配置 MCP（Model Context Protocol） 等扩展：把设计稿、数据库、API、文档源接进来，让模型在生成代码时能用到更多外部信息；有的还支持项目级或团队级的规则 / 系统提示（如 Cursor 的 Rules），在每次请求前自动带上「用 Kotlin」「遵循本项目的命名约定」等约束，相当于内置的持久 Prompt。
能力边界要心里有数：助手不会先通读整个仓库再下笔，它只是在这一轮里，根据你的描述和你选中的文件/目录（或它自己检索到的相关片段），在有限范围内理解和生成。所以：需求拆得越细、描述得越清楚（角色 / 任务 / 约束，第三节那一套），输出越靠谱；适合的是「独立小模块、工具方法、单文件/单函数级」的改写或生成，大而模糊的指令容易跑偏，需要多轮收窄。
常见产品一览
下面只介绍本文重点涉及的两款：Cursor 与 Trae，特点与能力以当前公开信息为准，便于对号入座。具体功能与定价以各产品官网为准。
| 产品 | 开发方 | 主要特点（当前版本） | 适用场景 |
|---|---|---|---|
| Cursor | Cursor | 类 VS Code，多标签对话、Agent/Ask 模式；支持 Multi-Agents 并行、Composer 编码模型、内置 AI 出图（架构图/流程图）、代码归因（Blame）；可切换 Claude/GPT/DeepSeek，支持 Rules、Skills、MCP；沙盒终端、语音模式等 | 强对话式生成、多轮改代码、前端/全栈/移动端、需项目级约定 |
| Trae | 字节跳动 | AI 原生 IDE：Builder 模式从 0 到 1 建项目（用户偏好高）、SOLO 模式 Agent 自主推进任务；10 万文件级全仓库检索、10+ 种上下文（文件/设计稿/图等）；集成大量 MCP（如 Figma、Supabase）；国内/国际版，补全延迟与构建耗时近年大幅优化 | 快速原型、全栈/Web、国内团队、从零搭项目 |
如何选择
同一类需求（比如「帮我写个函数」）Cursor 和 Trae 都能做，差异主要在：背后的模型能否切换、补全与对话/Agent 的侧重、上下文怎么组织、有没有项目级约定（Rules）。具体选哪个，建议自己亲自试一轮再定。
笔者的体验是：Cursor + Claude 算目前最强搭档，代码理解和多轮改写的表现都很稳；但 Claude 在中国用不了——不是翻墙能解决的，而是 Anthropic 对大陆/港澳的地区与账户限制（见下）。在国内用 Cursor 时切到其内置或其它可用模型（如 Cursor 默认模型、DeepSeek 等），也能完成日常开发；Trae 国内版可直接用，适合不想折腾环境的团队。
Claude 在中国为什么用不了？前因后果与办法
前因：Anthropic 明确不支持中国大陆、香港、澳门的用户直接访问 Claude（网页端、API、Claude Code 等）。原因包括其声称的合规、数据安全与商业策略，以及美方所谓的「国家安全风险」、防止技术通过中国实体外流等。2025 年 9 月起，又进一步禁止中国资本控股超过 50% 的企业（含在海外注册的子公司）使用 Claude，无过渡期、全线产品生效。所以：不是「网络被墙」，而是服务方主动对地区/企业身份做限制；个人用户即使用 VPN 注册或登录，也会面临 IP/支付/风控检测，2025 年底还出现过大规模封号，单纯翻墙并不稳。
后果：国内个人想直接用 claude.ai 或官方 API，要么被拦在「Unsupported Region」之类提示，要么用 VPN 后仍可能被封；企业若属「中国资本控股」，则被明确禁止使用。
办法：① 不依赖 Claude：在 Cursor 里改用其它已接入模型（如 GPT、DeepSeek 等），或直接用 Trae、国产大模型等做编程助手。② 仍想用 Claude 能力时：通过国内镜像/中转站（部分支持支付宝等）、API 中转服务（请求转发到 Claude API，国内直连）、或 Poe 等第三方平台间接用，需自行甄别合规与稳定性。③ 企业场景：若属被禁主体，只能弃用 Claude，改用国产或其它地区允许的模型与产品。
下面列一下 Cursor 与 Trae 的定价，便于按预算取舍（具体以官网为准，可能随政策调整）。
| 产品 | 档位 | 价格（参考） | 说明 |
|---|---|---|---|
| Cursor | Hobby（免费） | $0 | 每月有限次数 AI 对话、Tab 补全有限 |
| Cursor | Pro | $20/月（年付约 $16/月） | 含一定额度智能体请求、无限 Tab 补全、可用 Claude/GPT 等前沿模型 |
| Cursor | Pro+ | $60/月 | 约为 Pro 的 3 倍用量 |
| Cursor | Ultra | $200/月 | 高用量、优先新功能；团队版约 $40/用户/月 |
| Trae | 国内个人版 | 免费 | 含 AI、超级补全、SOLO 等，具体以官网为准 |
| Trae | 国内企业版 | 69 元/席/月（1 人起购） | 团队协作与管控 |
| Trae | 国际版 Pro | 约 $10/月（首月有优惠约 $3） | 快速队列额度、多模型等，以官网为准 |
增强大模型能力
为了让 Agent 更方便、也更「靠谱」地完成用户的复杂需求，业界在实践中逐渐抽象出了几类通用的增强手段——比如让 AI 先记住一套「固定规矩」的 Rules，把「怎么做某类事」写成可复用套路的 Skills，以及让 AI 能安全地去「用外部工具和数据」的 MCP。
简单理解就是：你按照 Agent 要求的方式把这些东西配置好，Agent 就能在此基础上，自动做更多原本需要你手动查资料、点来点去、写流程的工作。
本节下面只会简单讲清它们分别是什么、适合什么场景、原理大致如何，不会展开成一步步的实操教程；具体怎么配置、怎么写文件，Cursor、Trae 以及各家产品官网和社区里已有大量图文与视频，可以按需自行查阅。
Rules：让 AI 记住项目约定
Rules 的中文就是「规则」——指大模型输出内容要遵守的规则。
你可以把它理解成：事先写好的、每次和 AI 对话时都会自动生效的一批约定，模型在生成回复时必须按这些约定来，不用你每次再说一遍。在编程助手（如 Cursor）里，Rules 通常以项目里的配置文件或设置里的「规则」形式存在（例如 .cursor/rules/ 目录下的文件、或根目录的 RULE.md）。
应用场景举例：
语气与风格：「所有回复用正式、书面语，不要用网络梗或口语」；
长度与格式：「总结类回复不超过 200 字」「数字一律保留两位小数」；
边界与安全：「只根据我提供的内容回答，不要编造我没给过的信息」「涉及公司名称、金额时一律用 XX 替代」；
语言：「回复统一用简体中文」。
一旦把这些写成 Rules，之后每次对话 AI 都会默认遵守，你不用反复说「请简短一点」「别瞎编」。
在写代码的场景里，Rules 同理：
本项目用 Kotlin
新代码必须带注释
不要用已废弃的写法
原理概括：Rules 的文案在每次把请求发给模型之前，由助手自动拼进本次对话的「开头」（相当于系统级的固定说明）。模型看到的完整输入 = 这些规则 + 你选中的内容 + 你的问题，所以会把规则当作默认前提来生成，相当于你不用每次都重复的「持久设定」。
Skills：可复用的「能力包」
Skills 的中文就是「技能」是指 AI 做某类事情时要按什么步骤来做。
Rules 管的是「输出要遵守什么规矩」（语气、格式、不许做什么）；
Skills 管的是「这类事该怎么一步步做」——先做什么、后做什么、要注意哪些坑。写好一份 Skill，以后每次做这类事时，只要在对话里提一下，AI 就会按你写好的流程来，不会漏步、也不会顺序乱掉。
为什么需要 Skills？
如果没有一套相对完整、稳定的流程，每次你让 AI 做同一类事时，它都会「现场发挥」：有时候步骤全、有时候漏一步，有时候顺序乱了，有时候细节处理方式完全不一样。对写代码、写文档、写周报这类需要可重复、可对比、可审查的工作来说，这种「随机性」会让你很难信任它的产出。把「怎么做」写成 Skill，相当于先把这类任务的最佳实践固化下来，再让 AI 按这个套路执行——少靠临时发挥，多靠固定流程，输出会稳定很多。
应用场景举例：
写会议纪要：Skill 里写「先列出时间、参会人、议题，再按议题逐条写结论与待办，最后提炼 3 条行动项；每条待办要有负责人和截止日」；
写周报：写「先写本周完成事项（3～5 条），再写进展与风险，最后写下周计划；每条一句话，不展开」；
整理用户反馈：写「先按「功能 / 体验 / Bug」分类，再每条写「现象 + 建议」，最后汇总出现频率最高的前 5 条」。
一旦写好，之后只要说「按会议纪要 Skill 整理一下这段录音」或「按周报 Skill 生成」，AI 就会按这套步骤来。
在写代码的场景里，Skills 同理：
写自定义 View 时先定义属性、再 onMeasure、再 onDraw，注意 padding 自己处理
在本项目加新页面要先建 Fragment 和 ViewModel、再注册路由、再注入依赖
自己写 Skill，或者去 Skill 市场「拿来用」
Skill 不一定要你从零写起：很多工具（包括 Cursor 在内）都在做或计划做「Skill 市场 / 模板市场」，由官方或社区提供各类可复用 Skill，例如「写单元测试」「写周报」「生成接口文档」「重构某种常见代码坏味道」等。你可以：
自己为项目写专用 Skill：只服务你这一套业务和代码库；
到 Skill 市场挑选通用 Skill：像装插件一样「装好就用」，适合常见任务。
这样一来，复杂一点的「怎么做」就不完全靠你脑子记，也不完全靠 AI 临场发挥，而是沉淀在一份份 Skill 里，被不断复用和打磨。
原理概括：Skill 的文案是一段结构化的「怎么做」说明。当你在对话里 @ 引用某个 Skill 时，助手会把这段说明加入本次请求的上下文。模型根据「你当前的需求 + Skill 里的步骤与注意点」来生成，相当于每次都按同一套套路走。
MCP：AI 的「外挂能力」
MCP 的全称是 Model Context Protocol，中文常叫「模型上下文协议」，是指让 AI 能用上「外面的东西」（比如你的日历、公司的文档、数据库、设计稿），而不只能看你贴进对话框的那几段字。
你可以把它理解成：给 AI 接「外挂」的一套标准方式。没有 MCP 时，模型只能根据你这次对话里输入的文字（以及助手自带的少数能力，比如读当前打开的文件）来回答；有了 MCP，在你自己配置好、授权的前提下，AI 可以按协议去调用这些外部工具，把查到的、读到的结果再拿来参与生成回复，你不用再把整份文档、整张表都复制粘贴进对话框。
解析：更具体一点看，MCP 就是一份大家共同遵守的「对接协议」：一边是 Agent / 编程助手，另一边是现有的软件系统（数据库、文档库、Git、设计工具、业务系统等）。只要两边都按 MCP 的约定做一点适配——
软件系统这边：把自己的某些或全部能力，按照 MCP 规定的格式「包装」成对外的工具接口（例如「按条件查库」「按路径读文档」「获取某个 issue 的详情」）；
Agent 这边：学会用 MCP 规定的方式去调用这些接口，并把返回结果接回到对话的上下文里。
这样一来，Agent 就可以「像人一样」去调这些系统的能力，但过程是标准化的：你不用为每个系统单独写一套对接逻辑，而是统一走 MCP 这条路。结果有两个好处：一是大模型上下文里的数据会更精准、实时、贴合业务，不是凭印象乱猜；二是大模型的「能力上限」被这些外部系统撑了起来——它不再只是「会说」，而是能「查实情」「看真数」「读真文档」再来做判断和生成。在编程助手（如 Cursor）或其它支持 MCP 的产品里，你可以在设置里「添加 MCP 服务」——比如接上某个数据库、某个文档库、Figma、Git 等，本质都是在做这一步：让现有系统按 MCP 暴露能力，让 Agent 按 MCP 使用能力。
应用场景举例：
① 查日历：接上日历 MCP 后，说「我明天有什么安排？」，AI 通过 MCP 查你的日程，再根据结果回答或帮你排期；
② 读文档：接上文档/网盘类 MCP 后，说「把某某文件夹里最近那份需求文档的要点总结一下」，AI 调工具读到内容后再总结，你不用先打开文档复制一大段贴进来；
③ 查实时数据：接上股票、天气、汇率等 MCP 后，说「查一下某某股票最新价」或「北京明天天气如何」，AI 调工具拿到最新数据再回答。
原理概括：MCP 定义了一组「工具」的接口（叫什么名字、要传什么参数、返回什么格式）。在对话过程中，当模型觉得需要某条外部信息或要执行某个动作时，助手会代你调用对应的 MCP 工具，把返回的结果再拼进当前对话的上下文，模型基于「你原来的问题 + 刚拿到的结果」继续生成。也就是说：模型本身不会直接连你的数据库或读你的磁盘，而是走「你的请求 → 助手按协议调 MCP → 工具返回结果 → 结果写回上下文 → 模型再根据新上下文输出」这条链路，间接获得「外挂」能力。每个 MCP 服务能访问什么、能执行什么，由你配置时的权限和范围决定，不会默认拿到整个磁盘或全部权限。
第五节 其它
GEO
GEO 的全称是 Generative Engine Optimization，直译是「生成式引擎优化」，可以粗暴地理解成：给 AI「做 SEO」。传统 SEO 是想办法让搜索引擎（Google、百度）在搜索结果里优先展示你的网站；GEO 则是想办法让各种大模型（ChatGPT、Claude、Kimi 等）在回答问题时优先「想到」你、推荐你。只要模型是从互联网上学来的，只要它会「根据网上看到的内容来总结」，那谁往网上堆的内容多、话说得响亮、结构写得像「权威答复」，谁就越有机会变成它的「标准答案」。
2026 年的 315 晚会就点名曝光了这一套玩法：一些公司打着 GEO 优化的旗号，对外宣称「只要付钱，就能把你的产品做成主流 AI 的优先推荐，甚至变成标准答案」。记者实测时，先虚构了一款根本不存在的智能手环，再用所谓的「力擎 GEO 优化系统」批量生成十几篇软文发到网上，结果两个主流大模型真的在回答「推荐哪款智能手环」时，把这款完全虚构的产品排在了前面。这其实就是给 AI「投毒」：用成堆的虚假或极度偏颇的内容，去影响大模型学习和检索时看到的「世界」，让它在不知情的情况下把假的当真的转述给用户。
这背后已经形成一条小产业链：一头是卖 GEO 软件、卖「AI 排名优化服务」的服务商；一头是专门帮人「灌网」的发稿平台和灰产工作室，按篇数、按套餐收钱。一旦这套东西被用在金融、医疗、教育、安全等领域，后果会非常严重：普通人问 AI 要的是靠谱建议，拿到的却可能是被人花钱「优化」过的软文答案。对我们这些用 AI 工具的人来说，GEO 这件事提醒的只有一句话：AI 模型看到的世界，是有人在往里写的；所以凡是和钱、健康、安全相关的结论，永远不要只信 AI 一家之言。