本該是很簡單的一件事情，但是我刻意選擇了「一定要在Web環境下完成」，最後讓事情變得很複雜。

如果這是公司內部正式開發的專案，這個專案總共耗費了我九天時間。（因為我在鐵人賽中一天實際工時是兩小時左右。）

這值得嗎？

很多人（a.k.a.「主管和老闆」）一定同時表示「不值得」「你這根本不是合格的工程師該做的事情」。
但其實這些人（a.k.a.「主管和老闆」）真正的心態是「每個員工都應該要帶著穩定可靠現成的經驗與流程來為我想要推動的專案貢獻自己的勞動（直到沒有東西可以榨取為止）」。
在這過程中，我體驗過了Flutter和FlutterWeb的差距有多大，也藉機接觸了PCM、RIFF的檔案規格（未來也許有機會可以進一步深化），也使用了Azure的服務。但對很多人（a.k.a.「主管和老闆」）來說，他們希望這些動作都是在加入專案前就完成，或至少最好「一兩個小時、或半天一天內就完成」。

當然，這是最糟糕的情況，並不是所有人（a.k.a.「主管和老闆」）都用這麼極端的態度來面對員工一邊進行專案、一邊進行新技術的開發探索學習。但態度開放、使用正向思考來看待這個過程的，其實是鳳毛麟角！大家只是偏激負面的程度不同而已，終歸是偏激負面。

也許有人可以順利好運的（撿到了好用的範例、或有合用的教本、甚至就憑空擬定了合用的實作策略）在公司部門可以接受的範圍內完成了開發探索學習的過程然後完成了專案（然後升級成資深員工、小心的把這套產品的後續升級維護擴充的知識捏在自己手中不要分享給別人），但對於那些做不到的人呢？

發現了嗎？
其實我真正介意的並不是很多人（a.k.a.「主管和老闆」）的心態，因為這些心態的由來很複雜，有些人是一年三百六十五天總是這麼刻薄（積極的想要把員工榨乾），有些人只是因為專案壓力、經營管理的疲勞、客戶雞巴缺德的樣子，讓他們思維忍不住也跟著小家子氣起來了。
但是，今天軟體工程師面對的環境卻是工程師們自己營造出來的。
膚淺不負責任更不實用的教案範例討論串在網路上到處飛，埋藏了各種地雷的套件用後沒人解除沒人維護，規格文件說明混亂曖昧、明擺著不想讓人看懂....

就在最後的AzureTTS裡有個現成的例子。
要使用API除了要取得「Key」以外，還要輸入一個跟「Key」配對的「region」，（這是類似做為密碼？或是種設定值？無解。）
AzureTTS的API文件中並沒有特別說明這個「region」的設定或取得方式，而且留下的說明非常的曖昧模糊。

To set the SPEECH_REGION environment variable, replace your-region with one of the regions for your resource.

最後我是直接去問了AI，「我在台灣，請問這個region要設為多少？」
一問馬上有答案。（上一篇說到如何取得Key，其實找到答案與題目的過程沒那麼順利。）

這些問題的答案並沒有「學問」或「深度」，它通常無法經由邏輯推理思考、或有秩序的實驗試錯來找到答案，它就是種「Q&A式的規格」。
通曉並且不要明白的分享這些「Q&A式的規格」是很多工程師賴以為生的竅門，應付這些「Q&A式的規格」過去耗費了工程師無數的心力卻往往還不得其門而入，但AI copilot可能會改變這一切。
Riff的規格其實沒有什麼邏輯可言，因為那就是某個工程師在播放器或解碼器內制定了這樣的檔頭結構，這個結構本身跟「聲音/音樂」本身沒有直接的關聯。（雖然檔頭結構內有包含了重要的音檔規格，但這些規格可以用任何形式組成各種不同規格檔頭。為什麼制定這樣的檔頭本身其實沒有「邏輯」和「道理」好講，有的只是個結論而已。）
但過往要找到「可以看懂含義與做法的文件」是件很困難的事，文件本身就不多了，很多講得很粗淺、甚至錯誤百出。

我並不擔心AI是否會取代工程師，我也不會樂觀的期待AI讓工程師的工作變輕鬆，但我很期待看到AI讓這些沒有「學問」或「深度」的「Q&A式的規格」變得很好取得、很好理解。

(對了！有件事情提一下：存檔成功了！可以在一般播放器中播放音檔了！）

今年的鐵人賽似乎還有三天報名時間...要不要再挑戰個題目呢？