口语化编程内功
所有的"AI 写代码教程"都讲怎么装工具,但很少有人专门讲怎么把脑子里的想法翻译成 AI 听得懂的话。这一章不教任何技术,只教你说话的方式。它是本教程最有差异化的内容,也是接下来所有实战章节默认你已经掌握的能力。建议晚上找个安静时间慢慢读。
跟传统编程的"语法"不同,口语化编程没有刚性规则——多说一句 / 少说一句都不会"报错"。但产出的差距能差出 10 倍。本章就是把那 10 倍背后的隐性规律拆开给你看。
4.1 三句话法则:角色 / 目标 / 限制
先看一个典型的"零基础读者第一次发的提示词":
"帮我做一个网站。"
Codex 收到这句话,接下来的对话只会是它反问你十几个问题。你没省时间,反而把"想清楚"这件事推给了下一轮。
把上面这句话拆成三个维度,效果立刻变好。这三个维度是:
- 角色:我是谁,在什么场景下用
- 目标:这东西要解决什么具体问题
- 限制:技术 / 视觉 / 时间上不能越过什么边界
"我是一个独立咖啡师,有家小店在大学城。我想要一页能放给客人扫码看的菜单——只有一页,手机优先,菜单分三类(咖啡 / 茶 / 糕点),价格用人民币。配色不要太刺眼,我喜欢日式咖啡店的感觉。请先做一版给我看。"
Codex 拿到这段话就能直接开始干活,而且 90% 的细节不需要再问。
角色:别只说"我",说清楚"什么场景下的我"
"我是一个独立咖啡师"——这一句话同时告诉了 Codex 几件事:
- 这不是一个企业级项目(预算和需求都更轻)
- 用户是来店里的客人(不是网上下单)
- 你可能不太懂代码(它会自动降低专业术语的使用)
新手最常见的错误是把"角色"省掉,直接说目标。结果 Codex 会按"一般人想要一个菜单"的平均水平给你,而不是按"小店老板想要一个能扫码看的菜单"的具体期待。
目标:做"什么",不是做"得怎么样"
目标要写的是客观的东西——"一个能扫码的菜单页面",而不是"一个好看的、专业的、上档次的菜单"。"好看"和"专业"是评价词,不是目标本身。把评价词留给迭代阶段去说。
限制:把"不要什么"也说清楚
限制是最被低估的一项。零基础读者通常只说"我要什么",不说"我不要什么"。后者其实更重要,因为它能砍掉 80% Codex 可能踩你雷的方向。
限制至少要覆盖三块:
- 技术限制:只用一个 HTML 文件 / 不接后端 / 不引外部库
- 视觉限制:手机优先 / 不要花哨动画 / 不要鲜艳红色
- 范围限制:只做首页 / 不做登录 / 现在不考虑国际化
4.2 先描述,再细化:两轮节奏
新手有个本能反应:"我得把所有细节一次想清楚,再开口"。这是错的方向。
正确的节奏是两轮:
用三句法说清角色 + 目标 + 大方向限制。故意不给颜色、字号、间距这种细节,看 Codex 自己怎么发挥。
它可能不漂亮,但它告诉你 Codex 的"默认理解"是什么。你现在有具体东西可以反应了。
"主标题字太小了,放大一点"、"卖点之间间距太挤"、"按钮换成圆角"——每条都针对你看到的现状,不再凭空想象。
为什么这种节奏比"一次想清楚"好?
- 你的脑子需要参照系。凭空想"我要什么颜色"会卡 20 分钟;看到一个基线版本之后说"换成更暖的颜色"只要 5 秒。
- Codex 的"默认理解"通常不差。它见过几百万张产品官网,自带审美。你不给约束,反而它能发挥得更好。
- 避免"过度规约"的浪费。你花 20 分钟规定的细节,可能 Codex 第一轮就猜对了——这 20 分钟你白花了。
三句法里的角色和目标必须清晰,这是"骨"。只有那些"细节型限制"(配色具体色号、字号 px 数、间距像素)在第一轮可以省。骨不清楚,Codex 第一轮就会跑偏得离谱,你想"基于基线版本调"都没机会。
4.3 用"找参考"代替"说细节"
这是本章最实用的一招。
当你想表达"我想要那种感觉,但说不清楚"的时候,不要硬描述。直接给一个参考。三种给法:
参考方式一 · URL
参考方式二 · 截图
如果是 Codex 不一定见过的小众网站、设计稿、甚至杂志页,你可以截图丢给它。Codex CLI 在 2026 年支持读取图片(贴到对话里就行)。
参考方式三 · 类比一个产品
当你的产品本身就有"行业标杆"时,直接说类比。这种最省事:
因为视觉的好坏是无数微小决定的合力:间距差 2px、阴影深一点、行距宽一点——单独说每一项你都没感觉,合在一起才有"高级"。你不可能一条条说出来,但你能感受到。给参考,等于把这堆隐性决定一次性打包了。
4.4 当 Codex 反问你时,这是好事
有些新手一看到 Codex 反问就慌:"我把它说糊涂了?"——恰恰相反。它反问,通常意味着:
- 它确实需要一个你才能决定的选项
- 它发现你没说清的地方比它瞎猜要好
但反问也分两种,你得能区分:
有效反问 · 求一个真决策
例子:
"这个'立即下载'按钮,你希望它跳到 App Store 链接,还是先弹出一个二维码让用户用手机扫?这两种实现差挺多,我想确认一下再写。"
这是有效反问——两种方案对实现影响不同,Codex 不能替你拍板。必须正面回答,不能糊弄过去。
- 给了你两到三个具体的选项
- 每个选项的差异 Codex 自己说不清(不是它能猜的)
- 选项之间的影响不可逆 / 影响大(选错了后面要重做)
命中这三条,就是有效反问,请认真回。
敷衍反问 · 它在 hedge
例子:
"你希望首屏标题字号是多少?要不要响应式?按钮要不要加 hover 效果?表单提交要不要错误提示?"
这是敷衍反问——这些它完全可以自己拍板,问你只是为了"把责任分担给你"。你不能说"32px、要、要、要"逐个回答——那会让你陷入决策疲劳,而且 90% 的回答你都是随便给的。
正确的回应方式是授权:
什么时候直接拒绝反问
偶尔 Codex 会问一些它自己应该知道的问题——比如"这个文件目前长什么样?"。直接告诉它:
4.5 五件事不要做
下面这五件事是新手最常踩的反模式。如果你犯了其中一条,Codex 不会报错,但产出质量会肉眼可见地下降。
反模式 1 · 一次扔十个需求
"请把首屏标题改大、配色换成蓝色、定价区高级版加个'最受欢迎'标签、表单加邮箱验证、首屏背景加一张猫的图片、底部加 social 链接、还有手机上的字小一点。"
Codex 会全做一遍,但每一项的质量都比单独做时低——它的"注意力预算"被分散了。更糟糕的是,如果其中一个改坏了,你不知道是哪个改动引发的,回退也回退不干净。
正确做法:排队,一次一件。先发改首屏标题这条,看效果,确认满意,再发下一条。你的目标不是节省时间,而是每一步都可控可回退。
反模式 2 · 在 Codex 写代码时打断
当 Codex 已经开始写文件(diff 视图在出现),你看到一半发现"哎不对,我刚才说的不对"——等它写完再说。中途按 Esc 打断,文件可能处于半成品状态,既不是改前也不是改后。然后你想纠正,它得先收拾烂摊子,效率反而低。
正确做法:让它把这一轮干完,然后说"这一轮的方向不对,请回到上一版本,我们重新来"。Git 会救你。
反模式 3 · 说"你随便"
这是最常见的礼貌陷阱。你想表达"我没意见",但 Codex 听到的是"你给我一个无功无过的答案"。结果就是页面变得平庸——居中、灰色、圆角、内边距 24px,什么都对,什么都没特点。
正确说法:
- "按你的判断来,如果有疑问选最克制的方案"
- "我没强烈偏好,你按 [某个参考] 的风格做"
- "你做你觉得最有意思的版本,我们再调"
反模式 4 · 否认它能看到的事实
Codex 跟你的浏览器是两个东西。你刷新没看到变化,可能是浏览器缓存;它读你的代码,看到的是文件最新状态。这两件事经常对不上。
"你刚才说改完了,我看根本没改。"
(实际:文件改了,只是浏览器没刷新)
结果 Codex 会怀疑自己,反复读文件、反复改,绕几圈才发现问题在浏览器侧。
正确做法:陈述具体现象,不要下结论。
"我在浏览器里强制刷新后,看到的首屏背景还是浅蓝色。你这边读取到的 index.html 里 hero 区的背景色是什么?我们对一下。"
反模式 5 · 忘了让它"总结你改了什么"
每一轮结束时,加一句:
4.6 三个万能模板
上面的内功讲完了,我们用三个最高频的模板把它落地。完整的 10 条模板库在 附录 A,这里给最常用的三个,先记在脑子里。
模板 A · 描述需求
模板 B · 修 bug
模板 C · 改设计
动手试试
选一个你心里已经有的产品想法(没有就拿"个人作品集网站"当替身)。打开你常用的笔记应用,按下面的模板写一段提示词:
- 第一段(角色):三句话写清楚你是谁、在什么场景下做这件事、目标用户是谁
- 第二段(目标):三个数字编号的核心功能,每个不超过一行
- 第三段(限制):技术、视觉、范围三类各写一条限制
- 结尾:"请先做一个最简单的版本给我看,我们再迭代"
写完之后,拿这段去问下面两个朋友(或者自己换头脑):
- "看完这段,你能脑补出我要的东西大概什么样吗?"
- "哪一段最让你没把握?"
对方答不出来的地方,就是你下次跟 Codex 说话时要补的地方。
常见踩坑
角色信息埋在第三段才出现
- 现象
- 你前两句讲完产品功能,第三句才提"对了,我是个咖啡店主"——Codex 已经按"通用产品官网"的设定开始干活了。
- 原因
- 角色信息是整段话的基调,它必须放在最前面,后面所有的句子才会被它"染色"。
- 解决
- 角色永远写在第一句。哪怕只是"我是 ____"也好。
把目标和限制写反了
- 现象
- "我要做一个手机优先的网站"——"手机优先"被你当成了目标,实际上它是限制。真正的目标是"展示我的菜单"或"卖我的产品"。
- 原因
- 限制是"边界",目标是"内容"。前者负责"不要干什么",后者负责"要干什么"。混在一起,Codex 拿不到清晰指引。
- 解决
- 问自己一句:"如果这件事做到 100 分,我希望看到什么?"答案是目标。"如果做到 100 分但越界了,我会皱眉的是什么?"答案是限制。
太啰嗦,Codex 抓不到重点
- 现象
- 你写了 800 字的需求,觉得很详细很负责。Codex 读完先做出来一个版本,你发现关键信息被忽略了。
- 原因
- 800 字里有 80% 是"为什么我想做这件事"、"我的背景故事"、"我之前试过什么"——这些对 Codex 没用。它只关心你要它做什么。
- 解决
- 所有提示词控制在 150-300 字。背景故事一句话带过。删掉"我觉得"、"我希望"、"我想要"这些填充词,直接说事。
每次都从零开始重新解释项目
- 现象
- 同一个项目,第十次对话你还在说"我是个咖啡师,我的项目是……"。
- 原因
- Codex 的上下文是每次会话独立的。
/new之后它就忘了。但在同一次会话内,它记得很清楚。 - 解决
- 1)同一个项目尽量留在同一次会话里完成关键节点;2)对长期项目,在项目目录建一个
AGENTS.md文件,把"我是谁、项目是什么、限制有哪些"写进去,Codex 启动时自动读。详细做法在第 03 章。
觉得"已经讲过"就省略上下文
- 现象
- 你说"把上次那个改一下"——Codex 不知道你说的是哪次哪个。
- 原因
- "上次"在你的大脑里很清楚,在 Codex 的上下文里可能很模糊(尤其当中间穿插过别的对话)。
- 解决
- 每次给一个明确的指代:"index.html 里的定价区"、"刚才提到的那个邮箱表单"、"5 分钟前你改的标题"——明确的指代比"那个"省 10 轮对话。
用评价词代替具体描述
- 现象
- "做得高大上一点"、"再专业一点"、"看起来要更厉害"——Codex 不知道你的"高大上"是金色奢华、还是科技感、还是日式极简。
- 原因
- 评价词是主观感受,不是可执行指令。Codex 没法把"高大上"翻译成具体的 CSS 改动。
- 解决
- 评价词后面必须跟一个参考或具体维度。"高大上,像 Apple 官网那种"、"专业,字体小一点、间距更宽"——这样它就有方向了。
开始动手了才发现自己不知道想要什么
- 现象
- 第三句法的"目标"那一栏你写了三遍都不满意——其实你心里还没想清楚自己要做什么。
- 原因
- 这不是 Codex 的问题,是你的产品没想清楚。继续硬上,只会得到一个你也不满意的东西。
- 解决
- 暂停,关掉 Codex。拿一张白纸或一份 Notes,写下:1)我的产品解决了谁的什么问题?2)用户用完之后会跟朋友怎么介绍?3)如果只能砍到只剩三个功能,会留哪三个?写完再回来开 Codex。这是最划算的"返工"。