Skip to main content

Command Palette

Search for a command to run...

机场杂谈:挥霍 Api 和 Aigc

Updated
1 min read

最近总在写一些小玩意,有了 Copilot 和 ChatGPT,我得了一种奢侈的选择困难症——每次写代码之前都会犹豫一下:这次用啥语言呢?

几个小玩具

我给自己做了个播客

生娃和进厂之后,个人独处时间越发金贵,随之而来的问题就是阅读量难于保障了。过去我的阅读流程是浏览邮件列表、固定的播客、推特等信息源头,根据喜好情况搜集到 Pocket 之类的 Read it later 工具里面。但是现在因为缺乏连续时间,待读列表越来越长。想了下也就是跑步和开车的时候耳朵是比较清闲的——灵机一动:“给自己做个播客吧”。

个人使用,当然能省则省,大致定下了这样几个分工和工具:

  • 运行平台:Google Function,免费额度足够每日使用,负责抓取网文并
  • 存储:使用 Google 对象存储,同样免费额度
  • 交互:Github Issue/Comment + Webhook,构成交互界面
  • 翻译和整理:ChatGPT/DeepL,将互联网上抓取的内容进行翻译和排版
  • TTS:Azure TTS 服务免费额度
  • Buzzsprout:支持 API 的播客托管平台,能自动对接 Apple 和 Google 的播客服务目录

选定平台之后,使用 Github Issue 交互,通过 Webhook 调用 Google Function,借助各个服务,完成抓取、翻译、朗读以及发布的环节,最终形成了我自己的播客节目,怎么说呢——聊胜于无吧。

我给自己翻译了一本书

想把一本书翻译成中文,在线等,挺急的。

最近一直在看《Team Topologies》这本书,奈何我的英语水平比我的时间还有限,突然想起 @yihong0618 的项目 bilingual_book_maker,于是用了起来,使用 GPT 3.5 API,大概三个多小时,epub 就变成了一本中英同屏的读物了。如下图:

sample page

老实说翻译效果麻麻地,能看,好在是留着英文对照,倒也不会太影响阅读,推测是因为逐段翻译缺乏上下文支持造成的。

给自己请个运维专家

这是之前公众号文章中提到的 Pipe2GPT 项目,一个没头没脑的 Prompt:作为一个 IT 领域的专家,对于这段输出你有什么看法?我应该采取什么措施?,不管在控制台看到什么输出、或者日志,都用管道发给 ChatGPT,目前看来,知名软件的输出内容都能够得到具备一定可操作性的结果。

所以我想说啥

本领域知识依旧不可或缺

不论是翻译、出图、编程还是辅助创作等等,应该说都惊喜有余,可信不足的。例如

  1. 多次在利用 ChatGPT 生成代码时,出现错误的 API 地址、错误的数据结构等。AI 写代码,开发工作变成调试工作,效率不见得一定会提升。
  2. 整书翻译过程中,因为上下文长度限制,会有较多的错误结果。
  3. 出图跟编码差不多,修修补补的能力也还是要有的。

综上,毫无疑问地,ChatGPT、Midjourney 等的确能够快速出活,然而要达到交付要求,还是需要有碳基人坐镇本领域,才能达成生产级别的目标。

技术又解放了

其实最近给自己写着玩的东西远不止这些,尤其是结合 LangChain 之后,很多以前看似需要“思考”的东西,现在都可以通过一些零碎代码和零钱来解决了。如果有一点 Python 入门的开发和调试能力,结合 Copilot 或者 ChatGPT 这样的工具,就能够完成很多可用的东西了。正如我前一阵朋友圈吐槽说的——对“知其所以然”的需求,再一次被降低了。就像前面几个例子,虽然被朋友耻笑说这种不算个东西,上不得台面,但是的确解决了自己的问题,像生物信息等严重依赖编程的非 CS 专业来说,有了这些新东西的帮助,应该能大大降低工作难度,提高工作效率。

一大波新思路正在接近

用前面提到的 bilingual_book_maker 项目来说,究其本质,其实跟 ChatGPT 并没有很多关系,它只是将 ChatGPT 作为一个跟 Deepl API 等价的可选插件而已,当然这里并没有贬低这个项目的意思,相反地,这个项目给我的思考是——AIGC 的热潮,促使我们对很多传统 IT 领域进行新的审视,简单说又可以翻大饼了。这似乎是第一次,人工智能用这样触手可及的方式深入到各个领域,大概是堪比个人电脑进入家庭一样一股浪潮,除了对各种 IT 非 IT 领域的直接促进之外,应该也会促使对更多问题的深入思考——例如 HR 大概在思考的:

  • 程序员应该裁掉多少?
  • 实习律师留三成还是五成?
  • Prompt 技能要写到 JD 里面吗?怎么考核呢?
  • ....

每个人/组织都需要自己的垂类 AI 支持

众所周知,ChatGPT 一直在嚷嚷他的数据来源仅限于 2021 年之前,以及 Token 数量的限制等(ps,很奇怪,我只申请到了 ChatGPT,一直没机会使用其它几个大模型),导致面对一些垂类或者一些非公开上下文的时候束手无策,因此不论是私有模型还是其它手段,总要有某种方法来支撑这些更加贴近业务目标的需求。

安全隐私要出大问题

ChatGPT 在很多非结构化内容的处理上都有令人有点满意的效果,例如用来审视合同、润色文字作品、撰写周报、评估简历等等。其实很难抵抗把自家材料提交给 ChatGPT 的冲动,最终面对安全隐私部门的惩处,对吧?

更有意思的是,市面上有非常多的 ChatGPT 以及其他 AIGC 平台的代理,甚至已经有了分销和盈利的运作模式,放胆设想一下,一个野生 AIGC 代理,能拿到多少不为人知的大小秘密?

编不下去了

一次喝酒时,曹老板还在笑我:这个 AI 怀疑论者买了 Copilot(甚至 Copilot 怎么读都不知道)。现在我倒是经常在琢磨如何做好一个 AIGC 带路党的事情,可惜脑容量有限,一直没头苍蝇一样四处乱撞。接着航班大延误的机会,随便把这些零碎思考记录下来吧。

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts