Lion-Skills：一套让 AI 编程更靠谱的 12 个 Skills

梁子应该没事吧

1261人浏览 · 2026-06-25 17:33:45

梁子应该没事吧 · 2026-06-25 17:33:45 发布

手把手教你安装 Lion-Skills：一套让 AI 编程更靠谱的 12 个 Skills

标签： AI编程 · Claude Code · ZCode · Codex · 开发工具 · 开源项目 · 代码规范 · 效率工具

一、为什么需要 Skills？

1.1 现实痛点

如果你日常使用 Claude Code、ZCode、Codex 等 AI 编程工具，你一定经历过以下场景：

场景一：让 AI 写测试

你：帮我给这个函数写单元测试

AI（第一次输出）：
test('should work', () => {
  expect(add(1, 2)).toBe(3);
});
test('should work 2', () => {
  expect(add(2, 3)).toBe(5);
});

看起来很合理，但没覆盖：

边界条件：add(-1, -1)、add(0, 0)
异常输入：add('a', 1)、add(Infinity, 1)
浮点数精度：add(0.1, 0.2)

场景二：让 AI 改 bug

你：这个函数在并发场景下会有竞态条件，帮我修一下

AI（输出）：
function fetchData() {
  let data = null;
  fetch('/api/data').then(r => r.json()).then(d => data = d);
  return data; // 永远返回 null
}

修了症状（加了 async/await），但病因（闭包捕获、返回时机）完全没解决。

场景三：让 AI 提交代码

你：帮我提交一下

AI：git commit -m "fix: update code"

嗯……这跟 ChatGPT 写的有什么区别？

1.2 根本原因

这些问题的根源不是 AI 不够聪明，而是 AI 没有「按最佳实践工作」的约束。

传统做法是把方法论写在 prompt 里，但：

问题	说明
上下文占用	方法论越长，和代码抢上下文空间
无法按需加载	不管这次需不需要测试，prompt 里的测试规范都要加载
难以维护	方法论更新了，prompt 的哪一段要同步改？
不可复用	换个项目又要复制一遍
不可评审	纯自然语言，团队很难一起 review

1.3 Skills 的解决思路

把方法论写成结构化文件，需要时自动加载，不需要时不占空间。

这就是 Lion-Skills 做的事——把 12 个高频开发工作流，写成 12 份 SKILL.md 操作手册。

二、项目概览

2.1 基本信息

属性	值
项目名称	Lion-Skills
定位	面向开发者的跨工具 AI Skills 套件
Skill 数量	12 个（0.2.0 版本）
规范基础	Anthropic Agent Skills (`SKILL.md` 格式)
支持工具	Claude Code、ZCode、Codex
开源协议	见仓库 LICENSE 文件
GitHub	github.com/Lion-1209/Lion-Skills

2.2 核心理念

每个 skill 是一份「操作手册」，AI 在合适的时机触发它，照着做出更靠谱的结果。

不是让 AI 变得更聪明，而是让 AI 有更好的「方法论」。

2.3 跨工具架构

                    ┌──────────────────┐
                    │  SKILL.md 源文件  │
                    │  (Anthropic 规范) │
                    └────────┬─────────┘
                             │ 一份文件，零修改
           ┌─────────────────┼─────────────────┐
           ▼                 ▼                 ▼
   ┌───────────────┐ ┌───────────────┐ ┌───────────────┐
   │  Claude Code  │ │    ZCode     │ │    Codex      │
   │   (Plugin)    │ │ (skills目录) │ │ (agents/skills)│
   └───────────────┘ └───────────────┘ └───────────────┘

三个工具使用同一份 skill 文件，不需要做任何修改。

三、项目结构详解

Lion-Skills/
├── .claude-plugin/                    # Claude Code Plugin 配置
│   ├── marketplace.json               # Plugin marketplace 声明
│   └── plugin.json                    # Plugin 元数据
├── .gitignore
├── LICENSE
├── README.md                          # 项目说明文档
├── docs/                              # 设计文档
│   ├── plans/
│   │   ├── 2026-06-16-lion-skills-mvp.md           # MVP 实施计划
│   │   └── 2026-06-17-lion-skills-plugin-distribution.md  # Plugin 分发计划
│   └── specs/
│       ├── 2026-06-16-lion-skills-design.md        # 初始设计意图
│       ├── 2026-06-17-lion-skills-plugin-distribution-design.md
│       └── 2026-06-22-skill-suite-architecture.md  # 套件架构设计
├── skills/                            # ⭐ 12 个 Skills 源码
│   ├── clarifying-questions/
│   │   ├── SKILL.md                   # Skill 核心文件
│   │   └── evals/
│   │       └── evals.json             # 回归测试用例
│   ├── spec-writing/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── task-breakdown/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── testing/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── debugging/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── code-review/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── verify-and-fix/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── commit-message/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── onboarding-unknown-codebase/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── naming/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── error-handling/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   └── lion-writing-skills/
│       ├── SKILL.md                   # ⭐ 元技能：教你怎么写 Skill
│       └── evals/evals.json
└── template/
    └── SKILL.md                        # 新建 Skill 的模板文件

3.1 每个 Skill 目录的构成

每个 skill 目录包含两个核心文件：

文件	作用
`SKILL.md`	核心操作手册 — 描述触发条件、执行步骤、输出标准
`evals/evals.json`	回归测试 — 验证 skill 的行为是否符合预期

3.2 docs 目录的设计文档

文档	说明
`2026-06-16-lion-skills-design.md`	初始设计意图，记录为什么要做这套套件
`2026-06-22-skill-suite-architecture.md`	套件架构设计，skill 之间如何协作
`2026-06-17-lion-skills-plugin-distribution.md`	Plugin 分发实施计划
`2026-06-17-lion-skills-plugin-distribution-design.md`	Plugin 分发架构设计

四、12 个 Skills 详解

4.1 上游：需求与设计（3 个）

Skill 1：`clarifying-questions` — 澄清问题

解决的问题： 需求模糊、背后的隐藏假设、X-Y Problem

触发条件：

用户描述了一个问题但没有明确目标
用户的描述暗示了特定技术方案（Y），但没有说明真正的需求（X）
需求存在多种可能的解读

核心流程：

1. 识别模糊点 — 哪些信息缺失会导致方案不同？
2. 区分 X 和 Y — 用户说的是「方案」还是「需求」？
3. 提出澄清问题 — 每次最多 3-4 个，不要信息轰炸
4. 等待回答 — 不要假设，不要替用户做决定

实际例子：

❌ 用户说：「怎么在 React 里获取 DOM 元素？」

⚠️ 这可能是个 X-Y Problem——用户真正的需求可能是：

做一个点击外部关闭的下拉菜单
实现滚动到某个元素的位置
测量元素的尺寸

每种需求对应完全不同的方案。

Skill 2：`spec-writing` — 写设计文档

解决的问题： 设计文档不可评审、没有验收标准、改代码时不知道改到什么程度算「完成」

核心流程：

1. 背景 — 为什么要做这个功能？
2. 目标 — 成功标准是什么？（可量化）
3. 非目标 — 明确什么不在这轮范围内
4. 方案设计 — 架构图、数据流、接口定义
5. 验收标准 — 怎么判断做对了？
6. 风险与权衡 — 有什么取舍？

Skill 3：`task-breakdown` — 拆解任务

解决的问题： 需求拆解不到位，任务是虚的，无法分配和验收

核心原则：

每个任务都是可独立验证的端到端单元
任务之间有明确的依赖关系
每个任务有明确的完成标准（Definition of Done）
粒度控制在 0.5 ~ 2 天的工作量

4.2 中游：开发与质量（5 个）

Skill 4：`testing` — 写能抓住 bug 的测试

解决的问题： 测试用例脆弱、覆盖率数字好看但抓不住 bug

核心原则：

原则	说明	反例
覆盖边界条件	空值、极值、边界值	只测正常输入
覆盖异常输入	非法参数、异常状态	只测 happy path
不测试实现细节	测试行为，不测试内部状态	`expect(internalVar).toBe(1)`
一个测试一个断言	每个测试只验证一个条件	一个 test 里断言 10 个东西
测试名即文档	`shouldReturnNullWhenInputIsEmpty`	`test1`、`test2`

示例对比：

// ❌ 脆皮测试
test('add works', () => {
  expect(add(1, 2)).toBe(3);
});

// ✅ 健壮测试
describe('add', () => {
  test('should return sum of two positive integers', () => {
    expect(add(1, 2)).toBe(3);
  });

  test('should return 0 when both inputs are 0', () => {
    expect(add(0, 0)).toBe(0);
  });

  test('should handle negative numbers', () => {
    expect(add(-1, -2)).toBe(-3);
  });

  test('should handle floating point precision', () => {
    expect(add(0.1, 0.2)).toBeCloseTo(0.3);
  });

  test('should throw TypeError for non-numeric input', () => {
    expect(() => add('a', 1)).toThrow(TypeError);
  });
});

Skill 5：`debugging` — 科学定位根因

解决的问题： 乱改代码、修症状不修病因、靠直觉调试

核心流程（6 步法）：

┌──────────────────────────────────────────────────────┐
│  1. 复现问题                                         │
│     - 建立最小复现步骤（Minimal Reproduction）       │
│     - 确认问题可以稳定复现                            │
├──────────────────────────────────────────────────────┤
│  2. 收集信息                                         │
│     - 错误日志、堆栈跟踪                              │
│     - 环境信息（版本、配置、网络）                    │
│     - 最近变更（git log）                             │
├──────────────────────────────────────────────────────┤
│  3. 形成假设                                         │
│     - 基于证据，不是直觉                              │
│     - 列出所有可能的根因                              │
│     - 按可能性排序                                    │
├──────────────────────────────────────────────────────┤
│  4. 验证假设                                         │
│     - 一次只改一个变量                                │
│     - 记录每一次尝试的结果                            │
│     - 排除法缩小范围                                  │
├──────────────────────────────────────────────────────┤
│  5. 修因不修果                                       │
│     - 找到 root cause                                │
│     - 不是凑巧修好就完了                              │
│     - 问自己：为什么会出现这个问题？如何预防？         │
├──────────────────────────────────────────────────────┤
│  6. 回归验证                                         │
│     - 确认修复有效                                    │
│     - 确认没有引入新问题                              │
│     - 补充对应的测试用例                              │
└──────────────────────────────────────────────────────┘

关键原则：每次只改一个变量，记录每一次尝试。

Skill 6：`code-review` — 有重点的审查

解决的问题： 审查走过场、没有重点、漏掉真正的问题

审查层次（从高到低）：

┌─────────────────────────────────────────┐
│ L6: 代码风格                             │
│    命名、格式、注释                      │
├─────────────────────────────────────────┤
│ L5: 可维护性                             │
│    可读性、可扩展性、复杂度              │
├─────────────────────────────────────────┤
│ L4: 安全性                               │
│    注入攻击、权限控制、敏感信息泄露      │
├─────────────────────────────────────────┤
│ L3: 性能                                 │
│    算法复杂度、数据库查询、缓存策略      │
├─────────────────────────────────────────┤
│ L2: 正确性                               │
│    逻辑是否正确、边界是否处理            │
├─────────────────────────────────────────┤
│ L1: 架构与设计                           │
│    整体方案是否合理、是否过度设计        │
└─────────────────────────────────────────┘

审查原则：

先看 L1（架构），再看 L2-L3，最后看 L4-L6
对每个评论标注严重程度：🔴 必须改 / 🟡 建议改 / 🟢 Nitpick
区分「事实」和「偏好」：SQL 注入风险 是事实，变量名应该用驼峰 是偏好

Skill 7：`verify-and-fix` — 把「声称完成」变成「经验证完成」

解决的问题： AI 说「好了」但没好、开发者自测不充分

验证清单：

□ 功能是否按需求正常工作？
□ 边界条件是否处理？
□ 错误场景是否有合理的反馈？
□ 是否有回归风险？（修改是否影响了其他功能）
□ 是否补充/更新了对应测试？
□ 是否更新了相关文档？
□ 是否有 console.log / debugger 残留？

Skill 8：`error-handling` — 错误处理与日志设计

解决的问题： catch(e) { console.log(e) } 满天飞、线上出问题无法排查

最佳实践：

// ❌ 反例：吞掉错误，啥信息都没有
try {
  await fetchData();
} catch (e) {
  console.log(e); // e 是什么？什么时候发生的？为什么？
}

// ✅ 正例：结构化错误处理
try {
  await fetchData();
} catch (error) {
  // 1. 记录结构化日志
  logger.error('fetchData failed', {
    error: error.message,
    stack: error.stack,
    timestamp: new Date().toISOString(),
    context: { userId: req.user.id, endpoint: '/api/data' },
  });

  // 2. 区分错误类型
  if (error instanceof NetworkError) {
    return { success: false, message: '网络异常，请稍后重试' };
  }
  if (error instanceof AuthError) {
    return { success: false, message: '登录已过期，请重新登录' };
  }

  // 3. 兜底处理
  return { success: false, message: '系统繁忙，请稍后重试' };
}

4.3 下游：交付与维护（3 个）

Skill 9：`commit-message` — 规范的提交信息

解决的问题： fix: update code 满天飞、changelog 难写

提交信息格式：

<type>(<scope>): <subject>

<body>

<footer>

Type 枚举：

Type	说明	示例
`feat`	新功能	`feat(auth): add Google OAuth login`
`fix`	Bug 修复	`fix(api): handle null response in user endpoint`
`refactor`	重构（不改变行为）	`refactor(db): extract query builder to separate module`
`docs`	文档变更	`docs: update README with installation steps`
`test`	测试相关	`test(auth): add unit tests for login flow`
`chore`	构建/工具变更	`chore: upgrade dependencies to latest`
`perf`	性能优化	`perf(list): implement virtual scrolling for large lists`

示例：

# ❌ 差劲的 commit message
git commit -m "update"

# ✅ 规范的 commit message
git commit -m "feat(auth): add Google OAuth login

- Add Google OAuth 2.0 flow
- Handle token refresh automatically
- Add error handling for auth failures

Closes #123"

Skill 10：`onboarding-unknown-codebase` — 系统化上手新项目

解决的问题： 新项目无从下手，不知道从哪看起

上手流程：

1. 从 README 开始 — 了解项目是做什么的
2. 看项目结构 — 目录命名、模块划分
3. 找到入口 — main()、index.ts、app.py
4. 追踪核心流程 — 选一个核心功能，从前端追到数据库
5. 看测试 — 测试是最好的文档
6. 看最近变更 — git log --oneline -20
7. 看架构文档 — docs/、wiki、ADR

Skill 11：`naming` — 命名决策

解决的问题： 变量名一团糟、命名没有一致性

命名原则：

场景	命名规范	示例
布尔值	is/has/can/should 前缀	`isValid`、`hasPermission`
函数	动词开头，描述动作	`fetchUserData()`、`validateEmail()`
事件处理	on/handle 前缀	`onClick`、`handleSubmit`
常量	全大写下划线分隔	`MAX_RETRY_COUNT`
类型/类	名词，大驼峰	`UserProfile`、`HttpClient`
CSS 类	BEM 或 kebab-case	`.user-card__title`、`.btn-primary`

4.4 元技能

Skill 12：`lion-writing-skills` — 教你怎么写 Skill

如果你想把团队的工作流也沉淀成 skill，或者你有自己独特的方法论想固化下来，这个 skill 就是你的「技能写作指南」。

它涵盖：

SKILL.md 的标准结构
如何写触发条件
如何组织执行步骤
如何写输出标准
如何写 evals 回归测试

五、安装指南（三种工具）

5.1 Claude Code（⭐ 推荐）

Claude Code 是 Lion-Skills 的首选平台，支持 plugin 机制，体验最好。

前提条件：

已安装 Claude Code（claude 命令可用）
网络可以访问 GitHub

步骤一：添加 Marketplace

/plugin marketplace add Lion-1209/Lion-Skills

步骤二：安装 Plugin

/plugin install lion-skills@lion-skills

步骤三：验证

新开会话，说一句话试试：

「帮我写一个登录功能的 spec」

应该自动触发 spec-writing skill。

升级旧版本（如果之前装过 0.1.0）：

/plugin marketplace update lion-skills
/plugin install lion-skills@lion-skills

⚠️ 重要提醒：Claude Code 下不要同时使用两种安装方式。如果你用 plugin 安装了，就不要再把 skill 目录拷贝到 ~/.claude/skills/，否则同名 skill 会重复触发。

5.2 ZCode

ZCode 目前通过 skills 目录方式安装（社区验证可生效）。

Windows PowerShell：

# 替换路径为你的实际路径
Copy-Item -Recurse "E:\path\to\Lion-Skills\skills\*" "$HOME\.zcode\skills\"

macOS / Linux：

cp -r /path/to/Lion-Skills/skills/* ~/.zcode/skills/

⚠️ 装完后需要新开会话，skill 才会出现在可用列表中。

自动同步（推荐）：

如果想在源仓库 git pull 后自动生效，使用 symlink 代替拷贝：

# Windows PowerShell（需要开发者模式或管理员权限）
$skills = Get-ChildItem "E:\path\to\Lion-Skills\skills" -Directory
foreach ($s in $skills) {
    New-Item -ItemType SymbolicLink -Path "$HOME\.zcode\skills\$($s.Name)" -Target $s.FullName
}

# macOS / Linux
for s in /path/to/Lion-Skills/skills/*/; do
  ln -s "$s" "$HOME/.zcode/skills/$(basename "$s")"
done

💡 注意：ZCode 的 plugin 体系由 Z.ai 官方维护，第三方个人仓库接入官方 marketplace 的路径尚不明确。目前 skills 目录方式是社区验证可行的方法。

5.3 Codex

Codex 原生支持 Agent Skills，技能目录是 ~/.agents/skills/。

macOS / Linux：

for s in /path/to/Lion-Skills/skills/*/; do
  ln -s "$s" "$HOME/.agents/skills/$(basename "$s")"
done

装完后用 /skills 或在 prompt 里用 $skill名 触发。

六、验证安装

6.1 快速验证

新开会话后，用以下 prompt 测试：

这段代码怎么改进？

try {
  const response = await fetch('/api/data');
  const data = await response.json();
  return data;
} catch (error) {
  console.log(error);
}

预期行为：

应该触发 verify-and-fix 或 error-handling skill
AI 应该指出问题并给出改进方案
改进方案应该包含：具体错误类型、结构化日志、用户友好的错误信息

6.2 逐个验证

如果快速验证没触发，逐个测试每个 skill：

测试 Prompt	预期触发的 Skill
「帮我写一个用户管理模块的设计文档」	`spec-writing`
「帮我把这个需求拆成任务」	`task-breakdown`
「帮我写一个排序算法的单元测试」	`testing`
「这个函数有 bug，帮我找一下」	`debugging`
「帮我 review 这段代码」	`code-review`
「这个功能做完了，帮我验证一下」	`verify-and-fix`
「帮我提交代码」	`commit-message`
「帮我给这个新项目写一个上手指南」	`onboarding-unknown-codebase`
「帮我给这个变量取个名字」	`naming`
「帮我设计一下异常处理逻辑」	`error-handling`

七、进阶使用技巧

7.1 串联多个 Skills

复杂任务可以串联多个 skill：

收到需求：「做一个用户注册功能」
  → clarifying-questions（问清楚注册方式、验证规则、安全要求）
  → spec-writing（写设计文档）
  → task-breakdown（拆成具体任务）
  → [执行开发]
  → testing（写测试）
  → code-review（审查）
  → verify-and-fix（验证）
  → commit-message（提交）

7.2 自定义 Skill

你可以：

阅读 skills/lion-writing-skills/SKILL.md 学习规范
复制 template/SKILL.md 从零开始
参照现有 skill 的结构编写
添加 evals/evals.json 进行回归测试

7.3 贡献到上游

如果你写的 skill 对社区有价值，可以提交 PR 到 Lion-1209/Lion-Skills。

八、如何自己写一个 Skill？

8.1 SKILL.md 标准结构

---
name: skill-name
description: 一句话描述这个 skill 做什么，以及触发条件
---

# Skill 名称

## 触发条件

在以下场景中触发：
- 场景 1
- 场景 2
- 场景 3

## 执行流程

### 步骤 1：xxx

具体怎么做。

### 步骤 2：xxx

具体怎么做。

## 输出标准

输出应该包含：
- 要求 1
- 要求 2
- 要求 3

## 示例

给出正例和反例。

## 常见错误

列出容易踩的坑。

8.2 evals.json 结构

{
  "eval_cases": [
    {
      "name": "测试用例名称",
      "input": "用户输入",
      "expected_behavior": "期望 AI 的行为",
      "pass_criteria": "通过的标准"
    }
  ]
}

8.3 从模板开始

cp template/SKILL.md skills/my-new-skill/SKILL.md
# 编辑技能内容
# 编写 evals/evals.json
# 测试验证

九、常见问题 FAQ

Q1：安装后 skill 没有自动触发？

可能原因及解决：

没有新开会话：ZCode 和 Codex 需要在安装后新开会话
自然语言不够明确：尽量用包含 skill 触发关键词的描述
工具版本过低：确保 Claude Code / ZCode / Codex 是最新版本
目录放错了：检查 skill 目录的路径是否正确

Q2：Claude Code 安装 plugin 报错？

# 确认能访问 GitHub
gh repo view Lion-1209/Lion-Skills

# 如果网络不通，可能需要代理
# 或者手动 clone 后本地安装

Q3：多个 skill 同时触发了怎么办？

如果两个 skill 的场景重叠，AI 通常会选择最匹配的一个。如果确实有冲突，可以在 SKILL.md 的 description 中调整触发条件的优先级描述。

Q4：symlink 在 Windows 上报错？

Windows 创建 symlink 需要开发者模式或管理员权限：

# 方法一：启用开发者模式
# 设置 → 系统 → 开发者选项 → 启用开发者模式

# 方法二：用管理员权限打开 PowerShell
# 右键 PowerShell → 以管理员身份运行

Q5：如何更新 skill 到最新版本？

Claude Code（Plugin）：

/plugin marketplace update lion-skills
/plugin install lion-skills@lion-skills

ZCode / Codex（symlink）：

cd /path/to/Lion-Skills
git pull
# symlink 方式自动生效，无需额外操作

ZCode（拷贝方式）：

# 重新执行一遍拷贝命令
Copy-Item -Recurse "E:\path\to\Lion-Skills\skills\*" "$HOME\.zcode\skills\"

十、总结与资源

10.1 特性速查

特性	说明
开源项目	Lion-1209/Lion-Skills
Skill 数量	12 个（0.2.0 版本）
规范基础	Anthropic Agent Skills (`SKILL.md`)
支持工具	Claude Code、ZCode、Codex
跨工具	一份 skill 文件，零修改，全平台通用
可扩展	提供 skill 写作规范和模板
可验证	每个 skill 附带 evals 回归测试

10.2 快速链接

资源	链接
GitHub 仓库	github.com/Lion-1209/Lion-Skills
Anthropic Agent Skills 规范	docs.anthropic.com/en/docs/build-with-claude/agent-skills
套件架构设计	`docs/specs/2026-06-22-skill-suite-architecture.md`
初始设计意图	`docs/specs/2026-06-16-lion-skills-design.md`
Skill 写作指南	`skills/lion-writing-skills/SKILL.md`
Skill 模板	`template/SKILL.md`

10.3 写在最后

这套套件的出发点很简单：把「怎么做」从 prompt 里抽出来，变成一份可复用的操作手册。

好处是显而易见的：

AI 的回答更稳定、更可预测
方法论沉淀在 skill 文件里，不会因为换项目、换工具而丢失
团队可以一起 review 和迭代这些 skill
你可以基于这套框架，扩展出自己团队专属的 skill

如果你也在为 AI 编程工具的「不稳定性」头疼，不妨试试 Lion-Skills——给 AI 配一本《资深工程师方法论手册》，不用你每次都口头交代，它会自动翻到对应的那一页。

觉得有用？欢迎 Star ⭐

👉 github.com/Lion-1209/Lion-Skills

作者注：本文基于 Lion-Skills 仓库内容整理，所有 skill 内容遵循 Anthropic Agent Skills 规范。

手把手教你安装 Lion-Skills：一套让 AI 编程更靠谱的 12 个 Skills

标签： AI编程 · Claude Code · ZCode · Codex · 开发工具 · 开源项目 · 代码规范 · 效率工具

一、为什么需要 Skills？

1.1 现实痛点

如果你日常使用 Claude Code、ZCode、Codex 等 AI 编程工具，你一定经历过以下场景：

场景一：让 AI 写测试

你：帮我给这个函数写单元测试

AI（第一次输出）：
test('should work', () => {
  expect(add(1, 2)).toBe(3);
});
test('should work 2', () => {
  expect(add(2, 3)).toBe(5);
});

看起来很合理，但没覆盖：

边界条件：add(-1, -1)、add(0, 0)
异常输入：add('a', 1)、add(Infinity, 1)
浮点数精度：add(0.1, 0.2)

场景二：让 AI 改 bug

你：这个函数在并发场景下会有竞态条件，帮我修一下

AI（输出）：
function fetchData() {
  let data = null;
  fetch('/api/data').then(r => r.json()).then(d => data = d);
  return data; // 永远返回 null
}

修了症状（加了 async/await），但病因（闭包捕获、返回时机）完全没解决。

场景三：让 AI 提交代码

你：帮我提交一下

AI：git commit -m "fix: update code"

嗯……这跟 ChatGPT 写的有什么区别？

1.2 根本原因

这些问题的根源不是 AI 不够聪明，而是 AI 没有「按最佳实践工作」的约束。

传统做法是把方法论写在 prompt 里，但：

问题	说明
上下文占用	方法论越长，和代码抢上下文空间
无法按需加载	不管这次需不需要测试，prompt 里的测试规范都要加载
难以维护	方法论更新了，prompt 的哪一段要同步改？
不可复用	换个项目又要复制一遍
不可评审	纯自然语言，团队很难一起 review

1.3 Skills 的解决思路

把方法论写成结构化文件，需要时自动加载，不需要时不占空间。

这就是 Lion-Skills 做的事——把 12 个高频开发工作流，写成 12 份 SKILL.md 操作手册。

二、项目概览

2.1 基本信息

属性	值
项目名称	Lion-Skills
定位	面向开发者的跨工具 AI Skills 套件
Skill 数量	12 个（0.2.0 版本）
规范基础	Anthropic Agent Skills (`SKILL.md` 格式)
支持工具	Claude Code、ZCode、Codex
开源协议	见仓库 LICENSE 文件
GitHub	github.com/Lion-1209/Lion-Skills

2.2 核心理念

每个 skill 是一份「操作手册」，AI 在合适的时机触发它，照着做出更靠谱的结果。

不是让 AI 变得更聪明，而是让 AI 有更好的「方法论」。

2.3 跨工具架构

                    ┌──────────────────┐
                    │  SKILL.md 源文件  │
                    │  (Anthropic 规范) │
                    └────────┬─────────┘
                             │ 一份文件，零修改
           ┌─────────────────┼─────────────────┐
           ▼                 ▼                 ▼
   ┌───────────────┐ ┌───────────────┐ ┌───────────────┐
   │  Claude Code  │ │    ZCode     │ │    Codex      │
   │   (Plugin)    │ │ (skills目录) │ │ (agents/skills)│
   └───────────────┘ └───────────────┘ └───────────────┘

三个工具使用同一份 skill 文件，不需要做任何修改。

三、项目结构详解

Lion-Skills/
├── .claude-plugin/                    # Claude Code Plugin 配置
│   ├── marketplace.json               # Plugin marketplace 声明
│   └── plugin.json                    # Plugin 元数据
├── .gitignore
├── LICENSE
├── README.md                          # 项目说明文档
├── docs/                              # 设计文档
│   ├── plans/
│   │   ├── 2026-06-16-lion-skills-mvp.md           # MVP 实施计划
│   │   └── 2026-06-17-lion-skills-plugin-distribution.md  # Plugin 分发计划
│   └── specs/
│       ├── 2026-06-16-lion-skills-design.md        # 初始设计意图
│       ├── 2026-06-17-lion-skills-plugin-distribution-design.md
│       └── 2026-06-22-skill-suite-architecture.md  # 套件架构设计
├── skills/                            # ⭐ 12 个 Skills 源码
│   ├── clarifying-questions/
│   │   ├── SKILL.md                   # Skill 核心文件
│   │   └── evals/
│   │       └── evals.json             # 回归测试用例
│   ├── spec-writing/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── task-breakdown/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── testing/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── debugging/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── code-review/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── verify-and-fix/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── commit-message/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── onboarding-unknown-codebase/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── naming/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   ├── error-handling/
│   │   ├── SKILL.md
│   │   └── evals/evals.json
│   └── lion-writing-skills/
│       ├── SKILL.md                   # ⭐ 元技能：教你怎么写 Skill
│       └── evals/evals.json
└── template/
    └── SKILL.md                        # 新建 Skill 的模板文件

3.1 每个 Skill 目录的构成

每个 skill 目录包含两个核心文件：

文件	作用
`SKILL.md`	核心操作手册 — 描述触发条件、执行步骤、输出标准
`evals/evals.json`	回归测试 — 验证 skill 的行为是否符合预期

3.2 docs 目录的设计文档

文档	说明
`2026-06-16-lion-skills-design.md`	初始设计意图，记录为什么要做这套套件
`2026-06-22-skill-suite-architecture.md`	套件架构设计，skill 之间如何协作
`2026-06-17-lion-skills-plugin-distribution.md`	Plugin 分发实施计划
`2026-06-17-lion-skills-plugin-distribution-design.md`	Plugin 分发架构设计

四、12 个 Skills 详解

4.1 上游：需求与设计（3 个）

Skill 1：`clarifying-questions` — 澄清问题

解决的问题： 需求模糊、背后的隐藏假设、X-Y Problem

触发条件：

用户描述了一个问题但没有明确目标
用户的描述暗示了特定技术方案（Y），但没有说明真正的需求（X）
需求存在多种可能的解读

核心流程：

1. 识别模糊点 — 哪些信息缺失会导致方案不同？
2. 区分 X 和 Y — 用户说的是「方案」还是「需求」？
3. 提出澄清问题 — 每次最多 3-4 个，不要信息轰炸
4. 等待回答 — 不要假设，不要替用户做决定

实际例子：

❌ 用户说：「怎么在 React 里获取 DOM 元素？」

⚠️ 这可能是个 X-Y Problem——用户真正的需求可能是：

做一个点击外部关闭的下拉菜单
实现滚动到某个元素的位置
测量元素的尺寸

每种需求对应完全不同的方案。

Skill 2：`spec-writing` — 写设计文档

解决的问题： 设计文档不可评审、没有验收标准、改代码时不知道改到什么程度算「完成」

核心流程：

1. 背景 — 为什么要做这个功能？
2. 目标 — 成功标准是什么？（可量化）
3. 非目标 — 明确什么不在这轮范围内
4. 方案设计 — 架构图、数据流、接口定义
5. 验收标准 — 怎么判断做对了？
6. 风险与权衡 — 有什么取舍？

Skill 3：`task-breakdown` — 拆解任务

解决的问题： 需求拆解不到位，任务是虚的，无法分配和验收

核心原则：

每个任务都是可独立验证的端到端单元
任务之间有明确的依赖关系
每个任务有明确的完成标准（Definition of Done）
粒度控制在 0.5 ~ 2 天的工作量

4.2 中游：开发与质量（5 个）

Skill 4：`testing` — 写能抓住 bug 的测试

解决的问题： 测试用例脆弱、覆盖率数字好看但抓不住 bug

核心原则：

原则	说明	反例
覆盖边界条件	空值、极值、边界值	只测正常输入
覆盖异常输入	非法参数、异常状态	只测 happy path
不测试实现细节	测试行为，不测试内部状态	`expect(internalVar).toBe(1)`
一个测试一个断言	每个测试只验证一个条件	一个 test 里断言 10 个东西
测试名即文档	`shouldReturnNullWhenInputIsEmpty`	`test1`、`test2`

示例对比：

// ❌ 脆皮测试
test('add works', () => {
  expect(add(1, 2)).toBe(3);
});

// ✅ 健壮测试
describe('add', () => {
  test('should return sum of two positive integers', () => {
    expect(add(1, 2)).toBe(3);
  });

  test('should return 0 when both inputs are 0', () => {
    expect(add(0, 0)).toBe(0);
  });

  test('should handle negative numbers', () => {
    expect(add(-1, -2)).toBe(-3);
  });

  test('should handle floating point precision', () => {
    expect(add(0.1, 0.2)).toBeCloseTo(0.3);
  });

  test('should throw TypeError for non-numeric input', () => {
    expect(() => add('a', 1)).toThrow(TypeError);
  });
});

Skill 5：`debugging` — 科学定位根因

解决的问题： 乱改代码、修症状不修病因、靠直觉调试

核心流程（6 步法）：

┌──────────────────────────────────────────────────────┐
│  1. 复现问题                                         │
│     - 建立最小复现步骤（Minimal Reproduction）       │
│     - 确认问题可以稳定复现                            │
├──────────────────────────────────────────────────────┤
│  2. 收集信息                                         │
│     - 错误日志、堆栈跟踪                              │
│     - 环境信息（版本、配置、网络）                    │
│     - 最近变更（git log）                             │
├──────────────────────────────────────────────────────┤
│  3. 形成假设                                         │
│     - 基于证据，不是直觉                              │
│     - 列出所有可能的根因                              │
│     - 按可能性排序                                    │
├──────────────────────────────────────────────────────┤
│  4. 验证假设                                         │
│     - 一次只改一个变量                                │
│     - 记录每一次尝试的结果                            │
│     - 排除法缩小范围                                  │
├──────────────────────────────────────────────────────┤
│  5. 修因不修果                                       │
│     - 找到 root cause                                │
│     - 不是凑巧修好就完了                              │
│     - 问自己：为什么会出现这个问题？如何预防？         │
├──────────────────────────────────────────────────────┤
│  6. 回归验证                                         │
│     - 确认修复有效                                    │
│     - 确认没有引入新问题                              │
│     - 补充对应的测试用例                              │
└──────────────────────────────────────────────────────┘

关键原则：每次只改一个变量，记录每一次尝试。

Skill 6：`code-review` — 有重点的审查

解决的问题： 审查走过场、没有重点、漏掉真正的问题

审查层次（从高到低）：

┌─────────────────────────────────────────┐
│ L6: 代码风格                             │
│    命名、格式、注释                      │
├─────────────────────────────────────────┤
│ L5: 可维护性                             │
│    可读性、可扩展性、复杂度              │
├─────────────────────────────────────────┤
│ L4: 安全性                               │
│    注入攻击、权限控制、敏感信息泄露      │
├─────────────────────────────────────────┤
│ L3: 性能                                 │
│    算法复杂度、数据库查询、缓存策略      │
├─────────────────────────────────────────┤
│ L2: 正确性                               │
│    逻辑是否正确、边界是否处理            │
├─────────────────────────────────────────┤
│ L1: 架构与设计                           │
│    整体方案是否合理、是否过度设计        │
└─────────────────────────────────────────┘

审查原则：

先看 L1（架构），再看 L2-L3，最后看 L4-L6
对每个评论标注严重程度：🔴 必须改 / 🟡 建议改 / 🟢 Nitpick
区分「事实」和「偏好」：SQL 注入风险 是事实，变量名应该用驼峰 是偏好

Skill 7：`verify-and-fix` — 把「声称完成」变成「经验证完成」

解决的问题： AI 说「好了」但没好、开发者自测不充分

验证清单：

□ 功能是否按需求正常工作？
□ 边界条件是否处理？
□ 错误场景是否有合理的反馈？
□ 是否有回归风险？（修改是否影响了其他功能）
□ 是否补充/更新了对应测试？
□ 是否更新了相关文档？
□ 是否有 console.log / debugger 残留？

Skill 8：`error-handling` — 错误处理与日志设计

解决的问题： catch(e) { console.log(e) } 满天飞、线上出问题无法排查

最佳实践：

// ❌ 反例：吞掉错误，啥信息都没有
try {
  await fetchData();
} catch (e) {
  console.log(e); // e 是什么？什么时候发生的？为什么？
}

// ✅ 正例：结构化错误处理
try {
  await fetchData();
} catch (error) {
  // 1. 记录结构化日志
  logger.error('fetchData failed', {
    error: error.message,
    stack: error.stack,
    timestamp: new Date().toISOString(),
    context: { userId: req.user.id, endpoint: '/api/data' },
  });

  // 2. 区分错误类型
  if (error instanceof NetworkError) {
    return { success: false, message: '网络异常，请稍后重试' };
  }
  if (error instanceof AuthError) {
    return { success: false, message: '登录已过期，请重新登录' };
  }

  // 3. 兜底处理
  return { success: false, message: '系统繁忙，请稍后重试' };
}

4.3 下游：交付与维护（3 个）

Skill 9：`commit-message` — 规范的提交信息

解决的问题： fix: update code 满天飞、changelog 难写

提交信息格式：

<type>(<scope>): <subject>

<body>

<footer>

Type 枚举：

Type	说明	示例
`feat`	新功能	`feat(auth): add Google OAuth login`
`fix`	Bug 修复	`fix(api): handle null response in user endpoint`
`refactor`	重构（不改变行为）	`refactor(db): extract query builder to separate module`
`docs`	文档变更	`docs: update README with installation steps`
`test`	测试相关	`test(auth): add unit tests for login flow`
`chore`	构建/工具变更	`chore: upgrade dependencies to latest`
`perf`	性能优化	`perf(list): implement virtual scrolling for large lists`

示例：

# ❌ 差劲的 commit message
git commit -m "update"

# ✅ 规范的 commit message
git commit -m "feat(auth): add Google OAuth login

- Add Google OAuth 2.0 flow
- Handle token refresh automatically
- Add error handling for auth failures

Closes #123"

Skill 10：`onboarding-unknown-codebase` — 系统化上手新项目

解决的问题： 新项目无从下手，不知道从哪看起

上手流程：

1. 从 README 开始 — 了解项目是做什么的
2. 看项目结构 — 目录命名、模块划分
3. 找到入口 — main()、index.ts、app.py
4. 追踪核心流程 — 选一个核心功能，从前端追到数据库
5. 看测试 — 测试是最好的文档
6. 看最近变更 — git log --oneline -20
7. 看架构文档 — docs/、wiki、ADR

Skill 11：`naming` — 命名决策

解决的问题： 变量名一团糟、命名没有一致性

命名原则：

场景	命名规范	示例
布尔值	is/has/can/should 前缀	`isValid`、`hasPermission`
函数	动词开头，描述动作	`fetchUserData()`、`validateEmail()`
事件处理	on/handle 前缀	`onClick`、`handleSubmit`
常量	全大写下划线分隔	`MAX_RETRY_COUNT`
类型/类	名词，大驼峰	`UserProfile`、`HttpClient`
CSS 类	BEM 或 kebab-case	`.user-card__title`、`.btn-primary`

4.4 元技能

Skill 12：`lion-writing-skills` — 教你怎么写 Skill

如果你想把团队的工作流也沉淀成 skill，或者你有自己独特的方法论想固化下来，这个 skill 就是你的「技能写作指南」。

它涵盖：

SKILL.md 的标准结构
如何写触发条件
如何组织执行步骤
如何写输出标准
如何写 evals 回归测试

五、安装指南（三种工具）

5.1 Claude Code（⭐ 推荐）

Claude Code 是 Lion-Skills 的首选平台，支持 plugin 机制，体验最好。

前提条件：

已安装 Claude Code（claude 命令可用）
网络可以访问 GitHub

步骤一：添加 Marketplace

/plugin marketplace add Lion-1209/Lion-Skills

步骤二：安装 Plugin

/plugin install lion-skills@lion-skills

步骤三：验证

新开会话，说一句话试试：

「帮我写一个登录功能的 spec」

应该自动触发 spec-writing skill。

升级旧版本（如果之前装过 0.1.0）：

/plugin marketplace update lion-skills
/plugin install lion-skills@lion-skills

⚠️ 重要提醒：Claude Code 下不要同时使用两种安装方式。如果你用 plugin 安装了，就不要再把 skill 目录拷贝到 ~/.claude/skills/，否则同名 skill 会重复触发。

5.2 ZCode

ZCode 目前通过 skills 目录方式安装（社区验证可生效）。

Windows PowerShell：

# 替换路径为你的实际路径
Copy-Item -Recurse "E:\path\to\Lion-Skills\skills\*" "$HOME\.zcode\skills\"

macOS / Linux：

cp -r /path/to/Lion-Skills/skills/* ~/.zcode/skills/

⚠️ 装完后需要新开会话，skill 才会出现在可用列表中。

自动同步（推荐）：

如果想在源仓库 git pull 后自动生效，使用 symlink 代替拷贝：

# Windows PowerShell（需要开发者模式或管理员权限）
$skills = Get-ChildItem "E:\path\to\Lion-Skills\skills" -Directory
foreach ($s in $skills) {
    New-Item -ItemType SymbolicLink -Path "$HOME\.zcode\skills\$($s.Name)" -Target $s.FullName
}

# macOS / Linux
for s in /path/to/Lion-Skills/skills/*/; do
  ln -s "$s" "$HOME/.zcode/skills/$(basename "$s")"
done

💡 注意：ZCode 的 plugin 体系由 Z.ai 官方维护，第三方个人仓库接入官方 marketplace 的路径尚不明确。目前 skills 目录方式是社区验证可行的方法。

5.3 Codex

Codex 原生支持 Agent Skills，技能目录是 ~/.agents/skills/。

macOS / Linux：

for s in /path/to/Lion-Skills/skills/*/; do
  ln -s "$s" "$HOME/.agents/skills/$(basename "$s")"
done

装完后用 /skills 或在 prompt 里用 $skill名 触发。

六、验证安装

6.1 快速验证

新开会话后，用以下 prompt 测试：

这段代码怎么改进？

try {
  const response = await fetch('/api/data');
  const data = await response.json();
  return data;
} catch (error) {
  console.log(error);
}

预期行为：

应该触发 verify-and-fix 或 error-handling skill
AI 应该指出问题并给出改进方案
改进方案应该包含：具体错误类型、结构化日志、用户友好的错误信息

6.2 逐个验证

如果快速验证没触发，逐个测试每个 skill：

测试 Prompt	预期触发的 Skill
「帮我写一个用户管理模块的设计文档」	`spec-writing`
「帮我把这个需求拆成任务」	`task-breakdown`
「帮我写一个排序算法的单元测试」	`testing`
「这个函数有 bug，帮我找一下」	`debugging`
「帮我 review 这段代码」	`code-review`
「这个功能做完了，帮我验证一下」	`verify-and-fix`
「帮我提交代码」	`commit-message`
「帮我给这个新项目写一个上手指南」	`onboarding-unknown-codebase`
「帮我给这个变量取个名字」	`naming`
「帮我设计一下异常处理逻辑」	`error-handling`

七、进阶使用技巧

7.1 串联多个 Skills

复杂任务可以串联多个 skill：

收到需求：「做一个用户注册功能」
  → clarifying-questions（问清楚注册方式、验证规则、安全要求）
  → spec-writing（写设计文档）
  → task-breakdown（拆成具体任务）
  → [执行开发]
  → testing（写测试）
  → code-review（审查）
  → verify-and-fix（验证）
  → commit-message（提交）

7.2 自定义 Skill

你可以：

阅读 skills/lion-writing-skills/SKILL.md 学习规范
复制 template/SKILL.md 从零开始
参照现有 skill 的结构编写
添加 evals/evals.json 进行回归测试

7.3 贡献到上游

如果你写的 skill 对社区有价值，可以提交 PR 到 Lion-1209/Lion-Skills。

八、如何自己写一个 Skill？

8.1 SKILL.md 标准结构

---
name: skill-name
description: 一句话描述这个 skill 做什么，以及触发条件
---

# Skill 名称

## 触发条件

在以下场景中触发：
- 场景 1
- 场景 2
- 场景 3

## 执行流程

### 步骤 1：xxx

具体怎么做。

### 步骤 2：xxx

具体怎么做。

## 输出标准

输出应该包含：
- 要求 1
- 要求 2
- 要求 3

## 示例

给出正例和反例。

## 常见错误

列出容易踩的坑。

8.2 evals.json 结构

{
  "eval_cases": [
    {
      "name": "测试用例名称",
      "input": "用户输入",
      "expected_behavior": "期望 AI 的行为",
      "pass_criteria": "通过的标准"
    }
  ]
}

8.3 从模板开始

cp template/SKILL.md skills/my-new-skill/SKILL.md
# 编辑技能内容
# 编写 evals/evals.json
# 测试验证

九、常见问题 FAQ

Q1：安装后 skill 没有自动触发？

可能原因及解决：

没有新开会话：ZCode 和 Codex 需要在安装后新开会话
自然语言不够明确：尽量用包含 skill 触发关键词的描述
工具版本过低：确保 Claude Code / ZCode / Codex 是最新版本
目录放错了：检查 skill 目录的路径是否正确

Q2：Claude Code 安装 plugin 报错？

# 确认能访问 GitHub
gh repo view Lion-1209/Lion-Skills

# 如果网络不通，可能需要代理
# 或者手动 clone 后本地安装

Q3：多个 skill 同时触发了怎么办？

如果两个 skill 的场景重叠，AI 通常会选择最匹配的一个。如果确实有冲突，可以在 SKILL.md 的 description 中调整触发条件的优先级描述。

Q4：symlink 在 Windows 上报错？

Windows 创建 symlink 需要开发者模式或管理员权限：

# 方法一：启用开发者模式
# 设置 → 系统 → 开发者选项 → 启用开发者模式

# 方法二：用管理员权限打开 PowerShell
# 右键 PowerShell → 以管理员身份运行

Q5：如何更新 skill 到最新版本？

Claude Code（Plugin）：

/plugin marketplace update lion-skills
/plugin install lion-skills@lion-skills

ZCode / Codex（symlink）：

cd /path/to/Lion-Skills
git pull
# symlink 方式自动生效，无需额外操作

ZCode（拷贝方式）：

# 重新执行一遍拷贝命令
Copy-Item -Recurse "E:\path\to\Lion-Skills\skills\*" "$HOME\.zcode\skills\"

十、总结与资源

10.1 特性速查

特性	说明
开源项目	Lion-1209/Lion-Skills
Skill 数量	12 个（0.2.0 版本）
规范基础	Anthropic Agent Skills (`SKILL.md`)
支持工具	Claude Code、ZCode、Codex
跨工具	一份 skill 文件，零修改，全平台通用
可扩展	提供 skill 写作规范和模板
可验证	每个 skill 附带 evals 回归测试

10.2 快速链接

资源	链接
GitHub 仓库	github.com/Lion-1209/Lion-Skills
Anthropic Agent Skills 规范	docs.anthropic.com/en/docs/build-with-claude/agent-skills
套件架构设计	`docs/specs/2026-06-22-skill-suite-architecture.md`
初始设计意图	`docs/specs/2026-06-16-lion-skills-design.md`
Skill 写作指南	`skills/lion-writing-skills/SKILL.md`
Skill 模板	`template/SKILL.md`

10.3 写在最后

这套套件的出发点很简单：把「怎么做」从 prompt 里抽出来，变成一份可复用的操作手册。

好处是显而易见的：

AI 的回答更稳定、更可预测
方法论沉淀在 skill 文件里，不会因为换项目、换工具而丢失
团队可以一起 review 和迭代这些 skill
你可以基于这套框架，扩展出自己团队专属的 skill

觉得有用？欢迎 Star ⭐

👉 github.com/Lion-1209/Lion-Skills

作者注：本文基于 Lion-Skills 仓库内容整理，所有 skill 内容遵循 Anthropic Agent Skills 规范。

龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

我用 NVIDIA SkillSpector 纯静态扫了一遍 GitHub 最火的 agent skills：能挖出多少注入？0 个

龙虾开发者社区

周榜换血九成，Agent Skills 星数翻倍

龙虾开发者社区

写给 TypeScript 工程师的 OpenClaw.NET 上手指南：用你熟悉的 TS 思维，跑起一个生产级 AI Agent

读代码层：TS 和 C# 本来就是「远房亲戚」——asyncawait??、接口、泛型、严格空检查，你的心智模型几乎无缝平移。真正要适应的只有两件事：类型是具名而非结构化的（多一句显式声明），以及 NativeAOT 下的「禁反射」约束。写扩展层：你甚至可以不怎么碰 C#——Node.js 插件桥意味着你的 TypeScript 插件就是一等公民，而且能在生产 aot 车道跑。内核给你 .NET

龙虾开发者社区

所有评论(0)

查看更多评论

梁子应该没事吧

@qq_52935238

已为社区贡献2条内容

Lion-Skills：一套让 AI 编程更靠谱的 12 个 Skills

梁子应该没事吧

手把手教你安装 Lion-Skills：一套让 AI 编程更靠谱的 12 个 Skills

目录

一、为什么需要 Skills？

1.1 现实痛点

1.2 根本原因

1.3 Skills 的解决思路

二、项目概览

2.1 基本信息

2.2 核心理念

2.3 跨工具架构

三、项目结构详解

3.1 每个 Skill 目录的构成

3.2 docs 目录的设计文档

四、12 个 Skills 详解

4.1 上游：需求与设计（3 个）

Skill 1：clarifying-questions — 澄清问题

Skill 2：spec-writing — 写设计文档

Skill 3：task-breakdown — 拆解任务

4.2 中游：开发与质量（5 个）

Skill 4：testing — 写能抓住 bug 的测试

Skill 5：debugging — 科学定位根因

Skill 6：code-review — 有重点的审查

Skill 7：verify-and-fix — 把「声称完成」变成「经验证完成」

Skill 8：error-handling — 错误处理与日志设计

4.3 下游：交付与维护（3 个）

Skill 9：commit-message — 规范的提交信息

Skill 10：onboarding-unknown-codebase — 系统化上手新项目

Skill 11：naming — 命名决策

4.4 元技能

Skill 12：lion-writing-skills — 教你怎么写 Skill

五、安装指南（三种工具）

5.1 Claude Code（⭐ 推荐）

5.2 ZCode

5.3 Codex

六、验证安装

6.1 快速验证

6.2 逐个验证

七、进阶使用技巧

7.1 串联多个 Skills

7.2 自定义 Skill

7.3 贡献到上游

八、如何自己写一个 Skill？

8.1 SKILL.md 标准结构

8.2 evals.json 结构

8.3 从模板开始

九、常见问题 FAQ

Q1：安装后 skill 没有自动触发？

Q2：Claude Code 安装 plugin 报错？

Q3：多个 skill 同时触发了怎么办？

Q4：symlink 在 Windows 上报错？

Q5：如何更新 skill 到最新版本？

十、总结与资源

10.1 特性速查

10.2 快速链接

10.3 写在最后

手把手教你安装 Lion-Skills：一套让 AI 编程更靠谱的 12 个 Skills

目录

一、为什么需要 Skills？

1.1 现实痛点

1.2 根本原因

1.3 Skills 的解决思路

二、项目概览

2.1 基本信息

2.2 核心理念

2.3 跨工具架构

三、项目结构详解

3.1 每个 Skill 目录的构成

3.2 docs 目录的设计文档

四、12 个 Skills 详解

4.1 上游：需求与设计（3 个）

Skill 1：clarifying-questions — 澄清问题

Skill 2：spec-writing — 写设计文档

Skill 3：task-breakdown — 拆解任务

4.2 中游：开发与质量（5 个）

Skill 4：testing — 写能抓住 bug 的测试

Skill 5：debugging — 科学定位根因

Skill 6：code-review — 有重点的审查

Skill 7：verify-and-fix — 把「声称完成」变成「经验证完成」

Skill 1：`clarifying-questions` — 澄清问题

Skill 2：`spec-writing` — 写设计文档

Skill 3：`task-breakdown` — 拆解任务

Skill 4：`testing` — 写能抓住 bug 的测试

Skill 5：`debugging` — 科学定位根因

Skill 6：`code-review` — 有重点的审查

Skill 7：`verify-and-fix` — 把「声称完成」变成「经验证完成」

Skill 8：`error-handling` — 错误处理与日志设计

Skill 9：`commit-message` — 规范的提交信息

Skill 10：`onboarding-unknown-codebase` — 系统化上手新项目

Skill 11：`naming` — 命名决策

Skill 12：`lion-writing-skills` — 教你怎么写 Skill

Skill 1：`clarifying-questions` — 澄清问题

Skill 2：`spec-writing` — 写设计文档

Skill 3：`task-breakdown` — 拆解任务

Skill 4：`testing` — 写能抓住 bug 的测试

Skill 5：`debugging` — 科学定位根因

Skill 6：`code-review` — 有重点的审查

Skill 7：`verify-and-fix` — 把「声称完成」变成「经验证完成」

Skill 8：`error-handling` — 错误处理与日志设计

Skill 9：`commit-message` — 规范的提交信息

Skill 10：`onboarding-unknown-codebase` — 系统化上手新项目

Skill 11：`naming` — 命名决策

Skill 12：`lion-writing-skills` — 教你怎么写 Skill