今年上半年，团队里的 AI Coding 经历了两个阶段。第一阶段是把「怎么做事」写成 Skill 和 Rules，让不同同学、不同 IDE 里的 Agent 按同一套流程推进需求，3 月做了内部演示，中后台开始推广。第二阶段是发现流程跑通之后，瓶颈换了位置：代码写完要发布、要看监控、要配 AB、要补埋点，这些动作全都要碰内部基建，而 Markdown 里的规范管不住这件事。hbcli 就是从第二阶段长出来的。
这篇文章写在 9 月初，先讲第一阶段的工作流是怎么分层的，业界现在怎么做这件事，再讲它的边界在哪里；然后进入主线：hbcli 作为 Agent 执行面是怎么设计的，星枢在这条链路里管什么，哪些管控是必须的，哪些尝试有效。
我们团队负责公司内部的 AI 应用平台。平台跑起来的第一年，接得最多的是问答类场景：知识库问答、制度查询、接口文档答疑。这类场景上手快，用量数字也拿得出手，但有个共同的毛病：用户问完就走，AI 到底替谁省下了哪一件具体的事，说不清楚。所以 2024 下半年我们做了件挺笨的事，挨个找业务线和值班团队聊，问他们每天最烦、最重复、又最不敢不做的事情是什么。告警是我们发现值得做的一个点。
我们和某条业务线的同学一起盘过一次他们的告警。结论不太好看：告警多到没人能逐条看完，其中有很大部分是正常波动、重复触发或者短时抖动，值班同学长期处在告警疲劳的状态里。这不能怪谁不负责。告警量一旦超过人能处理的上限，人会自动降低对每一条的敏感度，而在这种状态下漏掉一条真实事故，往往事后才知道。
今年我们团队在 AI Coding 上投入挺多，开发这一侧的交付速度确实快了。但很快发现一个问题：需求出得快，测不过来。回归测试还是靠人点，多机型兼容还是靠人堆，很多小需求排不到测试资源，前端同学自己点两遍就上了。瓶颈从写代码挪到了测试。
那时候各种 GUI Agent 的 Demo 也很多，模型看一眼截图就能说出页面上有什么、该点哪里。我们就动了念头：能不能让 Agent 去操控真机做测试？于是我和测试团队一起发起了一个探索性项目，代号「海螺智控」。项目直接改造测试团队已有的平台和云真机能力，没有再建一套新平台。投入人力不多，定位很明确，就是验证一件事：测试能不能从「脚本执行」走到具备感知、规划、行动、评估能力的引擎，走通「需求 / 用例 → Agent 操控真机 → 报告」这条链路。
2023 年初去听 GMTC，回来写过一篇总结。那时我接手前端监控平台一年多，团队还小，文末记了两个想法：做基建先解决眼前的业务问题，等相同需求多了再抽象；前端要靠技术方案和方法沉淀，减少重复劳动。
两年多过去，职责已经跟当初不一样。那时我还是独立负责模块的开发；后来晋升，逐步负责大前端部门里一个大约八九人的前端小组；今年年初开始负责整个前端组，算上外包有二十多人。人数翻了一倍多，日常要处理的事情也跟着变了。
带八九人小组的时候，我大致知道每个人每天在做什么，推进项目也常常是盯着一条主线往前走。线上问题、联调卡住、方案拿不准，我自己接手处理，团队很快又能转起来。到了二十多人，业务线、平台、探索项目同时在跑，我继续靠自己到处补位，往往这边刚处理完，那边又出问题。那两个早年的想法还在，只是我更常想的问题变成了：这件事值不值得做，该交给谁，怎么少犯同一种错，以及怎么和一个想法不同的人把话说开。
很多地方仍是经验探讨，未必适用于别的团队。
2022 年中，我们大前端基础部门有两类事情很烧人。一类是线上应用指标波动，凌晨被电话叫起来归因；另一类是每天在群里重复回答基建系统和组件的用法问题。那时的想法是让扁鹊做自动归因，再在钉钉和基础项目里接一个问答机器人，把答疑接住。
问答机器人最早打算用语义分词加定制场景规则来做。调研之后发现维护成本压不住：系统名、组件名、告警口径一直在变，每加一个场景就要补一批词典和规则，通用不了，也复用不了。所以前期只落地了扁鹊的自动归因，问答那半件事搁下了。
转折在 2022 年 11 月前后。GPT-3.5 出来，我用 LangChain 串了一个知识库召回的 Demo，把内部文档灌进去，用自然语言问，答案居然大致能用。这件事后来长成了公司内部的 AI 应用平台「海螺」。这篇文章只讲一件事：它的问答准确率怎么从最早约 40% 一步步抬到 85% 以上，以及我在这个过程里对 RAG 的几点认识。
2020 年我写过两篇《前端监控系列》，一篇讲性能监控，一篇讲数据上报。那时候关心的是浏览器里怎么把指标算准、怎么把日志发出去。后来到了现在的公司，接手内部的前端监控平台扁鹊和配套的埋点 SDK 天启，才发现日志发出去之后的事，比发出去之前难得多。
扁鹊目前支撑公司内部 500 多个前端项目，H5、Web 和小程序都在里面，日均日志 10 亿条以上。链路本身没什么特别：天启 SDK 采集性能、错误、网络和自定义日志，经公司的数据网关进 Kafka，Flink 做清洗和实时处理，明细和聚合落在 ClickHouse，Node.js 服务负责查询编排，前面是一个 Vue 的平台页面。业界做前端监控，架构大同小异。
两年前有一段时间，随着公司业务的发展，新业务的增加，埋点数据的上涨，导致这条链路的状态很差。Flink 任务频繁重启，高峰期数据延迟五六十分钟是常态，最差接近 2 小时。业务同学线上出了问题，打开扁鹊看到的还是一个多小时前的数据，等于没有监控。这篇文章把这件事从头到尾讲一遍：怎么定位、怎么先止血、做了哪些治理、延迟怎么降到 2 分钟以内，以及哪些地方今天回头看还可以做得更好。
在 CentOS 7 下，无法安装 Node 18 以上版本，该如何解决？本文给出完整步骤与常见错误的处理。
随着公司内部对各类报表需求的不断攀升，原有的极光系统已经无法满足移动端、实时大屏等各类场景；另外由于页面逻辑中涵盖了大量计算，导致页面性能偏差且无法支持灵活的外部拓展，导致数据源单一；最后由于项目比较久远，整体UI风格相对老旧、交互方式单一。为了满足公司内部各业务灵活的数据报表产出需求，以及保证数据团队报表产出效率，就有了我们的北极星报表搭建平台。
很荣幸跟几位同事一起参加了 GMTC 全球大前端技术大会。本文按主题梳理我的现场笔记与思考，涵盖工程化、性能与监控、团队管理等方向。
随着2022年新年钟声敲响，我开始在键盘上敲下了第一行字。这篇年终总结其实在12月中旬就想写了，当时就大概想了下，列了下提纲，然后就因为各种原因搁置到了现在（拖延症真的很难治）。晚上趁儿子睡熟，老婆在忙，还没入睡的这段时间，来完成一下去年的任务吧。
在来新公司差不多3个月的时候，老板让我完成一下组内的KPI — 在公司内部的技术分享会上来波分享。刚开始还是有点慌的，但是换位想想，其实可以把这个机会当成自己这段时间的工作总结，也可以锻炼锻炼分享能力，何乐而不为呢。然后果(you)断(yu)的就答应了。
其实想起来写这篇文章，分享已经结束差不多要一个月了。想想不能就这样结束了，还是要整理一些资料做为产出。所以就有了这篇文章，对分享PPT做了删减和去敏。
已经有将近一年没有发文章了，中间换了一次主题，然后大致配置了一下，就一直没关注了。 然后一直忙，直到这段时间，翻了翻博客发现，评价好像有问题，数据统计分析也有问题。而且之前在阿里云申请的lion1ou.win的域名被签到国际站了，而且还备案不了。而且由于刚换工作，周末时间也空闲了一些。然后就萌生重拾博客的想法，顺便再梳理一下自己做过的一些小项目。说干就干，9月底开始动手。
性能监控和错误上报只是辅助功能，不应阻塞页面加载，因此只有当页面完成加载后，我们才进行数据获取和上报（实际上，页面加载完成前也获取不到必要信息），性能数据可以在页面加载完之后上报，尽量不要对页面性能造成影响。
错误监控主要是为了在sls看板上，能更加全面的展示我们项目的情况，所以这边加了个错误上报的口子，其实错误上报很简单，只需要全局捕获几种类型的错误就好了。
什么是性能监控，主要要监控哪些指标，有什么意义呢？
我们经常会遇到这样一个情况，发布在线上的页面，有一天老板或者是其他同学跟你反馈，你的页面怎么这么慢，是不是有bug。然后你会自己打开对应的页面，看了看感觉速度正常，也算是秒开吧。然后你再关闭缓存，再试了一下，还是好的呀，哪里慢了？这个时候你就很难评估出来这个页面到底是真慢还是某个设备的网络问题。
这种在单个设备上的表现，其实很难准确反映我们的页面在线上运行的真实情况。线上环境包括不同的设备、不同的宿主环境、不同的运营商网络、不同的地区这些关联因素，所以我们就需要有一套可以监控线上环境运行情况的系统。
随着业务的需求的增加，前端项目也越来越多，项目之间的代码风格也不尽相同。如果一个项目涉及多个同学维护的话，那这个项目的代码风格就会比较糟糕了。而且有的同学本地可能用了格式化插件，所以保存之后会造成整个文件的代码被格式化，其实可能只修改了一行代码。这样在做合并代码 review 时，很容易就会被忽略，也失去了 review 的意义。
前端的环境太多，很多问题并不是在浏览器上就能查出来，所以就需要掌握各个环境的调试技巧。
用了多年 Mac，收集了一些 Mac 软件，用来跟大家分享一下
上手 RN 开发也有一段时间了，为了让团队其他同学也能快速上手，也算是对自己学习过程的一个记录。 这里整理了一下整个开发过程需要注意的点，因为是面向大前端所有同学，所以也包括了前端、android、ios 的相关知识。主要分成几个部分：环境搭建、基础知识（RN 基础、前端基础）、学习资源
iconfont 显示成图形图标的字体，因为字体是矢量化图形，具有分辨率无关的特性，在任何分辨率和 ppi 下面，都可以做到完美缩放，不像传统位图如：png，jpg 一样，放大后会有锯齿或者模糊。
为什么使用 iconfont 对比图片大小来说容量更小，支持样式修改(大小，颜色)，适应多分辨率，网上有很多现成的 iconfont 资源可以使用。
主要是介绍了 react-navigation 的相关配置和样式设置，以及 react-navigation 内的 navigation 属性。navigator 主要分为以下三种类型：StackNavigator、TabNavigator、DrawerNavigator，每种类型都有其相应的使用场景和配置项。
在 React Native 中，你并不需要学习什么特殊的语法来定义样式。我们仍然是使用 JavaScript 来写样式。所有的核心组件都接受名为 style 的属性。这些样式名基本上是遵循了 web 上的 CSS 的命名，只是按照 JS 的语法要求使用了驼峰命名法，例如将 background-color 改为 backgroundColor。以下备忘一下，常用的样式和用法说明。
乐刻教练端业务是一个 Hybrid APP，通过原生 APP 提供调用原生能力的外壳，内部逻辑全部使用 H5 页面实现。 这种方式在早期产品需求快速迭代，客户端资源紧张的情况下，解决了很大一部分问题。但随着业务需要和使用人数的增加，教练端已经有点力不从心的。在 3 月份，已经对教练端进行过一次优化，主要集中在资源加载、初始数据、转场动画等。接下来，想要结合 HTML5 离线缓存机制，进行一些优化尝试。
不知不觉毕业已经将近三年了，干前端也有两年多了，从刚开始的门外汉也慢慢的成为一个能独立干活的职业猿了。两三年时间经历了很多次选择，从弱电到编程，从上海到杭州，但每一次的选择似乎都让自己向上又迈了一步。
第一次接触到混合开发应该是在一年前，当时在做 ionic 和 Cordova(PhoneGap)项目的时候，这些框架在 web 基础上包了一层 Native，然后通过 Bridge 技术使得 js 可以调用视频、位置、音频等功能。目前手上负责的项目则是一个与自家 APP 交互的混合开发项目，于是在课余时间就查了查相关的实现方案和原理。本文就是介绍这层 Bridge 的交互原理，主要描述了 js 与 ios 及 android 底层的通讯原理及 JSBridge 的封装技术及调试方法。
JavaScript的一大特点是，函数存在定义时的上下文和运行时的上下文以及上下文是可以改变的这样的概念。call、apply和bind都是为了改变某个函数运行时的上下文而存在的，换句话说，就是为了改变函数体内部this的指向。以下是三个相似点：
作为一个前端开发，不能使用Google，那不就是相当于失去了左板右臂，这怎么可以？ 但是要钱的FQ服务又有点贵，不舍得花钱，那今天我们就来薅一把亚马逊爸爸的羊毛。
在实际开发过程中，经常会接到产品关于分享海报，生成海报，照片合成等需求，这里就简单总结一下。关于一次海报合成的填坑过程，欢迎指正。
在项目开发中需要自己搭建配置前端服务，发布代码，所以捣鼓了一下 nginx。在这里记录一下，相应的常规配置。Nginx 是一款轻量级的网页服务器、反向代理服务器。相较于 Apache、lighttpd 具有占有内存少，稳定性高等优势。它最常的用途是提供反向代理服务。
运行 node 服务时，如果直接通过 node app 来启动，如果报错了，整个服务就会直接停止运行。所以开发时和在服务器运行时，需要一个进程管理的工具，一般有 forever，pm2，supervisor 这几种。
最近买了一台学生阿里云的服务器，开始建一个属于自己的小网站和一些项目 demo，所以开始了解 Linux 系统的相关知识和相关使用，入门第一步当然是命令行操作了，下面记录了一些常用的命令语句。
浏览器的主要功能是将用户选择得web资源呈现出来，它需要从服务器请求资源，并将其显示在浏览器窗口中，资源的格式通常是HTML，也包括PDF、image及其他格式。用户用URI（Uniform Resource Identifier 统一资源标识符）来指定所请求资源的位置。
BFC 是什么？从没有认识到最初的认识是一个关键且困难的过程。网上的很多文章都会写道：BFC 是一个环境。这样的写法让人看了就头疼：我们在 HTML 和 CSS 中好像从没接触过环境这个概念。
下面不妨让我用通俗的方式解释一下 BFC 的概念：BFC 可以简单的理解为某个元素的一个 CSS 属性，只不过这个属性不能被开发者显式的修改，拥有这个属性的元素对内部元素和外部元素会表现出一些特性（后面会讲到），这就是 BFC。
在前后端分离开发时为什么需要用户认证呢？原因是由于 HTTP 协定是不储存状态的(stateless)，这意味着当我们透过帐号密码验证一个使用者时，当下一个 request 请求时它就把刚刚的资料忘了。于是我们的程序就不知道谁是谁，就要再验证一次。所以为了保证系统安全，我们就需要验证用户否处于登录状态。
ESLint 是一个插件化的 javascript 代码检测工具，它可以用于检查常见的 JavaScript 代码错误，也可以进行代码风格检查，这样我们就可以根据自己的喜好指定一套 ESLint 配置，然后应用到所编写的项目上，从而实现辅助编码规范的执行，有效控制项目代码的质量。
meta是html语言head区的一个辅助性标签。也许你认为这些代码可有可无。其实如果你能够用好meta标签，会给你带来意想不到的效果，meta标签的作用有：搜索引擎优化（SEO），定义页面使用语言，自动刷新并指向新的页面，实现网页转换时的动态效果，控制页面缓冲，网页定级评价，控制网页显示的窗口等！
apidoc是一个生成RESTful API文档的工具，它通过代码注释中的特定格式和内容，生成API文档。目前支持的语法有:Java、Javascript、C#、C/C++、D、Erlang、Go、Groovy、Pascal/Delphi、 Perl、PHP、Python、Ruby、Rust、Scala 和 Swift。
今天来探讨一下 HTML5 的 range 这个新的 input 类型，不过重点不是在 range 要如何使用，而是在如何去改变 range 的样式，做出一个漂漂亮亮的滑动杆。
过去我们要制作美美的滑动杆 ( range slider )，不外乎就是用个 span 或 div ，搭配判断滑鼠座标 ( pageX、pageY ) 与点击事件来制作，就算是 HTML5 具有了 range 的 input 类型，预设的样式只能满足基本的需求，对于有一些要求视觉设计的网站来说，根本就毫无用武之地，只好自己手动干一个 range slider 来用了。
要说到”响应式布局设计”，我们先来介绍一下另外一个名词：”自适应网页设计”（Responsive Web Design），最早是Ethan Marcotte在2010年提出的。指的是可以自动识别屏幕宽度、并对页面的布局会基于一定的因素搭建做出相应调整的网页设计。自适应布局能够提供一种更加实用的解决方案，使得项目的实现成本更低，并且更加易于测试。自适应布局可以被看作是响应式布局的一个更加廉价的替代品，换句话说自适应网页设计就是一个精简版的响应式布局。当固定宽度与流动宽度结合起来时，自适应就变成了响应式，响应式网页设计指的是页面的布局（流动网格、灵活的图像及媒介查询），响应式布局等于流动网格布局，而自适应布局等于使用固定分割点来进行布局。
Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
正则表达式（Regular Expression，在代码中常简写为regex、regexp或RE）是计算机科学的一个概念。正则表达式使用单个字符串来描述、匹配一系列符合某个句法规则的字符串。正则表达式是由普通字符（例如字符 a 到 z）以及特殊字符（称为”元字符”）组成的文字模式。模式描述在搜索文本时要匹配的一个或多个字符串。正则表达式作为一个模板，将某个字符模式与所搜索的字符串进行匹配。
我们经常会看到，一些站点在首次进入的时候会先显示一个进度条，等资源加载完毕后再呈现页面，然后整个页面的操作就会非常流畅，因为之后没必要再等待加载资源了。尤其是在移动端，或者是页游中，这样做能避免页面出现白屏（等待加载图片），很大程度提升用户体验。那这种技术是如何实现的呢？其实非常简单，本文就来从基础细节探究一番。
iTerm2 是 MAC 下最好的终端工具。可以简单的认为，iTerm2 是配置完毕开箱即用的 tmux。