口语化提示词模板库
把这一页收藏起来。下面每一条都是从真实使用中沉淀出来、可以直接复制的"说给 Codex 听"的话。每条都带使用场景和为什么这么写。中括号 [...] 里的内容是你要替换成自己情况的"槽位"。
怎么用这些模板
不要死板地照搬。每条模板的结构(角色 / 目标 / 限制 / 收尾)比字面更重要。挑你当下场景最接近的那条,把中括号里的内容换成你自己的,然后按自己的语气调整一下,直接复制到 Codex 里。
模板 1 · 描述需求(角色 / 目标 / 限制三句法)
什么时候用:每个项目的开端。这是你跟 Codex 的"第一句话"。
说给 Codex 听
我是 [你的身份,比如:一个独立咖啡店主],想做一个 [项目类型,比如:让客人扫码点单的网页]。
它需要做到:
1. [核心功能 1]
2. [核心功能 2]
3. [核心功能 3]
限制:[只用一个 HTML 文件 / 不接后端 / 手机优先 / 用 XX 风格]。
请先做一个最简单的版本给我看,我们再迭代。
角色(我是谁)让 Codex 知道为谁服务;目标(三件事)给它边界;限制(技术或视觉约束)防止它做大;最后一句"先做最简单的版本"防止它一次给你一坨。
模板 2 · 让它先做计划,再动手
什么时候用:任务听起来涉及改多个文件,你想先看它怎么打算的。
说给 Codex 听
关于 [任务描述],请先不要写代码,先给我一份计划:你打算改哪几个文件、每个文件改什么、可能会有什么风险。我看完同意了再开始。
这种"先计划再执行"的工作流能避免 Codex 一时冲动改一堆东西。看到计划你可以删、加、改,再让它动手。
模板 3 · 改 bug(描述现象,不要猜原因)
什么时候用:页面不对劲,但你不知道为什么。
说给 Codex 听
我遇到一个问题。
我做了:[你刚才做的操作,比如:点了"立即下载"按钮]
我期待看到:[你预期的结果,比如:弹出二维码]
实际看到:[实际发生的事,比如:整个页面变白,什么都没了]
浏览器控制台的报错(如果有):[把红色文字粘贴在这里]
请先帮我定位问题,再说怎么修。
"做了 / 期待 / 实际 / 报错"是修 bug 的标准四件套。零基础读者最大的错误是"我猜是 XX 出了问题"——猜的方向 9 成是错的,反而误导 Codex。直接描述现象。
模板 4 · 改设计(对比描述法)
什么时候用:你看着不顺眼,但说不出哪里不对。
说给 Codex 听
现在 [某个区块,比如:首屏] 的视觉感觉像 [一个不太理想的参照,比如:90 年代企业宣传册],但我希望它像 [理想参照,比如:Stripe 官网首屏:大字、留白多、配色克制]。
请你对比这两种感觉的差距,提出 3-5 个具体的调整建议,然后逐个改过来。
"对比描述法"绕开了你需要懂设计术语的问题。Codex 知道 Stripe 长什么样,也知道 90 年代企业册长什么样,它能自己分析差距。
模板 5 · 撤回上一步
什么时候用:Codex 刚改完,你不喜欢,想回到改之前的状态。
说给 Codex 听
刚才那次改动我不喜欢,请帮我撤回到改动之前的状态。如果已经提交了 git,就用 git revert / checkout;如果还没提交,就把文件改回去。
撤回完告诉我现在是哪个版本。
用"撤回"这个口语词,Codex 自己会判断该用 git 还是直接改文件。最后那句"告诉我现在是哪个版本"帮你确认状态。
模板 6 · 让它解释自己刚做了什么
什么时候用:Codex 改了一堆东西你没全看明白,想让它复述一下要点。
说给 Codex 听
用三句话总结一下你刚才的改动:你改了哪些文件,核心改动是什么,我下次要怎么验证它生效。不要贴代码,用人话讲。
"三句话""不要贴代码""用人话"这三个限制能逼 Codex 浓缩,不然它会给你一篇说明文。这种总结对你建立项目认知非常有帮助。
模板 7 · 让它给你三个选项
什么时候用:你不知道下一步该做什么,或者拿不准应该选哪种实现方式。
说给 Codex 听
基于现在的状态,我想 [你的目标,比如:加一个反馈表单],你有什么方案?
请给我三个选项,每个写清:做法是什么、需要多少工作量、有什么权衡。我选完之后我们再开始。
"三个选项""权衡"这两个词让 Codex 帮你扩展可能性,而不是给你一个它觉得最对的答案。零基础读者最缺的是"我不知道还可以怎么选"——这条模板能补上。
模板 8 · 移动端适配一句话
什么时候用:页面在电脑上好看,在手机上不行。
说给 Codex 听
请让这个页面在手机上也好看:多列网格应该堆叠成单列,字号略小,内边距收紧,导航如果太挤变成汉堡菜单。改完之后请告诉我大致改了哪些 CSS 规则,简短列一下。
这条特意把"堆叠""字号""内边距""汉堡菜单"这些维度都点到——比单说"请适配手机"效果好很多。最后那句"告诉我改了什么"让你慢慢长出 CSS 直觉。
模板 9 · Git 提交 + Push 一气呵成
什么时候用:做完一个小阶段,想保存进度并推到 GitHub。
说给 Codex 听
请帮我:
1. 把当前所有改动加到 git
2. 提交一次,信息写"[一句话总结这次改了什么]"
3. 提交完告诉我可以去 GitHub Desktop 点 Push 了
不要自己执行 push,这一步我手动来。
明确"不要自己 push"是为了让你保留"最后确认"的机会——Codex 可以帮你做 99%,最后那 1% 是你的安全门。
模板 10 · 集成一个第三方服务(以表单后端为例)
什么时候用:你听说有个工具能解决问题,但不知道怎么把它接到你的项目里。
说给 Codex 听
我想把 [服务名,比如:Formspree] 接到我的项目里,目标是 [你想做什么,比如:让现有的邮箱订阅表单提交后真的能收到邮件]。
请先告诉我:
1. 在 [服务名] 官网我需要做什么准备(注册、建表单、拿什么 key)
2. 我把准备好的东西告诉你之后,你帮我改我的 index.html 哪里
请等我做完第 1 步再开始第 2 步。
"等我做完第 1 步再开始"非常关键——很多服务集成需要你先去网站做些操作(注册、拿密钥),Codex 不会替你做这些。明确分两步走,避免它瞎猜你的密钥值。
使用这些模板的元规则
- 不要堆模板。一次对话用一个模板,把当前问题解决,再用下一个。
- 每次都把"完成后用三句话总结你做了什么"加在结尾。这能持续帮你建立对项目的掌控感。
- 第一次用某个模板时,把它复制到下方一个 Notes 应用里,贴上你当时用的情境和效果。三个月后你会发现自己的模板库越来越个性化。
这一页的本质
是把"跟 AI 协作"这件事的隐性知识做了显性化。十条模板的背后是十种心智模型:开端、规划、修 bug、改设计、撤回、解释、决策、移动、保存、集成。掌握心智模型,模板本身就可以丢掉。