问HN：在编写代码之前，您如何对产品需求进行压力测试？
嗨，HN，
我是一名质量保证工程师，最近开始独立开发。
多年来，我发现了一个相同的模式：许多生产环境中的错误并不是由于糟糕的代码，而是由于不明确或不完整的需求——边缘案例和在开发开始之前从未明确的假设。
为了探索这个问题，我为自己构建了一个小产品，它可以从测试/逻辑的角度对一个功能想法或粗略规格进行压力测试：在编写任何代码之前，揭示隐藏的假设、缺失的验收标准和边缘案例。
在我构建自己的项目时，我一直在使用这个工具，它确实很有用——但我想了解这是否是其他工程师或创始人真正感受到的问题，还是仅仅是我作为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.