我发现一个很有意思的现象：同样用Claude Code写代码，有的人产出一坨需要反复修改的屎山，有的人一次就能拿到能跑的代码。差别不在工具，在prompt。
这话不是我编的。我观察了身边十几个经常用AI编程的朋友，发现真正用得好的那几个，prompt都有一个共同点——不是更长，而是更具体 。
别再说”帮我写个函数”#
这是最常见的烂prompt：“帮我写一个排序函数”。
然后AI给你写了一个冒泡排序。你一看，心想”这也太基础了吧”。但你有没有想过，你的指令就这么基础？
AI不是你肚子里的蛔虫。你说”排序函数”，它不知道你排什么数据、数据量多大、要不要稳定排序、对时间复杂度有没有要求。它只能给你一个最安全的默认答案。
好的prompt是这样的：
“用Python写一个排序函数，要求：1）输入是包含dict的list，每个dict有name和age两个字段，按age升序排列 2）相同age时按name字母序排列 3）返回新list，不修改原数据 4）加上类型提示”
看到区别了吗？不是字数多，而是你把约束条件 都说清楚了。AI不需要猜你要什么，直接给你要的。
给AI角色设定，别觉得矫情#
“扮演一个有10年经验的Java后端架构师”——这句话看起来像在玩过家家，但实测有效。
为什么？因为不同角色关注的东西不一样。一个初级程序员写代码可能不考虑异常处理，一个架构师写代码会想到可扩展性和边界情况。当你给AI设定了角色，它的输出风格会跟着变。
比如你要写一个支付接口：
“你是一个有10年经验的支付系统架构师，帮我设计一个订单支付接口。需要考虑：幂等性、超时处理、并发扣减、退款流程。先给出接口设计，再写核心代码。”
和不加角色设定相比，加上的版本会把边界情况和异常处理都写进去，而不加的版本可能只写一个快乐的路径。
把大任务拆开，别一口气丢给AI#
这是我踩过最贵的坑。有一次我直接丢给AI一个需求：“帮我写一个完整的用户管理系统，包括注册、登录、权限管理”。
结果呢？它给了我一个看起来很完整但到处是bug的东西。改了一整天，还不如自己写。
后来我改成了分步来：
- 先让它设计数据库表结构
- 确认表结构没问题，再让它写注册接口
- 注册接口跑通了，再写登录接口
- 最后写权限管理
每一步我都review，发现问题就及时纠正。最终的效果比一次性让它全写好得多，而且总耗时反而更短。
AI适合做原子任务，不适合做架构决策。 你负责拆分和把控方向，它负责执行。
给示例，别只给规则#
有时候你想要某种特定的代码风格，但怎么描述都描述不清楚。这时候最有效的办法不是写规则，而是直接给一个示例。
比如你想要一种特定的错误处理风格：
“按照下面这种风格写错误处理：
不用try-catch包裹整个函数，只在可能失败的操作处捕获。
捕获后不要静默吞掉异常，要记录日志并返回用户友好的错误信息。
示例：
def get_user(user_id):
if not user_id:
raise ValueError(“user_id不能为空”)
user = db.query(“SELECT * FROM users WHERE id = ?”, user_id)
if not user:
logger.warning(f”用户不存在: {user_id}“)
return None
return user”
AI看到示例之后，比你写十行规则描述都管用。这就是Few-shot的力量。
最后说一句#
prompt工程不是玄学，是沟通。你跟同事对接需求的时候，说清楚背景、约束、期望结果，同事就能给你想要的东西。AI也一样，只不过它不会主动问你”你具体想要啥”，所以你得自己把话说完整。