降重、降 AI接口文档 - 请求响应说明
降重降AI接口文档，包含请求参数、响应格式、HTTP状态码说明，一次改写同时降重和降AI，支持中英文，兼容知网、维普、Turnitin等9大检测平台。
降重、降 AI接口 v2.3
本接口只做纯文本改写：输入输出都是文本，不支持上传文档。 text 参数只接受纯文本字符串（JSON 字符串字段），传入 Word/PDF 等文件、URL 或 Base64 编码的文档都会失败；接口也不会返回文档文件。
需要处理整篇论文时，正确做法是：在您的程序里解析文档 → 提取正文自然段（可配合 [[FNxxx]] 占位符完整保留脚注）→ 逐个段落调用本接口 → 把改写结果写回文档。各语言的文档解析与写回示例见语言接入指南。文档直传改写能力目前在规划中。
2026-09-07，v2.3 更新，重大升级：进一步提升改写质量；支持英文改写，可通过 Turnitin 的查重和 AI 检测；万方平台降AI效果提升至「高」；新增 Turnitin 检测平台。
注意：2026年5月份格子达AI检测重大升级，目前我司当前版本已无法通过该模型的检测。
该服务属于段落级别的改写，并不支持长文改写，接口支持1000字以内文本。请逐个段落调用降重降AI接口。 强烈建议：按段落传入接口进行改写，不建议把提纲、目录、参考文献、公式以及代码一起传入，会影响改写结果。
1. 接口地址
POST https://api.llmapi.fit/completion/v2/reduce
2. 认证方式
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
3. 请求参数
| 参数名 | 类型 | 必填 | 说明 |
|---|---|---|---|
text | string | 是 | 需要改写的纯文本内容（最多1000字）；只接受文本字符串，不支持文件、URL 或文档 Base64 |
service_type | string | 否 | 系统已内置为mix，无需指定 |
接口默认同时完成降重和降AI，
service_type是v 1.30版本用的参数，此处为了兼容，故依然保留该参数，无需传入。
4. 请求示例
curl -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"text": "高村乡农村集体经济发展的重要因素是带头人的能力水平..."
}' \
"https://api.llmapi.fit/completion/v2/reduce"
5. 响应示例
与v 1.30的响应结构完全一样
{
"code": "success",
"message": "",
"request_id": "a1b2c3d4e5f6789012345678",
"output_text": "高村乡农村集体经济发展重要的是带头人能力强...",
"input_text_count": 169
}
6. 错误码说明
HTTP 200 表示改写成功，返回JSON包含
"code": "success"。非200状态码表示请求失败，响应体中包含
code字段标识具体错误类型。
6.1 code与message对照表
| HTTP状态码 | code | message | 处理建议 |
|---|---|---|---|
| 400 | textEmpty | 文本内容为空 | 检查 text 字段是否为空 |
| 400 | textTooLong | 文本超过字数限制 | 不超过1000字 |
| 400 | useageLimitedFailed | 可用字数不足 | 提醒用户充值 |
| 400 | badRequest | 请求参数错误 | 检查请求参数格式 |
| 401 | unauthorized | API密钥无效或已禁用 | 检查API密钥是否正确 |
| 429 | rateLimited | 请求过于频繁 | 降低请求频率，等待后重试 |
| 500 | internalFailed | 服务器内部错误 | 稍后重试，如持续出现请联系技术支持 |
| 503 | noGpuAvailable | GPU服务繁忙 | 等待3-5秒后重试 |
| 503 | serviceUnavailable | 服务暂时不可用 | 稍后重试 |
6.2 错误响应格式
所有错误响应均包含 code 和 message 字段：
{
"code": "错误码",
"message": "错误描述信息"
}
6.3 常见错误示例
// 余额不足
{
"code": "useageLimitedFailed",
"message": "可用字数不足"
}
// 文本超限
{
"code": "textTooLong",
"message": "文本字数超过1000字上限"
}
// GPU服务繁忙
{
"code": "noGpuAvailable",
"message": "GPU服务繁忙，请稍后重试"
}
// 请求过于频繁
{
"code": "rateLimited",
"message": "请求过于频繁，请稍后重试"
}
7. 注意事项
最重要的使用规则：逐个段落改写，只传正文段落。
我们发现不少开发者把好几段文本合并成一次请求发给接口，这种用法不被支持，改写效果会明显变差。本接口是段落级别的改写服务，一次请求只应处理一个正文自然段。正确用法带来的降重降AI效果远好于合并多段调用。
7.1 只传正文段落
标题、目录、参考文献、代码、表格、公式都不应传入接口，只输入正文的自然段：
| 内容类型 | 是否传入 | 说明 |
|---|---|---|
| 正文自然段 | ✅ | 接口只为此设计，逐段传入效果最佳 |
| 标题 / 目录 / 提纲 | ❌ | 改写后破坏文档结构，且无降重意义 |
| 参考文献 | ❌ | 引用格式固定，改写会破坏引用规范 |
| 代码 | ❌ | 代码不可改写，混入会污染改写结果 |
| 表格 | ❌ | 表格结构会被改散，需要保留原样 |
| 公式 | ❌ | 公式（含LaTeX）改写后无法使用 |
7.2 其他注意事项
- 文本长度：单次请求不超过1000字
- 请求速率：建议控制在10次/秒以内
- 字数统计：按Word统计方式，非字符数
- 失败扣费：请求错误时字数会自动退回
8. 脚注编号保持（[[FNxxx]] 占位符）
论文段落中经常带有脚注引用。如果把整段文本不加处理直接发给改写接口，脚注引用会被当作普通文字改写或丢弃，写回 Word 后脚注丢失且无法找回。为此，接口支持 [[FNxxx]] 脚注占位符：改写后的结果会原样保留占位符及其位置语义，你可以据此把脚注引用精确恢复到原位。
该机制对 .doc 和 .docx 同样有效——两种格式中脚注的概念结构一致：正文放引用标记、条目集中存储，占位符策略完全通用。
8.1 原理：为什么整段替换会丢脚注
docx 是 OOXML（ECMA-376）格式，脚注分两部分存储：
- 正文（
word/document.xml）：脚注引用是内联元素，和普通文字一样占据段落文字序列中的一个位置——这个位置本身就是引用与条目的关联信息； - 条目（
word/footnotes.xml）：所有脚注的内容集中存储，按 id 与正文引用一一对应。
.doc（二进制格式）虽然存储方式不同，但脚注的概念结构与上述一致：正文放引用、条目集中存储，因此同样的占位符策略直接适用。
常见的错误做法是"整段替换"——删除旧段落、插入全新段落。这会把引用元素随段落一起删掉，footnotes.xml 中的条目变成孤儿条目，不再被渲染，再次保存时被 Word 直接清除，脚注永久丢失。
正确做法是：段落对象不动，只替换段落内的文字；提取文本时把每个脚注引用替换为占位符，写回时按占位符把原引用插回原位。
8.2 占位符规范
| 项目 | 规范 |
|---|---|
| 格式 | 双方括号 + FN + 序号：[[FN0]]、[[FN1]]、[[FN2]]…… |
| 起始 | 每段从 [[FN0]] 开始，按引用在段内出现的先后顺序编号 |
| 作用域 | 段落内独立编号，段与段之间互不影响，支持多段并行改写 |
| 位置 | 占位符紧跟被标注的文字，可出现在句中任意位置（与原文引用位置一致） |
8.3 完整流程示例
第一步：提取段落文本，脚注引用替换为占位符（Word 中显示的原文，¹、² 为脚注上标）：
国外研究方面，Zawaideh¹将BIM与可解释机器学习相结合，对高层建筑施工的成本、进度与碳风险进行预测；Nguyen等²运用结构方程模型分析了建设项目成本超支各成因。
提取后实际发送给接口的 text：
国外研究方面，Zawaideh[[FN0]]将BIM与可解释机器学习相结合，对高层建筑施工的成本、进度与碳风险进行预测；Nguyen等[[FN1]]运用结构方程模型分析了建设项目成本超支各成因。
第二步：调用接口改写，返回的 output_text 中占位符被原样保留（可随语序移动，但继续紧跟被标注的词）：
国外研究方面，Zawaideh[[FN0]]将BIM技术与可解释机器学习相结合，对高层建筑施工的成本、进度与碳风险进行了预测；Nguyen等[[FN1]]运用结构方程模型，分析了建设项目成本超支的多重成因。
第三步：写回文档。段落对象保持不动，清空段落内联内容，按占位符切分改写文本：文字段写入为新文本，[[FNn]] 处将原脚注引用（原 id）插回原样位置。保存时 Word 按引用出现顺序自动重排脚注编号（1、2、3……），页脚条目自动渲染，footnotes.xml 无需任何手工修改。
8.4 接口对占位符的保证
- 原样保留：不新增、不合并、不拆分、不改写占位符本身；
- 位置语义保持：占位符可随语序调整移动，但继续紧跟被标注的词；
- 重复以首次为准：同一编号重复出现时，以第一次出现为准；
- 无感处理：不含占位符的段落就是普通文本，无需任何特殊处理。
实测 5000 次改写，占位符保留率 99.8%。极小概率丢失时的兜底建议：写回时把对应脚注引用追加到该段落末尾——脚注条目本身永不丢失，最坏只是引用位置退化为段尾。
8.5 常见语言的处理方法
本机制只依赖 OOXML 规范，任何能操作 docx 的技术栈都可以实现同一流程：
| 语言 / 库 | 提取与写回要点 |
|---|---|
| C# / Aspose.Words | 遍历段落子节点，取 Run 文本与内联 Footnote 节点并落占位符；写回时清空段落内联内容，按占位符切分插入新文本与原 Footnote 节点。可直接读写 .doc，无需格式转换 |
| C# / OpenXML SDK | 遍历 w:p 子元素，在 FootnoteReference 处落占位符；写回时重建 Run 与 FootnoteReference。条目在 FootnotesPart，全程不动 |
| Java / Apache POI (XWPF) | 遍历 XWPFParagraph.getRuns()，将 run 中的脚注引用替换为占位符；写回时用 XWPFRun 重建文本并在占位符处插入原引用 |
| Java / docx4j | 与 OpenXML SDK 流程一致：按占位符处理 w:footnoteReference，FootnotesPart 不做修改 |
| Python / python-docx | python-docx 没有高层脚注 API，需用 lxml 遍历 paragraph._p 的子元素，在 w:footnoteReference 处落占位符；写回时按占位符切分重建子元素 |
| JavaScript / Node.js | 可用 jszip 直接读写 OOXML 包：解析 word/document.xml，将 w:footnoteReference 替换为占位符，条目文件 word/footnotes.xml 不动 |
尾注（
endnotes.xml）与批注（comments.xml）和脚注结构相同——正文放引用、条目集中存储，适用同一占位符策略。.doc的差异只在各技术栈的读写支持：python-docx 与 OpenXML SDK 不支持.doc，Apache POI 的 HWPF 模块支持有限；这些技术栈的通行做法是先转.docx→ 执行改写 → 再转回.doc，占位符机制作用于中间的.docx阶段，不受影响。Aspose.Words 可直接读写.doc，无需格式转换。
9. 获取帮助
- 微信：GDDMDD
- 提供
request_id便于问题排查