Dayward AI
中文
Sign inSign up
Week 1 · D1About 3 hours

Advanced Prompting and Claude's "Personality": System Prompt, XML Tags, Letting the Model Think First, Structured Output

Skip the prompting basics and go straight to four Claude-specific habits: using a system prompt to set the role, using XML tags to organize long inputs, letting the model think before it answers, and requesting structured output.

Today's goals 0/3

Sign in to tick these off and save your progress.

今日目标

  1. 能说清 system prompt 与 user 消息的分工，并写出一份可复用的 system prompt
  2. 能用 XML 标签把多段材料、指令与示例组织成一份 Claude 读得清楚的长提示词
  3. 能让 Claude 先分析再作答，并用 JSON Schema 拿到结构化输出

这门课五天，讲的是同一件事：怎么带好一个能干但需要交代清楚的搭档。今天先学「怎么交代」，读完做完实验，回到页面顶部把三条目标勾掉。

小白版讲解

提示词基础在提示词课里，这里只讲 Claude 的四个习惯

先划一条边界。提示词（prompt）的通用写法——任务、背景、约束、输出格式四要素，给几个示例让模型照着学的少样本示例（few-shot），让模型一步步推的思维链（chain of thought）——这些在《5 天提示词工程零基础》的 D1 已经系统讲过，本课不重复。如果你连「把模糊需求写成清楚指令」都还没练过，先去那边花一小时，再回来。

本课的类比只有一个：你新招了一个搭档。这个搭档能力很强，读得快、写得快、不抱怨加班，但有一个特点：它只知道你交代过的事，没交代的它会自己猜。带这样的搭档，关键不在于「命令写得多凶」，而在于「交代得多清楚」。Claude 这个搭档还有四个特有的习惯，摸清了会顺手很多：

  1. 它对「名片」很敏感——你在系统提示（system prompt）里说它是谁，它整场都会照着演。
  2. 它读带标签的材料比读一坨文字准得多——XML 标签就是它认的分隔符。
  3. 它先想再说，答案会明显更稳——你要给它「想」的地方。
  4. 它能按你给的 JSON Schema 一字不差地吐结构化输出（structured output）——程序直接拿去用，不用再正则。

今天六个小节，前四个各讲一个习惯，第五个把四个习惯合成一份可复用的模板集，最后一节讲这份模板集在后面四天怎么用。贯穿本课的示例任务也在今天出场：「给一个 Express / FastAPI 的 TODO API 补上输入校验和对应的单元测试」。今天只用它练提示词，D3 起会真的让 Claude Code 动手做。

system prompt：给搭档一张名片，而不是在每句话里重复身份

想象你带新同事去见客户。你不会在每一句话前面都加「作为我们公司的后端工程师，你……」，而是在进门前塞给他一张名片：你是谁、代表谁、今天的边界在哪。之后的每句话，他都会站在这张名片的立场上说。

system prompt 就是这张名片。技术上，它是 Messages API 请求里一个独立的 system 字段，与 messages 数组里的用户消息分开；Claude 会把它当作整场对话的前提，而不是对话中的一句话。这带来两个实际差别：一是稠密对话里，放在 system 里的规则不会被后面几十轮聊天冲淡；二是它天然是「产品侧」的东西——人设、边界、输出风格由你统一维护，用户在对话里怎么说都不会改写它。

一张好名片有三段，顺序固定：

TextText
你是一名资深 Node.js 后端工程师，负责审阅并补全一个 Express TODO API。
 
边界：
- 只改 src/ 下的文件，不动 migrations/ 与 package.json
- 不引入 zod 以外的新依赖
- 不确定的需求先提问，不要猜
 
输出风格：
- 中文回答，代码块用英文注释
- 每次改动先说明「改哪里、为什么」，再给代码

三段分别回答三个问题：你是谁（角色）、你不能做什么（边界）、你说话什么样（风格）。注意「边界」写的是禁止项而不是能力清单——搭档的能力它自己知道，你要交代的是它不知道的红线。用代码写出来，两种语言长这样：

system-prompt.ts
import Anthropic from '@anthropic-ai/sdk'
 
const client = new Anthropic() // 自动读取 ANTHROPIC_API_KEY
 
const SYSTEM = `你是一名资深 Node.js 后端工程师，负责审阅并补全一个 Express TODO API。
边界：只改 src/ 下的文件；不引入 zod 以外的新依赖；不确定的需求先提问。
输出风格：中文回答，代码块用英文注释；每次改动先说明改哪里、为什么。`
 
const res = await client.messages.create({
  model: 'claude-sonnet-5',
  max_tokens: 1024,
  system: SYSTEM, // 名片放这里，不塞进 messages
  messages: [{ role: 'user', content: 'POST /todos 现在完全不校验请求体，先说说你打算怎么做。' }],
})
 
// 回复是一组内容块，文本块的 type 是 'text'
for (const block of res.content) {
  if (block.type === 'text') console.log(block.text)
}

工程代价在哪？system prompt 每次请求都会原样发一遍，它越长，每次请求的输入 token 就越多。所以「名片」要精简：能从对话上下文推出来的不写，标准的语言惯例不写。这条判据 D3 讲 CLAUDE.md 时会再出现一次，因为 CLAUDE.md 本质上就是 Claude Code 这个搭档的 system prompt。另一个常见误区是把「当前时间」「用户名」这种每次都变的东西塞进 system 开头，这会让 D2 要讲的 prompt caching 完全失效——名片上不要写日期。

XML 标签：把材料、指令、示例分装进有名字的盒子

你让搭档看一份需求文档、一段现有代码、三条测试用例，然后照着写。如果你把这四样东西复制粘贴成一整段发过去，他要先花力气分辨「哪一段是需求、哪一段是代码、哪一段是给我的指令」，分错了就全错。换成四个贴了标签的文件袋递过去，他一眼就知道每一袋是什么。

Claude 认的「标签」是 XML 风格的成对标记。这不是硬性语法，而是训练时大量见过的组织方式：<document>、<instructions>、<example> 这类标签把不同性质的内容清清楚楚地分开，模型分辨边界的准确率明显更高，也更容易在回答里引用「文档里第几条」。标签名可以自己起，只要成对、语义清楚、前后一致。一份长输入的骨架长这样：

TextText
<context>
这是一个 Express 写的 TODO API，路由在 src/routes/todos.ts，
数据结构见下面的 schema。
</context>
 
<schema>
type Todo = { id: string; title: string; done: boolean; dueAt?: string }
</schema>
 
<current_code>
router.post('/todos', (req, res) => {
  const todo = { id: nanoid(), ...req.body }
  store.push(todo)
  res.status(201).json(todo)
})
</current_code>
 
<instructions>
1. 用 zod 给 POST /todos 的请求体加校验：title 必填且 1–200 字，dueAt 可选且必须是 ISO 日期
2. 校验失败返回 400，body 形如 { error: string, issues: [...] }
3. 只给出需要改动的函数，不要重写整个文件
</instructions>
 
<example>
输入：{ "title": "" }
期望：400，error 为 "invalid body"
</example>

三个写法上的细节值得记住。第一，指令放在材料之后，尤其是材料很长的时候——搭档读完全部材料再看到「你要做什么」，比先看指令再翻几千行材料记得更牢，官方文档对长文档的建议也是「文档在前、问题在后」。第二，回答里让它引用标签：比如「先引用 current_code 里有问题的那一行，再给修改」，这会让它的回答可核对。第三，标签只是分隔符，不要为了「看起来专业」把每句话都包起来，三到六个顶层标签是常态。

有人会问：Markdown 的标题和代码围栏不也能分段？能，而且 Claude 也读得懂。区别在于 XML 标签是成对的，有明确的开始和结束，材料里本身就含有 Markdown 时（比如你贴进去一份 README）不会串位。你贴的材料越杂，这个优势越明显。

让模型先思考：分析与答案分开写，读者和程序各取所需

你问搭档「这个接口该不该加限流」，有两种回答方式。一种是脱口而出「该」；另一种是「这个接口每秒被调 3 次、没有鉴权、下游是付费 API，所以该」。第二种即使结论一样，你也放心得多，因为你能检查推理过程有没有漏掉什么。

对模型来说这不只是「显得靠谱」，而是实实在在的准确率差异：让它先把分析写出来再给结论，等于让它在生成答案之前多算几步，复杂任务上错误率会明显下降。做法很简单——给「想」和「答」各留一个标签：

TextText
先在 <analysis> 标签里逐条分析：现有代码有哪些输入没有校验、
每一项可能导致什么错误、你打算用什么规则拦住。
然后在 <answer> 标签里只给最终代码，不要重复分析。

这样输出会天然分成两段。给人看的时候两段都展示；给程序用的时候只取 <answer> 那一段，分析部分不进入后续流程。这就是「读者和程序各取所需」——你不需要在「要解释」和「要干净的结果」之间二选一。

顺带说清一个容易混淆的点：Claude 的新模型自带一种「先在内部想清楚再回答」的能力，API 里叫 thinking，默认是自适应开启的——模型自己决定这题要想多少。它和上面这种「在输出里写分析段」不冲突，也不互相替代：thinking 是模型内部的推理，你控制它的深度（output_config.effort）而不是内容；分析段是你要求它写给你看的推理，可核对、可存档、可作为后续对话的材料。简单题两个都不用，复杂题两个都用，需要审计过程的题一定要有分析段。

代价也很直白：分析段是输出 token，按输出价计费，而输出通常比输入贵好几倍。所以分析段要「按需」——批量处理一千条简单分类，写分析段就是在烧钱；审一份合同、评一段安全代码，分析段就是必需品。这个取舍是今天面试题的重点之一。

结构化输出：用 JSON Schema 拿到程序能直接用的结果

搭档做完一件事，你希望他填一张固定格式的表，而不是发一段散文让你自己从里面抠字段。以前的做法是在提示词里写「请只返回 JSON，不要多说话」，然后祈祷它不要在前面加一句「好的，以下是 JSON：」——祈祷经常落空，所以每个人都写过一段用正则把 JSON 从回复里挖出来的代码。

Claude 现在支持把 JSON Schema 直接作为请求参数传进去（output_config.format），模型的输出会被约束解码成严格符合这个 schema 的 JSON：字段齐全、类型正确、没有多余的话。两种官方 SDK 都提供了 parse 方法，让你用 zod 或 pydantic 定义类型，返回值直接是解析好的对象：

structured.ts
import Anthropic from '@anthropic-ai/sdk'
import { zodOutputFormat } from '@anthropic-ai/sdk/helpers/zod'
import { z } from 'zod'
 
const Review = z.object({
  missing_validations: z.array(z.string()), // 哪些字段没校验
  severity: z.enum(['low', 'medium', 'high']),
  suggested_tests: z.array(z.string()), // 建议补哪些测试
})
 
const client = new Anthropic()
const res = await client.messages.parse({
  model: 'claude-sonnet-5',
  max_tokens: 1024,
  messages: [
    {
      role: 'user',
      content: `<current_code>
router.post('/todos', (req, res) => { store.push({ id: nanoid(), ...req.body }); res.status(201).json(req.body) })
</current_code>
请评审这段代码的输入校验。`,
    },
  ],
  output_config: { format: zodOutputFormat(Review) }, // schema 作为参数，不写进提示词
})
 
const review = res.parsed_output // 已经是 Review 类型，不用 JSON.parse
console.log(review?.severity, review?.missing_validations)

几个边界要知道。schema 支持对象、数组、枚举、常量、可选字段这些常用形状，但不支持递归结构、数值范围（minimum / maximum）和字符串长度限制——这些校验要在你自己的代码里补。结构化输出与 citations（D2 会讲）不能同时开。另外，一旦你要求了结构化输出，「分析段」就没地方放了——所以上一节说的「先思考」在这里有两种落法：要么在 schema 里显式加一个 reasoning 字段放在其他字段前面（模型会先生成它，效果与分析段类似），要么依赖模型内部的 thinking。批量抽取、分类打标、把非结构化文本变成表——这些场景直接上结构化输出；需要长篇解释给人看的场景，还是用标签分段。

把四个习惯装进一份模板集，D2 起每天都会用到

到这里四个习惯都讲完了：名片（system prompt）、文件袋（XML 标签）、先想再说（分析段）、填表（结构化输出）。它们不是四种互斥的技巧，而是同一份提示词里四个可以同时出现的部件。合在一起，一次完整的交代长这样：

  • system：三段式名片，几十到两三百字，不含会变的信息。
  • user 消息：先放材料（每份一个标签），再放指令，最后放示例；如果要看推理，指令里要求分析段与答案段分开。
  • 请求参数：需要程序消费结果时传 schema，不需要就不传。

今天的实验就是把这四个部件各写成一份带空位的模板，然后用示例任务填一遍。这份模板集不是交作业用的，是给你自己后面四天用的：D2 读 PDF 的提示词会用到「材料在前、指令在后」；D3 写 CLAUDE.md 时你会发现它就是一张给 Claude Code 的名片，「删到不能再删」的判据和今天 system prompt 的判据一模一样；D4 写 SKILL.md 时的「说明书」就是分析段与指令段的组合；D5 用 claude -p 跑 CI 时，--append-system-prompt 传的正是今天写的名片。

最后提醒一件事。四个习惯都在讲「怎么交代」，但交代清楚只解决了一半问题：搭档听懂了，做出来的东西对不对，还得有人检查。这门课后半程的重心，会从「怎么说」转到「怎么让它自己验证」——那才是把 Claude 从聊天工具变成生产力工具的分水岭。

源码导读

动手实验

🧪 D1 实验：一份自用的 Claude 提示词模板集（Markdown）

Code location: labs/claude-mastery/day-01-prompt-templates

验收标准：

  1. system-prompt.md 有角色、边界、输出风格三段，全文不含日期、用户名等会变的信息，不超过 300 字。
  2. long-input.md 用至少三个成对的顶层标签分装材料、指令、示例，指令在材料之后。
  3. think-first.md 明确写出分析段与答案段各用什么标签，并说明程序只取哪一段。
  4. structured.md 附一个最小 JSON Schema，字段不少于三个，且没有在提示词正文里重复描述格式。
  5. 四份模板都用示例任务「给 TODO API 补输入校验和单元测试」填过一遍，填好的版本放在同一文件的「示例」一节。

这是一个文档型实验：没有代码要跑，产出是四份 Markdown 模板。starter/ 里的模板留了空位，solution/ 是填好的示范。先看 solution 一遍，再回到 starter 自己写——直接抄 solution 就失去了练习的意义，因为这份模板集将来要装的是你自己项目的名片，不是课程里的 TODO API。

  1. 打开 starter 里的 system-prompt.md，按角色、边界、输出风格三段填空，写完通读一遍，把任何「模型本来就知道」的句子删掉。
  2. 打开 long-input.md，把示例任务的需求、现有代码、测试用例各装进一个标签，把指令放在最后；数一下顶层标签是否在三到六个之间。
  3. 打开 think-first.md，指定分析段与答案段的标签名，并写一句「程序只解析哪一段」，想清楚这份模板适合什么复杂度的任务。
  4. 打开 structured.md，为「代码评审结果」写一个最小 JSON Schema（至少三个字段，含一个枚举），确认提示词正文里没有再描述格式。
  5. 把四份填好的模板在任何一个 Claude 客户端或 API Playground 里各跑一次，观察输出是否分段、是否符合 schema，把不满意的地方改回模板里。

面试题

今天 3 道题在下方题库区，侧重 system prompt 的职责边界、XML 标签为什么对 Claude 有效、结构化输出与思考的取舍。展开后先看「分析过程」再看要点——照着推导练，比背要点管用。标注「国内高频 / 海外高频」方便按目标市场取舍。

检查清单与明日预告

  • 能说清 system prompt 与 user 消息的分工，并写出一份可复用的 system prompt
  • 能用 XML 标签把多段材料、指令与示例组织成一份 Claude 读得清楚的长提示词
  • 能让 Claude 先分析再作答，并用 JSON Schema 拿到结构化输出
  • 能说出「分析段」与模型内部 thinking 的区别，以及各自的计费代价
  • 实验的 5 条验收标准全部通过
  • 3 道面试题不看要点也能答出至少 2 道

明天（D2）我们第一次真正用代码调 Claude：把一份几十页的 PDF 整本喂进去，让它给出带页码引用的摘要，再用 prompt caching 把反复提问的成本降一个量级。今天的「材料在前、指令在后」会直接用上，而「名片上不要写日期」这条为什么重要，明天讲缓存的前缀语义时你会恍然大悟。先学交代、再学喂材料，是因为材料一多，交代不清的代价会被放大几十倍。

Interview questions

  • What belongs in a system prompt and what doesn't? If the model keeps ignoring one rule, what do you check first?system prompt 应该放什么、不该放什么？如果一条规则模型总是不遵守，你会先检查什么？
    Common in ChinaCommon overseasBasic#system-prompt#prompt-design

    How to reason about it · think before answering

    1. The question tests boundaries, not writing skill. Naming what to exclude, and why, is what separates a strong answer.
    2. Give the rule: the system prompt is a fixed premise resent on every request, so it holds only what is true for the whole conversation — role, constraints as prohibitions, output style. Anything that varies per turn belongs in the user message.
    3. Then the anti-patterns: obvious conventions, pasted API docs, and per-turn material dilute the important rules and also invalidate the prompt-cache prefix on every call.
    4. Debug order for an ignored rule: check length first and prune, then check for ambiguity or conflicting rules, and only then add emphasis. If the rule is a must-run action, move it to a deterministic gate instead of adding more words.
    5. Likely follow-up: can system go last? Possible but unwise — earlier instructions carry more weight and a moving prefix breaks caching.

    分析过程 · 先想清楚再作答

    1. 这题考的是「职责边界」而不是「会不会写」。答成「放角色和要求」是及格线，能说出「不该放什么」以及「为什么」才有区分度。
    2. 先给一条判据：system prompt 是每次请求都重发的固定前提，所以只放整场对话都成立的东西——角色、边界（禁止项）、输出风格；每次都变的（时间、用户名、本轮材料）放 user 消息。
    3. 再说反面：把模型本来就知道的常识（「写干净的代码」）、大段 API 文档、每轮都不一样的材料塞进 system，只会稀释真正重要的规则，还会让 prompt caching 的前缀每次都变。
    4. 「规则总是不遵守」的排查顺序：先看 system 是不是太长导致规则被淹没（删到不能再删），再看规则是否含糊或与别的规则冲突，最后才考虑加强调；如果是「每次必须执行」的动作，应该改成程序层面的门禁而不是继续加规则。
    5. 可预期的追问：system 放最后行不行？可以但不推荐——模型对靠前的指令更敏感，且会破坏缓存前缀。

    Key points

    • Include role, prohibitions, and output style — premises that hold for the whole conversation
    • Exclude volatile facts, common sense the model already has, and long pasted docs
    • The system prompt is resent every request: longer means costlier and rules get buried
    • For an ignored rule: prune first, disambiguate second, emphasize last; must-run actions become deterministic gates

    答题要点

    • 放：角色、边界（写禁止项）、输出风格；整场对话都成立的固定前提
    • 不放：会变的信息（时间、用户名、本轮材料）、模型本来就知道的常识、大段文档
    • system 每次请求重发，越长越贵，也越容易让关键规则被淹没
    • 规则不被遵守先删再改再强调；「每次必须做」的动作改成程序门禁
  • Why does organizing long prompts with XML tags work so well for Claude, and how does it differ from using Markdown sections?为什么用 XML 标签组织长提示词对 Claude 特别有效？和用 Markdown 分段比有什么区别？
    Common in ChinaCommon overseasIntermediate#xml-tags#long-context

    How to reason about it · think before answering

    1. The keyword is why. Citing the docs is not an answer; explain it in terms of how the model detects content boundaries.
    2. Breakdown: the core risk in a long prompt is mixing material, instructions, and examples. Paired tags give each part an explicit start, end, and name, so the model separates them reliably and can reference a specific section in its reply.
    3. Versus Markdown: headings and fences delimit but have no explicit closing marker, so pasted material that itself contains Markdown breaks the structure. XML tags are paired, nestable, and freely named, and the benefit grows with messier input.
    4. Add the engineering habits: consistent tag names, instructions after the material, and asking the model to cite tags in its answer. Three to six top-level tags is typical.
    5. Follow-ups: is there a fixed tag vocabulary? No — structure and semantics matter, consistency within one prompt matters. What if the material contains XML? Pick non-colliding names.

    分析过程 · 先想清楚再作答

    1. 题眼在「为什么」。只答「官方推荐」等于没答；要能从「模型如何分辨内容边界」这个角度解释。
    2. 拆法：长提示词的核心风险是不同性质的内容（材料、指令、示例）混在一起，模型分错边界就会把材料里的句子当指令执行、或把示例当成事实。成对的标签给每一段一个明确的起止和名字，模型分辨边界的准确率更高，也能在回答里精确引用「哪一段」。
    3. 与 Markdown 的区别：Markdown 靠标题和围栏分段，但没有显式的结束标记；当贴进去的材料本身含 Markdown（比如一份 README）时容易串位。XML 标签成对、可嵌套、名字自定义，材料越杂优势越大。
    4. 补一条工程习惯：标签名前后一致，指令放在材料之后，回答时要求引用标签名。三到六个顶层标签是常态，不要过度包装。
    5. 可预期的追问：标签名有没有固定词表？没有，模型看的是结构和语义，但同一个提示词内要一致；另一个追问是「材料本身含 XML 怎么办」——换一个不会撞的标签名，或用 CDATA 式的转义说明。

    Key points

    • Long prompts mix material, instructions, and examples; paired tags give each an explicit boundary and name
    • Boundary detection becomes reliable and the model can cite a specific section
    • Markdown has no closing marker and breaks when pasted material contains Markdown; XML tags are paired, nestable, and freely named
    • Habits: consistent names, instructions after material, ask for tag citations, three to six top-level tags

    答题要点

    • 长提示词的风险是材料、指令、示例混在一起；成对标签给每段明确的起止和名字
    • 模型分辨边界更准，也能在回答里精确引用某一段
    • Markdown 没有显式结束标记，材料含 Markdown 时会串位；XML 标签成对、可嵌套、可自定义
    • 习惯：标签名一致、指令放材料之后、要求引用标签、顶层标签三到六个
  • When should you have the model write its analysis before answering, and when should you go straight to structured output? Can you have both?什么时候该让模型先写分析再回答，什么时候直接要结构化输出？两者能同时要吗？
    Common in ChinaCommon overseasIntermediate#structured-output#reasoning

    How to reason about it · think before answering

    1. This is a trade-off question; the criteria are who consumes the output and what an error costs. Give a decision rule, not 'it depends'.
    2. Chain: the analysis is output tokens, billed at output rates and adding latency, in exchange for higher accuracy on complex tasks and an auditable trace. The more complex, high-stakes, or human-reviewed the task, the more you want it; bulk, simple, machine-consumed tasks go straight to structured output.
    3. Can you have both? Once a JSON schema is passed the output is constrained to JSON, so free-text analysis has nowhere to go. Two options: add a reasoning field placed before the other fields, or rely on the model's internal thinking, whose depth you control but not its content.
    4. Production nuance: structured output fixes parsing reliability, not judgment quality; the schema cannot express numeric ranges or string lengths, so validate those yourself.
    5. Follow-ups: can the analysis leak into downstream code? Yes — separate analysis and answer with tags and parse only the answer. Thinking versus a written analysis: internal versus visible, depth versus content.

    分析过程 · 先想清楚再作答

    1. 这题考取舍，判据是「谁消费输出」和「错误的代价」。答「都用」或「看情况」没有信息量，要给出可执行的判断句。
    2. 推导链：分析段是输出 token，按输出价计费，且会让响应变长；它换来的是复杂任务上更高的准确率与可核对的推理过程。所以任务越复杂、错误代价越高、越需要人审计，越该要分析段；批量、简单、程序直接消费的任务，直接要结构化输出。
    3. 「能不能同时要」：一旦传了 JSON Schema，输出被约束成 JSON，自由文本的分析段没地方放。两条路：在 schema 里加一个 reasoning 字段放在其他字段前面（模型会先生成它），或者依赖模型内部的 thinking——它是内部推理，你控制深度不控制内容。
    4. 生产视角：结构化输出解决的是「解析可靠性」，不是「判断正确性」；schema 不支持数值范围与字符串长度约束，这些校验要自己补。
    5. 可预期的追问：分析段会不会被程序误用？会，所以要用标签把分析段与答案段分开，程序只取答案段；另一个追问是 thinking 与分析段的区别——一个内部一个外显，一个控深度一个控内容。

    Key points

    • Written analysis costs output tokens and latency but raises accuracy and gives an auditable trace — use for high-stakes, human-reviewed work
    • Structured output is consumed directly by code with zero parse failures — use for bulk, simple extraction and classification
    • To combine: put a reasoning field first in the schema, or rely on internal thinking
    • Structured output guarantees shape, not correctness; add range and length validation yourself

    答题要点

    • 分析段：输出 token 计费、更慢，但复杂任务更准、过程可核对；适合高风险、需人审的任务
    • 结构化输出：程序直接消费、解析零失败；适合批量、简单、明确的抽取与分类
    • 同时要：在 schema 里加靠前的 reasoning 字段，或依赖内部 thinking
    • 结构化输出保证的是格式不是正确性；范围与长度校验要自己补

Comments

Sign in to join the discussion

No comments yet — be the first.