建立你的 90 天計畫，從初步成果擴展到 1,000,000 自然流量
將你 Codex SEO 和 GEO 課程中的資產與證據，轉化為一個聚焦的 90 天計畫，包含頁面賭注、每週循環、證明需求和衡量檢查點。
將你的課程工作轉化為三個你真正能完成的賭注
通往一百萬自然流量的路徑不是一份 100 頁的內容行事曆。它是一個可重複的序列：選擇一個真實的客戶問題、建立一個有用且準確的回答、將它連接到相關決策、檢查發生了什麼，然後做出下一個有證據支持的改善。這個最終工作坊將你在課程中製作的檔案轉化為一個有足夠焦點可以執行的 90 天計畫。
你不需要一個新網站才能使用它。初學者可以規劃第一批頁面；現有網站擁有者可以規劃一個修復、刷新和新群集。Codex 準備計畫和它的包。人仍然批准內容、部署、預算、推廣、帳號存取，以及任何改變公開網路的東西。
你的完成成果： 一份 90 天自然成長計畫，包含三個或更少的活躍賭注、指名的擁有者、證明需求、容量感知的行事曆、每週審查日期、衡量筆記，以及每個賭注的停止或變更條件。
預留 60-90 分鐘。 帶上通過審查的已批准素材：你的成長起手卡、流量任務、事實包、客戶問題地圖、第一頁面或現有頁面筆記、主題地圖、品質關卡記錄、每週審查、相關處的 AI 回答觀察，以及刷新決策。也要帶上你實際的容量：你在一週典型時間內可以提供的內容、技術和擁有者審查小時數。
從已儲存的決策建立，而不是從腦力激盪
建立一個名為 plan-input.md 的檔案。它應該是一份已證實或可審查機會的簡短清單，而不是一份關鍵字構想的墳墓。
plan-input.md
Current position（當前位置）：一個已批准的準備檢查清單；一個現有的每月記帳服務頁面；
英國以外的主張沒有公開證明。
Reader mission（讀者任務）：幫助英國自由接案設計師決定有條理的記錄和每月記帳支援是否適合他們的情況。
Evidence that survived review（通過審查的證據）：兩份關於遠端服務適合度的帶日期客戶筆記；
事實包支持服務範圍和稅務申報排除；第一個檢查清單頁面上線；
刷新決策說保留 URL 並加入一個狹窄的適合度路徑。
Capacity per week（每週容量）：內容擁有者 2 小時；主題擁有者 30 分鐘；開發者每隔一週 2 小時。
付費位置或新工具沒有預算。
Open risks（開放風險）：服務區域措辭需要擁有者批准；最新頁面的成效比較尚未完成。
Not in scope（不在範圍內）：城市落地頁、付費反向連結、廣泛稅務建議、網站重新設計。注意什麼缺失了：一個流量預測、十五個通用主題、一個製造工具的承諾，以及模糊的「技術 SEO」。那些不是你可以執行的決策。輸入建立了讓 Codex 拒絕干擾的邊界。
使用三個賭注規劃提示詞
附上 plan-input.md 和它指名的來源檔案。然後複製這個提示詞：
閱讀 [plan-input.md] 和這些已批准的來源：[流量任務、事實包、問題地圖、主題地圖、
品質關卡記錄、每週審查、AI 觀察和刷新決策]。建立 90-day-organic-growth-plan.md。
包含：
1. CURRENT POSITION（當前位置）：僅事實，附上來源檔案和未知事項。
2. THREE GROWTH BETS MAXIMUM（最多三個成長賭注）。每個賭注需要一個客戶問題、頁面或資產、
已批准的證明、訪客行動、擁有者、工作量、依賴關係、衡量日期，以及明確的繼續/停止/變更條件。
3. THREE 30-DAY SPRINTS（三個 30 天衝刺），工作小到符合所述容量。
4. A WEEKLY REVIEW RHYTHM（每週審查節奏），使用一個帶日期的證據資料夾和一個行動。
5. MEASUREMENT（衡量）：自然/搜尋證據、頁面成果、轉換定義，以及在有用處分開的 AI 回答觀察。不要合併它們。
6. RISKS（風險）、擁有者決策，以及刻意排除在 90 天外的工作。
7. 為每個工作包連結回相關的課程工作坊。
將事實與預測分開。不要發明流量、排名、收入、容量、來源數據或轉換率。
不要發布、分配支出、聯絡任何人、建立帳號、提交 URL、更改分析或進行生產變更。在你批准之前把計畫讀作一個容量測試
Codex 永遠不應該僅僅因為提示詞允許三個就填滿三個賭注。正確的數字是任何可以完成和檢查的。對 Northstar Books，這是一份可信的第一稿：
賭注 | 客戶問題 | 第一個可交付成果 | 證明和擁有者 | 何時繼續 | 何時停止或變更 |
|---|---|---|---|---|---|
服務適合度頁面 | 自由接案設計師可以使用遠端記帳師嗎？ | 證據優先的頁面簡報 | 服務範圍事實；擁有者批准服務區域措辭 | 簡報有明確的問題和已批准的事實 | 擁有者無法支持服務邊界 |
檢查清單刷新 | 準備頁面沒有將準備好的讀者引導到適合度資訊 | 狹窄的變更表 | 刷新決策和事實包；內容擁有者 | 發布通過品質關卡且連結正常 | 新文案重複服務適合度頁面 |
回答資產 | 在決定尋求幫助之前我該收集哪些記錄？ | 保留並驗證檢查清單回答 | 現有檢查清單證據 | 完整期間和讀者回饋證明下一個變更合理 | 證據保持太薄弱；等待而不是改寫 |
第三個賭注可以是「驗證並等待」。當一個新頁面沒有完成的比較期間時，這是一個真實的賭注。它保護團隊不會不斷重建那一個需要時間被閱讀的資產。
拒絕一個不可能的計畫
如果計畫要求一個人在第一個月中產生五個頁面、一次遷移、一個工具、本地檔案、推廣、結構化資料變更和每日報告，拒絕它。使用這個修復提示詞：
這個計畫超出了所述容量。圍繞最小的一組已完成、可審查的賭注重建它。
只有當一個賭注有指名的擁有者、已批准的證明、一個下一個可交付成果和一個可檢查的
衡量日期時才保留它。將其他所有內容移到 EXCLUDED WORK，附上重新審視所需的證據。一個達到審查日期的較小計畫，比一個產生未驗證草稿的雄心勃勃的行事曆教你更多。
在建立更多工作之前鋪設三個衝刺
每個 30 天衝刺有不同的工作：建立一個可靠的輸入、發布一個小的已批准變更，然後檢查並決定。這是一份適合範例容量的具體行事曆。
衝刺 | 週 | 人工工作 | Codex 工作 | 已儲存的完成證明 |
|---|---|---|---|---|
1：準備 | 1-4 | 確認服務邊界；批准頁面簡報；保存變更前狀態 | 事實檢查、建立服務適合度簡報、識別檢查清單刷新範圍 | 已批准的簡報、事實包資料列、發布計畫 |
2：發布 | 5-8 | 審查狹窄變更；開發者檢查相關路線；批准發布 | 準備差異/變更表、檢查連結和主張、製作發布說明 | 品質關卡記錄、發布日期、正常運作的 URL |
3：檢查 | 9-12 | 匯出完整期間；審查回饋；選擇下一個行動 | 比較證據、陳述未知事項、推薦一個行動 | 帶日期的每週筆記、90 天審查、下一個賭注決策 |
這刻意不是「每週發布」。你的節奏遵循可以採購、審查和衡量的東西。如果一個事實在第一個衝刺中被阻擋，將頁面可交付成果轉為證據收集；不要用一個隨機主題取代它。
讓每個賭注通過四道關卡
在一個賭注進入活躍計畫之前，用同樣的四個問題評估它：
關卡 | 問題 | 通過是什麼樣子的 |
|---|---|---|
讀者 | 什麼決定變得更容易？ | 一個訪客問題和一個有用的頁面或資產結果 |
證明 | 我們可以公開陳述什麼？ | 指名的事實包資料列或可以批准它們的擁有者 |
容量 | 誰完成下一個包？ | 一個指名的擁有者和一個符合衝刺的工作量 |
學習 | 什麼會改變我們的下一個決策？ | 一個日期、證據來源和繼續/停止條件 |
如果沒人能批准它的地點或資格邊界，服務適合度頁面失敗。如果它重複檢查清單頁面，回答資產失敗。如果刷新是表面性的而不是與讀者問題相關，它失敗。當一個賭注失敗時，將它放在計畫的 PARKED 段落並附上缺失的證據。不要把它偽裝成一個優先事項。
在計畫內安排每週營運循環
只有當它有一個重複的決策時刻時，你的計畫才保持有用。在每個活躍賭注中放這一行：Weekly review: Friday, 10:00; input owner: [name]; approval owner: [name].（每週審查：週五 10:00；輸入擁有者：[名稱]；批准擁有者：[名稱]。）然後使用每週 Codex 成長循環建立一個帶日期的筆記。
每週筆記回答與 90 天計畫不同的問題。計畫設定當前的賭注和停止條件。筆記在那些邊界內選擇本週的一個行動。如果筆記提議一個第五個構想，它屬於 PARKED，除非它使一個活躍事實或風險失效。
在計畫內使用這個每週迷你提示詞：
閱讀 [當前的 90 天計畫]、本週的證據資料夾和活躍賭注記錄。選擇一個推進活躍賭注
或解決其陳述阻礙者的行動。引用證據、容量、擁有者批准和衡量日期。
如果沒有行動是合理的，規定最小的收集任務或等待條件。不要加入新賭注、
發布、花錢或更改實際系統。衡量系統而不混合不同的訊號
為每個賭注使用一份小型衡量筆記：
Measure（衡量）：[URL 或頁面群組] 的完整 Search Console/分析期間。
Page outcome（頁面成果）：[例如，點擊探索通話連結、完成檢查清單或合格詢問]，
由 [擁有者批准的事件或手動記錄] 定義。
AI observation（AI 觀察）：確切提示詞、市場/語言、日期、回答文字或截圖；
與自然工作階段分開記錄。
Review date（審查日期）：[在適當的完整期間之後的日期]。
Interpretation boundary（解讀邊界）：比較證據；不要聲稱一次編輯造成了一個結果。自然搜尋數據、頁面內行動、客戶回饋和 AI 回答觀察都可以提供幫助，但它們不能互換。AI 回答中的一個提及不是一個自然工作階段。曝光數的上升不是一個合格的詢問。將它們分開給 Codex 一個誠實的基礎來做下一個行動。
執行 30、60 和 90 天審查
在第 30 天，問：每個活躍賭注是否得到了它所需的事實、簡報或發布包？在第 60 天，問：已批准的變更是否通過了發布關卡並保存了變更前狀態？在第 90 天，問：哪個賭注有證據繼續、哪個需要聚焦刷新、哪個必須暫停？
使用這個最終審查提示詞：
閱讀 [90 天計畫]、[每週審查筆記]、[發布說明] 和 [完成的衡量證據]。寫下 90-day-review.md，
包含：已完成的工作；事實和未知事項；每個賭注的繼續/停止/變更決策；支持該決策的證據；
要帶走的教訓；以及一個推薦的下一個 30 天賭注。不要將因果歸因於證據之外，
不要沒有新證明就復活被排除的工作，或進行任何外部變更。一個誠實的結果可以是：「服務適合度簡報已準備好，檢查清單刷新已發布，成效需要另一個完整期間。保留兩頁群集；不要開始新的地點頁面。」這就是一個紀律化的網站成長的方式，而不是不斷改變方向。
你的可重複使用 90 天計畫檢查清單
- [ ] 我只使用了已批准的證據並記錄了當前的未知事項。
- [ - ] 我有三個或更少的活躍賭注，每個都有讀者問題和證明邊界。
- [ ] 每個賭注都有指名的擁有者、下一個可交付成果、衡量日期和停止條件。
- [ ] 第一個衝刺符合實際容量，包括審查時間。
- [ ] 每週審查在計畫內選擇一個行動，而不是發明一個新策略。
- [ ] 自然衡量、頁面成果和 AI 觀察保持分開。
- [ ] 任何公開變更都會通過發布關卡。
接下來循環到哪裡
計畫不是工作的結束；它是回到正確工作坊的地圖。當你需要一個新的需求訊號時，找出 30 個真實客戶問題。當一個已確認的頁面贏得一個獨特的後續決策時，建立一個五頁流量群集。當公開事實不一致時，在來源處修正它們。當一個現有頁面有證據但點擊薄弱時，使用刷新工作流程。
保持這個循環運行：證據 → 一個已批准的包 → 受控發布 → 審查 → 下一個決策。那就是有意義的、複合的自然成長背後的作業系統。
作者：Aaron Wolfe，Auspia 自然成長系統設計師，15 年 SEO/GEO 經驗。Aaron 專注於將初步成果轉化為持久的自然成長作業系統。
![90 天計畫工作包流程圖]()
對這項作業使用此順序：從真實輸入開始，檢查證據，準備一個可審查的輸出，然後選擇讀者的下一步。
