GPT-4o 为什么容易在复杂需求中跑偏？

GPT-4o 响应极快，输入需求后几秒内直接甩出一段基于 requests 和 BeautifulSoup 的 Python 代码。语法没错，能跑通，但默认网页是静态的——实际页面是异步加载，抓回来是空的。GPT-4o 等于在“猜”我的意图，跳过确认直接冲结果。前提假设一错，后面所有调试都是在为错误打补丁。

Claude 3.5 Sonnet 的处理方式更严谨。它接到指令后没急着写码，先列了几个关键确认点：网页要不要模拟登录？推送是实时还是定时？飞书端要纯文本还是结构化卡片？

先对齐后执行能否提高代码一次性正确率？

这种“先对齐，后执行”的机制，本质是把模糊的自然语言意图，硬生生映射成确定性的技术指标。处理复杂逻辑或架构设计时，Claude 3.5 Sonnet 的收敛能力确实能让代码一次性正确率更高。GPT-4o 在通用性和速度上有优势，但容易“过度自信”，跳到结果而忽略前提条件确认。

这次实测让我明白，与其花大把时间琢磨怎么写出完美详尽的 Prompt，不如搞一套框架，强迫 AI 进入“意图确认”模式，把定义确定性的责任转交给模型去引导。

如何通过 Prompt 框架强制 AI 进入确认模式？

如果你也老觉得 AI 不能“心领神会”，在对话开始前，可以先扔这么一段 Prompt 框架来强制切角色：

你现在是一个资深需求分析师。当我输入一个模糊的需求时，不要直接给出方案。
请执行以下流程：
1. 分析我话语中不确定的变量。
2. 针对这些变量提出 3-5 个关键问题以消除歧义。
3. 在我回答之前，仅提供一个初步的理解大纲。
4. 等我确认后再输出最终的确定性结果。

用这套逻辑后，沟通链路变成了：模糊需求 → AI 识别变量 → 关键问题对齐 → 确定性结果。这种方式减少了无效迭代，更重要的是，它逼着你在进入开发前先在逻辑层面达成共识。对于复杂脚本或系统设计场景，这种“反向询问”的效率远高于单向指令描述。