……不幸的是，如果这两种情况中的一种成立，即"实际规格和需求被正式化"，虽然听起来合乎逻辑，可能有所帮助，但根据我的经验，它对挽救任何实质性的项目帮助甚微（我见过很多这样的情况）。常见问题是，业务方/客户/经理被迫签署超出其专业能力范围的正式文件，或者工程师被束缚在一些没有意义的承诺中，他们对领域中被视为常识的知识一无所知，因此无法对未明说的内容进行情境化处理。这些被正式化的文档大多变成了互相指责的武器。我还多次看到，多年的正式规格和需求工作完成后，什么产品都没产出，项目在第一行代码进入测试之前就被中止了。我之前也举过这个例子：当新冠疫情封锁开始时，有很多数字化项目已经规划了数年，并且预算也准备了数年，但最终却由一个三人应急团队在长周末内匆忙地进行了规格制定、编码和部署。……
源讨论反对对话式界面的论点原帖 217 条评论 · 导入时统计> 如果你有一支由资深、有经验且聪明的工程师组成的团队，你可以用几句话表达一个愿望，相信他们会在有相关模糊之处时主动寻求信息，并期待一个良好的结果 这是一种谬误。一位有经验且聪明的工程师会告诉你的第一件事是，带着你的「几句话的愿望」离开，并在以某种方式正式化实际的规格和需求之前不要回来。如果你自己都不了解你想要什么，这意味着数小时/数天/数周/数月/甚至数年的来回沟通和错误的解决方案以及时间的浪费，因为自然语言太慢且容易丢失信息（这篇文章在这个问题上说得非常准确）。 关于「主动寻求信息」，我最喜欢的一个例子是，当你今天问我一个问题，我回答了，但一周后你再问我同样的问题时，我却给出了不同的答案（甚至可能是相反的答案），因为忘了或者只是改变了想法。…
完整原文把你的经验，加入这段讨论。
> 我也多次看到，多年的形式化规格和需求工作之后，什么成果都没有，项目甚至在第一行代码进入测试之前就被中止了。 这表明没有人真正了解他们想要什么。指望某人比你更了解某事是疯狂的，而希望一个对话式界面比你更了解某事则令人发笑。
完整原文我是一名产品经理，我以编写适当细节水平的规格说明书而自豪，而“适当”在很大程度上取决于具体情境。 但我仍然会因为LLM而变得懒惰，像不好的产品经理和工程团队那样陷入迭代中。“写一个SQL查询来按手势和月份查看用户”。 “现在把时间单位设为参数”。 “现在将功能转换为列”。 “现在按层次结构分组功能”。 “现在将功能表移到WITH中”。 我的观点和经验是，LLM们有无限的耐心，并且能快速响应需求，因此它们更适合探索，而不是人类团队。也许可以说是敏捷，但程度远超我们在人类世界中所追求的，因为这会非常昂贵，并导致争吵。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。