未来的vibe-coding将不再是关于如何编写代码，而是关于如何有效地编排这些各具特色的智能模型和工具。
AI工具更新的速度让人应接不暇，有些东西会可能昙花一现，有些会给人们的协作方式带来深刻变化，所以我认为不必带有焦虑感，让子弹飞一会儿。2025年末许多AI编程创新的方式集中爆发，是多年经验积累的结果。AI编程（vibe-coding）给我带来的最大收获远不止在工具升级带来的效率，而在于思维方式的升级；如果想驾驭琳琅满目的AI模型发挥他们的价值，你不得不学习一整套科学的方法论，而这套东西开始从对技术的理解转移到了管理思维与认知方式上了。接下来以我的研究历程来举例说明。
skill-creator
最近skill很火，一句话来说它就是结构化的提示词，可以帮助AI按照既定流程去操作，以及在什么环节调用哪些工具等等，这种感觉有点像提示词版的函数，使得输出更加可控=>可靠，没有看到让人眼前一亮的新技术。其实跟很多其他的新工具一样，在大模型强大的上下文能力以及分析逻辑能力下搭建起来的生态，比如coworker，clawdcode应该都是给AI提供了各种MCP接口和工具调用，本质上都是提示词与AI对话完成的。
后来我的感受是自己亲自去写完整的提示词非常费时，且上下文的约束太重要了，于是我尝试寻找优秀的skill模板整合到我自己的项目中去。通过调用gh grep mcp，我在GitHub上发现了很多整理各种技能的优秀代码库。其中一些技能对我的工作方法有很大启发，以下是几个代表性的例子：brainstorming、skill-creator和测试驱动开发（TDD）。
- skill-creator是在我学习skill这个概念时让我AI写过一版，而别人的版本显然更出色。我很喜欢这些结构化模板中的清晰逻辑，什么该做什么不该做，怎么做，步骤123，格式要求 etc..每次阅读都是一种享受。
- 另一个是brainstorming，这是一项我之前没想到的技能。在思考一些自己也不知道答案的问题时，它会不断提问，引导我思考，人机协作探索方案。这个思维框架确实有效，但对智能模型的思考能力要求较高，同时需要开放的心态和清晰的逻辑。
- 测试驱动开发（TDD），以前我对此感到畏惧，因为我没有系统学习过软件开发，也不愿意在工作中去写这些测试工具。尽管测试工作比较麻烦，但它确实需要，有skill来测试不确定的AI代码无疑是个好工具。
/whichmodel
Tell me your current model name and model ID in the format: provider/model
接下来研究一下一直困扰我的问题，应该用哪个模型，主流模型几十种，每天都会有新的排名发布，每个模型也有自己的特色，当然对于vibe-coding来说，模型的代码能力如长上下文、擅长信息收集和工具调用是最重要的，但是对于个人用户而言，成本也不得不考量，就像文章开头提到让子弹飞一会儿，不建议一个模型刚发布出来就冲上去买个年费会员，而是深度使用一段时间去感受，对于模型的吐槽和个人看法以后再聊，这里则重点介绍一下我对model variant 模型变体的探索收获。
five role variants
前一篇关于spec-coding的介绍以及上方skill的讨论可以看出规范专业的工作流程是AI编程的灵魂，于是这里面涉及到多个角色的扮演。每个处理步骤对模型的能力要求都有不同的侧重，除了在提示词中要求大模型考虑去扮演不同的角色，我们也可以对模型的能力进行参数配置。
在一开始学习MML大模型接口调用时就了解到里面除了提供提示词信息角色信息以外，还有一些参数设置：
temperature = 0.7 # 温度参数，控制随机性 温度越高越随机
top_p = 0.8 # 数值高低决定控制采样，决定文字输出的多样性
max_tokens = 100 # 最大输出长度
enable_thinking = False # 思考模式，而现在已经可以支持思考深度
不同角色所要求的风格，可以通过这些参数的不同搭配组合而实现，于是我根据自己的调用经验以及大模型提供的经验，首先整理了一下自己开发常用的几个步骤，并为不同步骤配置了5个变体（角色），每个变体都有详细的参数配置。
比如对于brainstorming这个环节，就需要AI发散型、探索式、低约束；真正进行计划的时候就需要收敛、决策式、结构化的风格；而工程实现的过程就不太需要过多思考，执行第一；对于检查环节则需要否定性、审计式、高确定性。这多么像在团队中不同部门角色的风格差异啊。这个宏观团队视角在我们日常工作的细节中是很少有去思考的，我们的日常工作容易被卷入细节中去。
工作流梳理表格
| 阶段 | ROLE | 核心环节 | 步骤说明 (Actions) | 关键产出/目的 |
| 1. Plan (规划) | explorer | Brainstorming | 基于需求进行发散性讨论，确定功能边界。 | 明确“要做什么” |
| designer | Initial Proposals | AI 根据上下文给出技术实现方案。 | 项目计划初稿 | |
| designer | Feasibility Check | 评估 AI 方案的性能、复杂度及技术栈一致性。 | 确认方案在现实中可行 | |
| refiner | Review & Refine | 人机协作微调方案，确定最终执行蓝图。 | 最终的实现蓝图 (Blueprint) | |
| 2. Build (构建) | coder | Initial Build | 搭建基础骨架或生成核心业务逻辑。 | 基础代码实现 |
| reviewer | Review & Diff | 严格对比 AI 生成代码与旧代码的差异 (Diff Check)。 | 防止意外覆盖原有功能 | |
| refiner | Unit Test Gen | 强制要求 AI 生成配套测试用例 (TDD 模式)。 | 用测试验证生成的准确性 | |
| 3. Verify (验证) | reviewer | Find Bugs | 深度排查逻辑漏洞、并发风险或安全隐患。 | 提升系统鲁棒性 |
| designer | Optimization | 对生成的代码进行性能压测建议或算法重构。 | 确保运行效率 | |
| refiner | Doc Update | AI 自动更新 README、注释或 Swagger/API 文档。 | 保证文档与代码同步 |
EXPLORER, DESIGNER, CODER, REVIEWER, REFINER
下图是我让gemini根据我对5个变体的定义设计的图片, 不得不说拟人化形象很生动到位
这5个角色的名称定义其实还是狭隘了点，因为相当于人为主观的去贴了一个标签，标签方便人们更加简单粗暴的去理解事物，但其实我是反对贴标签的，包括生活中对人和事物，因为它限制了我们对一个东西的想象空间，以及忽略了它的拓展性。不管什么样的标签，容易让人先入为主。
为了防止标签化对AI的判断也产生影响，生成这5个角色的过程我没有先给他们取了名字，而是提供了一套我预想的相关参数配置以及对应编号A-E 和 工作流描述丢给不同的AI去分析去匹配，我找了GPT, GEMINI, MINIMAX, QWEN, GLM这几个常用的模型，基本问了个遍。结合AI匹配的结果去对比，对于分歧较大的则反问为何不用另外一个，最终我结合自己的工作场景去确定了答案。
复杂程度
有些步骤的确容易产生明显的分歧，比如优化代码这个环节应该用designer还是refiner，其实正常来讲这个环节可以单独提一个项目出来走一个完整流程，这样看来designer的开放性以及顾全大局就比较重要，而如果只是小的改动在评估环节直接优化，refiner的专注风格就更适合；再比如在TDD unit test阶段，我是希望检查全局发现一些难以发现的漏洞还是说提高效率对一些地方死磕到底，是希望他简单直接执行还是过度思考，完全取决于项目的复杂程度。
暂时性方案？
以上可以发现对不同工作流的variant调用并非一件简单的事情，这就是为什么我将variant控制在了5个比较具有代表性常用风格，而不是针对每个工作环节配置一个，当然这也降低了我的选择难度。一开始我也想过，这么重要的参数配置为何不能在AI接收到prompt提示词后自主根据任务性质去自动匹配呢，如此自然是最好的，我也咨询过AI，好像还没能做到；
原因从上面的复杂程度介绍可以感受到这是一个偏主观和需求的活，好比你是诸葛亮，你派谁去守街亭，参考的东西是将领过去的表现，还是整体的战略考量，还是对手的优点弱点，这里都没有唯一答案，但是我相信AI有一天能够做到整体的战略战术思考判断，但人类是否能够信任又会是个问题。这里就点到开头提到的，AI给我带来的不仅是工具而已，运用工具的过程中所不得不思考的内容才是最有价值的地方。
发表回复