部落格已遷移到：https://arabelatso.github.io/ 這裡啦～歡迎大家去新部落格一起學習，討論～
方向：形式化驗證、模型檢測、機器學習
語言：python、murphi

邏輯思路：

相較於introduction部分，這個部分就比較好些了，只要遵循一些套路（只有套路得人心），就可以寫好一段漂亮的related work

但是要注意的是，綜述的related work和新方法論文中的related work篇幅不一樣。綜述中的需要更詳細一些，列舉的工作也就更多一些。但是思路是一樣的，總體結構總分總，每個段落也總分總（比較推薦），或者總分。

1. 第一段總說。比如我們著眼於什麼型別的相關工作，他們大體可以被分為哪幾個種類，包括a，b，c（或者這裡不具體寫也可以）。
2. 分段例子－順序。 每一個種類的工作的工作可能有好幾個。不要像疊羅漢一樣，可以按照他們的推程序度來進行排序。比如a做了什麼，b在a的基礎上提出了什麼，c又在b的基礎上改進了什麼。但是，大多數情況，我們參考的論文並不會這麼相關，也不會真的誰基於誰，那麼這時候有一個提示：發表時間。比如a是2010年發的，那麼它考慮的東西可能就沒有b那麼多，b就比它更近了一步。如果時間都一樣，都是2015年，那麼在方法上具體的去考量，比如a改進的是某個方面，這個方面比較容易想到的，而b改進的方面沒那麼容易想到，而且效果更好，結果表現也提高得更多，那麼我們就把b放在a後面說。總之，就是要讓各個例子之間，能夠有個順序，這個順序最好是遞進的，昇華的，所以我們才會把我們的工作擺在最後，因為最後的都是最好的～哈哈哈。
3. 分段例子 － 段內邏輯。 知道了工作們的順序之後，我們要把它們按照邏輯陳列在每一段中。每一段的機構是總分總。第一個總，沒什麼好說的，就是講這一類的方法是在做什麼，最好是一句話簡介。分，就是按照順序把那些例子說出來，最好也都一句話。
   如果有幾個例子比較相似，可以在講完這幾個例子的時候做一個小小的不易察覺的總結。比如：a怎麼做，b怎麼做，c怎麼做。它們都是針對與burst
   time的預測，可以更好的為資源分配做準備。（綜述比較好用，因為綜述要講的例子多，要寫的也就多了，能多一點就多一點嘛）。最後一個總，要昇華。比如：我們可以注意到，這些工作都是對流行度的總體趨勢進行預測的，所涉及的方法也主要是針對流行度的趨勢模式進行監測和識別的，這就使得要預測個體的趨勢就incapable了。這個批判不要說得太重，恰到好處地點出缺點就行了，不用過度變低。我之前就用詞太重，常常就是fail
   to之類的重話，顯得別人做的工作很stupid，這樣是不好的。畢竟我們是踩著別人的肩膀上來的，給點面子嘛。
4. 最後一段總說。 總的說一下各類的工作有什麼共同的缺陷，或者因為現在的實際應用有什麼新的要求了，而以前的工作已經不適應新的要求了，那麼我們想要適應新的更practical的問題，需要作出什麼樣的調整，
   或者想要一個什麼樣的方法，能夠解決這個問題。簡短一點即可。

一些問題：

1. 相關工作中是否要圖表？ 可以要的，也不是硬性要求。比如是關於資料庫的related work，那麼一個圖表可以很清晰的把各個資料庫的規模大小，含有資料種類的比較等等資訊直觀地表現出來，勝過你說千言萬語。
2. 相關工作要寫多長？ 這個沒有硬性標準。有看過在提出新方法的論文中只用了2段來寫的； 也有見過花了好多段融會貫通的寫在introduction裡邊的；
   也有的就是上面所說的結構，是比較經典的。綜述的話，還是建議中規中矩的按照上面的流程來走，新方法的寫作，如果沒有特殊要求，或者你的方法實在太屌了需要用很大的篇幅來描述，沒時間贅言別人的工作，除此之外，都建議用上述的標準結構來寫。新方法的話大約一頁雙欄的其中一欄到一欄半左右，大約400-500字，也不太多。
3. 是否要加引用？ 這個不是廢話嘛肯定要啊，而且在寫的時候，比較常用的方法是：“ Bella et.al. 做了什麼”，這種句式。那麼這個可以在名字後面直接引用，也可以在這一句之後引用。個人感覺寫在完整的句子之後比較好看。要注意引用是在句號前面哦。不要出現“balabala。［1］
   ”這種情況，很醜，也不對。正確示範： “balabala［1］。” 完美。