Taivas

背景近几年随着 LLM 及 AI Agent 应用的普及，准确的说是以前所未有的进化速度在不断刷新人们的认知，对很多企业和个人来说，既有兴奋又有焦虑，但我想，对于大部分人来说应该是焦虑居多。一方面，看到数个 LLM 公司及基于 LLM、 AI Agent 构建的应用公司在极短时间内，以极少的人力，展现出极为夸张的生产力，成为股市竞相争宠的新宠儿，市值更是直逼甚至超越多个传统大厂，而从这些大厂的视角来看，自己多年来沉淀、累积资本和护城河，就这样在极短的时间内被别人追平和超越，甚至在将来被从底层逻辑上颠覆。另一方面，当我们开始尝试在自身、在企业内部尝试追赶这一潮流的时候，发现各种水土不服，或者只能带来一些“花里胡哨”的、有限的帮助。归根结底，是因为，如果希望 AI 可以跟自己的工作无缝衔接，不但需要让 AI 可以接入你的日常工作、决策所需的所有数据、信息，更需要正确处理好人与AI的协作关系。 几个概念先来了解几个概念。 什么是 AI Native？AI-Native（AI原生）是指从产品或系统的设计之初，就将人工智能（特别是大模型）作为核心驱动力和底层基础设施，而非在传统系统上简单叠...

背景业务背景机票 OTA 业务已进入复杂出行需求与海量供给匹配的深水区，以商旅出行场景为例，用户既要遵守公司差旅报销的规章要求，又希望在此基础上为自己谋求尽可能多的权益，双倍里程积分、升舱、返现等增值商品应运而生。传统的机票 OTA 产品 GUI 交互形态（首页 -> listing页 -> OTA页 -> 下单页 -> 辅营页）显得笨重而臃肿，既没有让商旅之类的资深用户感到切实便利，又让只是简单的想买一张机票的小白用户感到头疼。 LUI 上的探索早在 25 年 4 月的飞猪 APP 内，就已经悄然布局了一款基于 AI Agent 的 LUI 形态的 OTA 导购链路，用户可以以聊天对话的形式定制涵盖机、火、酒、门票的旅游攻略，并可直接完成购票、订酒店等动作。随着 26 年春节期间，阿里生态的闪购、淘宝、飞猪等接入千问 APP，普罗大众才第一次真切的感受到，AI Agent 不光像豆包 APP 一样可以用来问答聊天，还可以在上面完成具有一定复杂度的购物及履约动作。然而随着 30 亿补贴的结束，大部分用户的在线消费习惯似乎又回到了原来的淘宝、京东。即便如此，...

机票行业的低频困境在拉新获流增长乏力的时候，老用户的留存与复购就显得尤为重要。不同于教育行业，用户有着明确的需求（子女教育）和周期（寒暑假及双减政策规定的课外补习时间段），机票行业用户出行概率极低，一年出行4次以上就可以认为是高频用户。 用户流失的原因通常来说，一个用户未发生复购，可能的原因包括： 前一次的购票或履约体验较差 二次购票时与竞品相比失去了价格优势 每年五一都会去外地游玩，今年却选择了留在本地（用户访谈中约十几分之一的概率） 中东打仗导致燃油费上涨最终选择坐火车（虽然不常见，但真实地发生了） 复访 & 复购首先看一下复访和复购的定义： 复访：用户上次完成交易，一定周期（如30天）内又进行了二次访问（如机票OTA行业的 listing 页） 复购：用户上次完成交易，一定周期（如30天）内又进行了二次交易 对于这几个指标，我的心路历程前后经历了2个阶段 起初我认为，复访和复购只是留存这个事情上，两个不同阶段的指标； 后来我认为，复访是因为用户觉得上次的购票体验还可以，所以这次会选择再来，但复购指标则表示这次的购票体验不亚于前一次的购票体验，因此我会选择二...

什么是 Vibe Working？“Vibe Working”（氛围工作法）是由近期在开发者社区爆火的“Vibe Coding”（氛围编程）理念自然延伸而来的一个概念。如果说 Vibe Coding 是指“完全依靠自然语言描述需求，让 AI 直接生成代码”，那么 Vibe Working 则代表了一种高度依赖 AI 智能体（Agent）进行工作流自动化、知识管理和任务调度的新型工作范式。 我的实践经历在工作中利用AI Agent 进行 Vibe Working，可以极大程度的进行提效。以下是自己的一些实践。 准备工作要进行 Vibe Working，首先需要有好用的 AI Agent。 龙虾秘书：我自己是安装了一个 openClaw 龙虾作为一个全职秘书，这么形容它是因为它需要记录我的所有工作信息，包括一些临时性的提醒、循环定时提醒、结构化长期的信息等等，利用它可以为我随时随地记零散的事情或者记录灵感乍现，最后可以按我的要求结构化的反馈给我，另外它可以接入钉钉，这样我可以随时在移动端处理工作 设计师：使用某个在线设计平台 Agent，在上面可以使用很多最优秀的、最新的大模型，额...

工作需要，迁移公司 Home Page 的 Server。主要是 AWS server 跨 Region 的迁移，网上有些教程但比较零散，基本思路是： 原 AWS Region 生成镜像 选择原 Server 所在 Region 选择 EC2 生成原 Server Instance 的镜像 INSTANCES-instances 勾选 原 Server Instance Actions-Image-Create Image 跨 Region 复制 AMIs IMAGES-AMIs Actions-Copy AMI 选择要复制 AMI 的 Destiation Region 和 Name 等信息 新 AWS Region 通过镜像生成 Server Instance 选择新 Server 所在 Region 选择 EC2 新建安全组 NETWORK & SECURITY-Security Groups Create Secure Group( copy Defails from origin one ) 生成主机实例 IMAGES-AMIs 勾...

前言很久没更了，首先悼念公司人士变动又走了两位大神同事jl，crvv。 我也因此有机会做些其它的事情，比如前后端代码的锻炼以及这几天公司主页迁移和部署。 Install WordPress with LAMP on Ubuntu 16.04过程比较曲折，因为先后在 AWS, Azure cn, RackSpace 上部署 WordPress，优先考虑的都是从各平台现有的 Image Market 上找现成的 Image 来直接生成部署好的 Server，然而除了 AWS，其它都不太好用，比如服务器登陆不好使，WordPress 登陆不好使，MySQL 登陆不好使之类的，因为最终生成的这些用户名和密码可能跟你初始化时设置的不一样（Azure cn 中 Server 的登陆密码就和我设的不一样，我反复试了三次，确认不是自己的问题），或者根本就没给你机会设置（RackSpace中 WordPress的登陆密码就没有地方初始化，之后尝试通过邮箱找回密码也是跪的）。 为了全部在自己掌控之中，避免后续其它尴尬的问题的出现，我还是决定自己从头搞。 Set Up Linux Server ( U...

Nginx碰过好几次了，一次比一次熟，了解的配置也越来越多。跨域问题经常会碰到，这次尝试通过Nginx来解决跨域问题。 关于跨域，SegmentFault里面有篇详解JS跨域的文章。 实践部分以下是自己的情况：A: 前端Web应用，访问地址是http://localhost:33867B: 服务器，提供api服务，地址是https://localhost:8383 因为这里A和B的协议和端口都不同，所以需要在后端进行允许跨域的配置。 Nginx需要做的就是，提供一个转发端口，与A和B都不同（否则会影响到A和B的访问），在这里取33868。并且，转发的同时还要给报文的报头添加允许跨域的标记，Nginx官方文档提供了CORS on Nginx的详细配置信息。因为这里开发的Web应用是一套开发工具，只用于本地开发而不会用在生产环境，所以最后我取了最简洁的配置，配置文件关键内容如下 123456789101112131415161718192021222324252627282930// xxx.confserver { listen 33868 ssl; ...

首先哀悼Hexo好像被墙了。。。不知道两会之后会不会恢复。 好久没写过一篇像样的技术博客了。。。赶巧最近几天碰到好几个以前碰到过但是没太弄清楚的问题，现在抽时间记一下吧。这篇先记一下今天碰到的关于ReactTestUtils.Simulate的一点小问题。 ReactTestUtils.Simulate首先ReactTestUtils是一套便于对React进行unit test的工具（React Test Utils，字面意思了。。。），其中官方文档提到Simulate is possibly the single most useful utility in ReactTestUtils. 我测试时用到了如下代码： 被测文件step-input.jsx 123456//change event handlerchangeHandler(name, e) { const s = {}; s[name] = e.target.value; this.setState(s);} 123456789101112131415161718//...

DNS终于work了，呼。。。虽然不难，但是对于初次尝试，过程还是比较艰辛的。 本来打算自建DNS服务器来玩，后来发现短期内建好还是比较费劲的，因为只有晚上回来才有时间研究，于是就先compromise一下吧。 首先由于打算使用https，所以证书首先是个问题，从JL处了解到WoSign和startssl，前者中国的，后者外国的，总觉得是不是外国的会好一点，然而JL说没啥大区别，相反WoSign证书有效期可达3年，而startssl只能到1年，所以最后决定用WoSign了。审核几乎是瞬间的，走完步骤就能下载证书了。 证书搞完后域名没有呀，所以也看不出效果，在Nginx的配置文件中配好证书路径后就开始倒腾DNS，要死要死。。。 首先为了省事直接走Goddady自带的DNS解析服务，设置了A记录，然而后来发现并未生效，以为是Nginx没配好，结果最后发现taivas.life连ping都ping不通。。。 然后呢，查了下据说Godaddy的DNS服务被墙了一部分。。。 然后呢，找教程改了Goddady的DNS，添加了更多的Goddady自带DNS及DNSPOD的DNS，不行。。。 然...

今天是2015年12月13日，我终于把自己的Blog搭建起来了。感谢JL的指点，以及后续仍需请教的CRVV，还有为员工提供免费RackSpace VPS的奥格是个好公司。 其实搭建自己的Website的想法早就有了，但直到10号晚上才最终下定决心。11号凌晨从Godaddy买下了自己的域名taivas.life；11，12号利用时间把新到手的VPS整理了一下；13号周日睡了个懒觉，利用一下午的时间把Hexo弄起来了（Hexo的Nginx配置花了点时间，以及碰到了Hexo配置里Rsync关于port的坑），19点左右终于成功通过ip访问到自己的Website。打算后续再自建个DNS Server就可以绑上域名taivas.life了。 以后我将会在这里记录自己的学习、生活和进步。