年入1亿美元的AI理财App靠“会吐槽用户乱点外卖”出圈我们从产品和技术两个维度拆解最近不少做AI应用的朋友都在讨论一个现象市面上很多AI理财工具还在比拼收益率预测谁更准、K线画得谁更漂亮却有一款产品靠着“用户乱点外卖被AI吐槽”这种反常识的交互方式火了起来而且年收入已经突破1亿美元。这里先给出一个明确判断这款产品的核心价值不在“吐槽”本身而在于它把AI从“决策辅助工具”变成了“行为干预工具”。传统理财App告诉用户“你应该存钱”这款AI理财App直接指出“你上周花了328元点外卖其中有3单是深夜下单比你的健身预算还高”然后基于用户的实际消费数据给出可执行的调整建议。这种从“分析”到“干预”的转变才是它能在AI理财赛道跑出来的根本原因。如果你正在做AI Agent、金融类App、或者任何与“用户行为分析个性化推荐”相关的产品这篇文章会从产品设计和技术实现两个维度把这类AI理财App的架构拆开讲清楚。文章包含可落地的代码示例、数据模型设计、触发策略配置和A/B测试思路即使你手头没有金融数据也可以用一个最小示例完整跑通这套流程。1. 这篇文章真正要解决的问题先泼一盆冷水大多数AI理财产品的失败不是死在模型精度上而是死在“用户根本不打开App”。为什么因为传统理财产品的交互逻辑是“低频严肃”。用户一个月打开一次App看一眼收益率然后关掉。这种模式决定了AI再强用户感知不到。而这款年入超1亿美元的产品把理财从一个“月度任务”变成了“日常对话”。用户每天都会收到AI对自己消费行为的反馈有表扬、有吐槽、有建议像是一个懂财务的朋友在帮忙盯账本。这篇文章要解决的核心问题有三个第一这类AI理财App的“吐槽”功能背后技术架构到底是什么样的它不只是接一个大模型API那么简单而是涉及消费数据的结构化处理、触发规则引擎、大模型生成话术、用户反馈闭环等多个模块。第二为什么“会吐槽”比“会计算”更能让用户留下来这里涉及行为经济学中的损失厌恶和即时反馈机制但从技术角度看它其实是一个基于事件驱动的用户干预系统。第三作为开发者如果我们要做类似的产品最小可用版本应该怎么搭建需要哪些数据、哪些模型、哪些触发策略这套设计思路不仅适用于理财也适用于健身、学习、时间管理等所有需要“行为改变”的赛道。读完这篇文章你会得到一套完整的方案而不是零散的知识点。2. 核心概念AI理财App为什么不只是“聊天算账”要理解这类产品的架构先要澄清几个关键概念。2.1 从“分析型AI”到“干预型AI”传统金融科技产品中的AI本质上是在做“分析”分析用户的风险偏好、分析市场走势、分析资产配置是否合理。分析的结果是一份报告需要一个专业用户去理解和执行。而这款AI理财App的特点是做“干预”它直接对用户的消费行为给出反馈。用户点了一份不合理的外卖AI会说“这笔消费超出了你本月的餐饮预算如果要坚持月底的旅行计划建议明天减少一次奶茶下单”。这种干预发生在消费决策的当下而不是月底复盘的时候。从技术架构上看分析型AI是“离线的、批处理的、推荐式的”干预型AI是“实时的、事件驱动的、对话式的”。这决定了系统的组件完全不同。2.2 事件驱动的用户干预系统这类AI理财App的核心不是自然语言处理而是事件驱动架构。它需要监听用户消费行为产生的事件把这些事件转化为结构化数据再根据预设的规则决定是否需要触发一次AI干预。一个完整的事件驱动干预系统包含以下环节用户消费行为 → 数据采集 → 事件总线 → 规则引擎 → 大模型生成话术 → 用户反馈 → 效果回收每个环节都有独立的组件可以被替换和优化。规则引擎决定“什么时候需要吐槽”大模型决定“怎么吐槽”反馈回收决定“吐槽是否有效”。2.3 “吐槽”不是目的而是触发用户反思的手段这里需要澄清一个容易误解的地方吐槽本身没有产品价值。它的价值在于用一种用户能接受的方式让用户意识到自己的消费行为和目标之间的差距。所以好的AI吐槽必须具备三个特征基于事实不是凭空说教。AI必须引用具体的消费记录比如“昨天23:17你在某外卖平台下了一单”。关联目标不是单纯指责。AI需要把单次消费和用户的长期目标联系起来。给出替代方案不是只说不许。AI需要告诉用户接下来怎么做可以改善财务状况。达不到这三个特征的“吐槽”只会让用户觉得被冒犯。这是很多模仿者做失败的主要原因。2.4 这类产品适合和不适合的场景从材料来看这款产品的场景非常聚焦面向有稳定收入、有理财意愿但缺乏自律的年轻用户。它的核心场景是“日常消费提醒月度预算管理储蓄目标跟踪”。适合的场景有三类月光族用户的储蓄习惯培养。旅行、购物等短期目标的资金规划。订阅服务、外卖、打车等高频小额消费的异常提醒。不适合的场景也有三类专业投资者的复杂资产配置。企业级财务管理和税务规划。高风险投资产品的推荐和交易。3. 环境准备与前置条件在开始搭建一个最小可用的AI理财App原型之前需要明确技术选型。这里给出一个成本最低、最容易上手的方案。3.1 运行环境操作系统Windows 10/11、macOS 12 或主流Linux发行版。Python版本3.9以上本文测试环境为3.11版本差异不大时可以兼容运行。数据库SQLite作为开发环境存储生产环境建议替换为PostgreSQL或MySQL。如果你使用的是其他语言栈比如Java或Go核心思路完全一致只是代码实现需要对应调整。本文以Python为例因为Python在处理数据分析和调用大模型API时生态更完善。3.2 依赖库需要安装以下Python库pip install flask sqlalchemy openai pandas python-dotenv各库的用途说明flask提供轻量级Web服务用于模拟接收消费数据的接口。sqlalchemyORM框架管理数据模型和数据库迁移。openai调用大模型API生成吐槽和理财建议话术。pandas对消费数据进行聚合分析生成统计特征。python-dotenv管理配置文件中的密钥避免硬编码。如果你的网络环境无法直接访问OpenAI服务可以替换为国内合规的大模型API接口格式兼容OpenAI规范即可。本文代码在调用大模型的地方做了抽象方便替换。3.3 获取模拟消费数据由于涉及真实用户的消费数据属于个人隐私本文不会使用任何真实数据。我们可以通过Python脚本生成一份模拟数据包含用户ID、消费金额、消费类别、消费时间和消费平台。生成模拟数据的代码如下直接复制到项目根目录下的generate_data.py文件# 文件路径generate_data.py import random import sqlite3 from datetime import datetime, timedelta categories [外卖, 交通, 购物, 娱乐, 学习, 医疗, 住房, 转账] platforms [美团, 饿了么, 滴滴, 淘宝, 京东, 支付宝, 微信支付, 线下刷卡] def generate_data(user_id, days30): conn sqlite3.connect(finance.db) cursor conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS transactions ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, amount REAL NOT NULL, category TEXT NOT NULL, platform TEXT NOT NULL, created_at TEXT NOT NULL ) ) now datetime.now() for i in range(days * random.randint(3, 8)): created_at now - timedelta(daysrandom.randint(0, days), hoursrandom.randint(0, 23), minutesrandom.randint(0, 59)) amount round(random.uniform(8, 500), 2) category random.choice(categories) platform random.choice(platforms) cursor.execute( INSERT INTO transactions (user_id, amount, category, platform, created_at) VALUES (?, ?, ?, ?, ?), (user_id, amount, category, platform, created_at.strftime(%Y-%m-%d %H:%M:%S)) ) conn.commit() conn.close() print(f已为用户 {user_id} 生成 {days} 天的模拟消费数据) if __name__ __main__: generate_data(user_001, days30)运行这个脚本python generate_data.py执行成功后当前目录下会出现一个finance.db的SQLite数据库文件里面包含一个用户的30天模拟消费记录。4. 核心流程拆解从消费数据到AI吐槽现在开始拆解这套系统的核心流程。虽然表面上看起来只是“读到数据-调用大模型-返回话术”但实际工程实现中每个环节都有独立的设计要点。4.1 第一步消费数据的结构化采集AI理财App和普通聊天机器人的最大区别在于它需要处理“结构化数据”而非“对话文本”。用户的每一笔消费都需要被转换成一条包含用户ID、金额、类别、平台、时间的结构化记录。这一步的常见做法有三种被动导入用户手动授权银行账单、支付账单系统通过API拉取数据后解析。主动申报用户手动录入每笔消费适合初期没有API权限的产品。自动监听用户安装插件或使用特定支付通道系统实时获取消费事件。从工程量上看第三种最优但需要和支付渠道谈合作。对于创业团队建议先做第一种和第二种的组合。4.2 第二步消费特征的提取与统计拿到原始消费数据后需要提取对理财建议有意义的特征。只靠大模型读原始账单是行不通的因为大模型的上下文窗口有限而且容易在大量数据中丢失关键信息。需要用统计方法把原始数据压缩成特征向量。典型的特征包括本月餐饮类消费总额和日均值。夜间消费22点到次日6点的笔数和金额占比。高频小额消费单笔小于30元的次数统计。各消费类别的占比和环比变化。储蓄率收入减去总支出后的比例。这一步用Python实现如下保存为feature_engine.py# 文件路径feature_engine.py import sqlite3 import pandas as pd def load_transactions(user_id): conn sqlite3.connect(finance.db) df pd.read_sql_query( SELECT * FROM transactions WHERE user_id ?, conn, params(user_id,) ) conn.close() return df def extract_features(df): features {} total df[amount].sum() features[total_expense] round(total, 2) # 按类别统计 category_sum df.groupby(category)[amount].sum() features[top_category] category_sum.idxmax() features[top_category_amount] round(category_sum.max(), 2) # 夜间消费统计 df[hour] pd.to_datetime(df[created_at]).dt.hour night_df df[(df[hour] 22) | (df[hour] 6)] features[night_count] len(night_df) features[night_amount] round(night_df[amount].sum(), 2) # 高频小额消费 small_df df[df[amount] 30] features[small_count] len(small_df) # 日均支出 days df[created_at].nunique() features[daily_avg] round(total / max(days, 1), 2) return features if __name__ __main__: df load_transactions(user_001) features extract_features(df) for key, value in features.items(): print(f{key}: {value})运行特征提取脚本python feature_engine.py输出的特征数据就是后续规则引擎和大模型的输入。4.3 第三步规则引擎决定是否触发吐槽很多开发者会跳过规则引擎直接把所有特征都发给大模型让大模型决定说什么。这种做法有两个问题一是成本高每次调用都要消耗token二是不可控大模型可能会对正常的消费行为做出过度反应导致用户觉得被冒犯。更稳妥的做法是先用规则引擎做一层过滤。规则引擎的作用是判断当前时间点是否需要对这个用户发起一次AI干预。规则引擎的核心代码实现# 文件路径rule_engine.py class RuleEngine: def __init__(self, rules_config): self.rules rules_config def evaluate(self, features): triggered_rules [] # 检查外卖类消费占比过高 if features.get(top_category) 外卖 and features[top_category_amount] 800: triggered_rules.append(外卖消费过高) # 检查夜间消费笔数过多 if features.get(night_count, 0) 5: triggered_rules.append(夜间消费频繁) # 检查小额高频消费过多 if features.get(small_count, 0) 15: triggered_rules.append(小额消费过多) return triggered_rules规则文件可以独立管理放在config/rules.json中{ rules: [ { name: 外卖消费过高, condition: top_category 外卖 and top_category_amount 800, action: warn, message_template: 本月外卖支出 {top_category_amount} 元超过预算建议减少高频外卖。 }, { name: 夜间消费频繁, condition: night_count 5, action: warn, message_template: 最近有 {night_count} 笔夜间消费总计 {night_amount} 元。夜间消费通常属于冲动消费建议睡前不要打开购物App。 } ] }规则引擎的价值在于可解释、可配置、可灰度。产品运营可以直接修改JSON规则而不需要改代码。这一点在工程实践中非常重要后面最佳实践部分会再展开。4.4 第四步大模型生成个性化话术当规则引擎判定需要触发干预后系统会把特征数据和触发规则作为上下文交给大模型生成最终话术。这一步要注意的是大模型不应该自由发挥生成虚假数据。为了让AI“吐槽”有据可依需要在提示词中把消费特征数据作为强约束传入。# 文件路径ai_advisor.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL) # 支持替换为其他兼容OpenAI规范的API ) def generate_advice(features, triggered_rules): prompt f 你是一个贴心的AI理财助手。以下是用户最近一个月的消费特征 总支出{features[total_expense]}元 最大支出类别{features[top_category]}花费{features[top_category_amount]}元 夜间消费笔数{features[night_count]}笔金额{features[night_amount]}元 小额高频消费次数{features[small_count]}次 日均支出{features[daily_avg]}元 系统检测到以下需要提醒的问题{, .join(triggered_rules)} 请用自然、友好的语气给出建议。要求 1. 必须先引用具体数据让用户感觉到AI真的在看他的账单。 2. 语气可以略带调侃但不要羞辱用户。 3. 每条建议必须包含一个可执行的改进动作。 4. 总字数控制在120字以内。 response client.chat.completions.create( modelos.getenv(MODEL_NAME, gpt-4o-mini), messages[ {role: system, content: 你是一个注重隐私和财务健康的理财助手。}, {role: user, content: prompt} ], temperature0.7, max_tokens300 ) return response.choices[0].message.content这里把API地址和模型名称都放到了环境变量中方便替换。在项目根目录创建.env文件OPENAI_API_KEY你的密钥 OPENAI_BASE_URLhttps://api.openai.com/v1 MODEL_NAMEgpt-4o-mini如果使用国内合规大模型服务只需修改OPENAI_BASE_URL和MODEL_NAME代码本身不需要改动。4.5 第五步效果回收与策略迭代最后一步是最容易被忽视的系统必须记录用户对AI建议的反馈。用户是否查看了建议是否修改了后续的消费行为这些数据会反哺规则引擎的阈值设置。例如如果规则引擎连续三天提示“外卖消费过高”但用户没有任何行为改变可能说明提醒频率过高导致用户免疫了。这时候系统应该降低频率或者换一种更有冲击力的表达方式。5. 完整示例搭建一个最小可用的Demo系统下面把前面几节的模块整合起来搭建一个完整的Demo系统。这个系统可以接收模拟消费数据自动分析特征触发规则并调用大模型生成个性化理财建议。5.1 项目结构先看整体目录结构ai-finance-advisor/ ├── app.py # Flask入口接收消费数据并返回AI建议 ├── generate_data.py # 生成模拟消费数据 ├── feature_engine.py # 特征提取 ├── rule_engine.py # 规则引擎 ├── ai_advisor.py # 大模型调用 ├── config/ │ └── rules.json # 规则配置 ├── .env # 环境变量 └── finance.db # SQLite数据库运行generate_data.py后生成5.2 Flask接口实现创建app.py把整个流程串联起来# 文件路径app.py from flask import Flask, request, jsonify from feature_engine import load_transactions, extract_features from rule_engine import RuleEngine from ai_advisor import generate_advice import json app Flask(__name__) # 加载规则配置 with open(config/rules.json, r) as f: rules_config json.load(f)[rules] rule_engine RuleEngine(rules_config) app.route(/api/advice/user_id, methods[GET]) def get_advice(user_id): # 1. 加载用户消费数据 df load_transactions(user_id) if df.empty: return jsonify({error: 该用户暂无消费数据}), 404 # 2. 提取特征 features extract_features(df) # 3. 规则引擎判断是否需要干预 triggered_rules rule_engine.evaluate(features) if not triggered_rules: return jsonify({ user_id: user_id, need_intervention: False, message: 你的消费情况整体健康继续保持。 }) # 4. 调用大模型生成话术 advice generate_advice(features, triggered_rules) return jsonify({ user_id: user_id, need_intervention: True, triggered_rules: triggered_rules, features: features, advice: advice }) if __name__ __main__: app.run(host0.0.0.0, port5000, debugTrue)5.3 运行和测试启动服务python app.py打开另一个终端访问接口curl http://127.0.0.1:5000/api/advice/user_001如果一切正常你会看到类似下面的返回结果。注意由于模拟数据是随机生成的每次返回的数值会不同但结构保持一致{ user_id: user_001, need_intervention: true, triggered_rules: [外卖消费过高, 夜间消费频繁], features: { total_expense: 4521.35, top_category: 外卖, top_category_amount: 1240.5, night_count: 7, night_amount: 386.2, small_count: 18, daily_avg: 150.71 }, advice: 你本月外卖支出1240.5元占总支出约27%比预算高了440元。最近7笔夜间消费合计386.2元大多是深夜下单。建议把外卖App从手机首屏移走设置每周三为自带便当日预计每月能省下500元左右。 }5.4 判断成功标准这个Demo跑通的标准有三个第一接口返回的need_intervention字段会根据数据动态变化。如果某个月用户消费非常克制没有触发任何规则回复就是“消费健康”。第二advice字段中引用的具体数字必须和features中的统计一致。这说明提示词约束生效大模型没有编造数据。第三多次请求相同user_id返回结果基本一致说明系统是“先规则后模型”的确定性流程而不是大模型随意发挥。6. 运行结果与效果验证跑通Demo只是第一步。如果这个系统要真正上线还需要建立一套完整的验证机制。6.1 功能层面验证从功能层面看至少需要测试四类场景场景测试数据预期结果正常消费日均支出在预算内不触发干预返回“消费健康”外卖超额外卖消费超过800元触发“外卖消费过高”规则AI给出建议夜间消费连续多笔深夜消费触发“夜间消费频繁”规则AI提示冲动消费新用户无数据数据库中没有记录返回404错误提示引导用户授权账单测试方式可以通过修改generate_data.py中的随机参数来构造不同场景。6.2 业务指标层面验证上线后的A/B测试是关键。这里给出一组建议的测试方案对照组用户使用不带AI提醒功能的普通账单查询页面。实验组A用户使用带规则引擎提醒但大模型只做简单模板填充。实验组B用户使用完整的规则引擎大模型个性化话术。核心观察指标不是“用户看了几条提醒”而是“用户在下一周期的储蓄率变化”。6.3 验证失败怎么办如果发现实验组用户卸载率上升首先要检查的是“吐槽”的语气是否过于冒犯。一个有效的排查方法是把AI生成的话术拿出来让没有看过产品的同事打分从1到5评价“是否觉得被羞辱”。低于3分的话术需要重新调整提示词。其次要检查的是触发频率。如果一个用户一周内收到超过3次同类提醒大概率会关闭通知权限。规则引擎中需要增加“频率控制”模块同一个规则在48小时内只触发一次。7. 常见问题与排查思路在实际开发和上线过程中下面几个问题出现频率最高。问题现象可能原因排查方式解决方案大模型返回的金额和账单不一致提示词中没有强制约束必须引用给定数据检查生成的提示词确认特征数据是否作为上下文传入在提示词中明确要求“只能引用给定数据不得推测”AI话术过于生硬像模板温度参数设置过低模型输出过于保守检查openai.chat.completions.create的temperature参数适当提高到0.7-0.9同时增加示例话术用户觉得被冒犯卸载App吐槽语气过重或者触发频率过高回收用户反馈数据查看卸载前最后收到的AI话术调整提示词在系统级增加“温和模式”接口响应慢用户体验差每次请求都调用大模型API查看API调用耗时日志增加缓存层相同特征结果24小时内复用规则引擎误报严重规则阈值设置不合理分析触发规则的用户的真实消费行为根据历史数据调整规则条件引入动态阈值无法接入真实银行账单银行API权限和合规问题查阅银行开放平台文档先做用户手动导入和拍照识别再申请正式API权限针对第一个问题这里给出一个更稳妥的提示词写法def generate_advice_safe(features, triggered_rules): prompt f 以下是用户的消费统计数据 - 总支出{features[total_expense]}元 - 最大支出类别{features[top_category]}花费{features[top_category_amount]}元 注意 1. 你只能引用上面提供的数字禁止编造任何其他数字。 2. 如果上面没有问题直接回复“一切正常”。 3. 回复内容不能包含任何建议用户借贷、套现、赌博的内容。 response client.chat.completions.create( modelos.getenv(MODEL_NAME, gpt-4o-mini), messages[ {role: system, content: 你是严格遵守数据准确性的理财助手。}, {role: user, content: prompt} ], temperature0.3, max_tokens200 ) return response.choices[0].message.content8. 最佳实践与工程建议前面已经把Demo跑通了但真正上线还需要考虑很多工程细节。这里给出五条对实际业务最有帮助的建议。8.1 规则引擎与大模型的分工边界从材料中可以看出这类AI理财App最核心的技术经验是不要把决策逻辑全部交给大模型。规则引擎负责确定性判断大模型负责生成表达。这样做的好处有三点成本可控、结果可预期、运营可干预。具体来说规则引擎包含三个层级触发层判断是否需要干预。策略层决定用什么方式干预推送、弹窗、对话。频率层控制干预频率避免用户免疫。大模型只负责策略确定后的“最后一公里”——把结构化的决策结果转化为自然语言。8.2 数据隐私与合规边界金融数据是最敏感的个人数据之一。在开发这类App时有几个底线必须守住。第一用户授权一定要明确。接入银行账单、支付账单之前必须让用户阅读并同意隐私协议明确说明数据的用途和存储期限。第二数据存储要加密。生产环境数据库中用户ID、手机号等身份信息需要使用带密钥的字段级加密。第三脱敏处理。从外部渠道获取账单数据时对非必要的敏感字段进行脱敏只保留分析所需的类别、金额、时间。第四模型输出的限制。在提示词中加入禁止项约束大模型不得输出任何涉及借贷、套现、赌博等高风险理财建议。8.3 冷启动策略新用户没有历史消费数据AI没有办法做分析。这时候的交互策略应该是“先收集后分析”。可以在引导流程中让用户手动导入最近一个月的账单或者先通过问卷调查获取用户的收入区间、储蓄目标和消费习惯。冷启动阶段不要过早启用“吐槽”功能。一个没有历史数据支撑的吐槽只会让用户觉得是AI在乱说反而损害信任。8.4 可观测性与日志记录AI理财系统的每次“吐槽”都应该有完整的日志链路至少包含输入特征当时计算的消费特征快照。命中规则触发了哪条规则规则版本号是多少。模型调用提示词版本、模型版本、温度参数、返回内容。用户反馈用户是否查看了建议是否产生了后续行为。这些日志不仅用于排查问题更是后续优化提示词和规则阈值的核心依据。建议把所有日志同步到独立的日志分析平台方便产品经理和算法工程师一起协作。8.5 费用控制与性能优化大模型API调用是这类App最主要的运营成本。一个用户如果每天收到三条AI建议每个月光是API费用就可能超过产品收入。建议采用三层优化策略缓存相同特征和相同规则触发的结果在24小时内直接复用。降级当大模型服务不稳定或预算超限时自动切换到预设模板话术。批量用户日结报告等非实时场景使用离线批量任务生成避开高峰时段。9. 总结与后续学习方向回到开头的问题为什么一款“会吐槽用户乱点外卖”的AI理财App能年入超1亿美元不只是因为吐槽有趣而是因为这类产品完成了从“AI分析”到“AI干预”的产品范式升级。它通过事件驱动架构、规则引擎和大模型生成能力的组合把理财建议嵌入到了用户的日常消费场景中。当用户每次打开外卖App都能想起AI的提醒时产品的粘性和商业价值就自然产生了。如果你对这个方向感兴趣下一步可以沿着五个路径深入第一深入研究行为经济学中的损失厌恶和即时反馈机制理解为什么“点外卖时收到提醒”比“月底看报告”更有效。第二学习金融数据合规知识特别是个人金融信息保护的技术要求。金融领域的合规门槛比普通应用高一个量级。第三完善规则引擎的动态阈值能力通过机器学习方法根据用户历史行为自动调整触发条件而不是依赖人工配置的固定阈值。第四探索多模态交互方式比如通过Apple Watch等可穿戴设备实时提醒用户消费行为把干预延展到更多场景。第五关注国内大模型API的金融行业解决方案在模型能力和合规要求之间取得平衡。最后给一个落地建议如果你正在做AI理财或行为干预类产品先不要急着上大模型。用规则引擎定义一个“无AI版本”的产品把触发逻辑和用户反馈跑通再逐步迭代加入大模型生成能力。从材料看这款产品最有价值的也不是大模型而是它对用户行为数据的理解和干预策略的设计。把这一步走稳AI才有支撑。