作为天天泡在 GitHub 和命令行里的人我最近明显感觉到一个趋势AI 编程助手正在从“聊天问答”向“可编排的工作流”进化。大家嘴里聊的不再是单纯的 prompt而是 Codex Skill、Claude Skill、OpenCode Skill。我翻了翻 GitHub 上的 skill 技能库也试用过不少现成的模板但真正让我觉得值得动手去定制的是我自己折腾出来的这个方向——security-audit-skill一个专门用来做代码与依赖安全审计的 AI 技能包。这个 Skill 能解决的问题非常具体让 AI 助手不再“泛泛地讲安全建议”而是按照一套固定的、可复现的流程去扫代码库结构、检查依赖版本、排查敏感信息泄露、识别常见漏洞模式最后输出一份带风险等级和修复建议的结构化审计报告。说白了就是把一个资深安全工程师日常做审计时脑袋里那套判断标准完整“外挂”给 AI。如果你正在用 Codex、Claude Code 或者 OpenCode 写代码又需要对自己项目做安全巡检或者单纯想学怎么写一个能真正落地的 Skill这篇文章应该能给你不少参考。1. 先搞清楚Skill 到底是什么为什么安全审计适合做成 Skill1.1 Skill 和 Agent 的区别别再搞混了聊 Skill 之前得先把一个概念掰扯清楚Skill 和 Agent 到底啥关系这段时间我见很多人把这两个词混着用其实它们完全不是一个层面的东西。一个相对好理解的说法是Agent 是那个“干活的人”Skill 是塞给这个人的“岗位手册 工具箱”。Agent 负责理解任务、拆解步骤、调取资源Skill 则是一套预先定义好的知识包里面写清楚了“遇到什么情况用什么方法、按什么顺序执行、输出什么格式的结果”。你可以把 Agent 想象成一个大厨Skill 就是刀工、火候、摆盘这些专项技能大厨可以同时掌握很多技能也可以先只配一个技能就上岗。更直白一点Agent 强调的是自主规划和决策Skill 强调的是专业能力和复用性。没有 Skill 的 Agent 就像一个刚毕业的新人你让它“审计一下项目安全”它能给你一套通用建议但大概率不深入、不落地、不统一给它挂上 security-audit-skill 之后它就像被一个老安全工程师附体了先查依赖、再扫密钥、然后看代码模式最后给你一张表。1.2 为什么安全审计天然适合做成 Skill那么多方向为什么我偏偏挑了安全审计来做第一个自研 Skill因为安全审计这个工种本质上是高度流程化、清单化的。一个成熟的安全审计流程无非是定义范围、收集资产信息、执行检查项、评估风险、输出报告。每个检查项背后都有明确的判断标准比如“requirements.txt 里出现了版本号低于 1.2.0 的某个库并且这个库存在已知 CVE那就应该标记高危”。这种“如果 A 且 B则标记 C”的逻辑恰恰是 Skill 最擅长承载的。相比之下像“帮我重构这个模块”这种开放型任务做成 Skill 的效果就一般因为重构方案高度依赖上下文没有固定的判断清单。而安全审计不同它的核心是一张又一张的检查表。把这些检查表做成规则文件AI 执行起来既快又准而且每次结果都稳定一致不会因为换了会话、换了时间输出的报告风格就天差地别。我建议你也花点时间想一想自己日常哪些工作是重复性、有明确判断标准的那种工作就是最值得做成 Skill 的候选对象。2. 设计 security-audit-skill核心思路要先定好2.1 先定义输入和输出边界否则 Skill 会失控我写这个 Skill 的第一件事不是急着写代码而是先定边界。一个 Skill 如果没有明确的输入输出约束AI 执行的时候就会“自由发挥”那还不如不用。我的定义是这样的输入是一个目标代码仓库路径或者一个依赖清单文件如果使用者在提问时指定了审计重点比如只审计依赖安全那 Skill 就聚焦到对应模块如果没有指定就跑全量审计。输出必须是一份结构化的 Markdown 审计报告包含审计范围、检查项列表、每个检查项的结果通过/失败/警告、风险等级、问题定位文件 行号或依赖项名称、修复建议。为什么要这么强调输出结构因为安全审计的产出是要拿去给团队整改、给领导汇报、甚至存档备查的。如果 AI 每次输出的报告格式都不一样那这个 Skill 的价值就大打折扣了。我把这个约束直接写进了 Skill 的触发指令里确保 AI 在看到“audit”相关关键词时第一时间就按这套格式走。2.2 审计工作流拆解四步走不跳步定义完边界接下来是设计工作流。我把整个安全审计拆成四个阶段强制让 AI 按顺序执行不允许跳步。第一步是依赖安全扫描。检查项目里所有依赖描述文件requirements.txt、package.json、go.mod 等提取依赖名和版本号与已知漏洞库进行匹配。第二步是敏感信息排查。扫描代码库中是否有硬编码的 API Key、数据库连接串、私钥等内容这一步用正则匹配能解决大部分问题。第三步是代码缺陷模式识别。重点看 SQL 拼接、命令执行、文件路径拼接、弱加密算法、越权判断缺失等典型问题。第四步是汇总输出。把所有发现的问题按严重程度排序生成报告。这套工作流不是我自己拍脑袋想的而是参考了很多安全团队内部审计 checklist 的通用做法。我把每一步的判断标准都写成了规则文件AI 执行的时候只需要按照规则跑就行。这么设计有个好处如果以后想调整检查逻辑只需要改规则文件不用重写整个 Skill。2.3 风险定级不能什么都报要分轻重缓急安全审计最忌讳的事情就是“狼来了”——什么问题都报高危最后团队就麻了真正严重的问题反而被淹没。所以我在 Skill 里专门设计了一套风险定级规则用四个等级严重、高危、中危、低危。严重级别对应的是直接影响系统安全、可能被直接利用的问题比如硬编码的云厂商密钥、可远程利用的反序列化漏洞高危是存在明确的利用路径但需要一定条件比如 SQL 注入、命令注入中危是依赖版本落后但暂无已知利用或者敏感信息出现在日志输出场景低危则是代码规范类问题比如使用了已弃用的加密函数但影响有限。定级是审计报告的灵魂我后面会专门讲规则文件里怎么用权重和条件来动态计算等级这里先不展开。总之做审计类 Skill一定要记住与其让 AI 事无巨细地报问题不如让它学会做减法把真正的风险挑出来。3. 实操从零写一个可落地的 security-audit-skill3.1 Skill 目录结构怎么搭阅读顺序是什么动手写的时候我强烈建议先搭一个清晰的目录结构。一个乱七八糟的 Skill自己过两周再看可能都不知道哪个文件是干嘛的。我自己的目录长这样security-audit-skill/ ├── SKILL.md ├── rules/ │ ├── dependency_risk.yaml │ ├── secret_detection.yaml │ └── code_pattern_risk.yaml ├── scripts/ │ ├── scan_dependencies.py │ ├── scan_secrets.py │ └── scan_code_patterns.py ├── templates/ │ └── audit_report_template.md └── reference/ └── cve_mini_db.json各层的职责我捋一遍SKILL.md 是入口也是 AI 最先读取的文件它定义了整个 Skill 的触发条件、元信息和执行大纲rules 目录放判断规则负责描述“什么问题算什么等级”scripts 目录放实际执行的扫描脚本负责把规则落成可运行的工具templates 目录是输出报告的模板保证格式统一reference 目录放参考数据比如一个小型的 CVE 对照表。这个分层的思路背后有一个很实际的考虑把“描述”和“执行”分离。AI 读 SKILL.md 就能知道该怎么调用脚本、怎么组织报告规则文件只负责定义判断标准脚本只负责跑数据和输出原始结果。这样每一层都只需要关注自己的事情调试的时候也能快速定位问题到底出在哪个环节。3.2 SKILL.md 怎么写AI 能不能正确理解就靠它了SKILL.md 是整个 Skill 的说明书AI 能不能正确理解你的意图就靠这个文件了。我用的是 Anthropic 社区比较主流的写法就是带 YAML frontmatter 的 Markdown里面明确写出技能的名称、描述、触发场景。这里放一个精简后的例子--- name: security-audit-skill description: 用于对代码仓库进行系统化安全审计包括依赖漏洞扫描、敏感信息检测、常见代码风险模式识别并输出分级审计报告。当用户要求审计代码安全、检查漏洞、扫描密钥或评估依赖风险时使用本技能。 --- # Security Audit Skill ## 执行流程 1. 识别审计目标确认用户提供的是本地目录路径、远程仓库地址还是依赖清单文件。 2. 调用 scripts 目录下的扫描脚本依次执行 - scan_dependencies.py 检查依赖风险 - scan_secrets.py 查找敏感信息 - scan_code_patterns.py 识别代码缺陷模式 3. 读取 rules 目录下的 YAML 规则文件对脚本输出进行风险定级。 4. 按 templates/audit_report_template.md 的格式生成报告不得随意更改章节和字段名。 ## 重要约束 - 必须先执行扫描脚本再根据脚本输出判断风险禁止凭空猜测问题。 - 若脚本执行失败必须向用户说明失败原因不得跳过该检查项。 - 报告中的风险等级必须遵循 rules 目录中的定级规则不得自行调整。 - 扫描过程中发现的密钥或敏感信息报告里只展示位置和类型禁止输出完整密钥内容。看到这个结构你可能会问为什么 AI 一定要按流程走因为语言模型的强项是理解语义弱项是严格按流程执行多条命令而不走样。SKILL.md 里的执行流程本质上就是在给模型划跑道告诉它每一步该踩哪个点跑偏了还能拉回来。如果你希望 AI “顺便”输出 JSON 版本的结果以便后续自动化处理可以在 SKILL.md 里加一行报告同时输出 Markdown 和 JSON 两种格式JSON 放在 report.json 文件中。这个小设计能让审计结果直接对接 CI/CD 流水线实测下来很实用。3.3 审计引擎脚本实践依赖扫描与漏洞匹配SKILL.md 只是骨架真正干活的是 scripts 目录下的脚本。我以最核心的依赖扫描为例讲讲怎么用 Python 实现一个轻量但有实际判断能力的扫描器。先明确思路扫描器读依赖描述文件解析出依赖名和版本号然后把版本号与 reference/cve_mini_db.json 中的漏洞库做比对比对命中后根据 CVE 的公开评分CVSS和是否可直接利用输出一条风险记录。下面是一段能直接跑的简化版核心逻辑import json import re from pathlib import Path def parse_requirements(text): deps {} for line in text.splitlines(): line line.strip() if not line or line.startswith(#): continue # 支持 requirements.txt 中 nameversion 的格式 match re.match(r([A-Za-z0-9_\-\.])\s*\s*([A-Za-z0-9_\-\.]), line) if match: deps[match.group(1).lower()] match.group(2) return deps def load_cve_db(path): with open(path, r, encodingutf-8) as f: return json.load(f) def check_dependencies(dep_file, cve_db): text Path(dep_file).read_text(encodingutf-8) deps parse_requirements(text) findings [] for name, version in deps.items(): if name in cve_db: for cve in cve_db[name]: # 简化规则若版本在漏洞影响范围内则命中 if version in cve[affected_versions]: findings.append({ dependency: f{name}{version}, cve_id: cve[id], cvss: cve[cvss], risk: 高危 if cve[cvss] 7.0 else 中危, suggestion: cve[fix] }) return findings if __name__ __main__: findings check_dependencies(requirements.txt, reference/cve_mini_db.json) print(json.dumps(findings, ensure_asciiFalse, indent2))这里我用了“精确版本命中”这种简化的匹配逻辑目的是让规则可解释、不产生太多误报。真实生产环境里依赖版本通常是区间形式比如 1.0, 2.0 且存在漏洞的版本是 1.8 以下更严谨的做法是实现一个版本区间比较器把“affected_versions”定义成区间数组然后用语义化版本库比如 packaging 库做比较。这个属于后期优化项但不影响先用起来。这里有一个很容易踩的坑很多 AI Skill 在依赖扫描这一步直接让 AI 凭“记忆”判断某个版本有没有漏洞这是非常不可靠的。大模型的训练数据有时间截断而且对少数偏门库的版本信息记忆很差。我坚持用本地 JSON 数据库做精确匹配就算数据库不全也不会给出无中生有的漏洞判断宁可漏报也不误报这是安全工具的第一原则。3.4 敏感信息扫描用正则守住最后一道线依赖扫描之后第二个核心脚本是敏感信息扫描。这个脚本的重要性不亚于依赖扫描因为硬编码密钥在实际项目里出现的频率远比你想象得高。我用 Python 实现了一个跑正则匹配的扫描器覆盖几类最常见的敏感信息AWS Access KeyAKIA 开头的 20 位大写字母数字组合、GitHub 个人访问令牌ghp_ 开头、RSA 私钥块BEGIN RSA PRIVATE KEY、以及常见的数据库连接串关键字。核心逻辑参考这段import re from pathlib import Path # 定义一个简化的敏感信息模式表 PATTERNS { aws_access_key: re.compile(rAKIA[0-9A-Z]{16}), github_token: re.compile(rghp_[A-Za-z0-9]{36}), private_key: re.compile(r-----BEGIN (RSA |EC |OPENSSH )?PRIVATE KEY-----), mysql_dsn: re.compile(rmysql://[^\s]:[^\s][^\s]), redis_dsn: re.compile(rredis://[^\s]:[^\s][^\s]), } def scan_secrets(root_dir): findings [] # 跳过常见无需审计的目录 skip_dirs {.git, node_modules, vendor, dist, build, __pycache__} for path in Path(root_dir).rglob(*): if not path.is_file(): continue if any(part in skip_dirs for part in path.parts): continue try: content path.read_text(encodingutf-8, errorsignore) except Exception: continue for name, pattern in PATTERNS.items(): for match in pattern.finditer(content): line_no content[:match.start()].count(\n) 1 findings.append({ file: str(path), line: line_no, type: name, risk: 严重 if name in (private_key, aws_access_key) else 高危 }) return findings你会注意到我把锁定关键词放在了匹配结果里自然出现的位置但报告的最终输出只会给出文件和位置不会复制密钥内容。这个细节必须做我之前和人讨论的时候发现有些公开的 skill 模板会在报告里直接贴出匹配到的密钥片段这简直是在给安全事故递刀。扫描文件的 whitelist 机制也很有用。很多项目会在测试目录里放虚拟密钥样本或者把密钥模板放在文档里做示例如果不加白名单每次审计都会产生大量误报。我的做法是在规则文件里加一个whitelist_patterns字段比如内容里包含example.com或your_前缀的匹配结果直接跳过。3.5 规则文件把“经验”和“代码”分离规则文件是整个 Skill 里我最看重的一块它把安全专家脑子里的判断经验变成 AI 可以查询、可以解释、可以修改的结构化数据。我以代码缺陷模式的规则文件为例看一下它的 YAML 长什么样patterns: - id: SQL_INJECTION name: SQL 拼接注入 description: 检测直接使用字符串拼接构造 SQL 查询的情况 severity: 高危 detection: language: python regex: execute\\s*\\(\\s*[fF]?[\].*\\{.*[\]\\s*\\) suggestion: 使用参数化查询如 cursor.execute(SELECT * FROM users WHERE id %s, (user_id,)) tags: [sql-injection, owasp-top10] - id: WEAK_HASH name: 弱哈希算法 description: 检测使用 md5 或 sha1 作为安全哈希的场景 severity: 中危 detection: language: python regex: hashlib\\.(md5|sha1)\\( suggestion: 使用 sha256 或更安全的哈希算法若用于密码存储请改用 bcrypt/argon2 tags: [crypto, weak-hash] - id: SHELL_INJECTION name: 命令注入 description: 检测将外部输入直接拼接进 shell 命令的场景 severity: 严重 detection: language: python regex: os\\.system\\s*\\(\\s*[fF]?[\].*\\{.*[\]\\s*\\) suggestion: 使用 subprocess.run 并传入参数列表避免 shellTrue tags: [command-injection, owasp-top10]这样设计之后AI 在审计时只需要三步读规则、跑正则、对结果做上下文判断。不像以前直接让 AI “检查一下有没有注入漏洞”它给出的结论经常语义化但没法直接定位问题和落地修复。我在规则里还加了一个字段叫context_hint用来告诉 AI 不要只依赖正则就下结论还要看代码上下文。比如匹配到hashlib.md5如果是在计算文件校验和这种非安全场景可以降级为低危但如果是在处理密码哈希那直接拉满高危。这种“正则定位 语义确认”的双重判断能大幅减少误报也让报告看起来是真的“读过代码”而不是在拿着关键词硬扫。3.6 报告模板让 AI 的输出稳定到像同一个人的手笔审计报告是最终交付物格式稳定特别重要。我准备了一个 Markdown 模板把每个章节、每个字段都固定下来。模板长这样# 安全审计报告 ## 审计范围 - 目标路径{target_path} - 审计时间{audit_time} - 审计版本{code_version} ## 风险统计 | 等级 | 数量 | |------|------| | 严重 | {critical_count} | | 高危 | {high_count} | | 中危 | {medium_count} | | 低危 | {low_count} | ## 问题详情 ### {cve_id} / {rule_id} - 风险等级{severity} - 问题位置{file}:{line} - 问题描述{description} - 修复建议{suggestion} ## 整改建议 - {action_item_1} - {action_item_2}模板写好后我直接把 SKILL.md 里的“按模板输出”从建议改成了强制。实测下来即使同一段代码让 AI 在不同时间审计了三次报告结构也几乎一字不差只有具体内容随代码变化而变。这种稳定性带来的安全感是用纯 prompt 方式完全没法比的。4. 安装与接入让 Codex / Claude Code / OpenCode 用上你的 Skill4.1 Codex 安装 Skill路径和加载机制要看清楚写好了 Skill接下来就是接入环节。先说 OpenCode 这个工具我很早就在用因为它核心是本地优先所有的 Skill 都放在用户目录下不需要注册任何在线服务这对很多讲究代码隐私的团队来说是一大加分项。比如我的 Skill 通常放在~/.config/opencode/skills/security-audit-skill/下面目录结构就是上面那一套。启动 OpenCode 后输入/skills就能看到当前已加载的 Skill 列表。如果没看到多半是路径没有配对或者 SKILL.md 的 frontmatter 格式有问题。Codex 的接入方式类似但它的历史包袱比较多老版本的接口路径和新版本不一样。我的经验是优先看它当前版本的文档确认 skills 目录的默认位置如果识别不到就把 SKILL.md 里的 name 字段和目录名改成完全一致通常能解决大部分加载问题。这个坑我踩过好几次后来养成了一个习惯新建 Skill 时目录名、name 字段、description 里的触发关键词三者在命名上保持统一能省去很多排查时间。4.2 Claude Code 加载 Skill文件引用和上下文注入的区别Claude Code 处理 Skill 的方式和 Codex 略微不同它更依赖“在对话中引用文件”这种机制。你可以把 SKILL.md 理解为一份可以直接路径引用的系统提示词在工程目录下用path/to/skill/SKILL.md的方式把它注入当前上下文。这个方法的好处是灵活但坏处也很明显如果你不说Claude 不会主动加载这个文件。我的习惯是把这个引用方式写进项目里的 CLAUDE.md 或者.cursorrules里等于在项目启动时默认让它加载这套审计逻辑。这样一来每次进到项目里Claude 都自带“安全审计”视角看到可疑代码时它会先按 skill 里的规则自查一遍再回答问题。有一次我在一个老项目里发现了硬编码密钥就是靠 Claude Code 在正常代码生成过程中突然给了我一个 warning原因就是我在 CLAUDE.md 里内置了“发现敏感信息立即按 security-audit-skill 规则提醒”这条指令。这种“被动触发式”检测比主动跑一次全量扫描还要好用因为它在编码阶段就拦截了风险。4.3 如何验证 Skill 是否真的生效接入完成后一定要做一次冒烟测试别信“看起来加载成功了”这种话。我先准备了一个专门的测试目录里面故意放三种问题一个旧版本的依赖比如 requests 2.20.0、一段硬编码的 fake AWS Key、一段字符串拼接的 SQL 查询。然后我分别在 Codex、Claude Code 和 OpenCode 里触发审计指令。判断 Skill 是否生效的标准非常明确AI 有没有调用脚本有没有按模板输出有没有正确识别我故意埋的三个问题如果 AI 回答得很笼统没有调用任何扫描脚本那说明 Skill 大概率没加载成功或者是 SKILL.md 里的触发条件没对上。还有一个好用的验证技巧直接问 AI “你现在加载了哪些 Skill能不能一句话概括 security-audit-skill 的执行流程”如果它能准确说出“先扫依赖、再扫密钥、再扫代码模式、最后出报告”这四步说明 SKILL.md 的核心指令已经被有效解析了。我测过很多现成模板这一步能过滤掉至少一半的“伪 Skill”。5. 常见问题与排查技巧实录5.1 Skill 没有被触发AI 完全无视规则这个问题是我被问得最多的。现象是把 SKILL.md 写得很好但 AI 就是不按要求执行输出风格和没加 Skill 一模一样。排查思路从三个方向走。第一检查 description 里的触发关键词是否覆盖了用户的自然表达。比如我写的是“审计、安全扫描、check security、vulnerability scan”但如果用户说的是“帮我看看这个项目的风险”很可能命不中。第二检查 SKILL.md 是否被正确加载到了上下文里有些工具要明确写路径才生效。第三看 SKILL.md 里是否出现了和工具默认指令冲突的内容。比如 Codex 原本就有“不要执行未经确认的代码”这条约束如果 Skill 里写“直接运行脚本不需要询问”那两条规则打架模型通常选择保守的一侧。5.2 输出报告格式不稳定同一项目两次审计结果不一样如果你发现同一段代码、同一个 Skill两次审计输出的报告结构不一样那基本可以断定问题是出在“约束不够强”。AI 是概率模型如果不把模板文件强引用进 SKILL.md它每次生成的格式都会有小差异。我的解决办法非常机械但也非常有效在 SKILL.md 里原样嵌入报告模板的核心表格结构并在模板开头加一句“严格使用以下表格格式不得修改字段名和列名”。同时把模板写成单独的文件让 AI 在生成报告前先读取这个文件。双保险之下格式问题基本消失。5.3 误报率太高大量中危低危占据报告误报太多会让人失去耐心最后干脆不用这个 Skill 了。我处理误报的思路很简单建立白名单机制和上下文降级规则。白名单主要针对测试文件。比如 tests/ 目录下如果包含假密钥直接忽略。上下文降级则是利用前面说的context_hint字段比如发现md5调用但如果周围代码里有etag、checksum这类词就自动降为低危。这些规则不是一次性写完的而是我在跑了七八个真实项目后根据每个项目里出现的“顽固误报”逐步叠加进去的。安全审计 Skill 不是一锤子买卖它像一个活的工具需要持续喂养规则。5.4 和其他 Skill 抢资源审计结果被无关输出污染还有一个在 GitHub 上被反复提及的痛点多个 Skill 同时加载时AI 有时候会在审计报告里混入其他 Skill 的输出习惯。比如我同时挂了“代码优化”和“安全审计”两个 SkillAI 可能在报告里写出“建议优化函数命名”这种和审计无关的废话。解决办法是严格控制触发粒度。SKILL.md 里的 description 要写得足够“窄”只在用户明确提到安全相关关键词时才激活。另外在 SKILL.md 的约束区写清楚“本技能只负责安全审计输出不要提供非安全相关的代码优化建议”这个提示很管用AI 会明显收敛输出范围。下面这个表是我自己项目里排查问题的速查表顺手整理给各位参考现象可能原因优先排查动作Skill 未加载目录名与 name 字段不一致统一目录名和 frontmatter 中的 name触发不命中description 关键词覆盖不足补充同义表达和英文关键词格式不稳定模板未被强制引用将模板内容嵌入 SKILL.md 并声明只读误报过多规则缺少白名单和上下文判断为规则文件增加 whitelist 和 context_hint与其他 Skill 冲突description 触角过长缩小触发范围增加负向约束脚本执行失败路径写死或依赖缺失使用相对路径并在 SKILL.md 中说明环境要求我在实际使用这几个 Skill 的过程中最大的体会就是安全审计这类“判断标准明确、输出格式固定”的任务是 Skill 的最佳试验田。它不像写业务代码那样需要强上下文理解但每个判断都需要经验和规则支撑。把团队的审计清单沉淀成 YAML 规则文件等于把资深安全工程师的经验变成团队资产新人用起来也能输出老手级别的报告。最后再分享一个小技巧给你的 Skill 加上版本号和更新日志。我在 SKILL.md 开头留了一个version: 0.3.2字段每次调整规则或增加检查项都会升一个版本号。这不只是为了好看而是当你有多个项目、多个机器在同时使用同一个 Skill 时版本号能帮你快速确认“当前机器上到底跑的是哪一版规则”。我因为这个吃过大亏在 A 机器上改了规则忘了同步结果 B 机器跑出来的报告和 A 机器完全对不上排查了半天才发现是版本不一致。吃了那次亏之后版本号就成了我所有 Skill 的标配。
