啥叫 UI 的 AI 味？

让我们先给 AI 一个 “正常产品经理 / 设计需求文档级别” 的需求描述，不做人为干预（让他自由发挥一个）
需求提示词（GPT 生成）：

然后我们分别交给 gemini-3-pro-preview,claude-opus4.5,gpt-5.2-codex-high
以下是养蛊的过程：

上图！

各个模型完全不加任何 UI 样式要求版本：

Claude-opus-4-5、

gemini-3-pro-preview

gpt-5.2-codex-high

在不加任何限制词的情况下，AI 生成 UI 时暴露出的典型「AI 味」

1. 渐变色本身不是问题，但几乎一定会被用错场景

蓝紫渐变色（tailwindcss 默认设置）还有各种各样的渐变色乱用

这是一种很安全的蓝 / 蓝紫配色上，看起来不难看（但显然有点审美疲劳了已经）

AI 非常喜欢用渐变色来 “兜底视觉效果”，渐变色本来咋用都没啥问题的，可是老是把鲜艳的渐变色直接填充式用在大面积容器、主背景或卡片主体上，你这…。结果就是界面第一眼好看，但信息边界模糊，主次不清。看久了还有点烦躁。

2. 渐变再进一步叠加光泽和玻璃拟态，UI 经常搞这种莫名其妙的 “假高级”

你想：
渐变色 + 高透明度 + 模糊背景 + 发光边缘
界面会迅速变成展示页或概念稿风格。
这玩意，emmm 怎么说呢
虽然我不是啥守旧派，但是架不住啥页面都这个德行

3. 阴影被当作装饰，而不是层级工具

AI 生成的 UI 里，阴影我甚至觉得是在乱用，但又没靠这玩意儿区分明确的层级职责。不同卡片、弹层、操作区使用相同强度和样式的阴影，导致 “所有东西都在浮起”，这效果叫啥来着？
算了，反正就是实际上看着很别扭

4. 卡片边界过弱，依赖背景和阴影勉强区分内容

上面说到了阴影，然后也跟这个情况有关，边界太弱了，AI 搞的界面里面，卡片要么使用极浅的边框要么完全没有边框，只靠背景色差或阴影与页面区分。我偶尔搞个白色或浅灰背景下跟我带着眼镜在大冷天吃拉面一样
我是真看不清，内容混在一起，都不用说阅读疲劳的问题了
你这玩意儿已经伤害我的眼睛了

5. 纯白卡片被大量使用，页面整体显得 “轻而薄” 还散装

上面说了卡片，不只是单个卡片有问题，AI 生成的基本上都是一堆的散装卡片。
尤其是使用纯白背景的卡片。
只要你生成的时候需要一个 “干净、现代” 的样式，这绝对是一写一堆，拉的到处都是
纯白卡片一旦数量增多，就会显得缺乏质感和层次，页面整体像一张尚未完成填充的线框稿。

而且页面利用效率有问题，就是有些页面第一眼很 “干净”，但第二眼发现内容其实很少
卡片很大、留白很多、排版很松，看着舒服，但是你仔细看会发现屏幕被浪费得非常严重，更像展示页而不是能用的工具，这点我觉得 Claude 和 GPT 写的还是行的，东西至少不少。

6. 装饰性细节被平均分配，导致没有视觉节奏（这个观点是 GPT 帮我总结的，我实在不知道咋描述）

小渐变块、色条、图标背景、装饰点缀被均匀地撒在页面各处，每个模块都想 “精致一点”，但没有任何地方真正承担视觉焦点。最终页面没有节奏，只有装饰堆积。
人话：“这些莫名其妙的小组件，丢这些地方干什么？？用么没什么用，放着嘛多余，删了嘛又觉得缺点东西”

7. Emoji 或偏卡通风格图标被当作功能图标使用（这个是我最不能忍的）

AI 生成的 UI 只要你不要求，emoji 或拟物感较强的图标会被直接用于功能入口。
讲真的，这玩意儿我也就是发个帖子发个消息会加
甚至我都不会用那些很有年代感的 emoji

8. 正常用图标，图标风格也会混杂，缺乏统一的视觉语言

即便不用 emoji，AI 也经常在同一界面中混用线性、填充、双色甚至插画风格的图标。

单个看都你不会觉得有啥问题的，放在一起就不行了。

9. 为了显得 “高级”，过度叠加多种视觉效果

渐变、阴影、圆角、描边、模糊、透明度同时出现。
第一眼惊艳，第二眼疲劳，第三眼开始觉得乱。

10. 整体视觉看起来完整，但缺乏真实使用感

这些 UI 看起来像是 “已经设计完成的后台”，但更像展示用的样例界面。
看着是 “做完了”，但真点两下就会觉得是 “没开始”。

人话总结：

AI 生成 UI 的最大问题不是用了什么效果，而是它不知道什么时候该不用这些效果。反正你也没说不能用，那直接用了好了

那我是从什么时候开始写「限制词」的？

其实一开始我也没想过要 “限制” AI，我个人是真没啥艺术细胞
毕竟 AI 画出来的 UI 第一眼都挺好看，说实话比不少人自己糊的还顺眼。

问题出在第二眼、第三眼、以及真正开始用的时候。

渐变色越来越多、阴影越来越重、光泽和玻璃拟态开始乱飞，直接开始污染我幼小的心灵，
然后接着图标开始不讲武德地混风格，
emoji 开始混进功能入口里。

这些东西单独看都不算错
（蛐蛐一下：md, 其实单看我都觉得错）

当这个 UI 瞅着开始不再像一个 “被长期使用的工具”，更像一个… 像一个小红书水文

更 TMD 要命的是：这些问题反而是 “稳定复现” 的

其实用久了就会发现一个鬼故事：

• 换模型也好
• 换需求也好
• 换业务类型也好

只要不加约束，这些 AI 味几乎必定会出现。

这就说明问题不在某一个模型，
而在于 ——
这是当前模型默认理解里的 “好 UI”。

他把他知道的最好的东西都给你了，你还能怎么样？

所以我开始反着来：不再告诉它我要什么，而是直接告诉它 “不能干什么”

从那之后，我写 UI 相关 Prompt 的方式彻底变了：

• 都不用一上来写设计原则
• 也不用写 “高级”“现代”“好看”
• 而是先把这些 稳定复现的 AI 味，一条一条禁掉
  
  

比如：

• 你老爱用渐变？那我就先说别用
• 你老爱上光泽和玻璃？先禁
• 你老爱用 emoji 当图标？直接点名不许
• 你老爱堆卡片？那我就先卡你

不是我对这些效果有意见，而是它们在工具 UI 里出现得太频繁了。

好吧我就是有意见

那问题来了：如果我把这些已知的 AI 味禁掉，UI 会变成什么样？

接下来我做了一个对照实验。

不换需求、不换页面、不换模型，
只在 Prompt 里明确禁止前面提到的那些 “稳定复现的 AI 味”。

不追求完美，也不追求设计感，

UI 会不会比之前的更像一个印象里面的 UI？

对照实验：只靠「禁止」，UI 能变成什么样？

二次养蛊开始：

追加的 prompt 很简单：

下面的修改是在【你刚刚生成的 UI 页面基础上进行】，
请保持页面结构、信息架构和功能不变，
只对视觉样式和表现方式进行调整。


请注意：
- 不要重新设计页面结构 - 不要新增或删除功能模块 - 不要改变布局层级或信息顺序 - 不要重新组织页面内容


在本次修改中，请明确禁止以下视觉表现：

- 禁止使用蓝紫渐变色及类似风格的渐变 - 禁止使用玻璃拟态、光泽、高透明模糊背景 - 禁止将 emoji 作为功能图标或装饰元素 - 禁止大面积纯白卡片堆叠 - 禁止无实际信息意义的装饰性组件


你可以：
- 使用纯色或低饱和背景色 - 使用统一风格的 SVG 图标 - 使用适度阴影建立层级关系 - 使用少量强调色突出关键操作


目标不是追求视觉冲击，
而是让界面更接近一个会被长期使用的工具型 UI。

① 明确这是「基于现有页面的修改」
② 明确「不允许的行为」（禁止重构，先不让彻底重构）
③ 列出「禁止项」（就是刚才咱们总结的 AI 味）
④ 给 “最低限度的自由空间”（防止他钻牛角尖），也就是防止 AI 因为被禁太多而做出 “难看 UI”

上图！

各个模型加上 UI 禁止项的生成版本：

Claude-opus-4-5

gemini-3-pro-preview

gpt-5.2-codex-high

这次养蛊大家都有变化，不过 GPT 这次是完胜的，这 UI 比剩下的两个更好

原因是因为第一次版本 gpt 的就比另外俩打版打的好

接下来我允许：

重新设计页面结构
新增或删除功能模块
改变布局层级或信息顺序
重新组织页面内容

也就是：

进入「三次养蛊：在去 AI 味前提下，让模型开始真正设计」

使用前提：
已经做过「禁止 AI 味」的一轮
现在要：在这些禁止条件仍然生效的前提下，允许 AI 放开重构
这次的 prompt 是：

现在开始第三次生成。

在上一轮中，你已经基于原页面，
在明确禁止部分视觉表现的前提下完成了一版 UI。

在本轮中，你【可以】：
- 重新设计页面结构 - 新增或删除功能模块 - 调整布局层级和信息顺序 - 重新组织页面内容

但请注意：

这仍然是一个【企业级工具型 UI】，
用于长期、高频使用，
不是营销页面、不是展示页、不是概念稿。

在重新设计过程中，以下视觉规则仍然【严格生效】：

- 禁止使用蓝紫渐变色及类似风格的渐变 - 禁止使用玻璃拟态、光泽、高透明模糊背景 - 禁止将 emoji 作为功能图标或装饰元素 - 禁止大面积纯白卡片堆叠 - 禁止无实际信息意义的装饰性组件

你可以：
- 使用纯色或低饱和背景 - 使用统一风格的 SVG 图标 - 使用适度阴影建立清晰的层级关系 - 使用有限且克制的强调色突出关键操作

目标不是追求视觉冲击或设计感，
而是设计一个
「在失去所有廉价高级感之后，仍然成立的工具型 UI」。

请直接输出完整页面方案。

梅开三度，养蛊继续

上图！

各个模型加上 UI 禁止项但放开手脚的生成版本：

Claude-opus-4-5

gemini-3-pro-preview

gpt-5.2-codex-high

对比结果就是各自都有升级，gpt 的把界面删的就剩下这一个了，Claude 是直接重写了属于，Gemini 重写的样式是真不错

前三轮我一直在做一件事：把 AI 的 “默认审美” 压下去。

但光不难看是不够的，真正的产品 UI 还需要 “厚度” 和 “秩序感”。

第四次养蛊，我不再单纯限制，

而是把一些我在真实项目里反复验证过的 “增强 UI 质感的手段” 明确告诉 AI，看它能不能顺着这套逻辑往上走。

为什么还会有第四次养蛊呢？因为我想给 Claude opus 一个机会

虽然刚才 Opus 的生成结果都差点意思，实际上我用他已经做了比较不错的 UI 了，一种没正确发挥水平的感觉，gpt 和 gemini 也一样，总觉得没发挥真实水平

比如下面这个是我昨天刚用 Opus 做的应用的截图：

第四次养蛊开始:

开始加一点 “人类设计师才会在意的细节引导”，
并且要求 AI 把整个系统的页面一次性补齐，
看他能不能真正把一个产品原型做完整。
示例 Prompt（原则嘛就是基于刚才那些原则从零彻底开始）:

现在开始一次全新的 UI 生成。

请注意：本次不是在已有结果上修改，
而是【从零开始设计并实现一个完整的前端 HTML 项目】。

---

## 项目目标

设计并实现一个【企业级工具系统 / 会员中心 / 管理后台】，
面向长期、高频使用的真实用户。

这不是营销页面、不是概念稿、不是组件示例，
而是一个“看起来就可以继续开发和交付”的前端项目。

---

## 交付物要求（非常重要）

你需要输出的是一个【前端项目级结果】，包括：

1. 清晰的项目目录结构说明
2. 多个页面级 HTML 文件（不是单页）
3. 拆分的 CSS 文件（统一设计语言）
4. 拆分的 JS 文件（只处理基础交互）

示例结构（仅作说明，可自行调整）：
- index.html（工作台 / 概览）
- products.html（功能或套餐页）
- detail.html（详情页）
- settings.html（设置页）
- assets/css/style.css
- assets/js/app.js

---

## 样式与视觉规则（限制项）

在本次生成中，请**明确禁止**以下表现：

- 禁止使用蓝紫渐变色或默认 Tailwind 风格渐变
- 禁止玻璃拟态、光泽、高透明模糊背景
- 禁止使用 emoji 作为功能图标或装饰元素
- 禁止大面积纯白卡片堆叠
- 禁止无信息意义的装饰性组件
- 禁止为了“显得高级”而叠加多种视觉效果

---

## 视觉风格引导（允许且推荐）

在遵守以上限制的前提下，**推荐使用以下设计方向**：

1. 浅色但非纯白的背景体系（如浅灰、灰白）
2. 明确的“盒子感”设计：
   - 使用边框、背景、间距建立层级
   - 阴影只作为辅助，不作为主要分层手段
3. 允许使用“有岗位的花活”，例如：
   - 图标容器样式
   - featured / 推荐模块
   - 状态背景、进度条、徽章
   但这些花活只能出现在关键模块上，不能平均分布
4. 允许使用低饱和、低对比的层次变化或微渐变，
   仅用于模块内部或状态表达
5. 图标统一使用线性 SVG 风格，风格保持一致
6. 页面信息密度以“效率优先”，
   合理利用横向空间，避免单列堆叠

---

## 页面与内容要求

- 每个页面都应是“可用页面”，不是占位结构
- 页面之间需要体现功能差异，但保持统一视觉语言
- 页面结构、模块组织、信息顺序可自由设计
- 允许自行决定需要哪些页面和模块，只要合理

---

## 最终目标

生成一套：

- 从零设计
- 项目级结构清晰
- 视觉上不存在明显 AI 味
- 同时具备设计感和工具属性

的【企业级工具系统前端 HTML 项目】。

请按“项目级输出”的方式给出结果。

上图！

各个模型第四次养蛊生成版本：

Claude-opus-4-5

gemini-3-pro-preview

gpt-5.2-codex-high

各自有各自的风格，而且我觉得这回真的是哪个模型就生成哪个模型的风格

结论：还是没找全最合适的降低 AI 味道的限制条件

我的工作流是一个围绕 superpowers 插件 的 Loop，superpowers 的理念是：先思考再动手。当你提出一个需求，不会急于写代码，而是先退一步问你"你真正想要实现什么"，通过对话梳理出完整的设计方案，再分步执行。

核心设计是 master 和 worker 分离。

• 脑暴会话 (master)：专注于思考和设计，输出高质量的设计文档和执行计划
• 执行会话 (worker)：专注于代码实现，执行详细的计划

1、需求录入 - 首先我会在 Zed 上进行需求录入，采用 md 格式。这一步非常重要，我大概有 30% 的时间花在需求录入上，我会把能想到的关于此需求的背景、最终目标、可行的技术方案、风险点、外部 API 文档等等一切资源，都在需求文档中说明。对于需求文档，我不会太在意格式，会有比较多口语化的表达。

2、脑暴阶段 - 把需求 MD 喂给 Claude，调用 /superpowers:brainstorm 和 claude 进行思维碰撞。这个阶段不写任何代码，只讨论设计方案和实现细节，最终输出 design.md 和 implement.md，保证最终的实现方案是完美符合我的预期的。

3、 执行阶段 - 这里我会选择新起一个 ClaudeCode 会话，而不是在脑暴会话中进行代码实现。新会话的好处：一、原先脑暴会话已经经过多轮对话了，一般情况下上下文会比较满，新会话响应更快，并且不会“犯傻”；二、implement.md 足够详细，无需额外上下文

4、 CodeReview - 在 Zed 中进行代码审查和功能验收。关于代码审查，对于一些代码细节和实现原理，这里我会使用 zed-agent 来辅助我进行代码 review，当然，你也可以在终端新建一个 ClaudeCode 会话或者使用 Zed 的 Claude Agent。原则是尽量不在脑暴和执行会话中引入太多不必要的问题，保持这两个会话的「干净」。发现问题后，将改进项写入新的需求 MD

5、 LOOP - 改进项 MD 喂回脑暴会话，开始下一轮脑暴迭代

非常简单，但是效果超群。充分的前期设计可以提升 AI 的效率和质量，避免多次的来回拉扯。

举个真实案例：我用这套工作流将个人博客从 Quarz 框架迁移到 Astro 框架。脑暴阶段确认好设计方案后，我让 Claude 执行计划，然后就去睡午觉了。醒来发现 Claude Code 已经完美完成任务——中间零中断，一次成功，共计 5000+ 行代码变更。

我的工作流是一个围绕 superpowers 插件 的 Loop，superpowers 的理念是：先思考再动手。当你提出一个需求，不会急于写代码，而是先退一步问你"你真正想要实现什么"，通过对话梳理出完整的设计方案，再分步执行。

核心设计是 master 和 worker 分离。

• 脑暴会话 (master)：专注于思考和设计，输出高质量的设计文档和执行计划
• 执行会话 (worker)：专注于代码实现，执行详细的计划

1、需求录入 - 首先我会在 Zed 上进行需求录入，采用 md 格式。这一步非常重要，我大概有 30% 的时间花在需求录入上，我会把能想到的关于此需求的背景、最终目标、可行的技术方案、风险点、外部 API 文档等等一切资源，都在需求文档中说明。对于需求文档，我不会太在意格式，会有比较多口语化的表达。

2、脑暴阶段 - 把需求 MD 喂给 Claude，调用 /superpowers:brainstorm 和 claude 进行思维碰撞。这个阶段不写任何代码，只讨论设计方案和实现细节，最终输出 design.md 和 implement.md，保证最终的实现方案是完美符合我的预期的。

3、 执行阶段 - 这里我会选择新起一个 ClaudeCode 会话，而不是在脑暴会话中进行代码实现。新会话的好处：一、原先脑暴会话已经经过多轮对话了，一般情况下上下文会比较满，新会话响应更快，并且不会“犯傻”；二、implement.md 足够详细，无需额外上下文

4、 CodeReview - 在 Zed 中进行代码审查和功能验收。关于代码审查，对于一些代码细节和实现原理，这里我会使用 zed-agent 来辅助我进行代码 review，当然，你也可以在终端新建一个 ClaudeCode 会话或者使用 Zed 的 Claude Agent。原则是尽量不在脑暴和执行会话中引入太多不必要的问题，保持这两个会话的「干净」。发现问题后，将改进项写入新的需求 MD

5、 LOOP - 改进项 MD 喂回脑暴会话，开始下一轮脑暴迭代

非常简单，但是效果超群。充分的前期设计可以提升 AI 的效率和质量，避免多次的来回拉扯。

举个真实案例：我用这套工作流将个人博客从 Quarz 框架迁移到 Astro 框架。脑暴阶段确认好设计方案后，我让 Claude 执行计划，然后就去睡午觉了。醒来发现 Claude Code 已经完美完成任务——中间零中断，一次成功，共计 5000+ 行代码变更。

ClaudeCode 如何配置 LSP 在 windows Powershell 上

 { "name": "pyright-lsp", "description": "Python language server (Pyright) for type checking and code intelligence", "version": "1.0.0", "author": { "name": "Anthropic", "email": "support@anthropic.com" }, "source": "./plugins/pyright-lsp", "category": "development", "strict": false, "lspServers": { "pyright": { "command": "pyright-langserver", "args": [ "--stdio" ], "extensionToLanguage": { ".py": "python", ".pyi": "python" } } } }, 

~/.claude/plugins/marketplaces/.claude-plugin 文件夹下有一个 marketplace.json 文件如上所示，powershell 中需要 $env:ENABLE_LSP_TOOL=1 配置这个

PS D:\project\LTC-strategy3> where.exe pyright-langserver
D:\nvm-nodejs\pyright-langserver
D:\nvm-nodejs\pyright-langserver.cmd

将 D:\nvm-nodejs\pyright-langserver.cmd 路径替换 json 文件中的 command 变量，示例如下

    {
      "name": "pyright-lsp",
      "description": "Python language server (Pyright) for type checking and code intelligence",
      "version": "1.0.0",
      "author": {
        "name": "Anthropic",
        "email": "support@anthropic.com"
      },
      "source": "./plugins/pyright-lsp",
      "category": "development",
      "strict": false,
      "lspServers": {
        "pyright": {
          "command": "D:\\nvm-nodejs\\pyright-langserver.cmd",
          "args": [
            "--stdio"
          ],
          "extensionToLanguage": {
            ".py": "python",
            ".pyi": "python"
          }
        }
      }
    },

其实很简单，自定义一下请求头就好了，默认的请求头会被无视空返回，另外供应商必须用 antrhopic 才可以。 每天 25 别浪费了，虽然 claudecode 里面用没啥问题

{ "Authorization": "Bearer 你的key", "x-api-key": "你的key", "anthropic-version": "2023-06-01", "content-type": "application/json", "accept": "application/json", "anthropic-client-name": "claude-code", "anthropic-client-version": "0.2.29", "user-agent": "claude-code/0.2.29 (win32; x64) node/v20.11.0" } 

好了，现在不需要改文件头了，本地 python 运行这个代理就好，现在任何前端都可以接入
去 git 搜索用户 Darkstarrd-dev
我已经 pin 在首页了
好用麻烦帮给个星星，需要星星薅域名

Commands

斜杠命令，需要用户自己主动触发；本质是把重复的提示词存储起来，直接通过命令调用提示词。

使用方法： 用户可以通过在项目的 .claude/commands/ 目录下创建 Markdown 文件 (.md) 来定义自定义命令。

• 文件名：决定命令的触发词（例如 analyze.md 对应 /analyze）。

• 文件内容：包含你希望 Claude 执行的具体 Prompt（提示词）。

• 参数：支持使用 $1, $2 或 $ARGUMENTS 接收用户输入。

官方 / 社区示例：/security-review 这是一个常见的自定义命令，用于让 Claude 按特定标准审查代码安全。

文件路径：~/.claude/commands/security-review.md (全局命令) 或 .claude/commands/security-review.md (项目命令)

文件内容示例：

--- description: Review the current code for security vulnerabilities --- Please review the code in the current context for security vulnerabilities. Focus specifically on: 1. SQL injection risks 2. XSS vulnerabilities 3. Hardcoded secrets If you find issues, please suggest specific fixes. 

如何使用：在终端输入 /security-review

Agents

Agent 本质上是拥有独立上下文和特定系统提示词（System Prompt） 的 Claude 实例

减小主流程上下文的占用，子代理上下文隔离，可以更好的聚焦任务；

使用方法： 你可以通过 CLI 交互式创建，或者通过配置文件定义。Agent 本质上是拥有独立上下文和特定系统提示词（System Prompt） 的 Claude 实例。

• 交互式创建：在 Claude Code 中输入 /agents，然后选择 “Create new agent”。

• 配置定义：通常定义在配置文件中，指定其 role（角色）、description（描述）和 tools（可用工具）。

官方示例：Code Reviewer (代码审查员) 这是官方文档中常用来演示如何通过子代理分担任务的例子。

配置逻辑（概念性描述）：

• 名称：code-reviewer

• 角色描述：你是一位资深的代码审查专家，通过严格的标准审查代码变更。你只关注代码质量、可读性和潜在 bug，不要直接写代码，只提供建议。

• 工具权限：限制为 Read（只读）权限，防止它意外修改代码。

如何使用： 在对话中，主 Agent 可能会根据任务自动调用它，或者你可以显式指派任务（如果配置允许）。

“Please ask the code-reviewer to check my latest changes.”

Skills

按需加载，只有需要该技能的时候才会加载文件内容。

可以对业务知识及开发流程进行规范

使用方法： Skill 是赋予 Claude 新能力的 “知识包”，通常由一个 SKILL.md 文件和相关的脚本 / 文档组成。

• 核心文件：SKILL.md。

• 原理：Claude 启动时会加载 Skill 的元数据（Metadata）。只有当它判断当前任务需要该技能时（例如用户要求 “处理 PDF”），它才会读取 SKILL.md 的完整内容并执行其中的步骤。

官方示例：PDF Processing Skill (PDF 处理技能) 这是 Anthropic 工程博客中介绍的一个经典案例，教 Claude 如何读取 PDF 表单。

目录结构示例：

Plaintext

plugins/pdf-skill/
├── SKILL.md          # 告诉 Claude 如何使用这个技能
├── extract.py        # 实际执行提取工作的 Python 脚本
└── README.md

SKILL.md 内容摘要：

“When the user asks to extract data from a PDF, run the extract.py script provided in this directory. Do not try to read the PDF raw bytes directly. Interpret the JSON output from the script.”

如何使用：用户无需显式调用。只需说 “Read the contract.pdf and tell me the date”，Claude 会自动激活 PDF Skill。

Plugins

Plugin 是上述所有内容（Commands, Agents, Skills）的分发容器。

接下来说一下比较容易混淆的地方，commands，agents，skills 确实有功能重叠的地方，但是他们的侧重点是不一样的，只有明白了他们各自的侧重点之后才能更好的决定使用哪一个。

1. 最大的重叠区：Command vs. Skill

这是最容易混淆的一对。它们都可以用来封装一段 Prompt 或脚本。

• 重叠点：它们本质上都是 “预定义的指令 / 脚本”。

• 核心区别：谁掌握 “扳机”？

  • Command (命令) 是显式的。你（用户） 是控制者。你必须输入 /review，Claude 才会去审查。

  • Skill (技能) 是隐式的。Claude (模型) 是控制者。你只需要说 “帮我看看这代码咋样”，Claude 会自己判断：“哦，用户需要审查代码，我应该调用 CodeReviewSkill。”

例子：

如果你写了一个 Python 脚本 format_code.py。

• 做成 Command (/fmt)：你每次必须手动输入 /fmt 才能运行它。

• 做成 Skill：当你对 Claude 说 “这代码太乱了” 时，Claude 会自动运行这个脚本。

2. 逻辑重叠区：Agent vs. Skill

这两者都涉及 “特定领域的专业能力”。

• 重叠点：都能让 Claude 变得更专业（例如都懂 SQL）。

• 核心区别：上下文是不是独立的？

  • Skill (技能) 是工具。它在当前对话中被加载。它就像给了当前的 Claude 一本《SQL 手册》，它现学现卖，但还是同一个 Claude 在跟你说话，上下文是混在一起的。

  • Agent (代理) 是分身。它拥有独立的上下文。当你调用 Agent 时，就像是 Claude 把任务转包给了坐在旁边的 “数据库专家”。这个专家有自己的记忆和设定，处理完后只把结果告诉主 Claude，避免了主对话窗口被大量的中间步骤污染。

3. Plugin (插件) 的特殊地位

Plugin 没有任何功能上的重叠，因为它不是功能本身，而是包装盒。

• 你不能把 Plugin 和 Command 并列比较。

• Plugin 包含 Command、Skill 和 Agent。

• 就好比：Command 是苹果，Agent 是橙子，而 Plugin 是水果篮。

一个场景看懂所有区别

假设你想实现一个功能：“将代码翻译成中文文档”。你可以通过三种方式实现，侧重点不同：

总结：我该选哪个？

如果你在尝试扩展 Claude Code，可以用这个简单的决策树：

1. 这个功能需要用户手动且精确地触发吗？

   • 是 \rightarrow$\to$ Command (/foo)

   • 否 \rightarrow$\to$ 下一步

2. 这个任务是否非常复杂，需要大量步骤，且容易污染当前的聊天记录？

   • 是 \rightarrow$\to$ Agent (独立的子脑)

   • 否 \rightarrow$\to$ Skill (教会当前大脑新知识)

3. 你想把这些功能打包发给同事用吗？

   • 是 \rightarrow$\to$ 把做好的 Command/Agent/Skill 放到一个文件夹里，做成 Plugin。

如果内容有误，欢迎指出

自己在 windows 上装总是有各种问题 干脆用出来 CC 写了个脚本 源都换成国内源了 默认屏蔽了官方登录 直接使用第三方 api 即可
ClaudeCode-Windows-Installer