大家好呀，我是 Lazy熊。
最近这段时间，我越来越明显地感受到一件事。
很多人在聊 AI 编程的时候，关注点其实都差不多。看模型、看价格、看速度、看功能，或者看哪个工具最近更火。
这些当然重要。
但真到自己上手之后，你会发现，最后真正决定体验的，往往不是这些东西。
而是一个更基础、但特别容易被忽略的问题：
你到底会不会给 AI 下指令。
尤其是像 Codex 这种偏执行型的 AI 编程工具，这一点会特别明显。
有时候你会觉得它真的很好用，像个靠谱的工程师。你把需求交给它，它能读上下文、能理解你的目标、也能给出相对稳的结果。
但有时候你又会觉得它不太对劲。不是完全不能用，而是总差那么一点。
有时候是方向不对。
有时候是它改得太多。
有时候是讲了一大堆，但就是不落地。
还有时候看起来写得挺像那么回事，结果一跑就报错。
我自己这段时间也一直在用 Codex 做各种事，修 bug、补功能、看代码、重构逻辑，来回试了不少次之后，我有一个越来越确定的判断：
很多人不是不会用 Codex，而是还没掌握跟它协作的方式。
所以这篇文章，我不打算讲太虚的东西。就想把我自己用下来觉得最有用的一些提示词技巧，还有几个最常用的模板，完整分享给大家。
如果你平时也在用 AI 写代码、改代码，或者想把 AI 真正用进自己的开发工作流，这篇应该会有点帮助。
1. 先说结论：Codex 好不好用，关键不在“会不会问”，而在“会不会派活”
刚开始用 AI 编程的时候，很多人的习惯其实很像在搜索。
遇到一个问题，顺手就丢一句过去：
“帮我看看这段代码。”
“帮我修一下这个 bug。”
“帮我优化一下。”
“帮我写个页面。”
这些话当然不是不能用。
但问题是，它们太像一句随口说的话了。
对于人来说，可能还能靠经验脑补一点上下文。
但对于 AI 来说，这种信息通常是不够的。
因为它根本不知道：
你真正要解决的问题是什么；
你现在在什么项目里；
哪些地方可以改，哪些地方不能动；
你是想先分析，还是直接修改；
你最后想拿到的是思路、代码，还是一整套方案。
这些你如果都不说，Codex 就只能自己猜。
而它一旦开始猜，结果就很容易不稳定。
所以我现在越来越觉得，提示词这件事，本质上不是在“考验 AI 聪不聪明”。而是在尽量减少它需要猜的部分。
说得直接一点就是：
好的提示词，不是让 AI 更强，而是让它少跑偏。
这一点想明白之后，很多问题其实就顺了。
2. 我后来慢慢发现，Codex 更像“协作对象”，不是“问答工具”
这一点我自己感受挺深的。
很多人现在用 AI，还是习惯于“我问一句，你答一句”的方式。这种方式也能用，但如果放在 Codex 身上，我觉得并不是最适合的。
因为 Codex 更像一个正在跟你一起做项目的人。
你不是在问它一个知识点。
你是在给它派一个任务。
你要告诉它目标。
告诉它背景。
告诉它边界。
告诉它优先级。
告诉它先做什么、后做什么。
比如同样是一个 bug，如果你只是说：
帮我看看这段代码哪里有问题
它大概率会回你一段泛泛的分析。
但如果你换成这样：
这是一个 React 后台页面。点击保存后接口已经成功返回，但列表没有刷新。请先判断根因，再给最小改动方案，不要重构无关代码，最后告诉我怎么验证。
你会发现，输出质量通常会稳定很多。
因为这时候它拿到的，不是一句模糊请求。
而是一个相对完整的工程任务。
它知道背景是什么。
知道问题现象是什么。
知道你要它先分析，再修改。
也知道你不希望它顺手大改一通。
说到底就是一句话：
你越像在跟一个工程师协作，Codex 越容易表现得像一个工程师。
3. 我自己最常用的几个提示词技巧
这部分我不讲复杂理论，就直接讲我平时最常用、也最有体感的几个动作。
第一，先说目标，再贴代码
这个是最基础的。
很多人一着急，就直接把代码扔过去，然后来一句“你帮我看看”。但问题是，只看代码，AI 其实很难一下判断你的真实意图。
你到底想让它干嘛？
是修 bug，还是解释逻辑？
是优化结构，还是重构代码？
是要思路，还是要直接改？
所以我现在更习惯先把目标说清楚，再给材料。
比如：
我现在要解决的是表单提交成功后页面状态没有更新的问题，
技术栈是 React + TypeScript，下面是相关代码。
你会发现，只是多加了这一句，后面的方向就会清晰很多。
因为任务先被钉住了。
它不会一开始就往别的方向跑。
第二，一定要把“不能做什么”写出来
这一点我真的很想单独强调一下。
很多人写提示词，只会写自己想要什么，但很少写自己不想要什么。可实际开发里，后者往往更关键。
因为 AI 一旦没有边界，就很容易开始“顺手优化”。
本来你只是想让它修一个状态更新问题，结果它顺便把整个组件结构都给你调了。你说它完全错吧，也不是。但它显然没有按你的真实意图来。
所以我现在很常写的一段就是：
-
不要重构无关代码
-
不要引入新依赖
-
不要修改现有接口定义
-
不要调整样式
-
优先最小改动
这几句话看起来很普通，但非常有用。
因为它能明显降低 Codex “发挥过度”的概率。很多时候，不是它不行，而是它太想帮你做好了。
但开发里有时候最需要的，恰恰不是“做更多”，而是“只做该做的”。
第三，提前规定输出格式
还有一个我自己很常用的小技巧，就是提前把输出格式定下来。
很多 AI 的回答，不是没价值，而是太散。它会讲很多东西，但你真正想拿到的其实就几个点：
-
根因是什么
-
修改方案是什么
-
关键代码在哪里
-
改完怎么验证
-
有没有风险
那最简单的办法，就是直接告诉它，你要它怎么输出。
比如：
> 请按以下格式输出：
> 1. 根因判断
> 2. 修改方案
> 3. 关键代码
> 4. 验证步骤
> 5. 风险提醒
你把格式定下来之后，结果通常会更集中，也更方便直接使用。
不然很多时候，它会不自觉写成一段“讲解型回答”。你还得自己从里面再整理一遍。
第四，要告诉它优先级
这个也是我后面越来越在意的一件事。
很多人给 AI 提需求，习惯把所有要求一次性都写上去。
既要修 bug，
又要改动最小，
又要提高可读性，
又要兼容旧逻辑，
最好顺便再做一点优化。
这些要求单看都合理。
但全部平铺放在一起，AI 不一定知道先满足哪一个。
所以更好的方式，是把优先级讲清楚。
比如：
> 第一优先级是修复当前 bug。
> 第二优先级是保持改动最小。
> 第三优先级是尽量保留现有结构。
> 如果需要大规模重构，请先说明原因，不要直接执行。
你把顺序一讲清楚，它的输出会更稳。因为它终于知道，什么是必须保证的，什么是可以往后放的。
第五，复杂任务时，先让它复述理解
这一招我自己觉得特别好用。
如果任务比较复杂，或者你自己都担心描述得还不够清楚，那可以先别让它马上开写。
先让它复述一下它理解到的内容。
比如：
> 在开始之前，请先复述你对任务的理解，包括目标、限制条件和你的执行顺序。
这一句的价值其实很直接。
它能帮你提前发现偏差。
不然最怕的情况就是，它从一开始就理解歪了，后面还一路歪下去。等你看到结果时，已经浪费了好几轮。
尤其是复杂项目、老模块、多人协作场景，这一步真的很省时间。
4. 我现在基本都按一个固定公式来写提示词
如果把上面这些经验再压缩一下，我现在写 Codex 提示词时，脑子里基本就是一个固定公式：
任务目标 + 项目背景 + 限制条件 + 输出格式 + 执行要求
这 5 个模块，我觉得已经能覆盖大多数常见场景了。
第一，先告诉它要干嘛。
第二，告诉它你现在在什么上下文里。
第三，明确哪些地方不能乱动。
第四，规定你想拿到什么形式的结果。
第五，再告诉它是先分析，还是直接动手。
很多人总在找一句“万能神 prompt”。
但我自己的感受是，真正有用的，不是某一句写得多漂亮的话，而是你有没有把这 5 件事说清楚。
你说清楚了，Codex 基本就不会太离谱。
你说不清楚，它就只能靠猜。
5. 下面这几个模板，是我自己最常用的
我按不同场景放几个模板，大家可以直接改着用。
模板一：修 bug
我需要你帮我定位并修复一个 bug。
项目背景：
当前现象：
预期行为：
请先阅读相关代码并判断根因。
如果能确认根因，请给出最小改动方案。
限制条件：
- 不要重构无关代码
- 不要引入新依赖
- 不要修改现有接口定义
请按以下格式输出：
1. 根因
2. 修改点
3. 关键代码
4. 验证方式
5. 风险提醒
这个模板我自己用得挺多。尤其适合那种问题很明确，但你不希望 AI 改太多的场景。
模板二：新增功能
我需要在现有项目里新增一个功能。
技术栈：
当前已有逻辑：
目标功能：
请先基于现有结构设计实现方案，优先复用已有模式和代码风格。
限制条件：
- 不要大规模重构
- 不要影响无关模块
- 命名风格保持一致
如果信息足够，请直接给出可落地代码；
如果信息不足，请先指出缺失信息。
输出格式：
1. 实现思路
2. 涉及文件
3. 关键代码
4. 风险与边界情况
5. 测试建议
这个模板适合新增页面、接口联调、表单逻辑、交互功能这些场景。重点是让它基于现有项目去写，而不是自顾自起一套新风格。
模板三：重构代码
请帮我重构下面这段代码。
目标：
提高可读性和可维护性，同时保持现有功能不变。
当前问题：
限制条件：
- 不要改变对外接口
- 不要引入新依赖
- 不要过度抽象
优先级：
1. 先保证行为一致
2. 再考虑结构优化
请输出：
1. 当前主要问题
2. 重构策略
3. 重构后的代码
4. 为什么这样改
5. 回归测试建议
这里面最重要的一句，其实就是“保持现有功能不变”。
因为 AI 一到重构场景，很容易一边重构一边把逻辑也改掉。所以这条边界一定要提前钉住。
模板四：先分析，再动手
先不要直接改代码。
请先阅读我提供的上下文，分析当前实现方式。
然后告诉我：
1. 当前逻辑是怎么工作的
2. 问题可能出在哪里
3. 有哪些可选方案
4. 哪种方案改动最小、风险最低
在我确认之前，不要直接重写代码。
这个模板特别适合那种你自己也没完全看懂的模块。先把思路理顺，再决定怎么改，会更稳一些。
6. 最后说一点我自己的真实感受
写到这里，其实核心意思也差不多了。
如果让我再用更简单的话总结一下，我会这么说：
第一，Codex 不是不能用，而是很多人还没找到正确的使用姿势。
第二，真正决定结果质量的，往往不是模型本身，而是你有没有把任务讲清楚。
第三，不要总想着一句提示词解决所有问题，很多时候，清晰的目标、边界和顺序，比“高级提示词”更重要。
我自己现在越来越强烈的一个感受就是：
AI 编程这件事，拼到后面，拼的其实不是谁工具更多，而是谁更会描述问题、拆解任务和管理输出。
你越会这些，Codex 就越像一个靠谱助手。
你越是随口一句，它就越容易变成“时灵时不灵”。
所以如果你最近也在用 Codex，我会很建议你把思路从“怎么问 AI”，切换成“怎么带着 AI 一起干活”。
这个变化看起来不大，但一旦转过来，使用体验真的会完全不一样。
今天就先分享到这里。
如果你也在做 AI 编程，或者想把 Codex、Cursor、Claude 这类工具真正用进自己的工作流，后面我也会继续分享一些更实战的提示词、流程和案例。
最后分享我现在自用的api中转站，支持codex/gemini/claude 优点是稳定，同步比较下来性价比高。
