OpenCode四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 冒出来，这种模块化、自动化的开发模式说不定会变成行业标准。