京东金融客户端用户触达方式的探索与实践

一、关于用户触达

用户触达:可以简单理解为通过某种方式将消息传递给用户的行为;触达的特定消息从功能上可分展示、引导落地两层。用户触达作为一种产品运营方式,已经融入我们日常生产活动的方方面面。在移动互联网的世界里,我们的产品离不开触达,用户活动也离不开触达。

二、为什么做用户触达

以用户使用角度来看,用户在使用 App 的过程中会有一些与用户相关的系统类的通知,比如交易物流、客服消息、账单信息,借还款提醒,实时资讯等消息需要及时的给用户提醒;

以 APP 运营活动看,App 在日常运营过程中,根据当前的目标,结合活动向用户定向发送相关营销类信息,比如单品的活动信息或一些品类促销优惠等,引导用户快速进入活动页面;

因此触达在拉新、促活、留存、变现、自传播等运营活动中扮演者重要角色。这篇文章从 app 研发视角介绍下用户触达方面的一些实践。

三、触达用户的方式实践

从 APP 的存活状态区分,实现触达有两种方式,一种是:APP 非活跃状态时的站外触达,主要包含:短信、Push、桌面小组件等

另一种是:APP 活跃状态时的站内触达,主要包含站内弹窗、页面固定运营位,feed 流推荐位等。

下面介绍下一下我们实现的几种触达方式及遇到的一些问题。

触达方式一:短信

短信起初应用最广泛的场景是作为我们交流沟通的一种方式,随着时代的发展微信、QQ 等即时通讯类的 app 逐渐代替了短信作为人与人沟通工具,但是由于短信能够及时稳定的将消息同步给用户的特点,它仍是我们现在使用比较广泛的消息触达方式。常见的应用场景如:验证码通知、还款提醒、账户变动、营销活动通知等。我们知道作为一种触达方式,它的使命不仅是将消息通知到用户,对于特定的消息还要能便捷的引导用户跳转到 APP 内的相应的落地页。

短信的消息触达能力是毋庸置疑的,虽然短信文本中直接放入的链接我们也可以打开,但是确存在一些局限性,这种方式仅支持打开 web 页面,无法跳转到 APP 原生页面,另外点击链接会先弹窗,由用户选择打开链接的 app,这种体验相比直接打开 APP 指定页面来说大打折扣。因此,如何通过短信直接到达 APP 内

相应的落地页就是我们需要解决的问题。google 提供了一种能使 Android 系统直接通过网站地址打开应用程序对应内容页面,而不需要用户选择使用哪个应用来处理网站地址的方式,即 Android App Links;其工作流程如下:

 要添加 Android App Links 到应用中,需要在应用里定义通过 Http (s) 地址打开应用的 intent filter,并验证你确实拥有该应用和该网站。

如果系统成功验证到你拥有该网站,那么系统会直接把 URL 对应的 intent 路由到你的应用。

1. 在 AndroidManifest 里配置用于系统进行验证的 IntentFilter:

当 android:autoVerify="true" 出现在你任意一个 intent filter 里,在 Android 6.0 及以上的系统上安装应用的时候,会触发系统对 APP 里和 URL 有关的每一个域名的验证。验证过程设计以下步骤:

系统会检查所有包含以下特征的 intent filter:Action 为
android.intent.action.VIEW、Category 为
android.intent.category.BROWSABLE 和
android.intent.category.DEFAULT、Data scheme 为 http 或 https

2. 配置一个数字资产链接的 Json 文件,声明你的网址和应用之间的关系;

对于在上述 intent filter 里找到的每一个唯一的域名,Android 系统会到对应的域名下查找数字资产文件,地址是:https:// 域名
/.well-known/assetlinks.json

只有当系统为 AndroidManifest 里找到的每一个域名找到对应的数字资产文件,系统才会把你的应用设置为特定链接的默认处理器。

数字资产示例:

package_name:在 build.gradle 里定义的 application ID

sha256_cert_fingerprints:应用签名的 SHA256 指纹信息,这个字段支持多个指纹信息,可以用来支持不同的应用版本,如开发版本和发布版本然后将 assetlinks 发布到 https:// 域名
/.well-known/assetlinks.json

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "xxx.xxx.xx",
      "sha256_cert_fingerprints": [
        "xx:xx...."
      ]
    }
  }
]

3. 跳转落地页

在配置了上述 intent filter 的 Activity 中解析 url,并执行跳转落地页等操作

4. 问题及排查方法

如果配置后点击短信的链接无法正常跳转,可以逐个排查相关配置是否正确

4.1 确认数字资产文件是否被正确地定义和发布:

https://digitalassetlinks.googleapis.com/v1/statements:list?

source.web.site=https:// 你的域名:可选的端口

&relation=delegate_permission/common.handle_all_urls

4.2 确认应用是否设置了正确链接处理方式:

adb shell am start -a android.intent.action.VIEW \

-c android.intent.category.BROWSABLE \

-d "http:// 你的域名:可选的端口"

4.3 检查链接策略

这一步需要在应用安装后,等待一段时间 10s 后再执行,因为应用安装后系统会请求解析配置表

执行:adb shell dumpsys package domain-preferred-apps 或 adb shell dumpsys package d

该命令返回了设备上每一个应用配置的列表,这个列表标明应用和网站之间的关联

App linkages for user 0:

Package: com.android.demo 代表应用包名

Domains: play.google.com market.android.com 网站域名,多个网站之间用空格分隔

Status: always : xxxx 表示应用在 Manifest 文件里的配置了 android:autoVerify="true" 状态为 always;后面的 xxxx 和验证是否成功无关,和系统中应用的配置记录有关;

4.4 解决机型兼容性适配问题

在实践过程中还发现各厂商的不同型号的设备上存在无法跳转到落地页的情况,经分析该机型上应用安装后系统请求解析配置表 assetlinks 过程失败,此时会使用系统默认浏览器打开落地页,落地页是 app 原生页面的无法跳转到落地页,对于需要登录的 web 页面,如果未在登录中心注册的也会跳转失败,并会重定向到 m.jd.com 。

解决方案:有问题的机型,使用统一下载页中转,下载页执行唤起 APP,APP 内处理跳转落地页逻辑。

触达方式二:Push 推送

1. 客户端推送方案

Google 为 Android 提供了 FCM 推送,但是因为网络服务等一些原因其可用性不佳;目前国内各厂商 rom 也都提供了免费的 push 推送接入能力,同短信比 push 由于其免费性极大地节约了触达成本。

同时国内也有一些三方推送服务供应商,我们结合京东金融自身业务特点,为了保障数据的安全性以及推送消息的服务质量,最终采取整合华为,小米,OPPO、ViVO、魅族各厂商推送能力与自建通道相结合的方案。

其中厂商推送特点:token 有效期内,用户杀死 app 可以接收到 push 消息;自建通道特点:app 启动后建立连接,接收 push 消息,杀死 APP 后收不到 push 消息,主要用于使用未适配的厂商设备如三星、努比亚等用户接收 push 消息。

各厂商在 push 方案的实现上大体相同(厂商 push 接入流程,下图以 MiPush 为例),在使用厂商推送的过程中我们也遇到了很多问题,因此了解了各厂商的特性是制定出良好的触达策略前提。

 2. 厂商推送遇到的问题

2.1 push 通知消息是否可以个性化展示

通常情况下通知栏消息展示效果主要内容包括消息标题、摘要、应用图标和时间。客户端可以自行定义具体展示内容。

不同厂商如华为、OPPO、vivo、小米、魅族等通知栏样式存在一些不同综合对比如下表:

 在通知展示的样式上,综合对比来看华为支持 inBox 的样式,OPPO 小米支持大图样式,可以通过这些特点定制出更有特色的通知展示形式来突出通知主题。

华为 inBox 样式:Inbox 样式将每行内容都当作独立的单行文本去展示。文本内容最多可展示 5 行,每行内容展示不了时后边自动添加 “...”

OPPO 小米支持大图样式:这种通知可以将更有吸引力的图片展示给用户

 2.2 App 有很多业务推送通知,用户是否可以指定接收分类消息

随着 APP 的业务越来越复杂,应用的通知越来越多,给用户造成明显打扰;

用户只能全局屏蔽这个应用的全部通知,不能屏蔽部分,然后留下对自己有用的。

为了解决这个问题,Android 8.0 开始支持开发者给自己的通知分成若干类,然后允许用户单独屏蔽这个类别的通知。

需要进行 Channel 分类,添加新 Channel(以 MiPush 为例):

ChannelHelper channelHelper = new ChannelHelper(APP_SECRET);
ChannelInfo channelInfo = new ChannelInfo.Builder()
        .channelId("id") //必填,通知类别的ID,长度不超过 200 字符
        .channelName("name") //必填,通知类别的名称,长度不超过40字符
        .channelDesc("desc") //可选,通知类别的描述,长度不超过300字符
        .notifyType(0) //必填,通知的效果类型,仅支持0,即振动、提示音、led灯三种效果都无
        .soundUrl("sound_url") //可选,通知的自定义铃声uri,格式介绍请参见 “4.1 自定义铃声”
        .build();
Result result = channelHelper.addNewChannel(channelInfo, 1)

不同的 channel 在系统设置页通知设置中展示如下:

 通过细分 push 通知的类别,增加通道数量可提高 push 消息在通知栏里的留存率;

同时用户可有更多选择,设置自己比较关注的类型消息,避免过多打扰,以提升用户体验。

2.3 如何指定推送方式或人群

各厂商推送方式支持方式如下:

2.3.1 基于 ReglD 的推送

RegID 为是推送 SDK 为每个设备上的每个 app 注册推送服务时生成的唯一标示。

当开发者需要给一个或多个具体的设备推送消息时,可以使用基于 RegID 的推送,将个性化的信息推送给指定的设备。这种方式适用于需要为每个用户订制个性化推送的场景。

2.3.2 基于 Alias 的推送

alias 是推送提供的一种个性化设定,开发者可以将用户在应用内的账号或其它用户唯一标识设定为用户设备 RegID 的别名,在推送中可以直接基于别名进行推送。

别名不仅方便开发者将推送与自有的账号系统进行关联,同时也避免了因需要保存设备 RegID 与自有帐号的对应关系而额外带来的开发和存储成本。

2.3.3 基于标签的推送

对应用下已订阅 push 的设置了标签的用户进行推送。在推送消息时,开发者可以结合每条消息的内容和目标用户人群,选择所对应的标签,完成请求后,push 推送服务会向所有

打上这一标签的用户发送该消息,从而满足定向推送的需求。并且提供标签管理功能。

2.3.4 小米通道 userAccount :最多可对应 20 台设备,单账号可登陆多台设备,给一个 userAccount 推送可同时有 20 台设备收到消息。

总结:将特定的推送消息通过特定的方式发送给比如不同的客户端版本、 不同地域、男女等的用户群体,或者通过给不同的用户群体打不同的标签的方式实现特性消息的推送,以达到更精细推送的目的。

2.4 OPPO、ViVO 触达成功率低,如何提升

触达数据接入数据看板后,经对比各厂商触达成功率发现 OPPO、ViVO 的触达率基本在 83%~86% 而小米华为通道触达成功率基本在 94%~98% 因此提升 OPPO、VIVO 通达的触达成功率是我们面临的又一问题

OPPO: 经排查发现影响 OPPO 触达率的主要因素为通知开关的状态:APP 仅在通知开关开启的情况下才能收到厂商的 Push 消息而 OPPO、一加通知开关在用户安装后默认关闭,因此收不到 Push 消息。

解决办法:前期主要是制定引导策略,在合适的时机检测通知开关状态,引导用户主动去设置页开启,后来经调研发现 OPPO 的 ColorOS 系统提供了一键开启通知开关的能力,后期使用引导一键开启方案,将 OPPO 通道的触达率提升到了 94% 左右;

VIVO: 与 OPPO 不同,VIVO 设备安装应用后通知开关是开启的,我们根据数仓提供的数据与厂商反馈的错误码分析,导致 VIVO 触达偏低主要因素为消息未进行分类而被限额。

vivo 通道消息类型分为两类 —— 按消息类型是否与用户强相关将消息分为 “运营消息” 和 “系统消息”,未接消息分类功能将导致所有消息默认为运营消息而受到频控限制,从而导致重要消息可能无法触达。

vivo 用户单应用每日运营消息接收条数上限 5 条,系统消息无限制。vivo 用户单应用接收条数限制以 “到达量” 是否超过 5 条为准,在发送时校验单用户是否到达 5 条,超限则计入管控量。

除 VIVO 外,华为、OPPO、小米对通知消息的数量 都有一定的限制,对于存在限额的厂商通道,将点击率高的个性化推送策略尽量安排在上午推送,可以保证优质推送内容的到达率;通过提高消息推送的额度,提高 push 消息的触达率。

2.5 如何增强未读消息提醒

可以在 App 桌面角标显示未读消息数,厂商 lunch app 和 push sdk 对此提供了相应的能力支持,用于增强提醒,各厂商的实现细节上有差异:

华为:角标未读数由服务端下发的 push 消息控制,开放了 api 供第三方应用设置角标未读数,移除通知栏消息角标数量不会变化。

小米:角标未读数等于厂商 push 通道(系统通知栏)收到的该 app 的未读通知数,开放 api 供第三方应用设置角标未读数。移除系统通知栏消息,角标数量相应减少。

oppo:支持红点,数字角标,角标未读数等于厂商 push 通道(系统通知栏)收到的该 app 的未读通知数。

vivo:桌面角标未读数开关默认关闭,需要用户手动开启才能使用,提供设置角标未读数的能力。

角标适配的问题及解决办法:

2.5.1 在小米系统上能展示通知数,但无法更新站内信数量。

解决方案:站内信和 push 打通,进入 app 时同步更新未读数。

2.5.2 在华为系统上无法显示 Push 数量,站内信数显示正常。

解决方案:华为推送服务提供了在服务端设置桌面角标 API 接口,第三方 app 可以在消息中封装角标参数。

2.5.3 vivo 手机上不支持显示角标未读数。

解决方案:更新 SDK 版本,接入角标能力

2.5.4 在 oppo 角标展示仅站内信数量。

push 功能在开通时可以申请圆点角标或数字角标、无角标三种形式,用户可以在通知设置中自主选择。

oppo push 支持的系统版本,目前支持 ColorOS3.1 及以上的系统的 OPPO 的机型,一加 5/5t 及以上机型,realme 所有机型(Android 8.0 以后的设备)。

2.5.5 其他:魅族手机未开放桌面角标设置。

触达方式三:站内横幅

1. 站内横幅方案介绍

已有的触达方式对用户实时行为产生的场景覆盖不够,而且这类场景较离线场景相比实时性更高,对用户来说相对更重要。针对这个情况,我们增加了对实时场景覆盖。

目的是将用户行为抽象成关系模型,当关系一侧的用户行为发生变更后触发对另一侧的触达,这种情况实时性更强而且和用户强相关,触达的消息点击和转化都比较高,也有利于增强用户粘性。

 站内横幅整体设计概览

数据服务层:各业务模块负责采集用户行为数据,由 molo 侧将用户行为抽象关系模型,用户进入指定场景,触发对应场景触达策略,再经统一频控量控进行核验

传输层:基于 MQTT 协议的长链接实现的鹰眼自建通道,将通过核验的触达信号传递给下一流程

APP 基础能力层:为触达消息传输,流程监控提供基础能力

数据解析层:将传递过来的触达消息体解析,合法性校验,监控异常数据

视图控制层:进行触达消息模板视图创建,弹出方式识别,通过 ViewCore 给触达消息视图注入生命周期,出入场动画,声音震动提醒、展示动效等各种定制化属性

2. 京东金融 App 站内横栏应用场景

站内横栏功能上线后,为一批业务提供了有效的触达策略

3. 遇到的问题及解决思路

3.1 如何让横栏实现在 App 站内全局

全局弹窗这个实现起来相对容易,主要依赖注册的页面生命周期监听,利用 WindowManager 在离开页面时移除 view ,在进入新页面重新添加;

3.2 指定页面显示或指定页面不显示问题

指定页面的前提是能区分是哪个页面,分两种情况:

Web 页面,首先获取运营在鹰眼平台配置的指定的 Web 链接,再通过 APP 的 web 容器获取当前正在加的 web 页面的链接地址,两个地址进行匹配,需要注意本地取到的 url 里参数存在比运营配置多的情况,因此匹配时我们认为只要本地取到的参数包含配置的地址中的各参数即是匹配成功;

原生页面,方式一,路由地址匹配:我们首先取原生页面的路由信息,本地有路由信息根据路由地址去匹配,若原生页面无路由地址,需要进行适配

方式二,popClass 匹配:需要将原生页面的类路径录入到后台页面配置表进行维护,匹配时根据页面的类路径进行匹配

3.3 如何避免多个横栏消息时丢失问题

同时支持多个横栏,这里需要注意的是横栏信息同步问题,我们在创建横栏的时候给横栏创建了一个属性信息对象,每个横栏属性信息都有唯一的 key, 将横栏属性缓存起来,并给缓存设置最大阈值,达到阈值时最后一个横栏消失清除缓存信息

总结:站内横栏触达方案是我们在智能化触达方式中的一项探索,功能上线后,为白条,保险,财富,基金,分期等业务提供了一种更智能化的运营方式,触达消息触达成功率 98%,点击率达到 12%~16%,助力相关业务提升 40% 以上

触达方式四:桌面小组件

AppWidget 又称小部件、小插件或微件。它是显示在 Launcher 上,能在 Logo 以外提供更多信息的一种特别的设计;它方便用户免于打开 App 即可直接查看信息和进行简单的交互。

  • Android 初期已经提供这种能力,但应用比较少,常见的应用如:时钟、天气、日历等;
  • iOS 10 引入小组件,直到 iOS 14 的全面支持,可能是受此影响,Android 12 改进了 widgetAPI,提升了用户及开发者体验

1. 创建 AppWidget

总的来说分以下几个部分:

1.1 定义 AppWidgetProvider

创建一个 AppWidgetProvider 子类,并创建对应的 AppWidgetProviderInfo 配置文件
example_appwidget_info.xml,并在 manifest 声明

1.2 设置 appWidget 的基本属性

AppWidgetProviderInfo 定义了 widget 的基本特性,如应用微件的最小布局尺寸、应用微件的初始布局资源、应用微件的更新频率,以及(可选)在应用微件创建时启动的配置 Activity。您可以使用单个 <appwidget-provider> 元素在 XML 资源中定义 AppWidgetProviderInfo 对象,并将其保存在项目的 res/xml/ 文件夹中

1.3 绘制 widget 的布局

AppWidget 可以支持的布局如下(由于其底层是基于 RemoteViews 实现,支持的视图较少):

  • FrameLayout、LinearLayout、RelativeLayout、GridLayout

支持使用的 View 如下(不支持自定义 View):

    • AnalogClock、Button、Chronometer、ImageButton、ImageView、ProgressBar、TextView、ViewFlipper、ListView、GridView、StackView、AdapterViewFlipper

1.4 配置 Configuration Activity

当应用 widget 使用配置 Activity 时,由该 Activity 负责在配置完成后对 app 的 widget 进行初始化

1.4.1 获取 widget id

1.4.2 执行应用微件配置

1.4.3 配置完成后,通过调用 getInstance(Context) 来获取 AppWidgetManager 的实例

1.4.4 通过调用 updateAppWidget(int, RemoteViews) 来使用 RemoteViews 布局更新应用微件

1.4.5. 最后,创建返回 Intent,为其设置 Activity 结果,然后结束该 Activity

1.4.6 设置预览图片

在选择创建 appWidget 时,展示给用户的描绘应用微件是什么样子的一张图片,未配置时默认展示 APP logo

1.4.7 配置 Service

请求集合中的特定项目时,RemoteViewsFactory 会为集合创建相应项目并将其作为 RemoteViews 对象返回。要在 appWidget 中添加集合视图,您必须实现 RemoteViewsService 和 RemoteViewsFactory。

详细参见官方 demo:
https://android.googlesource.com/platform/development/+/master/samples/StackWidget/src/com/example/android/stackwidget/StackWidgetService.java

1.4.8 设置点击事件

通常使用 setOnClickPendingIntent() 来设置对象的点击行为 - 例如,让按钮启动 Activity。但是,不允许对各个集合项目中的子视图使用此方法。如果要向集合中的各个项目添加点击行为,应改用 setOnClickFillInIntent()。这需要为集合视图设置待定 Intent 模板,然后通过 RemoteViewsFactory 在集合中的每个项目上设置填充 Intent。

2. 常见 App 的实现

金融 APP 的实现:

3. 小组件实践中的问题

3.1 如何裁剪图片圆角

一般在开发过程中使用 Glide 对图片进行裁剪,这里需要注意小组件里使用 Glide 与平常略有不同,因为拿不到对应的 View 视图,AppWidgetTarget 更适用于小组件加载图片场景,配合 MultiTransformation 可简便的实现图片圆角的剪裁

AppWidgetTarget appWidgetTarget = new AppWidgetTarget(context, ivViewId, views, mAppWidgetIds);
RequestOptions option = new RequestOptions()
                .transform(new MultiTransformation<>(
                        new CenterCrop(),
                        new RoundedCorners(ToolUnit.dipToPx(mContext, connerDp))));
GlideApp.with(context)
                    .asBitmap()
                    .load(bgUrl)
                    .apply(option)
                    .diskCacheStrategy(DiskCacheStrategy.NONE)
                    .into(appWidgetTarget);

3.2 如何实现自定义字体

小组件本身是不支持自定义 view 的,若要实现支持自定义字体,可以通过 Canvas draw text 方式 给 text 设置字体样式,粗细、颜色 、背景等属性

3.3 处理点击响应延迟问题

通过广播形式 PendingIntent.getBroadcast 处理点击事件,在部分机型上存在延时,最长约 7s;可以使用 setOnClickPendingIntent 方式代替,需要在 app 的跳转中心处理对应的事件,如跳转落地页、埋点等

3.4 如何制定更新策略

系统为了避免小组件过多的占用资源,默认拒绝频繁更新,设置了最短更新时间为 30 分钟;这种默认的刷新方式不太适合交互类型的小组件,存在用户操作完以后页面状态不同步的问题,那这个问题如何解决呢?首先根据业务场景需要我们也可以把刷新分为两类:

实时性有一定要求的业务场景:比如新闻资讯类的

通过创建 Service 开启定时任务的方式,制定更新的时间间隔,比如 5 分钟执行一次更新任务;

用户交互类型的业务场景:比如签到,收积分、能量等;此类场景不要求频繁刷新数据,但需要配置合理的自动刷新时间,同时在用户操作后需要刷新页面;可以在 App 启动时注册 APP 内页面生命周期监听ActivityLifecycleCallbacks,实现判断 APP 前后台监听能力,监听应用进入后台时发送刷新小组件的广播,触发小组件的刷新;或者封装统一方法,提供给业务主动触发刷新对应的小组件的接口

小结

本文主要分享了京东金融客户端技术团队对短信、push、站内横幅、小组件几种触达方式的探索实践过程以及遇到的问题和解决方案。希望能给在探索用户触达实现方案的同学提供一些思路;为了让用户在使用我们的产品的时候能有更好的体验,产品在运营过程中能高效的触达用户,京东科技技术团队在持续打磨已有方案的同时将继续探索和实践更加智能高效的触达方案。

相关推荐

GPT-6凌晨上线智能UI:智能UI时代的技术架构重构与应对之道

从命令行到图形界面,计算机行业用了三十年证明了同一件事:人类需要视觉的、空间的、可重复的交互表面,纯文字从来只是过渡形态。智能界面的出现,意味着AI行业第一次大规模承认了这个规律——对话是创造的接口,界面是使用的归宿。生成的界面如何稳定下来?个人的数据与身份如何安全地沉淀?Agent的行动能力如何可信地放大?谁能把这三个问题答好,谁就站在了Personal Agent图形界面时刻的浪潮之巅。

京东科技开发者 161

AI 会写代码之后,交付为什么还没变快?

AI 写代码,只是这场变革的起点,而不是终点。真正决定一个组织能否吃到 AI 红利的,不是"能不能用 AI 写出代码",而是敢不敢用 AI 重新设计交付流程、重新划分角色分工、重新组织团队结构。研发视角能把工具和个人推到极致,却会在组织的边界前止步;只有站上组织视角,把AI × 工具一路推进到AI × 组织,那些被 AI 照出来的摩擦,才会真正被抹平。国际技术部 Multi AI Native 想做的,正是这件事——让 Agent 成为你可靠的数字战友,让每一次迭代交付都快一个量级;

京东科技开发者 276

OxygenData-Vibe搭建:用 AI Coding重新定义数据看板搭建

长期以来,数据看板开发主要有两种方式:一种是使用标准化 BI 工具,交付快、成本低,但图表样式、交互体验和功能扩展都受限于 BI 本身的能力;另一种是自研定制开发,能够充分满足复杂和个性化需求,但需要投入大量研发资源,交付周期也更长。比如一个通过 BI 只需要 1 天就能搭建出来的看板,如果采用自研方式,可能需要投入 30 PD 的研发人力。既然 BI 交付这么快,为什么不把所有看板需求都交给 BI?原因在于,业务某些场景需要的不只是把数据展示出来。

京东科技开发者 337

当我谈数据库高可用时我谈些什么

大家都经常听到说数据库的双1,那双1指的是什么呢?参数=1(最安全)≠1(更快但可能丢)每次提交都把 redo 刷盘0/2:攒着刷,崩溃丢最近 1 秒每次提交都把 binlog 刷盘0/N:攒着刷,崩溃丢最近若干条"双 1"(都设为 1)= 单机不丢已提交事务的前提。生产核心库必须双 1;代价是每次提交两次 fsync。小结:单机层用 WAL 提速、用 2PC 保证 redo/binlog 一致、用崩溃恢复裁决半成品事务、用双 1 兜底持久性。

京东科技开发者 292

ScoAI:面向供应链的运筹原生决策智能

ScoAI 关注的并非 AI 能否进入供应链,而是 AI 参与供应链决策之后,哪些内容适合通过数据学习,哪些关系必须显式计算,以及哪些结果需要依据执行记录进行验证。其基本分工是:供应链业务定义问题、资源与行动后果,运筹学表达目标、约束和协同关系,AI 提供可复用的估计与判断。真正用于改进后续决策的,不仅是模型生成的初始结果,还包括实际采取的行动及其产生的业务反馈。

京东科技开发者 382

拆解海博 AI-Native 落地保障:海博团队 AI 知识库能力建设

绕了一大圈,回头看,我们其实一直在解开头那三个结:AI 读不懂系统、影响面靠人脑记、测试预期没处查。做到这里,本质上是把"AI 用不好"这个问题,从"是不是该换个更强的模型"重新定义成了"怎么把上下文经营好"。顺着这个思路,我们攒下了这么几样东西:•。

京东科技开发者 535

从零构建一个生产级记忆型 AI Agent —— AgentScope 项目全景技术与学习指南

domain 层端口接口(domain)职责适配器实现(infra)对话流水账读写经验记忆检索/落库请求级幂等四态会话元数据 CRUD会话级 Skill 选择态Skill 元数据HITL 权限网关(domain 内含逻辑,见第四篇)StreamSink技术中立的流式下沉(client 层桥接)以幂等端口为例,头部注释明确写道:实现 domain 端口,持有实体不出 infra 边界,对外只暴露嵌套视图GateResult。

京东科技开发者 589

数据涅槃:Agentic 重塑搜推数据生产体系

当前大模型已经能够理解需求、生成代码和解释错误,但数据生产的难点并不只是“写出一段 SQL”。一个需求还要经过数据源确认、口径澄清、加工编排、资源规划、任务提交、调度运行、结果交付和故障处置。任何一步缺少都可能让“看起来正确”的任务变成生产事故。

京东科技开发者 350

81.8 秒的视频,我们改了 15 个版本:一次纯 Codex 驱动的 AI-native 视频实践

81.8 秒、15 个版本,这些数字真正想说明什么?视频制作正在从一组专业软件里的复杂操作,变成一场围绕目标、参考和反馈展开的持续对话。AI 已经可以接住从脚本到交付的大量工作。你可以把精力留给更重要的部分:理解观众、选择故事、判断好坏。过去停在 PPT 和脑海里的想法,现在有机会被快速做成一支能看、能改、也愿意转发的视频。如果明天就要介绍你手头的项目,你最想先把哪一步交给 AI?

京东科技开发者 447

Codex 驱动的移动端AI全栈开发:从 Relay 原型图到可交付链路

AI 编程工具降低了跨端开发门槛,但“让 AI 写页面”并不等于“完成移动端交付”。PC 运营端页面通常以功能闭环为中心,设计约束较弱,研发可以基于组件库快速搭建;移动端 C 端页面直接面对用户,Relay 原型图和 UI 设计稿不仅是视觉参考,更是交互、信息层级、状态反馈和业务信任感的综合契约。

京东科技开发者 576

Claude Code vs Codex 记忆体系深度对比

Claude Code —— 分层自动记忆系统四层分层架构(CLAUDE.md / Auto Memory / Session Memory / AutoDream)构成自优化闭环,系统主动捕获、分类、去冗并跨会话接力经验。走的是自动化优先路线——让机器替人记忆、替人整理,以少量可控性的不确定换取强大的经验积累能力。Codex —— 声明式契约系统两层扁平架构(AGENTS.md 静态声明层 + 会话上下文层),记忆完全由人显式订立、显式修改,系统只读契约、绝不擅自变更。走的是可控性优先。

京东科技开发者 613

上游给空、下游拿到 -1,我把故障一直追到了 commons-beanutils 的构造函数

这篇手记是一份事后复盘,写在我们已经把修复推上线、把测试用例跑绿、把约束文档沉淀进团队库之后。非研发同事,可以直接从第八章开始看,前七章都是讲排障和代码分析。故障本身不复杂,修复也不复杂,但这次排查真正让我想写下来的,不是技术本身——而是从问题提报到解决全程AI的作用:问题定位:业务方反馈了一个异常单号说「下发失败」,一线运维同事直接在日志系统捞到相关的系统日志,用IDE打开下游代码库,把异常信息给到JoyCode——AI 直接指向了问题是serialType值非法,系统只接受0和1,而当前上游给的是-1。

京东科技开发者 709

SKill测评:谁才是真正的Skill之王?

巧合的是,阿里近期开源了一款名为 Skill-Up 的测评工具——它专门面向 Agent Skill 开发者,支持在 Claude Code、Codex、Qoder CLI 等真实 Agent Engine 环境中验证 Skill 的功能正确性,并可将失败用例转化为精准的修复指引,同时支持本地与 CI 环境的持续回归。2026年,Skill 的热度不减,已成为 AI 辅助编程领域的标配。在日常研发中,无论是沉淀个人经验,还是将团队的优秀范本标准化,将知识“蒸馏”为 Skill 已是大家的常规操作。

京东科技开发者 629

让AI真正参与工作!JoyDesk已上线京东云

JoyDesk提供覆盖AI资产管理、权限控制、安全策略、审批审计、运营监控等企业级治理能力,支持按组织、角色和项目进行精细化权限管理,并支持私有化部署,确保企业数据边界清晰、AI行为全程可追溯、安全策略灵活可配置,满足金融、政企等行业对数据安全和合规治理的要求,让AI真正成为企业可信赖的生产力。JoyDesk支持MCP协议、标准API、技能等多种开放接入方式,可快速连接企业现有业务系统,将业务能力封装为AI可调用的技能和专家,让AI能够理解业务流程、调用业务系统、完成业务任务,而无需改变企业原有IT架构。

京东科技开发者 662

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手【最终版】

这个项目展示了AI Agent 在垂直内容创作领域端到端自动化:从内容理解到播客输出,全流程 AI 驱动多模态融合:文字、图片、音频、视频统一处理专业级音频质量:音色设计 + 智能混音,输出广播级品质低门槛使用:可视化配置 + 自然语言交互,无需技术背景。

京东科技开发者 557

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手(高级篇)

这是一个 AI 驱动的播客创作助手,专注于从文字/视频/音频内容识别到播客制作的全流程。你可以用自然语言与它对话,也可以上传视频和音频,它会理解意图、调用相应的语音合成工具,把他们变成真实的播客音频。

京东科技开发者 723

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手(进阶篇)

这是一个AI 驱动的音频内容创作助手。你可以用自然语言与它对话,它会理解意图、调用相应的语音合成工具,把文字变成真实的播客音频,并保存在本地。关于项目的详细介绍见第一篇文章:第一个 AI Agent 项目:从零搭建 AI 音频创作助手(入门篇)这篇文章更多介绍进阶篇添加的功能。

京东科技开发者 548

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手(入门篇)

这个项目让我第一次把前端、后端、AI Agent 三块内容独立串联起来。技术选型上每一块都是当下主流的方案,实际跑通整条链路之后对"全栈"有了更具体的感受。框架版本要锁定:LangChain 这类快速迭代的框架,版本差异带来的问题远比你想象的多先跑通链路,再追求完美:新手阶段能把用户输入 → AI 处理 → 结果展示这条链跑通,比深入某个技术点更有价值多看官方文档:相比博客和教程,官方文档更新及时,特别是 LangGraph 这种新框架后续计划继续迭代,欢迎交流!

京东科技开发者 606

ICLR 2026 | 面向序列决策的贝叶斯集成方法

在这篇工作中,我们关注的是。

京东科技开发者 295

ICML 2026|NaviAgent:面向 Oxygen 智能体的可扩展工具编排

大型语言模型(LLM)越来越多地作为函数调用代理,调用外部工具来处理超出其静态知识范围的任务。然而,它们通常一次只调用一个工具,缺乏对任务结构的全局视图。由于工具之间往往相互依赖,这会导致错误累积和可扩展性差,尤其是在扩展到数百或数千个工具时。为了解决这些局限性,我们提出了NaviAgent,一种显式的双层架构,它通过基于图的工具关系建模将任务规划与工具执行解耦。在规划层,基于 LLM 的代理决定是直接响应、澄清意图,还是检索并执行一个独立于工具间复杂性的工具链。

京东科技开发者 387

实测 9 款 AI 架构图工具:从 Mermaid 美化到 GPT-Image2,一份选型清单

支持 5 类图(架构图、工作流图、时序图、数据流图、生命周期/状态机图),主题 4 种(Classic、Signal Flow、Blueprint、Editorial)+ 3 种色彩模式(Dark / Light / System Auto),输出格式含 HTML、PNG、SVG、WebM、Share Card PNG、JSON IR。它把提示词图库、图像生成案例、参考图编辑流程和命令行工具整合在一起,让 AI Agent 能直接调用 GPT Image 2 模型完成文生图、图生图、参考图编辑等任务。

京东科技开发者 898

别再守着 Claude Code 了——学会指挥它自主干活

回到开头那句:别再一句一句地喂它、然后守着屏幕。真正的用法是——把一件事想清楚、划好边界、给它一个能自我验证的目标,然后交出去。你会发现,省下来的时间不是一点半点。把重复的判断和执行还给机器,把真正需要你的判断留给自己。

京东科技开发者 585

CVPR 2026|Oxygen XR 团队在原生鱼眼高斯泼溅技术上带来新突破

京东零售技术团队联合清华大学提出DirectFisheye-GS框架,创新性地将鱼眼相机模型原生嵌入3D高斯泼溅管线,通过跨视角联合优化策略直接处理鱼眼图像,避免了传统去畸变预处理导致的信息损失。该方案在多个公开数据集上达到SOTA性能,有效解决了单视角优化引起的几何畸变和视角不一致问题,同时保持与现有3DGS工具链的兼容性。技术已应用于电商3D重建和4D体积视频等场景,显著提升了沉浸式体验。相关论文被CVPR 2026接收,为宽视场场景重建提供了高效解决方案。

京东科技开发者 354

拆解海博 AI-Native 落地保障:Harness、双 Loop、知识库与技能自主迭代实践

海博研发RoadMap 的落地,彻底终结了 AI 编程“对话式玄学”的旧模式,真正落地了AI Native 研发工程化。它证明 AI 规模化赋能研发的核心,不在于堆砌大模型能力,而在于用工程思维重构 AI 的工作范式:用结构化流程替代随机对话,用固化规则约束模型行为,用持续沉淀实现能力复利,用分层架构支撑规模化落地。

京东科技开发者 638

让 AI 快速「读懂」你的代码仓:Joy-Code-Graph 云端图谱服务的三次进化

代码知识图谱不是要取代 AI 的智能,而是要补齐它对代码全局关系的认知盲区。当 AI 能一眼看清「谁调用了谁、改动会波及哪里」,它写出的代码才真正靠谱;当这份认知安全地留在自己手里、随时被 Joygen 调用、并且永久沉淀在代码仓里——AI 编程的体验,才算真正上了一个台阶。这,就是我们做 Joy-Code-Graph 云端服务的初衷。能力共享,数据自主;一次建图,长期受用。

京东科技开发者 751

【Coding生态】从代码托管到 AI 能力底座:与Coding一起共建 AI 研发生态

前两种框架能够很好地支撑对话式能力和预设流程式能力。它们适合基于提示词或预设工作流完成研发问答、知识查询、流程编排等任务。但在更复杂的研发场景中,仅仅“回答问题”还不够。当用户业务逻辑复杂时,一旦场景进入真实落地阶段,例如下载代码、修改文件、执行命令、安装依赖、运行测试、读取完整代码文件,或者与自有系统联动、将结果渲染到 Coding 页面、推送到京 ME,AI 应用需要的不只是知识能力,还需要真实的代码库操作能力和独立可执行环境。

京东科技开发者 768

GPT-5.6、ChatGPT Work 与 Codex 更新食用指南

三档模型当前都提供 1,050,000 tokens 上下文、922,000 tokens 最大输入和 128,000 tokens 最大输出,接受文本与图像输入、输出文本,并支持 web search、file search、Computer Use、MCP、Tool Search、Skills、Apply Patch 等工具。Work 可以读取你提供的文件,通过插件连接 Slack、Google Drive、SharePoint、邮箱、日历、CRM 或项目系统,调用获批工具,并在执行中展示进度。

京东科技开发者 864

把业务流程沉淀成高质量 Skill 的实践路径

使用Record & Replay创建的Skill,尽管创建流程简单,但它的本质实际是让 AI 去操作页面,这不但有可能影响我们对电脑的操作,还有可能无法稳定复现。创建Skill时,可以使用 Codex 的 Record & Replay 插件,把一次手工操作录下来,再让 AI 生成可复用流程。刚开始切换时,很容易遇到接口报错,可以让Codex排查原因进行优化,直到可以稳定执行;补充相应业务背景,说明这件事为什么要做,谁会用,输入从哪来,输出给谁看。电脑休眠、关机、软件没开时,本地任务可能无法执行。

京东科技开发者 835

政企前台AI-Agent的架构实践:打造可复用的 AI 服务平台-【灯塔计划】

不止是爆火的龙虾,还是各种Skills,MCP、Agent,脱离的具体的场景谈方案,最后只会是一场空。这一套可复用的 AI 服务平台,截止目前,通过前后端对接规范文档,多项能力已快速接入到各个场域的不同端平台,大幅降低研发成本, 并且各业务线新场景的接入从原来的 “开发驱动” 转为 “配置驱动”,接入周期从天维度缩短至小时级。

京东科技开发者 862

京东 Oxygen xLLM 大模型推理引擎正式捐赠开放原子开源基金会,共建国产 AI Infra 生态

下一阶段 AI 基础设施的核心命题,不是简单的算力堆叠,而是让工程本身变得智能——让调度系统能自主感知负载特征并动态优化,让推理引擎能根据模型结构和硬件特性自动生成最优执行方案,让整个 AI 工程链路具备自感知、自决策、自优化的能力。未来,Oxygen xLLM 的项目官网、社区沟通渠道及微信社区将陆续向开发者开放,诚邀芯片厂商、模型厂商、云厂商、企业用户及个人开发者共同参与,让国产大模型推理引擎在开放生态中加速成长。硬件层,原生支持 GPU / NPU / MLU 多类 AI 芯片,深度适配国产芯片。

京东科技开发者 1003
上一篇: 理解virt、res、shr之间的关系(linux系统篇)
下一篇: 京东金融客户端用户触达方式的精细化探索与实践
京东云开发者
京东云开发者 企业官方账号 企业官方账号
博客等级 码龄8年 1万+粉丝 2140原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值