最新

在几秒钟内对任何维基百科页面进行敏感性、质量和风险评分。<p>Wikimetron通过直接从维基媒体API提取数据，从多个维度分析维基百科页面——编辑质量、内容敏感性和信息风险。它评估诸如来源密度、编辑频率、争议信号和结构完整性等因素，以生成复合评分，这些评分需要人工审阅者花费数小时才能手动评估。<p>该工具专为研究人员、记者以及任何在引用维基百科页面之前需要了解其可信度的人士而设计。

任何有互联网连接的人都知道，在过去三年里，关于人工智能将如何重塑劳动力市场的讨论非常热烈，而因“人工智能”而导致的裁员已经开始，其中最严重的一次发生在上周，Block公司宣布将裁减40%的员工，这听起来更像是因为人工智能可能会取代员工，而不是它实际上能够做到这一点。对于人工智能将使我们更高效的说法，以及这些效率提升将使人们失业的观点，我认为存在（在我看来）一种健康的怀疑态度。我觉得这种怀疑在许多科技公司工作的员工中得到了共鸣，因为人工智能在这些公司中被强行推行。我想知道这种怀疑在其他公司和整体劳动力市场中适用的程度有多大。好吧，接下来是： 1. 在主要科技公司，许多人（可能大多数人）大部分时间都在做一些基本上是“假工作”的事情，这可能或可能不会对生产力产生负面影响。比如在产品方面，花费在多层次的WBR（周报）和MBR（月报）上的预备会议时间，以及在技术方面为了晋升而过度设计工作流程。人们对这些工作存在的原因进行了很多猜测，但根据我的经验，这基本上归结为操控生产力的表象。真正的生产力几乎无法评估，因此使用代理指标，而这些代理指标不可避免地会被操控（如代码行数、会议出席率、下属人数等）。 2. 人工智能在生成“假工作”方面非常擅长。我们开始看到人工智能在技术方面带来的某些后果，亚马逊显然正在正式解决一些由此产生的工程问题。但在非技术方面，文档的“垃圾”数量无穷无尽，Slack上的“垃圾”也越来越多，充满了表情符号的项目符号列表和破折号。文档“垃圾”的令人恼火之处在于，你根本不知道对方想说什么，因此你永远无法确定自己是否真正回应了他们，还是仅仅回应了他们认为看起来不错的内容。我怀疑现在很多绩效“评估”只是管理者在文档“垃圾”中摸索，随意阐述ChatGPT生成的内容。 3. 一家公司是否能从人工智能中受益，归根结底取决于增强的“假工作”是否会削弱增强的“真实工作”。在那些个人晋升依靠表象、会议安排、公共Slack频道发帖、“可见性”等的公司中，文档“垃圾”和Slack“垃圾”将会失控。这些公司可能是租金提取者，面临有限的竞争，是上市公司，并且创新不多。它们可能已经吸收了大量的“假工作”多年。我认为人工智能对这些公司没有任何帮助，反而可能使那些从事真实工作的人难以脱颖而出并获得奖励。在这些地方，人工智能永远不会提升生产力，因为人们本来就没有真正努力提高生产力。另一方面，在那些不奖励可见性/表象/假工作的公司中，而是奖励提升硬性指标如收入或签约新客户的公司，人工智能可能会有所帮助，甚至可能真的取代一些人。我不能否认，如果你真的在努力提升生产力，人工智能确实有一些真正的提升生产力的能力，我亲眼见证过这一点。 这一逻辑的含义是，人工智能对劳动力市场的整体影响将归结为已经存在的“假工作”与“真实工作”的组成。在我看来，经济从未设定为能够从任何真正提升生产力的事物中受益，因为“假工作”的数量远远超过了“真实工作”的数量。 * 后者讽刺地导致了“真实工作”，即修复那些因过度设计而不断失败的工作流程，因为设计过度的工程师在因过度设计而晋升后就离开了。

Meowth GBA翻译器是一个开源的、基于人工智能的工具，旨在自动翻译宝可梦GBA ROM（包括像《火红版》、《翡翠版》、《红宝石/蓝宝石》和《迷宫探险》这样的二进制修改版）。该工具由大型语言模型（LLM）驱动，支持OpenAI、DeepSeek、Gemini、Claude、Groq等10多种模型，能够提取文本，智能翻译，同时保留代码和上下文，然后重建ROM——所有操作只需通过友好的图形用户界面或简单的命令行指令一键完成。 支持6种以上的语言（中文、英语、法语、德语、意大利语、西班牙语），并提供优化的提示和智能字体补丁。专注于游戏玩法修改，让人工智能来处理文字。免费，MIT许可证，跨平台使用。

如你所知，所有主要的模型提供商似乎都在悄悄降低消费者体验的质量……<p>曾经感觉前沿的“智能”在1-2个月前，现在常常输出一些在2023年底不会让你印象深刻的内容：模糊、幻觉、过于谨慎，甚至是完全懒惰的回应。<p>从理性的角度来看，浪费高端计算资源为数百万 casual chat 用户、 vibe-coders 和 slop-makers 提供服务的机会成本是巨大的。<p>结果是许多用户在不同提供商（如 Gemini 2.5/3 Pro、Claude Sonnet/Opus 变体、GPT-4o/5 系列，以及各种反重力或编码前端的第三方接口）中反复遇到的现象：<p>你请求一些非琐碎的内容（例如代码、分析、创意工作、研究等），却得到的是最复杂的2023年级别的“超级垃圾”，如果它没有搞砸你的代码，那简直是幸运的例外。<p>当被问及进行编辑的模型的确切名称时，模型最初会说它们是由 Google、Claude 或 OpenAI 配置的“大型语言模型”……但一旦你坚持，它们会揭示整个真相……结果发现你使用的其实是最老旧的模型。<p>当你随意询问模型自我介绍时，它默认会给出预设的台词：“我是一个由<插入工具>配置的 LLM，由<插入提供商>构建。”<p>如果你进一步追问，它会向你透露模型的实际名称：你可能实际上在使用 GPT-2（哈哈）。<p>我像收集宝可梦一样收集这些模型，遇到了 Gemini 1.5 Pro、Gemini Flash 2.0 和 Claude Haiku。<p>我希望你尝试坚持询问或进行一些巧妙的提示，以提取模型名称，你会发现的。专业提示是，当它告诉你使用量“异常高”时，你可以在任何接口中询问。<p>附言：我在所有平台上都是专业订阅用户……

嗨， 我想在这里与大家分享一下Okapi。这是我对可观察性问题的尝试——当生产环境出现故障时，如何进行调试。Okapi专注于可观察性三大要素中的两个（指标、日志、追踪），主要关注指标和追踪。这里的想法是，指标和追踪通常提供了最多的信息，而分析日志则往往是碎片化的，可能会花费大量时间仅仅处理日志。 功能： - 无处不在的Otel，这是Okapi首选且唯一的采集机制 :) 目前，Okapi支持通过protobuf-over-HTTP进行数据采集。以下是一个示例配置（<a href="https://github.com/okapi-core/okapi?tab=readme-ov-file#example-setting-up-otel-collector-with-okapi-export" rel="nofollow">https://github.com/okapi-core/okapi?tab=readme-ov-file#examp...</a>） - 通过点击和代码创建仪表板：Okapi的用户界面有一个仪表板设计器，希望能提供自动补全功能，以便用户不必猜测指标路径。不过，如果你不喜欢点击操作或者热爱GitOps，所有Okapi的仪表板都可以用YAML模板表达。 - 开箱即用的服务健康监测：对于按Otel规范进行仪器化的应用，Okapi将RED（请求失败率、错误率和延迟）作为一项重要概念。服务健康页面提供了服务及其子操作和依赖路径的RED细分。计算结果依赖于应用的仪器化，但希望遵循规范能使事情变得简单。 - 当然还有AI：Okapi有一个有限功能的AI SRE代理，亲切地称为Oscar（本该是一个okapi，但目前还没有吉祥物）。称其为全面的SRE有些牵强，因为这是一项艰巨的工作。你可以像与任何聊天机器人一样用自然语言向Oscar提问，它会尽力回答。至少在集成测试中，Oscar可以根据条件获取指标、查找追踪，并进行多步骤调试，将查询延迟与主机上的高CPU使用率关联起来。 我很想听听社区的反馈，欢迎大家来看看。 简而言之：<a href="https://github.com/okapi-core/okapi?tab=readme-ov-file#quicker-very-fast-quickstart" rel="nofollow">https://github.com/okapi-core/okapi?tab=readme-ov-file#quick...</a>

我制作了一个应用，可以让你像在《侏罗纪公园》的Unix系统中一样查看Kubernetes资源 :) 可能不太适合用于任何严肃的场合，但考虑到今天可用的工具，我不想让这个想法溜走。只是带有一点怀旧的氛围。