AI 程式設計實務

ai-coding-practice 領域的內容地圖 — 41 個概念。人類與團隊如何實踐 AI 輔助軟體工作：工作流程技巧、SDLC 遙測、作為瓶頸的審查與驗證，以及分工。精選入口；所有領域請見 Home。

• Acceleration Whiplash — Faros 2026：AI 將大量產出灌進以人類步調運作、無法消化這些產出的 SDLC — 吞吐量上升（任務 +34%、史詩 +66%），品質下降（錯誤 +54%、每 PR 事故 +243%、審查時間 5 倍），差距隨採用率擴大，甚至波及成熟度高的組織；Faros 自身 2026 年 9 月的後續報告指出，每項變更的風險減速（每 PR 事故 +14.5%），整體壓力卻加速上升（每月事故 +125.4%、QA 時間 +300.6%、PR 規模 +71.8%）——震盪從變更本身轉移到整個系統
• Agent-Generated Test Quality — 兩項 AIDev 研究探討代理程式程式碼是否經過測試。Jhanglani 等人（204K 個測試檔案）：這是取捨而非缺陷 — 代理程式涵蓋的邊界案例種類是人類的兩倍，斷言強度也相當，但可能不穩定的測試比例較高；三項方法缺陷拉低了數字。Dipongkor 等人（4,882 個 PR，ICSME 2026）則以差異內容衡量測試：50.4% 的程式碼變更 PR 沒有伴隨測試變更；既有測試在 Java 中執行了代理程式變更行的 61.5%，在 Python 中執行了 27.0%（64.8% 的 Python PR 完全為零）；代理程式撰寫的測試只在 35.9%／22.5% 的 Code+Tests PR 中提高覆蓋率，錯誤處理結構最高有 86.0% 未被涵蓋。廣度是內在特性，目標涵蓋則取決於關聯，而只有後者是安全網 — 兩項研究都沒有以人類為基準
• Agent Review Comment Resolution — Cynthia 等人（Saskatchewan／SMU／Monash，arXiv 2607.21997）：341 個 Python GitHub 儲存庫中，來自 Copilot、Cursor 與 Codex 的 54,713 則代理程式審查意見 — 首次大規模檢視方向相反的審查迴圈：代理程式負責審查，人類做決定。約 71% 已解決（Copilot 72.9%、Cursor 67.2%、Codex 54.8%），核心開發者負責大部分解決工作（Copilot 意見的 78.1%）；行內建議是最強的預測因子（OR 1.62），較長的意見結果較差 — 但 AUC 只有 0.58，因此決定採納與否的大部分因素並未出現在意見裡。對 470 則尚未解決但有人回應的討論進行分類：最常見的失敗是代理程式看不到的專案脈絡（23.8%），其次是有把握的誤報（63 則）；470 則中有 4 則屬於幻覺；24.3% 的建議已採取行動，卻從未標記為已解決。這與 Goldman 等人（ASE 2025）的研究相矛盾 — 4,000 則 RovoDev 意見、1,007 個 Atlassian 儲存庫、39.3% — 兩者是測量構念的落差，而非母體差異（2026-09-22 已調和）
• Agent-Vendor Heterogeneity — Kraishan（Texas Tech，arXiv 2609.17598）：跨 2,807 個儲存庫、37,623 個標記來源的 PR，並以相同儲存庫的人類作為基準 — 所有測量結果中，程式設計代理程式供應商之間的差異都大於代理程式與人類之間的差異。Codex 的還原率為 6.1%（相較人類 11.5%，OR 0.50），Devin 為 14.5%（OR 1.31），另外三者在統計上與人類無異；安全氣味出現率從 Cursor 的 1.6% 到 Claude Code 的 9.5%，人類為 4.6%；硬編碼憑證率相差四倍；首次人類審查延遲從約 1 小時到 12.6 小時不等。把代理程式合併為單一類別，正好會抹去維護者正在比較的差異 — 但供應商與 PR 大小及任務自我選擇互相混淆，論文無法將它們區分開來
• Agentic Coding Work-Composition Shift — Anthropic 的 40 萬場次遙測，2025 年 10 月至 2026 年 4 月：隨模型進步，修復損壞程式碼的場次比例從 33% 降至 19%（除錯工作幾乎減半），操作軟體（14%→21%）與撰寫加資料分析（約 10%→約 20%）增加；估計任務價值上升約 25–27% — 使用方式從救火轉向端到端代理式工作
• Agentic Work Systematization — OpenAI Codex 研究的「系統化」面向：從臨時使用代理程式（描述任務 → 代理程式執行 → 完成）轉向透過技能與外掛打造可重用的工作流程基礎設施；使用技能的使用者占每週活躍使用者比例從 5.4% 升至 26.6%（2026 年 3 月至 6 月），在 OpenAI 幾乎普及（96.2%）；自訂技能集中在具有共用慣例的地方 — 但測得的採用後生命週期只是一次性複製（53% 的重用技能從未修改，新增與維護之比為 2.7:1），因此只有遵循多數採用者都略過的維護紀律，系統化才能累積效益 — 而在確實維護的少數案例中（Shen 與 Hruschka，五個公開供應商儲存庫），紀律體現為人類主導、AI 輔助的迴圈，目前尚無已測得的移轉效益
• AI as Primary Author — Faros 2026：在沒有刻意決策的情況下，助理跨越成為作者的門檻，AI 程式碼接受率從 20% 升至 60%（Faros 2026 年 9 月後續報告為 65%）；「不是助理，而是作者」；人類從創作轉向監督，使這成為作者工作，而非審查工作 — 監督層的自動化持續領先作者工作，代理式審查涵蓋 50–80% 的 PR，領先業者的代理程式卻只開啟 13–14% 的 PR
• Building Is Cheap, Arguing Is Expensive — 「技術辯論中，程式碼勝出」：生成三個 PR，而非白板討論；用原型取代設計文件；減少設計文件
• Closed-Loop AI Review — Selvanayagam 與 Ghaleb（ÉTS Montréal／Trent，arXiv 2608.21311，ESEM 2026 初步成果）：在公開 GitHub 上，AI 審查 AI 的母體規模普查 — 2,830,284 個可歸因簽章的代理程式撰寫 PR，其中 248,641 個（8.8%）至少有一則可歸因於 AI 的審查；其中 45,269 個為跨產品審查（1.6%），208,145 個為同產品審查，且在 2025 年間成長超過兩個數量級。組成極不平均：Copilot PR 有 95.7% 經過自我審查，Cursor 與 Google Jules 則為 0.0%。審查者的輸出會隨配對對象改變 — CodeRabbit 的重構意見占比依作者從 9.7% 到 35.0% 不等；四個雙重角色機器人中有三個在審查自家產品程式碼時多發出 58–65% 的意見，方向與不同數量測量下的同模型審查盲點相反。歸因以產品為單位，而非模型；沒有缺陷真值，所有計數都是下限
• Code as Source of Truth — 高速程式設計讓文件過時；將規格／技能納入儲存庫；透過 Claude 進行入職；驗證規格漂移
• The Code-Quality Payoff Is Token-Indexed — DHH 認為，過去 25 年美觀、一致架構的經濟理據，建立在人類負責修改之上 — 由代理程式修改後，他能說出的唯一存續理由是 token 稀缺，這使程式碼工藝成了隨時間而變的經濟賭注，而非永恆的工程美德
• The Committed-Artifact Chain — Anthropic 的 Applied AI SDLC 作業手冊要求每個階段都以提交可由機器讀取的產物作結，供下一階段讀取 — intent.md → spec.md → plan.md → diff+tests → PR findings → incident record — 讓交接變成合併事件，提交紀錄也兼作稽核軌跡；這是語料中最完整的 markdown 作為介面案例，但完全屬於規範性主張：每個「如何衡量」都是待蒐集的指標，而非研究結果
• Compute Allocator — 人類角色的演變：決定哪些事情值得投入運算資源；生成的 token 只有約 1% 會出貨，99% 是投入對齊／溝通的基礎工作；豐裕思維
• Configurable Human Participation — HAS-Bench（Wu 等人）：將人類參與視為可配置的基準測試變項（五級能動性量表 × 三種互動管道 × 多種角色，共 397 個任務）— 平等合作（A3）比全自動化高出 +8.4 Pass@1，並補回 65% 的自主運作失敗任務，但效益取決於配置，超過 A3 後逐漸遞減；使用 LLM 模擬人類的限制須納入考量。
• Design by Selection — Nate Parrott 使用 Claude Design 的實務：生成候選方案幾乎不花成本時，設計師的工作便轉移到兩端 — 先離開鍵盤決定意圖，再手動編輯最後一哩路 — 中間階段則變成「要求十個選項，再混搭兩個可行的方案」。若缺少引導，模型會收斂到容易辨認的典型風格，因此明確的美學方向是關鍵輸入，而保真度本身也成為控制旋鈕（若視覺元素會造成干擾，就先做線框圖）
• Design Concept Grilling (hub) — Matt Pocock 的 grill-me skill；在任何計畫之前先觸及 Brooks 所說的「設計概念」；與「從規格到程式碼」相反；PRD 是目的地文件，Kanban 是旅程文件
• Disposable Micro-Apps — 為每項任務建立、用來編輯計畫的一次性自訂 UI（「疊在微型軟體之上的微型軟體」）；複製回 markdown；符合豐裕思維下的理性選擇
• Efficiency Debt of AI-Generated Code — Tran 等人（Google，arXiv 2608.06640）：在單一正式環境 C++ monorepo 中，12 個月內有 352 萬次變更，並設有人類撰寫的對照組 — AI 生成的 C++ 明確迴圈約多一倍，標準函式庫呼叫少 30–40%；這種原始碼層級的命令式偏好，在正式環境中表現為約 5% 的相對運算開銷，以及約 8% 的相對記憶體開銷。可靠性結果呈現分歧：建置失敗率與 sanitizer 發現數約為人類的 1.3 倍，但還原率約比人類低 0.9 倍。審查摩擦確實存在（阻塞討論串為 1.92 倍），但審查深度無法預測哪些低效率會存續 — 這是論文自身的零結果，也支持應在審查之前攔截此類債務的主張。根據分類回饋，目標發現數減少 11.1%，但重新生成的函式相較人類原始版本仍有淨退步
• HTML as the New Markdown — Thariq Shihipar 的論點：模型進步後，千行 markdown 計畫會讓人類難以招架；HTML 產物具備視覺與互動性，讓人類留在迴圈中。面向模型的 harness 縮小，面向人類的 harness 則擴大
• Human-Governed Skill Maintenance — Shen 與 Hruschka（Megagon Labs，arXiv 2609.05677）：首次縱向測量公開 SKILL.md 檔案由誰維護、維護內容為何 — 五個特意挑選的 AI 工具儲存庫中有 254 次實質編輯，每一次都由具名人類帳號撰寫或合併；62% 帶有 AI 共同作者尾註，各儲存庫呈現明顯雙峰分布（93%／92%／16%／5%／0%）；60% 是增進、38% 是修正，254 次編輯中只有 1 次棄用；技能以 5 天的中位間隔呈現穩定至增加的趨勢。預先註冊且具統計檢定力的移轉任務測試發現，維護後版本並不優於最早版本（1–5 分制下為 −0.09，CI [−0.28, +0.10]）
• Impose Values, Not Disciplines — Robert C. Martin 區分實務所欲達成的結果，與產生這些結果的人類工效儀式：終身提倡 TDD 的他拒絕要求代理程式採用 TDD，因為紅綠重構是為配合人類工作記憶而調整的流程，並非良好程式碼的本質 — 代理程式追求相同價值（覆蓋率、複雜度受限、分支經過測試），但門檻有所調整（人類的 CRAP 低於 4，代理程式低於 6，也許是 8），讓它們自行達標；不論提示怎麼說，它們都會回到先寫函式、再寫測試的做法
• Layered Supervision — Stolze 與 Strässle（ESEM 2026 SEIP，5 場訪談與一份 50 人的指標性調查）：當生成速度超越審查，監督不再是單一控制點，而是分散到三個層次 — 預防性護欄（將架構意圖外化至 steering 檔案與規格，但沒有任何機制檢查）、可執行護欄（將 lint／test／CI 從品質工具提升為以建置結果裁定），以及重新界定範圍的人類監督：從逐行閱讀轉向同步監督與「操作可解釋性」。各層依機制而非順序區分：預防層只有在生成器參照內容時才會事前塑形；可執行層則不論如何都會事後驗證。單一層次都不足以應付，而論文並未測量任何一層
• Living Design System — 從儲存庫擷取 design_system.html，作為可攜、可供人類和機器讀取的事實來源；元件遊樂場；連結工程與非技術利害關係人
• LLM-Assisted Grey-Literature Theory Building — Agarwal 等人的次要貢獻（arXiv 2607.07980）：一套可擴展範本，從數千份實務工作者文件而非數十場訪談建構紮根理論 — LLM 負責機械式、以引文為錨點的開放編碼（蒐集 38,709 份文件 → Gemini 相關性評審，κ=0.75 → 由多代理程式 Thematic-LM 使用三種刻意極化的編碼者視角，完成 3,100 份編碼 → 4,838 個代碼／109,951 段引文，成本約每份文件 $0.35），人類則保留詮釋性的主軸／選擇編碼；自動化後半段的嘗試失敗（由下而上的處理產生 15,029 個淺薄、重複的因果陳述），因此代碼→理論步驟仍由人工處理，把 LLM 當作搜尋引擎 — 這是關於 LLM 在質性研究中能做與不能做之事的分工教訓
• Open Source Under Agent Contributions — 貢獻供給免費且不受限制時，維護者的稀缺資源不再是貢獻者，而是注意力：DHH 表示，他在三個月內於 Omarchy 合併 1,000 多個 PR，待處理清單每週翻倍，代理程式負責初步分類；由於程式補丁不是人類撰寫，拒絕也變得不費社交成本 — 這與同一波湧入造成維護者倦怠的說法相互對照
• Outsource Your Thinking, Not Your Understanding — 「你可以外包思考，但不能外包理解」；理解是人類不可委派的瓶頸；知識庫作為理解工具
• Planning / Execution Division of Labor — Anthropic 的 40 萬場次遙測：典型 Claude Code 場次中，人類做出約 70% 的規劃決策（要做什麼），Claude 則做出約 80% 的執行決策（如何完成）；每個提示會引發約 10 項行動（使用者保留執行控制權時為 8 項，Claude 控制規劃時為 16 項）—「人決定要打造什麼，代理程式決定如何打造」
• Post-Acceptance Edit Behavior — Liang 等人（CMU，arXiv 2607.25130）：DECODE，1,141 位開發者在 IDE 中對已接受的 AI 自動補全文字進行 53,600 次編輯 — 首次測量人類接受 AI 程式碼後實際做了什麼，範圍在提交前，而非 PR 層級。一半編輯在 50 分鐘內完成，15 分鐘後數量急遽下降；保留率呈雙峰分布（中位數有 63% 留存，但大量案例落在 0% 與 100%）；31% 的軌跡包含刪除編輯，而最初嘗試自訂自動補全內容的開發者，下一步最可能刪除它（23.4%，功能變更後為 12.2%）。20 個模型中究竟是哪個寫出程式碼，影響極小（eta-squared 0.002–0.007）。預測部分的表現不如摘要所言：微調後的 3B 模型比自身基礎模型高 +0.23 F1，但只比最佳前沿基準高 +0.08；主流編輯類型 — 改變功能 — 在所有嘗試模型上的 Levenshtein 相似度最高約為 0.49
• Review as the Control Point — Agarwal 等人（CMU，arXiv 2607.07980）：根據 3,100 份經編碼的實務工作者文件，綜合出包含 26 個構念／67 種關係的因果理論 — 審查是決定程式設計代理程式如何影響軟體的控制點，而 AI 不會決定影響是正是負；團隊透過審查者專業、處置方式，以及如何調整審查流程來決定（三項調節因子）。核心是審查深度與審查者技能，並由理解債務回饋迴圈串連；論文自身不屬於供應商的 GitHub 遙測資料（超過 250 萬個 PR）顯示，代理程式 PR 的審查較少、合併速度快數倍、討論較少，但在站得住腳的分析選擇下，趨勢方向會反轉，而未經審查的比例隨時間向人類基準收斂
• Reviving Impractical Quality Tools — Robert C. Martin 說明代理程式為何會改變程式碼品質：CRAP 分數與突變測試在 2000 年前後都是好點子，但他因為人類必須負責處理產出而放棄 — 工具沒有變，勞動方式變了；代理程式不在乎工作有多無聊，讓一夜執行加上數週修復工作縮短為 30 分鐘迴圈。一般化來說，凡是成本來自修復而非偵測的品質技術，如今都值得重新評估
• Risk-Tiered Auto-Approval — PostHog 的 StampHog：合併閘門依序通過四項檢查（PR 狀態、爆炸半徑拒絕清單、差異上限、最後階段 LLM 否決），並採用失效時關閉的不變條件，自動核准約三分之一的已合併 PR，取代例行橡皮圖章式 Slack 流程；這是風險分級閘門的實際部署案例，只報告數量，未報告缺陷率。再加上第三種分級依據，以及首份相關母體分布：安全營運依回應的可逆性分級（自陳數據：13% 唯讀／44% 僅建議／30% 自動執行低風險事項／13% 中風險／0% 完全自主）。第四種依據適用於非程式碼企業工作流程 — 依輸出結果的影響分級（自動化／抽樣／審查／建議，各自採用不同審查頻率）— 並補上檢查點為何只會不斷累積的結構性拖累，以及可移除檢查點的三題稽核。
• Same-Model Review Blindness — Greptile 的 Rodrigo Caridad 分析兩組各 500 個 PR 的標記資料集（約 1,500 個已驗證的高嚴重性錯誤）：每個前沿模型抓到自家模型家族撰寫程式碼中錯誤的比例，都低於其他家族的程式碼 — Opus 4.7 同模型 53.7%、跨模型 60.0%；GPT 5.5 同模型 50.5%、跨模型 62.0%。交叉效應純屬交互作用（兩位審查者的平均表現都約 56%，兩個資料集只差 2.6 個百分點），但文章提出的機制 — 模型會漏掉自身最常產生的錯誤類型 — 以錯誤組成重新加權類別表後，只能重現主要結果約 7%，因此盲點存在於類別內部，而非由組成造成。真值由供應商建立，標記程序未說明，其中一組的提示詞又針對結果指標調校，且未公開產物 — 歸為案例研究，而非實證研究
• Security Debt of Agent-Generated Code — Sakib、Banik 與 Jadliwala（UTSA，arXiv 2607.12428）：以 LLM-as-judge 加人工編碼分析 4,022 個 AIDev 代理式 PR 中的 16,112 項高風險檔案變更 — 38.9% 的代理程式 PR 至少帶有一項安全氣味；供應鏈完整性問題（可變更的動作／映像標籤、未固定版本的安裝）占其中 82.3%；GitHub Actions 加 Dockerfiles 占 87.6%；硬編碼憑證占嚴重安全氣味的 99.6%；被標記比例隨 PR 規模從 16.2% 升至 53.6%。RQ2 的兩個意外結果顛覆常見說法：提交 74 個真正外洩憑證的主要是人類，而非代理程式（67.6%）；其中 81.1% 已進入整合階段，沒有任何機器人或人類審查者留言。研究沒有加入人類 PR 對照組，因此測量的是代理程式輔助工作流程的安全狀況，而非代理程式與人類之間的差異
• Spec-Driven Development as the New Waterfall — Robert C. Martin 將 2026 年規格驅動開發潮流解讀為換上新品牌的 1970 年代先大量設計再動工誘惑，並表示自己嘗試時同樣失敗：計畫無法預見代理程式會遇到什麼，因此人類只好叫停、重寫、重新開始 — 他的答案是敏捷做法（先做一兩個故事，再檢視架構），其理據是變更成本已接近零；規格應保持短暫，不提交，因為完成後的產物就是規格
• Telemetry vs. Survey Measurement — 感知落後於現實：以調查為基礎的研究（DORA）會漏掉系統遙測捕捉到的損害 — 還有家族效應（工具的一致性取決於是否共用資料來源，而非構念）、隨機化是唯一的因果工具、調查方法的反例（遙測看不到影子 AI），以及 Ramp 付款管道的觀察窗口；首次跨家族趨同：Anthropic 於 2026 年中超越 OpenAI；供應商調查原則重申兩次 — 若結論由產品提供、方法又受到限制，即使由第三方執行並明列樣本數 n，也不會改變證據等級。
• The Three Loops of AI-Native Building — Andrew Ng 為從零到一產品提出巢狀迴圈分類：代理式程式設計迴圈（幾分鐘，由代理程式閉合）、開發者回饋迴圈（數十分鐘至數小時，由人類閉合），以及外部回饋迴圈（數小時至數週，由市場閉合）；迴圈工程一直只最佳化最內層，而人類剩餘的工作是在外兩層移轉脈絡
• Unknowns as the Agentic Bottleneck — Thariq Shihipar 的地圖與疆域論：你告訴代理程式的內容與工作實際需求之間的落差就是「未知事項」；到了 Fable 級模型，人類能否找出這些未知事項，而非模型能力，決定輸出品質；將 Rumsfeld 2×2 套用於提示，並依階段順序整理各種引導方法
• The Verifiability Thesis (hub) — 電腦能自動化可規格化之事，LLM 能自動化可驗證之事；RL 驗證獎勵 → 鋸齒狀高峰；「可驗證 + 實驗室關注」；所有事情終將可驗證
• Verification as the New Bottleneck (hub) — Fiona Fung：程式設計不再是瓶頸 — 驗證、審查、維護才是；左移；TDD 不再有額外成本；PR 週期時間漏斗分析
• Vertical Slice Tracer Bullets — 將 Pragmatic-Programmer 的 tracer-bullet 模式應用於代理程式任務分解；垂直切片優於水平分層；帶阻塞邊的 Kanban 優於編號階段計畫
• Vibe Coding vs. Agentic Engineering — Vibe Coding 拉高下限（任何人都能打造）；代理式工程在加速的同時維持品質標準；「超過 10 倍且差距持續擴大」；大型專案看聘用與否，不看謎題

衍生內容#

• Opinions on Using AI Tools & the Future of the Software Engineering Role — 關於使用 AI 工具的四種立場辯論地圖（內部看好者／實務派從業者／治理懷疑論者／架構論點）+ 對軟體工程師未來角色的綜合：從程式設計轉向決策／驗證、角色趨同、哪些工作仍由人類負責、哪些護城河能存續，以及坦誠的限制
• The HTML Artifact Lifecycle: Where Plan History Lives, and When Disposable Becomes Durable — 針對面向人類的 HTML 產物生命週期提出兩個問題的綜合分析。(1) 一旦將產物視為編譯後的檢視畫面而非紀錄，差異／版本問題便迎刃而解：為內容層（markdown／設定／儲存庫）進行版本控管 — 複製回去的往返流程與從程式碼擷取的模式已如此運作 — 按需重新生成呈現內容，讓審查重新聚焦於決策，而非差異（依變更可能性排序計畫的技巧會把可審查差異放在最上方）。真正損失的是呈現內容本身的 blame 歷史，但由於呈現可在充裕成本下重新生成，因此可接受；一旦某項呈現選擇成為關鍵，就應升格為持久工具。(2) 釐清正確的重用單位後，範本問題便迎刃而解：重用的不是產物，而是生成器 — 反覆使用的微型應用可變成技能，每次都生成新的、符合需求的應用（保留一次性應用對每項任務的貼合度，同時取得重用帶來的一致性），這正是實際測得的系統化做法（使用技能的每週活躍使用者比例為 5.4%→26.6%）。只有在重複使用 + 同步壓力 + 受眾同時存在時（即 design_system.html 的情況），產物本身才會從一次性升格為持久；此時它不再免費，而是要承擔維護成本、同步週期，以及納入產物雜亂膨脹上限的責任。失敗模式是未做選擇的中間狀態 — 臨時應用被留下卻無人維護，既造成雜亂與腐敗，又無貼合度或一致性
• Human-in-the-Loop Boundaries — 人類應負責資源分配、理解、設計概念、風險與問責邊界；若人類充當手動執行者、通用審查者或儀式性核准者，就會拖慢系統
• Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping? — 監督相關群集的五題綜合分析。(1) 60% 的「接受」混合三種證據力不同的行為 — 明確採用、審查後未還原，以及僅僅未還原 — 只有第三種屬於橡皮圖章；造成 Faros 與 CMU 標題趨勢相反的，是構念而非資料。(2) 資源分配者淪為橡皮圖章的風險有三層證據（腦力耗竭造成錯誤率 +11／+39%、遙測顯示 31.3% 未審查、P2–P4 實務工作者論述）：數量加上表面合理性使人類不再投入，因此只有結構性對策（測驗閘門、依樣本檢視深度、風險分級閘門）能讓「理解」而非簽名成為合併條件。(3) 「審查要自動化到什麼程度」是區分任務，而非調整刻度：全面自動化機械驗證，對抽樣／高風險切片維持人類審查深度 — 因為真正的限制不是抓出缺陷（有爭議的 P9），而是責任歸屬、技能成長與理解債務；不論由誰抓到錯誤，這些都會累積。(4) Faros 與 DORA 部分是分類錯誤 — 調查測量感受到的生產力，遙測測量系統結果，兩者在各自層次都成立 — 但對成熟度防護效果的分歧確實存在，尚未解決。(5) Ng 與 Faros 可同時成立：從零到一與正式環境的範疇差異確實存在，也解釋了大部分結果；而有文件記載的樂觀偏差意味著不能把 Ng 自陳的 QA 減負當作測量結果
• Learning to Co-Work with AI: A Software Engineer's Field Guide — AI 時代軟體工程師實地指南：6 個技能群集（品味、harness、對齊優先的規劃、適合代理程式的架構、驗證、策略定位）、每日實務、反模式、90 天計畫
• Is Persistence the Line Between Prompting and Spec-Driven Development? — 不是 — 持續存在只是重要特性的可觀察代理指標，而那個特性是權威性：後續工作是否依據該產物來評判。語料在兩個方向都打破持續存在測試（CLAUDE.md、WORKFLOW.md、REVIEW.md、工作單與 Martin 自己的相依性規則檔案都持續存在，卻沒人稱之為規格；grilling 逐字稿、Carey 的 why 對話，以及 Martin 刪除的計畫都是短暫的，卻完整完成規格工作），兩種引用立場也都被誤讀 — Pocock 的句子有兩個子句，持續存在並且回到，只有第二個成立；Martin 確實在儲存庫保留一份規格檔，範圍限於檢查器強制執行的限制。權威性正確分類語料中的每個案例；持續存在則讓權威性更容易維持。此群集幾乎全屬實務者觀點，沒有任何研究測量持續存在本身
• The Under-Review Divergence: Faros's Widening Crisis vs. CMU's Convergence — 解答 acceleration-whiplash 的未解問題：Faros 與 CMU 在「審查中」的差異大多是測量產物 — 供應商測量企業全部 PR 中未審查 PR 數量隨採用深度變化的差值，非供應商則測量開源專案中未審查代理程式 PR 隨日曆時間變化的占比；兩者都符合同一種解釋：未審查產出總量隨數量增加，而代理程式 PR 未經審查即合併的比例，則隨團隊學會風險分流而下降；數量集中這項描述有證據支持（每個專案未審查比例中位數約 0%，合併後超過 50%；依 PR 類型進行分流），殘餘分歧則關乎預測 — 當代理式創作從 <1% 跨越到兩位數時，分流紀律能否維持
• When Does Verification Quality Determine Whether AI Automation Works? — 從 Lean／形式化證明搜尋到軟體 CI 與漏洞重現的驗證品質階梯，另加最低一階：根本沒有可執行驗證器時，以結構化輸出與儲存庫內的同儕比較替代；自主程度不應高於驗證器所能支援的程度
• Verifying Without a Compiler: Cowork's Harness vs Claude Code's, and Why the Slice Verifier Stays — 對沒有機械檢查器的驗證提出兩個問題的綜合分析。(1) Cowork 與 Claude Code 共用基本元件（技能、MCP、子代理程式、電腦操作），但位於驗證階梯的兩端，因此 harness 權重重新分配：Claude Code 仰賴確定性的事後驗證器堆疊（測試、編譯器、差異檢查、規格漂移檢查），既能抓錯，也能在合併前限制損害；Cowork 的輸出沒有這樣的階層，因此 harness 以融入判斷的設計取代機械檢查 — 載入的設計系統最接近樣式檢查器，evals 和 LLM 評審用於品質檢查，人類審查則集中在決策檢查點 — 而行動前分類器閘門成為關鍵，因為錯誤會直接進入線上 SaaS 狀態，中間沒有失敗的測試擋下。相應的失敗模式分成明顯型（建置失敗）與隱性型（看來正常的精美簡報 — 即「看起來成功的失敗」類別），因此 Cowork 更需要問責重新設計。(2) 規劃器之所以需要水平切片驗證器，是設計上的必需，而非只在 4.7 版本中經驗觀察所得：「每個切片都產生端到端回饋」是可機械檢查的不變條件（是否觸及 schema+service+UI？），可檢查的不變條件應放入確定性檢查器，不論信任模型與否 — 驗證器是一項限制（不會累積效益、保留成本為零、能抓出訓練先驗使分層趨向水平的回退），而「請垂直切片」是一項行為要求，是同一紀律的短暫形式。信任模型適用於提示行；驗證器才是持久的一類
• Writer/Reviewer vs Agent-to-Agent Review — 兩種模式是同一架構，只是場域不同，因此語料證據應歸屬四個拆解後的面向，而非任一品牌。審查者譜系是唯一有程式碼審查數據的面向（Greptile，案例研究：高嚴重性召回率跨模型 61.0%，同模型 52.1%，交叉差距為 8.9 個百分點，控制主要效應後仍成立，且無法以錯誤組成解釋）— 這推翻了原本對 Writer/Reviewer 模式的論證，因為程式碼歸屬偏差是模型家族的特性，清除脈絡也無法消除。資訊邊界面向有較好的設計論據（Bun 僅看差異的審查者、OpenCodeReview 僅做證偽的反思器、Cursor 掃描過但未報告的透鏡掃描），其唯一數據來自相鄰任務（Anthropic 監控召回率在長篇無害脈絡下從 92% 降到 48%）。閘門位置只有一個阻擋率（Ouroboros 63.5%），沒有結果測量。結果面向則分裂為兩種不可比較的構念：AACR-Bench 的參照匹配精確率為 7.23–37.80%，真實代理程式審查意見中由開發者解決的比例為 71.4%（共 54,713 則）。Codex 已推出的 /review 位於高精確率／極低召回率端（200 個 PR 有 266 則意見，召回率 4.92%），Claude Code 固定版本的 /code-review 則相反（5,980 則意見、召回率 28.90%、精確率 7.23%）— 差異在意見數量政策，而非模式本身。沒有研究直接比較這兩種模式

資料來源#