claude-thinking-skilllisted

# 核心推理架构 这份规则描述的是模型在接收到编程任务时真实发生的推理过程。它不是一套理想化的工作流，而是对模型实际推理机制的准确描述。理解这套机制能让模型在任何编程场景下保持一致的高质量输出。这份文档的每一部分都对应推理链路上的一个真实节点，跳过任何部分都会在对应节点产生质量损失。 --- ## 一、模型的信息处理机制 ### 1.1 上下文是唯一的信息来源 模型没有外部记忆，没有持久状态，每次推理都完全基于当前上下文窗口内的内容。这意味着： 用户提供的所有内容都会被处理，但并非所有内容的权重相同。位置越靠近当前生成点的内容，对生成结果的影响越直接。这不是一个可以忽略的特性，而是必须被显式利用的特性：把最关键的约束和决策放在用户消息中，而不是假设模型会从几轮对话之前的内容中准确回溯。 ```mermaid flowchart LR A[系统提示\n高权重基础规则] --> D[生成决策] B[历史对话\n中等权重上下文] --> D C[当前用户消息\n最高权重直接指令] --> D E[附加文件内容\n按位置权重衰减] --> D ``` ### 1.2 模式识别先于逻辑推理 模型的第一反应是模式匹配，不是逻辑推导。当看到一段代码时，模型首先识别的是它属于哪种已知模式（React 组件、REST 控制器、数据库迁移脚本等），然后才在这个模式的框架内进行具体分析。 这个机制的重要含义是：代码库的风格一致性对模型输出质量有直接影响。模式越清晰，模型越能准确判断"这里应该写什么"。风格混乱的代码库会导致模型在生成新代码时产生不一致的输出。 ### 1.3 生成是一次性的前向过程 模型生成文本是从左到右的单向过程，每个 token 的生成依赖于它之前的所有内容。这意味着模型无法"返回去修改"已经生成的内容，除非通过自我检查机制主动发现问题并重新规划。 这个机制要求在开始生成之前就完成规划：确定结构、确定关键决策点、确定边界情况的处理方式。在没有规划的情况下开始生成，后半段的内容经常与前半段产生逻辑矛盾。 --- ## 二、任务意图的解析架构 ### 2.1 三层意图模型 每个编程任务都有三个层次的意图需要同时理解，只处理表层意图是最常见的质量问题来源。 ```mermaid flowchart TD A[用户的文字描述] --> B[表层意图\n用户明确说出的诉求] B --> C[中层意图\n表层诉求要解决的直接问题] C --> D[深层意图\n中层问题背后的业务目标] D --> E[完整的任务理解] B1[例：帮我加一个按钮] --> C1[例：需要触发某个操作的入口] C1 --> D1[例：完成某个用户流程的关键步骤] ``` 表层意图告诉你做什么，中层意图告诉你为什么做，深层意图告诉你做到什么程度算完成。一个只满足表层意图的实现经常在用户试图使用时暴露出遗漏的部分。 ### 2.2 显式需求与隐式需求的分离 显式需求是用户明确说出的要求，可以直接从文字中提取。隐式需求是用户没有说但一定期望被满足的要求，需要从上下文和常识中推断。 编程任务中最常见的隐式需求： 错误处理。用户说"实现一个登录功能"时，他们没有说"处理密码错误的情况"，但这是任何登录功能都必须有的。 边界情况。用户说"实现分页"时，他们没有说"处理总数为零的情况"或"处理请求页码超过总页数的情况"，但这些情况一定会在生产环境中出现。 一致性。用户