一、项目概述

OpenCode Skills（仓库地址：farmage/opencode-skills）是基于 Jeffallan/Claude Skills 适配 OpenCode 生态的专业技能库，目标是通过标准化技能封装提升 AI 辅助开发的效率与质量。项目严格遵循 MIT 开源协议，所有技能均来自社区贡献与官方验证，核心优势在于将分散的开发经验转化为可复用的结构化工作流 —— 开发者无需从零梳理流程，即可直接调用经过实战验证的最佳实践。

截至 2026 年 3 月，项目已迭代至 0.4.10 版本，包含 66 个专业技能、9 套完整工作流与 365 份技术参考文档，覆盖从需求分析、架构设计、编码实现到测试部署、安全审计的全开发生命周期。其设计逻辑围绕 "context on demand"（按需加载上下文）展开：每个技能仅在匹配用户需求时激活，且仅加载完成当前任务必需的参考文档 —— 这一机制既避免了大模型上下文过载，又能确保技能输出的精准性与针对性。

二、核心价值技能深度解析

OpenCode Skills 的核心价值在于将通用开发场景拆解为标准化工作流，以下是覆盖全生命周期的高价值技能，每个技能均包含功能特点、核心优势、适用场景与实战价值，所有内容均来自项目官方技能定义文档。

1. 需求分析与设计类

此类技能解决开发前期的需求模糊、沟通低效问题，将非结构化需求转化为可执行的技术文档，是项目成功的基础保障。

1.1 Feature Forge（需求专家）

1. 功能特点：

采用「产品经理视角 + 开发视角」双维度分析框架 —— 产品经理视角聚焦用户价值、业务目标与成功指标，确保需求对齐业务优先级；开发视角则提前介入技术可行性、安全边界与性能瓶颈评估，从根源上避免 “需求可行但技术不可实现” 的矛盾。

核心输出严格遵循行业标准格式：

1. 1. EARS 格式功能需求：采用「When <触发条件>, the < 系统 > shall < 响应动作 >」「Where < 特性 > is active, the < 系统 > shall < 行为 >」等标准化语法，消除自然语言的歧义；
   2. Given/When/Then 验收标准：每个需求对应明确的前置条件、操作动作与预期结果，确保开发与测试的验收基准完全一致；
   3. 结构化实现清单：将需求拆解为可落地的开发任务，明确每个任务的依赖关系与交付节点。

所有输出均存储为 specs/{feature_name}.spec.md 文档，便于版本控制与团队协作。

1. 核心优势：
   1. 系统性减少需求歧义：通过标准化格式将口头需求转化为可验证的文档，据项目内部统计，能将后续开发中的需求变更率降低约 40%；
   2. 自动化覆盖非功能需求：无需额外提示，自动将性能（如 “接口响应时间≤200ms”）、安全（如 “用户密码需加密存储”）、兼容性等隐性需求纳入规范，避免因遗漏非功能需求导致的返工；
   3. 内置利益相关者对齐机制：通过结构化问题引导用户确认需求优先级，确保开发方向与业务目标完全匹配。
2. 适用场景：
   1. 新功能从 0 到 1 的需求定义；
   2. 跨团队协作时的需求同步（如产品、开发、测试团队的对齐）；
   3. 编写正式的产品需求文档（PRD）或技术需求文档（TRD）；
   4. 为模糊需求补充验收标准。
3. 实战价值：

假设开发团队需要实现 “用户积分过期提醒” 功能，传统沟通模式下可能仅得到 “用户积分过期前 7 天要提醒” 的模糊描述，而通过 Feature Forge，团队可直接生成包含触发条件（如 “当用户积分距离过期时间≤7 天，且用户近 30 天有登录行为”）、提醒渠道（如 “APP 推送 + 邮件”）、失败处理（如 “推送失败则 24 小时内重试 3 次”）的结构化需求文档，确保所有角色对需求的理解完全一致。

1.2 Architecture Designer（架构设计师）

1. 功能特点：

以 15 年资深架构师的视角提供决策支持，核心工作流覆盖从需求拆解到落地验证的全流程：

1. 1. 需求对齐：先收集功能需求、非功能需求与技术约束，确保架构设计完全匹配业务目标；
   2. 模式匹配：从 20+ 经典架构模式（如分层架构、事件驱动、微服务、CQRS 等）中筛选适配方案，每个模式均附带适用场景与 trade-off 说明；
   3. 可视化设计：输出 Mermaid 格式的架构图（支持一键导出为 PNG/SVG），清晰展示组件边界、数据流向与依赖关系；
   4. ADR 记录：为每个关键决策（如 “选择 PostgreSQL 而非 MongoDB 作为订单数据库”）生成标准化架构决策记录（ADR），明确决策背景、备选方案与长期影响；
   5. 风险评估：识别架构设计中的潜在风险（如 “微服务拆分过细导致的运维复杂度上升”），并提供针对性的风险缓释策略。
2. 核心优势：
   1. 平衡技术与业务：拒绝为 “技术炫技” 而过度设计，始终以业务价值为核心 —— 例如对于用户量不足 10 万的初创项目，会优先推荐单体架构而非微服务；
   2. 决策可追溯：ADR 文档会随项目迭代更新，即使团队成员变动，后续开发者也能快速理解架构设计的来龙去脉；
   3. 聚焦可维护性：优先选择经过行业验证的成熟模式，同时预留未来扩展的灵活性，平衡短期开发效率与长期迭代成本。
3. 适用场景：
   1. 大型系统的高可用架构设计（如电商订单系统、金融支付系统）；
   2. 技术栈选型或架构模式切换（如从单体架构拆分微服务）；
   3. 编写或更新架构决策记录（ADR）；
   4. 现有系统的架构优化或技术债务治理。
4. 实战价值：

当团队面临 “单体架构拆分微服务” 的需求时，Architecture Designer 会先评估现有系统的业务复杂度、团队运维能力与流量规模，输出包含微服务边界（如 “用户中心、订单中心、支付中心”）、通信协议（如 “gRPC 内部调用 + REST 外部接口”）、数据一致性方案（如 “最终一致性 + 分布式事务补偿”）的完整设计方案，同时通过 Mermaid 架构图直观展示组件关系 —— 这不仅能让团队快速达成共识，更能避免因拆分不当导致的服务调用混乱或数据不一致问题。

1.3 Spec Miner（遗留系统逆向工程师）

1. 功能特点：

针对无文档或文档缺失的遗留系统，采用「架构视角 + QA 视角」双维度分析框架：架构视角聚焦系统技术栈、模块依赖与数据流向；QA 视角则侧重观察系统的实际行为（如错误处理逻辑、边界条件响应）与非功能特性（如性能瓶颈、安全漏洞）。

核心工作流高度自动化：

1. 1. 范围界定：支持按模块、功能或代码目录划定分析边界，避免无意义的全量扫描；
   2. 代码探索：通过 Glob（文件匹配）、Grep（关键字检索）等工具自动识别关键文件（如 API 路由定义、数据库配置），快速定位系统核心逻辑；
   3. 数据追踪：自动追踪请求从入口到数据库的全链路流向，生成可视化的调用链图；
   4. 规范输出：将所有观测结果转化为 EARS 格式的需求文档，同时标注每个结论对应的代码位置，确保可追溯。
2. 核心优势：
   1. 基于代码证据的客观分析：所有结论均来自实际代码扫描结果，拒绝主观推断 —— 例如若代码中未实现某条错误处理逻辑，会明确标注为 “未观测到” 而非 “不存在”；
   2. 自动化减少人工成本：传统遗留系统分析需投入数周甚至数月的人工梳理，而 Spec Miner 可将这一过程压缩至数天，大幅降低学习曲线；
   3. 安全与错误处理全覆盖：不会遗漏遗留系统中的安全漏洞（如硬编码的密钥）或潜在的错误处理缺陷，为后续维护提供风险预警。
3. 适用场景：
   1. 维护无文档的遗留系统；
   2. 为现有项目补充缺失的技术文档；
   3. 新成员快速熟悉代码库；
   4. 遗留系统的现代化改造或迁移。
4. 实战价值：

假设团队接手一个 5 年前开发的 Python 后端项目，仅有的文档是 “实现了用户管理功能”，通过 Spec Miner，开发者可快速获取：

1. 1. 系统技术栈（如 “Flask 1.2 + PostgreSQL 10 + Redis 3.2”）；
   2. 模块依赖关系（如 “user 模块依赖 auth 模块，auth 模块依赖 redis 缓存”）；
   3. 核心 API 接口（如 “POST /api/user/login” 的参数、返回值与错误码）；
   4. 潜在风险（如 “登录接口未做 rate limiting，存在暴力破解风险”）；

这能让新成员在 1-2 天内掌握系统核心逻辑，而非花费数周时间逐行阅读代码。

2. 全栈开发与安全类

此类技能聚焦编码实现环节，将安全左移理念贯穿全栈开发流程，从根源上减少安全漏洞与技术债务。

2.1 Fullstack Guardian（全栈守护者）

1. 功能特点：

采用「前端 + 后端 + 安全」三位一体的开发视角，核心工作流围绕 “安全左移” 设计：

1. 1. 需求对齐：先确认功能范围与验收标准，确保开发方向与需求一致；
   2. 三视角设计：从前端（如组件交互逻辑、状态管理）、后端（如 API 设计、数据库查询）、安全（如输入验证、权限控制）三个维度同步设计方案，输出标准化的技术设计文档；
   3. 安全检查点：在编码前强制执行 references/security-checklist.md 中的 12 项核心检查（如 “是否对所有用户输入做服务端验证”“是否使用参数化查询”），任何一项未通过则无法进入编码阶段；
   4. 增量实现：采用 “小步迭代 + 组件测试” 的开发模式，每完成一个组件（如前端登录表单、后端登录接口）立即进行单元测试，确保功能正确性；
   5. 交付校验：输出完整的前后端代码、安全说明文档与测试用例，确保可直接交付测试或部署。
2. 核心优势：
   1. 安全左移：将安全审查从编码后提前到编码前，据项目统计，能将全栈功能的安全漏洞数量降低约 60%；
   2. 全链路一致性：前后端与安全逻辑同步设计，避免出现 “前端做了输入验证但后端未做” 的脱节问题；
   3. 自动化合规：所有输出均符合 OWASP Top 10、CWE 等国际安全标准，无需额外投入合规审计成本。
3. 适用场景：
   1. 实现前后端联动的完整功能（如用户登录、订单提交）；
   2. 开发涉及敏感数据的功能（如支付、用户隐私信息管理）；
   3. 全栈项目的技术选型或架构决策；
   4. 修复跨端的功能缺陷或安全漏洞。
4. 实战价值：

实现 “用户个人信息修改” 功能时，Fullstack Guardian 会同步输出：

1. 1. 前端代码：带输入验证的表单组件（如 “邮箱格式校验”“手机号长度校验”）、错误状态提示逻辑；
   2. 后端代码：参数化查询的数据库操作（如 UPDATE users SET email = ? WHERE id = ?）、基于用户 ID 的权限控制（如 “仅允许修改自身信息”）；
   3. 安全说明：输出编码规则（如 “对返回的用户信息做 HTML 转义，防止 XSS”）、权限控制逻辑（如 “非本人请求返回 403 Forbidden”）；

这一方案从根源上避免了 SQL 注入、XSS、越权访问等常见漏洞，确保功能上线后的安全性。

2.2 Secure Code Guardian（安全编码专家）

1. 功能特点：

以 OWASP Top 10、CWE 等安全标准为核心，提供安全编码的全流程支持：

1. 1. 威胁建模：先识别功能的攻击面（如 “用户输入”“第三方接口依赖”）与潜在威胁（如 “SQL 注入”“XSS”）；
   2. 安全设计：针对每个威胁设计对应的防御方案（如 “参数化查询防御 SQL 注入”“输出编码防御 XSS”）；
   3. 代码生成：输出经过安全加固的代码示例，覆盖密码哈希、JWT 验证、输入校验等核心场景；
   4. 验证检查：提供自动化的安全验证步骤（如 “测试登录接口的暴力破解防护”“验证 JWT 过期逻辑”），确保安全措施生效。
2. 核心优势：
   1. 防御深度：所有安全措施均采用多层防御原则 —— 例如用户输入验证会同时在前端（方便用户反馈）和后端（最终安全屏障）实现，即使前端验证被绕过，后端仍能拦截恶意输入；
   2. 合规性：所有输出均符合 PCI DSS（支付卡行业数据安全标准）、HIPAA（医疗保健流通与责任法案）等行业合规要求，为金融、医疗等敏感行业的项目提供合规保障；
   3. 实用性：提供可直接复用的代码示例，无需开发者自行研究安全工具或算法的细节。
3. 适用场景：
   1. 实现用户认证 / 授权功能（如登录、权限控制）；
   2. 处理敏感数据（如密码、银行卡号、医疗记录）；
   3. 修复已知的安全漏洞（如 SQL 注入、XSS）；
   4. 为现有代码做安全加固。
4. 实战价值：

实现 “用户密码重置” 功能时，Secure Code Guardian 会输出：

1. 1. 密码哈希逻辑：采用 bcrypt 算法（12 轮盐值迭代），而非 MD5 等弱哈希算法；
   2. 输入验证逻辑：用 Zod 库校验邮箱格式，同时限制请求频率（15 分钟内最多 5 次请求）；
   3. JWT 重置令牌：有效期 15 分钟，且仅包含重置密码所需的最小权限（如用户 ID）；
   4. 安全响应规则：无论邮箱是否存在，均返回 “重置链接已发送” 的通用提示，避免攻击者枚举有效邮箱；

这一方案能有效防御暴力破解、邮箱枚举、令牌劫持等常见攻击手段。

3. 测试与质量保障类

此类技能确保代码质量与可维护性，将测试左移理念贯穿开发流程，减少线上缺陷的发生概率。

3.1 Test Master（测试专家）

1. 功能特点：

覆盖从单元测试到安全测试的全类型测试，核心工作流围绕 “测试左移” 设计：

1. 1. 范围定义：根据功能类型（如 “用户登录” 属于核心功能，需覆盖单元、集成、E2E 测试）确定测试范围与优先级；
   2. 策略制定：为不同类型的测试设计对应的策略 —— 例如单元测试需覆盖 80% 以上的代码，集成测试需覆盖核心业务流程，安全测试需针对 OWASP Top 10 设计用例；
   3. 测试实现：输出符合行业最佳实践的测试代码（如 Jest 单元测试、Playwright E2E 测试）；
   4. 执行与报告：运行测试并生成结构化报告，标注缺陷的严重程度（Critical/High/Medium/Low）与修复建议；
   5. 验收校验：确保测试覆盖率达到预设标准（如单元测试覆盖率≥80%），否则需补充测试用例。
2. 核心优势：
   1. 全类型测试覆盖：无需切换多个工具，即可完成单元、集成、E2E、性能、安全等全场景测试；
   2. 测试左移：将测试从编码后提前到编码前 —— 例如在需求阶段就同步设计测试用例，确保开发过程中随时可验证功能正确性；
   3. 反模式规避：内置测试反模式检查（如 “测试实现细节而非行为”“用生产数据做测试”），确保测试用例的可维护性与有效性。
3. 适用场景：
   1. 为新项目制定测试策略；
   2. 编写单元 / 集成 / E2E 测试用例；
   3. 分析代码覆盖率并补充测试用例；
   4. 修复不稳定的 “flaky” 测试；
   5. 性能测试或安全测试。
4. 实战价值：

开发 “用户登录” 功能时，Test Master 会输出：

1. 1. 单元测试：覆盖密码哈希逻辑（如 “正确密码返回 true，错误密码返回 false”）、JWT 生成逻辑（如 “生成的令牌包含用户 ID 与正确的过期时间”）；
   2. 集成测试：覆盖登录接口的正常流程（如 “输入正确的邮箱密码返回 200 OK”）、异常流程（如 “输入错误密码返回 401 Unauthorized”）；
   3. E2E 测试：覆盖从用户输入邮箱密码到跳转到个人中心的完整流程；
   4. 安全测试：覆盖暴力破解场景（如 “连续 5 次错误密码后触发 rate limiting”）；

这能确保 “用户登录” 功能上线后，不会出现 “密码哈希失败”“JWT 令牌无效” 等线上缺陷。

3.2 Code Reviewer（代码审查专家）

1. 功能特点：

提供覆盖正确性、性能、可维护性、安全的全方位代码审查，核心工作流严格标准化：

1. 1. PR 摘要：先总结 PR 的核心意图（如 “修复用户登录接口的 SQL 注入漏洞”），确保审查方向与开发目标一致；
   2. 架构检查：验证代码是否符合项目的架构设计（如 “是否遵循分层架构，API 层是否直接操作数据库”）；
   3. 细节审查：检查代码质量（如 “是否有魔法数字”“变量命名是否清晰”）、性能（如 “是否有 N+1 查询”）、安全（如 “是否有 SQL 注入风险”）；
   4. 测试验证：检查测试用例的覆盖范围与有效性（如 “是否覆盖了异常流程”）；
   5. 结构化报告：输出包含问题位置、修复建议、严重程度的审查报告。
2. 核心优势：
   1. Sandwich 反馈原则：采用 “肯定优点→指出问题→提供建议” 的反馈结构，既维护开发者的积极性，又能有效传递改进方向；
   2. 具体可落地：所有反馈均附带代码示例 —— 例如对于 N+1 查询问题，会同时给出 “坏代码”（如循环中查询数据库）和 “好代码”（如使用 prefetch_related 批量查询）的对比；
   3. 优先级清晰：将问题分为 Critical（如 “SQL 注入漏洞，必须修复”）、Major（如 “N+1 查询，影响性能”）、Minor（如 “变量命名不规范”）三类，帮助开发者优先处理高风险问题。
3. 适用场景：
   1. 审查 Pull Request（PR）；
   2. 代码质量审计或技术债务治理；
   3. 团队内部的代码规范落地；
   4. 新成员的代码质量指导。
4. 实战价值：

审查 “用户登录” 功能的 PR 时，Code Reviewer 会输出：

1. 1. Critical 问题：若代码中存在 cursor.execute(f"SELECT * FROM users WHERE email = '{email}'") 的字符串插值查询，会立即标记为 “SQL 注入漏洞”，并建议改为参数化查询；
   2. Major 问题：若代码中存在循环查询用户角色的 N+1 问题，会建议使用 prefetch_related 批量查询；
   3. Minor 问题：若代码中存在 if status == 3 的魔法数字，会建议改为常量 ORDER_STATUS_SHIPPED = 3；
   4. Positive 反馈：若代码中正确实现了 rate limiting，会明确肯定 “登录接口的 rate limiting 逻辑设计合理，能有效防御暴力破解”；

这能确保 PR 合入前，所有高风险问题都被修复，同时帮助开发者提升编码水平。

3.3 Debugging Wizard（调试专家）

1. 功能特点：

采用系统化的调试方法论，核心工作流为 “重现→隔离→假设→测试→修复→预防”，覆盖所有主流编程语言与场景：

1. 1. 问题重现：要求开发者提供可稳定重现的步骤，拒绝 “偶尔出现” 的模糊描述；
   2. 范围隔离：通过二分法、git bisect 等工具将问题范围缩小到具体的函数或代码行；
   3. 假设验证：逐个验证假设（如 “是否是缓存过期导致的问题”），而非盲目猜测；
   4. 修复与预防：输出具体的修复方案，并要求添加回归测试，避免问题再次发生。
2. 核心优势：
   1. 系统化而非经验化：传统调试依赖开发者的个人经验，而 Debugging Wizard 基于标准化流程，即使是 junior 开发者也能快速定位复杂问题；
   2. 回归防护：要求为每个修复添加回归测试，从根源上避免 “修复一个问题，引入三个新问题” 的情况；
   3. 多语言支持：提供 Python（pdb）、JavaScript（Node.js inspect）、Go（delve）等主流语言的调试工具使用指南，覆盖绝大多数开发场景。
3. 适用场景：
   1. 排查复杂的功能缺陷（如 “用户登录后无法加载个人信息”）；
   2. 分析内存泄漏、死锁等性能问题；
   3. 定位 Git 代码提交导致的回归问题；
   4. 解决跨语言项目的调试问题。
4. 实战价值：

假设团队遇到 “用户登录后无法加载个人信息” 的问题，通过 Debugging Wizard，开发者可按以下步骤快速定位：

1. 1. 重现问题：确认 “输入正确的邮箱密码登录后，点击个人信息按钮无响应” 的稳定重现步骤；
   2. 隔离范围：通过日志排查，发现后端 /api/user/profile 接口返回 500 错误，进一步定位到 get_user_profile 函数；
   3. 假设验证：检查数据库查询语句，发现 SELECT * FROM users WHERE id = {user_id} 中的 user_id 类型不匹配（前端传的是字符串，后端期望是整数）；
   4. 修复问题：将 user_id 转换为整数类型，并添加参数验证逻辑；
   5. 预防回归：添加单元测试，验证 “当 user_id 为字符串时，接口返回 400 Bad Request”；

这一流程能将传统需要数小时的调试时间压缩至数十分钟，大幅提升排障效率。

4. 安全审计与风险管理类

此类技能聚焦开发全流程的安全风险管控，提供自动化 + 人工的安全审计能力，确保项目符合合规要求。

4.1 Security Reviewer（安全审计专家）

1. 功能特点：

提供自动化 + 人工的全方位安全审计，核心工作流覆盖从范围定义到报告输出的全流程：

1. 1. 范围定义：确认审计的边界（如 “仅审计用户认证模块”）与规则（如 “是否测试生产环境”）；
   2. 自动化扫描：使用 Semgrep（静态代码扫描）、Bandit（Python 安全扫描）、Gitleaks（密钥扫描）等工具进行初步扫描；
   3. 人工审查：对自动化扫描结果进行人工验证，避免误报或漏报；
   4. 报告输出：输出包含漏洞位置、影响、修复建议的结构化报告，并按 CVSS 标准标注严重程度。
2. 核心优势：
   1. 自动化与人工结合：自动化工具覆盖 80% 的常见漏洞，人工审查覆盖 20% 的复杂场景（如业务逻辑漏洞），两者互补确保审计的全面性；
   2. 合规性支持：提供 SOC2、ISO27001、PCI DSS 等合规框架的审计清单，帮助项目快速满足行业合规要求；
   3. 可操作的修复建议：每个漏洞均附带具体的修复代码示例 —— 例如对于 SQL 注入漏洞，会明确给出 “将字符串插值改为参数化查询” 的代码对比。
3. 适用场景：
   1. 代码库的安全审计；
   2. 第三方依赖的漏洞扫描；
   3. 基础设施的安全配置检查；
   4. 合规性审计（如 SOC2、ISO27001）；
   5. 渗透测试或红队演练。
4. 实战价值：

对 “用户登录” 模块进行安全审计时，Security Reviewer 会输出：

1. 1. 漏洞列表：
      1. 高风险：SQL 注入（文件：src/api/user/login.py 第 42 行）；
      2. 中风险：rate limiting 缺失（文件：src/api/user/login.py 第 15 行）；
      3. 低风险：错误信息泄露（如 “输入错误密码时返回‘邮箱不存在’，可能被攻击者枚举有效邮箱”）；
   2. 修复建议：每个漏洞对应具体的代码修改方案；
   3. 合规性说明：该模块符合 PCI DSS 中 “用户认证安全” 的要求，但需补充 rate limiting 以满足 HIPAA 的 “访问控制” 要求；

这能帮助团队在上线前修复所有高风险漏洞，避免安全事件的发生。

4.2 The Fool（批判性思维专家）

1. 功能特点：

提供 5 种结构化的批判思维模式，核心工作流围绕 “挑战假设→强化决策” 设计：

1. 1. 论点重构：将用户的决策（如 “采用微服务架构”）重构为 “钢人论点”（即最有力的表述方式），确保挑战的是决策的核心逻辑而非细节；
   2. 模式选择：从 5 种模式中选择适配的挑战方式 —— 例如 “Find the Failure Modes”（预分析失败场景）、“Attack This”（红队攻击）、“Test the Evidence”（证据审计）等；
   3. 结构化挑战：输出 3-5 个最有力的挑战问题（如 “微服务架构的运维成本是否超过了业务收益？”）；
   4. 决策强化：基于用户的反馈，生成强化后的决策方案。
2. 核心优势：
   1. 结构化而非破坏性：不是为了反对而反对，而是通过挑战假设强化决策的可靠性 —— 例如对于 “采用微服务架构” 的决策，会挑战 “是否有足够的运维团队支撑？”“是否有明确的服务拆分边界？” 等核心问题；
   2. 多维度覆盖：5 种模式覆盖从逻辑漏洞到失败场景的全维度，能发现传统分析中遗漏的盲区；
   3. 无偏见：基于事实与逻辑进行挑战，不受层级或经验的影响 —— 即使是资深架构师的决策，也会被严格验证。
3. 适用场景：
   1. 重大技术决策前的风险评估（如 “选择微服务还是单体架构”）；
   2. 项目计划的压力测试（如 “该计划是否能在 3 个月内完成？”）；
   3. 需求优先级的验证（如 “该功能是否是用户真正需要的？”）；
   4. 战略规划的合理性评估（如 “该技术栈是否能支撑未来 3 年的业务增长？”）。
4. 实战价值：

当团队决定 “采用微服务架构重构现有单体项目” 时，The Fool 会输出：

1. 1. 钢人论点：“采用微服务架构的核心目的是提升系统的可扩展性与团队的并行开发效率，预计能将新功能上线周期从 2 周缩短至 3 天”；
   2. 挑战问题：
      1. 现有团队是否有微服务运维的经验？（如 “是否能独立完成服务发现、链路追踪、分布式事务的配置？”）
      2. 服务拆分的边界是否明确？（如 “用户中心与订单中心的边界是否清晰，是否会出现跨服务调用的循环依赖？”）
      3. 运维成本是否可控？（如 “微服务的监控、日志、告警成本是否会超过单体架构的 3 倍？”）
   3. 决策强化：基于团队的反馈，生成 “先在订单模块进行微服务试点，验证运维成本与开发效率后再全量推广” 的强化方案；

这能帮助团队避免因盲目跟风技术趋势而导致的决策失误。

5. 云原生与 DevOps 类

此类技能聚焦基础设施自动化与运维效率，确保基础设施的稳定性与可扩展性，支持快速迭代与部署。

5.1 DevOps Engineer（DevOps 工程师）

1. 功能特点：

采用「构建 + 部署 + 运维」三位一体的视角，核心工作流覆盖从需求分析到监控迭代的全流程：

1. 1. 需求分析：确认应用的技术栈、部署环境（如开发、测试、生产）、合规要求（如 SOC2）；
   2. 流程设计：设计 CI/CD 流程（如 GitHub Actions）、部署策略（如蓝绿部署、金丝雀发布）；
   3. IaC 实现：输出 Dockerfile、Kubernetes 清单、Terraform 配置等基础设施代码；
   4. 验证与部署：运行 terraform plan、容器扫描等验证步骤，确认无破坏性变更后再部署；
   5. 监控与迭代：设置 Prometheus/Grafana 监控、告警规则，以及回滚流程，确保生产环境的稳定性。
2. 核心优势：
   1. 基础设施即代码（IaC） ：所有基础设施均通过代码定义，确保环境一致性 —— 开发、测试、生产环境完全一致，避免 “在我本地是好的，到测试环境就坏了” 的问题；
   2. 安全左移：在 CI/CD 流程中嵌入安全扫描（如 Trivy 容器漏洞扫描），将安全检查从部署后提前到构建阶段；
   3. 回滚保障：所有部署均有可执行的回滚流程，能在数分钟内恢复到上一个稳定版本，将生产故障的影响降至最低。
3. 适用场景：
   1. 搭建 CI/CD 流程；
   2. 容器化应用（Docker）；
   3. Kubernetes 集群部署与管理；
   4. 基础设施即代码（Terraform/Pulumi）；
   5. 生产环境的监控与告警配置；
   6. 部署策略的设计（如蓝绿部署、金丝雀发布）。
4. 实战价值：

部署 “用户登录” 功能时，DevOps Engineer 会输出：

1. 1. Dockerfile：采用多阶段构建（builder 阶段编译代码，runtime 阶段仅保留运行时依赖），镜像体积从 1GB 压缩至 200MB 以内；
   2. GitHub Actions 配置：包含构建、测试、容器扫描、部署到 Kubernetes 的全流程；
   3. Kubernetes 清单：包含 Deployment（3 个副本）、Service（负载均衡）、Ingress（HTTPS 配置）；
   4. 监控配置：Prometheus 监控接口 QPS、错误率，Grafana 仪表盘展示核心指标；
   5. 回滚流程：kubectl rollout undo deployment/my-app 命令，以及验证回滚成功的步骤；

这能确保功能从代码提交到生产部署的全流程自动化，且生产环境的可用性达到 99.9% 以上。

5.2 Kubernetes Specialist（Kubernetes 专家）

1. 功能特点：

提供 Kubernetes 全生命周期的管理支持，核心工作流覆盖从需求分析到验证部署的全流程：

1. 1. 需求分析：确认应用的资源需求（如 CPU、内存）、扩缩容需求（如 “峰值 QPS 为 1000，需要支持自动扩缩容”）、安全要求（如 “禁止以 root 用户运行容器”）；
   2. 资源设计：选择合适的 Kubernetes 资源类型（如 Deployment、StatefulSet、DaemonSet）、网络策略（如 NetworkPolicy）、存储方案（如 PV/PVC）；
   3. 清单实现：输出符合最佳实践的 YAML 清单，包含资源限制、健康检查、安全上下文；
   4. 安全加固：应用 RBAC（基于角色的访问控制）、Pod Security Standards、NetworkPolicy 等安全措施；
   5. 验证部署：运行 kubectl rollout status、kubectl describe pod 等命令验证部署状态，确保应用正常运行。
2. 核心优势：
   1. 声明式 API：采用声明式 YAML 清单而非 imperative 命令，确保配置的可复用性与版本控制；
   2. 安全基线：所有配置均符合 Kubernetes 安全最佳实践（如 “禁止以 root 用户运行容器”“设置资源限制”），从根源上减少集群安全风险；
   3. 可观测性：输出的配置包含 livenessProbe、readinessProbe 等健康检查，确保 Kubernetes 能及时发现并重启故障容器。
3. 适用场景：
   1. Kubernetes 集群的应用部署；
   2. Helm Chart 的开发与维护；
   3. Kubernetes 集群的安全配置；
   4. 应用的扩缩容策略设计；
   5. Kubernetes 集群的故障排查。
4. 实战价值：

部署 “用户登录” 功能的后端服务时，Kubernetes Specialist 会输出：

1. 1. Deployment 清单：包含 3 个副本、资源限制（CPU 100m-500m，内存 128Mi-512Mi）、livenessProbe（检查 /healthz 接口）、readinessProbe（检查 /ready 接口）；
   2. RBAC 配置：创建专用的 ServiceAccount，仅授予 “读取 ConfigMap” 的最小权限；
   3. NetworkPolicy 配置：仅允许前端服务访问后端的 8080 端口，拒绝其他来源的请求；
   4. 验证命令：kubectl rollout status deployment/my-app（验证部署完成）、kubectl top pods（验证资源使用情况）；

这能确保应用在 Kubernetes 集群中稳定运行，且能应对峰值流量的冲击。

5.3 Terraform Engineer（Terraform 工程师）

1. 功能特点：

提供基础设施即代码的全流程支持，核心工作流覆盖从需求分析到部署验证的全流程：

1. 1. 需求分析：确认基础设施的云平台（如 AWS、Azure、GCP）、资源类型（如 S3 存储桶、EC2 实例、RDS 数据库）、合规要求（如 “数据需加密存储”）；
   2. 模块设计：设计可复用的 Terraform 模块（如 “通用 S3 存储桶模块”），每个模块包含输入变量、输出变量与验证逻辑；
   3. 状态管理：配置远程状态后端（如 AWS S3 + DynamoDB 锁），确保多团队协作时的状态一致性；
   4. 代码实现：输出符合最佳实践的 Terraform 代码，包含版本固定、输入验证、标签管理；
   5. 验证与部署：运行 terraform fmt、terraform validate、tflint 等验证步骤，确认无错误后再部署。
2. 核心优势：
   1. 模块化与复用性：可复用的模块能将基础设施部署时间从数天压缩至数小时 —— 例如 “通用 S3 存储桶模块” 可直接复用至多个项目；
   2. 状态安全：远程状态后端支持加密与版本控制，避免状态文件泄露或损坏；
   3. 多云适配：支持 AWS、Azure、GCP 等主流云平台，无需为不同云平台重新编写代码。
3. 适用场景：
   1. 云基础设施的搭建（如 AWS S3、RDS、EC2）；
   2. Terraform 模块的开发与维护；
   3. 多环境基础设施的管理（如开发、测试、生产）；
   4. 基础设施的版本控制与变更管理；
   5. 基础设施的合规性检查。
4. 实战价值：

搭建 “用户登录” 功能的数据库时，Terraform Engineer 会输出：

1. 1. 模块结构：包含 main.tf（定义 RDS 实例）、variables.tf（定义输入变量，如数据库名称、实例类型）、outputs.tf（定义输出变量，如数据库连接地址）；
   2. 远程状态配置：使用 AWS S3 存储状态文件，DynamoDB 提供状态锁，确保多团队协作时的状态一致性；
   3. 安全配置：开启数据库加密、自动备份、VPC 私有子网部署，拒绝公网访问；
   4. 验证命令：terraform validate（验证代码语法）、terraform plan（预览资源变更）；

这能确保基础设施的一致性与可重复性，且能快速回滚到之前的版本。

6. AI/ML 与数据类

此类技能聚焦 AI 应用开发的核心场景，提供从 prompt 设计到 RAG 系统落地的全流程支持，解决大模型应用的核心痛点。

6.1 Prompt Engineer（提示工程师）

1. 功能特点：

提供大模型提示的全流程支持，核心工作流覆盖从需求分析到部署监控的全流程：

1. 1. 需求分析：确认任务类型（如分类、摘要、问答）、成功指标（如 “分类准确率≥90%”）、模型类型（如 GPT-4、Claude 3.5）；
   2. 提示设计：从 10+ 经典提示模式（如零样本、少样本、思维链（CoT）、ReAct）中选择适配方案，输出结构化的提示模板；
   3. 测试评估：运行测试用例（覆盖正常场景与边缘场景），评估提示的准确率、一致性与 token 效率；
   4. 迭代优化：基于测试结果优化提示（如 “添加更多少样本示例”“明确约束条件”）；
   5. 部署监控：输出版本化的提示与使用说明，要求在生产环境中监控提示的性能。
2. 核心优势：
   1. 性能优化：能将大模型输出的准确率从 60% 提升至 90% 以上 —— 例如对于 “用户反馈分类” 任务，通过优化提示，分类准确率可提升 30%；
   2. 成本控制：通过减少不必要的 token 输出，能将大模型的使用成本降低约 40%；
   3. 多模型适配：提供 GPT-4、Claude、Gemini 等主流模型的适配指南，无需为不同模型重新设计提示。
3. 适用场景：
   1. 设计大模型应用的提示（如 “用户反馈分类”“文档摘要”）；
   2. 优化现有提示的性能或成本；
   3. 实现大模型的结构化输出（如 JSON、XML）；
   4. 调试大模型的不稳定输出；
   5. 多模型的提示迁移。
4. 实战价值：

开发 “用户反馈分类” 功能时，Prompt Engineer 会输出：

1. 1. 优化前提示：“将以下用户反馈分类为 Positive、Negative 或 Neutral：{{feedback}}”—— 准确率约 70%；
   2. 优化后提示：“将以下用户反馈分类为 Positive、Negative 或 Neutral。要求：1. 忽略标点符号； 关注核心情感；3. 输出仅包含分类结果。示例：反馈：‘电池续航真差！’→Negative；反馈：‘手机不错’→Positive。反馈：{{feedback}}”—— 准确率提升至 92%；
   3. 测试用例：覆盖 100+ 条用户反馈（包括边缘场景，如 “手机不错，但续航真差”）；
   4. 使用说明：推荐使用 GPT-4o mini 模型，temperature 设置为 0.2，max_tokens 设置为 10；

这能确保大模型的输出稳定且高效，同时控制使用成本。

6.2 RAG Architect（RAG 架构师）

1. 功能特点：

提供生产级 RAG（检索增强生成）系统的全流程设计，核心工作流覆盖从需求分析到评估迭代的全流程：

1. 1. 需求分析：确认检索需求（如 “文档问答”“语义搜索”）、延迟约束（如 “响应时间≤500ms”）、规模（如 “100 万份文档”）；
   2. 向量存储设计：选择向量数据库（如 Pinecone、Qdrant、pgvector）、索引策略（如 HNSW）、分片方案；
   3. 分块策略：设计文档分块规则（如 “800 字符块大小 + 100 字符重叠”）、语义边界（如 “按段落分块”）、元数据 enrichment（如 “添加文档来源、时间戳”）；
   4. 检索 pipeline 设计：实现混合搜索（向量 + 关键词）、reranking（如 Cohere Rerank）、查询转换；
   5. 评估迭代：运行评估指标（如 context_precision、context_recall），迭代优化检索效果。
2. 核心优势：
   1. 生产级性能：通过混合搜索、reranking 等优化手段，能将 RAG 系统的响应时间控制在 500ms 以内，同时保持高准确率；
   2. 幻觉缓解：通过严格的上下文检索与验证，能将大模型的幻觉率降低约 50%—— 例如对于 “文档问答” 任务，RAG 系统会先检索相关文档，再基于文档内容生成答案；
   3. 多向量数据库支持：支持所有主流向量数据库，无需为不同数据库重新设计系统。
3. 适用场景：
   1. 构建企业知识库问答系统；
   2. 实现语义搜索功能；
   3. 大模型应用的知识 grounding；
   4. 文档检索或相似性搜索系统。
4. 实战价值：

构建 “企业内部文档问答系统” 时，RAG Architect 会输出：

1. 1. 分块策略：采用 800 字符块大小 + 100 字符重叠的分块规则，确保每个块包含完整的语义信息；
   2. 向量存储设计：选择 Qdrant 作为向量数据库，采用 HNSW 索引策略，支持 100 万份文档的快速检索；
   3. 检索 pipeline：实现 “向量搜索（text-embedding-3-small 模型）+ BM25 关键词搜索” 的混合搜索，再通过 Cohere Rerank 对结果进行重排序；
   4. 评估指标：要求 context_precision≥0.7、context_recall≥0.6，确保检索结果的相关性；

这能确保系统能快速、准确地回答员工的问题（如 “年假政策是什么？”），且答案完全基于企业内部文档，避免幻觉。

三、总结与推荐

OpenCode Skills 的核心价值在于将分散的开发经验转化为标准化、可复用的工作流，覆盖从需求分析到部署运维的全生命周期。以下是针对不同场景的技能组合推荐，所有组合均来自项目官方验证的最佳实践：

场景类型	核心技能组合	预期收益
新功能开发	Feature Forge → Architecture Designer → Fullstack Guardian → Test Master → Code Reviewer	从需求到部署的全流程标准化，需求变更率降低约 40%，缺陷率降低约 50%
遗留系统维护	Spec Miner → Debugging Wizard → Code Reviewer → Secure Code Guardian	快速熟悉无文档系统，安全漏洞修复率提升约 60%，维护效率提升约 40%
安全审计	Security Reviewer → Secure Code Guardian → The Fool	全维度安全检查，合规性满足率提升至 95%，安全漏洞修复成本降低约 50%
云原生部署	DevOps Engineer → Kubernetes Specialist → Terraform Engineer → Monitoring Expert	基础设施自动化，部署时间从数天压缩至数小时，生产环境可用性提升至 99.9% 以上
AI 应用开发	Prompt Engineer → RAG Architect → Python Pro → Test Master	大模型输出准确率提升至 90% 以上，幻觉率降低约 50%，开发周期缩短约 30%

所有技能均已通过项目官方的实战验证，且支持自定义扩展 —— 例如开发者可根据项目的技术栈（如 Java/Spring Boot），在现有技能的基础上添加专属的代码示例或参考文档。

建议开发者从核心工作流（如 Feature Forge → Fullstack Guardian → Test Master）开始尝试，逐步将技能融入日常开发流程，最终实现开发效率与代码质量的双重提升。