实际计费场景

每个自由职业者的账单生活都比一个干净的配置文件要复杂得多。客户变动、合同续签、错误发生，有时你做了一些不想收费的工作。这些场景描述了真实情况，以及 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 修改了她的账单规则并运行了 Sync Now。扩展重新聚合了一月至六月的数据，发现新项目下没有这些天的时间条目，于是在 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，自由职业者，改变了映射并立即运行了 Sync Now。

发生了什么: Eve 编辑了账单规则（更改了项目）并在没有考虑后果的情况下运行了 Sync Now。扩展在 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。
• 6个月的 Moneybird 条目保持不变。
• 在历史期间不在 Harvest 中创建追溯条目。

Vibes to Bucks 的处理方式: 当 Hugo 切换账单提供商时，扩展检测到 Harvest 没有同步历史记录。没有指导，它会尝试为每个历史日子创建条目。相反，同样的三个选项对话框出现：“从今天开始新”、“同步所有历史”或“仅同步未同步的日子”。Hugo 选择“从今天开始新”。扩展设置迁移截止日期，以便同步引擎跳过今天之前的所有日子。只有今天和未来的日子创建 Harvest 条目。他的 Moneybird 条目保持不变。

场景 9 — 意外删除规则

人物: Ivan，自由职业者，为客户 Kappa 的代码库计费。

发生了什么: Ivan 本想编辑他的账单规则以更改小时费率，但不小心删除了它。他立即注意到并用正确的设置重新创建了规则。

Ivan 的需求:

• 重新创建规则而不在 Moneybird 中造成数月的重复时间条目。
• 已同步的过去条目应保持不变。
• 计费应无缝继续，就像什么都没发生过一样。

没有指导的风险: Ivan 创建了新规则。扩展看到一个有历史成本数据的代码库，但没有匹配的账单规则历史。一个天真的同步会将每个过去的日子视为“从未在此规则下同步过”，并为整个历史创建条目。

Vibes to Bucks 的处理方式: 当 Ivan 为一个已经在账本中有历史成本数据的代码库创建账单规则时，扩展识别到这一点并呈现相同的三个选项对话框。Ivan 选择**“从今天开始应用”**——过去的条目保持原样，计费从今天开始继续。没有重复，没有间隙，没有恐慌。

共同的主题

以上每个场景都归结为一个问题：当你更改账单规则时，过去应该如何处理？

Vibes to Bucks 从不为你做这个决定。每次你编辑账单规则——更改客户、项目、费率或计费状态——扩展都会要求你选择：

每当账单规则更改会影响历史成本的处理时，这个引导选择都会在清晰的对话框中出现。没有惊喜，没有静默的追溯重新计费，没有孤立的重复条目。