山维空间

标签： chatgpt

  • 分享自制小工具：Automate GPT – 在 ChatGPT 里批量执行任务

    分享自制小工具：Automate GPT – 在 ChatGPT 里批量执行任务

    其实这个小工具是我很早以前开发的，最近因为有需求，又翻出来修了修，觉得蛮有用的，分享给大家。Automate GPT 是一个浏览器扩展，可以方便我们更好的使用 ChatGPT。

    OpenAI 最近几次发布的新功能还是很强力的，比如近期大热的各种风格化绘图，什么吉卜力啊、卡通3D啊、玩具啊，等等。相信大家都在各种平台上看过，我也试做了一些：

    （更多…）
  • SSR，云平台，ChatGPT——我的 2023 技术关键词

    SSR，云平台，ChatGPT——我的 2023 技术关键词

    前言

    2023 年，因为换工作，启动新项目等原因，我对我的技术栈进行了比较大的更新，主要集中在这三个方向：

    1. SSR（Server Side Rendering，服务器端渲染）。之前我开发的项目基本上都是 SPA（Single Page Application），比如 Vue，但之后我会越来越多开始用 Nuxt。由于基础设施的发展，以后 SSR 会更方便更好用。
    2. 云平台。以前我大概买了 3、4 台云服务器用来做各种尝试，在上面各种折腾。去年使用 Vercel、Supabase、CloudFlare 平台之后，我已经不打算再在服务器上浪费时间了，云平台实在太好用了。未来我会努力把所有服务都迁移到云平台上，新增产品都直接云原生。
    3. ChatGPT。相信不只是我，很多人都会把 ChatGPT 作为去年技术的首选关键词。如今我不仅在上面完成产品开发，日常也会使用它替代大部分的搜索；甚至我家孩子写作业也会使用它来帮忙。我认为，未来 ChatGPT 就像是搜索引擎一样，决定了一个人的起点和成长速度。

    接下来逐个分享。

    服务器端渲染，SSR

    起初我不是很看重 SSR，我总觉得，我当年也写过 PHP，有什么“服务器端渲染”我没见过？实际用过之后，我承认：真香……

    首先，使用 SSR 可以提升用户体验，且有利于 SEO，这点相信大家都知道。如果对其原理不太清楚的话，欢迎观看我的视频：从浏览器渲染机制理解 Web 性能——“在浏览器地址栏输入 URL，按下回车后会发生什么？”

    其次，如今的 SSR 与当年 PHP 模版套页面的实现有很大区别：

    1. 语言同构化：开发难度大大降低，没有心智负担。
    2. 数据传递与状态管理：虽然数据不能完全通用，但是框架尽量会帮我们处理好，让我们在服务器端和客户端都能自由使用。
    3. 渲染由边缘计算负责：这一点有点依赖云平台，不过考虑到浏览器的渲染机制，SSR 并不会拖慢渲染速度，用户体验只会更好。
    4. 页面切换不需要重新加载。对于旧的编程语言来说，因为前后端环境割裂，所以页面切换的时候都是重新加载完整页面；但是新框架下，则只需要加载数据即可，此处跟 SPA 的体验无二。

    第三，如今的 SSR 框架都很好的整合了服务器，包括中间件等功能，还有各种官方第三方模块支持，能大大降低我们开发服务器软件的成本。所以已经是我启动新项目的不二之选。

    云平台

    以前我长期维护好几台服务器，一方面可以部署自己做的产品 demo，另一方面也可以部署一些开源项目方便日常使用。因为各种云都有面向新用户的优惠活动，所以成本不高，我觉得值得一搞。

    自己的服务器当然比较比较自由，坏处就是免不了产生运维成本，即使使用 docker 也一样。部署新代码至少要去跑一遍拉取脚本，对吧？我的一位老板朋友甚至请我帮忙写了一套服务器脚本，用来做 CI/CD。

    初期这么搞没问题，但后来就越来越觉得功能不够，性价比也太低，开始寻求替代方案。之前我参加 Hackathon 的时候了解到 Vercel 云平台。它与 GitHub Pages 不同，支持 SSR、支持云函数，配合一些云数据库，比如 Upstash，可以快速搭建起来一套可用的服务。去年年初，我的那位老板朋友想做一套打分系统，放在他的静态网站里，于是，我就尝试用 Nuxt.js + Upstash 开发了一套，并且部署在 Vercel 上，效果非常好，免运维，多环境，推到 GitHub 自动部署，实在太好用。

    我把这个过程制作成了系列课程：Nuxt3+Vercel+Serverless 数据库全栈开发。大家感兴趣不妨看一看。

    后面一发不可收拾，过去一年我不再采购新的单体服务器，旧的服务器用完也不再续费。新产品都部署在 Vercel 等云平台上面，帮我节省了大量的时间。

    Vercel 去年年中的时候开通了存储功能，实际上就是打包了几家云数据库服务来卖，我也很快获准开通。从此，云平台使用就更加顺利了。临近年底，我尝试 CloudFlare Pages，效果也非常好。他们家的优势是自带统计分析功能，远比 Vercel 大方，一站式解决更省心。

    云数据库方面，我使用 Upstash 的 Redis，KV 数据库足以满足大部分产品需求。数据库用 Supabase 和 TiDB 比较多。前者支持 PG Vector，方便我们进行 LLM Embedding & Search；后者则提供 5GB 免费额度，比较好用。云存储有 CF 的 R2，空间和流量也相当充足。如果不是 PHP 太老没人支持，我都想把博客这台机器退掉了。

    ChatGPT，以及其它

    ChatGPT 更是值得大书特书的一个技术关键词。不过考虑到大家去年一整年应该已经被类似的内容淹没了，所以我这里就少写一些，只说说我的情况。

    我目前订阅了 ChatGPT+，方法是借用国外亲戚的手机号注册，并且用他的手机号注册 PayPal，通过 Google Play 订阅。订阅的原因是 ChatGPT 4 + DALL-E 都可以随便用，比 API 便宜得多。

    在编程领域，GPT-4 比 GPT-3.5 好太多了，知识库更新到去年 4 月份之后，除了 next.js 14 的内容外，我日常的编程问题大多可以用 GPT-4 解决，比如：

    • 写正则
    • 写 SQL
    • 查函数、查第三方库
    • 纠正函数错误

    帮我节省了大量的 Google 时间，单凭这点，每月 $19.99 的订阅费用就很值得。

    除此之外，我还在继续使用 GitHub Copilot。Copilot 也很好用，除了生成工具函数、编写测试外，我发现翻译语言和框架方面也有很大的作用。去年我就完全靠它开发了一个 flutter 应用，方法就是把 TS+Vue 写好的代码丢给它让它翻译。

    所以，无论是学习新东西，保障日常开发，还是扩展新领域，AI 对我都帮助巨大。

    总结

    总而言之，如果再有同学问，前端想学后端，应用学什么语言框架以及是否需要搭自己的服务器？我都会建议他们：不要学 Express、Koa；习惯用 Vue 就学 Nuxt，习惯用 React 就学 Next.js；不需要搭建服务器，就用云存储就能解决绝大多数问题。

    我还建议大家，尽快想办法开通 ChatGPT，再不济国产大模型也要用起来，未来是 AI 的时代，学会用 AI，效率会大幅度提升。半年的初入门新人，善用 AI 可以赶上 3 年的老程序员；而老程序员学会用 AI 之后，可以快速把自己的能力扩展到其它领域。

    以上，就是我去年关键的技术栈总结，希望对大家有所帮助。如果大家有什么意见建议，想说的想聊的，欢迎留言。

  • 使用 CRXJS Vite 插件开发 ChatGPT SidePanel 插件（一）

    使用 CRXJS Vite 插件开发 ChatGPT SidePanel 插件（一）

    OpenAI DevDay 简单回顾

    OpenAI DevDay 上发布了一大堆新特性新功能，提升上下文容量、降低 token 价格，再次震撼整个行业。相信大家已经通过各种渠道了解到这次更新的细节，所以我就不再赘述。这里简单分享三个观点：

    1. 这次更新最值得关注是 Assistant API，因为这项功能大大降低了 AI 工具的开发门槛，让很多开发者不需要学习了解新技术，就能上手开发较复杂的 AI 应用。
    2. TTS、DALL-E 3 API 开放后，OpenAI 开发生态基本完整。ChatGPT 可以开口说话，也可以动手画画；再加上前面说的 Assistant API 所带来的 Retrieval 和 Code Interpreter，ChatGPT 可以拥有训练集以外的知识，也可以拥有 LLM 以外的逻辑思维能力。产品实现上的卡点基本打通，剩下就是应用层开发扩展了。
    3. $20/月的 ChatGPT Plus 价值进一步提升，俨然已经是性价比之选。如何好好利用，将其价值压榨出来，值得我们思考。我的想法是通过浏览器扩展加强自动化与可编程性。

    Chrome Extension SidePanel API （Chrome 114+）

    Chrome 浏览器从 v114 之后，开始支持 SidePanel，从此我们可以把扩展放在浏览器侧边栏里，提供新的可能性。

    之前我们使用扩展时，有三种方案，它们都有一些影响使用的问题：

    1. Popup：非常容易被关闭，基本上只要 popup 窗体失焦，就会被关闭，里面执行中的程序也会停下来。
    2. Content Script 插入 DOM：新插入的 DOM 可能跟原本的页面有冲突，尤其是样式，会增加开发成本。
    3. 独立打开：需要成为 activeTab，无法与目标页面共存。

    这些问题都可以被 SidePanel 很好地解决。于是，我们可以利用 SidePanel API 开发一个浏览器扩展，它可以大幅加强某个网站的功能、提升在这个网站里执行自动化操作的能力。我们不用担心它会被以外关闭，导致自动化失效；也不用担心它会和目标网页产生冲突。

    假如，我们针对 ChatGPT 网站开发一个扩展，加强它的功能，把 ChatGPT Plus 的功能和额度用好用满，应该可以实现一些相当不错的功能。

    CRXJS Vite 插件改进浏览器扩展开发

    产生上述想法之后，我就一直想找机会试试。不过开发浏览器扩展还有个痛点：扩展拥有加强版 API，在普通页面里无法使用；但是如果使用开发者模式加载扩展，又会丧失 HMR，开发不便。

    经过调研，发现 CRXJS Vite 插件 可以解决这个问题。它可以给插件开发环境添加 自动更新的功能，我们就不需要每次更改代码之后再手动刷新，也可以确保我们的开发环境支持全套 chrome.* API，与实际运行环境一致，大大提升我们的开发效率。

    使用该插件的方式非常简单。首先，创建一个 vite 项目。对我来说，效率最高的框架还是 Vue3。本着每次尝试的新技术不要超过 1/4 的比例，那就 vue-ts 吧：

    pnpm create vite my-vue-app --template vue-ts

    接下来，安装并配置 crxjs vite 插件：

    pnpm i @crxjs/vite-plugin@beta -D

    然后配置 vite.config.ts：

    import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import { crx } from '@crxjs/vite-plugin'
import manifest from './manifest.config';

export default defineConfig({
  plugins: [
    vue(),
    crx({ manifest }),
  ],
  // 注意，这段配置很关键，请保证开发端口与 hmr 端口一致。不知道为何，插件生成的扩展里缺少 5173 默认值。
  server: {
    strictPort: true,
    port: 5173,
    hmr: {
      clientPort: 5173
    },
  },
})

    我的 manifest.json 也是使用 TypeScript 生成的，所以上面我 import 本地的 manifest.config.ts 文件。

    export default defineManifest(async function (env) {
  return {
    "manifest_version": 3,
    "name": "my ChatGPT tools",
    permissions: [
      'activeTab', // 要往目标页注入脚本
      'scripting',  // 同上
      'sidePanel',  // 启用 sidePanel
      'tabs', // 为了与 content script 通信
    ],
    content_scripts: [
      {
        matches: ['https://chat.openai.com/*'],
        // crxjs 会帮我们把目标文件编译后注入目标页面
        js: ['./content/src/index.ts'],
      },
    ],
    // 针对 ChatGPT 而做
    host_permissions: [
      'https://chat.openai.com/*',
    ],
    // 启动 sidePanel 时，加载当前项目的页面
    side_panel: {
      default_path: 'index.html',
    },
    // 这里主要为了点击图标能打开或关闭 sidePanel，background script 同样交给 crxjs 处理
    background: {
      'service_worker': 'src/sw.ts',
      'type': 'module'
    },
  };
});

    配置完成之后，照常启动项目 pnpm run dev。

    然后在浏览器的扩展管理器里启动开发者模式，加载已解压的扩展目录即可。

    CRXJS 插件原理

    启动开发环境之后，CRXJS 会帮我们生成一个开发版的浏览器扩展，里面除了必备文件之外，还有各大组件所需的加载器，帮我们分别加载 service worker、content script，和页面内 js。它还会建立一个 WebSocket 连接到 vite 开发服务器，当侦听到目标文件出现变化时，就通过各种方式重新加载。比如，页面文件可以直接 HMR，service worker 可能要刷新组件，而 content script 甚至要刷新目标页。

    于是，便实现了浏览器扩展在开发环境下的 HMR。

    使用 CRXJS 开发浏览器扩展的注意事项

    首先，前面代码里有写，需要注意配置 HMR 端口。不知道为何，CRXJS 不使用默认的 5173 端口。

    其次，content script 需要在目标页面执行，所以 content script 修改后，常常需要刷新目标页。但是不知道什么原因，有时候 CRXJS 自动刷新目标页之后，content script 并没有更新，我猜测与这几步操作的执行顺序有关。我建议用开发者工具打开 content script 确认一眼。

    比如我的 content script 是 content/src/index.ts，那么就确认 content/src/index.ts.js 即可。

    以及，由于 HMR 可能会更新运行环境，如果此时恰逢我们在使用 chrome.tabs.sendMessage() 传递消息，可能导致 SidePanel 页和目标页连接断开，消息传送失败。解决方案嘛，就是多重启。修改完消息两端的代码之后，连目标页带侧边栏一起重启一次，即可。

    总结

    目前我的扩展还在开发中，将来做好了可能会上线 CWS，暂时就先不公开仓库了。

    新技术总能带来新的可能性，希望大家都能抓住这一波机会，无论是 OpenAI、LLM 还是浏览器 SidePanel 扩展，做出有价值的产品。

    有任何问题、建议、想法，欢迎留言讨论，共同进步。

  • Prompt Engineering 经验分享

    Prompt Engineering 经验分享

    我这大半年来都在围绕 ChatGPT API 做事，积累了一些 Prompt 相关的经验，大部分跟编程有关。即拿到结果后，我们不直接输出，而是使用代码处理这些结果，然后再输出。Functional Calling 对编程当然有用，不过有时候，配合文中的一些方法，可以得到更好用的结果。

    ChatGPT 的基本原理

    ChatGPT 是一个生成式大语言模型，它由海量的数据训练而来。所以当我们输入一些内容作为启动数据之后，它就会计算出来最可能最合理的新内容。比如，输入“白日依山尽”，那么最合理的接续多半是“黄河入海流”。当然，由于 ChatGPT 已经针对“聊天”这个场景做过优化，所以，他可能会多说一些过渡性的内容。

    通常来说，我们发给 ChatGPT 的内容不会这么好预期，所以它会产出的结果也存在很大变数。这对我们来说有好处也有坏处。好处是，多变的结果，会让我们有更多期待，也更有机会拿到想要的结果；坏处是，结果质量可能忽高忽低，格式也飘忽不定，难以在程序里使用。

    Prompt 入门

    要写出好的、有效的 Prompt，第一步应该去认真阅读 OpenAI 官方的 GPT最佳实践（GPT best practices）。这里我简单总结一下：

    请求里包含必要的信息

    比如我家孩子想让 GPT 帮他写作文，如果只说：“帮我写一篇作文”，效果就不好。因为作文有很多可能，不同的阶段、不同的文体、不同的主题，写出来的作文可能完全不同。

    这时候就要耐心跟 GPT 讲清楚：“我是一名小学五年级的学生，请帮我写一篇作文，大约 300 字，记录我们家过中秋节的故事，我们吃了月饼，看了晚会；我们本来想出去旅游，但是爸爸妈妈猜到处都是人，就没有出去。”

    让 GPT 扮演一个角色

    GPT 已把成千上万的角色融于一身。还是上面的例子，我家孩子如果只让 GPT 帮他写作文，能写，但是未必敢交给老师。所以此时就要让 GPT 扮演同样的小学五年级的学生来写作文。

    给 GPT 提供周边信息的时候，要把边界标清楚

    没有格式的文字，无论是人还是机器都无法理解。所以我们可以使用各种 XML 标记，或者三连引号，让 GPT 知道哪些是我们的请求、哪些是我们给它的参考资料。

    提前帮 GPT 分解任务

    GPT 目前的逻辑能力有限，如果我们有更靠谱的解法，直接教给它会更有效率。

    提供例子让 GPT 参考

    这个策略在二次开发领域会大量使用，我觉得比 functional calling 更常用。

    指定输出内容的长度

    我们知道，语言都存在信息密度，想把一件事情说清楚，可能需要很多文字；而过多的文字，也可能存在一些“废话”。所以限制输出长度往往也可以行之有效地改进结果。

    不过实际上，内容长度会跟很多因素有关，往往不能简单一限了之；如果篇幅限制，实在说不清楚，GPT 也可能会忽略我们的某个要求，大量文字一吐为快。

    我的经验

    对编程来说，稳定性非常重要，因为我们的代码无法适配各种各样千奇百怪的输出。这些输出在 ChatGPT 的聊天界面里，面向使用自然语言的普通人，其表达能力没有问题，但是对我们的程序来说，一些微微的差异也可能破坏代码功能。

    总则：把 GPT 当成态度超好但能力一般的实习生

    GPT 拥有海量的知识，但是缺少足够的逻辑思维能力去组织、架构这些知识。于是我们不能指望 GPT 能够很好的利用这些知识帮我们做事情。更多的时候，我们要先想清楚怎么做，拆解出来步骤，再把任务逐一分配给 GPT，让它尽量简单地做执行工作。

    但是 GPT 态度绝对好，绝对耐心，它可以不厌其烦的反复尝试我们交代的工作，毫无怨言。真是一个能力平平的社畜……

    如果你不知道下一步该怎么做，不妨把 ChatGPT 当成一位无法独立处理工作的实习生，尝试带领它工作，而不是期待他能解决你都不知道该怎么解决的问题。

    减少歧义，尤其是隐含的歧义

    有时候，我们的表达会有一些隐含的歧义。比如，我们去吃饭，想点一份不辣的鱼香肉丝或者回锅肉，这里面就包含歧义——按照川菜里的标准定义，鱼香肉丝和回锅肉都有辣。如果是在不常吃辣的地方，厨师可能可以试一试；如果实在巴蜀本地，那多半厨师要谢绝接待了。

    我们向 ChatGPT 提要求的时候也要注意。举个例子，我厂的产品会要求 ChatGPT 帮忙写一封信，这封信需要遵循一定格式，我们才好解析它并重新格式化。但是我们发现，GPT 在写开头（intro）的时候，经常会只写：Dear Meathill，即问候语（greetings），然后漏掉我们希望有的第一段。反复换模型也没有效果。后来我把要求改成

    intro: greetings, then one paragraph of introduction about 50 words，终于解决了问题。

    因为对于 GPT 来说，一句 greeting 也可以是 intro，只要求写 intro，它搞不清我们的目的，输出就远不如后面准确。

    使用 YAML 传递格式化数据

    JSON 格式要求很严格，很容易出错，而且在得到完整结果前，也很难解析。所以我建议大家如果需要格式化数据，不要用 JSON，用 YAML。YAML 格式更简单，不容易出错；而且 YAML 在流式传播的时候，不耽误我们实时解析并且输出，效果更好。

    比如这样：

    Please, as a Christian minister, help me choose a thought-provoking verse from the Bible, tell me why you chose it, and then write a prayer for me. Please write to me in the following YAML formats. No other content.

    “`yaml
    verse: the verse content
    reference: the verse you select for me
    thought: teach me about this verse, about 80 words
    prayer: use it to lead me to prayer, about 80 words
    “`

    控制 Prompt 的长度

    正如前面所说：

    1. ChatGPT 的推理能力并没有传说中那么强；
    2. 自然语言里难免会存在前后矛盾之处

    所以过长的 prompt 很容易导致得到不稳定、不可靠的结果。网上能找到各种洋洋洒洒一大篇的超长 Prompt，实际上以我的经验，这些 Prompt 要么实际效果一般，要么有许多限制条件并不必要。尤其是那些限制 ChatGPT 应该说这个不应该说那个的，多半因为前后矛盾实际上并未生效。

    我建议大家保证遵守上面最佳实践的六点之后，尽量用简短无歧义的语言提出要求，得到的结果会更加可靠。

    （案例待补充）

    Embedding + Searching 中文一般，英文略好

    经我们测试，中文 Embedding 的结果差强人意，检索匹配度很差，感觉跟传统关键词搜索的效果差不多，自然语言与原文表达相似的意思，但是词汇完全不同的时候，经常搜不出结果。

    英文略好一些，不过也好不到哪儿去，事实搜索强于表意搜索，做知识库知识管理的话，问题不大；期待做回复系统的话，我认为并不可行。实际上，我体验那些所谓名人聊天工具时，感觉也是如此。

    比如，类似 trickle.com 这样的知识管理工具，存进去一些统计数据，如股票价格、销量等，然后基于自然语言进行检索：“苹果股价最高时是多少？”一般来说没有问题。但是如果写日记，然后搜索：“我那天特别开心，是怎么了来着？”，就基本没有结果。

    解决方案当然也是有的，在 Embedding 存入数据库时，预设一些搜索场景，然后让 ChatGPT 帮助生成搜索辅助内容，最后一起 Embedding 存入数据库，这样搜索的时候就有更大概率能找到。比如：

    这是我的日记，请分析我日记中所表述的心情、印象、态度，概括为 10～20 个形容词。请只用 TypeScript `string[]` 的格式输出。No more other content.

    “””长假期间天气好热，想出去玩，但想到这么热人又多就懒得走了……”””。

    总结

    ChatGPT 非常强，但要让他发挥全部战力，我们开发者的努力也不可或缺。以上是我这几个月来学习总结得到的经验，希望对大家有用。也期待看到更多开发者从编程角度，分享二次开发的经验。

  • 我的四月 AIGC Hackathon 参赛记

    我的四月 AIGC Hackathon 参赛记

    草长莺飞，Hackathon 纷至沓来

    春节过后，ChatGPT 彻底出圈，带动整个 AIGC 领域备受瞩目。于是乎各项赛事活动纷纷上马，都想抢先收割一波流量，也抢先开始对未来的探索。我也积极报名参加，一不小心报了三个 Hackathon 之多：

    1. 思否举办 AIGC Hackathon
    2. 即刻举办 HackEngine
    3. 腾讯举办 Light 公益创新挑战赛

    其中，思否 AIGC Hackathon 我以主创的身份参赛，其它两项赛事则是以交朋友为目来报名。按照我最初的想法，主要开发一个作品，其它两组尽量以顾问身份贡献力量——至少，我这里有各种后端服务、已经开放 GPT-4 的 OpenAI API、SD 服务器随时可用。结果呢，还是逃脱不了干活人的命运，三个组的产品我都得做，连续三周高强度的开会、开发，把所有上班以外的时间都投入进去，才堪堪做完。还好部分代码可以共用，不然真的忙不过来。

    思否作品：拜拜

    我们在思否的作品“拜拜”获得了大家的广泛欢迎，拿下最佳人气奖。今天主要分享下这个产品的构思与开发。

    创意来源

    我有一位多年好友，叫京超，是位产品经理，我经常会跟他讨论产品想法，我偏向技术，他偏向产品，互相攻防，有点类似头脑体操。后来我们商量要一起做点小产品，万一玩票玩成了呢。不过基本也都停留在口头阶段。

    今年过年，他发现亲戚中存在大量拜佛需求，每天必拜，赶上忙的时候，从相册里翻一张照片也能拜。于是他就想，这个需求我们应该可以满足，用互联网思维来看，这就是个打卡应用。我也看好这款产品，因为从技术角度来说，这类应用几乎不需要后端和数据库，只要前端页面+本地存储就能做，开发、运营成本都很低。

    ChatGPT 爆火之后，我很快想到：如果把 ChatGPT 加上，让用户每日拜佛之后还可以跟神佛交流，得到一些心灵的慰藉，岂不更好？于是马上联系京超，把应用开发提上日程。

    尝试开源共建，失败

    熟悉我的朋友可能知道，我还在做一些前端全栈培训方面的尝试，也有几个交流群。我发现对很多新人朋友来说，缺少项目经验通常是他们的大问题，写简历、面试都捉襟见肘。于是我想，把这个项目打造成开源项目，给群里的同学一些做实战项目的机会，我一方面负责产品规划、代码审查，另一方面尽量跟京超把这个项目的边界扩宽，让更多的人能参与进来。

    结果当然失败了😂。项目启动的时候，大家热情很高，有报名参加的、有围观学习的，20人的群分分钟建立起来。分配任务也比较顺利，大家分别领了一些小任务去做。但到代码审查阶段，问题就出现了。

    我只接受新人同学加入，他们经验不多，没受过系统的编程训练，提交的代码质量自然不好，甚至有同学把整个 node_modules 一起传到 PR 里。我就提了很多修改意见。第一波修改大家基本还愿意做，但修改过的 PR 仍然不过关，犯过的错误一犯再犯，A 同学的错误 B 同学也会出现，让他们互相观看学习也基本做不到。

    项目进度更是一言难尽，每日例会（只需要报告进度和同步计划），从全勤到一半人再到没人来，仅仅用了一周。

    最终，我选择放弃，希望他们能通过别的途径收获项目经验吧。

    参加 Hackathon

    虽然我们的创意过完年就定下来了，但是实际上，到思否 Hackathon 举办的时候，我们的正式代码都还没有任何动静，是真正的 Hackathon 作品。

    看到思否 AIGC Hackathon 的报名启事之后，我觉得我们的想法与之契合度甚高，所以立刻就拉着京超去报名。前面几位同学隐身退群之后，我正打算自己动手写代码，另一位好友竹子突然找我聊天，于是我问她有没有兴趣，结果一拍即合，她也加入我们的团队一起开发。

    我们的分工大约是：

    1. 京超负责产品和设计；
    2. 竹子负责主要流程，即拜佛相关功能；
    3. 我负责杂项、API、基础设施、以及特殊功能（比如语音识别和语音转换）

    我们都是工作多年的专业职人，虽然远程协作，没有很强的约束，但基本上进度很顺利，路演前顺利完成了拜佛流程，还能识别用户的口头祈愿，并用 ChatGPT 给予反馈。路演表现很好，引发大家的热烈响应，最后顺利拿到最佳人气奖。

    线上参赛

    其实我本来没想过要报这么多活动。腾讯 light 每年都有，我也每年都进来划个水，今年的团队比较厉害，“意外”进入复赛。思否启动的最早，我们带着作品来，自然很快就决定报名，也算主次分明。即刻 HackEngine 启动时，我其实犹豫了很久，就是怕时间上错不开，最终决定还是要加入学习一下。

    思否和即刻不约而同的选择把线上和线下分成两个赛道，这种做法很有道理，毕竟线上团队基本上有一个月的时间慢慢打造产品，而线下团队则要现场确定方案、只有 1.5～2 天的时间能真正动手开发。

    比较遗憾的是，即刻连线下赛的 demo 路演都不允许围观，我觉得稍微有点过。其实单纯从产品角度，大家能做的、想做的其实都差不多，不让围观也没太大作用。

    经过几年锻炼，大家对线上活动也都非常熟悉，线上赛的氛围还是蛮好的。秀产品，互加好友，找机会合作，除了不能见面细聊，都挺好的。我们也见到很多令人印象深刻的优秀作品，没拿到前三名也心服口服。希望下次再加油。

    未来

    活动结束，我们的开发还没结束。截止到目前，我们已经初步完成神佛语音合成功能，贴一段视频给大家试听一下：

    下一步我们会逐步完善功能，并且争取多平台发布，成为我们第一款上线应用。

    副产品

    为方便京超寻找最合适的音效，我开发了这个网站，可以尝试在线语音识别与语音合成，只需要腾讯云的 id 和 key 即可使用：

    https://buddha-stt.roudan.io/

    上面的带回音的视频即来源于此。如果需要的话，也欢迎大家使用我们的 API 来进行语音识别与语音合成。

    其它两项赛事的结果

    即刻

    我们组两次尝试均以碰壁告终。第一次我们选择“老年人打卡送鸡蛋”这个方向（也是我把方向理顺的），即老年人每天不定时打卡可以攒积分换鸡蛋粮油，我们通过 ChatGPT + 语音系统与老年人交流，并且将结果反馈给家中的年轻人。这个创意没能押中题 Copilot for X，于是开赛日换主题。第二次选择做装修效果图生成，因为组中小同学缺乏经验，无法做出最终作品，也宣告失败。不过 Hackathon 嘛，本来做不出东西就是常态，而且我们都觉得方向不是问题，现在还在摸索着前进，说不定未来哪天大家会见到我们的成果。

    腾讯 Light

    我们选择的是老年人保护方向，希望用一款输入法保护老年人免遭诈骗分子的侵害。通过初赛，没能通过复赛。

    总结

    ChatGPT 从去年年底震撼业界，到今年火爆出圈，再到现在各种应用层出不穷，几乎每天都有新消息，离不开大家的积极参与。分所谓众人拾柴火焰高，今年与 AI GC 相关的活动非常多，据我所知，思否今年还有六场 Hackathon；即刻 HackEngine 二期即将启动；TiDB 的活动也在筹备之中。如果大家对这方面感兴趣，随时入坑都不算晚。

    还是那句话：期待在不远的 AI 未来里，有你也有我。

  • 我的 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 学习一周总结：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 一定会有一席之地，我们也一起来争取属于我们的新领地吧。