用 AI 辅助写代码与排查 Bug：从需求到上线的实操流程

• 你负责的事：明确需求边界、提供真实上下文（技术栈、版本、数据结构、现有代码片段）、判断生成结果是否符合业务、对最终代码负责。
• AI 负责的事：根据上下文生成草稿、解释陌生报错、提出多种实现思路、补充边界用例。
• 绝不能外包给 AI 的判断：是否引入新依赖、是否触碰资金/权限相关逻辑、生成代码能否直接合入主干。这些必须由人拍板。

1. 写清输入输出：这个函数/接口接收什么参数、返回什么结构、异常时返回什么。
2. 贴出真实上下文：相关的表结构、已有的实体类、调用方代码片段，而不是让 AI 猜。
3. 声明技术栈和版本：语言、框架、关键库的具体版本，避免它用了已废弃的写法。
4. 列出约束：性能要求、并发场景、必须复用的现有工具方法、团队代码风格。
5. 拆成单一职责的小块：一次只让它生成一个函数或一个类，便于逐块验收。

• 弱提示：「写个导出 Excel 的接口」——结果通常是脱离你项目的通用 demo，导包、工具类全不对。
• 强提示：「基于 Java 8 + 这个 OrderVO（贴出字段）写一个导出方法，用项目里已有的 ExcelUtil.write(list, headers)，数据量可能上万条，要求流式写出避免 OOM，空列表时返回只含表头的文件。」——结果可直接对接你的代码。

角色：你是熟悉 [语言/框架 + 版本] 的资深工程师。
目标：[一句话说清要实现什么]。
上下文：
- 现有代码：[贴出相关函数/实体/表结构]
- 调用方式：[谁会调用、传什么]
约束：
- 必须复用 [现有方法/工具类]
- 处理这些边界：[空值 / 大数据量 / 并发 / 超时]
- 代码风格与上面的现有代码保持一致
输出：只给实现代码 + 关键处的简短注释，先说你的实现思路再贴代码。

1. 复现并收集证据：贴出完整报错堆栈、触发时的输入数据、期望行为与实际行为的差异。
2. 圈定范围：告诉 AI 哪些代码最近改过、问题在哪个环节出现（请求进来 / 业务计算 / 数据库 / 返回渲染）。
3. 让它先给假设而非直接改：要求「列出 3 个最可能的原因并说明各自的判断依据」，避免它一上来就乱改。
4. 逐个验证假设：按它给的排查点，自己加日志或打断点确认，锁定真正的故障层。
5. 在正确的层修复：前端行为异常就改前端，后端计算错误就改后端，别用一层去补偿另一层的问题。
6. 回归验证：原来能跑通的流程，改完后亲自再走一遍，而不是「理论上没问题」。

这段 [语言] 代码抛了下面的异常：
[完整堆栈]
触发时的输入是：[具体数据]
期望：[应该发生什么]；实际：[实际发生了什么]
最近改动：[改了哪里]
请先列出最可能的 3 个原因和各自依据，不要直接给修改后的代码，
我确认方向后再让你改。

• 真实性核对：它调用的每个函数、API、配置项是否真实存在？尤其警惕没见过的「便利方法」。
• 边界覆盖：空值、空列表、超大数据量、并发、超时这些场景它处理了吗？没有就追问。
• 安全红线：是否有硬编码密钥、SQL 拼接注入、未转义的用户输入直接渲染？
• 依赖审查：它有没有偷偷引入新的库？新依赖必须由你确认是否真要装。
• 实际运行：在本地跑一遍，跑通它给的测试或 curl，别只读代码就判定通过。
• 改动范围：让它解释这次改了哪些地方、有没有动到不该动的现有逻辑。