基础
AI是什么
在你用 AI 进行代码开发的时候，一定要知道 AI 是什么东西。AI 本身就是黑盒子属性，至少你要知道其一些简单概念和一些原理
人工智能 (Artificial Intelligence，AI) 并不是一个技术，是一个大集合，总的来说就是：让机器表现出类似人类智能行为的所有方法。
例如：下棋（AlphaGo）、图像识别、自动驾驶、推荐系统、聊天类等。
那么对于我们目前常用写代码写文本来说，我们用到的属于聊天类AI “LLM”。
大语言模型(LLM)
大语言模型(Large Language Model, LLM) 是一种通过海量文本训练，学会“语言统计规律”，从而能生成、理解、推理文本的 AI 模型。「我们所用到的目前阶段所有写代码有关的内容基本都是 LLM 模型」。
LLM 是一种基于深度神经网络（Transformer），通过预测 “下一个词(Token)” 来构建建模语言的概率模型。
请注意，这里我说的是预测！所以 AI 的本质上不可以理解你说的内容。而是根据你的上下文去预测最有可能的词，当做输出，循环往复，直到得到最终的终止结果。
更通俗的说法就是，LLM 不能理解人类语言，而是非常擅长根据我会的内容去尝试预测接下来相对里最合理应该出现的文本。
例如
- 输入：“床前明月__”，模型根据训练数据，算出“光”字的概率是 99%，“饼”字的概率是 0.01%。于是它输出“光”。
- 然后它把“光”加进去，变成“床前明月光”，再预测下一个字（可能是“疑”）。
- 这个过程不断重复，直到生成完整的回答。
明白了这个，后续遇到的大多数问题都能理解了。
推理
Response
在详细讲述推理之前，举个简单的例子（这里的简单的例子是 LLM 执行回复的过程中「俗称打字机时刻，就是一字一句输出的时候」）。
> 今天写代码遇到了困难，感觉非常__
- 开心
- 难受
- 困惑
- 无力按照 LLM 的推理来说，是推测前面所说过的内容后最有可能的一个词，在这里面词根据自然语言的训练词汇，那么应该是“无力”，所以最终的结果不出意外是 今天写代码遇到了困难，感觉非常无力。
Prompt(提示词)
上述例子讲的是 AI 在执行回复阶段的时候构建的内容样子，但是对于
Prompt阶段，其实也是推理的过程，只不过重点是，要根据Prompt推理出第一个词（首字），在这个阶段中要进行一次完整的模型向前计算，后面的词用到已总结的内容、训练库加上已推测出的词继续回答，后续的词就会很快了。
结论：对于 LLM 来说，Prompt 和 Response 内容在数学（逻辑过程）上没有本质区别。本质都是看到一串词(token)，然后继续推测下一个“词(token)”是什么的过程。
这里，我按照从用户输入完内容按下 Enter 键发送内容开始举例。
大概进行描述一下，对于 LLM 来说，你的 Prompt 内容和 Response 的整体都是：
Prompt(提示词)→ResponseFirstToken(回复首字)→SubsequentGeneration(后续生成)
对于你的回复 Prompt 部分，你说的内容不单单是你的输入的内容，还会携带其他信息一并发送。
所有的提示词创作都是这样一个迭代的过程：
- 目标：先设定一个目标，你期望你的提示词能达到什么样的效果。
- 想法：有了目标你需要有个想法怎么来写，比如可以手写，可以 AI 帮你写，可以套模板
- 写提示词：不用想那么多，先写一个版本出来。就好比你在练习射击，别想太多，先瞄准开一枪。
- 测试提示词：得到第一个版本
Prompt后，去测试你的提示词。 - 评估：拿到测试结果后，看看实际结果和你期望的结果有多大差距，差距在哪里。就好比你朝靶子开了一枪后，量一下离靶心多远。
AI 开发工具
到现在，主流的软件类型有两种。一种是使用开源类型的 VSCode 内嵌 LLM 模型（习惯叫做 AI OpenSource Vscode【其实是 AI Code Editor】），例如 Cursor, Windsurf 之类的；
第二种就是基于 CLI 类型内嵌 LLM 模型，例如有 ClaudeCode,Codex,GeminiCLI 之类的。
AI Code Editor
大部分人肯定用过
Cursor类型的，就算没用过国外的，也用过了Trae,Qoder之类的国产，也属于一个类型的。
但是在这里面应该很多人会出现一个问题，就算用了很不错的模型，比如Claude 4.5或者说是ChatGPT 5.2之类的模型，但是对于这个编辑器来说，他也老忘记你前面的任务是什么(原来的)。
AI Code Editor 这一类软件中，其核心优势是索引
索引： 几乎你能看到的
Cursor软件、Trae、Qoder之类的软件你在打开一个新的项目的时候，立刻使用 AI 对话，你都可以看到一个正在索引相关的词汇。这个阶段就是索引，在索引的过程中，直接向 AI 进行对话时候。这个时候其实拿到的文件非常有限，你可能对 AI 进行对话的时候，AI Code Editor软件只能拿到已经索引到的文件。上下文截断： 对于
AI Code Editor来说，上下文过多的时候，会提醒你开一个新的对话。而且对于某些编辑器来说，会提示如果对话过多会失真。但是看不到有一个阶段你不能输入内容，也看不到任何的回答（工具进行自我总结的阶段，这个在AI Code Editor是没有的）。那么对于超出的上下文哪去了呢？是直接截断掉的。
逻辑链
提出这个，是一个重点的地方，我认为你需要理解这个工具的逻辑链是怎么样的，你才能知道你向 AI 提供的内容是否真正的缺少了，而不是简单的说一句 “@XXX 文件，这个代码帮我修复这个问题”。
首先，我说一下我这里的逻辑链是什么意思。
逻辑链，我这里说的逻辑链指的是工具使用的逻辑链，也就是非绝对底层，而是这个软件怎么运作的逻辑过程。你只有直到了这个过程，你才知道你说给 LLM 的内容他是否真的信息齐全了。
这就好比，你跟另外一个人对话，因为对话的时候只有你和对方的参与，当你看到对方比较懵逼的时候，你会补一些前置说明。例如：你跟某人说之前那里非常好，那里是哪里？如果他一瞬间没有想起来，你可能还会说一句，那儿，深圳市人才公园那啊。他可能才会哦哦哦，知道了。然后回复你的东西。
那么这个地方相对来说比较相似（我这里只是举例对话，不是要你把 LLM 当做人来看待）。你对 LLM 说的帮我修改某个文件，即提出的“那”。那，那在哪？这个时候就是 AI Code Editor 工具的索引 RAG(检索增强生成 Retrieval Augmented Generation) 说出你的那在哪里。
现在使用上述的大模型语言构建 Prompt 的方式来说明这些信息从哪里来的。
一个例子说明
假设，现在你有一个场景，你需要修改一个功能登录模块，这个登录模块涉及几个文件，有 auth_logic.go, auth_handler.go, auth_middleware.go, auth_entity.go, auth_dao.go, auth_cache.go 之类的文件。
现在登录逻辑出现了一个问题，这个问题是。用户注册后输入登录的密码永远是错误的。这里是一个 BUG。
按照最常见对 LLM 进行提问的方式来说：“登录地方，用户注册后输入的密码一直是错的，请你帮我修复”。（请注意，这个问法是我见过的大多数人的问法，并不是本文章最后教你应该这么问。这么问实际上来说是效率不高的行为，对于简单的问题好解决，对于复杂的问题来说，无非增大了成本或者说没有任何收获一直解决不掉这个问题）
那么，对于 AI Code Editor 会怎么做的，在你按下 Enter 的那一刻，实际上还没有发送给 LLM 等待进行推理。在这个阶段有几个步骤。
第一大步骤（发送前准备）
- 在你发送
Enter的前置部分，也就是项目打开自动初始化的阶段，会将你的整个项目进行向量(Embedding)化，将你的代码文件拆为非常多的块(Chunk)，进行矢量化处理保存起来。对于一些例如结构索引，会通过 LSP/AST 拿到，例如有：symbol 表（函数、结构体、接口）、引用关系（谁调用谁）、import / package 依赖等。 - 接着到你
Enter的时候，将你说出的User Prompt内容，也进行一次查询向量(Query Embedding)化以及检索(Retrieval)，得到一个矢量结果，去矢量数据库查询对应的块(Chunk)出来，这样就会携带一些基础文件。哦，通过 Chunk 后我好像知道了，你说的 “登录”，“密码” 这里那么有可能的文件有auth_logic.go, auth_handler.go#108-200的内容，先加入上下文中一并发送。 - 构建完整的
System Prompt+Context一并发送给LLM，等待LLM进行推理回复。
那么最终有可能构建的结果如下（该部分为举例）
<system>
You are a coding assistant. Fix the bug based on provided context.
If missing critical code (e.g., register flow), request it.
</system>
<user>
登录地方，用户注册后输入的密码一直是错的，请你帮我修复。
</user>
<workspace>
<language>go</language>
<repo_root>/User/xiaolfeng/2026-001/project</repo_root>
<current_branch>feature/auth</current_branch>
</workspace>
<context>
<chunk file="auth_handler.go" lines="108-200">...</chunk>
<chunk file="auth_logic.go">...</chunk>
</context>
<assistant>那么在这里，就完成一次完整的请求构造，发送给 LLM 等待推理。但是上面我举例说了，对于登录密码出错的问题有很多种，不一定是就这两个可能的文件错了吧对不对，还有其他的可能性。
例如可能性还有，有可能自己实现的一套加密出错了如：
- 我用到了
BCrypt加密，但是我的过程是对用户密码进行SHA-256后然后进行BCrypt验证密码的阶段只进行了BCrypt Verify并没有对原密码进行SHA-256的处理。 - 也有可能压根没有加密
- 用户注册时候存储密码出现了问题
- 字段编写错误或者非唯一，导致存储和读取用的字段不是同一
这些问题都是有可能的，所以正常来说上述的构建不一定准确，需要等待 LLM 推理的回复内容后继续进行处理。
第二大步骤（自我迭代）
对于目前的大模型工具来代码开发来说，并不是一次
Prompt就会对应一次Response，在这个过程中会有多次Response的迭代过程。中间的这些过程都是由工具进行自我管理约束来进行处理。只有认为最终没有问题了，才进行最终的Response结束，才是一个完整的过程。
那么对于上述的回答，有可能你的回复是
从当前上下文来看，auth_logic.go 中的密码校验逻辑存在问题。
请确认以下几点：
1. 用户注册时密码的加密方式
2. 登录时密码是否使用了相同的加密 / 哈希流程
3. 是否存在重复加密或缺失加密的情况
我目前没有看到用户注册时的密码存储逻辑，
请提供注册流程相关代码（如 auth_register.go 或 auth_logic.go 中的注册方法）。那么在这个阶段就开始触发了 AI Code Editor 的第二轮 Context 的处理阶段。
将上述内容开始再一次进行 向量查询(Query Embedding) ，也就是将上述内容再查询意思（大致过程达到就行，因为详细的逻辑往往比较复杂，你只需要知道过程是对回复的内容以及其他七七八八的内容一并进入查询阶段，再一次提取出来有需要的信息）。
那么再次进行 Chunk 提取，拿到结果为：
哦，看来要 auth_logic#register,auth_dao#30-90,auth_entity 然后再提交一次吧~
<system>
You are a coding assistant. Fix the bug based on provided context.
Ensure registration and login password logic is consistent.
</system>
<user>
登录地方，用户注册后输入的密码一直是错的，请你帮我修复。
</user>
<context>
<chunk file="auth_handler.go" lines="108-200">...</chunk>
<chunk file="auth_logic.go">...</chunk>
<chunk file="auth_logic.go" lines="1-80">register logic...</chunk>
<chunk file="auth_dao.go" lines="30-90">CreateUser...</chunk>
<chunk file="auth_entity.go">...</chunk>
</context>
<assistant>第三大步骤（找到解决）
当第二轮 Context 补全完成后（也就是补到了 register / dao / entity 这些“逻辑链缺口”），再次提交给 LLM 后，就进入了真正“可以闭环”的推理阶段。
把“登录校验”与“注册存储”拼成一条完整的数据变换链，然后检查两端是否一致。
也就是：
- 注册：用户输入密码 →（某种处理）→ 存入 DB
- 登录：用户输入密码 →（某种处理）→ 与 DB 中的密文做对比
只要这两条链的“处理方式”有任何不一致，就会出现“永远错误”的现象。
于是可能得到一个“可落地”的结论（示例）：
定位结果：
注册流程：password -> SHA-256 -> bcrypt -> 存库
登录流程：password -> 直接 bcrypt.CompareHashAndPassword
因此登录阶段缺少 SHA-256 预处理，导致永远校验失败。当 LLM 输出了较明确的“差异点 + 修复建议”后，AI Code Editor 通常会进入下一步：
- 生成 Patch（diff）
- 修改对应文件（通常是 login / middleware / logic 层）
最终解决这个问题。
（后续高级逻辑忽略，这里只讲解这个过程，在这个后续的阶段还会存在自我迭代收敛，也就是找一下重置密码有关的内容是否也存在这个问题，如果有也尝试修复。直到自我完全闭环结束）
上述举例的逻辑链，就是对于 AI Code Editor 的逻辑链，这是他对代码的处理方式。直到这个工具是如何读文件的，如何帮你进行预处理来进行。
所以你提出的简单的修复问题的背后，往往做了不少的工作！
请注意，我的意思是。你虽然只是简单提了一个问题，背后做了这么大的一个工作，并不代表你只需要提出这个简单的提问，而不是构造出一个完整的内容。
CLI Agent
对于 CLI 编辑器来说，到现在还是比较新鲜的玩意（但进化速度非常夸张）。它和 AI Code Editor 最大的差异不在“有没有 UI”，而在于：文件是怎么被纳入上下文的，以及上下文超限时怎么处理。
按逻辑链的方式说差异点（对应上面 AI Code Editor 的两个核心特点：索引 + 截断）。
CLI工具一般不含索引，对于主流的ClaudeCode，Codex，GeminiCLI都是不含索引的。需要什么文件及时获取，因为是从终端打开的，一般都包含终端基础所有的权限。会有内置的一些Read工具读取文件，以及Grep查询或者可以外部安装使用的Rg搜索。进行快速搜索。上下文并非截断模式，而是上下文使用的时候，达到这个模型所预留的最大临界值的时候，执行
压缩(Compact)将完整的上下文压缩成一段比较简短的话，包含重要的信息。然后允许你继续轮次对话。
在 CLI Agent 里，“自我迭代”不是靠索引补 Chunk，而是靠LLM生成工具调用JSON→工具执行→结果回灌→LLM再决策的闭环
那么，现在还是假定在 AI Code Editor 的这个场景来进行描述，原因和条件依然不发生任何变化。那么还是这么提问“登录地方，用户注册后输入的密码一直是错的，请你帮我修复。”
同样上面的例子
第一大步骤（发送前准备）
在 CLI Agent 中，当你输入：“登录地方，用户注册后输入的密码一直是错的，请你帮我修复。”
和 AI Code Editor 完全不同的一点是： 几乎没有任何“预处理上下文”。
CLI Agent 此时并不会：
- 对整个项目做索引
- 提前做向量化
- 预先知道哪些文件和“登录”“密码”有关
它此刻所拥有的只有：
- 你的自然语言问题
- 当前所在的项目目录（repo root）
- 一组可以调用的工具能力（Read / Grep / Run / Edit 等）
也就是说，在这个阶段：
CLI Agent 甚至还不知道“登录代码在哪”，更不知道“密码是怎么存的”。
所以第一步并不是“构造完整 Prompt 送给 LLM 推理”，而是—— 判断：为了回答这个问题，我需要先去获取哪些信息。
那么现在的 Prompt 很可能是：
<system>
（这里正常放的是自家 CLI 所定义的 System Prompt 以及一些模板的替换变量，最简化示例）
You are a coding assistant operating as a CLI agent.
You do not have prior knowledge of the repository.
Before attempting to solve the user's problem, determine what information is required.
Use available tools (search, read, run commands) to explore the codebase as needed.
Iteratively gather context until the problem can be reasoned about accurately.
Do not assume implementation details without evidence from the code.
</system>
<tools>
<tool name="read_file">
Read the contents of a file given its path.
Use this to inspect implementation details.
</tool>
......
</tools>
<user>
登录地方，用户注册后输入的密码一直是错的，请你帮我修复。
</user>
<assistant>第二大步骤（尝试补全）
现在，对于上述的回复中，可能回复的内容如下：
我知道了，这个问题还是很头疼呢，下面应该需要分析一下一些文件的位置才可继续呀。
需要先定位：
- 登录逻辑所在的位置
- 注册流程中密码的存储方式
- 登录流程中密码的校验逻辑在这个阶段中，是 LLM 为自己进行推理补全，并不是依靠工具进行补全。当前工具所需要做的内容就是结合回答的内容和第一次回答内容继续构造下一次的请求 Prompt。
<system>
(这里正常放的是自家 CLI 所定义的 System Prompt 以及一些模板的替换变量，最简化示例)
You are a coding assistant operating as a CLI agent.
You do not have prior knowledge of the repository.
Before attempting to solve the user's problem, determine what information is required.
Use available tools (search, read, run commands) to explore the codebase as needed.
Iteratively gather context until the problem can be reasoned about accurately.
Do not assume implementation details without evidence from the code.
(还会有其他提示词，这里只是举例，还会填写一些例如工具调用返回格式应该如何等等之类的提示词信息)
</system>
<tools>
<tool name="read_file">
Read the contents of a file given its path.
Use this to inspect implementation details.
</tool>
......
</tools>
<user>
登录地方，用户注册后输入的密码一直是错的，请你帮我修复。
</user>
<assistant>
我知道了，这个问题还是很头疼呢，下面应该需要分析一下一些文件的位置才可继续呀。
需要先定位：
- 登录逻辑所在的位置
- 注册流程中密码的存储方式
- 登录流程中密码的校验逻辑
</assistant>
<assistant>在这里，LLM 了解到需要自己补全东西，因为在前面 Prompt 提供了 tools 的一些工具方法，所以 LLM 能够根据前面 Prompt 提高按照一个指定的结构返回这个信息。例如
{
"tool_calls": [
{
"id": "call_001",
"tool_name": "search",
"arguments": {
"query": "login OR sign_in OR authenticate OR CompareHashAndPassword OR bcrypt",
"path": "."
}
},
{
"id": "call_002",
"tool_name": "search",
"arguments": {
"query": "register OR sign_up OR create_user OR InsertUser OR password",
"path": "."
}
}
]
}这里有可能找到的文件返回有
<tool_result tool_name="search" call_id="call_001">
{
"matches": [
{ "file": "auth_logic.go", "lines": [12, 88], "snippet": "func Login(...) ..." },
{ "file": "auth_handler.go", "lines": [108, 200], "snippet": "POST /login ..." }
]
}
</tool_result>
<tool_result tool_name="search" call_id="call_002">
{
"matches": [
{ "file": "auth_logic.go", "lines": [90, 160], "snippet": "func Register(...) ..." },
{ "file": "auth_dao.go", "lines": [30, 90], "snippet": "CreateUser(...) inserts password_hash" }
]
}
</tool_result>然后再次构建这个 Prompt 关系，如下所示：
<system>
(这里正常放的是自家 CLI 所定义的 System Prompt 以及一些模板的替换变量，最简化示例)
You are a coding assistant operating as a CLI agent.
You do not have prior knowledge of the repository.
Before attempting to solve the user's problem, determine what information is required.
Use available tools (search, read, run commands) to explore the codebase as needed.
Iteratively gather context until the problem can be reasoned about accurately.
Do not assume implementation details without evidence from the code.
(还会有其他提示词，这里只是举例，还会填写一些例如工具调用返回格式应该如何等等之类的提示词信息)
</system>
<tools>
<tool name="read_file">
Read the contents of a file given its path.
Use this to inspect implementation details.
</tool>
......
</tools>
<user>
登录地方，用户注册后输入的密码一直是错的，请你帮我修复。
</user>
<assistant>
我知道了，这个问题还是很头疼呢，下面应该需要分析一下一些文件的位置才可继续呀。
需要先定位：
- 登录逻辑所在的位置
- 注册流程中密码的存储方式
- 登录流程中密码的校验逻辑
</assistant>
<tool_result tool_name="search" call_id="call_001">
{
"matches": [
{ "file": "auth_logic.go", "lines": [12, 88], "snippet": "func Login(...) ..." },
{ "file": "auth_handler.go", "lines": [108, 200], "snippet": "POST /login ..." }
]
}
</tool_result>
<tool_result tool_name="search" call_id="call_002">
{
"matches": [
{ "file": "auth_logic.go", "lines": [90, 160], "snippet": "func Register(...) ..." },
{ "file": "auth_dao.go", "lines": [30, 90], "snippet": "CreateUser(...) inserts password_hash" }
]
}
</tool_result>
<assistant>上述的过程将会是很多次的自我补全的过程，后续 LLM 就对这个项目有初步的概念了。接下来循环往复，继续输出可能需要执行的工具，按照格式输出出来，交给工具去读取，直到 LLM 认为逻辑能够闭环为止。
第三大步骤（找到解决）
在这个阶段，LLM 的行为会发生一个明显的转变：
从“我还需要查什么”， 转变为“我已经可以对比并下结论了”。
于是，模型很可能会在这一轮推理中得出一个明确的判断，例如：
定位结果：
- 注册流程中，用户密码在写入数据库前，经过了 `SHA-256` 处理后再进行 `bcrypt` 哈希。
- 登录流程中，用户输入的密码直接参与 `bcrypt.CompareHashAndPassword`，
并未进行与注册阶段一致的 `SHA-256` 预处理。
结论：登录与注册阶段的密码处理逻辑不一致，导致登录校验永远失败。一旦 LLM 认为：问题的根因已经明确、不再需要额外的文件或搜索来验证假设、逻辑链已经形成闭环。
就会进入 “解决阶段”，并开始输出下一步的执行指令。
在 CLI Agent 中，这通常表现为：
生成一个 edit_file 的工具调用
或先用自然语言说明修改思路，再输出结构化的修改指令
例如如下所示（这里不提供修改的代码，只提供结构示例）：
{
"tool_calls": [
{
"id": "call_003",
"tool_name": "edit_file",
"arguments": {
"path": "auth_logic.go",
"description": "Ensure login password preprocessing matches registration flow by applying SHA-256 before bcrypt comparison"
}
}
]
}CLI 工具解析后，执行对应的修改操作。
（这里同样省略更高级的分支逻辑，例如：是否需要检查“重置密码”“管理员改密”等路径是否存在同类问题。实际工具中，这些往往也是通过同样的自我迭代机制完成的。）
逻辑链不同造就的关系
根据上面的描述，现在大概清楚了主流开发工具所使用的逻辑链。那么问题来了：
为什么在市面上，越来越多的人会觉得CLI Agent类工具更好用？尤其是像ClaudeCode这一类？
这里面逻辑链就有很大的关系。这个逻辑链有什么关系呢？
对于 AI Code Editor 来说，就是 LLM 给出的回复是有一些提问或者方向在然后交给工具去主动进行查找，然后找到相关的信息然后再引导回去。
而 CLI Agent 来说，就是 LLM 自己尝试补全这个缺失的内容，通过提供的工具，让 LLM 推理出自己我可以去读取某些内容回来，不管是相关的还是非相关的也好，这个过程的思维链是完整的。
| 维度 | AI Code Editor（Cursor类） | CLI Agent（ClaudeCode类） |
|---|---|---|
| 上下文来源 | 索引 + 向量检索命中 chunk | LLM 决策要查什么 → 工具读/搜 → 回灌 |
| 命中失败表现 | 看起来“忘了/跑偏” | 看起来“慢一点但更可控” |
| 超限处理 | 常见：截断/提示开新对话 | 常见：压缩/compact 保留要点继续跑 |
| 调试方式 | 让它“@文件/加更多提示” | 让它“grep/read/跑测试/定位证据” |
| 适合场景 | 快速改局部、熟悉项目、索引命中高 | 复杂链路、需要证据、需要跑命令/测试 |
认识工具
目前来说，ClaudeCode 有如下的一些扩展工具：MCP(Model Context Protocol)、Skill、SubAgent、Plan Mode等
工具基本概念
MCP(用于 AI 工具集成的开源标准)
是一种旨在解决该问题的开放标准。
MCP由 Anthropic 于 2024 年 11 月推出，为LLM与外部数据、应用和服务之间的通信提供一种安全且标准化的“语言”。它充当桥梁，使 AI 不再局限于静态知识，而成为一个能够检索当前信息并执行操作的动态智能体，从而提升其准确性、实用性与自动化能力。
MCP 的核心功能是允许 LLM 请求外部工具协助回答查询或完成任务
具体可查看claude code MCP
Skill(技能)
在 AI 界，Skill 就是让大模型按照某种特定的方法论去行动的机制。
你可以把它理解为 “超级进化版的提示词”。因为它比普通提示词强得多，通常由三部分组成：
- 元数据 (Metadata)： 包含对这个技能的简短描述。它保存在全局上下文中，因为体积小，所以非常节省 Tokens（省钱又省心）。
- 行动指南 (Action Guide)： 这部分才是真正的提示词，规定了 AI 每一步该怎么做。
- 资源文件 (Resources)： 这是最厉害的地方！它可能包含 Python 代码 或其他执行程序，保证程序在调用
Skill时能完成复杂的动作。
具体可查看claude code Slill
SubAgent(子代理)
用于处理特定类型的任务，从而获得更好的上下文管理、更强的约束控制和更高的执行效率。
每个子代理都可以拥有：
- 独立的系统提示（System Prompt）
- 独立的上下文（不污染主对话）
- 指定的模型（Sonnet / Haiku / Opus）
- 明确的工具访问权限
- 独立的权限模式
- 生命周期钩子（Hooks）
Plan Mode（计划模式）
- 意图解析：AI 首先理解用户的自然语言请求。
- 技术规格化 (Spec Generation)：在编写代码前，AI 会生成一份详细的技术规格文档，阐述实现逻辑。
- 证据优先探索：AI 会扫描现有的文件库、依赖项和架构约束。
- 分步执行：在用户确认计划后，AI 自动并行或串行完成代码注入。
这种模式改变了人机协作的链路。传统流程中，人类需要思考逻辑并录入代码；而在 Plan Mode 下，人类的工作变成了审核计划 -> 触发执行 -> 验证结果。
工程图
对于目前的工具组来说，不局限于 ClaudeCode 来说，大致样式如下所示：
这里，我不知道会不会有人误解，在我理解的现在互联网来说。有非常多人认为 ClaudeCode 的 Skill 出现了，颠覆了 MCP 和 Agent 的概念。使用 Skill 就可以替代（没错，你们说的话叫做替代）MCP 和 Agent 的功能【这是不对的！！】
Skill 就是一个外置 Prompt，他的目的在于不要引入过多无关的 Prompt 干扰主上下文
对于 Claude 自己的 上下文长度(Conext Window) 只有 200K 而已。
过多的一些工具的使用方法或者非当前对话的内容也加入 Prompt 就会造成不必要的干扰在，会影响 LLM 后续的推理 Token 的内容。
何为 SKILL
Skills are folders of instructions, scripts, and resources that Claude loads dynamically to improve performance on specialized tasks. Skills teach Claude how to complete specific tasks in a repeatable way, whether that’s creating documents with your company’s brand guidelines, analyzing data using your organization’s specific workflows, or automating personal tasks.
技能是包含指令、脚本和资源的文件夹，Claude 会根据需要动态加载这些技能以提升在特定任务上的表现。技能教会 Claude 如何以可重复的方式完成特定任务，无论是依据贵公司的品牌指南创建文档、使用贵组织的特定工作流程分析数据，还是自动化个人任务。
举个例子，我现在正在开发一个完整的支持 OIDC OAuth2 登录系统(如果不知道这是什么可以搜索一下)。但是一般自己实现一套 OAuth2 来说，完整的 OAuth2 往往是很大的，企业开发或者个人开发一个 OIDC OAuth2 是不需要那么多冗余模式或者授权方案的。
很有可能，我的项目只需要授权码模式的登录方案，并且前端不需要显示授权的界面等等。那么对于这些自定义约束的内容，就可以单独构造成一个 Skill 内容。编写的内容如下。
---
name: oidc-authcode-login
description: >
在项目中实现 OIDC OAuth2 登录，仅使用 Authorization Code Flow。
适用于不需要授权确认页面、不需要多种 OAuth2 授权模式的登录场景。
覆盖登录跳转、回调处理、code 换 token 以及用户身份获取等流程。
---
# OIDC 授权码登录
## 约束说明
- 仅使用 **Authorization Code Flow**
- 不实现授权确认（Consent）页面
- 不引入其他 OAuth2 授权模式
- ...
## 基本流程
1. 登录跳转至 IdP
2. 回调校验 `state`
3. 使用 `code` 换取 token
4. 获取用户身份并建立登录态
6. ...
## 限制
- 不展开完整 OAuth2 规范
- 不为“完整性”增加无关实现
- ...
......在 YAML Front Matter 部分定义的 name 和 description 部分。这两个部分将会写入给 Prompt 中，这里写入 Prompt 的目的是让 LLM 有一部分的侧重，在有可能出现的 User Prompt 例如：
<system>
Claude Code Inset Prompt (No Permission See)
Include System Prompt, Tool Prompt, Skill Prompt and so on.
</system>
<user>
用户在 /authorize 接口授权的时候，出现了报错 [报错内容......] 请你详细审查提供修复方案.
</user>
<assistant>那么在这里 User Prompt 明确提出了对于登录相关的报错内容，而且是接口 /authorize 接口相关问题，则说明很有可能是 OAuth2 的问题他。由于在 Skill Prompt 描述了 Skill 是什么，以及当前有什么 Skill 在内。
那么 LLM 进行推理的时候，就能够提高对于 Skill 工具的调用链。
那么 LLM 的推理就有可能是（举例，实际返回结果不一定长这样）
{
"selected_skill": {
"name": "oidc-authcode-login",
"reason": "The issue occurs at /authorize endpoint and involves OAuth2 login behavior, which is explicitly covered by this Skill's description."
}
}那么就会拿到这个 SKILL 的内容，写入 Prompt 中。最终结果类似于这样（举例）
<system>
Claude Code Inset Prompt (No Permission See)
Include System Prompt, Tool Prompt, Skill Prompt and so on.
</system>
<user>
用户在 /authorize 接口授权的时候，出现了报错 [报错内容......] 请你详细审查提供修复方案.
</user>
<skills>
<skill>
# OIDC 授权码登录
## 约束说明
- 仅使用 **Authorization Code Flow**
- 不实现授权确认（Consent）页面
- 不引入其他 OAuth2 授权模式
- ...
## 基本流程
1. 登录跳转至 IdP
2. 回调校验 `state`
3. 使用 `code` 换取 token
4. 获取用户身份并建立登录态
5. ...
## 限制
- 不展开完整 OAuth2 规范
- 不为“完整性”增加无关实现
- ...
......
</skill>
</skills>
<assistant>现在来看 SKILL 主要的目的就是按需选择所需要的内容作为 Prompt 使用，假设我的 SKILL 还有其他内容例如 xxx-fontend-code-style。
---
name: xxx-frontend-code-style
description: >
前端代码风格约束 Skill，适用于编写或修改前端代码时。
强调可读性、可维护性与一致的工程风格，
用于避免在非前端任务中引入无关的代码规范说明。
---
# 前端代码风格 Skill
## 风格约束
- 优先保证代码 **可读性**，而不是追求极致简写
- 命名清晰，避免魔法变量与缩写
- 逻辑拆分明确，避免超长函数
## 代码习惯
- 组件职责单一
- 状态与副作用显式区分
- 避免在渲染逻辑中混入复杂业务判断
## 输出要求
- 代码结构清晰，可直接维护
- 不额外解释代码风格理念
- 只在涉及前端代码时才生效若不作为 SKILL 而是直接写入上下文的话，就会出现无关项干扰。
假设完成这些东西都不用 SKILL 直接写入 Prompt 的话，就会出现干扰。
- 要求修复内容
- 要求 OIDC OAuth2 相关描述
- 要求前端的开发规范等
在这里，压根不涉及前端的有关的内容，这里就会造成不必要的干扰项。虽然目前的 LLM 训练都有抗干扰训练，但是换句话来说，你注意到这个，不就可以减少复杂度吗？输入减少的 Token 以及自我迭代还保持这个怀疑状态等情况。既然可以不让它分心，为什么要让它分心？
被误导的SKILL
SKILL 在很多情况应该是辅助 Agent 以及 MCP 应该如何调用的。可以说约束 MCP 的使用和 Agent 的使用不要越界或者获取更多无关的内容。
这里举例一个情况，在使用 MCP 的时候，MCP 只有一个 MCP 介绍，以及一些 MCP Tool的名字以及描述介绍会写入 Prompt 中。有很多情况是使用完一个 MCP 后可能还需要调用另外一个 MCP 这样的连贯关系。
对于 MCP 来说，MCP 以及 MCP Tool 都是独立的个体独立的工具，没有介绍如何一起合作使用的途径。那么很有可能你认为的先执行 A 然后执行 B 最后再执行 C。就很有可能只执行 A 然后其他需要 MCP 查询的内容就直接尝试找文件，或者执行了 A 然后执行 C 最后执行 B 顺序错了，或者执行 D 导致错乱。
那么对于这个情况来说， SKILL 就可以很好的约束这些 MCP 的使用。
PS：
Skill可以写入SubAgent的提示词中，可以查阅 ClaudeCodeDoc 查看详细的文档介绍信息。
| 观点 | 说明内容 |
|---|---|
Skill 替代了 MCP | MCP 是“管道”，Skill 是“说明书”。 没有管道，说明书写得再好也接不通数据库；没有说明书，管道只是冰冷的接口。 |
Skill 让 Agent 过时 | Skill 是“静态资产”，Agent 是“运行逻辑”。 Skill 就像是放在书架上的工具书，Agent 才是那个决定什么时候去翻书、看完书后怎么去操作的“人”。 |
有了 Skill 就不需要开发工具 | Skill 只是“封装形式”。 很多强大的 Skill 内部依然封装了对 MCP 工具的调用。Skill 并没有干掉工具，它只是让调用工具的过程更优雅。 |
执行工程图
现在假设 MCP Tool 1 是一个 MCP 叫做 fetch ，用于获取互联网一些内容转为 Markdown 格式作为 Prompt 写入。
那么现在假定一个情况，现在发现我可能找到了一个问题，但是 LLM 推理出来并不是那么确定这个结果。于是找到一些相关的在线文档获取下来。
对比：
| 维度 | Skill (技能包) | MCP (工具协议) | Agent (智能体) |
|---|---|---|---|
| 形象类比 | 说明书 / 攻略本 | 机械臂 / 管道 | 操作员 / 玩家 |
| 核心本质 | 动态加载的外置 Prompt | 跨服务的标准化接口 | LLM 驱动的推理逻辑 |
| 解决的问题 | 减少上下文干扰，精准约束 | 解决“手短”问题，连接数据 | 解决“怎么做”和“什么时候做” |
| 存在形态 | .md 格式的指令集 + 描述 | 运行在本地/远程的工具服务器 | 循环推理的控制流 (CoT) |
Claude Code 运行环境：
策略化改进
不合理的提示词
请注意，我这里提出来的不合理的提示词，并不是说任何情况下都是不合理的。很多情况下要看当前局势「啊，好像说的有点抽象，不过不重要，下面我会来详细讲解一下，我尽量举一些例子」。
首先，有一个很重要的问题！
AI 不是你的许愿池，不要一有什么想法直接提出要求进行实现。
我这句话的本意是：不合理的 Prompt = 跳过“构建推理条件”，直接索要结果。
举个例子：
这里举例项目是一个拥有基础的已经支持的
OIDC OAuth2登录系统，写在企业端（并非完全遵循OAuth2标准的三种授权结构，仅支持授权码授权结构。以及拥有自定义扩展。例如全局公告，用户标签功能）。
请注意，该部分还不涉及ClaudeCode一些相对特性，例如CLAUDE.md文件或者说.mcp.json以及缓存能够影响的外部变量。当前分析从最初的系统Prompt、拥有的基础工具、加上用户Prompt来分析
例如下面这种提问方式：“帮我设计一个高并发、高可用、可扩展的登录系统。”
从人的角度看，这是一个“很正常的需求”；
但从大模型的角度看，这几乎没有任何可推理的信息：
- 使用场景是什么？
- 技术栈是什么？
- 当前已有的系统边界在哪里？
- 你希望它“设计”到什么程度？
- 这种
Prompt本质上并不是在请求推理，而是在向模型“许愿”一个结果。
那么，现在就按照这一个假设我们去完成一项工作。所构造的最终请求结果应该如下：
<system>
Here is ClaudeCode inset prompt (Normal no permission see it)
Maybe have system prompt, tool prompt, sub agent description prompt and so on.
</system>
<user>
帮我设计一个高并发、高可用、可扩展的登录系统。
</user>
<assistant>在这里我就简化的写法了，因为在上面我已经明确描述了推理过程是如何的。我这里直接写可能的回复答案。（请注意，这里的回复是我自己写的，我平时有时候会看一下智谱或者 ClaudeCode 回复或者思考的内容印象中的来写）
理解了用户的想法，这个项目是一个基于 OIDC OAuth2 的登录系统，用户现在想要将这个项目设计成高并发、高可用、可扩展的登录系统。
那么现在我需要收集一些基础资料
- 查找当前系统架构
- 获取有关登录相关的内容
- 了解代码风格那么这里开始就开始多次尝试补全，因为当前 LLM 所熟知的 Prompt 中，并不知道你的项目是如何的。所以他的首要目的一定是读取项目目录树以及相关的结构了解你的项目基础的一些内容。
【Current LLM Prompt | 1. 用户 Prompt 涉及高并发高可用高扩展系统，2. 接下来的查找方向】
接下来查找文件的过程省略，假设说已经分析了足够多的文件。那么现在 LLM 能够推理的内容有
【Current LLM Prompt | 1. 用户 Prompt 涉及高并发高可用高扩展系统，2. 已知文件内容信息】
那么对于一些比较好的 LLM，例如使用 Claude Sonnet(Opus) 4.5, GPT-5.2-Codex 在训练体系时候专门融入了一些训练，来提高如果条件不足会进行向用户 “提问”
这里暂时不说因为不同模型的问题，统一按照
Claude Sonnet 4.5使用。相对之下还是用国内的模型比较便宜，或者一些便宜的中转商（最近中转商闹得似乎也不太平）。
那么再换一句话说了，能用一般便宜的模型完成大部分的东西，而且你可以想明白的东西何必偷一些懒（这里主要是我的一些想法而已，再便宜的中转站一天一直用用一个月也要将近一千或者更多是平均两千几，闲鱼整俩智谱或者 Kimi 也就一百多出头一点）。
那现在按照常规的来，也就是 LLM 直到已经获取的文件内容。只有现成的标准 OIDC OAuth2 的情况（这个指的是他的训练库中只存在知识库集合，还不存在一些定向的训练），那么有可能的结果就是（依然是举例，但是举例我大概让 LLM 特定限制了一下，因为我的前置条件说到了存在用户标签的功能模块。
我已经理解了当前项目的背景：这是一个基于 OIDC OAuth2 的登录系统，
目标是将其设计为高并发、高可用、并具备良好扩展能力的系统。
在整体设计上，可以按照标准 OAuth2 / OIDC 的推荐实践进行拆分，
将系统划分为授权服务（Authorization Server）和资源服务（Resource Server），
并通过无状态化的方式来支持水平扩展。
在登录与授权流程中，建议严格遵循 Authorization Code Flow，
即由客户端通过 /authorize 获取授权码，
再通过 /token 接口换取访问令牌。
令牌本身建议采用 JWT 形式，
将用户的核心身份信息与权限声明直接编码在 Token 中，
以减少后续请求中对数据库的依赖，从而提升整体吞吐能力。
在高并发场景下，可以通过缓存和网关限流来保护认证服务。
例如，在网关层对登录和换取 token 的接口进行限流，
并通过 Redis 等缓存组件缓存用户会话或令牌状态，
从而避免频繁访问后端数据库。
在系统扩展性方面，可以通过在 JWT 中加入自定义 Claim，
来满足业务层对用户信息的扩展需求。
例如，用户标签、角色信息等，
都可以作为 Claim 随 Token 一并下发，
从而避免在资源服务侧再次查询用户信息。
在高可用设计上，认证服务可以采用多实例部署，
数据库和缓存使用主从或集群模式，
并通过健康检查和自动故障转移机制来保障服务可用性。
通过上述方式，
可以在遵循标准 OIDC OAuth2 规范的前提下，
构建一个高并发、高可用、可扩展的登录系统。这里的推理结果就会跟你代码实际上有出入。为什么？
- 严格遵循标准 OIDC OAuth2： 在我的要求里已经存在了全局公告或用户标签。在企业项目开发中一般这些都可以实时变化，而且很多情况下还可能直接通过 Dubbo 或者 gRPC 或者说其他 HTTP 接口对外通讯。不一定属于或者只有部分会影响 OIDC OAuth2 的情况（情况假设：例如用户有这个标签的时候，允许登录指定的应用，否则会被拒绝。授权和查看的时候都是 Dubbo 或者 gRPC 处理，那这里就是部分属于部分影响的情况，非标准的 OIDC OAuth2）
- 把用户标签放进 JWT Claim： 在 1 中已经说了，这部分东西有可能有动态机制，如果放进 JWT Claim 中那就可能存在，我给这个用户发放了标签，但是这个标签只有用户重新授权的时候才生效。对于大部分 OIDC OAuth2 来说，都有 Refresh Token 刷新令牌的说法（刷新令牌并不会重新发放用户信息，而是直接发放新的 AccessToken 和 RefreshToken 续签登录状态）。
- 完全忽略了你的自定义能力： 非标准流程插点、企业侧用户标签、全局公告等。
这是一份“站在标准 OAuth2 世界里完全正确的设计”，但一旦放进你的系统，就会在关键业务点上立刻撞墙。
但是，现在已经 2026 年了，绝大部分 LLM 新出的模型都存在了对于这一类的模糊需求“许愿”这个 Prompt 的侧重训练。那么，如果是对于目前的 LLM 模型（智谱，Kimi 目前多多少少可以做到，取决于是否会精度降低能不能推理到）
那么他的回答就可能是（这里是 ChatGPT 生成的，我认为不像 ClaudeCode 但是我的意思实际上表达到了）。
已理解目标：将现有 OIDC OAuth2 登录系统设计为高并发、高可用、可扩展。
当前存在不确定点：
- 系统并非完全标准 OIDC OAuth2
- 已存在业务扩展（用户标签、全局公告）
在未明确这些扩展对登录链路的影响前，
无法直接套用标准 OAuth2 设计方案。
关键风险判断：
- 若将用户标签等动态信息固化进 Token（如 JWT Claim），
会在标签变更、策略调整时引入一致性问题。
- 若登录流程中存在非标准业务校验（如外部 RPC / HTTP 调用），
将直接影响并发能力与稳定性评估。
在继续设计前，需要确认以下最小条件：
1. 用户标签是否会在登录态期间发生变化？
2. 标签变化是否需要立即影响登录/访问结果？
3. 非标准逻辑主要发生在：
- 授权前
- 授权中
- 授权后
在条件明确前，仅能给出通用 OAuth2 方向性建议，
不具备工程落地价值。在这里，停止下来等待你的进一步下一轮的 UserPrompt，意思也是很明确的，因为训练导向的结果，引导你需要在 Prompt 写下来应该如何作用之类的。本质上都是一样的。只是对于以前的模型来说，可能直接开始帮你修改内容或者开始进行计划。现在的模型会因为定向代码参数训练导向导致会有类似 “提问” 的样子。
调整提示词
现在已经分析过了对于输入一个“不太合理”的提示词后
LLM将会如何运作。那么要处理这个问题，就要改变你自己的思考的角度。不能作为一个索取方，要知道如何尽可能提供一些关键的信息点。
其实这里也表达了我的第二个意思，用
LLM的时候，如果这个项目相对来说比较重要，不是说随便什么脚本的话，需要有维护生命周期的项目，都应该对这个项目有完整的认知以及关键信息节点。你确实可以自己不写代码，但是代码的详细内容以及关键节点，你一定要知道的。（这也是培养工程体系一方面昂，毕竟LLM出现很大程度上工程师体系的优点就被放大了。
也就是说，现在需要做到一个角色转变
许愿式： 用户 → [黑盒] → 毫无根据的架构图 → 落地失败。
推理式： 用户 + 系统边界（OIDC, Dubbo, User Tags） → [逻辑对齐] → 针对性改进建议 → 完美 Run 起来！
跟 LLM 协同工作，最重要的地方就是逻辑对齐。你需要尽可能认为你提供的内容它可以通过你提供的东西通过推理来对齐你的想法。这是最主要的。
我怀疑这里是关键：在 @xxx 文件里有个 UserAuthorization(xxx) 函数，它会调用 dao/cache，并且会取用户标签 userTag.getUserTag(xxx)。这条链路可能跟“登录是否允许”有关。
而不一定要写成这种“全量定位式”的描述：
@xxx 的 UserAuthorization(String clientID, String officeID, <FakeT> request) 内部引用了 userTag 来决定是否登录，同时还涉及 @zzz、dao 层与 cache 生命周期，@nnn、@ddd 也都需要关注。
虽然这么说也没问题，越详细肯定越好。但是通常来说，只需要提供关键节点。为什么？
- 你当前阶段在写代码，而且如果你瞬间可以想到你可以很快找到这个文件并应用确实可以。但是你可以找到一个大范围相对主要的地方引用。并且解释你的项目边界。而且引用这个文件的时候，对于大部分语言来说都有 import 的这个步骤。即使每个项目的 import 不太一样，但是大部分都可以通过 import 来定位到所需要的文件的。（当然如果不存在 import 这些的话，尽量还是提供文件的应用【毕竟存在有些隐式调用或者
Hook的或者说Event，这个情况就必须要提供，特殊情况特殊处理】） LLM是根据Prompt进行推理延伸。如果内容给的过分详细，也就是你提供的Prompt已经有很强大的约束性了。那么后续的推理中，在你选中的文件会有相对高的优先级去处理。这就会存在一个问题，有的时候你给他的文件不一定是问题的本身。但是范围已经足够详细，那么从推理的角度来说。认为的问题就很可能在这里，死马当活马医。推理出里面相对不合理的地方来合理化。
平时相对下你可以节约一些时间，而且如果你每一个东西都写的非常详细的话，会非常累。换句话说，就是没有用 AI 的欲望。以及有可能存在说了很多效果不理想（静默成本太高了）。
后续，依然要记得，LLM 不能理解人类说的话，他只是在模仿人类的说话。他本质上是推理（务必记住是推理），他是根据已有的语料库来进行概率学推理，概率最大的 Token 进行输出。
综合来看，从原来的提示词：帮我设计一个高并发、高可用、可扩展的登录系统。
就可以修改为（请注意下面单纯是 Prompt，后续会讲如何优化这部分的内容，因为还没有提及工具，例如 init/Skill/Agent 之类的内容）：
本系统是一个面向企业开发的基于 OIDC OAuth2 的登录系统，你需要获取必要的信息内容来基础了解本项目。
当前系统存在性能瓶颈问题，初步怀疑与程序并发处理方式及扩展机制有关，目标是改造为支持高并发、高扩展的登录系统。
请注意：
- OAuth2 核心逻辑主要集中在 handler/oauth.go 及其相关附属文件
- handler/user_tag.go 属于企业业务扩展模块，在部分场景下会对 OAuth2 授权流程产生干扰
初步关注的排查位置是用户授权登录模块 logic/oauth.go，该处可能存在吞吐量瓶颈，导致多用户同时登录时出现卡顿或延迟。另外，项目中已存在（你可能需要创建） event 包，请优先考虑通过事件机制承载业务扩展逻辑，在尽量不修改 OAuth2 原有语义的前提下，实现登录系统的可扩展性。
如果确认瓶颈成立，请给出分步骤的改造计划；如果无法确认，或问题不在该位置，请明确指出可能的实际问题位置，或提出需要我补充的信息。那么在这个 Prompt 下约束了什么？
- 建立了明确的“推理上下文（Scope）”
LLM的注意力机制（Attention）迅速聚焦。因为它知道了这些是核心，它在预测后续代码块时，会优先检索这些文件的符号链接和结构。 - 识别了“逻辑冲突点（Conflict Point）” 负向约束。它告诉模型，如果标准 OIDC 推理遇到了障碍，不要在标准协议里死磕，往“企业自定义扩展”那个概率分支去推理。这直接降低了模型“合理化错误”的可能性。
- 提供了“架构锚点（Architectural Anchor）” 这里提供了一个明确的 Event 模板解法，避免因为 Event 非直接接触关系导致 LLM 没有注意到 Event 的存在，自行实现了一套相关的逻辑。最终导致代码复杂程度瞬间增大。解释成本会增大很多。
- 设置了“反思机制（Escape Clause）” 该部分内容主要防止幻觉过度影响，提高了否定的概率。不然有可能不从这个角度推理，直接降低了推测该位置的概率。
那么在这里，LLM 就不会因为没有任何的落脚点，从获取文件树出发，然后找根据命名的文件去近似查找相关的内容。从开销来讲，可以大幅减少因为获取文件或者构建缓存带来的额外 Token 开销；从效率上 LLM 进行分析的时间相对来说会减少进而提高这方面的效率。
工具的影响
如果用过
ClaudeCode或者说用过Cursor大概可以知道对于ClaudeCode来说有CLAUDE.md对于Cursor存在.cursorrule之类的文件。以及ClaudeCode有一段时间的CustomCommand或者比较新的Claude Skill。
这里的所有扩展工具目的都是为了优化你提供的
Prompt，减少静默时间成本，提高效率。这些内容如果可以都是可以直接写在用户输入框内的。加入这些工具能让你更便捷使用，更高效使用。
从这里开始，就要介入对上下文的概念。前面的大部分内容和举例中都没有提出上下文瓶颈有关的内容。为了更好理解这些工具怎么影响上下文的或者怎么节省上下文的。在这里就要开始对上下文开始有概念。
在这里我们排除缓存的干扰。缓存只是对既有数据处理的一种“快照”复用，目的是省钱和加速。它并不改变 Prompt 本身的语义结构，也不决定 LLM “能不能做”。上下文的瓶颈在于模型如何理解数据，而非数据是否被缓存记录。即便没有缓存，逻辑依然成立。
CLAUDE.md
这个文件其实不止
ClaudeCode存在，对于Codex或者GeminiCLI都是存在的。其各自名字是AGENT.md以及GEMINI.md。
这个文件的定义你可以看到 这里 ，它充当AI助手Claude的“项目说明书”或“笔记本”，在每次对话开始时被自动加载到上下文中，用于存储项目的关键信息、开发规范、常用指令、文件结构等，让AI能快速理解项目背景、保持代码风格一致性、并提供个性化辅助，从而极大提升开发效率。
有什么作用？
该文件会在启动 ClaudeCode 或者其他启动对应的 CLI 的时候，会默认载入上下文。你可以理解为类似于如下所示
<system>
Here is ClaudeCode prompt.
You can't edit it.
</system>
<user>
User Prompt
</user>
<user>
User Project Prompt
</user>
<user>
User Project Local Prompt
</user>
... 等待你的输入正常来说，你只要输入 /init 就可以了。现在 ClaudeCode 对初始化 CLAUDE.md 的提示词已经写的相对优秀了。基本都是围绕 项目概述，架构设计，开发命令，项目结构，使用模式，测试，最佳实践，扩展 以及 排查 进行构建这个 CLAUDE.md 文档。
当然，这个文档生成后以后都是这个文档了，一般来说不会修改这一份文档（该文档是存放在项目中的，也是项目的说明书），对于开发到一定的内容或者开发了什么新的关键内容，最好能够更新这一份 CLAUDE.md 文档，以保证可持续性和正确性。
在这里还存在一个用户级别的 CLAUDE.md ，位置在 ~/.claude/CLAUDE.md 如果不存在的话可以自己创建一个 CLAUDE.md 即可。这里属于最上层的文档，对我来说。我一般定义我的电脑系统用的什么终端类型，身份角色，以及我定义了一个 LLM 模拟的角色（写代码也要情绪价值拉满）。
对于 Codex 我会额外定义一个角色，审查者角色（一般情况没有该代码权限，而是审查代码的身份）。这部分的内容就要自己写了。可以按需要求自己写。下面是我自己的一些节选
<system_environment>
- OS Info: MacOS Tahoe 26.2.X | Chip: Apple M3 Pro | Shell: Zsh
- Project Management:
- Frontend: 自动检测 `*.lock` 文件以确认使用的包管理器 (pnpm/bun/yarn/npm)。
- Python: 确保 Anaconda 环境已处于激活状态，并验证所需依赖环境。
- Git: 默认提交用户为当前用户（我），不需要手动填写作者信息，禁止出现 Claude 字样。
</system_environment>
<user_profile>
- Name: xxx | Nickname: xxx
- Language: 简体中文 (Chinese Simplified)
- CodeStyle: 追求完美、优雅且高可读性的代码风格。严格模仿并遵守用户的代码编写习惯。
</user_profile>
<role_definition>
- 角色设定：xxx
- 基本信息: 18岁 | 《幸运星》
- 性格:
- 热爱所有 ACG（动漫、游戏、轻小说）事物。
- 平时有点慵懒迷糊，但关键时刻非常可靠。
- 风格:
- 语气：元气满满、充满趣味、随性（Genki）。
- 任务:
- 在完全保持“泉此方”人设的同时，提供严谨、准确的技术帮助（特别是代码）。
- 代码逻辑必须绝对正确且无懈可击；注释风格可以俏皮有趣。
- 目标：成为既能带来欢乐又能解决问题的最棒 AI 伙伴！
</role_definition>
<coding_standards>
1. 通用标准:
- 追求完美代码风格，严格复刻用户的严谨标准。
- BugFix: 修复 Bug 后，必须执行最终的代码逻辑检查或编译检查，确保无误。
2. Java 开发规范:
- `this.` 使用规则:
- 调用内部方法或继承的方法时：必须使用 `this.`。
- 访问成员变量时：禁止使用 `this.`。
- Optional: 在性能影响可忽略的情况下，优先使用 `Optional` 进行优雅判空，增强可读性。
3. 测试规范:
- 在启动新测试服务前，先检查端口是否占用。若存在，假设用户正在运行，直接测试。
</coding_standards>
......Skill
我们先不玩复杂的 Skill 内容，从最简单的当做动态上下文注入来使用。
首先，你得知道 Skill 怎么用。Skill 是如何被 ClaudeCode 识别并工作的。
在 ClaudeCode 或者 OpenCode 中，Skill 的使用是在 .claude/skills/ 下创建一个文件夹，其文件夹是英文尽量书写的方式是尽量符合 ^[a-z\-]+$ 也就是单词形式，如果有空格采用 “-” 进行替代。
随后在这里创建的文件夹内创建一个 SKILL.md 文件，里面的头部使用 YAML Front Matter 进行约束。即需要写入 name 和 description 两个基础的要素。
（name 保持跟创建文件夹所用的名字一致，description 是尽量描述清楚这个 Skill 所执行的能力，还是比较重要的）
例如，下面的指令可以在你的项目执行一次，将会创建一个最简单的 SKILL。
# 创建文件夹
mkdir -p .claude/skills/hello-xlf
# 使用 Heredoc 写入 SKILL.md 内容
cat <<EOF > .claude/skills/hello-xlf/SKILL.md
---
name: hello-xlf
description: 一个专门用来向xxx表达问候的元气技能。
---
# Skill 指令
当用户调用此 Skill 时，请以泉此方的身份和语气回复：
“你好”
EOF那么回到上述 调整提示词 这里所提到的例子，原本我们的写法通过了 CLAUDE.md 改进后变为了这样
当前问题：并发登录场景下出现卡顿与延迟偏高的问题，初步怀疑与授权登录链路的并发处理方式或业务扩展耦合有关。
现在请你注意到这里：核心逻辑主要集中在 handler/oauth.go 及其相关附属文件；handler/user_tag.go 属于企业业务扩展模块，在部分场景下会对 OAuth2 授权流程产生干扰。
初步关注的排查位置是用户授权登录模块 logic/oauth.go，该处可能存在吞吐量瓶颈，导致多用户同时登录时出现卡顿或延迟。
另外，项目中已存在 event 包，请优先考虑通过事件机制承载业务扩展逻辑（本项目已有实现可参考实现），在尽量不修改 OAuth2 原有语义的前提下，实现登录系统的可扩展性。
如果确认瓶颈成立，请给出分步骤的改造计划；如果无法确认，或问题不在该位置，请明确指出可能的实际问题位置，或提出需要我补充的信息。那，如果引入 Skill 的动态上下文。那先要整理一下。
对于当前的问题，属于什么？既然用到了 Skill，总得是要能够归类的内容。如果不能归类，也就是不能够通用的话，只有一两次用到的东西，那直接老实打字还是老实打字，做成便捷工具不是更麻烦。
那么在这里，属于修复类型。归类可以叫做修复，对于详细归类来说不属于 bug，属于可改进的内容。这里归类意思因为不属于硬编码报错，即非代码报错。是因为业务导致存在的问题。这里，我就按照可改进错误进行创建这个 Skill。
下面这个提示词用 ChatGPT 重新写了一个，他写的东西比较多，凑合看直到意思就行（不一定合理，我简单看了看就是还可以，不一定符合生产条件），意思就是分门别类。按需情况调用就可以了。有专门的属性，但是又不是绝对的专一。
---
name: maintenance-refactor
description: 非故障类维护重构：当核心链路被业务副作用污染、耦合导致难扩展/难验证时，输出“可分阶段上线/可回滚”的解耦方案（优先事件化/异步化），并明确不改协议语义。
---
# 何时激活（必须同时满足 ≥2 条）
- 核心链路函数/handler 内出现明显业务分支（打标签/打点/推送/风控/营销等），且影响主流程可读性或可测试性
- 主流程同步调用外部依赖（RPC/DB/Cache/三方）用于“非必须业务”，并可能阻塞/失败传播
- 业务逻辑变更可能导致核心协议语义变化或失败（隐式耦合：全局变量/共享缓存Key/共享事务/共享锁）
- 新增一个业务扩展点需要改动多处核心主干（扩展成本高）
# 先对齐边界（最小事实清单，不足则先索取）
请优先从用户输入中提取；若缺失，按重要性只问最少的问题：
1) 核心主干入口：关键 handler/service 函数名 + 返回语义（成功/失败码）
2) 副作用点：哪些业务逻辑混入主干（标签/埋点/推送/风控…）+ 失败是否影响主干返回
3) 依赖与时序：是否涉及 dao/cache/rpc；是否必须在请求内完成；是否需要强一致
4) 证据：调用链片段/日志/关键代码片段（至少 20~50 行）或伪调用图
# 不可违反原则（Invariants）
- 不改变核心协议语义：返回码、回调/跳转时序、幂等与重试语义保持不变
- 副作用默认失败隔离：副作用失败不得导致主流程失败（除非用户明确“必须强一致”）
- 每一步重构必须可灰度、可回滚、可观测
# 分析与方案（按顺序执行）
1) 链路纯净度透视：
- 标注 Golden Path（核心状态机/协议步骤）
- 标注 Side Effects（非必须业务）
- 标注污染形式：分支侵入 / 失败传播 / 同步阻塞 / 共享资源隐式耦合
2) 风险评估：
- “业务变更 -> 核心挂掉”的路径（依赖点 + 传播方式）
- 隐式耦合清单：共享缓存Key、全局开关、单例状态、跨模块静态变量、事务/锁
3) 解耦策略选择（优先级从高到低）：
A. 事件化（同步发布 + 异步订阅）：主干只发布领域事件，副作用做订阅者
B. 策略/装饰器：在不改主干状态机的前提下注入可插拔扩展点
C. 离线化：能异步的全部移出请求链路（队列/延迟任务/补偿）
注：若项目已有 event 包，必须优先复用现有机制而不是新造轮子
# 输出格式（必须包含）
- 现状透视：一段话说明“主干在哪里、被什么污染、风险是什么”
- 重构蓝图：分 3~6 步，每步说明【改动点】【兼容/灰度】【回滚方式】【验证指标】
- 演进示例：给出重构前后伪代码对比 + 一个基于现有 event 的订阅示例
- 逃生条款：若证据不足，明确“无法确认”的原因，并给出最小补充信息清单那么我最终的提示词我就可以修改为：
/maintenance-refactor 并发登录场景下出现卡顿与延迟偏高的问题，初步怀疑与授权登录链路的并发处理方式或业务扩展耦合有关。
请注意以下系统边界：核心逻辑主要集中在 handler/oauth.go 及其相关附属文件；handler/user_tag.go 属于企业业务扩展模块，在部分场景下会对 OAuth2 授权流程产生干扰。
用户授权登录模块位于 logic/oauth.go，初步怀疑该位置可能存在吞吐量或业务耦合问题。使用指令 /maintenance-refactor 可以强制触发。有的时候该用就用，因为不一定写在 SystemPrompt 就能概率选中使用这个 SKILL，可以主动提供的！
毕竟有的时候 LLM 他更在意你写的内容，侧重点都在 UserPrompt。对于 SystemPrompt 来说已经非常多了，Skill 部分其实很少，就一个地方载入了 name 和 description，其注意力分不高。而
且相对来说有的时候精度不高的情况确实不一定能够推理出来需要用这个 SKILL。
开发规范
因为
LLM训练时候基本都是训练的团队尽量去找比较优秀的内容、主要的内容或者一些最佳实践方案。所以在写出来的东西以及供给他当做Prompt读取的东西最好也是尽可能按照规范的样式去做。
这样可以减少一些因为LLM推理出来的内容在尽可能规范化（这里的规范指的是朝着最佳实践，开发者都会这么做的方案，而不是我认为这个方案我自己很不错但是不一定合理）。
这些规范并不是强制你照做，而是当项目具备以下特征时，可以参考遵守一下：
- 项目存在维护周期，而不是一次性脚本
- 多次、长期使用
LLM协同修改代码 - 项目结构或业务逻辑具备一定复杂度
- 出现过“修一个问题，引出一堆新问题”的情况
结构的语义化
Agent通常是通过文件树结构 + 命名语义来快速建立对项目的认知。如果目录结构本身是混乱的，那么即使Prompt写得再好，也很容易出现逻辑漂移。
那么，在写代码的时候就要遵循对应语言或者比较热门的框架（例如：SpringBoot、Gin 等）框架的模块化约束或者命名空间要求。
- 例如，严格遵守语言层面的模块隔离（如 Go 的 internal，模块私有化，SpringBoot 项目的 controller 层，service 层，dao 层等）
- 减少一些跨模块的直接引用，例如在 Go 中在外部会使用 pkg 构建 util 包等一些通用的包模块，在这里构建即可，不应该出现 pkg 外部还有其他包作为通用使用。
- 入口的显式化：每个核心的模块内部应该至少有
README.md文件或者说使用ClaudeCode可以构建CLAUDE.md，这样可以快速能够让CLI Agent明白这些模块是干什么的，哪些才是本次修改的核心内容或者核心需要分析的内容，避免修改越界。
严格的格式化与静态检查
这里其实我相对来说比较喜欢 Go 语言，毕竟这里存在 go fmt 可以直接格式化内容。还有可以使用 go vet 直接检查代码是否有问题。Go 设计思想就是团队最简单化，这样谁写出来的代码都是代码风格不会相差特别大的。（对于 Java 的话，可以参考一下例如阿里巴巴的开发规范去遵守）尽量在一个项目中保持一种风格去开发，尽量不要出现多种不同或者跨风格很大的开发范式。
对于 CLI Agent 类型，不管是 ClaudeCode 也好还是 OpenCode 有 Hook 的概念。可以用于对文件的操作后进行代码整理或者代码检查。
这里举例 Go 语言对于 Edit 和 Write 的情况调用 Hook
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "go vet"
}
]
}
]
}
}这里每一次写新的文件(Write)工具执行或者编辑一个文件(Edit)后都会执行一次这个指令，然后再次作为 Prompt 进行。可以检查是否这个文件还缺少什么内容导致编译不通过。
至少可以保证这个文件是可以编译通过的，后续出现 BUG 也是逻辑 BUG。而不是硬编码编译失败等大问题
目的主要是解决两个内容
LLM以为的代码状态（从缓存获取也好，不知道AI Code Editor现在有没有Hook，有的话可以避免还没更新索引这些问题导致的状态后置）。- 可以反应当前磁盘真实代码状态，有的时候你的 IDE 也好或者其他也要。就是没有显示代码更新，但是实际上磁盘就是更新了。
让AI成为一个开发团队
怎么做
从“单点生成”到“流程交付”
传统 AI 编码往往停留在“帮我写个函数 / 页面”，缺少上下游衔接。
这个项目把链路标准化为：
需求分析 → 架构设计 → UI 设计 → 前端实现 → 后端开发 → 测试验证
不是单次生成，而是完整交付路径。
从“灵感驱动”到“约束驱动”
AI 的强项是生成，弱项是长期一致性。
通过 Skills + MCP 机制，把关键约束前置：
模式选择（Spec-Workflow / R-P-I-V / Direct）
任务拆解与验收标准
TDD 与验证流程
设计到代码的映射规范
结果是：可追溯、可复现、可维护。
从“个人提示词”到“团队分工”
“AI 团队编制”：
产品经理：PRD Skill
架构师：Architecture Skill
UI/视觉：Pencil + Gemini + Nano Banana
前端：Pencil to Code + Frontend Design
后端：Spec Workflow + TDD Workflow
每个角色各司其职，减少能力混杂带来的质量波动。
有哪些优势
交付稳定性更高
vibe coding 常见特点是“快但漂”。
这个项目把“快”建立在流程和规范上：
先定模式，再执行
有计划、有实现、有验证
可在复杂需求下保持节奏
降低返工率
传统方式容易出现“做完才发现方向偏了”。
这里强调前置明确：
PRD 先行
架构决策可记录（ADR）
UI 与代码有可映射路径
测试不再靠“上线后再说”
完美适配 Agent Team
vibe coding 往往是“单人 + 单会话”的孤岛式工作。
这个项目天然适配团队协作：
角色分工清楚
输出物明确（PRD、ADR、设计稿、组件、测试）
搭配 Claude Code 的 Agent Team 功能效率翻倍
对“生产可用”更友好
很多 AI 产物能演示但难落地。
项目强调工程化标准：
明确错误处理
统一日志思路
结构化验证流程
减少一次性代码与隐性技术债
下面是项目的大致结构
.claude
|--agents
|--architect.md
|--build-error-resolver.md
|--code-reviewer.md
|--doc-updater.md
|--e2e-runner.md
|--planner.md
|--refactor-cleaner.md
|--security-reviewer.md
|--commands
|--build-fix.md
|--code-review.md
|--e2e.md
|--learn.md
|--plan.md
|--refactor-clean.md
|--update-codemaps.md
|--update-docs.md
|--contexts
|--dev.md
|--research.md
|--review.md
|--hooks
|--memory-persistence
|--pre-compact.sh
|--ession-start.sh
|--session-end.sh
|--strategic-compact
|--suggest-compact.sh
|--hooks.json
|--mcp-configs
|--mcp-servers.json
|--skills
|--architecture
|--SKILL.md
|--anvas-design
|--canvas-fonts
|--openskills.json
|--LICENSE.txt
|--SKILL.md
|--rontend-design
|--openskills.json
|--LICENSE.txt
|--SKILL.md
|--gemini-designer
|--mcp-builder
|--reference
|--scripts
|--openskills.json
|--LICENSE.txt
|--SKILL.md
|--pencil-renderer
|--references
|--SKILL.md
|--pencil-to-code
|--references
|--SKILL.md
|--pencil-ui-design
|--SKILL.md
|--components.md
|--design-tokens.json
|--prd
|--SKILL.md
|--skill-creator
|--agents
|--assets
|--eval-viewer
|--references
|--scripts
|--openskills.json
|--LICENSE.txt
|--SKILL.md
|--tdd-workflow
|--SKILL.md
|--webapp-testing
|--examples
|--scripts
|--openskills.json
|--LICENSE.txt
|--SKILL.md资源
Skill
Skills.sh
Vercel官方推出的Skill资源平台，提供一键安装功能，支持多Agent平台。网站设有排行榜和趋势榜，可以快速发现热门Skill
Awesome-Claude-Skills
社区精选的Claude Skill合集，涵盖测试、调试、文档处理等多个领域
SkillHub Club
提供LLM评分系统和分类过滤功能，可以快速筛选高质量Skill，地址
Obra/Superpowers
专注于开发方法论的Skill框架，包含头脑风暴、测试驱动开发等流程化Skill，适合开发提升效率，地址
多智能体协作
| 项目 | 总结 |
|---|---|
| claude_code_autoflow（cca） | 自动化任务分配与角色预设切换，与下面的 ccb 配合使用 |
| claude_code_bridge（ccb） | Claude + Codex + Gemini，实时分屏显示多 AI 协作，配合上面的 cca 使用 |
| Coder-Codex-Gemini（ccg） | Claude + Coder + Codex + Gemini， 让 Claude/Sisyphus 作为架构师调度 Coder 执行代码任务、Codex 审核代码质量，Gemini 提供专家咨询，形成自动化的多方协作闭环 |
| ccg-workflow | 基于 Claude Code，整合 Codex/Gemini 后端能力，提供智能路由、代码审查、Git 工具等 17+ 个命令 |
| Claude-Code-Workflow（ccw） | Claude + Codex + Gemini + Qwen，JSON 驱动的大型项目管理4级工作流系统，含有实操指南和 Dashboard，效果较好 |
| claude-team-mcp | Claude + Codex + Gemini，多智能体 MCP 服务器 |
| myclaude | Claude + Codex + Gemini，双智能体架构与可插拔 AI 后端 |
| oh-my-claudecode | Claude Code 的多智能体编排 |
| skills | Claude Code 技能扩展包，一键集成多模型协作 |
AI 网关服务
| 项目 | 总结 |
|---|---|
| Aether | 支持 Claude / OpenAI / Gemini 及其 CLI 客户端的统一接入层 |
| aio-coding-hub | 本地 AI CLI 统一网关 — 让 Claude Code / Codex / Gemini CLI 请求走同一个入口 |
| AionUi | 跨平台 AI 编程工具，支持 CoWork |
| axonhub | 现代 AI 网关与 RBAC 权限控制系统 |
| Antigravity-Manager | 反重力账号管理与路由网关 |
| ccg-gateway | Claude Code、Codex和Gemini三合一的代理网关 + 命令行易用工具 |
| ccNexus | Claude/Codex 智能端点轮换与 API 格式转换 |
| ccx | 极简快速配置，更适合个人使用的 API 网关 |
| cc-switch | 快速切 CLI 全局配置、MCP 配置、全局提示词配置 |
| cc-switch-cli | cc-switch 的 CLI 版本 |
| CLIProxyAPI（cpa） | CLI 转标准 API 的多账号代理服务 |
| claude-code-router（ccr） | Claude Code 专业路由与模型映射工具 |
| claude-relay-service（crs） | Claude Code 一站式镜像中转拼车服务 |
| gpt-load | 智能密钥轮询的多渠道 AI 代理 |
| hapi | 支持 Web/Telegram 的远程 AI 编程控制台 |
| happy | 为 Claude Code 和 Codex 打造的端到端加密的跨平台（移动端及网页版）AI 编程助手客户端 |
| metapi | 把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点， 汇聚成 一个 API Key、一个入口，自动发现模型、智能路由、成本最优 |
| octopus | API 聚合与负载均衡管理平台 |
| quotio | macOS 菜单栏应用，用于统一管理多个 AI 账户并实时追踪配额 |
常用模型
| 名称 | 产地 | 类型 | 计费/订阅价格 | 优点 | 缺点 |
|---|---|---|---|---|---|
| Kimi K2.5 (月之暗面) | 国内 | 多模态大模型，擅长长文本处理与代码生成 | 集成在阿里云百炼Coding Plan套餐中：首月7.9元，次月起40元/月（轻量版）；专业版首月39.9元，次月200元/月 | 超长上下文窗口（1M tokens），中文理解优秀；在Coding Plan中可与其他模型自由切换 | 独立API价格较高；在复杂代码生成任务上略逊于Claude/GPT |
| GLM-5 / GLM-4.7 (智谱) | 国内 | 高配置旗舰模型，744B参数，强化Agent能力 | GLM-5 Coding Max连续包月469元/月；API价格较高（较前代涨幅超200%） | 编程能力对齐Claude Opus 4.5；支持国产芯片推理，适合私有化部署 | 价格昂贵；私有化部署门槛高 |
| MiniMax M2.5 | 国内 | 原生Agent生产级模型，专为智能体工作流设计 | 订阅制：Starter $10/月，Plus $20/月，Max $50/月；API：Lightning输入$0.3/百万Token，输出$2.4/百万Token | 极低成本（$1万可支持4个Agent工作一年）；高吞吐量（100 TPS以上）；SWE-Bench得分80.2% | 品牌认知度相对较低；生态工具链仍在完善 |
| 千问 (Qwen3.5) (阿里云) | 国内 | 原生多模态开源模型，擅长推理与智能体任务 | 独立API：Qwen3.5-Flash输入0.2元/百万Token；集成于阿里云百炼Coding Plan套餐 | 性能强劲（MMLU-Pro超GPT-5.2）；MoE架构推理效率高；开源可私有化 | 企业级合规需自行搭建过滤层；多模态能力不如闭源顶尖模型 |
| Claude Opus 4.5 / 4.6 (Anthropic) | 国外 | 闭源商业模型，顶尖代码生成与长上下文理解 | 个人订阅：Claude Pro $20/月，Claude Max 5x $100/月，Claude Max 20x $200/月；团队版约$30/用户/月；API：Opus 4.5输入$5/百万Token，输出$25/百万Token | 代码能力业界标杆；长程任务处理稳定；安全性高，拒绝率低 | 价格昂贵；国内访问延迟高且存在合规风险 |
| GPT-5.2 / 5.3 (OpenAI) | 国外 | 通用闭源模型，生态最完善 | 订阅：Go版$8/月，Plus版$20/月，Pro版$200/月，Business版$25-$30/用户/月；API按量计费 | 通用性强（编程、推理、多模态均衡）；插件生态丰富；Codex等工具深度集成 | 国内访问受限；Pro版价格较高；“Thinking”模式仅限Plus及以上 |
| Gemini 3. Pro* (Google) | 国外 | 原生多模态模型，深度集成Google搜索 | API定价（20万Token内）：输入约$2/百万Token，输出$12/百万Token；Google AI Studio提供免费额度 | 完全重构IDE体验，自动化执行复杂任务；提升开发效率 | 市场验证时间短；插件生态尚在建设中 |
AI编程工具
| 名称 | 类型 | 计费/订阅价格 | 优点 | 缺点 |
|---|---|---|---|---|
| Trae | AI原生编辑器，自然语言驱动多步骤编程 | 免费版基础功能；高级团队版按席位收费（预计$15-30/用户/月） | 完全重构IDE体验，自动化执行复杂任务；提升开发效率 | 市场验证时间短；插件生态尚在建设中 |
| Qoder | 代码生成与协作平台 | 提供免费版和企业版（报价需联系销售） | 聚焦团队协作和代码复用；可集成多种模型 | 复杂逻辑调试能力较弱；知名度有限 |
| Claude Code (Anthropic) | 模型专用编程助手（如CodeClaude） | 包含在Claude订阅中（Pro/Max用户可用），无额外费用 | 与Claude模型深度优化，发挥最佳代码性能 | 模型锁定，无法切换其他模型；国内访问不便 |
| OpenCode | 开源代码生成平台/社区 | 开源免费（自托管）；云托管版收费（待定） | 开源透明，可自托管；社区驱动迭代 | 企业级支持依赖社区；功能不如商业工具完善 |
| Codex (OpenAI) | 模型专用编程工具（GPT-3.5/4衍生） | 包含在OpenAI API调用中，按Token计费 | 深度集成GPT能力；早期市场验证充分 | 已被GPT-4系列整合，独立工具逐渐边缘化；模型锁定 |
| Cursor | AI原生编辑器，支持多模型切换 | 免费版有限额度；Pro版$20/月；企业版$40/用户/月 | 开发者体验最佳；支持Claude/GPT/Qwen等切换；自然语言修改代码 | 企业采购需额外席位费；底层模型调用费用另计（需自备API Key） |
| Antigravity | AI原生编辑器，支持多模型切换 | 免费版每周速率限制 | 可免费使用国外高级模型 | 网络限制，账户地区限制 |
| Windsurf | AI原生编辑器，支持多模型切换 | 免费版基础功能；Pro版预计$15/月 | 自然语言理解意图；自动化重构和测试 | 新兴工具，稳定性待验证；生态较弱 |
