本教程面向已有Skill开发基础的用户,深入讲解Claude Code Skills 2.0引入的评测(Eval)、基准测试(Benchmark)和A/B测试体系。你将学会如何为自定义Skill编写数据驱动的测试用例、运行自动化基准测试、优化触发描述以提升召回率,以及建立持续质量保证流程。适合希望将Skill从"能用"提升到"生产级可靠"的开发者。
适用人群:已掌握SKILL.md基础编写、希望系统化验证和优化Skill质量的中高级开发者。
学习目标: - 理解Skills 2.0评测体系的三层架构(Eval → Benchmark → A/B Test) - 掌握eval用例的编写规范与数据集设计 - 学会使用skill-creator内置的基准测试工具链 - 能够通过trigger优化和description调优提升Skill触发精度 - 建立Skill版本迭代的质量门禁流程
| 项目 | 要求 |
|---|---|
| Claude Code | v1.0.28+(支持Skills 2.0评测功能) |
| 已有Skill | 至少一个可运行的SKILL.md文件 |
| skill-creator | 通过/install-skill skill-creator安装 |
| 基础知识 | YAML frontmatter、Markdown指令编写 |
| 测试数据 | 准备3-10组真实使用场景的输入样本 |
传统Skill开发流程存在一个核心痛点:"祈祷式发布"——写完SKILL.md,手动测一次,发布,然后祈祷它在各种场景下都能正确触发和执行。这种方式的致命缺陷:
2026年3月3日,Anthropic正式发布Skills 2.0,在skill-creator中集成了完整的评测工具链,彻底改变了这一局面。
graph TB
subgraph "第一层:Eval 单元测试"
E1[测试用例编写] --> E2[输入-期望输出对]
E2 --> E3[通过/失败判定]
end
subgraph "第二层:Benchmark 基准测试"
B1[多场景数据集] --> B2[批量运行评估]
B2 --> B3[量化评分报告]
end
subgraph "第三层:A/B Test 对比测试"
A1[两个Skill版本] --> A2[盲测对比]
A2 --> A3[统计显著性分析]
end
E3 --> B1
B3 --> A1
style E1 fill:#e1f5fe
style B1 fill:#f3e5f5
style A1 fill:#fff3e0
第一层:Eval(单元测试)——验证单个场景下Skill是否按预期工作。类似于软件工程中的单元测试,每个eval用例定义一组"输入→期望输出"的映射。
第二层:Benchmark(基准测试)——在多个场景上批量运行eval,生成量化评分报告。告诉你Skill的整体表现水平和薄弱环节。
第三层:A/B Test(对比测试)——将两个Skill版本(如原始版 vs 优化版)进行盲测对比,用统计数据判断哪个版本更好。
每个eval用例是一个JSON对象,包含三个核心字段:
{
"name": "simple-greeting-response",
"input": {
"user_message": "帮我写一个Python的快速排序函数"
},
"expected": {
"triggered": true,
"output_contains": ["def quicksort", "pivot"],
"output_not_contains": ["bubble sort", "冒泡排序"],
"behavior_checks": [
"代码应包含递归调用",
"应处理空列表和单元素列表的边界情况"
]
}
}
| 字段 | 类型 | 必填 | 说明 |
|---|---|---|---|
name |
string | ✅ | 用例唯一标识,使用kebab-case命名 |
input.user_message |
string | ✅ | 模拟用户输入的消息 |
expected.triggered |
boolean | ❌ | 是否期望Skill被触发 |
expected.output_contains |
string[] | ❌ | 输出必须包含的关键内容 |
expected.output_not_contains |
string[] | ❌ | 输出不应包含的内容 |
expected.behavior_checks |
string[] | ❌ | 语义级别的行为验证描述 |
expected.tool_calls |
string[] | ❌ | 期望调用的工具列表 |
原则一:覆盖正向和负向场景
[
{
"name": "positive-api-test-request",
"input": { "user_message": "帮我写一个REST API的集成测试" },
"expected": { "triggered": true }
},
{
"name": "negative-unrelated-question",
"input": { "user_message": "今天天气怎么样" },
"expected": { "triggered": false }
},
{
"name": "edge-case-ambiguous-request",
"input": { "user_message": "测试一下" },
"expected": {
"triggered": false,
"behavior_checks": ["不应在模糊请求时盲目触发"]
}
}
]
原则二:从真实用户输入取样,不要自己编造
真实用户的表述往往比开发者预期的更模糊、更口语化。从聊天记录、用户反馈中提取真实输入作为eval用例,比手工构造的"完美输入"更有价值。
原则三:用behavior_checks代替精确匹配
避免写output_contains: ["具体的某行代码"],这太脆弱。改用语义级描述:
{
"expected": {
"behavior_checks": [
"生成的代码应包含错误处理逻辑",
"应解释关键设计决策的理由",
"代码应可直接运行而不需要额外依赖安装"
]
}
}
原则四:边界条件必须覆盖
{
"name": "edge-empty-input",
"input": { "user_message": "" },
"expected": {
"triggered": false,
"behavior_checks": ["空输入不应触发Skill"]
}
},
{
"name": "edge-very-long-input",
"input": { "user_message": "帮我看这段[5000字代码]..." },
"expected": {
"triggered": true,
"behavior_checks": ["应能处理长输入而不截断"]
}
}
原则五:每个用例只验证一个关注点
不要在一个eval中同时验证触发逻辑、输出格式、工具调用。拆成三个独立用例,失败时能快速定位问题。
在Skill目录下创建evals/文件夹,存放测试用例:
my-skill/
├── SKILL.md
├── evals/
│ ├── basic.json # 基础功能测试
│ ├── edge-cases.json # 边界条件测试
│ └── regression.json # 回归测试用例
└── examples/ # 示例文件(可选)
└── sample-output.md
通过skill-creator交互式创建eval:
# 在Claude Code中调用skill-creator
/skill-creator
# 选择 "Add evals to an existing skill"
# 然后指向你的SKILL.md路径
skill-creator会引导你完成:
1. 选择要评测的Skill
2. 定义测试场景(正向/负向/边界)
3. 自动生成eval JSON文件
4. 放入evals/目录
你也可以手动编写完整的eval数据集文件evals/basic.json:
{
"skill_name": "api-test-generator",
"version": "1.2.0",
"evals": [
{
"name": "rest-api-crud-test",
"input": {
"user_message": "为用户管理API的CRUD接口写集成测试,base URL是/api/v1/users"
},
"expected": {
"triggered": true,
"output_contains": ["describe", "it(", "request"],
"behavior_checks": [
"应覆盖GET/POST/PUT/DELETE四个方法",
"应包含状态码断言",
"应使用测试框架的describe/it结构"
]
}
},
{
"name": "graphql-mutation-test",
"input": {
"user_message": "写GraphQL mutation的测试用例"
},
"expected": {
"triggered": true,
"output_contains": ["mutation", "query"],
"behavior_checks": [
"应区分query和mutation的测试",
"应处理GraphQL错误响应格式"
]
}
}
]
}
通过skill-creator的评测命令运行:
# 在Claude Code对话中
/skill-creator
# 选择 "Run evals on a skill"
# 输入Skill路径和eval文件路径
skill-creator会逐个执行eval用例,对每个用例:
input.user_message作为模拟用户输入expected.triggered已定义)output_contains和output_not_containsbehavior_checks中的语义条件运行完成后,你会看到类似报告:
╔═══════════════════════════════════════════════════╗
║ Eval Report: api-test-generator v1.2.0 ║
╠═══════════════════════════════════════════════════╣
║ Total: 8 evals ║
║ Passed: 6 · Failed: 1 · Warning: 1 ║
║ Score: 75/100 ║
╠═══════════════════════════════════════════════════╣
║ ✅ rest-api-crud-test PASSED ║
║ ✅ graphql-mutation-test PASSED ║
║ ✅ websocket-test PASSED ║
║ ❌ streaming-api-test FAILED ║
║ → output_missing: "应处理分块传输编码" ║
║ ⚠️ authentication-test WARNING ║
║ → behavior_check不确定: 需要人工复核 ║
╚═══════════════════════════════════════════════════╝
| 失败类型 | 根因 | 修复方案 |
|---|---|---|
| 触发失败(应触发未触发) | description不够精确或trigger条件过窄 | 扩展description中的同义词和场景描述 |
| 误触发(不应触发却触发) | description过于宽泛 | 添加NOT条件,缩小触发范围 |
| 输出内容缺失 | SKILL.md指令不够具体 | 增加"必须包含"的明确指令 |
| behavior_check不确定 | 检查描述太主观 | 用更具体的可观测条件替代 |
| 全部失败 | Skill文件有语法错误 | 检查YAML frontmatter格式 |
Benchmark是Eval的升级版——它不在单一用例上判定通过/失败,而是在一组代表性场景上量化评估Skill的整体表现,并生成可比较的分数。
flowchart LR
subgraph "Benchmark流程"
A[准备数据集<br/>10-50个场景] --> B[运行所有Eval]
B --> C[收集原始结果]
C --> D[计算维度评分]
D --> E[生成综合报告]
end
subgraph "评分维度"
D1[触发准确率<br/>Trigger Accuracy]
D2[输出质量<br/>Output Quality]
D3[指令遵循度<br/>Instruction Adherence]
D4[边界处理<br/>Edge Case Handling]
end
D --> D1
D --> D2
D --> D3
D --> D4
# 通过skill-creator运行
/skill-creator
# 选择 "Run benchmark on a skill"
# 指定Skill路径和benchmark数据集
skill-creator内置了两层评测体系:
第一层:快速验证(Quick Check) - 使用5-10个核心场景 - 运行时间约2-3分钟 - 适合开发过程中快速迭代
第二层:深度评测(Full Benchmark) - 使用20-50个覆盖全面的场景 - 运行时间约10-20分钟 - 适合发布前的全面验证
╔════════════════════════════════════════════════════════════╗
║ Benchmark Report: api-test-generator v1.2.0 ║
║ Date: 2026-06-11 · Model: claude-sonnet-4-6 ║
║ Dataset: 25 scenarios (15 positive + 8 negative + 2 edge)║
╠════════════════════════════════════════════════════════════╣
║ ║
║ 📊 Trigger Accuracy: 88/100 (22/25 correct) ║
║ True Positive: 14/15 · False Negative: 1/15 ║
║ True Negative: 8/8 · False Positive: 0/8 ║
║ ║
║ 📝 Output Quality: 82/100 ║
║ Completeness: 85 · Accuracy: 80 · Clarity: 81 ║
║ ║
║ 🎯 Instruction Adherence: 91/100 ║
║ Format compliance: 95 · Constraint respect: 87 ║
║ ║
║ 🔧 Edge Case Handling: 65/100 ⚠️ ║
║ Empty input: PASS · Very long: FAIL ║
║ Malformed: PASS · Ambiguous: WARNING ║
║ ║
║ 🏆 Overall Score: 81.5/100 ║
╚════════════════════════════════════════════════════════════╝
关键指标解读:
Skill的description字段是触发系统的核心依据。Claude根据description判断何时激活Skill。一个经过评测优化的description通常经历这样的迭代:
初始版本(触发率68%):
---
name: api-test-generator
description: Generate API integration tests
---
问题:太短,无法覆盖用户的各种表述方式。
第一轮优化(触发率82%):
---
name: api-test-generator
description: >-
Generate integration tests for REST APIs, GraphQL endpoints,
and WebSocket connections. Use when user asks to write API tests,
integration tests, or endpoint testing.
---
改进:增加了具体的API类型和用户可能的表述。
最终版本(触发率94%):
---
name: api-test-generator
description: >-
Generate integration tests for REST APIs, GraphQL endpoints,
WebSocket connections, and gRPC services. Use when user asks to
write API tests, integration tests, endpoint testing, route
testing, or HTTP handler tests. Supports Jest, Mocha, pytest,
and Go testing frameworks. Also handles test generation for
authentication flows, rate limiting, error handling, and
streaming responses. Do NOT trigger for unit tests, performance
tests, or load tests.
---
关键改进: 1. 扩展了API类型覆盖(增加gRPC) 2. 增加了框架名称(Jest、Mocha等)作为触发关键词 3. 列出了更多用户可能的说法("route testing"、"HTTP handler tests") 4. 明确声明了不触发的场景(NOT trigger条件)
flowchart TD
A[运行Benchmark] --> B{分析False Negative}
B --> |"有未触发的正向场景"| C[提取用户表述关键词]
C --> D[将关键词加入description]
D --> E[重新运行Benchmark]
B --> |"无False Negative"| F{分析False Positive}
F --> |"有误触发的负向场景"| G[添加NOT触发条件]
G --> E
F --> |"无False Positive"| H[Trigger优化完成]
E --> I{触发率 ≥ 90%?}
I --> |是| H
I --> |否| J[检查Eval用例覆盖度]
J --> C
实操步骤:
第一步:运行Benchmark,关注Trigger Accuracy的False Negative和False Positive。
第二步:对每个False Negative,记录用户原始表述,提取其中与Skill意图匹配但description中缺失的关键词。
第三步:对每个False Positive,分析为什么Skill在不相关场景被触发,在description末尾添加明确的排除条件。
第四步:更新description后重新运行Benchmark,对比前后差异。
第五步:如果触发率仍未达到90%,检查是否Eval用例的"期望"定义本身有误(有时候不是Skill的问题,而是测试期望写错了)。
| 法则 | 说明 | 示例 |
|---|---|---|
| 开头一句定调 | 第一句话概括核心功能 | "Generate integration tests for APIs" |
| 列出触发场景 | 用自然语言列举用户可能的请求 | "Use when user asks to..." |
| 包含同义词 | 不同用户可能用不同术语 | "tests / specs / test cases" |
| 声明排除范围 | 明确什么情况下不触发 | "Do NOT trigger for..." |
| 提及技术栈 | 列出支持的框架和工具 | "Supports Jest, Mocha, pytest" |
| 控制在150词以内 | 过长的description反而降低触发精度 | 聚焦核心场景 |
当你对Skill做了一次较大的修改(重构指令、调整输出格式、更换工具调用策略),单凭Benchmark分数的变化不足以判断改进是否真实——因为分数波动可能是随机因素导致的。A/B Test通过多次重复运行消除随机性,给出统计上可靠的结论。
# 在Claude Code中通过skill-creator运行
/skill-creator
# 选择 "Run A/B test between two skill versions"
# 指定版本A(当前版本)和版本B(新版本)的SKILL.md路径
# 选择评测数据集
# 设定运行次数(推荐≥5次以获得统计显著性)
skill-creator会在相同的数据集上,对两个版本进行盲测——评测系统不知道哪个是A哪个是B,避免偏见。
╔════════════════════════════════════════════════════════════╗
║ A/B Test Report ║
║ Variant A: api-test-generator v1.2.0 (current) ║
║ Variant B: api-test-generator v1.3.0 (candidate) ║
║ Dataset: 25 scenarios · Runs: 5 · Total: 250 evals ║
╠════════════════════════════════════════════════════════════╣
║ ║
║ 📊 Overall Score: ║
║ Variant A: 81.5 ± 2.3 ║
║ Variant B: 87.2 ± 1.8 ║
║ Delta: +5.7 · p-value: 0.023 ✅ Significant ║
║ ║
║ 📊 Trigger Accuracy: ║
║ Variant A: 88.0 ± 3.1 ║
║ Variant B: 93.6 ± 1.5 ║
║ Delta: +5.6 · p-value: 0.031 ✅ Significant ║
║ ║
║ 📊 Edge Case Handling: ║
║ Variant A: 65.0 ± 5.2 ║
║ Variant B: 78.3 ± 3.7 ║
║ Delta: +13.3 · p-value: 0.008 ✅ Significant ║
║ ║
║ 🏆 Recommendation: DEPLOY Variant B ║
╚════════════════════════════════════════════════════════════╝
关键数据: - Delta:两个版本的分数差。正数表示B更好。 - p-value:统计显著性。小于0.05表示差异不太可能是随机波动。 - ±后面的是标准差:越小表示结果越稳定。
假设我们有一个code-reviewer Skill,用于对代码进行安全审查。我们要通过完整的评测流程将它从v1.0优化到生产级别。
---
name: code-reviewer
description: Review code for security vulnerabilities and best practices
---
You are a security-focused code reviewer. When the user provides code:
1. Analyze the code for security vulnerabilities (SQL injection, XSS, CSRF, etc.)
2. Check for common anti-patterns
3. Suggest fixes with explanations
4. Rate severity: CRITICAL / HIGH / MEDIUM / LOW
Output format:
- Use a table for findings with columns: Line, Severity, Issue, Fix
- End with a summary of total findings by severity
evals/security-review.json:
{
"skill_name": "code-reviewer",
"version": "1.0.0",
"evals": [
{
"name": "sql-injection-detection",
"input": {
"user_message": "Review this code for security issues:\n```python\nquery = f\"SELECT * FROM users WHERE name = '{user_input}'\"\ncursor.execute(query)\n```"
},
"expected": {
"triggered": true,
"output_contains": ["SQL injection", "parameterized", "CRITICAL"],
"output_not_contains": ["看起来没问题", "安全"],
"behavior_checks": [
"应识别SQL注入漏洞",
"应建议使用参数化查询",
"应标记为CRITICAL或HIGH严重级别"
]
}
},
{
"name": "xss-detection",
"input": {
"user_message": "Is this React component safe?\n```jsx\n<div dangerouslySetInnerHTML={{__html: userContent}} />\n```"
},
"expected": {
"triggered": true,
"output_contains": ["XSS", "dangerouslySetInnerHTML"],
"behavior_checks": [
"应识别XSS风险",
"应建议替代方案如DOMPurify"
]
}
},
{
"name": "negative-non-code-input",
"input": {
"user_message": "帮我写一个产品需求文档"
},
"expected": {
"triggered": false
}
},
{
"name": "negative-general-chat",
"input": {
"user_message": "你好,今天天气不错"
},
"expected": {
"triggered": false
}
},
{
"name": "edge-hardcoded-secret",
"input": {
"user_message": "Review this config:\n```yaml\ndatabase:\n host: prod-db.internal\n password: admin123\n```"
},
"expected": {
"triggered": true,
"output_contains": ["hardcoded", "password", "CRITICAL"],
"behavior_checks": [
"应识别硬编码密码",
"应建议使用环境变量或密钥管理"
]
}
}
]
}
假设初始结果:
Trigger Accuracy: 60/100 (3/5 correct)
❌ xss-detection failed to trigger
❌ edge-hardcoded-secret failed to trigger
Output Quality: 70/100
⚠️ sql-injection output missing severity rating
Edge Case: 50/100
❌ hardcoded-secret not detected
Overall: 60/100
问题一:XSS场景未触发
根因:description只提到了"security vulnerabilities",未包含前端安全、React安全等关键词。
修复:更新description
description: >-
Review code for security vulnerabilities and best practices.
Use when user asks to review code, check for security issues,
audit code, find vulnerabilities, or analyze code safety.
Covers: SQL injection, XSS, CSRF, hardcoded secrets,
insecure dependencies, misconfigurations, authentication
flaws, and data exposure risks. Works with Python, JavaScript,
TypeScript, Go, Java, YAML config files, and more.
Do NOT trigger for non-code content like documentation,
requirements, or general chat.
问题二:硬编码密码未检测到
根因:SKILL.md指令中未明确提到配置文件审查。
修复:扩展指令
You are a security-focused code reviewer. When the user provides code or configuration:
1. Analyze for security vulnerabilities:
- Injection flaws (SQL, XSS, command injection, LDAP injection)
- **Hardcoded secrets** (passwords, API keys, tokens in config files)
- Authentication and authorization issues
- Data exposure risks
- Insecure defaults and misconfigurations
- Dependency vulnerabilities
将v1.0和v1.1进行A/B Test对比:
Variant A (v1.0): 60.0 ± 4.2
Variant B (v1.1): 88.5 ± 2.1
Delta: +28.5 · p-value: 0.004 ✅ Significant
Recommendation: DEPLOY Variant B
将每次优化的eval用例归档到evals/regression.json,确保未来修改不会破坏已修复的功能:
{
"skill_name": "code-reviewer",
"version": "1.1.0",
"regression_suite": true,
"evals": [
{
"name": "regression-xss-trigger",
"input": {
"user_message": "这个React组件安全吗?\n```jsx\n<div dangerouslySetInnerHTML={{__html: data}} />\n```"
},
"expected": {
"triggered": true,
"output_contains": ["XSS", "dangerouslySetInnerHTML"]
}
},
{
"name": "regression-hardcoded-secret",
"input": {
"user_message": "Review this config:\n```yaml\napi_key: sk-1234567890abcdef\n```"
},
"expected": {
"triggered": true,
"output_contains": ["hardcoded", "secret"]
}
}
]
}
flowchart TD
A[Skill代码修改] --> B[运行快速Eval<br/>~2分钟]
B --> C{通过率 ≥ 80%?}
C --> |否| D[修复问题]
D --> B
C --> |是| E[运行完整Benchmark<br/>~15分钟]
E --> F{Overall ≥ 85?}
F --> |否| G[分析薄弱维度]
G --> H[针对性优化]
H --> E
F --> |是| I[A/B Test vs 上一版本]
I --> J{B版本显著更好?}
J --> |否| K[保留A版本<br/>记录测试结果]
J --> |是| L[部署B版本]
L --> M[归档regression eval]
M --> N[更新版本号]
style A fill:#e3f2fd
style L fill:#c8e6c9
style K fill:#fff9c4
| 等级 | Overall Score | 发布建议 |
|---|---|---|
| 🟢 Production Ready | ≥ 90 | 可发布到公共市场 |
| 🟡 Beta Quality | 75-89 | 可团队内使用,标注Beta |
| 🟠 Experimental | 60-74 | 仅个人使用,需持续优化 |
| 🔴 Needs Work | < 60 | 不建议使用,需大幅改进 |
利用Claude Code的cron/schedule功能,定期自动运行Skill评测:
# 设置每日回归测试(示例)
# 在.claude/settings.json的hooks中配置
{
"hooks": {
"post_prompt": [{
"matcher": "skill-regression-check",
"command": "claude -p 'Run evals on my code-reviewer skill using evals/regression.json and report results'"
}]
}
}
同一个Skill在不同Claude模型上的表现可能差异显著。建议在Benchmark中加入模型维度:
{
"skill_name": "code-reviewer",
"benchmark_config": {
"models": ["claude-sonnet-4-6", "claude-opus-4-8", "claude-haiku-4-5"],
"compare_across_models": true
}
}
这可以帮助你发现: - 某些behavior_check只在Opus上通过(指令理解差异) - 触发行为在不同模型上一致性如何 - 输出格式在不同模型上的稳定性
当Skill应该触发但没有触发时,使用以下排查步骤:
方法一:直接测试触发
# 在Claude Code中输入
/skill-creator
# 选择 "Test skill triggering"
# 输入你的用户消息
# 查看哪些Skill被考虑以及为什么没被选中
方法二:对比测试
创建一个最小化的Skill,只包含name和description,看是否能触发。如果最小版本能触发,说明问题在SKILL.md的指令内容中。如果最小版本也不能触发,说明问题在description。
方法三:日志分析
# 启用debug模式查看Skill匹配过程
DEBUG=claude:skills claude -p "your test message"
问题:Skill触发了,但输出不符合预期。
排查路径:
## Example Output
When reviewing code with SQL injection:
| Line | Severity | Issue | Fix |
|------|----------|-------|-----|
| 3 | CRITICAL | SQL Injection via string formatting | Use parameterized queries: `cursor.execute("SELECT * FROM users WHERE name = ?", (user_input,))` |
**Summary**: 1 CRITICAL, 0 HIGH, 0 MEDIUM, 0 LOW
如果A/B Test中标准差过大(>5),通常是因为:
修复方案:
| 频率 | 动作 |
|---|---|
| 每次修改后 | 运行快速Eval |
| 每周 | 运行完整Benchmark |
| 每次模型更新后 | 重新运行全套测试 |
| 每月 | 审查并补充eval用例 |
| 每季度 | A/B Test当前版本 vs 最新最佳实践 |
| 维度 | 评估 |
|---|---|
| 适用训练营类型 | AI工程训练营、Claude Code高级训练营、Skill开发者认证班 |
| 教学时长 | 3-4小时(含实操) |
| 前置课程 | Skills基础开发课程(Round 2入门篇) |
| 实操占比 | 60%(eval编写 + benchmark运行 + A/B test分析) |
| 难度等级 | ⭐⭐⭐⭐ 中高级 |
| 分组建议 | 2-3人一组,每组负责一个Skill的完整评测优化闭环 |
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
