treg 程序化 SEO 上线计划：从数据富集集群到 Workflow 页面的分波次落地实录

后端API网关MCP 服务dsh-plugin【免费下载链接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn项目地址https://gitcode.com/GitHub_Trending/treg/treg点击查看免费下载本文以 treg 仓库内marketing/pseo-ship-plan.md为骨架结合docs/context/interface/seo.md与src/treg/agent_pages.py中已经落地的实现梳理 treg一个面向 Agent 的工具/数据 API 网关产品定位 OpenRouter for agent tools在 2026 年 8 月制定的程序化 SEOpSEO上线计划。读者将看到每类页面的真实生产成本、按搜索需求排序的三个上线波次、作为全新页面形态的/workflows/slug工作流页面的数据结构与运行收据机制以及贯穿始终的索引验收门槛与内容红线。读完可以复用它先做一个完整集群、提交目录、测量后再扩张的冷启动方法论。一、背景为什么是写完剩下的而不是再写新模板2026 年 08 月 21 日treg 已经上线了/agents/chatgpt和/use-cases/data-enrichment-sales/find-professional-emails两个页面。模板代码存在、测试通过剩下的工作全部是内容——而内容是最慢的部分。整个计划由三份文档支撑marketing/pseo-catalog-plan.md程序化页面的总体设计借鉴 Pipedream、Blotato 的机制分析与 treg 自身数据marketing/_review-codex-seo-plan.md独立审查意见核心结论是先交付一个完整集群并提交再扩张而非一次性铺开 250 URLmarketing/pseo-ship-plan.md本计划本身——排期与验收门槛。计划的执行理念非常明确页面成本中机器工作已经归零瓶颈是手写内容与验证所以整个排期围绕写作与核验展开而非围绕代码。二、每类页面现在的成本约束是写作与核验计划开篇给出了一张成本表说明三类页面的生产构成页面类型机器工作手写工作单页耗时Agent 页/agents/agent无模板直接渲染1 条字典记录标题、定义、4 步安装、4 条 FAQ 回答、1 张截图约 45 分钟Use-case 页/use-cases/job无1 条字典记录一句话、标题、lede、prompt、3 条为何有效、3 条差异说明、什么是 X、4 条 FAQ、related约 60–90 分钟因为差异说明需要真正阅读各家 provider 的文档Workflow 页/workflows/slug新模板见下文工作流本身 完整跑通一次取决于真实运行注意 use-case 页的耗时明显更高它的what differs差异说明不是模板字段而是阅读 provider 文档后的判断这正是它无法被自动化生成、也无法被竞品复制的部分。从源码看这种手写内容与模板渲染分离的架构在src/treg/agent_pages.py中体现得淋漓尽致该模块自述为 The hand-written half of the per-agent pages刻意不引入重依赖保持轻量 CLI 安装成本把编辑文案与路由代码隔离开来让人可以不读路由代码就审查全部编辑内容。三、Wave 1先完成一个已建了一半的集群本周Codex 审查的核心意见是交付一个完整集群、提交目录、然后再扩张。选中的集群是数据富集data enrichment理由有三provider 数量最多、买家最清晰、且第一页已经存在。Wave 1 的具体任务清单7 项/agents/claudeClaude.ai 的 Connectors 流程附连接器对话框截图使用与 ChatGPT 页相同的提示词/agents/claude-codetreg mcp install命令附安装后终端截图/agents/cursor同一命令附 Cursor 的 MCP 设置截图按需求排序新增四个富集 use-case 页verify-an-email-before-you-send5 个 provider——与邮箱查找配对是显而易见的下一步点击enrich-a-person-from-an-email-or-linkedin-url13 个 providerfind-people-by-role-company-or-location15 个 providerenrich-a-company-from-its-domain19 个 provider为集群建workflow 页见下文提交到目录mcpservers.org、PulseMCP、Glama、Smithery、Docker MCP hub、Anthropic 的 connector 目录并在 ChatGPT 插件列表的描述中链接/agents/chatgpt。第 14 天验收门槛Gate at day 14七页是否全部被索引且 GSCGoogle Search Console是否出现email finder api、linkedin email finder、chatgpt plugin、claude connectors的展示量。如果什么都没有被索引先停止写作修复抓取问题——这是内容问题 vs 抓取问题的早期诊断分水岭。四、Wave 2两个有实测搜索需求的集群第 2–4 周Wave 2 的前提是 Wave 1 成功被索引。每个集群由一张定价/对比页加上三四张 use-case 页组成。4.1 YouTube 视频集群在 X/Reddit 研究里获取视频字幕transcripts是被提及最多的单一任务16 篇帖子而且人们反复在自托管上失败。规划页面get-a-video-s-transcripta-channel-s-profile-and-lifetime-statssearch-videos-and-channels-by-keyworda-video-s-commentsWave 2 进度2026-08-21 更新YouTube 集群实际交付了5 页而非计划的 4 页——video-details-views-and-stats顺带上线因为它的配额论证与其余页面相同。计划同时公布了通过自有 Google Ads 端点实测的美国月度搜索量数字用于标题选词不是营销话术值得瞄准youtube transcript110,000 ·get youtube transcript2,400 ·youtube channel stats1,300 ·youtube data api1,000 ·youtube transcript api880 ·youtube video statistics590 ·youtube keyword search tool480 ·youtube scraper390 ·youtube comment scraper210 ·youtube search api170 ·youtube mcp server140明确放弃youtube video stats api0、youtube channel data api0、youtube subscriber count api10、youtube video details api10、youtube metadata api10、youtube channel api30由此提炼出可复用的选词规律买家输入事物 动词get youtube transcript或 scraper而不是事物 api唯一的例外是事物本身就是命名产品时youtube data api。这与富集集群的规律完全一致。集群还剩两个待办trending-videos和transcripts-of-x-and-facebook-video-posts。发现了一个需要人工处理的目录缺口Catalog gaptikhub.x.youtube-web-search-channel被映射到 capabilityyoutube.search.channels但它实际是按 id在单个频道内部搜索Search within a YouTube channel by keyword这与按关键词找频道是两回事。它在/use-cases/youtube-video/search-videos-and-channels-by-keyword页面上渲染成一行该页面的 FAQ 现在直接点明这一区别而不是掩盖它。真正的跨频道搜索是tikhub.x.youtube-web-v2-search-channels。处理方式是二选一重新映射该端点或给频道内搜索单独一个 capability。相关目录定义见src/treg/catalog/tikhub.yaml。4.2 连接你自己的账户Connect your own accounts集群这是总体需求最大的集群约 32 篇帖子而且每一行都是免费的——这是最强的卖点。规划页面search-console-queriesgoogle-analytics-reportsgoogle-ads-search-termsgoogle-business-reviews-and-replies这些是单 provider 页面因此采用短表单short formprompt、为何有效、连接步骤、参数、一次调用、FAQ。没有对比区。五、Wave 3其余集群按需求排序而非目录规模第 5 周起SEO8 个任务· Social9· Local businesses4· Finance7· E-commerce4· Advertising3· Market research3。写作顺序完全由实测关键词量决定一旦某个集群的前几页停止获得展示量就立即停止向该集群添加页面。这是有测量就前进、无测量就停手原则的延续。剩余的 agent 页opencode、codex、gemini-cli、openclaw、hermes、pi作为一批以noindex方式发布在/agents目录页之下只有当某个 agent 有独特安装路径、值得单独一页时才逐个转为可索引。原因很直接十个近乎相同的页面正是 Codex 审查标记的薄内容thin content风险。这一设计在docs/context/interface/seo.md的 agent 页章节中有对应实现说明/agentshub 为每个客户端一张卡片来自agent_pages.AGENTS未知 agent 直接 404。六、新事物Workflow 页面/workflows/slug这是本计划的核心创新值得单独成节。Use-case 页回答一个任务Workflow 页是一个真实的人会运行的序列——每一步的 prompt、结束时花了多少钱、以及输出怎么用。文档给出的定位是这是能赢得链接的形态因为它在自身价值上真正有用而且无法从某个 vendor 的文档重新生成。第一个 workflow 是/workflows/find-and-verify-a-lead-list数据富集计划中的五步骨架Step 1 Build the list companies.search 50 Series-A SaaS companies in the US, 50-200 staff Step 2 Find the people people.search the VP of Marketing or Head of Growth at each Step 3 Find the emails people.email.find their work emails, cheapest verified provider Step 4 Verify people.email.verify drop anything not deliverable Step 5 Enrich for the copy companies.news any funding or product news in the last 90 days Output a CSV, and the total cost printed by the agent每一步都链接到自己的 use-case 页——workflow 页就是那些辐条spokes一直缺失的轮毂hub。页面承载内容包括一条粘贴即用的完整 prompt跑通整个流程带每步价格的步骤表一个带真实数字的实例在 50 行数据上跑一次公布实际花费失败模式catch-all 域名、小公司查无结果等本次运行的 CSV。计划中的后续 workflow每集群一个/workflows/weekly-seo-reportSearch Console 关键词量 SERP 外链、/workflows/find-creators-to-sponsor搜索、档案、互动、联系、/workflows/watch-a-competitor广告库 帖子 新闻 招聘。成本估算workflow 页需要一次真实运行因此需要账户余额。上述 lead-list 运行大致为 50 次公司查询 50 次人物搜索 50 次邮箱查找 50 次验证合计约$3–6。6.1 仓库中的 Workflow 实现证据计划发布后/workflows页面已经在代码库中落地数据结构与计划完全对应。在src/treg/agent_pages.py中WORKFLOWS是一个以 slug 为键的字典4468 行起每个 workflow 含sentence、title、lede、prompt、prompt_why、steps、run、failure_modes、faq、related等字段steps是(name, capability id, agent 实际问的问题, 运行使用的端点, 一句话原因)五元组与计划中的表格一一对应once元组标记每次运行只调用一次而非每行一次的端点如 Apollo 的列表页按页计费50 家公司只算一次费用防止页面把 50 倍的列表价格算进总额decision步骤typesafe.jev是判断而非抓取jev 读取前序步骤拿到的行数据并返回概率其费率不来自目录而是单独存放在DECISION_STEPS每条 verdict 约 $0.00002这正是计划中每步价格从目录实时拉取规则的例外。6.2 真实运行收据Run Receiptfind-and-verify-a-lead-list在 2026-09-23 重新运行加入了两个 jev 决策步骤Apollo 列表之后的 ICP 门槛、新闻步骤之后的 opener 打分实际收据Apollo 匹配 958 家公司取第一页 50 家一次计费 $0.02648/50 行有可用域名27/48 通过 jev 门槛≥50%21 家在进入任何付费步骤前被丢弃60% 门槛则只会保留 14 家27/27 找到具名营销负责人Findymail 20 家、LeadMagic 角色查找 7 家21/27 找到工作邮箱Hunter 18 家、Kitt 补 Hunter 漏掉的 3 家Tomba 当天容量不足20/21 验证为可投递1 个未知0 个无效19/21 有过去一年的新闻事件PredictLeads19/19 完成 opener 打分4 个评分为良好或以上0–3 分制均值 1.79jev 两个步骤共 67 次判定、55,009 输入 token按挂牌价 $0.0023走团队自有 key不计费四路并行耗时约 5 分钟门槛环节 48 家公司花 90 秒总计费 $2.33即每可投递 lead $0.12被丢弃的 21 行若按本次费率全跑约需再加 $1.79。收据与 2026-08-26 的首次运行形成对比同筛选条件无门槛时花了 $3.62、产出 27 个 lead$0.13/个本次 $2.33、产出 20 个$0.12/个且 21 家公司从未进入付费步骤。CSV 存放在src/treg/workflow_runs/find-and-verify-a-lead-list.csv注意该 CSV 只含行级结果——person_found、finder、verdict、catch-all、news从不包含姓名、职位或地址因为这些都是真实的人而某公司 职位足以定位到个人。截至 2026-09-14代码库中已上线六个 workflowlead list 之外还有 creator 发现、creator 筛选、关键词需求到广告预算、竞品 Meta 广告、TikTok小红书品类情报SEO 批次全部通过 treg CLI 在 2026-09-14 真实运行并有 CSV。docs/context/interface/seo.md记录了配套测试test_workflow_page_is_served_with_the_crawler_essentials抓取管道、HowTo schema、.md、.csv、hub、301、sitemap、test_every_workflow_step_capability_and_endpoint_exist、test_no_workflow_ships_with_an_empty_section、test_every_workflow_run_has_its_csv_on_disk等——收据背后没有文件正是这些页面要避免的伪造运行失败。七、每页发布的常设规则Standing rules计划为每一页设定了六条不可违背的规则页面上不允许出现目录catalog产不出的事物手写 notes 除外——notes 必须点名 provider 事实并在verified状态变化时重新核验禁用破折号em-dash测试强制。对应测试见tests/test_agent_pages.pyHouse style: no em-dashes in page copy与tests/test_blog.py每个 use-case 页prompt 在最前对比放在agent 能看到什么之后按 vendor 的观测统计observed stats已获批准Jason2026-08-21但必须附带这是真实流量不是受控基准的免责声明.md镜像自动发布llms.txt见src/treg/web/llms.txt只链接/agents/chatgpt页面没有截图就不算完成。图片位为空就发布无图版本绝不放占位符。这几条规则与marketing/pseo-catalog-plan.md中页面是目录的函数noindex 直到需求被证明等决策一脉相承也与 Codex 审查的可防御页面标准独立查询任务、答案优先、来源可溯、可复现的归一化方法、可运行示例、改变买家选择的事实差异、人工审核推荐吻合。八、什么情况会触发停止并重新规划计划明确写下了三个触发点构成了整个扩张策略的止损机制第 14 天什么都没被索引→ 这是抓取问题不是内容问题修抓取而不是继续写页面第 30 天已被索引但全部七个 Wave 1 页面零合格展示量→ 关键词选错了加更多页面无法修复回到关键词测量第 30 天有展示量但没有安装启动→ 页面吸引来的读者并不想要插件重写页首而不是继续加页面。这一止损框架与_review-codex-seo-plan.md的建议一致第 14 天适合做抓取/索引诊断第 30 天适合检查目标查询族是否带来合格展示量但不应以单一 top-30 排名作为低流量新域的二元裁决——应综合索引覆盖率、目标查询份额、展示趋势、CTA/安装启动与首次调用而重复调用价值才是第 60/120 天的业务检验。九、从计划到实现这套方法论可复用的四个要点按需求分波次而不是按目录规模Wave 1 选 provider 最多、买家最清晰、已有第一页的集群Wave 2 只做有实测搜索需求的集群Wave 3 每加一页都由测量结果驱动集群一停止赚展示量就停止加页。先跑通一个真实集群并提交目录再横向复制页面类型是否值得规模化取决于查询匹配 成功重复调用是否都被证明而不是模板是否写完了。Workflow 页是以真实运行为内容的形态每步价格从目录实时拉取、收据与 CSV 来自一次带日期的真实运行、绝不写没有运行支撑的页面——这让页面无法被 vendor 文档重新生成也天然赢得外部链接。用验收门槛把写更多和修问题区分开第 14 天看索引、第 30 天看展示量与安装启动每个触发点对应一个明确的修复动作避免在错误方向上堆量。赞分享后端API网关MCP 服务dsh-plugin【免费下载链接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn项目地址https://gitcode.com/GitHub_Trending/treg/treg点击查看免费下载相关推荐Civitai 生态 SEO Hub 页实战基于 ecosystem-seo-page Skill 的程序化 SEO 落地页生成工作流Civitai 生态 SEO Hub 页实战基于 ecosystem seo page Skill 的程序化 SEO 落地页生成工作流 本篇技术指南围绕 Ci后端前端AI 应用Front-End-Checklist 服务区域页面Service-Area Pages本地 SEO 实战指南从 doorway 页红线到 LocalBusiness areaServed 落地Front End Checklist 服务区域页面Service Area Pages本地 SEO 实战指南从 doorway 页红线到 LocalBuAdd LocalBusiness 结构化数据从 Schema 编写到本地 SEO 落地实战Add LocalBusiness 结构化数据从 Schema 编写到本地 SEO 落地实战 本文以 Front End Checklist 仓库中的 loc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考