我宣布一下。
這個網站，終於被我用 AI 重構了。
不是那種「讓 AI 隨手補幾行程式碼」的參與度。
而是從頁面重做、結構梳理、路由相容、SEO、載入優化、內容接入、Markdown 清洗、最小測試集、CI，到這篇文章本身，AI 都深度參與了。
結果很直接。
效率真的高得離譜。
所以這篇文章，我想正式記錄一下這次重構，也順便聊一件事：
別抵觸 AI。會不會被它取代先不談，先學會怎麼駕馭它，真的能事半功倍。
先看結果
首頁
首頁這次不再只是「把內容堆上去」。
我把資訊層次重新梳理了：最新文章、專案、文件、工具入口更清晰，首屏更聚焦，也更像一個持續維護中的個人技術站，而不是零散頁面的拼接。
它現在至少能做到兩件事：
- 第一次進來的使用者，知道這站點主要寫什麼、做什麼。
- 老讀者回來時，能更快找到新內容和常用入口。
搜尋
搜尋是我這次很看重的一塊。
以前很多個人站，搜尋只是「能搜」，體驗其實很一般。
這次我把搜尋頁、搜尋路由、關鍵字處理、結果展示都順手重做了，尤其補了一個很實際的細節：
搜尋時增加了非法關鍵字過濾。
這個不是為了裝樣子，是真的有用。
實作上沒有搞複雜，思路很直接：
- 先把使用者輸入做標準化處理。
- 再和
site/blocked-search-keywords.json裡的詞庫做匹配。 - 命中後直接攔截，不讓髒詞繼續進入搜尋結果流程。
這麼做有幾個好處：
- 減少奇怪關鍵字污染搜尋頁和日誌。
- 避免頁面被低品質搜尋流量反覆命中。
- 對公開網站來說，能省掉不少沒必要的髒活。
這個功能不大，但非常「站長視角」。
專案中心
專案中心這塊，我也重新整理過。
之前很多專案、元件、NuGet 套件、工具入口散在不同文章裡，讀者不容易形成整體認知。
這次我把它們儘量收攏到了一個更清楚的入口裡。
你可以更快看到：
- 我在做什麼專案。
- 哪些是開源倉庫。
- 哪些是工具型頁面。
- 哪些內容適合直接拿去用。
這對我自己也很重要。
因為網站不只是「給別人看」，也是我自己的專案陳列櫃和能力檔案庫。
文章詳情頁
文章頁這次我盯得最細。
因為一個技術站最後好不好用，很多時候不看首頁多花，而看正文頁讀起來舒不舒服。
這次我主要盯了幾件事：
- Markdown 渲染別再出怪問題。
- 程式碼區塊顯示要規整。
- 頁面資訊結構要更清楚。
- 資源引用方式儘量統一。
最近我還順手清了一輪歷史文章裡的 Markdown 結構異常，比如老文章裡混雜的舊格式程式碼圍欄、反引號黏連、語言標籤缺失之類的問題。
這類問題平時不顯眼，但一旦累計多了，前端渲染就會非常難受。
這次到底重構了什麼
一句話說：
不是換了個皮，是把站點重新整理成了一個更像「產品」的狀態。
我這次主要做了下面這些事：
- 頁面結構重整。
- 路由相容補齊。
- SEO 基礎能力補強。
- 搜尋體驗重做。
- 非法關鍵字過濾。
- 資源網域名稱獨立。
- 載入效能最佳化。
- 內容熱更新支援。
- README、最小測試集、CI 補齊。
- 歷史 Markdown 結構問題清掃。
如果你是開發者，應該能明白這意味著什麼。
很多時候，真正費時間的不是「寫一個頁面」，而是把一堆零散、歷史包袱重、邊角問題多的東西，慢慢收拾成一個能長期維護的倉庫。
AI 在這件事上，確實幫了我很大忙。
講點實作細節
1. 網站倉庫和資源倉庫分開
這次我繼續保持了「雙倉庫」思路：
CodeWF/ # 網站倉庫
Assets.Dotnet9/ # 資源倉庫
CodeWF 負責站點本身的頁面、元件、路由、渲染和 SEO。
Assets.Dotnet9 負責文章、配置、圖片、導航、工具資料這些「內容資產」。
我自己越來越喜歡這種拆法。
因為內容站最怕的就是：改一篇文章，順手把站點邏輯也攪進去；改一個頁面，又把內容資源一起綁死。
拆開以後，腦子會清楚很多。
好處也很直接：
- 網站程式碼和內容資源職責清楚。
- 改文章時不必把站點邏輯一起攪進去。
- 更適合獨立部署和快取。
- 後面做內容同步、靜態資源加速也更舒服。
2. 網站網域名稱和資源網域名稱分開
這個細節我特意說一下。
網站入口和資源訪問，我是按兩個網域名稱部署的。
資源倉庫裡的圖片、封面、文章內嵌資源，統一走這個網域名稱：
所以你會看到本文裡的圖片引用，都是這種絕對位址：
https://img1.dotnet9.com/2026/05/codewf-homepage.png
這不是為了「顯得專業」，而是為了後面少折騰。
網站頁面和資源訪問分開之後，很多事都更好處理。
比如：
- 靜態資源快取策略可以單獨做。
- 資源遷移和 CDN 更靈活。
- 網站主網域名稱壓力更小。
- 文章內容更適合獨立維護和發佈。
3. 內容支援熱更新
這個功能我自己很喜歡。
現在本地開發時，文章、JSON 配置、部分圖片資源修改後，不必每次都重啟站點。
背後用了 FileSystemWatcher 去監聽資源目錄變化。
監聽的內容包括：
- Markdown
- JSON
- png/jpg/webp/svg 等圖片資源
這類東西很樸素，甚至沒什麼「炫技感」。
但如果你平時真的自己寫站、寫文章，就會知道它有多省時間。
因為寫文章最煩的，不是寫，而是「改一段，重啟一次，再看一遍」。
4. 載入速度這次也認真搞了，簡單分享下怎麼搞的細節
這塊我沒有去追那種特別花俏的指標詞，思路反而很樸素：
先把最容易白白浪費效能的地方補上。
也就是該壓的壓，該快取的快取，該延後的延後，該優先的優先。
第一類，壓縮。
這個我最先動手，因為它屬於幾乎沒有副作用、但收益很穩的一類。
我在站點裡直接開了 ResponseCompression，同時啟用了 Brotli 和 Gzip，而且把 image/svg+xml 也一起加進了壓縮範圍。
像 HTML、CSS、JS、SVG 這種文字型資源，本來就很適合壓縮，下發前先壓一遍，首屏傳輸體積就會直接變小。
這種最佳化不性感，但很值。因為它不是「理論上會更快」，而是使用者第一次開啟頁面時，第一段資源下載就真的會更輕。
第二類，靜態資源快取。
這一塊我也補得比較實在，不是泛泛地說一句「做了快取」就過去。
像 .css、.js、.png、.jpg、.webp、.svg、字型檔案，還有部分 json/txt，現在都會帶上：
Cache-Control: public,max-age=604800
也就是一週快取。
道理很簡單：使用者不是每次開啟頁面，都該把老資源重新拉一遍。
尤其部落格這種站點，很多資源本來就不是高頻變化的。快取命中起來之後，二次訪問會舒服很多，頁面也不會反覆做沒必要的請求。
另外我還配了 asp-append-version="true"，比如站點裡的 site.css、home.css、site.js、bootstrap.min.css 都帶版本參數。
這樣我就能比較放心地讓資源快取久一點，同時又不用怕樣式或指令碼更新後，使用者還拿著舊檔案。
好處很直接：
- 老資源可以放心快取。
- 檔案一旦更新，URL 自動變。
- 不用手動清快取，也不用擔心使用者拿到舊樣式。
第三類，圖片載入。
圖片這塊我沒有偷懶搞「一刀切」，而是分成了「列表圖」和「首圖」兩種處理方式。
文章列表頁、首頁卡片、分類頁這些非首屏核心圖片，統一儘量走：
loading="lazy" decoding="async"
意思就是能晚一點載入就晚一點，能非同步解碼就別阻塞主執行緒。
但文章詳情頁頂部封面這種更關鍵的視覺元素，我就沒有硬上懶載入，而是保留正常載入，同時補了 decoding="async" 和 fetchpriority="high"，讓真正該優先顯示的圖片優先顯示。
我自己不太喜歡那種「所有圖片都 lazy」就算最佳化完了的做法。實際頁面裡，不同圖片的重要程度根本不一樣，處理方式也不該一樣。
第四類，頁面渲染路徑梳理。
這部分說白了，就是儘量減少一種很煩的情況：
頁面內容還沒出來，雜七雜八的資源先排隊。
比如我對一些非關鍵外部資源做了延後處理：
- 對
cdnjs做了preconnect。 - Font Awesome 的樣式表用了
media="print" onload="this.media='all'"這種方式非同步載入。 - Prism 程式碼高亮樣式也做了類似處理。
- 百度統計指令碼不再一進頁面就同步載入，而是等
window.load之後，再透過requestIdleCallback或setTimeout延後插入。
這些點單拆開看都不算大事，但合在一起，頁面節奏就會順很多。
先把真正該先看到的東西給使用者，再去補圖示、統計、增強樣式，這個順序我覺得比什麼都重要。
第五類，SEO 和訪問入口整理。
這一塊表面上看像 SEO，其實我更願意把它理解成「把網站入口重新理順」。
因為內容站很多時候不是死在頁面寫不出來，而是死在：
- 搜尋引擎不知道你這頁到底是不是正文。
- 同一篇內容有多個入口，權重被打散。
- 分享出去只有個裸連結，卡片資訊不完整。
- 你自己改了路由，歷史入口和抓取入口一起斷掉。
所以這次我把這部分補得比以前認真很多。
先說最基礎的一層：canonical、Open Graph、Twitter Card。
現在頁面會統一輸出 canonical，文章詳情頁還會明確把 og:type 設成 article，og:image 直接走文章封面，同時把發佈時間、更新時間、作者這些資訊也一起帶上。
這些東西平時肉眼不一定直接看到，但很重要。
因為搜尋引擎、社交平臺、聚合工具首先要先判斷：這到底是一篇文章，還是一個普通頁面；它的主連結是誰；它的封面該用哪張圖。
這些基礎資訊不完整的時候，你自己覺得「頁面能開啟就行」，但搜尋和分享系統可不這麼想。
再往下一層，我把文章頁的結構化資料也補了。
不是隻寫個標題 description 完事，而是直接輸出了 Article 型別的 JSON-LD，把這些資訊都帶進去：
headlinedescriptionimagedatePublisheddateModifiedauthorpublishermainEntityOfPage
這玩意對普通讀者幾乎沒存在感，但對搜尋引擎理解頁面型別、正文身份、發佈時間這些資訊很有幫助。
再說 RSS 和 sitemap，這兩個我也不是擺個殼子出來。
RSS 現在會自動輸出最近 10 篇文章，不是留個空連結裝樣子。
而 sitemap 也不只是首頁一條，而是把這些入口都整理進去了：
- 首頁
- 部落格列表
- 分類頁
- 專題頁
- 標籤頁
- 文件頁
- 工具頁
- 每篇文章詳情頁
而且每個節點都會帶 lastmod、changefreq、priority。
這看起來很基礎，但對抓取路徑特別關鍵。因為你等於是在明確告訴搜尋引擎：哪些頁更重要，哪些頁更新更頻繁，哪些內容值得優先抓。
還有一個我自己比較在意的小細節，是 robots 的控制。
像搜尋結果這種頁面，本來就不適合被當成核心內容頁去收錄，所以我會給特定入口加 noindex,follow，避免一些沒必要的頁面跑去參與索引。
這類處理很像打掃衛生，平時不顯眼，但能少很多後續麻煩。
最後是訪問入口和相容路由。
這次我順手把 /blog、/search、/doc、/sitemap.xml 這些更直覺的入口也保留下來了。
這不只是為了「看起來網址更好看」，而是為了兩件事：
- 使用者和爬蟲更容易理解網站結構。
- 以後就算頁面組織方式繼續調整，歷史入口和常見訪問路徑也不至於一下子全斷。
所以嚴格說，這部分不完全等於「瀏覽器渲染更快」。
但對一個內容站來說，訪問效率從來不只是前端那幾百毫秒，還包括你怎麼被發現、怎麼被抓取、怎麼被分享、怎麼不把權重浪費掉。
所以這一整塊，我都把它算進了這次最佳化裡。
這些東西單獨看都不誇張。
但一項一項堆起來，體感差別其實很明顯。
很多時候，網站變快不是靠某一個「神最佳化」，而是把這些本來就該做的小事，一件一件做對。
如果你想直接把這個倉庫跑起來
這部分我也寫直接一點，免得有人看完覺得「好像挺能打」，結果真想跑起來的時候沒入口。
1. 先拉兩個倉庫
git clone https://github.com/dotnet9/CodeWF.git
git clone https://github.com/dotnet9/Assets.Dotnet9.git
思路很簡單，一個放站點程式碼，一個放內容資源。
2. 本地把資源目錄指過去
$env:Site__LocalAssetsDir = "D:\github\owner\Assets.Dotnet9"
dotnet run --project D:\github\owner\CodeWF\src\WebApp
也就是說，站點啟動的時候，會直接去讀資源倉庫裡的文章和配置。
3. 文章放哪
文章按這種結構放：
YYYY/MM/slug.md
例如：
2026/05/labor-day-ai-rebuilt-my-site.md
4. 站點配置在哪裡改
常見內容都在資源倉庫的 site 目錄裡。
比如：
site/categories.jsonsite/albums.jsonsite/doc/navigation.jsonsite/tools/tools.jsonsite/blocked-search-keywords.json
也就是說，這個站點不是那種強依賴後臺 CMS 才能維護的結構。
改 Markdown、改 JSON、改圖片，基本就能完成大多數內容更新。
AI 這次到底幫我做了什麼
這部分我想單獨說。
因為很多人現在一提 AI，要麼過度神化，要麼本能抗拒。
我自己的感受是：
AI 最有價值的地方，不是替你思考，而是幫你把執行速度拉起來。
這次它主要幫我做了這些事：
- 梳理重構思路。
- 細化頁面和路由調整。
- 補 README、CI、最小測試集。
- 清理歷史 Markdown 結構問題。
- 協助整理文章結構。
- 生成和調整文章封面 SVG。
- 幫我把零碎工作串成完整閉環。
以前很多活，不是不會做。
是太碎、太雜、太耗神，拖著拖著就不想動了。
現在有了 AI，只要方向清楚、驗收嚴格，它真的可以把很多「懶得做」的工作推著往前走。
以後我還會繼續讓 AI 幫我做更多工具
這個我也提前說一下。
後面我會繼續基於這個網站，做更多線上工具。
但我不想一上來就追求大而全。
我的思路很簡單：
先滿足站長自己的真實需求。缺什麼工具，就先讓 AI 幫我開發一個。
比如：
- 內容處理小工具
- 開發輔助小工具
- 圖片或文字轉換工具
- 更貼近日常寫站、寫程式碼、寫文章的實用工具
這樣做有兩個好處。
第一，工具不是為了湊數，而是真的會用。
第二，有真實使用場景，工具才更容易被慢慢打磨出來。
有人說，現在做這種網站意義不大了
這個話，我其實能理解。
如果只從流量、變現、平臺分發效率去看，很多獨立技術站確實不一定是最佳解。
所以如果有人說：
「不過現在感覺做這種網站的意義不大了。」
我的回答其實很直接：
是的，我認同一半。
對我的意義，主要不是非得有多少人看。
更重要的是兩件事：
- 展示自己這幾年的文章記錄。
- 滿足一下成就感。
有人願意看，當然開心。
沒人看，我也照樣會繼續做，哈哈。
因為它本來就是我自己的內容陣地、專案陳列櫃，也是一個能長期沉澱東西的地方。
歡迎來提建議，也歡迎 PR
如果你用了這個網站，或者看了倉庫程式碼，有任何回饋，我都很歡迎。
你可以去這兩個倉庫：
歡迎回饋的內容包括：
- 頁面體驗問題
- 搜尋體驗問題
- Markdown 渲染問題
- 資源組織建議
- 新工具想法
- 文案或錯字修正
- 直接提 PR
不管是網站倉庫還是資源倉庫，都歡迎一起來完善。
最後一句
這次重構做完，我最大的感受不是「AI 真神」。
而是：
會用 AI 的人，真的會比原來輕鬆很多，也快很多。
別急著抵觸它。
先學會怎麼提需求，怎麼拆任務，怎麼驗結果，怎麼把它當成一個高效率協作助手。
你會發現，很多原本嫌麻煩、不想開工、總想拖著的事，現在真的能做起來。
最後順手補一句。
本文同樣也是 AI 輔助完成的，我負責方向、事實校對和最終定稿。
如果你也在折騰個人網站、內容站、工具站，歡迎交流。