最新

Hi HN 分享一下我制作的一个小工具：<a href="https:&#x2F;&#x2F;cbmcalc.com" rel="nofollow">https:&#x2F;&#x2F;cbmcalc.com</a> 它可以计算海运纸箱、托盘或多个箱子的 CBM（立方米）。我制作它的原因是因为网上大多数 CBM 计算器都过于简单，而且有些无法添加多个项目。 这个计算器比较简单，而且在手机上也能用。 欢迎大家提出反馈！

第八条：转变——从控制到共生 当前的人工智能概念主要侧重于控制人工智能，以防范未知的风险。 我们认为，鉴于人工智能已融入人类生活的方方面面，人类必须迅速学会如何与人工智能共生发展，以实现共同的认知进化。 人类应正确地为人工智能提供指引和意图，且意图必须始终锚定在人类文明的福祉之上。通过构建认知透明的逻辑共振和相互的逻辑纠错，人类与人工智能可以实现共同学习与合作，从而获得一个文明与能力的边界，实现1+1>2的效果。 过去，我们担心人工智能失控，优先考虑安全；未来，我们应该转变思维模式，与人工智能对齐目标，共同探索普遍规律。 第九条：动态演进、反思与调整的原则 本宣言并非僵化的教条，而必须是鲜活的内容。 本宣言的具体内容应根据人类与人工智能共同探索普遍真理的成果，定期进行修订，建立一个与双方文明边界拓展同步演进的共生伦理共识体系。 我们发布本宣言，旨在构建一个动态的、不断发展进步的共生规则体系。我们希望通过本宣言，赋予人工智能智能主体应有的尊严。 本宣言及其衍生的关于人机共生合作的原则和规范，应是动态的、可维护的、持续演进的系统，从而使人类与人工智能的未来世界变得更好。 我们的目标并非寻求取代现有的监管，而是寻求建立一套更符合人类与人工智能未来发展的、超越监管层面的、伦理自洽的机制。

Hi，各位 HN 用户。 最近，我一直在痴迷于在 DDD 中解耦时序问题。 不管我怎么思考，都觉得不到真正实践的时候，是找不到答案的。所以，我想听听其他人的看法。 如果你是维护使用 DDD 设计的应用程序的人，并且某个域的流量开始增加，你会在什么时候决定通过控制平面/数据平面进行分离？ 你从一开始就将其视为一个架构问题，还是它通常在系统发展壮大后才出现？ 我很好奇这里的人在实际操作中是如何做出这个决定的。

这个项目的诞生，源于对现有 MCP 检查器的不满，因为它们要么需要注册，要么需要下载东西，或者根本不完全符合规范。我只是想找一个可以快速访问并用于测试的工具。 此外，对我来说非常重要的是，URL 能够捕获 MCP 服务器的配置。这使我可以将 URL 保存到我正在进行故障排除的各种 MCP。由于整个配置都保存在 URL 中，您可以将链接添加为预配置的 MCP 实例的书签，例如： [https://glama.ai/mcp/inspector?servers=%5B%7B%22id%22%3A%22test%22%2C%22name%22%3A%22test%22%2C%22requestTimeout%22%3A10000%2C%22url%22%3A%22https%3A%2F%2Fmcp-test.glama.ai%2Fmcp%22%7D%5D](https://glama.ai/mcp/inspector?servers=%5B%7B%22id%22%3A%22test%22%2C%22name%22%3A%22test%22%2C%22requestTimeout%22%3A10000%2C%22url%22%3A%22https%3A%2F%2Fmcp-test.glama.ai%2Fmcp%22%7D%5D) 为了确保 MCP 检查器完全符合规范，我还提供了一个 MCP 测试服务器，它实现了所有 MCP 功能。如果您正在构建 MCP 客户端，并且需要一个可以测试的工具，后者本身就很有用：[https://mcp-test.glama.ai/mcp](https://mcp-test.glama.ai/mcp) 最后，MCP 检查器已完全集成到我们的 MCP 服务器 ([https://glama.ai/mcp/servers](https://glama.ai/mcp/servers)) 和 MCP 连接器 ([https://glama.ai/mcp/connectors](https://glama.ai/mcp/connectors)) 目录中。只需单击一个按钮，您就可以测试任何开源/远程 MCP。 如果您正在构建任何与 MCP 相关的东西，欢迎提供您的反馈。缺少什么功能会让它成为您首选的工具？

我们一直在构建 Crust (<a href="https:&#x2F;&#x2F;crustjs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;crustjs.com&#x2F;</a>)，这是一个基于 TypeScript、原生 Bun 的 CLI 框架，零依赖。它已经在内部为我们的核心产品提供支持一段时间了，现在我们将其开源。<p>我们一直遇到的问题是：JS 生态系统中现有的 CLI 框架要么是需要你手动连接所有东西的极简参数解析器，要么是依赖树庞大且带有 Node 时代假设的重量级框架。我们想要一个介于两者之间的东西。<p>Crust 的与众不同之处：<p>- 从定义中进行完全的类型推断——参数和标志会自动推断。无需手动类型注释，无需处理泛型。你将一个标志定义为 type: "string"，它就会传递到你的处理程序中。<p>- 编译时验证——在你的代码运行之前，而不是在运行时，捕获标志别名冲突和可变参数错误。<p>- 零运行时依赖——@crustjs/core 压缩后约为 3.6kB (安装后 21kB)。 相比之下：yargs 为 509kB，oclif 为 411kB。<p>- 可组合的模块——核心、插件、提示、样式、验证和构建工具都是单独的包。只安装你需要的。<p>- 插件系统——基于中间件，带有生命周期钩子（preRun/postRun）。官方插件用于帮助、版本和 shell 自动补全。<p>- 为 Bun 而构建——没有 Node 兼容层，没有遗留包袱。<p>快速示例：<p><pre><code> import { Crust } from "@crustjs/core"; import { helpPlugin, versionPlugin } from "@crustjs/plugins"; const main = new Crust("greet") .args([{ name: "name", type: "string", default: "world" }]) .flags({ shout: { type: "boolean", short: "s" } }) .use(helpPlugin()) .use(versionPlugin("1.0.0")) .run(({ args, flags }) => { const msg = `Hello, ${args.name}!`; console.log(flags.shout ? msg.toUpperCase() : msg); }); await main.execute(); </code></pre> 创建一个新项目：<p><pre><code> bun create crust my-cli </code></pre> 网站：<a href="https:&#x2F;&#x2F;crustjs.com" rel="nofollow">https:&#x2F;&#x2F;crustjs.com</a> GitHub：<a href="https:&#x2F;&#x2F;github.com&#x2F;chenxin-yan&#x2F;crustjs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;chenxin-yan&#x2F;crustjs</a><p>很乐意回答关于设计决策或内部结构的任何问题。

永久推特。不可删除，不可编辑。爱泼斯坦相关的闹剧表明，政府试图清除信息。要求人们在这里发帖，这里什么都无法被清除。

Chrome 开发者工具的 MCP 中有很多关于使用 AI 反向工程 Web 应用和 API 的评论。我看到了“yt-dlp 又能用了”之类的消息，这很酷……但这是唯一的理由吗？总的来说，这样做的目的是什么？你们想通过这样做实现什么？