01.02 如何整理專案資料並向 Codex 說明需求

介紹輸入資料、草稿、成品和檢查記錄的組織方式，以及怎樣給出清楚的邊界。

01 · 導讀

介紹輸入資料、草稿、成品和檢查記錄的組織方式，以及怎樣給出清楚的邊界。
適合：能打開 Codex，但經常得到方向不對的結果的學員。

教學範例：Northstar Studio 為虛構業務，服務英國獨立咖啡店。 棉布袋 35×40cm、MOQ 100、打樣 7–10 個工作天皆為說明寫法的虛構參數；報價、運費、認證、完整交期不詳。 範例不代表真實經營成果。

02 · 相關資料

• 輸入資料與其來源、日期、未知欄位。
• input、drafts、output、checks、templates 目錄。
• 目標讀者、輸出格式與本次允許範圍。

03 · 核心講解

任務說明要同時給目標、輸入、範圍、限制和驗收，不只是「幫我做個好的」。

參考資料描述風格或事實，不自動授權複製其中的圖片、程式碼或客戶資訊。

「幫我做一份出海選題」過於籠統，Codex 無法知道能引用哪些參數、寫入哪裡，也不知道什麼不能碰。 把事實來源、目標讀者、輸出格式和禁止動作寫在同一份說明裡，後續修改時才有共同依據。 目錄分開後，原始資料不會被新草稿覆蓋。

需求說明可以依六行組織：要解決什麼、讀哪些文件、給誰看、輸出什麼格式、保存哪裡、遇到缺資料怎麼處理。 把「更專業、更爆款」換成這些可判斷的訊息，結果更容易修訂。

例如產品事實只有 cotton canvas，沒有認證與報價，選題就應圍繞著能證實的材料和使用問題。 要求腳本出現銷量、收益或交期時，Codex 應先指出證據缺失。

開始前讓它複述讀寫路徑，是為了避免原始資料與成品混放。 你授權寫 drafts/topics-v1.md，只對應這次內容產生；之後是否發布或發送，仍由業務負責人決定。

Codex 總是補出不存在的認證時，先檢查事實文件有沒有舊文案，再在 brief 中明確引用範圍與未知處理，不要只反復說「更真實一點」。

會員可閱讀完整文章。 登入