2026年8月15日 LLM 能建議 Metamorphic Relations，但它保證不了正確性 大型語言模型是發掘 test oracles 時還算稱職的腦力激盪夥伴，但它會幻覺化性質、遺漏領域限制。以下是如何安全使用它們，而不會上線錯誤的測試。 metamorphic-testingllmtest-oraclesai-engineering
2026年7月19日 你的 Claude 對話已經是文件了。只是它會在 12 小時後消失。 LLM 對話包含意圖、被拒絕的替代方案以及可執行的程式碼。這正是文件應該包含的內容。以下是將 ephemeral chat 轉換為持久、可搜尋的文件，同時不遺失敘事的方法。 literate-programmingllmdocumentationai-engineering
2026年7月13日 大型語言模型可以預先審查你的程式碼，但它無法主持會議 費根審查需要四到六個人、兩小時才能審完250行程式碼。大型語言模型可以透過承擔準備工作與檢查清單的執行來削減這部分成本，但它無法取代人類角色去發現最昂貴的缺陷。 fagan-inspectionsllmcode-reviewai-engineering
2026年6月12日 五種實作卻沒有共識：到底該怎麼選出最好的那一個 N-version programming 聽起來很簡單：跑多個實作，挑最好的答案。但在實務上，「最好」比「最常見」難定義得多。 n-version-programmingimplementation-selectiondifferential-testingai-engineering
2026年6月11日 同一個 LLM 就能寫出五種版本的函式。以下是讓它們真正不同的方法。 用 LLM 進行 N-version programming 不需要多個模型。只要改變 prompt、角色設定和推理限制，就能從單一模型中產出多樣且正確的實作。 n-version-programmingllmdiverse-implementationsai-engineering
2026年5月27日 驗證光譜：為什麼 AI 寫後端最強 AI 寫程式遵循一條驗證梯度。後端在毫秒內完成驗證。網頁端需要幾分鐘。行動端需要幾小時。回饋循環的速度與確定性直接決定了 AI 寫程式在各技術層的實際效果與可靠程度。驗證速度沿著光譜遞減，決定了 AI 編碼在哪裡能自主迭代、在哪裡必須仰賴人類的判斷。 ai-engineeringbackendwebmobilevalidationai-codebase
2026年5月26日 恐懼 vs. 勢如破竹：AI 程式設計的兩種現實 AI 程式設計對能從任何混亂中恢復的精英團隊有效。其他人得到的只有恐懼、失敗的 CI，以及被放棄的實驗。差距不在於模型。 ai-engineeringsoftware-architectureproductionai-codebaseteam-dynamics
2026年5月24日 AI 輔助寫碼在生產環境中：為何大多數團隊半途而廢 大多數團隊嘗試 AI 輔助寫碼，交付的程式碼未能通過 QA，然後放棄。問題不在模型，而在於缺乏讓 AI 輸出值得信賴的防護機制。 ai-engineeringsoftware-architectureproductionautotomyai-codebasebest-practices
2026年5月23日 Fuck-u-code：你的 AI 流水線遺忘的確定性品質閘門 你有型別檢查、語法檢查和架構規則。但你的確定性堆疊對複雜度、重複和命名災難視而不見。這裡有個零成本的解決方案。 ai-engineeringdeterministicguardrailscode-qualitystatic-analysisci
2026年5月22日 為什麼第一版從來都不是問題：AI 程式開發與長期維護 AI 程式開發工具擅長生成第一版。真正的工程挑戰從第四版開始——當團隊需要在不破壞其他一切的情況下修改某些東西。 ai-engineeringsoftware-architecturerefactoringai-codebaselong-term-maintenance
2026年5月22日 AI 生成程式碼與可替換性原則 衡量 AI 生成程式碼品質的真正標準，不在於第一天是否能運作，而在於第三十天你能否替換它，而不需要 rewrite 其他所有東西。 ai-engineeringsoftware-architecturereplaceabilityai-generated-codemaintainability
2026年5月22日 AI Codebase 的確定性防護機制 人工審查不一致。AI 審查更糟。AI 生成 codebase 唯一可擴展的防禦是確定性 enforcement：讓建置失敗的規則，而非被忽略的建議。 ai-engineeringsoftware-architectureguardrailssemgrepci-cdcode-review-automation
2026年5月17日 在 AI 時代，程式碼審查會變成規格審查 當 AI 能從規格產生實作、測試與 contracts，槓桿最高的人類工作就會往上游移動。最需要被仔細審視的東西，其實是規格本身。 ai-engineeringcode-reviewspecificationsliving-specificationsci
2026年5月16日 AI 安全棧: types、contracts、property tests 與 mutation gates 如果你想讓 AI-generated code 能在正式環境站得住，光靠 code review 不夠。你需要一套從 type constraints 到 mutation testing 與 runtime containment 的分層安全棧。 ai-engineeringsafety-stacktypesdesign-by-contractproperty-based-testingmutation-testing
2026年5月16日 Stanford CS146S 對 AI coding 的判斷是對的。缺的科目是架構 這篇對 Stanford CS146S 的評論認為，它準確看見了 AI coding 的轉向，但真正決定長期品質的仍是 AI architecture：系統是否可替換、可約束、可持續演進。 ai-engineeringsoftware-architecturestanfordcs146sguardrailsagentic-development
2026年5月15日 為什麼許多優秀的工程策略直到 AI 出現才真正變得划算 Design by contract、property-based testing、mutation testing、model checking 從來不是壞想法。真正的問題是它們長期需要太多專業判斷才能維持，而 AI 正在改變這筆帳。 ai-engineeringsoftware-reliabilitydesign-by-contractproperty-based-testingmutation-testing
