Dikaya Pro 2 代码审查：用失败测试验证每一条修改

最小 API 示例

此 Python 代码仅作说明，并非真实模型回答。密钥从环境变量读取，自动重试已关闭。断线可能让结果和费用都无法确认，不应盲目重试。

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro-2",
    max_tokens=512,
    messages=[{"role": "user", "content": "为我的任务列出检查清单。将原始事实与假设分开。"}],
)
print(response.choices[0].message.content)

明确 Pro 2 的名称与接入边界

Pro 2 的基础说明可以写成基于 GLM-5.3 的修改版本，但这一说明只适用于该条目。另一个公开标识 seller-glm-5-3 有独立的配置与接入条件，切换二者不能只改显示名称。Flash 和 Pro 的基础来源也不能从 Pro 2 的说明中推导出来，比较时应保存完整公开标识。

把代码审查作为这里的工作场景，并不证明它在所有编程任务中优于其他模型。可以先准备一份小型已知缺陷样本，按同一份契约检查是否提出可复现问题，但结果只适用于该样本。不要据此宣传不存在的排行榜、通过率或必然生成正确代码的能力。

给配置读取器写一份短契约

设想项目从文本读取超时时间：缺少字段时使用默认值，明确写零表示关闭，负数拒绝，无法解析的值返回指定错误。若不先写清这些规则，模型可能把零当作缺失，或建议所有异常都回退默认值。看似更稳健的修改实际上改变了调用方依赖的行为。

交付材料应包含函数、调用位置、运行时版本和当前测试，不必粘贴整个项目。把与任务无关的密钥和真实环境配置移除。若通过付费浏览器上传代码，仍需遵守文本附件限制；显示代码、复制代码或下载代码不是执行代码，聊天不会因展示一个测试块就提供真实测试结果。

每条指摘必须有一个修补前失败的测试

要求先输出最小输入、契约要求、现有行为和预期异常，再给测试。对于超时字段，缺省、空字符串、零、负值和非数字分别成例，不能只检查一个正常值。测试的期望值应来自契约，而不是再次调用待测函数计算，否则实现和测试可能共享同一种错误。

实际在本地执行修补前测试，保存失败位置与输出。若测试根本无法导入依赖，这是环境或样例问题，不能算作成功复现业务缺陷。模型说预计会失败只能标为预测；没有复现的指摘可作为待讨论建议保留，不要为了显得审查有价值而强行修正。

把最小修补与额外重构拆开

确认缺陷后，只改变造成契约违背的分支。例如修复零被默认值覆盖的问题，不同时重命名配置项、替换解析库或修改异常类型。要求模型解释每一处差分解决哪个失败用例，并列出尚未处理的问题。修补范围可追溯，才方便之后定位是否引入了新行为。

新测试通过后，还要运行项目原有测试和相关调用方检查。可以让模型帮助阅读实际失败日志，但日志中的私人路径与凭证先去除。保存真实命令、退出状态和结果，而不是一段它代写的通过报告；若没有执行完整检查，结论就限定在确实运行的范围。

演示与付费预算不是同一套条件

Pro 2 有独立演示策略，既有账户保存原有额度快照，不能用文章给所有账户许诺重新领取或恢复次数。演示还有自己的输入和输出限制，不能从付费目录推断其工具、图片或其他模型权限。发送之前看账户实际状态，优先用最小文本样本验证工作方法。

演示中的 reasoning_effort=none 不等于保证没有任何推理 token，也不保证最终文本必然非空。不要把其他五个模型的 low、high、max 选项套给 Pro 2。付费输出预算同样需要明确约束；声明上下文与浏览器历史、消息体以及生成上限分别核对，不能混作一个容量。

把审查记录与请求状态一起保留

API 代码采用官方 SDK 时，应按其文档关闭自动重试并设置明确输出上限。重试一次不是无成本的阅读动作，尤其不能在未确认上次结果时自动再做同一份付费审查。记录当前公开模型、契约版本、测试日志和已知响应，模型修改建议与实际采纳差分也要分开。

收到明确 HTTP 拒绝时按已知状态处理；网络中断、读取终止或丢失确认则可能留下未知结果，不能宣称未保存或未发生费用。MDN 的 Fetch 文档解释协议层的区别，不替服务作退款承诺。聊天交接只准备草稿，已有草稿可能优先，发送前检查选择器与账户允许范围。

常见问题

Pro 2 和 seller-glm-5-3 可以直接当作同一个模型吗？

不可以。Pro 2 允许说明为基于 GLM-5.3 的修改版本，但 seller-pro-2 与 seller-glm-5-3 是独立公开标识，配置、权限与使用条件应分别核对。代码结果也不能因为基础名称相近就认定完全相同，更不能把一个条目的测试记录当成另一个的验证。

模型说测试通过，代码是否就可以合并？

应先取得自己环境中的真实执行证据。要求修补前失败、修补后通过，并运行相关既有测试，记录命令和退出状态。模型生成的代码块或一句测试通过只是文本，不能证明依赖版本、调用路径和兼容性已经检查，也不替代代码负责人的审阅。

为什么演示输出限制不能直接当作普通 API 默认值？

演示有独立策略和账户快照，付费请求还有自己的输出默认、显式上限与预算约束。二者不能互相替换，也不应因为文章介绍 Pro 2 就认为所有工具或模型都开放。先查当前账户与文档，并为自己的请求明确设置输出范围，避免把不同限制混在一起。

审查过程中想看最新库文档，API 会自动搜索吗？

不会因为使用 Pro 2 就自动获得互联网工具。付费浏览器聊天存在显式搜索，公共 API 与外部客户端的工具配置需要分别确认。可以自行提供已核对的文档片段及版本，把外部资料和代码事实分开，不让模型把记忆里的接口名称当作当前库的证据。

参考来源

本文由 AI 辅助编写。示例用于说明方法，不是真实模型回答或对比测试。外部来源不能替代服务条款。

• Dikaya 中文文档：请求格式与客户端接入
  dikaya.cc
• Dikaya 中文模型目录：公开标识与能力声明
  dikaya.cc
• Dikaya 中文价格说明：配置价格与实际使用条件
  dikaya.cc
• OpenAI Python SDK 官方说明：关闭自动重试
  github.com
• MDN Fetch 使用指南：HTTP 状态与网络异常
  developer.mozilla.org