Ask HN: 在编写代码之前，你如何对产品需求进行压力测试？
1 分•作者: SoulLab•6 个月前
Hi HN，
我是一名 QA 工程师，最近开始独自创业。
多年来，我一直看到同样的模式：许多生产环境中的 bug 并非源于糟糕的代码，而是源于不明确或不完整的需求——在开发开始之前从未明确说明的边缘情况和假设。
为了探索这个问题，我最终为自己构建了一个小产品，它接收一个功能想法或粗略的规范，并从测试/逻辑的角度对其进行压力测试：在编写任何代码之前，揭示隐藏的假设、缺失的验收标准和边缘情况。
我一直在使用它来构建自己的项目，并且它很有用——但我试图了解这是否是其他工程师或创始人真正感受到的问题，或者这仅仅是我的 QA 偏见。
我很好奇：
- 在编写代码之前，您个人如何验证需求？
- 您是否曾因“本应更早发现”的逻辑漏洞而吃亏？
- 您是否依赖文档、清单、评审或其他方式？
如果需要，很乐意分享更多细节——主要目的是了解其他人如何处理这个问题。
查看原文
Hi HN,<p>I’m a QA engineer by background and recently started building solo.<p>Over the years, I kept seeing the same pattern: many production bugs don’t come from bad code, but from unclear or incomplete requirements — edge cases and assumptions that were never made explicit before development started.<p>To explore this, I ended up building a small product for myself that takes a feature idea or rough spec and stress-tests it from a test/logic perspective: surfacing hidden assumptions, missing acceptance criteria, and edge cases before any code is written.<p>I’ve been using it while building my own projects, and it’s been useful — but I’m trying to understand whether this is a problem other engineers or founders actually feel, or if it’s just my QA bias.<p>I’m curious:
- How do you personally validate requirements before coding?
- Have you been bitten by logic gaps that “should have been caught earlier”?
- Do you rely on docs, checklists, reviews, or something else?<p>Happy to share more details if useful — mostly here to learn how others approach this.