一次前后端联调的翻车，和一个我打算认真验证三个月的问题。
上个月做前后端联调，有个接口要适配到前端。
Swagger 文档是现成的，openapi.json 直接能拿到。我把需求、字段名、返回值怎么处理都跟 AI 说了一遍。
就差一样东西------接口实际的返回数据格式，我没给它。
不是因为它不在。它就写在同一份文档里，往上翻两屏就是。我当时就是懒得贴。
AI 写完，我扫了一遍：命名规范，注释齐全，try/catch 都没落下。看着挺像那么回事，直接刷新页面联调。
接口 200 是通的，瞄了一眼返回，数据也有。
但是控制台爆红。
那一个多小时
老实讲，接触 AI 编程之后我有点变懒了。
以前遇到报错，我会先看报错文件、看堆栈、猜想是哪一层的问题、去翻源码。现在我的第一反应是------把错误信息复制，粘给 AI，然后问"这是什么问题"。
那天我也是这么干的。
AI 开始读文件。读了一个，又读一个，跟前一个差不多，再读一个，还是差不多的。老规矩了，它要把一堆长得几乎一样的文件全扫一遍才肯动手。
我给 Cline 开了最高权限，所有弹窗选项都勾了"允许"，就是图省事。结果最常出问题的地方恰恰是------它准备自己打开 VS Code 的内部浏览器去调试，跳出来问你是否允许，我点了允许，然后它直接卡死了。
欲哭无泪。
只能取消掉，新开一个对话，把刚才说过的东西再讲一遍。
我们这边因为安全要求做了网络隔离，我自己买的模型用不了，只能用单位部署的模型。用的人多，响应也慢。
我不知道这是不是模型的问题，也可能是权限配得太满的问题，也可能就是我们网太差。反正那天就这么耗着，问了三轮，卡了两回。
最后实在没招了，我把 AI 关掉，自己下断点，一行一行看。
看到那几行的时候我愣了一下。
js
// AI 猜的
const { data } = res
const list = data.list
// 实际返回的
// { rows: [...], total: 0 }AI 猜返回体是 { data: { list: [...] } }，实际返回的是 { rows: [...], total: 0 }。
一个多小时。就这？
让我后背发凉的不是这个 bug
我一开始的反应是"这 AI 不行"。
但多说两句，我就觉得自己这判断不对。
我潜意识里默认了一件事：信息不够的时候，它会停下来问我。
它没有。
它直接用最像的那个答案把空白填上了，然后用和正确答案完全一样的语气讲出来。
那天改完，我坐在那儿想了一会儿。真正让我不安的是另一件事：
我不知道它还在哪些别的地方，替我做过决定。
这次是因为控制台报错，我抓到了。那下次呢？如果它猜错的是一个边界条件、一条只在特定情况下才走的逻辑分支------可能要半年后才爆，甚至可能永远不爆，就那么错着。
我原来的解法，现在想想挺蠢的
我的第一反应很朴素：写份文档，让它每次都读。
后来才知道，Cline 官方就有现成方案，叫 Memory Bank------在项目里放六个 Markdown 文件：
bash
项目根目录/
├── .clinerules
└── memory-bank/
├── projectbrief.md # 项目简介
├── productContext.md # 产品上下文
├── systemPatterns.md # 系统架构模式
├── techContext.md # 技术栈与开发环境
├── activeContext.md # 当前开发状态
└── progress.md # 进度跟踪思路挺清楚，我打算拿它当起点。但心里一直有个疑问没解决：
这六个文件，每一个都真的有用吗？
我的直觉是，有些内容它本来就能从代码里读出来，我写进去是白费力气。但我拿不出证据，纯粹是感觉。
直到看见一份实验
前几天查资料，翻到苏黎世联邦理工今年二月的一篇论文，专门测这些"给 AI 看的项目文档"到底有没有效果。
结果有点反直觉：
| 上下文文件来源 | 任务成功率变化 |
|---|---|
| AI 自己生成的 | 下降约 3% |
| 人写的 | 仅提升约 4% |
| 推理成本 | 上涨 20% 以上 |
写了半天，效果约等于零，还更贵。
论文里有句话解释得很直白：详细的代码库概览和已有文档大量重复，AI 本来就能读到你的代码，你复述一遍，只是在浪费它的注意力。
我第一反应是，那还写什么。
但回头想想那天的事，我发现问题不在写多写少------
我一直在写"我觉得它该知道的东西"，而不是"它真的不知道的东西"。
这两件事的重合度，可能低得可怕。看那个"下降 3%"，如果写进去的全是代码里已有的信息，那我干的事不是提供上下文，是制造噪音。
所以我打算花三个月，验证一下该删什么
这事我不想从网上抄答案。网上讲这个的基本是两类人：一类做小 demo 的，用 Cursor 十分钟写个待办事项，但真实项目没这么干净；一类是后端视角，讲 Java 微服务、模块依赖矩阵，跟前端完全是两回事。
前端有前端自己的麻烦。组件怎么组织，状态放哪儿，样式怎么约定，哪些祖传代码碰不得------这些没人讲。
我手上的项目正好合适。一个真实的企业级后台，有历史包袱，有复杂业务。它不是 demo，它就是那种你一次性讲不清楚的项目。
方法很笨：拿 Memory Bank 那六个文件当对象，一个一个往下删。删掉之后看它表现是真变差了，还是压根没变化。
说不定删到最后，六个文件活下来两个。
顺便说下我的约束，它会影响这件事的节奏：每天晚上尽量抽出一两个小时。 所以我不做宏大的东西，目标是每期推一小步，三个月收尾。
一个前提条件
我用的不是云端 AI。前面提过，我们这边做了网络隔离，只能用单位部署的模型，通过 VS Code 的 Cline 插件调。
意味着用不了 Cursor 那种云端代码库索引，也用不了很多要联网的能力。它对项目的全部了解，基本只能靠我喂。
我不能指望工具替我理解项目，通读整个工程不敢想，任务还没开始估计就挂掉了。喂什么，是我自己的责任。
这话听着像常识，但我以前的做法是"讲需求，讲背景，多喂就对了"。那天之后我才明白，光多没用，得喂对。
接下来
第一步我打算干件蠢事：把过去半年跟 AI 说过的"开场白"全翻出来，看看我到底在反复讲什么。
我有个猜测------那些我每次都讲的，可能恰恰是最没必要讲的。
要是猜对了，那这半年我有一半力气就真的白花了。
后续每一步的进展和翻车，我都会记下来。三个月后应该能出一份"真正必要的上下文清单"。
如果你也遇到过下面这几种情况，大概能在这个话题里找到同感，也欢迎说说你踩的坑：
- 每次开新会话，都要重新交代一遍项目
- 写了规则文档，它该错还是错
- 不确定哪些信息该写，哪些纯属废话
- 它写了段看着没问题的代码，跑到线上才炸