这个背景对我影响挺大。因为写 App 的时候，我很早就知道一件事：一个页面能跑，和一个项目能长期维护，是两码事。

刚入行的时候，我也会被一些很漂亮的东西吸引。页面写出来了，接口通了，列表能刷新，缓存也有了。那时候会觉得，嗯，这个功能完成了。

后来项目一复杂，问题就都出来了。

状态放哪。
模块怎么拆。
异常怎么兜底。
新人进来怎么读。
产品改三次以后，原来的代码还撑不撑得住。

架构这个词，不是在功能跑起来那一刻出现的。
它往往是在系统开始变乱的时候，才真正有意义。

现在看 AI 项目，我经常有同样的感觉。

很多人说自己是 AI 架构师，实际做的是另一件事：搭智能体、写提示词、接 API、配一个工作流，然后录个演示视频。演示的时候确实挺顺，客户也容易被打动。

但演示不是上线。

上线以后才是麻烦的开始。

我现在对 AI 架构师的第一个判断

AI 架构师不是最会搭工具的人。

当然，工具要会。
不会工具也谈不上架构。

但只会工具，最多叫 AI 工具搭建师。

我现在更愿意把 AI 架构师理解成这样：

他要设计的是一家公司使用 AI 之后，工作怎么重新流动。

这里面有工具，也有人。
有流程，也有考核。
有知识库，也有责任边界。
有老板想看的收益，也有员工心里那点不舒服。

这句话不太像技术定义，但它更接近真实项目。

因为 AI 进企业以后，最先出问题的地方，经常不是模型。是人和流程。

员工觉得不好用。
中层不知道怎么验收。
老板只看省了几个人。
知识库三个月没人更新。
AI 生成的东西堆在后面没人改。
最后大家说，AI 没效果。

我以前也会顺着这个说法去想，工具是不是没做好。后来发现，不一定。

有些工具交付那天挺好。
只是企业没有给它一个能活下去的位置。

工具层只是第一层，不是全部

先把话说死一点。

工具层必须扎实。

一个客服 Agent，如果连产品价格都答错；一个内容助手，如果十篇稿子九篇都是模板味；一个销售助手，如果对客户阶段判断不准。那后面讲组织、讲流程、讲管理，都没有意义。

工具层至少要做好这些东西：

这张表其实不复杂。

但很多项目连这张表都没有。

它们只是做了一个入口。输入一句话，输出一段结果。能跑，也能演示，但它不像企业系统，更像一个临时工具。

临时工具有临时工具的价值。
只是别急着叫架构。

我会先看业务里哪一段真的疼

AI 项目最怕一上来就说“全面 AI 化”。

这句话很大，听着很积极，落地的时候往往很散。

我现在更喜欢从一个很小的地方开始拆。比如内容团队、客服团队、销售团队、投放团队、培训团队。先别谈全公司，先看一个流程里最卡的那一段。

我会用一个很土的表。

这个表不高级。

但它能挡掉很多假需求。

有些需求不是不能做，是现在做了不值。
有些需求老板觉得很酷，但业务上不疼。
有些需求看起来简单，背后数据很乱，最后会变成无底洞。

架构师要敢说“不建议现在做”。

这句话比“能做”更难。

知识库不是把资料扔进去

我以前也犯过这个想法上的懒。

企业有文档，那就做知识库。
产品资料导进去，FAQ 导进去，销售话术导进去。
然后 AI 就应该懂公司了。

实际不是。

企业的知识大多不是一套东西，而是一堆版本。

销售有销售的说法。
客服有客服的说法。
老板有老板的说法。
产品文档写的是一个版本，客户实际问的是另一个版本。
老员工脑子里还有很多没有写下来的经验。

这些东西不整理，AI 只会把混乱说得更流畅。

这就很麻烦。

以前人说错话，可能还带点犹豫。
AI 说错话，语气通常很稳。

所以做企业 AI，知识库要先问四件事：

1. 哪些资料是正式口径；
2. 哪些资料已经过期；
3. 哪些内容可以对客户说；
4. 哪些内容只能给内部看。

再往下才是技术细节：怎么切分、怎么召回、怎么排序、怎么引用来源。

我现在越来越觉得，知识库的核心不是“库”，而是“知识负责人”。

没有负责人，知识库迟早变垃圾桶。

流程不重画，AI 的效率会被吃掉

拿内容团队举个例子。

原来的流程可能是这样：

选题 → 写脚本 → 改稿 → 客户确认 → 发布 → 复盘

现在 AI 把写脚本从两个小时压到二十分钟。

看起来提效很明显。

但如果改稿的人还是一个人，客户确认还是三天回一次，复盘还是没人看，那整个团队没有真的快起来。只是“写脚本”这个节点变快了。

瓶颈会转移。

这个东西在技术里很常见。
你把接口优化了，数据库慢了。
你把数据库优化了，前端渲染慢了。
你把一个点干快，系统不一定快。

企业流程也是一样。

AI 进来以后，流程图至少要重画一次。

不是为了好看，是为了看清楚这几个点：

• 哪些节点被 AI 压缩了；
• 哪些节点反而变忙了；
• 哪些审批可以取消；
• 哪些审核必须保留；
• AI 输出后由谁加工；
• 最终结果由谁负责。

这一步不做，AI 很容易变成“局部很先进，整体没变化”。

我对这种项目比较警惕。

因为它最容易在汇报里显得很好看，在业务里没什么感觉。

岗位不会简单消失，但责任一定会变

AI 进来以后，很多岗位的工作量会变化。

这个没必要回避。

内容岗以前主要写初稿，现在初稿被 AI 压缩了。
客服以前回答标准问题，现在标准问题被机器人接走了。
销售以前花很多时间写跟进话术，现在话术可以自动生成。
运营以前整理数据，现在数据整理也可以半自动。

表面看，是岗位被削弱了。

但我不太喜欢只这么看。

更准确一点，是岗位里的低价值部分被压缩，高价值部分被放大。

内容岗以后更像选题和风格判断。
客服更像复杂问题处理和知识库反哺。
销售更像客户意图判断和成交节奏设计。
运营更像数据解释和策略调整。

可以做一张岗位变化表。

这张表要跟团队讲清楚。

不讲清楚，员工只会看到一件事：AI 来了，我可能不安全。

人一旦这么想，就不会真正配合。

他会表面使用，实际绕开。
他会把 AI 当成老板监控自己的工具。
他会尽量不暴露自己真实效率。

这不是员工落后。
这是正常反应。

培训不能再讲“提示词万能公式”

很多企业做 AI 培训，形式很像。

先讲趋势。
再讲模型。
再讲几个提示词技巧。
最后让大家现场试一下。

当时热闹，第二周就凉。

不是大家不想学，是他们回到岗位以后，不知道怎么接到自己的工作里。

一线员工需要的是操作手册，不是趋势报告。

比如文案岗要知道：

• 什么时候用 AI 出初稿；
• 出完初稿后必须改哪几处；
• 哪些词一看就是模板味；
• 客户资料应该怎么喂给 AI；
• 最后提交时要保留哪些人工判断。

客服岗要知道：

• 哪些问题可以让 AI 回；
• 哪些问题必须转人工；
• AI 答错后怎么标记；
• 新问题怎么沉淀进知识库。

中层要学另一套东西。

中层不需要每天研究提示词，他要会验收。

他要知道一篇 AI 辅助文案到底好不好。
他要知道客服机器人答得准不准。
他要知道员工是真的提高了效率，还是只是把原来十分钟能做完的事，用 AI 包装成了半小时。

老板也有自己的课。

老板要看经营结果，不是看热闹。

调用量高不一定有效。
员工都注册了也不代表转型成功。
真正要看的是交付周期、返工率、客户满意度、新人上手时间、转化率、成本变化。

培训分层，AI 才能进岗位。

不分层，就会变成一次气氛很好的活动。

激励不改，员工不会真用

这个地方最难讲，也最应该讲。

一个员工原来一天写五篇稿子。
AI 进来以后，他一天能做十五篇。

如果工资不变，压力变大，他没有理由开心。
如果用得越好，越容易证明岗位可以减少，他更没有理由主动。
如果老板把省下来的钱全拿走，员工只会把 AI 当成威胁。

很多 AI 转型失败，表面是工具失败，底层是激励失败。

我觉得这里至少要改三件事。

1. 不要只按数量考核

AI 时代，数量太容易被刷出来。

更应该看质量、转化、客户反馈、返工率、复盘贡献。

2. 把 AI 使用质量放进绩效

不是看调用次数。

而是看员工有没有把 AI 变成更好的结果。比如沉淀了案例、优化了流程、减少了返工、提高了客户满意度。

3. 提效收益要让团队看见

不一定马上涨工资。

但至少要让团队知道，AI 带来的收益不会只变成更高的工作量。

可以是奖金，可以是分润，可以是晋升标准，也可以是把节省出来的时间转向更有价值的工作。

这件事不解决，前面做得再漂亮，最后也会卡住。

上线以后，还有一堆脏活

AI 项目最容易被忽略的是运营。

交付当天通常最热闹。
群里发通知，老板转发，大家试用，服务商讲解。
看起来很像一件事完成了。

其实刚开始。

上线后会发生很多小问题：

• 产品资料变了，知识库没人更新；
• 员工发现 AI 答错，不知道反馈给谁；
• 提示词一开始好用，后来业务变了就不合适；
• 调用成本慢慢变高；
• 某些岗位用得很好，某些岗位完全不用；
• 中层只看使用次数，导致员工刷调用；
• 客户反馈变差，但没人把原因追到 AI 输出。

所以 AI 架构师必须给企业留一张运营表。

这个表不复杂。

但它决定系统三个月后还活不活。

AI 工具没有人养，会很快变旧。
业务在变，知识在变，客户问题在变，模型也在变。

上线不是终点。
上线只是开始欠维护债。

我现在看 AI 架构师，会看这些交付物

一个人说自己是 AI 架构师，我不会先看他会不会写很炫的提示词。

我会看他能不能交付这些东西。

AI 架构师交付清单

• [ ] 业务场景优先级表
• [ ] AI 场景是否值得做的判断依据
• [ ] 原流程图
• [ ] AI 介入后的新流程图
• [ ] 人机分工表
• [ ] 系统架构图
• [ ] 知识库治理规则
• [ ] 权限和风险边界
• [ ] 岗位使用手册
• [ ] 中层验收标准
• [ ] 经营指标看板
• [ ] 岗位变化建议
• [ ] 绩效和激励调整建议
• [ ] 上线后的运营复盘机制
• [ ] 失败案例回收机制

这里很多东西不酷。

甚至有点麻烦。

但企业 AI 落地，本来就不是只靠酷的东西。

真正能活下来的系统，往往是这些麻烦东西撑住的。

我给 AI 架构师下的标准

我现在会把 AI 架构师分成两种。

一种是工具型。

他能把智能体做出来，能把流程跑通，能让 demo 看起来不错。这个能力有价值，而且市场也需要。

另一种是系统型。

他会先判断场景值不值得做。
会整理企业知识。
会重画流程。
会拆岗位责任。
会设计培训。
会提醒老板改激励。
会给中层验收标准。
会给工具留运营机制。
会提前画风险边界。

这两种人都能做 AI 项目。

但只有第二种，我愿意叫 AI 架构师。

因为架构师这三个字，应该承担“系统长期运行”的责任。

只解决工具问题，交付那天就结束了。
解决系统问题，交付那天才刚开始。

写到最后

我从 Android 转到 AI 架构这个方向以后，越来越觉得两件事很像。

以前写代码，最怕的是只顾眼前功能，不管后面维护。
现在做 AI，最怕的是只顾眼前演示，不管企业怎么用。

功能跑起来不难。
系统跑下去才难。

AI 也是这样。

一个智能体能回答问题，不代表企业完成了 AI 化。
一个工作流能生成报告，不代表管理效率真的提升。
一个知识库能检索资料，不代表公司的知识真的被治理好了。

真正的 AI 架构师，要处理的是工具后面的东西。

人怎么用。
流程怎么变。
知识怎么更新。
责任怎么分。
收益怎么算。
风险怎么控。
三个月后谁继续维护。

这些东西不一定适合拿来做炫技视频。

但它们决定 AI 到底是一个新鲜玩具，还是一家公司新的生产力。

所以我现在不太愿意把“搭个智能体”叫架构了。

那只是开始。

AI 架构师真正要交付的，是一家公司用 AI 之后，能够跑起来、改得动、算得清、有人负责的一套工作系统。

Kotlin是一种具有类型推断的跨平台、静态类型、通用型编程语言。Kotlin能够与Java完全互操作，并且Kotlin标准库的JVM版本依赖于Java 类库，但类型推断允许其语法更简洁。Kotlin主要针对 JVM，但也编译为JavaScript（例如，对于使用React的前端 Web 应用程序）或通过LLVM的本机代码（例如，对于与Android应用程序共享业务逻辑的本机iOS应用程序）。

2019 年 5 月 7 日，Google 宣布Kotlin编程语言现在是其Android应用程序开发人员的首选语言。自 2017 年 10 月发布Android Studio 3.0 以来，Kotlin已被纳入标准 Java 编译器的替代方案。Android Kotlin 编译器默认生成 Java 8 字节码（在任何更高版本的 JVM 中运行），允许程序员选择针对 Java 9 最多 18 进行优化，或允许更多功能；在 Java 16 中引入对 JVM 的双向记录类互操作性支持，自 Kotlin 1.5 起被认为是稳定的。

Kotlin 支持网络；通过编译为 JavaScript（即，带有经典后端的 Kotlin/JS，自 1.3 版起被声明为稳定版），而较新的 Kotlin/JS（基于IR）在 1.5.30 版中处于测试阶段。Kotlin/Native（例如Apple 芯片支持）从 1.3 版开始被视为测试版。

我本人为什么学习Kotlin语言

本人是一名Android开发工程师，因为Android开发的首要语言就是Kotlin，为了个人的成长，学习Kotlin是必要的。但是也不仅仅是因为这个。Kotlin的各种优点让我深受吸引，让我不仅仅是单纯的学习，而是学习Kotlin语言的魅力之处，让我觉得Kotlin真正的结合了百家之长，有dart的空安全检查，有go语言的协程，不仅仅可以用来开发Android程序，还可以编译IOS的业务层，也不仅仅是前端的Android，还可以用于编写Springboot程序，一样可以集成SpiringCloud全家桶。因为我不仅仅是Android开发，也同样对各种新的技术抱有饱满的兴趣，Kotlin在未来很可能也会成为机器学习，深度学习的首要语言。而这更是我为了跟随计算机时代不断前进的步伐，而选择的计算机语言。

关于语言层面的优点：

1.Concise 简单明了的

这一点有一个问题，代码上看起来非常的简短，几行就可以完成Java几十行的，但是有一部分人会觉得一个问题，就是代码简短了，阅读性就差了，虽然Java写起来冗杂，但是Java的各种关键字，各种语句，可以很明确的标示一条语句的具体含义，而Koltin，一条语句，可能有多种可以理解的方向，比如类型推断的特性，在需要返回值的时候，因为类型的不确定性，语言的不熟练，就会经常的用到强制类型转换，导致程序的各种各样的异常问题。终究也就只有一点，熟练度，只有你真正的熟悉了这一门语言，阅读性的问题也就没有那么重要了，都是一眼就能明白是什么意思。所以，熟练后，最终代码的简洁的优势就会逐渐凸显出来。

2.Safe 安全

这里指的也就是Kotlin带有得空安全检查，所谓的空安全检查，就是利用编译器的特性，在代码编写的阶段，在编译前就避免Java中出现的大量的空指针异常的问题，而所谓的空指针异常，也就是某一个参数，在运行的过程中，因为某种原因，导致并没有赋值或者被赋予了null值，在Java中null是一个特殊的值，如果本身接收null值的数据类型带有方法，而null作为一个特殊的值，是没有这个方法的，可是代码却要让他执行这个方法，那会显然，程序到这里就会崩溃，执行不下去了。而Kotlin，添加了空安全特性，在编译之前就进行了空安全检查，一个参数就有了可空和不可空的状态，利用？特殊符号来完成这一声明，这将在后面会详细介绍。当一个参数没有被初始化（第一次赋值）的时候，这个值在后面的使用过程中，就可能是空值。所以，编译器很容易的利用这个规则检查到了，而你，只需要在类型的声明出添加一个问号，就可以解决问题。但是，在你每一个使用这个可空类型的参数时，编译器都会提醒你，他可能为空，推荐你使用空安全检查，来完善对空值的处理，避免空指针异常。

3.Expressive 具有变现力

Kotlin是一个拥有大量的特殊函数式的语言，而这些函数式，也为Kotlin提供了强大的变现力。首先就是解构特性。支持将list和map直接结构成多个变量，并且直接在声明处的作用域之内使用。对数据的解析大大的简短了操作。其实就是let，run，with，apply，also，将调用本身，以及返回值进行了各种组合，实现我进我出，我进他出的效果。以及takeif，针对空值处理的一个函数式。

4.Interoperable 具有互操作性

kotlin可以与各种语言进行交互，就是它的可操作性，可以使用任何现有JVM库或框架。从Java中调用Kotlin代码，都没有任何问题。编写Kotlin代码，将其编译为JavaScript，并在浏览器中运行，以及使用现有的JavaScript API和库，使用Kotlin包装器构建具有JavaScript框架（如React）的应用程序。

5.Multiplatform 跨平台

也就是利用可操作性直接体现出了其强大的跨平台能力，JetBrains公司推出了开发工具的全家桶，而他们退出的语言也将拥有这样的特性，可以做任何事的全家桶语言。

结语

最后，语言虽然是最基础的内容，但是语言强大的特性，可以从语言的设计思维中得到不少的程序开发中的业务设计思维。接下来的时间，我会自己不定期的编写关于Kotlin语言的博客，我会尽可能的详细讲解，真正的做到让零基础的人来接触开发的大门。所以我的语言往往是很冗长啰嗦的，为的就是利用这种节奏，来给读者更多的思考，反思我讲诉的，思考自己所能理解的。不过我也明白自己也有着知识的诅咒，可能会因为自己已经掌握了某个知识点而忽略了。

• 使用 java -jar jetlinks-standalone.jar 后 服务正常使用断开ssh后，服务自动停止：
• 使用 nohup java -jar jetlinks-standalone.jar>log.out & 解决

2、npm start 启动项目 断开ssh之后服务自动停止

• 使用 npm run start:dev npm start 启动的项目 断开ssh后服务自动停止
• 使用 nohup npm run start:dev demo.jar 2>&1 & 解决问题

3、nohup &退出shell终端后，服务断开

• nohup &退出shell终端后，服务断开 退出时不要直接点叉子，要是如 exit

补充：把 nohup与& 结合在一起，这样就可以不挂断的永久在后台执行

nohup java -jar demo.jar 2>&1 &

不挂断的后台启动 demo.jar，

“2>&1” 表示 错误和输出都传到nohup.out文件中，默认状态只把输出输出到nohup.out文件中

nohup 命令默认输出到nohup.out文件中