鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册
站长：程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
23
3
50

大模型使用经验与模型分工

Yeb123
Yeb123
2026-05-03 12:44
阅读 5047
Yeb123
2026-05-03 12:44
阅读 5047

我是怎么用大模型的——任务分工、模型选型与多 Agent 编排的实战经验

这篇是个人经验分享，内容来自我在 10+ 个 AI 项目中反复踩坑后的判断。不讲"大模型能做什么"，只讲"我实际怎么做、为什么这么做"。

引子：我每天在多个模型之间切换

先交代一下背景：我手上同时在用多个大模型服务，不是炫技，是真的不同场景需要不同的工具。

模型 / 服务我给的定位日常干什么
Claude（App）强推理 + 长上下文主力聊天、项目复盘、前端设计、架构设计
Gemini（免费层）第二意见聊天二号选手、同一个问题对比不同模型输出，交叉验证
DeepSeek V4（API）低成本施工主力代码生成、接口实现、批量任务、第一版快速落地
ChatGPT 5.4（中转）第二推理引擎复杂逻辑复核、Claude 不可用时的替代推理
小米 AI Pro免费送的快领免费送的要啥自行车
Ollama qwen3:4b（本地 RTX 3060）离线 / 开发测试本地快速原型、断网时的兜底、轻量编辑

切的逻辑不是看心情，是看任务类型。 下面具体讲我怎么判断。

一、核心框架：四大层级

大模型使用中最常见的误区，是把"模型能力强"等同于"什么场景都该用它"。我的教训是反过来的：越强的模型越要省着用，用在刀刃上。

我把日常的 AI 任务分成了四大层级：

1. 全知全能→ Claude（强推理）

特征： 长上下文、多信息源、需要判断"什么该保留、什么该合并、什么该删"

我的真实场景：

  • 聊天 — 5 小时额度用完拉倒，找资料、推荐小软件这类随手问
  • 项目探讨 — 总有创造性思维，会结合你的资料提出可行的新点子，不是那种"你说 A 它回 A"的复读机
  • 前端 — Claude 出的 UI 我基本不用改，别的模型出来的总要调好几轮
  • 框架设计 — 想得全面，会主动推演扩展方向和边界条件，好的框架施工赢一半

为什么是 Claude： 这类任务的难点不在"写出来"，而在"判断取舍"。我让轻量模型做过项目复盘——技术决策的推理过程全丢了，只剩正确的废话。Claude 在 100K+ token 上下文里对细节的敏感度确实更好。总结类任务当然也能用别的大模型，但"创造性判断"这件事——什么该保留、什么该砍、哪里需要重构——Claude 的判断力就是更靠谱。

前端： 我一般让 Opus、GPT、DeepSeek V4 Pro 各出一版，然后自己挑。别的也不是难看，但 Claude 的就是更顺眼——说不清楚为什么，反正不用改。多出几个方案，挑就完了。

框架设计： 好的框架施工赢一半。Claude 不会只盯着当前需求写，会多想一步，追问"以后加 XX 会不会有问题"。施工型模型没这个习惯。我现在基本是 Opus + Ultra 对齐架构，看清楚路了，再切 Flash 施工。

许愿级场景： 当事情真的解决不了了——那种"搞了三天还不对、越改越乱、所有轻量模型都试过一轮全翻车"的时候，我会直接上核武器：Opus 4.7 拉满，GPT 拉满，最大模型、最大思考级别、最大预算，全部梭哈。 不是理性决策，是信仰充值。但说真的，这种级别的模型确实能在"所有人都看不懂"的时候找到那条正确的路——它看见的不是代码，是因果链。每次梭完都觉得这钱花得值。

一个例子： 我写 [[多Agent协作架构原则]] 那份文档时，原始材料散落在当日日记、项目总览、各子项目的设计文档里——时间跨度好几天、文件数量十来个。Claude 一次性读完所有材料，不仅能保留每个项目的技术细节，还能判断哪些内容应该升为全局原则、哪些只适合放在具体项目里。这种"结构判断力"是施工型模型做不到的。

2. 大模型用途 → DeepSeek V4 Pro / GPT 5.5

特征： 量大管饱、需要结构化输出，V4 Pro 和 GPT 5.5 各有主场

DeepSeek V4 Pro 的主力场景：

  • 把一整天的 Obsidian 日记整理成结构化复盘
  • 把散落在多个项目文件中的信息重组成一篇架构文档
  • 多轮对话后的沉淀总结
  • 写技术文章、通用内容
  • 第一波修 Bug — 先把明显的问题筛一轮，跑通再说

GPT 5.5 的主力场景：

  • 写更专业、更有外国味道的文章 — 那种需要"GPT 味"的东西，V4 Pro 写出来总感觉差一口气
  • 行业研究、专业分析 — 逻辑链条更紧密，不是"信息汇总"而是"分析 + 论证"
  • 修 Bug 二把手 — Claude 不在或者 Bug 没那么深的时候顶上

两句话总结：

  • V4 Pro = 干活主力，便宜量大，写文章、做总结、第一波修 Bug 全包
  • GPT 5.5 = 专业输出，要拿出去给人看的、要有"GPT 味"的、V4 Pro 搞不定的第二波

3. 小模型施工 → DeepSeek V4（低成本 + 高频）

特征： 目标明确、步骤清楚、需要快速出活

我的真实场景：

  • "给 FastAPI 补一套 CRUD 接口"
  • "Vue3 组件改成响应式布局"
  • "生成一个 LangGraph StateGraph 骨架"
  • "Docker Compose 模板 + Nginx 配置"

为什么用 DeepSeek： 目标已经非常清楚了，不需要"全局理解"和"结构判断"。我要的是快、便宜、可以反复调用。我的 P1 SlimTrack 项目从 0 到上线，大部分 CRUD 代码都是 DeepSeek 生成的，如果用 Claude 也能做，但成本高出几倍，代码质量并没有成比例提升。

什么时候又切回 Claude： 涉及跨文件逻辑的时候。比如 LangGraph 的条件路由 + 错误恢复链路——函数 A 的异常处理会影响函数 B 的状态流转。DeepSeek 在这个场景下容易"修一个 Bug 引出另一个 Bug"。我的做法是：Claude 做根因分析 → DeepSeek 执行修复。

修 Bug 和写代码是两种完全不同的能力。

修 Bug 需要"怀疑精神"——同时考虑多个可能的根因，而不是拿着第一个猜测就开修。施工型模型容易修完表面又出新问题。P4 多 Agent 系统的状态传播 Bug，DeepSeek 修了 3 次都没解决根因；Claude 一次就定位到是 State 字段粒度不够导致两个 Agent 对同一个 key 有歧义。

4. 修 BUG 专项

不管前面怎么分工，修 Bug 这件事值得单独拎出来说。

三层火力配置：

层级模型什么场景
第一波DeepSeek V4 Pro先筛一轮，明显的问题直接修掉，跑通再说
二把手GPT 5.5Claude 不在或 Bug 没那么深的时候顶上，逻辑推理仅次于 Claude
终极武器Claude + Ultra 思考拉满跨模块因果链 Bug、搞了几天没修好的——所有可能路径全跑一遍，不漏根因

为什么 Bug 修复要分层： 大部分 Bug 不需要终极武器。先让 V4 Pro 扫一遍，剩下的疑难杂症往上升级。这和医院分级诊疗一个道理——不是每个感冒都要挂专家号。

5. 本地做实验 → Ollama 本地（附）

特征： 学习目的为主，搞清楚本地模型能干什么、不能干什么。RTX 3060 6GB 显存，跑 qwen3:4b 刚好，再大就卡。

我的真实场景：

  • 改标题层级、统一 Markdown 格式
  • 调语气、翻译小段文字
  • 生成 JSON Schema、yml 配置
  • 给笔记批量加 frontmatter
  • 断网或者 API 挂了的时候兜底

体会： 本地模型跟云端差距还是挺明显的。4b 这个量级，简单的格式活能干，但稍微需要"理解"的东西就容易跑偏。比如让它总结一段文字，出来的东西经常抓不住重点。好处是零延迟、零成本、无限调用——改个标题、调个格式这种事，不需要云端 100K 上下文的模型来干。

为什么不能"杀鸡用牛刀"： Claude 当然也能做，但它的上下文窗口是稀缺资源——在 100K token 里翻找一个改标题只需要的信息，效率极低。我现在有意识地把轻任务分流到本地，保持 Claude 的窗口只装真正需要深度处理的内容。能在本地跑的本地跑，能批量处理的丢 DeepSeek。

二、一个我每天都在用的判断流程

基于上面的四大层级，我内化了一套快速决策流程：

▼
text
复制代码
拿到一个任务
    │
    ▼
Q1: 需要创造性思维 / 架构审美 / 复杂推理吗？
   （聊天探讨 / 前端设计 / 框架设计 / Bug 排查）
    │
    ├── 是 → Claude（全知全能 + 终极 Bug 修复）
    │
    └── 否 → Q2: 是写文章 / 做总结 / 修 Bug 吗？
              │
              ├── 是 → 要拿出去给人看 / 要"GPT 味"吗？
              │         ├── 是 → GPT 5.5（专业文章 / 二把手修 Bug）
              │         └── 否 → DeepSeek V4 Pro（复盘 / 笔记 / 第一波修 Bug）
              │
              └── 否 → Q3: 是写代码 / 施工吗？
                        │
                        ├── 是 → DeepSeek V4（小模型施工）
                        │
                        └── 否 → Ollama 本地（轻量编辑 / 实验）

这个框架背后的四个洞察

洞察 1：长上下文理解才是强模型的真正壁垒。 不是所有"难"任务都需要强模型——只有那些需要跨段落、跨文件、跨时间线理解的任务才真的需要。一个 CRUD 接口再复杂，它需要的也只是"写代码"，不是"理解上下文"。

洞察 2：施工型模型的定位是"先跑通，再优化"。 大多数功能的第一版不需要完美。用 DeepSeek 快速出 MVP，验证方向对了再用 Claude 精修关键路径。这个节奏比"每个版本都用 Claude 慢慢雕"快得多。

洞察 3：上下文窗口比算力更稀缺。 Claude 的 100K 上下文窗口不要用来做"改个标题"。我现在有意识地把轻任务分流到本地 Ollama 或 DeepSeek，保持 Claude 的上下文窗口"干净"——只装真正需要它深度处理的内容。

洞察 4：模型人格是试出来的。 上面这个流程图看着清楚，但真正内化靠的不是背——是每个模型都用过几十次之后，你自然就知道什么任务该找谁。比如 Claude 前端出得顺眼、GPT 写的英文邮件就是地道、DeepSeek 批量施工不用心疼——这些都不是 Prompt 能描述的，是自己一遍遍对比出来的肌肉记忆。

三、一个类比：大模型是领导，小模型是兵

用久了之后，我对模型分工有一个越来越清晰的直觉：

模型小 → 拿来干活。模型大 → 拿来统筹、总结。

非常像一个公司。大模型是大领导——不做具体执行，但决定方向、判断取舍、在关键时刻拍板。小模型是大头兵——执行力强、便宜、可以铺量，但不会主动思考"这件事该不该做"。

角色模型干什么
大领导Claude定方向、判取舍、架构决策、创造性突破、终极 Bug 修复
中层干部GPT 5.5专业分析、行业报告、"GPT 味"文章、二把手修 Bug
技术骨干DeepSeek V4 Pro总结复盘、文档重构、通用写作、第一波修 Bug
大头兵DeepSeek V4代码施工、批量任务、第一版快速落地
实习生Ollama 本地格式调整、局部替换、不花钱的实验

这个类比的本质是：不是所有问题都需要 CEO 亲自下场。但 CEO 下场的时候，一定是因为头兵搞不定了。

用久了还会发现，每个模型都有自己的"人格"：

  • Claude — 有主见，会反驳你，审美挑剔。不是那种你说什么它就做什么的助手，更像一个敢跟你争论的搭档。出的东西经常让你觉得"我靠这也行"。
  • GPT 5.5 — 洋气，写东西有股"外国味"，逻辑严密但偶尔啰嗦。适合拿出去撑场面。
  • DeepSeek V4 Pro — 老实人。不挑活、不废话、给什么干什么，出来的东西稳但不惊艳。第一波修 Bug 的可靠选择。
  • DeepSeek V4 — 快枪手。便宜到可以随便造，代码一把梭，行就行不行拉倒，不行再改。
  • Ollama 本地 — 憨。慢，笨，但免费。改个标题、调个格式这种事，它干得比谁都踏实。

这些感觉不是看文档看来的，是反复用、反复翻车、反复对比之后攒出来的。多试，多总结。最后一条：看好钱包，梭哈的时候想想月底账单。

四、实战：三个项目里的模型分工

上面说的是理论框架，下面是它在真实项目里的落地。

P2 学习助理：一条链路上的三种模型

P2 的核心流程是：视频 → 转录 → 知识点提取 → 结构化笔记 → 知识库入库。每个环节需要的模型能力不一样。

▼
text
复制代码
B站/YouTube 视频
    │
    ▼
Whisper large-v3（本地 GPU）          ← 专用模型，不是 LLM 的活
    │  转录文本 + 时间轴
    ▼
DeepSeek V4                             ← 施工型：提取关键概念、生成搜索词
    │  关键概念列表
    ▼
Claude                                  ← 强推理：补充资料搜索 + 知识结构整合
    │  结构化 Markdown 笔记
    ▼
Ollama qwen3:4b（本地 Embedding）       ← 轻量：向量化入库
    │
    ▼
Chroma / Milvus 知识库

为什么不在一个节点用 Claude 包办所有？

成本只是一方面。更关键的原因是：如果让 Claude 既做提取又做整合，它的注意力会被分散，整合质量反而下降。拆开之后，每个模型只关注一件事——DeepSeek 提取不关心结构，Claude 整合不关心提取。整体质量比"单模型全包"更高。

P4 电商 Copilot：Supervisor 用 Claude，Specialist 用 DeepSeek

P4 是 Supervisor + Specialist 架构：Supervisor 负责意图识别和路由，Order / Product / 售后三个 Specialist 各管一摊。

▼
text
复制代码
用户："退单重拍，地址换了"
    │
    ▼
Supervisor（Claude）                    ← 意图识别 + 任务拆解 + 路由决策
    │
    ├──→ Order Agent（DeepSeek）        ← 查订单、退单、退款
    ├──→ Product Agent（DeepSeek）      ← 查库存、推荐替代品
    └──→ 汇总（Claude）                 ← 整合结果，生成回复

为什么 Supervisor 必须是 Claude： "退单重拍，地址换了"这句模糊请求，需要拆成"退款 + 查库存 + 重新下单 + 改地址"四个子任务，还要判断执行顺序。这是典型的"理解全局"——施工型模型容易漏掉隐含的子任务。

为什么 Specialist 用 DeepSeek 就够了： Order Agent 收到的是"查 ORD-123 订单状态"——确定性操作，不需要推理。

成本对比： 1 次 Claude 推理 + 3 次 DeepSeek 执行，比 4 次全部 Claude 便宜 60%，效果几乎一样。

P9 CoreAI：三层 Agent 的分层选型

P9 是我最复杂的项目——感知层、思考层、执行层三层架构。

层级Agent模型原因
感知层转录 AgentWhisper（专用）语音识别不是 LLM 的活
感知层抓取 AgentDeepSeek网页结构化提取，目标明确
思考层研究 AgentClaude多轮搜索反思，需要强推理
思考层规划 AgentClaude复杂任务拆解，需要全局判断
执行层工具 AgentDeepSeek调 API、查数据库，确定性操作
执行层推送 Agent规则引擎不需要 LLM

规律很明显：越靠近"理解与决策"，越需要强模型；越靠近"执行"，越可以用施工型甚至规则引擎。

五、多 Agent 编排：模型分工的架构升级

模型分工解决了"一个任务用什么模型"，但复杂系统还有更深的问题：多个任务之间怎么协作？

我现在的原则是：新项目默认考虑多 Agent 架构。 不是每个项目都需要，但每个项目的架构设计必须回答——"如果以后需要多 Agent，当前设计是否支持？"

为什么单 Agent 不够用

▼
text
复制代码
单 Agent 的问题：
  一个 Prompt 塞所有场景 → Prompt 越来越厚、越来越难维护
  所有 Tool 对同一个 Agent 可见 → 客服 Agent 能调退款 API，误调用风险高
  LLM 幻觉 / Tool 选错 / 参数传错 → 三种错误混在一起，定位困难

多 Agent 的解法：
  每个 Agent 的 Prompt 短而专注 → 只干一件事
  每个 Agent 只看自己的 Tool → 不会越界
  哪个 Agent 出问题一目了然 → 独立调试、独立测试

本质是关注点分离（Separation of Concerns）——这是软件工程的经典原则，在多 Agent 架构里同样适用。

三条核心设计原则

1. Supervisor 用强模型，Specialist 用施工型。 这是"模型分工 + Agent 分工"的自然延伸：Supervisor 做意图理解和路由决策（理解全局），Specialist 做明确任务执行（施工）。

2. Agent 间不直接通信，所有中间结果写 State。 这不是技术洁癖，是调试需求。当系统出问题时，可以回放 State 的每一次变更，精确定位哪个 Agent 的哪一步出了问题。Agent-to-Agent 直接通信会让调用链不可追踪。

3. 一个 Agent 挂了不影响其他。 工程上的"降级优雅"。Product Agent 超时了，Supervisor 标记"商品信息暂不可用"，其他 Agent 继续跑——而不是整个请求卡死。

面试价值

多 Agent 是 2026 年 AI 工程面试的高频考点。这套经验对应几个高频问题：

面试问题我的回答框架
"多 Agent 之间怎么通信"不搞 Agent-to-Agent，所有中间结果写 LangGraph State
"单 Agent 和多 Agent 怎么选"关注点分离四维评估：场景复杂度 / 权限边界 / 测试独立性 / 迭代成本
"一个 Agent 挂了怎么办"分层处理：Agent 级重试 → Supervisor 降级 → 用户通知
"Tool 权限怎么管"每个 Agent 只看自己职责范围的 Tool，重叠 > 30% 说明职责没划清

一句话记住：多 Agent 不是把 LLM 调用拆成多个——是把职责拆开、把状态收拢、把错误隔离。拆是手段，收敛和隔离才是目的。

六、五条可复用的原则

1. 先判任务类型，再选模型

不要问"哪个模型最强"，要问"这个任务是什么类型，最适合什么模型"。判断核心就两个维度：是否需要创造性与全局判断、是否需要长上下文理解。

2. 大模型做领导，小模型做兵

强模型定方向、判取舍、做架构决策。施工模型做执行、铺量、快速落地。不是所有问题都需要 CEO 亲自下场——但 CEO 下场的时候，一定是因为头兵搞不定了。

3. 保护强模型的上下文窗口

100K token 的上下文窗口不要用来改标题。轻任务全部下放——本地 Ollama 或 DeepSeek 批量处理。保持 Claude 的上下文窗口只装真正需要深度处理的内容。

4. 复杂系统用多 Agent 做关注点分离

不要把不同职责塞进同一个 Prompt。拆成多个 Agent，每个 Agent 独立的 Prompt + Tool 集。Supervisor 负责路由，Specialist 负责执行。State 统一管理，错误逐层降级。

5. 建立成本追踪习惯

不知道钱花在哪，就没办法优化模型选型。至少记录：每个模型每月花多少、调用量多少、主要用在哪些任务上。数据是最好的选型依据。

写在最后

回头看，我使用大模型的方式经历了三个阶段：

第一阶段： 只用一个模型，所有任务都丢给它，能用但效率低、成本不可控。

第二阶段（4月）： 开始有意识按任务类型选模型——Claude 做重活，DeepSeek 做轻活。效率和成本都明显改善。

第三阶段（未来）： 引入多 Agent 编排。不只是模型级别的分工，而是架构级别的关注点分离。每个 Agent 有明确的职责边界，出问题能精确定位。

如果只记住一句话：大模型使用经验的关键，不是"用了多少个模型"，而是"有没有把每个模型放在它最擅长的位置"。 分工清楚之后，大模型才会从一个对话工具，变成真正可复用的生产力系统。

那么，可以猜一下，这个文章用了哪个大模型？

最后更新： 2026-05-03 关联文档： [[多Agent协作架构原则]] · [[01 项目总览]] · [[02 项目说明]] · [[10 PP4-API用量面板]]

AI
23
50
分享
操作
评论
相关内容
0个评论
全部评论
点击登录，快来和大家讨论吧～
表情
图片

目录

🔥 热门文章
1
手把手教你设计一个成熟的 Agent Harness
2510
2
我用 REA 逆向了付费颜色 APP，结果很意外！
570
3
离谱，DeepSeek 崩了 5 小时，大家却喊：梁圣恩情还不完？？
420
4
DeepSeek 全新模型发布，性价比最高的一集！
380
5
B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！
370
6
自己学习ai，直接买cursor 的套餐，还是买gpt 或者claude 的套餐?
360
7
又一个国产版 Codex 神器，也来卷办公了！
330
8
day3-如何写出一个高质量的 Skill（组内分享） 高质量 Skill 不是“一个调得很顺的巨型 Prompt”，而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”，再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子，但方法是通用的。 --- 一、先想清楚：Skill 到底是什么 一个 Skill 至少包含四部分： 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做，每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办，而不是硬编一个看似合理的结果 高质量 Skill 的共同点：职责单一、接口清晰、规则可定位、输出可验证。 反例：把几十条经验全塞进一个主 Prompt，改一条规则要重调整个 Prompt，评估时也不知道是哪条规则退化。 --- 二、核心方法：先建评估，再写 Skill 不要先写转换器再补测试。正确顺序是： 1. 定义输出契约：什么算合法、什么算合格； 2. 建金标准集：一小批人工认可“可放行”的样本； 3. 先写评估 Skill：让它在金标准集上跑出基线； 4. 再迭代生成 Skill：每次修改跑同一套评估，无退化且目标维度提升才算正向。 这就是评估驱动开发：评估是 Skill 的单元测试，金标准集是回归锚点。 --- 三、评估 Skill：三层门禁，逐层递进 前一层不过，后一层不跑。每层留可追溯证据。 第 1 层：确定性硬门禁 用解析器、Schema、校验器完成，不消耗模型成本。 · 输出可解析； · 必填字段齐全，类型/枚举合法； · 引用目标存在，无悬空引用、无不可达节点； · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层：语义断言 用脚本 + 结构遍历检查“逻辑对不对”，仍然保持确定性。 通用检查项： · 覆盖率：源材料里的关键步骤、分支、条件，输出里是否都有对应？ · 完整性：每个判断节点是否都有明确出口？有没有死胡同？ · 可达性：每条路径是否都能到达预期终点？有没有无出口循环？ · 顺序与依赖：有先后依赖的操作，是否保留了顺序？有没有被拍平成无序列表？ 例子：故障诊断转换中，检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层：LLM-as-Judge 只处理解析器表达不了的维度：忠实度、完整性、可执行性。 但 Judge 会漂移，不能单独放行，必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化，换模型必须用金标准集重新校准。 通用 Judge 维度： 维度 问什么 忠实度 输出是否忠实源材料意图？有没有自行发明内容？ 完整性 关键步骤、条件、证据是否保留？隐式知识有没有被压成空话？ 收敛性 输出是否仍指向原目标，而不是发散？ 可执行性 下游不依赖源材料能否直接使用？ --- 四、金标准集：回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子，扩到 15～30 份，覆盖失败模式而非随机抽样： · 完整正例：典型流程； · 边界/异常分支：异常路径、循环、前置失败回退； · 已知易错模式：实际踩过的坑； · 留出集：不参与调优，只用于最终验收，防过拟合。 金标准不需要完美，只需要当前标准下认可可放行。 回归指标：关键路径用 pass^k（k 次全过），稳定性用 pass@k。 --- 五、工程约束：让批量产出可重放 · 幂等：同输入 + 同 Skill 版本 + 同规则 → 输出一致，否则无法判断变好是 Skill 改了还是随机波动； · 隔离不阻断：单份失败进隔离队列，记录失败层和原因，不阻塞其余； · 版本绑定：规则、rubric、金标准集进 Git；每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”； · 抽样人工复核：Judge 临界样本 + 易错模式，人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅，写清：输入约定、输出契约、分步流程、硬规则、降级策略； · 经验规则放 references/ 或 rules/，按失败模式分类，不要全塞进主 Prompt； · 不确定时标 needs_review: true，不要硬编看似合理的结果； · 迭代由评估报告驱动：报告告诉你哪层挂了、哪类失败模式，你改对应规则文件，而不是漫无目的调 Prompt。 --- 七、落地顺序（不要反过来） 1. 固化输出契约：Schema + 结构约束； 2. 建金标准集：从已认可的 + 最易出错的样本开始； 3. 先写评估 Skill：跑出基线报告； 4. 再迭代生成 Skill：每次修改对比逐项通过率，无退化且目标提升才算正向； 5. 批量运行 + 隔离回放：失败进队列，结束后人工抽检； 6. 评估 Skill 自身版本化：换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”：每次修改必须附评估报告对比，逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数：前两层挂了，Judge 分数没有意义。 3. 不许把规则堆进主 Prompt：规则按失败模式分文件，评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”，评估 Skill 决定“敢不敢用”。 先让评估体系站稳，再让生成器迭代。这样交付的不是一堆“看起来还行”的产出，而是一套可证明、可回归、可交接的 Skill 质量体系。
310
9
AI 越强，被它拒绝的代价就越大 我有时候会想：AI 越来越厉害之后，有些事情，会不会反而越来越难做？ 这个想法看起来有点矛盾。AI 明明在降低门槛，让不会写代码的人做出软件，让不会画画的人生成图片，让一个人完成过去需要整支团队才能完成的工作。但今天用 Codex 的时候，AI 拒绝帮我编写 SQL 注入的请求体，而那还是我有源码、在本地跑测试的情况。那么，往后是否只会更难？ 我们假设某一天，AI 说：「这个请求违规，我不能帮助你。」到那个时候，你还有多少能力，能绕过它，把事情做完？ 这里的「违规」需要打个引号。平台的规则、模型的判断、法律的要求，以及一件事实际有没有造成伤害，彼此之间并不总是画得上等号。一个请求可能确实危险，也可能只是缺少上下文被误判，或者恰好落在某家公司的限制范围里。 无论是哪种情况，随着我们越来越依赖 AI，这句拒绝都可能变得越来越贵。 今天，一个程序员让 AI 帮忙写代码，AI 拒绝了，他大概率还有别的办法：查文档、找开源项目、问同行，或者自己写。麻烦一点，慢一点，但路还在。 可如果十年之后，大部分程序都由 AI 完成，情况就不一样了。 很多人从接触编程的第一天起，就习惯了描述需求、等待生成、运行结果、继续迭代。他们能做出相当复杂的产品，却未必经历过独立处理底层问题的训练。平时，这种能力结构完全够用，效率甚至更高。只有 AI 拒绝的时候，他们才会发现：平常被省掉的那段学习过程，恰好是此刻最需要的东西。 到那时，一次拒绝的成本，可能就从「今晚多花两个小时」，变成「先花半年学会这门技术」。 拿 SQL 注入举个稍显极端的例子：往后，连真正理解这类攻击如何发生、能够独立构造测试的人，会不会也越来越少？ 这里也包括那些有正当需求的人。一个开发者想检查自己的旧系统，一个经过授权的安全研究员想复现漏洞，假如 AI 识别到危险模式就拒绝，而使用者又只熟悉「让 AI 帮我检查」，这项原本可以独立完成的工作，就这样卡住了。 但是安全专家不会因此消失，但这类技能可能越来越集中在少数人手里。你仍然可以找专家，只是要付出更多的钱、更多的时间，以及更高的沟通成本。 类似的困境，未必只发生在网络安全领域。 你想从一个停止维护的软件里取回自己的数据，需要解析它的旧文件格式。AI 判断这涉及规避保护措施，拒绝继续。你拥有这些数据，却没有能力把它们读出来。 你买了一台设备，厂商停止提供服务。你想修改程序让它继续运转，过程中需要处理某种访问限制。AI 不愿协助，而你所掌握的维修方式，早已只剩下「把报错发给 AI」。 你想给常用的网站写一个辅助工具，减少重复操作。平台将此归入自动化限制，AI 也据此拒绝。过去会写脚本的人可以自己判断、自己处理；未来的使用者，可能连从哪里开始都不知道。 这些例子有一个共同点：当工具同时承担了「执行工作」和「传授知识」的角色，它的拒绝就不只是挡住了一次任务，也挡住了获得这种能力的机会。 更麻烦的是，这种依赖往往是我们主动选择的，而且每一步都很合理。 既然 AI 几秒钟就能做好，为什么还要花几个月学习？既然公司可以采购成熟的 AI 服务，为什么还要养一支负责基础工作的团队？既然市场上已经很少有人手写这些东西，学校为什么还要花大量时间教？ 对个人、公司和学校来说，这些选择都有现实依据。但叠加起来，整个社会保留的独立能力就可能越来越少。等到某项能力突然受到限制，我们才发现，备用方案早已在追求效率的过程中被一点点削掉了。 所以，「AI 越强，做事越便宜」可能只描述了未来的一半。 另一半是：被允许的事情越来越便宜，被拒绝的事情依然需要人工完成，却要面对更少的人才、更高的报价，以及越来越难获得的知识。两边的成本差距，会越拉越大。 有人会说，可以换一个模型，或者用本地模型。这确实是重要的选项。只要工具之间还有充分竞争，开放模型还足够可用，限制就未必能形成真正的门槛。 但备用方案也需要维护。它需要硬件、知识、软件生态，以及一群仍然理解这些系统的人。如果大多数人已经习惯了最方便的商业服务，那么「理论上还有别的办法」和「普通人实际用得起、用得明白」，之间仍然可能隔着很远。 我担心的，正是这段距离。 我不指望 AI 对任何请求都照单全收。对明显会伤害他人的行为设置限制，有充分的理由。但我们也需要关心：限制由谁定义，误判有没有申诉渠道，用户能不能换工具，以及脱离这个工具之后，还剩下多少独立行动的能力。 保留这些能力，平时看起来甚至有点低效，明明可以自动生成，还要理解原理；明明可以一键完成，还要知道手动怎么做。 但这些看似多余的知识，会在工具拒绝、失效、涨价或改变规则的那一刻，成为真正的选择权。 AI 越强，我们可能越需要留意它说「不」的那一刻。 因为那句话的分量，最终取决于：它拒绝之后，我们还能做什么。
310
10
什么是LLM
300
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题