2026年2月

有空可以去支付宝搜索“百事新春福利小程序”每天都可以到小程序抽 6 次
抽到 KFC 券（肯德基开门接福炸鸡桶满 59 特价 0 元券）后可在卡券点去使用，跳转肯德基点餐即可

这波百事 nb 又可以吃炸鸡了 😋

image

故事是这样的。

Tal和Aman,两个做AI产品的产品经理,花了100多小时,搞出了一套交互式教程。

他们说了一句让我破防的话:

“用Cursor做日常非技术工作的3个月,比用ChatGPT 3年学到的AI产品原理还多。”

我当时就愣了。

image.png

故事的起点

你肯定遇到过这种场景。

产品会上,有人提到"subagents"、“context engineering”、“agent memory”。

你点头。

你知道这些词是啥意思……但你心里祈祷别让你用这些词造句。

你看过视频讲解,收藏过信息图,甚至vibe coded几个应用,还上线了AI功能。

但为什么你还是觉得自己离真正理解这些东西差了十万八千里?

Tal和Aman说,问题不在你。

问题在"AI炒作工业综合体"。

大部分AI内容是设计来制造FOMO的,不是来教你的:“这个模型太疯狂了!”、隐藏混乱现实的demo、越看越晕的复杂图表。

image.jpg

他们发现了什么

核心发现就一句话:

从消费级UI(ChatGPT、Granola、Lovable)转向更强大的AI编码代理(Cursor和Claude Code),是内化重要AI概念最具变革性的习惯。

为什么?

因为编码代理会透明地展示它们的工作。

你能读到AI的推理过程。

你能检查工具调用。

你能看着上下文窗口被填满。

你会撞上和工程师构建AI应用时一样的墙,自然地直觉出自己的解决方案,开始预判趋势和行业公告。

这就是**“AI产品感”**——正确预判什么对用户真正有影响力、用AI技术上也可行的能力。

AI产品感是什么?

是遇到AI"忘记"事实的支持工单时,你能认出这是context rot(上下文腐烂)。

是看到用户在工作流中挣扎时,你能自信地说agent memory能解决这个问题——而且知道怎么重构体验。

image.png

他们现在怎么用Cursor

Tal和Aman现在每天都用Cursor和Claude Code做日常工作:

战略规划。

优先级排序。

决策制定。

数据分析。

生产力提升。

这些工具成了他们的思考伙伴和个人操作系统。

核心打法拆解

他们设计的教程分三个阶段:

阶段1: 上手Cursor(步骤1-4)

用一个迪士尼主题的有趣练习,让你熟悉Cursor。

关键动作:

  • 下载Cursor桌面应用(2分钟)
  • 创建新项目
  • 在Cursor内部继续阅读教程(灵感来自《神奇校车》)
  • 切换到Agent模式,选择Opus 4.5模型

image.jpg

image.png

阶段2: 实操AI模型选择和工具调用(步骤5-6)

这是关键。

你会亲手选择AI模型。

你会看到工具是怎么被调用的。

你会开始理解为什么某些模型适合某些任务。

image.jpg

阶段3: 构建轻量级个人操作系统(步骤7-10)

这是最硬核的部分。

你会构建一个自己每天都能用的AI产品。

然后用RAG、记忆和上下文工程来改进它。

你会体验到:

  • 什么是上下文窗口限制
  • 为什么需要RAG(检索增强生成)
  • agent memory怎么工作
  • 如何做上下文工程

image.jpg

image.png

他们还送了个大礼包

为了让你能完整体验这个教程,他们和Cursor团队合作,给Lenny’s Newsletter订阅者送50美元免费额度。

够用2.5个月。

说实话,这个操作挺聪明。

降低了用户尝试门槛。

image.png

image.jpg

The Playbook: 你可以直接抄的作业

如果你也想快速建立AI产品感,照着这个清单做:

第1步: 立即下载Cursor

  • 去cursor.com/download
  • 下载桌面应用(不是web版)
  • 2分钟搞定

第2步: 创建你的第一个项目

  • 打开Cursor
  • 点击"Open project"
  • 新建文件夹"Build AI Product Sense"

第3步: 切换到Agent模式

  • 确保你在"Agent"模式(不是Chat模式)
  • 关闭"auto",手动选择Opus 4.5模型
  • 这样Cursor才能执行操作

第4步: 在Cursor里继续学习

  • 把教程内容粘贴进Cursor
  • 让AI一步步带你走
  • 像《神奇校车》一样沉浸式学习

第5步: 用Cursor做日常工作

  • 不要只用来写代码
  • 用它做战略分析
  • 用它做数据处理
  • 用它做决策辅助

第6步: 观察AI的工作过程

  • 读AI的推理
  • 看工具调用
  • 盯着上下文窗口
  • 撞墙,然后自己想解决方案

第7步: 构建你自己的AI产品

  • 从一个简单的个人OS开始
  • 加入RAG
  • 加入记忆功能
  • 做上下文工程优化

image.png

image.png

为什么这个方法有效

关键在于透明度。

ChatGPT给你答案。

Cursor让你看到AI是怎么得出答案的。

这就是差别。

你不是在学AI能做什么。

你是在学AI是怎么做的。

你不是在追赶技术。

你是在预判技术。

image.png

Tal说了一句话我觉得特别对:

“AI产品感就是遇到支持工单说AI’忘记’了事实,你能立刻认出这是context rot。”

这就是产品感。

不是知道术语。

是看到问题,立刻知道是什么原因,该怎么解决。

image.png

这个世界,正在被那些真正理解AI工作原理的人重新定义。

不是那些会用ChatGPT的人。

是那些能预判AI能力边界、知道怎么设计AI产品体验的人。

Tal和Aman用100小时,给你铺了一条路。

你要不要走?

image.jpg

image.png

前言：HTML 是什么？

HTML（超文本标记语言）是网页的骨架。它诞生之初只为解决两个核心问题：

  1. 结构化内容：用“标签”区分标题、段落、图片等，让文档排版清晰。
  2. 超链接：实现点击跳转，把孤立的文档连成“万维网”。

核心 1：HTML 元素 —— 网页的“积木”

网页由一个个“元素”拼装而成。

1. 元素的标准结构

就像汉堡包，一个标准元素包含三部分：

  • <p> 开始标签：告诉浏览器“段落开始”。
  • 这是一段文字 内容：用户实际看到的文字。
  • </p> 结束标签：多了一个 /，表示“段落结束”。

2. 特殊情况：空元素（自闭合）

有些元素不需要包裹内容，只执行动作或嵌入资源，比如换行 <br> 或图片 <img>。它们没有结束标签。

<img src="https://xxx.png" alt="图片描述">

3. 嵌套规则：像穿衣服一样

元素可以互相嵌套（比如段落里加粗文字），但必须先开后关，不能交叉。

  • ✅ 正确：<p>我的猫特别<strong>凶</strong></p>（先脱外套 </strong>，再脱内衣 </p>）
  • ❌ 错误：<p>我的猫特别<strong>凶</p></strong>（交叉嵌套会导致页面错乱）

核心 2：HTML 属性 —— 给元素加“配置”

属性写在开始标签里，用于提供额外信息（如图片地址、链接网址）。格式为 属性名="属性值"。

<img src="cat.jpg" alt="猫咪照片" width="300">
  • src：图片地址（必填）。
  • alt：图片加载失败时的替代文字（对视障用户和 SEO 很重要）。

两个避坑指南：

  1. 属性值必须加引号：双引号 "" 或单引号 '' 均可，千万别省略。
  2. 布尔属性：有些属性写上就生效，不需要赋值。比如禁用输入框： <input type="text" disabled> <!-- 禁用状态 -->

核心 3：HTML 文档结构 —— 网页的标准骨架

把元素组合成一个 .html 文件，需要一个标准骨架：

<!DOCTYPE html>
<html lang="zh-CN">
  <head>
    <meta charset="utf-8">
    <title>网页标题（显示在浏览器标签页）</title>
  </head>
  <body>
    <h1>欢迎来到我的页面</h1>
    <p>用户能看到的内容都在 body 里</p>
  </body>
</html>

骨架拆解：

  • <!DOCTYPE html>：声明这是 HTML5 文档，让浏览器按最新标准渲染。
  • <html lang="zh-CN">：网页的根元素，lang 告诉浏览器和搜索引擎这是中文网页。
  • <head>：后台配置。用户看不见，包含字符编码（utf-8 防止中文乱码）、网页标题等。
  • <body>：前台内容。用户看到的所有文字、图片、按钮都在这里。
💡 小贴士：代码里的空格 在 HTML 代码里敲再多空格和换行，浏览器都会压缩成一个空格。我们换行缩进只是为了让代码更易读。

核心 4：注释与特殊字符

1. 注释（写给代码阅读者看）

浏览器会忽略注释内容，常用于备注或临时隐藏代码。

2. 特殊字符（实体引用）

如果你想在网页上直接显示 < 或 >，浏览器会误以为是标签。必须用“字符实体”代替：

想显示的符号代码写法说明
<<小于号 (less than)
\>>大于号 (greater than)
&&和号 (ampersand)

示例：&lt;p&gt; 是段落标签 会在网页上显示为 <p> 是段落标签。

用一张图总结HTML核心结构

🚀 实战：写你的第一个网页

只需 3 步，见证奇迹：

  1. 在电脑上新建一个文本文件，重命名为 index.html（注意后缀必须是 .html）。
  2. 将以下代码复制进去并保存：
<!DOCTYPE html>
   <html lang="zh-CN">
     <head>
       <meta charset="utf-8">
       <title>我的第一个网页</title>
     </head>
     <body>
       <h1>我用 HTML 写的第一个页面</h1>
       <p>今天学会了 HTML 的基本语法，包括：</p>
       <ul>
         <li>元素的结构（开始、内容、结束）</li>
         <li>属性的用法</li>
       </ul>
       <img src="https://image-static.segmentfault.com/722/785/722785927-699d1955a9615" />
     </body>
   </html>
  1. 双击 index.html，它会在浏览器中打开。恭喜，你已经是一名网页开发者了！

​

Snipaste是 Snipaste 截图贴图工具​ 的主程序，这玩意儿能截屏、贴图、取色，写文档、做笔记、写代码时特别好用，比系统自带的截图功能强不少。

一、准备工作

  1. 下载安装包​

  2. 用管理员身份运行（推荐） ​

    • 右键 Snipaste.exe→ 选“以管理员身份运行”，避免权限不足打不开。

二、安装步骤

  1. 双击 Snipaste.exe运行（如果右键过了就直接双击）。
  2. 第一次打开会弹出“用户账户控制”提示 → 点  “是” 。
  3. 进入安装向导，选语言（默认中文）→ 点  “下一步” 。

  4. 选安装位置：

    • 默认是 C:\Program Files\Snipaste，可点“浏览”改到其他盘（比如 D 盘）。

  5. 附加任务：

    • 建议勾“创建桌面快捷方式”和“开机自动启动”（开机就能用，不用每次手动开）。
  6. 点  “安装” ，等进度条走完（很快，几秒到十几秒）。
  7. 安装完会问是否立即运行 → 点“完成”，Snipaste 就启动了，任务栏会有图标。

三、实用步骤（日常怎么用）

  1. 截屏​

    • 按默认快捷键 F1​ 开始截屏，鼠标框选要截的区域，松开就截好了。
    • 截完会自动放到剪贴板，也能点“复制到剪贴板”或“保存图片”。

  2. 贴图​

    • 截完图后，按 F3​ 把截图“贴”到屏幕上，像一张便利贴一样浮在上面，不怕被其他窗口盖住。
    • 贴图可以拖动、缩放，右键点贴图能关掉、置顶、旋转、取色。

  3. 取色​

    • 按 F1​ 截屏时，鼠标移到颜色上，底部会显示颜色值（RGB/HEX），点一下就复制颜色代码，做设计、写 CSS 很方便。

  4. 贴多个图​

    • 截一次贴一次，屏幕能同时贴好多张图，对比代码、文档、设计稿特别好用。

  5. 隐藏/显示贴图​

    • 按 Ctrl+F3​ 可以隐藏所有贴图，再按一次又显示出来，不用一个个关。

  6. 设置快捷键​

    • 右键任务栏图标 → 选“首选项” → “热键”，可以改截屏、贴图的快捷键，比如改成自己习惯的键位。

​

原文发布于我的博客：为什么我认为 AI 正在让初级技术岗位完全消失

前几天刷抖音看到很多人在分析 AI 对未来产业的宏观影响，发觉有一个经典观点用在这里很合适：

人们总是倾向于高估新技术带来的短期冲击，却低估其长期影响

基于这个观点，我开始重新考虑 AI 对程序员行业的影响，然后我发现，AI 对我们，尤其是对于初级技术岗位应聘者的影响，远比很多人想象的大得多，甚至可以说，在没有其他因素影响的情况下，随着 AI 的发展，可能会导致初级技术岗位完全消失，靠吃程序员这碗饭逆天改命的阶级跃升通道可能会完全消失。

逻辑推导：为什么会得出这样的结论

我觉得 AI 对广义上的软件行业（包括互联网行业）造成的影响要分两部分看待：需求端影响和供给端影响。

需求端影响可能是大部分人都能想到的问题，即因为 AI 可以胜任大部分初级技术工作，AI “赋能”现有员工带来的生产力提升远超招招聘一个新人带来的边际效益，因此企业倾向于缩减初级岗位规模，导致初级技术岗位需求减少。

但是我想说的是，AI 不断进化给供给端（也就是学生，无论是来自社会还是来自大学）带来的影响恐怕更加严重，而且带来的影响可能是非常长远的，这是因为：AI 正在破坏传统式“稳扎稳打”的技术学习路径，强迫使用者产生路径依赖，进而逼迫其采用一种短视频式的碎片化学习方式进行学习，甚至不学习，而这种学习方式造就的所谓技术人员实际上在技术能力上完全被机器替代，成为 AI 的奴隶，而非其使用者

如果你不理解上面这段话，不妨可以想想看，在 LLM 诞生之前你是如何学习新知识，以及搜索技术解决方案的；而在 LLM 诞生后你又是如何做的。显然，由于 LLM 实在“太好用”，这可能会导致大部分学生丧失深度学习完整技术体系的能力：因为他们认为一旦有问题 LLM 就可以回答他们完美无缺的答案，甚至可以让 LLM 帮他们去写代码。

另一方面，对于高级技术人员来讲，他们只是拿 AI 作为研究和询问的辅助工具，在有足够技术知识背景储备的情况下，他们得以指出 LLM 回答中存在的明显问题，或是在实践中发现这些问题，但学生则完全不会这么做，他们只会照单全收，这种过度依赖 LLM 输出结果的趋势是十分可怕的。

结果就是，供给端的绝大部分人会完全失去满足需求端以及社会要求的，进入软件行业所需要的基础能力，进而完全被后者淘汰。

短期内，也许我们还没能看出学生在这种“大模型时代”发生的异变，但是长期来看，几乎可以确定的说，供给端影响可能会深刻改变这个行业的人才供应方式和流向，甚至可能造成严重的人才鸿沟。

结果分析：在这种情况下我们能做什么

首先，虽然上面说的很可怕，但实际上（国内）招聘市场也许并不会变得很恐怖，因为校招对于大部分公司来讲是一个政府的固定计划指标，无论学生的技术能力如何，岗位总量不会有很大的变化，而社招提供的初级技术岗位本来就已经所剩无几，再减少点也不会有很大的变化。

但是，即便如此，我还是要说，无论是初级学习者还是资深程序员，我们都一定要警惕这样的趋势，保住自己的核心优势，这并不是说要完全放弃使用 AI （否则就和因噎废食没什么区别了），而是说要懂得 AI 的边界和了解自身的核心能力。使用 AI ，而不是被 AI 使用，保持好奇心，不断提升自己的核心竞争力。只有这样，才能在不断的技术迭代和大时代下保住自己的饭碗，不被淘汰。

最近自己成功激活了一张 英国 giffgaff 预付费 SIM 卡 并把它用在 Stripe 手机号验证上，整个过程记录下来，帮助有同样需求的人少走弯路。

📍 什么是 giffgaff

giffgaff 是英国一家比较受欢迎的 预付费手机卡运营商，支持无月租、数据/短信/通话按需付费。它走的是 Pay-As-You-Go （随用随付） 模式，可以在全球接收短信验证码，适合做 手机号验证/接码 用。

🪪 一、我为什么用 giffgaff

✔ 支持接收短信验证码（比如 Stripe ）
✔ 可以长期保号，成本低（只要定期消费即可）
✔ 不需要英国本地开户、签证之类繁琐条件
✔ SIM 卡可以邮寄到国内 🇨🇳（慢但到）([知乎专栏][2])

🧩 二、激活和使用步骤（亲测可用）

1️⃣ 申请并收到实体 SIM 卡

从官方或社区领到免费/付费 SIM 卡，卡上会有激活码（ 6 位或更长）。

2️⃣ 打开激活页面

进入官方激活入口：
🔗 www.giffgaff.com

输入卡背面的激活码。

3️⃣ 注册账号

按照提示：

✔ 输入邮箱
✔ 设置登录密码
✔ 完成账号创建（以便将来登录管理）([知乎专栏][2])

4️⃣ 选择套餐 → 选 Pay as you go

页面有几个选项：
📌 Contracts （合约制）
📌 Monthly rolling （月租自动续费）
📌 Pay as you go （随用随付）

如果只是接验证码，不想月租浪费套餐期，就选择 Pay as you go （ 0 月租）。([知乎专栏][2])

5️⃣ 首次充值至少 £10

在激活过程中需要至少充值 £10 （首次激活要求）。
你可以：

💳 直接用支持 VISA/MasterCard 的信用卡充值
📜 或者用提前买好的 voucher 充值码 若没有海外卡也可用
（兑换方式通常是“redeem a top-up voucher”）

我当时正是用信用卡支付时在银行 App 里遇到了安全验证，需要在银行确认一下授权。通过确认后支付成功 → 页面显示 SIM 激活成功、生成新号码。

6️⃣ 插 SIM 卡到手机

激活成功后把卡插到手机卡槽，重启一下就能连上网络，大多数情况几分钟内生效。
如果没信号，多等一会或再重启试试。

☎️ 三、你现在可以做什么

🔹 你的英国号码已经生成，可以在 Stripe 等需要验证手机号的地方填写它。
🔹 只要能接短信，它就能收到验证码。
🔹 收短信对大部分国外服务来说都是免费的。

💡 四、小技巧与注意事项

🛠 如何长期保号（防止号码被停）

giffgaff 的 SIM 预付费卡如果 超过 180 天没有任何消费，号码可能被停用。所以建议：

✔ 每 6 个月内至少做一次轻微消费（例如发送一条短信就够了）
✔ 或充值再用一次流量
✔ 或使用一点数据任何动作就可续期

发短信是最省钱的方式（英国本地短信收费很低）。

💳 付款验证可能需要银行授权

有些支付会触发银行安全验证（如 3D Secure ），需要在你的银行 App 里同意付款才能完成充值（我在 HSBC App 里确认成功后才激活成功）。

📍 国际使用注意

✔ 如果在国内使用，短信、接码是可以的，
✔ 但发短信/打电话到国内会有成本（不建议用做日常通话）([皮普的数字花园][7])

✨ 总结

从 收到卡 → 激活 → 成功生成号码 → 在 Stripe 中接收验证码 的整个流程是：

📦 申请卡 → 💻 进入激活页面 → 🔑 输入激活码 → 📧 注册账号 → 💷 支付充值 → 📱 等待信号 → 🧾 使用接码

整个流程对我来说 没有太多技术难度，但关键是第一次支付验卡可能会遇到银行授权验证。只要完成支付，接短信是稳定可用的。

春节假期基本是和 openclaw 度过的…每天聊 N 小时…

发现不在电脑边，飞书对话 openclaw 经常遇到的问题就是讨论讨论着，他转身就闷头干活去了，好多时候就得等他回复才行…

于是我让他自己给自己撸了一个移动端控制台，可以随时看他在干啥，顺便开源了源码，欢迎大家 Star
👉🏻https://github.com/dreamwing/clawbridge

顺便整了个单页的官网，方便一键安装👉🏻https://clawbridge.app

全文链接：https://tecdat.cn/?p=44996
原文出处：拓端数据部落公众号

 

封面

在数字化商业时代，SaaS（软件即服务）企业的核心竞争力越来越依赖于对客户价值的精准判断。客户生命周期价值（CLV）作为衡量客户长期贡献的关键指标，其预测精度直接影响企业的获客成本控制、客户分层运营及资源投放策略。传统的CLV预测方法要么依赖简单的经验公式，忽略客户行为的非线性特征和时间动态；要么采用黑盒机器学习模型，虽能捕捉复杂模式却丧失了解释性，难以满足企业管理层的决策需求。
团队在为某SaaS企业提供数据咨询服务的过程中，发现量化生态学领域常用的广义加性模型（GAMs）在处理非线性、分层结构数据方面的优势，可有效适配CLV预测的业务场景。本研究将GAMs引入SaaS行业的CLV预测，结合Tweedie分布解决收入数据的异方差性问题，不仅实现了预测精度的提升，还能提取可解释的业务洞察，如客户升级阈值、功能采纳投资回报率等。
本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验，该项目完整代码与数据已分享至交流社群。阅读原文进群，可与800+行业人士交流成长。
本研究首先梳理SaaS业务的CLV预测痛点，随后通过模拟贴合真实业务的客户数据，构建基于GAMs的CLV预测模型，对比高斯分布与Tweedie分布的适配效果，最终提取可落地的业务决策建议。研究过程中所用到的方法和代码均经过实际业务验证，同时我们提供24小时响应的"代码运行异常"应急修复服务，相比企业自行调试效率提升40%，能快速解决模型落地过程中的技术问题。

一、SaaS业务下CLV预测的核心挑战

不同于传统软件的一次性授权销售模式，SaaS企业以订阅制为核心，客户按月或按年支付费用获取服务，这使得客户生命周期价值的计算和预测呈现出独特的业务特征：

  1. 获客成本与回本周期的平衡：SaaS企业获客成本通常远高于单月客户收入，例如单月付费99元的客户，若获客成本为500元，需至少6个月才能回本。精准的CLV预测能帮助企业识别高价值客户群体，确保获客投入的合理性。
  2. 客户行为的非线性特征：客户功能采纳率存在自然饱和效应（多数产品的功能采纳率难以突破90%），不同付费层级（基础版、专业版、企业版）客户的价值响应曲线差异显著，付费获客渠道的效果会随时间衰减，这些非线性关系是传统线性模型无法捕捉的。
  3. 数据的异方差性：高价值的企业版客户收入波动远大于基础版客户，传统高斯分布假设的等方差性与实际业务数据不符，会导致预测区间失真。

二、数据模拟与环境搭建

2.1 环境配置

首先加载建模所需的R语言包，涵盖GAMs拟合、数据处理、可视化及结果解释等功能，国内可直接通过CRAN镜像源安装，无访问限制，替代方案可选择国内的R语言镜像站或Anaconda仓库。

# 加载所需库library(mgcv) # 拟合带平滑项的广义加性模型library(tidyverse) # 数据处理与可视化library(marginaleffects) # 从GAMs中提取可解释的预测结果library(gratia) # GAMs的可视化与后验抽样library(scales) # 货币和百分比格式的坐标轴设置# 设置统一的绘图主题theme_set(theme_bw(base_size = 15, base_family = 'serif') + theme(panel.grid = element_blank()))

2.2 模拟真实SaaS客户数据

为验证模型效果，我们模拟100个客户5个月的行为数据，包含付费层级、获客渠道、功能采纳率等关键特征，目标变量为6个月CLV。模拟过程中融入SaaS业务的核心特征：功能采纳率饱和、付费渠道效果衰减、不同层级客户价值响应差异。

2.3 数据可视化探索

通过可视化探索数据特征，直观呈现功能采纳率与CLV的非线性关系、不同获客渠道的CLV时间趋势。


从上图可看出，功能采纳率与CLV的关系并非简单线性：企业版客户呈现明显的饱和效应，基础版客户接近线性增长，付费获客渠道的初期CLV更高，但高采纳率下优势逐渐消失。


时间趋势图显示：付费获客渠道的CLV在各层级均高于其他渠道，但企业版客户的付费渠道溢价（约2000元）远高于基础版；合作伙伴渠道在专业版客户中后期表现优于自然流量渠道，这为企业的获客渠道策略制定提供了直观依据。

相关文章

Python、R语言南方电网、电力负荷数据多模型构建：分位数回归、GAM样条曲线、指数平滑和SARIMA与预测实践

原文链接：https://tecdat.cn/?p=41810

三、广义加性模型（GAMs）构建与优化

3.1 基础GAMs模型（高斯分布+对数链接）

首先构建基于高斯分布的GAMs模型，采用对数链接函数确保预测值非负，模型包含付费层级的主效应、功能采纳率的全局平滑项、分层级的功能采纳率平滑项、分渠道的时间平滑项及全局时间平滑项。

模型结果显示，全局时间平滑项、自然流量和合作伙伴渠道的时间平滑项具有统计显著性，但高斯分布假设无法解决收入数据的异方差性问题——高价值客户的方差远大于低价值客户，这会导致预测区间的精度失真。

3.2 引入Tweedie分布优化模型

Tweedie分布是一类包含泊松-伽马复合分布的广义分布，其方差与均值满足Var(Y) = φ·μ^p（φ为离散参数，μ为均值，p为幂参数），能适配收入数据的异方差性：当1<p<2时，可处理含零值的正连续数据，且方差随均值增大而增长，贴合SaaS收入数据特征。
本研究中拟合的Tweedie模型幂参数为1.935，介于1和2之间，完美适配CLV数据特征。

模型对比结果显示，Tweedie模型的AIC值（7248.197）远低于高斯模型（8235.860），拟合效果显著更优。

3.3 模型结果可视化解读

3.3.1 功能采纳率的分层效应


上图结果显示：企业版客户在功能采纳率75%左右出现明显饱和，CLV增长停滞；专业版客户呈平稳增长，高采纳率下略有饱和；基础版客户在采纳率50%后CLV反而下降，推测是功能复杂度超出基础版客户的使用能力，导致体验下降。

3.3.2 获客渠道的时间效应


渠道时间趋势显示：付费推广渠道的CLV随时间下降，说明付费获客的客户粘性较低，促销激励消失后价值回落；自然流量和合作伙伴渠道的CLV持续增长，客户随使用时间增加逐渐挖掘产品价值，长期价值更高。

3.3.3 预测区间对比

# 可视化预测区间宽度对比pred_result %>% tidyr::pivot_longer(......) %>% # 省略数据重塑代码 dplyr::mutate(......) %>% # 省略变量重命名代码 ggplot(aes(x = clv_6month, y = interval_width)) + geom_point(aes(color = model), alpha = 0.5, size = 1.5) + geom_smooth(aes(color = model, fill = model), method = "loess", se = TRUE, alpha = 0.2) + scale_color_manual(values = c("darkblue", "darkred")) + scale_fill_manual(values = c("darkblue", "darkred")) + scale_x_continuous(labels = scales::dollar) + scale_y_continuous(labels = scales::dollar) + facet_wrap(~ model, scales = "free_y") + labs(x = "实际客户生命周期价值（元）", y = "95%预测区间宽度（元）") + theme(legend.position = "none")


从预测区间对比图可清晰看到：高斯模型的预测区间宽度恒定，无法反映高价值客户的高波动性；而Tweedie模型的预测区间宽度随CLV增大而增加，贴合业务实际，为企业的风险评估提供了更准确的依据。

四、业务洞察提取与落地应用

4.1 功能采纳率的投资回报率（ROI）分析

通过计算边际效应，量化功能采纳率提升对CLV的影响，为产品功能优化策略提供数据支撑。


边际效应分析结果显示：企业版客户的功能采纳率提升ROI最高，每提升10%的采纳率，CLV平均增加约200元；基础版客户的ROI最低，这提示企业应优先针对高价值层级客户优化功能体验。

4.2 客户升级阈值识别

确定基础版客户升级为专业版的最优采纳率阈值，为客户运营策略提供决策依据。基础版与专业版的月费差为200元，6个月的升级成本为1200元，需找到采纳率临界点使升级后的CLV增量覆盖成本。


分析结果显示：基础版客户的功能采纳率达到55%时，升级为专业版的边际收益超过升级成本，这一阈值可作为企业客户升级运营的核心指标——当基础版客户采纳率突破55%时，可推送升级方案，实现客户价值与企业收益的双赢。

4.3 场景规划：基础版客户价值提升策略

模拟优化基础版客户功能体验后的CLV提升效果，评估产品优化的投资回报。


场景模拟结果显示：优化基础版客户的功能体验后，平均每位客户的CLV可提升约1781元，投资回报率达3.52倍，说明针对基础版客户的功能简化、体验优化是高回报的产品策略。

五、研究总结与流程梳理

5.1 核心结论

  1. 广义加性模型（GAMs）可有效捕捉SaaS客户CLV的非线性特征，结合Tweedie分布能解决收入数据的异方差性问题，预测精度和区间可靠性显著优于传统高斯模型。
  2. 不同付费层级客户的功能采纳率-CLV关系差异显著：企业版客户存在饱和效应，基础版客户存在最优采纳率阈值，这为分层运营提供了依据。
  3. 获客渠道的长期价值差异明显：自然流量和合作伙伴渠道的客户价值随时间增长，付费推广渠道客户价值衰减，企业应优化获客渠道组合。

5.2 研究流程梳理

本研究将生态学领域的统计方法创新性应用于SaaS业务的CLV预测，实现了"精准预测+可解释洞察"的双重目标。

封面

Andrej Karpathy⼜造词了。

上⼀次是“vibe coding”——不看代码 ，⽤⾃然语⾔告诉 AI 你想要什么 ，它替你写。这个词从⼀条推⽂变成了全⾏业通⽤语。这⼀次他拎出来的词是 Claw。

他说了什么

Karpathy 发了条长推：买了台新 Mac mini ，准备周末折腾 OpenClaw——最近爆火的开源 AI Agent 项⽬，GitHub 上 20 万颗星。

OpenClaw 是什么？简单说 ，就是⼀个“住在你电脑⾥的 AI 助⼿ ”。 它不只是你问它答——它能⾃⼰读邮件、管⽇历、操作⽂件、跑脚本 ，你出门了它还在⼲活。你通过微信、Telegram、WhatsApp 这些聊  天软件跟它说话 ，它就去执⾏。

但 Karpathy 话锋⼀转 ，说⾃⼰⼼⾥有点打⿎：这东西有 40 万⾏代码 ，很⼤⼀部分是 AI“vibe coding”出来的——⼈都没细看过。 ⽽且正在被⿊客⼤规模攻击 ，实例被暴露、恶意代码混进插件市场的报告已经⼀堆了。他的原话：“彻底的蛮荒西部 ，安全噩梦。 ”

不只是 Karpathy⼀个⼈这么觉得。 NanoClaw 的作者 Gavriel Cohen 接受 The New Stack 采访时讲了个更具体的故事：装完 OpenClaw 那天晚上他没睡着。 Cohen 做开发的⼈，习惯审查每⼀个依赖 ，结果发现 OpenClaw 把他⾃⼰⼏个⽉前写的⼀个 GitHub⼩项⽬加进了依赖——只有⼏百颗星 ，好久没⼈维护。他说：“稍微做过代码审查的⼈看到这个包 ，都不应该往⾥加。 ”更离谱的是 ，他只让 Agent 监控⼏个 WhatsApp 群 ，结果它把所有 WhatsApp 消息都存进了本地数据库。

Cohen 在 NanoClaw 的 README⾥把 OpenClaw 的家底扒了个⼲净：52 个模块、8 个配置管理⽂件、45+依赖、15 个渠道的抽象层。 安全靠的是应⽤层的⽩名单和配对码 ，不是操作系统级的隔离。所有东 西挤在⼀个 Node 进程⾥ ，共享内存。 Cohen 说得很直⽩：“OpenClaw 让全世界看到了⼀个激动⼈⼼的东西 ，但 50 万⾏没⼈审查过的代码连着你的⼀切——这地基 ，你敢往上⾯盖楼吗？”

话说回来 ，Karpathy 说：但我喜欢这个概念。

他给了⼀个判断：Claw 是 AI 技术栈上的新⼀层。打个⽐⽅——ChatGPT 这类⼤模型是“顾问”，你问⼀ 句它答⼀句 ，不问就不动。AI Agent 是“执⾏者”，你给它⼀个任务 ，它⾃⼰拆解步骤、调⽤⼯具、把事 办了——但办完就下线了。 Claw 是“常驻员⼯ ”——不下线 ，有记忆 ，有⽇程 ，能⾃⼰安排事情、定时执⾏ 、 主动汇报。你睡了它还在⼲活。

那 Claw 和 Agent 到底什么关系？不是并列的两个东西——Claw 把 Agent 包在⾥⾯。Agent 是那个能⼲活的⼈ ，Claw 是给这个⼈配的办公室、 ⼿机、 ⼯作⽇志和排班表。往具体了说 ，Claw 在 Agent 之上加了⼏样东西：⼀个⼀直活着的进程（不是⼲完就退出）、⼀套调度机制（能⾃⼰定时触发任务）、消息路由 （统⼀对接各种聊天软件）、持久记忆（跨会话记住上下⽂）、 以及⼀个绑在具体硬件上的本地运⾏时（能碰你的⽂件和局域⽹设备）。 Karpathy 的原话是“a new layeron top of LLM agents”——不是替代 Agent ，是让 Agent 能“住下来“的那层基础设施。

⼀个⼩项⽬，为什么让⼤神兴奋

整条推⽂⾥信息密度最⾼的部分 ，是他聊⼀个叫 NanoClaw 的⼩项⽬ 。

NanoClaw 是 OpenClaw 的轻量替代品——体量不到 OpenClaw 的 1%。 Cohen 在 README⾸页第⼀句话就是：“同样的核⼼功能 ，8 分钟就能看懂的代码库。 ”核⼼代码只有⼏百⾏ ，整个项⽬⼤约 35000 个 Token ，只占 Claude Code 上下⽂窗⼝的 17%。每个 agent 跑在真正的 Linux 容器⾥ ，做到了⽂件系统级 的隔离。 Cohen 打了个⽐⽅： 哪怕发⽣Prompt 注⼊攻击 ，“爆炸半径也被死死限制在那个容器和对应的通信渠道⾥ ”——⽽OpenClaw 呢？你家庭群的 agent 和连着⼯作代码仓库的 agent 跑在同⼀个进程 ，共  享内存 ，中间没有任何操作系统级的墙。

35000token 这个数字为什么重要？因为 AI agent 可以⼀⼝⽓读完 NanoClaw 的全部代码 ，完全理解，直接上⼿写新功能。 OpenClaw 的 40 万⾏得跨好多个上下⽂窗⼝——⼈看不完 ，AI 也看不完。

Karpathy 特别喜欢两点。第⼀ ，代码少到“装得进我脑⼦ ，也装得进 AI 的脑⼦ ”——看得懂、查得清、改得动。第⼆ ，NanoClaw 有⼀个让他“有点炸脑”的设计：⽤skills 代替配置⽂件。

什么意思？举个例⼦。

传统做法：你想让 AI 助⼿接⼊Telegram ，得去改配置⽂件 ，填 API 密钥 ，写⼀堆判断逻辑——“消息从 Telegram 来⾛这条路 ，从微信来⾛那条路”。功能越加越多 ，配置⽂件越来越厚 ，最后配置本⾝变成了 ⼀坨谁都不想碰的怪兽。

NanoClaw 的做法：你跟 AI 说⼀句/add-telegram 。AI 读取这条“Skill”——其实就是⼀份说明书 ，告诉 AI“要接⼊Telegram ，改哪些⽂件、 怎么改”。然后 AI⾃⼰动⼿改代码 ，搞定。

不是⼈写配置 ，是 AI 照着知识改代码。

Cohen 管这套思路叫“Skills over Features”——技能优先于功能。 NanoClaw 明确不⿎励往主分⽀提交 新功能：你想加 Slack⽀持？别提 PR ，写⼀个 skill。 Cohen 说得⼲脆：“每个⼈应该只拥有跑⾃⼰agent 所需的那些代码。 它不是瑞⼠军⼑ ，是⼀个安全的底座 ，你通过跟 AI 对话来定制。 ”

Karpathy 从这⾥提炼出⼀句话 ，我觉得是整条推⽂最核⼼的洞察：

写⼀个最⼤程度可被改造的代码底座 ，然后⽤skills 把它变成任何你想要的样⼦。

原⽂：“the implied new meta is to write the most maximally forkable repo and then have skills that fork it into any desired more exotic configuration.”

说⽩了：最厉害的软件不是功能最多的 ，⽽是最容易被改成任何样⼦的。 

Karpathy 的回复⽐原推还猛

Cohen 在推⽂下⾯现⾝ ，解释了设计思路。他说 skills 系统像“shadcn for integrations”。

shadcn 是前端圈很⽕的 UI 组件库。别的组件库让你装⼀个包、通过参数配置来⽤；shadcn 是直接把源代码复制进你的项⽬——代码就是你的 ，想怎么改怎么改。⼀个组件就是加⼀个⽂件、改⼏个接⼊点，⼲净利落。

Skills 对“集成”做了⼀样的事：不是配出来的 ，是⻓在你代码⾥的。

Karpathy 接的这⼀句更猛。 他说这让他想起了深度学习⾥⼀篇经典论⽂——2017 年的 MAML。

MAML⼲嘛的？最通俗地说：普通的 AI 训练——拿⼀万张猫的图⽚ ，训练出⼀个识别猫的模型。换成识别狗？重新来。

MAML 的思路——不追求把“识别猫“练到极致 ，追求练出⼀个底⼦ ，不管丢过来什么新任务——猫、狗、花——只要看⼏个例⼦就能学会。 不当单项冠军 ，当最快上⼿的万能选⼿。

Karpathy 说他⼀直琢磨⼀个问题：这个思路搬到软件领域 ，对应的是什么？现在他看到了——最容易被 fork（复制并修改）的代码仓库。

NanoClaw 就是软件版的 MAML：不把功能堆到最全 ，把底座做到“谁拿到⼿ ，⼏步就能改成⾃⼰想要的样⼦ ”。

⼀句话：学会怎么学 ，⽐学会什么重要。容易被改 ，⽐功能⻬全重要。

这不只是理论。 Cohen 兄弟已经拿 NanoClaw 在跑⾃⼰的公司了。他们的 AI 营销公司 Qwibit 有个 NanoClaw 实例叫“Andy”，管着整条销售管线。Andy 每天早上 9 点⾃动汇报线索状态、分配当天任务。 ⽩天兄弟俩往 WhatsApp 群⾥随⼿转各种客⼾笔记、 邮件线索 ，Andy⾃⼰解析、更新知识库和数  据库、设好跟进提醒。 Cohen 说：“我不直接碰销售管线了 ，Andy 替我管。 ”——这就是 Claw 从概念变成⽇常的样⼦。

AI 时代 ，⽼规矩要改了

Cohen 在采访⾥还聊到⼏条很有冲击⼒的看法——做 NanoClaw 让他意识到 ，AI Agent 正在动摇程序员奉了⼏⼗年的⽼规矩。

“不要重复⾃⼰ ”（ DRY 原则）可能过时了。以前写代码贵 ，所以⼤家把通⽤逻辑抽成共享函数 ，改⼀ 处全局⽣效。但 AI agent 改共享函数的时候 ，改完就⾛ ，不会回头看下游有没有被波及。 反⽽是复制⼀ 份代码更安全——出了问题只炸局部。 Cohen 说：“维护重复代码的成本已经很低了。让 AI 跑⼀遍 ，同样的改动它会铺到所有地⽅ 。 ”

严格的⽂件⾏数限制也该松了。Cohen 早期给 Claude Code 设了 120⾏的上限 ，结果 AI 花在拆⽂件、 重构上的时间⽐写功能还多。现在的模型处理五百到⼀千⾏的⽂件毫⽆压⼒ ，旧规矩反⽽拖后腿。

代码不需要写得多漂亮。每隔三到六个⽉就有更好更便宜的模型出来 ，今天能跑就⾏——⼀年后更强 的 AI 会直接重写。 Cohen 说：“我们今天写的代码 ，不需要为了未来⼏年⽽存在。 ”

这⼏条加在⼀起说的是同⼀件事： 当 AI 成了写代码和维护代码的主⼒ ，软件⼯程的经典原则需要重新校 准——不是因为它们错了 ，是因为成本结构彻底变了。

为什么 Karpathy 坚持买 Mac mini 跑本地

推⽂最后有句话很多⼈⼤概直接划过去了：

有个实体设备被⼀个⼩幽灵“附⾝ ”，变成你的个⼈数字家庭⼩精灵 ，这件事在美学上就很让⼈愉悦。

这不是随⼝⼀说。 Karpathy 去年的年终总结⾥反复⽤ “ghost”（幽灵）描述 AI——⼤语⾔模型不是“慢慢进化出来的动物” ，是“被召唤出来的幽灵” ，智⼒形状很奇怪 ，某些⽅⾯像天才 ，某些⽅⾯像⼩学⽣。

早先这个“幽灵”住在云端 ，你得打开⽹站去找它。后来 Claude Code 出来了 ，“幽灵”搬进了你的终端，帮你写代码。现在 Claw⼜进了⼀步——“幽灵”住进了你家⾥⼀台⼩设备 ，连着你的智能灯泡、你的⽇历、你的聊天软件 ，⽩天替你处理杂事 ，晚上⾃⼰排明天的活。

Karpathy 选本地不选云端 ，不只是技术上的偏好 ，背后是⼀个⼀以贯之的态度：AI 应该是你拥有的、 你看得懂的、在你⾝边的东西——不是某家⼤公司的⿊盒⼦。 ⼏百⾏核⼼代码看得完 ，容器跑在我⾃ ⼰的硬件上 ，每个 skill 我能审查——都是这个态度的体现。

⼀个新品类正在成型

同⼀天 ，Python 界元⽼Simon Willison 发⽂确认：“Claw”正在变成⼀个⾏业术语 ，指代这⼀整类系 统。

这个品类⻓什么样？⼏条特征已经很清晰：

  • 跑在你⾃⼰的硬件上 ，不是别⼈的云服务；

  • 通过聊天软件交互——WhatsApp、Telegram、 Discord ，不⽤专⻔学⼀套新界⾯ .   不只是你问它答——它能⾃⼰安排任务、定时执⾏ 、 主动找你汇报；

  • 有持久记忆 ，知道你上周跟它说了什么；

  • 能⼒靠 skills 扩展 ，像装插件⼀样给它加新本事。

 

OpenClaw 是引爆点 ，但 Karpathy 真正在意的不是 OpenClaw 这个项⽬——安全上他说了不放⼼。他在 意的是这个品类背后的架构层。 NanoClaw、 nanobot、zeroclaw、 ironclaw、 picoclaw……⼀堆名字在冒 ，说明⼤家都在往同⼀个⽅向跑。

⽤Karpathy 的话把这个技术栈重新理⼀遍：⼤模型是顾问→ Agent 是执⾏者→ Claw 是常驻员⼯。

最后这⼀层刚刚⻓出来。很粗糙 ，安全问题⼀堆 ，Karpathy⾃⼰都说是蛮荒西部。但他的判断也很清楚：⽅向对了 ，剩下的是⼯程问题。

Cohen 最近上了趟 CNBC ，回来发推说了句更带劲的话：“整个产品品类正在被⼏⾏⽂字取代。监控⼀ 个⽹站的变化 ，以前是你每⽉花 8 美元订的 SaaS。现在就是⼀条 prompt。”

Claw ，就是让这条 prompt 住下来、⼀直跑下去的那层东西。

Karpathy 嘴上说着安全噩梦 ，⾝体很诚实——Mac mini 已经买了。

 

Karpathy 原帖：htps://x.com/karpathy/status/2024987174077432126

我平时做 web 开发，vue+java 为主。

2 个方案只简单使用过，对 opencode 的感觉是慢，有时候很简单的一个问题能思考好久好久才给出结果，但是优点是开源。

cc 的话只用过 claude api 版本，但是太贵了所以打算换国产模型。

V 友们给个建议呗，不知道该选择哪个。

⭐ GitHub : https://github.com/QuantClaw/QuantClaw | Apache 2.0 | C++17 | 324 tests ✅

最近在 Discord 上和 OpenClaw 聊得比较多，越聊越想把它搬到 C++ 上实现。于是花了些时间，通过在 Discord 上与 OpenClaw 聊天的方式用 C++ 17 从零复刻了一个版本------带 WebSocket 网关、Web 控制台以及 Discord/Telegram 接入。

image.png

目前 324 个单元测试已全部跑通。今天正式开源。

quantclaw-logo.png

*

🗣️ 故事的起点：在 Discord 上和 OpenClaw 聊天

OpenClaw 是一个挺有意思的开源 AI 项目，新年期间我一直在折腾它。日常就是在 Discord 里和机器人对话------理需求、聊想法，或者让它帮忙写点代码。

聊久了，职业病就犯了：OpenClaw 基于 TypeScript，功能很全，但运行时开销确实不小。我开始想：如果用 C++ 复刻一个，性能能压榨到什么程度？能不能跑在一台 2GB 内存的廉价小服务器上？

于是有了 QuantClaw------一个在对话中诞生，用 C++17 复刻的 OpenClaw。

*

🤔 为什么要用 C++ 复刻？

目前市面上的 AI 助手框架基本是 Python 或 TypeScript 的天下。开发效率虽高，但运行时占用的内存也多------一个空闲的 Node.js 进程通常要吃掉 50-80MB 内存，Python 甚至更多。

如果你打算在一台 2GB 内存的云服务器上 7x24 挂着私人 AI 助手，这部分内存开销就成了不得不考虑的资源成本。

QuantClaw 的做法是：全量 C++17 实现。

Node.js (OpenClaw)C++ (QuantClaw)
空闲内存~60MB~8MB
启动时间~2s<200ms
GC 停顿有无
分发形式庞大的依赖包单文件二进制

原生二进制运行，没有解释器开销和 GC 停顿，启动即就绪。内存占用降到了同类方案的 1/8 左右。

image.png

上图是我运行 QuantClaw 后的资源占用情况，其资源消耗极少。

*

📐 QuantClaw 是什么

QuantClaw 是 OpenClaw 生态的一个 C++ 原生实现。它兼容 OpenClaw 的工作空间标准（SOUL.md / USER.md / MEMORY.md）、技能系统（SKILL.md）以及 WebSocket RPC 协议，可以直接对接原有的前端和客户端。

简单说：这是一个更轻量、更高性能的私人 AI 助手后端。

*

🏗️ 架构一览

image.png

核心组件纯 C++ 实现，频道适配器（如 Discord）作为独立进程通过 WebSocket RPC 接入网关，保持了和 OpenClaw 一致的解耦设计。

*

🚀 启动：一行命令

git clone https://github.com/QuantClaw/QuantClaw.git
cd QuantClaw && mkdir build && cd build
cmake .. && make -j$(nproc)
./quantclaw gateway

网关启动很快，你可以看到各组件初始化的日志：

2quanclaw-log.png

从 MemoryManager 到 GatewayServer 初始化完成，整个过程不到 1 秒。

*

🖥️ Web 控制台

网关自带了一个简单的 Web 控制台。浏览器访问 localhost:18790 即可与助手对话：

3quantclaw-dashboard-chat.png

顶部显示实时连接数、运行时间等状态信息。下方聊天界面支持 Markdown 渲染。

4quantclaw-dashboard-status.png

后台提供了 12 个 REST API 端点，方便通过 curl 或其他工具集成到自动化流里。

*

🎮 Discord 频道接入

这是 QuantClaw 诞生的初衷。在配置里填入 Token，网关会自动拉起适配器进程：

{
  "channels": {
    "discord": {
      "enabled": true,
      "token": "YOUR_DISCORD_BOT_TOKEN"
    }
  }
}

接入后的对话效果：

5quanclaw-discord-chat.jpg

消息流转逻辑如下：

image.png

日志会记录每一轮 RPC 调用的链路，方便排查消息流转状态：

6quantclaw-discord-chat-log.png

*

🔌 多模型支持

QuantClaw 支持通过 provider/model-name 前缀进行路由：

{ "model": "openai/Qwen3-32B" }
{ "model": "openai/gpt-4o" }
{ "model": "anthropic/claude-sonnet-4-6" }

兼容 OpenAI 格式的接口基本都能无缝接入。

*

📦 功能清单

image.png

目前 324 个单元测试全绿通过 ✅

*

🔧 技术栈

纯 C++17 实现，核心依赖如下：

image.png

*

⚡ 快速上手

Ubuntu / Debian：

sudo apt install build-essential cmake libssl-dev \
  libcurl4-openssl-dev nlohmann-json3-dev libspdlog-dev zlib1g-dev

git clone https://github.com/QuantClaw/QuantClaw.git
cd QuantClaw && mkdir build && cd build
cmake .. && make -j$(nproc)
./quantclaw_tests   # 跑一遍测试
./quantclaw gateway # 启动

*

✍️ 写在最后

QuantClaw 的想法起得很简单------在 Discord 里聊着聊着，就想写个更轻、更快的 C++ 版本。从第一行代码到 324 个测试跑通，这个过程也是一次有趣的 AI 协同实践。

目前的版本是 v0.2.0，核心功能已经跑通。如果你也在找一个轻量、低开销的私人 AI 后端，欢迎尝试。

⭐ GitHub : https://github.com/QuantClaw/QuantClaw

License: Apache 2.0.

机械组装MES——AI智能排产与预测驱动的生产革命

在工业4.0深度渗透与消费需求个性化升级的双重驱动下，离散制造业正从“规模化量产”向“多品种、小批量、快迭代”的柔性生产转型。对于机械组装企业而言，如何破解生产协同难题、提升柔性制造能力，成为关乎生存与发展的核心命题。

万界星空科技MES系统以AI智能排产与预测为核心竞争力，帮助众多机械组装企业实现从“数字化”到“智能化”的跨越式升级。

一、机械组装行业的核心痛点

在介绍万界星空MES之前，我们先来看看机械组装企业普遍面临的生产挑战。首先是生产计划混乱，订单变更频繁、插单多，传统排产依赖人工经验，难以协调设备、物料、人员等资源。其次是过程不透明，车间状态往往呈现“黑盒化”，进度反馈滞后，异常处理缓慢。

质量追溯困难也是另一大痛点，一旦漏装零件，整机返工损失数万元，且难以精准追溯问题源头。此外，交付延期风险高企，设备交付延期往往导致客户索赔接踵而至。最后，工艺过度依赖人工，装配依赖老师傅经验，新人上手慢，关键步骤执行偏差大。传统靠Excel排产、纸质单据流转、人工报工的管理模式，早已难以支撑高质量、快交付的竞争需求。

二、万界星空MES的AI智能排产核心能力

2.1 高级计划与排程（APS）——计划管理的“大脑”

万界星空MES的智能排产系统绝非简单地接收ERP生产订单，而是将ERP下发的月计划、周计划，基于车间的实际资源状况和工艺路径，分解成日计划、班次计划，甚至精确到每个设备、每个人员、每分钟的作业指令。

其核心算法技术包括约束理论，综合考虑设备能力、人员技能、物料可用性、工装模具等约束条件；遗传算法，通过迭代优化找到最优排产方案；以及强化学习，自主优化生产序列，持续学习改进。

2.2 智能排产三大核心功能

智能排产引擎主要包含智能分析、实时监控和自动调度三大核心功能。

在智能分析方面，系统通过收集和分析生产过程中的数据，能够分析哪些工序需要生产、哪些需要采购，帮助企业做出更合理的决策。

在实时监控方面，系统实时监控设备运行状态、工艺参数等，及时发现生产过程中的异常和问题，并通知相关人员进行处理。

在自动调度方面，当同行还在靠“人工喊单”调度生产时，实现“工单自动流转、异常秒级响应”。系统能够自动进行工单流转、秒级响应异常以及动态调配资源。

三、AI预测功能——从“事后响应”到“事前预防”

3.1 生产进度预测

MES基于历史数据和实时生产状态，精准预测订单完成时间，让管理层能够提前识别延期风险，主动向客户更新交付预期，并合理调整生产优先级。

3.2 质量预测与预警

系统通过机器学习算法分析生产过程中的关键参数，提前预测质量风险。它能够识别可能导致质量偏差的工艺参数组合，在质量问题发生前发出预警。结合基于视觉识别的自动检测技术，准确率可达98%以上。

3.3 设备预测性维护

通过采集设备运行数据，AI算法能够预测设备故障发生概率，提前安排维护计划，避免非计划停机，从而延长设备使用寿命，降低维护成本。

3.4 物料需求预测

系统智能分析生产计划与BOM结构，自动计算物料需求。它能预测未来周期的物料消耗，提前触发采购申请，有效避免物料短缺导致的生产中断。

四、万界星空MES的差异化优势

MES具备多项核心优势。可自由修改、二次开发。其次是多端适配，支持PC端、Android端、触控屏端、PDA端。其模块化架构灵活扩展，适配离散制造多种场景。采用低代码配置，利用AI拖拽即可实现与ERP、OA、PLC等第三方系统集成。同时，系统注重数据安全，提供端到端数据加密及关键字段级权限控制。

五、典型应用场景

5.1 机械装备组装

一台数控机床包含上千个零部件，MES通过电子作业指导书（eSOP）加工艺防呆机制，自动推送3D装配动画、扭矩参数至工位终端，并对关键工序强制扫码验证物料批次，确保组装准确无误。

5.2 汽车零部件生产

面对多品种小批量生产挑战，AI算法综合考虑订单交期、工艺路线、设备产能，动态生成最优生产计划，并实现质量全程追溯。

5.3 电子设备组装

针对SKU庞大、定制化需求高的特点，系统支持非标或定制化工单的BOM与工艺路线绑定，实时掌握订单进度、设备状态、在制品数量，并能准确预估交货期。

六、客户价值与成效

MES帮助企业实现了显著的价值提升。生产效率提升了30%以上，按时交付率显著提升，质量追溯达到分钟级定位，库存周转优化了20%以上。更重要的是，管理决策实现了数据驱动，告别了以往“拍脑袋”的决策方式。

在智能制造的浪潮中，MES系统已不再是“可选项”，而是机械组装企业实现数字化转型的“必选项”。万界星空科技MES系统以其AI智能排产与预测的核心能力，正在帮助越来越多的企业打破产线“黑箱”，迈向智能决策新时代。

如需了解更多详情或获取案例演示，可联系我们为您提供定制化的解决方案。

OpenAI 最近发布了Codex应用服务器的详细架构描述，这是一个双向协议，它将 Codex 编码智能体的核心逻辑与其各种客户端界面解耦。应用服务器现在支持每一个 Codex 体验，包括命令行界面（CLI）、VS Code 扩展、Web 应用、macOS 桌面应用，以及来自 JetBrains 和苹果 Xcode 的第三方 IDE 集成，通过一个单一、稳定的 API 实现。

 

这篇文章由 OpenAI 工程师Celia Chen撰写，是一系列详细介绍开源 Codex CLI 内部结构的文章之一。正如 Chen 所描述的，智能体交互与简单的请求/响应交换有着根本的不同：

 

一个用户请求可以展开成一个结构化的动作序列，客户端需要忠实地表示：用户的输入、智能体的增量进度、沿途产生的工件。

 

Codex 应用服务器的内部架构：标准输入输出（stdio）读取器和 Codex 消息处理器将客户端的 JSON-RPC 请求转换为 Codex 核心操作，并将内部事件转换回稳定的、UI 就绪的通知（来源）。

 

为了对此进行建模，OpenAI 设计了三个对话原语。项（Item）是输入或输出的原子单位，具有明确的生命周期：“开始”（started）、可选的流式“增量”（delta）事件和“完成”（completed）。这可以是用户消息、智能体消息、工具执行、审批请求或差异。轮次（Turn）将由单个智能体工作单元产生的项序列分组，由用户输入启动。一个线程（Thread）是正在进行的会话的持久容器，支持创建、恢复、分叉和存档，并保留事件历史记录，以便客户端可以在不丢失状态的情况下重新连接。

 

该协议还支持服务器发起的请求。当智能体在执行命令之前需要批准时，服务器会向客户端发送请求，并暂停轮次，直到收到“允许”或“拒绝”的响应。通信使用JSON-RPC作为 JSONL 流式传输在stdio上，OpenAI 将其设计为向后兼容，以便旧版客户端可以安全地与新版服务器通信。

 

值得注意的是，OpenAI 在最终确定这个设计之前尝试并拒绝了模型上下文协议（MCP）。Chen 解释说，在构建 VS Code 扩展时，团队最初尝试将 Codex 作为MCP服务器公开，但“在 VS Code 中维护 MCP 语义以使其有意义被证明是困难的。”IDE 交互所需的更丰富的会话语义，如流式差异、审批流程和线程持久性，并没有干净地映射到 MCP 的工具导向模型上。OpenAI 仍然支持将Codex作为 MCP 服务器运行以适应更简单的工作流程，但建议使用应用服务器来实现全保真集成。

 

带有可选批准的工具执行的协议消息流。服务器暂停轮次并向客户端发送请求，客户端必须在智能体可以继续之前用“允许”或“拒绝”响应（来源）。

 

文章描述了客户端用于嵌入应用服务器的三种部署模式。像 VS Code 扩展和桌面应用这样的本地客户端捆绑一个特定于平台的二进制文件，将其作为子进程启动，并保持一个双向的标准输入输出通道开放。像 Xcode 这样的合作伙伴通过保持客户端稳定而指向更新的应用服务器二进制文件来解耦发布周期，允许他们采用服务器端改进而无需等待客户端发布。

 

Codex Web运行时采取了不同的方法：一个工作器配置一个容器，在其中启动应用服务器，浏览器通过 HTTP 和服务器发送事件进行通信——保持浏览器端 UI 轻量级。同时，对于长时间运行的任务，服务器仍然是数据源。

 

应用服务器的演变与更广泛的行业努力以标准化代理-编辑器通信相平行。由 Zed Industries 发起现在由JetBrains支持的智能体客户端协议（Agent Client Protocol，ACP）采取了互补的方法：OpenAI 的应用服务器是特定于 Codex 框架的协议，而 ACP 旨在成为连接任何编码智能体到任何编辑器的通用标准，直接类比于十年前通过语言服务器协议（Language Server Protocol）标准化语言工具的方式。Codex CLI 本身也被列为 ACP 兼容智能体之一。这些方法的共存反映了行业仍然在为智能体集成确定正确的抽象边界——一个 OpenAI 承认正在“快速演变”的空间。

 

Codex 应用服务器的所有源代码都可以在开源Codex CLI存储库中找到，协议文档包括用于 TypeScript 和 JSON Schema 的模式生成工具，以方便使用任何语言进行客户端绑定。

 

原文链接：

https://www.infoq.com/news/2026/02/opanai-codex-app-server

Matrix 首页推荐 

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。 

文章代表作者个人观点，少数派仅对标题和排版略作修改。

时光回溯至 2023 年，当时我开启了《生产力祛魅》系列的创作。那是一个效率工具大爆发的年代，如 Notion 等各种时兴工具开始崭露头角，SaaS（软件即服务）模式成为了市场主流。那个系列受到了许多朋友的关注，我们相互交流、探讨，受益颇多。

转眼来到 2026 年，时隔差不多三年时间。我回看在《生产力祛魅》中提出的论断，发现它们不仅没有过时，反而愈来愈重要。

在目前这个 AI「横行」的年代，一套能够持续运行、真正服务于人的生产力工作流，必须要死守这三个严苛的条件：

  • 本地化（Local-First）： 数据必须物理地存在于我的硬盘上。任何必须联网才能打开、必须登录才能查看数据的工具，都不能作为核心生产力工具，只能作为临时管道。
  • 稳定性（Stability）： 绝对不将云软件作为主要工具，工具应当像锤子和扳手一样，十年如一日地保持其功能预期。
  • 可迁移性（Transferability）： 数据必须是通用的格式（Markdown、PDF、纯文本等）。

虽然核心论据未变，但随着技术的迭代（尤其是 Docker 容器化技术的普及和本地 AI 模型的轻量化），我所利用的软件还是有所变化。

因此，我想借这篇文章，以一个在读硕士研究生暨文字工作者的视角，剥离掉协作功能（如 n8n 自动化流、团队协作 IDE 等），单纯地谈谈：一个人，一台电脑，如何构建一个不依赖外界、坚不可摧的「数字作坊」。从某种角度来说，我的「本地工作流」更像是一个纯粹的个人文字工作者如何安排、布置自己的「全天工作」。

办公工作流

在我的数字版图中，「办公」并非指在公司上班，而是指维持我个人数字生活正常运转的基础设施，这包括了网页浏览、数据存储、云盘软件等。虽然我的软件不少，但大多数都不会打开。真正作为「入口」和「中枢」的，依然是那些具有强大的「集聚」效应的工具。

图 1：办公、日常和云盘软件（1）
图2：办公、日常和云盘软件（2）

在图 1 和图 2 中展示的众多软件里，DEVONthink 是绝对的核心。它是一个本地文件管理器，DEVONthink 原本支持OCR，我可以将各种文件放进去，尤其是在处理大量非结构化数据（如古籍扫描件、学术论文 PDF、网页存档）时，它会将其 OCR，我可以搜索所有文件及其文本。这种无需联网的本地化智能，保障了研究的隐私性与连贯性。See Also、Graph 等功能则为文件、文本之间的联系进行了更为直观地展示。

我的浏览器软件很多，但是主力是 Arc 浏览器，Chrome、Edge、Safari 等主要是以备不时之需。Arc 浏览器的工作区（Spaces）功能，让我感觉很舒服。我可以建立学术、日常、娱乐等不同的工作区，让我能够更加专注于特定事物。

我原来的主力是 Chrome，因为其中有许多书签，我一直没有找到很好的替代品。Arc 并不太能够支持大量书签的处理，这使我陷入了进退维谷的境地。后来我发现 OneNav（https://github.com/helloxz/onenav）项目，通过用 Docker 搭建 OneNav，然后将所有书签都导入进去，构建了一个独立的、标准化的导航索引库，将书签数据从浏览器端剥离。不论我使用何种浏览器，都可以应用这套导航索引库。分门别类，十分方便。

图 3：OneNav 展示（1）
图 4：OneNav 展示（2）

如图所示，虽然我有很多邮箱软件，但是我日常只用 Thunderbird。

Thunderbird 的优势在于遵循了 POP3、IMAP、SMTP 等各种标准协议，以及丰富且透明的插件生态，其中有许多好用的插件（例如邮件流）。我将分散于 Google、Microsoft Outlook、腾讯、网易等服务商的邮件都汇聚在 Thunderbird，其本地数据库能够永久保存我的通讯记录。

图 5：Thunderbird 展示

至于 Microsoft Office 365、云盘等软件，在此不过多赘述。值得分享的是 OmniFocus，其实有许多朋友都分享、介绍过这款软件。在我看来，我不会用很花里胡哨的方式去使用它。我将它视作加强版本的日历软件，例如如图所示的「每周计划」「专业活动」等。「每周计划」是我每周要提醒自己做的事情，每天早上起来略览一遍，便清楚一周的计划。「专业活动」则是与学术会议等学术活动有关系，例如我何时投稿了某个学术会议，包括其后续情况等。

图 6：OmniFocus 展示

信息工作流

第二个工作流是信息工作流。过去的一年，我经常推荐 Follow（Folo）这款软件，认为它是目前最适合 RSS 阅读的软件。但是在 2025 年 10 月左右，Folo开始收费。

其实我很理解软件收费，也愿意付费，然而 Folo 较为高昂的订阅制收费确实令我望而却步。结合 Folo 那时候的更新并不符合我的审美取向，对原来签到虚拟币的弃置等诸多原因，我还是放弃使用 Folo，转而继续使用 Reeder，并且自行搭建 Rsshub。

图 7：Reeder 展示（1）
图 8：Reeder 展示（2）

从 Bilibili、YouTube 等视频网站，再到 Telegram、豆瓣、X 等平台资讯，以及学术方面的 CNKI 期刊等，搭建 Rsshub 的 Reeder 都能够支持。虽然没有 AI 翻译等功能，但是已经能够满足我的需要。

除 Reeder，我还搭建了 NewsNow（https://github.com/ourongxing/newsnow）作为重要的新闻资讯来源。NewsNow 是 Github 上的开源项目，很方便就可以用 Docker 进行本地搭建。该软件能够以高密度的文本看板形式呈现全球资讯，很方便我在碎片化时间进行快速浏览，

图 9：NewsNow

关于信息的收纳与整理，我个人的见解是：除非必要，否则不用在意，注意断舍离。之前我还经常将所看到的、颇为重要的信息以 PDF 形式进行保存。随着时间的流逝，我发现这毫无意义。有些朋友认为可以用 AI 工具辅助信息的收纳与整理，确实如此，但关键处在于要收纳与整理「重要信息」，而非全盘吸收，否则会被大量的信息「摧残」，进而不堪其扰，陷入摆烂状态。对此，其实我个人的观点是：对于重要信息（学业、职业、商业等各种相关），专门建立相应的笔记文件夹，并且要写日记，记录自己的感受感想。以此为基础，可以利用 AI 大模型等进行处理，建构个人的知识库。除此，其余信息均无记录必要。

生产工作流

之后是涉及到阅读、创作、研究等流程的生产工作流。Anytype 这一软件我曾撰写专文进行介绍，它主要用来记录我所投稿的期刊，里面记录着期刊的各种信息，辅助我进行投稿等。不同于传统笔记软件的文档逻辑，Anytype 允许用户自定义「对象类型」。例如我创建了「期刊」模板，里面包含影响因子、期刊级别、审稿周期等各种类型。

图 10：阅读、创作和研究软件

以 Acrobat 为代表的阅读类软件，则是根据场景、用途的差异进行使用。

Endnote、Scrivener、Tropy 是我的三大主力创作工具，构成了我重要的学术知识生产工作流。我所有的写作都是以「项目」作为基准，然后在 DEVONthink 内进行归档。接下来，我将详细介绍这个流程：

当我想要写作某篇文章时，我会用 Scrivener 建立一个新项目。Scrivener 内置各种形式的模板，并且支持各种形式的资料导入。Scrivener 的「活页夹」逻辑允许将长篇文章拆解为独立的文本块，支持非线性的跳跃式写作，对学位论文等长篇文章写作有很好的支持效果。

图 11：Scrivener 展示（1）

例如当我利用 Endnote 导入各种书籍、论文时，我可以直接将 Endnote 里的相关资料拖入 Scrivener 建立一个书签。当我想要看相关资料时，直接打开书签预览即可。除此，Scrivener 还支持快照（我在本科论文写作时改了二十个版本，因此产生了二十个文档。通过 Scrivener，就不会有这么多文档，对照不同快照也很便利）、批注、引文、参考文献等各种功能。

图 12：Scrivener 展示（2）

针对学术研究中大量的档案扫描件与图片资料，一般图像软件其实并没有很好的支持，例如元数据标注需求（馆藏号、年代、作者等）。Tropy 是一个免费、开源的软件，专门用于组织与处理图像，还支持图文对照录入，极大地提升了图像整理的精确度。我还会将我所利用的重要图像存储于 Tropy，当我写作时，通过拖拽等动作，我可以同 Scrivener 建立与 Endnote 相同的链接。

当我完成文章后，我会将它们统一放到 DEVONthink。每个项目都会内置相应的文件夹：（1）草稿、正文及构思；（2）草稿及正文所配图像；（3）参考资料；（4）投稿发表；（5）见刊文件等。

在「草稿、正文及构思」文件夹，我会放置我的 Scrivener 写作文件，及其所导出的 Word、PDF 等各种格式文件。在「草稿及正文所配图像」文件夹，我会放置我在正文中利用的图像，这些图像或多或少经过处理。在「参考资料」文件夹，我会将 Endnote、Tropy 这两个资料包放进去。

经过这一套流程，我写作的每篇文章都有迹可循，并且所有原始材料都能够完整保存。虽然我主要用这套工作流进行学术创作，但我认为这套工作流能够适配各种各样的写作任务，比较具有普适性。

总结

综上所述，我认为这套通过剥离非必要的云端协作依赖，坚持以「本地化、稳定性、可迁移性」为核心锚点的工作流，是我反复尝试过后的「当下最优解」。

无论是用 Docker 搭建 OneNav、RSSHub、NewsNow 等项目，还是使用 Thunderbird、Tropy等开源软件，其目的都在于一个纯粹的目标：在一个 AI 技术、云服务大肆发展的数字世界中，每个人都有必要开辟出一块完全属于自己的、利于深度思考与知识生产的自治领地。 这便是对生产力祛魅的最深刻实践。

编者注：文章封面使用 AI 生成，并经过人工修改。

> 关注 少数派小红书，感受精彩数字生活 🍃

> 实用、好用的 正版软件，少数派为你呈现 🚀

    go-sail 是什么？

    go-sail 是一个轻量的渐进式 Web 框架，使用 Go 语言实现。它并不是重复造轮子的产物，而是站在巨人的肩膀上，整合现有的优秀组件，旨在帮助使用者以最简单的方式构建稳定可靠的服务。 正如它的名字一般，你可以把它视作自己在 Golang 生态的一个开始。go-sail 将助力你从轻出发，扬帆起航。

    仓库地址

    https://github.com/keepchen/go-sail/

    LATEST_VERSION

    如何使用

    推荐 go version >= 1.23

    复制
    go get -u github.com/keepchen/go-sail/v3
    复制
    import (
    "net/http"
    "github.com/gin-gonic/gin"
    "github.com/keepchen/go-sail/v3/sail"
    "github.com/keepchen/go-sail/v3/sail/config"
)

var (
    conf = &config.Config{}
    registerRoutes = func(ginEngine *gin.Engine) {
        ginEngine.GET("/hello", func(c *gin.Context){
            c.String(http.StatusOK, "%s", "hello, world!")
        })
    }
)

func main() {
    sail.WakeupHttp("go-sail", conf).Hook(registerRoutes, nil, nil).Launch()
}

    示例

    配置读取

    复制
    parseFn := func(content []byte, viaWatch bool){
    fmt.Println("config content: ", string(content))
    if viaWatch {
        //reload config...
    }
}
etcdConf := etcd.Conf{
	Endpoints: []string{""},
	Username: "",
	Password: "",
}
key := "go-sail.config.yaml"

sail.Config(parseFn).ViaEtcd(etcdConf, key).Parse(parseFn)

    链路日志追踪

    复制
    func UserRegisterSvc(c *gin.Context) {
  ...
  sail.LogTrace(c).Warn("log something...")
  ...
}

    JWT 认证

    • 颁发令牌
    复制
    func UserLoginSvc(c *gin.Context) {
  ...
  uid := "user-1000"
  exp := time.Now().Add(time.Hour * 24).Unix()
  otherFields := map[string]interface{}{
      "nickname": "go-sail",
      "avatar": "https://go-sail.dev/assets/avatar/1.png",
      ...
  }
  ok, token, err := sail.JWT().MakeToken(uid, exp, otherFields)
  ...
}
    • 认证
    复制
    func UserInfoSvc(c *gin.Context) {
  ...
  ok, claims, err := sail.JWT().ValidToken(token)
  ...
}

    组件

    响应器

    复制
    func UserInfoSvc(c *gin.Context) {
  sail.Response(c).Wrap(constants.ErrNone, resp).Send()
}

    数据库

    • 读写分离
    复制
    func UserInfoSvc(c *gin.Context) {
  uid := "user-1000"
  var user models.User
  //READ: query user info
  sail.GetDBR().Where("uid = ?", uid).First(&user)
  ...
  //WRITE: update user info
  sail.GetDBW().Model(&models.User{}).
      Where("uid = ?", uid).
      Updates(map[string]interface{}{
          "avatar": "https://go-sail.dev/assets/avatar/2.png"
      })
}
    • 事务
    复制
    func UserInfoSvc(c *gin.Context) {
  uid := "user-1000"
  err := sail.GetDBW().Transaction(func(tx *gorm.DB){
      e1 := tx.Model(&models.User{}).
              Where("uid = ?", uid).
              Updates(map[string]interface{}{
                  "avatar": "https://go-sail.dev/assets/avatar/2.png"
              }).Error
      if e1 != nil {
          return e1
      }
      e2 := tx.Create(&models.UserLoginHistory{
                Uid: uid,
                ...
              }).Error
      return e2
  })
}

    Redis

    复制
    func UserInfoSvc(c *gin.Context) {
  ...
  sail.GetRedis().Set(ctx, "go-sail:userInfo", "user-1000", time.Hour*24).Result()
  ...
}

    计划任务

    • 周期性的
    复制
    func TodoSomething() {
  fn := func() { ... }
  sail.Schedule("todoSomething", fn).Daily()
}
    • Linux Crontab 风格的
    复制
    func TodoSomething() {
  fn := func() { ... }
  sail.Schedule("todoSomething", fn).RunAt("*/5 * * * *")
}
    • 竞态检测
    复制
    func TodoSomething() {
  fn := func() { ... }
  sail.Schedule("todoSomething", fn).Withoutoverlapping().RunAt("*/5 * * * *")
}

    分布式锁

    复制
    func UpdateUserBalance() {
  if !sail.RedisLocker().TryLock(key) {
      return false
  }
  defer sail.RedisLocker().Unlock(key)
  ...
}

    文档

    https://go-sail.dev

    在线示例

    https://nav.go-sail.dev

    功能特性

    • HTTP 响应器
      • 统一响应字段
      • 管理 HTTP 状态码
      • 管理业务码
    • 组件库
      • Database
      • Email
      • Jwt
      • Kafka
      • Logger
      • Nacos
      • Etcd
      • Nats
      • Redis
      • Valkey
    • 服务注册与发现
      • Nacos
      • Etcd
    • 工具类
      • 加解密
      • 文件
      • ip
      • 字符串
      • 随机数
      • 日期时间
      • ...
    • 日志收集与导出
      • 本地文件
      • 导出器
        • Redis
        • Kafka
        • Nats
    • 计划任务
      • 可取消的
      • 一次性的
      • 周期性的
      • Linux Crontab 风格的
      • 竞态检测
    • 遥测与可观测性
      • 调用链追踪
      • Prometheus
      • Pprof
      • 日志导出器
      • 性能监测
        • Prometheus
        • Pprof
    • 接口错误码
      • 动态注入
      • 国际化
    • 基于 Redis 的分布式锁
      • 阻塞式
      • 非阻塞式
    • 接口文档
      • Redocly
      • Swagger
    • 配置管理
      • File
      • Etcd
      • Nacos

    其他

    • 欢迎大家提 PR: pull request
    • 欢迎大家提出自己的想法: issue
    • 感谢你的 star 如果你喜欢这个项目的话 :)

    说说新年快乐的事情和收获

    先说说开心的事情， 大年初一祭祖回来以后，堂兄弟就一起去堂哥家玩梦幻喝酒聊天。媳妇由于上火，没出门， 聚会完回家以后她要我陪她出去逛逛。

    1. 初一 出门的时候， 我打算带她去我们祭祖的山上逛逛，老妈建议我们往城南走走，说今天财神在南方。 然后我俩听劝，小侄女要跟，小侄子不去，我们往南一路遛弯。我俩路上一直在聊天，小侄女前后乱跑， 走到去游乐园的路口， 由于我们年前去玩了， 媳妇想过去再看看。 我说这会人应该很少， 我们不如去年货市场看看怎么样，年前一直没去， 回来以后想去再去看看。 然后就继续往前走了，刚过了一个路口， 小侄女就蹲下喊有钱， 我跑过去一看 她收里举着一张卷成小卷的 100 块。 旁边两米远的地方，花坛边俩大爷在晒太阳，还有个年轻人在打电话。

    媳妇说真的有财神哎，就说真巧，要不是媳妇要出来逛；老妈建议往南走走；小侄女平常都是和侄子看动画片，非要跟来；十字路口我又建议往前走走；小侄女仔细探索，差一个我们都捡不到。然后就决定立刻花掉，我们每人花 30，剩下的 10 块给老妈。
    然后就直接去找超市，小侄女买了两种零食各三份回去给其他姐弟，我到一个新商场的超市买了些半斤麻子，和超市卤制的鹌鹑蛋。 媳妇直接路边+10 买了只烧鸡，我们仨蹲店门口 当场手撕了。

    1. 初二 快中午的时候 媳妇刷抖音，说有个那种城市里所谓 9D 海盗买冒险电影的我们县也有一家，要去体验下。之前在帝都商场一场 40， 两人得 80， 觉得糊弄小孩的就没去，这边一场 25，说去看看。 然后就导航出门，3 分钟到达，发现就是昨天我买鹌鹑蛋的新商场.
      体验完以后也就觉得值 20 吧, 完事不回去第二次, 大过年人还是挺多的还要排队. 商场刚开业, 四层也就开了四五个点, -1 层超市和 9D 电影,, 1 层有个买衣服和抓娃娃的, 3 层有个疯狂派对电动城,和火锅店.
      然后转了会准备回去了, 媳妇说要去电动城看看, 我知道那里边玩不赢,说了不去,她说过年 没事转转就走. 进去以后就不得了了.

    看了会骑摩托的要 5 币, 转了会她想玩,我就去前台买币, 39.9 才 80 游戏币,老贵了. 288 才 1000 个币, 3000 块 1w 币.
    然后就扫码买了 80 个, 给媳妇骑了会动感摩托, 转过头就看到一个推游戏币塔赢彩票的, 彩票可以兑换毛绒玩偶.有个小女孩推的可厉害了.一会推掉了三个 1000 游戏币的塔. 于是我想起之前团建, 可以推游戏币塔赚游戏币的, 问了下店员, 说有个小火车,
    我就喊媳妇过去,完了两把不懂,然后旁边有个小孩哥,赢了两筐游戏币. 我俩就站旁边看了会,然后大致看懂了规则, 然后自己琢磨了下套路. 但是这会没游戏币了, 转头我想再去买的,结果发现注册会员, 会有一个 30 币的优惠券,可以直接领 30 币.
    我就领了 30 个媳妇, 当然很快又没了.

    过了会我寻思应该是新号都有,就喊她也扫码,我换微信也试了下,一共领了 60 个去赚币, 运气不错, 熟了一般的时候, 媳妇摇中了大将模式,赢了一筐币, 我就拿去存了一半 大致 150 个币. 然后我也去玩, 前前后后整整一个下午, 我俩一共赚了 1300 个左右的币.
    然后就在群里, 喊我哥带小孩过来玩. 晚上给他们取了 1000 币, 被四个小孩,两个大人很快挥霍一空, 他们也抓了几个娃娃, 和一些零食玩具之类的.
    最后我留了 50 个游戏币, 把我哥嫂的微信教他们注册会员提了 60 个玩完以后就回家了.

    1. 初三 我去转亲戚了,媳妇在家和小侄子玩, 下午微信告诉我她们又去玩了, 登录了我妈和岳父岳母的微信刷了几十个免费币, 一半被小侄子玩了游戏, 一半赚币当然是没有赚到咯,运气不会一直这么好的. 晚上我回来以后就带了我爸的手机去找她们.
      玩了一会. 快要每币的时候我摇中一个,赚了 300 币.给她俩玩, 今天没存币,连同昨天留的 50 个都玩完了. 此时媳妇已经迷上赢彩票兑玩具了, 我已经帮她存了 2w 个小票,2.1w 就能兑换一个大玩偶,但是她想要 2.4w 的哪个.

    2. 初四转亲戚, 感觉一代新人胜旧人, 曾经个学习一很拉胯的表弟,好几年没见现在也都是风生水起, 因为当时我上大学的时候, 老舅喊我假期给他们补习过数学和英语,虽然我高考也一般 T-T.
      当时印象最深刻的是,有个给他们讲一道题, 发现他们不会做是因为没记住余弦定理, 然后就给他们讲为啥就是因为基本公式没记住,所以更谈不上如何运用了. 结果完了我问他们我刚说的啥,结果小老弟盯着我的笔记本电脑问我,你这个能玩地下城吗, 我当时就很无语, 所以现在印象如此深刻.
      小表弟没后来只考了个普通医专, 但是后来年龄大点了,自考了本科, 加上他舅在某市的医院当科室主任,后来帮扶进去了, 现在混的还不错. 以前没发现, 过年看他喝酒才知道,他一顿一斤半白酒打底,面不改色. 我就喊他,以后当了院长不要忘了老哥.

    还有两个也都混了骨科大夫, 舅老爷家之前是郎中, 我小时候也看到些清末,民国那种刻本印刷的老医书,也算是有传承了. 想必不是妙手回春但是也不至于是草包庸医. 有个小学刚毕业的, 现在专卖烟酒,也开上四个圈了,虽然也是二手的.

    1. 初五 接社火,继续转亲戚. 媳妇那肯定对玩偶仍旧是念念不忘, 下午回来喊我继续去, 这次没币了, 家里能用的微信号也都注册了, 去之前我约法三章 我就说买一点,玩完不管怎么样,能换什么就换什么,不再买了.
      去了以后我就买了 79 块钱的, 今天运气尚可, 不一会我就摇中一记, 赚了一筐, 赶紧让媳妇玩,我去存了, 我总觉得前天只赚了一次,说是因为 赚了之后没去存币. 第一筐存了 270 个左右. 后边我俩各自中了几次, 总共存了 800 多个币.
      然后就说不赚了, 直接全场玩一遍回家, 这中间碰到一位女士, 我俩赚金币的时候动静太大,引起好几个人过来围观, 她就问我怎么玩的,我当时就觉得她眼熟, 我就告诉她怎么容易中, 怎么卡节奏. 说完以后她就问我是不是我们认识, 我说我觉得也是呢,我问她你是不是 KJJ 她名字. 她说是的. 说她带小孩来逛.
      额, 只能说岁月真的是, 她是我之前的高一同学班花级别的, 贴别白. 后来我重新中考换到另一所高中去了, 就比她低一级, 后边她补习也来这边,聊过一次, 穿校服很好看. 但是现在皮肤也有些暗沉了.
      后来问她说在县城工作, 她家是有点背景的, 想想后边说加下微信,不定还能相互帮点小忙的,但是又寻思算了吧,毕竟以后我三五年也就回来一趟, 也只是麻烦人家而已.就不了了之了.

    最后我就拿剩下的币,帮媳妇刷小票,刷到了 2w8, 她呢也疯狂刷; 后来问了服务员, 抓的小娃娃也可以换小票,她就疯狂去抓娃娃了. 加上前两天,侄子侄女的抓的,拿回来一共兑了 5w2 小票. 换了两个大玩偶,一猫一狗.

    我把里边的各种游戏都爽玩了,一遍. 一直到老板要拉闸我俩才出来, 还剩十几个币, 我临时又去赚币哪里胡乱玩了下,算了画上句号. 最后到家发现还有三个币就放家里了.

    最后, 返程的时候,因为媳妇非要把两个玩偶都装行李箱带走,我两反复 battle. 最后还是带上了, 感觉女生对玩偶真的是有多少想要多少.
    感觉是真的改变不了她的想法,虽然好多买回来她从来不玩,甚至搬家,打理都是我在搞. 最后我妈跟我说实在要带就带上吧,这不吃不喝不吐气的, 如果要是活的你还怎么着呢?

    期间在家她也是很会哄小孩子开心啊, 之前我小侄子们都是围着我转, 这次回去全被她收买了, 她工作也是小孩相关, 确实也是哄小孩有一套.

    还有很多好玩的事情, 但是整个假期, 从和父母,亲戚以及自己的经历最大的感受, 培养自己.

    人们经常把自己看错了，却很少把自己忘记了。
    如果你想有一个自己最喜欢的仆人，那就自己伺候自己。
    我们能改变的只有自己, 能培养的也只有自己.

    为什么市面上很难找到一款对股票交易和基金投资体验都足够友好的 APP ？



    目前体验下来就是雪球 APP 还可以，但是能绑定的劵商太少了。
    我现在是同花顺买股票 + 蚂蚁财富买基金。

    尝试了一下同花顺买基金，那个操作起来步骤太长很麻烦。
    蚂蚁财富又买不了股票。


    另外我有一张众安的卡，za bank app 真是简单好用！
    1. 1
    2. ...
    3. 59
    4. 60
    5. 61
    6. 62
    7. 63
    8. 64
    9. 65
    10. ...
    11. 252