让 AI 写出一段看起来合理的代码并不难。把它放进已有项目，处理好边界情况，并确认没有影响原来的功能，才是日常开发里更费心的部分。
这里用“为静态博客添加文章搜索”作为一个假设任务，整理一套可以反复使用的协作方式。文中的步骤是工程建议，不是对某个编程工具的性能承诺。
把一个愿望改写成可以验收的行为
“搜索体验好一点”很难直接检查。可以先把它改写成具体要求：
- 输入关键词后，在当前页面筛选文章。
- 标题、摘要和标签都参与匹配。
- 英文字母匹配时忽略大小写。
- 没有结果时，展示清楚的空状态。
- 清空搜索后，恢复当前分类下的文章。
再补上项目约束：沿用已有样式；文章内容仍由 Markdown 维护；无需接入服务端搜索。范围清楚之后，模型就少了一些自行猜测产品方向的空间。
提供定位所需的上下文
对于已有项目，可以先让模型查看构建脚本、文章列表模板和现有交互，再提出修改。不要只给一张截图，就默认它知道列表数据从哪里产生。
提供上下文时，也要区分观察到的事实和自己的推测。例如：“输入后列表没有变化”是现象；“应该是事件绑定失败”只是可能的原因。先让工具验证原因，再决定修改位置。
一个适合小任务的说明可以是：
目标：为文章列表添加即时搜索。
范围：标题、摘要、标签；同时保留分类筛选。
约束：不引入运行时依赖，沿用当前页面风格。
验收：匹配、无结果、清空、分类组合四种情况都能工作。
交付：说明修改文件、验证方法和仍存在的限制。让修改足够容易审阅
第一次修改可以只覆盖搜索所需的模板和脚本。看到明显无关的重构时，先判断它是否是完成当前行为的必要条件。
审查时重点看数据从哪里进入、在什么地方筛选、如何更新页面。对于从文章内容构造的 HTML，还要确认输入经过了适当转义；对于用户输入，尽量使用文本和数据操作，避免直接拼接进 HTML。
小范围修改的价值在于容易看清行为变化，也更容易在出现问题时撤回。
验证行为，而不是只看代码能否解析
语法检查能发现一部分错误，但不能证明搜索结果正确。可以使用一个事先知道答案的词，检查匹配数量，再测试找不到结果和清空输入的情况。
还应验证分类与搜索叠加时的行为，以及键盘和手机使用时是否方便。已有正常行为也值得顺手确认，例如文章标题仍能打开详情页，搜索没有阻断页面导航。
SWE-bench 将真实代码仓库和 issue 描述作为软件修复任务，提醒我们评估场景可以超出单段代码生成。本文借鉴的是这种贴近项目任务的视角，不使用论文中的早期成绩判断当前工具能力。SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
完成一次修改，也留下可继续工作的信息
交付说明可以很短，但要回答三个问题：现在增加了什么行为，怎样验证过，还有什么限制。
例如，若第一版只做普通子串匹配，就明确说明它没有拼音搜索和语义检索。限制写清楚后，下一次是否升级就有了讨论依据，不需要把简单搜索包装成“理解内容”。
使用 AI 编程时，开发者仍需要决定做什么、检查什么，以及什么程度算完成。把这些判断写清楚，生成出来的代码才更容易进入一个能维护的项目。