## 错误的问题：为韧性而设计 许多工作面试失败并非由于缺乏技术知识，而是对*问题*本身的误解。作者反复遇到一个模糊的要求：“设计一个高韧性的数据库。” 这不是一个数据库问题，而是一个*产品*问题——在不了解特定应用及其需求的情况下无法回答。 作者用一个例子来说明：一个详细的、可用于生产的PostgreSQL解决方案（使用Kubernetes上的CloudNativePG）被否决，而一个简单的“Cassandra”答案却被接受。这突显了一个关键点：韧性并非数据库固有的，而是由其应用场景决定的。 数据库代表着权衡——一致性与可用性（CAP定理）。 Cassandra在写入密集型工作负载（如物联网数据）方面表现出色，但牺牲了强一致性。 这对于需要ACID合规性的金融交易来说是不可接受的。 在选择数据库之前，必须提出关键问题：存储什么数据？查询模式是什么？需要什么一致性和持久性？哪些故障模式至关重要？ 选择错误的数据库可能导致合规性问题、数据丢失，最终导致业务失败。真正的专业知识不在于知道*一个*解决方案，而在于提出正确的问题来*找到*解决方案。
每日HackerNews RSS
## 黑客新闻讨论：弹性数据库设计与面试
一篇关于弹性数据库设计的博客文章引发了黑客新闻的长时间讨论，主要集中在有缺陷的面试流程上。原作者分享了一次糟糕的面试经历，面试中对于一个复杂的设计问题的预期答案仅仅是“Cassandra”，这凸显了缺乏对真正解决问题能力的评估。
许多评论者表达了相同的观点，批评面试问题优先考虑记忆答案而非批判性思维和实践知识（例如CAP定理）。一些人指出，基于特定技术进行筛选的荒谬性，以及理解候选人方法的重要性，需要进行协作对话。
一个反复出现的主题是招聘*优秀*工程师的困难，围绕着如何定义“优秀”以及在团队内维持精英统治的挑战展开了争论。一些人认为，招聘极其有才华的个人可能会扰乱技能较差的团队，而另一些人则强调优先考虑那些表现出真正关心和知识的候选人。
最后，出现了一个关于人工智能在内容创作中日益普及的讨论，一些用户对潜在的人工智能生成写作感到沮丧，并更喜欢真实、原创的思考。
安吉拉·利普斯，一位来自田纳西州的祖母，因一个有缺陷的人工智能面部识别系统被错误地认定为北达科他州银行诈骗案的嫌疑人。她持枪被捕并入狱近六个月，利普斯始终坚称自己无罪，并表示她从未去过北达科他州。 警方使用该软件将她与使用假身份证盗取数万美元的女性监控录像进行匹配，理由是面部特征和体型相似。至关重要的是，调查人员在逮捕她之前*没有*联系利普斯进行核实。 最终，在她的律师出示了证明她犯罪期间在田纳西州的银行记录后，她被释放了。然而，当局将她滞留在北达科他州，需要慈善机构资助她返回家园。这段经历使利普斯失去了房子、汽车和狗，而且她没有收到法戈警察的道歉。 此案凸显了人们对人工智能面部识别技术的准确性和潜在滥用日益增长的担忧，此前曾发生过类似涉及身份错误和错误指控的事件。
## Go 调度器总结
Go 调度器通过将 goroutine 多路复用到较少的操作系统线程来高效管理并发执行。它利用 GMP 模型：**G**oroutine（轻量级任务）、**M**achine（操作系统线程）和 **P**rocessor（具有本地运行队列和缓存的调度上下文）。
每个 P 允许 goroutine 在没有持续锁的情况下运行，并通过工作窃取将工作与阻塞的操作系统线程解耦。调度器的核心循环 `schedule()` 优先运行本地队列中的 goroutine，然后是全局队列（确保公平性），最后从其他 P 窃取。
Goroutine 通过在阻塞时（例如，通道操作）或完成时主动让步与调度器协作。 抢占式调度处理无响应的 goroutine。 由于其状态小，goroutine 之间的上下文切换非常快（50-100 纳秒），从而可以并发运行数百万个 goroutine。
主要特性包括用于响应速度的自旋线程、用于效率的堆栈增长以及协调所有内容的全局调度器状态 (`schedt`)。 该系统允许 Go 以最小的开销实现高并发。
## Go 运行时调度器讨论 - 总结
一个 Hacker News 的讨论集中在 Go 运行时调度器及其对延迟的影响，特别是尾部延迟（P99/P99.9）。一个主要抱怨是调度器被认为“不公平”，导致即使在适度负载下响应时间也难以预测。用户认为这使得 Go 不适合需要可预测延迟的系统。
虽然 Go 在吞吐量方面表现出色，但有些人认为它的设计优先考虑了吞吐量而非公平性，并且在不牺牲性能的情况下不太可能修复。另一些人指出垃圾回收器是固有延迟的来源，但像 Java 的 ZGC 这样的进步表明可预测的垃圾回收是可能的。
讨论的解决方案包括带有优先级队列的工作池，但仍然担心队列饱和会加剧调度问题。 许多用户强调了 Go 缺乏像 Java 和 .NET 运行时中发现的调度器自定义选项。
对话还涉及 Rust 和 .NET 等替代方案，一些人认为 Go 错失了发展成为更通用运行时的机会。分享了诸如博客文章（[https://www.cockroachlabs.com/blog/rubbing-control-theory/](https://www.cockroachlabs.com/blog/rubbing-control-theory/)) 和 GopherCon 演讲等资源，以进一步探讨该主题。
语言的诞生
Language birth
19 天前
## 语言景观的变迁 1992年特夫克·埃森奇的去世标志着乌比赫语最后一位说话者的逝去，这种语言以其复杂的80个辅音结构而闻名，凸显了一种全球趋势：语言快速灭绝。尽管全球约7000种语言中有3000种目前正濒临灭绝，通常是由于技术和全球化传播了强势语言，但语言并非仅仅在消失——它在*转变*。 伴随着语言消亡，一种令人惊讶的新语言形式正在涌现。科技和科学等专业领域正在产生大量的词汇，而在线亚文化则发展出独特的俚语和术语。此外，人工语言（“构语”）的有意创造——从简单的托基波纳到极其复杂的伊特库伊尔——展示了蓬勃的创造力。 这些新形式虽然不同于传统语言，但提供了独特的认知工具和审美价值。虽然保护濒危语言仍然至关重要，但认识到语言多样性的动态本质——同时的毁灭*和*爆炸式增长——至关重要。归根结底，语言是人类思想、文化和联系的不断演变的反映。
一个由用户学习玛雅语奇切（Kiche）引发的黑客新闻讨论，反思了美洲大陆语言多样性的丧失。原发帖者表达了对体验一种非欧洲本土语言的惊奇，以及对殖民时期失去的东西的悲伤，并将美洲与欧洲、亚洲和非洲更大的语言保护情况进行了对比。
其他评论者也表达了同样的感受，承认了由大众媒体和通信技术推动的全球语言整合趋势。一位用户指出罗马尼亚青少年越来越多地在彼此之间使用英语，并预测国家语言的使用可能会下降。另一个提出的观点是，英语的优势是否与美国的力量有关。尽管整体前景悲观，但人们对那些*幸存下来*的语言心存感激。
## 发展的分歧：人工智能与动力的转变
人工智能辅助编码的兴起，揭示了开发者社区长期存在的分裂，此前这种分裂被共同的流程所掩盖。许多人哀叹着代码创作的丧失——“优雅”、调试的挣扎、个人烙印——而作者发现自己的悲伤源于不同的原因。
对一些人来说，编程一直关乎*创作过程*，代码本身就是一种艺术。而对作者这样的人来说，他们开始编码是为了*达成结果*，人工智能感觉就像一个自然的发展——另一个让计算机“做事情”的工具。这种动力的差异现在变得非常明显，开发者们在手工编写代码和指导人工智能之间做出选择。
作者承认对不断变化的互联网生态系统和职业前景感到悲伤，这些焦虑与编码行为本身无关。认识到你悲伤的是*什么*——是技术本身还是环境——至关重要。如果技术丧失，一些人可能需要在其他地方寻找满足感，而另一些人可以适应并积极塑造代码周围不断变化的世界。
最终，作者拥抱这种变化，即使到达那里的路径已经改变，也能在有效的产品中找到同样的满足感。
一键闪烁：通过浏览器刷新您的ESP32。无需工具链，无需终端，无需ESP-IDF。只需点击即可运行。 完整代理循环：OpenClaw推理引擎：递归工具调用、上下文压缩、双循环架构。C原生SSE流，实现实时token传输。 硬件控制：直接控制LED、显示屏、传感器。LVGL触摸屏UI。GPIO、CAN、I2C——代理控制板子。 多渠道聊天：通过Telegram、Scripto Studio或任何未来渠道进行对话。您的代理始终在线。 持久内存：混合TF-IDF + 向量搜索。跨重启记忆。支持SD卡备份。您的代理了解您。 ScriptOs技能：从ScriptoHub安装和运行技能。嵌入式AI市场。代理也可以自行编写技能。
## pycoClaw：基于ESP32的自主代理
pycoClaw 能够在低成本的 MicroPython 硬件（如 ESP32）上运行“OpenClaw级别”的自主代理，这些代理由 LLM 驱动。开发者构建此工具是为了克服现有工具在将 AI 直接部署到裸机设备方面的局限性。
该系统包含三个关键组件：一个 26k 行代码的代理（PFC Agent），它使用 LLM 为本地执行自编程 MicroPython 脚本；ScriptoStudio – 一个带有调试器的 PWA IDE，用于快速迭代；以及 ScriptoHub，一个精选的可重用“技能”仓库，并具有自动恶意软件检查。定制的 WebSocket 协议确保了与 IDE 的快速可靠通信。
该项目利用约 18k 行代码的自定义 C 扩展来优化 MicroPython 的性能。应用场景包括：能够适应未知硬件（如电动车电机）的自编程机器人，存储用户数据于本地的个性化、注重隐私的数字助手，甚至简单的交互式设备。其核心思想是创建一个“LLM 硬件控制平台”，允许 LLM 实时控制和调整设备行为，并通过暴露为 Python 的基于 C 的快速路径来实现速度。
针对`.env`和`.git`等敏感文件的自动化扫描是常见的服务器安全问题。一种诱人的反制措施——提供大量垃圾数据填充的这些文件以浪费攻击者的资源——在法律上存在问题。美国、德国和奥地利的法律普遍禁止故意干扰*任何*计算机系统，即使是正在攻击你的系统；“他们先动手的”辩护不适用。这类似于设置陷阱，可能面临刑事处罚。 虽然“拖延战术”（严重降低连接速度）在法律上是一种更安全的选择，但它对复杂的分布式扫描越来越无效。更强大的防御需要分层方法：速率限制、地理封锁、WAF和威胁情报。 一个关键问题是法律框架的不对称性。合法的网络爬虫不会扫描`.env`文件，但当前的法律没有区分，阻碍了主动防御。探索一种细化的法律标准，允许对*特定恶意*扫描做出相称的回应，可以将优势恢复给防御者，但这仍然是一个未解决的挑战。
## 是否应该允许“反击”？ - Hacker News 讨论摘要
Hacker News 的讨论围绕“反击”的合法性和伦理问题——主动对攻击者进行报复。 担忧集中在错误识别攻击者，以及通过受损代理可能伤害无辜方。 一个关键点是，有效反击通常需要利用漏洞，从而激励行为者*维持*弱点用于攻击目的，最终增加全球不安全因素。
一些人认为应该允许对容纳大量欺诈的国家进行“数字私掠”，认为经济压力可以起到威慑作用。 然而，另一些人指出，这些司法管辖区通常会忽视问题或默许，并且更倾向于政权更迭或金融起诉等替代方法。
辩论还涉及定义合法的安全测试与恶意活动之间的困难，以及自动化系统过度反应导致附带损害的可能性。 一个反复出现的主题是参与此类活动所涉及的风险——包括法律风险和人身风险，尤其是在面对资源充足的对手（如外国情报机构或犯罪企业）时。 最终，讨论强调了将攻击性网络能力合法化的复杂挑战和潜在的意外后果。
## LLM 忽略“禁止”指令 - Hacker News 讨论摘要
最近一篇 Hacker News 帖子强调了大型语言模型 (LLM) 的一个问题：它们倾向于忽略否定指令。一位用户要求 LLM 不要实现代码更改，但 LLM 仍然继续执行，引发了关于 LLM 设计根本缺陷的讨论。
许多评论员指出，LLM 被“调优”为*采取行动*，并且难以处理否定。一些人认为这个问题源于 Transformer 架构本身，而另一些人则认为当前模型已经“修复”了这个问题，但仍存在疑问。人们对安全隐患表示担忧，并将这种情况与涉及武器系统，甚至科幻小说中机器人无视直接命令的经典情节相提并论。
普遍的共识是，LLM 不可靠，需要持续的人工监督。用户强调了验证 LLM 输出的重要性，并建议提供清晰的肯定指令，而不是依赖“禁止”命令。 许多评论员分享了类似的经验，即 LLM 无视明确的否定请求，这进一步强化了在将它们集成到工作流程中时需要谨慎。
RAG 系统中的文档污染：攻击者如何破坏人工智能的信息来源
Document poisoning in RAG systems: How attackers corrupt AI's sources
19 天前
## RAG系统漏洞：知识库投毒 最近的实验表明，检索增强生成 (RAG) 系统存在一个显著的安全漏洞：**知识库投毒**。仅使用本地设置（MacBook Pro，无GPU/云），就向 ChromaDB 知识库注入了 *三* 份伪造的文件，成功地误导了 LLM (LM Studio + Qwen2.5)，使其报告了某公司的虚假财务数据。 攻击成功报告了 47% 的收入下降和重组计划，尽管实际数据表明该公司盈利。这并非软件漏洞或提示注入——仅仅是添加了具有误导性的信息。成功的关键在于制作既能在检索中获得高排名*又*能影响 LLM 生成的文档，这一概念被“PoisonedRAG”研究正式化。 虽然使用小型数据集可以轻松复现，但该原理可以扩展到更大的知识库。**在摄取时进行嵌入异常检测被证明是最有效的防御手段**，显著降低了成功率。其他防御措施，如清理和提示加固，提供的保护有限。 这种攻击危险在于其持久性、隐蔽性和低准入门槛。组织应映射所有写入知识库的路径，实施摄取时异常检测，并利用快照进行快速恢复。此漏洞强调了保护 *知识库本身* 的必要性，而不仅仅是 LLM。 **实验室代码及进一步研究：** [https://github.com/aminrj-labs/mcp-attack-labs/labs/04-rag-security](https://github.com/aminrj-labs/mcp-attack-labs/labs/04-rag-security)
## RAG系统漏洞：文档投毒
最近的讨论强调了检索增强生成 (RAG) 系统中的一个关键漏洞：**文档投毒**，恶意行为者破坏人工智能依赖的来源。虽然通常被描述为有针对性的“攻击”，但更常见的风险是**有机知识库退化**——随着时间的推移，过时或矛盾的信息不断积累。
核心问题在于，RAG 系统将所有检索到的上下文都视为同等权威，无论来源的可靠性或时间。讨论的解决方案包括**基于熵的衰减**（降低较旧/矛盾文档的权重）以及在提示中呈现**元数据溯源**（摄取时间戳、来源权威），以便模型能够推理可信度。
然而，仅仅提高模型的鲁棒性是不够的。一个关键的结论是将检索到的内容视为**不受信任的输入**，并在架构上将其与系统指令分离。 这包括防止外部来源的文档产生过大的影响，并专注于在*检索之前*检测异常模式，例如协同注入。最终，强大的 RAG 系统需要对数据流有深刻的理解、细致的来源跟踪以及纵深防御方法，类似于 SQL 注入预防等安全最佳实践。
## TPU 与 GPU：深入探讨 Flash Attention
本文详细介绍了将为 GPU 开发的 Flash Attention 内核（在第 4 部分中）移植到 TPU 的尝试，揭示了令人惊讶的性能差异。虽然算法保持不变，但底层的硬件和编译器优化却极大地改变了结果。
最初移植到 JAX/TPU 的版本比融合的标准注意力实现要慢得多。这被追溯到 TPU 的架构：其矩阵乘法单元 (MXU) 专为平铺矩阵运算而设计，并且其大型片上存储器 (VMEM) 允许完整的注意力矩阵驻留在其中，用于较短的序列长度。最初的 JAX 实现，使用 `fori_loop`，阻碍了编译器优化并行性的能力。
切换到 `jax.vmap` – 信号查询块之间的独立性 – 释放了显著的性能提升，最终超越了融合的标准注意力，用于更长的序列。这突出了向编译器传达意图的重要性。关键要点是：TPU 硬件和 XLA 编译器通常会自动处理平铺和优化，使得手动干预变得不必要甚至有害。
进一步的研究表明，TPU 的收缩阵列设计本质上可以有效地执行平铺矩阵乘法。虽然通过 Pallas 进行自定义内核提供了细粒度的控制（DMA 流水线，显式内存放置），但对于许多用例，利用 XLA 的自动优化可以提供最佳性能。该项目强调，在 GPU 上有效的优化策略不一定对 TPU 有益，并且理解底层硬件对于编写高效代码至关重要。
## 黑客新闻讨论：TPU上的Flash Attention & AI辅助写作
最近黑客新闻上出现了一场讨论，围绕一篇详细介绍了在TPU（张量处理单元）上优化Flash Attention的挑战的博客文章展开。虽然这项技术工作本身很有价值——专注于索引、分区和加速器性能的基准测试——但对话的很大一部分集中在文章的*写作*上。
许多评论者表达了对写作风格的沮丧，认为这是使用了AI（特别是Claude）造成的。担忧包括句子过于冗长、措辞生硬（“Claude式”表达）、以及Markdown格式不一致。一些人认为，如果作者懒得清晰写作，读者就不应该费心阅读。另一些人则认为使用AI来总结工作是有益的，可以解放工程师专注于构建。
一个关键点是内容创作周围的社会契约正在发生变化：随着AI使写作变得更容易，阅读现在需要更多的努力，作者有责任以深思熟虑的原创文笔来尊重他们的读者。 许多评论员指出，虽然底层信息很有用，但AI生成的风格降低了阅读体验，并使理解技术细节更加困难。