Codex 項目到底怎麼建？一個總文件夾，還是多個子文件夾？
整理版優先睇
Codex 項目結構冇統一答案，關鍵係按需求同控制上下文長度。
呢篇文章係大瑜分享佢對 Codex 項目結構嘅心得。佢用自己分身小瑜開公司嘅例子，解釋點樣組織 task 先至最有效。作者發現好多人混淆項目同 task，所以用實際場景講解兩種做法嘅利弊。
第一輪佢用一個總文件夾，入面開多個 task，好處係每個 task 都有上下文，數據容易共享。但係隨住業務擴張，task 越來越多，變得混亂。第二輪佢改為按分類開多個文件夾，每個文件夾入面做唔同 task，咁樣清晰好多，但係跨文件夾訪問就要指定路徑。
結論係冇絕對對錯，睇需求而定。另外，消耗 token 嘅真兇係上下文長度，唔係文件夾大小。建議定期保留中間結果落盤，當上下文超過 50-70% 就重開 task，咁樣先可以慳 token 兼保持效率。
- 項目結構冇標準答案，要根據實際工作流程決定用單文件夾多 task 定多文件夾。
- 單文件夾多 task 適合初期，好處係上下文一致、數據共享方便，但太多 task 會亂。
- 多文件夾各自 task 更清晰，但跨文件夾訪問需要指定路徑，唔能夠自動共享。
- 消耗 token 嘅真兇係上下文長度，唔係文件夾大小，所以唔好為咗慳 token 而縮細文件夾。
- 定期保留中間內容落盤，當上下文長度超過 50-70% 就重開新 task，可以有效控制 token 用量。
問題背景：點樣組織 Codex 項目？
大瑜喺講解 Codex 嘅時候，發現好多人對項目同 task 嘅結構唔係好明。到底係一個總文件夾入面開多個 task，定係按分類開多個子文件夾各自 task？佢用自己分身小瑜開公司嘅例子，逐步講解兩種做法嘅優缺點。
Codex 項目文件夾結構
task 組織方式
第一輪：單文件夾多 task
小瑜一開始開咗間公司，需要自己做需求、研發同運營。佢建立一個文件夾「codex-camp」，然後開三個 task：需求收集、產品研發、產品運營。
- 每個 task 都有自己嘅上下文，互相唔影響。
- 一個文件夾下，數據可以快速檢索同共享，例如研發可以直接拎需求分析報告。
但係隨住業務發展，需要處理小紅書同抖音嘅需求，於是每個需求再開新 task，最後 task 太多，亂到唔清唔楚。
上下文獨立
數據共享方便
第二輪：分類文件夾各自 task
為咗改善混亂，小瑜改為開三個文件夾：需求、研發、運營，每個文件夾入面再開對應嘅 task。
- 優點：結構清晰直觀，每個範疇一目瞭然。
- 缺點：研發 task 如果要用需求分析結果，默認係揾唔到，需要指定文件路徑先得。
清晰直觀
跨文件夾訪問要指定路徑
消耗 token 嘅真相同實用建議
好多人都誤解，以為文件夾大就會食多 token，其實係錯嘅。記住呢個原則，就可以有效控制 token 用量，同時保持工作效率。
定期保留中間內容落盤
重啓一個新 task
尋日同大家講解codex嘅時候，發現有啲朋友對項目同task唔係好明。
到底係一個總文件夾入面開多個Task直接開搞，
定係按分類子文件夾各自開task？
大瑜同你講個例子，你就明㗎喇。
第一輪：開住先啦！
而家大瑜嘅分身小瑜開咗間公司，佢要負責需求收集、產品研發、產品嘅營運都係佢做。
於是，小瑜同學就開一個新嘅文件夾：codex-camp。然後開三個任務：
好處好明顯：
1、每個任務都有上下文，邊個都唔影響邊個
2、一個文件夾下面，數據可以快速檢索、共享。例如研發需要需求分析嘅報告，直接拎就得。
不過隨住業務發展，
大瑜發現，仲需要小紅書嘅需求、抖音嘅需求，於是針對每個需求佢又開一個task，變成：
最後任務越嚟越多，越嚟越亂。於是直接分開囉。
第二輪優化
呢個時候，我哋就開三個文件夾，每個文件夾入面，完成唔同嘅任務處理。
優點好明顯：好清晰直觀。
但係缺點都好明顯：如果研發任務需要需求分析嘅結果報告。
唔好意思，預設係揾唔到㗎！如果需要用到文件，你要話畀佢知文件嘅位置先得。
寫喺後面嘅說話
好多人有一個誤區：
文件夾越大，消耗token越多！
話你知一個消耗token嘅真兇：上下文字數嘅長度。
如果想token用得慳：定期保留中間內容落盤，超過50%-70%嘅額度，就重新開一個新嘅task啦！
歷史文章列表：
Claude Code 好勁，但點解我更建議普通人先學 CodeX？
昨天在給大家講解codex的時候，發現有些小夥伴對項目和task不是很明白。
到底是一個總文件夾裏建多個 Task直接開幹，
還是按照分類子文件夾各自建task？
大瑜給你講個例子，你就明白了。
第一輪：先開始幹吧！
現在大瑜的分身小瑜開了個公司，他需要負責需求收集、產品研發、產品的運營都是他做。
於是，小瑜同學就建一個新的文件夾：codex-camp。然後建立三個任務：
好處很明顯：
1、每個任務都有上下文，誰也不影響誰
2、一個文件夾下，數據可以快速檢索、共享。譬如研發需要需求分析的報告，直接拿就對了。
可是隨着業務發展，
大瑜發現，還需要有小紅書的需求，抖音的需求，於是針對每一個需求他又建立一個task，變成：
最後任務越來越多，越來越亂。於是直接分開吧。
第二輪優化
這個時候，我們就打開三個文件夾了，每個文件夾裏，完成不同的任務處理。
優點很明顯：很清晰直觀。
但是缺點也很明顯：如果研發任務需要需求分析的結果報告。
不好意思，默認是找不到的！如果需要用到文件，你要告訴他文件的位置才可以。
寫在後面的話
很多人有一個誤區：
文件夾越大，消耗token越多！
告訴你一個消耗token的真兇：上下文的長度。
要想token用的省：定期保留中間內容落盤，超過50%-70%的額度，就重啓一個新的task吧！
歷史文章列表：
Claude Code 很強，但為什麼我更建議普通人先學 CodeX？