01先确定是在学习、排错还是修改项目

AI 编程助手可以解释代码、提出实现思路、生成样例、分析报错和修改项目，但这些任务需要的环境不同。

理解一个函数，通常只需要相关代码和调用背景；修复一个真实故障，则还需要重现步骤、运行环境和观察到的行为。只给一句“程序坏了”，容易得到泛泛的排查清单。

如果是学习任务，可以要求用一个小例子说明概念，再让工具解释每一步的输入输出。如果是项目修改，要说清楚当前行为、期望行为和不能改变的部分。把问题写成可以观察的差异，比直接要求换框架或重写模块更容易找到适合的解决办法。

02提供足够上下文，同时保护项目资料

有用的上下文包括相关文件、依赖版本、执行命令和完整错误信息。

报错前后的代码往往比孤立的一行更重要，因为问题可能来自调用方式或数据形状。尽量提供最小可重现示例，让其他人或工具也能按相同步骤看到问题，而不是依靠猜测还原环境。

同时清理日志和配置中的密码、访问令牌、真实用户数据以及内部地址。可以保留字段结构，用明确占位值替代敏感内容。不要为了方便排错，把整个生产数据库或全部账号凭据交给模型。对于公司项目，还应确认所用工具和代码上传方式符合团队要求。

03要求小范围、可解释的变更

让 AI 先指出可能需要修改的位置，再实施与问题直接相关的调整。

一个按钮的交互问题，通常不需要顺便重写整个样式系统。变更越集中，越容易判断是否解决问题，也越容易在出现副作用时回退。使用版本控制保存当前状态，能够让审查和比较更清楚。

审查差异时，不要只看它声称修改了什么，还要实际查看新增、删除和重命名的文件。注意是否改变公共接口、默认配置、权限或数据格式。即使代码运行成功，这些变化也可能影响其他使用者。让工具解释取舍和兼容性，比只要一段完成总结更有价值。

04能运行只是验证的开始

编译成功或页面打开，只能说明部分问题没有立即暴露。

验证应对应具体变更：修复输入校验，就检查正常、空白和异常输入；修改计算逻辑，就检查边界值和单位；调整界面，就检查键盘操作和不同屏幕尺寸。没有执行检查的工具，不应把猜测写成“全部通过”。

测试也不应只重复实现方式。如果新代码把错误结果写进了测试预期，两者可能一起通过。应从用户期望的行为出发，使用能暴露原问题的案例，并确认修复前失败、修复后符合要求。已有检查通过之后，再根据真实风险决定是否补充验证，避免堆积无意义的测试。

05依赖、安全和数据处理要额外留意

AI 可能建议不存在的函数、过时的接口或相似名称的依赖。

安装新包前核对官方项目、维护情况和许可证，确认它确实解决当前问题。不要直接运行来历不明的下载脚本，也不要把自动生成的命令当成已经经过审查。命令中的删除、覆盖和远程执行尤其需要理解其作用范围。

涉及登录、权限、支付、数据库迁移或生产数据的变更，应由了解业务的人审查。检查是否扩大访问范围、泄露日志、破坏兼容或缺少恢复方案。AI 可以帮助整理风险和验证步骤，但不能替代对真实系统影响的判断。工具能够执行某项操作，并不代表这项操作适合当前阶段。

06把交付变成别人能够接手的成果

完成后要求工具说明具体问题、最终行为、修改范围、执行过的检查和仍然存在的限制。

说明应与实际代码一致，不必夸大为“完全重构”或“性能全面提升”。若功能依赖环境变量或外部服务，要把配置要求写清楚，但不要把真实密钥提交进仓库。

对于准备发布的项目，在接近真实的环境中检查关键流程，并保留可恢复的版本。上线后继续观察错误与用户反馈。AI 编程助手最有价值的用法，是缩短理解和实现的时间，同时让修改仍然可以解释、验证和回退；省掉这些步骤，往往只是把成本推迟到故障出现之后。