别再卷模型了：用「Thin Harness + Fat Skills」把 AI 变成团队资产

你肯定见过这种场景：

• 同一个模型，有人一天改完一堆需求，你还在和它“你说人话、我说人话”来回拉扯。
• 你以为差距来自更强的模型、更花的插件、更玄学的 prompt。

真相更扎心：很多高手用的就是你手上这套模型。拉开差距的，是架构。

核心思路就一句话：

Thin Harness, Fat Skills

把“中间那层”做薄，把“技能”做厚。

你要的不是更复杂的系统，而是更清爽的中间层（Thin Harness）

harness（中间层）该干啥？

• 跑模型（选用哪个 LLM、温度、max_tokens 之类）
• 管上下文（对话历史、检索内容、系统规则）
• 读写文件（代码、日志、需求、测试报告）
• 安全控制（权限、脱敏、审计）

就这些。别加戏。

为什么要“薄”？

因为 harness 一旦胖起来，你会踩这些坑：

• 维护成本爆炸：每个功能都牵一发动全身。
• 能力无法复用：这个项目调得很顺，换个场景又得重搭一套。
• 调试像破案：到底是模型问题、上下文问题，还是 workflow 问题？看半天看不出来。

薄的好处也很直接：

• 你能快速换模型、换向量库、换工具链。
• 你能把“真正值钱的东西”搬到技能库里，变成可迁移资产。

真正值钱的，是可复用的技能文件（Fat Skills）

这里的 skill，不是“更长的 prompt”。

更像是：用 Markdown 写的软件说明书。

它要写清楚：

• 什么时候用它（适用场景）
• 输入是什么（参数）
• 产出什么（输出格式）
• 怎么做（步骤/判断流程）
• 什么算做好（质量标准）
• 失败怎么办（兜底策略）

一句话：

Skill file 不是提示词工程，是软件设计。

你把它当“团队 SOP + 质量规范 + 调用协议”。

今天用它查代码 bug，明天把输入换成用户反馈，它照样能跑，因为它靠的是结构化流程，不靠灵感。

一套能跑起来的架构长什么样（建议照抄）

把系统拆成三层：

[Harness 薄中间层]
  - LLM 调用
  - 上下文拼装
  - 文件/工具访问
  - 权限与审计
        |
        v
[Skill 技能库]
  - skills/*.md
  - 可版本管理（Git）
  - 可评审（PR）
  - 可测试（样例输入输出）
        |
        v
[Artifacts 业务资产]
  - 代码库、需求、工单
  - 领域词表、知识库
  - 测试用例、运行日志

你会发现：

• harness 像“操作系统内核”，越稳定越好。
• skills 像“应用程序”，越多越强。
• artifacts 是“数据与资产”，越积累越值钱。

手把手：写出一个真正能复用的 Skill（模板给你）

把下面这段直接存成 skills/code_review.md 之类的文件就行。

✅ Skill 模板（Markdown）

# Skill: 代码评审（带风险分级）

## 适用场景
- PR 合并前的快速评审
- 重构后检查潜在风险
- 线上事故后复盘定位可疑改动

## 输入参数
- repo_context: 相关目录结构/关键文件列表
- diff: 本次变更 diff（必须）
- constraints: 技术约束（如：不能改 DB schema / 兼容旧接口）
- risk_level: low | medium | high（默认 medium）

## 输出格式
用 Markdown 输出，固定包含：
1) 结论摘要（3 行内）
2) 风险清单（按严重度排序）
3) 必改项（可直接复制到 PR 评论）
4) 建议项（可选优化）
5) 需要你确认的问题（最多 5 个）

## 工作流程
1. 读 diff，标出：新增/删除/重命名/逻辑分支变化。
2. 识别高风险点：
   - 边界条件、空值、并发、缓存一致性、权限校验、外部依赖超时
   - 数据结构变更对序列化/兼容性的影响
3. 按 risk_level 调整力度：
   - low：只抓明显 bug 和风格一致性
   - medium：补齐边界条件与可维护性
   - high：增加失败模式分析（what can go wrong）
4. 给出可执行建议：
   - 每条建议必须包含“修改位置 + 修改方向 + 预期收益/风险”

## 质量标准（不满足就算失败）
- 不允许只说“建议优化”，必须具体到代码层面
- 发现问题要给最小修复方案
- 指出不确定处时，要明确需要哪类信息才能下结论

## 兜底策略
- 如果 diff 不完整：请求补齐关键文件
- 如果缺少上下文：优先提出澄清问题，不瞎猜

## 示例
### 输入
- diff: ...
- risk_level: high

### 输出示例（节选）
- 必改项：在 xxx 函数对 userId 判空，否则会导致...

你会发现，这玩意的关键不在“文采”，在协议。

写得越像工程文档，越能复用。

让 Skill 真的变强：加上“参数化”和“样例测试”

很多人技能库做不起来，原因很朴素：写完就扔那儿，从不验证。

1）参数化：让同一个 Skill 适配不同任务

举个很真实的例子：

• 你让 AI “分析用户反馈”，有人只要情绪归类；有人要输出可落地的需求条目；有人要给运营话术。

别写三个 prompt。

写一个 skill，加参数：

• output_mode = insights | tickets | scripts
• tone = neutral | friendly | assertive
• priority_rule = impact_first | frequency_first

2）样例测试：像测接口一样测 Skill

给每个 skill 配 2~5 个样例输入输出（放在同目录）：

• skills/code_review.md
• skills/code_review.cases.md（或 JSON/YAML）

每次改动 skill，就用这些 case 回归一下。

你会明显感觉：技能库开始“可维护”了，而不是“玄学库”。

一句话点破 AI Agent 的下一阶段：沉淀可复用的判断力

大家以前爱卷这些：

• 模型
• 工具
• workflow

这些当然重要。

更值钱的是：

• 你能不能把团队经验写成 skill
• 你能不能把重复工作固化成流程
• 你能不能把“模糊判断”和“确定性工具”拆开
• 你能不能让 AI 系统越用越懂业务

模型会更新，工具会过时。

技能资产会越积越厚，越积越像你的团队。

落地清单：照这 7 步做，你一周就能看到差别 ✅

• 选 3 个最耗时间、最重复的工作（比如代码评审、周报汇总、工单分类）。
• 每个工作写一个 skill，用上面的模板。
• harness 只提供：读取输入材料、调用 skill、输出到指定位置。
• 给每个 skill 配样例 case，当成回归测试。
• 建一个 skills/README.md，列出技能目录和适用场景，方便团队查。
• 上 Git，走 PR 评审：技能也是代码，别怕改。
• 每周复盘一次：哪些 skill 复用最多？哪些输出经常翻车？把翻车点写回质量标准里。

避坑清单（真踩过的人才会提醒你）⚠️

• 把 skill 写成一大段情绪化口号：没输入参数、没输出格式，复用率为 0。
• harness 搞成“万能框架”：什么都塞进去，最后哪里都不好改。
• 只收集“大神 skills”不做本地化：你的业务术语、你的约束、你的风险点，外面的 skill 不可能替你长出来。
• 不做样例测试：技能越改越漂，今天好用明天失灵。
• 不区分“判断”和“工具”：能用确定性脚本/查询解决的，别让模型瞎猜。

你该追的护城河是什么？

不是“用了哪个模型”。

是你们有没有一套自己的技能库：

• 重复工作有没有被 codify
• 模糊判断有没有被结构化
• 输出质量有没有标准
• 业务知识有没有沉淀成可调用的能力

把技能库做起来，你会看到很爽的变化：

• 同事之间交接变快了
• 新人上手变快了
• 你每天能少掉一堆机械沟通
• AI 的输出越来越贴着你们的业务走 😄