VitaeContext 網站作品集優化 是做什麼的？
概述
以技術SEO專家和招聘經理瀏覽網站的視角來審視作品。使用此技能來改善個人網站被搜尋引擎和AI系統爬取、渲染、摘要和信任的方式。
參考資料選擇
- 可爬取性、網站地圖、robots.txt、上線、URL結構：references/indexing-and-architecture.md
- 標題、標準標籤、結構化資料、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 的指引為不可用。
令牌使用紀律
- 對於URL審計，僅先檢查首頁、robots.txt、網站地圖以及優先頁面。
- 對於本地原始碼工作，在開啟大型檔案之前，先搜尋元資料、路由、佈局和結構化資料。
- 不要為了解決技術性可爬取問題而載入內容撰寫參考資料。
- 在讀取廣泛的內容檔案之前，優先檢查渲染後的公開HTML、路由元資料、網站地圖、robots.txt和頁面模板。
- 保持原始碼紀錄清單簡潔：列出輸入群組，而非每個資產或路由。
- 如果範圍受限，則指明下一步要檢查的項目。
審計深度約定
使用最小且誠實的審計深度：
快速掃描：首頁、robots.txt、網站地圖、標題/元描述/標準標籤基礎、主要導覽和可見定位。預設審計：快速掃描加上最多2個使用者指定或明顯優先的頁面、結構化資料、Open Graph、內部連結，以及（若有的話）頂級專案頁面。深入審計：完整路由清單、建置後的HTML/原始碼模板、性能/行動裝置檢查、重新導向/狀態碼、結構化資料驗證、無效連結和程式碼編輯。
對於廣泛的作品集審計，預設使用 預設審計。當目前答案可從更多證據中獲益時，提供 深入審計 作為可選的下一步。除非使用者要求進行完整的網站審計、確切的程式碼變更、上線驗證或檢查每個重要路由，否則不要默默地選擇 深入審計。
接收工作流程
- 如果使用者提供了公開的作品集URL，在工具允許的情況下，請獲取並檢查首頁、重要頁面、元資料、標準標籤、網站地圖、robots.txt、結構化資料和可見文案。
- 如果作品集原始碼在本地可用且使用者要求實作，則檢查原始碼並優先對元資料、結構化資料、語意化HTML、連結和內容進行直接程式碼編輯。對於僅審計請求，則返回可立即套用的補丁建議，除非使用者要求編輯。
- 如果公開爬取被阻擋或網站尚未部署，請詢問本地原始碼路徑、建置後的HTML、螢幕截圖、頁面清單或貼上的頁面文案。
- 如果網站文案依賴於個人簡歷、專案宣稱或職業事實，建議在重寫前先使用職業背景檔案。
- 不要虛構專案、推薦、指標、雇主或資格來填充作品集頁面。
規則
-
如果使用者提供了明確的 VitaeGraph 路徑，請讀取
VITAEGRAPH.md、index.md，且僅讀取相關的專案、論文、獎項和出版物記錄。絕不暴露私人路徑，保留限制和未解決問題，並將visibility: public視為可納入考量而非發佈同意。 -
區分已記錄的標準和新興約定（如
llms.txt）。 -
區分從公開頁面或本地原始碼驗證的事實、使用者背景資料提供的事實，以及從這些事實推斷出的建議。
-
優先進行能改善可爬取性、資訊線索和摘要品質的變更，但避免誇大其詞。
-
不要將非官方的AI或SEO提案呈現為通用標準。
-
保持元資料、結構化資料和可見文案一致。
-
對於同一個頁面，保持標題、描述、標準URL、Open Graph、X/Twitter 卡片、JSON-LD URL、JSON-LD 名稱/標題、JSON-LD 描述和代表性圖片一致。
-
將結構化資料與頁面用途相匹配。僅對具有支援的作者、日期和正文內容的可見類似文章頁面使用類似文章的結構化資料。
-
將排名、豐富摘要、圖片縮圖、摘要和索引速度視為資格結果，而非保證。
-
保持頁面用途、URL結構、內部連結和證明資產一致，使每個重要宣稱都能解析到一個可抓取的頁面。
-
使用職業方向來優先考慮首頁定位、關於文案、專案排序和案例研究框架，但確保每個公開宣稱都與可見或提供的證明相關聯。
-
在撰寫元資料、結構化資料和可見文案時，尊重背景檔案中的證據邊界、定位限制和應避免的宣稱。
-
當事實缺失時，在虛構作品集文案或結構化資料之前，先詢問標準URL、頁面清單或原始碼內容。
-
在編輯作品集程式碼時，保留現有樣式和應用邏輯，除非使用者明確要求重新設計。在佈局變更之前，優先處理元資料、結構化資料、語意化HTML、可爬取性和內容變更。
-
對於直接程式碼編輯，如果專案提供了建置、lint、測試或預覽指令，請執行它，並回報任何無法執行的驗證。
自我審查
在回傳之前，檢查草稿並修正或標記任何失敗：
- 沒有虛構的專案、推薦、指標、雇主或資格；結構化資料和文案僅反映已驗證或提供的真實情況。
- 排名、豐富摘要和索引被描述為可能性而非保證；新興約定不會被呈現為標準。
- 輸出符合要求的範圍和使用者陳述的目標；每個頁面的元資料、結構化資料和可見文案保持一致。
- 任何程式碼編輯都保留了現有樣式和邏輯，並回報了無法執行的驗證。
如果某項檢查失敗且無法從可用輸入中修正，請如實說明，而不是試圖掩蓋。
回覆格式
回傳：
- 已檢查的URL或本地檔案
- 可爬取性、元資料、結構化資料和內容問題
- 直接程式碼編輯或可直接使用的頁面文案
- 已執行的驗證或仍需進行的檢查
- 影響公開宣稱的背景檔案缺口
對於審計，當一個宣稱可能含糊不清時，使用簡潔的標籤，例如 已驗證、來自原始碼、來自上下文、推斷 和 無法存取。將不支援的責任、指標、年資、客戶、推薦或結果標記為缺口，而不是將它們變成元資料、結構化資料或文案。當審計刻意設定範圍時，加入一行 深度說明，說明哪些內容未經檢查，以及更深入的檢查會帶來什麼。
當使用者要求評分、評分卡或前後比較時，也應用 references/audit-scoring.md：報告總分、區間、每個類別的細項分數和優先修復排序，並將其標記為內部優先級啟發法，而非排名或索引保證。
人工操作手冊：網站作品集最佳化