让 AI 帮你写前端，先把验证流程搭好

让 AI 生成一个组件并不难，难的是确认它适合当前项目，而且没有悄悄改变已有行为。把它放进日常开发流程，最有价值的起点是一个范围明确、能够验证的小任务。

先给上下文，再给任务

“帮我做个搜索框”留下了太多空白。说明框架、数据结构、现有组件、样式约定和交互要求，结果才有判断依据。提供相关文件即可，不必把整个仓库、客户资料或生产日志全部粘贴进去。

一个任务描述可以这样写：

项目：Vue 3，使用 TypeScript。
目标：给现有文章列表添加标题搜索。
数据：articles 为只读数组，字段是 id 和 title。
约束：沿用已有输入框，不增加依赖。
行为：忽略首尾空格；空搜索显示全部；无匹配显示提示。
验证：中文、空白、没有结果、清空输入四种情况。

不要提交密钥、会话令牌和真实个人信息。日志先脱敏，配置文件只保留变量名和示例值；如果密钥已经泄漏，应立即撤销并更换，删除聊天记录不足以解决问题。

把改动拆成可以审查的小块

先完成过滤逻辑，再接界面，最后处理空状态和键盘体验。每一步都应能独立说明“输入是什么，输出是什么”。让 AI 同时重构目录、换组件库并增加功能，会让错误来源更难追踪。

当它提出新依赖时，检查这个依赖解决了什么问题、许可证是否合适、现有能力是否已经足够。不要因为生成的代码引用了某个包，就直接安装名字相近的陌生依赖。

读 diff，比读解释更可靠

先检查改动范围，再沿着数据流阅读。特别关注新增加的网络请求、浏览器存储、权限变化、错误处理，以及删除的校验。解释写得完整，不代表实现符合要求。

git diff --stat
git diff -- src
npm run build

构建通过只证明这一轮构建成功。项目有类型检查、测试和 lint 脚本时，按项目约定执行；如果没有这些脚本，不要把没有运行过的检查写成“全部通过”。

用真实操作验证承诺

打开页面，实际输入中文、清空内容、触发没有结果，再用 Tab 和 Enter 操作。涉及请求时，模拟慢网、失败和连续点击，观察旧请求是否会覆盖新结果。涉及布局时，检查手机宽度和长标题。

验证最好围绕用户行为，而不是重复实现细节。例如“搜索不存在的标题会显示空状态”，比“过滤函数调用了 includes”更能保护需求。

给下一次修改留下证据

提交前记录改动目的、实际执行的检查和仍未覆盖的情况。若结果偏离预期，保留错误现象和最小复现，再让 AI 修正具体问题。最终合并代码的人仍需要理解关键路径；遇到解释不清楚的实现，先缩小范围，直到能够说明它为什么成立。