ClaudeCode 的 Skills 技能包最近讨论热度很高。不少人把它理解为“给 ClaudeCode 写一套提示词模板”实际上它是一套更完整的机制把指令、脚本、元数据、依赖说明和调用约定封装在一起让 ClaudeCode 在特定任务里自动选择合适的技能来执行。今天这篇就围绕 ClaudeCode Skills 技能包开发与自动化实战展开适合已经在用 ClaudeCode、想提升自动化测试、前端开发、接口调试、批量任务处理效率的开发者。文章会把技能包的结构、开发步骤、自动化配置、本地部署、调试和常见坑点都拆开讲清楚。很多人的第一个疑问是ClaudeCode 本身已经能通过对话完成不少操作为什么还要额外开发技能包答案是稳定性。普通对话里让模型“扮演一个测试同学”或“用 Python 写一个接口自动化框架”每次生成的策略可能都不一样。技能包则把任务定义、执行方式、输入输出格式、甚至参考脚本都固定下来模型调用时相当于按规则执行结果的可重复性和可控性会好很多。1. 先明确 Skills 技能包到底解决什么问题1.1 技能包不是提示词模板而是一套可执行约定ClaudeCode 的 Skills 机制简单说就是让 ClaudeCode 在特定场景下具备“专业技能”。这个专业能力不是靠用户临时打字描述出来的而是通过一个技能目录结构、一份技能说明文档、若干脚本或参考文件预先定义的。技能包至少包含三层内容元数据描述技能叫什么、什么时候该用、能处理什么输入、输出什么结果。执行逻辑用脚本、命令或伪代码说明任务怎么做。调用约定模型读到这个技能后应该按什么顺序、什么参数格式执行。这种设计和传统自动化脚本的区别在于传统脚本是“人来触发、按固定流程执行”技能包是“模型根据用户需求判断要不要用、怎么用”。它更适合任务边界清晰、但每次输入有差异的场景。比如接口自动化测试你可以写一个技能包包含请求模板、鉴权方式、断言规则、报告生成逻辑。用户只要说“帮我把这个接口跑一遍自动化测试”模型就会按技能包里的约定去执行而不是每次重新设计一套方案。1.2 哪些场景适合开发技能包根据目前社区的使用反馈以下几类场景收益比较明显自动化测试接口测试、UI 测试、回归测试把测试步骤和断言规则封装成技能。前端开发辅助组件生成、样式规范检查、代码提交信息生成把团队的开发规范固化到技能里。批量文件处理重命名、格式转换、内容提取、批量生成配置。后端接口联调按 OpenAPI 文档生成测试请求检查返回值。流水线联动把 ClaudeCode 接入 Jenkins、GitLab CI 或本地脚本用技能包定义任务执行策略。知识库问答把内部文档、操作手册整理成技能让模型按固定口径回答问题。反过来如果你的任务高度开放比如“帮我头脑风暴一下产品方案”这种场景不适合技能包更适合直接对话。技能包的价值在于把“稳定执行”变成默认行为。2. 开发一个技能包之前要准备什么2.1 环境与依赖开发和测试 ClaudeCode Skills需要一个能正常运行的 ClaudeCode 环境。输入材料里没有给出明确版本但根据常见实践建议先确认以下条件ClaudeCode 已安装且能正常启动。模型 API 已配置支持长上下文更佳。本地有 Python 或 Node.js 运行环境因为很多技能包会调用脚本。准备一个单独的测试目录不要在正式项目里直接开发技能包。如果要用到自动化测试确认目标服务或网页可以被本地访问。系统方面Windows、macOS、Linux 都有使用案例。有用户反馈 Windows 上安装时遇到过“与 64 位版本 Windows 不兼容”或安装路径异常的情况这类问题通常和安装包版本、系统位数、下载来源有关。建议优先从官网或官方仓库下载不要用来历不明的安装包。2.2 先跑通一个最小示例无论你最终想开发多复杂的技能包第一步都不要直接写完整技能。我建议按下面三步走先用 ClaudeCode 完成一次普通对话任务确认基础功能正常。在项目目录下创建技能包文件夹只放一个最简单的技能说明。让 ClaudeCode 触发这个技能确认它能被识别。很多人在最开始就写十几个脚本、几百行配置结果技能包始终不生效排查半天发现是目录命名或格式问题。先跑通最小示例能省下大量调试时间。2.3 准备技能包目录结构ClaudeCode 对技能包没有严格的全局强制规范但社区实践已经形成了一套比较好用的目录约定。下面是一个示例结构skills/ └── api-testing/ ├── SKILL.md ├── scripts/ │ ├── run_tests.py │ └── parse_result.py ├── templates/ │ └── interface_test_template.md └── config/ └── settings.jsonSKILL.md 是技能的核心说明文件。模型会先读这个文件来判断是否使用该技能、怎么使用。我的建议是SKILL.md 里不要写大段代码要写清楚“何时用、怎么用、输入是什么、输出是什么、需要注意什么”具体的逻辑放到 scripts 或参考文档里。3. 一个可复用的前端开发技能包开发流程3.1 定义技能目标以“前端组件生成”为例。团队里经常要写表单组件、弹窗组件、列表页面如果每次都用 ClaudeCode 从头生成样式、命名、注释风格可能差别很大。可以把团队规范做成技能包。技能目标可以定义为根据用户输入的组件描述生成符合项目代码规范的前端组件代码包括模板、样式、脚本和基本注释。3.2 编写 SKILL.mdSKILL.md 可以这样组织--- name: frontend-component-generator description: 根据用户描述生成符合项目规范的前端组件代码。 --- # 前端组件生成技能 当用户需要生成 Vue/React 组件时使用此技能。 ## 使用步骤 1. 读取用户输入的组件功能描述。 2. 确认组件类型表单、弹窗、列表、详情、布局。 3. 按 templates/component_template.md 中的代码结构生成。 4. 输出前检查命名是否符合规范、样式是否使用项目变量、注释是否完整。 ## 输入要求 - 组件名称 - 功能说明 - 可选接口字段、样式要求 ## 输出要求 - 组件模板代码 - 样式代码 - 脚本代码 - 使用说明 ## 注意事项 - 组件名称使用 PascalCase。 - 样式变量优先使用全局变量不写死颜色。 - 注释使用中文。SKILL.md 的质量直接影响模型执行效果。写得越清晰模型越不容易跑偏。特别是“注意事项”部分很多人会忽略实际上这是保证输出质量的关键。3.3 准备模板文件模板文件是给模型参考的不是让模型原样复制。它要展示标准答案长什么样。比如template div classcomponent-name !-- 组件内容 -- /div /template script export default { name: ComponentName, props: {}, data() { return {}; }, methods: {} }; /script style scoped .component-name { /* 使用全局样式变量 */ } /style模板文件不要写很多个一个类型一个就够。模板过多反而会让模型混淆。3.4 测试技能包开发完后用几个典型输入来测试简单场景“生成一个登录表单组件。”带接口字段场景“生成一个商品列表组件字段有商品名、价格、库存。”异常输入“生成一个弹窗。”通过多组测试你可以判断技能包是否稳定。如果同一个输入生成结果差别很大说明 SKILL.md 里的定义还不够精确。如果生成的代码不符合规范检查模板文件里的示例是否足够明确。4. 自动化配置ClaudeCode 与批量任务结合4.1 单条任务跑通后再考虑批量自动化很多时候我们将技能包写得能处理单条任务但实际场景却要求批量跑。比如对 50 个接口执行自动化测试。把 100 个图片重命名并压缩。批量生成接口文档。对一个大型项目批量检查代码规范。批量任务最需要关注的是输出命名、失败重试、日志和结果汇总。如果是单条任务失败了大不了重跑批量任务里如果有几条失败不能整个都重来。我一般会在技能包中约定每条任务有唯一 ID输出文件名带时间戳和 ID。失败任务先记录日志不中断整个流程。最终输出一个汇总报告列出成功和失败项。任务中途可以被中断重新运行时跳过已完成部分。4.2 定义批量任务的技能包结构以“批量接口自动化测试”为例技能包可以这样设计skills/ └── api-batch-testing/ ├── SKILL.md ├── scripts/ │ ├── prepare_test_cases.py │ ├── execute_tests.py │ ├── generate_report.py │ └── retry_failed.py ├── config/ │ ├── api_config.json │ └── test_cases/ │ ├── test_login.json │ ├── test_user_info.json │ └── test_order_create.json └── templates/ └── report_template.mdSKILL.md里要明确说明批量任务的处理顺序读取配置文件和测试用例目录。按顺序执行每个测试用例。每个用例执行后记录状态。全部执行完后生成汇总报告。报告里要包含请求参数、返回结果、断言结果、耗时。这里的关键点是模型在批量任务里不要自己决定“跳过某个用例”或“修改断言规则”。所有用例都必须按配置文件执行。4.3 允许所有操作模式与交互频率有部分用户希望让 ClaudeCode 减少“是否继续执行”这类确认提示。交互频率太高批量任务根本跑不下去。一种方式是调整 ClaudeCode 的权限模式让它对受控操作自动放行。不过我不建议直接开启“允许所有操作”尤其是涉及删除、覆盖、修改系统配置、执行未知脚本时。更稳妥的方式是先手动执行业务流程确认每个步骤都是安全的。确定无风险操作后再切换自动确认模式。给 ClaudeCode 指定工作目录避免它误操作项目之外的文件。保留关键操作的日志。注意开启自动确认前先确认你正在运行的任务是可重入的。如果任务执行到一半失败重新运行后不能产生脏数据、重复数据或半成品文件。4.4 接入 CI 流水线很多团队希望把 ClaudeCode 技能包接入 Jenkins 或 GitLab CI实现自动化触发。比如每次提交代码后自动运行接口测试技能包。每次发布前自动生成变更日志。每次构建成功后自动更新接口文档。接入方式不复杂本质就是把 ClaudeCode 调用命令放进流水线脚本。但要注意几个前置条件CI 机器上需要安装 ClaudeCode 及对应依赖。需要配置 API 访问权限。技能包需要部署到 CI 机器上的指定目录。CI 运行环境和本地环境的差异要先验证比如 Python 版本、Node 版本、网络策略。超时时间要足够大。ClaudeCode 执行技能包时如果是调用模型 API耗时通常比本地脚本长。给一个简化示例不是实际项目的完整配置stages: - test api-test-job: stage: test script: - claude-code --skill api-batch-testing --config ./api_config.json timeout: 30m这个说明的是思路CI 里的核心任务不是“写脚本”而是调用技能包并传入配置。技能包里已经封装好了测试逻辑CI 只负责触发。5. 关键参数与输出质量的判断标准5.1 常用参数和配置项围绕 ClaudeCode 和技能包有以下参数值得关注参数/配置作用常见取值或建议工作目录限定任务执行路径单独的项目目录不放全局模型上下文长度影响技能包能读取多少内容长文本优先但也要控制成本自动确认模式控制是否手动确认每一步先手动跑通再适当放行技能包目录告诉 ClaudeCode 去哪里找技能项目级或用户级目录超时时间防止任务卡死根据任务复杂度设置批量任务不要设太短日志级别记录执行过程调试时用详细日志正式用精简日志这些参数的边界不能只看理论。如果你的机器内存小、上下文窗口有限技能包里的模板文件就要精简不要把几十个模板同时塞进去。模型需要在有限上下文里做决策。5.2 怎么判断一个技能包是否合格判断标准不是“技能有没有被触发”而是几个更实际的指标可重复性同样输入多次运行输出差异是否在可接受范围。稳定性连续跑多条任务成功率有多高。可读性输出报告、日志是否容易理解。可维护性新增一条测试用例或组件模板是否需要重写技能包。安全性技能包会不会执行危险命令、删除无关文件。我给学员的建议是每写一个技能包至少跑 10 次典型任务统计成功率和输出质量。不要只看只跑一次就下结论。5.3 输入输出规格要显式写明很多技能包失败不是因为逻辑不对而是输入输出没有约定清楚。比如接口测试技能包输入是接口请求配置输出是测试报告。如果不写明输入文件的字段结构模型可能自己猜猜出来的结果就不可控。下面是一个输入配置的示例结构{ base_url: http://127.0.0.1:8080, auth: { type: bearer, token_from_env: TEST_TOKEN }, cases: [ { name: 登录接口正常返回, method: POST, path: /api/login, payload: { username: admin, password: 123456 }, expect: { status_code: 200, body_has: [token, user_info] } } ] }在 SKILL.md 里说明这个结构的含义模型执行时就会按字段解析而不是凭空想象。6. 自动化测试与脚本调用的坑点汇总6.1 环境差异导致的执行失败技能包里如果调用了脚本最容易遇到的就是环境问题。比如 Python 脚本在本地可以运行放到另一台机器上因为缺少第三方包而失败。要解决这个问题技能包目录里加 requirements.txt 或 package.json。在 SKILL.md 的注意事项里写明“运行前需要安装依赖”。在脚本入口处做依赖检查缺少依赖时输出明确提示。更稳妥的做法是把 Python、Node 等运行时的版本要求写进配置。不要只看“能不能跑”要看“换一台机器还能不能跑”。6.2 路径和权限问题Windows 环境下路径分隔符、中文路径、权限设置都可能引发问题。有些用户反馈安装 ClaudeCode 时出现路径相关异常这类问题在技能包脚本里也会遇到。我建议所有路径统一使用相对路径。工作目录由 ClaudeCode 启动参数指定。脚本里不依赖当前工作目录而是根据项目根目录计算路径。输出文件不要写死文件名使用时间戳或任务 ID。6.3 模型“偷懒”或过度操作技能包开发中会遇到两个方向的问题。一个是模型没按技能包执行回退到普通对话模式另一个是模型过度执行把自己猜的逻辑也加进去。前者的常见原因是 SKILL.md 里没有写明“必须使用以下步骤”模型把它当参考而不是要求。解决办法是把说明的语气改成指令式明确写“必须”“禁止”“按顺序执行”。后者的常见原因是输入描述过于开放。比如用户说“帮我把这个项目测试一下”模型不知道测试范围就会自己决定测什么。解决办法是技能包对输入有更强的约束要求用户提供明确的测试范围或配置文件。6.4 日志与失败重试批量任务中最怕的是“跑了一半不知道跑到哪了”。因此技能包在开发阶段就应该包含日志和重试逻辑。推荐的做法每个任务执行前先记录任务 ID 和开始时间。执行结束后记录成功或失败原因。全部任务结束后扫描失败列表按需重试。重试时区分“可重试错误”和“不可重试错误”。接口超时通常可以重试断言不通过重试大多没有意义。import os import json import logging import time logging.basicConfig( filenamebatch_test.log, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s ) def run_case(case): # 这里是单条测试逻辑略 result {case: case[name], status: passed} logging.info(fcase{case[name]} status{result[status]}) return result def run_batch(cases): results [] failed [] for case in cases: try: result run_case(case) results.append(result) except Exception as exc: failed.append(case) logging.error(fcase{case[name]} error{exc}) return results, failed这段代码不算复杂但它代表了一种工程习惯把每条任务的成败记录下来而不是把所有东西打印在屏幕上跑完就丢了。7. 前端开发、接口自动化、Jenkins 联动等实际场景拆解7.1 场景一ClaudeCode 辅助前端组件库维护一个前端团队如果维护一个组件库每次新增组件都要遵循颜色变量、间距规范、命名规则、注释格式。把这些写进技能包后开发者只需要说一句“新增一个表单输入组件字段有手机号和邮箱”ClaudeCode 就能按规范输出代码开发者再做少量修改即可。这里要注意的是技能包里的模板代码要定期更新。团队规范变了模板不更新生成结果就会过时。7.2 场景二接口自动化测试与 Appium 联动移动端自动化测试也可以和技能包结合。Appium 用例可以封装成技能包脚本ClaudeCode 负责解析自然语言描述、生成测试数据、执行用例、收集报告。不过移动端自动化的环境更复杂涉及模拟器、设备连接、驱动版本、页面元素定位等。技能包能控制的只是执行逻辑不能解决所有环境问题。如果启动 Appium 服务失败或者元素选择器失效日志里要能看清是哪一层出了问题。更合理的使用方式是先用技能包定义用例生成规范再由 Appium 测试框架去执行底层操作。不要指望技能包替代测试框架。7.3 场景三Jenkins 自动化部署与发布说明生成在 Jenkins 流水线里加入 ClaudeCode不是为了替代 Jenkins而是让模型在特定阶段完成“文档生成、变更摘要、质量检查”这类需要理解上下文的任务。比如项目构建完成后自动调用一个技能包读取 Git 提交记录和测试报告生成一段发布说明。这个功能对日常开发很有用因为发布说明是最容易被忽略但又很重要的内容。这里的风险点在于CI 环境里执行 ClaudeCode 需要 API 调用会带来额外耗时和成本。如果构建任务很多建议只在发布分支或人工触发时启用。7.4 场景四接入 DeepSeek 等不同模型后端有一些用户提到“ClaudeCode 接入 DeepSeek”。这是一个常见的模型后端替代思路。如果 ClaudeCode 允许配置自定义模型接口那么把模型后端换成推理成本更低的方案在部分任务里是可行的。但要注意几点不同模型对 Skills 指令的理解能力有差异在 ClaudeCode 上能稳定执行的技能包换到其他模型后可能需要调整描述措辞。技能包里的脚本和逻辑是通用的但模型解析 SKILL.md 的能力不同执行效果也会有差别。涉及自动化任务时换成低能力模型前最好先在小范围内验证稳定性。另外这类接入通常需要配置 API 地址、模型名称、密钥等参数。不同版本配置方式可能不一样建议先查看当前环境的帮助信息或官方文档再修改配置。不要直接复制网上未经验证的配置。8. 排查思路技能包不生效时从哪里开始查8.1 现象分类先判断你遇到的是哪一类问题技能包完全不被触发ClaudeCode 好像没看到它。技能包被触发但执行结果不符合预期。脚本运行报错。任务卡住没有输出也没有日志。批量任务跑到一半失败但不知道失败原因。不同现象对应不同排查方向不建议一上来就重写技能包。8.2 排查链路按以下顺序排查效率会更高先看目录结构技能包是否放在 ClaudeCode 能识别的目录下检查 SKILL.md 的格式和编码文件编码是不是 UTF-8有没有非标准字符确认技能描述是否清晰模型是否知道“什么时候用这个技能”用单条任务测试不跑批量先跑一个最简单的输入确认技能包逻辑本身没问题。看日志日志里有错误信息、还是完全没输出没输出说明可能没触发到执行分支。检查脚本依赖单独在终端里运行脚本看是否因为缺少依赖而失败。检查工作目录和输出目录是否有写权限、路径是否正确。检查参数配置自动确认模式、超时时间、上下文长度是否合理。这里最容易忽略的是编码问题。如果 SKILL.md 里包含中文但文件保存编码不是 UTF-8模型读取时可能出现乱码或识别异常。我建议所有技能包文件统一使用 UTF-8。8.3 遇到“卡住”先看资源占用和输出目录很多人在技能包执行卡住时会反复检查代码但我更建议先看机器状态内存是否占满。CPU 是否持续占用。输出目录是否已经生成了部分文件。网络请求是否一直处于等待状态。脚本是不是卡在某个交互式输入上。如果是脚本卡在交互输入可能是因为模型在脚本执行过程中等待用户确认但没人回答。解决方法是给脚本增加超时或非交互模式参数避免脚本一直等待输入。9. 技能包开发的进阶把常见工作流固化成技能9.1 从“单次指令”向“工作流”演进技能包的进阶用法是把它变成一个“工作流”。比如不只是“生成一个接口测试请求”而是“从 OpenAPI 文档到测试报告”的完整流程。中间可能包括解析 OpenAPI 文档。自动生成测试用例。执行测试。收集失败用例。重新生成报告。发送通知。这类工作流技能包的要义在于让模型扮演流程编排者的角色按预先定义的步骤调用脚本和外部资源。9.2 给技能包制定命名规范一个项目里可能有十个、二十个技能包。如果命名混乱模型可能分不清该用哪个。建议技能包名字使用短横线分隔例如api-batch-testing不要用空格。每个技能包必须有明确的 description说明适用范围。不同技能包职责要单一不要一个技能包含几十个功能。技能包之间如果需要共享脚本可以放到公共目录但要明确说明依赖关系。9.3 如何让技能包具备扩展性当技能包越来越多就要考虑通用模块拆分。比如公共的 HTTP 请求模块。公共的文件读写模块。公共的报告生成模块。公共的日志模块。这样新的技能包可以复用这些模块不用每个技能包里写一遍。不过这种拆分也意味着技能包目录更复杂对 ClaudeCode 的读取能力要求更高。建议只有在技能包数量明显增多时才做抽象。10. 开发中的风险控制与工程习惯10.1 不要一开始就追求“全自动”从自动化程度来看技能包可以做得很克制第一级模型生成内容人工确认。第二级模型执行只读操作比如读取文件、生成代码。第三级模型执行有副作用的操作比如修改文件、调用接口。第四级模型自动运行批量任务并推送结果。我建议大部分团队先停留在第一级和第二级。等技能包被验证稳定、错误可接受后再逐步放开权限。很多人一上来就追求“全自动”结果任务跑得很快但输出质量不稳定反而更难收场。10.2 日志和审计习惯技能包开发中最容易忽略的是日志。其实日志不是写给用户看的而是给你自己排查问题用的。一个技能包如果跑了 50 个任务中间有 3 个失败没有日志你根本不知道失败原因。建议记录以下信息每个任务的输入参数摘要。开始时间和结束时间。成功、失败、重试的状态。失败时的异常摘要。生成文件的位置和大小。10.3 版本管理技能包也是代码应该纳入版本管理。不要只放在本地某个文件夹里。建议技能包放到 Git 仓库中。每个技能包有独立的变更记录。修改 SKILL.md 或脚本后先在小范围测试再发布。团队成员之间同步技能包时用 Git 更新不用手动复制。10.4 安全性边界技能包可以执行脚本、修改文件因此安全问题要提前考虑。我建议不要让技能包直接读取环境变量中的敏感密钥可以通过受控方式注入。不要允许技能包在任意目录下执行删除、覆盖操作尽量限定在指定工作目录。涉及外部接口调用的技能包要确认请求目标地址是可信的。定期检查技能包脚本避免夹带恶意命令。11. 从 ClaudeCode 到 Agent 协作的扩展思考11.1 ClaudeCode 和 Codex、Opencode 的 Skills 差异最近社区里除了 ClaudeCode还经常提到 Codex、Opencode 等工具对 Skills 的支持。不同工具对“技能”的封装方式不完全一样。这里不需要详细对比数据但有一个趋势值得关注把 AI 编程助手变成“可配置、可扩展”的工作台而不是只能对话的聊天框。如果你要在多个工具之间迁移技能包建议把核心逻辑写成独立脚本SKILL.md 只是入口说明。这样即使工具变了脚本仍然可以复用。不要把业务逻辑全部写在 SKILL.md 的自然语言描述里否则迁移时还要重写。11.2 技能包和 Agent 的关系技能包本质上是在增强模型完成特定任务的能力和 Agent 配合时能发挥更大的作用。Agent 负责任务分解和决策技能包负责具体执行。比如Agent 判断当前需要做接口测试。它查找并加载api-batch-testing技能包。技能包定义测试步骤和输出格式。Agent 按技能包执行并把结果返回给用户。这是一种分工Agent 处理“怎么拆”技能包处理“怎么做”。开发技能包时要注意让 SKILL.md 被 Agent 读取后能快速形成执行计划而不是让 Agent 再去理解一个复杂的手册。11.3 从“能用”到“好用”的进阶路线如果只是想尝鲜一个简单的技能包就够用了。如果想长期使用我建议按以下路线迭代先记录项目中重复性最高的工作。为其中一项工作设计技能包。用真实项目数据测试。收集失败案例优化 SKILL.md。扩展到批量任务。接入 CI 或定时任务。建立技能包仓库和版本管理。周期性审核技能包删除不再使用的部分。很多团队在第一步就卡住了因为他们没有记录“重复性工作”的习惯。你可以先从最近一周的工作日志里找哪些事看起来简单但经常做哪些事做一遍就要 30 分钟哪些事不同人做出来的结果不一致这些就是技能包可以切入的方向。12. 最后技能包不是万能的但能把重复工作变可控回到最开始的问题为什么要在 ClaudeCode 里开发技能包因为 AI 助手只有在执行逻辑被约束、输入输出被定义、错误处理被设计好的时候才能真正参与生产流程而不只是“聊天时给出建议”。技能包把“让模型自动完成一件事”变成了可维护、可测试、可升级的工程产线。它本身没有太多魔法核心不过是把经验写成规范把规范交给模型把执行结果纳入日志和反馈循环。如果你准备开始动手我建议先选一个最痛的点比如接口自动化测试或前端组件生成。写一个最小的技能包跑通再逐步增加流程。不要一上来就规划二十个技能包先做好一个真正用起来再复制到其他场景。我也提醒一句技能的运行效果高度依赖你选择的模型能力和对技能包的精确定义。不同环境、不同项目里同样的技能包表现可能差别很大。合理的心态是把它当作一个长期迭代的工程模块而不是一次性写完就完事的脚本。