K 線騎手 K-Rider:騎上真實 K 線,盡量別摔車

這篇講的東西

先講結論:K-Rider 不是一個「我很會寫遊戲」的作品,是一個「我很會發包」的作品。

程式碼幾乎都是 AI 寫的。但這台遊戲要做什麼、範圍切在哪、什麼叫「做對了」—— 這些是我定的。這篇就是把這條分工線攤開:一個沒有團隊的人,怎麼用甲方思維把 AI 當成一整個外包團隊,從一句點子做到上線。

如果你也想用 AI 做東西,卻常常「叫它做個 X」然後收到一坨跑不動的東西 —— 問題多半不在 AI,在發包。

先說 K-Rider 是什麼

騎機車衝真實股價 K 線的網頁小遊戲。台股紅漲綠跌、美股反過來;把一檔股票某段區間的 K 線變成賽道地形,騎過去,沿途撞上 AI 生成的歷史事件路牌(那天為什麼大漲大跌),摔車後被 AI 嘴一句。

它有真實資料(每天自動抓 Yahoo Finance)、有物理(Matter.js)、有排行榜、有 AI 賽評、有 email 留資漏斗。是一個麻雀雖小五臟俱全的產品,不是一個 demo。

好,回到重點:這麼多零件,一個人怎麼發包出來的。

甲方思維:三個動作

我把整個過程拆成三個動作,反覆循環:開規格 → 下發包 → 做驗收。

甲方不寫程式,甲方寫規格、驗收成品。你把 AI 當乙方,你自己就得站到甲方的位置 —— 這是這整套方法的核心。下面一段一段講。

一、開規格:一頁,四格,講完就能發包

開工前我沒有先寫任何程式,先寫了一頁規格書。四格,講完就能發包:

  • 受眾:想培養盤感、對股價波動有體感,但不想真金白銀進場賠錢的人。把抽象的紅綠 K 線變成可以親手騎過去的地形。
  • 核心玩法價值:真實歷史股價 → 賽道地形。騎機車衝過大波動日,撞上 AI 生成的事件路牌,摔車後被 AI 嘴。把「看不懂的線」變成「騎得過去的坡」。
  • 區塊:選關 → 騎乘 → 結算 → 分享 + 留資。
  • 驗收:地形保證可玩、機車手感靠實測定案、AI 賽評防投毒。

這一頁裡最重要的其實是我刻意不做什麼。重度防作弊(伺服器端重播驗證)、玩家帳號系統、自訂車輛 —— 全部切掉,丟進 v2 backlog。

先做出「能玩的天花板」,不做「防禦性的完美」。範圍是甲方的責任,不是乙方的。如果我不劃線,AI 會很樂意幫我把每個功能都做到滿,然後我永遠上不了線。開規格一半是在寫要做什麼,另一半是在寫不要做什麼。

二、下發包:不是「做個遊戲」,是一段一段可驗收的任務

這是最多人做錯的地方。「幫我做一個股價遊戲」不是發包,是許願。

發包是把規格拆成一段一段、每段都附一句夠具體、且收得了成品也驗得了的指令。舉幾個 K-Rider 實際的發包(完整的 prompt 鏈在拆解手冊裡):

先畫面、後程式。 我沒讓 AI 邊寫邊猜版面,而是先用生圖工具把 HUD 和結算卡畫成 mock 圖,照著圖落 CSS。發包長這樣:「畫一張暗色 neon 風的機車越野 HUD:左上累計分數、上方計時與氮氣條、右上全賽道縮圖小地圖……自有配色,不抄任何現有遊戲素材。」有了圖,對齊的成本就從「來回猜」變成「照稿做」。

手感用實測定案,不靠感覺喊。 機車物理我沒讓 AI「調到感覺對」,而是要它寫 headless 模擬:「機車是單一剛體,寫測試證明落平地 3 秒內穩定不抖、35 度連續上坡油門爬得上去、亂力轟炸 10 秒輪距恆定。」手感變成可以跑的數字,不是嘴上的形容詞。

漏斗:免費價值先給,再換 email。 「結算頁底掛一個零依賴 email 表單,藏一個 honeypot 欄位擋機器人,送出後當場回一條精選賽道連結即時兌現,重複留資也照樣再給。」

你看每一句發包的共同點:都內建了「怎麼算做對」。 這不是巧合 —— 一段你驗不了的發包,等於沒發包。

三、做驗收:規格寫了不算數,要能重複跑

發包出去、AI 交回東西,不能靠「我玩了一下感覺 OK」。K-Rider 的驗收是真的自動化測試(83 個),挑幾條代表性的:

  • 機車落地穩定不抖、不穿地:平地放 3 秒讓它靜止,車身位移要小於 2px、角度小於 0.3 弧度,人要在地面上方。
  • 爬坡力回歸測試:35 度連續上坡全程油門,驗證車真的爬得過去 —— 之後誰改物理參數,不准把這條弄壞。
  • 輪距不變量:亂力轟炸 10 秒,每一幀斷言前後輪距不變。因為整台車是單一剛體,輪胎在幾何上不可能變形 —— 這條不是「應該不會變」,是「結構上不可能變」,測試把它釘死。
  • AI 賽評防 prompt injection:賽後 AI 吐槽的共享快取只開放給精選股,避免有人用自訂 ticker 塞 prompt injection 去投毒別人會讀到的快取。

驗收清單是甲方最後的護城河。有了它,AI 迭代得再快,品質都不會漂走 —— 因為每一版都要先通過同一組「做對了沒」。這也是為什麼我敢讓 AI 大改物理程式碼卻不擔心:改壞了,測試會紅給我看。

為什麼要這樣分工

有人會問:AI 都能寫程式了,幹嘛還要人這麼囉嗦地開規格、驗收?

因為會變的東西和帶得走的東西是兩回事。程式碼是耗材 —— 模型換一代,同一份規格可以重新生成一份更好的程式碼。真正帶得走、決定成品好壞的,是「規格開得準不準、驗收收得緊不緊」。這兩件事,今天還是人做得比較好,而且是最值得練的。

所以這篇要很明確地標分工:K-Rider 的點子、範圍、每一個「要不要做」的決策、每一條驗收標準,是我(林亞澤)定的;把這些規格落成能跑的程式碼,是 AI 做的。 我不冒認自己手刻了物理引擎,也不把功勞一股腦推給 AI —— 甲方的價值就在規格與驗收這條線上,那條線是我畫的。

想學這套的話

K-Rider 是我把一整套技能疊到產品級的「天花板案例」。同一套東西 —— 生圖、特效、部署排程、AI Worker、名單漏斗 —— 我拆成一堂堂單招,放在 AI 互動行銷頁實作課 裡;課程教你在一頁活動頁上學會每一招,K-Rider 示範把全部疊起來會長成什麼。

一條完整的學習線(從學單招到做出產品級作品)在這裡:https://yazelin.github.io/ai-marketing-pages-course/series.html

而貫穿全部的,就是這篇講的甲方思維:開規格、下發包、做驗收。 AI 是很強的乙方,但你得先學會當甲方。

先去玩玩看,再回頭看它是怎麼被發包出來的: