~/VibeHandbook
免費 PDF

17 · 04

案例研究 4:一個不用你打理的內容站

想法

一位業餘愛好者想把一個 Markdown 筆記資料夾——多年旅行積攢下來的餐廳點評——變成一個可搜尋的公開站點,沒有要登入的 CMS,也沒有月度賬單。加一條筆記,推送,搞定。

Spec

A static site generated from a folder of Markdown files, one file
per review (title, city, rating, body in frontmatter). Build a
homepage that lists reviews newest-first, a page per review, and
client-side search by city or name. No database, no login, no
build step I have to run by hand. Pushing a new .md file should
publish it.

隱藏的需求在最後一句裡。"No build step I have to run by hand"意味著這段 spec 其實講的是工作流,而不只是產物——而工作流需求正是那種你不點名 AI 就會跳過的類別,因為它們不會在跑起來的應用裡露面。

技術棧

一個在構建時讀取 Markdown 的靜態站點生成器,部署到一個帶 觸發構建的 CDN 託管平臺上。推送到倉庫,託管方重新構建,CDN 來分發。搜尋在構建時生成的一個小 索引上做客戶端搜尋,所以沒有伺服器、也沒有查詢成本——在幾百條點評這個量級上這是個不錯的取捨,而且是我們點明瞭的、而非撞上的一個有意選擇。

整個工作流就是一根箭頭:一次推送觸發一次會發布的構建。除了訪客自己的瀏覽器過濾索引之外,請求時刻沒有任何東西在執行:

  新增 review.md         ┌──────────────────┐
  git push  ───────────▶ │  CDN HOST        │
                         │  構建步驟:       │
                         │  讀取所有 *.md   │──▶ 靜態  HTML 頁面們
                         │  生成 search.json│──▶ 小巧的搜尋 索引庫
                         └────────┬─────────┘
                                  │ 提供中
                                  ▼
                         ┌──────────────────┐
                         │  VISITOR BROWSER │  過濾 search.json 並
                         │  (客戶端)        │  在本地處理 — 無服務
                         └──────────────────┘
            無資料庫 · 無需登入 · 無需手動執行任何構建步驟

關鍵的 prompt

我們先把 AI 錨定在資料形狀上,在任何 UI 之前:

Set up a static site that reads every .md file in /reviews. Each
file's frontmatter has title, city, rating (1-5), date. Parse all
of them at build time into a sorted list (newest first) and
generate: a homepage listing them, and one page per review at
/reviews/<slug>. Show me the data-loading code first, before any
styling.

"before any styling"是一根有意為之的槓桿。一次性把整個東西要過來,你會得到一個連著你信不過的資料、卻很漂亮的頁面;先把資料層要過來,你就能在哪怕一個畫素分散你注意之前,先驗證好地基。然後是搜尋,被框住以保持廉價:

Generate a search.json at build time with {title, city, slug} for
every review. On the homepage, add a search box that filters the
visible list client-side by matching city or title — no network
calls, just filter the already-loaded index. Keep it under 50
lines of JS.

障礙

構建在本地通過了,但部署後的站點在每一個單獨的點評頁上都 404。首頁能用;按點評分的頁面不行。我們沒去做推理,而是把症狀和配置粘了上去:

Homepage works live, but /reviews/<slug> pages all 404 in
production while working in local dev. Here's my build output
directory listing and my host's deploy config: [pasted]. Why does
local dev serve these pages but production doesn't?

The AI traced it to the difference between dev-server routing (which
resolves paths dynamically) and static hosting (which serves only
files that physically exist). The build was generating the review
pages into the wrong output folder, so they never got uploaded —
dev had hidden the bug because its router faked the routes that
production couldn't.

我們把輸出目錄指向了託管方真正部署的那個,頁面就出現了,並且我們在上線檢查清單里加了一行:在線上站點點一個深層連結,而不只是首頁。更廣的教訓是,"在 dev 裡能用"和"部署後能用"是兩個不同的主張,而靜態匯出恰恰就是這兩者分道揚鑣的地方——dev 伺服器在路由上的寬容,是真正的基於檔案的託管永遠不會有的。

上線

我們推送了一條真實的點評,看著託管方重新構建,然後在線上域名載入了通向那一條具體點評的深層連結——也就是 dev 撒過謊的那個案例。然後我們搜了一下它的城市,確認索引把它收進來了。加下一條點評是一次一行的提交,而這正是全部意義所在:上線不是一個時刻,而是一個不用我們就能繼續運轉的工作流。

想離線閱讀?

免費下載整本書的 PDF 或 EPUB。