从Shell脚本到MCP：一个SEO老炮的20年自动化进化史

2005年，我写了一个Shell脚本，每小时ping一次Google，检查网站是否被收录。那是我第一次尝到自动化的甜头。

接下来的二十年，Python成了我的母语。爬虫、日志分析器、批量内容管道——只要是重复性工作，就写个脚本，部署，遗忘，继续下一个。这套方法论很稳，直到两年前彻底失效。

大模型刚能干活时，我和大多数人一样，把它当高级自动补全用。更聪明的关键词研究、更快的内容简报、更精准的元描述生成。三个月后，这套玩法就撞墙了。

转折点在于问题的转换：不是"AI能帮我做什么"，而是"一套好的AI指令系统应该长什么样"。这个问题把我拽回了软件工程的思维模式——只不过写的不是函数，而是行为规格。

看这两段prompt的区别：

❌ 自动补全思维："给工业泵页面写10个标题标签"

✅ 行为规格思维："你正在审计B2B工业设备页面的标题标签。标记任何使用通用动词（Buy/Get/Find）、超过60字符、或品牌名前置的标题。对每个标记项，解释具体SEO风险并重写。"

差距不只是风格。后者可靠——跑500页能得到一致、可执行的输出。前者每次结果都不一样。

差不多同时期，我开始用Claude Code和Cursor写Python。我不是什么高手，属于能读代码、修bug、但独立架构项目会纠结太久的那种。Vibe coding解决了我的 blank page 困境：用自然语言描述需求，几分钟拿到能跑的骨架，先理解再动手，从真实的东西开始迭代而非从零空想。

但理解这一步不能省。我见过太多人vibe-code出一堆自己维护不了的代码，从不读AI写了什么。那不是自动化，是技术债的变种。

六个月前，两个东西撞在一起了。我当时在解决一个具体问题：每次用AI agent做UI/UX工作（落地页、SaaS布局、设计审计），它都输出同样的平庸结果——居中hero、紫到靛蓝渐变、通用卡片网格。

问题在于上下文。这些模型被喂了太多Dribbble和Tailwind模板，它们"知道"什么是"好设计"，却不知道你的品牌、你的用户、你的转化逻辑。

我试过各种hack：把品牌指南塞进system prompt、上传参考截图、用 few-shot 示例。都有点用，但都不稳定。每次换模型或版本，又得重新调。

然后MCP（Model Context Protocol）出现了。

简单说，MCP让AI agent能调用外部工具和数据源，不是通过prompt里塞满上下文，而是通过标准化的协议接口。你的品牌资产、用户数据、历史表现——变成agent能实时查询的资源，而不是每次对话都要重新介绍的陌生人。

我建的第一个MCP server很蠢：只是让我的agent能查询我们过去两年的落地页A/B测试结果。但效果立竿见影。突然之间，AI不再建议"试试红色CTA按钮"，因为它能看到红色在我们这儿从来没赢过。

这改变了我对自动化的整个理解。

以前的模型是：识别重复任务→写脚本→部署→遗忘。现在的模型是：识别决策瓶颈→建上下文接口→让AI在正确的时间访问正确的信息。

不是更快地做同样的事，而是做以前做不到的事。

举个例子。以前我要做竞品内容审计，流程是：爬取对手页面→存数据库→跑NLP分析→人工读报告→写建议。现在我的agent直接查询我们的MCP server——里面有我们的内容策略文档、历史排名数据、转化表现——然后对比竞品页面，输出带优先级的行动清单。

同样的时间，不同的产出层级。

但这里有个陷阱，我花了很久才意识到。

MCP不是万能药。它解决的是上下文问题，不是判断问题。如果你的战略本身是模糊的，给AI更多数据只是让它更快地产出垃圾。我见过团队把一堆互相矛盾的目标塞进MCP，然后困惑为什么agent的建议总是摇摆不定。

另一个教训：接口设计比想象中难。早期我把太多逻辑塞进MCP server，结果agent调用一次要等十几秒，用户体验崩了。后来学会保持server轻量，只返回原始数据，让prompt里的逻辑处理解释和决策。

现在我的栈大概长这样：

• Python还在，但角色变了——从主力变成胶水，连接各种API和数据源

• Prompt工程是核心技能，但"工程"这个词有误导性。更像产品管理：定义行为、测试边界、处理边缘情况

• MCP server是新的基础设施，每个项目先问"什么信息能让AI做出更好决策"，然后建接口

• Vibe coding用于原型，但生产代码还是人工审查。AI写的代码我至少读两遍，确保我理解它为什么这样设计

最反直觉的发现：自动化程度越高，人的判断越重要。不是更少，而是更关键——只是集中在更早的阶段（定义问题、设计系统）和更晚的阶段（验收结果、迭代方向）。中间执行层被压缩了，但两端的权重增加了。

这和我二十年前写那个ping脚本时完全不同。那时候自动化是逃避，现在自动化是放大。不是让机器代替思考，是让机器承担它擅长的（模式匹配、大规模处理），让人专注人擅长的（模糊判断、创造性连接）。

最近我开始把这套方法论教给团队里的年轻SEO。他们的反应很有意思：有人兴奋，觉得终于不用写Python了；有人焦虑，担心自己的技能贬值。

我的看法是，工具层确实在快速贬值。五年前会写Scrapy爬虫是硬通货，现在用Firecrawl API加一段prompt就能搞定大部分场景。但问题定义层在升值——知道该爬什么、爬来干什么、怎么把数据变成行动，这些判断越来越值钱。

还有一个变化：反馈循环变快了。以前一个SEO实验的周期是周或月，现在可以是小时。这意味着你能跑更多迭代，也意味着你需要更强的筛选能力——不是每个能跑通的想法都值得规模化。

说到这，想起一个具体案例。三个月前我们有个客户，B2B SaaS，落地页转化率卡在2%不动。传统做法是重新设计、A/B测试、等统计显著——至少六周。

我们用MCP搭建了一个快速实验系统：agent能实时查询我们的历史表现数据库、竞品页面库、用户访谈记录。两天内跑了二十多个微型实验，不是改整个页面，而是改特定模块的文案逻辑、社会证明的呈现方式、CTA的时机。

最后赢的变体把转化率提到3.4%，但更重要的是，我们知道了为什么——不是设计更好看了，是某个特定用户痛点的表述方式触发了共鸣。这个洞察被写进MCP server，现在所有同类项目都能调用。

这就是我说的"做以前做不到的事"。不是效率的线性提升，是实验空间的指数扩展。

当然，这套玩法有门槛。MCP生态还在早期，文档不全，调试痛苦。我见过太多人建完server发现某个模型不支持某个参数，或者token消耗爆炸。技术债没有消失，只是转移到了协议层和接口层。

我的建议是：别一上来就建基础设施。先用最糙的方式验证——哪怕是把数据贴在prompt里——确认这个方向有价值，再逐步硬化成MCP接口。我早期犯的错就是过度工程，花两周建server，三天后发现需求理解错了。

另一个实用技巧：给你的MCP server写"使用说明"。不是给机器看的schema，是给prompt作者看的人性化文档——这个接口返回什么、有什么陷阱、什么时候该用、什么时候不该用。我把它放在server的description字段，agent调用前会先读。

回到开头那个ping脚本。如果现在重写，它会是一个MCP server，agent能查询索引状态、对比历史趋势、判断是否需要采取行动——而不是无脑每小时ping一次。

工具变了，但核心直觉没变：重复的事应该自动化，判断的事应该留给人类。只是"重复"和"判断"的边界在移动，而且移动得很快。

二十年SEO生涯，我以为自己懂自动化。现在发现，我只是懂那个时代的自动化。下一个时代正在用MCP、agent和vibe coding重新定义规则。

还在学。还在犯错。但至少，blank page 的问题解决了。