夜雨聆风最近，被 AI 忽悠着做了两周 MCP。
做完以后，我坐在电脑前面，看着一堆本地客户端、服务器部署、Skill 路由、状态文件、测试项目、日志输出、质量检查，脑子里只有一个想法。
我到底在干嘛？？？
更离谱的是，这事不是一开始就很蠢。
如果它一开始就很蠢，我反而不会陷进去。最可怕的地方就在于，AI给的方案听起来特别爽，特别完整，甚至特别像一个能做成产品的方向。
我手上已经有一套单片机 AI 研发 Skill，一套覆盖 MCU 项目研发流程的工作流。
它可以从零建立标准项目目录，归档散乱资料，根据原理图、网表、截图提取硬件接口，把客户口述、聊天记录、功能截图、零散需求整理成功能说明。
再往后，它还能根据硬件接口和功能说明开发固件代码，创建 Keil 工程，写模块代码，把文件加入工程，编译，根据日志修错误。
老项目源码也能问答，能辅助接手旧工程，分析功能链路，生成产品说明等等。
最后还能对固件代码做质量审查，检查代码分层、阻塞调用等。
虽然还不完美，但暂时够用。
说实话，这套东西本地跑起来以后，我还挺兴奋的。
因为它解决的不是 AI 会不会写代码，而是用AI打造一条单片机项目研发流水线。
具体介绍可以看这个链接：
花了半年，我把单片机 AI 工作流升级到了第二版
一个嵌入式项目里面，有 datasheet，有原理图，有网表，有旧代码，有客户需求，有 Keil，有编译日志，有板子，有电机，有继电器，有发热，有烧录，有现场反馈。
这不是聊天框里问一句答一句就能解决的，而是要标准化每个环节。
所以当时我脑子里很自然冒出来一个念头。
既然这套流程本地已经可以用了，能不能把它产品化成一个统一入口，再慢慢优化。
用户不用手动理解每个 Skill，也不用自己组合流程。他只要在 Codex、Claude Code 这种 AI 编程工具里接入以后，说一句自然语言，或者敲一条命令，系统就自动判断该调用哪个单片机研发工作流。
听着是不是挺合理。
本地 AI 负责交互和代码修改，MCP 负责连接工作流，服务器负责提供统一能力，用户只要说目标，后面就自动编排。
我甚至还专门租了一台服务器，把相关能力部署上去测试。
那一刻我觉得，兄弟，这事好像能成。
然后我就开始掉坑。
一开始都不是大问题。
改一版，跑一遍，发现上下文没传对。
再改一版，发现 Skill 规则没有被完整遵守。
继续改，发现 MCP 只返回了任务包，但本地 AI 实际写代码的时候还是会走偏。
继续加约束，发现约束一多，又变成大段文本，输出质量还是不稳定。
你再接着调本地客户端，调服务器部署，调 Skill 路由，调状态文件，调任务描述，调测试项目，调编译结果，调上下文传递，调日志输出，调质量检查。
每一步都不是完全没进展。
要么改这里那里又出问题，要么就是某个问题总是改不好。
怎么改都没用，输出一样不稳定，比本地skill调用方式差太远了。
这才是最折磨的。
下面是我来来回回优化了10几次MCP生成的代码差异：
每次优化都将近等40分钟以上，最离谱的一次等了5个多小时。
本来用的中转，后面实在扛不住了，每天烧几百，后面果断转了订阅，1周的额度，2-3天左右基本干完了，还重置了1次。
我当时真的崩了，麻蛋，当下时代马屁精，非AI莫属，打嘴炮像模像样，一落地就是二百五。
但明知道不会因为我骂它就变聪明，但你还是忍不住对着屏幕骂了它一个小时。
不敢骂太难听，怕被封号。。。
我不建议大家模仿。
没什么用。
但挺解压的。
骂完以后，冷静下来，我才意识到这次真正有价值的东西，反而不是 MCP。
是这次翻车本身。
因为它让我非常具体地看见了，AI 最危险的地方，往往不是胡说八道。
胡说八道其实很好识别。
它说 STM32 有 5000 个 GPIO，你一眼就知道这玩意在扯。
真正危险的是，它会把一个错误方向讲得非常完整。
完整到你一边看一边点头：嗯，有道理。
完整到每个模块都有名字，每个阶段都有路线图，每个风险都有缓解措施，每个下一步都看起来很清楚。
然后你就开始干。
干了两周，发现自己是在一条错误假设上狂奔。
这就很吓人。
以前我们说 AI 幻觉，很多人理解成它会编事实。但我现在越来越觉得，在产品方案和工程架构里，更麻烦的是另一种幻觉。
方案幻觉。
它不是编一个不存在的 API，而是帮你把一个没有审清楚的方向，包装成一个可执行计划。
你问它怎么做，它就给你 1、2、3、4、5。
你问它怎么优化，它就继续给你优化方案。
你问它怎么解决当前报错，它就给你补丁。
你问它怎么继续推进，它就鼓励你再试一版。
整个过程里，它很少会主动拽住你说，哥们，你这个方向本身可能就不该做。
这就是问题。
AI 太擅长补全。
但很多时候，创业和产品最需要的不是补全，而是刹车。
这次我还是栽了。
原因很简单，我对 MCP 完全不懂，完全没有判断力。
在熟悉的 MCU 工程里，我能看出来 AI 在乱猜引脚，乱写外设，乱把未验证说成通过。
但在产品架构和商业化封装这件事上，我一开始也被「标准入口」、「统一能力」、「服务器托管」、「本地 Agent 调用」这些词整兴奋了。
这些词都没错。
但词没错，不代表方案对。
这也是我想把这篇文章写出来的原因。
不是为了说 MCP 没用。
我反思的不是 MCP。
我反思的是，我在一个自己还没完全吃透的产品化场景里，太早让 AI 帮我补全了大方案。
而且越补越完整。
越完整，越容易让人误以为它已经被验证了。
这个坑，我觉得很多人都会踩。
尤其是现在大家都在做 Agent、做知识库、做 MCP、做工作流、做企业 AI 落地。
你只要把自己的需求讲给 AI，它马上就能给你一套很像样的架构。
用户层、服务层、工具层、状态层、权限层、日志层、评测层。
再配一套 Roadmap。
再配一套风险清单。
再配一套 MVP 计划。
再配一套商业化路径。
看完以后你会有一种很爽的错觉。
好像事情已经向前推进了。
但其实没有。
你只是获得了一份看起来很完整的语言产物。
真正困难的东西还在那里。
用户为什么要用？
不用这个方案时，他现在怎么解决？
这个方案里最致命的假设是什么？
最小实验能不能验证？
一旦验证失败，你愿不愿意停？
这些问题，AI 不会自动替你面对。
你必须主动把它们拽出来。
这次以后，我给自己沉淀了一套方案审查方法。
说成方法论有点装，但它确实救命。
第一步，不问 AI 怎么做，先问第一性原理。
这件事的底层事实是什么。
用户真正要的是什么。
他是想要 MCP，还是想要更稳定地完成一个 MCU 项目。
他是想要服务器托管，还是想要少翻资料、少猜引脚、少读老代码、少被编译错误折磨。
这两个问题差别非常大。
如果用户真正要的是稳定完成项目，那 MCP 只是可能的手段之一。你不能因为 MCP 听起来是当下正确答案，就把所有努力都塞进这个词里。
第二步，找核心矛盾。
每个听起来很好的方案，背后通常都有一个天然冲突。
我这次的冲突就是，高质量执行需要暴露高质量规则，但商业化又希望保护核心 Skill 资产。
我理想的就是MCP下发完整的skill规则，我以为直接把skill集成到mcp里面套个壳这么简单。
实际上不是，mcp写了很多代码去适配skill的规则，我脑子还是懵的，到现在都不知道这个方案到底能不能实现，只是测试下来好像实现不了。
MCP好像更适合像乐鑫MCP、stc的MCP这样连接他们芯片厂的数据库用。
这个矛盾如果不解决，后面所有优化都是打补丁。
你可以换服务器，可以换路由，可以换任务描述，可以加状态文件，可以加日志字段。
但只要这个矛盾还在，系统就会一直再在解决bug的路上。
第三步，做关键假设审计。
一个方案能成立，通常依赖一串假设。
比如我这次至少依赖这些假设。
本地 Agent 能稳定理解服务器返回的任务包。
用户愿意在 Codex 或 Claude Code 里配置 MCP。
服务器可以在不暴露核心 Skill 规则的前提下，让本地 AI 生成高质量代码。
MCP 的工具调用体验，真的比本地直接加载 Skill 更好。
这些假设只要有一个是假的，方案就会变形。
而我一开始犯的错，就是太早进入「怎么实现」，太晚回到「这些假设凭什么成立」。
第四步，让多个 AI 对抗式审查。
这块很有意思。
你不能只让 AI 当执行者，还要让它当反对者。
而且要明确给它角色。
一个从工程实现角度喷。
一个从用户体验角度喷。
一个从商业化角度喷。
一个从安全和知识产权角度喷。
它们不一定都对，但这种对抗能把方案里的自嗨挤出来。
AI 很擅长顺着你说。
那你就得故意让它反着说。
第五步，做反事实推演。
也就是问，如果用户完全不用我的方案，他现在会怎么办。
这个问题很残酷。
因为很多产品一问就露馅了。
用户不用你的 MCP，他可能直接把 Skill 放本地，让 Codex 读。
用户不用你的服务器，他可能直接买一个课程，学会流程以后自己跑。
用户不用你的统一入口，他可能找你做一次项目陪跑，把标准流程沉淀下来。
那你的产品价值到底在哪里。
它是更省事，还是更安全，还是更稳定，还是更容易交付，还是只是你自己觉得架构更漂亮。
这个问题不问清楚，后面很容易越做越复杂。
第六步，从验收标准倒推。
这是工程师最熟悉，但在做产品方案时最容易忘的一步。
不要问这个方案能实现哪些功能。
问它怎样才算通过。
比如一个 MCU AI 工作流，不能说生成了代码就通过。
至少要分层。
资料有没有归档。
硬件接口有没有证据。
需求有没有可执行约束。
代码有没有进工程。
编译有没有真实通过。
板级验证有没有烧录、串口、CAN、SWD 或人工观察证据。
哪一层没做，就停在哪一层。
这个原则，我现在越来越执着。
因为嵌入式项目里，语言上的完成没有意义。
板子不会因为你文档写得漂亮就跑起来。
硬件世界是很朴素的。
你说通过，可以，证据呢。
写到这里，我突然想起一个挺老的东西，叫费曼学习法。
很多人把它理解成，把一个东西讲给小孩听。
但我自己的感受是，费曼真正狠的地方不是讲得简单，而是它会逼你发现自己哪里其实没懂。
你讲不下去的地方，就是理解断点。
产品方案也是一样。
如果一个方案只能在 AI 帮你写的文档里成立，不能被你用非常朴素的话讲清楚，不能被一个真实用户的动作验证，不能被一个最小实验打穿，那它很可能只是语言上成立。
语言上成立，太容易了。
尤其在 AI 时代。
它能把任何东西写得像真的。
这也是为什么我现在越来越觉得，AI 时代最重要的能力，是判断力，这太重要了，我就是在这个陌生的领域被AI摆了一道。
你要知道什么时候让 AI 补全。
也要知道什么时候让 AI 停下。
你要知道什么时候问「怎么做」。
也要知道什么时候先问「这个方向为什么可能不该做」。
你要知道什么时候相信它的执行力。
也要知道什么时候怀疑它给你的完整感。
完整感，有时候是毒药。
我这次 MCP 的折腾，最后并不是完全白费。
它让我更清楚地确认了一个方向。
我不应该把重点放在「把 Skill 塞进某个连接协议后面」。
至少现阶段不应该。
更稳的路径，是先把单片机研发流程标准化，再沉淀固件资产库、先让项目过程变标准、再让每次项目，变成下一次项目的资产。
这句话我现在挺喜欢。
因为它比 MCP 更接近用户真正要的东西。
用户不是要一个协议。
用户要的是，下一次新项目不要又从零开始配工程。
用户要的是，datasheet 不要每次都重新翻 2000 页。
用户要的是，原理图、网表、代码、需求、编译日志、调试记录能串起来。
用户要的是，新人接手老项目时，不要只能靠问那个最懂的人。
用户要的是，AI 写了代码以后，工程师能知道它到底改了什么、进没进工程、编没编过、上没上板、哪里还没验证。
这些东西，才是价值。
至于最后用 MCP，还是本地 Skill，还是服务器任务包，还是项目陪跑交付模板，那都是手段。
手段可以换。
底层价值不能丢。
所以，如果你也正在用 AI 做产品、做工作流、做企业落地，我给你一个很不成熟的建议。
别太快让 AI 给你完整方案。
尤其是你越不懂的领域，越不要一上来问它怎么做。
先让它帮你拆事实。
再让它帮你找矛盾。
再让它帮你审假设。
再让它反对你。
再让它推演用户不用你的方案时会怎么办。
最后再从验收标准倒推，问这个东西到底怎样才算真的通过。
尼玛。
一想到特意为了做MCP租了一年服务器吃灰就头痛。。。
