企业官网建设流程全解析

最近有个词在开发者圈子里被搜得特别勤：context-mode。初看像某个开源项目名，可点进去搜的人，多半并不是在找一个固定仓库，而是被同一个问题卡了很久——AI编程助手明明模型不差，为什么一到真实项目里就开始“胡说八道”？我自己的答案是：上下文没给对。大模型每次只能在一个文本窗口里做推理，它能看到什么，完全取决于你或工具替它组装了什么。context-mode，正是组装上下文的那套模式与规则。

这篇文章想把这个词彻底讲透：它有哪些常见形态，底层被哪些因素卡死，真实项目里应该怎么选，以及如果哪天你想自己做一套上下文组装工具，可以从哪里下手。内容不绑死某款编辑器，你用的是Copilot、Cursor、Cline还是Continue，都能对上话。

1. 为什么“context-mode”会被反复搜索：从“模型不够聪明”到“上下文没给对”

1.1 所谓上下文模式，本质是“你允许模型看什么”

先拆掉一层神秘感。大模型本身不“记得”你的项目，它只在每次调用时，把系统提示词、用户问题、附带的文件内容、历史对话拼成一个文本块，输入给模型。模型在这个文本块上做推理，上下文窗口就是它的“短时工作台”。context-mode定义的，就是这个工作台上应该放哪些文件、放多少、按什么顺序放。

很多开发者以为“我用的是同一个模型，表现应该一样”，其实错了。模型是同一个，但不同工具、不同设置下，模型看到的材料完全不一样。你在搜索框里问“这个函数为什么会超时”，如果上下文里只有当前文件，模型只能从函数体内部猜；如果上下文里还有调用链、超时相关的配置项，它才能真的定位到根因。所谓上下文模式，说白了就是一套“喂料策略”。

为什么最近这个词被频繁搜索？我观察下来，主要是AI编码工具经历了一轮“能力同质化”。各家模型基础能力差距慢慢变小，真正的体验差距转移到“谁能把正确上下文送到模型眼前”。于是上下文模式成了热议点，也成了很多人的痛点。

1.2 同一个问题，换一种模式结果可能完全不同

举一个我确实遇到过的例子。一个React项目里有个搜索框组件SearchBox.tsx，需求是“输入关键词自动防抖后请求接口”。我先后用三种方式问同一个AI：

• 当前文件模式，只给AI看SearchBox.tsx。它很快写出了onChange里的setTimeout，但防抖函数、请求函数它都不知道在哪，只好自己临时“发明”了一个debounce实现，和项目里已有的utils/useDebounce.ts完全是两套。
• 全仓库模式，直接把整个项目文件都丢进去。听上去最稳，但项目不算太大也有几千个文件，真正关键的useDebounce.ts和接口定义被淹没在node_modules、配置文件、mock数据里，模型返回的内容七零八落。
• 项目检索模式，或者说“手动指定文件”的方式，我把SearchBox.tsx、useDebounce.ts、api/client.ts三个文件放进上下文。AI一眼就看懂了防抖工具已经存在，接口参数也能对上，生成的代码基本能直接用。

同一个模型，同一句需求，三种结果。你说是模型变笨了吗？不是。是“模式”决定了它能否看见关键信息。这就是context-mode之所以重要的最好证明。

2. 主流工具里的上下文模式全景：从当前文件到整个仓库

2.1 按作用域拆出来的五档模式

大多数AI编程助手，无论界面怎么换，上下文模式都可以按作用域拆成五档。

• 选区模式（Selection）：只把你在编辑器里选中的那几行代码发给模型。适合“这段代码在干嘛”“帮我优化这个函数”这类局部问题，成本极低，几乎不引入噪声。
• 当前文件模式（Current File）：把当前打开的文件完整放入上下文。适合对单个文件做修改、修bug、补注释。缺点很明显：模型看不到跨文件依赖。
• 打开文件模式（Open Tabs）：把编辑器当前打开的所有标签页内容一并送入。适合同时改动两三个文件的小重构。成本取决于你开了多少标签，开几十个标签时token会涨得很厉害。
• 项目模式（Project/Workspace）：不会把全部文件塞进去，而是通过检索或索引，返回与问题最相关的一批代码片段。这是目前主流工具的默认工作方式，也是“全仓库”和“当前文件”之间的折中。
• 仓库模式（Repository）：理论上覆盖整个仓库。实现上又分两种：全量塞入和索引检索。全量塞入在超大仓库里不现实；索引检索则有索引质量、检索边界的问题。

五档更好理解，但别误会成某款工具的固定按钮——不同工具叫法不同，粒度也不同。下面给一张表格对照：

2.2 各家工具都在“context-mode”上做了什么

先说GitHub Copilot。它的Chat部分分成了Ask和Agent两类操作方式，Ask偏向“解释、回答”，通常围绕当前文件或选区展开；Agent则会把“自己去读仓库”当作执行环节的一部分。Copilot也允许你在输入框里用@符号指定文件，把它们手动加入上下文。

Cursor的做法更激进一些。它有一个专门的Codebase模式，相当于把整个代码库做索引，提问时先用索引检索出相关文件，再连同用户问题交给模型。Cursor把“自动找上下文”当成核心卖点，但它也保留了手动添加文件的能力——只是很多人在默认的自动模式里，很少意识到自己可以手动干预。

Cline这类工具则走向另一个极端：它默认就把“上下文决策权”交给用户。你会清晰地看到当前上下文中添加了哪些文件，每次对话可以手动点选或移除相关文件，AI也会在需要时请求你允许读取更多文件。优点是透明，缺点是操作成本高。

Continue和不少同类工具，更多是“自动引用+手动@文件”的混合方案。模型会用检索方式自动找到候选列表，但你可以输入@文件名强制把某个文件放进上下文，优先级比自动检索更高。

各家UI完全不同，但抽象之后都是三个维度的组合：作用域（看多大范围）、检索方式（怎么找相关材料）、注入策略（最终把哪些文本按什么顺序放进提示词）。抓住这三个维度，换任何工具都不会觉得陌生。

2.3 为什么没有一个“包治百病”的默认模式

刚接触这些工具时，我一度希望厂商给一个“终极模式”——什么都不用管，AI自己就知道该看什么。后来发现这个想法本身有问题。

核心矛盾在于，上下文模式每一次选择都在做资源交易：看得越多，召回关键信息的概率可能越高，但同时噪声也越多，速度和成本也越差。而且，模型对超长上下文的注意力并不是平均分配的，越往中间的内容越容易被“忽视”。所以“喂得越多”和“答案越准”之间根本不是线性关系，在某个点之后反而会下降。

另一个问题是，不同任务的“相关”定义完全不同。修一个类型错误，最相关的是类型定义文件和报错处的函数；做一次框架升级，最相关的是入口配置、依赖列表和核心抽象。如果用同一个自动检索逻辑去应对所有任务，效果大概率是“平均可用，但不惊喜”。这也是为什么深入研究context-mode的人，最后都会走向“手动编排”或“任务感知的自动切换”。

3. 上下文模式背后的三个硬约束：令牌、检索、裁剪

3.1 上下文窗口再大，也有“物理天花板”

很多人有个直觉：既然模型上下文窗口已经做到几十万上百万token，干脆把整个代码库都塞进去不就行了？这个问题算一笔账就明白了。

假设一个中等规模的业务项目，源码文件2000个，平均每个文件300行，平均每行代码约10个token（含缩进、注释、符号）。全项目大概就是：2000 × 300 × 10 = 600万token。当前哪怕最激进的商业模型，上下文窗口也就百万级，而实际产品里留给代码的预算往往只有几万到几十万token，因为输出也要占空间，历史对话也要吃预算。

全量塞入还有另一个隐性成本：注意力稀释。研究里常提的“lost in the middle”现象，说的是模型对长文本中间部分的关注度明显低于开头和结尾。你把仓库几百万token喂进去，关键信息大概率落在“中间地带”，模型反而看不见。所以“窗口够大”不等于“上下文有效”。

做context-mode设计时，第一个要接受的现实就是：你永远有一个token预算，预算不是越大越好，而是要在预算内尽量装“最该被看到的东西”。

3.2 全塞进去不如“找对片段”：“相关”是怎么算出来的

既然不能全塞，就得检索。目前主流检索方式可以分三派。

第一种是关键词检索，最常用的是BM25算法。把代码库切成小块，统计每块里出现什么词，再和你的提问做词频匹配。速度快、可解释，但语义差。比如你问“如何让请求防抖”，它可能匹配不到函数名叫useDebounce的代码块。

第二种是向量嵌入检索。先让模型把每个代码块转成向量，用户提问也转成向量，然后计算相似度，返回最接近的Top K块。它能解决“语义相近但字面不同”的问题，但也有局限：代码相似不等于依赖相关。你今天改了UserService里的返回值，向量检索不一定能告诉你还有哪些文件调用了它。

第三种是符号/依赖图检索。利用语法分析器或语言服务器提取项目里的函数、类、接口和引用关系，构建一张“谁依赖谁”的图。检索时按“当前编辑文件 → 直接引用文件 → 间接引用文件”的路径扩散。这种方法最接近程序员真实干活时的思路，但它依赖解析器的完整性和索引更新，实现成本也最高。

好的context-mode，通常把三种检索组合起来：先用符号关系锁定候选范围，再用关键词和向量检索在范围内做排序，最后交给裁剪逻辑。只靠某一种检索，很容易漏掉真正关键的材料。

3.3 裁剪与重排：决定谁被留下、谁被丢弃、谁放在开头

检索完之后，拿到的候选文件还是太多，超过token预算。所以上下文模式里必须有裁剪层，按优先级留一部分：

• 项目自述和核心文档（README、架构说明）通常保留一个精简版本；
• 报错信息和调试日志拥有很高优先级，因为它们是“现场证据”；
• 直接依赖和被直接引用的文件，优先于间接依赖；
• 历史对话要压缩，早期确认的结论可以保留为“决策摘录”，而不是完整对话；
• 自动排除规则要写死：node_modules、dist、build、锁文件、二进制文件、超过阈值的大文件。

重排也很讲究。相同的内容放在不同位置，效果完全不一样。经验做法是把“任务目标”和“最关键的文件内容”放在提示词开头，把“约束条件”或“示例输出”放在结尾，其余作为中间段。因为模型对开头和结尾的注意力最强，中间留给人畜无害的补充材料。

理解了这三个硬约束，再回头看各家工具里的context-mode，你就会明白：它不是一个玄学按钮，而是一套精心设计的检索与资源分配系统。

4. 怎么选模式：一个基于任务类型的决策框架

4.1 用“修改范围 × 理解深度”判断该开哪一档

与其靠感觉选模式，不如用两个维度来分：修改范围（局部还是全局），理解深度（只需看懂眼前代码，还是要理解跨文件关系）。组合起来就得到一张很实用的决策表：

这张表我用了很久，每次都会发现新手最容易犯的错：单文件问题开了全仓库模式，浪费钱不说，答案反而被无关信息污染；跨模块问题只开了当前文件，模型只能自己脑补接口。

4.2 多文件重构时，模式应该是“分阶段切换”的

不要把模式当成一次性选择。一次多文件重构，完全可以在不同阶段用不同模式。

第一步，先开仓库或项目模式，抛出一个偏“调研”的问题：“我打算把用户服务里的同步逻辑改成异步，请先列出所有受影响文件和调用点。”这个阶段，你希望AI广泛探索项目，宁多勿漏。

第二步，拿到影响面清单后，把真正要改的几个文件固定下来，切换到打开文件模式或手动指定文件模式。这时的任务是执行修改，上下文应该收敛：当前文件是主角，相关类型定义、调用方各来一份，“噪声”越少越安全。

第三步，修改完成后，如果要Review某个具体函数，直接用选区模式，选中那几行反复追问。成本低，响应快，也不会把之前的上下文带歪。

整个过程中，我会把“已经确认的结论”直接写进后续提问里。比如“前面已经确认，异步改造只需要改UserService里的saveUser，其他调用方不做变动”。这相当于把历史对话的关键信息固化成文本，避免后面的轮次把它忘掉。

4.3 把上下文清单做成可复用的模板

模式选好、文件确认之后，我习惯把“本次任务有效上下文”显式写下来。这样做的好处有三：一是换工具时能复现；二是出了问题可以排查；三是团队协作时能说清楚“我给AI看了什么”。

一份典型的上下文清单长这样：

任务：给搜索框增加防抖请求能力 请只参考下面列出的文件，不要猜测其他模块的接口： - src/components/SearchBox.tsx - src/hooks/useDebounce.ts - src/api/client.ts 约束： 1. 防抖逻辑必须复用 src/hooks/useDebounce.ts，不要新增工具函数。 2. 接口类型以 src/api/client.ts 中导出的类型为准。 3. 保持现有样式，不要引入额外依赖。 先说明你的修改方案，再给出可直接运行的代码。

如果是写进脚本或配置文件，可以转成结构化版本：

{ "task": "add-debounce-to-search", "mode": "project", "include": [ "src/components/SearchBox.tsx", "src/hooks/useDebounce.ts", "src/api/client.ts" ], "exclude": ["dist", "node_modules", "package-lock.json"], "max_tokens": 12000, "prompt_tail": "请先说明修改方案，再给出完整代码。" }

别小看这一步。把上下文清单模板化，本质上就是在把context-mode从工具里提供的默认档位，改造成你自己团队的工程规范。后面我会专门讲自建方案。

5. 我在真实项目里踩过的“上下文模式”的坑

5.1 坑一：开启全仓库模式，关键文件反而被挤出窗口

有一回我要AI帮忙分析一次接口超时问题，觉得问题可能涉及多个服务，于是放到了“仓库模式”。项目不算巨型，但包含前端代码、后端代码、mock数据、脚本、文档，零零散散几千个文件。结果AI给出的回答，引用了一堆README、package.json、通用工具函数，真正处理超时的核心服务代码却没出现在上下文里。

事后我明白了两件事。第一，检索排在前面不代表最重要；第二，自动检索会把“看起来相关”但“本质上不相关”的东西排上来，比如名字里带timeout的配置文件和真正的超时处理逻辑冲突。现在遇到这类问题，我会先把入口文件和已知的调用链手动放进去，再让仓库模式的检索结果做补充，而不是反过来。

5.2 坑二：只给当前文件，AI开始“脑补”其他接口

另一个典型失误是把上下文收得太窄。某次后端重构，我把user.ts改成了新签名，然后让AI在auth.ts里补齐调用逻辑，只开了当前文件模式。AI没见过user.ts的新签名，就按照旧签名自己补了一个调用，编译时全部报错。

问题出在“我认为AI应该知道”和“AI实际能看到”之间的信息差。从那之后，凡是涉及跨文件改动，我会先确认上下文里是否包含被修改文件本身，而不只是当前文件。最稳妥的做法是让AI先把它理解的“相关签名”复述一遍，看到它复述对了再让它动手。

5.3 坑三：索引过期，AI眼里代码和磁盘上完全不一样

还有一次更隐蔽。我用工具修改了某个类型定义的字段名，但工具的代码索引没有立刻更新。提问时，索引返回的还是旧字段，AI给出的代码全部基于旧字段，和磁盘上的新代码对不上。刚开始我以为是模型抽风，反复质问，很久才发现是索引缓存的问题。

现在我的习惯是：在大改动之后，先触发一次索引更新再提问。很多工具有明确的重建索引入口；其他工具也可以通过重启服务、清理缓存来强制更新。另外，提问时可以加一句“先读取以下文件的原始内容再回答”，让AI直接以磁盘内容为准，绕过过期索引。

5.4 从“AI胡说”到定位上下文问题的完整排查链路

如果AI突然开始“胡说八道”，先别怪模型，按这套链路排查：

1. 先问AI自己：“你刚才的回答参考了哪些文件？”很多工具会列出引用来源，这是最快的一步。
2. 检查当前上下文模式。是不是选错了档位？是不是把某个文件的访问权开给了别的对话？
3. 把问题最小化复现：新建一个空对话，手动粘贴“报错信息+关键文件内容”，不要夹杂之前的聊天历史。这能排除历史上下文的干扰。
4. 切换模式做对比。同一个问题，用选区、当前文件、项目模式各问一次，看结果差异在哪里。
5. 查索引状态。如果AI引用的代码和磁盘不一致，优先怀疑索引过期。

我常常发现，花一分钟排查上下文的开发者，比一直换模型、换工具的开发者效率高得多。真正的问题很少是模型笨，而是我们没告诉它该看什么。

6. 进阶：自己动手做一套轻量 context-mode

6.1 最朴素的做法：任务关键词到文件白名单

如果你不想被某个工具绑定，完全可以做一个最简版context-mode——一个小脚本，负责“输入任务描述，输出组装好的Prompt”。

第一版用静态映射就够。比如维护一份任务关键词表，有搜索相关的任务就带SearchBox.tsx、useDebounce.ts，有登录相关的任务就带auth.ts、session.ts。Python实现不过几十行：

import sys TASK_FILE_MAP = { "search": ["src/components/SearchBox.tsx", "src/hooks/useDebounce.ts"], "auth": ["src/services/auth.ts", "src/types/session.ts"], "api": ["src/api/client.ts", "src/api/types.ts"], } def build_prompt(task: str) -> str: include = [] for keyword, files in TASK_FILE_MAP.items(): if keyword in task.lower(): include.extend(files) if not include: include = ["README.md"] lines = ["请只参考以下文件："] lines += [f"- {f}" for f in dict.fromkeys(include)] lines.append("任务：" + task) lines.append("不要猜测其他文件的接口，请先列出方案再写代码。") return "\n".join(lines) if __name__ == "__main__": print(build_prompt(" ".join(sys.argv[1:])))

这套逻辑很粗糙，但已经解决了大部分“我不知道该给AI看什么”的问题，而且完全可复现。因为上下文固定，试错成本和结果波动都被压下来了。

6.2 上点档次：依赖图 + 混合检索组合

静态白名单的问题在于，新文件、非预期任务会漏。所以更实用的第二版，是引入两层机制。

第一层，依赖图扩散。用tree-sitter或语言服务器解析代码，拿到函数、类、模块间的引用关系。你告诉脚本“我要改SearchBox.tsx”，它能自动往外扩展一层，把直接import的文件、直接调用该组件的地方都加入候选。

第二层，文本检索。用BM25或向量检索，从代码库里捞出和任务描述最相似的Top K片段。把两路候选合并，去重，按“直接引用 > 文本相似 > 间接引用”排序，再用token预算截断。这个整体流程可以抽象成一段伪代码：

candidates = dependency_expand(changed_files, depth=1) candidates += bm25_search(task_description, repo_chunks, top_k=30) candidates += vector_search(task_description, repo_chunks, top_k=30) ranked = rank_with_priority(candidates) context = trim_to_budget(ranked, max_tokens=12000) prompt = assemble(system_instruction, context, task_description)

实现起来大概几百行代码，不需要很复杂的架构。我自己的经验是，这个方案已经能达到商业工具里“项目模式”七八成的效果，而且因为完全可控，出问题后几分钟就能定位。

6.3 把“context-mode”做成可切换的策略层

最后，如果你真的要把这个东西长期维护，建议在代码层面把“模式”抽象成一个策略层。每个模式只负责回答一个问题：给定任务状态，如何组装上下文。

可以定义一个很简单的接口：

class ContextMode(Protocol): def build(self, task: str, state: ProjectState) -> PromptContext: ...

然后为不同模式实现不同类：

• SelectionMode：只取编辑器选中的代码。
• CurrentFileMode：取当前文件全文。
• ProjectMode：依赖图 + 混合检索 + 裁剪。
• RepositoryMode：在预算内尽量扩大检索范围。

上层只需要根据任务类型或用户显式选择，调用对应模式。这样做的好处是，后续想加入“依据任务自动切换模式”“对历史对话做摘要压缩”“记录每次答案质量并回填检索权重”，都变成往策略层里加东西，而不需要重写核心逻辑。

这个方向再往后走，就是所谓的上下文工程了。你会发现context-mode并不是某个固定项目，而是一整套“如何让模型看到最该看的东西”的工程方法。从理解它到自建它，中间的路，其实就是把开发经验沉淀成检索、裁剪和编排规则的过程。

最后说点个人体会。我刚接触这些工具时，也迷信“喂得越多越聪明”，缠着厂商找“终极自动模式”。踩过上面那些坑之后，我现在的工作习惯反而很朴素：每次开工前，花三十秒确认一下“AI能看到哪些文件”；每次提问时，刻意把最关键的三五个文件写进引用列表；每次回答离谱，第一反应不再是换模型，而是查上下文。这个习惯帮我省下的时间，远比想象中多。context-mode这个名字听起来很学术，实操起来其实就是一句话：别让模型在黑暗里猜，把该看的材料摆到它面前，再给它一个明确的边界。