"问AI就好了"：关于大模型的那些基础认知

那句”问AI就好了”

一个同事的代码评审功能做得七七八八进入场景遗漏得筛查环节。需要设计测试集来覆盖各种异常情况。

“这个让AI帮忙看看就好了，”负责的同事吃饭的时候正经道，”问它有没有遗漏的测试场景。”

但在聊到整套llm代码评审的工作流搭建时，语气中带着明显的不屑：”无非就是自己把所有上下文重组了一下问AI么？输出的结果肯定不稳定，还不如自己写逻辑判断来得靠谱。”

饭后，这段对话在脑海中挥之不去。这两种态度看似对立——一个觉得”问一下就好了”，另一个觉得”还不如自己写”——但它们其实源于同一个问题：对大语言模型的基础认知不足。

既不清楚它能做什么，也不明白它不能做什么。更重要的是，不知道在什么场景下应该如何使用它。

团队中这样的矛盾现象并不少见。一些人觉得很多工作”问问AI就行了”，显得轻松随意；同一批人在讨论把AI引入工作流时，又会略带嘲讽地质疑其价值。另一些人想要拥抱LLM带来的新变化，但对很多基础知识一知半解——不清楚有哪些主要的模型厂商，它们提供的模型都有什么区别，怎么付费，如何在IDE或CLI中使用，参数量意味着什么，tokens又是什么概念。

这种认知上的模糊地带，让技术决策变得困难，也让团队协作出现摩擦。

认知偏差的两个极端

AI无用论：看到的只是表面

那位同事说”上下文工程很low，不如自己写代码”，这个判断其实只看到了表象。

表面上看，上下文工程确实就是”把上下文重组了一下问AI”。把需求、代码片段、错误信息拼接成一段文本，发送给模型，等待回复。这个过程看起来没什么技术含量，像是在做文字拼接游戏。

但这个判断忽略了真正的工程化挑战：

输出模式约定。如何设计结构化的输出格式？是用JSON、XML，还是自定义的标记语言？如何确保模型稳定地按照这个格式输出？当格式解析失败时该怎么处理？

上下文腐败。当对话轮次增加，上下文会逐渐”腐败”——无关信息累积，关键信息被稀释，模型的注意力开始分散。如何保持上下文的质量？什么时候该清理历史，什么时候该保留？

首尾效应。模型对输入文本的不同位置有不同的敏感度。放在开头的信息和放在结尾的信息，对模型决策的影响是不同的。如何利用这个特性来优化输入？

优雅降级。当模型输出质量下降、API调用失败、token超限时，系统应该如何响应？是静默失败、提示用户、还是切换到备用方案？

输出校验。如何验证模型输出的正确性？对于代码，可以运行测试；对于文本，该用什么标准？如何在保证质量的同时避免过度校验带来的性能损失？

这些才是上下文工程的核心。说”输出不稳定”确实击中了痛点，但没有指出问题的根源，更没有提出解决方案。这就像看到一个复杂系统偶尔出错，就断言”整个系统没用”，而不去理解错误的原因和改进的空间。

AI万能论：忽略了适用边界

“问一下就好了”听起来轻松，但这种轻松背后往往是对成本和复杂度的低估。

规格驱动开发（SDD）是个很好的例子。这个范式在新项目从0到1时确实很有价值：通过编写详细的规格文档，为AI提供完整的上下文，让它按照最佳实践来生成代码。这个过程能够帮助厘清需求，避免AI因为理解偏差而走偏。

但当项目进入迭代期，SDD的成本就开始显现了：

文档的连锁修改。一个小功能的调整，可能需要修改多份相关文档——接口规格、数据模型、业务流程、测试计划。每份文档都需要保持精确，因为AI会依赖这些信息。
文档间的交叉验证。修改后的文档之间必须保持一致性。接口改了，调用方的文档也要改；数据结构改了，所有依赖它的文档都要同步。这个验证过程本身就需要大量的AI调用。
token消耗的线性增长。每次对话都需要加载相关的文档作为上下文。文档越多、越详细，token消耗就越大。而在迭代阶段，修改频繁，每次修改都要重新加载、重新验证，成本快速累积。

最终的结果是，SDD在0到1阶段是最佳实践，但在迭代阶段，它的时间成本和token成本可能会让人难以接受。它的适用面其实远比想象中要窄。

这不是说SDD没有价值，而是说任何方法都有其适用边界。”问一下就好了”忽略了这个边界，以为所有场景都能用同样的方式处理。

问题的根源

这两种极端态度的共同点是：对大语言模型的基础认知不足。

不知道模型的能力边界在哪里，所以无法判断什么任务适合用AI，什么任务不适合。不理解成本结构，所以无法在效果和开销之间做出合理权衡。不掌握基本原理，所以遇到问题时只能凭直觉判断，而不是系统地分析和解决。

要打破这种局面，需要建立一个基础的认知框架。

构建基础认知框架

主要厂商和模型家族：谁在提供什么

在讨论具体技术之前，首先要搞清楚市场上有哪些主要的参与者，以及它们各自的特点。

OpenAI：综合能力的标杆

OpenAI的GPT系列几乎是大语言模型的代名词。从早期的GPT-3，到GPT-3.5（ChatGPT最初的底层模型），再到GPT-4、GPT-4-Turbo，以及最近的o1系列，每一代都在能力上有显著提升。

GPT-4的特点是综合能力强。无论是文本理解、代码生成、数学推理，还是多语言处理，它在各个维度上都表现出色。生态也最为完善——API稳定、文档齐全、社区活跃、第三方工具丰富。

但GPT-4也有明显的缺点：贵。对于需要大量调用的场景，成本会快速累积。而且在某些特定任务上，它并不是最优选择。

o1系列是OpenAI最新推出的”推理模型”。与GPT-4不同，o1在回答之前会进行更长时间的”思考”，在数学、编程、科学推理等需要深度思考的任务上表现出色。但代价是响应时间更长，成本更高，而且不适合需要快速响应的交互场景。

Anthropic：长上下文和代码能力的优势

Claude系列是Anthropic的主打产品。Claude 3家族包含三个版本：Haiku（小而快）、Sonnet（平衡型）、Opus（大而强）。最新的Claude 3.5 Sonnet在代码能力上有显著提升，成为很多开发者的首选。

Claude的几个突出特点：

首先是超长的上下文窗口。Claude 3.5 Sonnet支持200k tokens的上下文，这意味着可以一次性处理大约15万个汉字，或者几十个代码文件。在需要理解大型代码库、分析长文档的场景下，这个能力很有价值。

其次是在代码任务上的表现。Claude 3.5 Sonnet在代码理解、生成、调试方面的能力，被很多开发者认为优于GPT-4。特别是在处理复杂的重构任务、分析代码架构时，它的表现往往更好。

第三是安全性和可控性。Anthropic在模型训练中特别注重”constitutional AI”，使得Claude在拒绝不当请求、避免有害输出方面做得比较好。

DeepSeek：便宜且好用的新选择

DeepSeek是国内的一匹黑马。DeepSeek V2和V3都采用了MoE（Mixture of Experts）架构，在性能和成本之间取得了很好的平衡。

DeepSeek V3的参数规模达到600B以上，但实际激活的参数只有37B左右。这意味着它拥有大模型的能力，但运行成本接近中等规模的模型。在代码生成、数学推理、中文理解等任务上，DeepSeek的性价比非常突出。

更重要的是，DeepSeek的API价格远低于OpenAI和Anthropic。在需要大量调用的场景下，成本差异可能是数量级的。

国内其他主要厂商

智谱AI的GLM-4系列在中文理解和生成上有不错的表现，特别是在处理中文的专业领域文本时。

MiniMax提供的模型在对话和内容生成方面有自己的特色，API接口设计也比较友好。

豆包（字节）、通义千问（阿里）、文心一言（百度）等大厂的模型，在各自的生态内有较好的集成，适合需要与这些平台深度绑定的场景。

参数量：不只是数字游戏

在讨论大语言模型时，经常会听到7B、13B、70B、175B这样的数字。这些数字代表模型的参数量，单位是十亿（Billion）。

但参数量并不是简单的”越大越好”。

参数量与能力的复杂关系

直觉上，参数越多，模型的”容量”越大，应该能存储更多知识，处理更复杂的任务。这个直觉大致是对的，但关系并不是线性的。

从7B到13B，模型能力会有明显提升。但从70B到175B，提升可能没有想象中那么大。而且在某些特定任务上，经过精心训练的小模型可能比粗糙训练的大模型表现更好。

更重要的是，参数量直接影响推理成本。模型越大，运行时需要的计算资源和内存就越多，推理速度越慢，成本越高。在实际应用中，需要在能力和成本之间找到平衡点。

MoE架构的特殊性

MoE（Mixture of Experts）架构改变了这个等式。

传统的”密集”模型在推理时会激活所有参数。一个175B的模型，每次推理都需要加载和计算全部175B个参数。

而MoE模型采用了”专家混合”的思路。模型内部包含多个”专家”子网络，每个专家擅长处理某类特定的输入。在实际推理时，一个”路由器”会根据输入选择激活哪几个专家，其他专家则保持休眠。

DeepSeek V3就是这样一个例子。它的总参数量超过600B，但每次推理只激活约37B的参数。这意味着它拥有大模型的”知识容量”，但推理成本接近中等模型。

这就像一个大型图书馆。传统模型相当于每次查询都要遍历所有书架，而MoE模型会先判断你要找的书在哪个区域，然后只去那个区域查找。总藏书量很大，但实际查找成本并不高。

这种架构创新是DeepSeek能做到”便宜又好用”的关键。

Tokens：模型的”语言单位”

Token是大语言模型处理文本的基本单位。理解token的概念，对于使用模型、估算成本、优化效果都很重要。

什么是Token

Token可以简单理解为”词元”——比词更小的语义单位。

对于英文，一个token通常对应一个词或词的一部分。比如”understanding”可能被分成”under”和”standing”两个token，”chatbot”可能是一个完整的token。

对于中文，情况稍微复杂。一个汉字通常对应1-2个token。常见的汉字可能只占1个token，生僻字或专业术语可能需要2-3个token。

这种差异带来一个实际问题：同样的语义，用中文表达比英文消耗更多token。如果API按token计费，那么中文用户的成本会高于英文用户。

为什么要按Token计费

模型的推理成本主要来自计算量，而计算量与处理的token数量直接相关。一段1000 token的文本，需要的计算量大约是100 token的10倍。

所以API提供商按token计费是合理的。通常输入token和输出token的价格不同——输出token更贵，因为生成文本需要更多的计算。

上下文窗口的概念

上下文窗口（Context Window）指的是模型一次能处理的最大token数量。早期的模型通常是4k（4096）tokens，后来发展到8k、16k、32k，现在一些模型已经支持128k甚至200k tokens。

这个数字包括输入和输出的总和。如果你的输入已经占用了3k tokens，那么在4k的窗口下，输出最多只能是1k tokens。

长上下文窗口带来了新的可能性。可以一次性输入整个代码库进行分析，可以处理长篇文档，可以保持很长的对话历史。但代价是成本更高，而且研究表明，当上下文非常长时，模型对中间部分的信息注意力会下降——这就是前面提到的”上下文腐败”问题。

实际使用中的Token消耗

一个实际的例子：设计一个中等复杂度的测试用例。

输入部分可能包括：

需求描述：500 tokens
接口定义：300 tokens
参考示例：400 tokens
约束条件：200 tokens

总计约1400 tokens的输入。

模型生成的测试代码可能是1000 tokens。

如果使用GPT-4 Turbo，输入价格是$0.01/1k tokens，输出价格是$0.03/1k tokens。这次调用的成本是：

输入：1.4k × $0.01 = $0.014
输出：1k × $0.03 = $0.03
总计：$0.044，约合人民币0.3元

如果使用DeepSeek V3，价格是GPT-4的1/10左右，同样的任务成本约0.03元。

看起来单次成本不高，但如果每天要生成几十个测试用例，一个月要处理上百个需求，成本就会快速累积。

付费方式和成本考量

不同的API提供商有不同的计费策略，理解这些策略对于控制成本很重要。

按Token计费：主流方式

大部分API都采用按token计费，输入和输出分别定价。一般来说：

OpenAI GPT-4 Turbo：输入 $0.01/1k, 输出 $0.03/1k
Claude 3.5 Sonnet：输入 $0.003/1k, 输出 $0.015/1k
DeepSeek V3：输入 ¥0.001/1k, 输出 ¥0.002/1k

价格差异可能达到一个数量级。这意味着在大量调用的场景下，选择不同的模型，成本差异可能是10倍甚至更多。

不同模型的价格策略

同一厂商的不同模型，价格也有明显差异。以Claude为例：

Haiku（小模型）：便宜但能力有限
Sonnet（中模型）：平衡性价比
Opus（大模型）：贵但能力最强

这就要求在使用时做出权衡：简单的任务用小模型，复杂的任务用大模型。不能因为”买了会员”就无脑用最大的模型，也不能为了省钱让小模型做它力所不能及的事情。

批量调用和缓存优化

一些API提供商对批量调用有折扣，或者提供缓存机制来降低成本。

比如Anthropic的Prompt Caching功能：如果你的输入中有大量重复的部分（比如系统指令、代码库上下文），这些内容可以被缓存，下次调用时只需要付缓存读取的费用，而不是完整的输入费用。对于需要频繁调用且上下文相似的场景，这能显著降低成本。

实际成本优化经验

在实际项目中，有几个简单的优化策略：

任务分级：根据复杂度选择不同的模型。简单的代码补全用小模型，复杂的架构重构用大模型。
上下文精简：不要无脑地把所有信息都塞进上下文。只提供真正相关的信息，可以节省token，还能提高模型的注意力集中度。
输出控制：明确限定输出的长度和格式。有时候模型会”话痨”，输出大量冗余内容，浪费token。
错误处理：当API调用失败或输出不符合预期时，不要无脑重试。先检查问题，优化输入，再重新调用。盲目重试会浪费大量成本。

在IDE和CLI中使用：从工具到工作流

理解了模型的基本概念，下一个问题是：如何在实际工作中使用这些模型？

IDE集成：最直接的体验

现代IDE已经深度集成了AI能力。

Cursor是一个基于VSCode的AI驱动IDE，内置了代码补全、重构、解释等功能。它支持多种模型，可以根据任务选择使用GPT-4、Claude还是其他模型。在编写代码时，Cursor能理解整个代码库的上下文，提供更准确的建议。

GitHub Copilot可能是使用最广泛的AI编程助手。它主要基于OpenAI的Codex模型，擅长代码补全和生成。在写代码时，Copilot会根据注释、函数名、上下文自动补全代码。对于常见的编程模式，它的准确率很高。

Claude Code是Anthropic推出的CLI工具，可以在命令行中与Claude交互。它支持文件读取、代码执行、系统集成等功能，适合需要深度定制工作流的场景。

这些工具的共同点是：降低了使用AI的门槛。不需要写API调用代码，不需要管理token，不需要处理输出解析——工具已经帮你做好了。

但这也带来一个问题：容易忽略底层的工作原理。当工具表现不如预期时，不知道问题出在哪里，也不知道如何优化。

API调用：更灵活的控制

如果需要将AI能力集成到自己的应用中，就需要直接调用API。

OpenAI和Anthropic都提供了官方的SDK，支持Python、JavaScript等主流语言。基本的调用流程是：

初始化客户端，提供API密钥
构建消息列表，包括系统指令、用户输入、历史对话
调用API，传入模型名称、消息、参数（如temperature、max_tokens）
处理返回结果，提取模型输出

这种方式的优势是灵活性高。可以精确控制每一次调用的参数，可以自定义输出处理逻辑，可以实现复杂的多轮对话和上下文管理。

但代价是需要处理更多的技术细节：错误处理、重试逻辑、token计数、成本监控等等。

本地部署：隐私和成本的权衡

如果对数据隐私有严格要求，或者调用量非常大，可以考虑本地部署开源模型。

工具如Ollama可以方便地在本地运行Llama、Mistral等开源模型。硬件要求取决于模型大小：7B模型需要至少8GB显存，13B需要16GB，70B可能需要多卡并行。

本地部署的优势是数据不出本地，没有API调用费用。但劣势也很明显：开源模型的能力通常弱于商业模型，运行需要专门的硬件，维护成本不低。

实际工作流的选择

在实际工作中，通常会组合使用多种方式：

日常编码用IDE集成工具（Cursor/Copilot），快速便捷
复杂的代码分析和重构，用Claude Code或API调用，获得更好的上下文理解
批量任务（如测试用例生成）用脚本+API，可以自动化和优化
敏感数据的处理，用本地部署的模型

没有一种方式是”最好”的，关键是根据场景特点做出合理选择。

MoE架构：为什么DeepSeek能做到便宜又好用

前面提到，DeepSeek V3通过MoE架构实现了性能和成本的平衡。这个架构背后的原理值得深入理解，因为它可能代表了大语言模型的一个重要发展方向。

传统密集模型的瓶颈

在传统的”密集”模型中，所有参数在每次推理时都要参与计算。

一个175B参数的GPT-3，每生成一个token，都需要进行175B次乘加运算。即使有专门的GPU加速，这个计算量也是巨大的。

这带来两个直接后果：

推理速度慢：大量的计算需要时间，用户等待响应的时间变长
运行成本高：需要高性能的硬件，能耗大，运营成本直接转化为API价格

更重要的是，并非所有参数在每次推理时都是必要的。对于一个代码补全任务，模型中关于文学、历史、地理的那些参数其实用不上。但在密集模型中，它们还是要被加载和计算。

这就像为了找一本编程书，却要翻遍整个图书馆的所有书架。效率很低。

MoE的核心思想：专家混合

MoE架构的核心思想是”专业化分工”。

模型内部包含多个”专家”子网络，每个专家擅长处理某类特定的输入。比如，可能有专门处理代码的专家、处理自然语言的专家、处理数学推理的专家。

在推理时，一个”路由器”（Router）会分析输入，决定激活哪几个专家。只有被选中的专家参与计算，其他专家保持休眠。

这就像一个医院。虽然有心内科、骨科、神经科等多个科室（专家），但病人来看病时，只需要挂对应的科室，而不需要挂所有科室的号。医院的总能力很强（专家多），但单个病人的诊疗成本并不高（只用到一两个专家）。

DeepSeek的实现：600B的容量，37B的成本

DeepSeek V3的架构设计体现了这个思路：

总参数量超过600B，意味着模型拥有巨大的知识容量。这些参数分布在多个专家子网络中。

实际激活参数约37B。在每次推理时，路由器会根据输入选择激活大约37B的参数。这意味着虽然模型”很大”，但运行起来的计算量接近一个中等规模的密集模型。

路由策略是关键。DeepSeek的路由器不是简单的规则匹配，而是一个可学习的网络。在训练过程中，路由器会学习如何为不同的输入选择合适的专家组合。这个过程是动态的、自适应的。

举个例子：当输入是一段Python代码，路由器可能会激活”代码理解专家”和”Python语法专家”；当输入是一个数学问题，可能会激活”数学推理专家”和”符号处理专家”；当输入是中文文本，可能会激活”中文语义专家”和”上下文理解专家”。

这种设计的好处是：

能力不妥协：600B的参数容量保证了模型的知识广度和深度
成本可控：37B的激活参数使得推理成本显著降低
速度更快：计算量小，推理速度快，用户体验更好

实际体验：与GPT-4o、Claude的对比

在代码生成任务中，DeepSeek V3.2的表现确实让人印象深刻。

函数补全和重构：对于中等复杂度的函数，DeepSeek的输出质量接近GPT-4o和Claude 4 Sonnet，但响应速度更快，成本只有它们的1/10左右。

代码理解和解释：在解释复杂代码逻辑时，DeepSeek能够准确抓住关键点。虽然表达有时不如Claude那么流畅，但技术准确性是有保证的。

中文场景的优势：对于中文注释、中文需求的处理，DeepSeek的表现明显优于国际模型。这可能得益于其训练数据中中文内容的比例更高。

但DeepSeek也不是万能的：

复杂推理任务：在需要多步推理、抽象思考的任务上，DeepSeek仍然弱于GPT-5和Claude Opus。比如设计复杂的系统架构、分析深层的代码缺陷。

长上下文处理：虽然DeepSeek也支持较长的上下文，但在处理非常长的文档时，它对信息的整合能力不如Claude。

稳定性：偶尔会出现输出质量波动，可能与路由策略的不确定性有关。对于关键任务，可能需要多次尝试或加强输出校验。

什么场景适合用DeepSeek

基于这些特点，DeepSeek特别适合以下场景：

大量重复的代码生成任务：比如测试用例生成、数据处理脚本、API封装代码。这类任务模式相对固定，不需要深度推理，但调用量大，成本敏感。

中文为主的应用：如果你的用户、需求、文档主要是中文，DeepSeek的性价比优势会更加明显。

成本敏感的探索性项目：在项目早期，需要大量尝试和迭代，但预算有限。DeepSeek可以让你以更低的成本进行更多的实验。

需要快速响应的交互场景：比如实时代码补全、聊天机器人。DeepSeek的推理速度优势能提升用户体验。

但对于需要深度推理、高稳定性、长上下文理解的关键任务，可能还是要选择GPT-5或Claude。

基准测试：如何评价模型能力

既然有这么多模型可选，如何客观地评价它们的能力？这就需要标准化的基准测试。

主流基准测试的作用

MMLU (Massive Multitask Language Understanding)：测试模型在57个学科（包括数学、历史、法律、医学等）上的知识广度。题目覆盖从小学到专业级别。这个测试主要评估模型的”知识储备”。

HumanEval / MBPP：专门测试代码生成能力。给定函数签名和描述，要求模型生成正确的实现。HumanEval包含164道编程题，MBPP包含974道。这是评估编程能力的主要标准。

MATH：数学推理测试，包含从初中到大学竞赛级别的数学问题。不仅要求得出正确答案，还要求给出推理过程。这测试的是逻辑推理能力。

BBH (Big-Bench Hard)：Big Bench中最困难的那部分任务。涵盖逻辑推理、常识理解、多步推理等。这些任务对当前的模型来说仍然很有挑战性。

这些测试的共同特点是：标准化、可重复、有明确的评分标准。研究者和厂商可以用它们来比较不同模型的能力。

新兴基准测试的创新

传统基准测试面临一个问题：当测试题目公开后，模型可能在训练时”见过”这些题，导致”过拟合”——在测试上表现很好，但真实场景中表现不佳。

新兴的基准测试试图解决这个问题：

LiveBench：动态更新的测试集。每个月都会加入新的题目，并移除旧的。模型不可能提前”学习”这些题目，必须依靠真实的理解和推理能力。

GAIA (General AI Assistants)：模拟真实的助手任务。不是简单的问答，而是需要多步操作、工具使用、信息整合的复杂任务。比如”找到某公司最新财报中的某个数据，并与去年同期对比”。

SWE-bench (Software Engineering Benchmark)：用真实的GitHub issue来测试模型。给定一个bug报告或功能需求，要求模型修改代码并通过测试。这是最接近真实软件工程工作的测试。

这些新测试更强调真实场景的能力，而不仅仅是答题技巧。

基准测试的局限性

尽管基准测试很有价值，但它们也有明显的局限性：

高分不等于好用。一个在MMLU上拿95分的模型，在实际的代码重构任务中可能不如一个90分的模型。因为测试题和真实任务之间存在gap。

针对性优化。厂商可能会针对某些知名测试进行专门优化，提升分数但不提升通用能力。这就像”应试教育”——考得好不代表能力强。

覆盖面有限。即使是最全面的测试，也只能覆盖有限的任务类型。对于很多特定领域（如某个编程语言的特殊库、某个行业的专业知识），通用测试可能完全没有涉及。

静态评估的问题。大部分测试是单轮问答式的，但实际使用中，多轮对话、上下文保持、错误恢复等能力同样重要。这些在传统测试中很难评估。

如何看待这些数字

在选择模型时，基准测试的分数可以作为参考，但不应该是唯一依据。

更好的做法是：

看测试类型：关注与你的任务相关的测试。如果主要做代码生成，HumanEval的分数比MMLU更重要。
看相对排名：不要纠结于绝对分数，而是看在相关测试中的相对表现。
做实际测试：用你自己的真实任务去测试几个候选模型。这比看任何基准测试都更可靠。
关注多个维度：除了准确性，还要考虑响应速度、稳定性、成本、API易用性等。

基准测试提供了一个粗略的筛选机制，但最终的选择要基于实际体验。

大小模型的实际体验差异

理解了模型的基本参数和评测方法，下一个问题是：在实际使用中，大模型和小模型的体验差异到底在哪里？

小模型的特点：快、便宜、但容易”跑偏”

代表模型：Claude Haiku、GPT-3.5-Turbo、Qwen-7B、Llama 3 8B

小模型的第一个特点是响应速度快。因为参数量小，推理需要的计算量也小。一个简单的代码补全任务,小模型可能在1-2秒内就给出结果，而大模型可能需要5-10秒。

在实时交互场景下，这个差异很明显。用户输入一个函数名，期待IDE立刻补全后续代码——如果等待时间超过3秒，体验就会明显下降。

第二个特点是成本低。小模型的API价格通常是大模型的1/5到1/10。对于需要大量调用的场景（如每天生成几百个测试用例），成本差异可能是决定性因素。

但小模型的局限性也很明显：

理解能力有限。对于复杂的、模糊的、隐含的需求，小模型往往抓不住重点。比如给出一段描述：”实现一个缓存系统，要求高性能，支持过期策略”。大模型可能会考虑LRU算法、并发控制、内存管理等多个方面；小模型可能只是实现一个简单的HashMap，忽略了性能和过期策略的要求。

容易”跑偏”。在多轮对话中，小模型更容易遗忘上下文或误解意图。你纠正一次，它改对了；你再问下一个问题，它又回到错误的理解上。这种反复纠正的过程很消耗耐心。

输出质量波动大。同样的输入，大模型的输出相对稳定；小模型可能这次给出不错的结果，下次就完全不对。这种不稳定性使得它难以用于关键任务。

大模型的特点：理解深、质量高、但贵且慢

代表模型：Claude Opus、GPT-4、GPT-4-Turbo、Claude 3.5 Sonnet

大模型的核心优势是理解力强。它能够理解隐含的需求、处理模糊的描述、把握复杂的上下文。

一个典型的场景是代码重构。你给出一段混乱的遗留代码，要求”优化这段代码的结构，提高可读性”。小模型可能只是简单地重命名变量、加几行注释；大模型会识别出代码的设计模式，提取重复逻辑，重组函数结构，甚至建议更合适的数据结构。

第二个优势是输出质量稳定。大模型生成的代码语法错误少、逻辑严密、注释清晰。在需要一次性生成较完整功能的场景下，大模型的”一次成功率”明显高于小模型。

第三个优势是长上下文能力。在处理大型代码库、长文档时，大模型能够更好地整合全局信息，给出更准确的分析。

但代价也是明显的：

成本高。大模型的API价格通常是小模型的5-10倍。对于预算有限的项目，这可能是无法接受的。

响应慢。生成同样长度的输出，大模型可能需要小模型3-5倍的时间。在需要快速迭代、频繁交互的场景下，这个延迟会影响工作流畅度。

“过度思考”。有时候，大模型会给出过于复杂的方案，而实际上简单的方法就够了。这就像你问路，对方给你讲了城市规划的历史——内容很丰富,但不是你需要的。

实际选择的权衡：任务复杂度是关键

那么什么时候该用小模型，什么时候该用大模型？

代码补全和简单生成：小模型完全够用。比如根据函数名补全函数体、生成getter/setter、实现简单的数据转换逻辑。这类任务模式固定，小模型的响应速度优势明显。

代码重构和架构设计：必须用大模型。这类任务需要深度理解代码的意图、识别设计模式、权衡多种方案。小模型在这方面力不从心。

测试用例生成：取决于复杂度。对于接口明确、逻辑简单的单元测试，中等模型（如GPT-3.5、Claude Sonnet）就够了。但对于需要考虑边界条件、异常流程、并发场景的集成测试，最好用大模型。

文档生成：同样看复杂度。技术文档的常规部分（API说明、参数列表）用小模型；需要解释设计思路、使用场景、最佳实践的部分用大模型。

代码审查和Bug分析：倾向于用大模型。这类任务需要理解代码的深层逻辑、识别潜在问题、考虑边界情况。大模型的深度理解能力在这里很有价值。

批量处理任务：如果任务模式固定、数量大、成本敏感，优先考虑小模型或中等模型。可以先用大模型做几个示例,提炼出模式，然后用小模型批量处理。

一个混合策略的例子

在测试用例开发中，可以采用”大模型设计，小模型生成”的策略：

用大模型（Claude 3.5 Sonnet）分析需求，设计测试策略，识别关键测试点
基于测试策略，用中等模型（GPT-3.5-Turbo）生成具体的测试代码
对于生成的代码，用小模型（Haiku）批量生成注释和文档

这样既保证了设计质量，又控制了成本。大模型只用在最关键的决策环节，日常的代码生成用更便宜的模型。

这种策略需要一定的工程化支持——需要设计好不同环节的输入输出格式，确保它们能够无缝衔接。但一旦建立起来，效率和成本的平衡会很好。

重新审视那些认知偏差

现在，有了这些基础知识，可以重新审视开头的那两种态度。

关于”上下文工程很low”：表面简单，实则复杂

那位同事说”输出不稳定，不如自己写逻辑”，这个判断确实指出了问题，但没有抓住本质。

上下文工程的核心挑战不在于”拼接上下文”，而在于如何设计一个稳定可靠的系统。

输出模式约定是第一个挑战。如何让模型稳定地按照预定格式输出？

一个常见的做法是在prompt中明确定义输出格式，比如：

请按照以下JSON格式输出测试用例：
{
  "testName": "测试名称",
  "setup": "初始化代码",
  "execution": "执行代码",
  "assertion": "断言代码"
}

但模型不总是严格遵守。它可能多输出一些解释文字，可能把字段名写错，可能用YAML而不是JSON。这时就需要容错解析——先尝试标准解析，失败了再用正则提取，还不行就用模型自己来修正。

这不是”low”的工作，而是工程化的必要措施。

上下文腐败是第二个挑战。随着对话轮次增加，无关信息累积，模型的注意力会分散。

解决方法是上下文管理策略：

定期清理：每隔N轮对话，总结关键信息，清除细节
优先级排序：把最重要的信息放在prompt的开头和结尾（利用首尾效应）
动态加载：根据当前任务，只加载相关的历史信息

这需要设计一个”上下文管理器”，决定什么时候保留什么信息。这是系统设计问题，不是简单的拼接。

首尾效应是第三个需要利用的特性。研究表明，模型对输入开头和结尾的信息更敏感，对中间部分的注意力会下降。

工程实践是：

把系统指令放在最开头，确保被重视
把当前任务的关键信息放在最后，引导模型关注
中间部分放参考信息和历史上下文

这种精心设计的信息排布，能显著提升输出质量。

优雅降级是可靠性的关键。当模型输出质量下降、API调用失败、token超限时，系统该如何响应？

一个完整的方案包括：

输出质量评估：用规则或另一个模型评估输出是否可用
降级策略：质量不佳时，简化任务、减少输出、或提示用户
备选方案：API失败时，切换到备用模型或人工处理
监控告警：记录失败情况，持续优化

这是分布式系统的思路，不是”拼接上下文”能涵盖的。

输出校验是最后一道防线。对于代码输出，可以编译、运行测试；对于结构化数据，可以schema验证；对于文本，可以用规则检查或模型复核。

这些工程措施加起来，才构成一个”稳定”的上下文工程系统。说”输出不稳定”没错，但认为”不如自己写逻辑”就低估了问题的复杂度——如果自己写逻辑能轻松解决，当初也不需要考虑用AI了。

真正的问题不是”用不用AI”，而是”如何把AI工程化”。

关于”SDD是银弹”：0到1的最佳实践，1到N的成本陷阱

“问一下就好了”背后隐含的假设是：AI能处理所有复杂度的任务，成本是可以忽略的。

SDD的案例很好地说明了这个假设的问题。

在新项目从0到1时，SDD确实是最佳实践。通过详细的规格文档，可以：

厘清需求：写文档的过程本身就是梳理思路的过程
提供完整上下文：避免AI因为信息缺失而理解偏差
建立验证基准：文档作为ground truth，可以校验生成的代码

这个阶段，投入时间写文档是值得的。即使token消耗较大，也能通过减少返工来弥补。

但在迭代阶段，情况完全不同：

文档的连锁修改成为主要成本。一个接口的小调整，可能需要修改5-10份相关文档。每次修改都要保证精确，因为AI会依赖这些信息。写代码的时间没多少，写文档和验证文档的时间占了大头。

文档间的对齐变得困难。当文档数量增加到几十份，它们之间的依赖关系变得复杂。A文档改了，B和C文档也要改，但可能还会影响到D和E。追踪这些依赖关系本身就是个挑战。

Token消耗线性增长。每次对话都需要加载相关文档作为上下文。在迭代阶段，修改频繁，每次都要重新加载、重新验证。如果一个月有100次修改，每次平均消耗10k tokens，那就是1M tokens——成本可能达到数千元。

最终的结果是：SDD在0到1阶段很好，但在迭代阶段，投入产出比快速下降。它的适用面比想象中窄得多。

这不是说SDD没有价值，而是说没有一种方法适用所有场景。在不同阶段、不同任务、不同约束条件下，需要选择不同的方法。

“问一下就好了”忽略了这种场景依赖性。

基础认知的重要性：知道边界，才能合理使用

这两个案例说明了同一个问题：不理解工具的能力边界，就无法合理使用它。

知道模型的能力边界，才能判断什么任务适合用AI。理解成本结构，才能在效果和开销之间做权衡。掌握基本原理，才能在遇到问题时系统地分析和解决，而不是凭感觉。

这就是为什么基础认知如此重要。它不是为了炫耀知识，而是为了做出更好的决策。

当你知道GPT-4擅长复杂推理但成本高，DeepSeek便宜但稳定性稍差，Haiku快速但理解力有限，你就能根据任务特点做出合理选择。

当你理解上下文窗口、token计费、首尾效应这些概念，你就能设计出更高效的prompt，降低成本，提升效果。

当你了解MoE架构的原理，你就明白为什么DeepSeek能做到便宜又好用，也就能预判它在哪些场景下可能不够稳定。

这些知识不是技术八股，而是实践工具。

一些还在思考的问题

即使建立了基础认知框架，仍然有很多问题没有明确的答案。

关于技术选型的困惑

如何在团队中建立合理的AI使用规范？

有些团队是”放任式”的——每个人用自己喜欢的工具和模型，没有统一标准。这样灵活性很高，但也导致经验无法共享，成本难以控制，质量参差不齐。

有些团队是”管控式”的——统一规定使用某个工具、某个模型，甚至统一管理API密钥。这样便于管理,但可能限制了创新，不同任务的特殊需求也难以满足。

在这两个极端之间，那个合适的位置在哪里？

类似的困惑还有：什么样的任务值得用AI，什么样的不值得？有些任务用传统方法5分钟就能搞定,用AI反而要调试半小时。但也有些任务看起来简单，用AI却能发现意想不到的优化点。如何做这个判断？

关于学习路径的选择

是应该深入学习底层原理（如Transformer架构、注意力机制、训练算法），还是专注于应用层面（如prompt工程、工具使用、工作流设计）？

深入学习底层有明显的价值——能更好地理解模型的行为,预判它的能力边界，优化使用策略。但代价是时间投入大，而且很多底层知识需要数学和机器学习基础。

专注应用层面则更实用——能快速上手，直接产生价值。但可能陷入”知其然不知其所以然”的状态，遇到问题时缺乏分析能力。

更复杂的是，技术迭代非常快。今天学的模型原理，可能一年后就被新架构取代了。投入大量时间研究细节，是否值得？

关于团队认知的统一

如何让团队对AI建立统一的认知？

现状是分裂的：有人觉得无用，有人觉得万能，有人想学但不知从何入手。这种认知差异导致协作困难——讨论技术方案时，对AI能力的预期不一致，很难达成共识。

是应该组织系统的培训？还是通过实践项目让大家逐步建立认知？如何平衡不同人的学习曲线和接受度？

更根本的问题是：在轻蔑与盲信之间，那个合适的位置到底在哪里？

既不能因为遇到几次失败就否定AI的价值，也不能因为看到几次成功就夸大它的能力。这个平衡点是动态的、依赖场景的，如何在团队中建立这种”动态平衡”的认知？

这些问题可能没有标准答案。但提出问题本身，可能比匆忙给出答案更重要。

写这篇文章的起因，是饭点那段简短的对话。一句”问AI就好了”，一句”上下文工程很low”，看似随意，却反映了对大语言模型认知的模糊地带。

这种模糊不是个人问题，而是整个行业在快速变化中的常态。技术迭代太快，新概念层出不穷，很多人还在摸索中。

但如果能建立一个基础的认知框架——了解主要的厂商和模型，理解参数量和token的概念，知道成本结构和使用方式，掌握选择模型的基本标准——至少能让讨论建立在共同的基础上，而不是各说各话。

至于那些更深层的问题——如何平衡能力和成本，如何建立团队规范,如何在轻蔑与盲信之间找到位置——可能需要更多的实践和思考。

但这也正是这个领域有趣的地方。没有完美的答案,只有持续的探索。

MaybeItWorks