微軟semantic-kernel(SK)團隊釋出了一篇部落格文章：Early Lessons From GPT-4: The Schillace Laws[1] ,微軟的CVP , Deputy CTO Sam Schillace 根據他在GPT-4方面的經驗制定了使用LLM建立軟體的九項原則，稱之為Schillace Laws of Semantic AI[2]https://learn.microsoft.com/zh-cn/semantic-kernel/howto/schillacelaws。
在大模型LLM 時代確定一個開發實踐定律的人肯定是大有來頭，因此我去找了他的資料學習了一下，他有著發現了不尋常的經歷，早在2004-2006年他自己創業，使用c# 構建的產品叫 Writely，也就是Google docs的前身， 2006年被Google收購了，他們當時的團隊有4人，從Writely到Google Docs的轉換的故事 如何避免軟體工程中最昂貴錯誤的發生[3]：
在今年初，我與Sam Schillace會面時也討論過有關重寫的問題，它是Box的技術副總裁，前Google Apps負責人。我向他提了一個問題，“你們工程團隊曾遇到過的最昂貴的錯誤是什麼？”
他的回答是，“嘗試從零開始開展程式碼重寫。”
Schillace的創業公司在2006年被Google收購了，他們當時的團隊有4人，產品名字是Writely即Google Docs的前身。在他們釋出了一個試驗性的C#原型作品後，使用者數很快就突破了50萬。加入Google後，他們收到的第一個商業任務是進行專案遷移，從而充分利用Google的架構體系以實現高容量和高擴充套件性。每天使用者數仍在快速增長，而他們也開始意識到之前所寫程式碼的擴充套件瓶頸。
我還在Google工作時，我知道Google的軟體堆疊是不支援C#的。所以當Schillace說到這裡時，我很自然地問到，“當你們進行從Writely到Google Docs的轉換時，你們是不是隻能從零開始？”。
Schillace的回答是，“是的。”當他們開展重寫工作時，有個合夥人提出邊轉換邊重寫，因為如果進行徹底推翻，將極大增加工作量。Schillace並不認同。最終，他說服團隊只設定一個非常有限的重寫目標，延後其它更多的目標工作。他們定下一個清晰的目標先把系統在Google資料中心運轉起來，然後再整合12種不同的Google技術。他們花費了一個星期來除錯並最終編譯成功。除錯過程中，很多錯誤是由於Java和C#不同的語義表達引起的，例如==雙等號的不同含義。
“這真的真的非常痛苦。”Schillace說道。繼續奮戰12個星期後，他們最終完成了一個“令人驚訝的，奇怪的，晦澀難懂的”程式碼庫。但它也最終在Google資料中心裡成功運轉了，這也創造了一項紀錄——被收購後最快適應Google架構的轉換專案。如果他們不是摒棄了過多的目標，也許還不能這麼快就完成。同時如果他們把更多精力放在程式碼質量上，時間也會用得更多，因為需要修正一堆堆的正規表示式。相反地，他們的目標是使Writely先儘快運轉起來。
這樣的故事是不是很熟悉，這樣的事情在中國也是不斷的發生，將C# 寫的軟體翻成他們喜歡的語言來編寫。 這是最昂貴的錯誤：嘗試從零開始開展程式碼重寫。
Sam Schillace 在微軟領導建立了semantic-kernel專案，選擇使用C# 構建。 當然以後肯定是會支援各種語言的，目前已經預覽支援Python。