AI提效,本质上是工程问题,而不是技术问题
今年,各公司纷纷将重心放在 AI 上。随着半年的“热火朝天”,AI 领域也开始出现了名词膨胀的现象,仿佛流畅说出各种高大上的概念,就代表对 AI 有了深入理解,以便升职加薪,或是吸引流量、贩卖焦虑。
今年,各公司纷纷将重心放在 AI 上。随着半年的“热火朝天”,AI 领域也开始出现了名词膨胀的现象,仿佛流畅说出各种高大上的概念,就代表对 AI 有了深入理解,以便升职加薪,或是吸引流量、贩卖焦虑。
Shopify 最近更新了一篇文章,讲了他们如何使用 MySQL 替换 Redis 实现库存预留(Inventory Reservation)。我进行了一番阅读,并结合自己的实验做了一些分析。
很多人第一次做 AI 应用时,都会有一种错觉:
“调用一下 GPT API,不就做完了吗?”
例如:
response = llm.invoke(prompt)看起来确实简单。
上周上班时候,听到对面一个小姐姐惊呼:“我的天呐,这个需求怎么测下来没几个bug,我好慌!”
其实不少人应该都体验过这种感觉,而且对于开发来说心里更加没底,跟测的时候焦急地等待,却没等来几个bug,总感觉上线要爆雷。
在测试领域,流量录制一直是一个“听起来很美好,但落地往往困难重重”的方向。
我体验了一段时间 Keploy 后,发现它可能是目前少数真正把“录制 → 回归”链路打通的工具,但目前网络上它好像有点低调,因此我专门写一篇文章。
上篇文章说到,我最近用 stdio 的本地 mcp 方式实现了各种基建与 AI 之间的连接,例如查数据库、调接口等等。
这篇文章分享一下出现问题(如接口报错等)时让 AI 直接来排查原因的实践。我可以很明确地说,现在 AI 的能力已经非常强大,这条路是完全走得通的,而且效果很好,超出预期。