最新

随着编码助手最近取得的巨大进步，我一直在思考 AI 驱动的自动补全是否仍然是开发者工作流程的重要组成部分。 我个人从未养成过度依赖它的习惯。当我开始接触到像样的 AI 自动补全工具时，像 Cline 和 Augment 这样的工具已经存在了，所以我最终更多地依赖于助手。 这让我很好奇其他人现在是如何使用它的。 你还在使用 Cursor Tab、Copilot 或类似的工具吗？ 如果你也使用编码助手，你是否发现自己较少使用 AI 自动补全，还是两者相辅相成？

楼主在此：这个项目源于一种担忧/偏执，即人工智能提供商在服务器负载过高时会限制其模型的性能。因此，我着手通过数学建模和研究来解决这个问题，以了解到底发生了什么，而我的发现令人相当惊讶。 这个想法似乎很自然：随着数据中心的需求在一天中暂时增加，限制模型的性能（无论是使用量化版本、减小上下文窗口还是将模型降级到更小的版本）似乎很有吸引力，因为模型原则上消耗的电力更少。问题在于，这可能会产生相反的效果：当用户试图解决一个问题时，如果人工智能给出了一个糟糕的答案，用户很可能会反复提问。从人工智能提供商的角度来看，这看起来很矛盾：限制到较低的模型实际上会增加其数据中心的更多需求。 对于代理工作流来说，这个问题甚至更糟，因为它们更有可能产生反复提问的风暴，这也许可以解释用户经历的宕机和感觉模型性能下降的传闻。 模型：我主要使用了排队论的论证，解决了具有异构用户的AI集群的最优动态规划调度服务问题。 见解：行业标准的做法是在用户数量超过某个阈值时限制系统性能，而这实际上是导致问题的原因。最优规则意味着要区分那些不太会感受到性能下降的用户和那些对性能下降非常敏感的用户。 局限性：可视化和论文示例只是一个玩具示例，用于说明问题。只有提供商拥有足够的数据来正确校准这些实例。 技术细节：可视化部分大约有100行 Flask 代码加上 JavaScript 前端（由 LLM 辅助，其真实性基于论文的原始数值示例）。 包含证明/理论的论文：https://arxiv.org/abs/2608.23986

我想分享 fake-bpy-module，这是一个虚假的 Blender Python API 存根集合，旨在为 VSCode 等外部 IDE 提供代码自动补全和类型提示功能。 我维护这个开源项目已有 8 年多，涵盖了从 Blender 2.78 到 5.2+ 的 Blender 活动生态系统。 -- Blender Python 开发的痛点 -- Blender 不会在其内置文本编辑器之外将 Python API (bpy) 作为标准的 Python 文件暴露。 这使得在外部 IDE 中进行插件开发变得繁琐且容易出现类型错误。 -- 解决方案及工作原理 -- 它不依赖于通常无法处理 Blender 动态环境中的边缘情况的标准 inspect 模块。 fake-bpy-module 解析官方 Blender Python API 文档以生成 .pyi 存根文件。 当然，文档解析本身也存在挑战。 有些 API 没有文档，有些则不能直接使用（例如 bpy_prop_collection 类）。 为了解决这个问题，生成器在存根生成阶段会内部转换和修补类型，以确保严格的兼容性。 -- 可用性及每日 CI/CD -- 这些存根可通过 PyPI 获取（例如 pip install fake-bpy-module-5.2），并支持多种 Blender 版本。 基于最新 Blender 代码的最新存根也可用（pip install fake-bpy-module）。 为了实现这一点，我们定制的 CI/CD 系统每天都会从最新源代码构建 Blender 二进制文件。 -- 子项目：fake-bge-module -- UPBGE 是一个基于 Blender 的开源游戏引擎分支。 我还为 UPBGE Python API (bge) 创建了一个专门的子项目 fake-bge-module。 https://github.com/nutti/fake-bge-module 我很乐意听取您对这些工具的反馈！