应采用结构化提示词规范：①用【Bug现象】标题明确输入、预期、实际表现；②粘贴原始报错日志；③提供最小复现步骤；④添加代码上下文锚点；⑤嵌入行号精准的ASSERT断言；⑥用RESTRICT和SECURITY_LOCK限定修改范围。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
deepseek排查报错时反复输出“可能是网络问题”“建议检查密钥”“也可能是模型加载失败”这类模糊猜测，根本无法定位真实错误源，说明提示词缺乏强制约束与结构化锚点。用Bug现象三要素锁定问题边界
第一步：在提示词最开头插入固定标题【Bug现象】，严格按以下顺序分行写清三项内容——输入、预期、实际表现，缺一不可。
第二步：把终端或日志里原始报错信息整段粘贴，保留所有换行、缩进和Traceback行号，不要改写、不要翻译、不要删减。例如：File "main.py", line 89, in run_task → raise ValueError(f"Invalid token: {token}") → ValueError: Invalid token: None。
第三步：若错误有触发条件，必须写最小复现步骤，比如“仅当用户上传CSV且勾选‘自动清洗’时触发”“调用/api/v2/submit后第3次重试必现”。【不写复现路径的Bug描述，AI默认忽略条件逻辑】
给代码加上下文锚点，禁止自由发挥
方法一：在粘贴代码前加注释行，格式为:/// CONTEXT_START: 模块名 v版本号。例如:/// CONTEXT_START: 用户会话校验模块 v3.2。
方法二：在疑似出错函数第一行下方插入作用域声明，明确依赖关系。例如:/// FUNCTION_SCOPE: validate_session() 依赖 get_user_profile() 与 check_expiry()，不调用 db.rollback()。
方法三：对关键变量，在其声明行后追加跟踪标记。例如：session_id = request.headers.get('X-Session-ID') → /// TRACK_VAR: session_id (string, 长度≥16，含字母+数字)。
嵌入断言指令，让AI必须验证再修改
① 在提示词中插入 ASSERT 行，格式为：ASSERT: line [行号] 必须返回非空字典，键包含 'status' 和 'data'。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
② 对循环体内部状态，添加 ASSERT_INSIDE_LOOP 行，例如：ASSERT_INSIDE_LOOP: 每次迭代后 retry_count 值必须比上一次+1，且不超过5。
③ 若涉及异步或时序逻辑，声明 ASSERT_ORDER，例如：ASSERT_ORDER: load_config() 完成后才能执行 init_cache()，二者不可并行。
这一步操作起来很简单，直接把三类断言按需复制进提示词即可。但注意：【每条ASSERT必须对应真实存在的代码行号，写错会导致AI跳过验证】
限定修复范围，禁止过度重构
在提示词末尾单独起一行，写明 RESTRICT 约束。例如：RESTRICT: 仅允许修改line 44–48，禁止新增函数、禁止修改参数列表、禁止引入新import。
若涉及权限、加密或数据库操作，追加 SECURITY_LOCK 行。例如：SECURITY_LOCK: 不得移除任何 jwt.decode() 的 verify_signature 参数，不得删除 try/except 包裹。
这一步不能省略。没有范围锁的提示词，AI大概率重写整个函数，反而引入新Bug。
