3天3個功能：1.5萬行代碼怎么切出來的

一個功能通常吃掉一周。設計、實現、界面、國際化、營銷頁、文檔，逐個來。這是作者學到的規則。4月28日到30日，他發了三個：關鍵詞搜索、模型上下文協議服務器、月刊。41次提交，15380行代碼。

不是并行，是切片

先澄清：不是三管齊下。一天一個，三天發完。能成的原因很簡單——每個功能被切成階段，丟給克勞德（Claude，AI編程助手）的單元很小。

這三個功能建在Apsity儀表盤之上。EP.02搭了儀表盤，EP.03加了AI洞察。本周的三件事疊在上面：關鍵詞發現、直接從克勞德調用數據、自動化月刊。

它們不是孤立的。是一個流程。Apsity本來就能顯示已注冊應用的數據——收入、下載量、關鍵詞排名、競品變動。缺的是三件事："新關鍵詞從哪找？""怎么在其他工具里用這些數據？""這個月發生了什么，我要一頁看完。"

關鍵詞搜索解決發現。應用商店優化（ASO）歸根結底是選詞。只看已注冊關鍵詞是魚缸視野，得看別人怎么出現。于是拉取18個國家的iTunes前50，讓AI總結，用戶把有潛力的詞存進觀察清單。

模型上下文協議（MCP）服務器是出口。有時候你想用自然語言問克勞德，而不是打開Apsity。"昨天收入怎么樣？"——克勞德問Apsity，然后回答。這個想法從EP.15做npm-subscriber-mcp時就有了。

月刊是回顧。EP.03做了每日提醒，但每日太吵。過了一個月，你想回頭看發生了什么，而數據散在各處。每月1號聚合，郵件發送，完事。

連起來：發現→使用→回顧。 workflow兩端原本缺失的部分。所以一起發。

正方：切片是唯一的杠桿

三個周級功能三天完成，原因確實簡單。作者從不把功能看成一大塊。切成小階段，每階段以可運行的產物和一次提交結束。

月刊的切片長這樣：

階段1——語言設置（設置里加ko/en）
階段2——月度聚合函數
階段3——克勞德生成月刊正文
階段4——4個卡片組件（指標/圖表/評論/建議）
階段5——月刊頁面渲染
階段6——郵件發送（4卡片內聯）
階段7——命令行測試工具

階段1和2獨立。階段3依賴階段2的輸出。階段4和5建在階段3的結果上。依賴圖看起來是串行，但階段2和4可以并行。早點定義數據結構，然后分別做聚合查詢和卡片界面。

兩個好處。第一，丟給克勞德的單元變小。"做個月刊"太模糊，"做個月度聚合函數，輸入是這個結構，輸出是那個結構"就清晰。克勞德的輸出質量取決于輸入的精確度。

第二，每階段結束都有東西能跑。不是"做了80%但跑不起來"，是"階段2跑完，聚合函數能返回正確數據"。心理賬戶不同，回滾點也不同。

作者提到一個細節：階段3讓克勞德生成正文，但正文結構是固定的。不是"隨便寫個月度總結"，是"按這四個板塊寫，每個板塊有字數限制和必含數據點"。約束給足，AI輸出才穩。

卡片組件的設計也體現切片思維。四個卡片獨立開發，最后拼成頁面。如果某個卡片有問題，不影響其他三個上線。階段6的郵件內聯是常見坑點——網頁渲染和郵件客戶端渲染是兩回事，單獨成一個階段，專門測試各郵件客戶端的兼容性。

反方：切片不是萬能藥

但切片有代價。階段切得越細，上下文切換越頻繁。作者三天41次提交，平均每天近14次。這意味著每天至少14次進入"這是什么階段、當前狀態、下一步做什么"的認知加載。

對于復雜功能，階段間的依賴可能隱藏。月刊的依賴圖被描述為"看起來串行，但2和4可以并行"——這個判斷需要全局視圖。新手容易切錯，導致后期返工。階段3依賴階段2的輸出，如果階段2的數據結構定義有問題，階段3、4、5、6全要改。

另一個風險：切片讓人產生"進度很快"的幻覺。七個階段做完六個，感覺"只剩一個"，但階段6（郵件發送）可能卡住三天。郵件客戶端的兼容性、退信處理、圖片內聯、垃圾郵件過濾，每個都是深坑。作者提到"專門測試各郵件客戶端"，說明踩過或預見到了。

克勞德的單元變小，但協調成本上升。41次提交背后是41次提示工程（prompt engineering）。每次都要交代背景、當前代碼狀態、期望輸出。對于大型代碼庫，"當前代碼狀態"本身的描述就很長。作者沒有提上下文窗口（context window）的限制，但15380行代碼的改動，不可能每次全量塞進提示。

還有一個未言明的前提：Apsity的底子已經打好。EP.02和EP.03的基礎設施——儀表盤框架、AI洞察管道、數據模型——是這三個功能的地基。如果從頭建一個新產品，三天三個功能是不可能的。切片的前提是已有可復用的模塊和穩定的數據流。

國際化（i18n）被輕描淡寫地放在"通常吃掉一周"的清單里，但實際很耗。階段1的語言設置只是開關，真正的翻譯工作——月刊正文的多語言生成、郵件模板的多語言版本——被分散在各階段。作者沒有提翻譯是誰做的：克勞德生成？人工校對？還是只做英語和韓語？如果是AI生成，質量是否經過審核？這些細節被切片的光滑表面蓋住了。

判斷：切片是工具，不是方法論

這件事的真正價值，在于展示了AI輔助開發的一種可行節奏。不是"用AI寫代碼更快"這種籠統說法，而是具體的操作參數：階段粒度控制在幾小時到一天，每個階段有明確的輸入輸出定義，AI負責實現而人負責驗收。

作者沒有說"這是最佳實踐"，只是記錄。但記錄本身有信息量：15380行代碼，41次提交，7個階段——這些數字暗示了工作量的分布。平均每次提交375行，對于AI輔助開發來說偏保守，說明作者在看AI的輸出，而不是全盤接受。

三個功能的選擇也有講究。關鍵詞搜索是數據輸入，MCP服務器是數據輸出，月刊是數據消費。形成一個閉環，而不是三個孤立功能。這種產品思維——用功能組合解決完整用戶旅程——比切片技術更值得學。

切片能成功的隱性條件：產品方向已經驗證，技術債務可控，AI工具鏈熟悉。少了任何一條，三天變三周。作者的經歷是"在特定約束下的可行解"，不是"普遍適用的加速公式"。

對于讀者，可帶走的是檢查清單：你的功能能不能拆成"幾小時能跑通"的階段？每個階段的輸入輸出是否提前定義？AI生成后你有沒有人工驗證？這些比"我也用克勞德"更重要。

最后，那個命令行測試工具（階段7）容易被忽略。它不是用戶可見的功能，是開發者的安全網。發郵件前能本地跑一遍，不用真的等每月1號。這種"為開發體驗投資"的意識，往往是三天和三周的分水嶺。

三天發完，代碼在倉庫里。但真正的產品驗證——用戶用不用關鍵詞搜索、MCP服務器的調用頻率、月刊的打開率——才剛剛開始。切片加速了開發，沒加速驗證。這部分時間，省不了。