DeepSeek 1017让我彻底心灰，费用超出预期

经过一番不懈的尝试，我终于对DeepSeek 1017（以下简称1017）心灰意冷。这几天的测试让我意识到，尽管其能力相当强大，已让我感觉达到了GPT 6.1 Sol的水平，但通过官方API收费还是让我难以承受。昨天使用DSH进行了一次模块重构，花费了4.6元，虽然觉得不便宜，但考虑到需要处理的代码和上下文较多，我还是勉强接受了。今天，我试图再来一次，这次我特别选择了一个相对简单的任务：利用frontend-design这个技能优化一个界面，并顺便调整相关的业务逻辑。整个过程进行得比较顺利，主要通过一轮开发和三轮微调，1017依旧展现了不错的表现，能够理解需求，调整界面，并处理业务逻辑，最终成果也令我满意。

查看DSH的使用统计，这次任务共执行了302步，发起了303次API请求，消耗了约8684万Token，令人惊讶的是，缓存命中率达到99.7%。我感到有些震惊，原来一次简单的界面调整竟产生了近8700万Token。虽然绝大部分都是来自缓存，但频繁的调用仍然意味着费用在不断上升。打开DeepSeek后台查看账单，我心里凉了半截，今天的费用竟然是5.2元！相比昨日的复杂模块重构，今天的简单任务却花了更多。两天的总开销已达9.8元。说真的，依照我对Astra的使用经验，处理类似的任务绝不会让我如此心疼。虽然无法直接将订阅额度与按量计费进行比较，但这种消耗确实超出了我的预期，简直太离谱了！

更让人困惑的是，当DeepSeek发布1017时，官方还特别提到过降低使用成本。我又查看了一遍10月17日的官方更新日志，官方表示新版本在提高性能的同时，也缩短了任务运行时间和输出长度，以便用户以更低成本和更快的速度完成任务，甚至专门进行了针对DeepSeek Harness等框架的优化。看到这些，我不禁疑惑，官方若说任务成本下降，为什么我感受到的却是账单越加上涨？

经过仔细分析，发现了两个问题。首先，1017并未降低API的Token单价，而是通过缩短输出和运行时间来降低整体任务成本，这两者是不同的概念。其次，各种任务的Agent执行过程差异较大，尽管任务看似更简单，但也不意味着Token消耗必然减少。特别是像界面调整这样的任务，模型需要反复读取、修改和检查代码，多轮的处理下来，费用可能甚至超过一次大型重构的成本。

此外，DeepSeek的峰谷计费也是一个容易被忽视的因素。昨天是周日，充分享受了空闲时段的半价，而今天是正常工作日，正值高峰时段，费用自然会上涨。今天的任务正好跨越了午休时间，虽然分成了几个时段，但实际上是同一个任务。在处理中间，有个需要我确认的地方，我选择先去打餐，等午休回来继续，因此就产生了额外的花费。之前我还在想，是否DSH存在等待费，看来并不是，但高峰时段的定价确实让我多花了钱。

当然，由于我没有逐项核算调用时间和Token消耗，因此不能完全将今天高于昨天的花费归结于峰谷计费。不过，昨天的4.6元和今天的5.2元的差别也不再显得那么奇怪。但即便考虑到峰谷价格，我还是觉得这种消耗偏高。毕竟1017的宣传是提升任务效率，而在我这几天的使用中，节省费用的感觉至今未能找到。

至此，任务还未完全结束。决定不再尝试，直接把DSH切换到OpenCode Go套餐继续使用。否则，按照现态，最后是否能突破10块钱还是未知数。好在DSH已经内置了OpenCode接入支持，配置起来非常方便。只需在模型提供商中选择OpenCode Go，填写API Key即可，完成配置后，就能在DSH的对话窗口选择Go套餐中的DeepSeek V4.1 Flash模型。但令我忧虑的是，直接使用DeepSeek官方API时，模型名称后面明明确带有1017后缀，而在OpenCode Go中只显示DeepSeek V4.1 Flash，没有1017的标识。这让我担心，OpenCode Go到底是连接到老版本，还是最新的1017。至今还没能找到OpenCode明确的确认，GitHub上也有人问这个问题，但还未得到答复。这让我感到不安，因为我使用的是1017的能力，如果在转向Go套餐后用回旧版本，那就得不偿失了。因此，我打算继续使用DSH和OpenCode的组合。