企业官网建设流程全解析

1. 先搞清楚 skill 到底是个什么东西

最近几个月，AI 编程圈子里 "skill" 这个词出现的频率越来越高，几乎到了绕不开的地步。不管是 Codex、Claude 这类闭源助手，还是 opencode 这类开源方案，都在往 skill 的方向上靠。我最早看到这个说法的时候也是一头雾水——这玩意儿跟普通的 prompt 有什么区别？跟 agent 又是什么关系？直到自己动手写了一个用于安全审计的 skill，才把这块彻底理顺。

简单来说，skill 就是一套结构化的、可复用的"能力包"。它不是一句提示词，而是一个文件夹，里面有说明文档、脚本、参考资源，甚至还可能带上校验规则和数据样例。当你给 AI 助手挂上某个 skill，它就知道"在这个场景下，我应该按照什么样的流程、调用哪些工具、参考哪些标准来做事情"。

拿我做的 security-audit-skill 举例。这个 skill 的核心目标很简单：让 AI 助手在做代码安全审计的时候，不再是走一步看一步地"随机发挥"，而是按一套固定的方法论来执行——先盘点资产，再检查配置，然后逐层扫描代码，最后生成审计报告。这套流程全部固化在 skill 里，你把这个文件夹往任何支持 skill 的 Agent 环境里一放，AI 就能立刻获得"安全审计"这个专项能力。

为什么要用 skill 而不是直接把流程写进 prompt？我实测下来的感受是，prompt 一长，AI 就明显"记不住重点"，尤其是面对多文件代码库的时候，经常审着审着就跑偏了。skill 把方法论、检查项、工具脚本拆成了独立模块，AI 可以按需加载，既不占用宝贵的上下文窗口，又能保证每一步都有章可循。换句话说，prompt 是给 AI 的"口头指令"，skill 是给 AI 的"岗位手册加工具箱"。

2. 为什么偏偏要做一个安全审计方向的 skill

安全审计这件事，看起来简单，做起来极其讲究方法论。普通的代码评审关注的是"这个功能实现得对不对"，安全审计关注的是"这个系统有没有可能被攻破"。两者的思维模式完全不同。

我先说清楚什么叫安全审计。它不是拿扫描器哗啦跑一遍就完事，而是需要审计者具备一套完整的分析框架：入口在哪里，信任边界在哪里，数据怎么流转，哪些地方可能被注入，哪些接口缺少鉴权，密钥有没有硬编码在代码里，依赖库里有没有已知漏洞。这些检查项，不同的审计者对同一个代码库，得出的结论可能天差地别——因为安全审计极度依赖经验和检查的全面性。

这就引出了为什么要用 skill 来承载这件事：

第一，安全审计是一个"流程固化价值极高"的场景。有经验的安全工程师心里都有一套 SOP，但每个人的 SOP 都不一样。把一套相对完整的审计流程固化成 skill，意味着哪怕团队里没有资深安全专家，拿这套 skill 去跑，也能达到一个"合格线"以上的审计水平。这跟资深工程师把代码审查清单写成规范文档是一个逻辑，只不过 skill 不只是文档，它还能驱动 AI 实际执行。

第二，安全审计涉及大量"资格判断"动作。比如"这段代码是否使用了不安全的反序列化函数""这个接口是否有越权风险""这个正则是否可能导致 ReDoS"——这些问题 AI 其实都能答，但无序地去问，AI 给出的答案往往是碎片化的。有了 skill，AI 会被引导着按优先级逐项核查，而不是东一榔头西一棒子。

第三，也是我私心最重的一点：安全审计是检验 skill 设计能力的绝佳试验田。它既需要静态分析（读代码找问题），又需要动态分析（看配置、看依赖、看运行时行为），还涉及大量的"知识检索"动作（查询 CVE、查询 OWASP 清单等）。一个 skill 能否把这些不同类型的动作优雅地编排起来，是对 skill 设计水平的真实检验。

所以我在设计这个 security-audit-skill 的时候，目标定得很明确：让一个普通的 AI 编码助手，在挂载这个 skill 之后，具备接近初级安全工程师的代码审计能力——而不是简单地"帮你看一眼代码有没有问题"。

3. security-audit-skill 的整体设计与结构拆解

3.1 目录结构与文件规划

我设计的 skill 目录结构如下，这也是目前主流的 skill 组织方式，兼容 Codex、Claude、opencode 等大多数支持 skill 的环境：

security-audit-skill/ ├── SKILL.md # 技能入口文件，定义触发条件和核心流程 ├── scripts/ │ ├── scan_deps.py # 依赖漏洞扫描脚本 │ ├── detect_secrets.py # 硬编码密钥检测脚本 │ └── audit_summary.py # 汇总生成审计报告 ├── resources/ │ ├── owasp_top10.md # OWASP Top 10 本地缓存版 │ ├── cwe_guide.md # 常见 CWE 条目速查 │ └── checklist.md # 审计检查项清单 ├── rules/ │ └── config_rules.yaml # 配置文件安全基线规则 └── examples/ ├── vulnerable_python.py # 故意构造的漏洞示例 └── audit_report_example.md

每个文件的职责都很清晰：SKILL.md是入口，决定了"什么时候触发、按什么顺序做、每个阶段做什么"；scripts目录放的是可以实际执行的工具；resources目录是 AI 可以参考的知识库；rules目录定义了配置类检查的标准；examples目录则用于给 AI 提供一个"长什么样算审计合格"的参照。

3.2 SKILL.md 的编写要点：这是整个 skill 的灵魂

SKILL.md是 skill 的行为纲领，AI 通过读取这个文件来决定怎么执行。我写的核心内容大致是这样：

--- name: security-audit description: 对项目代码进行系统性的安全审计，覆盖依赖漏洞、密钥泄露、注入风险、配置缺陷等常见安全问题，输出结构化审计报告。 triggers: - 安全审计 - security audit - 代码安全检查 - 帮我审一下安全 --- # Security Audit Skill ## 执行原则 1. 分阶段执行，每个阶段完成后再进入下一阶段。 2. 任何发现的问题都必须记录，包括"疑似"问题。 3. 最后输出统一的审计报告，不允许边审边给结论。 ## 阶段流程 1. 资产盘点：识别项目语言、框架、入口文件、依赖清单、配置文件。 2. 依赖审计：检查依赖版本，关联 CVE 数据库。 3. 密钥扫描：搜索硬编码密钥、Token、密码等高危泄露。 4. 代码审计：按 OWASP Top 10 逐项检查源代码。 5. 配置审计：检查部署配置、权限配置、安全头配置。 6. 报告生成：汇总所有发现，按严重级别排序输出。

这里有个很重要的设计细节：我把"执行原则"写在最前面，并且明确写了"分阶段执行"和"不允许边审边给结论"。为什么？因为 AI 有一个通病——你让它审计代码，它看到第一个问题时就会停下来长篇大论。这个写法能强制 AI 先把全貌摸完，最后再集中输出结论。这条经验我在多次调试中验证过，非常有效。

3.3 为什么要把知识库放进 skill 而不是让 AI 现场搜

resources目录里放 OWASP Top 10 和 CWE 速查表，很多人会觉得没必要——AI 不都 "知道" 这些吗？实测下来真不是这样。AI 对 OWASP 的理解停留在"听说过"级别，真让它逐项对照检查的时候，常常把 "A01:2021-Broken Access Control" 和 "A05:2021-Security Misconfiguration" 搞混。

我把精简版的 OWASP Top 10 检查要点写成了本地 markdown，每条类目包含：风险描述、常见触发代码模式、可用的修复建议。这样 AI 在审计时不需要靠"背"来工作，而是边查边比——这跟人类安全工程师桌边放一本 OWASP 手册是一个道理。

知识库的本地化还有一个实际好处：AI 的上下文窗口是有限的。如果把 OWASP 的完整内容塞进对话上下文，还没开始审计，上下文就用掉了一大截。放在resources目录里，AI 可以按需读取，用到哪一条查哪一条，效率高得多。

4. 核心审计逻辑与脚本实现详解

4.1 依赖漏洞扫描：不能只靠 AI 的"印象"

先说scan_deps.py。依赖审计这件事，AI 凭记忆来做是完全不可靠的——它可能知道某个版本有 CVE，但那个 CVE 列表是训练数据截止时间之前的，新的漏洞它一概不知。所以这一步必须用真实数据源。

我的方案是：脚本读取项目的依赖清单文件（requirements.txt、package.json、pom.xml 等），然后调用 OSV API 查询漏洞信息。OSV 是 Google 维护的开源漏洞数据库，支持通过 API 批量查询多个包，而且完全免费。

#!/usr/bin/env python3 """依赖漏洞扫描脚本 - 读取依赖清单并查询OSV数据库""" import json import subprocess import sys import urllib.request from pathlib import Path def parse_dependencies(file_path): """根据文件类型解析依赖清单""" file_path = Path(file_path) deps = [] if file_path.name == "requirements.txt": for line in file_path.read_text().splitlines(): line = line.strip() if line and not line.startswith("#") and "==" in line: pkg, version = line.split("==", 1) deps.append({"name": pkg.strip(), "version": version.strip()}) elif file_path.name == "package.json": data = json.loads(file_path.read_text()) for key in ("dependencies", "devDependencies"): for pkg, ver in data.get(key, {}).items(): deps.append({"name": pkg, "version": ver.lstrip("^~")}) return deps def query_osv(name, version): """调用OSV API查询单个依赖的漏洞""" url = "https://api.osv.dev/v1/query" payload = json.dumps({ "package": {"name": name, "ecosystem": "PyPI"}, "version": version }).encode() req = urllib.request.Request(url, data=payload, headers={"Content-Type": "application/json"}) try: with urllib.request.urlopen(req, timeout=10) as resp: return json.loads(resp.read().decode()) except Exception: return {} def main(): dep_file = sys.argv[1] deps = parse_dependencies(dep_file) findings = [] for dep in deps: result = query_osv(dep["name"], dep["version"]) if result.get("vulns"): for vuln in result["vulns"]: findings.append({ "package": dep["name"], "version": dep["version"], "vuln_id": vuln["id"], "summary": vuln.get("summary", ""), "severity": _extract_severity(vuln) }) print(json.dumps(findings, ensure_ascii=False, indent=2)) def _extract_severity(vuln): """从OSV返回中提取严重级别""" for ref in vuln.get("severity", []): if "score" in ref: return ref["score"] return "unknown" if __name__ == "__main__": main()

这里需要说明几个设计选择。第一，我用==来匹配 requirements.txt 中的精确版本，因为 OSV 查询需要精确版本号，模糊版本范围（比如>=、~=）没法直接查。第二，查询失败时静默跳过而不是报错，保证扫描流程不会因为单个包的网络问题而中断。第三，输出格式用 JSON，方便 AI 后续做汇总分析。

4.2 硬编码密钥检测：正则是功能，上下文判断才是审计

detect_secrets.py的实现思路是"正则匹配 + 上下文加权"。硬编码密钥这东西，单纯用正则扫描会产生大量误报——比如代码里有个变量叫password，但它指向的是环境变量名，压根没有泄露。

#!/usr/bin/env python3 """硬编码密钥检测脚本""" import json import re import sys from pathlib import Path # 各类密钥的高置信度正则 SECRET_PATTERNS = { "AWS Access Key": r"AKIA[0-9A-Z]{16}", "GitHub Token": r"gh[pousr]_[0-9A-Za-z]{36,255}", "Slack Token": r"xox[baprs]-[0-9A-Za-z-]{10,}", "Private Key": r"-----BEGIN (RSA|EC|OPENSSH) PRIVATE KEY-----", "Generic API Key": r"(?i)(api[_-]?key|secret|token|password)\s*[:=]\s*['\"][0-9a-zA-Z\-_]{16,}['\"]" } # 需要排除的常见模式（例如仅指向环境变量的情况） LOW_RISK_CONTEXTS = [ r"os\.environ", r"process\.env\.", r"getenv\(", r"env\[", r"config\.get\(", ] IGNORE_PATHS = {"node_modules", "venv", ".git", "__pycache__", "dist", "build"} def scan_file(file_path): """扫描单个文件中的密钥模式""" findings = [] try: content = Path(file_path).read_text(encoding="utf-8", errors="ignore") except Exception: return findings for i, line in enumerate(content.splitlines(), 1): for secret_type, pattern in SECRET_PATTERNS.items(): matches = re.finditer(pattern, line) for match in matches: # 检查是否属于低风险上下文 if any(re.search(ctx, line, re.IGNORECASE) for ctx in LOW_RISK_CONTEXTS): continue findings.append({ "file": str(file_path), "line": i, "secret_type": secret_type, "match": match.group(), "context": line.strip()[:100] }) return findings def main(): root_dir = sys.argv[1] if len(sys.argv) > 1 else "." root = Path(root_dir) all_findings = [] for file_path in root.rglob("*"): if file_path.is_file() and not any(part in IGNORE_PATHS for part in file_path.parts): # 仅扫描文本类文件 if file_path.suffix in {".py", ".js", ".ts", ".java", ".go", ".rb", ".php", ".yaml", ".yml", ".json", ".toml", ".ini", ".env", ".sh", ".bash", ".conf", ".cfg", ".properties"}: all_findings.extend(scan_file(file_path)) print(json.dumps(all_findings, ensure_ascii=False, indent=2)) if __name__ == "__main__": main()

这个脚本的精华在于LOW_RISK_CONTEXTS这个排除列表。如果没有它，扫描结果里会塞满os.environ["SECRET_KEY"]这种其实并不算泄露的代码，然后 AI 就会开始"狼来了"——把所有发现都当成误报，或者把所有发现都当成真实漏洞。有了这个上下文判断，扫描结果的精确度提升非常明显。

当然，这段脚本还有改进空间，比如使用entropy检测来识别随机生成的令牌、对历史 commit 中的密钥进行扫描等。但作为 skill 里内置的工具，它的定位是"快速筛一遍，把明显的问题找出来"，深度检测可以靠后一步的 AI 代码审计来完成。

4.3 审计检查项清单：把 OWASP Top 10 落地成可以勾选的条目

checklist.md是我花时间最多的地方。OWASP 官方文档写得很抽象，比如 "Broken Access Control" 下面列了十几条要点，AI 读完之后还是不知道"那我到底该看代码里的什么？"我需要把每个风险类别翻译成"审计员视角的可执行动作"。

节选我的清单内容：

# 安全审计检查项清单 ## A01:2021 - Broken Access Control（访问控制缺陷） - [ ] 所有涉及数据读取的接口是否校验了资源归属权限？ - [ ] 是否存在未授权访问的管理员接口？ - [ ] 是否使用了不安全的对象引用（如直接使用数据库ID做参数）？ - [ ] 是否存在缺少鉴权中间件的路由？ ## A03:2021 - Injection（注入） - [ ] SQL 语句是否使用了预编译/参数化查询？ - [ ] 是否存在字符串拼接 SQL 的情况？ - [ ] 命令行执行是否拼接了用户输入？ - [ ] 模板引擎是否开启了自动转义？ ## A05:2021 - Security Misconfiguration（安全配置错误） - [ ] 是否启用了默认账号/默认密码？ - [ ] 敏感接口是否缺少限流？ - [ ] 是否缺失安全响应头（CSP、HSTS、X-Frame-Options）？ ## A06:2021 - Vulnerable and Outdated Components（漏洞组件） - [ ] 依赖是否已锁定精确版本？ - [ ] 是否使用了已停止维护的框架版本？ - [ ] 前端资源（JS库、字体）是否用了不安全的 CDN 来源？ ## A07:2021 - Identification and Authentication Failures（身份认证失效） - [ ] 密码策略是否合理（长度/复杂度）？ - [ ] 登录接口是否缺少防暴力破解机制？ - [ ] Session 过期时间是否过长？ - [ ] Token 是否包含敏感信息？

看到区别了吗？OWASP 原文是"什么风险"，我的清单是"看哪行代码/哪个配置"。AI 在执行代码审计时，本质上就是在做"模式匹配"—把代码的特征和清单里的检查项一一对上。清单写得越具体、越偏向代码层面，AI 的执行越靠谱。

4.4 配置审计规则：YAML 定义的就是"基线"

config_rules.yaml定义的是配置类检查的基线。安全配置检查的特性和代码审计不一样——它不太需要 AI 的"理解能力"，更多是"比对"：配置的值和安全的预期值是否一致。

rules: - id: "config-session-cookie-secure" description: "会话Cookie必须设置Secure属性" target_files: - "*.py" - "*.js" - "*.ts" pattern: "cookie" check: "secure" expected_value: true severity: "high" - id: "config-cors-origin" description: "CORS配置不允许使用通配符+凭据的组合" target_files: - "*.py" - "*.js" - "*.go" pattern: "cors" check: "allow_origins" forbidden_values: - "*" severity: "medium" - id: "config-rate-limit" description: "登录接口必须配置限流" target_files: - "*.py" - "*.js" pattern: "login" check: "rate_limit" required: true severity: "high"

有人可能想问，AI 本身不就能看配置吗，为什么还要单独的规则文件？我的理解是，规则文件定义的是"组织认可的基线"，AI 会受训练数据的影响，不同模型对安全基线的理解不完全一样。有了显式的 YAML 规则，相当于团队把安全基线变成了代码，不但 AI 可以执行，人也可以 review 这个基线本身是否合理。审计过程中如果发现有规则没覆盖到的配置项，AI 还可以在报告里提出来，然后你再把这个新规则加回 YAML 里——这就是"审计能力持续沉淀"的过程。

5. 实操演示：拿一个 Python 项目跑完整流程

理论讲再多，不如实际操作一遍。我构造了一个故意存在多个安全问题的 Python Flask 项目，然后挂上 security-audit-skill 做完整审计。下面记录的是关键过程和结果。

5.1 项目代码示例（存在典型安全问题）

# app.py - 故意构造的包含安全漏洞的示例 from flask import Flask, request, jsonify import sqlite3 import os app = Flask(__name__) # 漏洞1：硬编码密钥（将被detect_secrets.py捕获） SECRET_KEY = "my-super-secret-key-12345678" # 漏洞2：使用全局数据库连接（可能导致SQL注入面扩大） conn = sqlite3.connect("users.db") @app.route("/login", methods=["POST"]) def login(): username = request.json.get("username") password = request.json.get("password") # 漏洞3：SQL注入 - 字符串拼接查询 query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'" cursor = conn.execute(query) user = cursor.fetchone() if user: return jsonify({"status": "success", "token": "fake-jwt-token"}) return jsonify({"status": "failed"}), 401 @app.route("/user/<user_id>", methods=["GET"]) def get_user(user_id): # 漏洞4：越权访问 - 未校验资源归属 cursor = conn.execute(f"SELECT * FROM users WHERE id = {user_id}") user = cursor.fetchone() return jsonify({"id": user[0], "username": user[1], "email": user[2]}) if __name__ == "__main__": # 漏洞5：Debug模式开启 + 未绑定固定地址 app.run(debug=True, host="0.0.0.0", port=5000)

同时准备一个 requirements.txt：

flask==2.2.3 werkzeug==2.2.3 jinja2==3.1.2 requests==2.28.1 pyyaml==5.4

5.2 分阶段执行记录

第一阶段：资产盘点

AI 识别出项目是 Python Flask 应用，入口是 app.py，依赖清单为 requirements.txt，无其他配置文件（但已注意到没有 .env 文件，这是一个配置缺失信号）。

第二阶段：依赖扫描

运行python scripts/scan_deps.py requirements.txt，输出结果中关键发现：

• pyyaml 5.4 存在已知漏洞 CVE-2020-14343（反序列化 RCE），严重级别高
• requests 2.28.1 无已知高危漏洞
• flask 2.2.3 本身无直接漏洞，但依赖的 werkzeug 版本需进一步核查

值得一提的坑：OSV API 对 PyYAML 的漏洞返回是 2020 年的，但 AI 在生成报告时不能"看到"这个漏洞就完事了，还需要判断当前项目实际是否调用了yaml.load()且未指定安全 Loader。这就是脚本输出和 AI 分析结合的价值——脚本负责"查出有漏洞"，AI 负责"确认是否可利用"。

第三阶段：密钥扫描

运行python scripts/detect_secrets.py .，结果直接命中SECRET_KEY = "my-super-secret-key-12345678"，且因上下文没有os.environ等引用，被判定为高置信度发现。

第四阶段：代码审计

这个阶段 AI 基于 checklist.md 逐项检查，报告了 SQL 注入（app.py 第 21 行）、越权访问（app.py 第 29 行）、Debug 模式开启（app.py 第 43 行）三个问题。每个问题都给出了触发的请求构造方式和修复建议。

第五阶段：配置审计

由于项目没有独立的配置文件，AI 在报告中额外标注了"缺少集中配置管理，安全相关配置散落在代码中"这一项，同时指出 Flask 内置服务器不适用于生产环境。

5.3 最终审计报告结构

审计报告设计为 markdown 格式，包含以下部分：

• 扫描范围与方法
• 高危发现（附复现路径与修复代码）
• 中危发现（附修复建议）
• 低危发现（建议性修复）
• 配置类问题汇总
• 未发现问题的检查项

报告最后面还会附一句"审计建议"：优先修复 SQL 注入和硬编码密钥，其次是升级依赖，最后再考虑加装 WAF 等外围防护。这个优先级排序很重要，AI 默认会"逢洞必报"，但真正有价值的审计报告是告诉你"先补哪个"。

6. 常见问题与排查技巧实录

6.1 AI 在审计过程中"半路跑偏"怎么办

最大也是最常见的问题：AI 在看到第一个漏洞之后，就开始详细分析、写修复代码，把后面的审计动作全忘了。这在没有 skill 的裸 prompt 场景下几乎是必然发生的。

我的解决办法写在SKILL.md的执行原则里——"分阶段执行，每个阶段完成后再进入下一阶段"以及"任何发现的问题都必须记录，包括疑似问题"。前者约束流程顺序，后者避免了 AI 因为"想去深入分析"而中断流程。另外我还在SKILL.md里加了一句"不要在审计完成前输出修复代码"，效果比单纯写"先完成扫描"要好得多。

6.2 误报太多导致审计报告失去参考价值

密钥扫描脚本初版只做正则匹配时，误报率大概在 40% 左右，报告里全是API_KEY = os.getenv("API_KEY")这种"伪泄露"。后来加了LOW_RISK_CONTEXTS排除逻辑，误报率降到了 10% 以下。

6.3 skill 运行在

不同编程语言项目上的效果差异

Python 和 JavaScript 项目的审计效果最好，因为主流漏洞模式（注入、XSS、反序列化）在这两种语言中的代码特征明显。Java 项目的效果稍微差一些，主要因为 Spring 等框架的配置分散且复杂，checklist.md里的条目相对不够精细。Go 项目因为语言本身的强类型和内存安全特性，发现的漏洞多集中在逻辑层面而非语言特性层面。

6.4 依赖审计 API 超时或不可用

如果运行环境的网络受限，scan_deps.py的分析模块会很脆弱。我在脚本里给每个查询设置了 timeout=10 秒，且失败时静默跳过。经验是：宁可"少报"也不能"报错停跑"，审计流程的连续性远比单点发现重要。如果要离线执行，可以考虑本地缓存一个 NVD/OSV 数据库的导出文件，但这需要另外维护更新机制。

6.5 skill 应该放在哪个层级

在设计 skill 的时候，很容易陷入"我要把所有安全知识全部塞进去"的误区。试过一次把整个 OWASP Testing Guide 放进 resources，结果 AI 在执行的时候明显变慢，经常翻找资料反而忘了当前阶段。我的取舍标准是：resources 里只放"AI 不会记错且高频使用"的内容，比如 Top 10 清单和 CWE 速查；而那些"需要时能联网查"的内容（具体 CVE 详情、漏洞利用 payload），不放进 skill。

7. 彩蛋：fetch 式 skill 与本地资源 skill 的选择

做 skill 做久了，你会发现 skill 有两种典型形态：一种是把所有东西打包在本地，一种是通过fetch动获取外部内容。对于 security-audit-skill 来说，我明确倾向于"本地资源为主 + 适时 fetch 为辅"。

原因有两个。第一，安全审计涉及的知识具有静态性——OWASP Top 10 几年才更新一次，CWE 条目相对稳定，不适合每次都去远程抓取。第二，审计动作的执行环境经常是内网或 CI 流水线，不一定具备外网访问能力。所以我在SKILL.md里写了一条规则：外部依赖检查（如 OSV 查询）作为独立阶段执行，其他阶段不依赖网络。

当然，如果项目未来要扩展这个能力，我建议可以做一个"双模式"的变体：默认离线模式用本地缓存数据 + 启发式扫描；在检测到外网可用时，自动切换为实时查询模式，获取最新漏洞情报。这种设计更符合企业级产品对环境适应性的要求，也是我把 skill 落地到生产环境的下一步计划。

现在回看整个过程，对我来说最有价值的收获不是"做出了一个能用的 skill"，而是对 skill 的设计哲学有了实感：skill 不是 prompt 的排列组合，也不是简单地把工具脚本打个包。它本质上是在定义"AI 在这个场景下的工作方式"。你定义得越具体、越结构化，AI 的执行就越稳定，结果就越可预期。这就好比带实习生干活——优秀的管理者会把方法论和标准化动作拆解清楚，而不是只跟实习生说"你去把这个项目好好审计一下"。

如果你也在琢磨怎么做一个属于自己的 skill，我建议不要从"构造一个万能技能"的角度出发，而是找一个像安全审计这样流程明确、边界清晰、检查项可枚举的具体场景入手。把一个场景的 skill 吃透，比堆十个半成品 skill 有价值得多。