我宣布：這個網站，終於被我用 ai 重構成了

我宣布一下。

這個網站，終於被我用 ai 重構成了。

不是那種“讓 ai 隨手補幾行代碼”的參與度。

而是從頁面重做、結構梳理、路由兼容、seo、加載優化、內容接入、markdown 清洗、最小測試集、ci，到這篇文章本身，ai 都深度參與了。

結果很直接。

效率真的高得離譜。

所以這篇文章，我想正式記錄一下這次重構，也順便聊聊一件事：

別牴觸 ai。會不會被它替代先不談，先學會怎麼駕馭它，真的能事半功倍。

先看結果

首頁

首頁這次不再只是“把內容堆上去”。

我把信息層次重新梳理了：最新文章、項目、文檔、工具入口更清晰，首屏更聚焦，也更像一個持續維護中的個人技術站，而不是零散頁面的拼接。

它現在至少能做到兩件事：

1. 第一次進來的用戶，知道這站點主要寫什麼、做什麼。
2. 老讀者回來時，能更快找到新內容和常用入口。

搜索

搜索是我這次很看重的一塊。

以前很多個人站，搜索只是“能搜”，體驗其實很一般。

這次我把搜索頁、搜索路由、關鍵詞處理、結果展示都順手重做了，尤其補了一個很實際的細節：

搜索時增加了非法關鍵詞過濾。

這個不是為了裝樣子，是真的有用。

實現上沒有搞複雜，思路很直接：

1. 先把用戶輸入做標準化處理。
2. 再和 site/blocked-search-keywords.json 里的词库做匹配。
3. 命中後直接攔截，不讓髒詞繼續進入搜索結果流程。

這樣做有幾個好處：

• 減少奇怪關鍵詞污染搜索頁和日誌。
• 避免頁面被低質量搜索流量反覆命中。
• 對公開網站來說，能省掉不少沒必要的髒活。

這個功能不大，但非常“站長視角”。

項目中心

項目中心這塊，我也重新整理過。

之前很多項目、組件、nuget 包、工具入口散在不同文章里，讀者不容易形成整體認知。

這次我把它們儘量收攏到了一個更清楚的入口裡。

你可以更快看到：

• 我在做什麼項目。
• 哪些是開源倉庫。
• 哪些是工具型頁面。
• 哪些內容適合直接拿去用。

這對我自己也很重要。

因為網站不只是“給別人看”，也是我自己的項目陳列櫃和能力檔案庫。

文章詳情頁

文章頁這次我盯得最細。

因為一個技術站最後好不好用，很多時候不看首頁多花，而看正文頁讀起來舒不舒服。

這次我主要盯了幾件事：

• markdown 渲染別再出怪問題。
• 代碼塊顯示要規整。
• 頁面信息結構要更清楚。
• 資源引用方式儘量統一。

最近我還順手清了一輪歷史文章里的 markdown 結構異常，比如老文章里混雜的舊格式代碼圍欄、反引號粘連、語言標籤缺失之類的問題。

這類問題平時不顯眼，但一旦累計多了，前端渲染就會非常難受。

這次到底重構了什麼

一句話說：

不是換了個皮，是把站點重新整理成了一個更像“產品”的狀態。

我這次主要做了下面這些事：

• 頁面結構重整。
• 路由兼容補齊。
• seo 基礎能力補強。
• 搜索體驗重做。
• 非法關鍵詞過濾。
• 資源域名獨立。
• 加載性能優化。
• 內容熱更新支持。
• readme、最小測試集、ci 補齊。
• 歷史 markdown 結構問題清掃。

如果你是開發者，應該能明白這意味著什麼。

很多時候，真正費時間的不是“寫一個頁面”，而是把一堆零散、歷史包袱重、邊角問題多的東西，慢慢收拾成一個能長期維護的倉庫。

ai 在這件事上，確實幫了我很大忙。

講點實現細節

1. 網站倉庫和資源倉庫分開

這次我繼續保持了“雙倉庫”思路：

CodeWF/           # 网站仓库
Assets.Dotnet9/   # 资源仓库

CodeWF 负责站点本身的页面、组件、路由、渲染和 SEO。

Assets.Dotnet9 负责文章、配置、图片、导航、工具数据这些“内容资产”。

我自己越來越喜歡這種拆法。

因為內容站最怕的就是：改一篇文章，順手把站點邏輯也攪進去;改一個頁面，又把內容資源一起綁死。

拆開以後，腦子會清楚很多。

好處也很直接：

• 網站代碼和內容資源職責清楚。
• 改文章時不必把站點邏輯一起攪進去。
• 更適合獨立部署和緩存。
• 後面做內容同步、靜態資源加速也更舒服。

2. 網站域名和資源域名分開

這個細節我特意說一下。

網站入口和資源訪問，我是按兩個域名部署的。

資源倉庫里的圖片、封面、文章內嵌資源，統一走這個域名：

https://img1.dotnet9.com

所以你會看到本文里的圖片引用，都是這種絕對地址：

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，把这些信息都带进去：

• headline
• description
• image
• datePublished
• dateModified
• author
• publisher
• mainEntityOfPage

這玩意對普通讀者幾乎沒存在感，但對搜尋引擎理解頁面類型、正文身份、發布時間這些信息很有幫助。

再說 rss 和 sitemap，這兩個我也不是擺個殼子出來。

rss 現在會自動輸出最近 10 篇文章，不是留個空連結裝樣子。

而 sitemap 也不只是首頁一條，而是把這些入口都整理進去了：

• 首頁
• 博客列表
• 分類頁
• 專題頁
• 標籤頁
• 文檔頁
• 工具頁
• 每篇文章詳情頁

而且每个节点都会带 lastmod、changefreq、priority。

這看起來很基礎，但對抓取路徑特別關鍵。因為你等於是在明確告訴搜尋引擎：哪些頁更重要，哪些頁更新更頻繁，哪些內容值得優先抓。

还有一个我自己比较在意的小细节，是 robots 的控制。

像搜索结果这种页面，本来就不适合被当成核心内容页去收录，所以我会给特定入口加 noindex,follow，避免一些没必要的页面跑去参与索引。

這類處理很像打掃衛生，平時不顯眼，但能少很多後續麻煩。

最後是訪問入口和兼容路由。

这次我顺手把 /blog、/search、/doc、/sitemap.xml 这些更直觉的入口也保留下来了。

這不只是為了“看起來網址更好看”，而是為了兩件事：

1. 用戶和爬蟲更容易理解網站結構。
2. 以後就算頁面組織方式繼續調整，歷史入口和常見訪問路徑也不至於一下子全斷。

所以嚴格說，這部分不完全等於“瀏覽器渲染更快”。

但對一個內容站來說，訪問效率從來不只是前端那幾百毫秒，還包括你怎麼被發現、怎麼被抓取、怎麼被分享、怎麼不把權重浪費掉。

所以這一整塊，我都把它算進了這次優化里。

這些東西單獨看都不誇張。

但一項一項堆起來，體感差別其實很明顯。

很多時候，網站變快不是靠某一個“神優化”，而是把這些本來就該做的小事，一件一件做對。

如果你想直接把這個倉庫跑起來

這部分我也寫直接一點，免得有人看完覺得“好像挺能打”，結果真想跑起來的時候沒入口。

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.json
• site/albums.json
• site/doc/navigation.json
• site/tools/tools.json
• site/blocked-search-keywords.json

也就是說，這個站點不是那種強依賴後台 cms 才能維護的結構。

改 markdown、改 json、改圖片，基本就能完成大多數內容更新。

ai 這次到底幫我做了什麼

這部分我想單獨說。

因為很多人現在一提 ai，要麼過度神化，要麼本能抗拒。

我自己的感受是：

ai 最有價值的地方，不是替你思考，而是幫你把執行速度拉起來。

這次它主要幫我做了這些事：

• 梳理重構思路。
• 細化頁面和路由調整。
• 補 readme、ci、最小測試集。
• 清理歷史 markdown 結構問題。
• 協助整理文章結構。
• 生成和調整文章封面 svg。
• 幫我把零碎工作串成完整閉環。

以前很多活，不是不會做。

是太碎、太雜、太耗神，拖著拖著就不想動了。

現在有了 ai，只要方向清楚、驗收嚴格，它真的可以把很多“懶得做”的工作推著往前走。

以後我還會繼續讓 ai 幫我做更多工具

這個我也提前說一下。

後面我會繼續基於這個網站，做更多在線工具。

但我不想一上來就追求大而全。

我的思路很簡單：

先滿足站長自己的真實需求。缺什麼工具，就先讓 ai 幫我開發一個。

比如：

• 內容處理小工具
• 開發輔助小工具
• 圖片或文本轉換工具
• 更貼近日常寫站、寫代碼、寫文章的實用工具

這樣做有兩個好處。

第一，工具不是為了湊數，而是真的會用。

第二，有真實使用場景，工具才更容易被慢慢打磨出來。

有人說，現在做這種網站意義不大了

這個話，我其實能理解。

如果只從流量、變現、平台分發效率去看，很多獨立技術站確實不一定是最優解。

所以如果有人說：

“不過現在感覺做這種網站的意義不大了。”

我的回答其實很直接：

是的，我認同一半。

對我的意義，主要不是非得有多少人看。

更重要的是兩件事：

1. 展示自己這幾年的文章記錄。
2. 滿足一下成就感。

有人願意看，當然開心。

沒人看，我也照樣會繼續做，哈哈。

因為它本來就是我自己的內容陣地、項目陳列櫃，也是一個能長期沉澱東西的地方。

歡迎來提建議，也歡迎 pr

如果你用了這個網站，或者看了倉庫代碼，有任何反饋，我都很歡迎。

你可以去這兩個倉庫：

• 网站仓库：https://github.com/dotnet9/CodeWF
• 资源仓库：https://github.com/dotnet9/Assets.Dotnet9

歡迎反饋的內容包括：

• 頁面體驗問題
• 搜索體驗問題
• markdown 渲染問題
• 資源組織建議
• 新工具想法
• 文案或錯字修正
• 直接提 pr

不管是網站倉庫還是資源倉庫，都歡迎一起來完善。

最後一句

這次重構做完，我最大的感受不是“ai 真神”。

而是：

會用 ai 的人，真的會比原來輕鬆很多，也快很多。

別急著牴觸它。

先學會怎麼提需求，怎麼拆任務，怎麼驗結果，怎麼把它當成一個高效率協作助手。

你會發現，很多原本嫌麻煩、不想開工、總想拖著的事，現在真的能做起來。

最後順手補一句。

本文同樣也是 ai 輔助完成的，我負責方向、事實校對和最終定稿。

如果你也在折騰個人網站、內容站、工具站，歡迎交流。