最新

我希望听取那些真正构建或运营过长期企业软件的人的观点。 背景（故意保持通用）： 我们有一款成熟的、能够产生收入的企业应用程序，已经在生产环境中运行多年。 半技术领导层（没有工程背景）正在积极考虑启动一款新产品，该产品将使用基于大型语言模型（LLM）的工具（如AI代码生成、快速原型制作等）构建，认为： - 现代AI工具显著降低了构建成本，LLM在未来将会有所改善。 - 新系统试图复制一家成熟竞争对手在大约10年内构建的大部分功能。 - 客户可以选择逐步迁移（旧系统仍然得到支持）。 - 这是一款软件产品，旨在用以替代当前应用程序的所有操作复杂性，目标是使其成为可再销售的产品。 - 使用LLM工具创建的早期演示版本是最终生产就绪的良好代理。 向所有者的推介是，这一过程可以比历史上所需的时间和成本快得多，主要因为“AI改变了软件构建的经济学”。 我并不是反对LLM——我每天都在使用它们，并且看到了实际的生产力提升。我的担忧更偏向结构性： - LLM在加速搭建和迭代方面似乎表现出色，但不清楚它们在多大程度上减少了： - 操作复杂性 - 数据正确性问题 - 迁移风险 - 长尾客户的边缘案例 - 支持和责任成本 - 演示看起来令人信服，但并没有揭示失败模式。 - 感觉我们是在将一家成熟竞争对手的最终状态与一个全新系统的初始构建成本进行比较。 我试图对自己的思考进行理性检查。 向社区提出的问题： - 你们见过基于LLM的企业产品重建在实践中成功吗？ - “便宜和快速”的叙述通常在哪里崩溃？ - AI是否实质性地改变了长期成本曲线，还是主要影响了早期的速度？ - 如果你在为非技术背景的所有者提供建议，你会坚持让他们明确承认哪些风险？ - 有没有一种原则性的方式来支持或反对这一策略，而不显得像“传统悲观主义者”？ 我特别希望听到以下人士的回答： - 拥有大规模生产系统的人 - 尝试进行全部或部分重写的创始人 - 在演示已经售出后加入AI优先的全新项目的工程师 感谢分享任何真实的经验、成功故事或警示案例。

我在1月14日为Cursor Pro支付了20美元。三天后，代币用尽，性能变得无法使用。我在1月17日申请了退款（在7天内）。他们的AI机器人“Sam”多次拒绝，然后人类客服“Charlene”也拒绝了，理由是“反映使用情况”，适用于3/30天。现在他们又把我转回了AI机器人。 这现在是正常的SaaS操作吗？三天=一个月没有退款？ 交易号：#395540957397

大家好！<p>我很高兴与大家分享我在学术研究中开发的一个项目：土耳其筛选引擎（TSE v1.0.0）。<p>这个引擎是N/6位方法论的实现，这是一种新颖的方法，旨在在最大化素数生成的吞吐量的同时，最小化内存占用。<p>无论你是数学爱好者、密码学研究者，还是高性能计算（HPC）爱好者，我都非常希望能听到你的反馈！<p>大家好，<p>我一直在优化素数筛选，特别关注在不牺牲吞吐量的情况下减少内存占用。我开发了一种名为N/6位的方法论，并将其实现为一个名为土耳其筛选引擎（TSE）的工具。<p>该项目现已开源，我希望能从社区获得关于实现和性能的反馈。<p>技术概述：<p>方法论：N/6位结构（详见链接论文）。<p>实现：使用NVIDIA CUDA和OpenMP的混合并行性。<p>目标：在现代硬件上最大化效率。<p>我为有兴趣进行基准测试或代码审查的人提供了预编译的二进制文件。<p>GitHub：[<a href="https://github.com/bilgisofttr/turkishsieve" rel="nofollow">https://github.com/bilgisofttr/turkishsieve</a>]<p>Zenodo（学术论文）：[<a href="https://zenodo.org/records/18038661" rel="nofollow">https://zenodo.org/records/18038661</a>]<p>我非常希望听到你们对内存管理的看法，或者如果你们有来自不同GPU架构的结果，也请分享。

我在YouTube视频中看到了一些部分无法跳过的色情广告（包括露骨的音频和视频），这些广告宣传的是男性壮阳药，甚至出现在教育和儿童内容中。<p>我已经立即向谷歌举报了这个问题。<p>那是一个多星期前的事了。<p>至今没有得到任何回复，而我现在在不同的浏览器和设备上已经多次看到了这个广告。<p>到底是有真实的人在审核这些广告，还是谷歌把一切都自动化到只剩下机器人了？<p>看起来他们现在对任何人都毫无审核地出售广告，只顾着赚钱。<p>恶意广告由来已久，但这次的情况是我见过的最严重的。

嗨，HN， 我是一名高中开发者，也是终端自定义的忠实粉丝。在 Neofetch 被归档后，我想构建一个感觉“即时”的工具，并充分利用 Rust 的性能。 这就是我创建 StarFetch 的原因。 为什么要试试它呢？ - 零延迟：它的设计足够快速，可以直接放入你的 .zshrc 文件中，而不会感到任何延迟。 - Rust 驱动：这是我学习系统编程的好方法，同时为用户提供一个内存安全的二进制文件。 - 输出简洁：专注于核心内容，没有多余的负担。 我在自己的环境中与 yabai 和 sketchybar 等工具一起使用它，开发过程非常愉快。我最近甚至将它提交到了“本周 Rust”栏目。 我很想听听你们对代码实现的看法，或者你们认为到 2026 年现代获取工具应该具备哪些功能。 GitHub：[https://github.com/Linus-Shyu/StarFetch_Core] 感谢你的关注！

- 比Ghostty Docs更直观的视图 - 直接编辑配置，无需打开新的文本编辑器 - 按名称或描述搜索

嗨，HN， 我构建了一个早期原型，探索自我保管医疗记录在实践中的可行性，使用加密证明而不将敏感健康数据上链。 我正在测试的问题是印度尼西亚的医疗数据碎片化，患者记录分散在各个医院，紧急情况下往往无法获取。 区块链仅用作不可篡改的审计层；该系统设计为即使链发生变化也能正常工作。 关键设计选择： - 不在链上存储医疗数据（仅存储哈希，用于验证和审计） - 所有记录在链外加密 - 患者通过基于二维码的分享控制访问（医生不接触加密货币） - 将区块链视为验证层，而非存储层 迄今为止的经验教训： - 医院不会运行区块链基础设施 - 医生不会管理私钥 - 用户体验比加密技术更重要 - 密钥恢复比预期更困难 - 监管在早期就影响架构设计 这还不是生产就绪的解决方案，尚未解决监管、密钥恢复或医院互操作性的问题。 我主要寻求批判性的反馈： - 这种方法的根本缺陷在哪里 - 我应该考虑哪些更简单的设计 - 医疗从业者的现实检查 代码库和技术细节在自述文件中。 欢迎提问。

大多数零知识证明系统都针对服务器级硬件进行了优化，配备了大量的内存。在扩展到工业规模的跟踪（超过2^20行）时，它们通常会遇到“内存墙”，在这个阶段，内存分配和数据移动成为比实际计算更大的瓶颈。 我正在开发Hekate，这是一个用Rust编写的零知识引擎，采用零拷贝流式模型和混合平铺评估器。为了测试其极限，我在一台使用Keccak-256的Apple M3 Max笔记本电脑上与Binius64进行了正面基准测试。 结果突显出显著的架构差异： 在2^15行时：Binius64更快（147毫秒对比202毫秒），但Hekate的内存效率已经高出10倍（44MB对比约400MB）。 在2^20行时：Binius64的内存使用达到72GB，在笔记本电脑上进入了交换地狱。而Hekate在仅使用1.4GB内存的情况下，处理相同的工作负载只需4.74秒。 在2^24行（16.7M步）时：Hekate在88秒内完成，峰值内存为21.5GB。由于该硬件的内存不足/交换，Binius64无法完成任务。 核心区别在于“物化与流式处理”。许多引擎在Sumcheck和PCS操作期间会在内存中物化并复制大量多项式，而Hekate则通过CPU缓存以平铺的方式进行流式处理。这将零知识证明的单位经济学从每小时2.00美元的高内存云实例转变为每小时0.10美元的普通硬件或本地边缘设备。 我希望能从社区获得反馈，特别是那些在二进制域、GKR以及内存受限的SNARK/STARK实现方面工作的人员。