请按格式输出：【原始代码】→【修改后代码】→【修改理由】；修改理由须含：1. 问题类型；2. 实际风险；3. 解决方式。角色为资深测试工程师，需code review式解释，禁用模糊表述，须引用行号及jvm实际行为。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Codeium在生成测试数据时不仅输出修改后的代码，还要附带清晰的修改理由，避免AI只改不解释、无法验证逻辑是否合理。
在提示词中明确要求“修改理由”必须包含三要素
第一步：在提示词开头就写明输出格式约束，例如：“请按以下格式输出：【原始代码】→【修改后代码】→【修改理由】”。【修改理由必须包含：1. 原代码的问题类型（如边界遗漏、空值未处理、类型不匹配）；2. 该问题导致的实际风险（如测试覆盖缺失、断言失败、Mock失效）；3. 本次修改如何针对性解决（如补全null检查、增加size==0分支、显式转换BigDecimal）。
第二步：提供一个带缺陷的示例片段，并在提示词中要求AI先识别再修复。例如粘贴一段缺少空集合校验的JUnit测试，后面紧跟“请指出问题、重写测试并严格按三要素说明理由”。这能强制模型进入诊断-修复-解释的完整链路。
用角色指令锁定AI行为模式
方法一：指定角色为“资深测试工程师”，并在提示词中写：“你正在给 junior 开发者做 Code Review，每次修改都必须让人看懂‘为什么这里非改不可’。”
方法二：添加否定约束：“禁止使用‘为了健壮性’‘提升可读性’等模糊表述；若理由中出现此类短语，必须立刻重写并替换为具体执行路径或JVM行为描述。”
绑定上下文触发理由生成
在提示词末尾追加一句：“如果原始代码中已存在Assert.assertEquals但预期值写错，请在修改理由中引用该行号，并说明JVM执行到此行时实际返回值与预期值的差异（如：第17行expect=5但actual=0，因sum()在空List上返回0而非抛异常）。”
这一步会激活Codeium对上下文的深度解析能力——它只有真正计算出actual值，才能写出符合要求的理由。没有真实执行环境时，它会主动模拟推演过程，而不是泛泛而谈。
