Tutorial 4 Prompting and Reviewing zh HK

教程 4 · 提示與審查

🌎 語言： 繁體中文（香港） — 查看全部 33 種語言

目標： 掌握元技能。你已經能與智能體一起構建功能；本章關注如何讓過程變得 順暢且可重複：一次寫對提示、高效審查差異、出問題時迭代，並在會話之間保持進度。

← 上一章：教程 3：你的第一個智能體任務 · 下一章：教程 5：本地化

---

像技術負責人一樣提示，而不是像搜索框一樣

把智能體視為快速、字面理解、積極主動的初級工程師，並像帶領優秀新人那樣帶領它：

• 同時說明目標和約束。 “加入 endorse”很弱；“按 connect 模式加入 endorse，只用帶種子的 RNG，附測試並保持門禁綠色”更強。約束讓程式碼融入專案。
• 指出示例。 “遵循 renderConnect 的模式”勝過一大段抽象描述。現有程式碼就是最佳規格。
• 非平凡任務先要計劃，再允許編輯。 改計劃很便宜，撤銷十個檔案的改動很昂貴。
• 每條提示只做一件事。 把“加 endorse、重構 RNG、更新 README”綁在一起會產生難審查的差異。
• 明確測試門禁。 “執行 npm test，全部變綠前不要視為完成”會讓智能體自行檢查工作。

每次都審查差異

速度是智能體的優勢，但未經閱讀的速度也是缺陷進入產品的方式。建立固定檢查習慣：

1. 範圍： 是否只改了該改的內容？無關行移動是警訊。
2. 模式： 是否符合周圍程式碼？是否沒有新增相依性，也沒有在 src/ 內做 I/O？
3. 專案規則： 本儲存庫要求只用帶種子的 RNG（在差異中搜索 Math.random）、 使用者可見文字必須放在語言套件，並且卡片行不能超過佈局寬度。
4. 無障礙： 新輸出能否通過 --accessible？執行 lockedin --accessible <your command>，確認它是乾淨的純文字，沒有裝飾符號漏過 a11yFilter。
5. 測試： 是否有新測試？功能壞掉時它真的會失敗嗎？可以問： “改哪一行能讓這個新測試失敗？”
6. 實際執行： 執行 npm test，再執行指令並親自查看輸出。

不必理解每個字元，但必須理解每個決定。無法解釋的改動，應先讓智能體說明，再決定是否接受。

門禁不綠時如何迭代

紅色門禁是正常步驟，不代表失敗。關鍵是給出精確回饋：

“npm test 失敗，錯誤如下：[paste the exact error]。renderEndorse 寬度測試要求每行卡片 可見寬度 ≤ 60 列。請修復，但不要削弱測試。”

粘貼真實錯誤文字。“壞了”會迫使智能體猜測，堆棧跟蹤則能讓它定位。最好繼續同一會話， 因為智能體已有剛才的上下文。若兩三次迭代仍不能收斂，就退一步重新劃分任務；單條提示可能太大。

跨會話保持進度

真實工作往往跨越多個時段。兩個習慣能讓智能體長期保持效率：

• 記憶 / 約定。 如果智能體支援持久記憶或專案說明檔案，請記錄始終要遵守的規則，例如 “所有隨機性都用 pick / shuffle”“宣布完成前執行 npm test”。約定只需說一次。
• 交接說明。 本儲存庫在 docs/HANDOFF.md 保留一份簡短、經過清理的狀態文件：專案是甚麼、如何構建和測試、下一步是甚麼。 返回專案或移交給隊友、另一個智能體時，它能在幾秒內重建上下文。可把更新它列為改動的一部分。

值得保留的護欄

• 門禁不可協商。 只有測試變綠才能交付；這讓你既快又能信任結果。
• 你是最終審查者。 智能體編寫，你來決定。接受差異就表示你為它負責。
• 小而可驗證的步驟勝過一次巨大跳躍。每次接受改動後，應用都應保持可用。

---

✅ 和你的智能體一起試試

1. 為“提供未經請求建議”的 mentor 指令寫一段規格，包含約束，並讓智能體按計劃、測試、程式碼、 門禁的順序測試優先實作；每一步都審查。
2. 要求智能體更新 docs/HANDOFF.md，加入新指令。
3. 故意破壞某處，例如刪除一個池條目，執行 npm test，練習把確切失敗交給智能體修復。

---

下一步

• 瀏覽 src/lockedin.js 的真實程式碼；你現在已經理解它的形狀。
• 閱讀 docs/HANDOFF.md 中的專案狀態和架構說明。
• 閱讀 指令參考 中的笑話。

教程到這裏結束。你現在能在測試門禁後指導 AI 智能體構建和修改真實軟件，並使用了一個 自信過頭的示例。同意嗎？👇 件