## 微软与 OpenAI 加深合作，重点转向 AWS 集成 微软和 OpenAI 已经重组了他们的合作关系，将 OpenAI 模型更广泛的可访问性置于 Azure 独占性之上。尽管微软仍然是 OpenAI 至 2032 年的主要云合作伙伴，但 OpenAI 现在可以将其产品提供给其他云提供商，特别是 AWS。 这一转变源于企业对在现有云基础设施上访问模型的需求，这是 Anthropic 的竞争优势。 公告的核心是“Bedrock 管理代理”，这是一个由 OpenAI 提供支持并原生集成在 AWS 中的新产品。 这旨在简化已经投资于 AWS 生态系统的企业的代理开发，处理身份验证、安全性和部署复杂性。 两家公司都强调这种合作将释放超出当前可能性的新能力。 微软将不再从 OpenAI 获得收入分成，但仍是主要股东。 两位首席执行官都强调了人工智能像云计算和移动平台一样具有变革潜力，强调易用性和降低开发人员的准入门槛。 他们预见一个人工智能成本大幅降低的未来，从而推动更大的采用和创新。 最终，该合作旨在以更低的价格提供更多智能，从而推动新一波人工智能驱动的应用程序。
每日HackerNews RSS
## OpenAI 模型登陆 Amazon Bedrock：摘要
OpenAI 模型现已登陆 Amazon Bedrock，包括 Codex，以及由 OpenAI 提供支持的托管代理，目前处于有限预览阶段。此举解决了企业对数据安全和合规性的担忧，允许已经投资于 AWS 的组织在其现有基础设施和协议中使用 OpenAI 的技术。
许多公司更喜欢将数据保留在其 AWS 环境中，因为他们与 AWS 建立了数据处理协议并信任 AWS 的数据处理实践，从而避免了与 OpenAI 签订单独合同的需要。 此次集成也简化了对现有 AWS 合同组织的访问，绕过了为新供应商可能漫长的审批流程。
讨论强调了与直接访问 OpenAI 相比，成本可能相当，但强调了对于优先考虑数据治理和简化集成的企业而言的价值。 一些用户注意到 Azure 的 OpenAI 实现过去存在问题，希望 Bedrock 能够提供更流畅的体验。 此举被视为 OpenAI 应对 Anthropic 在 AWS 上强大的企业影响力的战略举措，并可能解决对其商业模式和企业采用的担忧。
一位忠实的 GitHub 用户（Ghostty/用户 1299）在每日使用 18 年——超过他生命的一半时间——后，将离开该平台。GitHub 一直是他个人和职业生涯的核心，是他快乐的源泉，也是他开源工作的中心，包括 Vagrant 的创建。他甚至希望有一天能在 GitHub 工作。 然而，最近频繁的宕机和不可靠性使得继续认真工作变得不可能。尽管他深爱着这个平台，并承认自己曾对其提出严厉批评，但他认为 GitHub 正在积极阻碍他贡献和发布软件的能力。 Ghostty 的项目 Ghostty 将迁移离开 GitHub，并保留只读镜像。虽然个人项目暂时会保留，但重点是为 Ghostty 社区寻找一个更稳定可靠的家园，探索商业和开源替代方案。他表达了希望有一天能够回归，但前提是 GitHub 的稳定性得到可证明的改善。
## 优化 AGENTS.md 文件以提升代码生成质量 对大量代码库中的众多 `AGENTS.md` 文件研究发现，其效果差异很大——最好的文件显著提升了代码生成质量（可比作模型升级），而最差的文件反而*降低*了质量。关键发现表明，**简洁通常更有效**。 有效的 `AGENTS.md` 文件（约 100-150 行）优先考虑**逐步披露**，仅在需要时链接到详细的参考文档。**程序化流程**（编号步骤）和**决策表**（提前消除歧义）显著提高了任务完成度和对编码标准的遵守程度。包含**实际代码库示例**可以提高代码复用率。相反，过多的警告（“不应该做什么”却没有“应该做什么”）会导致过度探索和降低输出。 至关重要的是，文档质量受其*环境*影响；围绕 `AGENTS.md` 的大量文档往往会掩盖其内容。研究强调**模块化文档**，专注于隔离的子模块。Agent 可以可靠地发现 `AGENTS.md` 和引用的文件，但难以处理深度嵌套或孤立的文档。 最终，一个简洁、集中的 `AGENTS.md` 文件，利用组织良好的参考资料，比一个全面但笨重的文档更有价值。
## Agents.md 与 Harness 管理：总结
这次 Hacker News 讨论的核心在于，对于有效使用 AI 代理，维护良好的“harness”（工具包）至关重要——这不仅包括 `AGENTS.md` 文件，还包括代码、技能、记忆和命令。良好的 harness 可以显著提高生产力，而管理不善的 harness 则会适得其反。
主要观点是，代理的性能受其*所有*交互内容的影响，而不仅仅是 `AGENTS.md`。用户分享了经验，即一些看似有用的工具（如 GSD 或 Strix Halo）实际上由于 harness 的不透明演变而导致结果恶化。
关键点包括：优先考虑项目清晰度（良好的文档、测试）以最大限度地减少对大量 `AGENTS.md` 文件的依赖；将 harness 保留在仓库内以实现可移植性和控制；以及认识到代理需要自我反思并随着时间的推移调整其指令。一些人提倡使用结构化上下文文件来管理和验证这些指令。
最终，讨论强调了在使用 LLM 时平衡探索和利用的持续挑战，以及理解 harness 如何影响代理行为的必要性。
## Warp：一种代理式开发环境
Warp 是一种新的、开源的开发环境，由终端构建，并由 OpenAI 赞助。它允许开发者利用内置的、由 GPT 模型驱动的编码代理，或集成他们自己的 CLI 代理，如 Claude、Gemini 和 Codex。
核心 UI 框架采用 MIT 许可，而其余代码库使用 AGPL v3。Warp 积极鼓励社区贡献，并提供简化的工作流程——可以提交问题并标记为“准备规范”或“准备实现”，供贡献者使用。
用户可以下载 Warp，使用提供的脚本在本地构建它，并访问全面的文档。提供了一个 Slack 社区以获取支持，并且预览版本提供对实验性功能的访问。Warp 优先考虑一个尊重和富有同情心的社区，并以明确的行为准则为指导。
## Warp 终端开源：摘要
Warp，一款现代终端应用程序，已将其源代码以 AGPLv3 许可发布。 创始人在一篇博文中概述了这一决定，旨在利用社区贡献并加速开发，尤其是在代理集成和定制方面。 虽然最初专注于更丰富的终端体验，但 Warp 越来越多地整合了 AI 功能，引发了不同的反应。
一些用户觉得 Warp 过于复杂，或者认为其发展方向偏离了传统终端。 另一些用户则欣赏其垂直选项卡以及与 AI 编码助手（Claude、Codex）的集成等功能。 团队已收到反馈，并正在努力增加定制选项，包括禁用 AI 功能的能力。
开源公告引发了关于 Warp 起源（它与 OS/2 “Warp” 操作系统无关）以及它对 Alacritty 等开源基础的依赖的讨论，这引发了关于互惠和对上游项目支持的问题。 这一举动也被一些人视为对 AI 驱动的开发环境领域竞争的回应。
美国破产申请在截至2026年3月31日的12个月内增加11.9%，总计591,850起——比前一年增加的529,080起显著增加。商业破产（增加11.4%至25,960起）和非商业破产（增加11.9%至565,890起）都促成了这一增长。 尽管这标志着在十年下降趋势之后的持续上升，破产申请在2022年6月达到380,634起的低点，但目前的水平仍然远低于2010年近160万的峰值。第七章破产仍然是最常见的，最新期间有369,702起申请，其次是第十三章破产，有11,700起。 详细统计数据，包括按破产类型和县的细分，可从美国法院行政办公室获得。
## 破产率上升，引发对原因的争论
最近的一份报告（uscourts.gov）显示，美国破产率上升了11.9%，引发了Hacker News上对潜在原因的讨论。一些人认为通货膨胀是关键因素，但一个反复出现的主题集中在体育博彩的兴起上，一项研究表明，合法博彩与破产率增加之间存在相关性（破产可能性增加10%）。
许多评论员认为，更广泛的经济焦虑和缺乏机会的认知，正在驱使人们通过赌博来绝望地改善他们的财务状况。另一些人强调破产本身的局限性，指出它无法免除学生贷款或赡养费等债务，这不成比例地影响了中产阶级和下层阶级。
对话还涉及系统性问题，包括财富不平等和政府政策的作用，一些人对当前政府下情况的改善表示悲观。几位用户指出，除了个人申请外，*商业*破产也大幅增加，并指出了疫情期间的刺激措施推迟了财务困境的影响。
跳过内容CJIT教程关于Dyne.orgCJITC，即时编译！一个受Terry Davis的HolyC启发的微型、可移植的C编译器和解释器，基于Fabrice Bellard的TinyCC，由Jaromil和Dyne.org团队打造教程下载
对不起。
## DOOM 在 AI 客户端上运行：摘要
开发者 MCPI 成功地将 DOOM 移植到 ChatGPT 和 Claude 等 AI 客户端中直接运行，使用了他们新的 MCP（消息内容协议）应用框架。该项目专注于精简的实现：一个启动 DOOM 会话的工具，一个回退到标准启动 URL 的机制，以及一个位于 `/doom/play` 的浏览器路由，所有这些都通过签名令牌进行保护。
核心挑战并非 *在* 浏览器中运行 DOOM——这已经通过 cloudflare/doom-wasm 和 Freedoom 得到证实——而是让单个会话在具有不同安全限制（iframe、CSP）的不同客户端上一致地工作。解决方案涉及一个简化的架构：一个小的 MCP 服务器，基于浏览器的 DOOM shell，以及直接在宿主 iframe *内* 渲染 DOOM 画布，从而避免了复杂的嵌入问题。
该项目托管在 Netlify 上，优先考虑有趣的用户体验。它避免了服务器端会话持久化，保持启动过程自包含。虽然最初包含更复杂的功能，如存档，但它被简化为专注于核心功能。结果是一个令人惊讶的实用且引人入胜的体验，展示了 MCP 应用作为 AI 环境中交互式表面的潜力。
对不起。
Waymo 正在扩展到俄勒冈州波特兰市，认为该市的创新精神和对可持续发展的承诺非常适合其自动驾驶技术。目前，Waymo 正在进行手动驾驶以绘制波特兰市独特的道路，并为最终部署做准备。 此举得到了波特兰市长凯斯·威尔逊的支持，他认为 Waymo 可以为该市“零 Vision”目标（消除交通死亡）做出贡献，并得到了“反对酒后驾车母亲” (MADD) 的支持，强调自动驾驶汽车可以减少酒后驾驶事件。 Waymo 报告称，在其技术运行的城市中，严重伤亡事故减少了 13 倍，并旨在将这些安全益处带给波特兰居民和游客。感兴趣的人可以在 waymo.com/updates 上注册以获取更新，并在服务上线时收到通知。
## Waymo 扩张与自动驾驶汽车讨论
一则Hacker News讨论围绕Waymo可能扩张至俄勒冈州波特兰市，引发了对未来交通的争论。最初的兴奋点在于将Rivian等车辆的便利性与Waymo的自动驾驶能力相结合的可能性，从而实现舒适安全的远距离旅行。
然而，评论者很快将讨论转向质疑在现有公共交通选择（如火车和公共汽车）的情况下，自动驾驶汽车的必要性，尤其是在美国，基础设施利用率不足。人们对“最后一公里”问题以及对私密、可控的旅行体验的渴望表示担忧。
对话深入探讨了在恶劣条件（如雪和冰）下自动驾驶的实际挑战，以及当前传感器技术的局限性。许多人强调了Waymo相对于人类驾驶员的优势——始终如一地遵守交通法规、提高弱势道路使用者的安全性以及提供更可靠的体验。
最终，讨论涉及更广泛的主题：美国的汽车中心文化、对改善公共交通的需求，以及广泛采用自动驾驶汽车的潜在社会影响，包括工作岗位流失以及休闲区域可能出现的拥堵加剧。
## constexpr 数组：从两步法到 `define_static_array` 在 C++ 中，创建包含堆分配的全局 `constexpr` 容器是不可能的——`constexpr` 求值存在于“编译器的想象中”，无法产生运行时指针。虽然 C++20 允许在编译时使用 `new` 和 `delete`，但防火墙阻止在运行时访问该内存。 “constexpr 两步法”作为一种解决方法出现：在编译时计算一个 `std::vector`，然后将其内容复制到全局 `constexpr std::array` 中。C++26 引入了 `std::define_static_array`，用于更简洁的编译时数组生成，直接将数据存储到目标文件中。 然而，`define_static_array` 存在局限性。它仅支持“结构化类型”（如 `int`），难以处理指向字符串字面量的指针，并且无法处理只能移动的类型或创建可变数组——与更灵活的两步法相比。这是由于它依赖于模板参数和常量存储。 提出的更改 (P3380R1) 旨在通过允许用户定义的结构化类型来扩展 `define_static_array` 的支持，但完整的解决方案可能需要在未来的 C++ 标准中提供一种新的机制来操作静态存储。
对不起。
## GitHub 漏洞：通过 Git Push 导致的关键 RCE (CVE-2026-3854) Wiz Research 发现 GitHub 内部 git 基础设施存在一个关键漏洞 (CVE-2026-3854)，允许已认证用户通过单个 `git push` 命令在 GitHub.com 和 GitHub Enterprise Server (GHES) 上执行任意代码。该漏洞源于 GitHub 内部协议中的一个注入漏洞——具体来说，是在 git 操作期间使用的 `X-Stat` 头部中，缺乏对用户提供数据的清理。 利用方式是通过 `git push` 选项注入恶意数据来绕过安全检查，最终实现远程代码执行 (RCE)。在 GHES 上，这导致了服务器完全被攻破。在 GitHub.com 上，它允许访问共享存储节点上的数百万个公共和私有仓库，可能导致跨租户的数据泄露。 GitHub 在 6 小时内缓解了 GitHub.com 上的问题，并发布了 GHES 的补丁。然而，截至报告发布时，仍有 88% 的 GHES 实例存在漏洞，需要立即升级。这一发现凸显了 AI 增强工具在识别闭源二进制文件中的复杂漏洞方面的强大功能，并强调了在多服务架构中安全处理数据的重要性。
## GitHub 漏洞 (CVE-2026-3854) 概要
Wiz.io 发现 GitHub Enterprise Server (GHES) 存在一个关键的远程代码执行 (RCE) 漏洞 (CVE-2026-3854)，源于简单的输入验证失败。具体来说，`babeld` 服务在处理 Git 推送选项中的用户提供数据时存在问题，允许攻击者通过 `X-Stat` 头部中的分号注入命令。
此次发现突显了人工智能增强逆向工程的力量，LLM 代理加速了对复杂系统内部结构和漏洞识别的理解。虽然该漏洞并非显而易见，但人工智能工具显著加快了流程。在发布补丁 7 周后，仍有 88% 的本地部署 GHES 实例存在漏洞。
讨论的重点是维护 GHES 的挑战——包括困难的升级和对 GitHub 支持不足的看法——导致一些人探索 Forgejo 等替代方案。人们还对微软收购后 GitHub 的可靠性以及其他平台可能存在类似问题表示担忧。