我的 LLM 輔助編程實踐

關於使用大語言模型輔助編寫代碼 [1] 的網絡討論中，總會有開發者表達失望之情。他們常常質疑自己做錯了什麼—爲何有人報告取得如此顯著成效，而他們的嘗試卻效果平平？

使用大語言模型編寫代碼困難且反直覺。要摸清這種使用方式的邊界與侷限需要大量努力，而能幫助人們找到最佳應用方法的指導又少之又少。

若有人告訴你用大語言模型編程很_簡單_，他們（可能無意中）誤導了你。他們或許偶然發現了有效模式，但這些模式並非人人自然掌握。

兩年多來，我一直從大語言模型獲得出色的代碼編寫成果。這是我嘗試向你傳授一些經驗和直覺。

設定合理預期 #[2]

別被 “通用人工智能 “的炒作迷惑——LLM 本質上仍是高級自動補全工具。它們只是預測一系列標記的順序——但編寫代碼很大程度上就是將標記按正確順序串聯起來，所以只要引導得當，它們在這方面確實能發揮極大作用。

如果你幻想這項技術能完美實現你的項目，而你不需要發揮任何個人技能，那你很快就會失望。

相反，應將其視爲能力增強工具。我目前最喜歡的心智模型是：把它們當作一個過度自信的結對編程助手，這個助手能閃電般快速查找資料，隨時生成相關示例，並且能不抱怨地執行繁瑣任務。

過度自信這點很關鍵。它們絕對會犯錯——有時是微妙的，有時是巨大的。這些錯誤可能是非常不像人類的 [16]——如果一個人類合作者虛構了不存在的庫或方法，你會立即對他失去信任。不要陷入擬人化 LLM 的陷阱，假設那些會讓人類喪失信譽的失誤對機器也應該同樣適用。

在使用 LLM 時，你常會發現它們有做不到的事情。記下這些情況——這些都是有價值的教訓！它們也是值得保存的未來參考案例——當新模型能夠處理之前模型無法應對的任務併產生可用結果時，這正是強大新模型的標誌。

考慮訓練截止日期 #[3]

任何模型的一個關鍵特性是其訓練截止日期。這是指他們訓練數據收集停止的日期。對於 OpenAI 的模型，這通常是 2023 年 10 月。Anthropic、Gemini 和其他提供商可能有更近期的日期。

這對代碼來說_極其_重要，因爲它影響模型熟悉哪些庫。如果你使用的庫在 2023 年 10 月之後有重大破壞性更新，OpenAI 模型將不會知道這些變化！

我從 LLM 中獲得的價值足夠多，以至於我現在在選擇庫時會特意考慮這一點——我儘量選擇穩定性好且足夠流行的庫，這樣大量使用示例就會存在於訓練數據中。我喜歡應用無聊技術 [17] 的原則——在項目獨特賣點上創新，其他一切都使用經過檢驗的解決方案。

LLM 仍然可以幫助你使用其訓練數據之外的庫，但你需要投入更多工作——你需要在提示中提供這些庫應如何使用的最新示例。

這就引出了使用 LLM 時最需要理解的重點：

語境爲王 #[4]

從 LLM 獲取好結果的技巧主要在於管理其語境——即當前對話中包含的文本。

這種語境不僅僅是你輸入的提示：成功的 LLM 交互通常以對話形式進行，語境由當前對話線程中你的_每條_消息_和_ LLM 的每個回覆共同構成。

當你開始新對話時，語境會重置爲零。這點很重要，因爲當對話變得不再有用時，解決辦法通常是徹底清空重新開始。

某些 LLM 編碼工具超越了簡單的對話功能。例如 Claude Projects 允許你預先在語境中填充相當大量的文本——包括最近推出的直接從 GitHub 導入代碼 [18] 的功能，我現在_經常_使用它。

Cursor 和 VS Code Copilot 等工具會自動包含當前編輯會話和文件佈局的語境，有時你還可以使用如 Cursor 的 @命令 [19] 等機制引入額外的文件或文檔。

我主要使用 ChatGPT[20] 和 Claude[21] 的網頁或應用界面工作的原因之一，是它讓我更容易理解具體有什麼內容被納入語境。那些對語境不透明的 LLM 工具對我來說反而_效率更低_。

你可以利用之前的回覆也是語境一部分這一特點。對於複雜編碼任務，可以先讓 LLM 編寫簡單版本，確認其可行後，再迭代開發更復雜的實現。 我經常通過將現有代碼導入到新對話中來建立上下文，然後與 LLM 一起對其進行修改。

我最喜歡的代碼提示技巧之一是導入幾個與我想要構建的項目相關的完整示例，然後引導 LLM 以它們爲靈感創建新項目。我在描述我的 JavaScript OCR 應用 [22] 時詳細介紹了這一點，該應用結合了 Tesseract.js 和 PDF.js——這兩個庫我之前使用過，並能在提示中提供有效的示例。

詢問選項 #[5]

我的大多數項目都始於一些開放性問題：我嘗試做的事情可行嗎？有哪些潛在的實現方式？哪些選項是_最佳_的？

我將 LLM 作爲這一初始研究階段的一部分。

我會使用類似 “Rust 中 HTTP 庫的選項有哪些？包含使用示例 “或 “JavaScript 中有哪些有用的拖放庫？爲每一個構建一個演示 “（對 Claude）這樣的提示。

訓練截止日期在這裏很重要，因爲這意味着更新的庫不會被推薦。通常這沒問題——我不需要最新的，我需要的是最穩定且存在足夠長時間已經解決了大部分 bug 的庫。

如果我打算使用更新的庫，我會自己進行研究，而不依賴 LLM。

任何項目的最佳開始方式是創建一個能證明該項目關鍵需求可以滿足的原型。我經常發現，LLM 可以在我坐下來打開筆記本電腦的幾分鐘內就幫我完成一個可用的原型——有時甚至在我使用手機工作時也能做到。

明確指示任務內容 #[6]

完成初步研究後，我會徹底改變使用模式。對於生產代碼，我的 LLM 使用更加專制：我把它當作數字實習生，根據我的詳細指令來編寫代碼。

這是最近的一個例子：

編寫一個使用 asyncio httpx 的 Python 函數，函數簽名如下：

async def download_db(url, max_size_bytes=5 * 1025 * 1025): -> pathlib.Path

給定 URL，函數將數據庫下載到臨時目錄並返回路徑。但它在開始流式傳輸數據時檢查內容長度頭，如果超過限制，則引發錯誤。下載完成後，它使用sqlite3.connect(...)，然後運行PRAGMA quick_check來確認 SQLite 數據有效——如不有效則引發錯誤。最後，如果內容長度頭欺騙我們——比如聲稱 2MB 但實際下載了 3MB——我們會在發現問題時立即引發錯誤。

我自己可以編寫這個函數，但查找所有細節並讓代碼正常工作可能需要近 15 分鐘。Claude 在 15 秒內 [23] 就完成了這項任務。

我發現 LLM 對這類函數簽名反應極佳。我可以擔任函數設計者，而 LLM 則負責按照我的規格構建函數體。

我通常會接着要求 “現在用 pytest 爲我編寫測試 “。同樣，我指定我選擇的技術——我希望 LLM 能節省我輸入已經在腦海中的代碼的時間。 如果你的反應是 “肯定手動編寫代碼比輸入英文指令更快 “，我只能告訴你對我來說已經不是這樣了。代碼必須準確無誤。而英文有巨大的靈活空間，可以使用簡寫、含糊表達、允許拼寫錯誤，甚至可以說 “用那個流行的 HTTP 庫 “，即使你一時想不起名字。

優秀的編程大語言模型擅長填補這些空白。它們比我勤奮多了——會記得捕獲可能的異常，添加準確的文檔字符串，並用相關類型註釋代碼。

必須測試它寫的代碼! #[7]

我上週詳細討論過這個問題 [24]：唯一不能交給機器的事情就是測試代碼是否真正有效。

作爲軟件開發者，你的責任是交付可工作的系統。如果你沒有親眼見它運行，它就不是一個可工作的系統。你需要投入精力加強手動測試習慣。

這可能不夠光鮮，但一直是交付優質代碼的關鍵部分，無論是否使用 LLM。

記住這是交流過程 #[8]

如果我不滿意 LLM 生成的內容，它_永遠不會_抱怨被要求重構！“把那些重複代碼提取成函數”、“用字符串處理方法而不是正則表達式”，甚至直接說 “寫得更好點！“——LLM 第一次產出的代碼很少是最終實現，但它可以爲你重寫幾十次，不會感到沮喪或厭煩。

有時我第一次提示就能得到很棒的結果——隨着我練習越多，這種情況越來越多——但我預計至少需要幾次後續對話。

我常想這可能是很多人忽略的關鍵技巧——初次結果不理想並非失敗，而是推動模型朝着你真正想要的方向發展的起點。

使用能爲你運行代碼的工具 #[9]

越來越多的 LLM 編程工具現在具備爲你_運行代碼_的能力。我對其中一些持謹慎態度，因爲錯誤的命令可能造成實際損害，所以我傾向於使用那些在安全沙盒中運行代碼的工具。目前我最喜歡的有：

如果你願意冒一點風險：

這種循環運行代碼的模式如此強大，以至於我選擇核心 LLM 編程工具主要基於它們是否能安全地運行並迭代我的代碼。

Vibe-coding：絕佳的學習方式 #[10]

Andrej Karpathy 在一個多月前創造了這個詞 [31]，它很快流行起來：

有一種新的編程方式我稱之爲 “vibe coding“（氛圍式編程），你完全沉浸在氛圍中，擁抱指數型增長，甚至忘記代碼的存在。[…] 我會提出一些看似愚蠢的要求，比如 “把側邊欄的內邊距減半 “，因爲我懶得去找。我總是點 “全部接受 “，不再去看差異對比。當我遇到錯誤信息時，我只是複製粘貼它們，通常這就能解決問題。

Andrej 認爲這對 “一次性的週末項目來說還不錯 “。這也是探索這些模型能力的絕佳方式——而且非常有趣。

瞭解 LLM 的最佳方式就是與它們互動。向它們拋出荒謬的想法，用 vibe-coding 的方式讓它們勉強工作，這確實能加速你對什麼有效、什麼無效建立直覺的過程。

在 Andrej 給它命名之前，我就一直在 vibe-coding 了！我的 simonw/tools[32] GitHub 倉庫包含 77 個 HTML+JavaScript 應用和 6 個 Python 應用，每一個都是通過提示 LLM 構建的。通過構建這個集合，我學到了太多東西，而且我每週還會增加幾個新原型。

你可以在 tools.simonwillison.net[33] 直接嘗試我的大多數工具——這是該倉庫的 GitHub Pages 發佈版本。去年十月，我在 Everything I built with Claude Artifacts this week[34] 中詳細記錄了其中一些項目。 如果您想查看每個工具對應的聊天記錄，這些記錄幾乎都在該頁面的提交歷史中有鏈接—或者訪問新的製作說明頁面 [35]，那裏有包含所有這些鏈接的索引。

使用 Claude Code 的詳細示例 #[11]

在寫這篇文章時，我想到了創建 tools.simonwillison.net/colophon[35] 頁面的想法——我想要一個可以鏈接的頁面，比 GitHub 更直觀地展示我每個工具的提交歷史。

我決定藉此機會來演示我的 AI 輔助編碼過程。

這次我使用了 Claude Code[30]，因爲我希望它能直接在我筆記本上的現有工具倉庫中運行 Python 代碼。

在會話結束時執行/cost命令顯示了以下內容：

> /cost 
  ⎿  Total cost: $0.61
     Total duration (API): 5m 31.2s
     Total duration (wall): 17m 18.7s

初始項目從開始到完成只花了我 17 分鐘多一點，在 Anthropic 的 API 調用上花費了 61 美分。

我使用了指令式流程，明確告訴模型我想要構建什麼。以下是我的提示序列（完整記錄在這裏 [36]）。

我首先要求編寫一個初始腳本來收集新頁面所需的數據：

這個目錄中幾乎所有的 HTML 文件都是使用 Claude 提示創建的，這些提示的詳細信息鏈接在提交消息中。構建一個 Python 腳本，依次檢查每個 HTML 文件的提交歷史，並從這些提交消息中提取任何 URL 到一個列表中。然後輸出一個具有以下結構的 JSON 文件：{“pages”: {“name-of-file.html”: [“url”], {“name-of-file-2.html”: [“url1”, “url2”], …—如你所見，一些文件在其提交歷史中可能有多個 URL。腳本應命名爲 gather_links.py，並保存一個名爲 gathered_links.json 的 JSON 文件 我真的沒有仔細思考這第一個提示—更像是在思考初始問題時隨意輸入的一些想法。

檢查了初始結果後，我發現了一些問題：

看起來它只獲取了 URL 的開頭部分，它應該獲取完整的 URL，這些 URL 可能指向不同的網站—所以只需獲取任何以 https:// 開頭並以空白或提交消息結尾的內容

然後我改變了主意—我想要那些完整的提交消息：

更新腳本—我想同時捕獲完整的提交消息和 URL—新格式應該是 {“pages”: {“aria-live-regions.html”: {“commits”: [{“hash”: hash, “message”: message, “date”: iso 格式的日期], “urls”: [像之前一樣的 URL 列表]

提供這樣的例子是獲得你想要的結果的絕佳捷徑。

請注意，我始終沒有查看 gather_links.py[37] 中的代碼！這是純粹的感覺編程：我看的是它在做什麼，但我把實現細節完全交給了 LLM。

JSON 看起來不錯，所以我說：

這工作得很好。給我寫一個新腳本，名爲 build_colophon.py，用於查看收集的 JSON 文件並構建和保存一個 HTML 頁面。頁面應該適合移動設備，並應列出每個頁面—包含指向該頁面的鏈接—對於每個頁面，整潔地顯示提交消息（將換行符轉換爲 br 並將 URL 鏈接化，但不進行其他格式化）—以及提交消息日期和指向提交本身的鏈接，這些鏈接位於 https://github.com/simonw/tools[32]

Claude 知道 GitHub URL 的工作方式，所以告訴它鏈接到提交併提供倉庫名就足以讓它猜出https://github.com/simonw/tools/commit/fd9daf885c924ba277806b3440457d52b0ad90a8這樣的提交 URL。 我發現 Claude 在網頁設計方面有很好的默認品味——我只是說了句 “頁面應該適配移動設備 “就不管了。

Claude 埋頭工作併爲我構建了一個頁面，但不太對，所以我說：

運行得不對。ocr.html 有很多提交記錄，但在 colophon.html 中只有第一個提交的鏈接和標題，其餘都顯示在同一塊內——應該爲其他每個提交都有單獨的 HTML 塊，包含鏈接和格式化日期。此外，格式整齊的日期應該包含 HH:MM 以及日期

它自己修復了這個 bug，只剩下我決定做的兩處改動：

幾乎完美了，但每個頁面的提交記錄應該按相反順序顯示——最舊的在前

然後：

最後一個改動——頁面目前按字母順序列出，我們改爲最近修改的在頂部

整個項目就這些！這是 build_colophon.py[38]，它生成的頁面看起來相當不錯 [39]：

還有一項剩餘任務：我需要將新的 colophon 部署爲我網站的一部分，但我不想將那個新的 colophon.html 頁面檢入到倉庫本身。我想要一個自定義的 GitHub Pages 構建過程。 我開始了一個全新的 Claude Code 會話（清空狀態）看看 Claude 是否也能解決這個問題：

這個倉庫使用 GitHub Pages 部署。我想稍微修改構建過程——在部署到 GitHub Pages 前，它應該運行 python gather_links.py，這會生成一個名爲 gathered_links.json 的文件——然後它應該運行 python build_colophon.py，這會使用該文件創建 colophon.html——我希望 gathered_links.json 和 colophon.html 都能發佈到 GitHub Pages，但我不希望它們被提交到倉庫本身

與第一次不同，這次我非常仔細地觀察它的操作——我不知道如何以這種方式自定義 GitHub Pages 構建，我既想學習如何做到這一點，又要保持謹慎，以防它可能會產生幻覺的細節並導致任務失敗。

它告訴我它想創建這個文件並徵求我的許可：

name: Deploy to GitHub Pages

on:
  # Run on push to main branch
  push:
    branches: [ main ]
  # Allow manual trigger
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment
concurrency:
  group: pages
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Need full history for git log in gather_links.py

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip

      - name: Generate links and build colophon
        run: |
          python gather_links.py
          python build_colophon.py

      - name: Setup Pages
        uses: actions/configure-pages@v4

      - name: Build with Jekyll
        uses: actions/jekyll-build-pages@v1

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

我猜這是對的？我很欣賞關於 “gather_links.py 中需要完整的 git 歷史記錄 “的評論——這是我很容易忽略的事情。

然後它說它想把這些文件添加到 .gitignore——聽起來是個好主意。

它給出了到目前爲止的操作摘要：

我已經爲 GitHub Pages 創建了一個 GitHub Actions 工作流程：

  1. 創建了一個 .github/workflows/pages.yml 文件，它：
    • 在推送到 main 分支時運行
    • 檢出完整的 git 歷史（gather_links.py 需要）
    • 設置 Python 3.12
    • 按順序運行這兩個腳本生成文件
    • 構建並部署到 GitHub Pages
  2. 創建了 .gitignore 文件，以防止生成的文件被提交

現在當你推送到 main 分支時，GitHub Actions 將：

  • 運行 gather_links.py 腳本創建 gathered_links.json
  • 運行 build_colophon.py 創建 colophon.html
  • 將這兩個文件（以及所有其他文件）部署到 GitHub Pages

我檢查了一下它花費了多少：

/cost ⎿ Total cost: $0.1788 Total duration (API): 44.6s Total duration (wall): 10m 18.6s

我手動更新了我的 README.md，添加了一個指向新的 Colophon 頁面的鏈接，在這個提交 [40] 中，這觸發了另一次構建。

這次只運行了兩個作業，最終結果是正確部署的網站：

（我後來發現了另一個 bug——一些鏈接無意中在它們的 href= 中包含了 <br> 標籤，我通過另一個花費 11 美分的 Claude Code 會話 [41] 修復 [42] 了這個問題。）

爲人工接管做好準備 #[12]

我在這個例子中很幸運，因爲它幫助我說明了我的最後一點：預計需要親自接手。

LLM 無法替代人類的直覺和經驗。我花了足夠多的時間使用 GitHub Actions，所以我知道要尋找什麼樣的問題，而在這種情況下，我直接介入並完成項目比繼續嘗試通過提示來達到目標要更快。

最大優勢：開發速度 #[13]

我的新技術棧頁面 [35] 從構思到完成部署，只用了不到半小時。

我確信如果沒有 LLM 輔助，這項工作會耗費我更多時間——甚至可能多到我根本不會去實現它。

_這_就是爲什麼我如此看重 LLM 帶來的生產力提升：不僅僅是爲了更快完成工作，而是能夠實現那些原本因時間成本而無法開展的項目。

我在 2023 年 3 月寫過：AI 增強開發讓我對項目更有野心 [43]。兩年後，這種效果仍然沒有減弱的跡象。

這也是加速學習新知識的絕佳方式——今天學到的是如何通過 Actions 自定義 GitHub Pages 構建，這肯定是我未來會再次使用的技能。

LLM 讓我更快地執行想法，意味着我能實現更多想法，這又進一步讓我學到更多知識。

LLM 放大已有專業能力 #[14]

其他人能用同樣方式完成這個項目嗎？可能不行！我的提示依賴於 25 年以上的專業編程經驗，包括我之前對 GitHub Actions、GitHub Pages、GitHub 本身以及我所使用的 LLM 工具的探索。

我也知道這肯定能成功。我花了足夠多的時間使用這些工具，所以我很確信利用一個優秀的 LLM 來創建一個新的 HTML 頁面並從我的 Git 歷史中提取信息完全在它的能力範圍內。

我的提示反映了這一點——這裏沒有特別新穎的東西，所以我指定了設計方案，在工作過程中測試結果，並偶爾引導它修復 bug。

如果我試圖構建一個 Linux 內核驅動程序——這是我幾乎一無所知的領域——我的流程將完全不同。

額外收穫：回答關於代碼庫的問題 #[15]

如果讓 LLM 爲你編寫代碼的想法仍然讓你感到非常抗拒，那麼還有另一個用例可能會讓你更感興趣。

優秀的 LLM 在回答有關代碼的問題方面非常出色。

這也是風險很低的：最壞的情況是它們可能會理解錯誤，這可能會讓你花費稍微多一點時間來弄清楚。但與你完全靠自己翻閱數千行代碼相比，它仍然可能爲你節省時間。

這裏的技巧是將代碼導入到一個長上下文模型中並開始提問。我目前最喜歡的是這個起了個好聽名字的gemini-2.0-pro-exp-02-05，這是 Google 的 Gemini 2.0 Pro 的預覽版，目前可以通過他們的 API 免費使用。

我前幾天 [44] 就使用了這個技巧。我在嘗試一個對我來說新的工具叫 monolith[45]，這是一個用 Rust 編寫的 CLI 工具，它可以下載網頁及其所有依賴資源（CSS、圖像等），並將它們打包到單個歸檔文件中。

我很好奇它是如何工作的，所以我將它克隆到我的臨時目錄並運行了這些命令：

cd /tmp
git clone https://github.com/Y2Z/monolith
cd monolith

files-to-prompt . -c | llm -m gemini-2.0-pro-exp-02-05 \
  -s 'architectural overview as markdown'

我在這裏使用我自己的 files-to-prompt[46] 工具（這是 Claude 3 Opus 在去年 [47] 爲我構建的）來收集存儲庫中所有文件的內容到單個流中。然後我將其通過管道傳輸到我的 LLM[48] 工具，並通過 llm-gemini[49] 插件告訴它用 “architectural overview as markdown“作爲系統提示來請求 Gemini 2.0 Pro。 這給我返回了一份詳細文檔 [50]，描述了該工具的工作原理——哪些源文件做什麼，最關鍵的是，它使用了哪些 Rust crate。我瞭解到它使用了reqwest、html5ever、markup5ever_rcdom和cssparser，而且它完全不執行 JavaScript，這是一個重要的侷限性。

我每週會使用這個技巧好幾次。這是開始深入研究新代碼庫的絕佳方式——而且通常替代方案不是在這上面花更多時間，而是完全無法滿足我的好奇心。

引用鏈接

  1. https://simonwillison.net/tags/ai-assisted-programming/
  2. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#set-reasonable-expectations
  3. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#account-for-training-cut-off-dates
  4. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#context-is-king
  5. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#ask-them-for-options
  6. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#tell-them-exactly-what-to-do
  7. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#you-have-to-test-what-it-writes-
  8. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#remember-it-s-a-conversation
  9. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#use-tools-that-can-run-the-code-for-you
  10. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#vibe-coding-is-a-great-way-to-learn
  11. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#a-detailed-example
  12. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#be-ready-for-the-human-to-take-over
  13. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#the-biggest-advantage-is-speed-of-development
  14. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#llms-amplify-existing-expertise
  15. https://simonwillison.net/2025/Mar/11/using-llms-for-code/#bonus-answering-questions-about-codebases
  16. https://simonwillison.net/2025/Mar/2/kellan-elliott-mccrea/
  17. https://boringtechnology.club/
  18. https://support.anthropic.com/en/articles/10167454-using-the-github-integration
  19. https://docs.cursor.com/context/@-symbols/overview
  20. https://chatgpt.com/
  21. https://claude.ai/
  22. https://simonwillison.net/2024/Mar/30/ocr-pdfs-images/
  23. https://gist.github.com/simonw/5aed8bd87016c77465c23e0dc4563ec9
  24. https://simonwillison.net/2025/Mar/2/hallucinations-in-code/#qa
  25. https://www.cursor.com/
  26. https://codeium.com/windsurf
  27. https://aider.chat/
  28. https://en.wikipedia.org/wiki/Eating_your_own_dog_food
  29. https://aider.chat/HISTORY.html
  30. https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview
  31. https://simonwillison.net/2025/Feb/6/andrej-karpathy/
  32. https://github.com/simonw/tools
  33. https://tools.simonwillison.net/
  34. https://simonwillison.net/2024/Oct/21/claude-artifacts/
  35. https://tools.simonwillison.net/colophon
  36. https://gist.github.com/simonw/323e1b00ee4f8453c7834a7560eeafc1
  37. https://github.com/simonw/tools/blob/87e2577983f11fc9c7bf7b7a268cf2404a21e1c5/gather_links.py
  38. https://github.com/simonw/tools/blob/1e04f12a1cacea8856946162457d0d77e60ee549/build_colophon.py
  39. https://static.simonwillison.net/static/2025/colophon.html
  40. https://github.com/simonw/tools/commit/4ee15aaad8e9a412505210a30f485528cb3c0390
  41. https://gist.github.com/simonw/d5ccbca1b530868980609222790a97cb
  42. https://github.com/simonw/tools/commit/87e2577983f11fc9c7bf7b7a268cf2404a21e1c5
  43. https://simonwillison.net/2023/Mar/27/ai-enhanced-development/
  44. https://simonwillison.net/2025/Mar/6/monolith/
  45. https://github.com/Y2Z/monolith
  46. https://github.com/simonw/files-to-prompt
  47. https://simonwillison.net/2024/Apr/8/files-to-prompt/
  48. https://llm.datasette.io/
  49. https://github.com/simonw/llm-gemini
  50. https://gist.github.com/simonw/2c80749935ae3339d6f7175dc7cf325b
  51. https://simonwillison.net/2025/Feb/14/files-to-prompt/
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ZA72hJas-QNth2mRziu1oA

猜你喜歡