我以为是模型变差了，结果是我自己变懒了

上周我在用 codex-auto-review 跑一个代码审查任务，Prompt 是从 Claude 那边直接复制过来的，一字未改。

输出结果让我愣了三秒。

不是报错，是那种"说了等于没说"的回答——泛泛的建议，没有针对性，格式也乱。我的第一反应是：这模型是不是更新之后变差了？

然后我翻了一下自己的历史记录，发现同样的任务，三个月前在 Codex 上跑得很好。那时候的 Prompt 写了整八行，有角色、有约束、有输出格式要求。

而我现在的版本？两行半。

不是模型退步了。是我在 Claude 上用顺手之后，把"偷懒"当成了"熟练"。

---

两个模型的"默认期待"根本不同

在聊具体习惯之前，需要先建立一个认知框架，否则后面的对比示例会显得像在挑剔细节，而不是在解决根本问题。

Claude 和 Codex 系列在设计取向上有一个核心差异：

Claude 更像一个会猜你意思的同事。 你说"帮我看这段代码有没有问题"，它会自动推断你想要什么层面的反馈——是逻辑问题、性能问题还是风格问题，然后给你一个综合性的回答。它擅长处理模糊意图，会主动补全你没说清楚的上下文。 Codex 系列更像一个需要你写清楚需求文档的外包团队。 你说"帮我看看这段代码有没有问题"，它会照字面意思执行——找到一个问题，告诉你，然后停下来。它不会主动猜测你还想要什么，因为它的优化方向是精确执行，而不是意图推断。

这不是谁好谁坏的问题。这是两种不同的设计哲学，服务于不同的使用场景。

问题在于：当你在 Claude 上用了足够长时间之后，你的 Prompt 习惯会被它的"宽容度"悄悄驯化。你开始写越来越短的 Prompt，因为 Claude 总能给出不错的结果。然后你切换到 Codex，带着同样的习惯，然后翻车。

下面这三个习惯，是最容易出问题的地方。

---

3 个最容易搞乱的 Prompt 习惯

习惯一：省略角色设定

在 Claude 上用久了，很多人会发现不写角色设定也没关系——Claude 会根据问题的性质自动调整回答的视角和深度。你问代码问题，它用工程师的视角回答；你问文案问题，它切换成编辑的语气。

这个体验会让你觉得角色设定是"可选项"。

切回 Codex 之后，同样省略角色，输出质量会明显下滑。不是因为 Codex 不懂角色设定，而是它不会主动推断——你不说，它就用最通用的默认视角处理，结果往是正确但无用的回答。

翻车案例完整复现：

原始 Prompt（从 Claude 直接搬过来）：

帮我审查这段 Python 函数，找出潜在问题：


def process_user_data(data):


result = []


for item in data:


if item['age'] > 18:


result.append(item['name'])


return result

在 claude-opus-4.8 上的输出（节选）：这段代码有几个潜在问题：1. 没有对 data 为空或 None 的情况做处理；2. 直接访问字典键没有异常捕获，如果数据结构不一致会抛出 KeyError；3. 没有类型注解，可维护性较差……（继续展开了具体修复建议）

在 gpt-5.3-codex 上的输出（节选）：这段代码可以正常运行，但有一些可以改进的地方。建议添加错误处理。

---

同样的任务，加上角色设定之后：

你是一名有 5 年经验的 Python 后端工程师，专注于生产环境代码质量。

请从以下三个维度审查这段函数：


1. 异常处理与边界条件


2. 代码健壮性（类型安全、空值处理）


3. 可维护性（命名、注解、可读性）



每个维度给出具体问题和修复建议，代码示例用 Python 3.10+ 语法。



def process_user_data(data):


result = []


for item in data:


if item['age'] > 18:


result.append(item['name'])


return result

输出质量立刻回到了你期待的水平。

这些 Prompt 模板都可以直接在 [api.884819.xyz](https://api.884819.xyz) 调用多个模型对比验证效果，不用分别注册账号。

---

习惯二：用"追问式"代替"一次性完整 Prompt"

Claude 的多轮对话体验非常流畅，它能在对话过程中持续积累上下文，你可以先给一个粗略的需求，然后一轮一轮地补充条件，最终收敛到你想要的结果。

这种"先问再补"的习惯在 Claude 上是高效的。

但在 Codex 处理代码任务时，这个习惯会导致上下文断裂。Codex 在代码生成和审查任务上更适合一次性把所有约束条件写清楚——追问会让它在每一轮都重新理解任务边界，前后输出的一致性会变差，有时候第三轮的代码风格和第一轮完全不同。

坏习惯 Prompt（追问式）： 
第一轮：帮我写一个用户登录的 API 接口


第二轮：用 FastAPI 写



第三轮：加上 JWT 认证



第四轮：错误处理也要完整一点
重构后 Prompt（一次性完整版）： 
用 FastAPI 实现一个用户登录 API 接口，要求：


技术栈：


  • FastAPI + Pydantic v2
    • 

  • JWT 认证（使用 python-jose 库）
    • 

  • 密码哈希用 passlib[bcrypt]
    • 



接口规范：


  • POST /auth/login
    • 

  • 请求体：{ "username": str, "password": str }
    • 

  • 成功返回：{ "access_token": str, "token_type": "bearer", "expires_in": int }
    • 

  • 失败返回标准 HTTP 错误码（401/422）
    • 



错误处理要求：


  • 用户不存在 → 401（不要区分"用户不存在"和"密码错误"，防止用户枚举攻击）
    • 

  • 请求体格式错误 → 422
    • 

  • 所有异常都要有日志记录
    • 



输出完整可运行的代码，包含必要的 import 和示例用法注释。

两种写法的结果差距，不在于模型能力，在于你给它的信息密度。

---

习惯三：把"语气词"当控制信号

这是最隐蔽的一个习惯，因为它在 Claude 上真的有效。

在 Claude 里写"请尽量简洁"，它会给你一个明显更短的回答。写"帮我稍微润色一下"，它会做轻度修改而不是大改。这些模糊的程度词，Claude 能理解并执行。

在 Codex 上，这类词几乎被当作装饰性语言处理——它不会量化"尽量简洁"是多少字，也不知道"稍微"的边界在哪里。

你需要把模糊的程度词换成可量化的约束。

模糊语气词 vs 结构化约束对比表： | 模糊写法（Claude 有效） | 结构化写法（Codex 友好） | 说明 | | 请尽量简洁 | 回答控制在 150 字以内，不要举例 | 给出明确字数上限 | | 帮我稍微润色一下 | 只修改语法错误和用词不当，不改变句子结构和原意 | 明确修改范围和禁止项 | | 输出格式好看一点 | 用 Markdown 输出，代码块加语言标记，标题用 ## | 指定具体格式规范 | | 专业一点 | 使用技术文档风格，避免口语化表达，术语首次出现时给出英文原文 | 拆解"专业"的具体含义 | | 详细说明一下 | 分三个部分说明：原理、实现步骤、注意事项，每部分不少于 3 点 | 用结构代替程度词 | | 帮我优化这段代码 | 只优化时间复杂度，不改变函数签名和返回值类型，优化后给出复杂度对比 | 明确优化目标和约束 |
规律很简单：把所有"程度词"替换成"可以被机器验证的约束"。

---

切换工具前的 5 分钟自检清单

下次在 Claude 和 Codex 之间切换之前，花 5 分钟对着这个清单过一遍：

---

╔════════════════════════════╗

║          Prompt 迁移自检清单（Claude → Codex）        ║


╠════════════════════════════════╣


║                                      ║


║  □ 角色设定                                          ║


║    有没有明确说明"你是谁"？                           ║


║    → 加上职业背景、经验年限、专注领域                ║


║                                      ║


║  □ 任务边界                                          ║


║    需求是否一次性写完整？                             ║


║    → 把所有约束条件合并到第一条 Prompt 里              ║


║                                                      ║


║  □ 输出格式                                          ║


║    有没有指定具体的输出结构？                          ║


║    → 明确格式（Markdown/JSON/纯文本）、长度、分节方式  ║


║                                ║


║  □ 程度词检查                                        ║


║    有没有"尽量/稍微/详细/专业"这类词？                 ║


║    → 全部替换成可量化的约束                           ║


║                                                      ║


║  □ 禁止项声明                                        ║


║    有没有你不想要的输出？                             ║


║    → 明确写出"不要做什么"，比"要做什么"更有效          ║


║


╚════════════════════════════╝

---

这个清单同样适用于反向迁移（Codex → Claude），只是方向不同：从 Codex 切回 Claude 时，你可以适当放松约束，让 Claude 的意图推断能力发挥作用，不需要把每个细节都写死。

如果你想同时测试同一条 Prompt 在不同模型上的输出差异，[api.884819.xyz](https://api.884819.xyz) 支持一键切换模型，是做这类对比实验最省事的方式——注册即送体验 token，国产模型完全免费，不需要分别注册多个平台账号。

---

工具不重要，习惯的可迁移性才重要

回到最开始那个问题：为什么我们会把"Prompt 习惯漂移"误判为"模型变差了"？

因为我们习惯了把工具当成黑盒——输入进去，期待一个好结果，果不好就怪工具。但 Prompt 工程的本质是一种沟通能力，而沟通能力是有语境依赖的。你和一个习惯直接说话的朋友沟通的方式，和你写一份给陌生人看的需求文档，是完全不同的两套语言系统。

真正的 Prompt 能力不是"会用某一个模型"，而是理解不同模型的期待差异，能快速切换心智模型。

这篇文章里的三个习惯，本质上都是同一件事：你在用一种语言，跟一个期待另一种语言的对象说话。

下次切换工具之前，花 5 分钟对着清单过一遍。你会发现两个工具都比以前好用了——不是因为它们变了，是因为你变了。

你现在主要用哪个模型？切换过程中踩过什么坑？欢迎在评论区聊，说不定你的案例能帮到下一个人。

---

下篇预告： 这篇聊的是在两个工具之间切换时的习惯漂移。但还有一种更隐蔽的情况：你一直只用一个模型，但它悄悄更新了——你的 Prompt 还在用旧版本的"语言"跟它说话，而你完全没有察觉。下一篇我们聊这个。

---

本文由848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#AI教程 #Prompt技巧 #Claude #Codex #人工智能 #8848AI #AI工具 #提示词工程