千问代码审查需提供完整可运行代码、错误现象、审查重点、依赖说明及验证清单：一、粘贴含上下文的代码并说明环境；二、提供报错信息与最小复现输入；三、明确安全/风格等审查维度；四、声明第三方库版本与api行为；五、按功能目标与逻辑步骤结构化验证。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想让千问帮你发现代码里藏着的潜在Bug、指出可读性差的写法、给出符合工程规范的改进建议，而不是只告诉你“语法没错”。这需要你主动提供足够上下文，否则千问只能基于片段做模糊猜测，容易漏掉关键风险。
第一步：粘贴完整可运行的代码片段
把你要审查的函数、类或模块整段复制过来，不能只截取其中几行。比如审查一个Python的用户登录校验函数，必须包含def login_check(...)、所有参数声明、内部if/else分支、异常处理、return语句，以及顶部的关键注释（如“该函数需兼容LDAP和本地DB双模式”）。
如果逻辑分散在多个文件，按调用链顺序提供：先贴主入口（如app.py中的路由函数），再贴它调用的核心服务类（如auth_service.py），最后贴被依赖的数据模型（如User.py）。【缺失任一环节，千问无法判断参数是否被污染、状态是否被意外修改】
在代码最前面加一行说明：语言+版本+关键约束。例如：“Python 3.11，运行环境禁用网络请求，函数必须在200ms内返回”。
第二步：明确标注已知问题现象
方法一：提供完整报错日志
直接粘贴终端里跑出来的原始错误，从第一行Exception类型开始，到最后一行Traceback结束。不要手动删减路径或省略中间帧——千问靠堆栈层级定位是哪一层抛出的空指针。
方法二：给最小复现输入
写清楚“调用func([1, None, 3])时返回了负数，但文档要求必须返回索引值≥0”。比笼统说“结果不对”有用十倍。
方法三：描述非崩溃型异常
比如“并发调用50次后，第37次返回的session_id与前一次重复”，这种状态泄露问题必须靠具体行为描述才能触发千问对共享变量的检查。
第三步：指定你要优先关注的风险维度
第一步：列出三项最高优审查方向
例如：“1. SQL注入风险（所有拼接字符串的query）；2. 浮点数精度丢失（涉及金额计算的除法）；3. 未释放的Redis连接（search.py中所有redis_client实例）”。
第二步：补充合规依据（如有）
安全项目必须写明标准条款，例如：“需满足OWASP ASVS 4.0.3第7.1.2条：所有数据库查询必须使用预编译参数化语句”。
第三步：指出对比范式（可选）
如果你团队强制执行Google Java Style Guide，就写明：“检查是否违反该指南第3.3节‘常量命名必须全大写加下划线’”。
第四步：声明第三方依赖行为
千问不会运行你的代码，也不会猜requests.get()内部怎么实现。你必须写清所用库的精确版本和关键契约。例如：“requests==2.28.2，超时默认为30秒且不重试；pandas>=1.21.0，DataFrame.fillna()对NaN填充为0而非None”。【版本号写错会导致千问基于错误API签名做分析，结论完全失效】
若调用了自研SDK，用一句话说明其副作用，例如：“mylogger.log()会同步写入磁盘并阻塞主线程”。
