当大模型学会用系统思维审视需求：MARQ架构揭示AI工程化的新路径
引言：需求工程的痛点与AI的入场
在软件工程与系统工程的交叉地带，需求文档的质量往往决定项目的最终成败。一个模糊的措辞、一处矛盾的约束、一条被遗漏的安全要求，可能在编码阶段被放大为架构缺陷，甚至在系统交付后演变为安全事故。业界早有共识：需求缺陷发现得越晚，修复成本呈指数级上升。
近年来，大语言模型凭借强大的语义理解与生成能力，被尝试引入需求质量评估。然而，通用模型在面对专业工程文档时暴露出明显短板——它可以流畅地复述需求文本，却难以判断这条需求是否可验证、是否与上层系统目标对齐、是否覆盖了所有边界条件。这种'懂语言但不懂工程'的困境，成为AI进入专业领域必须跨越的门槛。
背景：从通用能力到专业判断的鸿沟
大模型在自然语言处理任务上的表现令人印象深刻，但需求工程有其独特的知识体系。一份合格的需求文档不仅要语法正确，更要满足完整性、一致性、可追溯性、可验证性等多维度的工程标准。这些标准并非通用语言知识，而是系统工程领域长期积累的方法论。
此前多数尝试采用直接提示工程的方式，让模型基于少量示例进行评估。这类方案的问题在于，评估质量高度依赖提示词的设计，且难以适应不同行业、不同项目类型的差异化需求。更重要的是，通用模型缺乏对需求之间关联关系的结构化理解，容易陷入局部判断而忽略系统层面的矛盾。
MARQ：模块化与领域知识的双轮驱动
新近提出的MARQ框架，全称可解读为一种融合系统工程知识的模块化、模型无关需求质量评估器。其核心价值在于两个设计哲学：模块化架构与领域知识注入。
所谓模块化，是指将需求质量评估拆解为多个相对独立的子任务模块——完整性检查、一致性校验、歧义识别、可验证性分析等。每个模块可以独立优化、替换或扩展，而不影响整体架构的稳定性。这种设计带来两个实际好处：其一，不同项目可以根据自身特点选择激活哪些模块；其二，当某个评估维度需要更新判断标准时，无需重新训练或调整整个系统。
模型无关性则意味着该框架不绑定特定大模型。无论是开源模型还是商业闭源模型，只要具备基础的文本理解能力，都可以作为底层推理引擎接入。这一特性在当前模型快速迭代的环境中尤为重要——用户不必因为新模型的出现而重构评估体系，框架本身具备了与技术演进同步的能力。
真正让MARQ区别于通用方案的，是系统工程知识的显式注入。框架并非让模型自由发挥，而是将工程领域的评估准则、检查清单、依赖关系图谱等结构化知识，以可解释的方式嵌入评估流程。模型在判断时，既依赖自身的语言理解能力，也参照领域知识提供的判断锚点。这种'语言直觉加工程理性'的组合，有效抑制了大模型常见的幻觉性判断与过度自信倾向。
深度点评：跳出'越大越强'的单一叙事
MARQ的出现，折射出AI应用落地的一个重要转向。过去几年，行业注意力过度集中于模型规模的扩张与通用能力的提升，却忽视了专业场景中真正需要的不是'什么都会'的通才，而是'懂行'的专才。
在需求评估这类任务中，模型能否写出一篇漂亮的文章并不重要，重要的是它能否像一位资深系统工程师那样，发现文档中那条被遗漏的异常处理需求，或识别出两条看似独立实则冲突的性能指标。这种能力无法仅靠更大的参数量或更多的训练数据获得，必须通过领域知识的结构化引入来构建。
模块化架构的另一个深层意义在于可解释性。当AI给出一个评估结论时，工程师需要知道它依据的是哪条工程准则、参照了哪个检查项、在哪个推理环节做出了判断。黑箱式的打分在工程实践中难以被信任，更难以被用于改进文档质量。MARQ的拆分式设计让每个判断都可以回溯到具体模块与知识依据，这为人工复核与持续改进打开了通道。
当然，这一路径也面临挑战。领域知识的结构化本身是项繁重工作，不同行业、不同组织的需求标准差异巨大，如何构建既通用又可定制的领域知识表示，是框架推广时必须解决的问题。此外，模块化设计可能引入模块间协调的复杂度，当多个模块的判断出现冲突时，如何仲裁也需要明确的机制。
前瞻：知识注入或成专业AI的主流范式
可以预见，MARQ所代表的思路将在更多专业场景复现。无论是法律合同审查、医疗文献分析，还是金融风险评估，通用大模型都需要经历类似的'专业化改造'——通过模块化架构适配场景差异，通过领域知识注入弥补专业判断的不足。
未来的需求评估工具可能不再追求一次性给出完美判断，而是形成人机协作的迭代流程：AI快速扫描文档并标注潜在风险区域，工程师基于可解释的评估依据进行复核与修正，修正结果又反哺领域知识库，使系统持续进化。这种模式下，AI不是替代工程师，而是将工程师从重复性审查中解放出来，聚焦于更具创造性的系统架构设计。
从更广的视角看，MARQ提醒我们，AI工程化的核心议题正从'模型能做什么'转向'如何让模型在特定场景中可靠地做正确的事'。答案或许不在更大的模型里，而在对专业领域更深的理解与更精巧的系统设计中。