発表しました。
このサイトはついにAIで再構築しました。
“AIに数行のコードを追加させる”ようなエンゲージメントではありません。
しかし、ページのやり直し、構造化、ルーティング互換性、SEO、ロード最適化、コンテンツアクセス、Markdownクリーニング、最小限のテストセット、CI、そして記事自体に至るまで、AIは深く関与しています。
結果は直接です。
*** 効率は非常に高いです ***
そこで、この記事では、このリファクタリングを公式に記録し、たまたま一つのことについてお話ししたいと思います。
** AIと衝突しない。それに置き換えられるかどうかは、まずそれを制御する方法を学び、実際に乗数を増やすことができます。**
まずは結果を見て
トップページ>
今回のページは、もはや“コンテンツをまとめる”だけではありません。
最新の記事、プロジェクト、ドキュメント、ツールの入り口がより明確になり、最初の画面がより焦点を当て、断片化されたページのスプライシングではなく、継続的なメンテナンスのパーソナルテクノロジーステーションのようになりました。
少なくとも2つのことができます。
- 最初の訪問者は、サイトが何を書いているかを知っている。
- 古い読者が戻ってくると、新しいコンテンツや一般的なエントリをすばやく見つけることができます。
検索する。
今回は検索が大切な部分です。
以前は、多くの個人的なサイトは、検索は“検索できる”だけで、経験は実際には非常に一般的です。
今回は、検索ページ、検索ルート、キーワード処理、結果表示をすべてやり直し、特に非常に実用的な詳細を追加しました。
** 検索時に違法なキーワードフィルタリングを追加しました。
これは見た目ではなく、本当に便利です。
複雑ではなく、アイデアは簡単です。
- ユーザー入力を標準化します。
- 再和
site/blocked-search-keywords.json里的词库做匹配。 - ヒット後に直接傍受し、汚い単語を検索結果フローに入れないようにします。
これにはいくつかの利点がある。
- 検索ページやログを汚染する奇妙なキーワードを減らす。
- 低品質の検索トラフィックによるページの繰り返しヒットを避ける。
- 公共のウェブサイトでは、多くの不要な汚い作業を節約できます。
この機能は小さいですが、非常に“ウェブマスターの視点”です。
プロジェクトセンタープロジェクト
プロジェクトセンターも再構築しました。
以前は、多くのプロジェクト、コンポーネント、NuGetパッケージ、ツールポータルが異なる記事に散らばっており、読者が全体的な理解を形成することは容易ではなかった。
今回は、できるだけはっきりした入り口に集めました。
もっと早く見ることができます
- 私が取り組んでいるプロジェクト。
- オープンソースリポジトリとは？
- ツールページとは？
- どのコンテンツが直接使用できますか？
それは私にとっても重要です。
ウェブサイトは単に“他人に見せる”だけではなく、私自身のプロジェクトのショーケースであり、能力のアーカイブでもあります。
記事の詳細ページ
今回はページが一番きれいになりました
テクノロジーステーションは最終的には使いにくいので、多くの場合、ホームページを見ずに、本文ページを読むのは快適ではありません。
今回は主にいくつかのことを見ました。
- Markdownはもう問題を起こさない。
- コードブロックは正規化される。
- ページの情報構造が明確になります。
- リソース参照方法はできるだけ統一されます。
最近、古い記事の古いフォーマットのコードフェンス、バッククォートのスティッキング、言語タグの欠落など、歴史的な記事のMarkdown構造の例外を簡単にクリアしました。
このような問題は通常目立たないが、累積するとフロントエンドのレンダリングが非常に難しくなる。
今回は何が再建されたか？
一言で言うと
** スキンを変更するのではなく、サイトをより“製品”のような状態に再編成しました。**
今回は主に以下のことを行いました。
- ページの再構築。
- ルート互換性がある。
- SEOの基本機能を強化。
- 検索体験の再構築
- 違法なキーワードフィルタリング。
- 独立したリソース。
- ロードパフォーマンス最適化
- ホットアップデートをサポート。
- README、最小テストセット、CI補完。
- 歴史Markdown構造問題のクリーニング。
開発者であれば、その意味を理解できるはずです。
多くの場合、本当に時間を費やすのは“ページを書く”ことではなく、断片化された、歴史的な荷物が重く、コーナーの問題が多い、ゆっくりと長期的なメンテナンスが可能な倉庫にパックすることです。
AIはこの問題で本当に助けてくれました。
詳細を伝える。
1. Webサイトとリソースリポジトリの分離
今回は“ダブルストレージ”の考え方を続けました。
CodeWF/ # 网站仓库
Assets.Dotnet9/ # 资源仓库
CodeWF 负责站点本身的页面、组件、路由、渲染和 SEO。
Assets.Dotnet9 负责文章、配置、图片、导航、工具数据这些“内容资产”。
私はますますこのカットが好きです。
コンテンツステーションが最も恐れているのは、記事を変更し、サイトロジックをかき混ぜることです。ページを変更し、コンテンツリソースを一緒にバインドします。
開封後、脳ははっきりします。
利点は直接的です：
- ウェブサイトコードとコンテンツリソースの責任が明確です。
- 記事を変更するときにサイトロジックを混ぜる必要はない。
- スタンドアロンの展開とキャッシュに適しています。
- コンテンツの同期、静的リソースの加速もより快適です。
2. ウェブサイトドメイン名とリソースドメイン名の分離
この詳細は特にお話しします。
サイトポータルとリソースアクセスについては、2つのドメイン名で展開しています。
リソースリポジトリの画像、カバー、記事の埋め込みリソースは、このドメイン名を統一します：
だから、この記事では、絶対アドレスの画像参照が表示されます：
https://img1.dotnet9.com/2026/05/codewf-homepage.png
これは“プロフェッショナルに見える”ためではなく、後ろにいることです。
ウェブサイトのページとリソースへのアクセスを分離すると、多くのことがより良くなります。
例えば：
- 静的リソースキャッシュポリシーは個別に実行できます。
- リソース移行とCD Nはより柔軟です。
- ウェブサイトのドメイン名はストレスが少ない。
- 記事は独立した保守と公開に適しています。
3. ホット·アップデートのサポート
私はこの機能が大好きです。
現在、ローカル開発では、記事、JSON設定、一部の画像リソースの変更後、毎回サイトを再起動する必要はありません。
背后用了 FileSystemWatcher 去监听资源目录变化。
リスニングの内容は：
- Markdown
- JSON
- png/jpg/webp/svgなどの画像
それは非常に単純で、“トリック”さえありません。
しかし、通常、実際にサイトを書いたり、記事を書いたりすれば、それがどれだけ時間を節約できるかがわかります。
記事を書くのが一番面倒なのは、書くことではなく、“段落を変えて、もう一度やり直して、もう一度見る”ことです。
4. ロード速度も今回真剣に取り組んで、詳細を共有する方法を簡単に
この作品では、私は特別な派手な指標語を追求していませんが、アイデアは非常にシンプルです：
** 最も無駄にしやすい場所を最初に埋めてください。**
すなわち，この圧の圧，このキャッシュのキャッシュ，この遅延の遅延，この優先の優先である.
1つ目は、圧縮。
副作用がほとんどなく、安定した利益があるカテゴリーに属するので、私はこれを最初に始めました。
我在站点里直接开了 ResponseCompression，同时启用了 Brotli 和 Gzip，而且把 image/svg+xml 也一起加进了压缩范围。
HTML、CSS、JS、SVGなどのテキストベースのリソースは、もともと圧縮に適しており、配信前に一度押すと、最初の画面転送ボリュームが直接小さくなります。
この最適化はセクシーではないが、価値がある。それは“理論的に速くなる”のではなく、ユーザーが最初にページを開くときに最初のリソースをダウンロードするときに本当に軽くなるからです。
2つ目は静的資源キャッシュです。
この作品は、一般的には“キャッシュを行う”という言葉ではなく、より現実的に補完しています。
像 .css、.js、.png、.jpg、.webp、.svg、字体文件，还有部分 json/txt，现在都会带上：
Cache-Control: public,max-age=604800
1週間のキャッシュです。
理由は簡単です。ユーザーはページを開くたびに、古いリソースを再度プルする必要があります。
特にブログのようなサイトでは、リソースの多くはもともと頻繁に変更されません。キャッシュがヒットした後、2回目の訪問ははるかに快適になり、ページは不要なリクエストを繰り返しません。
另外我还配了 asp-append-version="true"，比如站点里的 site.css、home.css、site.js、bootstrap.min.css 都带版本参数。
これにより、スタイルやスクリプトが更新された後にユーザーが古いファイルを保持することを恐れることなく、リソースをもう少し安心してキャッシュできます。
利点は直接的です。
- 古いリソースは安全に保存できます。
- 更新後、URLは自動的に変更されます。
- 手動でキャッシュをクリアしたり、ユーザーが古いスタイルを取得する心配もありません。
第三に、画像をロードする。
この画像は“万能”を怠け者ではなく、“リストグラフ”と“最初のグラフ”の2つの処理方法に分かれています。
記事一覧ページ、フロントページカード、カテゴリページこれらの非最初の画面コア画像は、統一できるだけ行く：
loading="lazy" decoding="async"
つまり、後でロードすることができ、非同期デコードすることができ、メインスレッドをブロックしないでください。
但文章详情页顶部封面这种更关键的视觉元素，我就没有硬上懒加载，而是保留正常加载，同时补了 decoding="async" 和 fetchpriority="high"，让真正该优先显示的图片优先显示。
私自身、最適化が終わっても“すべての画像がラジー”という考え方はあまり好きではありません。実際のページでは、異なる画像の重要性はまったく異なり、同じ方法で処理する必要はありません。
4番目のカテゴリは、ページレンダリングパスのコーミングです。
この部分は、厄介な状況を最小限に抑えるためです。
** ページ内容还没出，雑七雑八的先。**
例えば、非重要な外部リソースの遅延処理を行いました。
- 对
cdnjs做了preconnect。 - Font Awesome 的样式表用了
media="print" onload="this.media='all'"这种方式异步加载。 - Prismのコードハイライトスタイルも同様です。
- 百度统计脚本不再一进页面就同步加载，而是等
window.load之后，再通过requestIdleCallback或setTimeout延后插入。
これらのポイントは大きくはありませんが、一緒に、ページのリズムははるかに速くなります。
最初に本当に見るべきものをユーザーに与え、アイコン、統計、スタイルを強化するという順序が何よりも重要だと思います。
カテゴリー 5：SEOとアクセスポータルの整理。
これは表面的にはSEOのように見えますが、私はむしろ“ウェブサイトの入り口を合理化する”と解釈したいです。
コンテンツステーションはしばしばページで死ぬのではなく、死ぬのです。
- 検索エンジンはあなたのページが実際にテキストであるかどうかを知らない。
- 同じコンテンツには複数のエントリがあり、重みは分割されます。
- 裸のリンクがあり、カード情報は不完全です。
- ルートを自分で変更し、歴史的な入り口はグラブの入り口と一緒に壊れます。
だから今回はこれまで以上に真剣に取り組んでいます。
先说最基础的一层：canonical、Open Graph、Twitter Card。
现在页面会统一输出 canonical，文章详情页还会明确把 og:type 设成 article，og:image 直接走文章封面，同时把发布时间、更新时间、作者这些信息也一起带上。
これらは必ずしも肉眼では見えませんが重要です。
検索エンジン、ソーシャルプラットフォーム、集計ツールは、まずこれが記事なのか普通のページなのか、メインリンクが誰なのか、表紙にどの画像を使用すべきかを判断する必要があります。
基本的な情報が不完全な場合、“ページが開いていればいい”と思いますが、検索·共有システムはそうは思いません。
次のレベルでは、記事ページの構造化データも修正しました。
不是只写个标题 description 完事，而是直接输出了 Article 类型的 JSON-LD，把这些信息都带进去：
headlinedescriptionimagedatePublisheddateModifiedauthorpublishermainEntityOfPage
これは一般読者にはほとんど存在しませんが、検索エンジンがページタイプ、本文のアイデンティティ、公開時刻などの情報を理解するのに役立ちます。
RSSとサイトマップは、私が殻を作っていない2つです。
RSSは空のリンクを残す代わりに最近の10の記事を自動的に出力する。
Sitemapはホームページだけでなく、これらのエントリを整理します。
- トップページ>
- ブログ一覧
- カテゴリ別ページ
- テーマ別ページ
- Labelsページ
- ドキュメントページ
- ツールのページ
- 各記事の詳細ページ
而且每个节点都会带 lastmod、changefreq、priority。
これは基本的に見えますが、パスをつかむために特に重要です。どのページがより重要で、どのページがより頻繁に更新され、どのコンテンツが優先されるかを検索エンジンに伝えているからです。
还有一个我自己比较在意的小细节，是 robots 的控制。
像搜索结果这种页面，本来就不适合被当成核心内容页去收录，所以我会给特定入口加 noindex,follow，避免一些没必要的页面跑去参与索引。
このタイプの処理は、通常目立たない清掃に似ていますが、フォローアップのトラブルが少ないです。
最後に、アクセスポータルと互換ルートです。
这次我顺手把 /blog、/search、/doc、/sitemap.xml 这些更直觉的入口也保留下来了。
これは単に“ウェブサイトを見栄え良くする”ためではなく、2つのことのためです。
- ユーザーとクローラーはウェブサイトの構造を理解しやすくなります。
- 今後、ページ構成が調整され続けても、履歴エントリや一般的なアクセスパスが突然完全に切断されることはありません。
厳密に言えば、これは“ブラウザのレンダリングが速い”とは限りません。
しかし、コンテンツサイトにとって、アクセス効率はフロントエンドの数百ミリ秒だけではなく、どのように発見され、どのようにキャプチャされ、どのように共有され、どのように重みを無駄にしないかが重要です。
だから、私はこの最適化にすべてを含めました。
これらは単独で見ても過言ではない。
しかし、1つの項目を積み重ねると、感覚の違いは明らかになります。
多くの場合、ウェブサイトは特定の“神の最適化”に依存していませんが、これらの小さなことを正しく行う必要があります。
この倉庫をまっすぐに走らせたいなら
この部分も直接に書いて、誰かが見終わって“打つことができるようだ”と感じないようにして、本当に走りたい時に入り口がない。
1. 2つの倉庫を持つ。
git clone https://github.com/dotnet9/CodeWF.git
git clone https://github.com/dotnet9/Assets.Dotnet9.git
アイデアは非常に簡単で、1つはサイトコード、もう1つはコンテンツリソースです。
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の最も価値のある部分は、あなたのために考えることではなく、あなたの実行をスピードアップすることです。
今回は主に以下のことをしてくれました。
- 再構築のアイデアを見つける。
- ページの絞り込みとルーティングの調整。
- README、CI、最小テストセットを補完します。
- マークダウン構造の問題をクリーンアップする。
- 記事の構造化を支援する。
- ストーリーカバー SVGの生成と調整。
- 完全なクローズドループに断片的な作業を整理してください。
多くのことをしていない。
あまりにも壊れて、あまりにも複雑で、あまりにも消耗している神であり、ドラッグすると動きたくない。
AIでは、方向性が明確で厳格である限り、多くの“面倒な”作業を進めることができます。
今後もAIにツールを作ってもらいます。
これも事前に言いました。
今後もこのサイトに基づいてオンラインツールを追加していきます。
しかし、私は最初に大きなものを求めたくありません。
私の考えはとてもシンプルです
** あなた自身の本当のニーズを満たしなさい。ツールがない場合は、AIに開発させてもらいましょう。
例えば：
- コンテンツ処理ガジェット
- 支援ガジェットの開発
- 画像またはテキスト変換ツール
- 日常の執筆ステーション、コード、記事を書くユーティリティに近い
これには2つの利点がある。
まず、ツールは数字を集めるためではなく、実際に使うためです。
第二に、実際の使用シナリオがあり、ツールをゆっくりと磨きやすくなります。
このウェブサイトはもはや意味がないと言う人もいます。
その言葉、実は理解できます。
トラフィック、収益化、プラットフォーム配信効率の観点から見ると、多くの独立したテクノロジーステーションは必ずしも最適なソリューションではありません。
もし誰かが言うなら
しかし、今ではそのようなサイトを作る意味はほとんどありません。
私の答えはとても直接的でした
- はい、半分は賛成です。**
私にとって重要なのは、見る人の数ではありません。
さらに重要なのは2つです
- 過去数年間の記録を表示します。
- 達成感を満たす。
見たい人もいます。
誰も見ないで、私もやります。
それはもともと私自身のコンテンツポジションであり、プロジェクトのショーケースであり、長期的に物事を沈殿させることができる場所です。
PRも歓迎します。
このサイトを使用したり、リポジトリのコードを見たりしてフィードバックがあれば大歓迎です。
2つの倉庫に行くことができます：
フィードバックを歓迎する内容は次のとおりです。
- ページエクスペリエンスの問題。
- 検索体験の質問
- Markdownレンダリングの問題
- 資源組織の推奨事項
- 新しいツールのアイデア
- テキストまたは誤植の修正
- 略称はPR。
ウェブサイトのリポジトリやリソースリポジトリに関係なく、一緒に改善することを歓迎します。
最後の言葉。
このリファクタリングが終わったとき、私の最大の感情は“AIの真の神”ではなかった。
しかしながら：
** AIを使用できる人は、実際には以前よりもはるかに簡単で速くなります。
急がないでください。
まず、要件の提示方法、タスクの分割方法、結果のテスト方法、効率的なコラボレーションアシスタントとしての使用方法を学びます。
以前は面倒だった、始めたくなかった、いつもドラッグしたかったことの多くが、今本当にできることがわかります。
最後に一言。
** この記事もAIによって作成され、私がディレクション、ファクトチェック、最終決定を担当しました。
あなたも個人的なウェブサイト、コンテンツステーション、ツールステーションを投げている場合は、交換を歓迎します。