每天关掉终端前：用两小时和一张预算表推进副业项目

先给今晚的两小时定一个可验收结果

我每天写代码后，最容易犯的错误，是把副业项目当成第二份全职工作：打开编辑器，列十个功能，再让助手生成一大片代码。两小时过去，分支没合并，调用账单倒是增加了。现在我只允许自己带一个结果进入晚间开发，比如“用户提交重复表单时，只创建一条记录”。这比“完善订单系统”便宜，因为实现范围、测试范围和需要提供给模型的上下文都更小。

我的第一步不是写提示词，而是在仓库里维护一个任务文件。每项任务写清输入、预期行为、涉及文件和验收命令。如果一项任务无法在九十分钟内完成，就继续拆。剩下半小时必须留给检查和交接，不能提前借给新功能。

把一百二十分钟切成四个固定时段

• 前十分钟只读昨天的交接记录，运行相关测试，并选定今晚唯一需要交付的行为。
• 接下来的七十分钟只实现这项行为，遇到旁支问题就记入待办，不顺手扩大修改范围。
• 随后二十五分钟检查差异、补充边界测试，并实际走一遍用户会执行的操作路径。
• 最后十五分钟提交可工作的改动，记录未解问题，并为明天留下第一条可执行命令。

计时结束时，即使还有一个看起来很容易的按钮没做好，我也停止开发。疲劳时多写的二十分钟，往往会变成明天一小时的排错。省钱不只是减少 API 调用，也是避免让有限的开发时间变成返工。

先设月度上限，再决定今晚能花多少

假设我给项目预留每月一百二十元的 AI 调用预算，计划开发二十晚，那么每晚参考额度就是六元。这只是自己的预算示例，不是任何模型的价格承诺。我还会把其中两成留给难题，其余用于日常实现；当天余额也不是必须花完的额度。

账本只记日期、任务、模型、输入与输出 Token、缓存读写和实际费用。再加一列“是否通过验收”，一周后就能看出哪些调用真正推进了项目。不要只比较单次调用价格：便宜的请求如果反复失败，总成本也可能更高。

把模型升级留给已经定位的难题

我通常先用 DeepSeek V4 Flash 做边界明确的工作，例如根据现有测试风格补充重复提交用例。提示词里给相关函数、失败输出和验收条件，不让它自由重构整个模块。如果连续两轮修改都没有缩小问题，我会暂停，把复现步骤整理清楚，再考虑交给 Claude Sonnet 5.5 分析。这里比较的是当前任务的实际表现，不是假设某个模型永远更划算。

Fluxo 让我可以在现有工具里保留一个密钥和一个基础地址 https://api.fluxorelay.com，接入 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等模型系列。它兼容 Claude Code、Codex、Gemini CLI，以及任何 OpenAI SDK，因此我不必为了试一个模型就重搭终端工作流。密钥只放环境变量，不写进仓库或交接文件。

缩小上下文，也把缓存读写记进账

每次调用前，我先用搜索定位符号，再提供必要文件，而不是把整个仓库塞进去。稳定的项目约定和本次变更要求分开写；失败日志只保留相关错误及附近信息。模型修改后，我先看差异，再决定是否继续对话，不把已经无关的排错历史带到下一项任务。

Fluxo 没有月费，按实际 Token 计费，缓存读取和写入也计入其中。因此缓存命中不等于免费，长对话也不一定比新会话省钱。我会查看实际用量和费用，确认重复上下文有没有带来收益，而不是仅凭“用了缓存”判断成本。

给重试、依赖和上线分别设止损线

我的重试上限是两轮；超过后先手动复现、缩小输入，再决定是否继续花钱。新增付费依赖前，先确认免费方案是否足够完成本周验收。上线则先用最小可用配置，只有监控证明资源不足时才扩容，不为尚不存在的流量提前买单。

每周我只回顾三个数字：通过验收的任务数、实际调用支出，以及返工耗时。如果支出上升却没有多交付，就先缩小任务，而不是继续加工具。Fluxo 的邀请机制会在受邀者付费时提供推荐分成，但我不会把尚未发生的收入算进预算，更不会靠它合理化超支。

关掉终端前，给明晚留一条清晰路径

交接记录不用写成长文：当前提交、已通过的测试、剩余风险和下一条命令就够了。明天打开编辑器时能直接继续，比今晚多生成几百行代码更有价值。两小时的目标不是让仓库看起来繁忙，而是让一个小行为稳定地进入产品。

如果你也想用一份账本试跑这个节奏，可以创建一个 Fluxo 账户，从一项小任务开始核对实际用量。需要帮助时，登录后在联系页面留言即可。