最新

我做了一个网站，灵感来源于我最喜欢的 GitHub 仓库 illacceptanything/illacceptanything。只不过，它不是 GitHub 仓库，而是一个网站；它也不接受提交，而是接受提示。 以下是 API： <a href="https://api.ill-serve-anything.com" rel="nofollow">https://api.ill-serve-anything.com</a> POST /prompt {"prompt": "..."} GET /prompt/:id GET /prompts?limit=N 网站已经上线一天了。它似乎在禅意花园、委内瑞拉新闻、加密货币交易所和某个一直在胡说八道香蕉的人之间交替出现。 我一直在尝试在网站本身嵌入一个小的编辑功能，但人们总是把它搞坏，所以我放弃了。 如果你弄坏了它，请发送一个提示来修复它。

我构建了一个由人工智能驱动的加密货币分析仪表盘，提供实时买入/卖出信号、多时间框架分析、指标热力图和趋势评分。 目标是为交易者提供一个简洁、快速的界面，无需在数十个图表之间切换。 非常希望得到Hacker News社区的反馈。

Hi HN， 我是一名 QA 工程师，最近开始独自创业。 多年来，我一直看到同样的模式：许多生产环境中的 bug 并非源于糟糕的代码，而是源于不明确或不完整的需求——在开发开始之前从未明确说明的边缘情况和假设。 为了探索这个问题，我最终为自己构建了一个小产品，它接收一个功能想法或粗略的规范，并从测试/逻辑的角度对其进行压力测试：在编写任何代码之前，揭示隐藏的假设、缺失的验收标准和边缘情况。 我一直在使用它来构建自己的项目，并且它很有用——但我试图了解这是否是其他工程师或创始人真正感受到的问题，或者这仅仅是我的 QA 偏见。 我很好奇： - 在编写代码之前，您个人如何验证需求？ - 您是否曾因“本应更早发现”的逻辑漏洞而吃亏？ - 您是否依赖文档、清单、评审或其他方式？ 如果需要，很乐意分享更多细节——主要目的是了解其他人如何处理这个问题。

大家好， 我以惨痛的教训发现，将 Perplexity 会话导出为 PDF 格式时，如果页面数达到约 90 页，会导致大量内容丢失。 在就此事提交工单后，与一位代表的简短对话毫无帮助且令人困惑。对方声称“导出为 PDF”功能仅导出单个“线程”，要导出整个会话，必须单独选择并导出每个所谓的线程。这完全是错误的。 实际上，通过右上角的“…”菜单/“导出为 PDF”选项，根本没有方法可以选择线程。我用从 1 页到 170 页不等的各种会话进行测试，结果表明线程与导出无关。 导出页面数少于 90 页的会话通常*会保留所有内容，而 93 页的会话则没有，但 95 页和 170 页的会话却可以。这表明字符限制（如果这是原因）是可变的，因为 170 页几乎可以肯定包含比 90 页更多的字符。 这里要说明的根本问题是，无论原因是什么，在当前 UI 界面下，由于缺乏文档、通知等，数据丢失是不可避免的。 *我在提交工单后观察到了变化，并且已经进行了修改。情况以前更糟，现在有所缓解，但问题依然存在。