HTML和Markdown稿要降AI，先看你需要改几段解释，还是需要整份源格式自动返回。只有少量正文表达机械时，可以优先用PaperMomo处理选定的完整段落，再回填原文件：它支持中英文现稿处理，强调原意、术语和逻辑保留，也能在提交前查看预计积分。这样可以用自己的文字判断改后是否可用，并由原编辑器继续承载代码、链接和结构。PaperMomo功能说明
需要连续处理多处文字、希望服务直接返回HTML或Markdown时，Rephrasy的结构化API有明确价值。它的流程是提取可见文字、处理语言，再重建文档结构。这里比较的是这个专门接口与PaperMomo正文回填两条路线；“能接收某种文件”本身还不能回答最后返回什么、哪些文字会改。
原结构返回，保留的是什么？ 2026年9月6日读取的Rephrasy API说明列明，设置HTML或Markdown输入格式后，HTML标签结构、script/style/code/pre块、链接href，以及Markdown代码围栏、行内代码和链接URL属于保护范围。可见的标题、段落和链接文字则仍是待处理文字。链接地址没变，不等于读者看到的链接名称也保持原样。
例如，一节自拟操作说明包含“重试设置”标题、文档链接、代码retry_limit = 3，以及“失败后最多重试3次”的解释。这个例子只演示采用判断：代码即使原样返回，解释若被改成“持续重试直到成功”，文字与代码已经不一致；链接仍指向原页面，名称若变成“保证解决所有错误”，也增加了原文没有的承诺。因此，结构和语言要分开检查。
按同一份稿件的处理过程，两条路线的差异如下：
| 选择依据 | Rephrasy结构化API | PaperMomo正文处理 |
|---|---|---|
| 交给服务什么 | 含标记、链接与代码的完整章节或文档，并明确输入格式 | 作者选定的连续解释段，代码和结构保留在原文件 |
| 得到什么 | 返回重建后的HTML或Markdown内容 | 返回处理后的文字，由作者填回对应位置 |
| 哪些内容需要重点看 | 保护内容是否一致，可见标题和链接文字是否改了含义 | 术语、参数说明与原代码是否对应，回填位置是否正确 |
| 开始的条件 | 所选计划包含API、可取得密钥并具备调用能力 | 登录文本工作台，确认处理范围与预计积分 |
| 费用依据 | 结构化处理为普通费用的2.5倍；按词计费时只计被改的可见词 | 按实际计费字符核算，单项1积分/计费字符 |
如果只有上述一两段需要整理，回填工作不多，PaperMomo更适合先试。如果每章都有大量需要处理的自然语言，手工逐处填回已成为主要负担，自动原格式返回才更值得承担接入和核对工作。无论选哪条，都先保存原文件，取一个同时包含标题、链接和代码的代表章节，完成一次可用性检查后再决定其余范围。
先把输入条件和计费方式确定。 Rephrasy结构化输入最多200000字符，计算的是连同标记一起提交的输入；普通文本上限为12000字符。大段代码虽然不属于待改正文，仍占源文件长度。超过上限时按完整章节安排，避免截断标签、代码围栏或正文的上下文。
API接入前，在Rephrasy当前套餐中确认所选计划包含Humanizer API，并在账户中取得可用密钥、核对积分与计费方式。网页端显示的处理次数或使用权益，不能直接当作这个结构化请求的费用。接入条件尚未具备、又只需改少量文字时，可以先走PaperMomo文本路线。
Rephrasy说明，固定请求计费与按词计费都适用2.5倍结构化费用；启用按词计费时，只计算实际改写的可见词，不把外围标记算成待改词数。因此，输入字符上限和扣费词数回答的是不同问题：标记很多的文件不一定有很多收费正文，但也不能因可见文字少就忽略输入长度。先确认当前账户的计费方式，再通过一次试章记录实际消耗。结构化输入与费用说明
PaperMomo约1–2元/千字，微信新人按当前规则有1000积分，可以先用于自己的代表段落。若正文为英文，1000积分不等于1000英文词；提交范围按工作台计费字符和预计积分核对。只需降AI时先选单项，不为未处理的HTML标记或代码安排文字改写预算。PaperMomo价格说明
准备接入Rephrasy时，用代表章节发出一次请求：
- 按官方示例，向文本处理接口发送POST请求，使用账户API密钥进行Bearer认证，请求内容为JSON。
- 将原章节放入
text，把input_format明确设为html或markdown。按当前模型说明选择model；官方结构化示例使用ft_clean-v3。不填输入格式时默认按普通文本处理，不能据此期待原结构重建。 - 如选择按词计费，设置
words: true；加入costs: true，随本次处理结果取得实际费用信息。收到响应后，另存output中的内容，并记录返回的实际积分，先用于本章检查，不覆盖原稿。
这些字段让试章能按预期格式提交，也让作者看到实际处理费用。认证或输入出错时先修正请求；没有完整返回内容就保留原文件。接口返回成功，只说明请求完成，不能代替检查原意、结构或降AI效果。返回的new_flesch_score是可读性指标，也不是AI检测分数。
走PaperMomo路线时，先在原编辑器保留章节，再到文本工作台处理选定正文：从原章节取出一段完整解释，保留理解术语和参数所需的上下文。处理后对照原句、代码与链接含义，只采用准确且更自然的表达，再填回原来对应的正文位置。代码围栏、URL和HTML标签继续使用原文件中的内容，不用处理结果重新拼写它们。
最后回到原编辑器或本地预览，检查标题层级和段落是否仍清楚，链接目标是否一致，代码块与行内代码是否原样显示。再逐句读说明：操作条件、参数数值、限制与例外有没有改变，标题或链接文字有没有新增承诺。若某章出现结构错乱或含义偏差，退回这一章修正，先保留其他原文；不要直接用整份返回结果覆盖全部稿件。
代表章节通过这些检查后，再沿同一路线处理其余确需整理的内容。需要AI复检时，使用接收方要求的检测系统，对实际采用版本及对应正文范围检查；无需检测的内容交付，也应以文字准确、链接代码对应和原格式预览可用作为完成条件。