原创 Sanlang 2025-05-05 19:27 广东
少年啊，你也渴望成为超级个体吗？本文成分复杂，轻易不建议阅读
过去一年多，我深度投身于探索如何与 AI 进行编程协作。这趟旅程充满了惊喜、挫折，也沉淀了不少思考。回望这段经历，我想分享一些真实的观察和感悟，特别是关于如何引导 AI、应对其局限性，以及对当前热门的 MCP等概念的实践体会。
一、AI 编程是一个健忘的实习生
最初接触 AI 编程工具时，我很快意识到一个形象的比喻或许最为贴切：这就像是在带一个实习生。实习生有潜力，能干活，但最显著的特点是——你需要手把手地教。你不能指望他凭空领悟你的意图，更不能奢求他拥有丰富的项目经验以及猜中你的那些没说出口的小心思。
然而，AI 这个“实习生”还有一个更棘手的特性：它几乎没有我们人类意义上的“记忆力”或“经验积累”能力。它的基础能力似乎被锚定在了某个训练完成的水平上。无论你感觉自己“教”会了它多少东西，下一次面对类似问题时，如果你不提供同样精准、细致的引导，它依然会回到“出厂设置”状态。
这就引出了与 AI 协作的第一个核心挑战：如何有效地“教”？ 实践告诉我，给 AI 宽泛的原则或模糊的目标几乎是徒劳的。对于 AI 来说太过抽象。它需要的是极其具体、明确、按部就班的操作指令。你必须像编写一份详尽的操作手册一样，告诉它第一步做什么，第二步做什么，遇到什么情况应该如何处理。
当 AI 写的代码出现问题，麻烦才真正开始。和传统的重新跑一张图片，一个 5S 视频不同，AI Coding的结果有效性，需要进行测试，而每次 AI Coding 基本都会带来错误，在 Agent 模式下，他能花上几十分钟，慢慢帮你排障，他结束任务了，仍然看到红通通的部分错误。 所以面对 AI 产生的错误， 是应该尝试让 AI 基于错误信息继续修改（这很可能引入新的），还是选择自己撸起袖子手动介入？根据我的经验，后者往往是更常见且无奈的选择。你不得不花费大量时间去理解 AI 生成的代码，修正其中的逻辑缺陷或低级错误，然后才能知道本次跑的代码是否符合预期。
这种反复调试、重试的循环成本极高。你花费精力调整了 AI 的代码，运行，发现依然跑不起来，或者表现不符合预期。然后你再次尝试调整指令，或者进一步手动修改，再次运行……
这个过程不仅消耗时间，更是一种深不见底的心力损耗。最折磨人的，并非简单的失败，而是 AI 那难以捉摸的、时灵时不灵的表现。你投入大量精力，细致地引导、修正，满心以为这次总该对了，甚至偶尔它真的能“灵光一现”，给出一个漂亮的结果，那一瞬间的惊喜，让你觉得所有的投入都值了，仿佛“单抽出奇迹”。
但这种“好运”往往转瞬即逝。更多的时候，是你在投入了巨大期待后，迎来的却是它再一次的匪夷所思的错误、逻辑的原地绕圈，甚至是引入更隐蔽的缺陷。你感觉自己就像在一个永远看不到尽头的循环里，每一次满怀希望的尝试，都可能重重摔回失望的谷底。
这种反复的拉扯，让你情绪像坐过山车一样起伏不定。从看到希望的兴奋，到遭遇失败的沮丧，再到对下一次尝试既期待又恐惧的矛盾心理，最后往往只剩下一种深深的疲惫和无力感。你开始怀疑，这究竟是在利用智能，还是在进行一场结果极其不确定的“豪赌”？付出的时间和心力，远超传统调试，其精神上的消耗，甚至比沉迷概率极低的抽卡游戏还要令人焦虑和空虚。你甚至会对 AI 暴怒，就因为你知道它不会还嘴，你只会宣泄你的一切。
二、不要盲目的信赖 Agent
面对这些挑战，我逐渐摸索出一些更有效的协作模式。核心在于提供精准的指令和充分、高质量的上下文。
对于小型、边界清晰的任务，比如编写一个独立的函数、修复一个明确的 Bug，AI 确实能展现出不错的效率。你可以给它相对明确的输入输出要求，让它在可控范围内“折腾”。在这种情况下，它有一定概率能直接给出可用的代码。
但对于大型、复杂的任务，比如在现有复杂应用中开发一个全新的模块，情况就完全不同了。仅仅依赖简单的规则或通用的指导使用 Agent 是远远不够的。AI 在需要理解和整合大量既有代码、调用外部工具、处理复杂依赖关系时，非常容易“迷失方向”。它可能会调用错误的工具，理解错上下文的含义，生成与项目风格或架构格格不入的代码。
这时，上下文的质量和范围控制就显得至关重要。我们不能指望 AI 像人类一样自动“脑补”整个项目的背景，你也别指望这些 AI Coding 的软件供应商会给你那么长的上下文窗口，因此我们需要主动地、精准地“喂”给它所需的信息。这正是 GitHub Copilot 等工具提供 /edit 等精确指令能力的价值所在，而VSCODE 很早就建议“如果你知道如何修改，建议使用多文件 Editor“，使用 Editor + 精准的上下文 + 精确的指令，相当于给 AI 戴上了“眼罩”，让它只关注当前需要处理的核心区域，并提供最直接相关的上下文。
这样做的好处是，AI 接收到的信息更加聚焦，干扰更少，理解偏差的可能性也随之降低。它能更准确地理解你的意图，并在你指定的范围内执行修改，从而有效减少“意外惊喜”——那些因为它“自由发挥”或“理解跑偏”而引入的难以预料的改动。
所以：
专业 Coding，更多用的应该是代码补全，因为需要保持高质量的代码输出。
Vibe Coding（感受氛围），则应该克制使用 Agent 的功能，更多使用 Editor 的功能，获得更好的输出质量。
作为一个长期项目，则需要建立更强的规则力量。
三、规则的力量：为 AI 协作建立“脚手架”
在提供精准指令和上下文的基础上，建立一套多个清晰、必要的规则（Rules），如同为 AI 协作搭建了可靠的“脚手架”。这些规则并非凭空产生，而是源于项目实践和开发规范的沉淀。
例如，我们可以将项目中关于视觉组件的使用规范规则化：明确某个 UI 组件应该如何实例化、有哪些必填或推荐的参数、在何种场景下使用、遵循何种设计规范等。将这些规则以简洁明了、结构化的方式提供给 AI。当需要 AI 处理涉及该组件的任务时，这些规则就能成为它可靠的参照，避免生成不符合规范的代码。
那我们让 AI 完成任务的方法就可以拆分成：
你仔细想想，这真的是 AI Coding 最重要且最底层的核心思路了，而这一切得以顺利运转的关键，在与你懂得如何当老板，如何分任务，如何真正使用好事先定义好、并能有效传递给 AI 的“规则”。
“这些‘规则’不仅仅是简单的技术约束。它们是包含项目沉淀下来的‘领域知识’（Domain Knowledge）、团队协作的‘默契AI约定’（AI Conventions），甚至是产品设计背后的‘核心原则’（Design Principles）。比如，关于错误处理，我们约定了统一的日志格式和用户提示方式；关于某个核心业务流程，我们有明确的状态转换图。将这些隐性知识显性化、结构化地喂给 AI，才能让它的协作真正融入项目血脉。更重要的是，这个‘规则库’不是一成不变的，它需要随着项目的迭代、团队的成长而不断维护、修订和扩充，这是一个持续积累和精炼的过程。”
总而言之，AI 帮你写，你要负责不断的修正与调整方向，你的脑袋里有一张清晰的脉络，你才是 AI 的大脑，没有你的认知与规范 AI 只是无情的概率工具，写不鲜艳的文字，与性感的代码。
四、MCP 不是银弹
谈到规则和工具调用，就不能不提近来大热的概念——MCP，或者说更广义的 Agentic Workflow。这些概念描绘了一幅诱人的愿景：AI 不再只是被动执行指令，而是能像人类一样进行多步骤规划，自主选择并调用各种工具（API、数据库、文件系统等）来完成复杂任务。一时间，MCP 被誉为“当红炸子鸡”，似乎预示着 AI 能力的又一次飞跃。
怀着这份期待，我利用假期时间深入实践了基于 MCP 思路的开发。然而，坦率地说，结果令我非常失望。
我发现 MCP 与我们相对熟悉的 Function Calling（函数调用）在实践中的界限似乎相当模糊。核心逻辑依然没变：你预先定义好一套工具或函数，然后期望 AI 能在需要时准确地调用它们。但 MCP + Agent 往往意味着更长的调用链、更复杂的决策逻辑。
而问题恰恰出在执行的可靠性上。在我的大量测试中，AI 在执行 MCP 任务时“翻车”简直是家常便饭：
才爬了三个页面就开始汇总，压缩上下文。
简单来说，当前的大语言模型在可靠地、准确地理解何时、为何以及如何调用外部工具方面，还存在着巨大的鸿沟。它们在模拟复杂规划和执行流程时，表现得相当脆弱和不稳定。
为什么看似强大的 MCP 概念，在实践中却如此脆弱？对比一下那些相对成熟、可控的 AI 编程助手（如深度集成在 VS Code 等 IDE 中的 GitHub Copilot）或许能给我们一些启示。这些工具之所以能提供相对稳定的体验，很大程度上得益于：
领域高度聚焦：它们主要处理代码编辑任务，领域相对封闭。
精准的上下文：他们会不断的优化 AI 所获取的正确的上下文，而不仅仅只是粗暴的使用无用的上下文。
大量工程优化：背后有大量的工程投入，针对代码生成、补全、编辑等核心场景进行了深度优化和测试，对 Prompt 设计、上下文管理、模型微调等都做了细致工作。
而当我们试图在 AI Coding 中直接粗暴的使用自定义的 MCP + Agent 时，这些有利条件几乎都不存在了，Agent 需要处理的任务可能横跨多个领域，需要调用的工具五花八门，需要维护的状态也远比代码编辑复杂。而 Agent 执行任务的规划能力与工具调用能力又和大模型本身的性能有关。 个人体感来看，Claude 3.X 远远好于 OpenAI 4.1 ，o4-mini。
另外是 在 LLM 有限的上下文窗口（Context Window）内处理不断涌入的新信息（用户指令、工具返回结果、自身的思考日志等），Agent 不得不采用各种上下文压缩和管理策略。然而，目前的上下文管理技术还远未成熟。无论是简单的截断、基于向量相似度的检索，还是更复杂的 Summarization 或 Memory 机制，都不可避免地会在长流程中丢失关键信息。这就是为什么 AI 会“忘记”之前的指令，为什么它无法可靠地维护一个复杂的任务状态。所谓的“让 AI 把任务记在 To-Do List 里”，在实践中常常失效，太多要执行的事项了，优先级淹没在茫茫的大海中。
因此，如果有人指望着 MCP 能立刻在编程乃至更广泛的领域带来颠覆性的变革，我个人的看法是：现阶段可能需要大幅调低预期，保持审慎乐观。底层的可靠性、鲁棒性问题，以及模型在复杂推理和规划能力上的局限，依然是巨大的挑战。
当然有些小伙伴可能会问，为什么 Manus 这么牛逼～ ？ 因为他是专门为通用Agent 任务而设计，而不是我们在 AI Coding的 IDE 整了一些有的没有的拓展。
五、MCP 实践避坑指南：化繁为简，分而治之
尽管对 MCP 的整体效果感到失望，但在实践中，我也总结出了一些或许能提升其成功率的“避坑”策略，核心思想就是化繁为简、分而治之：
Prompt 的设计如下：
1、请调用MCP 服务的 Playwright 为我 帮我浏览网页 https://openai.com/news/product-releases/ 并将与 AI 有关的新闻网址进行记录Todo.md，记录在 ./todo.md
如果新闻列表的内容不完整，请继续帮我访问加载更多或者是下一页，并将每一次新增的新闻网址进行记录在 Todo.md 中，直到没有更多的新闻为止。
2、请调用MCP 服务的 fetcher 将我 ./todo.md 中的每一个网址进行访问， 使用参数 returnHtml 为 false，返回的内容为网页的Markdown 内容，导出到OpenAI 下的文件夹 release_news 中，格式为“发布日期-标题.md”。
这种“小步快跑”、目标聚焦的方式，虽然看起来繁琐，但大大提高了整个流程的成功率和可控性。
模型能力是基石，构建你的“个人规则库是效能提升的根本”
所有关于 MCP 的讨论，最终都绕不开一个根本问题：底层大语言模型（LLM）自身的能力。MCP 的成功执行，高度依赖于 LLM 的推理能力、理解力、遵循指令的精确度以及抗干扰能力。在我个人的横向比较中，即使是设计相对精良的 MCP 流程，不同模型跑出来的效果也可能天差地别。例如，在处理一些涉及网页理解和工具调用的任务时，我观察到 Claude 3.5 的表现通常优于同期的 OpenAI 模型。这并非捧一踩一，而是客观反映了不同模型在特定能力维度上的差异。
AI 的所谓“自主规划能力”，与它的模型能力是强正相关的。基础不牢，上层建筑（如复杂的 MCP 流程）自然难以稳固。这也解释了为什么即便是同一个 MCP 框架，换用不同的 LLM 后端，效果可能截然不同。
这一切都指向一个最终的结论：要想在实际项目中有效、可持续地利用 AI 进行协作，尤其是面对需要长期维护的项目，最重要的事情之一，是构建和积累属于你自己项目的“个人规则库”。
这个“规则库”是什么？它绝非网上随便抄来的通用 Prompt 模板或所谓的“最佳实践”。它是你基于对自身项目代码库、业务逻辑、技术栈、团队规范的深入理解，提炼出来的一系列具体的、可执行的指导原则、代码模式、工具使用约定和约束条件。
将这些问题的答案系统化、文档化，形成一套动态更新的“项目 AI 协作指南”，这才是真正能提升 AI 协作效率和质量的关键。这需要持续投入时间和精力去提炼、验证和迭代，但其价值远超追逐各种层出不穷的新概念或通用技巧。
疯掉的 AI 与失控的人生
MCP 技术的现实骨感，与科技媒体、自媒体乃至部分厂商对其近乎狂热的追捧，形成了巨大的反差。
对比严谨的传统软件工程，一个新功能或产品的发布，通常需要经过内部测试、Alpha 测试、Beta 测试等多个阶段，确保其质量、稳定性和用户体验达到一定的标准后，才会推向市场。我们会关注 Bug 率、性能指标、可用性评分，最终才达到更广泛的群体。
但在当前的 AI 领域，尤其是在 MCP、Agent 这类概念上，似乎完全是另一套玩法。大量的项目，无论是大厂的实验性产品，还是社区的开源项目，亦或是初创公司的 MVP，都在远未达到工业级成熟度和可靠性的情况下，被匆匆推向公众，且通过巨大的流量，夸大等覆盖到更多的人的身上。
成功了，皆大欢喜，成为宣传材料中的亮点；
失败了，用户默默承受，或者在社区里抱怨几句，像我就忍不住去各个微信群征求意见，是我的能力问题，还是 MCP的客观现状。
这种反差背后，我感到一种更深层的不安：在这场被资本、媒体和集体性焦虑共同点燃的 AI 狂热中，我们——无论是开发者还是普通用户——似乎正一步步滑向某种“失控”的边缘，将不可靠、未成熟的 AI 当成了拯救一切的银弹。我们成为了”焦虑跟随者、在 AI 浪潮中失控”。在这种强大的声浪下，个体的判断力被淹没，独立思考的空间被挤压。我们被迫成为“焦虑的跟随者”，生怕错过下一个风口，耗费宝贵的时间和精力去追逐那些被过度营销、实则充满陷阱的“银弹”，心甘情愿地扮演着“小白鼠”的角色，在一次次失败和挫败中，为不成熟的技术和浮躁的生态买单。
这也让我感到困惑甚至有些愤怒，整个舆论场似乎在合力助长这种“狂热焦虑”，大量的文章、视频、课程，都在渲染一种
“我用 Agent + MCP 就上天了”
“再不拥抱 Agent，学不会 MCP 就要被淘汰”的焦虑感。”
“拥有 AI 就拥有了新的一切。“
仿佛 MCP 已经是一项成熟到可以大规模应用的技术，而我们遇到的种种问题，只是因为我们“Prompt 没写对”。
我们真的必须接受这种以牺牲用户体验和开发者宝贵时间为代价的“狂奔”吗？
为什么我们每个人都要心甘情愿地扮演“小白鼠”的角色？
为什么层出不穷的新工具、新框架，大多都需要用户从零开始摸索、踩坑？
为什么厂商可以将如此不成熟的技术“坦然”地推向市场，并让用户为其不稳定性买单？
为什么我们可以容忍如此糟糕、充满挫败感的交互体验？
我隐隐约约的感觉到在这片喧嚣与焦虑交织的环境中，许多人（包括我），AI 成为了那些在现实中感到迷茫、渴望抓住救命稻草、甚至梦想借此“一键翻盘”的人们的银弹
他们将希望寄托于外部的技术“奇迹”，却忽视了技术本身的局限与陷阱，忽视真正的竞争因素价值，也可能忽略了自身真正需要付出的努力和成长。
当外部的技术生态本就如此脆弱、充满不确定性而内心又被这种“银弹幻想”所驱动时，个体的“失控感”只会以另一种方式变本加厉。
我们不仅要疲于应对工具本身的缺陷，更要对抗这种幻想破灭后的巨大失落，以及在追逐幻影过程中浪费的时间与机遇。这种双重的困境，正将许多人推向一种更深层次的迷茫与失控。
诚然，AI 无疑是这个时代最具变革潜力的技术之一，它在特定任务上展现出的能力令人震撼。但我们绝不能因此而忽视它当前的局限性，尤其是在需要深度理解、严谨推理、可靠执行和长期记忆的复杂任务上。
或许，与 AI 的真正高效、可持续的协作，并不在于一味追求那个能够“独立思考、无所不能”的“超级智能”，而在于我们——作为人类开发者、设计师、产品经理——如何更深刻地理解 AI 的能力象限，如何更精心地设计人机交互的流程，如何更精准地划分任务边界，如何有效地提供上下文和约束规则，以及如何建立完善的测试、监控和容错机制。我们需要将 AI 最擅长的、已经相对可靠的能力，稳妥地、创造性地嵌入到我们的工作流和产品中，而不是盲目地将希望寄托在那些远未成熟、充满不确定性的“黑科技”上。
欢迎一键三连，添加公众号为星标～第一时间获取新鲜推文
欢迎扫码交流群，一起反焦虑
