🔧 阿川の電商水電行
這是關於人工智慧究竟如何改變軟體開發系列文章的一部分。先前的文章包括： 《把關恐慌》 、 《計量表一直在執行》 、 《誰對誰說了什麼》 。
2月9日，我發表了一篇文章，介紹了我為解決開發者社群知識崩潰問題而建構的系統。 Foundation 是一個公開建置、公開迭代的副專案，包括其中的錯誤。
系統出故障了。我當時還不知道。
我已經把剪貼簿抓取功能上傳到 GitHub，編寫了工作流程文件，並寫了一篇文章。 Ctrl+A 全選，Ctrl+C 複製。擴充程式會攔截這些操作。簡潔、直覺、符合邏輯。
它只捕獲了用戶訊息，錯過了所有AI回复，錯過了所有物體，錯過了可見視口以上的所有內容。
這個缺陷在深度審查時是看不見的。它看起來好像沒問題，是因為我審查的速度和建造的速度一樣。
自信之船
首先是 HTML 導入功能。將 Claude 對話保存為 HTML 格式，執行命令列命令，搞定——不到兩秒鐘即可搜尋。它成功了。我編寫了文件，將其發佈到 GitHub，並撰寫了文章。
然後我嘗試讓它更簡單。開發了一個瀏覽器擴充功能－無需手動儲存，也無需命令列介面。只需像往常一樣使用對話功能，它就會自動捕獲螢幕截圖。
我的方法：監聽複製事件。
document.addEventListener('copy', async (e) => {
const copiedText = window.getSelection().toString();
// Parse timestamps to detect Claude vs user...
});Ctrl+A 全選。 Ctrl+C 複製。擴展程式攔截。邏輯清晰。簡潔明了。已發布。
它只捕獲用戶訊息。
所有AI響應都消失了。所有元素都消失了。任何超出可見視口的內容——都消失了。 Claude.ai是一個帶有虛擬滾動的React單頁應用程式。資料儲存在JavaScript狀態中，而不是DOM。 Ctrl+A無法選取未渲染的內容。
我發貨的時候對這些一無所知。我審核的速度和製作的速度一樣快。
這感覺不像是一條捷徑，而是一個合理的解決方案。
公眾清算
在發表「我建立了解決方案」這篇文章五天后，我寫了這篇文章：
“我創辦這個基金會時雄心勃勃，但我低估了它的規模。”
不在私人文件裡，也不在 GitHub issue 裡，而是在 DEV.to 的基金會組織下公開發布的。指出了越權行為，並縮減了規模。
九天後——2月18日——取得了突破。真正的API捕獲。真正的聯邦。段落級搜尋。這並非簡單的補丁，而是一次根本性的重新思考：不再淺嚐輒止，而是使用Claude.ai自己使用的API。
2 月 9 日「正常運作」的系統和 2 月 18 日實際正常運作的系統幾乎沒有任何捕獲邏輯相同。
同樣失效，不同表面
在我發布剪貼簿方法兩週後，有人評論了我的《把關恐慌》一文。
奧拉米德·奧蘭雷瓦朱： “這是用人工智慧寫的。”
沒有參與討論，沒有具體批評，只是表面功夫——然後得出結論。
上週，Bilgin Ibryam 分享了 Unmesh Joshi 關於學習循環和 X 平台終身學習碩士 (LLM) 的文章。 Unmesh 是 Thoughtworks 的傑出工程師，也是《分散式系統模式》一書的作者。以下是 Hannes Lehmann 的回應：
“我猜這篇文章也是人工智慧寫的？你看，每隔一句話就有一個破折號。”
標點符號作為證據。表面檢查。結論。
我使用剪貼簿方法時也遇到了同樣的失敗模式——審閱速度與作品生成速度相同，而審閱深度卻達不到作品所需的水平。
我執行了我的擴充程序，並觀察它是否捕獲了某些資料，以此來檢查它是否正常工作。它確實捕獲了一些資料，看起來沒問題。但我漏掉了一些資料。
Olamide 透過掃描人工智慧訊號來審查我的文章。他找到了一個，但完全沒理解其中的論點。
Hannes 透過數短橫線來審查一位 Thoughtworks 工程師關於學習和 LLM 的文章。他數了一些短橫線，但錯過了文章的實質內容。
生產環節成本降低了，但評測環節卻沒跟上，於是評測環節的成本也降低了。
瓶頸不在於人工智慧
恐慌情緒又找錯方向了。
不是“人工智慧產生了太多程式碼”，而是“我們以代際速度進行審查，並稱之為盡職調查”。
不是“人工智慧檢測器將拯救我們”，而是“表面檢查正在取代真正的理解”。
不是“剪貼簿方法看起來很聰明”，而是“聰明並不等於正確，我沒有辦法區分兩者”。
瓶頸從來不在於程式碼產生。程式碼產生速度一直快於程式碼審查——這就是程式碼審查、測試和結對程式設計存在的意義。我們所有的工程實踐都是為了解決同一個問題：快速輸出，緩慢理解。
人工智慧並沒有造成差距，它只是擴大了差距，而且擴大幅度非常大。
在這種壓力下，自然而然的反應就是降低審核成本。與其閱讀論點，不如掃描人工智慧訊號。與其問它可能遺漏什麼，不如執行程式碼，看看它捕捉到了什麼。在完全理解系統之前就發布文章。
基金會在反思之後迅速調整策略，直接提出了應對之策：驗證案例研究。 「我拒絕的人工智慧程式碼及其原因。」「人工智慧斷然否定的次數。」並非減緩產生速度——而是記錄在案的拒絕。
這就是文化轉變。不是檢測人工智慧，也不是禁止人工智慧，而是培養一種習慣，即對你交付的產品擁有足夠的掌控力，並真正做到對產品負責。
我的剪貼簿方法看似可靠，是因為我沒有刻意去問自己：這遺漏了什麼？在合併、發布和交付之前，加上這個問題，就能決定產生速度和審核深度。
這並不複雜，只是比我們預想的要慢。
有人專門圍繞這一點建立了一套流程。 Kiro 稱之為「屬性感知程式碼演化」——在代理程式編寫任何一行程式碼之前，你需要定義 bug 的狀況、「修復」的真正意義，以及哪些原本運作正常的部分必須保持運作。在執行開始之前，邊界就已經明確。這把「手術刀」已經存在，但大多數團隊尚未使用它。
這不是認罪，而是一種模式。
我自信地發布了有問題的程式碼，也為此寫了一篇文章。五天後我才回過神來，又過了九天才修復了它。所有證據都公開了——三篇文章，GitHub 上的程式碼，以及事發當時的即時記錄。
這種透明度才是關鍵。並非因為我為犯錯感到自豪，而是因為錯誤本身是有用的。它比那種粉飾太平、略過中間九天過程的「我做了個東西，而且成功了」的故事更有用。
Olamide 檢查了 AI 訊號，但錯過了論點。 Hannes 數了破折號，卻錯過了實質內容。我執行了擴展程序，但錯過了它沒捕捉到的所有內容。不同的表面，同樣的縫隙。
人工智慧讓內容生成變得廉價。我們的回應是讓審核也變得廉價。這才是真正的危機所在——不是內容生成了什麼，而是我們對內容的審查有多膚淺。
解決之道並非降低人工智慧的速度，而是加深責任感。在發布之前，先問問自己它遺漏了什麼。在檢查標點符號之前，先仔細閱讀論證。記錄你拒絕的內容，而不僅僅是你合併的內容。
生產週期會越來越短，成本會越來越低。但評測費用不會自己跟上。
我們必須選擇慢下來。
原文出處：https://dev.to/dannwaneri/i-shipped-broken-code-and-wrote-an-article-about-it-98p
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
