大模型题解生成产品和研发怎样约定验收1. 先区分工程失败与模型输出问题“上线了自动生成 Golang 算法题解的功能后测试反馈多项问题例如模型生成的代码缺少package main或者注释中包含无效信息。”产品经理在项目例会上提出质疑“发布前是否进行了充分校验这类质量问题如何交付给终端用户”负责 Agent 服务的研发工程师解释“大模型本身的输出存在随机性。即便在 Prompt 中明确要求输出标准 Go 语法模型偶发产生的生成偏差依然可能导致编译失败。若缺少自动化的拦截闸门难以单靠模型自身的约束保证确定性。”在 LLM 代码生成与自动验证系统中产品需要可解释的交付状态研发需要可验证的失败分类。两者应在接口和验收标准中明确而不是在个案发生后争论归属。要消除这类分歧关键在于利用工程手段明确 API 契约建立量化的 SLA服务等级协议与 Bad Case 自动化归因机制。2. 产研协作四大痛点与责任解耦在 LLM 代码自动生成系统中产品与研发必须明确以下四个核心边界1. 确定性软件 vs 非确定性模型的责任划分研发的责任保证失败被安全处理网络、解析、Schema 和沙箱错误不能让服务崩溃。至于某次格式错误由供应商、提示词或解析器引起需要按证据归因不能预设为单一团队责任。产品的责任根据校验状态设计降级与提示例如明确说明代码是否已通过当前测试集以及未覆盖的限制。2. Bad Case坏例的量化分级与归因不要将所有生成失败归咎于模型能力缺陷。可以把 Bad Case 自动化分为三级L1 级工程破坏JSON 截断、超时未响应、HTTP 500。责任人研发工程师。L2 级格式违约代码缺少必需的方法签名、带多余 Markdown 语法。责任人Prompt / 研发校验层。L3 级算法正确性代码能编译通过但在极端测试用例下 TLE 或 WA。责任人模型能力/产品策略。3. API 契约中必须明确“校验元数据Validation Metadata”API 返回报文绝对不能只有一个简单的code_string字符串。必须在协议层明确返回validation_status、passed_testcases_ratio和repair_attempts等元数据让前端和产品能够根据元数据展示不同的标签。3. 产研对齐的 OpenAPI 契约设计为了将上述责任边界落到实处产研双方共同签下的 API 接口契约必须是强类型的openapi: 3.0.3 info: title: 代码题解自动生成与验证服务 API version: 1.0.0 paths: /v1/solutions/generate-and-validate: post: summary: 生成算法题解并进行沙箱确定性校验 requestBody: required: true content: application/json: schema: type: object required: [problem_id, target_language] properties: problem_id: type: integer example: 1 target_language: type: string enum: [golang, python, java] max_auto_repairs: type: integer default: 2 description: 研发确定性工程层允许的自动修复次数 responses: 200: description: 生成并校验成功 content: application/json: schema: type: object required: [solution_code, validation_metadata] properties: solution_code: type: string description: 经过确定性校验的标准代码 complexity_analysis: type: object properties: time_complexity: { type: string } space_complexity: { type: string } validation_metadata: type: object required: [is_sandbox_passed, pass_ratio, attribution] properties: is_sandbox_passed: type: boolean description: 是否 100% 通过判题沙箱 pass_ratio: type: number format: float example: 0.85 description: 测试用例通过比例 repair_attempts_used: type: integer example: 1 attribution: type: string enum: [SUCCESS, RD_FORMAT_REPAIRED, MODEL_LOGIC_DEFECT] description: 结果归因标记用于产研数据复盘4. 研发端的确定性 Validation 拦截网关实现研发团队需要在服务端实现网关层代理自动完成“格式修复 沙箱校验 归因打标”全流程确保交付给产品和前端的每一个数据报文都符合上述契约。import json import time from typing import Dict, Any, Tuple from dataclasses import dataclass, asdict dataclass class ValidationMetadata: is_sandbox_passed: bool pass_ratio: float repair_attempts_used: int attribution: str # SUCCESS, RD_FORMAT_REPAIRED, MODEL_LOGIC_DEFECT class LLMSolutionEngine: def __init__(self, sandbox_client): self.sandbox sandbox_client def generate_and_validate(self, problem_id: int, lang: str, max_repairs: int 2) - Dict[str, Any]: repair_attempts 0 code parsed_json: Dict[str, Any] {} pass_ratio 0.0 prompt f针对 LeetCode #{problem_id} 生成 {lang} 高效解法使用标准的 JSON 输出。 while repair_attempts max_repairs: raw_llm_response self._call_llm(prompt) parsed_json, parse_err self._safe_parse_json(raw_llm_response) # 1. 研发工程硬伤拦截: JSON 语法错误 if parse_err: repair_attempts 1 prompt f\n[系统提示: 上次输出非合法 JSON: {parse_err}请严格修复格式。] continue code parsed_json.get(code, ) # 2. 研发工程硬伤拦截: 缺代码或语法破坏 if not code or len(code) 10: repair_attempts 1 prompt \n[系统提示: 生成的代码片段为空请补充完整代码。] continue # 3. 提交沙箱做确定性编译与用例校验 sandbox_res self.sandbox.run_judge(problem_id, lang, code) is_passed sandbox_res[status] Accepted pass_ratio sandbox_res.get(passed_cases_ratio, 0.0) # 如果 100% 过题直接标记成功返回 if is_passed: meta ValidationMetadata( is_sandbox_passedTrue, pass_ratio1.0, repair_attempts_usedrepair_attempts, attributionSUCCESS if repair_attempts 0 else RD_FORMAT_REPAIRED ) return { solution_code: code, complexity_analysis: parsed_json.get(complexity, {}), validation_metadata: asdict(meta) } # 如果没完全过题但在允许重试次数内尝试让 LLM 修复算法逻辑 repair_attempts 1 # 只反馈受控的错误类别与截断后的信息避免把测试数据或日志原样塞回 Prompt。 error_type sandbox_res.get(error_type, judge_failed) prompt f\n[沙箱反馈: 类型{error_type}请检查实现并修正逻辑。] # 超过最大重试次数触发产品级降级返回 meta ValidationMetadata( is_sandbox_passedFalse, pass_ratiopass_ratio, repair_attempts_usedmax_repairs, attributionMODEL_LOGIC_DEFECT ) return { solution_code: code, complexity_analysis: parsed_json.get(complexity, {}), validation_metadata: asdict(meta) } def _call_llm(self, prompt: str) - str: # 模拟 LLM 调用 return {code: func twoSum(nums []int, target int) []int { return nil }, complexity: {time_complexity: O(N)}} def _safe_parse_json(self, text: str) - Tuple[Dict, str]: try: return json.loads(text), except Exception as e: return {}, str(e)5. 把协作约定落到日常流程API 契约和验证链路明确后产品与研发可以按以下流程协作每周举行 Bad Case 归因复盘会用数据代替情绪查看周报里的归因比例。如果RD_FORMAT_REPAIRED研发格式修复占比高研发去优化 Prompt 模板和拦截校验如果MODEL_LOGIC_DEFECT模型逻辑缺陷占比高产品评估是否需要更换更强大的基座模型或调整 UI 预期提示。设立明确的上线 SLA 门禁例如规定“生成代码的一次性沙箱通过率必须 $\ge 70%$工程格式解析成功率必须 $\ge 99.5%$”。达不到 SLA 门禁项目坚决不上线。把用户反馈作为闭环训练集当在线用户对生成的题解点击了“代码报错”或“逻辑错误”时系统自动将当前 Prompt、代码及沙箱报错打包入库作为研发下一次优化 Prompt 或做 Few-Shot 示范集In-Context Learning的真实素材。确定性工程不能让模型变得确定但能把失败限制在可观测、可回退的边界内。先把接口状态、保留期限和人工介入路径写清楚再讨论提升模型能力。