当遇到错误排查时，AI常常给出“可能是网络问题”“建议检查密钥”或“模型加载失败”等模糊猜测，无法精准定位到真正的错误根源——这并非AI能力不足，而是提示词缺乏明确的约束与结构化指引。

要让AI精准锁定Bug，应避免使用“帮我看看哪里错了”这类开放式提问，而应将提示词设计成一张详细的故障信息登记表。以下六项核心要素，一个都不能少。

运用Bug现象三要素界定问题边界

第一步：在提示词起始位置添加固定标题【Bug现象】，然后按顺序分行列出三项——输入、预期结果、实际表现。缺少任何一项，AI都会开始胡乱猜测。

第二步：将终端或日志中的原始报错信息完整粘贴，保留原有换行、缩进和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会默认忽略条件逻辑——这一点已在工程实践中多次验证。

为代码添加上下文锚点，避免AI自由发挥

方法一：在粘贴代码前添加一行注释，格式为：/// CONTEXT_START: 模块名 v版本号。例如/// CONTEXT_START: 用户会话校验模块 v3.2。这能告知AI代码的归属与版本，避免它使用旧逻辑分析新问题。

方法二：在疑似出错函数的第一行下方插入作用域声明，明确其依赖关系。例如/// FUNCTION_SCOPE: validate_session() 依赖 get_user_profile() 与 check_expiry()，不调用 db.rollback()。这能有效抑制AI擅自添加无关函数调用的冲动。

方法三：对关键变量，在其声明行后添加跟踪标记。例如session_id = request.headers.get('X-Session-ID') → /// TRACK_VAR: session_id (string, 长度≥16，含字母+数字)。有了此约束，AI在分析变量来源时就不会凭空假设其可能为空或格式错误。

嵌入断言指令，强制AI验证后再修改

① 在提示词中插入ASSERT行，格式为：ASSERT: line [行号] 必须返回非空字典，键包含 'status' 和 'data'。这相当于给AI下达了一项硬性检查指令——不满足条件则停止后续操作。

② 对于循环体内部状态，添加ASSERT_INSIDE_LOOP行，例如ASSERT_INSIDE_LOOP: 每次迭代后 retry_count 值必须比上一次+1，且不超过5。这能防止AI在循环逻辑中写出无限重试或永不推进的Bug。

③ 如果涉及异步或时序逻辑，声明ASSERT_ORDER，例如ASSERT_ORDER: load_config() 完成后才能执行 init_cache()，二者不可并行。明确时序依赖，AI才不会乱调函数顺序。

这一步操作很简单，直接按需将三类断言复制进提示词即可。但注意：每条ASSERT必须对应真实存在的代码行号，写错会导致AI跳过验证——我在实际测试中发现，行号偏差超过3行时，AI常常直接忽略该断言。

限定修复范围，避免过度重构

在提示词末尾单独起一行，写明RESTRICT约束。例如：RESTRICT: 仅允许修改line 44–48，禁止新增函数、禁止修改参数列表、禁止引入新import。这能有效防止AI大刀阔斧重写整个模块，从而避免引入新问题。

如果涉及权限、加密或数据库操作，再追加SECURITY_LOCK行。例如：SECURITY_LOCK: 不得移除任何 jwt.decode() 的 verify_signature 参数，不得删除 try/except 包裹。安全相关的约束写清楚，AI才不会为了“简化代码”而顺手删除校验逻辑。

这一步不能省略。没有范围锁的提示词，AI大概率会重写整个函数——届时你将需要花费更多时间排查它新引入的Bug。