一次把 DeepSeek 折腾成 SEO 自动化流水线模型路由、技能文件与智能代理实战先交代背景。我手里有一个内容站日更压力大人工产出跟不上于是从去年底开始折腾 AI 生成、AI 改稿、AI 内链匹配这类活。试了一圈开源模型和各家 API 之后最终固定在 DeepSeek 上原因是它的输出质量、上下文长度和价格三者平衡得最好尤其适合 SEO 这种需要“批量产出但不追求单篇封神”的场景。这篇文章不是给你讲 DeepSeek 怎么注册、怎么调 API 那种入门教程而是把我最近搭的一套“DeepSeek 模型路由 技能文件 智能代理扩展”的 SEO 自动化工具链完整拆开。你如果也在做网站内容批量生产、聚合页生成、关键词聚类或者站内结构优化这篇内容可以直接抄作业。先说结论这套东西的本质是把 DeepSeek 从一个“聊天机器人”改造成一个“能自己判断该用什么模型、按什么流程干活、调用什么工具”的自动化引擎。核心就三块模型路由负责分流任务技能文件负责固化 SOP智能代理扩展负责把 AI 的输出真正落地成 SEO 动作。适合谁来读想用 AI 做 SEO 内容生产的个人站长、做海外站的内容运营、以及想给自己的工具链接入 DeepSeek 的开发者。不需要你有多深的算法背景但最好懂一点 Python知道 API 是什么否则后半部分读起来会有点吃力。1. 内容整体设计与思路拆解1.1 为什么是 DeepSeek 而不是其他模型先把选型逻辑讲清楚。SEO 自动化场景下模型要干的活往往不是“写出一篇惊世骇俗的文章”而是“稳定地产出 80 分以上的内容并且能听懂结构化指令”。我对比过几类模型模型优势在 SEO 场景下的问题闭源顶级模型理解力强指令遵循好贵批量调用成本扛不住开源小参数模型便宜可本地部署长文本生成容易跑偏结构化输出不稳定DeepSeek性价比极高上下文够长指令遵循能力强偶尔需要调参数部分场景要配合外部工具才能落地DeepSeek 最让我满意的点是它的 API 兼容性极好接入成本低到离谱。你不需要专门写一套 SDK 对接逻辑直接用 OpenAI 兼容的调用方式就能跑起来。这意味着我之前写的很多 SEO 脚本只需要把 base_url 改一下把模型名换成 deepseek-chat 或者 deepseek-reasoner立刻就能切过来。而且它的上下文长度足够长处理那种“给 20 个关键词批量生成 20 个标题加描述”的任务时可以一次性把指令和结构化输出格式都塞进 prompt 里不用频繁分片调用节省的不仅是 token还有我写代码的时间。1.2 SEO 自动化到底在自动化什么很多人一提“SEO 自动化”第一反应就是“用 AI 批量写文章”。这个理解太窄了。真正跑起来之后你会发现SEO 的活儿里写作只是最后一步前面还有大量的重复劳动关键词扩展与聚类把一个核心词拆成长尾词再按搜索意图分组。内容结构生成为每个聚合页生成标题、H1、H2 大纲、meta description。内链策略判断新文章应该从哪些旧文章出链、锚文本用什么。存量内容优化给旧文章生成新的标题建议、补充段落、FAQ 内容。结构化数据生成 JSON-LD 所需的 FAQPage、Article 等格式内容。这些任务的共同点是重复、有规律、但需要一定的语义理解能力。传统脚本干不了纯人工干太累正好是 DeepSeek 这类模型的舒适区。我设计的这套工具链就是把这五类任务全部拆成“模板 路由 执行”三步。模板负责定义输出格式路由负责决定用哪个模型执行环节通过智能代理扩展把结果写回数据库或者生成文件。1.3 三件套的分工逻辑路由、技能文件、智能代理这套系统里最难理解的一层就是它的分工逻辑我拿一个生活化的例子解释一下。假设你开了一家翻译公司手下有几个翻译一个擅长法律文书一个擅长技术文档还有一个擅长小说。客户来了之后你不能让所有稿件都扔给同一个翻译你得先看稿件类型分给对应的人。这里的“分稿员”就是模型路由。每个翻译手里都有一本自己的术语表和操作手册这就是技能文件。而翻译完成后帮你把文件归档、发送给客户、开具发票的那个助理就是智能代理扩展。模型路由Agent/Model Router做的事情就是判断当前任务属于哪一类然后把请求分发到最合适的模型上。比如简单的标题生成我用 deepseek-chat复杂的策略分析用 deepseek-reasoner本地的敏感数据处理交给本地小模型。技能文件Skill File则是一套预设的“提示词模板 输出格式约束 示例”组合体。它不是简单的 prompt而是把整个任务的执行步骤都固化下来了。比如我做关键词聚类技能文件里会包含输入格式说明、聚类规则定义、输出 JSON 结构示例、以及常见错误兜底逻辑。智能代理扩展Agent Extension是负责“动手”的那一层。AI 返回的结果往往只是文字不能直接当成 SEO 动作落地。比如 AI 说“应该给这篇文章加一个 FAQ 板块”智能代理会负责把这个 FAQ 板块真正插入到页面的 HTML 里并更新对应的结构化数据。2. 核心细节解析与实操要点2.1 模型路由从硬编码到智能分发先看模型路由这一层。最开始的版本我的代码里全是硬编码所有请求全部打到 deepseek-chat 上。后来发现一个问题有些任务虽然量大但对推理能力要求不高用更小的模型也能完成成本能省下三分之一而有些任务虽然量不大但涉及策略判断deepseek-chat 经常会给出平庸的回答必须上 deepseek-reasoner。于是我就做了一层简单的路由逻辑。核心思路是定义一个任务类型枚举不同类型的任务映射到不同的模型和参数。from enum import Enum class TaskType(str, Enum): TITLE_GENERATION title_generation OUTLINE_CREATION outline_creation CONTENT_WRITING content_writing KEYWORD_CLUSTERING keyword_clustering META_OPTIMIZATION meta_optimization STRATEGY_ANALYSIS strategy_analysis ROUTING_CONFIG { TaskType.TITLE_GENERATION: { model: deepseek-chat, temperature: 0.9, max_tokens: 200, }, TaskType.OUTLINE_CREATION: { model: deepseek-chat, temperature: 0.7, max_tokens: 800, }, TaskType.CONTENT_WRITING: { model: deepseek-chat, temperature: 0.8, max_tokens: 4000, }, TaskType.KEYWORD_CLUSTERING: { model: deepseek-chat, temperature: 0.3, max_tokens: 2000, }, TaskType.META_OPTIMIZATION: { model: deepseek-chat, temperature: 0.5, max_tokens: 500, }, TaskType.STRATEGY_ANALYSIS: { model: deepseek-reasoner, temperature: 0.4, max_tokens: 3000, }, }这套路由看起来简单但有几个细节值得说一下。第一temperature 的设置是有讲究的。标题生成类任务我故意调高到 0.9因为标题需要多样性同一个关键词要产出 10 个不同角度的标题温度低了会大量重复。关键词聚类则是相反temperature 调到 0.3因为聚类追求的是稳定、可复现的分类结果温度高了会导致同一批关键词每次分的组不一样。第二max_tokens 要按任务卡死。SEO 场景里最怕的就是模型生成到一半被截断尤其是内容写作一旦截断就是一篇文章废掉。我卡到 4000 是因为我的单篇文章正文基本控制在 3000 字以内加上标题和段落结构4000 个 token 有富余。你要是写长文这个值要相应调大。第三也是最容易踩坑的点不要在路由层面对 response 做太多假设。比如有些任务你需要 JSON 输出有些需要 Markdown有些只要纯文本。模型返回的格式会因为 prompt 的微小差异而变化所以路由层只负责“分发请求并拿到原始响应”格式清洗交给后面的技能文件执行层去做。2.2 技能文件把 SEO 作业 SOP 固化下来技能文件是这套系统里我花时间最多的一部分。它的本质是把“一个资深 SEO 编辑接到任务后怎么干活”的完整过程变成 AI 可以理解和执行的指令集。我给它定的结构包含四块任务描述、输入说明、输出约束、示例。我们拿“关键词聚类”这个技能文件来拆解。# 技能关键词聚类 ## 任务描述 将给定的关键词列表按照搜索意图进行分类每个类别中选出一个代表性关键词作为组名并为每组输出一个聚合页面的标题和描述建议。 ## 输入说明 输入为一个关键词列表每行一个UTF-8 编码关键词之间无其他符号分隔。 ## 输出约束 输出必须为 JSON 格式结构如下 { groups: [ { group_name: 代表关键词, keywords: [关键词1, 关键词2], page_title: 聚合页标题建议, page_description: 聚合页描述建议 } ] } 注意不要输出 JSON 以外的任何内容不要使用 Markdown 代码块包裹 JSON。 ## 示例 输入 宠物猫粮推荐 猫粮什么牌子好 幼猫猫粮挑选 猫咪罐头测评 输出 { groups: [ { group_name: 猫粮推荐, keywords: [宠物猫粮推荐, 猫粮什么牌子好], page_title: 2024年猫粮推荐指南铲屎官必看的选购策略, page_description: 从幼猫到成年猫从干粮到罐头一文看懂猫粮选购关键点。 } ] }看到这里你可能觉得这不就是个结构化 prompt 吗确实它和 prompt 在形式上很像但区别在于第一技能文件是独立的、可复用的文件。它不是写死在代码里的字符串而是以一个 单独 .md 文件的形式存放在技能目录下。这意味着你可以在不改代码的前提下随时调整某个技能的指令甚至可以让非技术人员直接编辑这些文件来优化 AI 的输出质量。第二技能文件之间可以互相嵌套引用。比如我在做“内容写作”技能时会在技能文件的内部引用“标题生成”技能的输出格式规范确保 AI 写出的大纲里的标题风格和单独生成标题时的风格保持一致。第三技能文件的核心价值在于统一输出格式。SEO 自动化和纯聊天最大的不同是你后面还有程序要处理 AI 的结果。如果 AI 这次输出 JSON 下次输出 Markdown你的解析脚本就会炸。技能文件把所有输出强行限定在固定结构里从源头规避了这个问题。2.3 智能代理扩展让 AI 从“动嘴”变成“动手”模型路由负责选模型技能文件负责教模型怎么回答问题但这两层都没办法真正让 AI 倒腾你的网站数据。比如 AI 说“建议给 A 页面加一个 FAQ 板块里面放这三个问题”怎么让这个建议变成现实我的做法是引入一个轻量级的智能代理扩展层。它的核心职责是解析 AI 的输出结果调用外部工具把结果落地。最简单的落地方式是文件输出。比如关键词聚类任务完成后AI 会返回一个 JSON 数组智能代理直接把这个 JSON 写到数据库里同时生成一个 CSV 文件供人工审核。这个逻辑不复杂简单但有效。稍微复杂一点的是和 CMS 对接。我自己的站点是 WordPress所以我直接用 WordPress REST API 作为代理的落地工具。AI 生成完文章内容之后代理负责调用 WordPress API 创建文章草稿并填入标题、正文、meta description、标签和分类。整个过程完全无人值守。import requests def publish_draft_to_wordpress(title, content, meta_description, tagsNone): wp_url https://your-site.com/wp-json/wp/v2/posts headers { Authorization: Bearer YOUR_APP_PASSWORD, Content-Type: application/json, } payload { title: title, content: content, status: draft, meta: { description: meta_description, }, } if tags: payload[tags] tags resp requests.post(wp_url, jsonpayload, headersheaders, timeout30) if resp.status_code ! 201: raise RuntimeError(fWordPress API error: {resp.status_code} {resp.text}) return resp.json()[id]架设智能代理时要特别注意一点它必须要有“失败时明确报错”的能力而不是静默吞掉异常。比如 WordPress API 返回 400 错误代理就应该把错误信息原样抛出来并带上 AI 生成的原文方便人工排查。否则哪天接口改了、字段名变了你的系统会“看起来在运行”实际上已经三天没发布过任何东西了。2.4 其中一个关键选择本地部署还是 API 调用聊到 DeepSeek很多人第一反应是问用官方 API 还是本地部署我的建议是SEO 自动化场景下默认用官方 API除非你有数据合规需求。原因有几个一是成本。DeepSeek 的 API 定价本身就极低批量生成场景下一个月几百块能撑起一个中小站点的内容更新量。你自己部署电费、显卡折旧、维护时间算进去成本反而更高。二是稳定性。官方 API 的可用性要比自己搭的 GPU 服务稳定得多。SEO 自动化最怕的就是半夜跑批任务时服务挂了第二天起来发现一篇文章都没生成白白损失一天。三是上下文能力。我自己试过本地部署 7B 和 14B 的模型长文本生成能力明显不如 DeepSeek 官方 API 的大模型版本。SEO 写作这种任务动辄需要几千 token 的上下文本地小模型很容易在写到一半时“忘记”前面的设定。当然本地部署也不是没有价值。如果你的业务涉及敏感数据或者需要在离线环境跑批量任务本地部署可以作为补充方案。我的做法是日常任务走官方 API只有涉及内部数据脱敏处理时才把任务路由到本地模型上。这就是模型路由的另一个价值场景——你可以混用多种来源的模型服务而不必被一家绑死。3. 实操过程与核心环节实现3.1 环境准备与工具链搭建开始之前把我用的环境列出来。我的主力机器是一台带 3060 显卡的台式机但说实话跑这套系统用不上显卡。因为所有重量级推理都在远程 API 上完成本地只跑流程编排和工具调用。能跑通的底配是一台 2 核 4G 内存的轻量云服务器装 Ubuntu 22.04 或者 Debian 12 都行Python 版本建议 3.10。代码层面核心依赖只有两个openai 库因为 DeepSeek 兼容 OpenAI 接口和 requests用于调用 WordPress API 和其他 HTTP 服务。不需要引入 LangChain 之类重型框架我们的任务用不到那么多抽象层自己写一个简单的循环反而更可控。pip install openai requests python-dotenv环境变量维护一个 .env 文件DEEPSEEK_API_KEYsk-xxxxxxxx DEEPSEEK_BASE_URLhttps://api.deepseek.com WORDPRESS_SITE_URLhttps://your-site.com WORDPRESS_APP_PASSWORDxxxx xxxx xxxx xxxx这里有个小技巧DeepSeek 的 base_url 建议单独用环境变量维护不要硬编码。这样后面如果公司决定改用其他兼容 OpenAI 接口的服务只需要把 BASE_URL 换掉整个代码不用动一行。3.2 模型路由的完整实现路由层是整个系统的入口。我把它设计成一个装饰器风格的函数方便不同的任务调用时自动带上对应的模型参数。import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.getenv(DEEPSEEK_BASE_URL), ) def route_and_call(task_type, messages, **kwargs): config ROUTING_CONFIG[task_type] response client.chat.completions.create( modelconfig[model], messagesmessages, temperaturekwargs.get(temperature, config[temperature]), max_tokenskwargs.get(max_tokens, config[max_tokens]), ) return response.choices[0].message.content封装好之后调用一处统一的函数就行。举个例子生成 10 个标题prompt 你是资深 SEO 编辑。请为以下关键词生成 10 个吸引人的标题{keyword} messages [ {role: system, content: 你是一名资深 SEO 内容编辑擅长撰写高点击率标题。 }, {role: user, content: prompt.format(keyword宠物猫粮推荐)}, ] result route_and_call(TaskType.TITLE_GENERATION, messages)执行过程中我发现一个关键点不要在路由函数里做过多重试逻辑。比如 API 超时你要做的是抛异常让上层的任务调度器来统一重试。否则一旦某个模型持续不可用你的系统会卡在重试循环里看起来像死机了一样。重试逻辑放在更高一层import time def call_with_retry(task_type, messages, max_retries3, delay5): for attempt in range(max_retries): try: return route_and_call(task_type, messages) except Exception as e: print(fAttempt {attempt1} failed: {e}) if attempt max_retries - 1: raise time.sleep(delay)3.3 技能文件的加载与解析机制技能文件是 Markdown 格式加载逻辑很简单读取文件内容分装成 messages 系统提示词。但这里有一个细节处理得好不好直接决定输出质量系统提示词里应该放什么用户提示词里又该放什么。我的经验是技能文件的“任务描述”和“输出约束”部分放进系统提示词因为这两块是长期稳定的规则而“输入说明”对应的具体数据放进用户提示词因为每次任务的数据都不同。def load_skill(skill_name): with open(fskills/{skill_name}.md, r, encodingutf-8) as f: return f.read() def run_skill(skill_name, task_type, input_data): skill_content load_skill(skill_name) system_prompt skill_content # 整个技能文件作为系统提示词 user_prompt f以下是本次任务的数据\n{input_data} messages [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] result route_and_call(task_type, messages) return result踩过的一个坑是技能文件如果太长会挤占模型的上下文空间。尤其当输入数据本身很大时比如给你 200 个关键词做聚类关键词列表可能就占了 2000 个 token技能文件再加上示例又会占用一千多 token。这种情况下模型可能会因为上下文超限而输出截断。解决方法是给技能文件瘦身示例只保留一个其余参考信息通过“知识库检索”在运行时动态追加而不是把所有内容写死在技能文件里。3.4 智能代理的落地从 AI 输出到网站更新智能代理是整个流水线的最后一环。它的输入是 AI 的返回结果输出是真实的网站更新动作。我把它设计成“解析结果 → 生成任务列表 → 执行任务”三段式。以“批量更新旧文章标题”为例。输入是一批旧文章的 ID 和原标题输出是新的标题建议。智能代理要做的事情是解析 AI 返回的 JSON逐条取出文章 ID 和新标题。调用 WordPress REST API 逐篇更新。记录更新成功和失败的条目输出报告。import json def bulk_update_titles(title_result_json): data json.loads(title_result_json) updated, failed [], [] for item in data[updates]: post_id item[post_id] new_title item[new_title] try: resp requests.post( f{WORDPRESS_SITE_URL}/wp-json/wp/v2/posts/{post_id}, headersauth_headers, json{title: new_title}, timeout15, ) resp.raise_for_status() updated.append(post_id) except Exception as e: failed.append({post_id: post_id, error: str(e)}) return {updated: updated, failed: failed}这里有个很现实的经验批量更新类操作一定要做“预览模式”。可以先让智能代理把 AI 的结果输出成一个 CSV 文件人工抽查一遍确认标题风格没问题再通过一个开关参数决定是真正写入 CMS 还是只输出文件。我前面有次直接把 AI 输出的标题全部写入线上结果 AI 生成的标题里混了几个明显夸大的说法差点引来麻烦。后来改成“默认生成文件、手动开启写入”问题就好多了。3.5 实战案例关键词聚类到聚合页生成的完整流程把前面三层串起来看一个完整的实际案例。我给它起名叫“聚合页一键生成”。第一步输入一批原始关键词。比如你卖宠物用品想做一个“猫粮推荐”方向的聚合页群。原始关键词可能包括宠物猫粮推荐、猫粮什么牌子好、幼猫猫粮挑选、猫咪罐头测评、老年猫粮怎么选……第二步模型路由识别任务类型是 KEYWORD_CLUSTERING把任务发给 deepseek-chat同时加载“关键词聚类”技能文件。第三步AI 返回聚类后的 JSON 结果。每个分组包含组名、组内关键词、聚合页标题建议和描述建议。第四步智能代理扩展把分组结果写成一个 CSV 文件同时为每个分组调用“内容写作”技能生成聚合页的正文大纲。大纲再进入正文生成流程最终转成完整的 HTML 内容通过 WordPress API 创建为草稿。第五步站长登录后台浏览一遍草稿调整不满意的部分然后一键发布。这个流程跑通之后我半个月能产出 40 到 50 篇质量达标的聚合页内容。虽然和头部内容站动辄几千篇的数量级没法比但对一个中小型个人站来说已经是之前人力效率的三倍以上。4. 常见问题与排查技巧实录4.1 模型输出格式不稳定怎么办这是我遇到频率最高的一个问题。即便技能文件里明确写了“输出必须为 JSON不要输出其他内容”模型还是偶尔会手滑在 JSON 外面加一个 Markdown 代码块标记或者 在 JSON 前面加一句“好的以下是结果”。我的解法是双保险。第一道保险在技能文件里加一句“不要输出任何解释性文字只输出 JSON 对象本身。”第二道保险在解析环节做容错处理。用正则把代码块标记剥掉再尝试 json.loads。万一还是解析失败就把这条结果标记为“需人工处理”不要让程序崩溃。import re import json def safe_parse_json(raw_text): text raw_text.strip() text re.sub(r^(?:json)?\s*, , text) text re.sub(r\s*$, , text) # 去掉可能的解释性前后缀 try: return json.loads(text) except json.JSONDecodeError: # 取第一个 { 到最后一个 } 之间的内容 start text.find({) end text.rfind(}) 1 if start ! -1 and end start: return json.loads(text[start:end]) raise4.2 长文本生成中途被截断这个问题的根源是 max_tokens 不够。我们的内容写作任务设的是 4000 tokens但有时候 AI 在收尾时喜欢多写一段总结导致超限截断。排查办法是打开 API 返回的 finish_reason 字段。如果是 length说明是截断如果是 stop说明是自然结束。你可以在路由函数里把这个字段打印出来方便观察。response client.chat.completions.create(...) print(response.choices[0].finish_reason)如果频繁出现 length就需要调大 max_tokens或者把任务拆成两步先写大纲再按大纲分段写正文避免一次性生成长文。4.3 调用 WordPress API 时认证失败WordPress 的 REST API 认证有几个容易踩的坑。第一官方推荐用“应用程序密码”在用户资料页面生成格式是“xxxx xxxx xxxx xxxx”调用时用 Basic Auth 头。第二URL 必须用 httpshttp 会被拒绝。第三如果你用了 Cloudflare 之类的 CDN要先确保 REST API 的路径没有被缓存或者拦截否则会出现偶发性的 401。按照我自己的排查经验80% 的认证失败都出在密码格式、协议或 CDN 拦截上三分钟内基本能定位。4.4 模型路由调度的成本控制问题几个模型混用后最大的隐性成本风险是 max_tokens 设置过大。deepseek-chat 按 token 计费max_tokens 只是上限实际用多少扣多少看似没风险但如果你把 max_tokens 设置得很大模型可能会倾向于用满比如让它写 200 字的描述它给你写到 400 字。建议在路由配置里精确控制不同任务的 max_tokens并且定期看日志统计实际消耗及时调整。4.5 关于“消息工具调用需要立即返回”的报错这个报错的英文原文是 “messages tool calls need immediate results”在接入智能代理或者代码执行工具时比较常见。它背后的逻辑是当模型发出一个工具调用请求时你必须立刻把工具执行结果返回给它不能中间去做别的耗时操作。我在一次批量处理任务中遇到过类似的情况AI 请求调用某个工具但我的代理代码里该工具执行逻辑比较慢甚至依赖外部服务响应结果引发了这类报错。解决方式有两种第一种把工具调用改为“延迟执行”。即模型返回工具调用参数后不立即执行而是把参数存入队列由后台任务异步执行执行完毕后把结果补传给模型。第二种简化流程避免在同一个对话上下文中出现“需要持续往返多轮工具调用”的复杂场景。SEO 自动化的大多数任务并不需要 AI 自主决定多次调用工具更多是我预先定义好流程AI 只负责其中某一环的输出。所以把这个报错当作信号——如果频繁出现说明你的流程设计得过于复杂了建议拆成多个独立步骤而不是让模型在一个对话里反复调用工具。4.6 技能文件里示例越写越多反而越乱我一开始有个错误认知示例越多模型输出越准。后来发现完全不是这样。示例超过三个以后模型会“混淆”示例之间的关系有时候会把两个示例的格式杂交一下产出一个四不像。正确做法是每个技能文件只放一个高质量示例并且该示例尽量覆盖所有边界条件。比如我希望它输出的 JSON 包含一个“groups”数组那么这个示例里就一定要有多个 group而不是只有一个。这样模型就能直接模仿不会瞎编。5. 后续还可以这样扩展整套系统到目前为止已经在我的个人站点上稳定跑了三个月生成内容包括聚合页、FAQ 内容、元描述、内链锚文本建议以及旧文章标题优化方案。它的边际成本极低每篇内容的 token 成本折算下来不到一块钱这就是 DeepSeek 在这个场景下最大的价值。如果你想继续扩展还有几个方向可以尝试。一是接入 Playwright 之类的浏览器自动化工具让智能代理可以自动抓取搜索结果页面数据作为内容素材来源把“关键词 → 内容”的链路变成“关键词 → 搜索数据 → 内容”。二是把技能文件做成一个可共享的仓库。我和几个朋友现在就是这么干的——把各自调好的技能文件放回公共仓库里互相取用能省掉很多重复调 prompt 的时间。一个技能文件本质上就是一份“你希望 AI 怎么干活”的说明书代码重要但最终决定内容质量的往往是这份说明书。三是在模型路由层引入成本监控面板。每次调用结束后把 token 消耗、费用估算、耗时记录下来按任务类型做统计。它能帮你看清哪些任务花得值哪些任务该降配。这套方法论里我认为最值得带走的不是某一份代码而是一个思路AI 做 SEO 自动化质量天花板不取决于模型有多强而取决于你是否把任务拆得足够清晰。模型路由、技能文件、智能代理扩展三者本质上都是在回答同一个问题——“每一步该由谁来做、怎么做、做完了交给谁”。想清楚这个问题换什么模型都能跑起来。我自己现在的使用习惯是每次新开一个 SEO 项目先花半小时想清楚任务边界再去微调技能文件而不是急着写代码调 API。这个习惯帮我省下的返工时间远比任何技术优化都多。希望这篇内容也能帮你少走一段弯路。 DeepSeek驱动SEO自动化：模型路由、技能文件与智能代理实战指南
一次把 DeepSeek 折腾成 SEO 自动化流水线模型路由、技能文件与智能代理实战先交代背景。我手里有一个内容站日更压力大人工产出跟不上于是从去年底开始折腾 AI 生成、AI 改稿、AI 内链匹配这类活。试了一圈开源模型和各家 API 之后最终固定在 DeepSeek 上原因是它的输出质量、上下文长度和价格三者平衡得最好尤其适合 SEO 这种需要“批量产出但不追求单篇封神”的场景。这篇文章不是给你讲 DeepSeek 怎么注册、怎么调 API 那种入门教程而是把我最近搭的一套“DeepSeek 模型路由 技能文件 智能代理扩展”的 SEO 自动化工具链完整拆开。你如果也在做网站内容批量生产、聚合页生成、关键词聚类或者站内结构优化这篇内容可以直接抄作业。先说结论这套东西的本质是把 DeepSeek 从一个“聊天机器人”改造成一个“能自己判断该用什么模型、按什么流程干活、调用什么工具”的自动化引擎。核心就三块模型路由负责分流任务技能文件负责固化 SOP智能代理扩展负责把 AI 的输出真正落地成 SEO 动作。适合谁来读想用 AI 做 SEO 内容生产的个人站长、做海外站的内容运营、以及想给自己的工具链接入 DeepSeek 的开发者。不需要你有多深的算法背景但最好懂一点 Python知道 API 是什么否则后半部分读起来会有点吃力。1. 内容整体设计与思路拆解1.1 为什么是 DeepSeek 而不是其他模型先把选型逻辑讲清楚。SEO 自动化场景下模型要干的活往往不是“写出一篇惊世骇俗的文章”而是“稳定地产出 80 分以上的内容并且能听懂结构化指令”。我对比过几类模型模型优势在 SEO 场景下的问题闭源顶级模型理解力强指令遵循好贵批量调用成本扛不住开源小参数模型便宜可本地部署长文本生成容易跑偏结构化输出不稳定DeepSeek性价比极高上下文够长指令遵循能力强偶尔需要调参数部分场景要配合外部工具才能落地DeepSeek 最让我满意的点是它的 API 兼容性极好接入成本低到离谱。你不需要专门写一套 SDK 对接逻辑直接用 OpenAI 兼容的调用方式就能跑起来。这意味着我之前写的很多 SEO 脚本只需要把 base_url 改一下把模型名换成 deepseek-chat 或者 deepseek-reasoner立刻就能切过来。而且它的上下文长度足够长处理那种“给 20 个关键词批量生成 20 个标题加描述”的任务时可以一次性把指令和结构化输出格式都塞进 prompt 里不用频繁分片调用节省的不仅是 token还有我写代码的时间。1.2 SEO 自动化到底在自动化什么很多人一提“SEO 自动化”第一反应就是“用 AI 批量写文章”。这个理解太窄了。真正跑起来之后你会发现SEO 的活儿里写作只是最后一步前面还有大量的重复劳动关键词扩展与聚类把一个核心词拆成长尾词再按搜索意图分组。内容结构生成为每个聚合页生成标题、H1、H2 大纲、meta description。内链策略判断新文章应该从哪些旧文章出链、锚文本用什么。存量内容优化给旧文章生成新的标题建议、补充段落、FAQ 内容。结构化数据生成 JSON-LD 所需的 FAQPage、Article 等格式内容。这些任务的共同点是重复、有规律、但需要一定的语义理解能力。传统脚本干不了纯人工干太累正好是 DeepSeek 这类模型的舒适区。我设计的这套工具链就是把这五类任务全部拆成“模板 路由 执行”三步。模板负责定义输出格式路由负责决定用哪个模型执行环节通过智能代理扩展把结果写回数据库或者生成文件。1.3 三件套的分工逻辑路由、技能文件、智能代理这套系统里最难理解的一层就是它的分工逻辑我拿一个生活化的例子解释一下。假设你开了一家翻译公司手下有几个翻译一个擅长法律文书一个擅长技术文档还有一个擅长小说。客户来了之后你不能让所有稿件都扔给同一个翻译你得先看稿件类型分给对应的人。这里的“分稿员”就是模型路由。每个翻译手里都有一本自己的术语表和操作手册这就是技能文件。而翻译完成后帮你把文件归档、发送给客户、开具发票的那个助理就是智能代理扩展。模型路由Agent/Model Router做的事情就是判断当前任务属于哪一类然后把请求分发到最合适的模型上。比如简单的标题生成我用 deepseek-chat复杂的策略分析用 deepseek-reasoner本地的敏感数据处理交给本地小模型。技能文件Skill File则是一套预设的“提示词模板 输出格式约束 示例”组合体。它不是简单的 prompt而是把整个任务的执行步骤都固化下来了。比如我做关键词聚类技能文件里会包含输入格式说明、聚类规则定义、输出 JSON 结构示例、以及常见错误兜底逻辑。智能代理扩展Agent Extension是负责“动手”的那一层。AI 返回的结果往往只是文字不能直接当成 SEO 动作落地。比如 AI 说“应该给这篇文章加一个 FAQ 板块”智能代理会负责把这个 FAQ 板块真正插入到页面的 HTML 里并更新对应的结构化数据。2. 核心细节解析与实操要点2.1 模型路由从硬编码到智能分发先看模型路由这一层。最开始的版本我的代码里全是硬编码所有请求全部打到 deepseek-chat 上。后来发现一个问题有些任务虽然量大但对推理能力要求不高用更小的模型也能完成成本能省下三分之一而有些任务虽然量不大但涉及策略判断deepseek-chat 经常会给出平庸的回答必须上 deepseek-reasoner。于是我就做了一层简单的路由逻辑。核心思路是定义一个任务类型枚举不同类型的任务映射到不同的模型和参数。from enum import Enum class TaskType(str, Enum): TITLE_GENERATION title_generation OUTLINE_CREATION outline_creation CONTENT_WRITING content_writing KEYWORD_CLUSTERING keyword_clustering META_OPTIMIZATION meta_optimization STRATEGY_ANALYSIS strategy_analysis ROUTING_CONFIG { TaskType.TITLE_GENERATION: { model: deepseek-chat, temperature: 0.9, max_tokens: 200, }, TaskType.OUTLINE_CREATION: { model: deepseek-chat, temperature: 0.7, max_tokens: 800, }, TaskType.CONTENT_WRITING: { model: deepseek-chat, temperature: 0.8, max_tokens: 4000, }, TaskType.KEYWORD_CLUSTERING: { model: deepseek-chat, temperature: 0.3, max_tokens: 2000, }, TaskType.META_OPTIMIZATION: { model: deepseek-chat, temperature: 0.5, max_tokens: 500, }, TaskType.STRATEGY_ANALYSIS: { model: deepseek-reasoner, temperature: 0.4, max_tokens: 3000, }, }这套路由看起来简单但有几个细节值得说一下。第一temperature 的设置是有讲究的。标题生成类任务我故意调高到 0.9因为标题需要多样性同一个关键词要产出 10 个不同角度的标题温度低了会大量重复。关键词聚类则是相反temperature 调到 0.3因为聚类追求的是稳定、可复现的分类结果温度高了会导致同一批关键词每次分的组不一样。第二max_tokens 要按任务卡死。SEO 场景里最怕的就是模型生成到一半被截断尤其是内容写作一旦截断就是一篇文章废掉。我卡到 4000 是因为我的单篇文章正文基本控制在 3000 字以内加上标题和段落结构4000 个 token 有富余。你要是写长文这个值要相应调大。第三也是最容易踩坑的点不要在路由层面对 response 做太多假设。比如有些任务你需要 JSON 输出有些需要 Markdown有些只要纯文本。模型返回的格式会因为 prompt 的微小差异而变化所以路由层只负责“分发请求并拿到原始响应”格式清洗交给后面的技能文件执行层去做。2.2 技能文件把 SEO 作业 SOP 固化下来技能文件是这套系统里我花时间最多的一部分。它的本质是把“一个资深 SEO 编辑接到任务后怎么干活”的完整过程变成 AI 可以理解和执行的指令集。我给它定的结构包含四块任务描述、输入说明、输出约束、示例。我们拿“关键词聚类”这个技能文件来拆解。# 技能关键词聚类 ## 任务描述 将给定的关键词列表按照搜索意图进行分类每个类别中选出一个代表性关键词作为组名并为每组输出一个聚合页面的标题和描述建议。 ## 输入说明 输入为一个关键词列表每行一个UTF-8 编码关键词之间无其他符号分隔。 ## 输出约束 输出必须为 JSON 格式结构如下 { groups: [ { group_name: 代表关键词, keywords: [关键词1, 关键词2], page_title: 聚合页标题建议, page_description: 聚合页描述建议 } ] } 注意不要输出 JSON 以外的任何内容不要使用 Markdown 代码块包裹 JSON。 ## 示例 输入 宠物猫粮推荐 猫粮什么牌子好 幼猫猫粮挑选 猫咪罐头测评 输出 { groups: [ { group_name: 猫粮推荐, keywords: [宠物猫粮推荐, 猫粮什么牌子好], page_title: 2024年猫粮推荐指南铲屎官必看的选购策略, page_description: 从幼猫到成年猫从干粮到罐头一文看懂猫粮选购关键点。 } ] }看到这里你可能觉得这不就是个结构化 prompt 吗确实它和 prompt 在形式上很像但区别在于第一技能文件是独立的、可复用的文件。它不是写死在代码里的字符串而是以一个 单独 .md 文件的形式存放在技能目录下。这意味着你可以在不改代码的前提下随时调整某个技能的指令甚至可以让非技术人员直接编辑这些文件来优化 AI 的输出质量。第二技能文件之间可以互相嵌套引用。比如我在做“内容写作”技能时会在技能文件的内部引用“标题生成”技能的输出格式规范确保 AI 写出的大纲里的标题风格和单独生成标题时的风格保持一致。第三技能文件的核心价值在于统一输出格式。SEO 自动化和纯聊天最大的不同是你后面还有程序要处理 AI 的结果。如果 AI 这次输出 JSON 下次输出 Markdown你的解析脚本就会炸。技能文件把所有输出强行限定在固定结构里从源头规避了这个问题。2.3 智能代理扩展让 AI 从“动嘴”变成“动手”模型路由负责选模型技能文件负责教模型怎么回答问题但这两层都没办法真正让 AI 倒腾你的网站数据。比如 AI 说“建议给 A 页面加一个 FAQ 板块里面放这三个问题”怎么让这个建议变成现实我的做法是引入一个轻量级的智能代理扩展层。它的核心职责是解析 AI 的输出结果调用外部工具把结果落地。最简单的落地方式是文件输出。比如关键词聚类任务完成后AI 会返回一个 JSON 数组智能代理直接把这个 JSON 写到数据库里同时生成一个 CSV 文件供人工审核。这个逻辑不复杂简单但有效。稍微复杂一点的是和 CMS 对接。我自己的站点是 WordPress所以我直接用 WordPress REST API 作为代理的落地工具。AI 生成完文章内容之后代理负责调用 WordPress API 创建文章草稿并填入标题、正文、meta description、标签和分类。整个过程完全无人值守。import requests def publish_draft_to_wordpress(title, content, meta_description, tagsNone): wp_url https://your-site.com/wp-json/wp/v2/posts headers { Authorization: Bearer YOUR_APP_PASSWORD, Content-Type: application/json, } payload { title: title, content: content, status: draft, meta: { description: meta_description, }, } if tags: payload[tags] tags resp requests.post(wp_url, jsonpayload, headersheaders, timeout30) if resp.status_code ! 201: raise RuntimeError(fWordPress API error: {resp.status_code} {resp.text}) return resp.json()[id]架设智能代理时要特别注意一点它必须要有“失败时明确报错”的能力而不是静默吞掉异常。比如 WordPress API 返回 400 错误代理就应该把错误信息原样抛出来并带上 AI 生成的原文方便人工排查。否则哪天接口改了、字段名变了你的系统会“看起来在运行”实际上已经三天没发布过任何东西了。2.4 其中一个关键选择本地部署还是 API 调用聊到 DeepSeek很多人第一反应是问用官方 API 还是本地部署我的建议是SEO 自动化场景下默认用官方 API除非你有数据合规需求。原因有几个一是成本。DeepSeek 的 API 定价本身就极低批量生成场景下一个月几百块能撑起一个中小站点的内容更新量。你自己部署电费、显卡折旧、维护时间算进去成本反而更高。二是稳定性。官方 API 的可用性要比自己搭的 GPU 服务稳定得多。SEO 自动化最怕的就是半夜跑批任务时服务挂了第二天起来发现一篇文章都没生成白白损失一天。三是上下文能力。我自己试过本地部署 7B 和 14B 的模型长文本生成能力明显不如 DeepSeek 官方 API 的大模型版本。SEO 写作这种任务动辄需要几千 token 的上下文本地小模型很容易在写到一半时“忘记”前面的设定。当然本地部署也不是没有价值。如果你的业务涉及敏感数据或者需要在离线环境跑批量任务本地部署可以作为补充方案。我的做法是日常任务走官方 API只有涉及内部数据脱敏处理时才把任务路由到本地模型上。这就是模型路由的另一个价值场景——你可以混用多种来源的模型服务而不必被一家绑死。3. 实操过程与核心环节实现3.1 环境准备与工具链搭建开始之前把我用的环境列出来。我的主力机器是一台带 3060 显卡的台式机但说实话跑这套系统用不上显卡。因为所有重量级推理都在远程 API 上完成本地只跑流程编排和工具调用。能跑通的底配是一台 2 核 4G 内存的轻量云服务器装 Ubuntu 22.04 或者 Debian 12 都行Python 版本建议 3.10。代码层面核心依赖只有两个openai 库因为 DeepSeek 兼容 OpenAI 接口和 requests用于调用 WordPress API 和其他 HTTP 服务。不需要引入 LangChain 之类重型框架我们的任务用不到那么多抽象层自己写一个简单的循环反而更可控。pip install openai requests python-dotenv环境变量维护一个 .env 文件DEEPSEEK_API_KEYsk-xxxxxxxx DEEPSEEK_BASE_URLhttps://api.deepseek.com WORDPRESS_SITE_URLhttps://your-site.com WORDPRESS_APP_PASSWORDxxxx xxxx xxxx xxxx这里有个小技巧DeepSeek 的 base_url 建议单独用环境变量维护不要硬编码。这样后面如果公司决定改用其他兼容 OpenAI 接口的服务只需要把 BASE_URL 换掉整个代码不用动一行。3.2 模型路由的完整实现路由层是整个系统的入口。我把它设计成一个装饰器风格的函数方便不同的任务调用时自动带上对应的模型参数。import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.getenv(DEEPSEEK_BASE_URL), ) def route_and_call(task_type, messages, **kwargs): config ROUTING_CONFIG[task_type] response client.chat.completions.create( modelconfig[model], messagesmessages, temperaturekwargs.get(temperature, config[temperature]), max_tokenskwargs.get(max_tokens, config[max_tokens]), ) return response.choices[0].message.content封装好之后调用一处统一的函数就行。举个例子生成 10 个标题prompt 你是资深 SEO 编辑。请为以下关键词生成 10 个吸引人的标题{keyword} messages [ {role: system, content: 你是一名资深 SEO 内容编辑擅长撰写高点击率标题。 }, {role: user, content: prompt.format(keyword宠物猫粮推荐)}, ] result route_and_call(TaskType.TITLE_GENERATION, messages)执行过程中我发现一个关键点不要在路由函数里做过多重试逻辑。比如 API 超时你要做的是抛异常让上层的任务调度器来统一重试。否则一旦某个模型持续不可用你的系统会卡在重试循环里看起来像死机了一样。重试逻辑放在更高一层import time def call_with_retry(task_type, messages, max_retries3, delay5): for attempt in range(max_retries): try: return route_and_call(task_type, messages) except Exception as e: print(fAttempt {attempt1} failed: {e}) if attempt max_retries - 1: raise time.sleep(delay)3.3 技能文件的加载与解析机制技能文件是 Markdown 格式加载逻辑很简单读取文件内容分装成 messages 系统提示词。但这里有一个细节处理得好不好直接决定输出质量系统提示词里应该放什么用户提示词里又该放什么。我的经验是技能文件的“任务描述”和“输出约束”部分放进系统提示词因为这两块是长期稳定的规则而“输入说明”对应的具体数据放进用户提示词因为每次任务的数据都不同。def load_skill(skill_name): with open(fskills/{skill_name}.md, r, encodingutf-8) as f: return f.read() def run_skill(skill_name, task_type, input_data): skill_content load_skill(skill_name) system_prompt skill_content # 整个技能文件作为系统提示词 user_prompt f以下是本次任务的数据\n{input_data} messages [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] result route_and_call(task_type, messages) return result踩过的一个坑是技能文件如果太长会挤占模型的上下文空间。尤其当输入数据本身很大时比如给你 200 个关键词做聚类关键词列表可能就占了 2000 个 token技能文件再加上示例又会占用一千多 token。这种情况下模型可能会因为上下文超限而输出截断。解决方法是给技能文件瘦身示例只保留一个其余参考信息通过“知识库检索”在运行时动态追加而不是把所有内容写死在技能文件里。3.4 智能代理的落地从 AI 输出到网站更新智能代理是整个流水线的最后一环。它的输入是 AI 的返回结果输出是真实的网站更新动作。我把它设计成“解析结果 → 生成任务列表 → 执行任务”三段式。以“批量更新旧文章标题”为例。输入是一批旧文章的 ID 和原标题输出是新的标题建议。智能代理要做的事情是解析 AI 返回的 JSON逐条取出文章 ID 和新标题。调用 WordPress REST API 逐篇更新。记录更新成功和失败的条目输出报告。import json def bulk_update_titles(title_result_json): data json.loads(title_result_json) updated, failed [], [] for item in data[updates]: post_id item[post_id] new_title item[new_title] try: resp requests.post( f{WORDPRESS_SITE_URL}/wp-json/wp/v2/posts/{post_id}, headersauth_headers, json{title: new_title}, timeout15, ) resp.raise_for_status() updated.append(post_id) except Exception as e: failed.append({post_id: post_id, error: str(e)}) return {updated: updated, failed: failed}这里有个很现实的经验批量更新类操作一定要做“预览模式”。可以先让智能代理把 AI 的结果输出成一个 CSV 文件人工抽查一遍确认标题风格没问题再通过一个开关参数决定是真正写入 CMS 还是只输出文件。我前面有次直接把 AI 输出的标题全部写入线上结果 AI 生成的标题里混了几个明显夸大的说法差点引来麻烦。后来改成“默认生成文件、手动开启写入”问题就好多了。3.5 实战案例关键词聚类到聚合页生成的完整流程把前面三层串起来看一个完整的实际案例。我给它起名叫“聚合页一键生成”。第一步输入一批原始关键词。比如你卖宠物用品想做一个“猫粮推荐”方向的聚合页群。原始关键词可能包括宠物猫粮推荐、猫粮什么牌子好、幼猫猫粮挑选、猫咪罐头测评、老年猫粮怎么选……第二步模型路由识别任务类型是 KEYWORD_CLUSTERING把任务发给 deepseek-chat同时加载“关键词聚类”技能文件。第三步AI 返回聚类后的 JSON 结果。每个分组包含组名、组内关键词、聚合页标题建议和描述建议。第四步智能代理扩展把分组结果写成一个 CSV 文件同时为每个分组调用“内容写作”技能生成聚合页的正文大纲。大纲再进入正文生成流程最终转成完整的 HTML 内容通过 WordPress API 创建为草稿。第五步站长登录后台浏览一遍草稿调整不满意的部分然后一键发布。这个流程跑通之后我半个月能产出 40 到 50 篇质量达标的聚合页内容。虽然和头部内容站动辄几千篇的数量级没法比但对一个中小型个人站来说已经是之前人力效率的三倍以上。4. 常见问题与排查技巧实录4.1 模型输出格式不稳定怎么办这是我遇到频率最高的一个问题。即便技能文件里明确写了“输出必须为 JSON不要输出其他内容”模型还是偶尔会手滑在 JSON 外面加一个 Markdown 代码块标记或者 在 JSON 前面加一句“好的以下是结果”。我的解法是双保险。第一道保险在技能文件里加一句“不要输出任何解释性文字只输出 JSON 对象本身。”第二道保险在解析环节做容错处理。用正则把代码块标记剥掉再尝试 json.loads。万一还是解析失败就把这条结果标记为“需人工处理”不要让程序崩溃。import re import json def safe_parse_json(raw_text): text raw_text.strip() text re.sub(r^(?:json)?\s*, , text) text re.sub(r\s*$, , text) # 去掉可能的解释性前后缀 try: return json.loads(text) except json.JSONDecodeError: # 取第一个 { 到最后一个 } 之间的内容 start text.find({) end text.rfind(}) 1 if start ! -1 and end start: return json.loads(text[start:end]) raise4.2 长文本生成中途被截断这个问题的根源是 max_tokens 不够。我们的内容写作任务设的是 4000 tokens但有时候 AI 在收尾时喜欢多写一段总结导致超限截断。排查办法是打开 API 返回的 finish_reason 字段。如果是 length说明是截断如果是 stop说明是自然结束。你可以在路由函数里把这个字段打印出来方便观察。response client.chat.completions.create(...) print(response.choices[0].finish_reason)如果频繁出现 length就需要调大 max_tokens或者把任务拆成两步先写大纲再按大纲分段写正文避免一次性生成长文。4.3 调用 WordPress API 时认证失败WordPress 的 REST API 认证有几个容易踩的坑。第一官方推荐用“应用程序密码”在用户资料页面生成格式是“xxxx xxxx xxxx xxxx”调用时用 Basic Auth 头。第二URL 必须用 httpshttp 会被拒绝。第三如果你用了 Cloudflare 之类的 CDN要先确保 REST API 的路径没有被缓存或者拦截否则会出现偶发性的 401。按照我自己的排查经验80% 的认证失败都出在密码格式、协议或 CDN 拦截上三分钟内基本能定位。4.4 模型路由调度的成本控制问题几个模型混用后最大的隐性成本风险是 max_tokens 设置过大。deepseek-chat 按 token 计费max_tokens 只是上限实际用多少扣多少看似没风险但如果你把 max_tokens 设置得很大模型可能会倾向于用满比如让它写 200 字的描述它给你写到 400 字。建议在路由配置里精确控制不同任务的 max_tokens并且定期看日志统计实际消耗及时调整。4.5 关于“消息工具调用需要立即返回”的报错这个报错的英文原文是 “messages tool calls need immediate results”在接入智能代理或者代码执行工具时比较常见。它背后的逻辑是当模型发出一个工具调用请求时你必须立刻把工具执行结果返回给它不能中间去做别的耗时操作。我在一次批量处理任务中遇到过类似的情况AI 请求调用某个工具但我的代理代码里该工具执行逻辑比较慢甚至依赖外部服务响应结果引发了这类报错。解决方式有两种第一种把工具调用改为“延迟执行”。即模型返回工具调用参数后不立即执行而是把参数存入队列由后台任务异步执行执行完毕后把结果补传给模型。第二种简化流程避免在同一个对话上下文中出现“需要持续往返多轮工具调用”的复杂场景。SEO 自动化的大多数任务并不需要 AI 自主决定多次调用工具更多是我预先定义好流程AI 只负责其中某一环的输出。所以把这个报错当作信号——如果频繁出现说明你的流程设计得过于复杂了建议拆成多个独立步骤而不是让模型在一个对话里反复调用工具。4.6 技能文件里示例越写越多反而越乱我一开始有个错误认知示例越多模型输出越准。后来发现完全不是这样。示例超过三个以后模型会“混淆”示例之间的关系有时候会把两个示例的格式杂交一下产出一个四不像。正确做法是每个技能文件只放一个高质量示例并且该示例尽量覆盖所有边界条件。比如我希望它输出的 JSON 包含一个“groups”数组那么这个示例里就一定要有多个 group而不是只有一个。这样模型就能直接模仿不会瞎编。5. 后续还可以这样扩展整套系统到目前为止已经在我的个人站点上稳定跑了三个月生成内容包括聚合页、FAQ 内容、元描述、内链锚文本建议以及旧文章标题优化方案。它的边际成本极低每篇内容的 token 成本折算下来不到一块钱这就是 DeepSeek 在这个场景下最大的价值。如果你想继续扩展还有几个方向可以尝试。一是接入 Playwright 之类的浏览器自动化工具让智能代理可以自动抓取搜索结果页面数据作为内容素材来源把“关键词 → 内容”的链路变成“关键词 → 搜索数据 → 内容”。二是把技能文件做成一个可共享的仓库。我和几个朋友现在就是这么干的——把各自调好的技能文件放回公共仓库里互相取用能省掉很多重复调 prompt 的时间。一个技能文件本质上就是一份“你希望 AI 怎么干活”的说明书代码重要但最终决定内容质量的往往是这份说明书。三是在模型路由层引入成本监控面板。每次调用结束后把 token 消耗、费用估算、耗时记录下来按任务类型做统计。它能帮你看清哪些任务花得值哪些任务该降配。这套方法论里我认为最值得带走的不是某一份代码而是一个思路AI 做 SEO 自动化质量天花板不取决于模型有多强而取决于你是否把任务拆得足够清晰。模型路由、技能文件、智能代理扩展三者本质上都是在回答同一个问题——“每一步该由谁来做、怎么做、做完了交给谁”。想清楚这个问题换什么模型都能跑起来。我自己现在的使用习惯是每次新开一个 SEO 项目先花半小时想清楚任务边界再去微调技能文件而不是急着写代码调 API。这个习惯帮我省下的返工时间远比任何技术优化都多。希望这篇内容也能帮你少走一段弯路。