Python对接AI语音API实现电话告警通知：从零到一的完整实践

做运维监控和业务系统开发的这几年，我越来越觉得“及时通知”比“数据准确”更容易被低估。数据报错了可以慢慢排查，但如果是半夜线上服务挂了，报警邮件没人看、钉钉群没人回，等天亮才发现事故，那就已经晚了。后来我把目光转向语音通知接口，用Python脚本去对接AI语音API，让系统在关键时刻直接给值班人员打电话，把异常信息用语音播报出来。这篇文章我就把从零到一接入的完整过程、代码细节和踩过的坑都写出来，给正在选型或准备集成的开发者做个参考。

先交代一下这篇内容适合谁：主要面向有Python基础、想给自己的系统加上语音告警能力的人，比如运维工程师、后端开发、独立开发者、小团队的技术负责人。你不需要懂很复杂的语音算法，AI语音API已经把语音合成和电话拨打这些难活都封装好了，你要做的只是写好脚本、调好参数、处理异常。文章里的代码都是可以直接抄的，复制到项目里改改配置就能跑。

1. 为什么需要语音通知：先搞清楚这件事值不值得做

1.1 语音通知解决的痛点

很多人第一个反应是：通知方式不是很多吗？短信、邮件、企业微信、钉钉、App推送，哪个不能满足需求？我的经验是，通知方式越多，关键时刻越容易出问题。邮件的到达率没有保证，尤其是自建邮件服务器，一封告警邮件可能延迟十几分钟；企业微信和钉钉机器人确实好用，但如果值班人员手机开的是免打扰，消息一样会被吞掉；App推送就更不可控了，应用商店、厂商通道、手机省电策略都会影响送达。

语音通知不一样。它的核心逻辑是运营商直接发起一通真实电话，手机只要不是关机或者没信号，就会响铃。这个“打扰感”恰恰是它最大的价值。你深夜睡得正熟，邮件来了你听不见，但如果手机响了，潜意识里你就会拿起来看一眼。对这种强提醒能力，最合适的场景就是高优先级、低频率的告警：数据库主从切换、服务器CPU跑满、线上支付成功率突然下跌、机房断电，这些事件不需要频繁通知，但一旦发生就必须有人响应。

用生活化的类比来说，邮件是企业邮箱里的备忘录，微信是企业IM里的聊天记录，而语音通知是那个直接拨过来的电话。没人喜欢半夜接电话，但有事的时候电话往往最管用。语音通知不是用来替代其他通知方式的，它是把这些通道兜底的最后一道防线。我现在的做法是“分级通知”：低级告警走静默通道，高级告警打电话，只有吵到人，问题才不会被淹没。

1.2 为什么选Python脚本集成，而不是写个Java服务

技术选型上，我优先选了Python，理由很实际。第一是开发效率高，语音通知这个功能本质上就是把参数拼好、请求接口、处理响应，十几行代码就能把核心链路跑通，用Java写一套反而显得重。第二是脚本化部署简单，直接丢到一台机器上配合 crontab 就能定时运行，或者作为一个独立模块放到监控体系里，几乎不需要额外的服务框架。第三是Python在告警监控生态里已经很成熟，很多监控平台都支持通过脚本扩展通知渠道，Python正好能无缝接入。

另外，Python的异常处理和网络请求库足够健壮，对接第三方API时，requests 库的各种便利能力能省掉很多重复劳动。相比Node.js，Python的进程管理和运行环境更稳定，在服务器上常驻运行不容易出幺蛾子；相比Go，虽然Go性能更好，但是为了一个调用频率不高的语音通知接口专门维护一个Go项目，有点杀鸡用牛刀。本质上，语音通知脚本的瓶颈在网络和运营商侧，不在你的编程语言性能上，所以选开发效率最高、团队最容易维护的那个就行。

1.3 AI语音API的底层原理：呼叫是怎么通起来的

我第一次接触语音通知接口时也有点懵，以为要自己处理SIP协议、对接运营商线路，后来发现完全不用。市面上主流的AI语音API服务商，已经把整个链路封装成了非常简单的HTTP接口。

大致流程是这样的：你在系统里发起一次请求，把目标手机号、要播报的文字内容和相关配置传给服务商的接口；服务商拿到内容后会先做文本转语音（TTS），把文字转换成音频文件，这个过程现在的AI语音合成已经非常自然了，几乎听不出机器感；TTS完成后，服务商再通过运营商呼叫线路对你的手机号发起真实呼叫，你接起来后，系统会自动播放那一段合成音频；整个通话过程结束后，服务商会记录通话状态（接通、未接通、振铃时长、通话时长），并通过回调地址把结果推给你。

这就像你点外卖，不需要自己开餐厅，也不需要自己送外卖，你只需要在App里下单，餐厅做好饭、骑手送上门。AI语音API承担的是餐厅和骑手的角色，你要做的只是把订单（文本、号码、配置）下对。理解这个流程后就会发现，我们作为开发者的核心工作其实只有三块：把请求参数拼对、把签名算对、把回调接好。

2. 接入前的准备工作：账号、密钥与Python环境

2.1 开通服务、创建应用、搞定密钥

接这类语音API，第一步永远是去服务商控制台开通服务并创建应用。不要一上来就写代码，先花十分钟把控制台里的功能结构和文档看一遍。我用过的服务商流程大同小异：注册账号、完成实名认证、开通语音通知服务、创建应用后获得一组 AppID 和 AppKey，这组密钥是后续所有请求的身份凭证。

AppID 是公开标识，相当于你的用户名；AppKey 是私密凭证，相当于你的密码，绝对不能明文提交到代码仓库。我见过一些同事把密钥直接写死在Python文件里然后推到Git仓库，这个习惯非常危险，一旦仓库泄露，别人就能拿你的密钥随意调用接口产生话费。正确做法是把密钥放到环境变量、部署系统的密钥管理服务，或者至少放到独立的配置文件里并加入 .gitignore。

创建应用时，服务商一般会让你配置通知号码白名单。开发调试阶段我强烈建议至少添加一个自己的测试号码，很多服务商对白名单外号码的呼出是有限制的，或者需要额外审核。如果你不想在测试阶段频繁打扰团队成员，就用自己的手机号接收测试。另外，服务商基本上都要求语音通知内容经过模板审核，所以你在控制台里需要提前把所有要播报的文本模板提交审核，等审核通过后再调用。我一开始天真地以为能像发普通请求一样传任意内容，结果接口直接报错，审核机制是语音服务合规的一部分，尤其在面向公众号码呼出的时候必须走这个流程。

2.2 Python环境准备与依赖安装

环境方面，Python 3.8以上版本就足够了，我用的3.10。官方下载安装后，建议在项目目录下创建一个虚拟环境，避免依赖冲突。

mkdir voice-notify cd voice-notify python3 -m venv venv source venv/bin/activate pip install requests apscheduler flask

requests 用来发HTTP请求，apscheduler 用来做定时任务，flask 用来写接收回调的简单Web服务。如果你的项目里已经用了 Django、FastAPI，完全可以不需要 Flask，直接在现有框架里加一个回调路由就行。有些服务商提供了官方Python SDK，如果你不想自己拼请求，建议优先用官方SDK，避免签名和参数格式踩坑；但即便用SDK，我建议也理解一下底层签名逻辑，排查问题的时候会省很多时间。

编辑器我平时用VS Code，配合Python扩展就很舒服。你也可以用PyCharm，专业版对Flask调试支持得更直接。不过这些都不影响最终效果，选自己顺手的就行。

2.3 从文档里抓出四个关键信息

很多开发者拿到API文档后喜欢直接翻示例代码，跳着看，结果漏掉关键参数。我推荐一个高效的阅读方法：不管服务商文档写得多花哨，你只需要在文档里找到四个关键信息。

第一个是鉴权方式，也就是请求里怎么带签名或Token。最常见的模式是参数签名（MD5或HMAC-SHA256），也有不少服务商使用JWT。第二个是请求地址和请求方式，语音通知接口一般是POST JSON格式，地址形如 https://api.example.com/voice/notify。第三个是核心参数列表，重点看 phone、templateId、params、callbackUrl 这类的字段定义和限制，比如模板参数类型、号码格式要求。第四个是错误码表和回调事件字段说明，错误码表能帮你快速定位问题，回调事件字段告诉你通话完成之后平台会给你推什么数据。

建议把文档原文保存一份到本地，或者在项目目录里做一份更精简的接口速查文档。因为服务商的文档偶尔会改版，线上文档位置变动很容易，你不可能每次排查问题都重新翻一遍线上文档。我自己的做法是把关键说明和错误码复制到一个 Markdown 文件里，跟着项目走，后面谁接手都能快速上手。

3. 核心脚本实现：从零编写可复用的语音通知模块

3.1 签名算法详解：为什么需要签名

开始写代码前，必须先把签名机制讲透。语音通知接口属于收费接口，每一次调用都会产生真金白银的费用，所以服务商必须确认请求是合法的，签名的作用就是这个。通常的逻辑是：客户端把业务参数按一定规则排序拼接，再加上一个时间戳，拼上你的AppKey，然后用约定的哈希算法算出一段签名；服务端收到请求后，用自己保存的AppKey按同样的规则重新计算签名，两个签名一致才认为请求可信。

这个机制和家里门禁卡差不多，门禁卡里面有一个密钥信息，刷卡时把信息传给门锁，门锁校验通过才开门。听上去简单，实际写起来有几个坑：拼接顺序必须严格按文档要求来，通常是所有参数名按字典序升序排列再拼接成 key=value&key=value 的形式；JSON格式的参数需要先转成字符串再参与签名；中文内容在签名前编码处理要慎重，确保UTF-8编码一致，否则本地算出来的签名和服务器算出来的永远对不上。

我用一个兼容大多数服务商的示例来演示签名逻辑，这里用最简单的MD5方式：

import time import json import hashlib def generate_sign(params: dict, app_key: str) -> str: # 1. 过滤掉空值和sign本身 filtered = {k: v for k, v in params.items() if v not in (None, "") and k != "sign"} # 2. 按键名升序排列 sorted_keys = sorted(filtered.keys()) # 3. 拼接成 key=value&key=value 格式 raw = "&".join([f"{k}={filtered[k]}" for k in sorted_keys]) # 4. 加上AppKey作为最后盐值 raw_with_key = f"{raw}&key={app_key}" # 5. 计算MD5摘要 sign = hashlib.md5(raw_with_key.encode("utf-8")).hexdigest().upper() return sign

注意，不同服务商的拼接盐值方式不同，有的把AppKey放在最前面，有的放在最后面，有的不需要 &key= 前缀。所以这份代码只是一个通用模板，务必根据你自己服务商的文档微调。另外，很多服务商要求带上一个当前时间的 Unix 时间戳，防止请求被重放攻击，这也就要求你的服务器必须做时间同步，否则时间偏移太大，请求会被判定过期。

3.2 封装一个VoiceNotifyClient类

有了签名函数后，完整调用逻辑就好写了。我习惯把所有的语音通知逻辑封装成一个类，这样以后在项目的任何地方都能直接导入使用。下面这个示例没有依赖官方SDK，直接用 requests 实现，你可以完整抄下来，再根据自己的服务商参数调整。

import time import json import hashlib import requests class VoiceNotifyClient: def __init__(self, app_id: str, app_key: str, api_url: str): self.app_id = app_id self.app_key = app_key self.api_url = api_url def _generate_sign(self, params: dict) -> str: filtered = {k: v for k, v in params.items() if v not in (None, "")} sorted_keys = sorted(filtered.keys()) raw = "&".join([f"{k}={filtered[k]}" for k in sorted_keys]) raw_with_key = f"{raw}&key={self.app_key}" return hashlib.md5(raw_with_key.encode("utf-8")).hexdigest().upper() def send_voice_notify(self, phone: str, template_id: str, template_params: dict, callback_url: str = None, max_retry: int = 3): timestamp = str(int(time.time())) params = { "appId": self.app_id, "phone": phone, "templateId": template_id, "templateParams": json.dumps(template_params, ensure_ascii=False), "timestamp": timestamp, } if callback_url: params["callbackUrl"] = callback_url params["sign"] = self._generate_sign(params) for attempt in range(1, max_retry + 1): try: resp = requests.post(self.api_url, json=params, timeout=10) resp.raise_for_status() result = resp.json() if result.get("code") == 0: return result # 这里可以针对特定错误码决定是否重试 print(f"[第{attempt}次重试] 接口返回错误: {result}") except requests.exceptions.RequestException as e: print(f"[第{attempt}次重试] 网络异常: {e}") if attempt < max_retry: time.sleep(2 ** attempt) return None if __name__ == "__main__": client = VoiceNotifyClient( app_id="你的AppID", app_key="你的AppKey", api_url="https://api.example.com/voice/notify" ) result = client.send_voice_notify( phone="13800138000", template_id="TTS_123456", template_params={"username": "张三", "amount": "1250.50"}, callback_url="https://your-server.com/voice/callback" ) print(result)

这段代码里有几个我刻意加入的细节。第一个是超时时间，requests 请求务必设置 timeout，否则网络异常时脚本会一直卡住，引起更严重的问题。第二个是重试机制，语音通知接口偶尔会遇到网络抖动或者服务商瞬时繁忙，我做了最多3次退避重试，注意每次重试之间用 2 的指数递增方式等待，避免短时间内连续冲击接口。第三个是 templateParams 用 JSON 字符串传递，因为很多服务商要求模板变量以JSON字符串形式传，这里顺手做了 ensure_ascii=False，确保中文参数不会被转成 \uXXXX 导致播报内容异常。

3.3 回调处理：如何知道用户有没有接电话

语音通知接口通常是异步的。你发完请求，接口返回的只是“受理成功”，不代表电话已经打通。真正的通话状态（接通、拒接、振铃无接听、通话时长）是通过回调地址异步推送给你的。所以如果你想在电话挂断后做后续操作，比如记录告警恢复时间、发工单、二次确认，就必须处理好回调逻辑。

回调就是服务商往你配置的 callbackUrl 发一个POST请求，body里包含 callId、状态、振铃时长、通话时长等字段。业务上需要明白：回调请求参数同样需要验证签名，不能随便收到一个POST就信任它。你可以复用前面写的签名函数，但要特别注意，回调参数的拼接顺序和请求时是一样的，别搞混。

我写一个最小的Flask回调服务示例，帮你快速验证流程：

from flask import Flask, request, jsonify, abort import hashlib app = Flask(__name__) APP_KEY = "你的AppKey" def verify_callback_sign(params: dict) -> bool: sign = params.pop("sign", "") filtered = {k: v for k, v in params.items() if k != "sign"} sorted_keys = sorted(filtered.keys()) raw = "&".join([f"{k}={filtered[k]}" for k in sorted_keys]) raw_with_key = f"{raw}&key={APP_KEY}" expected = hashlib.md5(raw_with_key.encode("utf-8")).hexdigest().upper() return sign == expected @app.route("/voice/callback", methods=["POST"]) def voice_callback(): data = request.json or {} if not verify_callback_sign(data): abort(400, "签名校验失败") # 处理业务逻辑 print("收到回调:", data) # 服务商要求快速应答，避免重复推送 return jsonify({"code": 0, "message": "success"}) if __name__ == "__main__": app.run(host="0.0.0.0", port=5000)

这个回调服务要注意三个点：第一，收到回调后一定要尽快返回响应，一般服务商都要求1秒内应答，否则会认为推送失败并重复推几次；第二，业务处理逻辑要做幂等处理，因为服务商可能推送不止一次，你最好预留一个根据 callId 去重的机制；第三，不要在该POST请求里做耗时太长的任务，把后续通知、写库这些操作丢给消息队列或者异步线程处理。

3.4 定时告警脚本实战：结合监控系统自动拨打

封装好客户端之后，真正的实战场景来了。我这边最常用的场景是定时检查服务器上的关键服务，发现异常就自动拨打告警电话。下面是用 apscheduler 做定时任务、结合前面客户端的完整脚本。

import socket import shutil import datetime from apscheduler.schedulers.blocking import BlockingScheduler from voice_notify_client import VoiceNotifyClient client = VoiceNotifyClient( app_id="你的AppID", app_key="你的AppKey", api_url="https://api.example.com/voice/notify" ) def disk_usage_check(): hostname = socket.gethostname() threshold = 80 usage = shutil.disk_usage("/").percent if usage > threshold: client.send_voice_notify( phone="13800138000", template_id="TTS_DISK_ALARM", template_params={ "hostname": hostname, "usage": f"{usage:.1f}%", "time": datetime.datetime.now().strftime("%H:%M") }, callback_url="https://your-server.com/voice/callback" ) if __name__ == "__main__": scheduler = BlockingScheduler() scheduler.add_job(disk_usage_check, "interval", minutes=5) scheduler.start()

这套结构的好处是逻辑非常清晰，你只需要在函数里写清楚监控检查逻辑，一旦判定为异常，就调用 client.send_voice_notify 发起通话。定时触发不一定非得用 apscheduler，如果你有现成的监控平台，比如类Prometheus体系里的Alertmanager，完全可以把语音通知脚本作为Webhook接收端，只要监控告警发个POST过来，脚本解析后直接调语音通知。我两种方式都试过，独立脚本适合中小团队快速自助，接入监控平台适合已经有完整监控体系的团队。

4. 参数细节与性能优化：让脚本更稳健、更省钱

4.1 语音模板与播报参数的设计技巧

语音通知按通话时长计费的场景很常见，所以一篇播报内容控制在20秒以内是最合理的。太短的语音浪费一次电话接通机会，太长的语音浪费费用也容易让接听者不耐烦。这就需要在模板设计上下功夫。

模板变量那段文字要注意：人名、金额、时间这类动态内容，一定要给服务商在模板里留好点位。这种设计类似Python里的格式化字符串，但是服务商那边的实现方式更多是占位符替换。比如你设计一个模板：“您好，您的订单{orderId}因支付超时已被取消，如有疑问请在工作时间联系我们。”发布前你自己就要明确这些变量可能的值域，避免用户昵称超过一定长度导致播报截断。我遇到过最奇葩的问题是有个用户昵称特别长，TTS合成时把后面关键的“如有疑问请联系”整段截掉了，接电话的人根本不知道要干嘛。

另外，有些服务商允许你在请求里传语速、音量和播放次数。语速建议设置在舒适区间，不要太快，毕竟接电话的人可能刚被吵醒；音量可以稍微大一点，尤其给上了一定年纪的用户拨打时，声音清晰比音色优美重要得多。如果服务商支持重复播放模式，对于重要告警我建议设置播放两遍，一遍听不全还有机会再听一遍。

这里有一个参数对照表，是我自己的经验值，可以根据服务商的映射调整：

4.2 批量通知：用线程池控制并发，别一次性梭哈

有一次我在业务通知场景里要一次性给1000个人发语音提醒。一开始图省事直接写个for循环逐个同步调用，结果发现跑完一轮要接近20分钟。后来改成多线程，但是如果不加控制，瞬间并发太高容易被服务商限流，甚至出现大量呼叫失败。

正确做法是用线程池，把并发数限制在一个合理范围。服务商文档里通常会写明QPS限制，比如每秒最多5次请求，那你的线程池大小最好不要超过5，另外再配合一个请求间隔，把整体速率压到安全水位。

from concurrent.futures import ThreadPoolExecutor, as_completed def notify_one(phone): result = client.send_voice_notify( phone=phone, template_id="TTS_ORDER_NOTIFY", template_params={"orderId": "12345"}, callback_url="https://your-server.com/voice/callback" ) return phone, result all_phones = ["13800000001", "13800000002", "13800000003"] with ThreadPoolExecutor(max_workers=5) as executor: futures = [executor.submit(notify_one, phone) for phone in all_phones] for future in as_completed(futures): phone, result = future.result() print(f"{phone} 发送结果: {result}")

这个脚本跑完会打印每个号码的发送结果。批量场景下，建议对失败号码进行二次归集和重试，不要在这个主循环里无脑重试全部，因为大批量重试很容易把负载推高。我的策略是：第一次循环里只记录失败号码，等首轮跑完后再单独对失败列表做重试，每次重试间隔拉长一点。这样既能保证成功率和效率，又不会因为瞬时补偿请求导致新的限流。

4.3 费用控制与代码层面的保护

负责过这类接口的人都会明白，费用控制是第一优先级。语音通知是按分钟计费的，而且不少服务商设置了套餐有效期限，如果代码逻辑写错了，可能在几十秒内就把额度烧光。我在生产环境里遇到过两次由于测试环境误配，把几万条通知发出去的惨案，所以后来我强制要求代码里必须有两个安全机制。

第一个是配置一个全局开关，比如环境变量 VOICE_NOTIFY_ENABLED，只有值为 on 的时候才允许真正发起调用，否则打印一条日志就跳过。这个开关在灰度调试阶段特别有用。第二个是白名单双保险，不仅在服务商控制台配置，也要在脚本里维护一个允许呼出的号码列表，任何不在列表里的号码直接拒绝调用。两个机制同时开着，即使配置错误或者被恶意触发，也有两道防线兜底。

这个思路看起来简单，但作用非常大。代码本身就是给人看的，越是能直接发起收费操作的代码，越应该把误触发的概率降下来。我宁可多做几个判断，也不愿意在结算账单的时候才意识到问题。

5. 常见问题与排查技巧实录

5.1 高频错误对照速查表

实际对接过程中，我整理了一张错误排查表，基本上覆盖了大部分新手会遇到的问题。遇到问题时直接对号入座，比自己翻代码快得多。

5.2 几个让我印象深刻的真实踩坑记录

第一个坑是签名拼接里的大坑：JSON参数序列化顺序。Python字典默认保留了插入顺序，但如果模板参数很多，不同环境或者不同代码路径下字典顺序可能有微妙差别。我排查了很久才发现，某一次调用里 templateParams 服务端解析出来的JSON字符串和本地签名用的字符串差了几个字段的顺序，导致签名一直失败。解决方案很简单，要么参与签名时使用固定的 key=value 拼接而不是整体对JSON字符串签名，要么先把JSON字典用 sort_keys=True 稳定序列化。

第二个坑是回调地址必须是公网可达。本地调试时我用 127.0.0.1 配置回调，结果服务商的回调请求全部失败，但接口本身没有任何报错。后来我用了内网穿透工具或者直接把回调地址指到一台有公网IP的测试机，问题才解决。真实生产环境里，你的服务器一般都有公网入口，但也要确认防火墙和Nginx是否放行了对应的POST路径。

第三个坑是服务商回调存在重复推送。刚开始我以为服务商最多推一次，结果有一次凌晨线上问题触发了告警，我的回调服务连续收到了七条相同的通知。后来我赶紧在回调处理逻辑里增加按 callId 去重的字典缓存，同时把业务处理改成幂等操作。这个问题不细看真发现不了，但对业务流程影响很大。

5.3 日志与可观测性：不要等到出事才后悔

把语音通知脚本跑起来之后，还要把日志做好。我建议至少有三个维度的日志：请求日志、回调日志、错误日志。请求日志记录每次调用时的号码、模板、请求参数和返回结果，方便排查“为什么没打电话”；回调日志记录通话状态、时长、回调参数，方便分析“打了电话但用户没接”；错误日志记录所有异常堆栈和错误码，方便定位代码问题。

我现在的做法是把日志统一打到标准输出，由部署环境统一收集。如果你只是单机部署，也可以用 Python 标准库 logging 打到文件里，但一定要配置日志轮转，否则文件会无限增长。代码里尽量别用 print 输出关键信息，因为生产环境里 print 的输出往往不稳定，也不方便按级别过滤。

日志信息要包含一个唯一标识，比如每次语音通知请求生成一个 requestId，后续回调里带上同样的 requestId，这样排查问题时就能把一次通话的“出生记录”和“通话结果”完整串联起来，省去大量猜测时间。如果你有过排查线上问题到怀疑人生的经历，你一定会认同：日志是系统最诚实的注释。

6. 脚本的后续扩展方向

接入语音通知只是第一步，这个能力扩展出去可以做很多有价值的事情。我现在除了告警通知，还用它做了服务状态查询，用户拨打电话后根据语音提示按键，就能查询订单状态；也做了无人值守场景的定时任务播报，每天早上把前一天的运营数据语音播给业务负责人，完全不需要对方主动打开报表。

我建议你做完基础集成后，可以往这几个方向考虑：把语音通知封装成微服务，提供给多个业务团队复用；对接企业内部IM机器人，让告警电话挂断后自动在群里生成工单；利用回调数据统计接通率和响应时长，反过来优化告警策略。事实证明，一套稳定可复用的语音通知服务，在团队里的价值远比想象中更大。

最后分享一下我个人的使用心得：语音通知接口并不是越频繁越好，每一次电话都意味着成本，也意味着对接收者的打扰。用好它的关键在于克制，只在最关键的时候拨打，把短信和IM用来处理普通事件，把语音留给真正需要叫醒人的场景。另外，脚本里所有可配置项，包括号码、模板、开关、重试次数，都应该能从环境变量或配置文件读取，别为了图一时省事硬编码在代码里。这样后续维护和交接，都会轻松非常多。