最新

嗨，HN， 现在人工智能能够生成代码，我在思考使用人工智能或进行“氛围编码”的每个人是如何考虑维护问题的。 软件不可避免地会因为弃用、更新、安全建议等原因而出现故障，而现在软件、应用程序、网页应用和SaaS的生成变得相对简单。 软件的技术债务迅速增加（添加API、数据库、分析、功能、更多库、更多文件、更多代码路径等），因此软件出现故障的可能性也随之增加，尤其是在“氛围编码”流行的情况下。 大家对此是怎么考虑的？ 你们只是让ChatGPT、Claude和其他大型语言模型“修复代码”，然后祈祷一切顺利吗？还是在添加单元测试和集成测试或者其他措施？ 谢谢！

在网络安全领域，关于某些SOC 2审计报告的合法性和质量的讨论开始浮现，社区成员对疑似存在的可疑SOC 2认证进行了辩论。尽管细节尚未得到验证，但这一讨论反映了人们对审计严格性和自动合规声明可信度的更广泛担忧。 这一辩论发生在2026年SOC 2需求不断增长的背景下，组织在审计的全面性与商业合规截止日期之间苦苦挣扎。随着SOC 2合规要求的不断演变，关于审计深度不一致的担忧可能会影响企业风险团队在评估供应商时对SOC 2文档的解读和依赖，特别是在评估第三方风险和供应商保证时。

特斯拉已申请了一项专利，标题为“基于8位计算硬件的高精度复数旋转位置编码计算”（US20260017019）。<p>该专利中包含多个概念，但似乎这项技术将在最新的AI5芯片中应用。一个很好的介绍可以在这里找到：https://www.youtube.com/watch?v=GG9yOsPEGek<p>其中一个关键思想是使用对数和加法，而不是乘法。这种方法更快且能耗更低。<p>这将对NVIDIA造成影响。

在1月11日，谷歌和Shopify宣布推出通用商业协议（ucp.dev）。这是一种开放标准，允许任何应用程序在不需要API、集成或中介的情况下查询跨电子商务平台的产品。 AskUCP是基于该协议构建的首批应用之一。 目前，如果你想在线购买某样东西，你必须知道哪个商店在销售。你可能会去亚马逊，或者去一个Shopify商店，或者去Etsy。每个平台都有自己的搜索功能、界面和结账流程。这种体验是碎片化的，因为基础设施是孤立的。 UCP在协议层面上改变了这一点。如果产品以标准格式描述，任何应用程序都可以发现它们。你不需要每个平台的许可，也不需要构建集成。任何人或任何AI代理只需查询该协议即可。 AskUCP旨在提供一个统一的在线商业视图。你只需搜索一次，就能看到来自整个生态系统的产品。目前，这意味着整个Shopify目录。随着更多平台采用UCP，它们的产品也将变得可探索。最终，这应该涵盖所有产品。 这只是一个概念验证。现在还处于早期阶段，存在一些粗糙的地方。欢迎告诉我你的想法、改进建议、创意等。

这篇帖子在首页上停留了大约1到2个小时，然后就消失了。在这段时间内，它获得了大约300个积分，这远远超过了大多数在Hacker News首页上停留1到2天的帖子。即使你翻到第2页或第3页、第4页或第5页，也找不到这篇帖子！ 这似乎很奇怪。YCombinator对此有任何兴趣吗？

嗨，HN， 我开发了一个名为“文档复制计划器”的小型浏览器工具，旨在帮助人们确定需要保留多少份重要文件，采用何种格式，以及存放在哪里，全部操作均可离线进行。 主要功能： - 支持护照、身份证、合同、收据、票据等多种文件 - 生成主要副本、备份副本和应急副本的计划 - 可下载的PDF或可打印的清单 - 完全在浏览器中运行——无需账户、无需上传、无需追踪 动机：大多数人将敏感文件存储在云应用或电子邮件中，这增加了泄露风险。这个工具提供了一个简单、可操作的计划，让用户在不依赖服务器或第三方的情况下安全地保留副本。 您可以在这里试用：proofpocket.com/doc-copy-planner 我很想听听HN社区的反馈： - 这种离线文档规划的方法是否合理？ - 在工作流程或用户体验方面有什么可以改进的地方吗？ - 在安全性或可用性方面，有没有我遗漏的边缘案例？ 感谢您查看这个工具！

这个PDF模式匹配器是一个本地网页应用，允许您比较两堆文档中的正则表达式匹配。这对于文档对账等场景非常有用。<p>我最初为我父母的小企业创建了一个Python NiceGUI应用，以便他们能够验证所有的送货单是否都包含在货运信用单中。<p>我将其重新实现为一个基于浏览器的Nuxt应用。<p>我使用PDF.js从PDF中提取文本，并且还在尝试使用Tesseract.js进行光学字符识别（OCR）。Papaparse用于生成结果的简单CSV报告。

我发布了一个新的 Python ASGI/WSGI 应用服务器。这可能对以下人群特别感兴趣： - 对服务器技术感兴趣的 Python 开发者，尤其是已经在使用 Envoy 的人 - Envoy 用户可以看到动态模块所支持的用例 - Rust 爱好者可以看到它如何在两个非 Rust 生态系统（Envoy 和 Python）之间架起桥梁 请注意，这是我在 Rust 中的第一个真正项目——虽然在开发过程中我努力学习 Rust 的习惯用法，但我怀疑这是否能算作一个完全符合 Rust 风格的项目。 我对支持 HTTP/2 trailers 的 Python 应用服务器感兴趣，以便能够将 gRPC 作为普通应用程序提供，同时支持非 gRPC 端点。在查看现有选项时，我注意到在连接套接字、流控制等方面存在很多复杂性。来自 Go 的我习惯于 net/http 提供功能齐全、生产就绪的 HTTP 服务器，几乎不需要额外工作。但由于多种原因，从 Go 驱动 Python 应用并不现实。 巧合的是，Envoy 发布了对动态模块的支持，允许在 Envoy 中运行任意代码，并提供了 Rust SDK。我想这将是一个有趣的实验，看看这是否真的能驱动一个完整的 Python 服务器——我原本认为不可能。但在动态模块中暴露了一些更多的控制选项后——它实际上成功了，pyvoy 应运而生，这是一个动态模块，加载 Python 解释器来运行 ASGI 和 WSGI 应用，从 Envoy 的 HTTP 过滤器进行数据转换。还有一个命令行工具，可以处理运行 Envoy 并将模块指向应用——这绝对没有 net/http 那样方便，但我很感激复杂性仅存在于启动阶段。pyvoy 不需要处理 HTTP、TLS 等，所有这些都由经过实战考验的 Envoy 堆栈处理，我们获得了包括 trailers 和 HTTP/3 在内的所有 HTTP 功能。 通过对 trailers 的支持，pyvoy 在服务器上驱动了 connect-python 的 gRPC 协议支持（<a href="https://github.com/connectrpc/connect-python" rel="nofollow">https://github.com/connectrpc/connect-python</a>），允许它们在现有的 Flask 或 FastAPI 应用中根据需要提供。值得注意的是，它是唯一一个在没有不稳定表现的情况下通过所有 connect 的一致性测试的服务器。重要的是要指出，当禁用需要 HTTP/2 的功能时，uvicorn 也能可靠通过。当不需要双向流或 gRPC 时，它是一个很好的服务器——不幸的是，我们尝试的其他服务器在处理客户端断开连接、保持活动等方面表现不稳定。这并不让我感到惊讶，因为我早就看到实现特别是 HTTP/2 的可靠性是多么困难，我很感激 pyvoy 可以依赖 Envoy 来处理这些问题。 看起来 pyvoy 是一个快速（始终基于自己的工作负载进行基准测试）、可靠的服务器，不仅适用于 gRPC，也适用于任何工作负载。它还可以直接使用任何 Envoy 功能，并且可以替代一对 Envoy + Python 应用服务器。我目前在生产环境中以低规模使用它，服务于 Django、FastAPI 和 connect-python。 欢迎分享您对这个项目的想法。感谢您的阅读！