AI Coding 辅助开发：把需求变成可验收的修改
用“表格标签不换行”的小案例，说明需求边界、最小改动、验证证据与交接记录如何配合。
先把一句请求变成可观察的结果
“把表格优化一下”没有明确终点。可以改写为：类型列居中，文字不换行；状态用圆点与文字表示；不修改接口与业务判断；在深色、浅色和紧凑模式下检查。这样，人和 AI 才能对完成标准形成共同理解。
本文以界面展示任务作为教学案例，讨论协作方式，不报告未经测量的开发提效比例，也不把工具生成的结论视为验收证据。
给足上下文，也明确不能碰什么
开始前应记录当前分支、未提交改动、相关组件和共享样式。若同一个标签组件被多个模块使用，直接改全局样式可能修好一个页面，却影响其他页面。先定位问题来自列宽、布局还是通用组件，再选择修改范围。
任务说明应同时包含要达到的效果和不能改变的边界，例如不变更数据库、不新增依赖、不动认证。已有工作区改动需要单独保存，不能把前一位协作者的成果误当成自己的新增内容。
每轮只解决一个可验证的问题
一个可复用的协作顺序是：复现问题、说明原因、修改最小范围、验证结果、记录差异。如果问题没有复现，先保留截图、错误信息和输入条件，不急于写补丁。
| 阶段 | 应留下的证据 |
|---|---|
| 修改前 | 现象、页面尺寸、相关代码位置 |
| 修改中 | 文件差异、为什么采用这个修改范围 |
| 验证 | 实际命令结果、页面截图、失败项 |
| 交接 | 提交或源码包、备份、部署状态、待办 |
构建通过不等于页面正确
类型检查能发现部分接口使用错误，构建能发现打包问题，但它们不能证明文字没有折行。显示任务需要浏览器验证：检查不同模式下的尺寸、溢出、颜色和交互，必要时使用临时样例覆盖现有数据没有出现的状态。
验证样例与业务数据要隔离。只为检查红色“不通过”状态，不应去修改真实记录。保存结果时也不能只写“PASS”，应说明检查了哪些条件，哪些没有检查。
把可继续工作的线索留下来
交接至少包含目标、变更文件、验证结果、产物位置、线上是否更新和回滚方法。未完成项写清阻塞原因，例如缺少写入权限或服务器访问权限，而不是把准备好的代码描述成已经上线。
若修改发生在独立副本，应保存原始快照和补丁清单，交回时先检查原项目是否又有新改动。对 AI 生成内容的审阅也应关注真实性：示例是否标注、命令是否验证、引用是否支持结论。