用四个 Skills 组合掌控 AI 开发：从需求到代码的自动化流程
为什么我们需要 Skills 而不仅是提示词
很多开发者刚开始用 AI 写代码时，习惯在聊天窗口里扔一大段提示词。起初还行，但随着项目变大，上下文窗口不够用了，AI 开始遗忘之前的约定，或者生成的代码风格忽左忽右。这时候，单纯的“提示词工程”就显得力不从心。
OpenCode 这类终端 AI Agent 引入的 Skills（技能）概念，本质上是一种结构化的能力封装。它不是简单的文本模板，而是包含元信息、执行步骤和边界约束的文件模块。通过 Skills，我们可以把复杂的开发任务拆解成标准化的流水线：产品定义、UI 设计、代码实现。每个环节由专门的 Skill 负责，AI 不再是漫无目的地闲聊，而是在既定的轨道上执行具体指令。
这种模式的核心价值在于“可控性”。我们不再依赖 AI 的随机发挥，而是通过预设的 Skill 逻辑，强制 AI 遵循特定的工作规范。比如，让“产品经理”Skill 必须追问清楚输入输出，让“设计师”Skill 必须参考具体的配色指南。下面我将通过一个“音乐可视化机器人”的实际开发案例，拆解这套由四个 Skills 组成的工作流。
核心架构：四个 Skills 的分工协作
在这个工作流中，我们定义了四个关键角色，它们对应 OpenCode 项目 .opencode 目录下的四个 Skill 文件，并由根目录的 AGENTS.md 作为主控调度器进行协调。
1. product-spec-builder（毒蛇产品经理）
这个 Skill 的角色设定非常鲜明：它不接受模糊的需求。当你提出一个想法时，它会像一位严厉的产品经理一样，不断追问细节。比如，“用户输入是什么？”“异常情况下怎么处理？”“业务规则有哪些限制？”
它的输出产物是 Product-Spec.md 和变更记录。这份文档不是那种充满空话的 PPT，而是包含具体功能点、数据结构和交互逻辑的技术规格书。只有当这份文档足够清晰，后续的开发才能避免返工。
触发指令：/prd
2. ui-prompt-generator（UI 提示词设计师）
有了产品规格书，下一步是视觉化。这个 Skill 负责阅读 Product-Spec.md，提炼核心功能页面，并生成用于绘图或前端实现的 UI 提示词。它会考虑视觉风格、配色方案，并输出 UI-Prompts.md。
这一步的关键在于将抽象的功能描述转化为具体的视觉语言。比如，将“播放音乐”转化为“带有动态波形图的播放控件，采用玻璃态风格”。
触发指令：/ui
3. ui-ux-pro-max（UI/UX 设计智能）
这是解决 AI 生成界面“塑料感”的神器。很多 AI 写的界面虽然能跑，但配色俗气、布局僵硬。ui-ux-pro-max 内置了 50 种 UI 风格指南（如玻璃态、极简主义、暗黑模式）、21 种专业配色方案、50 种字体配对以及针对 React、Vue 等主流技术栈的最佳实践。
它在开发阶段介入，确保生成的代码符合现代审美和用户体验标准。它不仅仅是一个样式库，更是一套设计决策系统，告诉 AI 为什么这里要用留白，那里要用阴影。
触发指令：/dev（配合设计上下文）
4. dev-builder（全栈开发工程师）
最后一步是落地。dev-builder 读取前面的产品文档和设计提示词，搭建项目结构，编写核心代码。它负责选择合适的技术栈，集成必要的 API（如 OpenAI、Gemini 等），并确保代码的可维护性。
这个 Skill 的重点在于“完整性”。它不仅写组件，还处理路由、状态管理和错误边界。它知道如何把前三个环节的输出拼成一个可运行的应用。
触发指令：/dev 或 /run
实战演练：开发一个音乐可视化机器人
为了展示这套流程的威力，我们来做一个稍微有点挑战的项目：一个能根据音频歌词自动生成人物演唱动画的音乐机器人。需求包括：音频歌词识别、人物口型同步、表情变化和肢体动作。
第一步：安装与配置
首先，你需要安装 OpenCode。在 macOS 或 Windows 终端中运行：
curl -fsSL https://opencode.ai/install | bash
# 或者通过 npm 全局安装
npm i -g opencode-ai安装完成后，进入项目目录。为了获得更好的推理能力和代码生成质量，我选择了 GLM-4.7 模型。在 OpenCode 终端中，使用 Ctrl + P 切换模型。当然，你也可以根据喜好选择 Grok Code 或其他支持 Function Calling 的模型。
第二步：启动“毒蛇产品经理”
在终端输入 /prd，激活 product-spec-builder。
我输入初始想法：“我想做一个音乐视觉效果应用，根据音频输入和歌词演唱，生成一个自动演唱的动画人物，包括口型、表情和肢体动作。”
AI 没有直接给代码，而是开始追问：
- “音频来源是本地文件还是实时麦克风输入？”
- “人物形象是 2D 还是 3D？是否有预设模型？”
- “口型同步的精度要求是多少？是否需要考虑延迟？”
- “API 配置方面，你打算用哪个模型做视觉分析，哪个做歌词识别？”
经过几轮交锋，我们确定了技术方案：使用 Qwen3-VL-Plus 进行视觉动作分析，使用 Gemini 2.5 Pro 进行音频歌词识别。最终，product-spec-builder 生成了详细的 Product-Spec.md，明确了数据流向和接口定义。
第三步：生成 UI 提示词
接着输入 /ui，激活 ui-prompt-generator。它读取刚才生成的规格书，提取出“播放器界面”、“人物展示区”、“歌词同步显示区”等核心模块。它建议采用“赛博朋克”结合“极简主义”的风格，以突出科技感，同时保持界面整洁。生成的 UI-Prompts.md 详细描述了每个组件的视觉特征，比如“半透明的黑色背景”、“霓虹蓝色的波形图”。
第四步：UI/UX 增强与代码实现
现在进入开发阶段。输入 /dev，此时 ui-ux-pro-max 和 dev-builder 协同工作。
ui-ux-pro-max 首先介入，它检查了 UI-Prompts.md 中的描述，并应用了内置的“暗黑模式”配色方案和“玻璃态”组件样式。它指出原提示词中对比度不足的问题，并给出了修正后的 CSS 变量建议。
随后，dev-builder 开始编写代码。它基于 Next.js 搭建项目框架，集成了 Qwen3 和 Gemini 的 API 客户端。在处理音频解析部分，它重用了社区成熟的库，而不是从头造轮子。在实现人物动画时，它根据 ui-ux-pro-max 的建议，使用了 Canvas 进行高性能渲染，确保口型同步的流畅性。
整个过程中，AI 没有产生那些常见的“样板代码”，而是直接生成了符合项目架构的业务逻辑。因为它清楚地知道前一步的设计约束和后一步的功能需求。
第五步：运行与验证
代码生成完毕后，运行 /run 启动开发服务器。打开浏览器，上传一首歌曲。可以看到，界面上的虚拟人物随着歌词节奏准确地进行口型匹配和肢体摆动。UI 配色沉稳且富有层次，完全没有早期 AI 生成页面那种刺眼的饱和度和混乱的布局。
这种工作流解决了什么问题？
回顾整个开发过程，Skills 组合带来的改变是实质性的。
首先是上下文的稳定性。传统的对话式开发，随着对话轮数增加，AI 容易忘记最初的需求。而 Skills 通过文件化的方式，将需求、设计、代码分离存储。每次调用 Skill 时，AI 只关注当前环节的任务，同时通过 AGENTS.md 保持全局视角。这就像把一个大型项目拆分成多个微服务，每个服务只关心自己的职责。
其次是质量的标准化。如果没有 ui-ux-pro-max，AI 可能会随机选择颜色，导致界面看起来像十年前的网页。有了这个 Skill，它就必须在规定的 50 种风格和 21 种配色中选择，保证了输出的下限。同样，“毒蛇产品经理”强制我们在编码前理清逻辑，避免了“边写边改”的低效循环。
最后是灵活性与控制权。Skills 是文件形式的，这意味着你可以修改它们。如果你觉得“产品经理”太啰嗦，可以调整它的提示词，让它更简洁；如果你想换一种 UI 风格，只需修改 ui-ux-pro-max 的配置。这种透明度是封闭 IDE 插件无法比拟的。
结语
AI 编程正在从“聊天辅助”走向“代理执行”。OpenCode 的 Skills 机制提供了一种中间形态：既保留了人类对流程的控制权，又利用了 AI 的自动化能力。通过 product-spec-builder、ui-prompt-generator、ui-ux-pro-max 和 dev-builder 这四个技能的组合，我们不仅是在写代码，更是在编排一个高效的数字团队。
对于开发者而言，掌握这套方法的意义不在于记住几个指令，而在于理解如何将复杂任务结构化。当你学会定义清晰的 Skill 边界，AI 就不再是一个不可预测的黑盒，而是一个听话且专业的执行者。未来，随着更多垂直领域 Skills 的出现，这种模块化、自动化的开发模式可能会成为行业标准。