电信个性化并不只是让模型写一段更亲切的营销文案。它需要把套餐、用量、账单、漫游需求和客户流失信号组合起来，在合适的渠道给出可执行建议。Circles 将 OpenAI API 用于 AI 原生的电信体验，并通过 Codex改善开发流程；其披露的结果包括 ARPU（每用户平均收入）提升 22%、客户流失率降低 9%，以及开发效率提高。
从用户分群转向动态决策
传统电信营销通常依赖静态标签，例如“高流量用户”或“近期可能流失”。这类标签适合批量活动，却很难解释用户此刻为什么需要某个套餐。
接入大模型后，系统可以把结构化事实整理成自然语言建议：
- 用户连续两个月接近流量上限，可以比较加购流量包与升级套餐的成本。
- 用户即将出境，可以提前展示目的地适用的漫游选项。
- 用户近期频繁咨询账单，可以优先解释费用变化，而不是继续推销。
- 用户出现流失信号时，可以根据服务记录生成挽留建议，但优惠资格仍由业务规则决定。
关键边界是：模型负责理解上下文和生成表达，计费、资格、价格与合规判断仍应由确定性系统执行。否则，一段听起来合理的回复可能包含不存在的套餐或未经批准的折扣。
一条可控的个性化链路
面向生产环境，可以把流程拆成五步：
- 数据服务提取最少必要的用户特征，不把完整账单或身份资料直接交给模型。
- 规则引擎筛选真实存在且用户有资格购买的产品。
- OpenAI API 根据用户状态和候选产品生成推荐理由与渠道文案。
- 应用层校验输出结构、产品编号、价格和禁用措辞。
- 实验平台记录曝光、接受、投诉、退订和后续留存，而不只统计点击率。
这种设计把模型限制在“候选集合内做解释与排序”。即使模型调用失败，系统也能退回规则推荐或人工客服流程。
可以这样实践：生成受约束的套餐建议
下面是一个可运行、可改造的 Python 示例。它不代表 Circles 的具体内部实现，而是演示如何只向模型提供匿名化特征和已经通过规则筛选的候选套餐。
运行前安装 SDK，并设置 API 密钥。模型名称可通过 OPENAI_MODEL 调整：
python -m pip install --upgrade openai
export OPENAI_API_KEY="your-api-key"
export OPENAI_MODEL="gpt-4.1-mini"
创建 recommend_plan.py：
import json
import os
from openai import OpenAI
client = OpenAI()
customer_context = {
"customer_ref": "anon-7f31",
"current_plan": "basic-20gb",
"monthly_usage_gb": [18.4, 21.2, 19.8],
"roaming_trip_next_30_days": True,
"support_contacts_last_90_days": 1,
}
# These candidates should come from the telco catalog and eligibility engine.
eligible_offers = [
{
"offer_id": "plus-40gb",
"monthly_price": 39,
"features": ["40 GB data", "5 GB roaming data"],
},
{
"offer_id": "travel-addon-7d",
"one_time_price": 15,
"features": ["7-day roaming pass", "3 GB roaming data"],
},
]
prompt = f"""
You are a recommendation component for a telecom application.
Use only the eligible offers supplied below. Never invent prices,
features, discounts, or eligibility rules.
Customer context:
{json.dumps(customer_context, ensure_ascii=False)}
Eligible offers:
{json.dumps(eligible_offers, ensure_ascii=False)}
Return JSON only with these keys:
- offer_id: one ID from eligible_offers
- reason: a concise customer-facing explanation
- confidence: a number from 0 to 1
- requires_human_review: true or false
"""
response = client.responses.create(
model=os.environ.get("OPENAI_MODEL", "gpt-4.1-mini"),
input=prompt,
)
result = json.loads(response.output_text)
valid_ids = {offer["offer_id"] for offer in eligible_offers}
if result.get("offer_id") not in valid_ids:
raise ValueError("Model returned an ineligible offer")
confidence = float(result.get("confidence", 0))
if not 0 <= confidence <= 1:
raise ValueError("Confidence must be between 0 and 1")
print(json.dumps(result, ensure_ascii=False, indent=2))
执行：
python recommend_plan.py
生产版本还应校验 JSON Schema、限制输出长度、过滤敏感内容，并为低置信度或高风险场景设置人工审核。推荐理由不能替代资费合同，最终页面应从产品目录重新读取价格和条款。
Codex 改善的是交付闭环
AI 原生体验不仅增加模型调用，也带来提示词、评测集、数据接口和安全策略等新代码。Codex 可以参与测试生成、接口改造、故障定位和重复性迁移，但开发效率不能只用“生成了多少代码”衡量。
团队可以把一个个性化功能拆成可验证的仓库任务：
任务：为套餐推荐服务增加资格校验。
约束：
- 模型返回的 offer_id 必须存在于 eligible_offers。
- API 超时后返回现有规则引擎结果。
- 日志不得记录电话号码、姓名或完整账单。
- 添加无效 offer_id、超时和空候选集测试。
验收：运行项目现有的格式检查、单元测试和类型检查，并报告结果。
这类任务给 Codex 明确的文件范围、行为约束和验收命令，比“优化推荐服务”更容易审查。生成的代码仍需经过代码评审、自动化测试和安全检查，尤其是涉及计费、身份认证和客户数据的模块。
上线时盯住业务结果与风险
Circles 披露的 ARPU 提升 22% 和流失率降低 9% 说明，生成式 AI 的价值可以落到电信业务指标上。但这些结果不应被直接当作其他运营商的预期收益；客户结构、产品目录、实验周期和归因方法都会影响结果。
落地前可以检查以下事项：
- 推荐只能引用实时产品目录中的价格、权益和资格。
- 输入数据经过最小化、脱敏，并符合当地的数据驻留与隐私要求。
- 建立离线评测集，覆盖错误资费、虚假优惠、敏感推断和不当挽留话术。
- 在线实验同时观察 ARPU、流失率、投诉率、退订率和人工转接率。
- API 不可用或输出校验失败时，有规则引擎或人工服务兜底。
- Codex 生成的变更必须通过与人工代码相同的评审和发布门禁。
真正可持续的个性化系统，不是让模型自由决定卖什么，而是让它在可信数据、明确候选项和可审计规则之间，帮助用户更快理解哪种选择适合自己。