本文在草梅友仁的博客发布和更新，并在多个平台同步发布。如有更新，以博客上的版本为准。您也可以通过文末的 原文链接 查看最新版本。

前言

欢迎来到草梅周报！这是一个由草梅友仁基于 AI 整理的周报，旨在为您提供最新的博客更新、GitHub 动态、个人动态和其他周刊文章推荐等内容。

开源动态

本周墨梅博客的开发依旧在稳步进行中。

您可以前往 Demo 站试用：https://demo.momei.app/

您可以通过邮箱 admin@example.com，密码momei123456登录演示用管理员账号。

或前往官网注册：https://momei.app/

也可以前往文档站来了解项目整体规划和未来开发路线图：https://docs.momei.app/

当前墨梅博客已经正式发布了 1.16.0 版本，以下是新页面和新功能的一些截图。

添加创作者统计功能，现在可以在后台看到单个创作者的统计数据。

新增远程仓库同步功能，现在可以同步博客到指定的 GitHub/Gitee 仓库（使用 Hexo 风格的 markdown 文件）。

新增了墨梅博客内容资产化增强包的联系页面。现在可前往增强包页面下方加入候补名单，当增强包开发完成时，会通过邮件等方式在第一时间通知你。

更多功能和页面可以前往官网体验，也可前往之前的博客查看截图。

欢迎各位用户体验。并提出意见和建议。

接下来的话还会继续按照路线图和待办进行开发功能，敬请期待。

当然，目前墨梅博客还有很多需要打磨的细节，功能上也还不完善，如有任何意见和建议，都可以在项目的 GitHub issues 中提出。

如果你也对墨梅博客感兴趣，欢迎参与开发和测试。

AI Coding Plan 普遍开始限流

最近在使用 GitHub Copilot 的过程中开始频繁遇到了 session limit 和 weekly limit，这意味着即便付费订阅了 Copilot Pro 也免不了被限流。

但唯一的问题是这个限制没有考虑额外付费的用户，之前超量的时候都是直接花钱买次数，比如说 3 月份就额外买了 10 美元的量，最后的用量甚至来到了 200%（额外多出快 100%的用量）。

而现在，额外付费买的这部分用量也会被计入限流中，导致目前会出现一个离谱的情况，那就是套餐内的请求量也有可能会用不完（要是之前的话，请求用量估计已经来到了 80%以上）。

虽然说下个月起，GitHub Copilot 就要转变为按照实际使用量计算了（参考：《GitHub Copilot 正在转向基于使用量的计费》），不过在这最后一个过渡时期，能不能让用户的体验稍微好一点呢？

当然，Coding Plan 开始限流并不是 GitHub Copilot 一家的问题，无论是国外的 Claude、OpenAI、Gemini，还是国内的 GLM、MiniMax 等 AI 大模型厂商，都无一例外的开始对 Coding Plan 进行限流。

其中还不乏把用量限制的很低的厂商，甚至还不惜擅自修改套餐内容，得罪用户，也要进行限流。

比如说 GLM 就直接把老套餐废了，强行切换到新套餐。（参考：《老套餐迁移与补偿说明》）

而阿里云这边更是直接废掉了 Coding Plan Lite，直接没法续费和升级。（参考：《Coding Plan Lite 基础套餐停止续费和升级通知》）

因此大家在对这些 AI 厂商生气之前，也需要额外思考一个新的问题，那就是：为什么这些 AI 厂商都不约而同的对 Coding Plan 进行了限流？

原因其实比大家想的要简单，那就是提供 AI 大模型的订阅服务，它实际上是一个重资产的行为。

那么重的是哪一块资产呢？实际上就是算力，或者说 GPU。而这一块它的边际递减效应其实是不太明显的，简单来说就是来多少用户就真的得提供多少算力。而传统的互联网行业他的边际递减效应非常明显，为第 1 个用户提供服务需要较多资源，而当用户量大起来的时候，为第 1 万个用户提供服务，所需要增加的资源就并不多。

但在 Coding Plan 中，为第一个用户，和为第 1 万个用户所需要提供的算力是基本差不多的，没办法减少太多成本。

更何况，那些用量特别大的用户，是真的可以把套餐用到上限的，这就导致订阅套餐的用户越多，这样的用户越多，而对算力的要求就越高，因此成本会居高不下。

而这也就是越来越多的 AI 厂商开始压缩套餐使用量的原因。

与此类似的还有另外一个问题。最近大家也已经听说了一些关于之前很火的视频生成大模型 seedance2.0 降智的问题。

虽然说现在还是可以依靠一些付费充值的手段来，获得一些满血版的使用，但和刚开始相比确实没那么惊艳了。

这实际上就是 AI 大模型面临的最大的一个难题：一个新的大模型刚开始出现的时候，算力比较充裕，因此用户体验比较良好；而当新的用户被吸引进来之后，算力开始紧张，用户体验开始下降，然后用户开始流失；直到下一个大模型出现，重复上述循环。

可以说无论是文本大模型，还是图片生成大模型，或者视频生成大模型，都存在着上述循环。

也因此，那种靠堆算力来取得较高性能的 AI 大模型其实是不可持续的，原因是通过对算力获得的增长是差不多线性的。而人们因此产生新的需求，他反而是指数级增长的，所以 AI 大模型的性能增加程度是无论如何都不太可能追得上新增加的需求的数量的。

所以虽然 DeepSeek 自己评价 DeepSeek-V4-Pro 的结果是仍与 Opus 4.6 思考模式存在一定差距，但我仍然更看好 DeepSeek 的模式。

因为 DeepSeek 一直在尝试做出性能更好，而算力需求更低的 AI 大模型，我认为这才是 AI 大模型未来。

（如果未来能出个物美价廉的 DeepSeek-V4-Pro 套餐就更好了）

DeepSeek-V4 的使用体验

这段时间也是亲自高强度的使用 DeepSeek-V4-Pro 和 DeepSeek-V4-Flash 进行编程，累计消耗约 5.5 亿 token，花费约 45 元，折合起来差不多每 1 元可使用 1200 万 token。

当然其中也包含了一下部分的 V4-Flash，不过因为用量太少就合并进去计算了。

而能够这么便宜的原因就是因为 DeepSeek 神秘的缓存机制，导致缓存命中率居高不下，在编程这个上下文容易高度重复的场景下，是非常优秀的节约成本的方案。

当然也必须要承认的一点就是，DeepSeek-V4-Pro 跟目前最顶尖的那些 AI 大模型，比如说 GPT5.5、Claude Opus 4.6 等还是有比较大的差距的，这一点也就是我在实际使用过后发现 DeepSeek-V4-Pro 的编码成果当中存在不小的疏漏后发现的。所以想靠 DeepSeek-V4-Pro 就直接追平顶尖 AI 大模型还是不大可能的。

但我还是比较看好的 DeepSeek 的，毕竟就这个价格，还要啥自行车呢？

隔壁的 Anthropic 卖的 Claude API 得有多贵？Opus 4.7 输入 5 美元（约 34 人民币）每百万 token，输出更是来到了 25 美元（约 170 人民币）每百万 token。

套餐方面，也因为动不动就封号加上 KYC 验证加强，导致用起来越来越麻烦，成本也迅速上升。

所以，虽然理论上说应该尽可能使用最强的 AI 模型来最大化工作效率，从而创造更多的收益来抵消开支上涨，但实际上没有人能不考虑成本来做事。

正所谓贵有贵的玩法，穷也有穷的玩法，更重要的是结合自己的实际情况，采用性价比最高的方案。

GitHub Release

rss-impact-server

v1.18.2 - 2026-05-02 20:28:53

摘要:

v1.18.2 版本发布摘要

测试: 为缓存服务添加单元测试。
Bug 修复: 更新依赖项并优化缓存管理实现。

momei

v1.16.0 - 2026-05-09 20:42:55

摘要:

1.16.0 (2026-05-09)

✨ 新功能

admin:

v1.15.0 - 2026-04-25 20:36:49

摘要:
v1.15.0 版本更新内容摘要：

新功能：

管理后台 AI 模块新增任务详情加载功能
API 增强了类型安全与错误处理
评论系统新增翻译功能及跨语言提示
友链模块增加元信息接口的本地化支持，并添加友链管理功能及国际化支持
代码治理方面：完成首轮存量代码注释治理并固化 JSDoc 模板；添加 ESLint/类型债治理文档及相关配置；添加注释漂移治理文档
新增 Hexo 风格文章仓库同步能力，以及 Hexo 仓库同步功能
国际化方面：增强审计功能；完善 admin-posts 模块翻译；更新多语言支持和管理界面文本
Markdown 编辑器添加编辑器功能及代码复制支持
分页查询增加安全解析功能
文章列表查询添加语言回退过滤器
SEO 方面增加页面 SEO 相关功能，并为标签页面添加结构化数据和 SEO 优化
其他：新增评论区 AI 翻译功能；统一字符串列表解析逻辑

Bug 修复：

文章管理模块添加管理功能及国际化支持
邮件模板添加运行时字段支持
外部 Feed 面板优化测试用例结构
外部 Feed 处理无标题项的情况
完成 ESLint/类型债第二轮收紧
国际化方面：优化仓库同步信息本地化文本；添加用户协议管理功能的国际化支持
设置模块优化字段解析逻辑，添加外部源编辑器功能

代码重构：

AI 模块统一去除末尾斜杠的处理逻辑
ASR 模块使用 toWebSocketBuffer 函数发送数据
数据库增加就绪检查功能
治理方面将 Hexo 仓库同步重构为远程仓库同步
国际化重构动态键处理逻辑
设置 API 增强类型处理逻辑
第三方设置优化外部源设置模型绑定
其他：优化效果挂载条件

picgo-plugin-optimization

v1.1.1 - 2026-05-10 00:30:35

摘要:
版本 1.1.1 (2026-05-09)：

修复：tsdown 依赖项配置重构。
重构：tsdown 的 neverBundle 依赖项修改，新增 picgo 和 axios。

其他博客或周刊推荐

总结

本周的更新和动态如上所示。感谢您的阅读！
您可以通过以下方式订阅草梅周报的更新：

博客：草梅友仁的博客
墨梅博客：墨梅博客
RSS：草梅周报
公众号：草梅友仁的后花园
邮箱订阅：草梅友仁的博客订阅

往期回顾

墨梅博客 1.11.0 发布与数据库用量超支教训 | 2026 年第 13 周草梅周报 - 2026-03-29 23:06:55
墨梅博客 1.10.0 发布与 AI 编程工作流优化 | 2026 年第 12 周草梅周报 - 2026-03-22 22:51:32
墨梅博客 1.9.0 发布与 LeanCloud 停服应对 | 2026 年第 11 周草梅周报 - 2026-03-15 23:18:42

本文作者：草梅友仁
本文地址： https://blog.cmyr.ltd/archives/2026-19-caomei-weekly-ai-programming-throttling-deepseek-v4-experience.html
版权声明：本文采用 CC BY-NC-SA 4.0 协议进行分发，转载请注明出处！

草梅友仁的博客

AI 编程限流 DeepSeek-V4 体验墨梅博客 | 2026 年第 19 周草梅周报

前言