前言

很多用过 AI 写代码的人都会经历这样一个阶段：起初被它的"聪明"惊艳，然后被它的"犯傻"气哭，最后陷入困惑——它到底是真懂，还是在装懂？这一篇就从技术原理出发，帮你建立一个对大模型代码能力的"现实主义预期"。

我们要回答的问题包括：大模型为什么会写代码？200K 上下文到底值钱在哪？为什么 AI 经常"看得到代码"却"理解不了项目"？它在哪些场景下会"一本正经地胡说八道"？理解了这些，你就知道该怎么写 Prompt、该怎么验证 AI 的输出。

1. 大模型代码能力的技术基础

很多人把大模型想象成"超级搜索引擎"或"编程百科全书"，这都低估了它的能力，也误解了它的本质。

1.1 Transformer：一切的基础

现代大语言模型（包括写代码用的 Claude、GPT、DeepSeek）几乎都基于同一种神经网络架构——Transformer。它最核心的能力是注意力机制（Attention）：当模型读到一段代码时，它能同时"看到"这段代码里的所有 Token，并自动判断哪些 Token 之间关系更重要。

打个比方：如果让你读 function getUserById(id: string) 这一行代码，你的注意力会立刻放在 getUserById 和 id 上，因为你知道这是函数名和参数。Transformer 的注意力机制做的事情类似，但它能跨越更长的距离——比如识别出第 100 行的函数定义和第 500 行的函数调用是同一个东西。

1.2 代码预训练：让模型"学过"代码

Transformer 给了模型"看懂上下文"的能力，但要让模型会写代码，还需要在海量代码上预训练。训练数据包括 GitHub 上的开源项目、Stack Overflow 的问答、官方文档、教程书籍等等，量级通常是几万亿 Token。

预训练之后，模型学会了什么？它学会了代码的统计规律：在 if (user) { 后面大概率跟 return；在 React 函数组件里大概率会 return <div>...</div>；在 Python 类里 __init__ 是构造函数……这些规律被压缩成几十 GB 的模型参数。

1.3 不要神化，也不要矮化

这种"学过海量代码"的能力有两面性：好处是它真的能写各种语言、各种框架的代码；坏处是它经常把相似但不同的东西搞混——因为它本质上是在"预测最像训练数据的下一个 Token"，而不是"理解逻辑"。这是后面"幻觉"问题的根源。

2. Token 与上下文窗口：1M 时代重新理解"AI 的工作记忆"

理解大模型，必须理解两个核心概念：Token 和上下文窗口。这两个词决定了 AI 编程能力的上限。2026 年的今天，主流模型已经普遍跨过 1M Token 门槛，这对工程师意味着什么？我们这一节重点讲清楚。

2.1 Token：AI 世界的"原子"

AI 不是像人一样一个字一个字地读代码，它把文本切成一个个小块，叫做 Token。例如 Hello World 会被切成 Hello 和 World 两个 Token；中文的 你好世界 可能被切成 你好 和世界 两个 Token，也可能更多。

为什么 Token 这个概念重要？因为AI 的计费和能力限制都以 Token 为单位。粗略换算关系是：1 个 Token ≈ 4 个英文字符 ≈ 1-2 个中文字符，一篇 1000 字的中文文章大约对应 500-1000 个 Token。

2.2 上下文窗口：AI 的"工作记忆"

上下文窗口是 AI 一次能"记住"的内容总量，就像你的办公桌大小——桌子越大，能同时摊开的文件越多。

模型（2026 年现状，按窗口从小到大）	上下文窗口	大致相当于
GPT-3 / 3.5（早期）	4K - 8K Token	一篇短文
GPT-4（2023 初版）	8K Token	几页文档
GPT-4o	128K Token	一本中篇小说
Claude Sonnet 4.5 / Opus 4.5	200K Token（1M Beta 中）	一本厚书
Qwen3-Max	262K Token	一套完整项目代码
GPT-5 / GPT-5.5	400K Token	一部长篇小说到两本专业书
Claude Sonnet 4.6 / Opus 4.6+	1M Token（已 GA）	一整套技术手册
DeepSeek V4 Pro / V4 Flash	1M Token	一整个中型项目 + 文档
Gemini 2.5 Pro / 3 Pro	1M Token	一个小型代码库到一套开源框架
Gemini 1.5 Pro（API）	2M Token（当前最大）	一个完整大型代码仓库

2.3 1M 上下文到底意味着什么：能装下哪些东西

2024 年之前，"上下文够不够用"是个大问题；2026 年的今天，1M Token 已经是主流门槛。这意味着什么？直观换算：

• 1 本《代码大全》（约 800 页）≈ 30 万 Token
• 1 个中型开源项目（如 Next.js 核心代码）≈ 50-80 万 Token
• 1 套完整技术文档（如 Vue 3 官方文档全集）≈ 100-150 万 Token
• 1M Token 大致能装下一整个中型项目的代码 + 文档 + 测试用例

这意味着什么？以前你需要做"上下文裁剪"——挑选哪些文件让 AI 看；现在你可以"全量喂入"——把整个项目代码 + 所有文档一次塞给 AI。 Claude Code、Gemini Fullstack Agent 都已经在用这个能力做"全仓库感知"。

2.4 超长上下文的三个真实用途

对 AI 编程来说，超长上下文（≥ 500K）解锁了三个以前做不到的事：

用途一：跨项目的"全局重构"。 以前 AI 只能改一个文件、一个模块；现在你可以把整个项目的 50 个文件全喂给 AI，让它做"项目级别的重构"——比如把所有 React 类组件统一改成函数组件，AI 能看到所有用法的上下文，不会改一处漏一处。

用途二：长文档/书籍级的问答。 工程师可以把整本《设计模式》《算法导论》喂给 AI，让它基于全书内容回答"哪种模式适合我的场景"。这种"全书阅读 + 跨章对比"的能力，128K 模型做不到，1M 模型能做得很好。

用途三：完整日志/报错分析。 生产环境的报错日志可能一次刷出几千行；以前要分批贴给 AI，现在可以一次性贴完，AI 能基于完整日志链路定位问题根因。

2.5 不要迷信数字：1M 也不等于"全记住"

但 1M 不等于"完美"。这里有一个非常重要的认知陷阱：上下文窗口大 ≠ 信息被同等重视。 Transformer 的注意力机制在长上下文中会出现"中间遗忘"现象——研究表明，模型对开头和结尾的内容关注度高，对中段的内容关注度低（俗称"lost in the middle"问题）。所以即使你有 1M 上下文，把核心信息放在开头和结尾仍然是最优策略。

这也是为什么 CLAUDE.md 这种"项目说明书"非常有用——它把最关键的项目信息压成几千 Token，每次会话自动加载在开头，等于给 AI 装了一个"项目记忆外挂"。

3. 模型能"看"代码 ≠ 真的"理解"项目结构

理解了上下文窗口的概念后，就容易理解一个反直觉的事实：AI 即使能"看到"全部代码，也不等于它真的"理解"了项目结构。

3.1 一个典型的反例

假设你有一个 React 项目，包含 50 个组件、20 个工具函数、5 个页面。AI 收到了所有文件，它"看到"了这些代码。但当你说"请重构用户管理模块的代码组织方式"时，AI 可能会做出一系列令人困惑的事情——它可能把 UserList.tsx 和 UserCard.tsx 合并成一个大文件，可能给一个工具函数起了个和现有命名规范不一致的名字，可能删除了某个它没看到用法的 import。

为什么会这样？因为 AI 的"看到"和人的"看到"完全不是一回事。人看代码，是带着几十年的工程经验和项目上下文；AI 看代码，是在做 Token 之间的概率匹配。

3.2 AI 理解的三个常见误区

第一个误区：AI 知道每个文件的语法，但不知道文件之间的"约定"。比如你们项目里所有 React 组件都用 named export，但某个文件用了 default export——AI 不会主动"统一"这种不一致，除非你明确告诉它。

第二个误区：AI 记得住细节，但记不住"为什么"。AI 看到一段被精心优化的正则表达式，但它不知道这段代码是因为性能问题被重写过的——它可能反过来"优化"成更简洁但更慢的版本。

第三个误区：AI 在长对话中会"失忆"，1M 上下文也救不了。上下文窗口虽然扩到了 1M，但前几轮的内容会被逐渐"稀释"——而且如前面提到的"lost in the middle"问题，模型对中段的内容关注度天然偏低。所以你会发现一个有趣的现象：AI 在前 5 轮对话里表现很好，到第 30 轮时开始"犯傻"——它忘了你之前定下的规则。超大上下文不等于"长期记忆"，更不等于"稳定状态"。要想让 AI 在长任务中保持一致性，必须依赖 CLAUDE.md、Auto Memory 这类外挂机制，而不是指望模型"自己记住"。

3.3 怎么弥补"理解"的鸿沟

最有效的办法是给 AI 写"项目说明书"（CLAUDE.md）——把项目背景、命名约定、代码风格、禁区规则都写清楚，让 AI 在每次会话开始时重新加载这份说明书。这不能完全弥补"理解"的差距，但能把差距缩小到可接受的范围。

4. AI 输出的"幻觉"：代码场景的三个真实案例

幻觉（Hallucination） 是 AI"一本正经地胡说八道"的学术说法。AI 生成内容的本质是预测概率最高的下一个词，大多数时候预测得很准，但有时候会自信地编造内容。

4.1 案例一：调用了不存在的 API

新手最常踩的坑：让 AI 写一段调用某个第三方库的代码，AI 信心满满地写了出来，import 也写得头头是道。但实际运行时报错：ModuleNotFoundError。查文档才发现，这个 API 在 3.0 版本就被移除了，AI 用的是 2.0 的旧 API 拼凑出来的"幽灵函数"。

为什么会这样？因为 AI 的训练数据有时间截止点，而且它会把不同版本的 API 混在一起"概率性"地输出。AI 不具备"我这个 API 是否存在"的判断能力。

4.2 案例二：错误地"理解"了业务逻辑

让 AI 给一个电商网站写"满 100 减 20"的优惠计算函数。AI 写出来的代码语法完美、注释清晰、还有单元测试。但实际跑起来才发现：它把"满 100 减 20"理解成了"100 元以上打 8 折"，因为它从训练数据里看到 8 折比减 20 更常见。

这是代码场景里最危险的幻觉——语法对、风格好、跑得起来，但业务逻辑完全错了。这种错误不会让程序崩溃，但会让你的电商网站每天都在亏钱。

4.3 案例三：自信地"补全"了不存在的文件

让 AI 分析一个项目的代码结构。AI 告诉你："我看到项目里有个 legacy/old_api.py 文件还在被引用，建议你清理一下。“但实际上这个文件根本不存在——是 AI 在长上下文中"想象"出了一个文件，因为它觉得"这个项目应该有一个遗留目录”。

这种幻觉在大型项目里特别危险，因为人类审查者看到"AI 提到了一个文件"时，会本能地相信它存在，而不是去验证。

4.4 应对幻觉的三个原则

原则一：永远验证关键代码。数据库操作、用户认证、支付逻辑——这些地方 100% 信任 AI 出过事的案例比比皆是。"信任但验证"是 AI 编程的黄金法则。

原则二：让 AI 引用它看过的东西。当你让 AI 修改某段代码时，要求它"先告诉我你打算修改哪几个文件、引用了哪几行代码"。这样能有效减少"凭空想象"的幻觉。

原则三：把幻觉当作 bug 来对待。AI 出现幻觉时，不要说"它又犯傻了"然后跳过，而是要追根究底：它是基于什么信息得出的错误结论？是上下文不够？还是你的描述有歧义？把幻觉当作改进 Prompt 的信号。

5. 学生/工程师怎么利用这些原理写出更好的 Prompt

理解了上面的原理，你就能有针对性地改进 Prompt。下面是五个立竿见影的技巧。

5.1 原则一：给 AI 足够的"上下文经营"

不要只说"帮我写个登录功能"，而是说：“我在做一个 Next.js + Prisma + SQLite 的项目，使用 NextAuth 做认证。现在需要加一个登录功能，要求支持邮箱密码登录，登录后跳转到用户主页。”

后者给了 AI 至少 5 个关键信息：技术栈、相关库、目标行为、具体要求、跳转逻辑。AI 基于这些信息生成的代码，质量会明显高于前者。

5.2 原则二：把"为什么"告诉 AI

不要只说"写一个冒泡排序"，而是说：“我需要给初学者演示排序算法的工作过程，请写一个带详细注释的冒泡排序，并在每一步打印当前数组状态，让初学者能看清每轮的比较和交换。”

前者 AI 写出来的是"正确但枯燥"的代码；后者 AI 写出来的是"为初学者定制"的代码。告诉 AI 你的目标和受众，AI 就能调整输出的粒度和风格。

5.3 原则三：让 AI 显式说明它的"推理过程"

在复杂任务中，让 AI"先说思路，再写代码"。比如：“请先分析这个问题可能涉及的几个技术点，然后给出你认为最合适的方案，最后再写代码。”

这样做有两个好处：一是能让你提前发现 AI 的思路错误；二是当 AI 主动暴露推理过程时，它"瞎编"的概率会显著降低。

5.4 原则四：拆分大任务为小任务

不要让 AI 一次性写 500 行代码。把它拆成 5 个 100 行的小任务，每完成一个就 review 一次。这不只是为了减少幻觉——更是因为 AI 在短任务上的注意力更集中，输出的代码质量更高。

5.5 原则五：建立你自己的"项目记忆"

把项目的关键决策、命名约定、代码风格写到 CLAUDE.md 或类似的说明文件里，每次和 AI 对话时让它先读这份文件。这等于给 AI 装了一个"项目记忆外挂"，能从"陌生人"变成"半个团队成员"。

5.6 原则六（1M 时代新增）：把"项目核心信息"放在上下文的开头和结尾

既然 1M 上下文也存在"lost in the middle"问题，那你就主动利用这一点：把你的项目目标、关键约束、禁区规则这些"最重要信息"放在对话的开头（系统提示或 CLAUDE.md），把"当前任务的具体要求"放在结尾（用户的最新提问）。中间部分放项目代码、参考文档这些"次要信息"。这种结构能让模型对核心指令保持高注意力，输出质量明显更稳定。

结语

这一篇我们走过了 AI 代码能力的底层：Transformer + 代码预训练给了它"学过代码"的能力，Token 和上下文窗口决定了它"能看到多少"，而幻觉是它"概率性输出"的天然副产品。

2026 年的今天，1M 上下文已经从"奢侈品"变成了"日用品"。但工程师必须清醒：更大的上下文不等于更好的 AI——它只是把"上下文经营"这件事从"挤破头挑选"变成了"全量喂入后再精心组织"。真正决定 AI 输出质量的，仍然是你给它的结构化程度、约束清晰度、关键信息的位置。

理解这些原理之后，你就不会再问"AI 怎么又犯傻了"——你会问"我给的上下文是不是不够"、“我的描述是不是有歧义”、“我是不是应该把任务拆小一点”、“核心信息是不是放在了正确的位置”。这才是和 AI 高效协作的正确心态，也是 1M 时代工程师的核心竞争力。