MCP 服务器

🧠 Vibe Check MCP

镜子 (jìng zi)

MCP-Mirror

开发者工具

README

🧠 Vibe Check MCP

也可以在以下位置找到 Vibecheck：mcpservers.org, Glama.ai, mcp.so

当你的 AI 无法进行橡皮鸭调试时，它内在的橡皮鸭。

什么是 Vibe Check？

在 “vibe coding” 时代，AI 代理现在拥有令人难以置信的能力，但问题已经转移：

从

“我的 AI 代理真的能完成这个复杂任务吗？”

到

“我的 AI 代理能理解我只想编写一个简单的程序，而不是一个_价值数十亿美元的科技公司的基础设施_吗？”

它提供了 AI 代理目前所缺乏的关键“等等……这不对劲”的时刻：一个内置的自我纠正监督层。它是 Vibe Coder 的权威理智检查 MCP 服务器：

通过实施战略性模式中断来防止 AI 工作流程中的级联错误。
使用工具调用“Vibe Check”与 LearnLM 1.5 Pro (Gemini API) 结合，针对教学法和元认知进行微调，以增强复杂的工作流程策略，并防止隧道视野错误。
实施“Vibe Distill”以鼓励计划简化，防止过度设计的解决方案，并最大限度地减少代理中的上下文漂移。
自我改进的反馈循环：代理可以将错误记录到“Vibe Learn”中，以提高语义召回率，并帮助监督 AI 随着时间的推移定位模式。

TLDR; 实施一个经过微调的代理，以阻止你的代理并在它自信地实施错误的东西之前让它重新考虑。

问题：模式惯性

在 vibe coding 运动中，我们都在使用 LLM 来生成、重构和调试我们的代码。但这些模型有一个关键缺陷：一旦它们开始沿着推理路径前进，即使路径明显错误，它们也会继续前进。

你：“解析这个 CSV 文件”

AI：“首先，让我们实现一个自定义的词法分析器/解析器组合，它可以处理任意的
     CSV 方言，并具有可扩展的架构，以适应未来的文件格式……”

你：*盯着 200 行代码，而你只需要读取 10 行*

这种模式惯性会导致：

🔄 隧道视野：你的代理陷入一种方法，无法看到其他选择
📈 范围蔓延：简单的任务逐渐演变成企业级解决方案
🔌 过度工程：为不需要它们的难题添加抽象层
❓ 错位：解决一个相邻但与你要求的不同的问题

功能：元认知监督工具

Vibe Check 通过三个集成工具为你的代理工作流程添加了一个元认知层：

🛑 vibe_check

模式中断机制，通过元认知提问打破隧道视野：

vibe_check({
  "phase": "planning",           // planning, implementation, or review (计划、实施或审查)
  "userRequest": "...",          // FULL original user request (完整的原始用户请求)
  "plan": "...",                 // Current plan or thinking (当前计划或想法)
  "confidence": 0.7              // Optional: 0-1 confidence level (可选：0-1 的置信度)
})

⚓ vibe_distill

元思考锚点，用于重新校准复杂的工作流程：

vibe_distill({
  "plan": "...",                 // Detailed plan to simplify (要简化的详细计划)
  "userRequest": "..."           // FULL original user request (完整的原始用户请求)
})

🔄 vibe_learn

自我改进的反馈循环，随着时间的推移建立模式识别：

vibe_learn({
  "mistake": "...",              // One-sentence description of mistake (对错误的单句描述)
  "category": "...",             // From standard categories (来自标准类别)
  "solution": "..."              // How it was corrected (如何纠正)
})

Vibe Check 的实际应用

使用 Vibe Check 之前：

before

Claude 假设 MCP 的含义，尽管存在歧义，导致所有后续步骤都具有这个错误的假设

使用 Vibe Check 之后：

after

调用 Vibe Check MCP，并指出歧义，这迫使 Claude 承认缺乏信息并主动解决它

安装与设置

通过 Smithery 安装

要通过 Smithery 为 Claude Desktop 自动安装 vibe-check-mcp-server：

npx -y @smithery/cli install @PV-Bhat/vibe-check-mcp-server --client claude

通过 npm 手动安装（推荐）

# 克隆仓库
git clone https://github.com/PV-Bhat/vibe-check-mcp-server.git
cd vibe-check-mcp-server

# 安装依赖
npm install

# 构建项目
npm run build

# 启动服务器
npm run start

与 Claude 集成

添加到你的 claude_desktop_config.json：

"vibe-check": {
  "command": "node",
  "args": [
    "/path/to/vibe-check-mcp/build/index.js"
  ],
  "env": {
    "GEMINI_API_KEY": "YOUR_GEMINI_API_KEY"
  }
}

环境配置

在项目根目录中创建一个 .env 文件：

GEMINI_API_KEY=your_gemini_api_key_here

代理提示指南

为了实现有效的模式中断，请在你的系统提示中包含以下说明：

作为自主代理，你将：

1. 将 vibe_check 视为关键的模式中断机制
2. 始终在每次调用中包含完整的用户请求
3. 指定当前阶段（计划/实施/审查）
4. 当复杂性增加时，使用 vibe_distill 作为重新校准锚点
5. 使用 vibe_learn 构建反馈循环以记录已解决的问题

何时使用每个工具

工具	何时使用
🛑 vibe_check	当你的代理开始解释待办事项应用程序的区块链基础知识时
⚓ vibe_distill	当你的代理的计划比你的整个技术规范有更多的嵌套项目符号时
🔄 vibe_learn	在你手动将你的代理从复杂性深渊中引导回来之后

API 参考

有关完整的 API 文档，请参阅技术参考。

架构

<details> <summary><b>元认知架构（点击展开）</b></summary>

Vibe Check 实现了基于递归监督原则的双层元认知架构。主要见解：

模式惯性抵抗：LLM 代理在其推理路径中自然表现出类似动量的属性，需要外部干预才能重定向。
相位共振中断：元认知提问必须与代理的当前阶段（计划/实施/审查）对齐，才能实现最大的纠正效果。
权威结构集成：必须明确提示代理将外部元认知反馈视为高优先级中断，而不是可选建议。
锚压缩机制：复杂的推理流程必须提炼成最小的锚链，才能作为有效的重新校准点。
递归反馈循环：必须存储和利用所有观察到的错误步骤，以构建纵向故障模型，从而提高中断效果。

有关底层设计原则的更多详细信息，请参阅哲学。 </details>

Vibe Check 的实际应用（续）

VC1

文档

文档	描述
代理提示策略	代理集成的详细技术
高级集成	反馈链接、置信度等等
技术参考	完整的 API 文档
哲学	Vibe Check 背后的更深层次的 AI 对齐原则
案例研究	Vibe Check 在实际应用中的真实示例