最新

我制作了一个网站，灵感来自我最喜欢的 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 这个网站已经上线一天了。它似乎在一个禅意花园、关于委内瑞拉的新闻、一个加密货币交易所，以及一个总是在说“香蕉”的人之间交替。 我一直试图在网站内部嵌入一个小的编辑功能，但人们总是把它拆掉，所以我已经放弃了。 如果你把它弄坏了，请发送一个提示来修复它。

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

嗨，HN， 我是一名质量保证工程师，最近开始独立开发。 多年来，我发现了一个相同的模式：许多生产环境中的错误并不是由于糟糕的代码，而是由于不明确或不完整的需求——边缘案例和在开发开始之前从未明确的假设。 为了探索这个问题，我为自己构建了一个小产品，它可以从测试/逻辑的角度对一个功能想法或粗略规格进行压力测试：在编写任何代码之前，揭示隐藏的假设、缺失的验收标准和边缘案例。 在我构建自己的项目时，我一直在使用这个工具，它确实很有用——但我想了解这是否是其他工程师或创始人真正感受到的问题，还是仅仅是我作为QA工程师的偏见。 我很好奇： - 你个人在编码之前如何验证需求？ - 你是否曾因“应该早些发现”的逻辑漏洞而受到影响？ - 你依赖文档、检查清单、评审，还是其他什么？ 如果有用，我很乐意分享更多细节——我主要是想了解其他人是如何处理这个问题的。

大家好， 我发现，导出 Perplexity 会话为 PDF 时，当页面数达到约 90 页时，会导致大量内容丢失，这一点我是通过亲身经历得出的。 在就此问题提交工单后，与客服的简短对话并没有提供帮助，反而让我感到困惑。客服表示“导出为 PDF”功能仅导出单个“线程”，而要导出整个会话，必须逐个选择并导出这些所谓的线程。这显然是错误的。 实际上，无法通过右上角的三点菜单/导出为 PDF 选项选择线程。对不同会话进行测试，从 1 页到 170 页的导出结果显示，线程并不相关。 在 90 页以下的导出通常*能够保留所有内容，而 93 页的导出却没有保留，但 95 页和 170 页的导出则保留了所有内容。这表明字符限制（如果这是原因的话）是可变的，因为 170 页的内容几乎肯定会比 90 页多。 无论原因是什么，根本问题在于，在当前用户界面下，由于缺乏文档、通知等，数据丢失是不可避免的。 *我注意到在提交工单后情况有所变化，已经进行了修改。之前的情况更糟，现在稍微好一些，但问题依然存在。