推理与答案分区输出
做法是用固定标签把推理过程与最终答案分开，例如 <reasoning> 与 <answer>。好处有两个：程序只需要定位 answer 区块取内容，不必从整段文字里猜哪个数字才是答案；面向用户的界面可以只展示 answer，推理留给日志与排查。这是把推理类任务接进工程流水线时最省事的一种结构，也是避免把中间量当结论的直接办法。
要点
| 解析 | 程序先定位 <answer> 区块，只用其中内容，避免把推理里的数字误当答案 |
|---|---|
| 展示 | 面向用户的界面只展示 answer 区块，reasoning 留给日志 |
| 加固 | 再补一句「答案只出现在 answer 区块」，减少内容被写错位置 |
| 标签命名 | 选择不易与正文混淆的标签，避免实际内容里出现同名串 |
| 兜底 | 解析不到标签时按失败处理并重试，不要退回正则抓数字 |
典型使用场景
- 数值问答：中间计算与最终数值分开，避免取错
- 决策建议：推理与结论分区，只把结论推送给业务方
- 评测场景：评分器只看 answer 区块，减少推理文本的干扰
- 多步流程：上一步的 answer 作为下一步的输入，结构稳定
- 日志留痕：reasoning 入日志库，便于复盘模型思路
标签模板
标签模板
请按以下结构输出：
<reasoning>
（推理过程，可分点，不超过 200 字） # 控制长度，避免挤占答案预算
</reasoning>
<answer>
（最终答案，一句话） # 只写结论，不重复推理内容
</answer>分区方式的取舍
| 方式 | 优点 | 注意 |
|---|---|---|
| 标签分区 | 一次调用即可，解析简单 | 标签被正文伪造时可能提前闭合 |
| 两次调用 | 答案提取最干净 | 成本与延迟翻倍 |
| JSON 字段 | 推理与答案各占一个字段，解析最稳 | 需平台支持结构化输出或严格约定 |
| 前缀标记 | 如「答案：」，书写最简 | 正文里若再次出现该标记，定位会出错 |
标签名要唯一且不常见：若正文里可能自然出现 </answer>，解析前先做同名串剔除，或改用 JSON 字段承载。