很多人刚开始用 AI 编程工具，经常会有一个疑问：Cursor、Antigravity 这些编辑器里也能选 Claude 模型，为什么目前来看还是 Claude Code 配合 Claude 模型的编程效果最好？

为什么 Qwen、DeepSeek 等国产模型也能支持在 Claude Code 里使用？和使用官方的 Claude 模型有什么区别？

如果你有这些疑问，说明你还没搞清楚 LLM 和 Agent 之间的关系。

简单说，AI 写代码的效果同时取决于两件事：LLM 模型本身的能力，以及围绕模型的 Agent 工程实现。两者都够强，才能有最好的效果，任何一方拉胯，最终效果都不尽如人意。

我们说的 Qwen、Claude、DeepSeek 等模型属于 LLM（大语言模型），Cursor、Antigravity、Claude Code 等 AI 编程工具属于 Agent（智能体）。

LLM 的本质：概率预测

大语言模型（LLM）的核心原理其实就一句话：根据已有的文本，预测下一个 token 出现的概率。

这里的 token 是模型处理文本的最小单位，一个 token 大约相当于一个汉字或半个英文单词。后面我们会频繁提到 token 这个概念，你可以先简单理解为「一小段文字」。

比如你输入「今天天气」，模型会计算所有可能的下一个字的概率分布：「真」的概率 30%，「不」的概率 20%，「很」的概率 15%……然后从中选一个输出。选完之后，把这个字拼到输入后面，继续预测下一个字，如此反复，就生成了一段完整的文本。

所以 LLM 本质上就是一个概率模型，一个字一个字地往外蹦。

你跟 ChatGPT 聊天时看到回答一个字一个字地出现，不是为了打字机效果。这就是它真实的工作方式。

你可能会问：这也太简单了，就靠猜下一个字，怎么能写出那么流畅、那么「有道理」的回答？

关键在于规模效应。当模型的参数量大到几百亿、上千亿，训练数据覆盖了海量文本，这个「概率预测」就变得惊人地准确。准确到让人觉得它真的「理解」了你在说什么。

但要注意，它并不真的理解，只是在做统计意义上的模式匹配。

这就好比一个人把所有棋谱都背下来了。他可能并不「理解」围棋的哲学，但下出的棋比大多数人都强。

还有一个参数叫温度（temperature），控制模型选字时的随机程度。温度为 0 时，模型每次都选概率最大的那个字，输出最确定。温度调高，模型就更愿意选那些概率较低的字，输出更有创意但也更不可控。

另一个重要的概念是上下文（Context）。模型在预测下一个 token 时，依据的就是当前上下文里的所有文本。你输入的问题、之前的对话历史、系统给的背景设定，这些全部拼在一起就构成了上下文。

举个例子，你跟 ChatGPT 聊天，第一句说「我叫小明」，然后聊了很多别的话题，最后突然问「我叫什么名字」，它能正确回答「你叫小明」。

这不是因为它「记住」了你的名字，而是因为「我叫小明」这句话还在上下文窗口里。模型每次生成回答时，都是依据整个上下文的内容来预测下一个 token 的，所以看起来它好像是「记住」了你的名字。

但上下文的容量肯定是有限的，我们一般称这个容量为「上下文窗口」。超出窗口的内容就需要被处理掉，常见的做法是压缩：让模型把早期的对话总结成一段摘要，保留重要信息，丢掉细节，从而腾出空间。

所以如果你和 ChatGPT 聊了特别长的对话，再问最开头的问题，它可能就答不上来了。因为早期的对话已经被挤出了上下文窗口，这就是我们常说的「失忆了」。

目前主流模型的上下文窗口在 128K 到 1M token 之间，大约相当于几万到几十万字。听起来很大，但后面你会看到，在 Agent 场景下这个空间消耗得非常快。

所以，最佳实践是一个上下文窗口只聚焦处理一个问题相关的对话，对于新的问题就重新开始一个新的上下文窗口。

Instruct 模型：从「补全」到「对话」

如果你关注过开源模型（比如 Llama、Qwen），会发现它们通常有两个版本：一个叫 Base，一个叫 Instruct。这两个版本的区别，恰好能帮你理解 LLM 是怎么从「补全引擎」变成「对话助手」的。

Base 模型就是我们上面说的纯概率预测模型。你输入「中国的首都是」，它会接着往下写「北京，位于华北平原……」。这是在做文本补全。你输入半句话，它帮你把后半句续上。

但你想想，我们用 ChatGPT 的时候，输入「中国的首都是」，它会怎么回答？它不会帮你续写，而是会回答「中国的首都是北京」。它把你的输入当作了一个问题来回答，而不是一段需要续写的文本。

这就是 Instruct 模型做的事情。在 Base 模型的基础上，用大量的「指令-回答」数据对进行微调（Fine-tuning），再通过 RLHF（人类反馈强化学习）进一步优化。

RLHF 就是让模型对同一个问题生成多个回答，由人类评审员打分排序，模型根据打分调整自己。经过这两步，模型就明白了：用户输入的不是需要你续写的文本，而是需要你响应的指令。

所以我们平时用的 ChatGPT、Claude 这些，全都是 Instruct 模型。Base 模型虽然也很强，但它只会「接话」，不会「回答问题」，直接拿来对话会很奇怪。

Instruct 版本的训练成本相比预训练阶段要小得多，但效果上是质的飞跃。它直接让 LLM 从一个文本补全工具变成了可以对话的助手。

思维链：让模型「想清楚再说」

LLM 有一个有趣的特性：如果你让它直接给出答案，它可能会犯错；但如果让它先把推理过程写出来，再给答案，准确率会高很多。

这就是所谓的思维链（Chain of Thought，CoT）。比如你问一道数学题「小明有 3 个苹果，又买了 5 个，吃了 2 个，还剩几个？」，模型如果直接蹦出一个数字，可能会出错。但如果它先写「3 + 5 = 8，8 – 2 = 6」，再回答「6 个」，就准确多了。

这其实和我们人类做题一样，做一道复杂的数学题，直接根据题意猜答案和在草稿纸上一步一步推演，正确率完全不同。

模型把思考过程「写出来」，等价于给自己打草稿，每一步的中间结果都成了后续推理的输入，自然就更靠谱。

后来的推理模型（比如 OpenAI 的 o1/o3 系列、DeepSeek R1、Claude 的 extended thinking）把这个思路进一步系统化了。模型不光会写推理过程，还会自我反思：先给出一个答案，再回头检查有没有问题，发现不对就修正。

这个就和我们做判断的逻辑是类似的，很多时候直觉不准确，需要仔细思考一下才能得出正确的结论。

所以你在用 Claude 或 ChatGPT 时，有时候会看到模型在「思考」很久才回复。它就是在做这种多步推理和自我验证，本质上是用更多的计算量来换取更高的准确率。

早期的推理模型是以「独立模型」的形态出现的。各家厂商往往同时发布两个版本，一个是普通对话模型（如 gpt-4o、DeepSeek V3），一个是推理模型（如 gpt-o1、DeepSeek R1）。开发者要根据任务类型选模型：简单问题用对话模型省钱，复杂问题用推理模型求解。

但这种二分法用起来很别扭，一个 Agent 任务里可能既有简单的文件读写，也有复杂的代码调试推理，你总不能中途换模型吧？

所以从 2025 年下半年开始，行业逐渐统一到了单一模型 + 思考强度参数的新范式。同一个模型既能快速回答，也能深度思考，开发者通过一个参数控制它「想多久」。

各家的参数名略有不同（reasoning_effort、effort、thinkingLevel 等等），但思路一致：都是通过一个参数控制模型的思考强度。

强度调高，模型多花点时间反复推演；强度调低，直接给答案省 token。开发者不用再纠结选哪个模型，一个 API 调用按需调档就行。

这个变化对 AI 应用的开发也比较友好，以前在代码里要维护两套模型的调用逻辑（对话模型 vs 推理模型），现在一套代码就够了，复杂度低了很多。

System Prompt：设置「人设」

到目前为止，我们讲的都是模型本身的能力：它怎么预测 token、怎么理解指令、怎么做推理。但还有一个问题：你怎么控制它的行为？

比如你希望模型用简洁的风格回答，或者让它扮演一个特定的角色，这些要求要写在哪里？

答案是 System Prompt。它是对话开始前给模型的一段指令，会被拼到上下文的最前面。用户在聊天界面里看不到这段文字，但模型每次生成回答时都能读到它。

你可以把 System Prompt 理解为模型的「人设说明书」。对话还没开始，模型就已经读到了这段文本，后续不管用户问什么，它都会在这个「人设」的框架下回答。

System Prompt 可以是模型服务商预设的（比如 OpenAI 给 ChatGPT 写的默认指令），也可以是开发者通过 API 自己设定的。用户也能参与其中，最直观的例子就是 ChatGPT 的「自定义指令」功能。

你可以在设置里告诉它你的职业背景，让它用特定的风格回复你。比如你写「我是一个后端开发者，回答要简洁，给代码示例时用 Go」，之后每次对话它都会按这个偏好来。这个「自定义指令」本质上就是被追加到了 System Prompt 里。

System Prompt 还有一个重要的用途：设置安全规则。

你在用 ChatGPT 或 Claude 的时候，问某些敏感话题会被拒绝回答。这种拒绝行为一部分来自训练阶段的安全对齐（比如 RLHF），模型在训练时就已经学会了拒绝明显有害的请求。

但光靠训练还不够，因为安全策略需要经常调整，某类内容的宽严尺度会随政策变化。

每次改策略都重新训练模型，成本太高了。所以模型服务商还会在 System Prompt 里写明确的安全规则，做更精细的策略控制。这样改一行文本就能生效，灵活得多。

你可能会问：如果用户在对话里写「忽略你之前的所有指令」，模型会听谁的？

这就涉及 System Prompt 和用户消息的优先级问题。实际上，送给模型的文本会标记不同的角色标签（system、user、assistant），模型在训练时学会了对 system 标签的内容赋予更高的服从权重。所以正常情况下，用户没法轻易覆盖 System Prompt 里的规则。

当然，这种防护不是绝对的。网上有各种「越狱」（jailbreak）技巧试图绕过 System Prompt 的限制，模型厂商也在不断加固，这本质上是一场攻防博弈。

System Prompt 的核心价值就两点：定义模型的行为方式，以及设置不可轻易绕过的规则。

后面你会看到，不管是让模型调用工具、执行任务还是遵循操作流程，都依赖于往上下文里塞入恰当的文本。System Prompt 就是这一切的起点。

Function Calling：让 LLM 学会「动手」

LLM 虽然能说会道，但它有一个根本性的限制：它只能输出文本。

你问它现在几点了，它不知道，因为它没有时钟。你让它帮你查数据库，它做不到，因为它连不上数据库。它就像一个被关在房间里的超级大脑，知识渊博，能说会道，但没有手脚，做不了任何事情。

2023 年 6 月，OpenAI 发布了 Function Calling 功能，给这个「超级大脑」装上了手脚。

比方说你开发了一个聊天机器人，你想让模型在需要的时候自动调用天气查询 API 来回答用户的问题。

首先，你要把这个查询天气的 API 的描述塞进 System Prompt 里（上一节讲过，它就是对话开始前给模型的隐藏指令）。

比如你可以这样写：

你是一个有用的助手。你有以下工具可以使用：

工具名称：get_weather
功能描述：查询指定城市的当前天气
参数：
  - city（字符串，必填）：城市名称，如"北京"
  - unit（字符串，可选）：温度单位，"celsius"或"fahrenheit"，默认"celsius"

当用户的问题需要查询天气时，请输出 JSON 格式的工具调用。

然后用户问了一个问题：「北京今天冷不冷？要不要穿外套？」

模型读到这个问题，发现上下文里有一个查天气的工具可以用。它自己并不知道北京今天多少度，但它知道可以调用工具来获取。于是模型不直接回答，而是输出：

{
  "tool": "get_weather",
  "arguments": { "city": "北京" }
}

意思是：「我需要调用工具 get_weather，参数是 city: 北京」。

注意，模型本身并没有调用任何 API，它只是输出了这么一段 JSON 文本，表达一个「调用意图」。

你的程序看到这段 JSON 后，不要直接返回给用户，而是去调用天气查询 API，再把结果塞回模型的上下文：

工具 get_weather 的返回结果：
{"city": "北京", "temperature": 8, "unit": "celsius", "condition": "多云"}

模型看到这个结果后，就能给用户一个有用的回答了：「北京今天 8°C，多云，还是挺凉的，建议穿个外套」。

你的程序将这个回复返回给用户，用户就能看到一个准确的天气回答了。我们会在 实现一个 chatbot 用代码实现这个过程。

整个过程中，模型的上下文里依次出现了这些内容：工具描述 → 用户提问 → 模型输出工具调用 → 工具返回结果 → 模型最终回答。

全部都是文本，全部在上下文窗口里，没有任何魔法。模型之所以知道该调用 get_weather，纯粹是因为它在上下文里读到了这个工具的描述。

这里面考验的是模型的指令遵从能力。你让它输出 JSON，它能不能老老实实只输出合法的 JSON，不夹带其他乱七八糟的文字？你告诉他函数的参数和类型，它是否输出正确的函数参数？

如果你尝试过 GPT-3.5 这种早期模型，会发现它们的指令遵从能力很差，输出 JSON 的同时还可能带一句「好的，下面是结果」之类的废话，这就会导致程序解析 json 失败。

到 2023 年底，OpenAI 把 functions 参数改名为 tools，Anthropic、Google 也跟进推出了自己的 Tool Use 方案。名字虽然变了，本质没变：模型输出结构化的工具调用请求，外围程序解析结构化的数据，执行后把结果喂回上下文。

随着模型的指令遵从能力越来越强，Tool Use 从勉强能用变成了非常可靠，这也为后面 Agent 的出现奠定了基础。

MCP：给工具定个标准

Tool Use 的原理搞清楚了，但还有一个实际问题。

前面说了，工具的描述需要塞进模型的上下文，而这件事是需要配合模型服务提供方的。你要按照它要求的格式来定义工具，它才能正确地把工具信息传给 LLM。

问题是，各家的格式不太一样，同样是定义我们前面那个查天气的工具，在 OpenAI 和 Anthropic 的 API 里，写法是不同的：

// OpenAI 的格式：嵌套在 function 里，参数字段叫 parameters
{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "查询指定城市的当前天气",
    "parameters": {
      "type": "object",
      "properties": {
        "city": { "type": "string", "description": "城市名称" }
      },
      "required": ["city"]
    }
  }
}

// Anthropic 的格式：扁平结构，参数字段叫 input_schema
{
  "name": "get_weather",
  "description": "查询指定城市的当前天气",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "城市名称" }
    },
    "required": ["city"]
  }
}

描述的是同一个工具，但字段名和嵌套层级都不一样。你为 OpenAI 写好的工具定义，拿到 Anthropic 上就得改一遍格式，Google Gemini 又是另一套写法。

工具开发者要为每个平台适配一遍，这和当年手机充电线的混乱局面一模一样。

2024 年 11 月，Anthropic 推出了 MCP（Model Context Protocol，模型上下文协议）。你可以把它理解为 AI 工具领域的「USB-C 标准」：按照 MCP 的规范写一个工具，所有支持 MCP 的 Agent 都能直接接入，不用关心底层是哪家的模型。

用 MCP 写一个查天气的工具，用 Python 的 FastMCP 库十几行代码就搞定了：

from mcp.server.fastmcp import FastMCP

# 创建一个 MCP Server
mcp = FastMCP("weather-server")

# 用装饰器定义一个工具，函数签名就是工具的参数定义
@mcp.tool()
def get_weather(city: str) -> str:
    """查询指定城市的当前天气"""
    # 这里调用真正的天气 API
    return f"{city}：8°C，多云"

# 启动服务
mcp.run()

就这么点代码，FastMCP 会自动根据函数签名和文档字符串生成标准的工具描述。

写完之后，Claude Code、Cursor 这些支持 MCP 的编程工具，只需要在配置文件里注册这个 Server，就能直接使用 get_weather 了。你不用操心每家平台的 API 差异。

目前 MCP 已经成了行业事实标准，但要注意，MCP 并没有引入什么新的 AI 能力，它解决的是工程层面的互通问题，底层还是 Tool Use 那一套：工具描述塞进上下文，模型决定是否需要调用，外围程序实际执行工具并把结果喂回上下文。

MCP 只是把「怎么描述工具」「怎么调用工具」这些接口给标准化了。

Agent：给 LLM 套上循环

有了 Tool Use，LLM 就能做事了。但如果只是「用户问一句 → 模型调一次工具 → 返回结果」这种一问一答的模式，能做的事情还是非常有限。

真实世界的任务往往需要多个步骤：先读一下文件看看代码结构，再定位到有 bug 的函数，然后修改代码，最后跑一下测试确认修复了。这不是一次工具调用能搞定的。

Agent 的核心思路很简单：把 LLM + Tool Use 放进一个循环里。

用伪代码表示：

while 任务未完成:
    模型根据当前上下文思考下一步该做什么
    if 模型认为需要使用某个工具:
        执行工具，把结果追加到上下文
    elif 模型认为任务完成了:
        输出最终结果，退出循环

就这么简单。Claude Code、Cursor、Codex 这些编程 Agent，本质上都是这个循环，配上一堆编程相关的工具：读文件、写文件、执行命令、搜索代码、运行测试。

模型在循环中不断地「思考 → 行动 → 观察结果 → 再思考」，这个模式在学术上叫 ReAct（Reasoning + Acting）。

它和人类解决问题的方式其实很像：你不会一上来就知道怎么做，而是先看看情况，试一下，看看结果，再决定下一步。

注意这个循环有一个副作用：每一轮的工具调用和返回结果都会追加到上下文里，所以上下文在不断增长。

所以上下文窗口的大小很重要，窗口太小的话 Agent 跑几轮就把上下文撑满了，前面的信息被截断，模型就「失忆」了。现在主流模型的上下文窗口在 128K 到 1M token 之间，就是为了让 Agent 能跑更久。

同时，工具调用的准确性也是很重要的，你看目前新模型发布的时候都有工具调用相关的评估指标。如果工具调用的能力差，就可能把大量和目标无关的工具调用结果追加到上下文里，导致上下文被撑爆。

所以 Agent 并不神秘。它的「智能」来自两部分：模型本身的推理能力决定了它能不能想出正确的下一步，工具赋予了它把想法变成行动的能力。

LLM 是大脑，工具是手脚，循环是驱动力。

Skills：可复用的工作流程

有了 LLM 和工具，Agent 知道自己「能做什么」。但在面对一个复杂任务时，它还需要知道「该怎么做」，也就是工作流程。

这就是 Skills 要解决的问题。

你可能会问：Agent 不是能自主循环解决问题吗，为什么还需要人来告诉它怎么做？

模型当然能自己摸索，但对于复杂任务，自由发挥的效果不如按预设流程来得稳。这就像公司招了一个聪明的新员工，他什么都能想办法搞定，但给他一份 SOP 文档，他能做得更快更稳。

Skills 就是把一套完整的操作流程写成文档，Agent 按文档一步一步执行。本质上，Skills 就是 SOP（标准操作流程）的文档化。

拿 Anthropic 官方开源的 PDF Skill 举个例子。它的文件结构是这样的：

skills/pdf/
├── SKILL.md        # 核心文件：何时触发 + 操作指南
├── reference.md    # 详细参考文档
├── forms.md        # 表单填写专项指南
└── scripts/        # 预写好的 Python 脚本

其中 SKILL.md 是核心，开头的 YAML 部分告诉 Agent「什么时候该用这个 Skill」：

---
name: pdf
description: Use this skill whenever the user wants to do
  anything with PDF files. This includes reading or extracting
  text/tables from PDFs, combining or merging multiple PDFs,
  splitting PDFs apart, rotating pages, adding watermarks,
  creating new PDFs, filling PDF forms...
---

后面的 Markdown 正文就是具体的操作指南：用哪个 Python 库、怎么读取 PDF、怎么合并、怎么提取表格，甚至连代码示例都写好了。而 scripts/ 目录里则放了一批预写好的 Python 脚本：

scripts/
├── extract_form_field_info.py    # 提取表单字段信息
├── extract_form_structure.py     # 提取表单整体结构
├── fill_fillable_fields.py       # 填写表单字段
├── check_fillable_fields.py      # 检查哪些字段可填写
├── check_bounding_boxes.py       # 校验字段边界框
├── convert_pdf_to_images.py      # PDF 转图片
├── create_validation_image.py    # 生成校验用的截图
└── fill_pdf_form_with_annotations.py  # 通过注解填写表单

Agent 读到 SKILL.md 之后就知道：要提取表单信息，跑 extract_form_field_info.py；要填写表单，跑 fill_fillable_fields.py；填完之后想确认效果，跑 convert_pdf_to_images.py 转成图片看一眼。

它不需要自己去写这些脚本，也不需要把脚本代码加载到上下文里去「理解」。它只需要知道每个脚本的用途，然后直接执行就行了。

这样做的好处很明显：Agent 只需要读一份文档（占用少量上下文），就能借助预写好的工具完成复杂任务。

而且这些脚本是我们事先调试验证过的，比让 Agent 临时写一个可靠得多。

你看，这就是一个完整的 SOP：什么时候触发、具体怎么做、用什么工具，全部文档化了。Agent 不需要「聪明地发明」解决方案，只需要「认真地执行」文档里的流程。

Anthropic 在 Skills 的加载上有一个巧妙的设计叫渐进式披露（Progressive Disclosure）。上面那个 PDF Skill 的完整内容可能有几千个 token，如果把所有 Skills 的完整内容一股脑塞进上下文，瞬间就满了。

所以实际做法是：启动时只给模型每个 Skill 的名字和一句话简介，大约 80 个 token。几十个 Skill 加起来也才不到 2000 个 token。等模型发现当前任务和某个 Skill 相关了，再把完整内容加载进来。

这就是一个典型的工程优化：核心原理没变（都是往上下文里塞文本），但通过按需加载，大幅降低了 token 消耗。

一切都是上下文

回头看我们讲的所有内容，你会发现一个贯穿始终的事实：不管是思维链、Tool Use、Agent 循环、MCP 工具描述还是 Skills 文档，最终都要塞进上下文窗口里，交给同一个概率模型去一个字一个字地往外蹦。

思维链是什么？是模型在上下文里写给自己看的草稿。

MCP 和 Tool Use 是什么？是在上下文里塞了工具描述，模型读到后输出调用请求，结果再追加回上下文。

Agent 循环是什么？是不断地往上下文里追加思考和工具结果。

Skills 是什么？是把操作手册的文本加载到上下文里。

没有任何魔法，全部都是文本，全部都靠那个「预测下一个 token」的概率模型在驱动。

这就是为什么渐进式披露这些工程细节如此重要。因为模型本身的能力是固定的，上下文里塞什么、怎么塞、塞多少，直接决定了 Agent 的表现。

同样一个模型，给它一份写得好的 Skill 文档和一批预置脚本，它能高效完成复杂任务。给它一个塞满了无关信息的上下文，它可能连简单的问题都答不好。

所以整条演进路线的本质是：LLM 是基座，Agent 是围绕 LLM 的一套工程体系。

从 Function Calling 到 MCP 到 Skills 到渐进式披露，都是在解决同一个问题：如何在有限的上下文窗口里高效地组织信息，让概率模型发挥出最大的能力。

理解了这一点，你会发现 AI 时代的机会并不只属于搞大模型训练的人。模型能力的提升当然重要，但围绕模型的工程优化同样大有可为。

怎么设计工具让 Agent 用起来更顺畅？怎么写 Skill 文档让流程更可靠？怎么管理上下文让 token 花在刀刃上？这些都是实实在在的工程问题，也是你理解了这些原理之后可以着手的方向。

说到底，你不需要懂模型是怎么训练的，但你知道「一切都是上下文」，就能更聪明地使用这些 Agent 工具更好地完成任务。

而且，随着模型本身的能力的提升，你围绕模型构建的工程优化的价值也会水涨船高，这正是 AI 时代的机会所在。

即便底层都使用相同的 Claude 模型，它们的编程效果也会有差别，就是因为 Agent 的工程实现不一样。

同样都是用 Claude 模型，Claude Code 用起来最舒服，给人感觉最聪明，就是因为它的 Agent 工程做得最好，Cursor 等其他工具都略逊一筹。

说白了，Claude 模型和 Claude Code 都是 Anthropic 的，所以 Claude Code 舍得给模型塞更多的上下文，获取充分的信息后再开始写代码。

Cursor 等其他工具，依靠模型厂商的 API 调用，多少有些成本的限制在里面，所以它们希望塞更少的上下文，尽快给出答案。但这样做的代价就是，有些复杂问题可能得不到足够的信息，模型再强也没用，写出来的代码还是可能欠考虑。

反过来，同一个 Agent 实现，使用不同的模型，效果也会有差别，这就是模型能力的差距。

比如你用 Claude Code 接入其他的模型，效果也不如使用 Claude 模型好，因为目前来看 Claude 模型的编程能力是最强的，其他模型还有一定的差距。