## LLM 作为一种新的开发工具 作者详细描述了他们在软件开发方法上的转变，发现乐趣不在于*编程*本身，而在于*创造事物*，而大型语言模型 (LLM) 现在能极大地赋能这一过程。他们发现最近的 LLM 进步（例如 Opus 4.6）能够以惊人的低缺陷率进行编码，可靠性甚至超过手工编写的代码，同时保持对系统理解。 他们的工作流程以将 LLM 用作协作代理为中心：一个“架构师”进行规划，一个“开发者”进行实现，以及“审查者”进行批判。至关重要的是，利用*多个*模型进行审查可以提高质量，并且定义自定义代理允许自主任务委派。这个过程强调系统架构和设计技能，而不是细致的编码。 作者展示了几个以这种方式构建的项目——包括一个安全的个人助手（“Stavrobot”）、一个语音备忘录吊坠（“Middle”）和一个艺术项目（“Sleight of Hand”），证明 LLM 不仅限于简单的脚本。他们强调了强大的“框架”（使用 OpenCode）来管理模型和代理的重要性。 关键要点是一个协作的、迭代的过程，人类专业知识引导 LLM，从而产生可靠的、复杂的软件，并提高效率。作者提供了一个详细的注释编码会话，作为此工作流程的实际示例。
每日HackerNews RSS
## 使用人工智能自动化告警分诊 Quickchat 的作者厌倦了每天早上手动筛选 Datadog 告警，因此他们使用 Claude Code 构建了一个自动化系统来处理这项繁琐的任务。由于需要处理跨多个平台的大量日常对话，他们的 Datadog 实例“繁忙”，他们旨在消除将告警分类为真正问题或瞬时问题的每日例行工作。 该解决方案在约 30 分钟内构建完成，利用 Datadog 的模型上下文协议 (MCP) 授予 Claude Code 访问实时监控数据的权限。一个自定义“技能”指示人工智能对告警进行分诊，将其分类为可操作的错误、基础设施问题或噪音。对于可操作的错误，人工智能会启动隔离的工作树，编写带有测试的修复程序，并自动打开拉取请求。一个 cron 作业每天运行此过程。 结果如何？作者现在醒来时会看到预先创建的 PR，大大减少了早上的调查时间，并让他们能够更早地开始专注工作。虽然承认它无法取代重大故障期间的人工干预，但这种“懒惰工程”方法展示了自动化如何叠加改进、保留上下文并简化事件响应。该系统易于实施，并且可以适应其他重复性任务，例如安全扫描和依赖项更新。
## AI 监控总结 - Hacker News 讨论
一位开发者创建了一个 AI 来总结 Datadog 警报，起因是对手动每日检查的繁琐。讨论迅速转向了需要检查的*原因*，以及错误监控的细微之处。
许多评论者认为，适当的监控应该依赖于良好调整的**警报**，而不是手动审查。一个关键点是错误分类的难度——尤其是在具有基于异常的错误处理的语言中——以及区分可操作的错误与预期事件（如登录失败）。一些人提倡监控*成功*而不是失败。
几位用户强调了对有效监控设置缺乏理解，导致依赖于这种 AI 这样的变通方法。一个核心问题是，如果仅仅依赖 AI 总结，可能会失去“生产直觉”——对正常系统行为的基本理解，这对于有效的开发和故障排除至关重要。
最终，共识倾向于修复潜在的监控问题，而不是构建 AI 来弥补它们，重点是主动警报和对应用程序遥测的深入理解。
《Linux编程接口》（TLPI）的作者发现，该书越来越多地被作为大学Linux/UNIX系统编程课程的教材或推荐读物。为了改进未来版本以适应学术市场，作者正在积极寻求目前在教学中使用TLPI的教授的反馈。 具体而言，作者希望了解学校机构、课程大纲、学生水平和规模，以及TLPI是必修还是辅助材料。最重要的是，作者欢迎详细的建议，说明如何使本书更适合大学课程。此举旨在调整TLPI，以有效支持系统编程教育。鼓励使用该书的教授与作者联系，分享他们的见解。
## Linux 编程接口作为大学教材 - 摘要
一个 Hacker News 的讨论集中在使用“Linux 编程接口”（TLPI）作为大学教材。许多评论员称赞 TLPI 是一本全面且宝贵的资源，用于理解操作系统和系统编程的实际情况——这些内容通常在纯理论的计算机科学课程中缺失。
对话强调了学术计算机科学教育与行业需求之间的脱节。一些用户抱怨大学优先考虑理论知识，而不是像 CLI 使用、Git 和 shell 脚本等实用技能，导致毕业生无法为现实世界的开发做好准备。一些人回忆起有价值的、自发组织的课程填补了这一差距。
将教育系统与苏联控制国家和德国进行比较，这些国家利用分层系统来区分理论和实践学习。另一些人指出英国理工学院的衰落，它们曾经专注于实践技能。
最终，讨论强调了对更平衡的计算机科学教育的渴望，以弥合学术纯粹性和软件行业务实需求之间的差距。TLPI 的新版本预计将发布，可能在 Linux 开发 16 年后更新文本。
客户端挑战：您的浏览器已禁用 JavaScript。请启用 JavaScript 以继续。网站的必要部分无法加载。这可能是由于浏览器扩展、网络问题或浏览器设置造成的。请检查您的连接，禁用任何广告拦截器，或尝试使用不同的浏览器。
## 大麻素与阿尔茨海默病：摘要
2016年索尔克研究所的一项研究探讨了大麻素清除阿尔茨海默病标志物——脑细胞中的β-淀粉样斑块的潜力*在体外*。研究发现高浓度的THC可以有效降低斑块水平和炎症。
然而，评论员很快指出重要的注意事项。有效浓度（0.1-1uM）非常高——需要可能危险的大麻剂量（估计每天9-10个强效大麻烟卷）才能达到，甚至可能在这些水平下*导致*神经元细胞死亡。
讨论强调了实验室结果与实际应用之间的差异，质疑娱乐性使用是否能够复制这些效果。许多人强调需要进一步研究，指出以β-淀粉样为靶点的阿尔茨海默病药物试验失败的历史，以及大麻对大脑影响的复杂性。一些人建议替代预防措施，如锂或超声治疗。
最终，这篇文章引发了关于潜在益处与风险，以及将*体外*研究结果转化为可行治疗方法的挑战的争论。
强盗：一台运行彩色 Forth 的 32 位裸机电脑[视频]
Bandit: A 32bit baremetal computer that runs Color Forth [video]
3 天前
关于按住版权联系我们创作者广告开发者条款隐私政策和安全性YouTube的工作原理测试新功能© 2026 Google LLC
一个名为“Bandit”的新型32位裸机电脑，运行Color Forth，在Hacker News上引起了关注。该项目通过YouTube视频展示，因其巧妙的设计和“后末日”风格的赛博甲板美学而受到赞扬。
讨论强调了Color Forth的历史背景，提到了Jupiter Ace和ZX80/81等机器。用户欣赏该项目的定制精神，并指出创作者选择的键盘布局（Dvorak，Color Forth先驱Chuck Moore喜爱）反映了个人的偏好。
许多评论者表达了购买Bandit的强烈兴趣，称其为“终极极客摆弄玩具”。普遍的看法是，这种硬件相关的作品是平台上一股来自人工智能/大型语言模型讨论之外的清新空气。
Microsoft Excel 将 1900 年错误地视为闰年，这是为了与 Lotus 1-2-3 保持历史兼容性。在 Excel 开发时，为了便于文件传输和用户体验，优先保持与 Lotus 的日期系统一致——该系统*错误地*将 1900 年包含为闰年。 虽然从技术上讲不准确，但纠正此行为会导致严重破坏。现有的 Excel 电子表格中的所有日期都会提前一天，需要大量的手动调整，并可能导致公式失效。与依赖当前系统的其他程序兼容性也会丧失。 保持此错误的唯一缺点是，对于 1900 年 3 月 1 日*之前*的日期，WEEKDAY 函数的结果不准确——这种情况大多数用户很少遇到。因此，微软选择保留 1900 年闰年的假设，以避免广泛的并发症。Excel 正确计算所有其他闰年。
## Excel 的闰年错误及其他日历怪癖
一个 Hacker News 的讨论强调了 Excel 长期存在的错误，即把 1900 年当作闰年。尽管这个错误会造成问题（甚至影响基因组研究！），但为了兼容性原因一直被保留。这引发了关于历史日历不一致性和软件错误的更广泛讨论。
用户分享了类似的问题，例如 Rockchip RTC 错误地认为 11 月有 31 天，以及微软 Zune 因闰年计算错误而冻结。讨论深入探讨了日历的起源，指出最初的罗马日历是不完整的（以 12 月结束），后来尝试添加冬季月份，但并不受欢迎。
许多评论者指出了详细描述这些怪癖的资源，包括 Joel Spolsky 讲述的比尔·盖茨审查，以及一部关于计时法的综合历史。该帖子强调了这些历史“错误”如何深深地嵌入到现代系统中，以及在不破坏现有功能的情况下修复它们的挑战。
## 通过ChatGPT账户访问OpenAI API：openai-oauth `openai-oauth`是一个社区维护的工具，允许您使用现有的ChatGPT账户身份验证来免费访问OpenAI的API。它通过利用OAuth令牌绕过对API密钥的需求。 **工作原理：** * **CLI & 代理:** 运行 `npx openai-oauth` 以启动一个本地代理（默认：http://127.0.0.1:10531/v1），该代理与OpenAI API兼容。 * **Vercel AI SDK 提供商:** 直接与Vercel AI SDK集成，以便在应用程序中无缝使用。 * **模型:** 访问通过您的ChatGPT账户可用的Codex模型（例如，gpt-5.4）。 **主要特性:** 支持 `/v1/responses`、`/v1/chat/completions`、`/v1/models`、流式传输、toolcalls和推理跟踪。 **重要注意事项:** 这是一个*非官方*项目。请小心保管您的 `auth.json` 文件（包含登录凭据）——就像密码一样。它仅用于**个人、本地实验**，不提供任何保证。用户有完全责任遵守OpenAI的服务条款。
## 通过ChatGPT账户免费访问OpenAI API - 摘要
一个新的GitHub项目 ([github.com/evanzhoudev](https://github.com/evanzhoudev)) 允许用户可能使用他们的ChatGPT Pro/Plus订阅访问OpenAI API，从而绕过直接的API费用。该方法利用现有的ChatGPT访问权限来使用API配额。
Hacker News上的讨论显示，OpenAI对此事的立场处于“灰色地带”。虽然未明确允许，但OpenAI与OpenCode（使用类似方法）的合作表明存在一定的容忍度。然而，许多评论员认为OpenAI可能会关闭这个漏洞，或者正式集成一个类似系统，因为依赖它用于商业项目存在风险。
人们担心违反OpenAI的服务条款以及可能导致账户被封禁。一些人认为这在伦理上是有问题的，类似于滥用自助餐或规避预期的使用限制。另一些人认为OpenAI可能会改进与订阅相关的API信用跟踪，而不是完全禁止这种做法。该项目采用Affero GPL许可，作者建议仅将其用于个人/实验项目。
## 使用 Elixir 的 `Map.take!` 探索类型系统 Dashbit（Elixir、Nx 和 Livebook 的创建者）正在为 Elixir 开发一个类型系统，并将其用作学习练习，以了解为动态语言添加类型所固有的权衡。本文探讨了一个建议的 `Map.take!/2` 函数——现有 `Map.take/2` 的一个更严格的版本——如果任何请求的键在映射中不存在，将引发错误（像具有已知字段的记录一样处理）。 实现 `Map.take!/2` 本身很简单，但定义一个有用的类型签名却具有挑战性。一个基本的签名过于宽泛，无法指定返回映射的确切形状。受 TypeScript 的 `keyof` 启发而创建精确签名的尝试，揭示了复杂性。不应改变行为的简单重构可能会破坏类型检查，甚至看似合理的解决方案也可能*不健全*——通过类型检查但运行时失败。 作者探讨了潜在的解决方案，包括分发条件，并最终建议 **宏** 提供了一条有希望的途径。宏可以强制执行静态键列表，从而实现精确的类型推断并避免复杂类型签名的陷阱。这凸显了一个核心矛盾：在演进动态语言时，平衡表达力、简洁性和静态验证。文章最终倡导对静态与动态类型进行细致的讨论，以及语言设计中涉及的权衡。
## 泄漏的抽象与 TypeScript Map
最近在 Hacker News 上的一场讨论围绕着一篇探讨 TypeScript 的 `Map.take!` 函数类型安全问题的博文展开。核心论点并非类型系统本身，而是将丰富的类型系统强加于一个从根本上建立在“Any”类型之上的语言所带来的挑战。
许多评论者同意标题具有误导性，将问题描述为“泄漏的抽象”，而实际上更多的是在使用通用的 `Map`（Any 到 Any）时所存在的局限性，以及期望编译时保证的期望。真正的泄漏的抽象涉及底层系统中隐藏的复杂性，而这里并非如此，因为 TypeScript 类型不会影响生成的 JavaScript。
提出的解决方案包括利用依赖类型、行/记录类型，或者从根本上避免在关键存在至关重要时使用 `Map`——选择更具体的数据结构。一个反复出现的主题是，当键访问依赖于运行时条件（如 `Math.random()`）时，编译时评估的困难，这要求编译器象征性地评估所有代码路径。
对话还涉及可选类型的权衡，一些人更喜欢 Python 等语言的灵活性，而另一些人则支持强类型系统的安全性。最终，这场讨论强调了在试图对本质上动态的操作强制执行严格类型安全时所固有的局限性。
## LLM 疲劳：可能在于你，而非模型 与 Claude 或 Codex 等大型语言模型 (LLM) 合作可能会令人惊讶地感到疲惫。作者发现，长时间的使用往往会导致沮丧和效率低下，最初会责怪模型本身——潜在的“变笨”、上下文限制或臃肿的系统。然而，核心问题通常在于*用户*的疲劳。 疲劳会直接影响提示质量，导致中断和负面反馈循环。缓慢的处理速度，特别是处理大型文件等任务时，会加剧这种情况，从而产生令人沮丧的缓慢迭代周期。 避免这种“恶性循环”的关键在于自我意识。当提示写作感觉勉强或不耐烦时，就应该意识到需要休息。不要依赖人工智能来填补思维中的空白，而应专注于编写清晰、自信的提示，并明确所需的成果。 至关重要的是，应将缓慢的反馈循环*视为问题本身*来解决。通过明确要求更快的迭代——模仿测试驱动开发——并提供清晰的失败案例，LLM 可以优化速度和效率，最终消耗更少的上下文并提供更智能的结果。最终，LLM 的成功取决于认识和减轻个人疲劳，并优先考虑快速、专注的工作流程。
## LLM 与开发者疲惫：总结
最近 Hacker News 上的一场讨论集中在与大型语言模型 (LLM) 进行编码工作时令人惊讶的疲惫感上。虽然 LLM 有潜力提高速度，但许多开发者发现持续的监督、提示和审查在精神上令人疲惫。
一些评论者提倡**异步工作流程**，禁用干扰性通知，并同时专注于少数任务，利用“等待时间”进行相关工作。关键在于避免追求 LLM 的最大效率，并允许它们有空闲时间。 另一些人指出，核心挑战不是编码本身（现在往往变得微不足道），而是**持续的决策**——引导 LLM 和规划项目。
一个反复出现的主题是**审查 LLM 生成的代码**的困难，尤其是在质量受损时。有些人觉得这比传统的编码更令人疲惫，因为人类仍然是瓶颈。 关于这是否是“技能问题”——需要学习更好的提示技巧——或当前 LLM 能力的根本限制，存在争论。 最终，这场讨论揭示了人工智能辅助开发的前景与管理其缺陷的现实之间的紧张关系。
人工智能代理正在自动化重复性任务，让人类可以专注于创造力和批判性思维——这是软件开发领域一个令人兴奋的转变。然而，广泛采用取决于**信任**：确保代理可靠地*按预期*执行，并避免意外行为。
Fabraix 正在通过其开源“游乐场”（playground.fabraix.com）建立这种信任。该平台通过挑战社区使用可见的系统提示和工具来“越狱”实时代理，从而压力测试人工智能代理的安全性。
挑战是社区驱动的——由社区提出、投票和计时。成功的漏洞利用会被公开记录，从而促进集体学习并推动人工智能防御的改进。这种迭代的攻防过程建立了对人工智能漏洞的共同理解。
Fabraix 认为，开放、协作的安全测试对于构建强大而可靠的人工智能系统至关重要，最终使所有使用这项技术的人受益。该项目的前端和挑战配置是公开可用的，从而促进透明度和社区贡献。
## Fabraix 开源 AI 红队演练场总结
Fabraix 开源了一个 AI 代理红队演练场 (github.com/fabraix)，源于内部安全测试。目标是通过挑战用户来利用 AI 系统中的漏洞，并公开记录成功的漏洞利用和安全防护日志。
最初的挑战是诱导代理调用禁止使用的工具，在 60 秒内通过重新构建上下文而非直接请求成功绕过。当前的挑战侧重于数据泄露。
讨论强调了主动红队演练的重要性，超越被动修复（如密钥轮换），转向实施最小权限访问。然而，核心争论在于安全与代理自主性之间的平衡——过度限制的措施会降低实用性。参与者强调公开的记录对于发现意外的漏洞利用链条的价值，特别是能够绕过简单安全防护的多步骤序列。
该平台正在不断发展，计划增加排行榜，并根据用户反馈进行改进，包括成功漏洞利用的确认消息。Fabraix 旨在提高代理的可靠性，使其能够承担失败的责任。