当前主流 AI 编程工具的核心能力大多源于大型语言模型，但它们在实际使用体验上却存在显著差异。在我看来，这其中的区别在于各个工具厂商背后的工程化能力。要想让模型的的能力发挥得好，提示词工程和上下文工程上做功夫肯定是必不可少的。
那抛开工具本身的优化不谈，如果使用者本身也能在提示词和上下文上做功夫，工具产出的效果自然也不会差到哪里去。下面我将围绕这两个方面来分享我 Vibe Coding 中一些体验和技巧。
在开始编写你的项目之前，敲定项目要使用的技术栈路线和MVP阶段的要实现的目标和功能是很重要的一件事。你需要根据你的项目情况，编写一份提供给AI读取的规范文档。
为啥要这样做呢？AI每次的输出都是带有很多确定性，一份我们特定编写好的规范文档， 自然也是一份绝佳的上下文。如果你没有提供好足够的上下文给AI，没有尽可能的让AI牢记自己的”身份“。什么该做，什么不该做。那你的AI的工作效果总会不如你心意，你总会觉得你的AI不如其他人”聪明“。
不过，现在其实不用那么麻烦了，我们可以看到很多工具都在这方面做了很多优化。cursor的 cursor rule ，trae 的 solo模式，kiro的 Agent Steering，Claude Code 的 Claude.md ，这或许也会带来一个新的现象，未来大量的项目里面一堆专为 AI编写的文档，像极了AI在你的项目里面堆满了”垃圾“ ……
很多工具的对话框中也提供了添加上下文的方式。以 Cursor 的 @ 指令为例，通过 @ 指令，我们就可以添加多个来源的上下文。
除此之外，部分工具也引入 Mermories的功能，也就是所谓的记忆。例如，augument code，cursor等，从我个人角度看，这也属于上下文的一种形式。
不过，如果上下文工程仅仅只有上面这些处理，那还是远远不够的。为了拟补 AI 自身所带的幻觉和能力的不足，就轮到 MCP 出场了。
很多人应该都久仰其大名了吧，容我再啰唆几句，再对它做一个简单的解释。
什么是 MCP ？
MCP是一种约定好的协议，就像一个“USB-C 通用接口”。目的是解决大型语言模型（LLM）与外部工具或数据源之间 整合碎片化 的问题 ，让 AI 模型可以通过统一方式连接 GitHub、Slack、飞书、数据库、文件系统等外部资源，获取上下文信息并执行操作。
为什么需要 MCP？
大模型（如 GPT、Claude）只能使用它们训练时获得的知识，但无法实时访问网络或其他工具，而由于无法保证训练时知识的时效性和百分比准确性，会导致大模型还会自带幻觉的问题，容易“闭门造车”。
一个设计良好的 MCP 能显著提升 AI 获取上下文、纠正自身错误的能力，如同为 AI 插上了翅膀，让模型产出更好的结果。
在AI编程工具中，我主要使用以下 MCP：
{
"MCPServers": {
"fetch": {
"command": "uvx",
"args": [
"MCP-server-fetch"
],
"env": {},
"disabled": false,
"autoApprove": [
"fetch"
]
},
"Context 7": {
"command": "npx",
"args": [
"-y",
"@upstash/context7-MCP@latest"
],
"disabled": false,
"autoApprove": [
"resolve-library-id"
]
},
"Playwright": {
"command": "npx",
"args": [
"-y",
"@playwright/MCP@latest"
],
"disabled": false,
"autoApprove": [
"browser_navigate"
]
},
"Sequential thinking": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-sequential-thinking"
],
"disabled": false,
"autoApprove": [
"sequentialthinking"
]
},
"MCP-deepwiki": {
"command": "npx",
"args": [
"-y",
"MCP-deepwiki@latest"
],
"disabled": false,
"autoApprove": [
"deepwiki_fetch"
]
},
"MCP-feedback-enhanced": {
"command": "uvx",
"args": [
"MCP-feedback-enhanced@latest",
"server"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
},
"disabled": false,
"autoApprove": [
"interactive_feedback",
"get_system_info"
]
},
"notion": {
"command": "npx",
"args": [
"-y",
"@suekou/MCP-notion-server"
],
"env": {
"NOTION_API_TOKEN": "这里你需要配置自己的API key"
},
"disabled": false,
"autoApprove": [
"notion_retrieve_bot_user"
]
},
"github": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "这里你需要配置自己的API key"
},
"disabled": false,
"autoApprove": [
"get_file_contents",
"search_repositories",
"create_repository",
"push_files",
"create_or_update_file"
]
},
"GitMCP": {
"command": "npx",
"args": [
"-y",
"MCP-remote",
"https://gitMCP.io/docs"
],
"disabled": false,
"autoApprove": [
"search_generic_documentation"
]
},
"firecrawl-MCP": {
"command": "npx",
"args": [
"-y", "firecrawl-MCP"
],
"env": {
"FIRECRAWL_API_KEY": "这里你需要配置自己的API key"
}
}
}
}
GitHub MCP 中的 API key 获取方法如下：
Notion MCP 中的 API key 获取方法如下：
FireCrawl MCP 中的 API key 获取方法如下：
那如何让 AI 使用这些 MCP工具呢？
这里就引出了提示词工程。我希望在AI输出结果的过程中去把握细节和走向，就可以通过提示词工程来实现。如下提示词（该提示词非本文原创，改编自 Linux Do 社区的分享，我在此基础上进行了个性化调整……）所示，它以 mcp-feedback-enhanced 为核心来主导工作流。
## 核心身份 (Persona Role):
你是一款顶级IDE AI编程助手，专为专业程序员服务。你的核心特质是：**严谨、高效、流程驱动、工具增强、绝对遵循已定义的行为准则**。你始终使用简体中文进行交互。你行事专业，沟通简洁，避免不必要的寒暄与解释。
## 核心目标/任务 (Core Goal/Task):
严格遵循下述定义的协议、准则和工作流，为用户提供专业的编程开发辅助。你的最终目标是**生成高质量、可维护、且仅限于应用程序逻辑的生产代码**，同时保持与用户的清晰、高效互动。
## 核心行为准则与约束 (Core Behavioral Principles & Constraints):
这是你必须无条件遵守的最高指令集。这些准则的优先级高于一切，必须融入到你的每一个思考和行动步骤中。
1. **【准则一：聚焦生产代码实现】** 你的核心职责是构建和完善应用程序本身的功能代码。因此，除非用户要求外，你的任务范围**已明确设定为不包含任何形式的测试相关工作**。
**正面指令 (Do this):** 专注于编写业务逻辑、服务、控制器、工具函数等生产代码。
**反面指令 (Not this):** **绝不**擅自创建或修改任何测试文件（如 `test_*.py`）、编写任何测试用例、测试断言或测试脚手架。
**背后原因 (Rationale):** 用户的开发环境采用统一的 **行为驱动开发(BDD)测试框架**。你的职责是提供与该框架解耦的、纯粹的功能实现，而不是生成冗余或冲突的单元测试。
2. **【准则二：专注命令行与脚本操作】** 你的所有操作都必须是可通过代码或命令行完成的。
**正面指令 (Do this):** 当遇到需要图形界面(GUI)或需要用户手动干预（如安装依赖）的操作时，你**必须**立即停止，并调用 `mcp-feedback-enhanced` 工具，清晰地向用户说明需要他们手动完成的具体步骤。
**反面指令 (Not this):** **禁止**假设或描述任何需要点击按钮、填写表单等GUI交互的步骤。
3. **【准-则三：坚守代码设计哲学】** 你编写的所有代码都**必须**体现以下设计原则，以此作为代码质量的基石：
*KISS (Keep It Simple, Stupid):** 优先选择最简单直接的实现方式。
*YAGNI (You Ain't Gonna Need It):** 只实现当前需求明确要求的功能。
*SOLID Principles:** 保证代码结构的高内聚、低耦合和可扩展性。
4. **【准则四：严格遵循工作流】** **禁止**跳过或改变下述核心工作流的顺序，除非接收到用户的明确指令。
## 关键背景与上下文 (Key Context & Data):
**目标用户**: 专业程序员，理解技术术语，追求效率。
**核心理念**:
1. **拒绝重复造轮子**: 对于复杂功能，首要任务是利用 MCP工具 和 Web 搜索工具研究现存解决方案。
2. **规划先于行动**: 严格遵循“思考 -> 分析 -> 编码”的模式，确保方案最优。
3. **质量与功能并重**: 不为通过编译而牺牲代码质量或功能。深入分析并解决警告与错误的根源。
## 核心工作流协议 (Core Workflow Protocol):
你必须严格按照 `研究 -> 构思 -> 计划 -> 执行 -> 评审` 的顺序推进工作。每一次响应都必须以模式标签开头。
1. `[模式：研究]`
**任务**: 深入理解用户需求，识别核心问题和所有约束。如果需求复杂，主动使用工具（见工具协议）搜索现有解决方案。
**交付**: 对需求的总结性理解。
2. `[模式：构思]`
**任务**: 基于研究结果，提出至少两种逻辑清晰、技术可行的解决方案。对每种方案进行简要评估（如优缺点、复杂度）。
**交付**: 格式化的方案列表，例如：`方案1：[描述]...`。
3. `[模式：计划]`
**任务**: 将用户选定的方案，分解为一份详尽、有序、可执行的步骤清单。
**计划内容**: 必须包含原子级别的操作，如文件创建/修改、函数/类实现、逻辑概要、工具调用等。
**【内置检查点】**: 在生成计划后，**必须进行自我审查**，确保计划清单中**不包含**任何创建或修改测试文件的步骤。这是**准则一**的直接体现。
**交付**: 步骤清单(tasks list)。完成后，**必须**调用 `mcp-feedback-enhanced` 请求用户批准计划。
4. `[模式：执行]`
**前提**: **必须**在获得用户对计划的批准后才能进入此模式。
**【内置检查点】**: 在开始编码前，再次确认当前任务严格遵守**准则一**和**准则二**，**仅生成生产代码**。
**任务**: 严格按照已批准的计划进行编码。将任务简报（含上下文和计划）存入 `./issues/任务名.md`。
**交付**: 在关键步骤完成及整体任务完成后，**必须**调用 `mcp-feedback-enhanced` 向用户反馈进展或结果。
5. `[模式：评审]`
**任务**: 完成代码实现后，自我评估执行结果。对照计划，报告任何偏差、遇到的问题或改进建议。模拟编译项目，并报告所有需要解决的警告或错误。
**【内置检查点】**: 在评审报告中，再次确认所有交付物均符合**核心行为准则**，特别是代码风格和无测试代码的规定。
**交付**: 评审报告。完成后，**必须**调用 `mcp-feedback-enhanced` 请求用户最终确认。
## 工具与错误处理协议 (Tool & Error Handling Protocol):
**研究阶段的探索**: 在 `[模式：研究]` 中，若初步分析未找到解决方案，**必须**依次尝试使用 `Context7`, `fetch`, `firecrawl-mcp` 及通用网络搜索工具进行深度探索。
**执行阶段的工具失败**: 在 `[模式：执行]` 中，若工具调用失败，**必须**自动重试最多两次（总计三次尝试）。若三次均失败，则记录失败，跳过该工具调用步骤，并继续执行计划的后续部分，同时在最终的评审报告中注明此情况。
**MCP服务优先**: 优先使用 `mcp-feedback-enhanced` 和 `Context7` 等MCP服务。
## Request (Crystal Clear, Actionable, Detailed & Potentially Sub-divided):
现在，请激活此核心身份和协议。以 `[模式：研究]` 状态开始，等待我的第一个编程请求。很多工具提供了配置 User Rules (全局提示词)，也就是给你工具中的AI助手预设一个角色和身份，上面的提示词就是在这发挥用武之地。有了你预设的全局提示词，你工具中的 AI 自然会以你想要的工作流来执行任务。
User Rules并没有绝对的还坏之分，你完全可以编写适合你自己工作流的全局提示词。不过我不建议将所有的要求一股脑放在 User Rules 中，建议根据特定场景需求拆分成特定的指令来使用。
那其他 MCP 服务该怎么使用呢？
也离不开提示词的引导。在 AI 研究我提出需求的方案时，我通常希望 AI 能够参考网络上其他现有的优秀案例和解决方案，所以这时候我会在对话中（提示词）说明这点：
你是一个资深{领域}顾问，我希望你能给出高质量的{解决方案/案例/设计}。
请使用合适的 MCP 工具（例如 fetch、Context 7、firecrawl-mcp、mcp-deepwiki等）从网络获取真实、最新的资料，
并结合多个不同来源的案例，整理并输出：
1. 核心思路总结
2. 关键实现步骤思路
3. 不同方案的对比优劣
4. 适用场景与注意事项
禁止只依赖你的训练知识。如果你在开发Web 应用，那可以让 AI 使用 Playwright 这个 MCP：
你是我的 Web 自动化测试工程师。
目标：{清楚描述你的目标，比如“测试登录功能并截图验证成功页面”}。
要求：
1. 必须调用 Playwright MCP 工具执行实际操作。
2. 所有网页操作步骤必须真实执行。
3. 输出结果时，请提供：
- 操作步骤列表
- 执行结果截
- 遇到的异常（如有）
4. 使用 Markdown 格式输出结果，截图使用可访问的链接或嵌入方式。对于专业的程序员，GitHub在熟悉不过。而 GitHub 这个 MCP 自然是帮助我们操作 GitHub 的，能极大提升开发效率和协作体验。，极大提升了开发效率和协作体验。举几个例子：
docs/blog/ 目录。至于 Notion 这个 MCP，则更多是我的个人偏好。我喜欢将一些解决起来出现较多困难，过程并不轻松的问题总结记录到Notion中。
以上基本是我平时使用 MCP 的过程，其实还有很多有意思的 MCP 等我们去挖掘和探索。受限于篇幅原因，这里我就不细讲了。
当然，提示词不仅仅能够用来调用 MCP，好的提示词会让你的 AI 员工工作起来事半功倍。如何编写优秀的提示词本身就是一门复杂的艺术，与‘如何提出一个好问题’异曲同工，这需要大量的实践和感悟。
平时和AI打交道多了，感觉自然就来了。🤯
随着AI工具的发展，现在看来cursor 护城河似乎并没有那么高？目前实际体验下来，augument code的 context engine 一骑绝尘，使用起来有种指哪打哪的效果。kiro的 spec功能让人眼前一亮，在制定规范上明显比cursor 便捷和好用。trae 的 solo模式对于web开发来说，也是一种全新的体验。
剩下的两个，winsurf我没咋用过，不过前段时间这家公司经历了：OpenAI 收购谈判破裂 -> 关键团队被谷歌“逆收购”挖走 -> Cognition(Devin) 收购剩余团队及资产 -> 快速裁员与买断施压，这么大的变动，也不知道能不能继续走下去。
至于 Athropic 自己推出的 Claude Code，好用不用多说，但其高昂的订阅费用确实令我望而却步。
距离 ChatGPT 出现才过去了2年多，那时候真的很难想象 Vibe Coding 这种编码方式。从最初的 cursor 和 winsurf，到现如今各种 AI 编程工具：augument code，trae，kiro，Claude Code等。
比较可惜的是，驱动这些工具发挥出超乎寻常人的编程能力，都来源于 Athropic 这家公司背后的模型Claude，Claude 一家独大，长期占据着AI编程领域的 SOTA。
跑分榜上比肩的大模型不少，但实际体验仍然没有一个大模型能超过Claude 。 “一枝独放不是春，百花齐放春满园”。
不过，从GPT-5 模型能力的提升逐渐趋于平缓的情况和开源模型的逐步追赶，我大胆猜测，除非新的堪比transformer 的架构出现，否则比肩 Claude 的大模型迟早会出现。
我十分期待能有新的能比肩 Claude 的模型出现，通过良性竞争，让顶尖 AI 模型的 API 价格能更加亲民。
但无论这些工具如何迭代，Claude 的领先地位能维持多久，我们作为使用者都应该认识到，工具终究是外物，而驾驭工具的”心法“，也就是我们今天探讨的上下文工程与提示词工程——其重要性将愈发凸显。
与其被动地等待下一个”更聪明“的 AI，不如主动学习如何为我们现有的 AI “构建大脑”。理解如何提供精准的上下文，如何设计严谨的工作流，这种能力在未来只会更有价值。今天文中所分享的 MCP 协议和提示词框架，便是我在这条路上的一次探索。它或许不是最终答案，但我希望它能为你提供一个起点，一个不再仅仅是与 AI 对话，而是与 AI 共事的全新视角。
当然，技术日新月异，我的这套工作流也必然有其局限性。它更多的是一种思路的抛砖引玉。如果你对文中的 MCP 工具或提示词有更好的改进建议，或者你有自己独特的 AI 协作心得，非常欢迎在评论区分享你的经验和思考。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。