让 AI 编程更可靠：把任务写成可验证的步骤

AI 编程助手可以快速产出实现，但速度并不等于可靠性。更稳定的协作方式，是把任务变成一个可以检查结果的小循环。

先定义结果，再描述做法

把「帮我加一个搜索功能」改写成具体的使用场景：

访客可以通过标题、标签和正文关键词搜索已发布文章。输入为空时显示初始状态，没有结果时显示空状态。草稿和未来文章不得出现在索引中。

这些条件能帮助实现者理解什么叫完成，也能帮助你判断代码是否偏离目标。

如果你已经有技术约束，一并写清楚。例如「项目使用 Astro 静态输出，搜索在浏览器完成，不引入数据库」。

提供足够但相关的上下文

上下文包括现有目录、组件约定、数据结构和运行方式。优先让助手阅读相关文件，避免在没有了解项目的情况下复制一套全新架构。

有价值的信息通常是：现有代码入口在哪里、哪些行为已经正常、最近出现了什么错误、你期望保留哪些交互。

不要把凭据、真实用户记录或无关的公司资料放进提示词。提供经过处理的小型复现数据通常更方便排查。

每次只推进一个可核对的目标

一个搜索功能可以分成这些步骤：

1. 从已发布文章生成统一索引。
2. 实现查询与结果排序。
3. 接入输入框、结果列表和状态反馈。
4. 检查鼠标、键盘和移动端操作。

步骤不需要都拆成独立会话，但应该能够被分别理解和验证。一次同时改搜索、配色、路由和部署流程，会让问题来源更难判断。

把验收条件写成行为

一个好的验收条件描述外部结果，而不是重复代码内部的写法。

测试范围与风险相匹配。修改共享数据逻辑需要更完整的验证，修改一处间距则不必搭建庞大的测试工程。

阅读改动，再决定接受

即使自动检查通过，也要看一次差异。重点关注新依赖、删除的逻辑、网络请求、配置与权限变化。

git diff --stat
git diff
npm run check
npm run build

遇到错误时，保留完整错误信息和最小复现步骤。描述「在哪个页面做了什么，预期是什么，实际发生什么」，比单纯说「不好用」更能缩短排查路径。

留下一份下一次能用的记录

完成任务后，用几句话记录实际修改、验证结果和已知限制。它可以是一条提交说明，也可以是 Pull Request 描述。

AI 帮你减少输入代码的时间，你仍然需要理解问题边界、确认结果，并决定哪些变化值得进入项目。