3天3個功能：一個獨立開發者的交付實驗

41次提交，15380行代碼。三個通常各需一周的功能，被壓縮到72小時完成。作者沒加班，只是換了一種拆解方式。

這是Apsity開發者記錄的真實交付過程：關鍵詞搜索、模型上下文協議（MCP）服務器、月度報告——三個功能構成完整的數據工作流閉環。

三個功能，一條工作流

Apsity的核心是應用商店數據看板：收入、下載量、關鍵詞排名、競品動態。但用戶反復問三個問題：

「新關鍵詞去哪找？」「怎么在其他工具里用這些數據？」「這個月到底發生了什么？」

關鍵詞搜索解決「發現」。只盯著自己注冊的關鍵詞是魚缸思維。作者拉了18個國家的iTunes前50數據，讓AI總結，用戶可把潛力詞存進監控列表。

MCP服務器解決「使用」。用戶想直接在Claude里問自然語言問題：「昨天收入怎么樣？」Claude調用Apsity接口返回答案。這個想法從EP.15的npm-subscriber-mcp就開始醞釀。

月度報告解決「回顧」。EP.03的每日提醒太碎。每月1號自動聚合數據，郵件發送，一頁紙看完。

發現→使用→回顧。工作流的兩端補上了，所以三個功能一起發。

拆解：把「一周」切成七片

月度報告的拆解過程被完整記錄：

階段1：語言設置（韓/英切換）

階段2：月度聚合函數

階段3：Claude生成報告正文

階段4：四個卡片組件（指標/圖表/評論/建議）

階段5：報告頁面渲染

階段6：郵件發送（四卡片內嵌）

階段7：命令行測試工具

階段1和2獨立。階段3依賴階段2的輸出。階段4、5基于階段3的結果。看起來是串行，但階段2和4可以并行——只要提前定義好數據格式，聚合查詢和卡片UI就能分開做。

兩個直接收益。

第一，丟給Claude的單元變小。「做月度報告」太模糊。「寫一個聚合上月數據的SQL函數」足夠具體。

第二，每階段結束都有可運行的東西。不是等七天看結果，是每天多次驗證方向。

正方：小單元交付是速度的來源

作者的核心論點：速度不是來自加班，來自認知負荷管理。

大功能拆成小階段后，每個階段的決策點變少。語言設置只管語言設置，不用想郵件模板。這種隔離讓AI輔助編碼更有效——上下文窗口里只放當前階段的需求。

并行空間也被釋放出來。階段2和4的并行依賴「數據格式先行」的約定。提前定義接口，兩邊各自推進，最后拼接。

41次提交分布在三天，意味著平均每天13-14次代碼快照。這不是為了刷數字，是階段邊界的外化。每次提交對應一個可回滾的檢查點。

反方：這種方法的隱性成本

但原文也暴露了張力。

「階段2和4可以并行」——前提是開發者能預判數據格式。如果前期設計偏差，后期拼接成本可能超過串行開發。月度報告的七個階段看似清晰，實際依賴作者對郵件渲染、卡片布局的預先想象。

另一個問題：三個功能真的「獨立」嗎？作者承認它們「是一個單一工作流」。這意味著功能間的耦合被設計進去了。如果用戶需求變化，這個預設的流可能變成枷鎖。

還有15380行代碼的質量。三天高強度輸出，測試覆蓋度、邊界處理、技術債務——原文沒提，但不等于不存在。小階段交付加速了可見進度，是否加速了可維護性？

判斷：一種特定條件下的可行策略

這個案例的價值不在「三天三功能」的數字，而在它展示了單人開發的約束優化。

作者的條件很具體：已有EP.02/03的底座（看板+AI洞察）、功能間存在預設的工作流關系、AI輔助編碼降低實現成本。這些條件不滿足，拆解策略的效果會打折扣。

對讀者的啟示可能是反直覺的：快不是目標，可驗證的進度才是。七個階段的價值不在于并行效率，而在于每個階段結束都能回答「這步對嗎」。

至于MCP服務器的長期意義——讓Claude直接調用業務數據——這比關鍵詞搜索或月度報告都更接近基礎設施層。如果模型上下文協議成為行業標準，Apsity的早期實驗會轉化為先發優勢。

當然，前提是用戶真的愿意在聊天窗口里問「昨天收入怎么樣」，而不是打開看板自己點。

作者最后沒說的是：這三個功能上線后，用戶用了嗎？