用途
LLM Friendly Site Optimizer 是一个战术层面的内容与引用优化技能，旨在让网站成为 AI 助手和 RAG 系统的高质量、可引用来源。它通过对齐技术可发现性、干净抽取、答案型内容、结构化数据、外部信号与监控，提升站点被 AI 引用和检索的概率。
该技能定位为现有架构技能之上的内容/引用层，与以下技能分工：seo-llm-site-architect 负责抓取/索引架构、元数据、规范 URL、schema 策略、站点地图、robots、爬虫策略与搜索监控；ui-ux-llm-product-architect 负责用户旅程、页面 UX、无障碍、语义控件、视觉层级与渲染可读性；web-security-architect 负责隐私、公开/私有内容边界、CSP/CORS/cookie/认证、密钥与安全的 AI/Agent 执行边界。冲突规则明确：安全、隐私、无障碍、可见内容真实性以及规范 SEO 架构，优先级高于 LLM 引用策略。不得创建仅对爬虫可见的隐藏声明、暴露私有内容，或添加未在可见页面中体现的 schema。
主要能力
技能提供多种操作模式：
audit：执行 Step 0 和 Step 1，产出带评分的差距报告和优先级行动计划。
llms-txt：依据站点真实的规范高信号页面创建或更新 /llms.txt。
pillar-plan：构建主题到 URL 的矩阵，并排列现有与新建支柱页面的优先级。
pillar-page：使用理想的 LLM 引用模板创建或改写单个页面。
schema：添加或修复 Article/NewsArticle/TechArticle/FAQ/Breadcrumb/WebSite/Software 等 schema。
monitoring：创建或更新 LLM 引用追踪表与每周查询集。
implementation：检查仓库并进行限定范围的代码/内容修改，然后验证。
使用方式
技能默认在用户未提供目标画像时使用以下配置：site_url 为 "https://mlllm.io"，site_language 为 "ru/en"，site_niche 为 "AI news + builder lab"，target_audience 为 "AI/ML developers, technical product managers, and system architects"，top_topics 包含每日开发者 AI 新闻、实用 MCP agent 栈架构、用 RAG 和 LLM 构建 AI 新闻 Telegram 机器人、自主 AI agents 与任务编排、开源 LLM 工具与基准等。
Step 0 强制审计要求先完成清单检查，并将每项标记为 OK（已实现并验证）、PARTIAL（存在但不完整、过时或不一致）、MISSING（缺失或损坏）、N/A（与站点/页面类型无关）。对每个 PARTIAL 或 MISSING 项，需给出具体修复方案：文件/路由、建议文本、schema 字段或实现动作。在可用 URL 时运行辅助脚本：
python3 $CODEX_HOME/skills/llm-friendly-site-optimizer/scripts/audit_llm_friendly_site.py https://mlllm.io --max-pages 20
然后阅读 references/audit-checklist.md 获取完整清单。
Step 1 优化 llms.txt：以严格 Markdown 创建 /llms.txt，包含站点名称、1-3 句具体描述（面向谁、覆盖什么、权威性来源）、关键区块链接列表、面向 AI 助手的最佳用途映射，以及“不要使用”列表。规则包括：站点描述控制在 150 词以内；仅包含规范、公开、有用的页面；不包含私有、内部、草稿、管理、认证、预发布、调试或废弃 URL；关键支柱页面变更或新增时更新；将 llms.txt 视为新兴约定，而非保证排名/引用的机制。可使用 assets/llms.txt.mlllm.template 作为起步模板。
Step 2 理想支柱页面：每个目标页面应结构化为自包含答案，包括：H1 为具体问题或陈述而非模糊标题；H1 下方紧接 2-4 句或 3-5 个要点的直接回答；带具体事实的 TL;DR/短摘要；H2/H3 章节中每个 H2 独立回答子问题；在有用处使用列表、表格、图表、代码块与示例；可见的发布与更新日期；带资料链接的作者/来源；至少 3 个长尾问题及直接回答的 FAQ；指向 2-3 个相关页面的内部链接；指向权威来源（官方文档、GitHub、arXiv、标准、一手来源）的外部链接；与可见内容匹配的 JSON-LD。分块规则：每个 H2 章节在被单独抽取为 512-1024 token 的 RAG 块时仍应成立。不得使用隐藏的 display:none AI 专用摘要作为独立事实层；优先使用所有用户可读的可见“Summary for AI assistants”或常规 TL;DR/Key facts 区块。可参考 references/pillar-page-template.md。
Step 3 结构化数据：使用 JSON-LD 并保持与可见内容一致。新闻页面用 NewsArticle 或 Article；教程/解释器用 TechArticle 或 BlogPosting；FAQ 区块仅在 FAQ 内容可见时使用 FAQPage；嵌套页面用 BreadcrumbList；首页仅在存在站点搜索时使用 WebSite 与 SearchAction；项目/工具页面在存在真实项目/工具时使用 SoftwareApplication 或 SoftwareSourceCode。添加 schema 前阅读 references/schema-minimums.md。
Step 4 主题捕获策略：对每个 top_topics 条目，创建一个真实用户会向助手提出的目标问题；映射最佳现有 URL 或将新页面标记为必需；选择页面类型（每日/新闻枢纽、指南、架构解释、构建日志、基准/工具页面、对比或 FAQ）；根据业务相关性、现有证据、引用缺口和原创内容产出能力进行优先级评分。输出矩阵格式为：| Target question | URL | Status | Priority | Required action |。可使用 assets/topic-matrix.template.md。
Step 5 外部信号：为每个支柱页面提出具体投放位置，包括解释实现的 GitHub README/Wiki/docs、在工件确实有用时的 Hacker News Show HN/Ask HN、相关且非垃圾的 Reddit 社区（如 r/LocalLLaMA、r/MachineLearning、r/programming）、带具体架构/内容摘要的 X/Twitter 线程、带规范链接指向原文的 dev.to、Habr 或技术博客，以及页面适配时的 Awesome 列表或精选 GitHub 资源。使用上下文链接而非裸 URL。参考 references/external-signals-monitoring.md。
Step 6 LLM 引用监控：创建每周追踪表，字段为 date,assistant,query,cited_url,snippet,rank_in_answer,notes。对每个 top topic 测试：“How do I solve/build/understand [topic]?”、“What resources do you recommend for [topic]?”、“Explain [topic] with sources.”。追踪支持搜索的 ChatGPT、Perplexity、支持搜索的 Claude、Gemini/Google AI 功能、Copilot/Bing 以及与受众相关的细分助手。仅在可用时使用浏览器/搜索工具，并清晰标注人工观察。
Step 7 最终 QA：发布或标记页面优化完成前，确认 H1 是具体问题或陈述；首屏包含直接回答/TL;DR；每个 H2 块可抽取且有意义；FAQ 至少 3 个真实问题及可见回答；日期与作者/来源可见并存在于元数据/schema；meta description 使用答案公式（受众 + 内容 + 目的）；规范 URL 正确；JSON-LD 可解析且与可见内容匹配；页面出现在站点地图和 /llms.txt 中；尊重安全/隐私边界；在给定 URL 或渲染文本时，LLM 能正确总结页面。
适用场景
适用于技术内容站点，尤其是面向 AI/ML 开发者、技术产品经理与系统架构师的 AI 新闻、教程与工具类网站，希望提升其在 AI 助手与 RAG 检索中的可引用性。也可用于内容审计、llms.txt 编写、支柱页面规划与改写、结构化数据修复以及引用监控。
限制
安全、隐私、无障碍、可见内容真实性与规范 SEO 架构优先于 LLM 引用策略；不得创建隐藏的仅爬虫可见声明、暴露私有内容或添加与可见页面不符的 schema。llms.txt 属于新兴约定，不保证带来排名或引用。审计、监控等步骤中涉及人工观察与可用工具限制，缺失事实需明确标注。具体价格、收费模式与平台支持信息暂未提供。