AI写脚本三大硬伤与MCP服务实战解法

AI辅助写脚本，为何总让人失望？

用AI辅助编写自动化脚本，几乎是每个开发者都尝试过的事。但真正落地时，你会发现AI存在三个致命痛点：失忆（不记得之前做过什么）、眼瞎（拿不到准确的节点/元素信息）、反复踩坑（同一个错误一犯再犯）。这三大硬伤让AI从「效率工具」变成了「反复返工的负担」。

近期，一位B站UP主分享了一套基于MCP（Model Context Protocol）服务的解决方案，用Rust编写的一系列工具节点，一次性补上了这三大短板。本文结合其完整实测流程，剖析这套方案的设计思路与实际效果。

什么是MCP？ MCP（Model Context Protocol）是Anthropic于2024年底推出的开放协议标准，旨在解决大语言模型与外部工具、数据源之间的标准化连接问题。在MCP出现之前，每个AI应用都需要为不同工具编写定制化的集成代码，维护成本极高。MCP通过统一的客户端-服务器架构，让模型能够以标准化方式调用本地或远程工具，极大降低了AI与外部系统集成的复杂度。目前Claude、Cursor等主流AI产品均已支持MCP协议，它正在成为AI工具生态的重要基础设施标准。

为什么选择Rust？ 作者选择Rust编写MCP服务工具节点并非偶然。Rust以其内存安全性和接近C语言的执行性能著称，特别适合构建需要长时间稳定运行的后台服务与工具链。在AI Agent生态中，工具节点往往需要频繁处理文件IO、网络请求和进程管理等系统级操作，Rust在这些场景下既能避免Python的GIL锁和垃圾回收停顿问题，又能提供比Go更精细的内存控制，是AI基础设施层的重要技术选型方向。

硬伤一：失忆——历史记录节点赋予AI长期记忆

大模型的上下文窗口是有限的，一旦对话拉长或跨会话，AI就会「失忆」——不记得之前的开发进度、遇到过的问题，以及最终的解决方案。这在长周期的脚本开发中尤为致命。

要理解这个问题的根源：大模型的上下文窗口（Context Window）指模型在单次推理中能够处理的最大Token数量。即便是目前最先进的模型，如Claude 3.5 Sonnet（200K Token）或GPT-4o（128K Token），在长周期开发场景下依然面临上下文溢出的挑战。更关键的是，跨会话的状态持久化问题无法靠扩大上下文窗口解决——每次新对话都是「全局失忆」的白板状态。这一根本性架构限制，正是外部记忆存储机制存在的核心原因。

MCP服务的核心功能之一，正是AI对话历史记录。实测中，作者直接在对话框输入「查询历史记录」，AI便自动调用历史查询工具，梳理之前的对话内容。从日志输出可以看到，AI调用了多个工具进行检索，最终成功找到并分析出上次的开发记录，清晰整理出「之前都做了什么」。

这一功能的核心价值在于，它把AI的记忆从「单次会话」延展到了「跨会话的项目级」。开发者不再需要每次重新交代背景，AI可以接着上次的进度继续工作，形成真正的开发连续性。

硬伤二：眼瞎——节点预处理与分析工具精准补位

第二个痛点是AI「看不清」。在自动化脚本开发中，AI需要读取界面节点（UI元素）信息才能编写精准的操作代码。但原始节点信息往往体积庞大，大模型面对海量文本，要么「偷懒」跳过，要么直接把上下文撑爆。

这里有必要解释一下UI节点数据的本质：在移动端或桌面端自动化脚本开发中，UI节点（也称UI树或Accessibility Tree）是描述界面元素层级结构的XML/JSON数据。一个普通应用界面的节点文件往往包含数千乃至数万行数据，充斥着坐标、尺寸、资源ID等大量冗余字段。直接将原始节点数据投喂给大模型，不仅会迅速消耗上下文配额，还会因为信息噪声过多导致模型识别到错误的元素属性。业界常见的应对策略包括节点裁剪、摘要提取和关键路径过滤。

针对这一点，MCP服务设计了节点预处理机制。实测中，作者让AI「抓个节点」，AI主动调用节点抓取工具，通过QE程序执行抓取，并根据当前项目名称拼接QE命令参数，抓取成功后将节点信息存储在缓存目录中。

值得关注的是，当作者要求「详细分析节点」时，AI发现文件过长，于是主动调用节点分析工具，通过工具提供的摘要提取关键信息。这种「预处理＋摘要」的双重机制，既保证了AI能拿到精准的节点数据，又避免了上下文被无关信息淹没。

作者也坦言，此次演示使用的是免费的MIMO模型，速度与能力不及付费大模型，但即便如此，节点工具依然让AI稳定完成了抓取与分析。这说明工具链的合理设计，能在一定程度上弥补模型本身的能力短板。

硬伤三：反复踩坑——错误库让AI从失败中沉淀经验

第三个也是最令人抓狂的问题：AI会反复犯同样的错误。这一点在实测的代码编写环节体现得淋漓尽致。

作者提出一个简单需求让AI输出代码，第一版果然因节点信息错误无法运行。随后的反复修正过程令人印象深刻：

• AI最初使用了ID属性，但作者知道某些场景下APPID属性不可靠，于是提醒；
• AI改用DS属性，但方案不符合官方API规范；
• 再次提醒后，AI查阅知识库，输出了正确的官方DS函数；
• 但AI又忽略了「属性内容不固定」的问题——比如点赞数量会随作品变化；
• 经过再次提醒，AI最终输出了正确的正则查询节点代码。

这个过程暴露了AI的通病：不理解业务的动态性。大模型在训练时学习的是静态知识模式，而真实业务场景中，界面元素的属性值往往随用户数据动态变化，这种「运行时不确定性」是模型仅凭静态推理难以感知的盲区。

解决之道，正是MCP服务的错误库功能。作者在开发过程中让AI进行「经验记录」，将遇到的错误和解决方案存入错误库。下次遇到类似问题，直接查询问题库和历史记录即可快速解决，从根本上避免重蹈覆辙。这本质上是为AI构建了一套「项目级专属记忆」，将每次调试失败转化为可复用的结构化知识资产。

实战演示：从取色到点赞验证的完整闭环

除了三大核心功能，作者还演示了取色工具这一配套能力。

流程如下：作者提出抓取屏幕的需求，AI截屏后询问是否需要打开取色工具。确认后，AI调用MCP提供的取色截图工具并打开图片，同时告知使用方法——鼠标左键取色后点复制按钮、关闭窗口，再由AI读取日志获取结果。

取色完成后，AI进入找色代码编写环节。这里再次出现了「AI瞎写API」的经典问题，经过多次工具调用后，AI终于产出可用代码。测试过程中还遇到「忘记申请截图权限」的插曲，经提醒并查阅知识库后，AI自行修正了代码。

最终，AI成功找到颜色值并执行点击操作。作者进一步优化了执行逻辑：正常流程应为「先未点赞→执行点击→找色确认是否成功」。经过修正，AI实现了完整的点赞成功验证功能——当检测到已点赞状态时，脚本会自动跳过，不再重复点击。

从日志中可以看到「已点赞跳过」的输出，证明脚本逻辑完全正确。整个流程形成了「抓取→分析→编码→测试→验证→经验记录」的完整开发闭环。

总结：工程化工具链，才是AI编程的真正竞争力

这套基于Rust构建的MCP服务，其价值不在于某个功能有多惊艳，而在于它系统性地修复了AI辅助脚本开发的结构性缺陷：

• 历史记录节点：解决失忆问题，让AI具备跨会话的长期记忆；
• 节点预处理与分析工具：解决眼瞎问题，用摘要机制平衡信息精度与上下文占用；
• 错误库：解决反复踩坑问题，让AI从每次失败中积累可复用的经验。

值得放在更宏观的行业背景下理解这套方案的意义：传统RPA（机器人流程自动化）依赖预先录制的固定脚本，脆弱且缺乏自适应能力——界面一旦变化，脚本即告失效。而引入AI Agent则带来了推理与决策能力，能够根据当前界面状态动态生成操作策略。文中的MCP工具链正是这两种范式融合的典型案例：用AI负责理解与决策，用工程化工具链补齐记忆、感知和经验积累能力，形成「AI大脑+RPA执行层」的混合架构，代表了自动化开发的下一阶段演进方向。

当然，实测也暴露了当前AI的局限——对业务动态性的理解仍需人工反复引导，免费模型的能力更是有限。但通过工具链的精心设计，这些短板得到了有效弥补。

对于从事自动化脚本、RPA或AI Agent开发的工程师而言，这种「用工程化手段补齐模型能力」的思路极具参考价值。未来AI编程的竞争，或许不只是模型本身的比拼，更是上下文管理与工具编排能力的较量。