GLM 5.3 多文件协作指南：先对齐接口契约再修改代码

最小 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-glm-5-3",
    max_tokens=512,
    messages=[{"role": "user", "content": "为我的任务列出检查清单。将原始事实与假设分开。"}],
)
print(response.choices[0].message.content)

用一张契约图代替整个仓库的倾倒

以活动报名系统为例，一次改动可能涉及浏览器表单、请求校验、业务服务和存储记录。先列出文件角色与调用方向，说明哪些字段由谁生成、谁消费、哪里允许缺省。模型拿到的是有边界的调用链，而非一堆没有版本和路径关系的代码，更容易回查每条修改建议的依据。

区分公开 API 的承诺和内部实现细节。例如前端显示名称可以改变，但服务使用的报名状态枚举不能随意翻译。让模型把推测的依赖标为待确认，不凭一个导入语句宣布已经阅读整个模块。上下文能够容纳更多材料也不意味着客户端确实传送了仓库全部内容。

逐字段检查缺省、空值和旧版本

为联系人字段建立矩阵：未提供、显式 null、空字符串和非空文本分别是什么意思。前端清空输入不一定应该删除已有记录；后端缺省也未必等于空值。把四种输入在每一层的处理写清楚，让模型指出不一致的位置，并用当前代码片段支持判断，而不是只给笼统的类型建议。

加入旧客户端发送未知字段或缺少新字段的情形。若决定拒绝，明确错误码与可见提示；若兼容，说明由哪一层补足默认值。模型提出自动迁移或新增数据库字段时先列为另一个设计议题，不能把它悄悄混进本来只检查接口契约的任务中。

强度选项与输出上限要分别设置

该公开条目声明 low、high、max 推理强度，可以根据当前文档和任务范围选择。它们不是三档经过保证的质量分数，也不证明 max 必然更快解决问题。固定一份样本、保持输入契约一致，再比较可复现的缺陷覆盖；不把一两次主观印象包装成基准结果。

输出上限是另一个控制项，声明的模型上下文既不是答案长度，也不是浏览器历史额度。先请求契约矩阵，再单独请求必要差分，可以减少答案被截断后丢失关键文件的风险。若使用推理相关设置，还应查看实际 usage 和当前说明，不能把最终可见文字长度当作全部消耗。

在层与层的边界安排验收测试

先写一个最小端到端场景：旧记录存在联系人，用户清空输入，系统应按已经确认的契约更新。再分别测试表单序列化、服务校验和存储调用。模型应说明每个测试会抓住哪种不一致，期望值来自业务规则，而不是复制待测实现的同一段判断。

异常路径也要覆盖，例如请求格式错误不能在页面上显示为保存成功，服务拒绝不能被前端转换成空记录。运行测试在自己的环境完成，保留真实输出。代码展示没有执行能力的含义，模型生成的通过摘要也不能替代实际命令、退出状态和测试名称。

多文件并不意味着忽略输入形式

代码片段保留文件名、版本和相关行的上下文，过长时按调用边界拆分。浏览器支持的文本与代码附件有独立格式和容量限制，其他文件应先自行导出并核对。截图进入此模型之前使用另行付费的文字桥接，因此像素布局信息可能在描述中缺失，不应当作原生图像审查。

需要最新接口资料时，可以在付费浏览器明确启用搜索，把得到的外部来源和本地代码分开。搜索结果片段不能证明依赖安装的版本，也不表示公共 API 自带搜索。更稳妥的材料是锁定的依赖版本、实际接口文档摘录，以及你自己环境中观察到的调用结果。

用完整变更记录决定是否采纳

要求输出受影响文件、必须同步的字段、兼容性风险和未执行检查，然后逐项对照实际差分。拒绝把未提供的文件写成已经修改；如果测试只覆盖服务层，就明确前端尚未验证。这样能够识别代码局部看似合理，却让另一层继续使用旧字段解释的情况。

接入 API 时使用当前价格与权限信息，SDK 关闭自动重试并给出显式输出预算。明确 HTTP 拒绝和网络结果未知分开处理，不能凭断线宣布没有费用、没有保存或可以免费重做。本文提示只准备草稿，发送之前检查完整模型标识及已有草稿，避免把其他条目的任务误发给它。

常见问题

为什么要把 GLM 5.3 和 Pro 2 分成两个接入条目？

因为 seller-glm-5-3 与 seller-pro-2 是不同的公开模型标识。Pro 2 有基于 GLM-5.3 的修改版本说明，但不能据此合并二者的配置、权限或使用结果。为可追溯性，任务记录应保留精确标识，并按当前目录核对各自支持的参数与费用条件。

把 reasoning_effort 设为 max 就能保证跨文件正确吗？

不能。low、high、max 是该条目声明的强度选项，不能替代字段契约、完整输入或实际测试。先确认默认与支持方式，限定任务，再检查输出是否覆盖生产者和消费者。正确性证据来自可复现的测试与人工审查，而不是参数名称本身。

大上下文是否等于一次可以上传整个仓库？

不是。模型上下文、浏览器消息与字节限制、附件限制和输出上限各自存在，代码库也可能包含不该发送的凭证。先提供调用链相关文件和版本，按边界拆分并保留全局索引。只有实际送入并核对过的范围，才能写进此次审查的覆盖记录。

接口被拒绝与流式连接中断应该怎样分别记录？

收到明确 HTTP 错误时记录状态和安全诊断；中途断线或读取异常则可能无法确定最终处理结果。MDN 的 Fetch 文档帮助区分这些协议现象，但不能证明费用结算。关闭 SDK 自动重试，核对已有记录，不根据网络异常推定没有执行，再决定是否人工重新请求。

参考来源

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

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