🧠 氛围检查MCP服务器

也可以在以下平台找到Vibecheck：mcpservers.org、Glama.ai、mcp.so

当你的AI无法自我质疑时，它内心的橡皮鸭。

什么是氛围检查？

在**"氛围编程"**时代，AI代理现在拥有惊人的能力，但问题已经转变为：

从

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

变成

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

它提供了AI代理目前所缺乏的关键"等等...这不对"时刻：一个内置的自我纠正监督层。它是氛围编码者的终极理智检查MCP服务器：

通过实施战略性模式中断来防止AI工作流中的级联错误。
使用工具调用"氛围检查"与LearnLM 1.5 Pro（Gemini API），针对教学和元认知进行微调，以增强复杂工作流策略，并防止隧道视觉错误。
实施"氛围提炼"以鼓励计划简化，防止过度设计解决方案，并最小化代理中的上下文漂移。
自我改进的反馈循环：代理可以将错误记录到"氛围学习"中，以提高语义回忆，并帮助监督AI随着时间的推移针对模式进行改进。

TLDR；实施一个经过微调的代理，在它自信地实施错误之前停下来重新考虑。

问题：模式惯性

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

你："解析这个CSV文件"

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

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

这种模式惯性导致：

🔄 隧道视觉：你的代理陷入一种方法中，无法看到替代方案
📈 范围蔓延：简单的任务逐渐演变成企业级解决方案
🔌 过度设计：为不需要它们的问题添加抽象层
❓ 不对齐：解决的是与你要求的问题相邻但不同的问题

功能：元认知监督工具

氛围检查通过三个集成工具为你的代理工作流添加了一个元认知层：

🛑 vibe_check

模式中断机制，通过元认知质疑打破隧道视觉：

vibe_check({
  "phase": "planning",           // 规划、实施或审查
  "userRequest": "...",          // 完整的原始用户请求 
  "plan": "...",                 // 当前计划或想法
  "confidence": 0.7              // 可选：0-1的置信度级别
})

⚓ vibe_distill

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

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

🔄 vibe_learn

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

vibe_learn({
  "mistake": "...",              // 错误的一句话描述
  "category": "...",             // 来自标准类别
  "solution": "..."              // 如何纠正的
})

氛围检查的实际应用

使用氛围检查之前：

Claude在歧义的情况下假设了MCP的含义，导致所有后续步骤都有这个错误的假设

使用氛围检查之后：

调用氛围检查MCP，指出歧义，迫使Claude承认这种信息的缺乏并主动解决它

安装与设置

通过Smithery安装

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

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

手动安装（推荐）

# 克隆仓库
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文档，请参阅技术参考。

架构

元认知架构（点击展开）

氛围检查实现了一个基于递归监督原则的双层元认知架构。关键见解：

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

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

氛围检查的实际应用（继续）

VC1

验证

文档

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

贡献

我们欢迎对氛围检查的贡献！无论是错误修复、功能添加还是仅仅改进文档，请查看我们的贡献指南开始。

许可证

MIT