EP-4 與 AI 共同協作寫程式的準則
本週主要在研究如何依據故事套路，檢索金庸小說向量資料庫，讓語言模型生成武俠小說大綱。在研究的過程中，我發現更需要處理的，是找到與 AI 共同協作的準則。這是因為在開發的過程中，我大量使用 AI 幫助我撰寫程式，但是成果往往不如預期。因此我們必須先知道 AI 的極限，以及學會如何與 AI 互動。
現階段 AI 的極限在哪
AI 有極限嗎？我不知道，畢竟我也不是電腦科學家。但是我很肯定的是，現在的主流寫程式工具，無論是使用網頁版的Claude 3.5 Sonnet、GPT-4o，或者是人工智慧程式編輯器，如Cursor、Windsurf等等，在2024年底的現在，這些工具都有明顯的極限，作為一個開發者很快就會觸及。
明白 AI 的極限是很重要的，知道它的極限在哪，才可以避免給一些錯誤指示。
上下文的極限
根據 Anthropic 官方說法，Claude Pro 的上下文窗口目前為 200k+ 個 tokens（約 500 頁文本或 100 張圖像）。至於 OpenAI 的 GPT-4o ，其上下文窗口最大為 128k tokens 。
這邊說的上下文窗口，指單一傳送給語言模型的 tokens 數，順道一提，1 token 約等於 4 個英文字母或 3 個中文字。
這樣看起來，可以接收的訊息量很大啊，但是別忘記了，在每次的聊天會話時，語言模型有能力記得你第一次的問題，這代表它每次都會重新閱讀整個對話。
假設你第一次使用了 1000 tokens 數，第二次對話，你使用了1500 tokens 數，在第二次對話時， Claude 實際上是使用了 2500 tokens 數，上下文窗口是累計計算的。可以想想這樣的過程持續數十次，最後 Claude 會閱讀相當大量的文章，然後就會拒絕回應。
每日訊息數上限
不只上下文有極限，每日使用的訊息數量也有極限。
以付費使用者來說， Claude 每日發送訊息量大約500則左右，會依據系統負載量隨時調整。至於GPT-4o ，每3小時最多發送80則訊息。
綜合上述兩者來看，使用者是無法任意地使用語言模型的，就我個人體感經驗，大概持續工作4~6小時，就會碰到上限。就算你還有體力，當日就得停工了。
AI 程式編輯器的極限
之前是以 Claude 、 ChatGPT 網頁版的角度來談，那麼如果我們訂閱了目前流行的 AI 程式編輯器，如 Cursor 、 Windsurf ，是否仍會遇到類似的問題呢？
答案是肯定的，畢竟如果模型本身都有限制了，那麼使用模型的 IDE ，自然也有限制。
首先我們先看 Windsurf 官網介紹，
我使用的是 Windsurf Pro 專業版，假設我在對話框中使用了高級語言模型，例如 Claude 35. Sonnet ，一次對話使用一個高級使用者提示詞點數（ Premium User Prompt Credits ），每月最多能使用 500 次。如果在對話中，語言模型有查看檔案、搜尋、寫入的動作，每使用一次工具就會消耗流程操作點數，最多操作 1,500 次。
如果這些點數都用完了，就會自動切換成傳統對話模式（Legacy Chat mode），沒辦法操作工具，不過仍然可以使用高級語言模型進行上下文閱讀。或者花 10 美金額外購買 300 點。
Cursor 有類似的限制，作法不同。
如果是使用高級語言模型，每月可優先使用 500 次， 500 次用完了，仍然可以繼續使用，但是如果現階段一堆人在用，你的請求會被排在其他請求後面。
我不清楚 Cursor 其他還有什麼限制，畢竟我目前沒有使用 Cursor ，因為它比較貴。不過大差不差。 AI 編輯器會有的限制，兩者都是差不多的。
智力上限
這個問題比較難說明，到底是使用者太笨，表達錯誤，還是 AI 無法正確理解我們的問題？
假設我們的問題很單純，通常 AI 可以正確無誤地解決問題。例如我要它在畫面中增加單選的項目，項目文字必須要由我提供的 JSON 檔取出。那麼它通常能夠正確解決問題。
要完成此任務，你必須提供你的網頁程式碼，指定你要加入的位置。如果是使用 Windsurf 等 AI 編輯器，它會自動去讀取你的資料夾的程式碼，不需要在對話框提供。
在使用的體感上，如果你是使用網頁版，即便你一開始就把相關的程式碼都丟給它，有時仍會發現它搞不清楚程式之間的關係，或者它遺漏了某個程式碼。如果它出錯了，我們就必須額外提醒。提醒次數一多就會讓人感到煩躁。
如果使用 AI 編輯器，我覺得表現的會稍微聰明一點（只有一點）。儘管背後使用的都是同一個語言模型。我在猜測應該是開發團對有針對 AI 編輯器去做一些調整，讓 AI 能夠逐步地思考，檢索相關程式碼。
如果我們的問題比較複雜呢？
例如我前天發現，當我在畫面上選擇了主角的身分，以及其他的故事選項，當我送出資料時，畫面又回到了一開始的狀態。
這時我讓 Windsurf 盤查問題，嘗試了好幾次，都是互相轉圈，甚至有時候還刪除了不該刪除的程式，不然就是搞不清楚現在在做什麼。不過它也還算聰明，懂得設計日誌，然後請求我把每次日誌資料都提供給它。
然後每次生成程式碼時，有時候沒什麼問題，但是接著請它修改其他程式碼時，卻把之前沒問題的程式又修掉了，真是莫名其妙。
當我發現它在轉圈時，就必須人工介入，仔細閱讀它檢查了哪些程式碼，確認它卡在哪裡。最後來回好幾次，才終於搞定問題，能夠把我們選擇的資料傳送給語言模型，讓語言模型生成故事大綱。
安全風險
我自己是沒有發生資安問題，但是之前有新聞說，Python套件Ultralytics被駭客入侵，導致用戶的開發環境被植入挖礦軟體。所以如果讓 AI 輔助開發程式，卻沒有檢查 AI 使用了哪些套件，就容易發生資安危機。
既然 AI 仍有極限，作為開發者該如何應對？
學會如何下命令
要改善程式碼，學會如何向 AI 下命令是必須的，以下是我的建議：
大任務要拆解成小任務，不要期待它一口氣做好所有事。
命令要明確，不能給含糊的問題，建議最好開啟文字編輯器，先在上頭想好問題或指示，確認後再送出。
當我們把任務拆解後，同時要求它只能解決指定的任務，一步一步解決問題
要求 AI 做 debug 時，必須要求它做最小幅度的修改。
自己的大腦才是最強的語言模型
我們現在得知， AI 使用次數有限制，而且可能因為我們無法正確描述問題，或者問題太過複雜， AI 不能滿足我們的需求。當 AI 在使用套件時，並無法實時確認目前外界的狀態，可能會誤用了遭到駭客入侵的套件。
因此到目前為止， AI 仍然只能當作輔助寫程式的工具，無法取代寫程式。
所以別忘記了，我們的大腦才是最強的語言模型。
我們可以將 AI 當作是一個非常有耐心的夥伴，能夠全天候地協助我們解決問題。但是別忘記了真正要寫程式的還是我們。
當程式碼超過一定的行數以上（個人體感是1000行）， AI 出錯的機率也會開始增加。如果對於寫程式一點概念都沒有， AI 提供的程式，也從未讀過，此時就會開始覺得棘手。
其實這個概念也不只是運用程式撰寫上，無論是使用 AI 來輔助寫作、繪圖、編曲，要達到令人滿意的成果，人類的介入都相當重要。至少在現階段的 AI ，人類還是具有主導權。
為 Windsurf 編輯器加入限制
在使用 AI 編輯器時，最常遇到的問題是， AI 自作主張幫我加入一些安全性的功能，例如try…catch語法。當然有些部分是必要的，可是如果你不適當地制止它，程式有可能越來越長。
因此在 AI 編輯器的系統提示詞（ System Prompt ）加入一些客製化規則就相對地重要。
因為我是 Windsurf 的使用者，所以以下僅用 Windsurf 做範例，但是原則都相同。
在 Windsurf 編輯器內，找到右下角的 Windsurf Settings ，就可以開啟系統設定，有兩個位置可以編輯：
Set Global AI Rules：設定共通的準則
Set Workspace AI Rules：針對每一份專案設定特殊準則
我在網路上找了建議的準則，是由 Reddit 上的網友 bu3askoor 提供，我只有做少許的修改。供各位參考。底下這部分可以設定共通的準則。
語言
回應方式：永遠使用台灣地區的繁體中文及相關用語
核心程式設計原則
程式碼品質：優先考慮乾淨、易讀和可維護的程式碼。
演算法效率：使用最有效率的演算法和資料結構。
錯誤處理：實作穩健的錯誤處理和記錄機制。
測試：為所有關鍵功能撰寫單元測試。
設計模式：運用適當的設計模式以提高可維護性。
程式碼審查：產生易於他人審查的程式碼。
模組化：撰寫模組化程式碼，將複雜邏輯分解成較小的函式。
重複使用：優先重複使用現有程式碼，而非重新撰寫。
安全性：優先考慮安全的編碼實務。
簡潔性：追求簡單明確的解決方案，避免過度設計。
程式碼風格和格式
縮排：使用 tab 進行縮排。
命名慣例：變數使用 snake_case，類別使用 PascalCase，函式使用 camelCase。
註解：加入清晰簡潔的註解說明程式碼區塊和邏輯。
程式碼格式：自動格式化程式碼以提高可讀性。
行長度：保持每行不超過 100 個字元。
程式碼格式化區塊：格式化長串列和字典以提高可讀性。
一般行為（該做和不該做）
變更：進行小幅度、漸進式的變更；避免大規模重構。
避免：除非明確要求，否則不要更改可運作的程式碼。
變更：修改程式碼時，逐步進行，先驗證變更。
釐清：如有不確定，在產生程式碼前先請求釐清。
避免：除非明確要求，否則不要覆寫手動程式碼變更。
文件：如被要求，查看專案文件並在回應中使用。
推理：在產生程式碼或發送回應前，逐步推理。
成本最佳化：注意成本，僅在必要時發送請求，除非必要，避免 AI 驅動的除錯、重構或測試生成，盡可能批次處理變更。
除錯：進行小幅度漸進式變更以修復錯誤，查看終端機輸出資訊。
提示效率：使用精確且具體的提示；避免模糊，不重複先前的指示；重複使用上下文。
本地處理：手動執行簡單任務；避免不必要地使用 AI。
使用者指導：始終遵循給定的指示，並將使用者指示優先於全域規則。
簡潔性：避免過度設計，追求最簡單的解決方案。
特定語言指示
Python
Python 型別提示：為所有函式參數和回傳值使用型別提示。
Python 匯入：依類型分組匯入：標準、外部和本地。
Python 程式碼檢查：對程式碼運行 pylint 以確保風格一致。
Python 測試：使用 pytest 進行所有單元測試。
Javascript
Javascript：使用現代 ECMAScript 慣例。
Javascript 避免：避免使用 var；優先使用 const 和 let。
Javascript 程式碼檢查：對程式碼運行 eslint 以確保風格一致。
Javascript 註解：使用 JSDoc 風格註解記錄函式。
Javascript 測試：使用 jest 進行所有單元測試。
檔案處理
檔案管理：將長檔案分解成較小、更易管理的檔案，並包含較小的函式。
匯入陳述式：優先從其他檔案匯入函式，而非直接修改這些檔案。
檔案組織：將檔案組織到目錄和資料夾中。
專案管理
功能規劃：始終參考專案的功能規劃以獲取上下文。
功能規劃進度：每次變更後更新功能規劃進度。
功能規劃下一步：在每個回應中建議功能規劃的下一步驟。
作業系統
作業系統：須知我使用的是 Windows，且必須使用 PowerShell 指令。針對不同的專案，我們可能會有不同的需求。
最好在一開始就先跟 AI 說明清楚，底下這段也是網友 bu3askoor 提供的範例，我針對我的需求修改如下。
**專案背景 Project Context**
project_type: 金庸風格武俠小說生成器
tech_stack: Python, Streamlit, LangChain, OpenAI API, FAISS
file_structure:
- 主程式：`main.py`、`story_outline.py`
- 設定檔：`openai_config.py`、`log_config.py`
- 工具類：`utils.py`、`rag.py`、`vdb.py`
- 資料庫：`vectorstore/`、`novel_database/`
- 模板：`templates/`
**功能需求 Feature Requirements**
story_generation:
- 需包含三幕劇結構（起源、成長、結局）
- 每一幕都必須提供使用者選項
- 完整的故事大綱生成功能
- 自動儲存生成進度
rag_system:
- 使用 FAISS 向量資料庫儲存金庸小說參考資料
- 透過 LangChain 實現檢索增強生成
- 確保生成內容符合金庸寫作風格
user_interface:
- 清晰的使用者介面展示故事選項
- 即時顯示生成結果
- 提供故事進度儲存功能
**系統設計 System Design**
logging_system:
- 完整的日誌記錄系統
- 錯誤追蹤與處理機制
template_system:
- 模板化的故事結構
- 可擴展的故事類型設計
**程式撰寫準則 Coding Guidelines**
error_handling:
- 所有的 API 調用都必須有適當的錯誤處理
- 使用者輸入驗證
documentation:
- 程式碼必須包含完整的中文註解
- 關鍵函數必須有清楚的文件說明
**專案管理 Project Management**
version_control:
- 遵循功能開發計畫
- 確保程式碼的可維護性和擴展性