把 AI 生成的代码变成可以维护的代码

AI 可以快速给出一段实现，但项目需要承受这段实现之后发生的事情：需求会变化，网络会失败，旧数据还在，别人也要继续维护。

因此，协作的重点不只在于生成速度，还在于能否把结果变成一份边界清楚、可以验证的改动。

从一个能检查的目标开始

“把后台做好”很难结束。“保存文章时保留继续输入的内容，旧响应不能覆盖新输入”则有明确的触发条件与结果。

目标越具体，越容易判断实现是否触及问题。必要时可以同时写出已有约束：使用当前技术栈，沿用鉴权，保留未提交修改，不引入额外平台。

这些约束需要先进入实现过程，而不是代码生成后再逐条补救。

提供上下文，也限定范围

让 AI 阅读接口类型、相关状态和已有测试，通常比只贴一条错误消息更容易得到贴合项目的修改。但上下文并不是越多越好，尤其不应包含口令、持久凭据或与问题无关的私有资料。

同时说明允许修改哪些模块。一个局部输入问题，不应该顺带换掉导航、重写所有表单，或引入另一套请求封装。改动范围小一些，原因和结果也更容易对应。

检查真实的工作流

类型检查和构建能发现一类问题，却不能证明用户操作已经可用。保存流程还要实际观察保存中继续输入、响应丢失、刷新恢复和冲突处理。

测试应保护行为，而不是照着实现把每一个分支复述一遍。出现失败后，先确认失败是否来自真实约束，再决定修改实现还是修正测试条件。

截图、请求结果和关键文件摘要，可以让“已经完成”变成别人能够核对的事实。它们不必很多，但应当对应最重要的风险。

审阅那些看起来很顺的细节

生成的代码可能在正常路径上很完整，却忽略离开页面时的取消、重复请求或旧状态。审阅时可以沿着时间顺序问：这次操作发出后，用户还能做什么？晚到的响应会写到哪里？失败后下一次尝试使用哪份输入？

如果解释不清楚，就继续缩小改动，先把这个边界处理好。

让交付有一个结束点

一个功能完成后，记录行为变化、验证结果和仍存在的限制，再提交可以独立理解的代码。没有新失败或新需求时，不必用反复全量测试和细枝末节的调整代替交付。

AI 协作最终留下的应当是项目能够接住的成果：维护者知道它解决了什么，能够复现检查，也知道下一次修改从哪里开始。