在当下人工智能快速渗透的环境里，很多产品经理、开发者、创业者都会问：为什么我们明明已经有了大模型，却依然在需求落地上频频翻车？知乎上有人提过一个问题：大模型是不是万能的需求翻译器？底下一个高赞回答说，大模型的聪明，只能解决语言层面的模糊，却无法替你判断业务逻辑的正确与否。今天我就结合需求工程的发展脉络、行业案例和前沿研究，聊聊背后的关键：未来的稀缺，不是写得快，而是谁能把模糊的业务，刻成机器可执行的规约。

如果我们往回看，软件工程史上有三道永恒的坎：消歧、冲突解决、约束建模。Fred Brooks 在《人月神话》中就说过：“软件的本质难题在于概念化，而不是实现。”消歧，就是要把含糊的自然语言转化为精确的定义。冲突解决，就是面对多方需求拉扯时做出可落地的平衡。约束建模，则是要在资源有限的情况下，把需求装进现实的盒子。可惜的是，很多团队往往停留在“需求文档就是一堆文字”的阶段，导致同一个功能，开发和测试的理解南辕北辙。直到现在，AI的出现才让人看到了把自然语言落到 DSL（领域专用语言）、契约与验收标准的可能。

我想起一个真实的案例。某互联网大厂在做智能客服时，最初的需求只有一句话：“让用户能快速解决问题。”结果不同团队各自理解：有的觉得是提升知识库覆盖率，有的觉得是缩短响应时间，还有的觉得是改进转人工体验。结果花了半年，做出三个互不兼容的版本。后来，他们引入事件风暴（Event Storming）的方法，强制把业务事件拆解出来，并且用 AI 协助生成领域建模的草图，才逐渐统一了理解。到这时大家才明白，模糊需求的最大敌人不是技术，而是语言的二义性。所以，如果你要推动一个复杂项目，第一步就是：把需求写成“机器能读懂”的验收条件，而不是仅仅让人感觉懂。

正如 Eric Evans 在《领域驱动设计》中指出的：“软件核心难题是领域复杂性，而领域模型就是团队共同语言的载体。”领域建模的价值，在于为产品和架构建立“语义接口”。有界上下文的划分，让不同团队能够在清晰的边界内对话，而不是互相踩坑。故事总是有转折。有个创业团队在做跨境电商平台，起初他们写的需求文档就是“让卖家轻松上架商品”。结果开发实现的是批量上传，运营却要的是智能推荐属性，两边吵到不可开交。最后他们尝试用 AI 来生成事件风暴图谱，把“上架”具体拆分为“选择商品、录入规格、校验合规、推送审核”几个事件，再在边界上下文内明确责任，才算避免了返工。于是他们学到的教训就是：任何模糊的需求，只有沉淀成结构化的事件流，才能真正变成团队的“喂养数据”。所以，如果你想减少返工，就要先推动团队用 AI 协助沉淀一个能复用的事件建模模板。

更有意思的是，角色的迁移正在发生。过去流行“提示词工程师”，大家忙着研究如何写 prompt 才能让 AI 输出满意的结果。但未来真正稀缺的，是“规格工程师”与“数据语义师”。在 ACM Transactions on Software Engineering 2023 年的一篇论文里，研究者就提出：“生成式 AI 的长期瓶颈，不是推理能力，而是需求规约的质量。”换句话说，谁能把需求写成机器可读的规范，谁就是新的护城河。我认识一位资深产品经理，他起初以为会被 AI 替代，于是焦虑不安。后来他转向研究如何用 DSL 写 PRD，甚至设计了一套“验收用例—反例—失败模式”的规范模板，结果团队的返工次数减少了三分之一。动作的指向性非常清晰：如果你担心自己被替代，第一步要做的，不是卷提示词，而是学会写可机读的 PRD。

当然，并不是所有场景都适合这种规格化思维。在初创期的探索场景里，快速试错比严格规约更重要。因为此时的目标不是降低返工，而是探索方向。如果你花太多时间写规范，反而会错过市场窗口。正如 Steve Blank 在《精益创业》中说的：“创业的本质不是做产品，而是寻找可持续的商业模式。”所以在高度不确定的早期，先去试，再去写，是更合理的做法。但一旦方向确定，再继续依赖拍脑袋的需求，只会埋下无尽的返工地雷。

如果让我给出一个收束，那就是：如果只做一件事，先推动团队沉淀一个可机读的 PRD 模板。想更进一步，再引入领域建模与事件风暴，让需求成为 AI 的训练数据；最后，培养自己作为“规格工程师”的身份，从 prompt 升级到 spec，把模糊变成规约，把规约变成护城河。你有没有遇到过类似的返工噩梦？欢迎在评论里分享，你的故事也许就是别人顿悟的钥匙。

合十，如夜话，至此