山维空间

我的技术和生活

  • 我的 AI 学习一周总结：ChatGPT 开放插件系统

    我的 AI 学习一周总结：ChatGPT 开放插件系统

    本周主攻产品的注册、付费、计费系统，遇到不少问题，投入到 AI 学习的时间不太多，本来以为攒不够内容，没想到临近周末 OpenAI 又放了个大招，所以赶紧表达下我的观点，把这周总结发了。

    好好学习，天天向上。卷到最后，就是胜利。

    OpenAI 发布 ChatGPT 插件系统

    今天早上醒来，到处是 ChatGPT 插件系统的新闻，官方新闻在这里：

    We’ve implemented initial support for plugins in ChatGPT. Plugins are tools designed specifically for language models with safety as a core principle, and help ChatGPT access up-to-date information, run computations, or use third-party services.

    ChatGPT plugins (openai.com)

    除了一般的能力整合，更吸引我们注意的是，这次 OpenAI 还公开了一些带来更多可能性的功能（通过官方插件，不知道会不会开放给第三方）。

    网络浏览能力 Browsing

    类似 New Bing，这个功能让 ChatGPT 可以从互联网上获取资讯，然后结合强大的文本理解和推理能力，一方面对接用户的自然语言询问，另一方面代替用户从茫茫文海中查找合适的内容。

    这个能力十分让人期待，不过也让我隐隐有些担心：大家都依赖 ChatGPT 快速获得答案之后，互联网信息污染会不会越来越容易，也越来越容易造成破坏了？

    另外一个问题。ChatGPT 能否像搜索引擎那样广开善源，即从大量信息源总结出结果，而不是只有几个少数的信息源，比如 CNN？如果信息来源很多，它能不能正确的总结和分辨？又能不能在合适的时间内给出结果呢？有待观察。

    网络沙箱执行能力 Code interpreter

    GPT 的模型本身就能很好的理解和生成代码，但由于它并不是真的理解语法规范，所以生成的代码能不能执行比较看运气。如今，通过 Code interpreter，它可以在页面沙箱里执行的 python 代码，于是至少有三个方面的改善：

    1. 解决数学问题。以前逢数学题必错，将来不会了。
    2. 直接进行数据分析和可视化
    3. 文件类型转换

    信息提取 Retrieval

    ChatGPT Retrieval 插件可以访问个人和组织专属信息源，根据用户自己的数据生成更精准的回答。这个产品是开源的，可以部署在用户自己的环境里，相当炸裂，这下 LangChain 和 LlamaIndex 岌岌可危，我之前想搞的 Second Me 也可以换个方向了。

    但是，这也印证了开发者的担忧：大厂偷家怎么办？本来核心技术就在大厂，我们辛辛苦苦帮他们把产品方案趟出来，裤衩一声，大厂发布了自己的版本，我们呢？

    我对 ChatGPT 插件系统的想法

    插件系统会把用户留在 ChatGPT，大大威胁 Google 和其它传统入口

    之前 ChatGPT 最大的问题就是数据太旧，很多知识它都不知道，还特别喜欢编造结果，使得我们不能依赖它做决策。如今它可以从互联网上获得资讯，理论上可靠性大大提升；而且它的界面是自然语言，非常友好。未来可能会有越来越多的人依赖 https://chat.openai.com/chat 获取信息、做决策；也会有越来越多的语音助手接入他们的服务。于是用 Google、百度、Bing 获取信息的人就会减少，使用 hao123 这种目录网站的人几乎就是史前动物了。我认为对 Google 他们是大利空。

    可以想像，就像抖音快手分别带火大量新品牌一样，我认为所有厂商都不会放过这个机会，大家一定会涌入 ChatGPT 插件市场，试图用 AI 给自己引入新的用户。未来，CEO（Chat Engine Optimization）可能会和 SEO 一样重要。比如，通过在知乎问答“脸上长痘怎么办”里注入自己的品牌内容，可能比做一堆垃圾内容农场，更有价值。这么一想，利好知乎、Quora。

    插件系统并不会威胁其它 AI 厂商

    我倒不觉得插件系统会对其它 AI 厂商带来什么威胁——或者不如说，不会让威胁更大，因为模型领先太多。相反，ChatGPT 很可能通过自己的发展，给其它厂商打了个样出来，让大家知道怎么做产品。

    比如，多模态重要还是接入互联网重要？我觉得可能是后者，至少对百度而言，过去一周被反复处刑的文生图功能，是不是可以先放放？集中精力优化大模型，然后多做一些应用层的接口，可能更受市场欢迎。

    API 能不能用插件系统，怎么用？

    作为应用开发者，我觉得，插件能带来的功能，我用 App、自己的网站、浏览器扩展，都可以完成。（正如我在 之前的文章 说过的那样）。只要能获得合适的收益，在 iOS、Web、还是 ChatGPT 平台上做产品，对我来说都差不多，都挺好。

    所以我更关心技术天花板在哪里。比如访问网络的能力，我能不能在 API 里使用？怎么用？这关系到我能否拥有自己的产品入口，以及我应该怎么搭建我的基础设施。

    OpenAI 的云够用么？面向公共开放后，收费贵么？

    现在几乎所有 AI 产品都在排队，OpenAI 更是排队大户。我觉得除了产品本身的成熟度之外，他们的云服务承载能力和运营成本也是排队的一个重要原因。

    假设将来产品基本成熟了，单客成本会是多少呢？有多少用户能用上呢？我觉得也是个问题。所有的工具，都会加剧人与人之间的差异，将来善用 AI 工具的人一定比全手工的人高效很多，那么 AI 会不会导致新的不平等呢？

    Stable Diffusion 小进展

    这些问题可能都是国内才会遇到的，即然我是简中写作，那可能还有些作用吧。我们使用的是 AutoDL 的服务器，看起来是建在华为云上。服务器官方提供代理，可以加速 GitHub 访问，但是我们这个区刚好没有，惨兮兮……当真是没有困难创造困难也要上。

    安装扩展

    SD webui 默认仅允许本地环境在线安装扩展，我们部署在服务器上的环境必须添加 --enable-insecure-extension-access 到 COMMANDLINE_ARGS 里才可以。配置并重启服务之后就可以了。

    直接 clone https 协议的仓库可能会被墙影响，然而默认情况下，基本上所有扩展都要依赖 git clone https://github.com/xxxx 安装。此时我的解决方案是先生成 ssh-key：

    ssh-keygen -t ed25519 -C "meathill+sd@gmail.com"

    然后把 key 添加到 GitHub。再接着把 ssh 协议的仓库链接复制到“Extension > Install from URL”里安装，即可。

    安装完成后，很多时候仅重载前端界面不行，还是要重启整个服务。

    面部修复

    AutoDL 提供的镜像默认不包含面部修复功能，在第一次使用该功能时，SD webui 会尝试下载对应的包。因为服务器在墙内，下载地址在 GitHub，所以速度很慢，可能会超时或者断线失败。此时可以手动辅助处理，先下载到本地，然后上传到服务器。大约有以下几个文件：

    使用 Vercel Edge Function 调用 OpenAI API 的经验

    我总结了最近几周的开发经验，主要是使用 Vercel Edge Function 提供 API 服务时踩过的坑，汇集成一篇博客，推荐有类似需求、做类似技术选型的同学参考：

    使用 Vercel Edge Function 访问 OpenAI API 的注意事项

    一堆新品

    各大厂商发布了不少围绕 AI 打造的新品和改进的老产品，正如下图所示：

    这里简单列几个，大家有空可以试试。不过大部分都只是有限开放，要先加入 wishlist，等排队。

    • GitHub Copilot X 更好的代码辅助工具，可惜只能用在 VS Code
    • 文心一言 百度的竞品，目前还不能打，不过持续关注吧
    • Office Copilot 整合 GPT 到 Office 里，可能产生质的变化
    • Google Bard Google 的竞品，好像也要差一些
    • Adobe Firefly Adobe 把绘图类 AIGC 整合到自家的产品里，大大降低美术制图的门槛

    市场很热，OpenAI 的掌舵者对节奏的把握也很强，隔三差五就把大家刺激一波。我的观点还是：书上得来终觉浅，绝知此事要躬行。工程上总会有各种各样奇奇怪怪的问题等待我们去解决，有些可以用 AI 加速，有些则需要自己摸索。所以对大家来说，越早动手，工程积累越多，优势越大。

    大家加油吧。有空别忘了去排队。

  • 使用 Vercel Edge Function 访问 OpenAI API 的注意事项

    使用 Vercel Edge Function 访问 OpenAI API 的注意事项

    从某天开始，OpenAI API 无法从国内直接访问。而且，也不是每个人都有自己的云服务器，能够搭建独立服务。那么，还有别的办法能比较容易的访问到 OpenAI 么？当然是有的，比如 Vercel Edge Function，或者 CloudFlare Edge Function。

    这里我准备结合前阵子的开发经验，分享一下使用 Vercel Edge Function 访问 OpenAI API 的注意事项，让新来的开发者能少走弯路。

    推荐阅读

    开始之前，我建议大家先花点时间了解一下 Edge Function，以及如何使用 Vercel Edge Function 开发 OpenAI 应用。因为我后面要分享的主要是踩过的坑，所以先系统性了解会好很多：

    Building a GPT-3 app with Next.js and Vercel Edge Functions

    官方教程，还有 Demo 网站 和 GitHub 项目，非常友好。虽然是英文写的，不过并不难懂，实在不行就用 Edge 浏览器自带的翻译功能吧，建议大家好好学习英文。

    自有域名+CNAME 实现国内访问

    Vercel 给免费版用户也提供子域名+ SSL 证书，很多时候都够用，但可惜，vercel.app 大域名被墙了，连带所有子域名都无法访问。好在 Vercel CDN 在国内也还能用，所以我们只需要一个自己的域名即可。

    申请域名的选择有很多，国内几大云服务商都能注册，国外的域名供应商也可以放心使用。我比较常用的是 namecheap.com。便宜的比如 .xyz 域名首年只要几块钱，随便注册一个就能用。

    注册完域名之后，在 Vercel 后台找到自己的应用，在“Setting > Domains“里添加域名，然后 Vercel 会告诉你怎么配置 DNS。复制解析目标，在域名供应商 DNS 配置页面完成 CNAME 配置，稍等片刻，解析生效后，即可得到一个国内也能正常访问的域名。

    使用 Edge Function

    Vercel Edge Function 与我们日常开发的 node.js 服务器略有区别。它并非完整的 node.js，而是 Edge 基于 V8 专门打造的袖珍运行时，尽可能轻量化，裁剪掉很多系统 API。功能少，但是速度很快，几乎零启动时间。（我之前将它跟 Supabase 记混了，以为它也是基于 deno 的。）

    使用 Edge Function 的好处，简单来说：省运维；详细来说，大概有这么几点：

    1. 性能更好。比随便买个小水管强得多。
    2. 自带弹性伸缩。不管访问量怎么成长，都有 Vercel 集群帮我们自动伸缩。（当然可能需要付钱）
    3. 启动速度比 serverless 快很多，基本没有等待时间。
    4. 免费额度足够初期 MVP 验证。

    坏处当然也有。首先，Edge Function 里跑的是 TS，这就意味着很多兼容 JS 的开源仓库都不能用。其次，Edge Function 很多原生 API 都不支持，所以没有特意兼容的仓库也不能用。举个例子，要完成网络请求，大家最熟悉的 Axios 就不能用，只能用系统原生的 fetch。

    解决超时问题

    由于算法原因，OpenAI API 返回数据的总时间可能比较长，而 Edge Function 的等待时间又限制得很严。所以如果等待 OpenAI 返回全部数据再渲染，可能因为等太久，在 Edge Function 这里会超时。

    解决方案就是使用流（stream）式传播。在这种情况下，OpenAI 会逐步返回结果（差不多一个单词一个单词这样蹦），只要在客户端进行组合，就能看到类似实时输入的效果。

    完整的范例代码上面的官方文章有，我就不复制粘贴了，大家注意就好。

    Edge Function 的流不是最初的流

    这里有个坑，虽然我们在 Edge Function 里获取了 OpenAI API 的流，然后转发出来，但实际上我们接收到的流并不是最初的流。最初的流里，每次发送的数据都是完整的 JSON 文件，可以直接解析；但是 Edge Function 里转发给我们的却是前后合并后随机切分的结果。

    于是我们必须重新整理响应体。大概方案如下：

    1. 在每次返回的响应体里找到两个 json 的连接处
    2. 截断，拿到前面的 json，解析，得到自己想要的数据
    3. 继续查找完整的 json，如果没有，则和下一次响应体连接起来处理

    核心代码如下：

    class fetchGpt {
  fetch() {
    // 前面的代码参考官方例子
    // 我从循环读取开始
    while (!done) {
      const { value, done: doneReading } = await reader.read();
      done = doneReading;
      if (!value) {
        break;
      }

      // readableStream 读出来的是 Uint8Array，不能直接合并
      if (chunkValue.length > offset) {
        lastValue = concatUint8Array(lastValue, value);
      } else {
        lastValue = value;
        offset = 0;
      }
      chunkValue = decoder.decode(lastValue);
      [finishReason, offset] = this.parseChunk(chunkValue, offset);
    }
  }
  parseChunk(chunk: string, offset = 0): [string, number] {
    let finishReason = '';
    let nextOffset = offset;
    while (nextOffset !== -1) {
      nextOffset = chunk.indexOf(splitter, nextOffset + 1);
      const text = nextOffset !== -1
        ? chunk.substring(offset, nextOffset)
        : chunk.substring(offset);
      try {
        const json = JSON.parse(text);
        const [ choice ] = json.choices;
        const { delta, finish_reason } = choice;
        const chunkContent = delta?.content || '';
        // 这里我把数据交给事件 和 pinia 处理
        this.emit(MessengerEvent.MESSAGE, chunkContent, json.id, json.created);
        this.store.appendTextToLastItem(chunkContent, {
          id: json.id,
          created: json.created,
          system: this.options.system || '',
        });
        finishReason = finish_reason;
        offset = nextOffset !== -1 ? nextOffset : chunk.length;
      } catch (e) {
        //- ignore
      }
    }
    return [finishReason, offset];
  }

    常见 API 使用错误

    大家都知道，OpenAI 按照请求响应的 token 数算钱。所以我就想精打细算，通过在请求参数里减少 max_tokens，尽量少返回些内容。

    事实证明这个做法不成立。首先，OpenAI 对请求的兼容性不高，max_tokens 如果是 NaN 或者带有小数，都会报错。其次，ChatGPT 很啰嗦，内容量少了，它不过瘾，就会反复要求继续（finish_reason: 'length'），尤其在极端条件下，如果我们自动 continue，可能会误入死循环。

    所以我建议，max_tokens 最少 128，尽量 256 以上。

    前几天，有朋友在我的博客下面留言，说 Whisper 他试过，没啥特别的。我的观点不是这样。所谓纸上得来终觉浅，绝知此事要躬行。很多东西，确实不复杂，照着官方教程弄，三下五除二，在本地跑起来，并不难。但是想弄得干净利索，在生产环境里跑顺，遇到什么问题都能快速解决，也不是随随便便就能搞定的。

    希望有类似需求，寻求类似解决方案的同学能少走弯路；也欢迎大家多多分享，有意见建议，欢迎留言讨论。

  • 我的 AI 学习一周总结：GPT-4.0 发布

    我的 AI 学习一周总结：GPT-4.0 发布

    学习 AI 一时爽，一直学习一直爽。不知道这周能攒多少笔记，总之边学边努力吧。今天 GPT-4 发布了，感觉内容一下就够了，所以发布吧。

    GPT-4.0 发布

    今天的重大消息，昨天夜里（美国 3 月 14 日），OpenAI 发布了新版本大模型 GPT-4.0。新版本的训练量大幅提升，带来效果的大幅提升。群友做了一张总结图片，我先引用一下，方便大家快速了解：

    建议看下官方博客：GPT-4 is OpenAI’s most advanced system, producing safer and more useful responses。以及官方视频：OpenAI – YouTube。可以得到更准确、更全面的信息。

    这里我说几个我关注的点：

    1. GPT-4 的数据集与 GPT-3.5 一样，仍然截止于 2021 年 9 月份，并没有新数据进来。
    2. GPT-4 的可靠性据说提升了 40%，也就是编造不准确信息的概率降低了40%，某种程度上利好依赖事实查证的领域，但是考虑到他的数据滞后性和非联网，这方面的效果仍然有待观察。
    3. GPT-4 大幅提升了逻辑推理能力，可以得到更有价值的结果
    4. 大幅增加了上下文容量，最高可达 32k，是原先的 8 倍之多。更长的上下文意味着更好的结果、更大的可能性。
    5. 但是也带来了更高的价格，32k 是之前的 30 倍（8倍长度，30倍价格，啧啧）
    6. 目前只向 plus 用户开放，频率限制为 100 次请求/4小时。

    至于多模态，支持读图，我个人不太看重。当然，能给盲人带来更好的生活体验，是非常棒的一件事。只是我暂时不太能想出来，能用它快速做些什么。

    更大的上下文容量，配合更好的逻辑推理能力，我认为极大利好专业辅助领域，比如专业文献解读、商业文书生成与校验，等等。同时，因为大幅涨价，可能也只有这些领域愿意支付这样的成本。但是普通应用领域，我觉得 GPT-3.5 的潜力尚未完全开发，作为基础入门版学习 OpenAI 的产品开发也很足够，看起来 OpenAI 的产业布局相当到位，不知道国内外的竞争者是不是压力山大。

    ChatGPT

    chatpdf.com 中英文提问表现不一

    我向 Vincent 推荐了 chatpdf.com，他尝试之后，我们发现，如果用英文提问，ChatGPT 找不到内容就会老老实实回答：不知道，目标资料里没有相关内容。如果用中文，它就会编造一个答案。不知道是语料导致的，还是 ChatGPT 里有相关的配置。

    这也让我想到之前提到的，用英文让 ChatGPT 编造一个哈姆雷特的故事，它会拒绝；用中文，它就会满足用户的要求。不知道是语料问题还是设置问题。我其实怀疑是人为设置，毕竟中文语料不够，如果不瞎编答案的话，可能很多问题都没有结果，所以预料不够的环境，OpenAI 就会让 ChatGPT 自由发挥；语料够的话，就尽量保守（从模型产出）。

    Supabase

    Supabase（firebase 的替代品）使用 ChatGPT 重构了他们家的文档系统，现在搜索框里选择“Ask Clippy“就可以使用自然语言得到尽可能精确的答案。比如我问：how to migrate from firebase，就得到下图的答复（实际过程是 stream 输出，很 ChatGPT）：

    考虑到上面所说，英文提问，ChatGPT 不会瞎编答案，这个搜索结果可能相当可靠。如此一来，感觉 Algodia 也有危机 😂。

    Supabase 写了篇博客介绍这次升级：Supabase Clippy: ChatGPT for Supabase Docs，可以当作参考。他们用到了 PG Vector 这个 PostgreSQL 数据库的插件，感觉可以学起来。

    Embedding

    GPT-4 发布之前，最近一周大家的关注点主要有两个：首先，让 ChatGPT 掌握额外的知识，即 fine-tuning。我们可以通过 OpenAI embedding API 完成这个功能：

    1. 把新的内容利用 embedding API 生成符合 OpenAI 定义的向量
    2. 存入 Vector DB
    3. 新请求先从 Vector DB 取出可能的关联数据，然后一起发给 OpenAI 进行判断和答案生成
    4. Vector DB 可以选用 Supabase（存在架构限制），或者 PostgreSQL + 插件

    这方面成功案例已经不少，上一节的两个案例都是很成功的表现。我这周也想花点时间把自己的博客导进去试试，感觉这个方向必须有点积累。

    小模型好效果

    斯坦福微调（fine-tuning）了 7B LLaMA 模型，用 52K 的数据，达到跟达芬奇003 （在某些领域）接近的效果。因为模型小数据少，可以跑在更低端的消费级设备上，比如树莓派。群里也有朋友实测成功。

    tatsu-lab/stanford_alpaca: Code and documentation to train Stanford’s Alpaca models, and generate the data. (github.com)

    这也是大家关注的方向之一。即从大模型中切出一小部分，用在某个特定领域，满足某个特定需求，使用比较低端的设备，得到比以前好得多的结果。降本增效，始终是个好策略。

    我正好有个 4B 4G 内存，抽空试试看，不过只能用英文。

    没想到 GPT-4 这么快就发布了，坦率地说对我们这样的应用层来说，变化不大。对其它专业领域，会有深远影响。希望其它家尽快跟进，把价格干下来。

    我本人计划尽快开始学习 embedding 和尝试小模型，以及 whisper，先积累一些浅显的理解。

  • 【代友招聘】【API6】网关开发工程师

    【代友招聘】【API6】网关开发工程师

    刚刚收到 API6 的伯乐奖，老同事的公司棒棒哒！再帮他们吆喝几句，万一又有机会呢。

    API6 是我前厂两位同事离职后创办的公司，基于 OpenResty 打造新一代 API 网关系统，可能是国内现在最好的开源+商业服务公司。他们从一开始就拥抱开源，与社区一起发展，然后基于开源产品打造商业服务，是我非常看好且无比期盼的商业模式。看到他们越走越稳越走越高，我由衷感到高兴。

    推荐给各位有技术梦想的同学，他们的开源+商业服务模式，已经在很多领域、很多国家走通。能在国内落地的还不多，很值得我们学习。

    API 网关开发工程师

    岗位职责

    1. 研发基于 Apache APISIX 的下一代 API 管理和分析平台；
    2. 在 API 的大数据、行为分析、安全防护、云原生等领域保持技术创新；
    3. 参与 Apache APISIX 的研发，成为 committer 或 PMC（核心贡献者）。

    任职要求

    1. 对 Apache APISIX 或其他网关有深入的了解；
    2. 认同开源文化，熟悉开源协作方式；
    3. 良好的编码习惯，认同测试驱动开发；
    4. 良好的文档习惯及英文读写能力；
    5. 熟悉服务网格、k8s ingress controller 者优先；
    6. 开源项目贡献者优先；
    7. Nginx、Lua、OpenResty 代码贡献者优先。

    附加信息

    • 薪酬超过行业的平均水平；
    • 顶尖工程师文化的技术氛围，工程师都是 Apache committer 和 PMC；
    • 正常国内的五险一金福利；
    • 带薪年假；
    • 一个可以平衡事业和生活的工作环境；
    • 年龄仅仅是一个数字。不管您刚刚大学毕业还是已有家室，我们只为您的能力而来；
    • 我们是一家分布式的公司，员工分布在国内 6 个城市，通过 GitHub、Slack、谷歌文档、腾讯会议完成全部的协作。

    联系方式

    meathill@gmail.com （找我内推）

    recruit@api7.ai （官方招聘）

  • 【代友招聘】【全职远程】全栈 Next.js Web3 教学网站

    【代友招聘】【全职远程】全栈 Next.js Web3 教学网站

    事情是这样的。前厂去年年底把我们遣散后，我就找了一些工作来做，这是其中之一。我们最初要参加一场 Hackathon，作品是 Web3 教学网站，用游戏闯关的模式，吸引更多人来加入 Web3 开发。Hackathon 之后，老板决定把产品延伸扩展，做成独立产品，继续推广，让更多人可以用。

    按约我本打算继续帮他们做开发，但如今我已经确定要跟 Vincent 一起做 AI 应用层的产品，时间上不够两相兼顾，必须辞去一边。经过协商，我接下来会逐步退出这边的开发，初期兼作一些顾问型的工作，直到他们招到合适人选。

    这里，我要帮他们招招人试试看。情况大概如下：

    • 这是一家主要团队在美国的初创企业
    • 他们的主要目标产品是 Web3 教学网站
    • 他们已有产品、设计、课程团队，需要一个比较有经验的全栈开发负责网站研发工作
    • 近几个月工资会以稳定币形式支付，需要自己负责社保等；几个月后他们会回到国内正式注册公司，到时候可以正式跟国内公司签约
      • 不希望稳定币的话，可以要求人民币结算
    • 老板还是很靠谱的，结账很爽利
    • 主要技术栈是 Next.js+TailwindCSS+DynanmoDB+Vercel
    • 工资我不敢承诺，不过应该在远程岗位里算不错
    • 最好有远程工作经验，能做好自我管理，还能辅助管理研发最好

    有兴趣、有能力的同学，请与我取得联系，我会推荐给他们进行进一步的面试。

  • 我的 AI 学习一周总结：ChatGPT API 的改进

    我的 AI 学习一周总结：ChatGPT API 的改进

    本周也在继续学习 AI based 应用研发，继续总结+做笔记。

    ChatGPT API 的改进

    新 API 除支持 ChatGPT 模型以外，还增加了一些功能参数，能让我们提升工具效率，同时降低费用消耗。

    新增 messages 参数，显示定义角色

    ChatGPT API 增加了 messages 参数，支持显示定义角色，可以取代之前的 prompt，更清晰的标记每一个内容的来源，方便 API 生成更有价值的内容输出。OpenAI 称之为“Chat Markup Language（ChatML）”，格式如下：

    type MessageItem = {
  role: 'user' | 'system' | 'assistant';
  content: string;
};
type Messages = MessageItem[];

    具体文档参见：Chat completion – OpenAI API。

    以前我们必须手动保留全部来往信息，放在 prompt 里。这样有几个问题：

    1. 往来数据量很大，很多时候要浪费钱在传输前面产生的内容上
    2. 除了 ChatGPT 以外，其它工具无法分析数据结构
    3. 我估计，OpenAI 那边的计算效率也不高

    n 参数，支持一次性返回多个结果

    以前虽然名为 choices，但每次只返回一个结果，如果要调整，就要多次发送 prompt，还要带上之前的结果，很浪费。

    现在，如果是文字润色、内容仿写等场景，就可以从多个结果中选择最好的一个，再进行微调，无疑会大大提升效率，也会降低消费。

    突破 token 限制

    使用 OpenAI 自己的 embedding API，将自己的数据（比如聊天记录中的数据）导入，生成更符合自己需要的模型。新的模型被之前的数据重塑过，就会看起来更符合新的要求。

    原文在此：这确实是一个相当好的绕过tokens长度限制解决方案，我尝试将这个方案整理一下

    仓库在此：mckaywrigley/paul-graham-gpt: AI search & chat for all of Paul Graham’s essays. (github.com)

    值得关注的项目

    LlamaIndex（gpt-index）

    Welcome to LlamaIndex (GPT Index)! — LlamaIndex documentation (gpt-index.readthedocs.io)

    正在更名为 LlamaIndex（羊驼），可以将自己的数据和 LLM 结合，得到更适合自己的模型。基本上就是上面 “突破 token 限制” 逻辑的实现。比如，我们可以把一本书通过 LlamaIndex 喂给 ChatGPT， 得到的模型里就有了我们最近喂进去的知识，然后我们可以再用自然语言向 ChatGPT 提问，就会得到包含了新知识的答案。

    感觉一扇新的大门正在打开。几乎所有说明书、客服，甚至一些高阶职位都可以（可能）被这个方案替代。据说实测结果，它对新知识的理解归纳总结能力都很强。

    ChatPDF

    ChatPDF – Chat with any PDF!

    不知道跟上面一个项目是什么关系，感觉实现的功能很像。上传一个 PDF，然后使用自然语言的方式让 ChatGPT 帮你提炼内容。我试了一下，感觉很神奇，虽然我觉得不能替代完整读完一本书的价值，但帮我们快速归纳查找内容应该作用很大。

    然则，我试用之后发现，它还是做不到“不知道就说不知道”，于是，如果我们的问题超出了书本和它原本模型的边界，它就又开始瞎编了。这仍然是很大的问题。因为用户可能默认它包含了书的全部内容，用户自己却不十分确定书的内容，于是很可能把错误的知识归纳当成正确的吸收。

    bilingual_book_maker

    yihong0618/bilingual_book_maker: Make bilingual epub books Using AI translate (github.com)

    基于 ChatGPT/OpenAI 的全书翻译工具，可以把完整的一本书交给它，它会帮你拆开，一节一节的翻译，然后生成一本新的返回给你。

    酷表

    酷表ChatExcel

    上传 excel，然后用自然语言描述你的需求，它会帮你自动调整表结构、编写函数，等。直到你满意，就可以下载表格，继续编辑。

    目前来看有些文件会上传失败，可能还不太稳定，可以持续观望。

    部署 Stable Diffusion 到 AutoDL.com

    经 Easy 推荐，我在 AutoDL.com 购买了一台 3090 服务器，给几个朋友部署 Stable Diffusion 环境。AutoDL 的价格比较便宜，支持按小时租用，还有做好的镜像，使用起来比较方便。大概过程如下：

    1. 抢一台服务器。因为显卡数量有限，价格比较便宜，所以必须过抢。
    2. 服务器就位后，登录 JupyterLab，按照提示运行
    3. 使用“自定义服务”获取对外的 IP 和端口
    4. 因为系统盘容量有限，可以把模型放在数据盘上，然后软链过去使用
    5. 实测 3090 出图速度很快

    复制周姐成功，接下来该学习 Lora 炼丹了。

    Hackathon

    近期跟 AI 有关的 Hackathon 也很多，我报名了好几个，已经有点忙不过来了……

    推荐给大家：

    1. SegmentFault AIGC Hackathon 2023 黑客马拉松
    2. 即刻（App 里搜索“AIHackathon”）
    3. 腾讯 Light（报名已经截止）

    现在各种 AI 的新知识简直太多了，看着各种新闻，一方面精神振奋，另一方面又觉得有点慌，感觉不自觉就会地落在别人后面……

    另外，原则上来说，ChatGPT 是 OpenAI 的作品之一，很多功能可能要借助 OpenAI API 实现。不过实际讲述时，我就懒得区分了，相信读者应该能看明白。

  • 我的 AI 学习一周总结：ChatGPT API 发布

    我的 AI 学习一周总结：ChatGPT API 发布

    即然接下来的时间准备投身 AI 行业应用层开发，那就隔三岔五分享一下近期学到的知识、在做的事情吧。（配图是今天用第一次用 SD 生成的图片，prompt：“a beautiful girl“。）

    ChatGPT API 发布

    今天（2023-03-02，美国时间 03-01） OpenAI 正式发布了 ChatGPT API，即 基于 gpt-3.5-turbo 模型的。它的价格更便宜，$0.002/1k tokens，比之前 text-davince-003 便宜 10 倍。它能提供更好的对话质量，还提供了新的结构化数据接口，相信会给应用开发者带来更多的空间。

    chatgpt 等 npm 包也相应更新，如果没有办法搞定绑卡操作，可以继续用这些社区接口白嫖。

    尝试 Vercel Edge Function

    之前开发 GPT-3 插件的时候，有同学介绍了 Building a GPT-3 app with Next.js and Vercel Edge Functions 一文，于是我尝试把 API 挪到 Vercel Edge Function 上，然后失败。

    今天写本文的时候，又看了眼 TwitterBio 的例子，发现自己并没有做错。排查来排查去，还是自己犯蠢，部署环节出了问题。如今已经可以使用了。回头重构下插件，添加一些功能进去。

    学习社区 ChatGPT API 仓库

    ChatGPT 的开发商 OpenAI 提供两大块服务，API 和 ChatGPT 网页版。API 需要绑卡，有一定门槛；网页版可以免费用，不过存在偶尔连不上、响应慢等情况，据说买 plus 之后会有好转。

    于是社区就开发了网页版转 API 的工具，可以用来搭建自己的 ChatGPT API。但是需要使用反向代理服务器作为中转，开发者也不提供反向代理服务器的源码，存在一些风险，所以我看完就不打算使用了。

    本地搭建 Stable Diffusion 环境

    搭建过程其实很简单，难点主要在下载 pip 包和模型上，受限于墙内的网络环境，原本简单的下载变得异常艰辛。还好在换用国内 pip 源之后，我终于在本地搭建成功 Stable Diffusion Web UI 环境。大体过程如下：

    1. 安装必须的软件环境，比如 cmake、python3.10 等
    2. clone AUTOMATIC1111/stable-diffusion-webui: Stable Diffusion web UI (github.com)
    3. 修改 pip 源
    4. 反复执行 ./webui 直至安装成功
    5. 换模型可以在 Civitai 下载

    Whisper 模型

    Whisper 模型是 OpenAI 释出的开源模型，可以用来做语音识别，据说效果非常好。它不仅可以识别语音内容，还可以根据声纹，区分不同的发言人。所以用途也很广，比如视频会议之后，可以用它生成会议的文字记录。如果再结合 ChatGPT，就可以进行内容总结、会议摘要等工作，想象空间很大。

    因为开源，所以可以自己搭建服务器，据说不需要很强的计算能力，庶民可用。OpenAI 这次也放出了 Whisper API，方便用户使用。

    ChatGPT 新知

    中文语料少的副作用

    使用英文要求 ChatGPT 创作哈姆雷特的故事，它会拒绝，因为它知道哈姆雷特，新故事如果背景差异过大，它就会拒绝。但如果用中文，因为语料不足，哈姆雷特对它来说也只是个人命，它就会很配合。

    名人资料

    GPT-3 会大量混淆中国名人，比如郭德纲、岳云鹏；相对来说，ChatGPT 就好很多。

    现在 AI 工具与 AI 基础设施层出不穷，日新月异应接不暇，学起来既有动力也有压力。下一步希望能把所有工具的环境都搭建起来，先积累感性认识再说。

  • 我所了解的 ChatGPT：二次开发；有何限制；对未来的影响

    我所了解的 ChatGPT：二次开发；有何限制；对未来的影响

    前言

    ChatGPT 其实去年底就已经在开发界大放异彩，但是圈子之外对它了解不多。春节过后，公关公司开工上班，马上开始紧锣密鼓的宣传，然后就开始破圈，如今已经是整个公共领域，尤其是创投方面最热门的话题。

    我最近也接到需求，要开发一个基于 OpenAI API 的小应用，于是开始深入了解。如今应用初步完成，对 OpenAI 的产品有了更具体的了解。再结合之前向做 AI 的朋友请教，并总结自己观察思考，于是想写一篇文章分享给大家。希望未来的 AI 世界我们都不要缺席。

    OpenAI 的服务

    ChatGPT 是 OpenAI 的一项服务。它的内核是 GPT-3.5。OpenAI 还提供很多其它服务，比如图像生成、文本分析、比 ChatGPT 质量略差的 GPT-3 等。使用这些服务需要一些操作或技巧，比如翻墙——这次是 OpenAI 先动的手。以下是我摸索出的一些经验，希望可以帮后来者省去一些时间。

    注册

    目前注册 OpenAI 比较麻烦，因为他不向中国用户提供服务，所以必须有国外手机号，并且全程使用全局代理才可以完成。国外手机号可以借用接号平台来绕过，大家可以按需选用；如果有国外的亲朋好友帮忙，就会很容易。

    绑卡

    如果你只想在网页端使用 ChatGPT，可以暂时不绑卡。如果要使用 API 或者其它服务，就得绑卡。绑卡很麻烦，国内信用卡都不支持。虚拟信用卡比如 Payoneer，只对企业开放，需要资质审查，也不太好搞。

    至于我，最后还是拜托国外的亲戚帮忙搞定。目前有三个月的免费期，暂时够我把设想的应用场景跑一遍了。

    GPT-3 与 GPT-3.5

    大热的 ChatGPT 就是 GPT-3.5，现在只提供网页服务，如果要当成 API 调用，需要一些转换步骤，比较麻烦。从开发角度来说，直接使用 OpenAI API 会简单很多，但是只能使用 GPT-3 模型，对话 质量会差一些。不过看起来 ChatGPT API 已经在登记预约中，猜测很快也会开放，所以先把代码写好，等待开放应该也可以。

    目前来看，我认为官方不希望大家偷摸使用 Web 接口，近期可以继续尝试，长远来看最好做好切换到 API 的准备。

    我的进展

    我目前实现了本地通过 OpenAI SDK 调用服务 API。不过官方 SDK 有些问题，比如因为使用 Axios，无法部署在 Vercel Edge Function，必须放在自己的服务器上。所以接下来我计划做两件事情：

    1. 尝试不用 SDK，把逻辑直接放在 Vercel Edge Function 里
      • Vercel Edge Function 无论是否开启 stream: true 都会报告 504，猜测是 OpenAI 封禁了 Vercel。理论上当然可以继续尝试绕过，不过长远来看，与服务商做斗争并不明智，先放着吧。
    2. 搭建 ChatGPT Web API 环境，以便直接使用更好的服务
      • 需要使用第三方反向代理服务器，存在一些风险。而且他们并不愿意提供部署代理服务器的方案，理由是给非官方代理方案更大的生存空间。我觉得那就不如耐心等待 ChatGPT API 开放。

    ChatGPT 的限制

    （以下内容感谢 @Gary 指导。）

    4097 tokens

    GPT-3.5 的最大长度是 4097 token，根据我做 AI 的朋友讲解，汉字=2token，英文=0.5 token。也就是 GPT-3.5 的上下文最多保持 2k 汉字或 8k 英文字符 的内容。所有文本合并到一起发给 AI，AI 给出答案；我们再把新文本续上，发过去，AI 给出新的答案。直到最初的内容被挤出去，产生新的上下文。

    这是什么意思呢？比如我们日常交流，都是自带上下文的，跟父母、跟同事、跟恋人说话不一样，也是因为上下文不同。我会跟游戏里的同好聊魔兽世界，但是如果跟父母说同样的话题，他们就会不知所云。这就是上下文的差异。

    换言之，我们跟 ChatGPT 对话，用中文，教给它一件事情，累计 2k 字之后，他就会忘记这个要求。要避免这种情况，我们就得每隔一段时间重新教它一次；或者，以编程的方式重构 prompt，添加先决条件，以便维持特定功能。

    听起来有理有据，但其实错误百出

    我称其为“尬聊之神”。ChatGPT 并不是真的智能，或者说，目前的 AI 实现都在从不同方向模拟人类的智能，也许我们最终会成功，但是现在似乎还有些距离。具体到 ChatGPT 上就是，你说什么，他都会给出回应，但是回应有没有价值，不好说。

    尤其在一些绝对的事实方面，因为训练语料的问题，ChatGPT 的表现会比较差。因为对它来说，假的、错的语料，只要语法正确，也是好语料。这方面 Bing 里号称 GPT-4（我对此版本号表示怀疑）的模型表现就会好很多，因为它会结合网页权重，使用更权威的材料。

    在编程领域也是如此。因为开源软件的关系，ChatGPT 拥有非常丰富的程序开发知识，可以帮我们解决很多问题，写出很多代码。但是这些代码写得如何、能不能跑起来，还很难讲。所以，能不能把编程的工作丢给它？目前不能，它甚至不具备基于语言特性进行逻辑推导（语法检查）的能力。——但是不代表我们不能用它提升效率、学习技术。

    还没有真正的智能，也无法持续学习

    前面说过，ChatGPT 可以在保留一定上下文的基础上，与当前用户进行有状态的交流。所以我们也可以教 ChatGPT 做一些事情，比如发出指令：“以后提到日期，都用 YYYY-MM-DD 的格式”。接下来，我们就能把 ChatGPT 当成自动格式转换器来使用。或者，我们可以让它换用不同的语气、不同的语法，改变输出的内容，契合某种风格。比如出名的胡总编模拟器、鲁迅模拟器等。

    但这些并不是自我意识与学习，本质上只是 ChatGPT 根据完整上下文合成的文本，而已。有很大的限制：首先我们必须保留足够的上下文，其次我们也没有办法直接把这个状态转移到其它用户。

    哪些未来更可期？

    ChatGPT 的出现，让大家都很兴奋，我也一样。我们都确定未来可期，但是通常来说，总会有一些未来更可期，另一些未来不那么可期。结合上面提到的问题，我认为有一些领域可能不太好做：

    老年人陪护（x）

    我有个朋友上一份工作主攻老年人市场，所以他立刻就问，能不能用 ChatGPT 做一款老年陪护软件。

    我认为不行。这里涉及到两个问题：

    1. 上下文限制。AI 会损失大量的历史记录，需要用户花费大量的时间反复训练。对有经验的用户来说，可以通过各种手法优化，对老年人来说，可能会反复经历挫折。
    2. 不够准确。因为训练语料的问题，ChatGPT 无法保证内容的准确性，如果老年人寻医问诊，可能得到错误的答案。众所周知，AI 不能背锅，这一点也很难解决。

    但也有一些领域会有很大的机会：

    语言类，翻译、文书等

    这方面算是 ChatGPT 的主场了，无论翻译，还是文书书写，目前来看 ChatGPT 都能完成的非常好。4097 tokens 的限制，可能需要我们在产品层面给予一定的辅助设计，但是在可以想象的空间内，都能产生不错的产品。包括但不限于：

    1. 小说生成器
    2. 解说文字生成器
    3. 内容/关键词提取器
    4. 商务邮件辅助工具
    5. 学外语辅助工具
    6. ……

    太多太多，不一一列举了。总之，这块儿几乎一定会产生很多应用，甚至我们现在就能见到不少。

    用户界面

    我认为 ChatGPT 最大的价值就是全新的用户界面。以前我们的用户界面，无论命令行、图形化，都只针对具体的需求，需要用户自己有清晰的认知、有明确的方向、并认真学习。如果用户没有学习过，就很难使用现有的产品。想象一下，如果用户可以用自然语言发出命令，那几乎所有产品界面都可以重建得更好用。

    举个例子，我们家 Siri 最常用的功能就是定时，比如煮泡面：嘿，siri，定时 4 分钟。但是其它功能很难做到，因为其它的功能描述起来太复杂，而且表达方式也比较多，Siri 目前处理不了。

    ChatGPT 则可以从用户的文字描述中提炼出有价值的信息；经过简单的训练之后，还可以发出指定的命令。所以我设想，将来很多东西都可以用它重建，比如（GPT 没有好的翻译，所以我就用姆伊姆伊来替代）：

    • “姆伊姆伊，帮我叫水”——我家桶装水喝完之后，要打电话给水站让他们送水——ChatGPT 自动拨号，跟客服简单沟通，叫水。
    • “姆伊姆伊，帮我订个外卖，吃粉吧“——这个需求会复杂很多，除了外卖之外，我们需要 AI 分辨出“吃米粉”这样的需求，并且从历史当中，判断我们常吃的粉是哪一家，然后帮我们完成订外卖的需要。

    AI 公司的未来

    未来 OpenAI 这样的大型公司，能提供通用模型的公司会越来越少，因为通用模型数据量和计算量太大，小公司根本烧不起。但是做 AI 的小公司可能会冒出来，类似用 WordPress 做建站，小公司可以帮客户在大模型的基础上做 finetuning，帮助客户将 AI 集成到产品里。

    我会怎么做？

    首先，我一定要尝试用 ChatGPT 做产品。我觉得它是很重要的产品，是未来的重要组成部分。去年它开始在业内刷屏的时候，我没想到它能获得这么大的公众关注度，这对我们来说既是好消息也是坏消息。好消息是将来可以借助它的品牌做宣传，坏消息是势必有更多的竞争者入局。

    接下来是产品方向。我想做简历相关，让 ChatGPT 帮我们把简历做得更匹配 JD、更有竞争力。考虑到它在文本分析和生成方面的强势，我觉得这个方向有很大的机会。

    我也计划加入一家以 AI 应用层为主要产品的公司，不要错失良机。希望能找到合适的老板或团队，即尊重技术，又擅长市场，大家能够合作共赢。

    前端怎么做？

    我认为现在是前端的好机会，因为目前 ChatGPT 基于浏览器提供服务，所以浏览器扩展就有很大的想象空间。建议所有前端小伙伴都好好学习一下 ChatGPT 的相关知识，能够实际开发一两个相关产品。比如，有人会让 ChatGPT 推荐一些配色，如下图：

    ChatGPT 只能给出色值，不方便直接看到。我们就可以写一个浏览器插件，将页面上的颜色转换成色块显示出来，并且支持一键保存到自己的调色盘。利用好这段真空期，有很大的发展空间。

    总结

    以上，就是我从去年得知 ChatGPT，到最近一周基于 ChatGPT 开发浏览器扩展，再结合我看到的、聊到的、想到的内容，集中分享。

    希望对看到文章的各位有启发、有帮助。如果你对 ChatGPT，对近期的 AI 热潮有想法、有问题，欢迎留言讨论。更欢迎针对我文章的评议、讨论。

    未来，AI 一定会有一席之地，我们也一起来争取属于我们的新领地吧。

  • 2023 告别 CSS 预处理工具，彻底拥抱 TailwindCSS

    2023 告别 CSS 预处理工具，彻底拥抱 TailwindCSS

    CSS 是声明式语言，很简单，很好学，但是写起来很累，所有东西都要写出来才能生效。复用方面更是无从下手，虽然大家都在不断总结，但始终没能找到足够好用的方案，可以有效改善 CSS 开发。

    于是我们只好把视线转出 CSS 之外，转投 CSS 预处理工具，Less、SASS（SCSS）、Stylus，引入种种 CSS 不具备的功能，帮助我们改进开发体验。比如嵌套、函数、循环、条件，等等。然而如果你细心观察，实际上，这几个工具最近 5、6 年都没怎么更新（我说的是功能性），因为该有的都有了，甚至很稳定；其它来自于 CSS 的改进，几乎跟它们没什么关系，也不用更新。

    最近几年，随着 CSS 发展，一些新特性逐步引入，我觉得这些工具越来越难用，它们能带来的好处已经无法掩盖它们所造成的问题。是时候告别 CSS 预处理工具了，就像我们当年告别 jQuery 一样。

    为什么说预处理工具落后？

    我把理由分成三大类：

    预处理工具的问题

    • 对 CSS 函数兼容性不好，尤其是 rgba()、hsl() 这些常用的颜色函数
    • 数值类型转换，有不符合预期的行为，比如 Stylus 实现 content:5

    CSS 的改进

    • CSS 拥有越来越多的函数，可以直接进行计算，比如前面提到的颜色；还有 calc() 来完成基础数学计算
    • CSS 变量非常好用，可以大大改进编程体验，配合各种 JS 框架，我们可以更容易的把数学逻辑和显示效果绑定在一起
    • CSS Houdini 可以实现新功能，即使不深入使用（JS 部分），也有好用的自定义属性
    • CSS 也开始从预处理工具吸收营养，比如近期的嵌套功能已经开始被整合，未来我们可以直接使用

    预处理工具无法跟进的问题

    • 很多缩写、复合属性无法处理，比如 background-image、box-shadow 等，都支持多属性共同生效，预处理工具擅长的循环、条件、函数无法提供帮助。
    • 预处理，顾名思义，发生在生产之前。实际上，网页在实际浏览时，会有很多因素影响到渲染结果，比如分辨率、dark mode 等。预处理工具对这些需求也没有改进。

    替代方案

    我目前的替代方案基于 TailwindCSS，所以自然包含 PostCSS、AutoPrefixer 等工具。然后用 postcss-import 实现自动导入和模块化；使用 tailwindcss/nesting 实现嵌套。

    为什么选用 TailwindCSS？首先，实际开发中，不管使用什么前端框架，我们都需要大量原子化的胶水样式，比如调整间距、改变字号、给容器添加一些边框、圆角、阴影等。这些样式如果都手写，工作量并不小；学习不同的样式名也是负担；以及最重要的，CSS 优先级问题。使用 TailwindCSS 就都能很好解决。

    TailwindCSS 不仅包含一大堆原子化样式，自身也是个完整且优秀的 CSS 编译器。它包含 reset，提供一组全局通用的 CSS 变量；它可以从各种文件里把我们用到的样式提取出来，构建后生成的 CSS 里只有我们要用到样式，不会有多余的；它会分析我们对样式的使用，合理的调整样式顺序，保证样式能正确生效。使用 TailwindCSS 可以节省很多时间。

    它还自带若干插件，比如解决嵌套的 tailwindcss/nesting，支持内容类元素的的 @tailwindcss/typography 等。使用这些插件也可以帮我们节省很多时间。

    最后，TailwindCSS 的生态不断成长，我们的选择范围越来越宽：HeadlessUI、DaisyUI、付费的 Tailwind UI 等。方便我们从产品生命周期的任意阶段开始集成。

    推荐项目配置

    启动项目的时候，安装依赖。包含 PostCSS + AutoPrefixer、TailwindCSS 和 DaisyUI。前者提供 CSS 处理框架，包含自动导入 css 和嵌套功能；后两者提供可见的 UI。

    pnpm i postcss postcss-import tailwindcss autoprefixer daisyui -D

    自动初始化配置，-p 会自动生成 PostCSS 配置：

    pnpm tailwindcss init -p

    调整 postcss.config.js，启用 postcss-import 和 tailwindcss/nesting。目前我们常用的嵌套规则和 CSS 规范略有区别，不过无所谓，规范也没确定，所以这样就足够了。

    module.exports = {
  plugins: {
    'postcss-import': {},
    'tailwindcss/nesting': {},
    tailwindcss: {},
    autoprefixer: {},
  },
}

    然后调整 tailwind.config.js

    const DaisyUI = require('daisyui');
// 这个插件可以帮我们处理文档类内容，我建议常用
const Typography = require('@tailwindcss/typography');

module.exports = {
  // 从以下文件查找用到的样式
  content: [
    './index.html',
    './src/**/*.{js,ts,jsx,tsx,vue}',
  ],
  theme: {
    extend: {
      // 扩充 TailwindCSS 没有包含的样式
    },
  },
  plugins: [
    DaisyUI,
    Typography,
  ],
  daisyui: {
    themes: [{
      // 只构建一个主题： luxury，并覆盖其中的两个属性
      luxury: {
        ...require('daisyui/src/colors/themes')[ '[data-theme=luxury]' ],
        primary: '#FFA028',
        '--bc': '0 0% 87.5%',
      },
    }],
  },
}

    然后，创建样式入口 main.css。其它样式可以如常写在这个文件里，不过如果要 @import 其它 CSS 文件，就要进行一些调整。具体可以看官方文档。

    @tailwind base;
@tailwind components;
@tailwind utilities;

    然后在入口文件引用 main.css 即可：

    import './main.css';

    至此，新项目配置完成，可以照常开发了。

    下期预告

    这次我先分享了整体思路：用新的工具链替代预处理工具，保证已有的功能不缺失。那么下期分享的内容就是使用新的 CSS 特性，更好的完成开发。

    如果你对新 CSS 感兴趣，对预处理工具和新工具链有兴趣和疑问，欢迎留言讨论。如果本文对你有启发，也请帮我点赞分享，谢谢。

    本文参与了 SegmentFault 思否写作挑战赛，欢迎正在阅读的你也加入。

  • 【视频】肉山的模拟面试系列（三）：在校生杨秋实同学

    【视频】肉山的模拟面试系列（三）：在校生杨秋实同学

    模拟面试系列继续，进入第三周，这次请到的是杨秋实（化名）同学。（这周参加一场 Hackathon，基本上一周都在忙，所以忘记上周的视频还没写到博客里，下周补吧。）

    他还是在校学生，但是很早就开始实践，加入校内师兄师姐成立的一个公司，做前端开发。我觉得他在学生里也算各种翘楚，对他也比较是期待。不过仔细看，他的简历槽点略多。

    想知道他的具体表现么？那就看视频吧。

    视频内容：

    • 这次我结合上次视频的复盘，先分享了应对紧张状态的一些知识。
    • 然后点评了秋实同学的简历。他的简历存在一些细节问题，大家共勉。
    • 接下来面试前端基础。
    • 然后是结对编程。
    • 最后是点评。

    有任何问题、意见、建议，欢迎留言弹幕私信与我交流。想参加模拟面试的同学，也请跟我联系。目前下周还是空缺，欢迎投稿。