其實，我對AI的態(tài)度，一直都是比較謹(jǐn)慎，也比較理性的。

既不過度吹捧，也不掩耳盜鈴，一切順其自然，就挺好。

對我沒用的，別人再怎么販賣焦慮，我也不會關(guān)心。

對我有用的，不用等別人來催，我是會主動擁抱的。

在我目前的工作場景中，使用AI最多的情況，就是讓它幫忙寫SQL。

作為一個不懂代碼的產(chǎn)品經(jīng)理，想想還是有點小激動的。

在以前，如果我想查詢某些特定的數(shù)據(jù)，唯一的辦法就是找開發(fā)同學(xué)幫忙。

你知道的，產(chǎn)品經(jīng)理和開發(fā)，天然就不在一個頻道上。

且不說人家很忙，每天都要改BUG，對我自然是愛答不理的。

就算人家稍微有點空，和他們溝通起來，也是要花很多時間的。

最終的結(jié)果就是，要么給你一個文件，外加一個臉色。要么就是給你一個“做不到”，外加一個臉色。

哎，產(chǎn)品經(jīng)理苦SQL久矣！

這不，救星來了，有了AI，一切都變得簡單了。

當(dāng)然了，想要這一切可行的首要前提是，自己的電腦得連上數(shù)據(jù)庫，這是基礎(chǔ)。

我們公司的開發(fā)，用的都是Navicat，自然而然，我也就用它了。

軟件下載好之后，就需要開發(fā)同學(xué)幫忙開通賬號，開好賬號之后，就開始連接數(shù)據(jù)庫了。

前期要做的工作就是：安裝工具 → 開賬號 → 連接數(shù)據(jù)庫。

以上這些基礎(chǔ)操作做完之后，接下來，就可以請AI開始表演了。

用具體的例子來說吧。

我們公司會定期給用戶發(fā)送優(yōu)惠券，然后就需要定期復(fù)盤優(yōu)惠券的使用情況。

于是我的需求就出來了：我需要指定時間內(nèi)的，發(fā)送的優(yōu)惠券，已使用的數(shù)量、未使用的數(shù)量。

于是，我就將我的數(shù)據(jù)庫信息+需求一起發(fā)給AI。

是的，數(shù)據(jù)庫的基本信息也需要給AI，包括表名、字段名稱、字段類型。不然，在后續(xù)執(zhí)行的過程中，可能會遇到點小麻煩的。

以我的需求來說，提示詞如下：

數(shù)據(jù)庫類型是MongoDB，表名Coupon，匯總下CreateTime是26年1月-3月之間，Type是滿減券，Status這個字段不同值的條數(shù)。

然后，AI就會給出答案，然后復(fù)制信息到數(shù)據(jù)庫中執(zhí)行，然后就是，等待結(jié)果。

是不是很簡單？不僅如此，在給出答案的同時，它還會進(jìn)行解釋，看起來也不費勁。

當(dāng)然，在一切都順利的情況下，數(shù)據(jù)庫會返回你想要的答案，這是最好的情況。

但是，凡事都會有例外。在這個過程中，我也經(jīng)常遇到報錯或者無響應(yīng)等意外情況。

不過也不用擔(dān)心，將看到的報錯信息發(fā)給AI，它會自動進(jìn)行調(diào)整的。

比如剛開始，我沒有說明CreateTime這個字段的屬性，在執(zhí)行的時候返回空。

于是，我就把CreateTime里具體的值，發(fā)送了一個給AI作為參考例子，它也就自然懂了我的意思。

我要做的事情，就是盡量提供精確的信息，信息越細(xì)節(jié)，得到正確答案的概率就越高。

這就是我，一個不懂代碼的產(chǎn)品經(jīng)理，用AI寫SQL的過程。

放在以前，這是我不敢想象的事情，而自從有了AI，讓這一切，變成了可能。

那些在說AI會讓程序員大批失業(yè)，這是危言聳聽，畢竟現(xiàn)階段，有些工作，人還是無法替代的。

未來如何，我不敢說，我們就拭目以待吧。

不過值得慶幸的是，AI確實帶來了改變。

從目前來看，它讓程序員的效率變高了，也讓我對程序員的依賴變少了。

以上這些，都是我親身感受到的變化。

最后我想說的是，終于不用再看程序員的那張臭臉了，這感覺，真爽！

---End---

來源 | 明天上線（ID：mingtianshangxian66）

作者 | 這個需求很急 ; 編輯 | 蝦餃

內(nèi)容僅代表作者獨立觀點，不代表早讀課立場