企业官网建设流程全解析

平时在折腾 AI Agent 的时候，大家应该都遇到过类似的困惑：明明同一个模型，换一种方式组织提示词，输出质量能差出一条街；但按一套固定的提示词去跑，又总觉得模型只是在“泛泛而谈”，不够聚焦。最近我在做一个偏安全场景的项目时，接触到了security-audit-skill这个概念，研究了一圈之后发现，它其实不属于某个具体的软件或平台，而是一套把“安全审计”这件事沉淀成 AI Agent 可复用技能的完整思路。今天就把我从设计、写死到跑通的完整过程拆开聊一聊。

如果你正在用 Codex、OpenCode 这类编码代理，或者对“怎么把专家经验固化给 Agent 用”这件事感兴趣，这篇文章应该能给你省下不少试错的成本。我会把 skill 和 agent 到底什么关系、和普通提示词有什么区别、怎么写一个能落地的安全审计 skill、以及部署和排坑这些环节都过一遍，全程用我实际跑过的例子来说明。

1. 先搞明白：skill 到底是什么，和 agent 别搞混了

先说一个我从热词里反复看到的问题：很多人把 skill 和 agent 当成同一个东西，或者觉得 skill 就是“高级一点的提示词”。这两种理解都不太准确，尤其是当你想认真做一个安全审计方向的 skill 时，这个概念的偏差会直接导致设计上的跑偏。

1.1 skill 的本质：把“行为方式”打包进上下文

简单来说，skill 是一套结构化的指令、规则、脚本和参考资料的组合体，它描述的是一种“应对某类任务的完整方法论”，而不是一个独立运行的智能体。你看它的载体通常非常朴素：一个 Markdown 文件（比如SKILL.md）加一堆辅助脚本或参考文档。当 agent 需要处理某项任务时，会把这份 skill 的关键内容加载进自己的上下文里，然后按这套方法论去执行。

打个比方，agent 像是一个经验丰富的“临时工”，你告诉它做什么它就做什么，但前提是它得知道自己该按什么流程来。skill 就像是给这个临时工的一本“作业指导书”，里面有操作规范、有检查清单、有质量标准。临时工本身还是那个模型，但拿到了指导书之后，工作方式就从“自由发挥”变成了“按指令办事”。

1.2 agent 和 skill 的分工差异：一个管行动，一个管方法

很多资料会把 agent 描述成“能自主规划、调用工具、完成任务”的程序，这没错。但如果你细看主流 agent 框架（比如 Claude Code、Codex、OpenCode 等）的实现方式，会发现 agent 更像是一个“调度器”和一个“执行器”的结合体：

• agent 负责理解用户目标，拆解任务，决定调用哪些能力
• skill 负责在某个特定场景下，为 agent 提供“该怎么做”的细节

举个例子，同样是让模型去检查一个 Web 项目的安全性，如果没有 skill，模型可能会凭训练时的记忆泛泛地列出“SQL 注入、XSS、CSRF”这老三样。但如果挂载了一个写好的security-audit-skill，它就会按照你规定的审计流程去走：先看依赖清单，再逐项检查认证逻辑，接着核查配置项，最后输出一份固定格式的报告。也就是说，skill 把“做安全审计”这件事的方法论给固化了，agent 要做的是加载并执行这套方法论。

1.3 为什么叫 skill 而不是插件或剧本

我在热词里看到有“skill插件”这种说法，也有人在问“skill和agent的区别”。这类概念辨析其实挺重要，因为它决定了你怎么使用它。如果把它理解成插件，你可能会以为它是个独立运行的软件，需要单独启动；如果把它理解成剧本，你可能又会觉得它只是写死的一段对话流程。

实际用过之后我的感受是：skill 更像是一个“微方法包”，粒度比插件更小，但比纯提示词更有操作性。它不负责跑服务，不负责管理生命周期，它只干一件事：在 agent 需要的时候，把最好的做法塞进模型的“脑子里”。所以你完全可以把 skill 当成活跃在 agent 生态里的一套“能力胶囊”，这也是为什么现在很多 agent 框架都会原生支持 skill 机制。

2. security-audit-skill 的核心思路与方案选型

有了基本概念打底，接下来聊聊我设计security-audit-skill时的整体思路。这套技能的目标很明确：让一个通用的大模型 Agent，在不需要额外微调的情况下，能按专业安全审计人员的思维方式去检查代码和配置。

2.1 为什么安全审计特别适合做成 skill

当时我为什么要专门做这么个东西？原因是安全审计这个场景对专业性和流程性的要求非常高：

• 专业性：你得知道检查哪些点、用什么方式查、各种漏洞的特点和利用条件
• 流程性：审计不是东一榔头西一棒子，需要按一定逻辑系统地排查
• 可复制性：同样的检查方法应该能在不同项目上重复使用

这三个特点，恰好是 skill 最擅长解决的问题。普通提示词无法承载复杂的判断逻辑；而如果写一个全功能的 agent，投入产出比又太低。用 skill 的方式来干这件事，既可以把“审计方法论”独立维护，又能随时适配不同的 agent 框架和模型，灵活性最高。

我把这个名为security-audit-skill的技能定位成一条“审计流水线”：当模型面对一个待检查的项目时，它不再自由发挥，而是按我预设的流程一步步检查，最终产出一份结构化报告。通过这种方式，模型输出的专业度和一致性都有了保障。

2.2 技术选型：为什么用 Markdown 加脚本的轻量结构

在做具体方案时，我对比过三种实现思路：

最后选 Markdown 加辅助脚本的方案，主要是因为这类 skill 的消费方是模型而不是程序。Markdown 对模型的解析非常友好，同时又具备轻量、跨平台、易维护的特点。配合少量脚本用于自动收集依赖、扫描文件，就可以在保留模型分析能力的同时，把一些机械性工作交给代码去完成。

另外，这种结构对多 agent 框架的兼容性也很好。我现在在 Codex 和 OpenCode 里都挂过同一个 skill，只需要把文件夹放到对应的 skills 目录下就行，不改一行代码。如果选用了自研程序，迁移成本会高很多。

2.3 结构设计：一个可扩展的安全审计工具箱

我最终把security-audit-skill的目录结构设计成这样：

security-audit-skill/ ├── SKILL.md ├── scripts/ │ ├── collect_deps.py │ ├── scan_configs.py │ └── summarize_report.py ├── references/ │ ├── owasp_top10_notes.md │ ├── auth_checklist.md │ └── config_review_cases.md └── examples/ └── sample_report.md

核心是SKILL.md，它负责告诉模型“你是一名安全审计员，你要按以下方法论工作”；scripts/目录里放的是辅助脚本，比如自动收集依赖清单、查找敏感配置项；references/放的是模型可以参考的专业笔记；examples/则给它提供输出格式的样例。

这个结构的好处是：你把“方法论”和“工具”分离了。方法论更新时只需要改SKILL.md；工具需要更新时只动scripts/，两者互不干扰。我后来在维护其他方向的 skill 时也复用了这套结构，实操下来非常省心。

3. SKILL.md 的编写要点：把专业方法论写成模型能执行的语言

SKILL.md 是整个 skill 的灵魂，它的质量直接决定了最终效果。很多新手在写 skill 时会陷入两个极端：要么写成一本厚厚的教科书，要么写得太简单，跟普通提示词没有区别。这两种方式我都在security-audit-skill的开发过程中踩过坑，下面拆开讲一讲。

3.1 描述区：让 agent 能准确识别“什么时候该用我”

Skill 文件的开头通常是一个 YAML 格式的描述区，它的作用是让 agent 在“技能匹配”阶段快速判断这个 skill 是否适用于当前任务。这部分虽然只占了文件很小的一块，但它决定了技能能不能被正确触发。

我一开始写描述时犯过一个大错：只写了“用于安全审计”这几个字。结果在真实项目中，当 agent 遇到“检查项目安全性”这类需求时，经常不会自动调起这个 skill。后来我把描述改成了带场景和关键词的形式，效果立刻就不一样了：

--- name: security-audit description: >- Use this skill when the task involves checking code, dependencies, authentication logic, or configuration files for security issues. This includes requests like "audit this project", "check for vulnerabilities", "is this code safe?", and any security review scenario. ---

这段描述的作用是教会 agent 做“意图匹配”。它不是简单写“安全审计”，而是列出了所有可能触发的用户表达，让模型能更准确地判断。通俗理解，这就像是在一本书的封面上写清楚“这本书适合谁读、讲了什么主题”一样，agent 拿到手才能判断要不要翻开看内容。

3.2 指令区：把审计流程拆成可执行步骤

指令区是整个 skill 的核心，它会影响模型执行的逻辑。我参照专业安全审计的执行顺序，将其分为“信息收集→静态分析→动态核查→总结报告”四个阶段。

具体来看，我在SKILL.md的指令区里按这个顺序列了清单：

## What to Do You are a professional application security auditor. Your job is to systematically review the provided codebase or configuration through the following process: ### Step 1: Inventory - Identify the language(s), framework(s), and package management files involved. - Run the dependency collection script to get a list of direct dependencies and, if possible, their versions. ### Step 2: Static Checks - Review authentication and authorization flows. - Look for hard-coded secrets, weak hashing algorithms, or unsafe deserialization. - Inspect database queries for injection patterns. - Check file upload and path handling logic. ### Step 3: Config Review - Inspect default/live configuration files for insecure settings (e.g., debug mode enabled, permissive CORS, missing security headers). ### Step 4: Report - Summarize findings into a structured report. - Classify each issue by severity (Critical / High / Medium / Low / Info). - For each finding, include: affected file, line or config key, why it is a problem, and a concrete remediation suggestion.

为什么要把步骤写得这么细？因为模型在自由状态下容易遗漏检查项。人在审计时可能会因为经验丰富而自动想到某些点，但模型如果没有引导，很可能只挑自己训练数据里出现最多的漏洞类型来输出。把步骤写细，本质上是给模型划了一条执行路径，让它每一步都走完再往下。实测下来，这样写出的报告覆盖度比自由发挥要高得多。

3.3 落款区：明确约束与边界

我发现很多人写 skill 时会忽略“落款区”，但这对安全审计类 skill 尤其重要。安全审计如果让模型随意发挥，它可能会给出不切实际的建议，或者在你没有完整代码上下文时强行编造结论。

我在SKILL.md的结尾部分加了一段“声明与边界”，内容大约是：

## Boundaries - If you do not have access to the source files, do not guess. State clearly which parts could not be reviewed. - Report only issues you can verify or reason about from the visible evidence. - Do not attempt to exploit or verify a vulnerability by executing attack code. - All remediation suggestions must respect the project's architecture and language ecosystem.

这段约束的作用是防止模型“一本正经地胡说八道”。没有这段约束时，我遇到过模型毫无根据地声称某处存在 SQL 注入的情况——它只是想迎合用户的排查需求。加了边界约束之后，输出的报告更接近一个真正的安全审计专家会给出的判断。

4. 辅助脚本与参考资料：让模型从“凭记忆”变成“有依据”

SKILL.md只是“方法论”，而一个好的安全审计 skill 还必须配备辅助脚本和参考资料。这部分对应到热词里“skill脚本”和“检索文献skill”的方向，也是让技能具备实操性的关键。

4.1 辅助脚本：自动收集信息，减少幻觉

安全审计最怕模型凭空猜测依赖版本、配置内容、代码结构。为了减少这类问题，我给 skill 配了collect_deps.py和scan_configs.py两个脚本。

collect_deps.py的核心逻辑是自动识别项目的包管理文件并提取依赖列表，再输出成模型容易解析的文本格式。比如检测到package.json就读取 dependencies 和 devDependencies 字段，检测到requirements.txt就逐行解析包名和版本。脚本并不做漏洞库匹配，它的职责仅仅是“如实告诉模型项目里装了什么”，这样模型在后面的分析中就有了事实基础。

#!/usr/bin/env python3 """Collect dependency information for a project in a model-friendly format.""" import json import os import sys from pathlib import Path def collect_from_package_json(path): with open(path, "r", encoding="utf-8") as f: data = json.load(f) deps = data.get("dependencies", {}) dev_deps = data.get("devDependencies", {}) return deps, dev_deps def collect_from_requirements_txt(path): deps = {} with open(path, "r", encoding="utf-8") as f: for line in f: line = line.strip() if not line or line.startswith("#") or "://" in line: continue if "==" in line: name, version = line.split("==", 1) deps[name.strip()] = version.strip() else: deps[line] = "any" return deps, {} def main(): root = Path(sys.argv[1] if len(sys.argv) > 1 else ".") print("=== Dependency Inventory ===") for path in sorted(root.rglob("package.json")): if "node_modules" in path.parts: continue deps, dev_deps = collect_from_package_json(path) print(f"\n[package.json] {path}") print("direct deps:") for name, version in deps.items(): print(f" {name}: {version}") print("dev deps:") for name, version in dev_deps.items(): print(f" {name}: {version}") for path in sorted(root.rglob("requirements.txt")): deps, _ = collect_from_requirements_txt(path) print(f"\n[requirements.txt] {path}") for name, version in deps.items(): print(f" {name}: {version}") if __name__ == "__main__": main()

这个脚本写的很简单，但它对模型的作用非常大。没有这份清单时，模型只能凭文件名或 import 语句去猜；有了它之后，整个审计过程的所有分析都有了稳定的起点。热词里有人在问“codex用的检索文献skill”，这类需求其实是一样的思路：给模型提供额外的检索依据，让它在更充分的信息基础上做判断。

4.2 参考资料：把专家笔记压缩进技能包

除了脚本，我还准备了几个 Markdown 格式的参考资料文件。这些资料不需要面面俱到，它们的作用是在模型需要的时候提供关键提示。以auth_checklist.md为例，我整理了认证逻辑中常见的检查点：

# Auth Checklist - Password storage: Is bcrypt/scrypt/argon2 used? Plaintext or MD5/SHA1 is a finding. - Session management: Are session tokens generated with enough entropy? Are session cookies marked HttpOnly and Secure? - Password reset: Is the reset token single-use? Does it expire? - MFA: Is multi-factor authentication supported for sensitive operations? - Access control: Are object-level access checks enforced on every request? Is there a server-side authorization check beyond UI hiding?

这类资料写的比较精炼，每一条都是“检查点”，而不是长篇大论。模型在审计时读到这些列表，会像一位资深安全工程师在旁提点一样，知道自己该去验证哪些项。如果你想让 skill 适配更具体的团队规范，可以在 references 里增加内部安全规范文档，这样模型输出的建议就会向团队标尺对齐。

4.3 脚本与模型的协作边界

写到这里我想特别说明一点：这些脚本一定要设计成“被动调用”的模式。很多人在做辅助工具时会想着把功能做得越大越好，比如直接做一个扫描器返回“有漏洞”的结论。但对 AI skill 来说，这是反效果的。如果你的脚本已经能精确判断漏洞，你还用模型做什么？正确的关系是：

• 脚本负责提供客观事实：依赖清单、配置项、可疑文件的列表
• 模型负责专业判断：某个配置是否危险、某种写法是否易受攻击、如何修复

维持这个边界很重要，它让模型始终处于“分析和决策”的位置，而不是变成一个只会复读脚本输出的“传声筒”。我在设计scan_configs.py时也只做“发现并展示配置项”这一步，绝不在脚本里写任何漏洞判断逻辑，判断的事全部交给 SKILL.md 引导模型去完成。

5. 部署、使用与工具链整合：从“写好的 skill”到“能用的 skill”

写好了 skill，下一步就是把它挂到 agent 环境里跑起来。这一步看似简单，但如果没有理顺部署路径和调用方式，后面你会遇到不少莫名其妙的报错。

5.1 安装路径：不同框架都有对应的 skills 目录

目前主流支持 skill 机制的 agent 框架，大多采用“目录放取”的方式。以我实际用过的两个环境为例。

Codex 环境：它支持通过codex install skill之类的命令来安装，也可以直接把 skill 文件夹放到配置文件中指定的 skills 目录下。你可以在项目根目录集中维护一个skills/目录，也可以把不同项目各自的 skill 放在项目内部。我推荐把通用型 skill（比如这个安全审计的）放到全局目录，这样跨项目都能用。

# 把安全审计 skill 安装到全局 skills 目录 cd security-audit-skill codex install skill .

OpenCode 环境：它的 skill 目录通常位于~/.config/opencode/skills/或项目级.opencode/skills/下。安装时直接把整个security-audit-skill/文件夹复制过去即可。

mkdir -p ~/.config/opencode/skills cp -r security-audit-skill ~/.config/opencode/skills/

注意，这里有几个容易踩的坑，我逐个讲一下。

坑一：文件夹名必须与 SKILL.md 中的 name 一致（或符合框架约定）。比如我给 Codex 用的时候，skill 目录名一般得对应到一个合法的标识符，不能带空格和特殊字符。如果你命名不一致，agent 可能加载了内容却无法正确索引到技能名称。

坑二：SKILL.md 必须放在 skill 文件夹根目录。有的框架要求 skill 的描述信息必须在首屏可见位置，如果嵌套太深，框架可能完全识别不到这个 skill。我有一次把SKILL.md放到了docs/子目录里，结果整个技能在 agent 侧完全不可见，排查了半天才意识到是路径问题。

坑三：开发完 skill 之后一定要重启 agent 进程。我用 Codex 时第一次测试，写完 skill 没有重启，结果在会话里怎么调用都提示找不到。这和服务器热部署完全是两码事，agent 框架读取技能列表通常是在启动时做的。

5.2 实际调用：让 agent 正确识别并执行审计流程

部署完之后的调用方式，主要取决于 agent 框架的交互设计。在支持多 agent 协作的工具里，你通常可以在代码提交前、构建流程或发布的环节中挂载这个安全审计任务；在普通命令行场景里，你只需要在会话里明确要求做一次安全审查即可。

以下是使用 OpenCode 时的会话示例：

用户：请对这个项目做一次全面的安全审计。 Agent: 我将使用 security-audit-skill 技能开展审计。 首先收集项目依赖信息，然后检查核心代码和配置文件……

在 Codex 里，你还可以通过 AGENTS.md 文件配置自动规则，比如“所有涉及数据库操作代码的变更，都要先运行安全审计 skill 再提交”。这样就可以把安全审计固化到开发工作流中，而不依赖人工每次手动触发。

我实测下来比较推荐的一种方式是：在 CI/CD 流程中加入一个“预提交安全审计”环节，让 agent 在代码合并前自动调用这个 skill。这样既能利用模型的智能发现潜在风险，又不增加太多人工干预成本。

5.3 skill 与整体工具链的协同

部署并不是终点。想让security-audit-skill真正发挥价值，你还需要让它和日常使用的其他工具链配合起来。比如：

• 与代码托管平台的 PR 检查集成，每次提交自动触发审计
• 与通知系统联动，发现高危问题时及时提醒
• 与其他辅助 skill 串联，先做代码分析，再做安全审计

热词里有人提到“springai skill agent”、“skill和agent的区别”，这类问题在实际协作中体现得更明显。在一个成熟的 agent 编排系统里，会有多个 skill 共同工作：一个负责需求分析、一个负责编码、一个负责测试、一个负责安全审计。每个 skill 之间可以互相引用对方的输出，从而形成完整的工作流。安全审计 skill 在里面扮演的是“把关人”的角色，它不生产代码，但它负责判断这些代码能不能安全地进入生产环境。

6. 使用实战：一次完整的 security-audit-skill 审计记录

讲原理和部署讲了半天，不如直接看一次真实的执行记录。下面是我在一个 Node.js 示例项目上跑security-audit-skill的过程，项目里故意埋了几个典型问题。

6.1 审计准备与信息收集

我先把 skill 安装好，然后在项目根目录执行会话指令。agent 第一步会加载 SKILL.md，并按照定义先运行collect_deps.py。下面是我在项目里的执行记录：

$ python scripts/collect_deps.py . === Dependency Inventory === [package.json] ./package.json direct deps: express: ^4.17.1 mysql2: ^2.3.3 jsonwebtoken: ^8.5.1 dev deps: nodemon: ^2.0.15

这个步骤的价值在于，模型接下来会基于这份依赖清单去思考“这些组件的已知风险点有哪些”。比如express4.x 版本较老，mysql22.3.3 也存在版本偏旧的问题，模型就会在后面的审计中重点核查这些依赖是否引用了不安全的写法。

6.2 静态审计发现与推理

拿到依赖清单后，agent 调起scan_configs.py扫描配置文件，同时开始审查关键代码文件。我准备了一个带有典型问题的代码片段，agent 的审计路径大致是这样推进的：

• 发现config.js中设置了debug: true，结合依赖版本分析，判定这是生产环境遗留的调试配置
• 在routes/login.js中看到密码校验用的是crypto.createHash('md5')，得出弱哈希算法的结论
• 在db.js中发现 SQL 语句使用字符串拼接而不是参数化查询，判定存在注入风险

这些判断不是模型凭空想出来的，它是在SKILL.md的 Step 1-3 引导下，逐个检查点排查后得到的结果。相比之下，我之前用普通提示词让模型做同样的检查时，它只输出了“存在 SQL 注入和弱加密”，没有指出debug: true这种配置问题。

6.3 报告生成与输出

Agent 按照 SKILL.md 中定义的格式输出了结构化报告。报告中包含严重程度分级、受影响文件、具体问题描述和修复建议。我截取报告的主要结构，方便你参考：

# Security Audit Report Date: 2025-xx-xx Scope: node-sample-project ## Findings ### [High] SQL Injection in db.js - File: db.js, line 22 - Detail: User input is concatenated into a SQL query string. This allows an attacker to manipulate the query logic. - Remediation: Use parameterized queries (e.g., `connection.execute()` with `?` placeholders) instead of string concatenation. ### [Medium] Weak Password Hashing in routes/login.js - File: routes/login.js, line 45 - Detail: MD5 is used for password hashing, which is considered cryptographically broken. - Remediation: Migrate to bcrypt or argon2 with a per-user salt. ### [Low] Debug Mode Enabled in config.js - File: config.js, line 5 - Detail: `debug: true` exposes stack traces and internal error details in production responses. - Remediation: Set `debug: false` in production, or better, load this value from an environment variable.

看到这个过程，你应该能理解为什么我要强调“流程化”了。安全审计是一个系统性的排查过程，靠模型自由发挥很容易漏项，而一旦把专业方法论固化到 skill 里，模型就能像一个有经验的安全工程师一样按步骤检查、推理、输出。整个过程既保存了模型的灵活性，又提升了输出的规范和完整性。

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

最后这部分，我整理了在实际使用security-audit-skill和编写各种 skill 过程中遇到的高频问题。很多问题光看文档是发现不了的，都是在实际跑的时候才会冒出来。

7.1 skill 没有被加载或识别

这是我遇到最多的问题，查了半天发现自己犯了一个低级的错误——SKILL.md里的name字段用了驼峰命名，而目录名用了小写加连字符，导致框架在初始化时匹配不上。

排查清单：

7.2 模型忽略 skill 中的步骤，仍然自由发挥

这个问题相对隐蔽。有时明明已经把 SKILL.md 写好、部署也正确，但模型还是会跳过步骤直接给结论。通过几次试验，我总结出了一套行之有效的优化方法。

原因一：SKILL.md 的指令太笼统。比如只写“check for common vulnerabilities”，模型无法从中获得行为约束。后来我改成“Step 1: 收集信息；Step 2: 执行静态检查；Step 3: 输出报告”，每一步还附上具体要检查什么，模型的遵从度立刻提升。

原因二：模型上下文不够长或任务过长。当审计任务涉及多个文件时，模型可能会为了节省 token 而跳过一些步骤。我的解决办法是：在 SKILL.md 中明确要求“Do not skip any step”，并且在最终报告中必须包含所有步骤的对应输出字段。如果模型觉得信息不足，它至少会显式声明“未能核实某项”，而不是假装查过。

7.3 模型输出的修复建议与项目实际环境不匹配

安全审计技能生成报告之后，你有时会发现建议方案并不适配当前项目的实际生态。比如它建议一个 Python 项目使用某个 Java 生态的安全库。究其原因，是模型把训练数据中的通用经验直接套用过来了，没有结合项目技术和语言上下文。

我的解决方式是：在 SKILL.md 的“Boundaries”部分明确要求“All remediation suggestions must respect the project's architecture and language ecosystem”，同时在第一步的信息收集中就让模型获取语言和框架信息。这两点合在一起，可以让模型的建议更具针对性。

7.4 Skill 文件过大导致 agent 上下文溢出

Skill 写得过于详细虽然能保证专业性，但也可能导致SKILL.md太大。当 agent 为节省上下文而截断内容时，模型执行效果反而下降。

我的实践经验是：把核心的方法论写在SKILL.md里，保证它短小精悍；把大段的代码示例、内部规范、详细案例放到references/目录，让模型按需查阅。这样可以让核心驱动保持轻量，同时保留足够的参考信息。这一思路在“ppt skill”“会议纪要 skill”“科研论文 skill”等非技术场景同样适用——核心指令要精简，深层资料要沉淀。

8. 写在最后：把重复性专业工作交给 skill

最近身边越来越多人在聊“codex skill”“opencode skill”“agent skill”，我能感觉到 AI Agent 的应用方式正在发生一次范式转移。以前我们习惯于写提示词，后来学着搭 agent 流程，现在大家开始意识到：真正专业的东西，是需要以“技能包”的形式沉淀下来的。security-audit-skill只是我在安全领域的一次尝试，但它反映的方法论适用于任何领域——把你最拿手的专业经验，梳理成一套模型能理解的流程，然后让它在你不在场的时候也能按标准执行。

我个人在实际操作中最大的体会是，skill 设计最关键的并不是写多复杂的代码，而是想清楚：你要模型遇到什么样的任务、按什么思路去思考、参考哪些信息、输出什么结果。只要这四个问题理清楚了，skill 的结构和内容自然就能定下来。后面如果你也想为自己手头的工作流做一个专属 skill，建议先从最常见的场景入手，把你平时反复给人解释的那套经验先文字化，再结构化成SKILL.md文件。等你试用顺手之后，可能会发现原来 AI 能干好的事情，比我们想象的要多得多。