先看两句话,让 AI 做同一件事:
「给用户加一个改密码的功能。」
和:
「给用户加改密码功能。要校验原密码;新密码走我们已有的弱密码拦截(
lib/password-policy);微信登录的用户没有原密码,原密码框要允许留空;改完让其它设备的登录失效。」
第一句,AI 会给你一个「教科书版」的改密码——很可能校验原密码,于是微信用户全被挡在门外,因为他们压根没有原密码。第二句,它一次就能给到你要的东西。差别不在 AI 聪不聪明,在于你有没有把藏在脑子里的约束说出来。
下面是我实际在用的几条,从最管用的开始。
一、先说清楚「做完了长什么样」
这是最重要的一条,却最常被跳过。大多数人上来就描述「怎么做」,却没说「怎么算做对了」。而 AI 最需要的恰恰是后者——它是它自我检查的靶子。
所以在描述功能之前,先花一句话说清成功的样子:「成功 = 微信用户能在原密码留空的情况下设置新密码,且弱密码会被拦下。」有了这句,AI 不但知道要做什么,还知道该拿什么去验证自己做得对不对。
二、把边界情况当成需求的一部分,而不是补丁
「正常流程」谁都会写,真正决定成败的是边界。与其等 AI 交货后再一个个发现漏洞,不如一开始就把你能想到的边界摆上桌:
- 空的 / 缺失的输入,该报错还是当默认值?
- 没有权限的人来了,怎么办?
- 同一件事被点两次(并发 / 重复提交),会不会出问题?
- 依赖的外部服务挂了,该降级还是直接失败?
你不用全想到——想不到的那部分正是后面「自己核」要兜的。但凡是你已经知道的坑,一定要说;AI 没在你的项目里踩过它们。
三、给它锚点:指向已有的代码,而不是凭空描述
这条能立竿见影地提升质量。与其描述「用我们的风格写个表格」,不如说「照 ReferralDetail.tsx 里那个表格的写法来」。与其说「加个加密」,不如说「用 lib/pay-crypto 里现成的那套」。
原因很简单:凭空生成,AI 会造出一套和你项目格格不入的新东西;给了锚点,它就顺着你已有的约定往下写。一个健康的代码库里,新代码应该读起来像老代码——锚点就是保证这件事的最省力办法。
四、一次只推进一件事
把「重构支付模块、顺便加 Stripe、再修一下那个显示 bug」塞进一句话,是自找麻烦。三件事绞在一起,一旦哪里不对,你很难判断是哪一步引入的,AI 自己也容易顾此失彼。
拆开。先把 Stripe 加好、验过、确认没问题,再动下一件。慢一点的错觉,换来的是每一步都可控、可回滚。合起来反而更快。
五、让它先说计划,你再放行
遇到稍微大一点的改动,先别让它直接动手。让它先讲一遍准备怎么做:改哪些文件、分几步、担心哪里。这一步几乎不花时间,收益却极大——很多误解在计划阶段就暴露了,而在这时纠正,比等它把三十个文件都改完再推翻,便宜太多。
「先别写,告诉我你打算怎么改、会动哪些地方。」——这句话我几乎每天都在说。
六、把「不确定就问」写进指令
AI 有个危险的默认倾向:它宁可猜一个,也不愿意停下来问你。而猜错的代价,往往要到很后面才显现。所以我会明确告诉它:拿不准的地方,别自己定,先问我。一句话,就能把很多「它自作主张选了错的那条路」挡在前面。
放到一起
把上面几条串起来,一个好的需求大概长这样:
目标：微信用户也能改密码。
成功的样子：原密码留空也能设新密码，弱密码被拦。
约束：
- 校验原密码，但微信用户没有原密码，要允许留空
- 新密码走 lib/password-policy 的拦截
- 改完让其它设备登录失效
边界：连点两次不能出问题
参考：表单照 AccountCenter.tsx 里现有的弹窗写
先告诉我你打算改哪些文件，拿不准的地方先问我。看起来比「加个改密码功能」啰嗦得多。但你多花的这两分钟,换回来的是 AI 一次就做对、而不是来回返工五次。这笔账,怎么算都划算。
写好了规格,只是成功了一半。另一半是——它交货之后,你怎么知道能不能信?那是下一篇的事。