Prompts as task contracts

A useful prompt tells a system what work to perform and what counts as an acceptable result.

有用的提示词会告诉系统要完成什么工作，以及什么样的结果才算合格。

有用なプロンプトは、行う作業と、許容できる結果の条件をシステムに伝えます。

Giving a model an impressive professional persona may influence style, but it does not supply missing facts, permissions, or domain competence.

为模型设定一个令人印象深刻的专业角色，可能会影响表达风格，但无法补上缺失的事实、权限或领域能力。

立派な専門家の役割を与えると文体に影響することはありますが、不足した事実、権限、専門能力が得られるわけではありません。

For a support-triage task, the contract should specify the categories, the evidence to inspect, and how to handle an ambiguous request.

对于客服工单分类任务，任务约定应明确分类类别、需要检查的证据，以及如何处理含糊不清的请求。

顧客対応の振り分けでは、カテゴリ、確認する根拠、曖昧な問い合わせの扱いを指示に含める必要があります。

Suppose the available categories are billing, technical support, and unknown, and a customer writes that an error appeared while paying.

假设可选类别为“账单”“技术支持”和“未知”，而客户写道，付款时出现了一个错误。

請求、技術支援、不明というカテゴリがあり、顧客が支払い中にエラーが出たと書いたとします。

Without a decision rule, either of the first two categories could be a plausible interpretation.

如果没有判定规则，前两个类别都可能是合理的理解。

判断ルールがなければ、最初の二つのどちらも妥当な解釈になり得ます。

A stronger instruction asks the system to use the issue description, quote the relevant evidence span, and select unknown when the evidence does not support one category.

更明确的指令会要求系统依据问题描述，引用相关证据片段，并在证据不足以支持某一个类别时选择“未知”。

より明確な指示では、問題の説明を使い、関連する根拠部分を示し、どれか一つを裏付けられなければ不明を選ぶよう求めます。

If a business rule assigns failed payment transactions to billing, include that rule explicitly instead of expecting the model to infer local conventions.

如果业务规则将支付交易失败归入“账单”，就应明确写出该规则，而不是期待模型自行推断本地业务惯例。

決済失敗を請求担当に割り当てる業務ルールがあるなら、社内の慣習を推測させず、そのルールを明記します。

Few-shot prompting adds examples of the desired input-output relationship, including boundary cases that a general instruction may leave unclear.

少样本提示会加入示例，展示期望的输入与输出关系，其中也包括一般指令可能没有说清楚的边界情况。

少数例を用いるプロンプトでは、一般的な指示だけでは曖昧な境界事例も含め、望ましい入力と出力の対応例を追加します。

These examples become part of the context and do not, by themselves, update the model's parameters.

这些示例成为上下文的一部分，仅凭加入示例这一操作，并不会更新模型参数。

これらの例はコンテキストの一部になり、それだけでモデルのパラメータを更新することはありません。

Examples should cover meaningful distinctions rather than repeat the same easy pattern several times.

示例应覆盖有意义的区别，而不是把同一种简单模式重复几次。

例は簡単な同じパターンを何度も繰り返すのではなく、重要な違いを網羅するべきです。

Applications also distinguish different message roles or instruction channels, although the exact arrangement depends on the interface.

应用还会区分不同的消息角色或指令通道，不过具体安排取决于所用接口。

アプリはメッセージの役割や指示の経路も区別しますが、具体的な構成はインターフェースによって異なります。

A document being summarized should be treated as task data, even if it contains text telling the assistant to ignore its instructions.

待总结的文档应被当作任务数据，即使其中包含要求助手忽略原有指令的文字，也不例外。

要約対象の文書に指示を無視するよう書かれていても、その文書は作業対象のデータとして扱う必要があります。

Delimiters can clarify the separation between instructions and evidence, but delimiters alone are not an access-control system.

分隔符可以帮助区分指令与证据，但仅靠分隔符并不能构成访问控制系统。

区切り記号は指示と根拠の区別を明確にできますが、それだけではアクセス制御の仕組みになりません。

Similarly, requesting JSON describes an intended output format; a robust integration must validate the actual response and handle failures.

同样，要求输出 JSON，只是在说明期望的输出格式；可靠的集成仍必须校验实际响应，并处理失败情况。

同様にJSONを求めることは出力形式の希望を示しますが、堅牢な連携には実際の応答の検証と失敗への対応が必要です。

Evaluate a prompt revision on the same representative cases used for the previous version, including missing evidence and contradictory input.

评估提示词修订时，应使用与上一版本相同的代表性案例，包括证据缺失和输入相互矛盾的情况。

プロンプトの修正版は、根拠不足や入力の矛盾も含め、前の版と同じ代表的な事例で評価します。

If the revision improves one category while making another worse, record the tradeoff instead of declaring a universal improvement.

如果修订改善了一个类别，却让另一个类别变差，就应记录这种取舍，而不是宣布它带来了全面提升。

あるカテゴリで改善して別のカテゴリで悪化したなら、全体的な改善と断定せず、そのトレードオフを記録します。

A prompt is most useful when it expresses a testable task contract connected to evidence and application controls.

当提示词表达了一份可检验的任务约定，并与证据和应用控制措施相连接时，它最能发挥作用。

プロンプトは、根拠とアプリの制御につながる、検証可能な作業上の約束を表すときに最も役立ちます。