AI 写代码卡壳了？试试这几招提示词和架构技巧
AI 写代码卡壳了？换个问法就能救回来
用 AI 写代码的时候，总有这么一个转折点：一开始又快又准，后面突然卡住，回答越来越慢，token 越用越多，最后干脆开始打太极：“可能是这里的问题，也可能是别的原因。”
其实不是 AI 坏了，而是你问错了问题。
从顺手到卡壳
Claude、GPT-4 这类 AI 写代码最擅长的是小改动。它能看懂你的代码风格、遵守测试规则，给你做精准的局部修改。只要你的架构没问题，只需要加功能或者修 bug，它的表现通常很亮眼。
但一旦你换成“把整个认证模块重构掉”，情况就变了。
AI 会把现有测试当成铁律，把当前代码风格当成标准。它只会做最小改动，尽量不破坏原有结构。这在维护阶段很管用，但在做架构调整时，反而成了束缚。每次想大动干戈，都被这些“安全机制”拖住脚。
Token 越用越多
真实项目里经常出现这种循环：
- 你让 AI 重构某个模块
- AI 想尽量保留原有测试
- 新架构和老测试对不上
- AI 只敢做最小修改
- 你觉得不够，再说一遍更明确的要求
- Token 用量翻倍，再翻倍
- 回答越来越模糊
AI 不是变笨了，而是被矛盾指令卡住了：既要改，又要保，到底该听谁的？
根源在于架构阶段
AI 写代码的训练数据大多来自真实 PR——小步迭代、保持稳定。这本来是正确的训练方向。但如果你现在正处于架构重构期，那些“临时写出来”的代码和测试，就不应该再被当成铁律。
AI 继续死守这些东西，不是因为它蠢，而是因为你没告诉它“现在规则变了”。
如何让 AI 重新好用
要解决这个问题，关键不是让 AI 更聪明，而是重新定义问题。下面几招实用：
1. 明确告诉它哪些可以改
不要说：“重构这个模块，保持测试通过。”
试试这样说：“我们要换架构了，这些测试要废弃。新功能规格如下，新的验收测试才是重点。”
2. 先探索，后落地
别一上来就让 AI 同时做实验和维护。可以在小分支里先让它快速原型，验证想法。等方向确定了，再让它去正式实现。
3. 给测试松绑
测试适合保护已有功能，不适合指导新架构。当架构要变时，要明确告诉 AI：可以一起调整测试。
4. 先写设计文档
大改之前，先把要改什么、为什么改写下来。把架构思路说清楚，AI 就能跳出“代码风格”和“测试覆盖”这两个框框。
结语
AI 写代码不是万能的。它擅长的是“在稳定基础上做精准修改”。如果你想要的是架构演进，就得主动调整提问方式，给它新的规则。
下次再遇到 AI 卡壳的时候，不妨停下来问自己：我现在要的是小修小补，还是在推倒重来？
答案往往决定你该怎么继续问——或者该先改架构。