从“AI写崩”到“上下文治理”：一个前端工程师的2025实战复盘

2024年底，我曾对AI编程工具产生过强烈的怀疑。

不是技术不行，而是它根本记不住我的项目。

每次长对话，它就像失忆的老朋友，同一个规范要强调三遍以上。

TypeScript还是写成松散JS，函数式优先变成了命令式堆砌。

这不是提问技巧的问题，是底层架构的缺陷。

一、返工地狱：AI写得快，项目却越来越歪

作为一名前端工程师，代码写得多快从来不是瓶颈。

返工成本才是。

典型场景如下：项目采用TypeScript+函数式范式，接口DTO已稳定，目录结构经过迭代优化。但AI生成的代码永远是另一套风格。更可怕的是，对话超过二十轮后，输出开始自相矛盾——前文确认的方案，后文被彻底推翻。

我花了三个月反复验证：不是我的Prompt不够好，是AI根本不具备项目级上下文记忆能力。

二、关键转折：让项目自己管理规则

2025年Q1，我开始系统性地解决这一问题。

核心思路异常简单：上下文不属于对话，属于项目本身。

具体做法是在项目根目录创建GEMINI.md文件。该文件不是传统的Prompt模板，而是项目规则的本体定义：技术栈与编码规范、目录与模块约定、输出验收条件。

从这一刻起，我不再对AI重复强调任何规则。我默认它进入项目就自动加载这些约束。

这是认知层面的根本转变。

三、短期记忆：用命令显式管理会话状态

持久化规则解决了长期上下文问题，但开发中存在大量临时但关键的信息：数据库端口、鉴权方式、mock与真实接口的切换规则。

传统做法是在对话中反复强调，结果是这些信息被淹没在大量历史消息里，AI无法准确识别。

我的解决方案是使用GeminiCLI的memory命令：

每添加一条关键信息，就执行一次显式存储。

查看时，记忆列表就像一个实时的项目状态板，结构清晰，信息纯净。

四、上下文压缩：让长对话保持清晰

对话变长后，AI开始遗忘已确认的结论，这是所有开发者的噩梦。

传统解法是开新会话，从头再来。但这种做法的代价是，每次都要重新建立上下文。

更好的方案是使用/compress命令：让AI自己把历史对话压缩为结构化摘要，保留决策与约束，丢弃噪音。

这不是为了节省Token，而是重新让上下文变得清晰、可继续推进。

五、工作流闭环：让AI接入真实执行环境

真正让GeminiCLI成为协作者的关键，是三步操作。

第一步：引用完整文件结构而非片段。使用@./src/和@./src/main.ts让AI读取真实项目状态。

第二步：允许AI执行命令并验证结果。目标从“看起来正确”变为“能否通过真实验证”。

第三步：接入MCP获取一手调试数据。chrome-devtools-mcp让AI直接读取Performance、Network、Console数据，不再依赖人类转述。

六、模型对比：上下文能力决定工程化上限

2025年我同时使用GeminiCLI和Codex5.2。

Codex在代码质量和逻辑严谨性上确实很强，某些复杂算法场景表现更接近资深工程师。

但核心差异在于：Codex几乎不具备项目级上下文记忆能力。会话之间难以继承项目认知，规则需要反复说明，对长周期协作极不友好。

这不是能力高低的问题，而是设计取向的差异。

我的结论是：模型强不强决定下限，是否具备上下文与记忆机制，决定它能否进入日常工程流。

七、实战命令清单

以下是经过实战验证的关键命令：GEMINI.md文件管理项目规则、memoryadd/show管理短期记忆、compress压缩长对话、@文件路径引用真实代码、MCP接入调试工具链。

2026年，我不会追逐更强的Prompt技巧，而是继续深耕上下文治理：分层维护项目上下文，固化高频任务，扩展MCP数据源。

因为核心认知已经确立：当上下文清晰、记忆可靠，AI才真正具备进入生产环境的资格。