真實世界的計費情境

每位自由工作者的計費生活都比乾淨的配置文件所顯示的更為混亂。客戶更換、合約續約、錯誤發生，有時你做了一些不想收費的工作。以下情境描述了真實的情況，以及 Vibes to Bucks 如何處理每一種情況。

情境 1 — 合約續約：同一客戶，新專案

誰： Anna，自由開發者，為客戶 Acme 工作於 github.com/acme/website。

發生了什麼： 自一月以來，Anna 一直將 AI 成本計入 Moneybird 專案「Acme Website Q1–Q2」。7 月 1 日，一份新的 6 個月合約開始生效。客戶的 Moneybird 專案更改為「Acme Website Q3–Q4」——可能有不同的時薪。儲存庫和分支保持不變。

Anna 的需求：

從 7 月 1 日起，所有新的 AI 成本同步到新專案。
已在 Moneybird 舊專案下的六個月時間條目保持不變。
今天的成本進入新專案。

沒有指導的風險： Anna 更改了她的計費規則並運行即時同步。擴充套件重新聚合了一月至六月的數據，發現新專案下沒有那些天的時間條目，於是在 Moneybird 中創建了 180 個重複條目——與舊專案下已存在的條目並存。

Vibes to Bucks 的處理方式： 當 Anna 編輯她的計費規則指向新專案時，擴充套件會詢問她歷史成本應如何處理。她選擇 「從今天開始應用」。過去的日子保持與舊專案的關聯。只有今天和未來的日子在新專案下同步。沒有重複，也不需要清理。

情境 2 — 客戶更換：將儲存庫移至不同客戶

誰： Ben，開發者，工作於 github.com/org/platform。

發生了什麼： Ben 最初將此儲存庫計入客戶 Alpha，Alpha 資助了研發階段。該平台現在已進入生產階段，客戶 Beta 是持續的客戶。Ben 需要重新映射儲存庫。

2a — 完全切換

Ben 的需求： 未來的成本進入客戶 Beta。已同步到客戶 Alpha 的過去條目保持不變。無需追溯。

Vibes to Bucks 的處理方式： Ben 將計費規則的聯絡人從 Alpha 更改為 Beta。擴充套件詢問歷史應如何處理。他選擇 「從今天開始應用」。Alpha 的歷史條目保留在 Moneybird 中。Beta 從今天開始接收條目。

2b — 完全追溯修正

Ben 的需求： Alpha 的計費是一個錯誤——從一開始就應該是 Beta。Ben 希望將所有內容重新同步到 Beta。他接受需要在 Moneybird 中手動清理 Alpha 的條目。

Vibes to Bucks 的處理方式： Ben 選擇 「應用於所有時間」。擴充套件警告他 Alpha 下的現有條目不會自動刪除——他需要在 Moneybird 中刪除這些條目。然後為 Beta 創建每個歷史日的條目。

2c — 僅同步缺口

Ben 的需求： Ben 在發現映射錯誤後兩週前停止了同步。他的帳本中有 14 天未同步的成本。他希望這 14 天進入 Beta，但已同步到 Alpha 的月份應保持不變。

Vibes to Bucks 的處理方式： Ben 選擇 「僅應用於未同步的日子」。擴充套件知道哪些日子已在 provider_posts 中有時間條目並跳過它們。只有 14 天未同步的日子在 Beta 下創建。

情境 3 — 專案拆分：將工作重新分配到子專案

誰： Clara，開發者，為客戶 Gamma 工作於一個 monorepo。

發生了什麼： Clara 一直將所有 AI 工作計入一個總括專案「General Development」。Gamma 現在希望按功能區域細分成本。Clara 創建了基於分支的計費規則：feature/auth/* → “Auth Module” 和 feature/billing/* → “Billing Module”。

3a — 僅向前拆分

Clara 的需求： 從今往後，成本路由到正確的子專案。已同步到「General Development」的過去成本保持不變。

Vibes to Bucks 的處理方式： 當 Clara 添加新的分支規則時，擴充套件會詢問每個規則的歷史。她為兩者選擇 「從今天開始應用」。「General Development」下的歷史條目不受影響。

3b — 歷史準確性

Clara 的需求： 她實際上希望將過去的成本追溯移動到正確的子專案。她接受需要在 Moneybird 中手動刪除舊的「General Development」條目。

Vibes to Bucks 的處理方式： Clara 為新規則選擇 「應用於所有時間」。擴充套件警告舊專案下的現有條目，並為每個子專案每天創建正確的條目。Clara 在 Moneybird 中清理舊條目。

情境 4 — 不可計費的禮貌性工作

誰： David，自由工作者，工作於客戶 Delta 的儲存庫。

發生了什麼： David 被拉入內部代碼審查和一些不屬於 Delta 範疇的實驗——但他在他們的儲存庫中保持 Cursor 開啟。他不想將接下來的 2 小時 AI 成本計入 Delta。

David 的需求：

切換 Delta 的計費規則到「不可計費」模式。狀態欄中有一個可見指示器確認規則不可計費。
AI 成本仍然在儀表板上跟蹤和可見——他想看看這些禮貌性工作的成本——但標記為不計費。
每小時一個提醒通知：「Delta 計費規則已不可計費 2 小時。仍在進行不可計費工作嗎？」
當他切換回可計費時，正常同步恢復。
不可計費的成本在儀表板上顯示於 Delta 下，但與可計費成本明顯區分開。

為何是每個映射，而非全局： David 可能在多任務處理。如果他切換到客戶 Beta 的儲存庫，而 Delta 是不可計費的，Beta 應該仍然正常計費。不可計費是一個每個客戶的禮貌性決定：「這個成本不是客戶要求的——我為他們做這個是出於禮貌。」

Vibes to Bucks 的處理方式： David 打開設置面板並將 Delta 的計費規則切換為不可計費。對話框詢問兩件事：不可計費應何時開始（現在，或回溯），以及何時結束。David 選擇 「從現在開始」 和 「今天結束」——計費明天自動恢復。狀態欄顯示 $4.23 today · Delta [unbillable till end of day]，當他在 Delta 的儲存庫中工作時。不計費的成本仍然同步到 Moneybird 作為非計費時間條目（在記錄中可見但不包括在客戶發票中）。儀表板顯示 Delta 的可計費和不可計費成本，明顯分開。

如果 David 預計禮貌性工作會持續更長時間，他可以選擇 「特定日期」（例如，不可計費直到星期五）或 「直到我手動恢復」，並設置提醒間隔（每 30 分鐘、1 小時、2 小時等），以免忘記重新開啟計費。

變體 — 追溯不可計費

David 的需求： 他在開始前忘記切換。他希望事後將過去 90 分鐘標記為不可計費。

Vibes to Bucks 的處理方式： David 打開設置面板，將 Delta 切換為不可計費，並在開始部分選擇 「回溯」，時間設為 90 分鐘前。從那時起的成本被標記為不可計費。如果今天的時間條目已同步到 Moneybird，擴充套件會重新計算並更新以反映減少的可計費金額。回溯僅限於今天——對於多日修正，Sync Ledger 提供撤銷和重新同步控制。

情境 5 — 撤銷錯誤同步

誰： Eve，自由工作者，改變了映射並立即運行即時同步。

發生了什麼： Eve 編輯了一個計費規則（更改了專案）並在未考慮後果的情況下運行即時同步。擴充套件在 Moneybird 中創建了 3 個月的新時間條目，與舊專案下的現有正確條目並存。

Eve 的需求：

查看剛剛同步的內容——顯示創建或更新了多少條目，在哪些日子，在哪個專案下的摘要。
回滾：擴充套件刪除錯誤創建的條目，或者明確告訴她需要手動清理哪些條目 ID。

Vibes to Bucks 的處理方式： 每次同步後，擴充套件顯示通知：「已同步到 Moneybird——創建 87，更新 2，跳過 14。」 點擊 「顯示詳情」 打開 Sync Ledger——一個專用視圖，顯示每個已同步和待處理的條目，可按客戶、專案和日期篩選。Eve 可以精確看到剛創建的條目，選擇錯誤的條目，然後點擊 「撤銷同步」。擴充套件從 Moneybird 中刪除這些條目，並將它們標記為待處理，以便在她修正規則後正確重新同步。

情境 6 — 臨時專案計費

誰： Frank，開發者，工作於 github.com/acme/api。

發生了什麼： Frank 通常計費到專案「API Maintenance」。在三月的兩週內，他參加了一個特別的衝刺，計費到「API v2 Migration」。衝刺結束後，他切換回來。

Frank 的需求：

在 3 月 10 日更改計費規則到「API v2 Migration」。
在 3 月 24 日更改回「API Maintenance」。
只有 3 月 10 日到 23 日的窗口同步到「API v2 Migration」。
3 月 10 日之前和 3 月 23 日之後的所有內容同步到「API Maintenance」。
無需在任何方向上追溯混亂。

Vibes to Bucks 的處理方式： Frank 每次更改計費規則時，他選擇 「從今天開始應用」。在 3 月 10 日，規則開始計費到「API v2 Migration」。在 3 月 24 日，它切換回「API Maintenance」。每個時期的條目保持在當時活躍的專案中。

情境 7 — 停止計費，保持追蹤

誰： Gina，自由工作者，正在結束與客戶 Eta 的合作。

發生了什麼： 合約結束了，但 Gina 仍然在 Eta 的儲存庫上進行小規模維護。她希望在她的儀表板上看到 AI 成本——以評估新合約是否值得——但她不想同步任何時間條目。

Gina 的需求：

將計費規則標記為永久不可計費（不是臨時切換——是一個持久設置）。
儀表板仍然顯示歸屬於客戶 Eta 的成本。
同步完全跳過此計費規則。
如果 Eta 帶著新合約回來，她將其切換回可計費，並且僅從那時起同步——不包括間隙期。

Vibes to Bucks 的處理方式： Gina 取消選中 Eta 的計費規則中的「可計費」。成本繼續被追蹤並顯示在儀表板上的 Eta 下，但不創建任何時間條目。當新的合約到來時，她重新啟用計費並選擇 「從今天開始應用」。不可計費的間隙保持不計費。

情境 8 — 提供商遷移

誰： Hugo，自由工作者，已同步到 Moneybird 6 個月。

發生了什麼： Hugo 的會計公司將他轉移到 Harvest。他在配置中更改 destination: harvest 並設置新的 Harvest 計費規則。

Hugo 的需求：

從今往後，同步到 Harvest。
Moneybird 的 6 個月條目保持不變。
不在 Harvest 中為歷史時期創建追溯條目。

Vibes to Bucks 的處理方式： 當 Hugo 切換計費提供商時，擴充套件檢測到 Harvest 沒有同步歷史。沒有指導的情況下，它會嘗試為每個歷史日創建條目。相反，出現相同的三選項對話框：「從今天開始全新開始」、「同步所有歷史」或「僅同步未同步的日子」。Hugo 選擇「從今天開始全新開始」。擴充套件設置遷移截止日期，因此同步引擎跳過今天之前的所有日子。只有今天和未來的日子創建 Harvest 條目。他的 Moneybird 條目保持不變。

情境 9 — 意外刪除規則

誰： Ivan，自由工作者，為客戶 Kappa 的儲存庫計費。

發生了什麼： Ivan 本想編輯他的計費規則以更改時薪，但卻意外刪除了它。他立即注意到並用正確的設置重新創建規則。

Ivan 的需求：

重新創建規則而不在 Moneybird 中造成數月的重複時間條目。
已同步的過去條目應保持不變。
計費應無縫繼續，就像什麼都沒發生過一樣。

沒有指導的風險： Ivan 創建了新規則。擴充套件看到一個有歷史成本數據的儲存庫，沒有匹配的計費規則歷史。天真的同步會將每個過去的日子視為「從未在此規則下同步過」，並為整個歷史創建條目。

Vibes to Bucks 的處理方式： 當 Ivan 為一個已在帳本中有歷史成本數據的儲存庫創建計費規則時，擴充套件識別到這一點並呈現相同的三選項對話框。Ivan 選擇 「從今天開始應用」——過去的條目保持原樣，計費從今天開始恢復。沒有重複，沒有間隙，沒有恐慌。

共通主題

以上每個情境都歸結為一個問題：當你更改計費規則時，過去應該怎麼處理？

Vibes to Bucks 從不為你做出這個決定。每次你編輯計費規則——更改客戶、專案、費率或可計費狀態時——擴充套件會要求你選擇：

選擇	它的作用
從今天開始應用	過去的日子保持現有的計費。只有今天和未來的日子使用新規則。
應用於所有時間	新規則追溯應用於帳本中的每一天。警告現有條目不會自動刪除。
僅應用於未同步的日子	已在計費提供商中有時間條目的日子不受影響。只有沒有現有條目的日子使用新規則。

每當計費規則更改會影響歷史成本的處理方式時，這個引導選擇會在清晰的對話框中出現。沒有驚喜，沒有靜默的追溯重新計費，沒有孤立的重複條目。