AI 时代到底应该学什么
今年的热点已经换了好几茬。年初还在聊 Harness，年中变成 Loop Engineering，现在又开始讲 Graph Engineering。名字一个接一个，每个都说自己代表下一代工作方式。
#架构
共 76 篇文章。
Skill工程架构
最开始我把 Skill 理解成一种更完整的 Prompt：把流程写清楚，把注意事项补全，再加上一些示例，效果应该就会越来越好。
基于开源客户端二次开发，UI组件库应该怎么选
最近在规划一个基于开源 Agent Runtime 的桌面客户端，UI 开发很快遇到一个具体问题：到底要不要引入第三方组件库？是用 MUI、Ant Design 快速搭页面，还是所有组件都自己写？
Pretext深度解析
https://github.com/chenglou/pretext !Pretext 学习从隐藏结构到表征的机制
如何沉淀Skill
我建议你们内部不要只分成“两类”，而是分成下面四类。这样后续盘点项目资产时会清楚很多。
Agent技术选型分析
Agent 框架选型不能只看谁最火。真正要先问的是：流程有没有分支和重试，任务会不会跑很久，状态要不要恢复，工具和人类审批是不是链路的一部分。
从harness看未来软件工程师的工作职责
我现在更确定的一点是：AI 写得快，不等于系统交付得快。工程师的价值不会只剩“亲手敲代码”，但也不会自动消失，它会更多落在问题定义、执行环境、反馈回路和结果验证上。
技术拆解-ChatCut
ChatCut 值得关注的地方，不是“AI 自动剪视频”这个口号，而是它把视频素材先变成可检索、可推理的语义索引。剪辑的核心动作也就从拖时间轴，变成了找素材、组织叙事和生成可编辑的片段序列。
AG-UI
AG-UI 对我最大的启发，不是又多了一个协议名，而是它把 Agent 和前端 UI 之间的边界讲清楚了：模型怎么想是一层，工具怎么调是一层，运行过程怎么让用户看见、确认和接管，又是另一层。
关于VISALL改版的想法
回溯过往，我们将所有用例（Case）的逻辑都堆砌在 iFinD 的 spec 主题下。例如，单份文件可能包含 5000 多行代码，其中充斥着大量的 if-else 判断。这些逻辑的本质，实际上就是针对不同 Case 进行差异化的主题配置。
可视化能力构建
第一部分是关于组件能力。我们提供了许多可视化组件，主要落地在公司to B和to C的业务中。业务方通常在我们的平台上进行一站式的可视化配置，完成后以代码形式将这些组件应用到他们的项目中。此外，我们对这些组件进行了上层封装，提供不同主题以适配各业务线，比如海外业务线、首长的业务线、资讯业务线等；同时也
MediaPipe学习笔记
在现代 Web 开发中，交互方式早已不局限于鼠标和键盘。随着计算机视觉技术的进步，特别是 Google MediaPipe 的出现，我们可以在浏览器中以极低的延迟实现人脸追踪、手势识别等高级功能。
英语语法中的常见概念
请帮我梳理下，并对这些概念进行合理的分类、说明（包括其英文名称是什么，为什么要叫这个中英文名字)、举例等，方便我快速理解、学习、彻底掌握和应用这些内容。
Debug-HXKLine在低端机型卡死
如何避免上来就钻入细节，这里有2个技巧： - 先逮着问题反馈方，问10个问题 - 自己反复使用和测试出问题的页面，详见下一个章节 ### 没有明确现象和问题的范围域 >排查问题和架构设计一样，都应该遵循这个原则：自顶向下，逐步求精。
ECharts学习的本质框架
这个文章是将[[元框架-ECharts]]中基于「第一性原理 + 数学建模 + 形式化方法」的框架 简化为可用于团队培训的版本，目标是：不丢核心思想，但让工程师能听懂、能用、能落地、能快速掌握。
模板-ECharts业务配置
请从当前项目代码中，抽取可复用的工具函数，加入这个模板代码（visualization-framework）的合适位置中去
datav服务端改造方案
本文档旨在分析当前后端项目的结构问题，并基于领域驱动设计（DDD）思想，提出三种可行的重构方案，以提高项目的模块化、内聚性和长期可维护性。
单向数据流
单向数据流（Unidirectional Data Flow, UDF）是一种软件设计模式，其核心思想是数据在应用内的流动是沿着一个单一、可预测的方向进行的。该模式的精确定义是"将单向的变更（one-way mutations）应用于一个不可变的数据状态（immutable data state）"
技术拆解-PacificVis2025的状态管理与事件机制
本文档分析了 Pacific Vis 2025 可视化项目中使用的状态管理和事件系统模式，并将其与传统的 Flux/Redux 架构模式进行比较。
VISALL和StandardChart主题机制设计
可以提供一个default theme，即跨业务线通用的那部分主题。
可视化业务开发框架解析
一般是把2、3、4提出来做个链接，其目的是为了解决查询、管理问题，提高可维护性，可以理解为是一个微型数据库，算是个cache。
混合架构-基于D3.js的程序设计
这篇是一次 D3 代码整理。原来的时间线代码把数据处理、路径生成、样式设置、事件绑定都塞在一个类里，写第一版很快，但后面加交互、换主题、做测试都会慢下来。
Prompt-定制化可视化组件
您是一位资深的前端架构师，专门负责设计企业级数据可视化组件。请基于以下完整的架构指导，为用户设计一个高度定制化、可维护、高性能的单体可视化组件。
IoC容器设计分析
// 手动连接 this.renderEngine.resourceManager = this.resourceManager; this.interactionHandler.container = this.renderEngine.getContainer()
数据可视化组件库的架构模式
这篇把问题从“图表怎么画”往前推了一层。做组件库时，真正先决定的是用户是谁、API 长什么样、渲染层怎么抽、扩展机制要不要开放。
VISALL组件库的微内核架构分析
VISALL这个项目本身是基于微内核架构去设计的，但是随着多次版本的迭代，功能越来越多，其架构已经存在一些偏离了,因此准备对其进行系统的分析，找出里面存在的问题，然后我们计划对其进行一次重构。使其更加符合微内核架构的设计理念，以增强其程序质量和可维护性、可扩展性。
InversifyJS重构3D项目
Pacific Vis 2025 是一个基于 Three.js 的复杂数据可视化项目，用于展示全球女性投资者相关的社会经济数据。随着项目复杂度的增长，我们面临着严重的架构问题：循环依赖、手动依赖管理、模块间耦合度过高等。本文将分享我们引入 InversifyJS 进行重构的真实经验，包括具体的代码对
基于AI进行项目重构的工作流
最近我在频繁地进行项目的优化重构操作，在这个过程中积累了一些理解项目和分析项目的经验，这里简单地记录一下作为今后的参考。
通过一个项目掌握Agent开发的全部内容
目前，Agent 相关的开发已经成为主流趋势，因此出于多方面考虑，我们必须掌握 Agent 开发的流程以及相关的技术细节。
从J2EE思考可视化的基建该如何建设
在当今数据驱动的时代，可视化系统已成为企业决策和用户体验的核心组成部分。然而，构建一个健壮、可扩展的可视化平台并非易事。本文将借鉴J2EE（Java 2 Platform, Enterprise Edition）的架构思想，探讨如何构建现代化的可视化基础设施。
资讯可视化-如何提升生成内容的质量
目前，我们对 prompt 的依赖程度过高，大部分逻辑都通过 prompt 来实现，这一现状带来了大量的不确定性与稳定性问题。对此，我认为较为合理的改进方向应从两个层面着手： 第一，将部分工作从 prompt 转移到工程化层面，尤其是那些具备确定性的工作，比如一些程序化计算流程的管理等； 第二，对于
weekly-summary-20250831
https://www.ruanyifeng.com/blog/2025/08/weekly-issue-363.html
资讯可视化-基于沟通日志的AI复盘
同时，请依据这些问题的严重程度、出现频率等维度做出分析排名；在此基础上形成一份总结表格，并将上述所有分析结果写入本地 Markdown 文件。信息越详细越好，不要丢失任何信息。最后，请再反思文档与已分析的问题，确认是否还有可以补充的内容。
AI时代架构师的核心职责
AI 的普及并未削弱架构师的价值，反而要求其从 "代码编写者" 转向 "全局掌控者"，核心职责主要体现在需求与架构的翻译、质量与效率的守护、团队协作的枢纽这几个方面。
技术拆解-时间轴曲线组件
这是一个基于 Stencil 框架的高级时间线组件，实现了蛇形布局和复杂曲线连接效果。组件使用 SVG 遮罩技术、多层渲染架构和渐变色系统，提供了专业级的可视化体验。
AI开发中是否应该使用框架
在 B 站看到一个视频：不要用 AI 框架，作者的观点和观众的评论很有意思，因此我用 AI 将其整理了一下。
本地依赖分包踩坑经历
最近在 HIVIS 可视化组件库项目中，我们遇到了一个典型的本地依赖分包问题。这个问题看似简单，但背后涉及到了现代前端工程化的诸多核心概念：模块解析、构建系统、依赖管理等。
近期关于AI Coding的感想
最近这段时间，我几乎每天都在和各种 AI 编程工具打交道。这个过程有点像是在玩一场大型的"抽卡游戏"，有时候你会抽到 SSR，有时候则是连续的 R 卡。
如何编写测试代码
项目下的fixed、final等等文件，是否都是之前调试过程中的产物呢？现在调试完成了，是否应该对测试模块下的代码进行一个整体性的梳理，去掉这些 │ Fixed、Final 等等文件，将其编写为整洁的代码呢？ 另外帮我分析一下目前的这个测试模块，其程序设计、技术选型等等是否
技术拆解-LangExtract
LangExtract 是由 Google 开发的一个 Python 库，专门用于使用大型语言模型（LLMs）从非结构化文本中提取结构化信息。该项目提供了一个完整的信息抽取流水线，具有高度的准确性和可扩展性。
Chrome插件开发技术选型
在过去的几周里，我和我的团队深度参与了一个 Chrome 插件开发项目，从最初的技术选型到最终的 POC 验证，踩了不少坑，也积累了一些经验。今天我想把这些经验分享给正在考虑 Chrome 插件开发的你。
技术拆解-如何编写书签管理的Obsidian插件
最近在使用 Obsidian 做笔记管理时，发现一个痛点：虽然 Obsidian 内置的书签功能能收藏重要文件和文件夹，但访问起来不够便捷，特别是当项目文件越来越多的时候。于是我们决定开发一个书签管理插件，通过一个优雅的仪表板界面，让用户能够快速访问收藏的文件夹、笔记和最近打开的文件。
AI可视化增强分析助手开发实践
这篇记录的是一次“把 AI 分析放回阅读现场”的尝试。用户不用复制到别的工具里，选中文本后就在浏览器侧栏里看到分析结果、图表、流程图或者富文本解释。
更安全的解析function字符串
在开发基于 AI 的 ECharts 配置修改器时，我遇到一个问题：当 AI 返回包含 JavaScript 函数的图表配置时，这些函数在传输和解析过程中丢失，导致动态配置（如颜色函数、格式化器等）无法正常工作。 关联内容：[[流式输出]]
weekly-summary-20250720
F10的技术选型： https://fellou.ai/eko/docs/getting-started/eko/
Gemini CLI 使用技巧
这篇是我用 Gemini CLI 一段时间之后攒下的技巧和踩坑记录。不是文档搬运——官方文档能查到的我就不重复了——重点是那些实际用起来才发现的点：什么场景它好用、什么场景它会让你抓狂、以及跟 Claude Code 比起来各自的定位。
Gemini CLI 源码分析
不过目前使用起来，感觉还不达成熟。不过因为是开源的，估计过一段时间会好很多，可以当成一个储备的工具先关注着。 目前的重点，还是借助其源码，学习一下AI CLI的实现思路。
技术拆解-大事标记折线图
// - 自定义标记图元（dvMarker，显示事件详情）
weekly-summary-20250406
灵活适配的模型选择 得益于多 Agent 架构，我们可以根据任务的复杂度和模型的特点，灵活选择最适合的模型。例如，对于数据拆分这类相对简单的任务，7B 小模型即可快速输出结果，确保高效执行；而对于更复杂的任务，则可以选择更强大的模型来保证输出质量。
阅后即焚类型的可视化
解决<font color="#ff0000">长尾</font>可视化需求、<font color="#ff0000">一次性</font>需求。 目前AIGC暂时不能解决复杂可视化问题，就先解决简单可视化问题。 展平式的SVG + Claude ## 适用场景 不同的方向，产品规划和技术路线是
weekly-summary-20250323
这周我的睡眠时间严重不足，每天基本只睡了6个多小时，但令人惊讶的是，我整体精神状态却非常好。白天也不犯困，这主要归功于我感觉正在做的事情对我而言非常有意义——每天都在花时间准备系统架构设计师的考试。
weekly-summary-20250223
注意，这里的"b"是小写，表示比特位（bit）。平时使用的 MB 和 GB 的"B"是大写，表示字节（Byte），一个字节等于8个比特位。 视频应用对网速的需求最大，Netflix 的 4K 视频，网速要求是每秒 15 Mb，4G 网络下可以同时打开三、四个窗口播放。
weekly-summary-20241208
https://www.zhihu.com/question/5861691391
weekly-summary-20240915
单元测试用于验证正确性，Self-play 用于尝试和学习，两者结合，可以实现 AI 可视化配置！ UI 稿/截图-LLM 试错-单元测试验证-LLM 试错-单元测试验证...... 将可视化配置任务转换成一个类似围棋的自我对弈任务，通过强化学习解决。 这个是一个很好的思路，可以尝试一下，有搞头！
Weekly Summary(20240623)
不管是业务领域的程序设计(比如我就是可视化库和功能的领域)，还是诸如写 CSS 这种细节的实施上，最高效的方式都是对你的工作内容进行抽象，形成套路。
可视化技术架构升级
现在处于类似jQuery和三大框架之间的那个框架层出不穷的阶段，后面会有一个或者几个牛逼的技术框架来统一整个开发领域，Agent可能会是一个选项。
前端的架构设计
https://www.zhihu.com/question/26646855/answer/68503768
3D写实风格
https://www.zhihu.com/question/399445153/answer/1311717764
组件与数据流
https://zhuanlan.zhihu.com/p/26426054
Weekly Summary(20211114)
上周四突发的几个事情，占据了我不少时间，包括更新展示大厅的 PPT、和设计师核对交互细节、新的发布流程(起码 3 小时)等。
可视化组件设计
应该先画图，有哪几个生命周期，每个阶段应该做什么，不应该做什么，把这个想清楚，形成原则，就是设计了，框架也就出来了。
Weekly Summary(20210124)
2021 怎么走？还是这样肯定不行，得变更，得跳出舒适圈。
前端团队的问题到底是什么？
现在前端团队都是分散到各个具体业务中的，这就导致信息互通、技术工具的整合推广，都存在问题。前端年初都会列出很多待解决的问题，我们也知道有很多事情应该去做，但是究竟这些问题里面，最影响开发效率、性价比最高的20%内容是什么，其实是没有数据来支撑验证的，因此我们的改进还是稍微有点拍脑袋。 形成对比的就是
如何写好后端业务代码
形成一个自己的程序框架至关重要。程序框架其实就是你抽象自己的设计思路，抽取可复用部分，形成后续项目的基座。里面应该包含了程序目录结构、调试工具、编码规范的约束工具、日志工具、发布工具、常用函数库、常用业务库等等。这样就避免每次你都从头再来一遍，也避免了犯一些低级错误。
Flutter安装笔记
我平时喜欢看小说，但是现在的小说APP广告太多了：启动应用有广告，从其他APP切换回来又有广告，体验很不好。因此我想自己写一个简单的文档阅读APP。考虑到现在Flutter挺火的，就准备用这个试一试。因此这里记录下安装Flutter的过程中遇到的一些问题。
为什么拓扑图项目的进度管理做得这么烂
拓扑可视化平台这个项目的进度让我很不满意，比预期的时间整整多了三天。究其原因，在于我的项目管理做得太烂了，基本上没有什么规划可言。
疫情地图开发总结
在一知半解的情况下，凭感觉去评估难度、工作量和时间，结果很多细节上的问题都没考虑，估算的时间可能只有真实工作量的三分之一(甚至更少，比如这次我预估半天不到就能搞定，结果搞了整整两天，且第一天还是三个人一起搞)。
平台即服务
这是缘于最近SMM给我提的需求：提供一个通用的拓扑结构，展示不同业务方的数据。经过跟SMM的沟通，我发现他期望的其实不是一个拓扑组件，而是一个涵盖了数据接入标准、存储、可视化呈现的平台。通过平台对外提供服务，服务于公司所有的业务。结合最近在关注的前端平台搭建相关的内容，我突然想到，这个需求不就是一个
什么是架构师
架构师(Architect /ˈɑːrkɪtekt/)是很多技术人员的职业发展目标。但是绝大多数人(至少我身边的绝大多数人)，对于架构师的定义、工作职责、能力要求并没有一个很清晰的了解。这也就导致大家的职业规划只是嘴上说说，没有明确的目标和行动策略。
Weekly Summary(20200412)
现在技术更新越来越快，工作压力也与日俱增，再加上自己年龄逐渐增大，这两年考虑这方面的内容比较多。其实这个问题的答案很早就有了，那就是持续学习才能让自己不被淘汰。但是光是学习还不够，你学习的速度、产出的价值还需要能跟得上业界的发展、公司的发展速度，否则就意味着竞争力的下降，最终只是迟一点被淘汰而已。
如何编写方案设计文档
我们需要在一开始，就把这三要素给讨论确定下来。这部分内容花费的时间多一点也是很值得的。
Weekly Summary(20200329)
业务组件的建设和推广，结合结果页，找几个新业务实践下，我们不只是提供可视化组件，这样才能扩大团队规模，才能发展。
Weekly Summary(20200322)
因为有所求，希望能快点搞定，早点回家。 这说明我自己想去做的事情，动力还是很足的。
《阿里巴巴中台战略思想与架构实战》读书笔记
公司在金融市场发展到现在，接下去的路可能是如下三方面(都是营造差异化的竞争力)： 1、中台战略：借助中台，快速试错、大量试错，不因为开发、效率等问题放过任何一个创新点，找到创新点进行突破 2、可视化战略：视觉、交互的升级，公司发展到一定阶段，这部分内容的重要程度会越来越高 3、技术战略：通过AI技术
近期写总结计划过程中的一些想法
企业最关心的（或者说唯一在乎的）事情，就是增加收入、降低成本。 企业实际上需要的不是程序员，而是能够帮助它们增加收入、降低成本的人。 企业雇佣你，是为了让你帮它们完成某个可以增加收入、降低成本的项目，而不是为了让你追求个人的软件成就。
如何画出优秀的架构图
Office的PPT在画图时其实是很强大的，这个已经能够满足常规需求了，因此直接选择PPT作为画图工具即可。