架构师视角：GPTs Demo搭建后的思考（上）
由安德鲁小镇GPTs的PoC实录
引发的资深架构师的思考
实践之后，AI到底会对软件开发带来什么样的变化？
UX的变化；API的未来；LLM的位置
01 安德鲁小镇GPTs-Demo
在 2023年11月 Open AI 的开发者大会，发布了一个新的服务: GPTs，我这次 demo 的主角, 就是想试试看, 搭配自定义的 API，GPTs 能把体验做到什么样的程度?
GPTs 是以 Chat GTP 为基础, 他允许你在这基础上, 预先设定好它的角色设定 (只管用自然语言说明就好), 背后的知识库 (只管上传档案就好, 不用理会 RAG 什么的细节), 你也可以把自己的 API 挂上去 ( Custom Action, 只要遵循 Open API spec 就好, 写好每个 path 的说明即可, 不用做特别设定, GPTs 会自己思考何时要呼叫你的 API)。完成之后，这个定制化的 GPTs, 就会按照你的设定, 来回应你的问题。而我这次的 demo, 就是定制了安德鲁小舖 GPTs, 他是个店长, 你只要跟他对话, 他可以在线上服务你, 并且替你呼叫 API 完成整个购物的流程。
整个测试进行下来，说老实话，技术门槛很低，没有太多新的 “技术” 要学。但是整合应用的门槛很高，困难的地方在于跟传统的做法差异太大了，像我这种经验充足的业界老人反而束手束脚的很不习惯.. (这是我的问题啊)，有很多颠覆传统的思考方式需要适应。另一个感受就是: 我对 API 的看法又更深一层了，这个 demo 里，API 是 AI 与现有系统的唯一沟通管道，而 API 被呼叫的方式也跟过去不同，要呼叫你 API 的是 AI，是你无法预测他行为模式的 LLM，而不是另一个 developer … 这背后带出了你的 API 不再是 “能用就好” 的设计思维，而是要真正要让领域专家 (我假设给了正确知识的 GPTs 就是领域专家) 能充分理解 API 运作逻辑，并且能正确使用。过去我在谈的 API First 跟 Business Model，正好在这边完全派上用场，这是这次 PoC 能顺利进行最关键的地方。
开始看 demo 吧! 你有几种方式可以体验 安德鲁小舖 GPTs:
- 懒人包, 可以直接看完整对话记录。
- 技术细节，可以直接看我这次开出来的购物网站 API 规格。
- 实际体验安德鲁小舖 GPTs, 只要你有 Chat GPT Plus 订阅，点这个链接就可以体验了。我只是实验性质，API 目前架设在 Azure App Service 下，没有 HA，随时会关掉。资料都是存在记忆体内，服务重启就会清空。账号注册登入只是个流程，只看 username，密码乱打都可以过。
介绍完毕，接下来我就用我的情境，跑完一次整个使用的过程吧:
1.1 店里都卖什么？
首先，对话一开始，我就问了店里都卖什么:
其中看到“已与andrewshopoauthdemo. azurewebsites.net 进行对话”，就代表 GPTs 背后已经在呼叫你的 API 了，箭头往下拉可以看到背后 POST 了什么资讯.. 这边还如预期，GPTs 中规中矩的呼叫了 /api/products, 把取得的商品资讯 (json) 转成清单显示给我看。GPTs 蛮细心的地方是，商品资讯还会自动帮我摘要.. 我原本写的内容比较啰嗦… 为了方便对照，底下是 API 原生传回的内容:
[
{
"id": 1,
"name": "18天台湾生啤酒 355ml",
"description": "18天台湾生啤酒未经过巴氏德高温杀菌，採用欧洲优质原料，
全程0-7°C冷藏保鲜，犹如鲜奶与生鱼片般珍贵，保留最多啤酒营养及麦香风味；
这样高品质、超新鲜、赏味期只有18天的台湾生啤酒，值得您抢鲜到手!",
"price": 65
},
{
"id": 2,
"name": "可口可乐® 350ml",
"description": "1886年，美国乔治亚州的亚特兰大市，有位名叫约翰•潘伯顿
（Dr. John S. Pemberton）的药剂师，他挑选了几种特别的成分，发明出一款美味的糖浆，
没想到清凉、畅快的“可口可乐”就奇迹般的出现了！潘伯顿相信这产品可能具有商业价值，
因此把它送到杰柯药局（Jacobs' Pharmacy）贩售，开始了“可口可乐”这个美国饮料的传奇。
而潘伯顿的事业合伙人兼会计师：法兰克•罗宾森（Frank M. Robinson），认为两个
大写C字母在广告上可以有不错的表现，所以创造了\"Coca‑Cola\"这个名字。但是让
“可口可乐”得以大展锋头的，却是从艾萨•坎德勒（Asa G. Candler）这个具有行销
头脑的企业家开始。",
"price": 18
},
{
"id": 3,
"name": "御茶园 特撰冰酿绿茶 550ml",
"description": "新升级!台湾在地茶叶入，冰酿回甘。台湾在地茶叶，原叶冲泡。
如同现泡般的清新绿茶香。",
"price": 25
}
]1.2 设置预算和商品折扣后的处理
接着我就开始出难题给 GPTs 了… 我的 API 只有提供商品单价，或是你加入购物车后，会有 API ( /api/carts/{cart-id}/estimate ) 会传回结账金额的试算结果。这段 code 背后有做折扣条件的计算。背后的规则是:
18天台湾生啤酒 有第二瓶六折优惠
不过这规则并没有 API 揭露，因此需要推测，并且加入购物车试看看才能知道结果。所以我出了难题给 GPTs:
结果还蛮神奇的，GPTs 的理解跟推理能力还不错，看得懂我的要求，也看得懂 API 的能力范围，于是自己推演了逻辑，一连串呼叫了好几次 API 帮我确认结果，最后给了我建议的采购项目。不得不说，做得比我预期好，虽然偶尔也会得到错的答案，但是看得出来 GPTs 有在努力…。
(不过，这结果没有 100% 稳定可靠，我在测试的过程也碰过很瞎的答案.. )
我继续刁难他。过去在做 Chat Bot 的经验，对谈只是在聊天介面下下 CLI 的指令那样的感觉，根本不是 “对话”。这种 Chat Bot 要说上能了解你的意图，根本就差太远，只能说是鸡同鸭讲。为了确保 GPTs 真的理解我的意图，我刻意追加了要求，用口语要求在前面的结果修正多加两件，而品名我也刻意用同义字，只讲了 “啤酒”，没有讲精准的产品品名..
结果 GPTs 的处理相当正确，呼叫了对应的 API，也给我正确的结果，并且进行了结账的流程，呼叫了 /api/checkout/create (开始结账) 的 API..
结账过程很顺利。我的 API 设计本来就只要求拿到支付 ID 就当作结账完成，而 API 背后我也没真的去检查 ID 对不对，简单的说你只要给个 ID 就能过关。GPTs 也正确地替我呼叫结账完成 API, 完成结账。并且显示订单内容给我:
到这为止，购物的主要流程都很顺利地结束了。我给 GPTs 100 分，因为他替我 “脑补” 补上了我 API 没有涵盖的功能，这点对我来说还蛮震撼的，GPTs 补足了所有软件的难题: 猜测使用者想要干嘛，然后做出正确回应… 我留一些感想在后面观点再聊，我继续往下 demo …
1.3 调整订单，不要酒类饮料
继续测试 GPTs 的解读和处理能力… 我继续挑战他的对话能力，这次告诉它预算，条件比照办理，但是有小孩不能喝酒。我特意句子里没有讲不要买酒，只是隐讳地告诉他我的期待，需要靠他自己联想，该把购物车内的酒类商品都拿掉，并且调整数量符合我的预算跟条件 (不同商品购买数量要接近一致):
碰到我这种难搞的客人，果然钱很难赚 XDD，这次也顺利结账，获得第二张订单，过程我就略过了 (有兴趣自己看对话记录)。
1.4 整理订单记录
接下来，身为一位常客 (也才买两次)，来询问一下买过了什么也是很合理的… 问了订购记录，GPTs 也帮我办到了，同时也很尽责地帮我把订单内容汇总了一下才回给我。我贴一下 GPTs 的回应:
我也补一下 API 回应的 raw data (json) 结果，让大家可以对比一下.. (测试完成我就清掉了，这 API ( /api/member/orders ) 结果是我事后另外补的，内容不大一样各位就别计较了 XDD)
{
"totalOrders": 2,
"totalAmount": 2172.0,
"orders": [
{
"id": 1,
"buyer": {
"id": 1,
"name": "andrew"
},
"lineItems": [
{
"title": "商品: 18天台湾生啤酒 355ml, 单价: 65 x 12 件 = ¤780.00",
"price": 780
},
{
"title": "商品: 可口可乐® 350ml, 单价: 18 x 11 件 = ¤198.00",
"price": 198
},
{
"title": "商品: 御茶园 特撰冰酿绿茶 550ml, 单价: 25 x 11 件 = ¤275.00",
"price": 275
},
{
"title": "优惠: 18天台湾生啤酒 355ml 第二件六折, 折扣 ¤26.00",
"price": -26.0
},
{
"title": "优惠: 18天台湾生啤酒 355ml 第二件六折, 折扣 ¤26.00",
"price": -26.0
},
{
"title": "优惠: 18天台湾生啤酒 355ml 第二件六折, 折扣 ¤26.00",
"price": -26.0
},
{
"title": "优惠: 18天台湾生啤酒 355ml 第二件六折, 折扣 ¤26.00",
"price": -26.0
},
{
"title": "优惠: 18天台湾生啤酒 355ml 第二件六折, 折扣 ¤26.00",
"price": -26.0
},
{
"title": "优惠: 18天台湾生啤酒 355ml 第二件六折, 折扣 ¤26.00",
"price": -26.0
}
],
"totalPrice": 1097.0
},
{
"id": 2,
"buyer": {
"id": 1,
"name": "andrew"
},
"lineItems": [
{
"title": "商品: 可口可乐® 350ml, 单价: 18 x 25 件 = ¤450.00",
"price": 450
},
{
"title": "商品: 御茶园 特撰冰酿绿茶 550ml, 单价: 25 x 25 件 = ¤625.00",
"price": 625
}
],
"totalPrice": 1075
}
]
}我的 API 很啰嗦的把每个折扣都列出来了，但是 GPTs 回给我的讯息，把它汇总 summary 结果给我了，这种程度的讯息处理，没有 AI 的辅助，自己开发 Chat Bot 会开发到哭出来吧…
接着，继续为难店长 (咦?)，我很清楚我的 API 只有传回订单内容，我就要求 GPTs 帮我家总一下到底每种商品我买过几件…
结果，如我预期做得很不错，不但没有重新打一次 API 重新取得结果之外，也正确地理解我的要求，帮我算好统计结果了。最后我要求把条列的内容换成表格，也一样做到了 (看起来是用 markdown)
1.5 PoC小结
Demo 内容就到此先告一段落，背后很多技术细节，跟我处理过程踩到的地雷，就先跳过。
为了方便大家快速判定一下 GPTs 到底 “脑补” 了多少东西，我附上我的 API source code:
程式码我就直接附上 GitHub Repo 了。我的目的只是 PoC, 所以里面有很多 Anti Patterns, 请直接忽略…
我相信不少朋友只是想知道 API 做了哪些事，我特地把 swagger 打开才部署上 Azure App Service, 需要可以直接看swagger, 我也截了图:
02 软件开发的变化
我从开始学写程式时写的第一行程式码<span style="text-decoration: none;">printf("Hello World, Andrew!"); 开始，所有交给电脑处理的事情都是非常明确的，一个指令一个动作。直到现在，电脑都不大能处理逻辑不明确的操作，这 20 年来最大的差别就是操作变简单了，但是要明确的指令这件事一直都没变.. 这也难怪, 电脑从一开始被发明出来, 英文是 “computer” (计算机), 而不是像中文这样翻译成 电 “脑”, 或是 “智慧” 等等这类用语，计算机就是计算，再复杂的计算还是计算，不是智慧，也不是真人。
不过 AI 在 2023 的发展，打破了这个门槛。对我这种 AI 门外汉来说，我看到的就是语言模型突然之间成熟到能理解对话内容背后的 “意图” 了，突然之间你问他什么内容，他都能若有其事地回答你有参考价值的答案 (正确性是另一回事，但是至少是人话了)。光是这点，就足以打破过去 20+ 年我对软件开发的基础认知。
2.1 使用者体验
软件发展过程中，很长时间都是在在改善 “UX” (User Experience)，都在标榜直觉，易懂，好操作。从视窗介面 (用画面 + 滑鼠替代键盘)，用所见即所得代替指令 + 输出结果的过程；进化到行动装置后，体感操作也进来了，用触控，装置翻转，镜头，麦克风等等操作，再次用手指 + 体感，替代滑鼠..
不过这些都是让 “操作” 变简单，基本上你还是在下指令。你心里仍要清楚这 “指令” 跟预期 “结果”，只是这指令越来越简单而已。我在教家里长辈用手机电脑，最大的障碍不是这些操作，而是不知道要完成他的 “意图” 该做什么 “操作”..
举例来说，长辈想要把一份文件传给对方…
“我该开 email 还是 line? 我该选档案还是复制链接? 我该打对方的电话号码还是 …? 对方是 facetime 我怎么 line 给他…”
这些问题没让长辈搞懂的话，操作再简单都没用，长辈们用手机电脑就是存在着障碍… 更不用说档案系统的目录阶层跟档案，还有 APP 之间的关系了 (我家的长辈永远搞不懂一个 word 档案开了三个 word 视窗是怎么一回事)
这就是我所谓 “使用者意图” 跟 “使用者操作” 之间的隔阂。目前所有的 UX，都是在 UI 设计基础上，去 “猜测” 使用者的意图是什么，而让整个操作过程变简单，流程缩短的持续优化过程。然而，这 “猜测” 的准确度落差很大，业界能把 UX 真正做得很好无懈可击的案例，说真的其实不多。这到目前为止还是门非常专业，非常倚重经验的一个设计领域。
2.2 由大语言模型整合所有资源
而 LLM (大型语言模型, Large Language Model) 的成熟，我认为这个隔阂开始被打破了。所有在去年初次体验 Chat GPT 的人大概都有一样的感受吧! Chat GPT 的 UI 不怎么样，就是聊天而已，很普通，但是他对你输入的文字能很正确的猜到你的意图，给你合理的回应，光是这点就完全把其他的 UX 做的努力甩到一边去了。对我而言，这是所谓的 “降维打击”，LLM 用截然不同的方式，来解决 “了解意图” 这件事，这解决方式的差异，注定了传统的 UX 优化，再怎么样是跟不上 LLM 的。
因此，我在这次 PoC 我亲身体会到 LLM + API 的整合威力了。这次 PoC 我认为影响我想法最大的，就是我的 API 怎么被呼叫的这个过程。过去，API 一直都不是给 “人” 看的东西，都是工程师们之间沟通用的火星文，凡人是看不懂这种外星语言的.. 然而如果你把 LLM 当 “人” 来看，他却又有办法在 “自然语言” 跟 “程式语言” 之间对应..。
这部分 open ai 的文件: Function calling 这篇就说明的很清楚, 各位可以不用看他的完整规格, 但是流程说明倒是可以看一下，我节选的部分:
Function calling allows you to more reliably get structured data back from the model. For example, you can: Create assistants that answer questions by calling external APIs (e.g. like ChatGPT Plugins) e.g. define functions like send_email(to: string, body: string), or get_current_weather(location: string, unit: ‘celsius’ or ‘fahrenheit’) Convert natural language into API calls e.g. convert “Who are my top customers?” to get_customers(min_revenue: int, created_before: string, limit: int) and call your internal API Extract structured data from text e.g. define a function called extract_data(name: string, birthday: string), or sql_query(query: string) …and much more!
过去，UI 是由前端工程师做出来的，在 UI 之后，完全就是工程师的世界了。UI 接受使用者的操作，UI 设计人员就必须负担把它转译成 “正确” API 的任务，而这 API 一路往下层传递，变成呼叫其他服务，或是存取资料库等等细节。
而透过 LLM，路线不同，但是目的一样，同样是把使用者的输入转译成 “正确” 的 API 呼叫。只是这里的输入，可能是自然语言，甚至是整个操作的前后情境 + 自然语言的综合判断。LLM 能够理解来自多方的内容 (只要都能对应成自然语言，也就是 Prompt)，就能做出正确的回答。例如你丢给 Chat GPT 一篇文章，你在接着问他一些问题，Chat GPT 能 “理解” 这些文章内容，并且重新整理萃取出你要的内容，甚至按照你要求，加工整理之后给你结果。要转译成 API 呼叫也是一样，从自然语言归纳成呼叫 API 的步骤，逐步把每个参数从语言中萃取出来，变成正确格式 (json)，剩下就交给其他模组接手 (转发 API) 就完成目的了。
这个 安德鲁小舖 GPTs 就是在做这件事，而且做得还不错，我才开始感到震撼，未来的软件开发，免不了一定要有个环节，必须善用 LLM 的解读使用者意图的能力才行。而 LLM 会扮演的是整个软件系统的中控中心 (因为他能断定该呼叫什么模组，而不是单纯照预先写好的逻辑)
我所谓的 “整个软件开发的变革” 就是指这个，未来越需要贴近使用者意图的应用，越会依赖 LLM 当作中控中心。所有操作都先转化成自然语言丢给 LLM，由 LLM 帮你 “思考” 该调用哪些功能来满足使用者。这 “思考” 的过程就是从前后文找出对应的 API，然后从前后文萃取出参数来呼叫。而应用程式的开发框架，也开始会配合这样的架构抽象化，方便软件开发人员快速堆叠建构应用。
所以，在未来 API 不会消失，但是 API 不再是给其他开发者看的火星文，API 的设计也必须开始合理化 & 标准化，因为未来会呼叫你 API 的不再是 developer，而是 LLM。无法被 AI 快速使用的 API 将会是落伍的武器，无法在下个世代发挥战力。
2.3 所有的应用都会围绕着LLM来开发
什么叫做 “无法被 AI 快速使用的 API” ?
前面 2-2 聊的问题，关键只有一句话，就是: LLM 负责自然语言与函数呼叫之间的转换 ( LLM 要将自然语言转为 API call 的顺序与解析出对应参数，而要将 API 回应结果汇总给使用者 )
翻成白话，就是 AI 理解你 API 的使用方式，靠的就是 “文件”。你可以透过文件告诉 AI 该怎么使用 API，但是你无法约束它，因此你的 API 设计是否有一致性，是否合理，是否够严谨就很关键。你必须有很明确的流程，AI 才能输出正确的呼叫顺序的脚本来执行，如果流程错误，你的 API 必须能辨别，如果你发现你的 API 有很多 “特例”，你就得花更多时间来写文件，并且测试 AI 能否理解。
在这次的 PoC, 我就犯过类似的问题。不合理的设计，靠文件是补不完的，你能做的只有几个:
- 封装: 不合理的设计就藏起来吧，别让 AI 看到..
- 文件: 如果问题不大，文件标注 “不能这样用喔…“，也许有机会
- 改写: 重新封装一个 “设计” 合理的 API，开放这版本的 API 给 API ..
到最后，别再指望你 API 的缺陷，可以提醒其他 developer 闪开或是配合你了 XDDD, LLM 不吃这一套的，除非你有足够的本钱来训练你自己的语言模型 (通常是改 API 的ROI最高)
2.4 各种角色的职责变化
因为这些核心流程的改变，我相信未来的软件开发，会从很基础的结构就开始翻过一轮。我先简单摘要几个我想通的变革，后面再从这些变革出发，来看看 Microsoft 的 AI 技术布局，也来看看 架构师 等资深人员，还有软件开发者 的角色该如何调整自己来追上这波变革。
1. LLM 会变成作业系统的一环:
我预期 LLM会变成作业系统的核心元件之一。不论是整合云端的 AI service，或是软硬件已经有能力在设备端 (edge) 就能执行 LLM 运算。作业系统会统一管理这些资源与沟通介面。所谓的 AI OS / AI PC 大概就是这么一回事
2. LLM 会融入主流的软件开发框架:
软件开发框架会改变，势必会让 LLM 有个正确的位置，并且有足够的 Plugins 机制让应用程式能去扩充 LLM 的 “技能”，让 LLM 充分的使用它
3. Copilot 会变成作业系统的主要介面:
操作介面也会改变。UI 不会消失，但是如同我的 PoC，开始会有一部分 UI 无法处理的需求，会用自然语言 (文字，语音，视觉等等) 等方式来沟通，并且让 LLM 来引导。这就是 Microsoft 不断推广的 Copilot 基础。这也会下沉到作业系统，或是主要的工具入口 (如 Office, GitHub, Visual Studio 这类特定领域的必要软件)
未来，不论你是软件开发的哪一种角色，架构师也好，开发者也好，你都该了解这些改变，并且能在这改变中做出贡献 (有能力能加速这改变的过程)，你就不用担心你会被 AI 淘汰...