最新

我一直在琢磨一个我称之为 CCCP 的想法——上下文感知可组合压缩协议。 大多数压缩格式将这个过程视为一个黑箱：你输入字节，输出字节。我希望有一个可编程和可组合的格式，能够适应不同的领域——甚至可以由不同的供应商进行定制。 到目前为止，CCCP 具有一些有趣的特性： - 可组合：可以组合多个查找表（LUT）和编码阶段。 - 上下文感知：解码过程由显式元数据指导，而不仅仅是原始字节流。 - 可回溯的中间表示：中间表示可以在最终的二进制压缩之前重建原始逻辑。 - 可编程：供应商可以插入自己的 LUT、编码器和解码器。 这仍然处于非常早期和实验阶段。如果有人见过类似的方法，或者在实际使用中可能出现的问题，我非常想听听。 代码库： - [https://github.com/brucekaushik/cccp](https://github.com/brucekaushik/cccp) - [https://github.com/brucekaushik/cccp-python-poc](https://github.com/brucekaushik/cccp-python-poc)

你好，我需要一些关于适合程序员的最佳分体式键盘的推荐，能够让我打字更快。你对这些或其他的键盘有什么看法吗？如果有带轨迹球来控制光标的键盘（不是IDE哦，哈哈）那就更理想了。 <p>https://www.kickstarter.com/projects/naya-create/naya-create</p> <p>https://www.kickstarter.com/projects/keykrush/keykrush-orca-split-ergonomic-keyboard</p> <p>https://www.kickstarter.com/projects/uniboard/uniboard-the-ergonomic-ai-keyboard-that-reimagines-input</p>

来自艾哈迈达巴德市的文字。 这段文字源于我在2024年与艾哈迈达巴德的设计师和教育者们的一些对话。 印度的设计历史有点像一本被遗忘的图书——有趣且潜在有价值，但在你真正需要的时候却 inexplicably 消失在书架上。尽管在独立后的历史中，传统与现代以奇妙的方式交融，但几乎没有人想到把这些写下来。我怀疑这是因为设计师天生忙于设计事物，以至于没有时间停下来写作。 上周，我偶然发现了一个关于被遗忘的科技与设计历史中最奇特且令人愉快的故事：苹果的Newton在印度。没错，就是Newton——1980年代iPhone和iPad的前身，曾承诺未来，却跌跌撞撞地回到了过去。我在艾哈迈达巴德遇到的一位参与了这一传奇故事的人告诉我，苹果在绝望的最后一搏中决定将Newton引入印度。想法是什么呢？把它卖给政府。你知道的，当你的尖端科技产品濒临死亡时，通常会这样做。 计划很简单：苹果将Newton宣传为社会发展的革命性工具，田野工作者可以用它来收集数据。因为政府喜欢大宗购买东西（尤其是听起来有用的东西），这可能会拯救Newton。最有趣的是，他们甚至在拉贾斯坦的农村进行了研究，结果让所有人惊讶的是，人们实际上喜欢并理解它。苹果产品的粘性让田野工作者们爱不释手。想象一下，在沙漠中，有人悠闲地用一个看起来像是星际迷航中的设备收集土壤数据。 一年里，一切进展顺利。然后，按照苹果的风格，他们突然中止了这个项目。Newton在这里的计划被搁置了。 当然，这让我想起了另一个古怪的设计/科技历史：Simputer，一个在1990年代于班加罗尔设计的手持设备。如果说Newton是古怪的姑姑，那么Simputer就是疯狂科学家的表亲——另一个由印度科技人员进行的聪明但大多被遗忘的尝试，试图重塑未来，但并没有成功。这个设备甚至配备了加速度计。没错，你没听错——在90年代就有加速度计！为了演示它，他们制作了一个滚珠迷宫游戏，如果Simputer能存活下来，可能会比你那部可靠的诺基亚上的贪吃蛇更让人上瘾。但可惜的是，像所有美好的事物一样，它在我们能尽情享受倾斜LCD屏幕的乐趣之前就消失了。 让我感到不安的是：在尘封的角落里，还有许多这样的故事在等待被讲述。然而，随着原始讲述者的年纪渐长（有些人也已离世），我们正在以比“请备份你的硬盘”更快的速度失去这些故事。 历史在我们指间流逝，我不禁想到，在这一堆被遗忘的设备和被抛弃的梦想中，或许有一本手册，教我们如何修复这一切。它可能被归档在“我们最终会处理的事情”下。

这对您有什么帮助 Agentic Sync 是一个原型演示任务管理系统，专为开发人员和人工智能代理有效协作而设计。这不仅仅是另一个待办事项应用程序——它是一个复杂的“搞定事情”（GTD）实现，内置了人工智能代理集成。 核心价值主张 对于开发人员： - 具有即时、社交媒体般的用户界面，乐观的更新使任务管理变得轻松自如 - 完整的本地部署——通过 Tauri 编译为本地桌面应用程序，并使用您自己的数据库 - 人工智能代理直接通信——代码代理可以以编程方式创建、更新和完成任务 - 生产级的 GTD 工作流程——处理复杂的任务状态、依赖关系和审批流程 - 零外部依赖——完全在您的基础设施上运行 对于人工智能代理： - 直接任务创建——代理可以使用包含的客户端在没有人工干预的情况下记录任务 - 状态管理——代理在任务完成时将其标记为“待审核”，需要人工审批 - 丰富的任务上下文——支持需求、技术计划、验证步骤和依赖关系 - 项目组织——自动分类和计划链接 实时演示 通过用户友好的界面增强人工智能代理的沟通 观看 Loom 上的演示 [https://www.loom.com/share/121fb242c0ba4c0c856abb31733342bb](https://www.loom.com/share/121fb242c0ba4c0c856abb31733342bb)

我想分享一个我在阿里云上遇到的令人担忧的案例，并询问是否有人遇到过类似的问题。 我在一个大约3200行代码的项目中测试了他们的Qwen LLM API（代码补全 + 聊天）。在2小时内，他们的系统声称我消耗了1000万个令牌。 为了让大家更好地理解这个情况： 即使将整个3200行代码重复作为上下文发送（每次调用最多约15万个令牌），也需要大约67次调用才能达到1000万个令牌。 我的日志显示的请求量远远没有达到这个水平。 然而，他们的账单立即扣除了约4.19美元，并留下了一个“待处理”的7.18美元未付款项。 当我向支持团队提出这个问题时，他们的回应是： “这可能是因为像VSCode这样的插件在长上下文中自动补全”或者“每次调用都携带历史上下文，因此令牌消耗得更快。” 这个解释连基本的合理性检查都无法通过： 携带上下文并不会神奇地将使用量乘以100倍。 我使用过的任何LLM API（OpenAI、Anthropic、Mistral、Groq）都没有出现令牌消耗与实际使用如此脱节的情况。 将责任归咎于VSCode插件是一种推卸责任，而不是根本原因分析。 他们没有承担责任，而是试图用200美元的优惠券来让我沉默，而这些优惠券仅限于阿里云使用。我拒绝了。此后，我要求： 退还他们已经扣除的4.19美元。 清除那张虚假的7.18美元“未付款”账单。 删除我的账户并确认我的代码/日志被删除（出于隐私考虑）。 他们拒绝提供（2）和（3）。 这引发了两个更大的问题： 信任：如果他们的账单如此不透明，任何开发者如何能够安全地大规模使用他们的API？ 隐私：如果他们乐于对客户的令牌使用进行误导，那么他们在后台对上传的代码和提示做了什么？ 我已经开始在各个平台（Reddit、LinkedIn）上记录和发布证据。下一步：联系记者。 是否还有其他人遇到过阿里云的类似账单或支持失败？ 我很想听听那些详细测试过他们API账单的工程师的意见。 —— 警告开发者：在使用阿里云进行AI工作负载时要极其谨慎。 不透明的账单 + 无能的支持 = 危险的组合。