最近的资讯可视化项目，在将测试页面部署到服务器的过程中，我遇到了一些问题，现在记录下来作为经验总结。 系统版本升级的必要性与数据丢失首先遇到的问题是服务器系统版本过低。我的服务器目前使用的是 CentOS 7，这个版本无法支持我们的程序运行，因为程序依赖于 Node.js 18 以上的版本，而我本地开发使用的是 Node.js 20 版本。 为了在系统上升级 Node.js，我发现需要先升级 gl

在 B 站看到一个视频：不要用 AI 框架，作者的观点和观众的评论很有意思，因此我用 AI 将其整理了一下。 视频核心观点视频《【AI 开发避坑指南】为什么现在不要用 AI 框架？资深工程师深度解析框架弊端》主要观点包括： 反对使用 AI 框架的主要理由： 框架的致命缺陷：过度抽象化导致系统僵硬、黑盒操作难以调试追踪、性能瓶颈无法精准定位、框架升级带来架构不稳定 主流框架实战问题：抽象概念增加不必

前言最近在 HIVIS 可视化组件库项目中，我们遇到了一个典型的本地依赖分包问题。这个问题看似简单，但背后涉及到了现代前端工程化的诸多核心概念：模块解析、构建系统、依赖管理等。 本文将深入分析这次踩坑经历，从问题现象到根本原因，从解决方案到架构思考，希望能为同行提供一些有价值的经验参考。 背景与需求项目架构概览HIVIS 是一个基于 Stencil 的现代化可视化组件库，项目结构相对复杂： 123

D3(Documentation Driven Development) - 从模糊需求到精准实现：文档驱动开发实践。 文档驱动开发的核心思想文档驱动开发的核心思想是：No Code - 先用 AI 生成完整的技术文档，再基于文档生成代码。这种方法论源于我在实际项目中的探索和思考。 从 UED 设计师案例引发的思考最近观察了我们 UED 团队的设计师们开发软件的经历，让我对 AI 辅助开发有了

本文由 AI 基于项目源码生成。 前言在当今信息爆炸的时代，如何让用户更高效地获取和理解资讯内容成为了技术团队的重要挑战。传统的纯文本新闻阅读体验已经无法满足用户对信息直观性和交互性的需求。本文将深入解析我们团队开发的资讯可视化增强系统，分享如何将原始新闻文章转化为带有丰富可视化元素的交互式内容的完整技术实践。 这个系统的核心价值在于通过 AI 智能分析和前端可视化技术，自动识别文章中的关键信

本文由 AI 基于平时记录的简短想法扩写而成。 最近这段时间，我几乎每天都在和各种 AI 编程工具打交道。这个过程有点像是在玩一场大型的”抽卡游戏”，有时候你会抽到 SSR，有时候则是连续的 R 卡。 不要用平替，免费的才是最贵的经过这么长时间的实战，我越来越认同一个观点：在 AI 编程这个领域，免费的工具往往是最贵的。 CC（Claude Code）是我目前用过最顺手的工具，没有之一。GLM

一个案例种子需求123456789项目下的fixed、final等等文件，是否都是之前调试过程中的产物呢？现在调试完成了，是否应该对测试模块下的代码进行一个整体性的梳理，去掉这些 │Fixed、Final 等等文件，将其编写为整洁的代码呢？ 另外帮我分析一下目前的这个测试模块，其程序设计、技术选型等等是否合理，有没有更好的方案。 │目前看起来是比较零

反思：时间轴的需求，为什么我确认的时候这么多内容没考虑到？不要陷入“把事情想简单了”的误区，这种情况太常见了，即使同一个团队的不同职责的人之间，也普遍存在这个问题。 忽略的内容需求上 交互：点击、悬浮 极端情况：文本过长的展示方式 resize destroy 跨组件的通信、和外部的通信 技术上技术的选择，应该根据需求而定。 一开始想复杂了，感觉要用D3.js，但是因为其布局是固定的3XN

T8是蚂蚁集团AntV技术栈下的一款文本可视化解决方案，采用声明式JSON Schema语法来描述数据解读报告的内容。作为一个专门为AI时代设计的可视化库，它在架构设计上有诸多值得深入研究的亮点。 开源源码阅读方法与项目汇报相似，阅读开源源码应采用自顶向下、逐步求精的方法： 先看宏观调用流程 - 理解整体架构和入口点 再深入具体实现 - 分析各个模块的细节 架构设计思考整体Manager封装的

需求来源我们最近要开发一个组件给业务方使用，网页对于性能有较高的需求。而我们的组件代码量比较大，会导致组件的 CDN 比较大，加载耗时较长。因此我们需要对组件进行分包处理，将原本较大的 CDN 拆分为多个相对较小的 CDN。 之前的项目打包时支持导出 ESM 和 UMD 两种形式。但 UMD 格式是为了兼容不同浏览器模块化规范的处理，其产物没有包和模块的概念，不支持分包。因此我们只能选择 ESM