前言在 AI 辅助编程日益普及的今天如何高质量地与 AI 协作已成为开发者的核心技能。本文将通过正反两方面的案例展示提示词质量对编程结果的决定性影响并总结出一套实用的 AI 协作行为准则。1. 提示词正确使用案例本节展示了 3 个覆盖不同角色开发、安全、运维的正面案例演示如何使用结构化提示词引导 AI 生成高质量代码。所有代码文件均由 AI 根据提示词自动创建和生成。1.1 开发角色猜数字游戏作为开发者不仅要保证核心功能还要充分考虑各种异常情况如非数字输入确保代码健壮性。程序应“优雅”地处理异常而非直接崩溃。AI 提示词示例角色你是一位注重代码稳健性的 Python 开发者。任务编写一个猜数字游戏的脚本。约束随机生成 1~100 的整数使用while循环持续猜测必须处理非数字输入禁止程序报错猜对后必须输出 Bingo 并退出。参考使用input()获取用户输入使用random.randint(1, 100)生成目标数字。验收标准输入非数字提示“无效”并继续循环输入 50 时输出 Bingo输入 60 时提示 Too big。AI 生成的代码如下 (guess_number.py)1 import random 2 3 target random.randint(1, 100) 4 5 while True: 6 user_input input(请猜一个1-100的数字) 7 try: 8 guess int(user_input) 9 if guess target: 10 print(Bingo!) 11 break 12 elif guess target: 13 print(Too big) 14 else: 15 print(Too small) 16 except ValueError: 17 print(无效)代码说明使用random.randint(1, 100)随机生成目标数字。使用while True循环持续让用户猜测。使用try-except ValueError完美处理非数字输入提示“无效”并继续循环。猜对后输出 Bingo! 并使用break退出。1.2 安全角色密码强度检测密码安全是系统安全的第一道防线。我们需要编写一个脚本检测密码强度帮助用户设置符合要求的密码。AI 提示词示例角色你是一位安全审计工程师。任务编写一个 Python 密码强度检测脚本。约束长度必须在 8~16 位必须同时包含数字和字母必须包含特殊字符如 !# $ %满足所有条件输出 Strong否则输出 Weak。参考使用str.isdigit(),str.isalpha()检测字符类型。验收标准输入 abc123!x 输出 Strong输入 abcdefg 输出 Weak (缺数字和特殊字符)。AI 生成的代码如下 (password_checker.py)1 password input(请输入密码) 2 3 has_digit any(c.isdigit() for c in password) 4 has_alpha any(c.isalpha() for c in password) 5 has_special any(c in !#$% for c in password) 6 length_ok 8 len(password) 16 7 8 if has_digit and has_alpha and has_special and length_ok: 9 print(Strong) 10 else: 11 print(Weak)代码说明检查密码长度是否在 8~16 位。使用str.isdigit()和str.isalpha()检查是否包含数字和字母。使用自定义集合检查是否包含特殊字符。只有所有条件满足才输出 Strong。1.3 运维角色端口存活检测在运维工作中及时发现服务器端口异常是保障稳定运行的关键。AI 提示词示例角色你是一位资深运维开发工程师。任务编写检测 localhost 80 端口存活的脚本。约束超时设置为 1s如果连接失败必须重试 2 次最终成功输出 UP失败输出 DOWN使用socket库。验收标准端口存活时输出 UP端口不可达时重试后输出 DOWN。AI 生成的代码如下 (port_check.py)1 import socket 2 3 def check_port(host, port, timeout1, max_retries2): 4 attempts max_retries 1 5 6 for attempt in range(attempts): 7 sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) 8 sock.settimeout(timeout) 9 10 try: 11 result sock.connect_ex((host, port)) 12 if result 0: 13 sock.close() 14 return True 15 finally: 16 sock.close() 17 18 return False 19 20 host localhost 21 port 80 22 23 if check_port(host, port): 24 print(UP) 25 else: 26 print(DOWN)代码说明使用socket库检测端口。超时设置为 1s (sock.settimeout(1))。使用connect_ex进行检测。连接失败时重试 2 次共尝试 3 次。2. 提示词使用中的常见问题根据日常工作我们可以总结出 AI 编程中常见的四个“坑”及其改进方法。2.1 需求不明确问题描述提示词过于模糊导致 AI 做出大量假设。例如只说“写一个用户注册 API”AI 会自行决定框架、字段和验证规则生成的代码往往不符合实际预期。改进方案提供完整上下文包括技术栈Flask/FastAPI、接口路径、请求方法、字段定义、验证规则、返回格式及异常处理。2.2 上下文缺失问题描述缺乏量化基线和架构约束。例如修复 N1 查询问题时如果不给出“性能提升目标”或“禁止修改表结构”的约束AI 可能会给出无法落地的建议。改进方案建立“项目上下文文档”包含技术栈、架构约束、数据库 Schema 等。表 1正反提示词在本案例中的作用要素在本案例中的作用如果缺失会怎样项目背景锁定技术栈和架构风格AI 会自动遵循项目规范AI 可能引入无关依赖或错误模式约束条件明确定义优化边界和禁区AI 可能引入新缺陷或修改不安全的表验收标准3 条中的验收标准明确AI 能判断是否有有效的依据只能让人工一审2.3 异常处理不完善问题描述忽略边界条件导致生产事故。例如批量发送短信任务如果没有考虑服务重启、并发竞争、重试机制等极易导致重复发送或消息丢失。改进方案在提示词中显式列出异常场景幂等性、并发锁、超时重试。表 2缺少边界条件可能引发的事故缺少的边界条件多 worker 部署时可能的故障可能引发的事故缺少幂等处理多个 worker 会重复发送同一条短信重复扣短信费缺少并发控制两条短信同时发送状态更新冲突重复发送短信缺少重试机制网络抖动导致部分 API 调用失败消息永久丢失短信漏发缺少优雅关闭进程被 kill 时正在处理的短信被丢弃大量未发送缺少超时控制某条短信阻塞整个 Celery worker 进程队列积压2.4 需求描述不完整问题描述“挤牙膏”式的迭代。用户像切香肠一样一点点提需求先写基础版 - 加过期处理 - 加刷新逻辑...导致 AI 每次都在旧代码上打补丁最终代码结构混乱难以维护。改进方案一次性给出完整需求。利用“项目上下文文档”避免重复描述公共信息专注于当前任务的完整逻辑。表 3五步迭代 vs 一步到位对比维度五步迭代的解决方策一次性给出的完整解决方案代码结构每轮都在上一轮基础上打补丁层层嵌套直接设计统一的 Token 类API 一开始就组织好测试覆盖率每轮只测新增功能老功能可能退化完整设计测试用例首轮就覆盖所有场景格式规范第一轮不规范后续几轮不一致开始就统一命名和返回值格式调试难度出错时要排查是哪一轮引入的问题出问题就是整体设计问题定位更快3. 与 AI 协作的行为准则为了最大化 AI 的效能建议遵循以下三条核心准则。3.1 验收优先先定义正确标准将 TDD测试驱动开发思想引入 AI 协作。先写验收标准再让 AI 写代码。反例“帮我写个登录功能”。正例“帮我实现登录要求密码错误返回 401成功返回 JWT TokenToken 有效期 2 小时”。这样 AI 生成的代码天然符合预期且方便验证。3.2 小步推进一次只做一件事把大任务拆小降低试错成本。第一轮先实现基础功能。第二轮加上异常处理。第三轮完善错误码和日志。每完成一个任务立即测试验证确认没问题再进入下一个。3.3 善用版本控制Git 是你可靠的恢复工具在使用 AI 编程时Git 不仅仅是代码管理工具更是你的“后悔药”。每个新功能从干净的 Git 状态开始确保git status无未提交变更随时可以通过git checkout .一键还原。一个小功能点一次提交不要等到完成所有功能再提交。对于 AI 生成的每个独立可工作的部分都应当及时提交。遇到问题及时重置如果 AI 的多次修改让代码越来越复杂不要继续“修补”。使用git reset --hard HEAD回到已知的干净状态开启新对话重新用完整的提示词来解决。避免累积问题多次失败的尝试会产生一层又一层的修补代码。当你最终找到解决方案时先回滚再干净地实现而不是在失败代码上继续修改。3.4 及时验证不要盲目信任在 AI 修改了代码后不要立刻开始下一个任务而是先测试验证当前的修改是否正确。正确的做法是对于 AI 生成的代码一定要及时验证如图 1 所示。这种“修改一步验证一步”的工作节奏能够将问题的解决成本降到最低。(注修改文件 - 运行测试 - 测试通过? - 是:继续下一个 / 否:解决问题)希望这篇整理后的博客内容对你有所帮助如果有具体的代码需要补充或调整欢迎随时告诉我。