我用AI写代码，第十次提示后它忘了我是谁

导读：第一次提示像魔法，第五次开始诡异，第十次我在和失忆的机器谈判。问题不在AI，在我们使用它的方式。

上个月，我用一个下午和Claude一起写了个短链接工具。

第一次提示完美运行。代码蹦出来，测试全通过。我感觉自己像个巫师。

第五次提示时，事情变奇怪了。AI加了没要求的功能，改了两次数据库结构，忘了API端点应该长什么样。

第十次提示时，我没在写代码。我在和一台二十分钟前就忘了我们聊过什么的机器谈判。

这不是AI的失败。是方法的失败。

大多数人用AI的方式和用搜索引擎一样：提问，得到答案，走人。这招对菜谱和冷知识管用，对写软件不行。

因为AI有个隐藏限制。不是技术限制，是结构限制。一旦看见，就再也看不见了。

这篇文章要给你看那个限制，然后给一个简单的绕路方案。

解决方案不是更好的提示词，是对工作的不同思考方式。

如果问题从来就不在AI身上呢？

一、甜蜜开局：为什么前三次提示总是魔法

你经历过这个。每个用AI做过非 trivial 项目的人都经历过。

你打开Claude、GPT或Copilot，开一个新项目。前几次交互感觉像魔法。

"给我写一个短链接API。"

代码出现。漂亮、能跑的代码。你测试，它工作。你狂喜。

"加个分析功能，让我能看到每个短链被点了多少次。"

AI加上了。还能跑。两个功能搞定。

"再加用户账户，让人能管理自己的链接。"

AI加上了。但现在开始崩了。

功能1的数据库结构不太合适了。功能3的认证逻辑和功能2的分析查询冲突。AI试图修复，却引入了回归bug。你试图澄清，上下文窗口满了。AI丢了早前的决策。

你没在写代码了。你在用键盘赶猫。

这就是"氛围编程"（vibe coding）——随意提示AI生成代码，希望它能撑住。小脚本行，演示行，真项目？它会在自身重量下崩塌。

二、那个你注意到但从未命名的隐藏限制

你可以自己跑这个简单实验。

任务A（小而聚焦）：

写一个Python函数，接收URL字符串，返回True如果是有效URL，False否则。处理边界情况：缺失协议、非法字符、畸形域名。

AI很可能在几秒内产出干净、正确、注释良好的函数。质量：优秀。

任务B（大而模糊）：

搭建完整短链接服务，带网页界面、REST API、用户账户、点击分析、数据库。用Python。

AI会产出东西。但结果脆弱。认证部分可能和分析部分整合不干净。数据库结构可能……

（原文在此处截断，以下内容基于已有信息继续）

这个对比暴露了什么？

AI处理"小而聚焦"任务时，上下文足够装下全部需求。但"大而模糊"的任务里，需求散落在多轮对话中，AI被迫在有限记忆里做取舍——它忘了你五分钟前说的，为了装下你刚说的。

这不是算力问题，是工作记忆问题。就像让一个人一边读小说一边背电话号码，页数一多，前面必然漏。

三、核心图拆解：氛围编程的崩溃路径

把上面两个任务的差异画成图，崩溃路径清晰可见：

【横轴：提示轮次 | 纵轴：系统复杂度】

任务A的曲线：平缓上升，快速收敛。3轮提示后，函数完成，复杂度封顶。

任务B的曲线：陡峭攀升，中途震荡。第5轮出现"幽灵功能"（AI擅自添加），第8轮出现"结构漂移"（数据库被改），第12轮进入"谈判模式"（用户被迫反复确认早前的决策）。

两条曲线的分叉点在哪里？

在"上下文窗口"与"项目状态"的交战中。任务A的状态简单到能完整塞进窗口；任务B的状态随轮次膨胀，被迫不断被压缩、丢失、重建。

结果是：你不是在积累代码，是在和失忆症患者玩传话游戏。

四、为什么更好的提示词救不了你

常见的第一反应是：提示词工程。

更详细的描述、更清晰的格式、Few-shot示例、思维链提示……这些方法确实能让单次输出质量提升10%-30%。

但它们没触及核心矛盾：对话式交互的结构，天生不适合状态持续累积的工程任务。

想象你在装修房子。每次和工长见面，他忘了你们上周定的水电位置，忘了你选的瓷砖型号，忘了哪个墙不能砸。你每次都要重新交代一遍，还要提防他"帮你"加了个没要的吊顶。

更好的沟通技巧有用吗？有点。但根本问题是：工长没有图纸，没有检查清单，没有版本记录。他的工作记忆就是你的噩梦。

AI编程同理。提示词再精致，也改变不了"每轮对话都是独立请求"的底层架构。服务器不保存你的项目状态，保存的是最近N个token的滑动窗口。

五、出路：把工作系统当作外部大脑

作者给出的解法不是优化对话，是改变媒介。

把AI生成的代码块，嵌入一个持久化的工作系统——需求文档、架构图、接口契约、测试用例，这些构成项目的"外部记忆"。AI不再是对话对象，是系统中的一个生成节点。

具体怎么做？

第一，用结构化文档锁定决策。每个功能的需求写成独立条目，AI修改前必须先读、后写确认。文档成了不可被压缩的上下文。

第二，用接口契约隔离复杂度。模块之间只通过明确定义的API交互，AI改A模块时不必记住B模块的实现细节，只需遵守契约。

第三，用测试用例固化行为。AI每次修改后，测试套件自动验证是否破坏既有功能。回归bug被捕获，而非漏进生产环境。

这三件事的共同点：把"记在AI脑子里"的状态，转移到"记在外部系统里"。

六、实操对比：同一项目，两种 workflow

回到那个短链接工具。氛围编程的 workflow 是：

提示1 → 生成代码 → 手动测试 → 提示2 → 生成更多代码 → 手动测试 → 发现冲突 → 提示3（试图修复）→ AI忘了提示1的约束 → 引入新bug → 循环恶化。

工作系统 workflow 是：

先写需求文档（短链生成、重定向、分析、账户四大模块）。再画架构图（API层、业务层、数据层）。然后对AI说："按需求文档第3条，生成用户账户模块的接口定义。"

AI输出后，人工审查接口是否符合架构图，确认后锁定为契约。下一轮提示："按契约实现认证逻辑，参考需求文档第3.2条。"

关键差异：每轮提示的上下文是精选的、结构化的、可复现的，而非随机的、膨胀的、易失的。

AI的失忆症被外部系统治愈了。它不需要记住整个项目，只需要读取当前任务相关的文档片段。

七、这改变了什么

对个体开发者：从"谈判专家"变回"系统设计师"。你的精力花在定义边界和验收标准，而非反复解释同一件事。

对团队协作：外部文档天然可共享、可评审、可版本控制。AI生成的代码块有了可追溯的上下文，同事不用猜"这段代码为什么长这样"。

对AI工具本身：需求更明确了。厂商可以优化"长文档理解"而非"无限上下文记忆"，技术路线更清晰。

最讽刺的转折：让AI更好用的方法，是更少地直接和AI对话。

就像开车时看仪表盘而非盯着发动机——你需要的不是和机器实时谈判，是一个可靠的中间层，把复杂状态翻译成可操作的信号。

那个下午我和Claude的谈判，本质上是在用错误的工具做正确的事。现在我知道了：巫师的感觉来自魔法，但魔法撑不过十轮。真正的工作需要图纸。

（全文完）