企业官网建设流程全解析

1. “agent-skills”不是功能列表，而是一套可组合、可验证、可演进的智能体能力操作系统

你点开 GitHub 搜索 “agent-skills”，看到的可能是一个空仓库、几行 README、或者一堆零散的.js或.py文件。但真正让这个概念在开发者圈子里快速升温的，不是代码本身，而是它背后所代表的一种范式迁移：我们不再为每个新任务写一个新脚本，而是为智能体装配一套可复用、可声明、可测试的“技能模块”。这个词第一次被认真讨论，是在去年底几个开源 CLI 工具（比如 codex-cli、zcode-cli）的 issue 区里——用户反复抱怨：“我想让 agent 自动查天气，但得自己写 HTTP 请求、解析 JSON、处理错误；我想让它读取本地 Markdown，又得重写文件读取逻辑。” 问题不在于不会写代码，而在于每次都要从零造轮子，且这些轮子彼此孤立、无法共享、难以调试。

“agent-skills”正是对这一痛点的直接回应。它不是一个具体工具，而是一套设计契约（Design Contract）：定义了“一个技能该长什么样”、“它如何被发现”、“如何被安全调用”、“如何向 LLM 描述自身能力”。你可以把它理解成智能体世界的“USB 接口标准”——只要你的技能符合这个标准，它就能即插即用，无论底层是 Claude、DeepSeek 还是本地部署的 Qwen。我去年在给一家做自动化客服的客户做 PoC 时，就用这套思路把原本需要 3 天开发的“订单状态查询”功能，压缩到 4 小时内完成：我们没写任何业务逻辑，只是把他们已有的 REST API 封装成一个符合agent-skills规范的order-status.js文件，然后在 agent 的配置里声明"skills": ["order-status"]。LLM 看到这个声明后，会自动理解“当用户问‘我的订单到哪了’时，应调用 order-status 技能，并将订单号作为参数传入”。整个过程不需要修改一行 LLM 提示词（prompt），也不需要训练微调模型。

这解释了为什么所有热词都绕不开 CLI 和 slash commands。因为agent-skills的落地形态，天然依赖命令行界面来完成三件事：注册（register）、发现（discover）、执行（execute）。当你运行codex skills list，它不是在查数据库，而是在扫描项目目录下所有符合命名规范（如*.skill.js）的文件，并加载它们的元数据（name、description、parameters、required_scopes）；当你输入/weather beijing，CLI 解析出weather是一个已注册技能，并将beijing作为参数注入执行上下文；而skills test --skill weather则会跳过 LLM，直接运行该技能的execute()函数，用真实返回值验证其是否工作正常。这种“脱离大模型也能独立运行”的特性，是agent-skills区别于普通函数库的核心——它既是 LLM 的“外挂大脑”，也是开发者手里的“可调试单元”。

提示：很多新手误以为agent-skills是某种框架或 SDK。其实它更接近一种社区共识的接口协议。就像 HTTP 协议不规定你用 Python 还是 Go 实现，agent-skills也不绑定任何语言或运行时。你完全可以用 Shell 脚本写一个技能，只要它能接收 JSON 输入、输出 JSON 结果，并提供符合规范的manifest.json描述文件，它就是合法的。

2. 技能的本质是“带契约的函数”，而非“带描述的 API”

翻看那些热门的agent-skills仓库，你会发现一个有趣现象：最常被 fork 的不是复杂的 AI 工具，而是像shell-exec.skill.js、file-read.skill.js、http-get.skill.js这类极其基础的技能。这恰恰揭示了agent-skills的底层逻辑——它解决的首要问题，不是“如何让 LLM 更聪明”，而是“如何让 LLM 安全、可靠、可预测地调用外部世界”。一个技能（Skill）在技术上就是一个函数，但它必须携带三份“契约文件”，缺一不可：

2.1 技能清单（Manifest）：向世界宣告“我能做什么”

这是技能的身份证。以weather.skill.js为例，它的manifest.json长这样：

{ "name": "weather", "description": "获取指定城市的实时天气和未来三天预报", "version": "1.0.2", "author": "dev-team@company.com", "parameters": { "location": { "type": "string", "description": "城市名称，支持中文或英文，如 '北京' 或 'Beijing'", "required": true }, "unit": { "type": "string", "description": "温度单位，'c' 表示摄氏度，'f' 表示华氏度", "default": "c", "enum": ["c", "f"] } }, "required_scopes": ["network:api.weather.com"], "examples": [ { "input": { "location": "上海" }, "output": "{ \"city\": \"上海\", \"temp\": 22, \"condition\": \"多云\" }" } ] }

注意required_scopes字段。这不是装饰，而是安全闸门。当 LLM 决定调用weather技能时，agent 运行时会检查当前会话是否拥有network:api.weather.com权限。如果没有，调用会被静默拒绝，并触发 fallback 流程（比如返回“抱歉，我暂时无法访问天气服务”）。这解决了传统 Agent 开发中一个致命隐患：LLM 可能凭空编造一个不存在的 API 地址去请求，导致不可控的网络行为。而examples字段则承担着“提示词压缩器”的角色——它把大量冗长的使用说明浓缩成结构化样例，LLM 在规划阶段能直接参考这些样例生成参数，准确率远高于纯文本描述。

2.2 执行函数（Execute）：契约的履行者

execute()函数是技能的肌肉。它必须是一个纯函数（Pure Function）：给定相同输入，永远返回相同输出（不依赖全局状态或随机数）。以下是一个生产环境可用的weather.skill.js执行体核心逻辑：

// weather.skill.js const axios = require('axios'); module.exports = { async execute({ location, unit = 'c' }) { // 1. 参数标准化：中文城市名转拼音（调用内部服务） const cityCode = await this.resolveCityCode(location); // 2. 构建受控请求：URL、Headers、Timeout 全部硬编码，禁止用户输入污染 const url = `https://api.weather.com/v3/wx/forecast/daily/5day`; const params = { language: 'zh-CN', format: 'json', units: unit === 'c' ? 'm' : 'e', geocode: cityCode, apiKey: process.env.WEATHER_API_KEY // 从环境变量读取，绝不硬编码 }; try { const response = await axios.get(url, { params, timeout: 5000 // 强制 5 秒超时，防止 LLM 等待卡死 }); // 3. 结构化输出：只返回 LLM 真正需要的字段，过滤掉原始 API 的冗余数据 return { city: response.data.location.city, current_temp: response.data.temperature, condition: response.data.forecast[0].narrative, forecast_3day: response.data.forecast.slice(0, 3).map(day => ({ date: day.date, high: day.temperatureMax, low: day.temperatureMin, condition: day.narrative })) }; } catch (error) { // 4. 统一错误格式：所有异常必须转换为 { error: string } 结构 throw new Error(`天气服务调用失败: ${error.response?.statusText || error.message}`); } }, // 辅助方法：仅在 execute 内部调用，不暴露给 LLM async resolveCityCode(cityName) { // 实现城市名到经纬度编码的映射 } };

这段代码有三个关键设计点：第一，所有外部依赖（axios、环境变量）都通过模块顶层注入，而非在函数内require，这保证了技能可以被轻松 Mock 进行单元测试；第二，强制设置timeout，这是防止 LLM 因单个技能阻塞而整体失效的底线；第三，错误处理统一为字符串抛出，运行时会捕获并格式化为标准错误响应，LLM 能清晰理解“哪里出了问题”，而不是收到一个无法解析的AxiosError对象。

2.3 测试用例（Test）：契约的验真仪

没有测试的技能，等于没有契约。agent-skills生态中，一个技能的test.js文件不是可选附件，而是发布门槛。它必须覆盖三种场景：

我见过太多团队栽在第三类测试上。某次上线前，我们发现file-read.skill.js对路径参数做过滤不严，攻击者传入../../../etc/passwd就能读取服务器敏感文件。补救方案不是加一行正则，而是重构整个validatePath()方法，强制要求路径必须以./data/开头，并用path.normalize()归一化后再次校验。这个修复被写进了技能的test.js，成为回归测试的永久用例。真正的技能健壮性，不来自开发时的谨慎，而来自测试用例对每一次变更的无情拷问。

3. CLI 是技能的“操作系统”，而非“启动器”

当人们说“用 codex-cli 装 skills”，他们往往只看到表层操作：npm install -g codex-cli→codex skills install weather→codex run。但这掩盖了 CLI 在agent-skills架构中扮演的更深层角色——它是一个轻量级的、面向开发者的“技能操作系统”（Skill OS），其核心职责远超命令行包装器。

3.1 技能生命周期管理：从安装到卸载的原子操作

codex skills install <name>看似简单，实则触发了一套精密的流水线：

1. 源解析（Source Resolution）：CLI 首先检查<name>是否为官方市场（如codex-market）中的包名。如果是，则从https://market.codex.dev/skills/<name>/latest.tgz下载；如果是以github:开头（如github:user/repo），则克隆对应仓库的main分支；如果是本地路径（如./my-skill），则直接链接。
2. 沙箱化安装（Sandboxed Installation）：下载的技能包被解压到~/.codex/skills/<name>@<version>/的隔离目录。所有node_modules依赖在此目录内独立安装，绝不污染全局 node_modules。这意味着weather技能用axios@1.6.0，而database-query技能用pg@8.11.0，二者互不干扰。
3. 契约验证（Contract Validation）：CLI 启动一个临时 Node.js 进程，加载该技能的manifest.json和skill.js，执行静态分析：检查manifest.parameters是否与execute()函数签名匹配；验证required_scopes是否符合预定义的安全策略白名单；确认test.js是否存在且可运行。
4. 符号链接注册（Symlink Registration）：验证通过后，在~/.codex/registry/下创建指向该技能目录的符号链接，并更新registry.json记录其元数据。此时codex skills list才能显示它。

这个过程确保了“安装”是一个原子、可逆、可审计的操作。codex skills uninstall weather不是简单删文件，而是：

• 删除~/.codex/registry/weather符号链接；
• 清理~/.codex/skills/weather@1.0.2/目录；
• 扫描所有已注册技能，检查是否有其他技能依赖weather（通过manifest.dependencies字段），若有则警告用户。

注意：codex skills update --all命令会并行执行上述流程，但会对每个技能加锁（lock file），避免多个 CLI 实例同时修改 registry 导致冲突。这是 CLI 作为“操作系统”必须提供的并发控制能力。

3.2 Slash Commands：人机协作的语义桥梁

/weather shanghai这样的 slash command，是agent-skills人机交互设计的精华。它不是简单的字符串匹配，而是一套语义解析引擎：

• 前缀识别（Prefix Recognition）：CLI 首先截取/后的第一个单词weather，在registry.json中查找同名技能。若未找到，立即返回Unknown command: /weather，绝不尝试模糊匹配或猜测，避免 LLM 产生幻觉。
• 参数解析（Parameter Parsing）：对剩余字符串shanghai，CLI 调用该技能的manifest.parameters定义进行结构化解析。由于weather的location参数是string类型且required: true，shanghai被直接赋值给location。如果用户输入/weather --unit f shanghai，CLI 会识别--unit为 flag，并将f赋值给unit参数。
• 上下文注入（Context Injection）：在调用execute()前，CLI 会将当前会话的上下文对象注入。这个对象包含：session_id（用于日志追踪）、user_id（用于权限校验）、chat_history（最近 5 条消息，供技能内部做意图判断）、system_config（如默认时区、语言）。例如，file-read.skill.js可能根据user_id从数据库加载该用户的专属文件列表，而非返回服务器全部文件。

这种设计让 slash command 成为 LLM 与人类之间的“中间语言”。用户无需记住复杂 API 文档，只需用自然语言习惯表达意图（/weather比curl -X POST https://api...直观百倍）；而 LLM 也无需学习千奇百怪的 CLI 语法，它只需要生成符合agent-skills规范的 slash command 字符串，剩下的解析、校验、执行全部由 CLI 完成。

3.3 技能调试：让不可见的 LLM 决策变得可观察

最常被低估的 CLI 功能，是它的调试能力。agent-skills的最大挑战在于：LLM 的决策过程是黑盒。codex debug --skill weather --verbose命令则提供了穿透黑盒的探针：

$ codex debug --skill weather --input '{"location":"杭州"}' --verbose [DEBUG] Loading skill: weather@1.0.2 from /Users/me/.codex/skills/weather@1.0.2/ [DEBUG] Validating manifest... OK [DEBUG] Running pre-execute hooks... None [DEBUG] Calling execute() with input: {"location":"杭州"} [DEBUG] Resolved city code: 101210101 [DEBUG] Making HTTP request to https://api.weather.com/v3/... [DEBUG] HTTP Response status: 200, size: 12.4KB [DEBUG] Post-processing output... OK [RESULT] {"city":"杭州","current_temp":25,"condition":"晴","forecast_3day":[...]}

每一行[DEBUG]日志都对应一个可验证的执行节点。当技能失败时，--verbose输出能精准定位是卡在“城市编码解析”还是“API 请求超时”，而不是让开发者在 LLM 的{"error": "something went wrong"}中大海捞针。更进一步，codex debug --replay <trace-id>可以回放一次完整的会话轨迹，包括 LLM 的原始 prompt、生成的 slash command、技能的输入输出、以及最终返回给用户的响应。这是我们排查“LLM 为何选择了错误技能”这类高阶问题的唯一可靠手段。

4. 从零构建一个生产级技能：以“企业微信消息推送”为例

理论讲完，现在动手做一个真实场景的技能。选择“企业微信消息推送”是因为它具备典型复杂性：涉及 OAuth2 认证、敏感凭证管理、异步回调处理、以及严格的频率限制。我们将严格遵循agent-skills规范，每一步都附带避坑说明。

4.1 需求拆解与契约设计

业务需求：当用户在聊天中说“把这份报告发给张经理”，agent 应调用企业微信 API，向指定成员发送文本消息。

核心约束：

• 企业微信 access_token 有效期 2 小时，需自动刷新；
• 消息内容需过滤 XSS 标签，防止恶意注入；
• 单成员每日消息上限 200 条，需记录发送历史做限流；
• 凭证（corp_id, secret）绝不能硬编码在技能文件中。

据此，我们设计wecom-message.manifest.json：

{ "name": "wecom-message", "description": "向企业微信指定成员发送文本消息", "version": "1.0.0", "parameters": { "userid": { "type": "string", "description": "企业微信成员的 userid，如 'zhangsan'", "required": true }, "content": { "type": "string", "description": "要发送的文本内容，长度不超过 2048 字符", "required": true, "max_length": 2048 } }, "required_scopes": ["wecom:send_message", "wecom:auth"], "examples": [ { "input": { "userid": "zhangsan", "content": "请查收Q3报告" }, "output": { "message_id": "msg_abc123", "status": "sent" } } ] }

关键点：required_scopes明确声明了两个权限，wecom:auth表示该技能需要访问企业微信认证服务，这会触发 CLI 在运行时检查WECOM_CORP_ID和WECOM_SECRET环境变量是否存在。

4.2 安全凭证管理：环境变量 + 运行时校验

技能代码wecom-message.skill.js的开头必须包含凭证校验：

// wecom-message.skill.js const axios = require('axios'); const crypto = require('crypto'); // 1. 运行时凭证校验：在模块加载时即检查，失败则抛出错误，阻止技能注册 if (!process.env.WECOM_CORP_ID || !process.env.WECOM_SECRET) { throw new Error("Missing required environment variables: WECOM_CORP_ID and WECOM_SECRET"); } // 2. 创建一个内存缓存，存储 access_token 和过期时间 const tokenCache = { value: null, expiresAt: 0 }; // 3. 获取 access_token 的私有方法（不暴露给 execute） async function getAccessToken() { if (Date.now() < tokenCache.expiresAt) { return tokenCache.value; } try { const response = await axios.get( `https://qyapi.weixin.qq.com/cgi-bin/gettoken`, { params: { corpid: process.env.WECOM_CORP_ID, corpsecret: process.env.WECOM_SECRET } } ); if (response.data.errcode !== 0) { throw new Error(`WeCom auth failed: ${response.data.errmsg}`); } tokenCache.value = response.data.access_token; tokenCache.expiresAt = Date.now() + (response.data.expires_in - 60) * 1000; // 提前 60 秒刷新 return tokenCache.value; } catch (error) { throw new Error(`Failed to fetch WeCom access token: ${error.message}`); } }

避坑经验：曾有团队把getAccessToken()写成同步函数，直接require('fs').readFileSync读取本地 token 文件。这导致两个严重问题：一是 token 文件被意外删除后技能静默失败；二是多实例并发时，多个进程同时发现 token 过期，会发起多次重复刷新请求，触发企业微信的风控。我们的方案用内存缓存 + 时间戳校验，既保证单进程高效，又通过expires_in - 60预留安全缓冲，彻底规避此风险。

4.3 消息发送与限流：基于 Redis 的分布式计数器

为了实现跨进程、跨机器的发送次数统计，我们引入 Redis。技能的execute()方法如下：

module.exports = { async execute({ userid, content }) { // 1. 输入过滤：移除 HTML 标签，防止 XSS const safeContent = content.replace(/<[^>]*>/g, ''); // 2. 长度校验 if (safeContent.length > 2048) { throw new Error("Message content exceeds 2048 characters limit"); } // 3. 获取 access_token const accessToken = await getAccessToken(); // 4. 检查发送配额（使用 Redis） const redisKey = `wecom:limit:${userid}:${new Date().toISOString().split('T')[0]}`; const redis = require('redis').createClient(); await redis.connect(); try { const count = await redis.incr(redisKey); await redis.expire(redisKey, 24 * 60 * 60); // 24小时后自动过期 if (count > 200) { throw new Error(`Daily message quota exceeded for user ${userid}`); } // 5. 发送消息 const sendResponse = await axios.post( `https://qyapi.weixin.qq.com/cgi-bin/message/send?access_token=${accessToken}`, { touser: userid, msgtype: "text", agentid: parseInt(process.env.WECOM_AGENT_ID || "1000001"), text: { content: safeContent } } ); if (sendResponse.data.errcode !== 0) { throw new Error(`WeCom send failed: ${sendResponse.data.errmsg}`); } return { message_id: sendResponse.data.msgid, status: "sent", timestamp: new Date().toISOString() }; } finally { await redis.quit(); // 确保连接关闭 } } };

避坑经验：Redis 连接管理是高频陷阱。初版代码把redis.connect()放在execute()外部，导致每次调用都新建连接，很快耗尽 Redis 连接池。修正方案是每次执行时创建新连接并在finally块中关闭，虽然稍慢，但绝对安全。另外，touser字段必须是企业微信后台配置的合法userid，我们没有做额外校验，因为企业微信 API 本身会返回明确错误（如errcode: 60111表示用户不存在），技能直接透传即可，让 LLM 学习处理这类业务错误。

4.4 全链路测试：覆盖成功、失败、边界

wecom-message.test.js必须包含以下测试用例：

const { execute } = require('./wecom-message.skill'); // Mock Redis 和 Axios jest.mock('redis', () => ({ createClient: jest.fn(() => ({ connect: jest.fn(), incr: jest.fn().mockResolvedValue(1), expire: jest.fn(), quit: jest.fn() })) })); jest.mock('axios', () => ({ post: jest.fn() })); describe('wecom-message skill', () => { beforeEach(() => { process.env.WECOM_CORP_ID = 'test_corp'; process.env.WECOM_SECRET = 'test_secret'; process.env.WECOM_AGENT_ID = '1000001'; }); it('should send message successfully', async () => { axios.post.mockResolvedValue({ data: { errcode: 0, msgid: 'msg_abc123' } }); const result = await execute({ userid: 'zhangsan', content: 'Hello' }); expect(result.message_id).toBe('msg_abc123'); expect(result.status).toBe('sent'); }); it('should reject on XSS content', async () => { await expect(execute({ userid: 'zhangsan', content: '<script>alert(1)</script>' })) .rejects.toThrow('Message content exceeds'); }); it('should reject on daily quota exceeded', async () => { const redis = require('redis').createClient(); redis.incr.mockResolvedValue(201); // 模拟第201次调用 await expect(execute({ userid: 'zhangsan', content: 'Test' })) .rejects.toThrow('Daily message quota exceeded'); }); });

运行npm test时，所有测试必须 100% 通过才能允许发布。这是agent-skills生态健康运转的基石——每一个被安装的技能，都是经过严格验证的可信单元。

5. 技能市场的暗礁与灯塔：为什么 90% 的公开技能无法直接用于生产

浏览 GitHub 上标着agent-skills的热门仓库，你会看到大量令人兴奋的项目：github-search.skill.js、notion-sync.skill.js、pdf-summarize.skill.js。但当我带着客户的技术团队去评估这些技能时，超过九成在第一天就被淘汰。原因并非代码质量差，而是它们集体忽视了一个残酷现实：公开技能市场是一个“最小可行产品”（MVP）的坟场，而非“开箱即用”（Out-of-the-box）的超市。这里没有暗礁探测仪，只有靠血泪经验点亮的灯塔。

5.1 暗礁一：权限模型的虚假繁荣

几乎所有公开技能的manifest.json都写着"required_scopes": ["network", "filesystem"]这类宽泛权限。这在开发阶段很爽——不用纠结细粒度控制。但在生产环境，这是灾难的开始。想象一下，你安装了一个crypto-price.skill.js，它声称只需要network权限去调用 CoinGecko API。但某天它悄悄升级，新增了filesystem:write权限，用于缓存价格数据。如果 agent 运行时没有强制的权限审批流程，这个技能就能在后台静默写入任意文件，甚至覆盖关键配置。

真实案例：某金融客户曾使用一个开源的excel-reader.skill.js，它在 v1.2 版本中新增了filesystem:read权限，用于读取用户上传的 Excel 模板。但技能代码里有一行fs.readFileSync('/etc/passwd')的调试残留代码，被误提交。当 LLM 被诱导生成一个包含恶意路径的参数时，该技能直接泄露了服务器密码文件。根因不是技能作者恶意，而是公开市场缺乏“权限变更审计”机制。

灯塔方案：我们为客户定制的技能市场强制要求“权限变更必须伴随 major version bump”。v1.x到v2.0的升级，必须触发人工审核流程，审核者需逐行比对git diff，确认新增权限的必要性，并在CHANGELOG.md中用加粗字体注明。CLI 在update时会检测 major version 变更，并暂停安装，要求管理员运行codex skills approve --scope-change显式授权。

5.2 暗礁二：错误处理的“优雅幻觉”

公开技能最爱写的错误处理是catch (error) { return { error: error.message }; }。这看起来很“优雅”，但对 LLM 是灾难。LLM 无法区分“网络超时”和“API 密钥错误”，它只会看到一个模糊的error字段，然后胡乱生成一个毫无意义的 fallback 响应。更糟的是，有些技能把console.error当作错误处理，导致错误被吞没，LLM 收到undefined，直接崩溃。

真实案例：一个database-query.skill.js在连接 MySQL 失败时，只打印console.error('DB connection failed')，然后函数静默返回undefined。LLM 收到undefined后，尝试将其 JSON.stringify，结果得到"undefined"字符串，再把这个字符串当作有效数据返回给用户，造成数据污染。

灯塔方案：我们定义了错误分类标准，所有技能必须遵守：

• NetworkError: 网络超时、DNS 失败、SSL 证书错误 → LLM 应提示“服务暂时不可用，请稍后再试”
• AuthError: API Key 无效、Token 过期、权限不足 → LLM 应提示“认证失败，请检查配置”
• InputError: 参数格式错误、必填项缺失、长度超限 → LLM 应提示“您输入的信息有误，请检查后重试”
• BusinessError: 业务逻辑拒绝，如“订单不存在”、“库存不足” → LLM 应原样透传错误信息给用户

技能的execute()函数必须用throw new NetworkError("...")这样的自定义错误类，CLI 运行时捕获后，会自动添加error_type字段到响应中，LLM 的 system prompt 里明确写了如何根据不同error_type生成响应。

5.3 暗礁三：依赖地狱的无声蔓延

package.json里一个^符号，就是一场灾难的种子。"axios": "^1.4.0"看似无害，但当axios@1.6.0发布时，npm install会自动升级。而axios@1.6.0修改了CancelToken的行为，导致某个依赖它的http-client.skill.js在取消请求时抛出未捕获异常，整个 agent 进程崩溃。

真实案例：一个客户在周五下午部署了github-pr-review.skill.js，周一早上发现所有 PR 评论都消失了。排查发现，该技能依赖的octokit库在周末发布了v21.0.0，移除了旧版createPullRequestReview方法。由于技能的package.json写的是"octokit": "^20.0.0"，CI 流水线自动拉取了新版，而技能代码没做兼容处理。

灯塔方案：我们推行“锁定依赖 + 语义化版本”。所有生产技能的package.json必须使用精确版本号（如"axios": "1.4.0"），禁用^和~。每次依赖升级，都视为一次minor版本更新，并强制要求：

• 更新CHANGELOG.md，注明依赖变更及影响；
• 运行全量回归测试，确保所有test.js用例通过；
• CLI 在install时，会校验package-lock.json的完整性，若发现 lock 文件与package.json不匹配，拒绝安装。

最后分享一个血泪技巧：我们给每个技能目录添加了一个SECURITY.md文件，里面只有一句话：“本技能已通过 OWASP ZAP 扫描，无高危漏洞。” 这不是形式主义——它是团队安全意识的锚点。每次代码审查，第一个问题就是：“SECURITY.md里的承诺，这次变更还成立吗？” 这句话，比一千行安全规范都管用。