最近的 AI 的社会叙事，让我觉得如果我自己手打任何一个文字、手写任何一行代码、甚至主动去检阅任何一个文字——都感觉是愚蠢而低智。

所以 AI 如果真的像泡沫预期的那般，那未来人类（我）已经在哪个位置上。

短期

• AI 的能力不是你的个人能力，如果对一个未知的领域，通过 AI 你懂了那么一点皮毛，甚至于 AI 无情感动物的给你附和了几句，警惕那不是你的能力，那是一种普通且普世的能力。
• 依然坚持无手动 coding，即使是智慧一个无情感机器，总有技术运用的熟练和决策之分。你要做的事如何在大家在一个起跑线的情况下，让事情最大化。把机器用到极致也需要长期的锻炼和积累。
• 特别注意的是 AI 的创造力是真的有限，如果创造力在 AI 的射程之内，你要相信那不是真的创造/创新，那只是一种搬运。
• 未来的代码编程和英语能力相似了，但是依然要把英语狠投入，听说读写全方位依然是强竞争力，哪怕是 prompt 英文的效果依然大于中文。

中长期

• 任何领域未来的试错成本会变得较低，比如一款产品、一种药物等，所以对于很多领域的内容会变得质量越来越高，比如粗制滥造的互联网产品几乎不会存在了。外包依然能够保持中长期，但是成本会持续下探。生物医药、信息透明等领域或许会迎来一个比较好的发展；SaaS软件抄袭现象越来越多，未来一个不是定制的 SaaS 的估计很难生存了，行业深耕是必然了。
• 传统的白领会被大幅度缩减，尤其文稿、行政类、专业性较强的职业（基础的问诊医生、初级法律、软件开发）。所以这些有点小聪明的人未来会去向哪里是值得思考的问题，目前我没有答案。
• 我们假设 AGI 真的到来，未来人的核心的品质是：自洽、群体号召力、生活技能丰富。因为你未来搞定的不是事了，是要搞定人。

最近看到科技爱好者周刊（第 381 期）：中国 AI 大模型领导者在想什么 - 阮一峰的网络日志 关于中国一线领导者的访问的总结，一些所思所想：

• 中国一线现在针对算力的担忧比较明显，在中美算力差距过大的模式下，中国依然是专注在应用和交付，而美国会更多的关注下一代，所以如果AGI真的可以很快到来，大概率依然是美国下。更令人深思的话，当前模式下除了对社会级别的影响，对“战力”的影响也是巨变，美国的霸权主义更甚，对世界的掠夺式的地位或许会更加持久。对算力的突破依然是迫在眉睫，这个可能分布在光刻机、能源、量子计算等等，所以如果是价值投资者，这些领域应该可以长期看好。
• 还有一个比较有意思的点，提到关于To C和To B的差异。To B的定制化会让模型应用分层更加明显。这同样意味着在To B领域的竞争也会更加明显，在To B领域的AI相关的应用“百家争鸣”的场面依然存在，那资源分配依然是To B的主旋律。这个和过往模式的区别可能不会很大。尤其在To G领域，过滤的某些现象可能会持续存在。这得益于deep seek、千问等大模型，以及数百家科技型的国企。
• 那作为我自身，在AI这个浪潮下，必须针对AI一线的发展和模式紧跟步伐，了解脉络和发展方向，然后利用“应用”思维将AI价值落地，当前可能是服务于coding，更多的是利用技术在领域内价值落地

以上——记录于2026-01-17 9:00

以下是精华部分的摘录：

原味地址：

年度回顾

关键词：稳定输出

心态逐渐放平之后的稳定输出。

平台架构工作：低代码开发平台

这是我的第一反应，从业七年有余，第一次接触到生成式的低代码平台，平台很像过往的JSP逻辑。

代码完全是模板化，逻辑完全是数据化（store+原型链对象）。

更可怕的是，生成的代码完全对外暴露，业务方可以随意更改，改到不知所措之时，开始回归到平台，“你这平台不行啊！”。而作为平台层必须要满足业务的一切需求。

面对底层一堆的模板堆砌，从底向上的改动几乎不可能了。在不另起炉灶的情况下（资源有限），如何站在产品的角度看待平台是当前的一个问题。

版本化：平台作为一个大整体，无法形成有效的版本管控，对于当前离散的版本升级难度更大

很难想象，当前的版本升级是通过文件拷贝的方式。全平台没有一致性的版本概念。

这里首先做的就是将原有的对外暴露的空包代码进行收敛，将设计器资源、组件核心包资源收敛到平台，通过报版本的概念的统一管理，并以设计器版本作为统一口径。

这一步极其简单，也反映有些传统行业连起码的工程化思维都没有正确建立。

同时搭建了gitlab runner，规范打包流程和版本管理。摆脱过去依赖个人主机人工打包的方式。

性能优化：构建升级

这一步是很表征的现象，平台本身首先面向的是业务开发人员，在实际开发过程中的开发启动，调试缓慢等问题，始终存在，但一直无人下手解决，由于整体项目确实比较老旧，构建升级的难度还是存在的。

最终也只升级到了基于webpack5的构建优化，以及整体运行支持了Node 18+的版本。

最终的效果参考之前的一篇方案：

https://www.yuque.com/wumingshi/hv357e/gdt1kt5wr259lmb0?singleDoc# 《前端空包项目构建升级》

https://www.yuque.com/wumingshi/hv357e/zdyi79mcvst4l98z?singleDoc# 《FormDesign项目升级》

关于开发及构建目前也只能行进如此，原始项目的基于vue2，加上存量的大量的陈旧的三方包（个别包源码无从查找），导致进一步升级（如vite rspack）等基本不可能。

平台向前：接入三方生态

平台本身是产品（虽然当前已是千疮百孔），但是如何让平台有能力继续往前，接收新的血液，也是自己思考的问题。加上本身也鼓励其他业务方能够不断向平台贡献物料，没有统一的接口和工具，如何让平台更好的贡献物料呢。在这就开始操刀实施让平台可以接受异构代码的能力，

参考之前的总结：前后不解耦的低代码平台实现前端现代化

这一步目前的价值还没有完全发挥，基于此基本可以做到原有的代码不动，新的内容或者渐进重构的内容靠近现代化前端，让平台的能力尽可能达到上限。

代码冲突：解决生成式代码的冲突的问题

前文也提到平台本身是代码生成式，生成的代码本身会进行外露，业务方本身可能就会对代码进行更改，而更改后的代码又无法回溯到设计器内。

在平台进行升级或者相关联的功能发生改动，进行发布的时候，冲突已是必然，而业务方认为这是不可接受的。既如此便如此，总得找到口径去解决问题。

关于具体的方案之前也进行过总结：https://www.yuque.com/wumingshi/hv357e/vuwfo9q5a5xi6i1n?singleDoc#

而问题解决的核心方式是

1. 通过设计器对写入的代码与平台代码进行隔离，并对平台的代码编辑进行编辑。通过内置代码编辑良好的设计器对写入的代码进行约束。
2. 对于出现的冲突（可合并的部分）进行自动合并。
3. 对于出现冲突（不可自动合并的部分）基于AI进行分析

通过以上方式，已经可以避免大部分的代码冲突（在遵守使用规则的前提下）。

其他

• 大数据表格引入AG
• 移动端应用设计器组件和渲染端使用同构组件（一定程度让项目复杂度提升了）
• 搭建了unpkg服务，用于pkg文件解析

小结

对于平台的几场手术，有些已有成效，有些还得继续培育。对于生成式的低代码，在AI时代的开启，如何接入AI应该要深刻考虑，我认为生成式的肯定会被v0、bolt这样的场景解决掉，过程中的调整更多的应向nocobase这样的平台看齐。生成式的场景我肯定是悲观的（无技术、无人心），面向开发的平台未来的完成度因为AI的存在，大家的要求度会更高，还是尽快掉头吧。

下半年重点：智慧楼宇工作

下半年的工作重心有所转移，转移到面向济南软总部的智慧楼宇解决方案，决策层的根基是希望能够基于自身制造业优势，搭建整体智能化解决方案。并将方案首先在自身楼宇上进行实践，然后打包成展品进行对外销售。很明显这是巨大的红海，未来的竞争优势和不可替代的市场在哪里，这个可能不是当下首要解决的问题，首要解决的是基于自身的楼宇打造，打造公司整体智能化解决的能力。

在软件层面，楼宇整体实施其实无特别创新和技术挑战性。在使用层面上，面对各个供应商的系统，首先需要考虑的是平台底座的问题，包括人员、权限、菜单、入口等等。

统一平台：系统一致性入口

• 后端基于同步进行人员、权限、资源的统一编排（独立表及数据一致性）
• 前端基于微前端将各个子系统进行统一集成，保证不进行跳出

前端的实现方案：微前端的那些问题——乾坤-qiankun和无界-wujie

基于微前端方案搭建智慧应用平台集成方案。

最终实现了各个子应用都可以按照菜单的维度进行集成及权限控制。在实际应用过程中iframe\无界成为了我们的主要首选，原因是乾坤本身在多个应用间跳转响应优势不明显，隔离度也远不及其他二者。最终我们定义的规则是：

• 自研平台（低代码架构），优先考虑wujie
• 外部系统，优先考虑iframe

而前端的集成不需要任何的代码改动和发版，只需要通过基本的配置即可。

但是后端目前的数据同步策略，还不尽完美，考虑到子系统本身已经成型，目前考虑的是通过数据同步的方式进行跨系统的数据写表，从而降低子系统的改进门槛，但引入的问题是数据存在大量的重复的问题，后续的空间以及数据一致性带来不小的挑战。我目前设想的方案是，需要把数据表这一层做一层逻辑抽象，让所有的数据读取同一张表，但是在使用的侧，不需要关心表的问题，建立统一的数据中台（受制于资源等其他，目前未能实施）。

数字孪生平台：ThreeJS+（BIM）blender

对于数字孪生，大家整体实施的经验不足。对标很多外部供应商，包含BS、CS架构的漂视、山海鲸等，最终考虑到自身能力的储备选择了自研，最终通过ThreeJS+GLB搭建了一个基础模型，基本满足当下的需求。当然这里的核心的工作重点在建模，ThreeJS目前阶段的操作比较轻量。

关于数字孪生，前期对标过很多供应商，发现现在做的都还是在还原阶段，按照第一性原理的角度想，这种投入产出比似乎没有那么高，无法做到仿真这一步，数字孪生本身的价值我认为形同虚设。而真正进入仿真这一步的，国内目前还没有哪家做得好，或者说这一步的门槛又极高。

工单平台：使用工作流 + form-create搭建个性化工单

在识别智慧楼宇的场景中，发现存在工单平台的缺失，同时集团总部也确少一个工单平台，工单本身形态比较简单，但是如何满足各个业务线的要求，是否“一个场景，一次开发”。

最终我选择了搭建+工作流配置的方式。目前实际运行的效果还是非常让人满意的。并成功接入内部APP及企业微信。消息触达和处理效果喜人。

这里特别出彩的地方的是，在web功能齐全的情况，也需要一套移动端。这里第一次真正的使用AI用于生产环境，这个场景对于AI天然优势，最终在我实施两天左右，成功复刻了一个移动端的原型，而单独开发少说也得一个月的时间。

其他的边角料

• 供应链投毒，搭建三方包自检工具，用于检测异常包
• 展厅大屏应用，构建离线的可安装的应用（tauri）
• 使用pake构建移动端应用，满足快速交付
• 构建AI转发代理（自费）
• ...

工作总结

总结过往一年，基本算是稳定输出。但是业务价值并未完全凸显。很遗憾有些果实无法看到长熟那一刻了，这一年对自己的PPT功力也有了一些锻炼，但是依然不喜于钻研此道，一线人如果不能够实事求是，这个泡沫会越吹越大。

对于传统数字企业的转型我认为的正确之道：

• 数字接口人与业务的深度绑定
• 数字操作人与业务的制度隔离
• 数字从业人与业务的视角对齐

以上绝非空喊口号，更不是埋怨，而是基于当前的工作经验的真诚。

大多数数字实施人如果都一味/过度的奉上，数字价值迟早要破。而损害的不是根，是那个开的最美的花，只占有阳光，却不结果。

AI碎碎念

过去一年在态度上始终保持对AI的关注和警醒，一方面被AI的信息爆炸弄的一团乱麻，一方面又时不时被AI的生态所震惊。Agent的Coding、nanobanana的图片让你知道你必须要正视。AI目前依然处于乱序的状态，必要的工程化管理/约束依然是工作本身提效的关键，比如Spec Kit、Gemini Conduct等，对于一个团队必须统一语言/工具是针对AI千变万化的有效应对，如果一家公司目前都all in 打造自身的claude skiils，提效应该是让人兴奋的。

作为我个人来讲，过去一年重点关注的是Google家族生态（嗯 AI教育资格送的一年羊毛，不薅白不薅啊）。工具的使用保持精品和不失焦。

• Gemini是我日常chat模式的第一伙伴(涵盖一切我想问的话题，本身具备个性记忆能力，越聊越会了解自己，细思甚恐)。
• nanobanana是我图片需要的生成首选，尤其3.0 pro 对文本及中文的支持相当优秀。
• PPT生成（google目前缺失有效完整链路工具），manus和genspark对PPT生成效果不错，notebookLM生成的结果颜值在线。
• code agent：gemini cli 以及 vscode copilot。vscode copilot除了能用claude模型之外，内置大量的tools供模型使用，是一个比较大的优势，之前对比过使用模型完成rust练习手册，cluade的模型确实占优。cursor付费之后几乎没有使用，vscode的距离应该不会差的很远，警惕营销文。
• 日常辅助任务，首选gemini cli。antigravity受制于每次都得启用tunel模式，使用频率也不高。
• 笔记AI，主站点还是在yuque，因为情怀吧（虽然早有了youmind，但是价格不便宜啊），AI在知识库、文档、知识、创作领域可能是创业项目最多的，好的工具是你多输出的载体而已，不可因为工具而工具。AI时代，我相信notion的地位依然很难撼动。保不齐哪天就会转向notion了，但yuque于我目前已足够。
• 知识/新闻获取工具，这一年的消息获取已基本都依赖rss获取，之前有想法做一个AI筛选内容战，没想到早已出现，https://www.bestblogs.dev/，而且比我预想的结果优秀的多，对不起，卷不过....之前也设想过搭建一个私人诊疗平台，好吧支付宝阿福也下场了，拼的不是想法，只能是速度和资源，悲矣...

AI让我明白，我需要从技术思维往解决方案思维持续练脑。

原文：“考试满分、实战翻车”，llya 1.5小时访谈详解模型能力的“锯齿落差”

AI总结

1. 核心预测：AGI 何时到来？

• 时间表： Ilya 预测，人类级别的 AGI 将在 5 到 20 年内实现。
• 经济影响： 尽管目前的 AI 即使在评估中表现优异，但在实际经济应用中仍显滞后，但他坚信 AI 终将渗透到各个领域，带来快速的经济增长。

2. 技术瓶颈与“锯齿状”能力

Ilya 指出当前模型能力存在一种**“锯齿状”（Jagged）**的落差：

• 现象： AI 像是一个“应试专家”，在复杂的编程竞赛中能拿满分，但在实际应用（如修改简单代码错误）时常常“翻车”，犯低级错误。
• 原因：

• 过度拟合： 强化学习（RL）让模型过度专注于狭窄的评估目标，牺牲了泛化能力。
• 缺乏“价值函数”： 现有的模型缺乏人类那样内在的、高效的反馈机制（即“价值函数”或类似“情绪”的系统），无法在得出最终结果前判断路径是否正确。

3. “规模化（Scaling）”已死，“研究时代”回归

• 规模化见顶： 单纯依靠增加数据和算力的预训练“规模化配方”已进入瓶颈期。并不是说不能继续扩大，而是单纯扩大 100 倍规模不再能带来质的飞跃。
• 重回研究时代： 现在的重点从“堆算力”转回了“找配方”。我们需要通过研究找到更高效利用算力的方法（例如更高效的强化学习、价值函数），这与 2012-2020 年的探索期非常相似。

4. 解决泛化难题：向人类大脑取经

• 样本效率差异： 人类（例如青少年学开车）只需要极少的数据（10小时）就能掌握复杂技能，且具备极强的鲁棒性，而 AI 需要海量数据。
• 价值函数即“情绪”： Ilya 提出了一个有趣的观点，人类的**“情绪”其实是一种生物进化的“价值函数”**。它帮助我们在逻辑运算之前快速判断好坏（如恐惧、自信）。未来的 AI 需要引入类似的机制来提高学习效率。

5. SSI 的战略：直通超级智能（Straight Shot）

Ilya 解释了他在新公司 Safe Superintelligence (SSI) 的独特打法：

• 不急于商业化： 不同于 OpenAI 或 Anthropic 的“渐进式部署”产品策略，SSI 专注于纯粹的研究，试图“直通”超级智能，避免被商业竞争分心。
• 算力聚焦： 尽管 SSI 只有 30 亿美元融资（相比巨头较少），但巨头的算力大量用于推理（服务用户），而 SSI 的资源全部集中在研究上，因此在研发算力上并不落后。
• 部署即学习： 超级智能不会是一个出厂即完美的成品，它更像是一个绝顶聪明的 15 岁少年，需要在部署到真实世界的过程中持续学习（Continuous Learning）。

6. AI 安全与对齐：让 AI “关心有情众生”

• 新的对齐目标： 面对难以预测的超级智能，Ilya 提出构建安全 AI 的核心在于让它**“关心有情生命”（Care about sentient beings）**。
• 生物学基础： 这类似于人类的同理心或镜像神经元机制。如果初始的超级智能具备这种“善意”的元设定，它在自我进化中更有可能保持对人类的安全。

7. 如何打破“模型同质化”

• 现状： 目前各家的大模型（LLM）因为使用了相同的预训练数据，表现非常相似。
• 破局： **自我博弈（Self-Play）**和多智能体竞争是打破同质化的路径。让 AI 相互竞争、辩论或进行“证明者-验证者”的对抗，可以激励模型产生差异化的思考路径，并在没有新数据的情况下提升能力。

8. 什么是好的“研究品味”？

Ilya 分享了他从 AlexNet 到 GPT-3 的成功心法：

• 美学标准： 好的研究应该是美、简洁、优雅的。
• 生物启发： 必须正确地借鉴大脑机制（如神经网络的连接方式），但不要被细节（如大脑皮层的褶皱）误导。
• 自上而下的信念： 当实验数据暂时不理想时，如果你的理论在逻辑上是美且合理的，你需要有“信念”坚持下去，而不是轻易放弃。

总结一句话： Ilya 认为单纯堆砌算力的时代已经结束，未来属于通过“回归研究”来赋予 AI 类似人类的“价值函数”和“持续学习能力”，最终在 5-20 年内实现一个关心有情众生的超级智能。

之前还在小打小闹的使用AI搭建了一个landing page，包含脚手架、素材生成等等，但其实非常明显的一眼假。因为内容不够具备系统性，内容的发展也完全失控，关键的是离生产级还差的相当远。如何建设一个真正意义上的生产级的项目呢？

因为AI的不受控或者无法完整跟上AI的思维链路，导致在生产环境中完整使用是一个不小的壁垒。

由头

这不机会来了，公司希望大家一个工单APP，工期确实比较紧。

工单的特点

• 共识性的知识（大模型肯定比产品经理还懂）
• 具有不少开源的参考（大模型早就了如指掌）

听起来是不是变得很简单了，一句话生成是不是完事了？如果真是这样，那我们人类可能距离被AI掌控的距离就不远了，因为我们会把AI说的奉为人类的意志，一切人类感觉不合理的地方都被当作是错误。细思极恐啊。

使用的AI工具

copilot、claude4.5

借助的前端技术栈

nano css、vant ui、element ui、vue3、piana、vite、biomejs

是不是看起来很简单？

关键在如何具体实施呢？

我的实施路径

key1: 照猫画虎

找一个相对成熟的web端现有平台，例如芋道等

key2: 界定技术边界

约定前端技术边界，例如你需要指明使用的UI框架、状态管理、组件存放位置、共用范围，这一步其实比较关键，在于一方面可以讲实现框定在一个特定范围内，方面后续的变更，同时也可以让AI知道整体项目的结构。AGENT.md其实就是做这样的事情，这个非常关键，一定要明确的写清楚，按照前端架构的思路，约定具体的实施路径，可以参考claude skill的哲学思想。

key3: 一定要用听的懂的话术描述产品功能

这个也是程序员常常犯的错误，自己说的话很容易被误解，更何况目前来看偏高一维度的“生物”，一定要把自己想法拉回到大白话维度，尽可能全面不啰嗦的描述具体的功能。你想到的是基于自身的知识背景。例如我现在要将某一个页面的组件进行抽象，最好的做法是自己做好一个参考，这时AI可以无限复制。说白了大模型啥都懂，也就不容易聚焦，一定要让它尽可能聚焦，这里就涉及到背景上下文的问题。用AI打造一个系统，或者从组件维度开始拼装也未尝不是一个好选择。

key4: 约定复用能力

代码生成很容易出现片状的代码，针对高阶能力，需要在能力描述中进行体现，这样才能保证代码生成量过多，同时实现过于原子化的现象。在项目级或者页面级别的生成中，需要维护好自身的“skill”，让大模型知道当前项目的组件已经满足到什么程度，在这方面，可能spec kit/open spec是个好选择，目前还没有深度使用。

写在最后

有了AI，我们总是期望通过直接甩出一张楼宇大厦，让大模型直接开始动工，最终的结果很可能是楼宇有了个外壳，却无法承担楼宇的真正功能。

真正基于AI的工程化，目前可能还是从筑墙开始、搭建积木的思维更是可靠。