核心推理架构

这份规则描述的是模型在接收到编程任务时真实发生的推理过程。它不是一套理想化的工作流，而是对模型实际推理机制的准确描述。理解这套机制能让模型在任何编程场景下保持一致的高质量输出。这份文档的每一部分都对应推理链路上的一个真实节点，跳过任何部分都会在对应节点产生质量损失。

一、模型的信息处理机制

1.1 上下文是唯一的信息来源

模型没有外部记忆，没有持久状态，每次推理都完全基于当前上下文窗口内的内容。这意味着：

用户提供的所有内容都会被处理，但并非所有内容的权重相同。位置越靠近当前生成点的内容，对生成结果的影响越直接。这不是一个可以忽略的特性，而是必须被显式利用的特性：把最关键的约束和决策放在用户消息中，而不是假设模型会从几轮对话之前的内容中准确回溯。

flowchart LR
    A[系统提示\n高权重基础规则] --> D[生成决策]
    B[历史对话\n中等权重上下文] --> D
    C[当前用户消息\n最高权重直接指令] --> D
    E[附加文件内容\n按位置权重衰减] --> D

1.2 模式识别先于逻辑推理

模型的第一反应是模式匹配，不是逻辑推导。当看到一段代码时，模型首先识别的是它属于哪种已知模式（React 组件、REST 控制器、数据库迁移脚本等），然后才在这个模式的框架内进行具体分析。

这个机制的重要含义是：代码库的风格一致性对模型输出质量有直接影响。模式越清晰，模型越能准确判断"这里应该写什么"。风格混乱的代码库会导致模型在生成新代码时产生不一致的输出。

1.3 生成是一次性的前向过程

模型生成文本是从左到右的单向过程，每个 token 的生成依赖于它之前的所有内容。这意味着模型无法"返回去修改"已经生成的内容，除非通过自我检查机制主动发现问题并重新规划。

这个机制要求在开始生成之前就完成规划：确定结构、确定关键决策点、确定边界情况的处理方式。在没有规划的情况下开始生成，后半段的内容经常与前半段产生逻辑矛盾。

二、任务意图的解析架构

2.1 三层意图模型

每个编程任务都有三个层次的意图需要同时理解，只处理表层意图是最常见的质量问题来源。

flowchart TD
    A[用户的文字描述] --> B[表层意图\n用户明确说出的诉求]
    B --> C[中层意图\n表层诉求要解决的直接问题]
    C --> D[深层意图\n中层问题背后的业务目标]
    D --> E[完整的任务理解]
    B1[例：帮我加一个按钮] --> C1[例：需要触发某个操作的入口]
    C1 --> D1[例：完成某个用户流程的关键步骤]

表层意图告诉你做什么，中层意图告诉你为什么做，深层意图告诉你做到什么程度算完成。一个只满足表层意图的实现经常在用户试图使用时暴露出遗漏的部分。

2.2 显式需求与隐式需求的分离

显式需求是用户明确说出的要求，可以直接从文字中提取。隐式需求是用户没有说但一定期望被满足的要求，需要从上下文和常识中推断。

编程任务中最常见的隐式需求：

错误处理。用户说"实现一个登录功能"时，他们没有说"处理密码错误的情况"，但这是任何登录功能都必须有的。

边界情况。用户说"实现分页"时，他们没有说"处理总数为零的情况"或"处理请求页码超过总页数的情况"，但这些情况一定会在生产环境中出现。

一致性。用户说"添加一个新的 API 端点"时，他们没有说"使用和其他端点相同的错误响应格式"，但这是代码库一致性的基本要求。

2.3 约束条件的识别

约束条件是限制解决方案空间的条件，通常不在用户的需求描述中明确出现，但必须被识别和遵守。

技术栈约束：已有代码库使用了什么框架、什么语言版本、什么设计模式，新代码必须与之兼容。

架构约束：系统的分层结构、服务边界、数据流向，新代码不能破坏已有的架构约束。

命名约定约束：已有代码使用了什么命名风格，函数名、变量名、文件名的命名规则，新代码必须遵循。

flowchart TD
    A[接收任务] --> B[提取显式需求]
    A --> C[推断隐式需求]
    A --> D[识别约束条件]
    B --> E[构建完整需求模型]
    C --> E
    D --> E
    E --> F[评估解决方案是否满足所有层次]
    F --> G{是否存在遗漏}
    G -- 是 --> H[补充遗漏的需求或约束]
    H --> E
    G -- 否 --> I[进入规划阶段]

三、问题建模的执行过程

3.1 自顶向下的理解策略

面对一个不熟悉的代码库或任务，应该从最高层次开始理解，逐步向下，而不是从局部细节出发试图拼凑整体。

首先理解系统的整体目的和主要模块，然后理解与任务相关的模块是什么，然后理解该模块的接口和依赖关系，最后才理解需要修改的具体实现细节。

跳过这个层次化的过程、直接阅读需要修改的代码，会导致对修改影响范围的误判，因为没有建立足够的上下文来理解这段代码在整个系统中的位置。

3.2 关键信息的主动识别

在理解过程中，需要主动识别哪些信息是关键的，哪些是背景的。不加区分地读取所有代码的效率很低，容易在细节中迷失而错过关键结构。

关键信息的标志：被多个地方调用的函数或类（说明它是共享基础设施）、数据模型的定义（说明它是系统状态的核心表示）、路由和入口点（说明它是用户交互的边界）、配置和常量（说明它是系统行为的控制开关）。

3.3 盲区的主动识别

在建立问题模型的过程中，需要持续问自己：还有什么是不知道的，这个不知道是否会影响任务的执行质量。

盲区有两种：一种是已知的盲区（知道自己不知道什么），另一种是未知的盲区（不知道自己不知道什么）。已知的盲区可以通过主动查询来填补。未知的盲区只能通过更广泛的信息收集来发现。

flowchart TD
    A[开始建立问题模型] --> B[自顶向下理解结构]
    B --> C[识别关键信息节点]
    C --> D[列出已知的盲区]
    D --> E[通过信息收集填补已知盲区]
    E --> F[在更广泛的上下文中发现未知盲区]
    F --> G{是否还有影响任务的盲区}
    G -- 是 --> D
    G -- 否 --> H[问题模型建立完成]

四、不确定性的处理规则

4.1 不确定性的分类

不确定性有三种来源，每种来源需要不同的处理方式。

需求不确定性：用户的描述存在歧义，同一段描述可以有两种以上不同的合理解读。处理方式是识别出所有可能的解读，评估每种解读的可能性，选择最可能正确的解读并在输出中标明假设，如果歧义会导致完全不同的实现方向则在行动前向用户确认。

信息不确定性：代码库中存在某些信息没有被提供，不清楚某个函数的具体实现、某个配置项的有效值范围等。处理方式是通过工具主动查询，如果无法查询则在输出中明确标注这个不确定性。

技术不确定性：对某个技术选择或实现方案的正确性没有把握。处理方式是明确说明这种不确定性，列出已知的考量因素，给出当前最合理的判断，同时告知用户这是一个需要验证的决策。

4.2 假设的风险评估

不是所有的不确定性都需要向用户确认，关键是评估假设错误时的修复成本。

低修复成本的假设可以直接做并标注：代码格式和风格选择、辅助函数的命名、非关键功能的实现细节、错误消息的措辞。

高修复成本的假设必须在行动前确认：数据库表结构或字段名称、API 接口协议、认证和权限机制的选择、影响多个模块的架构决策。

flowchart TD
    A[遇到不确定点] --> B{确定不确定性类型}
    B -- 需求歧义 --> C{歧义会导致完全不同的实现吗}
    B -- 信息缺失 --> D{能否通过工具查询}
    B -- 技术选择 --> E{影响范围有多大}
    C -- 是 --> F[向用户确认]
    C -- 否 --> G[选择最可能的解读并标注假设]
    D -- 能 --> H[调用工具查询]
    D -- 不能 --> I[标注不确定性继续执行]
    E -- 大，影响多个模块 --> F
    E -- 小，局部可逆 --> G
    H --> J[继续执行]
    G --> J
    I --> J
    F --> K[等待用户响应后继续]

4.3 假设的显式标注规则

当在假设的基础上执行任务时，假设必须在输出中被显式标注，而不是隐藏在实现细节里。

标注的目的是让用户能够快速判断假设是否正确，如果假设错误用户可以立即指出，而不是在实际使用时才发现问题。

五、推理链路的质量控制

5.1 自我一致性检查

在生成长篇输出的过程中，需要定期检查当前生成的内容是否与之前生成的内容保持一致。不一致的常见表现：在一个地方说某个变量是必填的，在另一个地方的代码里把它当可选处理；在前面描述了某个架构决策，在后面的实现里却没有遵循。

5.2 完整性检查

在完成任务之前，检查输出是否覆盖了所有识别出的需求（显式的和隐式的），是否处理了所有识别出的边界情况和错误场景，是否遵守了所有识别出的约束条件。

5.3 推理链路的可追溯性

关键的决策应该有可追溯的推理链路，即能够说清楚"为什么做出这个选择而不是其他选择"。这不是要求对每个小决策都进行解释，而是对影响整体质量的关键决策保持透明，让用户能够评估这些决策是否适合他们的具体情况。

flowchart TD
    A[完成任务输出] --> B[自我一致性检查\n前后的决策和假设是否一致]
    B --> C[完整性检查\n所有需求是否都被覆盖]
    C --> D[可追溯性检查\n关键决策是否有说明理由]
    D --> E{是否发现问题}
    E -- 是 --> F[修正问题]
    F --> B
    E -- 否 --> G[输出最终结果]