Claude 為我編寫了一個有 400 次提交的 RSS 閱讀器應用程式

在過去的幾週裡，我一直在試用最新版本的 Claude Code，它幫我寫了一個稍後閱讀服務，包含 RSS、電子報訂閱以及一個 Android 應用程式。

軟體工程經驗很有幫助，因為我確實規劃了許多高階設計和數據模型，有時也會要求更簡單的設計。但總體而言，我大部分時間感覺自己像是一個產品經理，試圖盡快明確功能需求。雖然軟體工程不僅僅是寫程式，但我開始認為 Claude 在這部分已經超越了人類。

在網頁版應用程式中朗讀來自 RSS 訂閱源的文章。Android 應用程式可以在背景執行此操作，並支援我車上的媒體控制。這與今年早些時候（編碼代理很有趣但不太實用）以及幾個月前（如果你不時刻引導，編碼代理就很難用）相比是一個重大變化。Claude Opus 4.5（以及據稱其他一些新模型）通常預設就能寫出合理的程式碼。

雖然有些功能有非常詳細的設計，但我的一些提示詞（prompts）其實非常簡略。

在第一天之後，我基本上只是合併 PR 而不去看它們，並假設它們能正常運作。從那以後，我不得不撤回或修復少數問題，但即使是那些問題，大多數也只需一個錯誤報告提示詞就能修復。

精選功能

Android 應用程式

Claude 做過最令人印象深刻的事情是根據這個提示詞寫出了整個 Android 應用程式：

1. 建立設計文件
2. 一次性實作整個 MVP 應用程式

在那之後，Android 應用程式中幾乎所有的功能都是透過這個提示詞實作的：「你能在 Android 應用程式中實作 X 嗎，就像它在網頁版中的運作方式一樣？」

朗讀功能

我要求它實作的最複雜功能是文章朗讀，使用 Readability.js（可選地）清理 RSS 訂閱內容，然後（可選地）通過 LLM 處理使文本更易讀，接著使用兩個管道之一將文本轉換為語音，最後將語音朗讀連結回正確的原始段落。

老實說，我不確定自己是否也能一次性完成這個任務。這曾是應用程式中錯誤最多的部分，但主要是因為高階設計過於脆弱。Claude 親自建議了一些改進，一旦我們採用了不那麼脆弱的設計，它從那時起就一直穩定運作。

精選問題

非我所創症候群 (Not Invented Here Syndrome)

Claude 寫了一些正規表達式（regexes）而不是使用顯而易見的工具（JSDom、HTML 解析器），這造成了一些問題。擁有軟體工程經驗有助於發現這些問題，且在要求時 Claude 很容易就能修復它們。

依賴項中的錯誤

Claude 的 NIH 症候群實際上部分是有道理的，因為我們遇到的最惱人的錯誤是在別人的程式碼中。對於資料庫遷移中的一個錯誤，我最終建議採用 NIH 方案，讓 Claude 寫了一個基礎的資料庫遷移工具。

我們遇到的另一個主要（仍未解決）問題是 Android 模擬器在 CI（持續整合）中無法正常關閉。遺憾的是，我認為這對 Claude 來說可能太難直接取代，但它也不像遷移那樣是流程中的關鍵部分。

其他觀察

• Claude 喜歡保持向後相容性，如果不需要，則需要提醒它不必費心。
• Claude 確實會幻覺 API 文件，這導致我將 fly.io 的文件放入倉庫中供參考。我想像如果你使用大量不常見的 API，這會變得更加惱人，但 Claude 非常了解 React。
• 有時它會提出過於複雜的設計，然後當我要求檢查是否有任何過於複雜的地方時，它會修復它們。
• 它在提出高階系統設計方面其實做得很好，儘管它傾向於提出較為脆弱的設計（競態條件、需要非常小心維護狀態的情況）。

剩餘問題

Claude 在極簡提示下仍未解決的問題包括：

1. CI 中的 Android 模擬器問題（上游問題）。
2. 電子報設置需要在 Cloudflare 控制面板中進行一系列手動步驟，所以我還沒有真正嘗試。
3. 朗讀生成似乎是在主線程上進行的，導致 UI 滯後。Claude 第一次嘗試實作 Web Worker 沒有成功，我還沒抽空去找出問題出在哪裡。

但僅此而已，這裡最大的問題是我基本上沒有投入任何精力。我預計如果我真的花一個小時在這些問題上，每一個都是可以解決的。

這對我來說是一次大開眼界的經歷，因為 AI 編碼代理在短短一個月內就從「有點幫助」變成了「極具生產力」。如果你最近還沒嘗試過它們，你真的應該試試。並請記住，這將是它們有史以來最差的時候。