它是什麼

46 是社區工程作者的英文文章中文翻譯;52 是網名 MaiYangAI 對公開工程師網名 @poteto 九類工作線的整理及自身實踐。合為可追加的工程方法,不以 PR 數當成效。

怎麼用(作者方法,未實測)

  1. 盤點九類真實需求:性能、用戶 bug、使代碼庫更適合 Agent 的重構、Skill 改善、新功能、UI 打磨、harness 改善、開發工具/發布/可觀測性、其他專案。先選一類,寫清輸入、背景、限制、輸出與校驗;沒有需求就不湊量。
  2. 按穩定代碼領域分責。Bot 向 Cursor cloud agent 提供具體提示、倉庫 Skill 與證明要求,追蹤 transcript、跟進或中止;在安全權限內排除環境卡點,超權限交人。需特殊環境時,來源用 private worker 跑模擬器並回收截圖,不代表通用雲環境能做所有事。
  3. 視覺改動交前後截圖,Bot 核對是否真的包含要求,不符退回;讓執行端可啟動開發實例與端到端測試,才有無人時的下一步反饋。
  4. 用共享 Notion 資料庫保存任務與 PR 狀態。46 作者每半小時查 Bugbot/安全發現是否成立、CI 失敗及合併衝突;有問題回 Working 並跟進,正常才 Ready for Review 並啟動代碼審查。這是作者頻率,不是必須照搬的排程。
  5. 把改動對照原始需求與提示詞意圖,不確定交人拍板。兩篇自動合併條件不同:46 為高置信且影響小,52 轉述為低至中風險;保留為不同作者實踐,不把中風險免人工當通則,本卡不授予合併權限。
  6. 獨立營運角色處理入職、日常規則提醒及錯誤根因分析,更新 playbook 並同步其他角色,避免只在單次聊天糾錯。

維護與緊急流程

46 列夜間清死代碼、載入與包體優化、安全、構建耗時、國際化、多端對等,以及近一天合入摘要。P0 會臨時每五分鐘看 transcript 糾偏,作者明確提醒耗 token,只留真正緊急情況。

限制與成本

規模、PR 產量與交付速度均為作者自述/來源轉述的自述,不作基準,本卡不轉錄數字。52 提醒多線並行有注意力碎片化代價。擴大前先補 lint、編譯診斷、測試與可觀測性,檢查需求是否解決、證明是否充分。Bot 週池與外部編碼工具授權用量分開核對,來源未提供通用成本表。

來源與時效

作者方法,尚未實測。各頁標示 Last updated: Oct 14,年份未寫明,不補年份;介面、版本與能力為來源寫作時說法。

倉庫值班的窄修補與採納率(32)

32(網名 Gipp)的值班方案先把 CI 失敗分偶發測試、真回歸、依賴破損與 lint;只讓已限定的偶發測試/格式類進最小修補,附失敗日誌開 draft PR,真實應用邏輯、無法分類與安全關鍵更新交人。不能為消除紅燈改弱測試,也不能把「偶發」標籤當已證明沒有真回歸。

先在低風險單一倉庫試一週,看修補被接受或被關閉重寫的比例;低就縮範圍,不先加倉庫。發版角色僅依命令準備,絕不合併。原文六角色是作者架構,無須先建齊。

原文同時讓 fix-engine 與 Fix Bot 開 PR,存在重複提交責任不清;多子 Agent 同寫 live.json 也未提供鎖定/原子更新。60 秒輪詢、300 子 Agent、百萬上下文、免費工具與相容配置均為作者主張/作者自述,未獨立核驗;不能直接照抄部署。CLI 安裝示例也不足以證明已完成 Grok Bot 客戶端設定。

可檢查的狀態轉移與獨立審查(40、42)

40(網名 Morlex)的維護者契約是先重現及寫失敗測試,再分支委派、跑測試、開草稿 PR;認證、計費、遷移停給人。42 將它展成檔案契約:每 issue 唯一 id、當前負責人、task、status、evidence、implementation、review、handoff;派工前查既有進行中紀錄,只有互不影響的工作才並行,雲端編碼環境不可假定讀得到 Bot 電腦的檔案或登入。

42 的主線為 NEW → TRIAGED → REPRODUCED → BUILDING → TESTED → REVIEWING → REVIEW_PASSED → DRAFT_PR_READY;失敗回實作或 BLOCKED,末端交人工。每次前進須有實物證據;Reviewer 讀原 issue、重現、真 diff、測試日誌及邊界案例,確認回歸測試修前失敗/修後通過,給 PASS/FAIL/BLOCKED;FAIL 附位置、理由、證據與修正要求,Reviewer 不代改實作。Release 只有真草稿 PR、必要檢查通過、獨立審查完成且無阻擋項才整理人審交接。狀態檔是作者自定工作流,提示詞本身不會強制執行,需倉庫檢查、分支保護等支撐。

42 首輪夜班僅取指定 agent-ready 標籤、排除進行中項目並限制新任務量;其每晚最多兩件是作者範例。逾時先查前一步是否已完成;缺依賴按紀錄恢復後最多重試一次;同錯兩次停。文中「最多兩輪修補」與「審查失敗再一輪」要事先定清總上限,不合成無限循環。晨報逐件列負責人、狀態、成品、實跑結果、審查、下一步及待批,未完成分列。

來源重疊與能力限制(31、40、42)

31 與既收 46 的工程方法高度重疊,只補語音測試閉環:作者將語音 API 接到編碼環境系統音訊輸入/輸出,結合音訊及逐字稿測跨產品 speech-to-speech;是其環境實作,沒有通用接線細節,不補腳本。並行規模與速度只屬作者自述,不轉錄為容量。

40 稱每 Bot 各有電腦,與 42 及既有共享模型衝突,採同帳號共享電腦界定。40 的全用 Opus 與 42 的平台自動路由不可指定也有差異;不把後端、基準、併購、方案或 API 價目當本次已核實現況。42 對按 token 固定計費的說法又與 36 按模型成本描述不同,計費歸屬待核,見 grokbot-quota-saving-checklist-20261113。

可信度 B;作者方法,尚未實測;沿用正式狀態。所有來源頁均標 Last updated: Oct 14,年份未寫明。本文只整理保存全文,未核驗產品現況。

更新紀錄