开发者专属提示词技巧

我做开发这几年，AI工具几乎重塑了我的工作方式。但很多人用AI写代码的方式，说实话挺浪费的——要么把它当万用许愿机，要么拿过来直接复制粘贴，结果写出来的东西bug一堆。

问题不在AI，在于你怎么跟它说话。

这篇文章不搞那些花哨的理论，就聊我自己踩过的坑、总结的经验，都是实打实的干活技巧。

先搞清楚AI适合干什么

我最开始用ChatGPT写代码的时候，干了一件很蠢的事：直接跟它说"帮我写个电商网站"。结果它给我返回了一坨看起来像模像样、但跑都跑不起来的东西。

后来我明白了，AI最适合的是帮你完成你已经想清楚了的、边界清晰的小任务。比如"用React写一个带验证的登录表单"、"把这个函数改成异步的"、"给这段代码写单元测试"——这种AI能发挥最大价值。

大项目怎么办？你自己搭骨架，让AI填肉。

还有个坑，就是看到代码不审查直接粘进项目里。我第一次这么做的时候，引入了一个XSS漏洞——AI生成的代码里直接拼接了用户输入到DOM里，没有任何转义。从那以后，AI写的每一行我都会过目。不是说AI不行，而是它不理解你的上下文，你的安全要求，你的业务约束。

角色设定这件事，真的有用

一开始我也不信什么"你是一个资深工程师"这种提示词，觉得挺傻的。但实际用了之后发现确实有区别。

不设定角色的时候，AI给你的代码风格飘忽不定，有时候简洁，有时候嗦，错误处理时有时无。但你告诉它"你是一个有10年后端经验的工程师，注重错误处理和代码可读性"，输出的质量明显更稳定。

我现在常用的角色设定大概是这样：

你是一位资深全栈开发工程师，代码风格简洁清晰，注重错误处理和边界情况。
你写的代码必须有完善的错误处理、清晰的注释，并且易于维护。

不是每次都写这么长，但遇到复杂需求的时候，花30秒设定角色，省得后面来回改。

技术栈也可以直接指定：

你是React + TypeScript前端开发者，严格使用函数式组件和Hooks，类型定义完整，不使用any。

这个真的有用。不指定技术栈的时候，AI有时候会给你写class组件，或者混用various写法。

需求描述是关键中的关键

"帮我写个登录功能"——这种提示词我见过太多了，基本上只能得到一个最简陋的demo。

打个比方，你去餐厅只说"给我上菜"，厨师给你什么全凭运气。你得说清楚：几个人吃、什么口味、有没有忌口、预算多少。写代码也是一样。

我现在描述需求的习惯是这样的：先说清楚要做什么、用什么技术栈、有哪些具体要求。比如：

帮我写一个用户登录表单，React 18 + TypeScript + Tailwind CSS。

具体要：
1. 邮箱和密码输入框，带验证（邮箱格式、密码不少于6位）
2. 记住我复选框
3. 登录按钮带loading状态
4. 输入错误时在字段下方显示提示
5. 成功后跳转首页
6. 用axios发请求

要求函数式组件 + Hooks，类型定义完整，关键逻辑写注释。

写得是挺长的，但AI给出来的东西基本一次就能用。比起来回改七八轮，到底哪个效率高？

有个小技巧：列需求的时候用数字编号，别写一大段话。AI处理结构化信息的能力强得多，编号清晰它不容易漏。

Debug的时候该怎么问

遇到bug的时候，直接把错误信息扔给AI，效果其实不怎么样。我后来总结了一个比较好用的方式：

这段代码有bug（贴代码）

错误信息是：（贴错误信息）

我已经试过：（比如检查了类型、确认了数据不为空、但问题还在）

帮我：
1. 定位问题出在哪
2. 给出修复代码
3. 解释为什么会有这个问题
4. 以后怎么避免

最关键的是告诉AI你已经试过什么。否则它给你的建议大概率就是你已经排除过的方向，来回兜圈子。

还有些bug是偶现的、复现不了的。这种情况我也会让AI帮我"列出所有可能的原因，按可能性排序"。它给出的排查方向通常比自己瞎猜高效多了。

Code Review的好用法

这几年养成了一个习惯：写完一段复杂逻辑后，会让AI先过一遍，然后再提交。不是说它能替代人工Review，但很多低级问题——比如忘记处理null、循环里有重复请求、变量命名混乱——它一眼就能看出来。

我的提示词一般这样写：

Review这段代码，从这几个方面看：
1. 有没有潜在bug
2. 有没有性能问题
3. 有没有安全隐患
4. 代码风格是否一致
5. 有什么可以优化的

每个问题给出具体修改建议。

有时候AI会指出一些我没注意到的问题，比如"你这个函数做了两件事，最好拆开"，或者"这里可能有竞态条件"。不是说它说的都对，但确实能帮你看到盲区。

学新东西的时候

遇到没学过的技术，以前是翻文档、看教程、找示例，现在多了一条路——让AI给我讲。

但关键是要说人话。你得告诉它"用最简单的话解释，别用行话"。

比如：

我想学Docker，但我完全没接触过容器化。
用最通俗的话告诉我：
- Docker到底解决了什么问题
- 核心概念有哪些
- 最常见的坑是什么
- 给我一个最简单的例子

别用专业术语，就当我是个刚学编程的新手。

用这种方式学新概念，效率比看官方文档快太多了。官方文档是给有基础的人看的，AI可以按你的水平来调整讲解深度。

生成测试代码

写单元测试这件事，说实话一直挺烦的。所以现在我都会让AI先帮我生成测试用例框架，我再根据业务逻辑补充。

用Jest为这段函数写单元测试，覆盖正常情况、边界情况和异常情况。

它生成的测试用例通常能覆盖大部分场景，我再补充几个业务特有的case就行了。比自己从头写省不少时间。

几句话的安全提醒

最后说几个安全方面的，都是实实在在踩过的坑或者听说过的：

• 公司代码不要直接粘进去。这个不用多说，很多公司明文规定，而且主流AI工具都会拿对话数据做训练。
• 密钥和密码要特别小心，不要出现在发给AI的代码里。
• AI写的加密和安全相关代码要格外仔细审查。它在这方面容易出问题，比如用了弱加密算法、忘记加盐之类的。
• 涉及权限控制、输入验证的逻辑，自己多花时间check。

写在最后

用AI写代码这件事，说到底就是你得当好它的项目经理。需求说清楚、结果要审查、问题要迭代。把它当成一个能力很强但经验有限的同事，而不是许愿机。

至于效率提升多少，每个人情况不同，我不想编什么"效率提升3倍"的数据。但说句实在话——会用AI和不会用AI的开发者，差距确实在拉大。不一定是写代码的速度，更多是解决问题的思路。

开始的好方式就是：下次写代码的时候，先花30秒把提示词写清楚，看看效果有什么不同。