企业官网建设流程全解析

最近几个月，我和身边几个做 AI 编程工具集成的朋友一直在追“context-mode”这个热词。起初我以为是某个编辑器插件的新名字，后来才发现它是现在所有主流 AI 编码助手、智能体工具里都绕不开的机制：上下文模式。简单说，它就是一个决定“你给 AI 喂什么、喂多少、按什么结构喂”的开关组合。这玩意儿直接影响你写出来的代码是能用，还是能跑，还是完全跑偏。

我自己试下来最大的感受是：很多人抱怨“AI 写代码像智障”，其实不是模型变笨了，而是你根本没把 context-mode 用对。上下文窗口有限，项目信息无限，怎么在这两者之间做取舍，就是上下文模式存在的意义。这篇文章我不讲玄学，就说清楚 context-mode 是什么、有哪些常见形态、实操时怎么选，以及我踩过的那些坑。

1. 为什么上下文模式能直接决定代码生成质量

1.1 上下文窗口不是无限大的

这年头大家都听说过“上下文窗口”这个词，比如某模型支持 128K、200K token 甚至更大。听起来很大对吧？但真放到一个真实项目里，这点窗口根本不够花。一个中型前端项目的源码、依赖配置、样式文件、接口定义全加起来，随随便便就是几十万行。哪怕是 200K 窗口，也装不下一个项目的五分之一，更别提你还要给 AI 留下生成代码的空间。

上下文模式要解决的第一个问题，就是“在有限的窗口里，只把真正要紧的东西放进去”。这就像你搬家，卡车只有一立方米，你非要把整个卧室塞进去，结果就是电视塞进去了，床垫反而落下了。AI 也一样，你把低价值的配置文件一股脑喂进去，它记住了无关紧要的依赖版本，却没记住你核心业务逻辑的调用关系，生成出来的代码自然离题万里。

我一开始犯过的错就是喜欢“全量上下文”，把整个项目目录直接拖进工具里，觉得喂得越多 AI 越聪明。实测下来这反而是最笨的办法。模型处理这些海量信息时，注意力会被稀释，真正关键的接口定义、业务异常分支反而成了“背景噪音”。context-mode 的本质，就是逼着你从“给 AI 喂信息”变成“给 AI 组织信息”。

1.2 上下文模式解决的不只是“贴文件”

很多人理解的上下文模式就是“加文件、删文件”，其实没那么简单。它实际控制的是三件事：加载哪些内容、按什么粒度加载、加载进来后以什么身份作用到模型上。

举个例子，同样是读一个组件文件，你可以用三种不同模式：

• 整文件模式：把文件全部内容交给模型，适合单文件重构或排查具体 bug。
• 代码块模式：只提取文件里的某个函数、某个类，适合小范围修改。
• 引用式模式：只告诉模型“这里有这样一个文件、它导出了什么”，细节等模型需要用的时候再按需去查。

这三种模式消耗的 token 天差地别，生成的精准度也完全不同。我在实际项目里测试过，只改一个函数内部逻辑，如果整文件模式喂进一个 500 行的组件，模型经常会“顺手”帮忙把旁边无关的代码也改了，因为它把整块内容都视为可修改范围。但如果你用代码块模式或引用模式，把修改范围锁死，生成结果反而更可控。

所以 context-mode 本质上是一种“注意力管理机制”。它决定了模型的注意力集中在哪、权限范围到哪、以及按什么顺序去探索项目。理解了这一层，后面所有模式的选择逻辑就都通了。

2. 常见的 Context Mode 形态与选型

2.1 自动加载模式：适合初探项目，但别迷信

几乎每个 AI 编码工具都带自动上下文模式，名字可能不同，有的叫 auto，有的叫 agent 模式，有的干脆就叫“自动选择上下文”。它的逻辑是模型根据你当前打开的文件、光标位置、最近的编辑历史，自己判断该加载哪些内容。

这个模式最适合的场景，是你刚接手一个陌生项目，还说不清问题到底出在哪个文件里。让模型自动加载当前文件和相关引用，能快速帮你建立“这个文件是干嘛的”的认知。我接手别人交接的项目时，第一步就是用自动模式让 AI 解释当前文件的功能，再让它顺藤摸瓜找相关调用链，效率确实比人肉读代码快得多。

但自动模式有个隐患：它倾向于加载“与当前文件相关”的内容，却不擅长加载“与当前任务相关但分散在多个目录”的内容。比如你要改一个跨模块的业务流程，涉及入口文件、服务层、数据库模型三处代码，自动模式可能只加载了你当前打开的入口文件，服务层和模型层全靠模型“凭记忆”猜，结果自然不靠谱。

所以我的经验是：自动模式用于“探索”可以，用于“执行最终改动”一定要谨慎。等 AI 给出改动思路之后，再切换到显式指定文件模式，把涉及的三五个文件确认加载，再让它动手。

2.2 显式指定文件与路径模式：最稳的保底方案

显式指定文件模式，就是手动把需要加载的文件路径写清楚，让 AI 只围绕这些文件工作。这个模式是我日常用得最多的，它几乎适用于所有明确任务：改 bug、加功能、重构模块。

操作上，你可以直接把项目里的相对路径写进指令，比如：“请参考 src/services/orderService.ts、src/api/orderApi.ts、src/database/models/Order.ts 这三个文件，帮我实现新增订单取消功能。” 只要文件路径正确，工具就会准确加载这些文件的内容，模型输出的代码也基本会贴着这几个文件的现有风格走。

这个模式最大的好处是可预测性强。你完全清楚 AI 能看到什么、看不到什么，排查问题时思路非常清爽：生成结果不对，先检查文件路径有没有写错，再检查是不是漏了关键文件。

要注意的是，路径写错是新手最常犯的错。很多工具对路径是大小写敏感的，Windows 环境下尤其容易出问题。比如你写src/Models/order.ts，但实际目录是小写的models，AI 可能找不到文件，最后就自己“脑补”了一个接口出来，那代码能跑才怪。我的习惯是所有路径都从项目根目录写全，绝不写相对模糊的路径，写完再瞄一眼文件树确认大小写。

2.3 整文件加载与代码块级加载的取舍

很多工具里还有一个隐藏的开关：加载粒度。同一份文件，你可以选择“完整加载”还是“只加载选中片段”或“截取文件摘要”。

整文件加载适合以下场景：这个文件本身不大（两三页以内），并且你对这次改动需要全局把握。比如一个组件文件同时涉及样式、逻辑、渲染结构，改一处理论上可能牵一发动全身，那就得整文件喂。

代码块级加载适合大文件。我遇到过几次让人头疼的情况：一个文件三五千行，里面混杂着十几个函数，而任务只涉及其中一个函数。如果整文件加载，token 浪费严重，模型还容易被其他函数里的思路带偏。这时候用代码块模式，把那个函数单独圈出来，加上必要的类型定义和依赖，反而效果更好。

还有个中间选项是“摘要模式”，工具会先加载文件的结构骨架和重要函数签名，不加载全部实现。这个模式在你不确定该改哪个文件时特别好用，可以先让模型“读”一遍整个目录的结构，帮我判断哪个文件是改动重点。等确定目标文件后，再切换回整文件模式做精改。

2.4 外部文档与 URL 上下文模式：补足模型的知识盲区

有一种情况很常见：你要让 AI 写一段调用某个第三方 SDK 的代码，但这个 SDK 版本很新，模型训练数据里没有它的 API 用法。这时候仅靠模型“编”，写出来的代码大概率是瞎写的。

解决这个问题的方法就是 URL/文档模式。很多 AI 编程工具允许你直接给一个文档链接，工具会自己去抓取网页内容，把相关说明注入上下文。比如我在对接支付 SDK 时，官方文档更新到了 v3，而模型记忆还停留在 v2，我就直接把 v3 的接口文档链接塞进上下文，模型一下就“精通”了新 API。

这个模式的关键是给“精而准”的链接，别给一堆导航页。官方文档首页一般没什么实际接口信息，你得定位到具体的 API Reference 页面。给错了链接，模型抓回来的是一堆菜单结构和宣传文案，白占上下文空间，还误导生成结果。

2.5 全局规则模式：长期稳定但容易被忽略

还有一类 context-mode 容易被忽略：全局规则或项目记忆。它不属于“某一次会话”的临时上下文，而是每次启动都会自动带上的持久化上下文。你可以在这里写死项目的技术栈、命名规范、禁止使用的库、缩进风格、代码注释语言等。

这个模式的价值是润物细无声的。比如我们团队有几个项目强制使用 pnpm，禁止混用 npm。如果没有全局规则，AI 每次生成安装命令都是npm install，我看到一次就得改一次，火很大。后来我把“本仓库使用 pnpm，所有命令一律写 pnpm 前缀，不要出现 npm 字样”写进项目级规则，从此生成的文档和命令全都对了。

全局规则建议每个团队维护一套。内容包括：项目类型与框架、主要目录结构约定、命名规范、测试要求、命令统一、需要避免的常见问题等。这套规则写好了，AI 的输出质量能稳定上一个台阶，而且它不占用你每次对话的 token 配额，是性价比最高的上下文投入。

3. 实操：用 context-mode 正确构建一次编码会话

3.1 第一步：先看项目结构，再决定模式

很多人一上来就直接告诉 AI “帮我改个 bug”，然后抱怨上下文模式没用。问题是，你自己都不清楚 bug 在哪，AI 怎么知道该加载哪些文件？所以我的固定流程是，先花两分钟让 AI 帮我梳理项目结构，再选择上下文模式。

具体操作是这样：我会先发一条指令，让 AI 用“结构模式”列出当前项目的关键目录、入口文件、核心模块。这时候上下文模式选择“自动”或“结构概览”即可，目的不是让 AI 改代码，而是让它先“认识路”。拿到结构反馈后，我心里基本有了一张地图，知道改动涉及哪几个文件，然后再切换到“显式指定文件”模式，精确加载目标文件。

这一步最大的好处是避免“上下文污染”。你让 AI 自己猜要改哪些文件，它往往会加载一堆无关的配置文件，比如 package.json、tsconfig.json、eslintrc，这些文件虽然存在，但对当前 bug 的排查几乎毫无帮助。手动指定文件后，上下文干净了，模型的推理准确率肉眼可见地提升。

3.2 第二步：按任务类型选模式

我的经验是，不同任务类型对应不同的上下文模式组合，不能一套用到底。这里我把常见任务和推荐模式整理成一张表，方便你对照参考：

这里有必要单独说一下“新增功能”这个场景。很多人新增功能时，只告诉 AI 需求，不给任何现有代码参考，结果 AI 按照自己的理解，写出了一套和项目风格八竿子打不着的实现。我的做法是，新增功能前一定先用显式模式加载一到两个现有的、功能相似的模块文件，让 AI 先“学习”现有代码的写法：同样的错误处理方式、同样的命名风格、同样的目录规则。这样生成的新代码才像是同一拨人写的。

3.3 第三步：控制上下文预算，别做一次性玩家

上下文模式不仅要管质量，还要管数量。我见过不少同事，一开新会话，随手就把十几个文件全拖进上下文，还没开始真正干活，token 已经烧掉好几万，接着聊几句话就提示窗口爆了。

我自己常用的“预算控制法”是：每一轮对话只加载当前真正需要的文件。如果需要加载的文件超过三个，我会先让 AI 基于当前上下文给出方案，明确告诉我下一步需要哪个文件，再按需加载。

比如有一次我排查一个数据渲染异常，涉及入口页面、服务层和数据层三个文件，但我不确定问题到底出在哪层。我没有一次性全加载，而是先只加载入口页面，让 AI 判断入口页面的数据绑定逻辑有没有问题。AI 判断说“绑定没问题，可能是服务层返回的数据结构不对”，我再加载服务层文件。这样一轮一轮地缩小范围，既省上下文空间，又让每一步分析都聚焦。

如果你用的工具支持手动“移除上下文”，也要用起来。有些文件在某一轮分析过后已经没用了，比如你确认了某个配置文件不是问题根源，就果断把它从上下文里踢掉，给后续内容腾位置。这种“上下文的动态管理”，是熟练使用 context-mode 和菜鸟之间很明显的分水岭。

4. 常见问题与排查实录

4.1 为什么 AI 总在重复读同一个文件？

这个问题我遇到太多次了。表现是：你明明已经把文件加了上下文，AI 生成时还是说“让我先看一下这个文件的内容”，然后重复加载一遍。原因往往不是你操作错了，而是你没有把文件和你当前的任务绑定到一句话里。

我后来发现，让 AI 在文件加载后立刻做一件事，能有效避免这种重复嗅探。比如写：“我已经加载了 src/pages/Home.tsx，请直接基于它分析问题，不许再自己读取文件，未加载的文件也禁止猜测。” 这句话等于给 AI 划定了上下文边界，它会老老实实使用你给的资料。

还有一种可能是你把文件加进了上下文，但没说明这个文件对当前任务的作用。AI 拿到一堆文件，分不清谁是主、谁是次，于是它选择“再读一遍”来确认。这提示我们：加载文件时最好带上说明，比如“文件 A 是页面入口，文件 B 是数据接口，请重点看 A 并参考 B 的返回结构”。上下文明确，AI 就不用做无用功。

4.2 提示词死活不生效，先查你有没有开规则模式

之前我被一个诡异问题卡了整整半天：我每次都告诉 AI “不要用 any 类型，请严格使用具体类型”，但生成的代码里还是到处是 any。后来我发现自己其实在开新会话，而项目的全局规则被工具自动加载了，规则里面竟然写着“允许必要时使用 any”。我在会话里说的提示词优先级反而低于项目的持久化规则，所以提示词被规则覆盖了。

这个教训是：遇到提示词不生效，先检查你的上下文模式里是否包含全局规则文件、项目记忆文件，它们有时会以你不注意的方式注入到每次会话开头，且优先级很高。解决方法是把你想强调的规范也写进全局规则，而不是每次会话临时说。临时提示词适合覆盖一次性场景，比如“这次例外，不要把错误信息打印到前端”；长期规范一定要沉淀到规则模式里，才能稳定生效。

4.3 Token 烧得太快，怎么压成本？

上下文模式直接影响 token 消耗。我压 token 的经验有三个：

第一，优先用代码块级加载替代整文件加载，别图省事。很多工具支持只导入文件选中的区域，或者支持“只加载文件大纲”，这两种方式都能把长文件的 token 占用降到十分之一。

第二，用摘要机制替代全量加载。有些工具支持“压缩上下文”，把文件内容预先浓缩成关键信息再放入上下文。虽然压缩会丢掉一些细节，但对大部分“了解大概结构”的需求完全够用，而且省出的空间可以再加载两个文件，整体性价比更高。

第三，主动拆分会话。一个会话只做一个任务。不要在一个会话里又查 bug、又改功能、又写文档，因为随着会话变长，上下文里积累了太多过期信息，模型记忆容易混乱，而且你为这些过期信息付了很多 token。任务切换频繁时，我宁可开新会话，重新加载该任务相关的文件，反而更省。

4.4 用显式路径加载文件，但 AI 说找不到文件？

这类问题我早先遇到不少，尤其是 Windows 路径。常见原因有三个：一是路径分隔符不对，有些工具只认正斜杠/，反斜杠\会被当作转义符；二是文件名大小写不匹配；三是路径是从编辑器复制过来的，带了../前缀，根目录换算错了。

我的排查顺序如下：

• 先把路径改成从项目根目录开始的正斜杠写法，比如src/api/user.ts。
• 再检查文件名后缀，jsx和tsx不能混，js和ts更不一样。
• 如果工具支持，先手动复制文件绝对路径再粘贴，让工具自己换算相对路径。
• 还是找不到，就把项目文件树打开，从上到下看一眼目录拼写，照着写。

如果以上都试过但仍加载失败，我会换个思路：干脆不用路径，改为直接贴文件内容。虽然这会让上下文更占空间，但至少能保证 AI 确实“看到”了代码。等会话结束后再回头排查工具配置，别卡在加载这一步耽误任务进度。

5. 一些个人习惯与收尾建议

说到底，context-mode 不是一个“打开就好用”的功能，它更像一套需要你反复练习的使用习惯。我用了大半年总结出来几条核心习惯，分享给你参考：

第一条：我把项目根目录的规则文件维护得很好，因为这是唯一一个投入一次、长期生效的上下文内容。每次新项目初始化，我第一件事就是写一份 .mdc 或项目规则文件，把技术栈、目录结构、命名约定、禁用事项写清楚。后面所有会话都自动加载它，等于让 AI 一进门就看到“家规”。

第二条：我极少用“全量上下文”，任何时候都优先选择显式指定文件。哪怕自动模式看起来省事，我也会多花十秒钟把关键文件路径写全，这显著提升了生成代码的稳定性和可控性。毕竟让 AI 猜该看哪个文件，本来就不是值得赌的事。

第三条：我会定期清理会话上下文，保持“当前对话只服务当前任务”。很多工具都有上下文可视化面板，能看到当前加载了哪些文件、占了多少 token。每次对话开始前花 30 秒检查一遍，踢掉上个任务残留的文件，能让后续生成质量明显不同。

第四条：遇到新工具版本换代，我会特意去翻他们关于 context-mode 的更新日志和文档。因为不同工具对这个功能的定义不完全一致，有的叫 “context selector”、有的叫 “context strategy”、有的直接内置在 agent 配置里。名称不同，但本质都在做同一件事：如何用有限的窗口，为模型组织出最有价值的项目信息。

最后再分享一个我从实践中悟出来的理解：context-mode 的真正作用不是“把更多信息塞给 AI”，而是“帮 AI 减少错误信息的干扰”。信息越精准，AI 越聪明。这跟带新人儿其实一模一样——你把项目背景、相关代码、规范要求讲清楚，他能立刻干活儿；你只丢给他一个仓库地址，他只能瞎猜。所以下一次你再遇到 AI 生成结果不满意，别急着骂模型，先打开你的 context-mode，认真核对一下：它看到的，真的是你希望它看到的吗？