用ChatGPT或Codex辅助编程，关键不是一次生成多少代码，而是每一步能否说明目标、运行验证并由人验收。先把任务拆小，保留可重复的测试方法，再判断工具是否真正减少了工作量。

先写清需求与不改范围

开始前列出当前行为、期望行为、输入输出和完成条件。例如修复一个输入校验问题时，应先说明什么输入要接受、什么输入要拒绝，以及报错应如何展示，而不是只说“帮我修一下”。

同时写明不能改变的接口、权限、数据格式与兼容要求。任务涉及多个模块时，先确认依赖和调用关系，再按能独立检查的小修改推进，避免为了局部方便顺手改动无关业务。

用最小复现缩小问题

提供足以复现的脱敏代码、错误现象、操作步骤和相关环境信息。先在隔离环境确认问题能够重复出现，再请求解释原因与修改方案。不要直接上传生产密钥、客户数据、完整日志或数据库；示例账号和数据应清楚标为演示。

当信息不足时，先补充证据或承认尚未确定，不把工具推测的原因当成已证实结论。修改之前保留原始失败现象和现有测试结果，后续才有依据判断问题是否真正解决。

先列测试，再检查实现

  • 正常情况：典型输入能否得到预期结果。
  • 边界情况：空值、长度极限、重复提交与特殊字符如何处理。
  • 异常情况：依赖不可用、请求超时或权限不足时是否安全失败。
  • 回归情况：相邻功能、旧接口和已有使用方式是否仍然正常。

测试不应只跟着新实现写。先明确期望和约束，检查工具生成的断言是否真正验证用户需求，而不是把错误行为也当作正确结果。涉及状态变化时，还要观察失败后是否留下不应存在的部分修改。

小步修改与人工审查

每次只处理一个可解释的问题，查看差异是否超出任务范围。重点审查权限判断、输入处理、错误分支、敏感信息与外部请求；不要因为代码能运行，就默认业务含义和安全边界都正确。

先运行相关测试，再按风险检查周边流程。验证失败时查明原因，不删除关键断言来换取通过；未运行、未覆盖或无法确认的部分应明确记录。需要上线时，准备备份和可恢复方案，而不是直接覆盖后再判断。

用一周记录评估收益

记录任务类型、准备材料耗时、工具建议中实际采用的内容、人工修正和验证耗时，以及最终是否通过验收。把等待、返工和审查成本也算进去，不把生成速度直接等同于交付效率。

这些记录不是官方用量公式或效果保证。Plus等订阅的功能和限额可能变化，应查看官方套餐与当前账号信息；会员不等于API余额。需求明确、过程可验证、结果可审查，工具建议才适合进入实际项目。