导读：第一次提示像魔法，第五次开始诡异，第十次我在和失忆的机器谈判。问题不在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的谈判，本质上是在用错误的工具做正确的事。现在我知道了：巫师的感觉来自魔法，但魔法撑不过十轮。真正的工作需要图纸。
（全文完）
热门跟贴