和AI聊代码，很多人觉得别扭，像是跟一个听不懂话的实习生说话。你说东，它可能给你西。问题不在AI，在于我们没把话说清楚。把AI当成一个有无限知识储备、但毫无项目背景的初级程序员，沟通就会顺畅很多。 它不知道你的项目是干嘛的，也不懂你的个人习惯，你给它多少信息，它就办多少事。模糊的指令只会得到模糊的代码。
第一步，也是最重要的一步，是给够上下文。直接说“写个用户登录函数”，AI给你的八成是个最基础的版本，可能用的是你不喜欢的库，或者压根没考虑安全性。你应该这样说：“我正在用Python和Flask框架开发一个电商网站的后端。请你写一个处理用户登录的函数。数据库用的是PostgreSQL，用户密码是用bcrypt加密存储的。”你看，这样一说，语言（Python）、框架（Flask）、数据库类型、加密方式这些关键信息都给到了，AI就能生成更贴近你需求的代码。 把技术栈、项目目标、当前代码环境说清楚，是拿到可用代码的基础。
接着，你要给AI定义一个角色。 这听起来有点多余，但效果很好。因为这能引导AI在它的知识库里，优先调用特定领域的知识和代码风格。 比如，你可以这么开头：“你是一位精通网络安全的Python后端专家。” 这句话会给AI一个行为框架，它生成的代码会更注重安全性，可能会自动加入一些防止SQL注入或者XSS攻击的考虑。如果你说“你是一位注重代码可读性和维护性的高级工程师”，那么它返回的代码注释可能会更详细，结构也更清晰。
然后，必须清晰地描述功能逻辑，最好是分步说明。 人类程序员在写代码前，脑子里会有一个执行步骤。你需要把这个步骤告诉AI。不要指望它能猜到你的心思。
举个例子，假设你要写一个处理用户上传头像的功能。
一个糟糕的提示是：“帮我写个上传头像的功能。”
AI可能会给你一段最简单的文件接收代码，没有验证，没有处理，什么都没有。
一个清晰的提示应该长这样：
“请为我的Flask应用写一个处理用户上传头像的函数，命名为upload_avatar。
这个函数需要执行以下步骤：
1. 从POST请求中接收上传的文件，文件字段名为avatar。
2. 检查文件是否存在。如果不存在，返回400错误，JSON内容为{'error': 'No file part'}。
3. 检查文件名是否为空。如果为空，返回400错误，JSON内容为{'error': 'No selected file'}。
4. 检查文件后缀名，只允许.jpg, .jpeg, .png格式的图片。如果格式不对，返回400错误，JSON内容为{'error': 'Invalid file type'}。
5. 检查文件大小，不能超过2MB。如果超过，返回400错误，JSON内容为{'error': 'File size exceeds limit'}。
6. 生成一个新的、唯一的文件名，可以使用UUID来避免重名。
7. 将文件保存到服务器的/static/avatars/目录下。
8. 如果一切成功，返回200状态码，JSON内容为{'message': 'Upload successful', 'filename': '新的文件名'}。”
这种分步拆解的方式，就像写一份详细的需求文档，AI基本上只能严格按照你的步骤来实现，出错的概率大大降低。 对于复杂的逻辑，这种方法尤其有效。
提供输入和输出的示例，是另一个非常有效的技巧，这在AI领域被称为“少样本学习”（Few-shot Learning）。 语言描述总会有歧义，但例子不会。
比如，你要写一个解析特定格式字符串的函数。你可以这样描述：
“请写一个Python函数parse_user_info，这个函数接收一个字符串作为输入，返回一个字典。
这个字符串的格式是'名字:年龄:城市'。
下面是一个例子：
输入: '张三:30:北京'
输出: {'name': '张三', 'age': 30, 'city': '北京'}
请注意，年龄需要转换为整数类型。”
有了这个具体的例子，AI就能准确理解你的数据结构和类型转换需求。 它会看到冒号是分隔符，看到输出的字典键是什么，还知道年龄字段需要从字符串变成数字。这比你用一大段话去描述“请解析一个以冒号分隔的字符串，第一个部分是姓名，第二个是年龄…”要直接得多。
约束和规范也要明确。 你希望AI用哪个库？有没有性能要求？错误处理机制是怎样的？这些都要说清楚。
“请使用requests库而不是urllib来发送HTTP请求。”
“这个函数的执行时间需要非常快，请避免使用循环嵌套，优先考虑性能优化。”
“在函数开头要添加详细的文档注释（docstring），说明函数的功能、参数和返回值。”
“请遵循PEP 8代码风格指南。”
这些约束就像是代码审查的规则，提前告诉AI，它就能生成更符合团队规范和项目要求的代码。
最后，要把和AI的交互看作是一个持续对话和迭代的过程。 不要期望一次就能得到完美的最终代码。AI给出的第一版代码，应该被看作一个草稿。 你需要审查它，然后给出具体的反馈来修正。
比如，AI给你的代码里用了一个你不想用的方法。你可以直接说：“刚才的代码不错，但是不要使用os.system()，请用subprocess模块来替代，因为这样更安全。”或者“你生成的这段代码没有处理当文件不存在时的异常，请加上try-except块来捕获FileNotFoundError。”这种具体的、针对性的反馈，能帮助AI快速定位问题并进行修正。
把这些原则结合起来，你给出的提示词就不再是一句简单的话，而是一份小型的、结构清晰的需求文档。 它应该包含：
1. 角色（Role）：你希望AI扮演什么样的专家。
2. 上下文（Context）：项目背景、技术栈等信息。
3. 任务（Task）：具体要做什么，用分步逻辑来描述。
4. 示例（Examples）：清晰的输入输出例子。
5. 约束（Constraints）：技术选型、代码风格、性能要求等。
6. 输出格式（Output Format）：你希望它如何返回结果，比如只要代码，还是要加上解释。
养成这样的习惯后，你会发现AI生成的代码质量会好很多。这省下的修改和调试时间，远比你认真编写提示词花的时间要多。归根结底，和AI协作编程，考验的不仅仅是AI的能力，更是我们自己定义问题、拆解问题和清晰表达的能力。
评论前必须登录！
注册