Humanize Writing API:让AI文本读起来像人写的
Humanize Writing API 一次调用把 AI 文本改写成自然人味。$0.01/次,无需 prompt,附实测数据和代码示例。
发现这个 API,是因为我花了二十分钟改写一段文字,改完还是一股 AI 味。AI 生成的文本,问题不在于内容不对,而在于读起来不对:读者能感觉出来,搜索引擎也开始能判断了。而且,手动改写通常比从头写还慢。
Agent Body 的 Humanize Writing API 只需一次调用。发送一段文字,它会返回改写后的版本——意思和事实都不变,只是节奏、用词和句式经过调整,读起来自然多了。
SandBase 上的 Humanize Writing API——一个接口搞定文本自然化。
实测数据
我用刚发的一篇模型对比文章做了测试:原文在 GPTZero 上 AI 概率为 98%,经 API 处理一遍后,同一内容降到了 23%。意思完全没变,阅读体验却明显更好。
| 指标 | 处理前 | 处理后 |
|---|---|---|
| GPTZero AI 概率 | 98% | 23% |
| 语义保留 | — | ✅ |
| 事实变化 | — | 无 |
| 字数变化 | — | -8%(更紧凑) |
| 耗时 | 手动 20 分钟 | API 2 秒 |
使用方法
API 接收一个 text 字段,返回改写后的文本。没有复杂配置、不需要 prompt engineering、不需要选模型——一个端点、一个参数、一个结果。每次调用 $0.01,不限字数。
curl 示例
curl -X POST https://api.sandbase.ai/v1/run \
-H "Authorization: Bearer $SANDBASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "agentbody/humanize-writing",
"text": "你要改写的 AI 生成文本放在这里。API 会保留原意的同时让文字更自然。"
}'
Python 示例
import os
import requests
def humanize(text: str) -> str:
resp = requests.post(
"https://api.sandbase.ai/v1/run",
headers={
"Authorization": f"Bearer {os.environ['SANDBASE_API_KEY']}",
"Content-Type": "application/json",
},
json={
"model": "agentbody/humanize-writing",
"text": text,
},
)
resp.raise_for_status()
return resp.json()["output"]["text"]
result = humanize("AI 生成的文本放这里。")
print(result)
批量处理整篇文章
def humanize_article(markdown: str) -> str:
paragraphs = markdown.split("\n\n")
result = []
for para in paragraphs:
# 跳过代码块、标题、表格
if para.startswith("```") or para.startswith("#") or para.startswith("|"):
result.append(para)
continue
if len(para) < 30:
result.append(para)
continue
result.append(humanize(para))
return "\n\n".join(result)
SandBase 统一 API 接口——所有模型通过同一个 /v1/run 端点调用。
成本分析
对每天都要发文的团队来说,这改变了工作流程。以前每篇文章要花半小时手动去除 AI 味,现在可以在后处理环节逐段过一遍 API。一篇两千字的文章,成本大概两毛钱。
| 文章长度 | 段落数 | API 成本 | 节省时间 |
|---|---|---|---|
| 500 字 | ~5 | ¥0.35 | 10 分钟 |
| 1500 字 | ~15 | ¥1.05 | 25 分钟 |
| 2500 字 | ~25 | ¥1.75 | 35 分钟 |
| 每周 10 篇 | ~150 | ¥10.5 | 5 小时 |
每周十块钱省五小时人工,ROI 非常离谱。
质量评估
测试了 12 篇文章,大约 80% 的改写结果可以直接发布。剩下 20% 需要微调,通常是技术术语被过度简化了。
做得好的地方:
- 去掉填充短语(“值得注意的是”、“为了能够”)
- 句子长短交替(打破单调节奏)
- 把书面语换成口语化表达
- 在不丢失信息的前提下缩短字数
需要人工复查的:
- 不认识的技术术语可能被简化
- 很短的句子有时会被不该合并时合并
- 代码相关的表述(变量名、API 路径)可能被改动
集成到发布流程
# 1. 写文章(AI 辅助或手写)
# 2. 对正文段落跑 humanize
python3 humanize_article.py src/content/zh-CN/my-article.md
# 3. 看 diff
git diff src/content/zh-CN/my-article.md
# 4. 接受好的改动,回退不好的
# 5. 发布
关键:不要 humanize 所有内容。跳过代码块、表格、标题和技术规格。只处理叙述性段落。
通过 SandBase 的统一 /v1/run 端点,可以集成到任何内容管线中。
API 规格
| 字段 | 值 |
|---|---|
| Model ID | agentbody/humanize-writing |
| 端点 | POST https://api.sandbase.ai/v1/run |
| 认证 | Bearer token(SANDBASE_API_KEY) |
| 输入 | text(字符串,必填) |
| 输出 | output.text(字符串) |
| 执行方式 | 同步 |
| 价格 | $0.01/次 |
| 供应商 | Agent Body |
常见问题
支持中文吗?
支持。API 会保持源语言。发中文进去,返回中文改写。本文的多个段落就是用这个 API 润色后的。
每次调用最大文本长度?
没有文档限制,但建议每次 500 字以内效果最好。长文本逐段处理。
会改变事实吗?
不会。API 改写的是风格,不是内容。意思、数据和意图都保留。
能用于 SEO 内容吗?
可以——这是主要用途之一。AI 检测分数大幅下降,同时保持关键词相关性。
跟手动编辑比怎么样?
更快(每段 2 秒 vs 20 分钟)、更便宜($0.01 vs 编辑人力)。但不能替代最终的人工技术准确性审查。
在 SandBase 上试用:Humanize Writing API


