… 但有些人有出色的产品品味，他们可以通过试用产品来判断是否满足真实用户的需求 - 其中一些人是早期采用者客户，有时是优秀设计师，有时是产品经理。他们确实需要试用产品（或原型）才能真正了解是否有效。我作为初级工程师时，总是对产品经理在书面规格中设计一个功能，我们实现之后，但在发布前尝试时，他们却想要完全重新设计感到沮丧，这往往需要糟糕的黑客手段或重大的技术设计变更才能满足新要求。但经过15年看到一些在纸上看起来很棒的想法在用户身上却失败的经历，同时注意到真正出色的产品人员在功能开发完成后、发布给用户之前就能准确判断哪里有问题，我学会了对这类重写保持灵活。而这正是vibecoding可以加速的类型。
源讨论开发速度不是瓶颈原帖 149 条评论 · 导入时统计把你的经验，加入这段讨论。
有趣的是，即使这是正确的决定，回溯起来也会让人感到沮丧，我肯定也经历过这种感觉。 另外，过去我曾为不同的媒体机构制作交互式地图和图表，人们经常长时间争论是否应该制作柱状图或折线图（实际的问题和可视化方法通常更为复杂）。 我记得有时会建议同时制作两种方案并进行测试，但直觉上人们总觉得这不切实际，尽管这通常比讨论花更少时间，而且能产生更具体的结果。
完整原文我们有句说法：我们的客户总是知道自己想要什么。直到他们得到了，他们才知道自己想要的是不同的东西。 不要把这当作抱怨。这只是基本的行为观察。我们说我们做的事情和我们真正做的事情是不同的。同样，我们说我们想要的东西和我们真正想要的东西也是不同的。 冒犯一点说：我们说我们想要定期锻炼以保持健康，但我们真正想要的是坐在沙发上刷手机，手里拿着啤酒。 在产品开发的背景下，我们对一个想象中的（甚至只是草图的）解决方案的态度，与对一个实际运行的软件的态度截然不同。因此，很明显我们不可能第一次就做对。 我们可能在朝着正确的方向努力，但许多产品团队甚至做不到这一点。对他们来说，开发速度只是计算在风险投资公司撤资前剩余时间的时钟。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。