半年前我第一次打開 WorkBuddy心態(tài)很天真把 App 需求往輸入框一貼它就該把能跑的代碼全吐出來。試了一下午demo 確實跑起來了但 UI 丑、邏輯亂、一加功能就崩離“能上線”三個字隔著十萬八千里。后來我把 WorkBuddy 當成一個真正的協(xié)作者來管——給它定規(guī)則、配工作臺、拆任務(wù)、做代碼評審前后三周把一個工具型 App 推到應用商店順利過審。這篇文章就把這條路線完整拆給你六個階段、十六個坑外加一份可以直接抄走的交付清單。不管你是第一次用 WorkBuddy 做真實項目還是已經(jīng)在用它寫 demo 但不知道怎么收尾成產(chǎn)品按這套流程走能少繞很多彎。1. 先說結(jié)論WorkBuddy 能不能扛起“上線”這件事1.1 WorkBuddy 不是普通聊天框而是一個需要“管理”的工作臺先聊一個容易混淆的問題WorkBuddy 和 CodeBuddy 到底是什么關(guān)系這兩年社區(qū)里兩個名字經(jīng)常一起出現(xiàn)教程也常常混著講。按我的使用體會可以粗暴理解成同源不同定位——CodeBuddy 更偏向編輯器里的“程序猿助手”而 WorkBuddy 強調(diào)的是可配置的工作臺你可以在里面搭建不同的 Workspace給每個 Workspace 掛上不同技能Skill和規(guī)則Rules讓它在既定邊界里干活。提示如果你只用它聊天等于買了一臺有自動駕駛的車卻一直手動推著走。我第一次用的時候完全沒有這個概念把需求整段丟進去讓它“給我做一個記賬 App”。它確實能干生成了頁面、數(shù)據(jù)庫和接口調(diào)用但所有代碼擠在一個會話里散落各處——沒有分層、沒有統(tǒng)一錯誤處理、沒有設(shè)計約束后續(xù)每加一個小功能都會改動好幾個文件改完一個崩一個。那一刻我明白了WorkBuddy 的定位本來就不是“一句話生成整個項目”的黑盒而是一個需要你定規(guī)則、分任務(wù)、做驗收的智能勞動力。1.2 我判斷“能上線”的三個標準既然目標是“能上線”就不能用跑通 demo 的標準來驗收。我自己定義了三把尺子穩(wěn)定性核心功能不閃退、數(shù)據(jù)不丟、弱網(wǎng)和異常輸入下不崩。AI 生成代碼最容易缺的正是失敗分支這部分必須重點盯。可維護性代碼結(jié)構(gòu)能讓人看懂、能繼續(xù)改。如果生成完只有 AI 自己看得懂下一次迭代就是災難?？砂l(fā)布性構(gòu)建、簽名、審核、商店后臺配置這一套流程能走通包括圖標、隱私政策、權(quán)限說明這些看起來不起眼但缺一個就上不了架的東西。拿這三把尺子去量你會發(fā)現(xiàn)很多“demo 跑通了”的興奮瞬間其實還很遠。這也決定了后面每一個階段我都用“產(chǎn)出物是否達標”來判定能否進入下一步。1.3 六個階段到底怎么劃分的整條鏈路我拆成了六個階段順序可以調(diào)整但“上一階段沒驗收完不進入下一階段”這條鐵律不要破階段目標核心產(chǎn)出物對應坑階段一需求拆分與技術(shù)選型需求清單 技術(shù)棧決策坑 13階段二環(huán)境搭建與工作臺配置可復現(xiàn)的開發(fā)環(huán)境坑 46階段三規(guī)則、技能與對話策略Rules Skill 配置坑 79階段四核心功能開發(fā)可運行的功能版本坑 1012階段五聯(lián)調(diào)、構(gòu)建與出包可安裝的包坑 1314階段六上架審核與上線后運營商店在架的 App坑 1516我把“上架后”也放進階段六是因為很多人以為提交成功就結(jié)束了結(jié)果第一天就被用戶反饋打回原形。上線不是終點是新一輪迭代的起點這個后面細說。2. 階段一把需求磨碎再動手坑 132.1 坑 1需求沒拆碎整段丟給 AI這是最普遍的一個坑我自己也踩得很扎實。把“幫我做一個記賬 App”這種需求整體丟給 WorkBuddy它確實會給你生成一個完整項目但問題在于代碼看起來都全實際卻是一鍋粥。生成出來的頁面動輒上千行狀態(tài)管理和 UI 混在一起數(shù)據(jù)庫字段和頁面字段互相糾纏。你想讓它改一個統(tǒng)計邏輯它可能把列表也一起動壞了。后來我把需求拆成了一個一個“一句話任務(wù)”新建項目搭建基礎(chǔ)目錄結(jié)構(gòu)配置數(shù)據(jù)庫表用戶表、賬單表、分類表實現(xiàn)登錄頁手機號 驗證碼實現(xiàn)賬單列表頁實現(xiàn)賬單新增表單實現(xiàn)統(tǒng)計頁。每拆完一個任務(wù)單獨開一次對話讓 WorkBuddy 去完成完成后先人工看一遍代碼再進入下一個任務(wù)。整個開發(fā)節(jié)奏一下子可控了。有一個我自用的拆分模板可以抄功能賬單新增表單 驗收標準 1. 用戶可輸入金額、分類、備注、日期 2. 金額只允許數(shù)字且大于 0 3. 表單校驗失敗時給出中文提示不提交 4. 提交成功后返回列表頁并刷新列表 5. 網(wǎng)絡(luò)失敗時保留輸入內(nèi)容允許重試。提示驗收標準寫得越具體AI 生成出來的東西越接近你要的。別把“能跑”當驗收標準要把“符合這 5 條”當驗收標準。2.2 坑 2技術(shù)棧選錯AI 生成的質(zhì)量先天打折這個坑很多人不會意識到。大模型訓練時對不同技術(shù)棧的“見過程度”完全不同越是主流、社區(qū)資料越多的技術(shù)棧AI 生成質(zhì)量越穩(wěn)越是小眾或者文檔混亂的框架AI 越容易一本正經(jīng)地寫出錯誤代碼看起來沒問題一運行就報錯。我當時的取舍邏輯是三點團隊熟不熟、生態(tài)強不強、AI 數(shù)據(jù)多不多。工具型 App 最終選了 WebView 殼 Web 內(nèi)頁的方案原因很現(xiàn)實這個技術(shù)棧我熟、調(diào)試快、WorkBuddy 生成質(zhì)量相對穩(wěn)定而且后續(xù)迭代成本低。項目開始前花一個半小時做個技術(shù)棧對比表能避免后面半個月返工。對比維度至少要有AI 生成質(zhì)量、生態(tài)成熟度、真機調(diào)試難度、上線門檻。別只選“最酷的”要選“AI 最會寫的”。2.3 坑 3沒把“要上線”寫進需求后面全是補課我最初的需求清單全是功能描述“能登錄”“能記賬”“能統(tǒng)計”?？雌饋頉]毛病但“上線”這兩個字背后還有一堆需求沒說出口首次啟動要不要隱私協(xié)議彈窗申請相機或相冊權(quán)限時要不要解釋理由沒網(wǎng)的時候頁面怎么辦用戶清緩存后本地數(shù)據(jù)會不會丟這些不寫進需求WorkBuddy 就默認不管它不管審核階段和用戶手里就會出問題。我后面為了這些補課花了不亞于開發(fā)的時間。正確的做法是在需求清單里單列一欄“上線約束”上線約束 - 首次啟動展示隱私協(xié)議用戶同意后才可以進入主流程 - 獲取定位、相冊、麥克風等敏感權(quán)限前必須彈窗說明用途 - 所有頁面必須有網(wǎng)絡(luò)異常狀態(tài)和重試按鈕 - 關(guān)鍵操作刪除、支付、清空數(shù)據(jù)需要有二次確認。把這些約束固定成全局規(guī)則之后AI 生成的每一個功能都會自動帶上對應處理相當于在源頭過濾掉了一大批審核風險。階段一總結(jié)需求拆得越碎AI 干得越穩(wěn)技術(shù)棧選得大眾生成質(zhì)量越高上線約束想得越早返工越少。3. 階段二環(huán)境搭建與工作臺配置坑 463.1 坑 4版本裝錯普通版和國際版不是一回事WorkBuddy 的安裝階段就有坑。我在網(wǎng)上順手找了個版本裝上界面看著和教程里差不多但模型入口、設(shè)置項、技能市場都對不上很多 Skill 根本沒有。我一度以為是自己的使用方法問題浪費了大半天才反應過來是版本裝錯了。教訓是先查版本號再開工。我的下載流程現(xiàn)在是這樣的只從官方渠道下載不順手用別人網(wǎng)盤里轉(zhuǎn)發(fā)的版本安裝完第一步到“關(guān)于”頁確認版本號和更新渠道上網(wǎng)搜該版本的官方說明確認 Skill 市場和 Rules 功能開關(guān)齊全老機器比如 Win7先看兼容說明別裝到一半才發(fā)現(xiàn)裝不上。市面上流傳的“國際版”和“普通版”差異并不小教程作者用的是哪個版本你最好就跟哪個版本不然很多命令和設(shè)置項都對不上。3.2 坑 5緩存目錄默認躺在系統(tǒng)盤項目一多又慢又占地方WorkBuddy 會在本地產(chǎn)生不少緩存項目索引、模型上下文、技能模板、歷史會話數(shù)據(jù)。默認路徑一般落在系統(tǒng)盤的用戶目錄下。做兩三個項目之后我發(fā)現(xiàn)啟動和切換項目明顯變慢系統(tǒng)盤空間也一路飄紅。解決辦法就是顯式改緩存目錄把緩存挪到空間充裕的盤。以我用的版本為例設(shè)置入口里能找到緩存路徑也可以嘗試命令行方式workbuddy config set cacheDir D:/workbuddy/cache不同版本命令行寫法可能不一樣拿不準就先在設(shè)置面板里找改完以后重啟并重新索引第一次會比較慢后面就正常了。提示緩存目錄改完之后舊緩存最好手動清一次但別在 WorkBuddy 正在運行時刪容易損壞索引。退出后清理再啟動最穩(wěn)。3.3 坑 6模型連接和上下文參數(shù)沒有校準輸出忽好忽壞進入 WorkBuddy 之后一般會看到一個模型連接配置界面里面有模型選擇、上下文長度、生成溫度這類參數(shù)。很多人直接默認值就開干結(jié)果輸出質(zhì)量像抽獎。我建議先花一頓午飯的時間做校準用同一個固定小任務(wù)去測不同參數(shù)的效果比如“給這個列表頁寫一個空數(shù)據(jù)占位組件”。關(guān)注兩件事上下文長度設(shè)得太短長文件改不動設(shè)得太長對話一多就超窗口報錯。我一般選“夠用就好”需要改大文件時臨時調(diào)高。溫度這個參數(shù)直接決定生成結(jié)果的“隨機性”。寫代碼我通常壓到比較低讓輸出更穩(wěn)定做文案或者命名建議時可以稍微調(diào)高。我最終固定下來的初始配置是這樣的只是參考不是最優(yōu)答案配置項我的初始值說明模型項目默認模型以你的賬號可用模型為準上下文長度中檔基礎(chǔ)開發(fā)夠用溫度偏低代碼穩(wěn)定優(yōu)先自動生成開啟配合 Rules 使用這些參數(shù)調(diào)完之后我沒再頻繁動過后面所有項目都先以這套為基線再按需調(diào)整。4. 階段三規(guī)則、技能和對話策略坑 794.1 坑 7沒有預設(shè) RulesAI 越寫越“野”如果只給 WorkBuddy 一個功能任務(wù)不給行為邊界它就會用自己的“習慣”寫代碼而這個習慣未必是你想要的。比如它可能會在頁面組件里直接寫網(wǎng)絡(luò)請求可能會一開始就引入一個你沒打算用的第三方庫可能函數(shù)命名風格前后不一致。等代碼量上來這些問題就會變成不可維護。WorkBuddy 的 Rules 機制就是干這個的——給所有后續(xù)任務(wù)定邊界一旦配置后續(xù)任務(wù)全部生效。我把自己項目的全局規(guī)則固化成了下面這份你可以直接改# Global Rules 1. 所有新增函數(shù)必須寫明用途、輸入?yún)?shù)和返回值說明。 2. 禁止引入依賴清單中未聲明的第三方庫。 3. 網(wǎng)絡(luò)請求統(tǒng)一走 api 層禁止在頁面組件中出現(xiàn)裸請求。 4. 所有用戶輸入必須做合法性校驗失敗時給出中文提示。 5. 涉及敏感權(quán)限相冊、定位、麥克風時必須先說明申請用途。 6. 全局變量必須經(jīng)過狀態(tài)管理禁止跨組件直接修改。寫好 Rules 之后我發(fā)現(xiàn)一個明顯的改變同樣的任務(wù)生成代碼的“野性”小了很多函數(shù)注釋、錯誤處理、命名風格都規(guī)矩了。這一步效果比換更強的模型還明顯。4.2 坑 8Skill 同時掛多個規(guī)則互相打架WorkBuddy 的 Skill 可以理解為“預制的流水線模板”比如頁面生成 Skill、數(shù)據(jù)庫建模 Skill、代碼評審 Skill。我一開始圖效率把幾個 Skill 同時掛在一個 Workspace 上結(jié)果生成的頁面里混進了數(shù)據(jù)處理層的模板代碼兩邊規(guī)則互相打架改起來非常難受。后來我總結(jié)出兩條一個任務(wù)只掛一個最相關(guān)的 Skill做完再換不確定某個 Skill 干了什么的時候先全部關(guān)閉用一個標準小任務(wù)測一遍再逐個打開對比輸出差異。這樣排查效率高很多也不會出現(xiàn)“兩個規(guī)則在打架”的玄學問題。4.3 坑 9對話上下文沒有策略聊久了就“失憶”這個坑其實比前兩個更隱蔽。WorkBuddy 的對話上下文是有限的一個會話里來回改十幾輪之后它會“忘記”最開始的要求。最典型的表現(xiàn)是你讓它改列表頁它把登錄頁的條件判斷也順手改了你讓它保留 A 邏輯它回你一個已經(jīng)刪掉 B 邏輯的新版本。我的解決方案是三句話一個任務(wù)一個會話任務(wù)完成立刻開新會話關(guān)鍵約束每次開頭貼一遍不要默認 AI 記得上一輪的內(nèi)容長任務(wù)拆成多個子任務(wù)分別開會話最后再合起來聯(lián)調(diào)。我每次開會話之前會復制一段固定的開場模板見下把當前任務(wù)和紅線約束寫清楚實測下來“失憶”概率降低非常多請基于當前項目配置工作。 當前任務(wù)實現(xiàn)【任務(wù)標題】。 注意 1. 只修改與任務(wù)相關(guān)的文件 2. 遵守項目全局 Rules 3. 完成后先自查再給出變更說明 4. 不要新增依賴。階段三的經(jīng)驗是規(guī)則定邊界技能管流程會話控記憶。三條都做到AI 的輸出就從“隨機發(fā)揮”變成“穩(wěn)定執(zhí)行”。5. 階段四核心功能開發(fā)節(jié)奏比速度重要坑 10125.1 坑 10一次讓 AI 生成整頁代碼改起來懷疑人生到了真正寫功能的時候最大的誘惑是“一次全部生成”。我試驗過一次讓 WorkBuddy 直接生成整個首頁它確實一分鐘給完頁面能跑數(shù)據(jù)也能加載但代碼亂到我不敢動——布局、狀態(tài)、接口、樣式全在一個文件里糾纏。改一個字體大小都要影響別的地方。后來我把“頁面開發(fā)”拆成四步每一步都跑通驗證再繼續(xù)生成靜態(tài)布局骨架先不看邏輯確認結(jié)構(gòu)對填充靜態(tài)元素和樣式確認視覺對接狀態(tài)和交互邏輯確認操作對接接口數(shù)據(jù)確認數(shù)據(jù)流對。每一步都單獨開會話用一句話說清這一步的目標。不要跨步驟讓 AI“順便改一下”它的多任務(wù)處理能力沒有想象中好。5.2 坑 11跳過代碼評審小問題攢成大事故AI 生成代碼的另一個問題是局部正確、整體埋雷。比如兩個組件用了兩個不同的日期格式化方式同一個接口被封裝了三層退出頁面時定時器沒有清理。這些問題單看一次生成的代碼不容易發(fā)現(xiàn)但攢多了就會在某次改動時一起爆。我的做法是每完成一個功能就開一個獨立的“代碼評審”會話用固定的評審 prompt 讓 AI 先自己過一遍請對這個功能相關(guān)代碼做一次嚴格評審 1. 找出潛在 bug尤其是狀態(tài)更新和異步處理 2. 檢查是否違反項目全局 Rules 3. 檢查是否有安全隱患輸入未校驗、明文傳輸?shù)?4. 檢查是否有重復代碼和不一致命名 5. 輸出按“嚴重問題 / 一般問題 / 建議”分類。AI 評完之后我再人工掃三個關(guān)鍵位置網(wǎng)絡(luò)請求有沒有錯誤處理、用戶輸入有沒有校驗、本地數(shù)據(jù)讀寫有沒有異常分支。這一輪做完一個功能才算真正能入庫。5.3 坑 12錯誤處理與邊界條件缺失用戶一操作就崩AI 生成的代碼一般“主路徑”很完整——正常輸入、正常點擊、正常返回它都能走通但一遇到異常輸入、弱網(wǎng)、重復點擊、超長文本這些邊界條件就開始露怯了。我的記賬表單就出過這種問題金額輸入“abc”直接崩連錯誤提示都沒有提交按鈕沒做防重復用戶連點三下賬單多出三條。解決的辦法不是讓 AI 更聰明而是在任務(wù)描述里明確要它補邊界。我自己總結(jié)了一份“邊界檢查清單”每次功能開發(fā)完成之后專門開一個會話讓 WorkBuddy 按清單自查空數(shù)據(jù)列表為空、搜索無結(jié)果時有沒有占位提示超時接口請求超時后有沒有提示和重試超長/非法輸入輸入框有沒有限制和校驗重復操作提交按鈕有沒有防重復權(quán)限拒絕用戶拒絕授權(quán)后流程能不能正常繼續(xù)頁面卸載定時器、訂閱、監(jiān)聽有沒有及時清理。把這份清單作為 Rules 的一部分固化下來之后同類問題大幅減少。階段四的經(jīng)驗很簡單小塊提交、先評審后入庫、邊界單獨查。速度看起來慢了實際上返工少了總時間是省的。6. 階段五聯(lián)調(diào)、構(gòu)建與出包前夜坑 13146.1 坑 13只在模擬器跑通真機上一測試全是問題模擬器是我們開發(fā)時的好朋友但也是發(fā)布前的“障眼法”。我在模擬器上跑得很順的頁面第一次裝到真機上就露餡了權(quán)限彈窗流程完全不一樣存儲路徑對不上列表滾動掉幀圖片加載卡頓。真機和模擬器的差異主要有三類權(quán)限與系統(tǒng)交互真機的權(quán)限彈窗、相冊、定位邏輯更復雜模擬器常常直接放行性能表現(xiàn)真機渲染和內(nèi)存限制更真實模擬器跑得動不代表真機跑得動網(wǎng)絡(luò)與存儲真機網(wǎng)絡(luò)切換、后臺恢復等場景模擬器很難模擬。所以我的建議是從第一個可用版本開始就做真機安裝測試不要等到最后才想起來“真機試一下”。我給自己定的節(jié)奏是每周一次真機回歸寧可頻率低不能沒有。真機測試清單至少包括冷啟動和熱啟動不閃退登錄態(tài)持久化殺進程后仍保留弱網(wǎng)環(huán)境下請求失敗有提示權(quán)限拒絕后功能可用前后臺切換不丟頁面狀態(tài)。6.2 坑 14Gradle 構(gòu)建依賴解析失敗被報錯卡了快一天出包階段最容易讓人懷疑人生的就是構(gòu)建問題。我遇到過一個非常典型的報錯片段Could not determine the dependencies of task :app:compileDebugJavaWithJavac. Could not resolve all task dependencies for configuration :app:debugCompileClasspath.這類報錯表面上是“依賴解析失敗”實際原因往往五花八門。按下面的順序排查效率最高先定位是哪個依賴出了問題不要盯著報錯最后一行猜。執(zhí)行./gradlew :app:dependencies --configuration debugCompileClasspath看輸出里哪個依賴標紅或標 FAILED。檢查版本寫法。如果是latest.或這類動態(tài)版本先改成固定版本號動態(tài)版本最容易在不同時間構(gòu)建出不同結(jié)果。清理緩存再試./gradlew clean如果還不行可以刪除本地 Gradle 緩存目錄下對應模塊的緩存注意備份別全刪。檢查倉庫地址確認倉庫配置的順序?qū)Σ粚?、地址能否正常訪問必要時換一個備用倉庫地址。我們項目里曾經(jīng)就是因為某個倉庫地址擋在前面后面的依賴全部解析不出來。善用版本對比如果昨天還能構(gòu)建今天突然失敗用版本管理工具對比依賴配置文件看這兩天改了什么多數(shù)時候能直接找到元兇。另外一條經(jīng)驗不要選擇在發(fā)版前夜第一次跑完整構(gòu)建。構(gòu)建問題應該在你還留有三四天余量的時候集中踩完否則小問題也會變成發(fā)布日期的大事故。6.3 出包前夜清單這些邊角料真的不能省這個環(huán)節(jié)不單獨算坑了但它和坑 14 一樣容易讓人通宵包名、簽名、圖標、啟動圖、版本號。包名一旦發(fā)布就改不了簽名文件丟了就只能換身份重新上架圖標和啟動圖必須準備全尺寸。我的發(fā)布前自查清單供參考包名確定并全局統(tǒng)一不包含拼寫錯誤簽名文件生成并加密備份記錄 keystore 口令圖標和啟動圖按各商店要求準備全尺寸版本名和版本號遞增隱私政策鏈接可以在后臺配置時訪問構(gòu)建產(chǎn)物在至少兩臺真機上安裝驗證。這些“邊角料”在 WorkBuddy 生成代碼的過程中幾乎不會出現(xiàn)但上架的時候缺一個都會被卡。提前準備好出包當天就能從容很多。7. 階段六上架審核與上線后的第一天坑 15167.1 坑 15被安全審核或格式要求攔下各平臺標準還不一樣提交審核是“能上線”的最后一關(guān)也是最容易讓人心態(tài)崩掉的一關(guān)。我第一次提審被拒理由寫的是“權(quán)限用途說明不足”。我檢查了一下發(fā)現(xiàn) App 會在首次啟動時申請存儲權(quán)限但沒在授權(quán)彈窗之前向用戶解釋為什么要這個權(quán)限也沒有在后臺配置里寫清楚用途。這本該是階段一“上線約束”里就有的內(nèi)容我當時沒寫于是回來補。各個應用商店的審核側(cè)重點不完全一樣有的特別重視隱私合規(guī)必須補充用戶隱私政策、權(quán)限申請理由有的重視內(nèi)容分級要求填寫分級問卷有的會要求提供測試賬號方便審核員體驗完整功能。被拒之后不要慌先按駁回理由逐條對應到具體頁面和處理代碼改完再提交不要“換個姿勢碰運氣”反復提交。我給自己整理的審核自查清單是這樣的隱私政策鏈接在 App 內(nèi)可訪問且與 App 實際行為一致每個敏感權(quán)限都有對應的申請時機和用途說明登錄功能有可用的測試賬號提供給審核員無網(wǎng)絡(luò)、空數(shù)據(jù)等狀態(tài)的文案不含歧義截圖和宣傳語與實際功能一致不夸大版本說明寫清楚本次改動內(nèi)容。7.2 坑 16上線后沒有反饋閉環(huán)下一輪迭代只能靠猜上架成功那一刻我非常興奮第二天就開始規(guī)劃新功能。幾天后看到用戶評論說“登錄有時候會失效”但我完全不知道發(fā)生了什么——因為我沒有接入崩潰統(tǒng)計也沒有用戶反饋入口只能靠用戶發(fā)截圖和日志來猜。上線后的第一天應該做兩件事一是把崩潰統(tǒng)計和用戶反饋入口打開二是給關(guān)鍵操作加上埋點。這樣用戶說“提交失敗”你至少能查到是接口超時還是參數(shù)錯誤。后續(xù)每次迭代我會在發(fā)版說明里把“本次修復的問題”連同崩潰日志一起列出來用 WorkBuddy 去分析日志里的異常堆棧定位到具體代碼位置比肉眼翻日志快多了。迭代節(jié)奏上我的建議是上線第一周每天看一次崩潰率和新用戶反饋之后降到每周一次每兩周出一個小的修復版本穩(wěn)住基本盤再開始加功能。這樣做的好處是無論用戶怎么用你總能在 72 小時內(nèi)知道自己的 App 有沒有出問題而不是在評論區(qū)里被反復教育。8. 十六個坑速查總表與一份可復用清單8.1 十六個坑速查總表下面是全文十六個坑的速查表按階段排列可以打印出來貼在工位上。階段坑典型癥狀一句話解法一1. 需求沒拆碎生成代碼一鍋粥改一處崩一處拆成一句話任務(wù)帶驗收標準一2. 技術(shù)棧選錯AI 生成質(zhì)量差、報錯多選 AI 訓練數(shù)據(jù)最多的主流方案一3. 上線約束缺失審核被拒、隱私/權(quán)限問題多把隱私、權(quán)限、網(wǎng)絡(luò)約束寫進需求二4. 版本裝錯設(shè)置項對不上、Skill 缺失官方渠道下載先核對版本號二5. 緩存目錄在系統(tǒng)盤啟動慢、系統(tǒng)盤空間告急顯式改緩存目錄重啟后重建索引二6. 模型參數(shù)沒校準生成質(zhì)量忽高忽低固定任務(wù)測溫度/上下文記錄基線三7. 規(guī)則沒預設(shè)代碼風格亂、越寫越野寫 Global Rules固化行為邊界三8. Skill 同時掛多個輸出混入無關(guān)代碼一個任務(wù)只掛一個 Skill三9. 會話上下文失控AI 失憶、改錯位置一任務(wù)一會話關(guān)鍵約束每次貼一遍四10. 一次生成整頁代碼糾纏改不動布局、樣式、交互、接口四步拆開寫四11. 跳過代碼評審小問題攢成大事故每功能一次獨立評審會話四12. 邊界條件缺失非法輸入、弱網(wǎng)、重復點擊崩潰用邊界清單讓 AI 自查一遍五13. 只用模擬器驗證真機權(quán)限/性能/存儲出問題每周一次真機回歸測試五14. 構(gòu)建依賴解析失敗構(gòu)建報錯看不懂定位依賴、固定版本、清緩存、查倉庫六15. 審核標準不統(tǒng)一各商店駁回理由不同按駁回理由逐條改不自作聰明六16. 上線后無反饋閉環(huán)用戶反饋無法定位第一天接崩潰統(tǒng)計和埋點8.2 項目交付自查清單把上面的坑倒過來就是一份可以直接抄走的交付清單需求每個功能都有驗收標準上線約束隱私、權(quán)限、網(wǎng)絡(luò)、錯誤處理全部寫清環(huán)境官方版本號確認緩存目錄已調(diào)整模型參數(shù)已有基線規(guī)則Global Rules 已配置Skill 按任務(wù)切換會話策略已統(tǒng)一開發(fā)每個功能小步提交完成后有 AI 評審和人工掃關(guān)鍵點邊界條件單獨查構(gòu)建真機回歸通過依賴版本固定簽名和圖標齊全版本號遞增上架隱私政策可訪問測試賬號可用各商店要求逐條對照反饋閉環(huán)已打開。8.3 一點個人體會如果你完整走完這一遍可能會和我有同樣的感受WorkBuddy 不是幫你省掉了思考而是把思考變成了可以被機器執(zhí)行的要求。你給它的規(guī)則、拆解、約束越清楚它交付的質(zhì)量就越穩(wěn)定你指望它自己理解“能上線”三個字它大概率只會給你一個能跑的 demo。這十六個坑我每一個都真金白銀花過時間。工具會越來越強但這套“拆需求、定規(guī)則、分階段、做驗收”的流程不會過時。希望這份經(jīng)驗能幫你把第一個能上線的 App 跑得更順一點。