人本视角下大语言模型代码生成中的歧义重构

type

status

date

slug

summary

1. 引言：从指令到意图的认知鸿沟

随着大语言模型（LLM）在软件工程领域的广泛应用，代码生成的范式正在经历一场从“语法驱动”到“意图驱动”的根本性变革。在传统的软件开发过程中，程序员使用精确的形式化语言（如Python、Java）与机器交互，这种交互本身就是去歧义的。然而，随着Copilot、ChatGPT等工具的普及，普通用户——即那些缺乏系统计算机科学训练的非专家——开始使用自然语言（NL）作为主要的编程接口。这一转变虽然降低了编程的门槛，但也引入了自然语言固有的模糊性与编程语言所需的绝对精确性之间的深刻矛盾。

当前的学术界，特别是自然语言处理（NLP）领域，已经建立了一套完善的歧义分类体系，最受认可的是包含词汇歧义、句法歧义、指代歧义等在内的11类定义。然而，这些传统的分类法主要基于语言学的描述性特征，侧重于文本本身的属性，而未能充分考虑到人机协作代码生成这一特定场景下的特殊性。在代码生成场景中，歧义的产生不仅仅源于语言的结构，更源于用户（Human）的个性化背景（Personalized Background）、领域经验（Domain Experience）以及其对计算机系统运作方式的认知心智模型（Mental Model）。

正如研究指出，用户与LLM之间的交互存在显著的“指令鸿沟”（Instruction Gap）——用户想要实现的意图与他们能够表达的文本提示之间存在距离。这个鸿沟的本质是认知的，而非纯粹语言学的。当一个金融分析师要求“处理这个账户”时，他脑海中的“账户”概念（包含交易流水、借贷关系）与LLM训练数据中的“Account类”（包含username, passwordHash）可能完全不同。这种歧义并非仅仅是词汇的多义性，而是源于用户特定的职业背景与模型预训练知识之间的“领域失配”（Domain Mismatch）。

因此，直接沿用NLP的通用11类歧义定义已不足以指导下一代“澄清感知型”（Clarification-Aware）代码生成系统的设计。我们需要对现有的分类体系进行筛选与重构，通过“人本位”的透镜，剔除那些纯粹语言学层面的、在代码生成中影响较小的歧义类型（如纯粹的语音歧义或通用/非通用歧义），聚焦于那些由人的背景、经验习惯和认知局限所直接导致的歧义类型。

本报告旨在建立一个新的分类学（Taxonomy）。这个新的分类学是传统分类学的子集与深化，它强调每一个歧义类别背后的“人的机制”：即用户的什么场景、什么背景、什么样的思维定势导致了这种歧义的产生。我们认为，只有理解了歧义背后的认知机制，LLM才能像资深工程师一样，不仅仅是生成代码，而是主动识别模糊地带并发起有效的追问，从而真正弥合人机之间的理解鸿沟。

2. 理论框架：代码生成中的歧义形式化与人本过滤

在深入具体的分类重构之前，我们必须首先在理论层面界定什么是代码生成语境下的“歧义”，以及我们筛选“与人相关”歧义的标准。

2.1 歧义的形式化定义

依据相关文献的标注体系，我们将代码生成的问题陈述定义为，即自然语言空间中的一个指令。未知的真实代码解决方案集合（Ground-truth code solutions）为，这代表了用户内心真正期望的、能解决其特定问题的代码集合。与之相对，令 H 表示包含所有在语法上有效且符合字面需求 R 的解空间：。

在这个框架下，我们可以精确地定义歧义：当且仅当真实解集是字面解空间 H 的真子集时，编程问题 S 存在歧义。

这意味着，存在至少一个代码实现 h，它完全符合用户输入的自然语言提示词 R，但却不是用户心中想要的那个结果。

这个公式揭示了人机交互的核心矛盾：LLM作为概率模型，会在 H 空间中采样，而用户的意图往往被其隐性知识（Tacit Knowledge）所包裹，未能显式地转化为 R 的一部分。我们的研究目标，就是探究用户的哪些个人背景因素导致了 R 的不完整，从而使得 H 空间过大，包含了大量无效解。

2.2 筛选标准：以“人”为中心的过滤机制

传统的NLP 11类歧义包括：词汇（Lexical）、句法（Syntactic）、范围（Scopal）、省略（Elliptical）、集合/分配（Collective/Distributive）、蕴含（Implicative）、预设（Presuppositional）、习语（Idiomatic）、指代（Coreferential）、泛指/特指（Generic/Non-Generic）、类型/实例（Type/Token）。

为了适配“普通人使用LLM写代码”的场景，我们采用以下三个维度进行筛选：

背景相关性（Contextual Dependency）：该歧义是否源于用户特定的领域知识（Domain Knowledge）或缺乏特定技术背景？

认知差异性（Cognitive Divergence）：该歧义是否源于人类自然语言思维与计算机形式逻辑思维之间的心智模型差异？

交互意图性（Interaction Intent）：该歧义是否源于用户对LLM能力的错误假设（如过度拟人化）？

基于此标准，我们筛选出六大核心类别，并对其进行重命名与机制重构，以凸显其“人本”属性。这六大类别构成了我们新的分类学核心：

词汇歧义 ——————— 领域认知多义性 (Domain-Cognitive Polysemy)

句法/范围歧义 ——————— 逻辑结构映射误差 (Structural Logic Misalignment)

省略歧义 ——————— 习惯性语境缺失 (Habitual Context Omission)

预设歧义 ——————— 系统状态幻觉 (Systemic State Hallucination)

指代歧义 ——————— 交互记忆错位 (Conversational Memory Disalignment)

蕴含歧义 ——————— 质量期望隐匿 (Implicit Quality Expectation)

下文将详细阐述这六类歧义的重构定义、发生场景及背后的认知机制。

3. 分类一：领域认知多义性 (Domain-Cognitive Polysemy)

（原形：词汇歧义 Lexical Ambiguity）

3.1 定义重构

在传统NLP中，词汇歧义指一个单词有多种含义（如"bank"指银行或河岸）。在代码生成场景下，这种歧义并非简单的字典多义，而是用户的专业背景语言体系与编程领域的保留术语体系之间的碰撞。我们将此定义为“领域认知多义性”：当用户基于其特定的生活经验或职业背景使用某个术语时，该术语在计算机科学中恰好具有另一个严格定义的含义，从而导致LLM产生误解。

3.2 人本场景与机制解析

场景 A：非技术领域的术语借用

普通用户往往倾向于使用生活中的高频词汇来描述逻辑操作，而这些词汇在代码中往往对应着特定的数据结构或算法，但两者并不等价。

案例：一个HR背景的用户输入：“把这些员工名单清洗一下。”

歧义机制（背景导致）：在HR的背景中，“清洗”可能意味着删除离职员工或更新联系方式；而在数据科学背景（LLM的训练语料主导）中，“Data Cleaning”通常指去除空值、格式标准化或去重。用户的职业经验（Background Experience）构建了“清洗”一词的语义网络，而这个网络与代码库中的语义网络不重叠。LLM可能会生成一段去除NaN值的Python代码，而用户实际上想要的是业务逻辑上的筛选。

场景 B：跨领域的专业术语冲突

当用户具有特定领域（如金融、生物、法律）的专业知识时，这种歧义尤为严重。

案例：财务人员输入：“计算这笔交易的Buffer。”

歧义机制（专业知识壁垒）：在财务领域，Buffer可能指“缓冲金”或“预留额度”；而在计算机领域，Buffer是“缓冲区”（内存区域）。LLM作为一个通用模型，如果没有明确的上下文（Persona），极易将其解释为IO.Buffer或内存操作，生成底层系统代码，而非用户期望的财务计算公式。这种歧义是由于用户的领域认知模型（Mental Model of Domain）与LLM的预训练统计分布不一致造成的。

机制总结：

这种歧义与“人”的关联在于知识结构的异构性。用户的知识结构是基于其生活和工作经验构建的，他们不仅缺乏准确的技术词汇（Technical Vocabulary），更严重的是，他们意识不到自己使用的日常词汇在编程语境下已经被“征用”并赋予了特殊含义。这是一种典型的认知盲区（Cognitive Blind Spot）。

4. 分类二：逻辑结构映射误差 (Structural Logic Misalignment)

（原形：句法歧义 Syntactic Ambiguity & 范围歧义 Scopal Ambiguity）

4.1 定义重构

传统句法歧义关注句子解析树的多样性（如"old men and women"）。在代码生成中，我们将其重定义为“逻辑结构映射误差”。这特指用户在用自然语言描述复杂的逻辑运算、条件判断或循环范围时，由于缺乏算法思维训练，导致其自然语言的线性叙述无法精确映射到代码的层级结构（嵌套、优先级）上。这涵盖了原有的句法歧义和范围歧义。

4.2 人本场景与机制解析

场景 A：运算优先级的认知差异

自然语言是流线型的，往往依赖语调或停顿来断句，而编程语言严格依赖优先级（Precedence）和括号。

案例：用户输入：“如果不包含A或者包含B且长度大于5，则删除。”

歧义机制（认知负荷）：这里的逻辑是 (not A) or (B and len>5) 还是 ((not A) or B) and len>5？普通人在表达逻辑时，往往采用“线性累加”的思维模式，即想到一个条件说一个条件，缺乏“布尔代数”的结构化思维（Structured Thinking）。LLM在解析时往往依据统计概率，而无法确知用户脑海中的逻辑分组。研究显示，即便是新手程序员也常在运算符优先级上犯错，普通用户更甚，这是由于认知负荷（Cognitive Load）过高导致用户无法在脑海中构建精确的逻辑树。

场景 B：量词范围的模糊性（Scopal Ambiguity）

这是范围歧义在人机交互中的体现。

案例：用户输入：“检查每个用户是否有一个过期的许可证，并发送邮件。”

歧义机制（集合与分配的心理表征）：用户是想“每发现一个过期就发一封邮件”（Distributive，在循环内发送），还是“检查完所有用户后，给管理员发一封汇总邮件”（Collective，在循环外发送）？。这种歧义源于用户对数据处理流程（Data Flow）的心理表征是不清晰的。在日常对话中，我们很少区分“分别做”和“一起做”的严格界限，因为人类协作者会根据常识补全。但对于LLM，这种过程性知识（Procedural Knowledge）的缺失是致命的。

机制总结：

此歧义与“人”的相关性在于思维模式的转换障碍。编程要求具备高度的逻辑严密性和层级化思维，而普通人的自然语言思维是扁平的、流式的。当用户试图用流式语言描述层级逻辑时，就会产生结构映射误差。这反映了用户计算思维（Computational Thinking）的缺乏。

5. 分类三：习惯性语境缺失 (Habitual Context Omission)

（原形：省略歧义 Elliptical Ambiguity & 不完整问题 Incomplete Problem）

5.1 定义重构

在NLP中，省略歧义指句子成分的缺失。在代码生成场景下，这表现为“习惯性语境缺失”。这是指用户由于长期处于特定的工作或生活环境中，形成了一套默认的假设体系（Default Assumptions），误以为LLM也共享这套体系，从而在提示词中省略了对于代码实现至关重要的参数、边界条件或具体数值。

5.2 人本场景与机制解析

场景 A：基于经验的参数默认

案例：用户输入：“帮我写一个排序函数。”

歧义机制（知识的诅咒）：用户没有指定是升序还是降序，是按数值大小还是字典序。为什么？因为在用户（比如一个做排行榜的运营）的日常工作中，“排序”默认就是指“分数从高到低”。这种心理现象被称为“知识的诅咒”（Curse of Knowledge）——当我们熟悉某事时，我们很难想象不知道这件事是什么样子的。用户潜意识里认为“从高到低”是排序的唯一自然属性，因此省略了该参数。LLM作为缺乏特定上下文的通用模型，只能猜测或随机选择。

场景 B：边界条件的习惯性忽略

案例：用户输入：“计算两个日期的间隔天数。”

歧义机制（理想化模型）：用户往往忽略“开始日期大于结束日期怎么办？”或“是否包含首尾两天？”等边界情况。这是因为人类在处理日常任务时，往往只关注正常路径（Happy Path），而自动忽略异常路径。这种认知偏见（Cognitive Bias）导致了需求描述的不完整性。在软件工程中，这是“不完整问题”（Incomplete Problem）的主要来源，是最容易被识别但也最普遍的人为疏忽。

机制总结：

这一分类深刻体现了个人经验对沟通的简化作用。人与人交流时，省略是高效的（基于共同背景）；但人与AI交流时，省略是灾难性的。歧义源于用户未能将隐性知识（Tacit Knowledge）显性化，错误地将LLM视为具备相同背景知识的“同事”。

6. 分类四：系统状态幻觉 (Systemic State Hallucination)

（原形：预设歧义 Presuppositional Ambiguity）

6.1 定义重构

预设歧义指句子中包含的隐含假设不一定成立。在代码生成中，我们将其重定义为“系统状态幻觉”。这特指用户对计算机系统、运行环境或数据状态持有错误的心理模型（Flawed Mental Model），在提示词中预设了某些不存在或不可行的条件，导致生成的代码建立在虚假的逻辑基础之上。

6.2 人本场景与机制解析

场景 A：虚构的API与库

案例：用户输入：“用Python的SuperPDF库把这个文件转成Word。”（实际上并不存在SuperPDF库，或者该库没有这个功能）。

歧义机制（概念模型错误）：用户可能在别处听过类似的库，或者基于对技术的过度泛化（Overgeneralization），认为“既然AI能做图，那肯定有个库能一键转PDF”。用户预设了一个不存在的工具。这种歧义不仅仅是描述不清，而是基于错误的技术素养（Technical Literacy）。LLM可能会产生幻觉，捏造一个库，或者不知所措。

场景 B：对环境状态的错误预设

案例：用户输入：“获取当前登录用户的ID。”

歧义机制（环境感知缺失）：这句话预设了一个前提：代码是在一个已经鉴权、有会话上下文（Session Context）的环境中运行的。但如果这段代码是一个独立的脚本，根本没有“登录用户”这一概念。这种歧义源于用户对软件架构（Software Architecture）的无知——他们不知道“获取ID”需要先建立数据库连接、验证Token等一系列前置状态。这是用户对概念机器（Notional Machine）——即计算机如何执行程序的心理表征——存在根本性误解。

机制总结：

此歧义与“人”的相关性在于技术认知的局限性。用户不仅是描述需求，更是在基于自己（通常是错误的或不完整的）对计算机能力的理解来提出需求。这种歧义揭示了用户与真实系统能力之间的认知鸿沟。

7. 分类五：交互记忆错位 (Conversational Memory Disalignment)

（原形：指代歧义 Coreferential Ambiguity）

7.1 定义重构

指代歧义通常涉及“it”、“they”指代不明。在人机多轮对话（Chat-based Coding）的场景下，我们将其重定义为“交互记忆错位”。这是指用户在多轮交互中，错误地估计了LLM的上下文窗口或注意力机制，导致代词所指代的上下文状态（Contextual State）在人脑和模型之间发生了偏离。

7.2 人本场景与机制解析

场景 A：过时的上下文引用

案例：

T1（用户）：写一个函数处理列表A。

T2（LLM）：生成了代码V1。

T3（用户）：不好，换一种方法。

T4（LLM）：生成了代码V2。

T5（用户）：“还是用它吧，但是加个注释。”

歧义机制（工作记忆差异）：用户口中的“它”是指V1还是V2？在人类的短时记忆中，可能觉得V1更好，所以意指V1；但LLM通常基于最近优先原则（Recency Bias），可能倾向于认为用户指最新的V2，或者无法确定。这种歧义源于人类的注意力焦点（Human Attention Focus）与模型的上下文窗口（Model Context Window）的不对齐。用户认为交互是一个连续的、有情感偏好的流，而模型处理的是离散的Token序列。

场景 B：拟人化导致的指代不清

案例：用户输入：“把你刚才想到的那个优化方案写出来。”

歧义机制（拟人化投射）：用户将LLM视为一个有思维过程的个体（Agent），认为它“想”过某些方案但没说出来。实际上LLM没有隐性思维，只有输出。这种指代歧义源于用户对AI的拟人化（Anthropomorphism），将人类的思维属性投射到了模型上。

机制总结：

这种歧义反映了交互心理学中的问题。用户在对话中维护了一个动态的“共同基础”（Common Ground），并假设LLM也维护了完全相同的副本。当双方对“当前关注焦点”的理解不一致时，指代歧义就产生了。这与用户的沟通风格（Conversational Style）密切相关。

8. 分类六：质量期望隐匿 (Implicit Quality Expectation)

（原形：蕴含歧义 Implicative Ambiguity）

8.1 定义重构

蕴含歧义涉及言外之意。在代码生成中，我们将其重定义为“质量期望隐匿”。这是指用户字面上的功能需求虽然清晰，但隐含了对代码质量（安全性、性能、鲁棒性）的非功能性需求（Non-Functional Requirements），这些需求在用户的语用习惯中是“不言自明”的，但对LLM来说却是模糊的。

8.2 人本场景与机制解析

场景 A：安全性与性能的默认

案例：用户输入：“写一个登录页面。”

歧义机制（职业标准投射）：如果用户是一个资深工程师，他隐含的意思是“写一个包含CSRF防护、密码哈希存储、SQL注入防御的登录页面”。如果用户是一个学生，他可能只要一个能跑通的Demo。这里的歧义在于：“登录页面”这个词蕴含的质量标准是什么？用户基于自己的专业水准（Expertise Level），默认了输出代码应达到的标准。LLM如果不了解用户的身份背景，往往会生成最简单的（通常是不安全的）代码，这违背了资深用户的隐含意图。

场景 B：语用学中的合作原则

案例：用户输入：“能帮我优化一下这个循环吗？”

歧义机制（格赖斯准则）：根据格赖斯（Grice）的会话合作原则，用户问“能...吗”实际上是一个请求，而非询问能力。但在代码层面，优化的方向（时间换空间？空间换时间？可读性优先？）是蕴含在用户的具体场景中的。用户假设AI能像同事一样，理解当前项目的瓶颈（如内存不足），从而给出特定的优化。这种歧义源于用户对“合作式语境”的依赖，而LLM往往缺乏这种场外信息。

机制总结：

这是最高阶的歧义，它关乎价值观与标准。歧义不在于“做什么”，而在于“做到什么程度”。这直接取决于用户的专业身份（Professional Identity）和对任务重要性的主观评估。

9. 结论与研究意义

通过对传统NLP 11类歧义的深度筛选与重构，我们建立了一个面向普通用户代码生成场景的、具有强烈人本特征的新分类学（见表1）。

表 1：人本导向的代码生成歧义分类学

新分类名称	原型来源	产生机制（人本因素）	典型用户场景
领域认知多义性	词汇歧义	知识结构异构：日常经验/特定行业背景干扰了技术术语的准确理解	财务人员用“Buffer”指代缓冲金
逻辑结构映射误差	句法/范围歧义	计算思维缺乏：自然语言的线性叙述无法映射到代码的层级逻辑	用户混淆循环内外的操作范围
习惯性语境缺失	省略歧义	隐性知识固化：长期习惯导致的“知识诅咒”，误认为背景信息是常识	忽略排序规则、默认日期格式
系统状态幻觉	预设歧义	心智模型缺陷：对计算机系统原理（Notional Machine）的错误理解	请求不存在的库、忽视运行环境
交互记忆错位	指代歧义	交互心理投射：将人类的连续记忆与注意力模型投射给AI	多轮对话中模糊的“它”或“那个”
质量期望隐匿	蕴含歧义	专业标准差异：基于自身专业等级对代码非功能属性的默认期待	默认代码包含企业级安全标准

这一新分类学的核心价值在于：

解释力（Explanatory Power）：它不仅仅描述了“哪里错了”，更解释了“为什么错”。它将歧义的根源从文本本身引向了屏幕背后的具体的人——他们的职业、他们的思维习惯、他们的认知局限。

指导性（Prescriptive Value）：这种分类为“澄清式AI”（Clarification Agent）的设计提供了明确的路径。如果识别出“领域认知多义性”，AI不应只问“你是要A还是B”，而应采用跨领域的解释性语言进行确认；如果识别出“系统状态幻觉”，AI则需要扮演教育者的角色，纠正用户的心智模型。

差异化（Differentiation）：这与现有的纯语言学分类或纯软件工程分类截然不同。它是一个交叉学科的产物，融合了认知心理学、人机交互（HCI）与软件工程，完美契合了“普通人使用LLM”这一新兴且充满挑战的研究课题。

这一理论框架为后续的数据集构建（PRO creation）和模型优化提供了坚实的理论地基。未来的工作应致力于量化这些认知因素对歧义产生概率的影响，并开发能够动态感知用户“认知画像”的自适应代码生成模型。

📎 参考文章

Li, M. Y., Liu, A., Wu, Z., & Smith, N. A. (2024). A Taxonomy of Ambiguity Types for NLP. arXiv preprint arXiv:2403.14072.

Wu, J. J. W., Chaudhary, M., Abrahamyan, D., Khaku, A., Wei, A., & Fard, F. (2025). Can Code Language Models Learn Clarification-Seeking Behaviors? arXiv preprint arXiv:2504.16331v2.

Larbi, M., Akli, A., Papadakis, M., Bouyousfi, R., Cordy, M., Sarro, F., & Le Traon, Y. (2025). When Prompts Go Wrong: Evaluating Code Model Robustness to Ambiguous, Contradictory, and Incomplete Task Descriptions. arXiv preprint arXiv:2507.20439v1.

Subramonyam, H., Pea, R. D., Pondoc, C., Agrawala, M., & Seifert, C. M. (2024). Bridging the Gulf of Envisioning: Cognitive Challenges in Prompt Based Interactions with LLMs. In Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems (CHI '24).

Mu, F., Shi, L., Wang, S., Yu, Z., Zhang, B., Wang, C., Liu, S., & Wang, Q. (2024). ClarifyGPT: A Framework for Enhancing LLM-Based Code Generation via Requirements Clarification. Proceedings of the ACM on Software Engineering, 1(FSE).

Miao, C., Wang, Y., He, L., Fang, L., & Yu, P. S. (2025). ClariGen: Bridging Instruction Gaps via Interactive Clarification in Code Generation. In AAAI 2025 Workshop on Preventing and Detecting LLM Misinformation (PDLM).

Kobalczyk, K., Astorga, N., Liu, T., & van der Schaar, M. (2025). Active Task Disambiguation with LLMs. In Proceedings of the Thirteenth International Conference on Learning Representations (ICLR '25).

Kim, Y., Chin, B., & Son, K. (2025). Applying the Gricean Maxims to a Human-LLM Interaction Cycle: Design Insights from a Participatory Approach. Accepted at CHI '25 LBW.

Austin, J., Odena, A., Nye, M., Bosma, M., Michalewski, H., Dohan, D., et al. (2021). Program Synthesis with Large Language Models. arXiv preprint arXiv:2108.07732.

Ko, A. J., & Myers, B. A. (2004). A Framework and Methodology for Studying the Causes of Software Errors in Terms of Chains of Cognitive Breakdowns. Journal of Visual Languages & Computing.

Milne, I., & Rowe, G. (2002). Difficulties in Learning and Teaching Programming—Views of Students and Tutors. Education and Information Technologies.

Yuan, Y., Malaviya, C., & Yatskar, M. (2023). AmbiCoref: Evaluating Human and Model Sensitivity to Ambiguous Coreference. In Findings of the Association for Computational Linguistics: EACL 2023.

Mistrik, I., Grundy, J., Van der Hoek, A., & Whitehead, J. (2010). Collaborative Software Engineering: Challenges and Prospects. Springer Science & Business Media.

Grice, H. P. (1975). Logic and Conversation. In Syntax and Semantics 3: Speech Acts.

💡

有关文章的问题，欢迎您在底部评论区留言，一起交流~