先别依赖Codex，先学会写Prompt

先别依赖Codex，先学会写Prompt

上周我帮一个创业团队做技术评审，他们用Codex已经三个月了。技术负责人打开后台让我看使用数据，三个月，生成了超过一万段代码，但最终合入主分支的比例不到30%。剩下的70%去哪了？大部分被删掉重写，小部分在反复修改后勉强能用，但带着大量技术债。

我问他平时的Prompt怎么写的。他翻了翻聊天记录，给我看了一句典型的话：“帮我写一个用户管理的后台接口。”

问题就出在这里。

一、Codex的能力被你低估了，但你的“表达能力”被你自己高估了

很多人以为Codex用不好是因为模型不够聪明。但过去两年我跟不同水平的开发者协作、观察他们使用Codex的方式之后，有一个判断越来越明确：大部分“烂结果”的根源，不是Codex脑子不行，是你给它的指令根本没法用。

你想想这个场景：一个资深工程师走过来跟你说“帮我写个接口”，你是不是也得追问一句，什么功能？什么框架？权限怎么控制？数据表结构是什么？异常处理逻辑？Codex不问，不是因为AI比人更懂你，而是它默认你不会在这一点上偷懒。结果大多数人真的在这一点上偷了懒。

Codex的产品负责人曾在一次访谈中提到，他们团队内部大多数人的编码方式已经发生了根本性变化，不再从打开IDE开始写第一行代码，而是从构建上下文开始。这个说法被很多文章拿去当“AI替代程序员”的论据，但少有人注意到他话里真正的重点：那些高效使用Codex的人，花在“说清楚要做什么”上的时间，远比花在“写代码”上的时间长。

这句话才是关键。

二、三个你每天都在犯的Prompt错误，每一个都在浪费你的时间

我观察了几十个开发者的Codex使用记录之后，总结出三类最致命的Prompt写法。不是因为它们看起来很蠢，恰恰是因为它们看起来“足够用”，所以才害人不浅。

第一类：“需求模糊型”，“帮我写个登录功能”

这句话你对一个刚入职的新人说了，他甚至还会追着你问七个问题。但你对Codex说了，它直接给你输出了一套完整的代码。你瞟了一眼，觉得运行没问题，上线三小时后发现：密码没加密、没有失败次数限制、Session过期时间写死在代码里、而且完全没有防御SQL注入。

这种Prompt最大的问题是你以为AI会“按照常识”帮你补充细节，但AI的“常识”是基于统计概率的通用模式，不是你的业务场景。它的登录功能可能是从一千个开源项目里学出来的，偏偏你公司的认证体系是那一千零一个。

第二类：“背景缺失型”，“把这段代码优化一下”

你发了三屏的代码过去，什么上下文都没给。Codex不知道你的QPS是100还是100000，不知道你追求的是可读性还是极致性能，不知道你是在做原型验证还是重构生产环境的核心链路。于是它给你的优化方案可能是牺牲可读性换性能的，而你恰恰需要团队里其他三个人也能维护这段代码。

Codex在没有上下文的情况下，会倾向于输出“平均最优解”，而你的业务场景几乎从来不是“平均”的。

第三类：“指令模糊型”，“你帮我检查一下”

检查什么？潜在的空指针异常？并发安全问题？还是命名不规范？算法的时间复杂度？接口的向后兼容性？你眼里的“检查”可能是安全审计，AI眼里的“检查”可能是代码规范，你们在打哑谜，而你每次都要为这个哑谜付出修改成本。

有一组对比数据很说明问题。我让同一个工程师分别用模糊Prompt和结构化Prompt完成同一个任务，统计结果如下：

这不是AI变聪明了，是你变“清楚”了。

三、写好Prompt不是玄学，是四个可复用的结构化步骤

很多人把“会写Prompt”想象成一种天赋，好像有些人天生就知道怎么跟AI说话。我不认同。过去一年我在三个不同的技术团队里推行同一套方法，发现写好Prompt本质上是一种可以被标准化的沟通结构，跟你写技术文档、做需求评审的底层逻辑完全相通。

我把这套方法拆成四个步骤，每一个步骤解决一个特定问题。

步骤一：设定角色，“你是谁？我是谁？”

在Prompt开头明确AI的角色和你自己的角色。不是为了让对话更有仪式感，而是告诉AI该调用哪一套知识体系。

比如：“你现在是一个有8年经验的Java后端工程师，精通微服务架构和DDD设计模式。我是一个全栈开发者，正在做电商系统的订单模块重构。”

这句话不是废话。你告诉AI的是：你的回答应该以Java生态为基础语言、以微服务为默认架构、以领域驱动设计为方法论。没有这句话，AI的输出会倾向于泛编程语言的通用写法，而你可能根本不用Python和Node.js那一套。

步骤二：交代背景，“我们在哪？之前干了什么？”

用最精炼的语言描述项目和任务的上下文。可以是一句话，可以是一段代码，可以是一个GitHub链接。

比如：“我们的项目是一个基于Spring Boot 3的订单管理系统。现在需要新增一个批量退款的功能，涉及到的表是orders、refund_records、user_account。这是当前order-service下的核心代码结构：[贴代码或链接]。”

这里的逻辑很简单：不要把AI当成一个什么都知道的百科全书，把它当成一个刚加入你项目、需要快速了解上下文的高级工程师。 你会给新同事介绍什么背景，就给AI交代什么背景。

步骤三：拆解任务并加约束，“具体做什么？边界在哪？”

这是最需要花时间的一步，也是大多数人最不愿意花时间的一步。

不要写“帮我实现退款逻辑”，要写：“实现一个批量退款的方法，要求：1）单次最多处理100条退款请求；2）使用数据库事务保证原子性，如果任意一条退款失败则整体回滚；3）调用支付宝和微信支付的退款接口，需要处理第三方接口超时的情况（超时时间设为5秒）；4）退款成功后更新orders表和refund_records表；5）并发条件下不能出现重复退款。”

这里的每一条约束，都是在帮AI缩小搜索空间。你给的条件越具体，AI的输出越贴合你的真实需求；你给的条件越模糊，AI就只能输出“所有人都能用的答案”，而这种答案对谁都不够好用。

步骤四：规定产出形式和协作流程，“我要什么格式的结果？你怎么配合我？”

这一步决定了你拿到的是“一段能跑的代码”还是“一个可落地的解决方案”。

比如：“请你先输出一个实现方案的简要计划（包含核心类设计和方法签名），我确认后再开始编写代码。代码符合以下规范：遵循阿里巴巴Java开发手册、为所有public方法写Javadoc注释、为关键逻辑编写单元测试、异常处理需要在日志中记录完整的堆栈信息。”

这个要求的作用不是展示你的强势，而是建立一次对话的协作契约。AI默认会一次性输出，但你让它先给方案再写代码，就给了你一个介入调整的机会，避免了它在错误的方向上一路狂奔。

四、别追新概念，先把你的“表达基本功”练扎实

最近各种文章都在讲Skills工程、Context Engineering、Loop Engineering，让很多人产生了一种焦虑：是不是我又落伍了？是不是我又得学新技术了？

我直说：这些概念都很有价值，是AI工程化的必然方向。但在你连一个结构化的Prompt都写不利索之前，它们对你的帮助极其有限。

Skills的本质是什么？是把你的工程经验封装成可复用的工作流模板，让AI按照你的习惯做事。但如果你连“我的习惯是什么”都说不清楚，你封装出来的Skill只会是一个放大了的错误模板。

Context Engineering的本质是什么？是让AI在开始工作之前就理解你的项目结构、技术选型、编码规范。但如果你在交代背景这一步就偷懒，再高级的上下文管理工具也帮不了你。

Loop Engineering听起来很酷，让AI自己规划、执行、验证、修正，人类只做决策。但你要知道，Loop的起点就是你的Prompt，如果你的方向指令是偏的，让它在闭环里自我优化只会让偏差越跑越大。

所以我的观点非常明确：Codex的更新日志你可以不看，Skills的框架你可以晚点学，但如果你不花时间练好“结构化表达”这个基本功，你在AI编程这件事上永远都是在碰运气。

五、下一步：把你的“表达资本”沉淀下来

写完这篇文章，大概率会有三种反应：

第一种人看完觉得有道理，然后继续用老方法跟Codex交互，直到下一次被一个改了三天的bug唤醒这段记忆。这很常见。

第二种人会开始有意识地按照四个步骤去写Prompt，但每写一次都觉得麻烦，慢慢地又缩回了原来的习惯。这也很常见。

第三种人会做一件事：把今天读到的这四个步骤，写成一个属于自己的Prompt模板，存在笔记软件里。 每次打开Codex之前，先把这个模板调出来，按照“角色-背景-任务约束-产出格式”填一遍。

如果你选择做第三种人，你会发现一个有趣的现象：用模板写的Prompt，第一次调试就接近可用的概率远高于你随口说的那句“帮我写一下”。这时候你才算真正建立起了对Codex的“驾驭感”，而不是被它牵着鼻子走。

最后送你一句话，这句话是我踩了足够多的坑之后才真正理解的：在AI时代，编码可能是被自动化的，但“说清楚你到底要什么”这件事，永远不会。

下一步，打开你的笔记软件，新建一个页面，把下面这个骨架复制进去，开始积累你自己的Prompt模板库。这才是你作为一个开发者在AI时代真正的护城河。

【Codex Prompt 模板】
角色设定：

AI的角色：

我的角色：

项目背景：

技术栈：

相关模块/代码：

当前状态：

任务描述：

具体需求：

约束条件（性能/安全/兼容性）：

边界情况：

产出要求：

格式：

代码规范：

协作流程（先方案后代码？直接输出？）：