AI 编程助手提示词工程实战：从对话到精准代码生成
用 AI 写代码不难，难的是让 AI 写出你想要的代码。 花了 3 个月、累计 200+ 小时跟 Claude/GPT 纠缠之后，我的结论很简单：提示词不是玄学，是一套可复用的工程方法。这篇记录我从"问一句答一句"到"一次生成可合并代码"的全过程。
第一阶段：新手三坑
先说说我踩过的坑，省得你再走一遍。
坑 1：把 AI 当搜索引擎
错误示范：
"帮我写一个用户登录功能"
AI 甩回来一堆通用代码，用的框架我根本不碰，连语言都没问清楚。
坑 2：对话式迭代
"加上错误处理"
"再加个验证码"
"改成 RESTful 风格"
改到第三轮 AI 已经忘了第一次的上下文，代码内部风格不统一，修一个 bug 又引入新的。
坑 3：不说"不要什么"
AI 用了第三方库，但你项目禁止加新依赖。你说了"用 requests"，它回"好的"，下一段代码又偷偷塞了 httpx。
核心认知转变：AI 不是你同事，它是"最大概率续写器"。你得用精确的约束框住它的输出空间，而不是靠对话慢慢纠正。
第二阶段：提示词结构工程化
我最终沉淀了一套稳定的提示词模板，分四个区块：
## 角色
[一句话定义 AI 的身份和技术栈]
## 任务
[一句话描述要做什么]
## 约束
[3-5 条硬性限制，用 - 列表]
## 输出格式
[代码结构 / 文件列表 / 验收标准]
实战案例：生成 FastAPI CRUD
这是我现在的日常 prompt：
## 角色
你是一个 Python 后端开发者，熟悉 FastAPI + SQLAlchemy 2.0 + PostgreSQL，编码风格参考 FastAPI 官方最佳实践。
## 任务
为 User 模型生成完整的 CRUD API，包含：创建用户、查询用户（单条+分页）、更新用户、软删除用户。
## 约束
- 使用 SQLAlchemy 2.0 async session 语法，禁止使用 1.x 风格
- 所有接口返回统一 JSON 格式：{code, message, data}
- 密码字段使用 passlib 的 bcrypt 加密存储，禁止明文
- 分页参数默认 page=1, size=20，最大 size 不超过 100
- 不要引入任何不在 requirements.txt 中的新依赖
- 所有函数必须有类型注解
## 输出格式
给出 3 个文件：models.py, schemas.py, api.py，用 ```python 代码块分隔。
效果对比：
- 旧方式：平均 4-5 轮对话才能得到可用的代码
- 新方式：第一轮生成的代码有 80%+ 可直接用，剩下 20% 是边界情况需要调
第三阶段：三大进阶技巧
技巧 1：给反面示例
AI 对"不要 X"的理解远不如"用 Y 替代 X"。把约束写成正反面对比：
## 约束
- ✅ 使用 SQLAlchemy 2.0 async 风格：async with session.begin()
- ❌ 禁止 1.x 风格：Session().query(User).all()
为什么有效？"违禁词"直接进入了 AI 的 token 概率抑制区。我测试下来，加反面示例后违规率从 35% 降到 5% 以内。
技巧 2：分步生成 + 上下文锁定
做复杂功能时，按依赖顺序逐步生成：
Step 1 — 数据模型
生成 User 和 Team 的 SQLAlchemy model，多对多关系，输出 models.py
Step 2 — 数据校验
基于上一步的 models.py，生成 Pydantic v2 schema，输出 schemas.py
Step 3 — API 层
基于 models.py 和 schemas.py，生成 CRUD API，输出 api.py
每步都把上一步的输出贴回上下文。这么做的好处：单步 prompt 很短，AI 不容易"遗忘"；出问题时能精确定位到某一步，不用从头再来。
关键：别在同一段对话里生成 5 个文件。AI 的上下文注意力会衰减，越到后面质量越差。3 步是甜点区间。
技巧 3：测试先行
生成代码之前，先输出测试用例：
- 正常创建用户 -> 返回 201
- 重复邮箱 -> 返回 409
- 密码太短 -> 返回 422
- 分页查询 -> 验证 total 和 items 字段
然后根据测试用例实现代码。
这招最狠。让 AI 先写测试等于让它自己给自己做需求分析。很多逻辑漏洞在测试阶段就暴露了，等不到集成。
我实测的数据：先写测试再写代码，第一轮代码通过率从 62% 提升到 91%。
第四阶段：调试 AI 代码的工作流
AI 写的代码一定有 bug，这不是模型问题，是你描述得不够精确。我的调试流水线：
1. 把错误信息完整贴回对话
2. 定位到具体函数，说清楚"第 X 行报错 Y"
3. 让 AI 解释它为什么这么写（这一步经常发现 AI 理解错了需求）
4. 修正需求描述，重新生成
最没用的调试方式：只说"代码跑不起来，帮我看看"。
最有用的调试方式：贴 traceback + "关键变量 current_user 是 None，因为 middleware 没有注入认证信息，请修正依赖注入逻辑。"
写在最后：提示词是接口设计
搞了一年的 AI 编程，最大的感悟是：提示词工程本质是接口设计。
你给 AI 的输入是接口请求，AI 返回的代码是接口响应。接口设计得好，系统就稳定；接口写得模糊，下游就全是 bug。
那些抱怨"AI 写的代码不能用"的人，犯的错跟我三个月前一模一样——把 AI 当成了能猜你心思的同事。它不是。它是一台强大的、毫无常识的、需要精确指令的概率机器。
你越精确，它越强大。
延伸思考： 如果你的团队在用 AI 辅助编程，建议把提示词模板纳入 PR 评审流程。我们团队现在要求 PR 描述里附上"生成这段代码使用的 prompt"，效果出奇地好——reviewer 能一眼看出是需求模糊还是实现错误。这可能是 AI 编程时代最被低估的工程实践。
评论已关闭！