OpenCode与Agent Skills实战：开源终端AI编程助手完全指南

AI 编程助手正在从“聊天窗口里的代码建议器”进化成“真正坐在终端里干活的同事”。Claude Code 是这轮进化的标志性产品但它闭源、按量计费、模型绑定较深很多团队在尝鲜之后开始寻找替代方案。OpenCode 就是在这个窗口期内被越来越多人讨论的开源选择。它把 Claude Code 的交互体验搬进了终端同时开放了模型接入和扩展能力也让“把 AI 接入自己项目”这件事第一次变得可控。与此同时“Agent Skills”这个词的热度也快速上升。它解决的是另一个问题通用 Agent 在自己的领域内不够专业。你可以让 Agent 写代码但它不一定懂你的团队规范、项目约定和交付标准。Skill 本质上就是一套把“领域知识 操作流程 输出模板”打包成文件的能力模块装进 Agent 之后它就能在具体场景里按你的规则办事。最近甚至能看到“Agent Skills 赋能人文社科混合研究方法论文写作”这类讨论说明这套思路已经不局限于写代码。这篇文章的定位是一份从零到实战的教程。我们先用一个判断建立共识OpenCode 适合什么样的人Agent Skills 解决的核心问题是什么然后完整走一遍 OpenCode 的安装、配置、首次调用再动手创建一个可复用的 Skill最后用一个代码审查场景演示 Skill 如何改变 Agent 的输出质量。文章末尾会给出常见坑和工程建议方便你直接落到团队项目里。1. 为什么现在要关注 Agent Skills 与 OpenCode如果只看 2025 年 AI 编程工具的演进节奏会很容易得到一个结论IDE 插件时代正在被终端 Agent 时代覆盖。GitHub Copilot 把 AI 塞进了编辑器的输入框你写完一行注释它补一段代码而 Claude Code 的做法完全不同——它直接在终端里接管了一个项目的工作区能读文件、跑测试、改代码、提交 git像一个人一样把任务从头做到尾。这种“终端 Agent”形态带来的变化是结构性的。它不再是“AI 帮你补全”而是“AI 帮你执行”。但 Claude Code 本身有几个问题第一闭源你无法知道它内部到底做了什么也无法针对自己的场景修改它第二模型绑定紧密想换一个更便宜或更合适的模型并不容易第三计费策略对高频使用的团队来说成本不低尤其当上下文很长、一次任务要消耗大量 token 时。OpenCode 恰好在这几个点上给出了替代方案。它的核心是一款开源终端 AI 编程助手交互形态和 Claude Code 非常接近都采用 TUIText User Interface终端图形界面的方式在命令行里运行。更重要的是它支持接入多家模型服务商包括 Anthropic、OpenAI、OpenRouter以及本地的 Ollama。这意味着你可以根据成本、隐私和数据合规要求自由选择模型而不是被某个厂商绑死。Agent Skills 则在另一个维度上补足了通用 Agent 的短板。现在的基座模型已经足够聪明但“聪明”不等于“懂你的规矩”。你的团队可能有自己的代码规范、提交信息格式、接口文档风格你的研究团队可能有自己的方法论框架、引用格式和论证结构。如果把这些写进一个 Skill 文件Agent 在做相应任务时就会主动加载并按规范执行。这样一来AI 输出的质量就不再完全依赖“你 prompt 写得多好”而是依赖“你的 Skill 定义得多清楚”。这篇文章适合谁读我认为有三类人第一类正在评估要不要把 Claude Code 替换成开源方案的团队技术负责人第二类已经接触过 Agent 但觉得“它只会写代码不懂我们项目规范”的开发者第三类想把 AI Agent 应用于写作、研究、文档整理等非纯编码场景的同学。接下来的内容基本不需要太多前置知识但如果你会一点终端命令上手会顺很多。2. OpenCode 是什么Claude Code 的开源替代方案2.1 一个终端里的 AI 编程助手OpenCode 从定位上说是一个运行在终端里的 AI 编程代理。你用opencode命令启动它之后会进入一个交互式界面输入自然语言任务它就会自动完成拆解任务、读取文件、调用工具、生成代码、执行命令等一系列操作。整个过程对你来说是“黑盒执行、白盒过程”因为它每一步都会展示出来你可以随时叫停、修正方向。它和普通聊天式 AI 工具最大的区别在于“权限”和“工具”。聊天工具只能输出文字而 OpenCode 这样的终端 Agent 可以在你授权下直接操作文件系统、执行构建命令、运行测试、查看 git 状态。换句话说它不是一个“建议者”而是一个“执行者”。这也是为什么它在工程类任务里效率很高同时也要求你理解权限边界。从技术架构上看OpenCode 采用主流的 Agent 循环模型接收系统提示和用户任务调用工具观察工具返回的结果再决定下一步动作。工具能力决定了 Agent 能做什么模型能力决定了 Agent 想得到什么而 Skill 决定的是“用正确的方式做正确的事”。2.2 OpenCode 与 Claude Code 的对比很多文章把 OpenCode 称为“Claude Code 开源替代”这个说法基本准确但需要加一个限定它替代的是交互形态和核心场景而不是逐字节复刻。下面这张表可以帮助你快速判断对比维度Claude CodeOpenCode是否开源否是运行形态终端 TUI终端 TUI模型支持以 Anthropic 系列为主多厂商、本地模型均可接入数据与隐私依赖厂商 API可控性较弱可接本地模型适合私有化场景扩展机制支持 Agent Skills 等能力支持 Skill 类扩展模式成本控制订阅或按 token 计费模型费用由自己选择的供应商决定社区生态官方闭源扩展受限制开源社区可二次开发注意这里的“扩展机制”在不同版本上实现程度会有差异具体以你使用的 OpenCode 版本为准。但从大的方向看OpenCode 给了你“更换模型”和“自定义流程”两条自由度这是它在团队场景里越来越受关注的核心原因。2.3 开源意味着什么对个人开发者来说开源意味着你可以在自己的机器上跑通完整的 Agent 流程不用为每一次对话单独付费只需要支付模型 API 的费用如果你接入 Ollama 本地模型甚至可以完全不依赖外部服务。对团队来说开源意味着可审计。你可以审查它调了哪些工具、往哪些地址发送了哪些数据这在金融、政务、医疗等对数据敏感的场景里是刚需。项目代码在仓库里出了问题可以自己改也可以提 issue 等社区修复不会出现“厂商改版后你的流程全崩了”的被动局面。当然开源也有代价。OpenCode 的某些功能迭代非常快配置项和命令可能在不同版本间有变化社区版没有商业公司提供全流程的客服支持遇到问题更多依赖文档和 issue。我的建议是如果你在探索阶段先用它跑一个真实项目体验过一次完整流程后再决定要不要引入团队。3. Agent Skills 的核心概念3.1 什么是 Agent SkillAgent Skill智能体技能可以理解为一组“预封装的能力”。它通常由一个文件夹构成里面包含一份描述任务流程的SKILL.md文件还可以附带脚本、模板、参考文档等资源。当 Agent 接到任务时会先根据 Skill 的 name 和 description 判断要不要加载它一旦加载就会按照文件里定义的步骤执行。我用一个类比来解释模型是刚毕业的高材生能力很强但不懂你们公司的办事规矩Skill 是新员工手册。你不可能在每个任务里都把手册全文塞进 prompt但你可以告诉他“遇到客户投诉时先看投诉处理手册”。这对 Agent 也一样在 prompt 中详细写流程会占用大量上下文而 Skill 只在需要时才被加载效率高得多。3.2 Skill 与 Agent 的区别这是社区里最容易混淆的一组概念。简单说Agent 是一个“能思考、能决策、能调用工具”的自主系统它负责整体任务的拆解和执行Skill 是 Agent 可以调用的“能力模块”负责某个特定领域的具体执行方式。对比维度AgentSkill定位自主执行任务的系统可复用的能力模块核心能力规划、调用工具、自我修正按既定规则和流程完成任务可变性决策过程动态变化内容规则化稳定重复依赖关系可以调用多个 Skill不依赖 Agent可独立维护类比员工操作手册和工具包理解这个区别很重要。很多人以为“Agent 能写代码 写得好”其实写得好不好取决于它有没有调用到正确的 Skill。一个配置了代码审查 Skill 的 Agent和没配置的 Agent输出质量可能差一个量级。Skill 是给 Agent “装上行业经验”的载体。3.3 Skill 与 Prompt 的本质差异你可能会有疑问把规则写进 Skill 和写进系统 Prompt有什么区别区别至少有两点。第一加载时机不同。Prompt 在每一次对话开始时都会被完整送入模型占用的上下文是固定开销Skill 只在任务相关时被加载描述文本通常很短内部详细步骤则在调用后逐层读取这种设计叫“渐进式披露”能大幅节省上下文。第二可维护性不同。Prompt 是一大段文本你很难在多个项目之间复用和版本管理Skill 是文件结构可以放进 git可以跟随项目分发可以写脚本来自动测试。从工程角度理解Prompt 是“临时配置”Skill 是“可交付资产”。如果你的团队已经积累了一套代码规范把它做成 Skill比做成长篇 prompt 要科学得多。4. 环境准备与 OpenCode 安装4.1 安装前的准备在安装 OpenCode 之前请确认你的环境满足以下条件操作系统Windows 10/11、macOS 或主流 Linux 发行版均可。Windows 下建议优先使用 PowerShell 或 Windows Terminal。Node.js如果你选择 npm 安装需要安装 Node.js 18 及以上版本。这是目前最常见的安装路径。网络环境安装时需要能够访问 npm 镜像或 GitHub Releases。国内网络环境下建议提前配置 npm 镜像源或使用代理这里指常规网络代理请遵守所在地区的法律法规。API Key你需要至少一个可用的模型 API Key比如 Anthropic 或 OpenAI 的如果暂时没有也可以安装 Ollama 后用本地模型体验。如果你不想装 Node.js可以考虑二进制安装或包管理器安装。命令细节请以 OpenCode 官方文档为准因为不同版本在持续迭代下面的命令是当前社区常用的方式。4.2 三种安装方式# 方式一npm 全局安装最常用 npm i -g opencode-ai # 方式二macOS 使用 Homebrew brew install sst/tap/opencode # 方式三官方安装脚本Linux / macOS / WSL curl -fsSL https://opencode.ai/install | bash选择建议如果你用 Windows优先使用 npm 方式装完直接获得opencode命令如果你用 macOSHomebrew 方式更干净如果你在服务器或者 Docker 环境里官方脚本最方便。安装结束后可以执行以下命令确认版本号opencode --version如果正常输出版本号说明安装成功。如果提示找不到命令请继续看 4.4 节。4.3 验证安装是否成功除了opencode --version还可以用opencode --help查看可用的子命令和参数。这个命令会列出当前版本支持的功能比如启动交互式会话、执行单次任务、查看配置等。不同版本的功能差异较大所以养成看--help的习惯比背命令更可靠。4.4 Windows 下“无法识别 opencode”的解决办法用 npm 安装后Windows 用户经常会遇到下面这个报错opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这不是 OpenCode 本身的问题而是 npm 全局安装目录不在系统的 PATH 环境变量里。npm 默认把全局命令安装到C:\Users\你的用户名\AppData\Roaming\npm如果这个路径没有加入 PATHPowerShell 就找不到它。解决办法分两步。第一步确认 npm 全局目录npm config get prefix第二步把上面的路径加入用户 PATH 环境变量# 将下面命令中的路径替换为 npm config get prefix 的结果 [Environment]::SetEnvironmentVariable( Path, $env:Path;C:\Users\你的用户名\AppData\Roaming\npm, User )执行完后重新打开一个终端窗口再执行opencode --version验证。如果你用的是其他包管理器安装也可以按同样的思路检查对应 bin 目录是否在 PATH 中。5. OpenCode 基础配置与首次调用5.1 选择模型供应商OpenCode 支持多家模型供应商这是它相比 Claude Code 的核心优势之一。常见选择有Anthropic Claude代码能力最强但价格较高适合对质量要求高的场景。OpenAI GPT 系列生态成熟推理能力不错很多团队比较熟悉。OpenRouter一个聚合平台可以在一个 Key 下访问多个模型适合做对比实验。Ollama 本地模型完全离线隐私最好但模型能力相对有限适合日常体验和敏感数据场景。选择时可以从三个维度考虑任务复杂度、数据敏感度、预算。如果只是做个人项目和日常脚本本地模型就能跑通如果是团队正式工程建议选择能力更强的商用模型。5.2 配置 API KeyOpenCode 通过环境变量读取 API Key。以 Anthropic 为例# Linux / macOS export ANTHROPIC_API_KEYsk-ant-你的key # Windows PowerShell $env:ANTHROPIC_API_KEYsk-ant-你的key如果使用 OpenAI则设置OPENAI_API_KEY。为了避免每次开终端都重新设置可以把它写入 shell 配置文件.bashrc、.zshrc或系统环境变量。更规范的做法是使用opencode.json配置文件来管理模型参数。下面是一个典型示例{ $schema: https://opencode.ai/config.json, provider: { default: anthropic, anthropic: { model: claude-sonnet-4-5 } } }注意模型名称和配置字段会随版本更新实际使用前建议查看当前版本的官方配置说明或者直接通过/config命令在 TUI 里修改。5.3 启动 OpenCode 第一次对话在项目目录下启动cd /path/to/your/project opencode进入交互界面后你会看到类似聊天的输入框。直接在输入框里输入任务比如请查看当前项目的 README.md并告诉我这个项目的核心功能。OpenCode 会先读取文件再给出回答。它执行的每步操作都会显示在界面上你可以观察它读取了哪些文件、运行了哪些命令这也是终端 Agent 和纯聊天工具体验上最不同的地方。如果你不想进入交互式界面有些版本支持一次性的运行模式opencode run 请总结当前项目的目录结构具体子命令名称以opencode --help输出为准。跑通第一次对话后你可以继续尝试让它修改代码、运行测试、提交 git先感受一下 Agent 的工作方式再进入下一步。6. 从零创建一个 Agent Skill6.1 Skill 的文件结构我们以社区广泛使用的 SKILL.md 格式为例。一个 Skill 本质上是一个目录里面必须有一个SKILL.md其他文件都是可选的辅助资产。典型的目录结构如下skills/ └── code-review/ ├── SKILL.md └── review_helper.py放在哪个位置取决于你的项目约定。比较通用的做法是在项目根目录下建立skills/目录或者放在团队统一维护的技能仓库里。在 OpenCode 中Skill 的加载路径与具体版本有关你可以查看官方文档确认也可以直接把 Skill 目录和项目放在一起通过对话要求 Agent 加载它。6.2 编写 SKILL.mdSKILL.md是 Skill 的核心。它由两部分组成YAML 格式的 frontmatter 和 Markdown 格式的正文。frontmatter 里的name和description是给 Agent 看的“索引信息”Agent 会通过 description 判断当前任务是否需要加载这个 Skill。--- name: code-review description: 对代码进行系统化审查重点检查安全性、性能和可维护性。当用户要求“审查代码”“检查代码质量”“code review”时使用本技能。 --- # 代码审查技能 执行代码审查时严格遵循以下流程 1. 先读取目标文件确定代码语言和功能范围。 2. 按三个维度逐项检查 - 安全是否存在注入、硬编码密钥、危险函数调用。 - 性能是否存在不必要的循环、N1 查询、大对象重复创建。 - 可维护性命名是否清晰、函数是否过长、是否有重复代码。 3. 对每个问题给出严重级别 - P0必须修复可能引发安全事故或严重故障。 - P1建议修复影响质量或后续维护。 - P2可选优化改善体验但不阻塞交付。 4. 输出结构化报告包含问题清单、所在文件与行号、修改建议。这里的核心技巧是“把规则写具体”。不要写“请认真审查代码”这种空话而要写清楚检查维度、判断标准、输出格式。Agent 对规则性文本的执行能力很强只要你定义了它就会严格照做。6.3 加入辅助脚本有些 Skill 不能只靠文字规则还需要脚本做静态扫描、解析文件、生成报告。我们给 code-review 技能加一个 Python 辅助脚本用来扫描 Python 文件中的常见问题。# 文件路径skills/code-review/review_helper.py 代码审查辅助脚本对 Python 文件做基础静态扫描。 import ast import sys from pathlib import Path def analyze_python_file(filepath: str) - list: 对 Python 文件做基础静态扫描返回问题列表。 每个问题是一个元组(行号, 严重级别, 问题描述) issues [] tree ast.parse(Path(filepath).read_text(encodingutf-8)) for node in ast.walk(tree): # 检测疑似硬编码密钥 if isinstance(node, ast.Assign): for target in node.targets: if isinstance(target, ast.Name) and key in target.id.lower(): issues.append((node.lineno, P1, f疑似硬编码密钥: {target.id})) # 检测危险函数调用 if isinstance(node, ast.Call) and isinstance(node.func, ast.Name): if node.func.id in (eval, exec): issues.append((node.lineno, P0, f禁止使用 {node.func.id}() 函数)) # 检测不必要的列表转集合 if isinstance(node, ast.Call) and isinstance(node.func, ast.Name): if node.func.id list and isinstance(node.args[0], ast.Set) if node.args else False: issues.append((node.lineno, P2, 列表转集合再转列表可考虑直接使用集合)) return issues if __name__ __main__: if len(sys.argv) 2: print(用法: python review_helper.py 文件路径 [更多文件路径]) sys.exit(1) for file in sys.argv[1:]: try: for lineno, level, msg in analyze_python_file(file): print(f{file}:{lineno} [{level}] {msg}) except SyntaxError as e: print(f{file}: 语法错误 - {e}) except FileNotFoundError: print(f{file}: 文件不存在)这段脚本做了三件事遍历 Python 抽象语法树、检测硬编码密钥和危险函数调用、按“文件路径:行号 [级别] 描述”的格式输出。它的目的是给 Agent 提供“可执行的检查工具”让审查结果不只靠模型推理还能落在真实的静态分析上。脚本本身可以随着团队需求持续扩展例如加入复杂度计算、依赖安全检查等。7. 项目实战让 Agent 用 Skill 做代码审查7.1 准备一个待审查项目我们创建一个最小测试项目包含一个存在明显问题的 Python 文件# 文件路径src/app.py import subprocess API_KEY sk-1234567890abcdef def run_cmd(user_input): 直接在当前 shell 中执行用户输入的命令。 result subprocess.run(user_input, shellTrue, capture_outputTrue) return result.stdout def main(): cmd input(请输入命令: ) print(run_cmd(cmd)) if __name__ __main__: main()这个文件有三个典型问题硬编码 API Key、使用shellTrue执行外部命令、存在命令注入风险。它很适合用来验证 Skill 是否真的被 Agent 采用。7.2 触发 Skill 并观察执行流程确保skills/code-review/目录已放在项目合适位置后在项目根目录启动 OpenCodecd /path/to/demo-project opencode在输入框中输入请使用 code-review 技能审查 src/app.py如果 Skill 配置正确你会看到 Agent 先是判断任务与 code-review 匹配然后加载SKILL.md中的检查流程再调用review_helper.py执行静态扫描最后结合模型的分析生成结构化报告。预期输出大致如下src/app.py:4 [P1] 疑似硬编码密钥: API_KEY src/app.py:7 [P0] 使用 shellTrue 执行外部命令存在命令注入风险 src/app.py:7 [P0] 将未过滤的用户输入直接拼接到 shell 命令中对比不启用 Skill 时的输出你会明显感受到差异普通对话可能只会笼统地说“代码有些问题建议注意安全”而带 Skill 的 Agent 会给出行号、级别和具体修改建议而且可以反复在同一个项目里保持一致的标准。这正是 Skill 最大的价值把一次性的“AI 建议”变成可重复执行的“团队规范”。7.3 从代码审查扩展到更多场景代码审查只是 Agent Skills 的一个应用场景。理解了这套“skill 即文件结构”的模式后可以扩展的方向很多提交信息规范化Skill 中定义 commit message 的格式和字段Agent 提交代码前自动生成符合规范的提交信息。接口文档生成Skill 中定义你团队的接口文档模板Agent 扫描代码后按模板输出。日志规范检查Skill 要求所有异常必须包含上下文、traceId 和错误码Agent 在写日志代码时自动符合规范。研究论文写作正如社区讨论的“Agent Skills 赋能人文社科混合研究方法论文写作”Skill 里可以定义研究方法论框架、引用格式、文献综述结构Agent 按这套规则辅助写作和润色。这些场景的共同点都是领域知识稳定、规则明确、输出格式固定。只要满足这三个特征就值得封装成一个 Skill。8. 常见问题与排查思路问题现象可能原因排查方式解决方案执行opencode提示无法识别npm 全局目录不在系统 PATH 中执行npm config get prefix检查路径将全局目录加入 PATH 并重启终端启动后 API 报错如 401API Key 未设置或 Key 无效检查环境变量是否已导出重新设置ANTHROPIC_API_KEY或OPENAI_API_KEY模型返回结果质量差模型选择不当或参数配置错误查看opencode.json中的模型配置切换到更强模型或调整参数Agent 没有加载 SkillSKILL.md的 description 不够清晰检查 Skill 目录是否被识别优化 description加入触发关键词辅助脚本执行报错Python 脚本依赖或语法问题手动执行脚本验证修复脚本后重新触发响应速度很慢上下文过长或模型推理开销大检查会话上下文长度新开会话或清理无关文件工具调用权限不足未授权 Agent 执行特定命令查看界面权限提示按需授权遵循最小权限原则出现任何问题时最直接的排查方式是先看错误信息本身。OpenCode 在执行每个工具调用时都会输出结果报错往往就发生在某个具体操作里不要急着怀疑“模型不行”先定位是哪一步挂了。9. 最佳实践与工程建议9.1 Skill 的命名与描述规范name要短而准确最好使用kebab-case如code-review、commit-message-gen。description是 Agent 判断是否加载 Skill 的关键一定要包含“什么时候用”和“触发关键词”。一个好的 description 应该是“为了什么场景、当用户要求什么时、使用本技能解决什么问题”而不是一句空泛的功能介绍。9.2 把 Skill 纳入版本控制Skill 是团队资产不是个人笔记。建议在项目仓库中建立skills/目录随代码一起提交。这样新成员 clone 项目后Agent 环境开箱即用代码评审时也能 review Skill 的规则变更。如果 Skill 跨项目复用可以单独建一个技能仓库通过脚本或 submodule 同步到各项目。9.3 上下文管理只暴露必要信息给 Agent 授权读取文件时要遵循“最小化”原则。Skill 里不要写“读取整个项目”这种指令而应该精确到目标文件或目录。上下文越长模型越容易在无关信息上“走神”处理速度也会变慢。合理的 Skill 操作方式是先看目录结构再读取目标文件最后执行检查。9.4 权限与安全边界OpenCode 这样的终端 Agent 拥有执行命令的能力这既是效率来源也是风险来源。在正式环境中建议遵循以下原则不要让 Agent 在未确认的情况下执行破坏性命令如删除文件、清空数据库。生产环境的变更必须在测试环境完整验证后进行。API Key 永远不要写进代码或 Skill 文件通过环境变量或密钥管理服务注入。定期检查 Agent 的权限配置确保它只能访问它需要的目录和工具。9.5 用测试驱动 Skill 迭代Skill 本质上是“可执行规范”所以它也应该能被测试。比如给 code-review Skill 创建一个包含已知问题的测试文件运行后检查输出是否包含预期的问题级别和行号。这样每次修改 Skill 规则后都能快速验证规则有没有被破坏。这个思路在大型团队里尤其重要因为 Skill 会随业务规则持续演化不能只靠“感觉”。9.6 团队协作中的版本兼容OpenCode 迭代速度很快Skill 的格式也可能在版本升级后变化。建议在项目里记录当前使用的 OpenCode 版本和模型名称升级前先在小范围试运行确认 Skill 行为没变化之后再推给全团队。这类“先灰度、再全量”的节奏和传统软件发布如出一辙。10. 总结与后续学习方向这篇文章从趋势讲到落地核心想传递三件事。第一OpenCode 是当前最值得关注的 Claude Code 开源替代方案之一它的价值不只是“免费”而是模型可切换、流程可自定义、代码可审计这几个特性对团队工程化非常关键。第二Agent Skills 是把 AI 从“通用助手”变成“领域专家”的关键机制它的本质是把稳定规则从 prompt 中解放出来变成可版本化、可复用、可测试的文件资产。第三安装、配置、创建 Skill、项目实战这套完整流程并不复杂读完这篇文章你已经具备把它们接入真实项目的基本能力。下一步的实践建议很具体先找一个你团队里“规则明确、重复度高”的任务比如代码审查、提交信息生成、接口文档整理把它写成第一个 Skill再在一个小项目里用 OpenCode 跑通对比一下启用 Skill 前后的输出质量确认有效后再逐步扩大覆盖范围。需要提醒的是OpenCode 和 Agent Skills 这两件事都还处于高速演进阶段命令、配置和 Skill 格式在不同版本之间可能有变化。遇到与文章描述不一致的地方优先查看你当前版本的--help输出和官方文档。工具会变但“把领域规则封装成资产”这个思路不会过时它才是这篇文章真正值得你收藏的部分。