第一次看到 GALNAVI 這個(gè)名字時(shí)我注意到標(biāo)題里有兩個(gè)關(guān)鍵詞一個(gè)叫 Galgame 導(dǎo)航平臺(tái)一個(gè)叫由 AI 協(xié)助開(kāi)發(fā)。前者讓我想起一個(gè)很常見(jiàn)的場(chǎng)景——?jiǎng)側(cè)肟?Galgame 的玩家想找一個(gè)作品的官方發(fā)布頁(yè)或想確認(rèn)某部作品有沒(méi)有漢化信息往往要在搜索引擎、論壇和群聊之間來(lái)回切換最后還不一定找得準(zhǔn)。后者則讓我意識(shí)到這很可能是 AI 輔助編程時(shí)代的一個(gè)典型樣本。我的判斷是GALNAVI 這類(lèi)項(xiàng)目真正值得關(guān)注的地方不是代碼難度而是它展示了一種新模式——個(gè)人開(kāi)發(fā)者可以借助 AI 工具把一個(gè)小眾垂直需求快速做成一個(gè)開(kāi)源、可復(fù)用、可以被別人參與維護(hù)的產(chǎn)品。它看起來(lái)是一個(gè)導(dǎo)航站實(shí)際上是一個(gè)“AI 輔助個(gè)人開(kāi)發(fā)”的實(shí)踐樣本。本文就圍繞這個(gè)判斷展開(kāi)。1. 先理解它真正解決的是信息索引問(wèn)題不單純是“寫(xiě)網(wǎng)站”1.1 導(dǎo)航平臺(tái)到底在“導(dǎo)”什么GALNAVI 的定位看起來(lái)很簡(jiǎn)單一個(gè)給 Galgame 玩家用的導(dǎo)航平臺(tái)。但“導(dǎo)航”這個(gè)詞背后是一個(gè)很容易被忽視的信息問(wèn)題。如果一個(gè)導(dǎo)航平臺(tái)只是把一堆鏈接堆在頁(yè)面上那它和瀏覽器收藏夾沒(méi)有本質(zhì)區(qū)別。我理解它真正的價(jià)值是把分散在官方站點(diǎn)、漢化組公告、攻略 Wiki、社區(qū)討論板塊里的信息整理成結(jié)構(gòu)化的“作品卡片”。一個(gè)典型的導(dǎo)航條目通常會(huì)包含這些信息作品名包括中文名和日文原名。官方發(fā)布頁(yè)比如發(fā)行商官網(wǎng)、商店頁(yè)面。漢化狀態(tài)比如“官方中文”“漢化中”“已漢化”。攻略入口比如 Wiki 地址、社區(qū)指南。社區(qū)討論鏈接比如論壇專(zhuān)樓。每一個(gè)條目本質(zhì)上就是一條“坐標(biāo)信息”。導(dǎo)航平臺(tái)把散落在各處的位置點(diǎn)統(tǒng)一管理起來(lái)按標(biāo)簽和狀態(tài)組織好。這樣用戶(hù)不需要知道某個(gè)作品的官網(wǎng)藏在哪里也不需要記住哪個(gè)漢化組發(fā)過(guò)公告打開(kāi)導(dǎo)航站就能找到方向。需要說(shuō)明的是GALNAVI 具體收錄了什么、界面長(zhǎng)什么樣、如何分類(lèi)這要以項(xiàng)目 README、倉(cāng)庫(kù)文件和實(shí)際展示為準(zhǔn)。我這里說(shuō)的是一般導(dǎo)航平臺(tái)常見(jiàn)的信息組織方式。1.2 為什么瀏覽器收藏夾解決不了這個(gè)問(wèn)題很多人第一反應(yīng)是找東西收藏不就行了收藏夾當(dāng)然適合個(gè)人保存少量常用鏈接但一旦條目超過(guò)幾十個(gè)它的問(wèn)題就會(huì)暴露出來(lái)。收藏夾是扁平的沒(méi)有分類(lèi)狀態(tài)也沒(méi)有字段。你存了一個(gè)官網(wǎng)過(guò)幾天發(fā)現(xiàn)作品出官中了收藏夾不會(huì)自動(dòng)幫你更新?tīng)顟B(tài)。鏈接失效了收藏夾也不會(huì)提醒你只有點(diǎn)開(kāi)時(shí)看到 404 才知道。更重要的是收藏夾只有你自己能看到?jīng)]法讓別人參與補(bǔ)充也沒(méi)法形成一份公共信息索引。導(dǎo)航平臺(tái)比收藏夾多出來(lái)的不是“鏈接列表”而是“結(jié)構(gòu)”和“狀態(tài)”。這也解釋了為什么這種項(xiàng)目值得做成開(kāi)源平臺(tái)而不是私人書(shū)簽。它要解決的問(wèn)題本質(zhì)上是把一個(gè)垂直領(lǐng)域的信息碎片整理成一套可持續(xù)更新的公共索引。下面這張表可以對(duì)比一下幾種方式的差異對(duì)比維度瀏覽器收藏夾靜態(tài)導(dǎo)航站開(kāi)源導(dǎo)航平臺(tái)數(shù)據(jù)結(jié)構(gòu)無(wú)結(jié)構(gòu)有簡(jiǎn)單分類(lèi)有統(tǒng)一字段和狀態(tài)狀態(tài)維護(hù)無(wú)手動(dòng)維護(hù)可協(xié)作維護(hù)內(nèi)容來(lái)源個(gè)人個(gè)人維護(hù)社區(qū)提交 維護(hù)者審核技術(shù)門(mén)檻無(wú)中等中等但可參與貢獻(xiàn)長(zhǎng)期風(fēng)險(xiǎn)鏈接失效快信息過(guò)期取決于維護(hù)活躍度1.3 這個(gè)項(xiàng)目標(biāo)題里的“AI 協(xié)助開(kāi)發(fā) 開(kāi)源”意味著什么這個(gè)項(xiàng)目專(zhuān)門(mén)在標(biāo)題里寫(xiě)了“由 AI 協(xié)助開(kāi)發(fā)”我覺(jué)得這不是噱頭而是一個(gè)很實(shí)在的信號(hào)。它說(shuō)明這個(gè)項(xiàng)目很可能沒(méi)有龐大的開(kāi)發(fā)團(tuán)隊(duì)也不是大廠產(chǎn)品而是一個(gè)個(gè)人開(kāi)發(fā)者借助 AI 編程工具完成的。這種組合在以前不太容易出現(xiàn)。以前一個(gè)人從零做一個(gè)導(dǎo)航站要設(shè)計(jì)頁(yè)面、寫(xiě)前端、處理數(shù)據(jù)、部署上線(xiàn)還要考慮移動(dòng)端適配。一套流程下來(lái)至少要幾天甚至幾周?，F(xiàn)在 AI 工具能把頁(yè)面骨架、樣式布局、數(shù)據(jù)渲染這些重復(fù)性工作快速完成人的精力可以放到內(nèi)容篩選、產(chǎn)品設(shè)計(jì)和邊界控制上。開(kāi)源的意義也很直接。它是導(dǎo)航平臺(tái)天然的協(xié)作形態(tài)代碼可以被審查內(nèi)容可以靠社區(qū)貢獻(xiàn)新增條目可以走 issue 和 PR 流程。對(duì)一個(gè)小眾垂直的信息平臺(tái)來(lái)說(shuō)沒(méi)有比開(kāi)源更合適的起步方式了。2. 用 AI 從零搭一個(gè)導(dǎo)航平臺(tái)第一步不是寫(xiě)代碼而是拆需求2.1 把需求拆成最小可用集合很多人都以為用 AI 輔助開(kāi)發(fā)就是跟 AI 說(shuō)一句“幫我做一個(gè)導(dǎo)航站”然后等它生成一個(gè)完整項(xiàng)目。實(shí)際上這是最容易翻車(chē)的做法。需求越模糊AI 生成的代碼越容易返工。不管是 GALNAVI 還是其他類(lèi)似項(xiàng)目一個(gè)導(dǎo)航平臺(tái)的最小可用版本其實(shí)不需要太多功能。按常見(jiàn)實(shí)踐第一版只需要四個(gè)模塊條目列表頁(yè)按分類(lèi)展示作品卡片。詳情信息點(diǎn)進(jìn)去能看到該條目的多個(gè)鏈接和備注。搜索和篩選按作品名或標(biāo)簽過(guò)濾。數(shù)據(jù)文件用 JSON 或 Markdown 維護(hù)條目數(shù)據(jù)而不是寫(xiě)死在頁(yè)面里。用戶(hù)系統(tǒng)、后臺(tái)管理、評(píng)論點(diǎn)贊、訪問(wèn)統(tǒng)計(jì)這些都可以先不做。第一版跑通核心鏈路讓用戶(hù)能快速找到一個(gè)作品的入口就已經(jīng)完成了它的使命。2.2 讓 AI 生成頁(yè)面骨架的提示詞思路如果我要用 AI 編程工具來(lái)做我不會(huì)直接說(shuō)“幫我寫(xiě)一個(gè)導(dǎo)航站”而是會(huì)給出更明確的輸入。一個(gè)常見(jiàn)的提示詞結(jié)構(gòu)是這樣的注意這只是一個(gè)示例結(jié)構(gòu)實(shí)際參數(shù)要結(jié)合你手里的項(xiàng)目來(lái)調(diào)整項(xiàng)目描述這是一個(gè) Galgame 導(dǎo)航平臺(tái)用來(lái)展示作品條目信息。數(shù)據(jù)格式條目來(lái)自 JSON 文件字段包括 name、originalName、tags、officialUrl、communityUrl、status。頁(yè)面模塊需要列表頁(yè)和詳情側(cè)欄列表按標(biāo)簽篩選。交互要求點(diǎn)擊卡片顯示詳情外部鏈接新窗口打開(kāi)。樣式要求卡片式布局簡(jiǎn)潔適配手機(jī)端。這段提示詞的要點(diǎn)不是“寫(xiě)得長(zhǎng)”而是把輸入數(shù)據(jù)、輸出行為說(shuō)清楚。AI 生成的代碼才會(huì)和你的數(shù)據(jù)結(jié)構(gòu)對(duì)得上后續(xù)改動(dòng)也更方便。注意不要讓 AI 一次性生成整個(gè)項(xiàng)目。每個(gè)模塊單獨(dú)生成、單獨(dú)驗(yàn)證出問(wèn)題時(shí)更容易定位。2.3 數(shù)據(jù)模型要先于頁(yè)面這一點(diǎn)值得單獨(dú)強(qiáng)調(diào)。很多人用 AI 寫(xiě)頁(yè)面時(shí)喜歡先讓 AI 生成一張好看的界面再去填數(shù)據(jù)結(jié)果很容易出現(xiàn)字段對(duì)不上的問(wèn)題。更合適的做法是先把數(shù)據(jù)模型定下來(lái)再讓頁(yè)面去適配數(shù)據(jù)。一個(gè)導(dǎo)航條目通常建議包含這樣幾個(gè)字段id唯一標(biāo)識(shí)。title中文名。originalTitle日文原名或官方名。tags標(biāo)簽列表用于分類(lèi)篩選。status當(dāng)前狀態(tài)比如“已漢化”“漢化中”“官方中文”。officialUrl官方發(fā)布頁(yè)或官網(wǎng)。communityUrl社區(qū)討論或攻略入口。note備注比如版本相關(guān)說(shuō)明。先把這些字段寫(xiě)成一個(gè) JSON 文件放上 20 到 30 條真實(shí)數(shù)據(jù)再去讓 AI 開(kāi)發(fā)頁(yè)面。這樣你在開(kāi)發(fā)階段就能看到一個(gè)接近真實(shí)的展示效果而不是滿(mǎn)屏示例文本。數(shù)據(jù)先行頁(yè)面后做能省掉大量返工。2.4 AI 輔助編碼的常見(jiàn)過(guò)程與坑點(diǎn)實(shí)際開(kāi)發(fā)流程可以按這樣的順序來(lái)讓 AI 生成純靜態(tài)的卡片列表頁(yè)面。把 JSON 數(shù)據(jù)文件引入頁(yè)面驗(yàn)證字段是否渲染正確。增加標(biāo)簽篩選和搜索功能。增加詳情展示。本地預(yù)覽通過(guò)后選一個(gè)靜態(tài)托管方式部署。這個(gè)過(guò)程中最容易踩的坑有幾個(gè)。第一個(gè)坑是字段名不一致。AI 可能生成了name字段的頁(yè)面但你的 JSON 里寫(xiě)的是title結(jié)果頁(yè)面顯示 undefined。解決辦法是先把數(shù)據(jù)格式給 AI 看再生成代碼。第二個(gè)坑是依賴(lài)太重。AI 有時(shí)會(huì)引入一個(gè)很大的 UI 庫(kù)或者依賴(lài)多個(gè)外部 CDN導(dǎo)致頁(yè)面加載很慢。對(duì)導(dǎo)航站這種以?xún)?nèi)容為主的頁(yè)面我更建議保持輕量能原生實(shí)現(xiàn)就別上重框架。第三個(gè)坑是移動(dòng)端適配。AI 生成的頁(yè)面有時(shí)候在電腦上看沒(méi)問(wèn)題手機(jī)上卻很糟糕。雖然是 AI 寫(xiě)的但你要在提示詞里明確說(shuō)清楚需要移動(dòng)端適配。第四個(gè)坑是鏈接協(xié)議頭。有些內(nèi)容條目里寫(xiě)的鏈接是www.xxx.com頁(yè)面渲染時(shí)如果沒(méi)有自動(dòng)補(bǔ)全協(xié)議點(diǎn)擊會(huì)跳到站內(nèi)路徑。正確做法是在數(shù)據(jù)里寫(xiě)完整的https://開(kāi)頭的地址。這些細(xì)節(jié)看著小但都會(huì)直接影響一個(gè)導(dǎo)航站能不能正常使用。3. 讓導(dǎo)航平臺(tái)真正可用難點(diǎn)在內(nèi)容維護(hù)不在代碼3.1 內(nèi)容從哪里來(lái)代碼寫(xiě)完之后導(dǎo)航平臺(tái)真正的工作才剛剛開(kāi)始。一個(gè) Galgame 導(dǎo)航平臺(tái)的條目信息源一般是這幾類(lèi)官方渠道發(fā)行商官網(wǎng)、商店頁(yè)面、官方博客或社交賬號(hào)。漢化信息漢化組發(fā)布公告、相關(guān)論壇板塊。攻略資料Wiki 站、社區(qū)指南、攻略帖。綜合信息作品評(píng)價(jià)站、數(shù)據(jù)庫(kù)網(wǎng)站。這些信息源不能全交給 AI 去自動(dòng)抓取和生成。AI 可以幫你整理格式、檢查字段缺漏但“某個(gè)作品當(dāng)前的漢化狀態(tài)”這種信息必須由人工復(fù)核。因?yàn)檫@類(lèi)信息時(shí)效性強(qiáng)一旦寫(xiě)錯(cuò)很容易誤導(dǎo)用戶(hù)。導(dǎo)航站的公信力就建立在準(zhǔn)確度上。3.2 鏈接失效是長(zhǎng)期敵人一個(gè)導(dǎo)航站做了幾年之后最常見(jiàn)的現(xiàn)象不是功能壞了而是鏈接一條條失效。官網(wǎng)改版、項(xiàng)目遷移、作品下架、域名過(guò)期都會(huì)讓舊條目變成死鏈。這不是 GALNAVI 獨(dú)有的問(wèn)題所有導(dǎo)航類(lèi)項(xiàng)目都會(huì)遇到。維護(hù)策略可以從這幾個(gè)層面入手給每條數(shù)據(jù)記錄一個(gè)lastChecked字段標(biāo)出上次檢查時(shí)間?？吹绞l目通過(guò) issue 提交維護(hù)者集中處理。如果項(xiàng)目托管在 GitHub 上可以用 GitHub Actions 寫(xiě)一個(gè)簡(jiǎn)單的定時(shí) HTTP 狀態(tài)檢查腳本把返回 404 的鏈接整理成報(bào)告。這只是一個(gè)工程實(shí)踐思路。但要注意自動(dòng)檢查只能發(fā)現(xiàn)“鏈接打不開(kāi)”無(wú)法判斷“這個(gè)鏈接還是不是最合適的來(lái)源”。所以自動(dòng)化之外人工抽查不能省。注意鏈接失效檢查只能發(fā)現(xiàn)打不開(kāi)不能判斷來(lái)源是否仍然最合適。3.3 開(kāi)源協(xié)作的內(nèi)容貢獻(xiàn)規(guī)則導(dǎo)航平臺(tái)天然適合社區(qū)貢獻(xiàn)但維護(hù)者要提前想清楚一套協(xié)作規(guī)則否則 PR 和 issue 會(huì)變成一團(tuán)亂麻。我建議明確這幾點(diǎn)用 issue 收集“新增條目”或“鏈接失效”的需求。規(guī)定新增條目的數(shù)據(jù)格式比如是否必須包含官方鏈接。限制收錄范圍避免變成大雜燴。對(duì)爭(zhēng)議性條目維護(hù)者有一票否決權(quán)。對(duì)新手貢獻(xiàn)者來(lái)說(shuō)“先看規(guī)則再提交”的方式比直接改代碼更友好。規(guī)則越明確社區(qū)的參與效率反而越高。3.4 做“導(dǎo)航”而不是“搬運(yùn)”是更穩(wěn)妥的邊界這里我想多寫(xiě)一點(diǎn)。一個(gè)導(dǎo)航平臺(tái)完全可以選擇只做索引不托管資源。從項(xiàng)目名字看GALNAVI 定位是“導(dǎo)航平臺(tái)”更像是把玩家引導(dǎo)到官方或社區(qū)信息源而不是提供資源下載入口。做索引而不做搬運(yùn)有兩個(gè)明顯好處。第一減少版權(quán)和安全風(fēng)險(xiǎn)。不需要處理資源存儲(chǔ)、授權(quán)、分發(fā)這些復(fù)雜問(wèn)題項(xiàng)目邊界更干凈。第二長(zhǎng)期維護(hù)成本更低。只要鏈接有效索引就能成立。對(duì)用戶(hù)來(lái)說(shuō)一個(gè)只做可靠信息入口的導(dǎo)航站反而更值得長(zhǎng)期信任。這個(gè)邊界意識(shí)不僅適用于這個(gè)項(xiàng)目也適用于所有類(lèi)似的信息聚合類(lèi)開(kāi)源項(xiàng)目。4. 開(kāi)源 AI 協(xié)作開(kāi)發(fā)正在改變個(gè)人開(kāi)發(fā)的節(jié)奏4.1 AI 把“想法到原型”的距離壓縮了以前一個(gè)人想做一個(gè)垂直導(dǎo)航站需要掌握的知識(shí)包括頁(yè)面結(jié)構(gòu)、樣式、部署、域名配置可能還有數(shù)據(jù)管理。這些東西單獨(dú)看都不難但組合在一起對(duì)非專(zhuān)業(yè)程序員來(lái)說(shuō)就是一道很高的門(mén)檻。AI 編程工具正在降低這個(gè)門(mén)檻。不是變成零門(mén)檻而是從“完全不會(huì)寫(xiě)代碼”變成了“會(huì)描述、會(huì)驗(yàn)證、會(huì)調(diào)整”。普通人也可以先把想法變成一個(gè)能點(diǎn)擊的原型再根據(jù)實(shí)際效果迭代。GALNAVI 這個(gè)項(xiàng)目能出現(xiàn)本身就是這種變化的體現(xiàn)。我長(zhǎng)期觀察開(kāi)源社區(qū)后發(fā)現(xiàn)很多好項(xiàng)目不是被發(fā)明出來(lái)的而是需求一直就在那里只是過(guò)去實(shí)現(xiàn)成本太高。AI 輔助編程改變的是這后半段一個(gè)需求一個(gè)愿意維護(hù)的人再加上一個(gè) AI 助手就能形成一個(gè)真實(shí)的項(xiàng)目。4.2 個(gè)人開(kāi)源項(xiàng)目的生命力靠的是規(guī)則而不是熱情個(gè)人開(kāi)源項(xiàng)目最普遍的結(jié)局是上線(xiàn)時(shí)很有激情一個(gè)月后不再更新。這很正常因?yàn)榫S護(hù)開(kāi)源項(xiàng)目本質(zhì)上是持續(xù)投入而持續(xù)投入需要規(guī)則不能只靠熱情。對(duì)于一個(gè)內(nèi)容型項(xiàng)目比較實(shí)際的做法是在 README 里明確項(xiàng)目處于什么階段比如“剛開(kāi)始建設(shè)”“可以試用”“維護(hù)頻率較低”。列出內(nèi)容貢獻(xiàn)和代碼貢獻(xiàn)的入口。定期發(fā)布更新日志哪怕只是“本周新增 10 個(gè)條目”。把“新增條目”和“修復(fù)失效鏈接”寫(xiě)成模板降低參與門(mén)檻。即使維護(hù)頻率不高只要規(guī)則清楚用戶(hù)也不會(huì)覺(jué)得項(xiàng)目失去了方向。開(kāi)源不等于必須高強(qiáng)度維護(hù)但一定要把狀態(tài)說(shuō)清楚。4.3 對(duì)學(xué)習(xí)者的啟示把它當(dāng)成 AI 編程的“閱讀樣本”對(duì)正在學(xué) AI 輔助編程或前端開(kāi)發(fā)的人來(lái)說(shuō)像 GALNAVI 這樣的開(kāi)源項(xiàng)目是一個(gè)很合適的學(xué)習(xí)對(duì)象。你可以做三件事讀 README看作者是怎么介紹這個(gè)項(xiàng)目的?？磾?shù)據(jù)文件和頁(yè)面代碼理解數(shù)據(jù)驅(qū)動(dòng)頁(yè)面渲染的思路。把它 clone 到本地自己部署一次再換一批數(shù)據(jù)試試。這不是讓你復(fù)制粘貼而是看一個(gè)完整的個(gè)人項(xiàng)目是怎么組織起來(lái)的。很多時(shí)候項(xiàng)目本身的技術(shù)深度不一定高但“結(jié)構(gòu)清晰”就是很強(qiáng)的學(xué)習(xí)價(jià)值。5. 如果也想做類(lèi)似的導(dǎo)航站我建議按這個(gè)順序入手5.1 先定義邊界再定義功能動(dòng)手之前先回答三個(gè)問(wèn)題這個(gè)導(dǎo)航平臺(tái)給誰(shuí)用收錄什么品類(lèi)不收錄什么品類(lèi)每個(gè)條目最少包含哪些信息邊界越清楚后續(xù)越輕松。如果你一上來(lái)就想做一個(gè)“覆蓋全品類(lèi)的終極導(dǎo)航站”很快就會(huì)因?yàn)閮?nèi)容量太大而沒(méi)法推進(jìn)。好的垂直導(dǎo)航往往是先從一個(gè)非常具體的需求開(kāi)始。5.2 先手工填 20 到 30 條真實(shí)數(shù)據(jù)我特別建議先手工收集一批真實(shí)數(shù)據(jù)整理成 JSON 或 CSV。這一步有兩個(gè)作用讓你真實(shí)感受一個(gè)條目需要哪些字段。給 AI 提供真實(shí)數(shù)據(jù)頁(yè)面開(kāi)發(fā)時(shí)不需要用假數(shù)據(jù)占位。數(shù)據(jù)質(zhì)量比數(shù)據(jù)數(shù)量重要。先做到“20 條完全可靠”比“100 條大多有錯(cuò)”更值得。重要先用手工維護(hù)數(shù)據(jù)再寫(xiě)代碼這個(gè)順序不要反過(guò)來(lái)。數(shù)據(jù)模型沒(méi)定好代碼寫(xiě)得再多也容易返工。5.3 再按“列表、搜索、詳情、部署”的順序迭代頁(yè)面開(kāi)發(fā)順序建議是這樣列表頁(yè)把 JSON 中的條目渲染成卡片。單個(gè)作品詳情展示多條鏈接和備注。搜索和篩選按作品名和標(biāo)簽過(guò)濾。部署上線(xiàn)選一個(gè)靜態(tài)托管平臺(tái)把頁(yè)面發(fā)布出去。這個(gè)順序的核心邏輯是先讓用戶(hù)能看見(jiàn)信息再讓用戶(hù)能找到信息最后才是讓項(xiàng)目能被訪問(wèn)。每一步都能獨(dú)立驗(yàn)證不會(huì)出現(xiàn)“寫(xiě)了一大堆代碼但不知道問(wèn)題出在哪”的情況。5.4 長(zhǎng)期維護(hù)的工程化建議如果項(xiàng)目真的有人開(kāi)始用了可以接著考慮這些工程化能力給倉(cāng)庫(kù)加 issue 模板區(qū)分“條目新增”“鏈接失效”“功能建議”。給條目加狀態(tài)字段記錄是否仍在線(xiàn)。適當(dāng)增加訪問(wèn)統(tǒng)計(jì)了解實(shí)際使用情況?？刂埔蕾?lài)數(shù)量減少構(gòu)建復(fù)雜度避免幾個(gè)月后還要處理一堆依賴(lài)升級(jí)問(wèn)題。就個(gè)人項(xiàng)目而言很多項(xiàng)目死在“依賴(lài)升級(jí)”上。初期依賴(lài)越少越好能原生實(shí)現(xiàn)就不引入框架。技術(shù)棧新不一定好適合自己的維護(hù)能力才是關(guān)鍵。5.5 常見(jiàn)問(wèn)題與排查鏈路如果你做完部署后遇到問(wèn)題可以按下面的順序排查現(xiàn)象頁(yè)面打不開(kāi)、數(shù)據(jù)沒(méi)顯示、搜索無(wú)結(jié)果、鏈接跳 404。第一步打開(kāi)瀏覽器開(kāi)發(fā)者工具看 Network 請(qǐng)求確認(rèn)靜態(tài)資源是否加載成功。第二步直接訪問(wèn) JSON 文件地址看數(shù)據(jù)是否可獲取、格式是否合法。第三步檢查頁(yè)面代碼中的字段名是否和數(shù)據(jù)文件的字段一致。第四步檢查鏈接是否寫(xiě)全了協(xié)議頭比如https://。第五步檢查部署環(huán)境是否有路徑問(wèn)題比如使用靜態(tài)托管子路徑時(shí)資源基礎(chǔ)路徑要配置正確。這個(gè)順序可以套用到絕大多數(shù)靜態(tài)導(dǎo)航站類(lèi)項(xiàng)目。先查輸入再查數(shù)據(jù)再查代碼再查部署是通用鏈路。6. 內(nèi)容質(zhì)量才是這類(lèi)項(xiàng)目最大的護(hù)城河6.1 GALNAVI 是一個(gè)“可完成的事”回到項(xiàng)目本身。GALNAVI 的定位、命名和開(kāi)源方式?jīng)Q定了它首先是一件“可完成的事”。它不是超大平臺(tái)而是一個(gè)垂直、小而美的信息入口。它可能不會(huì)變成大眾產(chǎn)品也不需要變成大眾產(chǎn)品。對(duì)使用它的人來(lái)說(shuō)能找到可靠信息就夠了。這種“夠用就好”的克制反而是很多個(gè)人開(kāi)源項(xiàng)目能走下去的原因。6.2 小眾需求會(huì)因?yàn)?AI 而被更多實(shí)現(xiàn)AI 輔助編程帶來(lái)的一個(gè)長(zhǎng)期變化是更多垂直、小眾、看起來(lái)“不賺錢(qián)”的需求會(huì)被低成本地實(shí)現(xiàn)。過(guò)去一個(gè)導(dǎo)航平臺(tái)至少需要一個(gè)能寫(xiě)前后端的人現(xiàn)在只需要一個(gè)對(duì)領(lǐng)域足夠了解、愿意維護(hù)內(nèi)容的人。GALNAVI 只是其中一個(gè)方向?？梢灶A(yù)見(jiàn)的是類(lèi)似的“AI 輔助個(gè)人開(kāi)發(fā) 開(kāi)源協(xié)作”項(xiàng)目會(huì)越來(lái)越多。這種模式真正的價(jià)值不是省下了多少開(kāi)發(fā)時(shí)間而是讓越來(lái)越多原本無(wú)法啟動(dòng)的想法有了被做出來(lái)的可能。6.3 代碼可以交給 AI判斷必須留給人最后想強(qiáng)調(diào)一點(diǎn)無(wú)論 AI 能把開(kāi)發(fā)效率提升多高對(duì)于一個(gè)信息型平臺(tái)來(lái)說(shuō)真正決定價(jià)值的仍然還是內(nèi)容是否準(zhǔn)確、更新是否及時(shí)、是否有維護(hù)者在持續(xù)把關(guān)。AI 可以生成一套完整的頁(yè)面代碼可以讓維護(hù)流程更順暢但它不能代替人判斷“什么值得收錄”“這個(gè)鏈接是否可靠”“這條狀態(tài)是否過(guò)時(shí)”。這些判斷屬于領(lǐng)域知識(shí)和長(zhǎng)期投入不是模型生成的臨時(shí)輸出。所以如果你也想投入一個(gè)類(lèi)似的項(xiàng)目最后一個(gè)建議是先不想代碼先想清楚你要維護(hù)一個(gè)什么樣的信息源以及你愿意為它投入多長(zhǎng)時(shí)間。這個(gè)答案比任何技術(shù)選型都重要。GALNAVI 展示的正是 AI 輔助開(kāi)發(fā)的甜點(diǎn)區(qū)間需求明確、范圍有限、結(jié)構(gòu)清晰借助工具快速落地再通過(guò)開(kāi)源把維護(hù)成本分散到社區(qū)。至于它能走多遠(yuǎn)取決于內(nèi)容機(jī)制也取決于人。這不只是這一個(gè)項(xiàng)目的命題也是所有個(gè)人 AI 開(kāi)發(fā)項(xiàng)目的共同命題。