副標題：生物堿全合成中的計算機輔助關鍵步驟生成
隨著能模擬真人聊天、甚至能幫著做作業的人工智能（AI）程序ChatGPT的大紅大紫，朋友圈里時不時都能看見有人曬與ChatGPT的聊天記錄。不知讀者朋友有沒有試過讓ChatGPT幫著回答一些專業點的化學問題，看看這個AI程序能強到什么程度。
談到這個，是因為計算機領域的發展也在推動著甚至改變著化學領域的發展。此前，我們已經報道過不少計算機程序或者AI在化學研究中的應用，比如預測晶體制備策略（Nature, 2016, 533, 73, 點擊閱讀詳細），根據分子結構預測氣味（Science, 2017, 355, 820, 點擊閱讀詳細），反應條件優化（Nature, 2021, 590, 89, 點擊閱讀詳細），獨立自主地探索化學新反應和新分子（Nature, 2018, 559, 377, 點擊閱讀詳細），以及設計復雜天然產物的全合成路線（Nature, 2020, 588, 83, 點擊閱讀詳細）。近日，美國密西根大學的Tim Cernak教授課題組又在這一領域取得了突破，他們在Science 雜志上報道了一種新的計算策略，結合計算機輔助合成規劃（computer-aided synthesis planning，CASP）與分子圖編輯（molecular graph editing）以最大限度地縮減生物堿合成的所需步驟。作為例證，通過利用高影響關鍵步驟他們成功地將(–)-stemoamide（1）的對映選擇性全合成縮短為僅僅三步。其中關鍵之處在于計算機算法建議的Mannich反應，有意思的是，在此前報道過的30多種(–)-stemoamide全合成路線中從未涉及到該反應。
圖1. 關于1的兩個逆合成規劃。圖片來源：Science
復雜天然產物全合成，尤其是生物堿全合成，被看作是科學與藝術的結合，直到今天也是化學領域的研究熱點。除了攻克一個又一個的復雜結構，化學家們還在追求讓全合成更高效——路線盡量短、收率盡量高、條件盡量溫和。通常情況下，高效的全合成一般通過優化關鍵步驟（如：環加成、串聯或多組分偶聯反應）來同時形成許多必要的目標鍵，以便快速實現所需的結構復雜度。盡管關鍵步驟的概念為化學家所熟知，但其尚未應用于CASP中。事實上，現代CASP策略旨在最大限度地減少保護基操作并最大限度地提高收斂性，但自動化逆合成的重點則是放在編碼反應規則上以在預測路線的實驗中實現最大的可靠性。同時，最先進的人工合成策略通過采用創新但風險性較高的關鍵步驟并最大限度地減少低影響步驟（如：保護基操作、不必要的氧化還原操作和官能團的相互轉換）來最大限度地提高步驟經濟性和原子經濟性。
盡管現代CASP設計的路線已在藥物合成中有所應用，但卻很少用于生物堿的全合成中。為此，作者選擇從百部科植物中分離出來的生物堿stemoamide（1）為目標分子，它的四個手性中心和稠合環結構將帶來足夠的挑戰，而且它32條已被報道的合成路線也視為有效的比較基準。如圖1所示，Route 1計劃去除α-甲基并切斷氮雜環的C-N鍵得到烯烴2，而2是由CASP推薦的關鍵步驟——有機催化的Mannich烯丙基化-內酯化序列產生的，進一步簡化為起始原料3、4和兩當量的醛5；而Route 2則源于CASP和圖編輯策略的推演，其中CASP推薦的Schmidt-Aubé重排是一個關鍵的簡化元素。環丁酮中間體6利用關鍵的Michael加成和烷基化可進一步分解為原料7、8、9和10。
圖2. 通過圖編輯分析識別關鍵步驟。圖片來源：Science
作為從CASP生成路線中最大限度縮減步數的第一次嘗試，(–)-1在軟件SYNTHIA 中進行了自動逆合成，其中有機催化的Mannich反應出現在了每條預測路線中（圖2A），這讓作者感到很意外，因為先前的32種合成路線中從未涉及到該反應。然而，即使最短的計算路線也需要7步，因此作者引入分子圖編輯以通過最大化高影響轉化和最小化低影響轉化來編輯計算路線。如圖2B所示，作者將每個中間體（包括起始原料和最終目標）的分子圖編碼為單獨的鄰接矩陣，其中行數和列數等于整個合成路線重原子和基團的總數。通過這種方式，最終目標的所有鍵、從起始原料出發的反應路徑以及合成中使用的任何讓步基團都被準確地映射到每個單獨的矩陣中，并與最終目標的矩陣相關（圖2C）。對1的矩陣（圖2B，右）進行簡單比較后，作者發現其與計算的倒數第二個中間體14（圖2B，中）共享更多條目（99%），并且比與起始原料3、11、12、8和HBr的矩陣多（圖2B，左）（93%）。因此，關鍵步驟最大限度地減少了從給定中間體到目標的圖編輯距離（graph edit distance），這相當于最大限度地形成目標鍵，同時最大限度地減少反應操作。另外，通過圖編輯距離對已發表的全合成進行的研究表明，不同的關鍵步驟很容易可視化。值得一提的是，1的最短計算路徑的完整圖分析揭示了Mannich偶聯的影響（圖2D），即圖編輯距離圖中最陡峭的下坡步驟（黃色）。
圖3. 基于不對稱有機催化Mannich反應的1的全合成。圖片來源：Science
盡管計算顯示Mannich反應為關鍵步驟，但仍有待改善的地方，例如：C2和C11在1中都處于羧基氧化態，因此考慮到氧化還原經濟性，可以協調11和12的氧化態以減少兩個步驟，即兩當量的市售醛5在self-Mannich反應中結合（圖3A），接著在反應后期安裝手性α-甲基，而先前的報道已證實非對映選擇性甲基化在 1的幾種合成中作為最后一步是可行的。具體合成路線如下：將3與四倍過量的醛5和20 mol% L-脯氨酸溶于DMF中并在-15 °C進行攪拌，然后向其中加入烯丙基溴化物4、鋅、氯化鉍并升溫至室溫就可通過中間體Mannich加合物15得到主要產物——內酯16。隨后，通過過濾從反應混合物中除去過量的鋅和不溶性物質，并將粗濾液用三氟乙酸進行處理、經柱色譜純化以33%的總收率、38:1 dr值、99% ee值得到內酰胺17，這意味著通過兩步序列就能以高選擇性快速構建五個鍵、兩個環和三個立體中心，并且只需一次柱色譜純化。接下來，要進行17的氫溴化，但在實驗過程中CASP建議的策略（使用氫溴酸）得到了難以處理的混合物。為此，作者將烯烴17轉化為伯醇18，然后進行溴化和原位脫除對甲氧基苯基得到19，最后經環化和非對映選擇性烯醇烷基化安裝C10甲基便可合成(+)-1，總共6步并且僅需四次柱色譜純化。此外，作者還對通過計算路線的修改而產生的實驗路線進行了圖編輯分析（圖3B），其中Mannich烯丙基化關鍵步驟的高影響顯而易見，而且隨后完成合成所需的官能團相互轉化的影響也很低。為了獲得步驟更少的合成路線，作者生成了數百條額外的計算路線以得到1及其相關的后期中間體（如20）。有趣的是，其中一種計算策略涉及到一種特殊的環丁酮中間體（6的類似物，圖4A），后續可通過Schmidt-Aubé重排合成1。具體而言：從市售原料7出發，經Brown烯丙基化獲得中間體21（產率：58%，ee值：89%）。接著，用正丁基鋰使22去質子化，并將21添加到陰離子的冷溶液中，然后用碘甲烷捕獲中間體烯醇化物并用鹽酸水溶液淬滅反應混合物，便可以88%的產率和4:1 dr值得到酮 6，再與疊氮基三甲基硅烷經2-亞碘酰基苯甲酸（IBA）催化的反馬氏加氫疊氮化反應得到中間體23，最后經Lewis酸誘導的假定中間體 24 的分子內Schmidt-Aubé重排便可實現(–)-1的全合成，整個過程的最長線性步驟（LLS）為3步，總產率為22%，比上圖中的合成步數減少一半。
圖4. 基于Schmidt-Aubé重排的1的全合成。圖片來源：Science
在1的六步合成中可以很容易地觀察到步驟影響，其中第一個有機催化的Mannich烯丙基化步驟顯著增加了3、5和4到1的圖相似性，安裝了產生1所需的 45% 的化學鍵（圖3B）。這個高影響步驟之后是一系列低影響步驟（如：保護基操作和官能團相互轉換），可很容易通過圖3B中的淺斜率識別。相比之下，3步合成路線效率更高，分別為中間體到1的圖相似性貢獻了17%、55%和28%（圖4B），并且關鍵步驟是從一千多個計算的逆合成路線的分析中選出的。此外，圖編輯距離技術還可用于突出顯示路線中的捷徑，即通過將圖編輯圖中具有適度斜率的相鄰轉換組合為一個快捷步驟來實現。例如，Mannich路線中的第3、4和5步原則上可以組合為整體的反馬式加氫酰胺化，因此可以用硝酸鈰銨（CAN）淬滅TFA促進的內酰胺化（step 2）以產生17的類似物，其中PMP基團從3中去除，總收率為33%，然后該類似物可以一步法轉化為中間體20，最終以四步實現1的全合成。
總結
Tim Cernak教授課題組通過(–)-stemoamide的對映選擇性三步全合成，突顯了現代 CASP為中等復雜目標分子規劃可行合成路線的能力。本文的方法表明，可以將來自不同 CASP 路線建議的多個高影響步驟結合起來以得出更簡潔的合成路線。在當前的研究中，作者將步數作為唯一的優化指標，但未來重要的現實指標（如試劑成本、砌塊可用性、預測產率）可以很容易地作為加權距離指標納入。隨著自動話逆合成的進一步發展，復雜的分子包括藥物分子將會更容易獲得。
Computer-aided key step generation in alkaloid total synthesis
Yingfu Lin, Rui Zhang, Di Wang, Tim Cernak
Science, 2023, 379, 453-457, DOI: 10.1126/science.ade8459
選自dev.to
作者：Lydia Hallie
機器之心編譯
參與：Panda、杜偉
git merge、git rebase、git reset、git revert、git fetch、git pull、git reflog……你知道這些 git 命令執行的究竟是什么任務嗎？如果你還有些分不清楚，那千萬不能錯過這篇文章。在本文中，熟知 JavaScript、TypeScript、GraphQL、Serverless、AWS、Docker 和 Golang 的 21 歲年輕軟件顧問 Lydia Hallie 通過動圖形式直觀地介紹了這些常用 git 命令的工作過程，包你過目不忘。
盡管 Git 是一款非常強大的工具，但如果我說 Git 用起來簡直是噩夢，大多數人也會認同我的說法。我發現在使用 Git 時，在頭腦里可視化地想象它會非常有用：當我執行一個特定命令時，這些分支會如何交互，又會怎樣影響歷史記錄？為什么當我在 master 上執行硬重啟，force push 到原分支以及 rimraf 我們的 .git 文件夾時，我的同事哭了？
我覺得創建一些最常用且最有用的 Git 命令的可視化示例會是一個完美的用例！下面我將介紹的很多命令都有可選參數——你可以使用這些參數來改變對應命令的行為。而我的示例只會涵蓋命令的默認行為，而不會添加（或添加太多）可選配置！
本文作者Lydia Hallie。
合并
擁有多個分支是很方便的，這樣可以將不同的新修改互相隔離開，而且還能確保你不會意外地向生產代碼推送未經許可或破損的代碼修改。但一旦這些修改得到了批準許可，我們就需要將其部署到我們的生產分支中！
可將一個分支的修改融入到另一個分支的一種方式是執行 git merge。Git 可執行兩種類型的合并：fast-forward 和 no-fast-forward。現在你可能分不清，但我們馬上就來看看它們的差異所在。
Fast-forward (—ff)
在當前分支相比于我們要合并的分支沒有額外的提交（commit）時，可以執行 fast-forward 合并。Git 很懶，首先會嘗試執行最簡單的選項：fast-forward！這類合并不會創建新的提交，而是會將我們正在合并的分支上的提交直接合并到當前分支。
完美！現在，我們在 dev 分支上所做的所有改變都合并到了 master 分支上。那么 no-fast-forward 又是什么意思呢？
No-fast-foward (—no-ff)
如果你的當前分支相比于你想要合并的分支沒有任何提交，那當然很好，但很遺憾現實情況很少如此！如果我們在當前分支上提交我們想要合并的分支不具備的改變，那么 git 將會執行 no-fast-forward 合并。
使用 no-fast-forward 合并時，Git 會在當前活動分支上創建新的 merging commit。這個提交的父提交（parent commit）即指向這個活動分支，也指向我們想要合并的分支！
沒什么大不了的，完美的合并！現在，我們在 dev 分支上所做的所有改變都合并到了 master 分支上。
合并沖突
盡管 Git 能夠很好地決定如何合并分支以及如何向文件添加修改，但它并不總是能完全自己做決定。當我們想要合并的兩個分支的同一文件中的同一行代碼上有不同的修改，或者一個分支刪除了一個文件而另一個分支修改了這個文件時，Git 就不知道如何取舍了。
在這樣的情況下，Git 會詢問你想要保留哪種選擇？假設在這兩個分支中，我們都編輯了 README.md 的第一行。
如果我們想把 dev 合并到 master，就會出現一個合并沖突：你想要標題是 Hello! 還是 Hey!？
當嘗試合并這些分支時，Git 會向你展示沖突出現的位置。我們可以手動移除我們不想保留的修改，保存這些修改，再次添加這個已修改的文件，然后提交這些修改。
完成！盡管合并沖突往往很讓人厭煩，但這是合理的：Git 不應該瞎猜我們想要保留哪些修改。
變基（Rebasing）
我們剛看到可通過執行 git merge 將一個分支的修改應用到另一個分支。另一種可將一個分支的修改融入到另一個分支的方式是執行 git rebase。
git rebase 會將當前分支的提交復制到指定的分支之上。
完美，現在我們在 dev 分支上獲取了 master 分支上的所有修改。
變基與合并有一個重大的區別：Git 不會嘗試確定要保留或不保留哪些文件。我們執行 rebase 的分支總是含有我們想要保留的最新近的修改！這樣我們不會遇到任何合并沖突，而且可以保留一個漂亮的、線性的 Git 歷史記錄。
上面這個例子展示了在 master 分支上的變基。但是，在更大型的項目中，你通常不需要這樣的操作。git rebase 在為復制的提交創建新的 hash 時會修改項目的歷史記錄。
如果你在開發一個 feature 分支并且 master 分支已經更新過，那么變基就很好用。你可以在你的分支上獲取所有更新，這能防止未來出現合并沖突。
交互式變基（Interactive Rebase）
在為提交執行變基之前，我們可以修改它們！我們可以使用交互式變基來完成這一任務。交互式變基在你當前開發的分支上以及想要修改某些提交時會很有用。
在我們正在 rebase 的提交上，我們可以執行以下 6 個動作：
reword：修改提交信息；
edit：修改此提交；
squash：將提交融合到前一個提交中；
fixup：將提交融合到前一個提交中，不保留該提交的日志消息；
exec：在每個提交上運行我們想要 rebase 的命令；
drop：移除該提交。
很棒！這樣我們就能完全控制我們的提交了。如果你想要移除一個提交，只需 drop 即可。
如果你想把多個提交融合到一起以便得到清晰的提交歷史，那也沒有問題！
交互式變基能為你在 rebase 時提供大量控制，甚至可以控制當前的活動分支。
重置（Resetting）
當我們不想要之前提交的修改時，就會用到這個命令。也許這是一個 WIP 提交或者可能是引入了 bug 的提交，這時候就要執行 git reset。
git reset 能讓我們不再使用當前臺面上的文件，讓我們可以控制 HEAD 應該指向的位置。
軟重置
軟重置會將 HEAD 移至指定的提交（或與 HEAD 相比的提交的索引），而不會移除該提交之后加入的修改！
假設我們不想保留添加了一個 style.css 文件的提交 9e78i，而且我們也不想保留添加了一個 index.js 文件的提交 035cc。但是，我們確實又想要保留新添加的 style.css 和 index.js 文件！這是軟重置的一個完美用例。
輸入 git status 后，你會看到我們仍然可以訪問在之前的提交上做過的所有修改。這很好，這意味著我們可以修復這些文件的內容，之后再重新提交它們！
硬重置
有時候我們并不想保留特定提交引入的修改。不同于軟重置，我們應該再也無需訪問它們。Git 應該直接將整體狀態直接重置到特定提交之前的狀態：這甚至包括你在工作目錄中和暫存文件上的修改。
Git 丟棄了 9e78i 和 035cc 引入的修改，并將狀態重置到了 ec5be 的狀態。
還原（Reverting）
另一種撤銷修改的方法是執行 git revert。通過對特定的提交執行還原操作，我們會創建一個包含已還原修改的新提交。
假設 ec5be 添加了一個 index.js 文件。但之后我們發現其實我們再也不需要由這個提交引入的修改了。那就還原 ec5be 提交吧！
完美！提交 9e78i 還原了由提交 ec5be 引入的修改。在撤銷特定的提交時，git revert 非常有用，同時也不會修改分支的歷史。
揀選（Cherry-picking）
當一個特定分支包含我們的活動分支需要的某個提交時，我們對那個提交執行 cherry-pick！對一個提交執行 cherry-pick 時，我們會在活動分支上創建一個新的提交，其中包含由揀選出來的提交所引入的修改。
假設 dev 分支上的提交 76d12 為 index.js 文件添加了一項修改，而我們希望將其整合到 master 分支中。我們并不想要整個 dev 分支，而只需要這個提交！
現在 master 分支包含 76d12 引入的修改了。
取回（Fetching）
如果你有一個遠程 Git 分支，比如在 GitHub 上的分支，當遠程分支上包含當前分支沒有的提交時，可以使用取回。比如當合并了另一個分支或你的同事推送了一個快速修復時。
通過在這個遠程分支上執行 git fetch，我們就可在本地獲取這些修改。這不會以任何方式影響你的本地分支：fetch 只是單純地下載新的數據而已。
現在我們可以看到自上次推送以來的所有修改了。這些新數據也已經在本地了，我們可以決定用這些新數據做什么了。
拉取（Pulling）
盡管 git fetch 可用于獲取某個分支的遠程信息，但我們也可以執行 git pull。git pull 實際上是兩個命令合成了一個：git fetch 和 git merge。當我們從來源拉取修改時，我們首先是像 git fetch 那樣取回所有數據，然后最新的修改會自動合并到本地分支中。
很好，我們現在與遠程分支完美同步了，并且也有了所有最新的修改！
Reflog
每個人都會犯錯，但犯錯其實沒啥！有時候你可能感覺你把 git repo 完全搞壞了，讓你想完全刪了了事。
git reflog 是一個非常有用的命令，可以展示已經執行過的所有動作的日志。包括合并、重置、還原，基本上包含你對你的分支所做的任何修改。
如果你犯了錯，你可以根據 reflog 提供的信息通過重置 HEAD 來輕松地重做！
假設我們實際上并不需要合并原有分支。當我們執行 git reflog 命令時，我們可以看到這個 repo 的狀態在合并前位于 HEAD@{1}。那我們就執行一次 git reset，將 HEAD 重新指向在 HEAD@{1} 的位置。
我們可以看到最新的動作已被推送給 reflog。
原文鏈接：https://dev.to/lydiahallie/cs-visualized-useful-git-commands-37p1