Structured outputs and reliable interfaces

An application often needs a predictable data structure rather than a paragraph of prose.

应用通常需要格式可预测的数据结构，而不是一段普通文字。

アプリでは、文章の段落ではなく、予測できるデータ構造が必要なことがよくあります。

A refund assistant might return a decision, an amount, a currency, and identifiers for the evidence it used.

退款助手可能需要返回决定、金额、币种，以及所用证据的标识符。

返金アシスタントは、判断、金額、通貨、使用した根拠の識別子などを返すことがあります。

A schema describes permitted fields and value types, helping software interpret the result consistently.

模式（schema）规定允许出现的字段和值的类型，帮助软件以一致的方式解读结果。

スキーマは許可するフィールドと値の型を示し、ソフトウェアが一貫して結果を解釈する助けになります。

Some model interfaces support constrained structured output, but the supported schema features and failure behavior must be checked for the selected interface.

某些模型接口支持受约束的结构化输出，但必须核实所选接口支持哪些模式特性，以及发生失败时会怎样处理。

一部のモデルのインターフェースは制約付きの構造化出力に対応しますが、使えるスキーマの機能と失敗時の動作は選ぶインターフェースで確認する必要があります。

Merely asking for JSON in a text prompt is different from enforcing a supported output constraint.

只在文字提示中要求输出 JSON，与实际强制执行接口支持的输出约束，是两回事。

テキストの指示でJSONを求めるだけのことと、対応する出力制約を適用することは異なります。

Even when an output conforms to a schema, the business meaning of its values may be wrong.

即使输出符合模式，其中各项值的业务含义仍可能是错的。

出力がスキーマに適合していても、値の業務上の意味が誤っていることがあります。

Consider a fictional output approving a refund of 900 yen for an order whose eligible refund amount is only 600 yen.

考虑一个虚构的输出：某笔订单符合条件的退款金额只有 600 日元，输出却批准退款 900 日元。

返金可能額が600円の注文について、900円の返金を承認する架空の出力を考えます。

The amount can be a valid number and the currency a valid string, while the proposed decision still violates the order's conditions.

金额可以是有效的数字，币种也可以是有效的字符串，但所提出的决定仍然违反该订单的条件。

金額が有効な数値で通貨が有効な文字列でも、提案した判断は注文の条件に違反しています。

Domain validation must therefore check the amount against authoritative order data and the applicable policy.

因此，业务规则校验必须依据权威订单数据和适用规定来核对金额。

そのため業務上の検証では、金額を正式な注文データと適用規定に照らして確認する必要があります。

Authorization is another separate check: a correct amount does not establish that this user is allowed to approve it.

授权是另一项独立检查：金额正确并不能证明当前用户有权批准这笔退款。

認可も別の確認であり、金額が正しくても、その利用者に承認権限があるとは限りません。

A robust interface also needs explicit representations for unknown information, refusal, unavailable evidence, and temporary tool failure.

可靠的接口还需要明确表示信息未知、拒绝处理、证据不可用和工具暂时故障等状态。

堅牢なインターフェースには、不明情報、拒否、根拠の利用不可、一時的なツール障害を明示する表現も必要です。

If every field is mandatory without an unknown state, the design may pressure the model to invent a value merely to complete the form.

如果每个字段都必填，却没有表示未知的状态，这种设计可能迫使模型仅为了填完整张表而编造一个值。

不明という状態を用意せず全フィールドを必須にすると、フォームを埋めるためだけに値を作り出すようモデルを誘導する設計になりかねません。

A nullable amount can mean no supported amount is available, but the application must define that meaning rather than leave it ambiguous.

允许金额为 null 可以表示没有依据充分的金额可用，但应用必须明确规定这个含义，不能让它含糊不清。

nullの金額は裏付けのある金額がないことを表せますが、その意味は曖昧にせずアプリで定義する必要があります。

Streaming introduces a timing issue because an incomplete response may not yet form a complete or valid object.

流式输出会引入时序问题，因为尚未传输完毕的响应可能还不能构成完整或有效的对象。

ストリーミングでは、途中の応答がまだ完全で有効なオブジェクトでない場合があるため、タイミングの問題が生じます。

A preview can update while content arrives, but an external action should wait for the required validation and authorization checks.

内容到达时可以逐步更新预览，但应等到必要的校验和授权检查完成后，再执行外部操作。

内容の到着中にプレビューを更新することはできますが、外部への操作は必要な検証と認可を待つべきです。

Retries should have limits and should preserve the original task evidence so that repair does not silently change the requested decision.

重试应有次数限制，并保留最初任务的证据，避免修复过程悄悄改变原本要求作出的决定。

再試行には上限を設け、修復中に求められた判断が黙って変わらないよう、元の作業の根拠を保持すべきです。

Well-formed output is necessary for reliable integration, but factual support, domain rules, and permissions determine whether that output can be used.

格式正确的输出是可靠集成的必要条件，但该输出能否实际使用，还取决于事实依据、业务规则和权限。

正しい形式の出力は信頼できる連携に必要ですが、使用できるかを決めるのは事実の裏付け、業務ルール、権限です。