要用腾讯混元精准定位测试失败问题并生成可运行修复代码，需提供完整错误堆栈、测试输入/输出及源码片段，采用三段式提示词明确角色、事实与动作，并调用function call模式限定JSON输出格式，最后验证修复代码是否通过原测试。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你拿到一段测试失败的报错日志，想让腾讯混元直接帮你定位问题并生成可运行的修复代码，而不是泛泛而谈“检查空指针”或“确认参数类型”，就得用对调用方式和提示词结构。
准备测试失败信息与上下文
把完整的错误堆栈、测试用例输入、预期输出、以及出问题的源码片段（最多200行）整理成纯文本。不要截图、不要折叠、不要省略异常类名和行号——【缺少Traceback最后一行的具体异常类型和文件行号，混元可能误判为逻辑错误而非语法/运行时错误】。
例如：AssertionError: assert get_user_by_id(1) == {'id': 1, 'name': 'Alice'} → 实际返回None；对应代码在user_service.py第42行：return db.query(User).filter(User.id == user_id).first()。
构造精准提问指令
在混元Web界面或API请求中，用三段式结构输入：
① 角色定义：“你是一名有5年Python后端经验的工程师，专注Django/SQLAlchemy项目，擅长从pytest失败日志逆向修复代码。”
② 输入事实：“以下是一次测试失败详情：[粘贴完整报错+源码片段]”
③ 明确动作：“请只做三件事：1. 指出根本原因（精确到哪一行、为什么出错）；2. 给出修改后的完整函数代码（保持原有缩进和注释风格）；3. 补充一行修复验证说明（如‘现在get_user_by_id(1)将返回User对象而非None’）。”
这一步不能写成“帮我看看哪里错了”，必须限定输出格式和深度。混元对模糊指令响应质量波动极大。
调用API时强制启用function call模式
方法一：使用hunyuan-functioncall模型（非hunyuan-pro）
在SDK请求中显式设置Model="hunyuan-functioncall"，并传入tools参数定义code_fixer工具：
{"type": "function", "function": {"name": "code_fixer", "description": "修复给定代码片段中的缺陷，输出修正后完整代码及原因", "parameters": {"type": "object", "properties": {"error_log": {"type": "string"}, "source_code": {"type": "string"}, "file_path": {"type": "string"}}}}}
方法二：若仅用hunyuan-pro，需在messages中补强约束：“你只能输出JSON格式，字段为reason、fixed_code、verification_note，不加任何解释性文字。”
【未指定输出结构时，混元大概率插入口语化说明，导致无法直接注入CI流程】。
验证修复结果是否可直接运行
第一步：把混元返回的fixed_code复制进原文件，替换对应函数体。
第二步：在终端执行同一测试命令（如pytest tests/test_user.py::test_get_user_by_id -s），观察是否通过。
第三步：若仍失败，检查混元是否遗漏了依赖变更——比如它修复了SQL查询，但没提示你要在models.py里补上User.__repr__方法来满足断言中的字典键匹配。
这一步操作起来很简单，直接把文件拖进去就行。但要注意：混元不会自动处理测试环境setup/teardown逻辑，如果错误源于数据库事务未回滚，它给的代码一定无法通过，此时需人工补上@patch或@pytest.fixture(scope="function")。
