什麼樣的 Markdown 計劃文件適合軟體開發專案？好的計劃和偉大的計劃有什麼區別？ 我總是不斷強調我花了 85% 以上的時間和精力在計劃階段。那到底包含了什麼呢？ 這很難抽象地解釋；你需要一個具體的例子來真正說明其中的細微差別。所以我想分享一個今天的好例子。 這也解決了我最近收到的一個問題，關於我的方法。人們似乎認為你必須一次性完成專案中的所有工作。在我的方法中，這是正確的，但僅限於版本 1！ 如果你決定想要添加新功能或改變某些運作方式，當你有一個運行中的 v1 時，顯然可以這樣做。而你這樣做的方式與創建 v1 的方式相同，首先創建一個超詳細的 Markdown 計劃，然後將其轉化為 beads。 所以我將給你一個來自 Cass 的例子，我的編碼代理會話搜索程式，這是一個相當複雜的 Rust 程式，能自動檢測、解析、存儲和索引你所有的先前會話日誌，幾乎涵蓋所有的編碼代理。它提供低於 50 毫秒的即時 "隨打隨查" 功能，並擁有許多其他優秀的功能。 我決定想要為 Cass 添加一個功能，類似於我在 MCP Agent Mail 和 beads_viewer (bv) 中已經擁有的功能：將你的設置導出為可以使用 GitHub Pages 提供的靜態網站。 你可以看到這個專案的 bv 的一個例子，這是我將在這篇文章中描述的計劃過程的最終結果： 這個功能使得使用 gh 工具生成和部署導出網站變得非常快速和簡單。 該網站通常由一個 sqlite 文件和一堆在瀏覽器中運行的 typescript 和 wasm 組成，但性能非常好，功能和樣式也很不錯，你可以在剛才給出的例子中觀察到。 現在，分享 MCP Agent Mail 消息或一堆 beads 是一回事，但分享一堆編碼代理會話日誌則非常不同；這些東西通常充滿了敏感信息、API 密鑰、咒罵/侮辱（至少我的會這樣！）以及其他你絕對不想向全世界暴露的材料。 但是 GitHub Pages，儘管很好，但僅適用於公共倉庫（順便說一下，我的工具也支持 Cloudflare 頁面，但 GH Pages 在這種用例中更好且更簡單）。那麼如何處理這些問題呢？ 答案是加密：用戶首先選擇要包含的編碼代理、項目文件夾、時間範圍等，然後生成一個包（請注意，這個包是 Cass 內部將所有編碼代理消息從其原始本地格式轉換為的標準格式），然後用戶提供一個密碼來用於該包的加密。 所以這個想法是，儘管倉庫和網頁是公共的，但除了你和你告訴密碼的其他人，其他人將僅看到一個密碼字段，無法閱讀任何消息。 ...