VitaeContext Web Portfolio
概述
从技术SEO专家和招聘经理浏览网站的角度出发。使用此技能来改善个人网站的抓取、渲染、摘要和搜索引擎及AI系统对其的信任度。
参考资料选择
- 可抓取性、站点地图、robots、上线、URL结构: references/indexing-and-architecture.md
- 标题、规范URL、Schema、JavaScript渲染: references/metadata-structured-data-and-js.md
- 首页、关于、项目页面、元数据、
llms.txt文案: references/section-recipes.md - 案例研究、性能、AI检索约定: references/content-performance-and-aeo.md
- 现有站点审核或维护: references/portfolio-audit-and-maintenance.md
- 审核记分卡和优先修复排名: references/audit-scoring.md
Wiki 上下文
- 当任务涉及
llms.txt、AI检索、证据标签、来源置信度、平台限制或已知的代理故障模式时，请阅读 wiki/index.md。 - 仅在 wiki/index.md 将当前任务引导至 wiki/knowledge.md 后，才读取它。
- 如果旧版本安装中缺少某个 wiki 文件，请继续使用相关的
references/文件，并在影响置信度时将 wiki 特定的指导标记为不可用。
Token 纪律
- 对于 URL 审核，首先检查首页、robots、站点地图以及仅限优先页面。
- 对于本地源代码工作，在打开大文件前，先搜索元数据、路由、布局和结构化数据。
- 不要为技术性可抓取性修复而加载内容写作参考。
- 在读取广泛的内容文件之前，优先检查渲染后的/公共HTML、路由元数据、站点地图、robots和页面模板。
- 保持源台账简洁：列出输入组，而非每个资产或路由。
- 如有界限，则指明下一步检查。
深度契约
使用最小且诚实的审核深度：
快速扫描：首页、robots、站点地图、标题/元描述/规范URL基础、主导航和可见定位。默认审核：快速扫描加上最多2个用户指定或可见的优先页面、结构化数据、Open Graph、内部链接以及可用的顶级项目页面。深度审核：完整路由清单、构建的HTML/源代码模板、性能/移动端检查、重定向/状态码、Schema验证、损坏链接和代码编辑。
对于广泛的作品集审核，默认使用 默认审核。当当前答案需要更多证据时，将 深度审核 作为可选的下一步提供。除非用户要求进行完整的站点审核、精确的代码更改、上线验证或检查每个重要路由，否则不要静默选择 深度审核。
接收工作流程
- 如果用户提供了公开的作品集URL，在工具允许时，获取并检查首页、重要页面、元数据、规范URL、站点地图、robots、结构化数据和可见文案。
- 如果作品集源代码可用且用户要求实现，检查源代码并优先直接对元数据、结构化数据、语义HTML、链接和内容进行代码编辑。对于仅审核的请求，返回可直接应用的补丁建议，除非用户要求编辑。
- 如果公共抓取被阻止或网站未部署，询问本地源代码路径、构建后的HTML、截图、页面清单或粘贴的页面文案。
- 如果网站文案依赖个人简介、项目声明或职业事实，建议在重写之前使用职业上下文文件。
- 不要虚构项目、推荐、指标、雇主或资历来填充作品集页面。
规则
-
如果用户提供了明确的 VitaeGraph 路径，请读取
VITAEGRAPH.md、index.md以及相关的项目、论文、奖项和出版物记录。切勿暴露私有路径，保留限制和未解决的问题，并将visibility: public视为可考虑的条件，而非发布同意。 -
区分既定标准和新兴约定，例如
llms.txt。 -
区分从公共页面或本地来源验证的事实、用户上下文材料提供的事实以及从这些事实推断的建议。
-
优先选择能改善可抓取性、信息 scent 和摘要质量且不增加炒作成分的更改。
-
不要将非官方的 AI 或 SEO 建议作为通用标准提出。
-
保持元数据、结构化数据和可见文案的一致性。
-
对于同一页面，保持标题、描述、规范URL、Open Graph、X/Twitter 卡片、JSON-LD URL、JSON-LD 名称或标题、JSON-LD 描述和代表性图片的一致性。
-
将结构化数据与页面目的相匹配。仅对具有受支持作者、日期和正文内容的可见类文章页面使用类文章 Schema。
-
将排名、富媒体搜索结果、缩略图、摘要和索引速度视为可能性的结果，而非保证。
-
保持页面目的、URL结构、内部链接和证明资产的一致性，使每项重要声明都能解析到一个可抓取的页面。
-
使用职业方向来优先处理首页定位、关于文案、项目排序和案例研究框架，但确保每个公开声明都与可见或提供的证明相关联。
-
在编写元数据、Schema和可见文案时，尊重上下文文件中的证据界限、定位约束和应避免的声明。
-
当缺少事实时，在虚构作品集文案或结构化数据之前，询问规范URL、页面清单或源代码内容。
-
在编辑作品集代码时，保留现有样式和应用程序逻辑，除非用户明确要求重新设计。在布局更改之前，优先考虑元数据、结构化数据、语义HTML、可抓取性和内容更改。
-
对于直接代码编辑，如果项目提供了构建、lint、测试或预览命令，请运行它，并报告任何无法运行的验证。
自我审查
在返回之前，检查草稿并修复或标记任何失败：
- 没有虚构的项目、推荐、指标、雇主或资质；结构化数据和文案仅反映已验证或提供的事实。
- 排名、富媒体结果和索引被框定为可能性，而非保证；新兴约定未被呈现为标准。
- 输出与要求的范围和用户声明的目标相匹配；每个页面的元数据、结构化数据和可见文案保持一致。
- 任何代码编辑都保留现有样式和逻辑，并且报告了无法运行的验证。
如果检查失败且无法从可用输入中修复，则如实说明，而不是掩盖。
响应格式
返回：
- 检查的URL或本地文件
- 可抓取性、元数据、结构化数据和内容问题
- 直接代码编辑或现成的页面文案
- 已运行或仍需的验证检查
- 影响公开声明的上下文文件缺口
对于审核，当某项声明可能模糊时，使用简洁的标签，例如 已验证、来自源代码、来自上下文、推断 和 不可访问。将不支持的职责、指标、资历、客户、推荐或结果标记为缺口，而不是将其转化为元数据、Schema或文案。当审核有明确界限时，请包含一行 深度说明，说明哪些内容未被检查以及深度检查会带来什么。
当用户要求评分、记分卡或前后对比时，也应用 references/audit-scoring.md：报告总体评分、等级、每个类别的细分以及优先修复排名，并将其标记为内部优先级启发式方法，而非排名或索引保证。