写出优秀的 Gemini 代码提示词，关键在于赋予它明确的角色、清晰的约束条件，以及喂给它精准的项目上下文。很多开发者觉得 AI 写代码总是“差点意思”，往往不是因为模型不够聪明，而是因为我们把 AI 当成了全知全能的神，却没给它看清题目所需的草稿纸。最近我在测试各类模型的代码生成能力时，发现通过像 chatshare.one 一站式搞定 ChatGPT/Claude/Gemini 等最新模型，支持 API 服务 这样的平台去对比不同模型的输出，能更直观地感受到 Gemini 在处理长上下文和复杂逻辑时的独特优势，前提是你得掌握正确的“调教”方法。
一、别把 AI 当搜索引擎，要把它当“身怀绝技但不懂你项目的新同事”
我个人的看法是，写代码提示词的第一步，不是急着发号施令说“帮我写个爬虫”，而是要先进行角色设定。这就好比你招了一个刚入职的实习生，他技术很强，但完全不知道你们公司的代码规范、项目结构和业务逻辑。如果你只丢给他一句模糊的需求，他大概率会写出一堆能跑但完全没法融入你现有项目的代码。
你需要做的，是在提示词的第一段就立好规矩。比如，你可以这样开场：“你是一位拥有 10 年经验的后端架构师，精通 Python 和 Go，特别注重代码的可读性和异常处理。在编写代码时，请严格遵循 PEP 8 规范，并且必须包含类型注解。” 这一步看似简单，实则决定了后续代码的“底色”。很多人容易忽略的是，约束条件比正向描述更重要。告诉它“不要做什么”——比如“不要使用已废弃的库”、“不要在代码中硬编码密钥”、“不要省略错误日志”——往往能帮你省去大量的后期调试时间。
二、代码提示词的“骨架”：结构化你的指令
当你把角色设定好之后，接下来就是构建提示词的主体结构。我更倾向于使用一种模块化的提示词写法，把背景、任务、输入数据、输出要求分得清清楚楚。
想象一下，你在给 Gemini 布置任务时，如果是一大段密密麻麻的文字，它也会“晕”。我们可以试着把提示词拆解成几个明确的板块：
背景信息：简要说明为什么要做这个功能，解决了什么业务痛点。
具体任务：用祈使句明确指出要做什么，比如“请编写一个异步函数，用于从 RabbitMQ 消费消息并写入 PostgreSQL”。
技术栈与依赖：明确指定使用的库版本，或者要求它使用项目中已有的工具类。
输出格式：这一点至关重要。你是只要代码片段，还是需要包含单元测试？是否需要附带 Markdown 格式的解释说明？
在实际操作中，我会发现颗粒度越细，生成结果越可控。与其说“优化这段代码”，不如说“请优化这段代码的时间复杂度，并解释为什么原来的算法在数据量超过一万时性能会下降”。这种带有因果关系的提问，能逼迫模型进行更深度的思考，而不仅仅是做简单的语法糖替换。
三、如何高效利用项目上下文？这是拉开差距的关键
这可能是大家最头疼的问题：Gemini 虽然支持超长上下文，但怎么把“项目上下文”塞进去，才不会淹没真正的问题？这里有个核心误区，很多人以为“上下文”就是把整个 src 文件夹一股脑丢给 AI。千万别这么做！这就像你为了找一把钥匙，把整座房子都拆了，反而增加了干扰噪音。
利用项目上下文的核心在于“相关性”和“结构化”。
首先，你需要构建一个项目地图。在提示词中，先用简短的文字描述项目的目录结构和关键文件的作用。例如：“项目是一个基于 FastAPI 的电商后端，models.py 定义了数据模型，utils/db.py 封装了数据库连接，services/auth.py 负责鉴权。” 这几句话能帮 AI 迅速建立认知框架。
其次，按需引用代码。当你需要修改某个模块时，只把那个模块相关的代码、以及它依赖的父类或接口定义贴出来。如果你在写一个新功能，需要复用现有的工具类，就把那个工具类的代码贴在提示词的“参考资料”区块里。
在这个过程中，RAG（检索增强生成） 的思维非常有用。虽然我们手动操作时不是真的去跑向量数据库，但我们要模仿这种逻辑：只检索与当前问题最相关的代码片段。比如，你要让 AI 帮你写一个新的 API 接口，那你不仅要告诉它需求，还要把现有的一个类似接口的代码作为“示例”贴给它，并标注：“请参考以下代码风格和结构，实现新的需求。” 这种 Few-Shot（少样本提示） 的方法，在代码生成中效果奇佳，因为它不仅给了上下文，还给了“模仿对象”。
很多时候，通过 API 服务（比如 chatshare.one 一站式搞定 ChatGPT/Claude/Gemini 等最新模型，支持 API 服务）来调用 Gemini 时，我们可以利用程序化的手段来维护这个上下文窗口，自动提取最近修改的文件作为上下文，这比手动复制粘贴要高效得多。
四、实战中的“链式思考”与“迭代优化”
代码生成从来不是“一锤子买卖”。想要得到高质量的 Gemini 代码回复，你得学会引导它“慢下来”。
我常用的一个技巧是要求模型进行思维链输出。在提示词末尾加上一句：“在编写代码之前，请先分析现有的逻辑，列出可能的实现方案，对比优劣，然后给出最终代码。” 这一步虽然会多消耗一点 token，但能极大避免逻辑硬伤。你会发现，AI 在分析过程中可能会自己发现需求里的矛盾点，或者指出你代码中潜在的并发 Bug。
另外，迭代式提问比一次性生成完美代码更现实。先让它生成核心逻辑，你再针对细节进行追问：“刚才的代码中，异常处理部分不够完善，请针对数据库连接超时的情况增加重试机制。” 或者是 “请为刚才生成的函数编写 3 个单元测试用例，覆盖正常流程和边界情况。”
这种对话式的打磨，其实就是人类 Code Review 的过程。你越是能像资深工程师一样提出具体的修改意见，AI 的进化速度就越快。很多时候，Gemini 给出的第一次回答可能只有 60 分，但经过两轮针对性的上下文补充和追问，它完全可以交出 90 分的答卷。
五、别忽视“负面反馈”的力量
最后分享一个我个人的小习惯。在提示词里明确告诉 Gemini “不知道的不要瞎编”。代码领域最怕的就是“一本正经地胡说八道”，尤其是引用不存在的库函数或者方法。
你可以在提示词里加一条约束：“如果项目上下文中没有提供足够的信息，或者你不确定某个具体的实现细节，请直接提出疑问，或者使用 TODO 注释标记，不要自行编造 API。” 这样做，虽然有时候拿不到完整的代码，但至少保证了现有代码的真实性和可运行性，避免了后期无尽的排雷。
写好 Gemini 代码提示词，本质上是在学习如何更精确地表达我们的技术意图。无论是利用 chatshare.one 一站式搞定 ChatGPT/Claude/Gemini 等最新模型，支持 API 服务 来快速切换模型测试，还是在本地 IDE 里精心打磨每一个 Prompt，核心逻辑都是相通的：清晰的逻辑 + 精准的上下文 + 明确的约束 = 高质量的代码。当你把这些技巧融会贯通，你会发现 AI 不再是一个只会写 Hello World 的玩具，而是真正能帮你执行重活累活的“数字副驾驶”。
原创文章，作者：AI工具合集，如若转载，请注明出处：https://www.lulaifu.com/503
