辽宁
不死心又试了一次，DeepSeek 1017终于让我死心了
DeepSeek-V4.1-Flash-1017（以下简称1017）的能力确实在线。这两天测试下来，至少在我自己的项目中，感觉已经有点GPT 6.1 Sol的水平了。
但是， 直接用官方API，这个价格实在有点扛不住。
昨天用DSH跑了一个模块重构，花了4.6元。虽然觉得贵，但考虑到涉及的代码量比较大、上下文也比较多，倒也勉强接受了。
今天还是不死心，决定再试一次。
这次特意选了个相对简单的任务：使用frontend-design这个Skill完善一个界面，顺便调整一处业务逻辑。
整个过程也比较常规，一轮主要开发，加上三轮微调。1017的表现依然不错，需求理解、界面调整和业务逻辑处理都比较到位，最终成果我也挺满意。
先看看DSH的使用统计。
这次任务累计执行了302步，发起303次API请求，消耗约8684万Token，缓存命中率高达99.7%。
看到这里，我还是有点吃惊。
这么一个界面调整，居然跑出了将近8700万Token？
当然，绝大多数都是缓存命中的Token，实际重新处理的内容远没有这么多。但缓存命中不等于免费，调用次数一多，上下文反复传递，费用照样会往上涨。
然后打开DeepSeek后台看了一眼，心里凉了半截。
5.2元！
昨天一个相对复杂的模块重构，花了4.6元。今天这个明显更简单的任务，反而花了5.2元。
两天加起来已经9.8元了。
说实话，按我平时使用Astra的体验，处理这种任务都不至于让我这么肉疼。当然，订阅额度和API按量计费不能直接比较，但这消耗确实超出了我的预期。
这简直太 梁子 了！
而且，DeepSeek这次发布1017的时候，还专门提到了降低使用成本。
我又去翻了一遍10月17日的官方更新日志。
官方说，新版本在提升性能的同时，还缩短了任务运行时间和输出长度，让用户能够以更低的成本、更快的速度完成任务。甚至特别提到针对DeepSeek Harness等框架进行了优化。
好家伙，看到这里我就更纳闷了。
官方说任务成本降低了，我怎么感觉账单反而越来越高了？
不过仔细分析，这里有两个问题。
首先，1017并没有降低API的Token单价，而是通过减少输出和运行时间来降低完成任务的总成本。这是两个概念。
其次，不同任务的Agent执行过程差异很大。即使任务看起来更简单，也不代表Token消耗一定更少。尤其像界面调整这种任务，模型需要反复阅读代码、修改、检查，多轮下来，费用可能比一次规模更大的重构还高。
还有一个容易忽略的因素，就是DeepSeek的峰谷计费。
昨天是周日，全天享受空闲时段半价。而今天是周一，属于正常工作日。
根据DeepSeek的官方价格说明，北京时间工作日9:00—12:00和14:00—18:00属于高峰时段，价格是空闲时段的两倍，其他时间依然享受半价。
今天这个任务正好跨越了午休时间。
截图里虽然分成了几个时段，但其实就是一个任务。中午正好卡在一个需要我确认的地方，于是先去吃饭、午休，回来以后继续，直到基本完成。
之前我还在想，难道DSH跟出租车一样，还有等待费？
现在看来，等待费倒是没有， 但工作时间的高峰价确实可能让我多花了钱。
当然，目前没有按照调用时间和Token明细逐项核算，所以也不能把今天比昨天贵的原因全部归结于峰谷计费。
只是这么一来，昨天4.6元、今天5.2元的差别，就没那么奇怪了。
不过，即使考虑峰谷价格，我还是觉得这个消耗偏高。毕竟1017宣传的是更高的任务效率，而在我这两天的实际使用中，省钱的感觉暂时还没找到。
到这里，任务其实还没有完全收尾。
不试了，直接把DSH切换到OpenCode Go套餐继续干吧。
否则照这个趋势，最后能不能突破10块钱，还真不好说。
好在DSH已经内置了OpenCode的接入支持，配置起来非常简单。只需要在模型提供商中选择OpenCode Go，然后填写自己的API Key即可。
配置完成后，在DSH的对话窗口中就可以选择OpenCode Go套餐里的DeepSeek V4.1 Flash模型了。
不过，这里还有一个让我比较纠结的问题。
直接使用DeepSeek官方API时，模型名称后面明确带有1017后缀。而OpenCode Go里面只显示DeepSeek V4.1 Flash，没有1017。
那么，OpenCode Go现在究竟路由到的是老版本，还是最新的1017？
目前还没有找到OpenCode Go对此的明确确认。GitHub上也有人专门提出了这个问题，要求OpenCode公开实际使用的模型版本，但暂时还没有得到明确答案。
这就有点难受了。
毕竟我就是冲着1017的能力来的，如果切换到Go套餐后又用回旧版本，那就有点得不偿失。
所以接下来准备继续使用DSH+OpenCode Go的组合，看看在实际项目中的表现是否有明显差别。
这两天测试下来，我对1017的能力是比较认可的。虽然还不能说它在所有方面都达到了Sol的水平，但至少在我的实际开发任务中，已经相当能打。
现在的问题已经不是它能不能干活，而是怎么才能用得起。
官方说的性能与成本优化，我相信在一些任务中确实能够体现出来。只是对于我这种需要多轮交互、反复修改代码的开发方式，实际费用依然有点高。
看来，Codex+10美元的OpenCode Go还得继续当主力。
毕竟代码是要天天写的，总不能每完成一个功能，都顺手把钱包重构一遍。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
