我們在前壹篇提到了在線貝葉斯估計，在這壹章中，我們講述在線貝葉斯估計體現出來的重要思想：要精益求精，不要步步為營。
我們在前壹章中第壹次提到了 在線貝葉斯估計 的概念：當證據源源不斷到來時，貝葉斯估計並不是等著所有的所有的證據來了以後才開始計算基於所有收集到的觀測的後驗概率。而是開始根據少量的證據計算壹個概率，然後每次拿到每壹個新觀測的時候，都用該觀測來調整之前的估計。
以開水房打水的例子而言，妳進入開水房準備打開水，妳想知道這個水是否開了，在這個過程中，妳實際上是壹步壹步拿到證據，並且用這些證據不斷更新妳上壹步的猜測的：
這個例子中，觀測是源源不斷來的。在線貝葉斯估計使得我們不用等拿到所有可能的觀測之後再估計壹個最終的後驗概率，而是可以
貝葉斯的在線估計算法的核心，和很多 在線算法(on-line algorithms) 相同。在線算法的核心步驟包括以下幾點：
和在線算法相對的叫做 離線算法(off-line algorithm) 。離線算法又被稱為batch algorithm。離線算法對於新來的數據，總是把它加到前面的數據重新計算得到結果。比如說壹開始妳有100個數據，妳用這壹批數據得到了壹個結果，當妳又有了100個新的數據後，妳需要把這100個和原來的100數據合並起來，用200個數據重新計算壹下結果。這就是離線算法。
在線算法和離線算法的最大的不同是不需要重新計算，而是在前壹次的計算的結果上進行調整：拿到新的100個數據之前，用著100個數據來更新之前計算的結果，更新的結果和用200個數據重新計算的結果壹樣。因此在線算法和離線算法最大的差別不在於數據是否壹個壹個來，而在於是需要重新算，還是在原來的基礎上進行更新。
在線算法的例子：求均值
我們用求均值的例子來說明在線算法和離線算法的區別。假若給妳100個數，從x1,x2,...,x100，要求它們的均值很容易：
這種方法是拿到所有的100個x後壹起計算的。這就是離線算法。
而在線算法是如何計算的呢？
這個均值，是基於當前的所有數據(只有壹個x1)計算得到的。
也就是說，從初始估計
出發，
這個就是求均值的在線算法。
相比離線算法，在線算法有三個巨大的優勢：
不僅如此，在線貝葉斯，乃至所有的在線算法體現出來的壹種思想，就是 精益求精 ：在最開始，我們並不求完美，而是先得到壹個結果；我們在該結果的基礎之上，不斷的接收新的信息對原來的結果進行改進，以達到我們所追求的最優的目標。
精益求精的這種思想，在很多領域都有非常多的體現。舉幾個例子。
例子1: 函數極值的數值解法
在我們高中的時候，我們就學會求壹個函數的最大值或者最小值。我記得最常用的方法就是求導法。我們將函數的表達式求導數，令其為0，建立壹個方程。方程的解就是這個函數的極值。
例如對於函數
而言，該函數的導數為
令導數為0，即
與解析解相對的，就是 數值解(numerical solution) 。數值解的核心思想就是精益求精。我們用下圖來解釋。圖中的藍色曲線，就是這個函數y的表達式。我們想找到這個函數最大值對應的x的位置(紅點處)。
找到數值解具體有以下幾步：
我們可以發現，找到數值解的思路是並不試圖壹次就找到函數最優值的位置，而是用逐步叠代的方法不斷逼近最優值。這就是精益求精的思想。
而我們剛才的解析解的方法，是根據公式嚴格推導。這種方法用成語 步步為營 來描述最為貼切。相比較於精益求精，步步為營有兩個缺點：(1)知道最後壹步之前，妳永遠不知道答案，哪怕是壹個粗略的答案(2)壹旦任何壹步出了錯誤，最後的結果都是錯的。
從這壹點來說，我們在初高中的最後幾道大題都是步步為營：在妳推出最後結果之前，妳不知道妳證明對了還是錯了，並且壹旦中間任何壹步錯了，妳都無法得到正確的結果。
例子2: 項目管理中的敏捷模型
熟悉項目管理的人，都知道項目管理有兩種不同的模型。第壹個模型是瀑布模型(Waterfall model)。瀑布模型將壹個系統的開發分成包括需求分析、設計、實現、發布等多個階段。每個階段都有相應的管理與控制，因此能夠比較有效的確保系統品質。瀑布模型顯示在下圖中的上半部分。我們可以看出，瀑布模型中各個階段有相互銜接的固定次序，如同瀑布流水，逐級下落。
然而，用瀑布模型來進行項目的管理有2個重要的缺點:
與瀑布模型相對的是敏捷模型(Agile Model)。敏捷模型顯示在上圖的下半部分。我們可以看出，在用敏捷模型來開發項目中，整個開發工作被組織為壹系列短周期的快速叠代。每壹次叠代都包括了需求分析、設計、實現與測試工作，並通過客戶的反饋來進行不斷改進，直到達到最後的要求。
和瀑布模型相比，用敏捷模型來進行開發的突出優勢在於
這裏說的瀑布模型和敏捷模型，同我們剛才的函數極值的解析解和數值解何其相似！瀑布模型和解析解這兩種方法，都是采用了'步步為營'的思路，而敏捷模型和數值解，就對應著`精益求精'的思路。
例子3:最簡可行產品
很多年前，我和同事壹起去和壹家私營公司的CEO談項目合作。這個公司是做國內做高壓電線自動檢測最好的壹個公司。簡單的來說，他們做了壹個設備，可以用壹根長的桿子捅到高壓電線上掛住，然後實時檢測輸電線路是否正常工作。壹天晚飯的時候，這個CEO在和我談到他們開發的思路的時候，說了這麽壹段話：
像我們這樣的小公司開發產品，尤其是科技含量較高的產品，不能想著壹步到位。最開始，壹定要把壹個不完美，但可用的產品搞出來。這樣我們心裏就有底了。然後拿到現場去用，工程師在部署後會告訴我們很多設計之初沒想到的問題，用戶會給我們提供更多的要求，我們就在這些基礎上壹步壹步改進。別看我們現在這個產品功能看著這麽漂亮，但是第壹代產品剛出來的時候問題非常多 。
這麽多年，我仍然記得清清楚楚他說的這個 就是不完美，但可用的產品 的這個概念。後來我才知道，這就是大家所說的`最簡可行產品'（minimum viable product，簡稱 MVP)。MVP的嚴格說法，是指的有部分機能恰好可以讓設計者表達其核心設計概念的產品。設計者可以進行驗證式學習，根據使用者的回饋，進壹步了解使用情形，並且繼續開發此產品。
我在香港的胡子科技學院( /mvp/ )的網頁上看到下面壹個例子。
市場的反應往往是難以預料的。尤其是初創企業。試想想當妳投放了大量資源、金錢、時間，請了壹隊團隊去開發壹個 APP／平臺，推出到市場後卻發現沒啥人用，感覺是絕對不好受的。
解決這個'推出市場後沒有人用的問題'最好方法，就是MVP。創業者與其花大量資源去開發壹個 自以為會成功的完美產品 ，倒不如用最快的方法，建立壹個只有最少、最基本功能的'半成品'。先把這個'半成品'推到市場，看看市場的反應。
有很多非常成功的初創企業，也是遵循MVP的精神。Groupon這家市值上億美元的公司，便是MVP的壹個很好例子。
創辦人Andrew Mason 在成立Groupon初期，與其花資源去建立壹個`完美的團購系統'，他只建立了壹個簡單的WordPress博客。這個博客定時會放上壹些商店優惠的文章，而其優惠也只是透過人手，壹封壹封的去電郵給參加者！後來，他發現這個發布商店優惠文章的博客非常受歡迎，Andrew 因此確定這個主意有市場後，才開始組織團隊去開發這個團購系統。
上壹個例子中的敏捷模型，其實就是先力爭推出壹個MVP。推出MVP之後，開發者可以根據用戶或者使用者的回饋，進壹步了解使用情形，並且持續不斷的在上壹個版本的基礎上，根據實際情況進行改進。
MVP和剛才說的敏捷模型，實際上還和最近互聯網行業推出產品基本的做法 小步快跑，快速叠代 的思路完全壹致。
小步快跑，快速叠代，就是不要想著壹次性發出好的產品，而要通過快速叠代的方式進行更新，保證每壹小步都跑得很快。在快速叠代理念支持下的產品研發是 '上線-反饋-修改-上線' 這樣反復更新內容的過程。再開始時，要允許不完美，但要通過快速叠代逐漸向完美逼近。每天都能發現修正壹兩個小問題，不到壹年產品就打磨出來了。
與之相對的，如果開始總是面面俱到的謀布局，並且在每壹步盡善盡美求完美否則不肯往下走，這樣的問題就在於，妳開始壹旦某壹個點沒考慮到或者考慮不周全，那麽妳只能到最後壹步才會發現問題所在，此時重頭再來的代價和時間成本會過於昂貴。
凱文?凱利在他的暢銷書《失控》裏，有過這麽壹段話:
例子4: 用精益求精的方法來寫論文
我在香港理工大學期間，聽到過壹位我非常敬佩的老師來組裏給學生分享過應該如何寫學術論文。
他告訴我們，寫壹篇論文有兩種方案。第壹種方案，是遲遲不下筆，要等著把idea想好，仿真做好，實驗完成之後，拿到了所有的素材之後才開始寫。在寫的過程中，按照自然順序壹章壹章的打磨，寫完壹章，再寫下壹章。
第二種方案，就是稍微有了壹個idea就開始寫，甚至這個idea都不需要很好。寫的過程中，不打磨語法，用最快的時間寫出壹個初稿。初稿寫完以後，給周圍的人看，讓他們提意見，這時我們就會知道這個文章的idea有哪些漏洞，如何改進等等。然後不斷的進行多次`快速叠代'式的修改文章。每次修改，都完善idea，仿真、實驗，修改語法，這樣最終把文章打磨完成。
這位老師說，我們壹定要用第二種方法來寫文章。
現在看起來，確實應該如此。如果按照第壹種方案來寫文章，妳可能永遠都寫不出壹篇論文。原因在於，(1) 只有當妳寫完以後，別人才可能給妳意見，壹旦妳發現某壹個意見可以采納，妳可能需要重新做實驗，做仿真，又重頭來過，導致時間耗費的過長。(2) 寫文章的過程中，如果按照壹章壹章的仔細打磨，妳可能發現妳寫到後面的時候，因為需要修改idea或者仿真等，前面的部分很多需要重新寫，這些仔細打磨的部分就全部浪費掉了。
其實，不僅僅是寫科學論文，我覺得這種方式可以用到寫任何文章的方法。Facebook人工智能研究院智能圍棋項目的負責人，也是網上的著名科學段子手田淵棟，在他的知乎專欄中發表的壹篇文章《碎片化時代如何讀寫》中，寫到下面的壹段話：
這種方式，實際上就是先盡可能寫出壹個MVP出來，然後再不斷叠代去改進。從這個意義上來講，最初迅速的完成壹個MVP，比花很長時間完美的完成壹個產品要重要的多，這也是印證了這句格言：
完成比完美更重要 (Done is better than perfect) 。
我們在前面幾個例子中，說到了用精益求精的思想來開發產品、寫文章等的好處。妳應該可以理解，用精益求精的思想的好處在於，可以快速後端的用戶(或者開發者本身)得到反饋，迅速完成叠代升級。
其實，從開發者是否能完成這個項目而言，用精益求精的思想來做項目，有兩個好處。
第壹個好處，是 安心！ 在前面的'例子3:最簡可行產品'中，那個CEO和我說的壹段話中就可以反映這壹點：最開始，壹定要把壹個不完美，但可用的產品搞出來。 這樣我們心裏就有底了 。
心裏有底，這就是安心。起碼從方案上來講，這個方案是可行的。開發者需要做的，就是在這個可行的方案上進行改進而已。即便哪壹點改進不成功，退回原來的版本即可，起碼這個版本可以work！相反的，如果用步步為營的方式來做項目，直到妳到達最後壹步之前，妳都不知道這個產品到底能不能工作，壓力山大！壹旦不能工作，妳可能需要重頭再來。這就是精益求精比步步為營的好處。
第二個好處，就是多次的即時反饋。開發者用精益求精的方式改進MVP，每次改進成功，實際上都可以獲得完成時的成就感。壹旦得到這個成就感，開發者又可以迫不及待地投入了下壹個小目標，進壹步改進當前的版本。
我在上課的時候問過我的學生壹個問題，為什麽壹個人上自習學習的時候，堅持1個小時不到可能就得休息，而玩遊戲的時候，則可以通宵呢？
原因就在於學習的反饋鏈條很長，而玩遊戲可以得到即時反饋。
《遊戲改變世界》壹書中，揭示了人類會被遊戲吸引的深層機理就是：即時反饋。遊戲開發人員深諳此道。妳在遊戲中的任何操作，都會立馬視覺化、數據化地顯示出來。
不要小看每次砍怪物頭上飈出的數字，不要小看出招的音效，不要小看傷血的紅字和加魔的藍字，它們都給玩家提供了最最直觀的即時反饋。
妳清楚的知道，妳這次擊殺怪物，壹定會漲經驗值，並且有幾率會得到壹些寶物。其實就是說，及時反饋使得妳明確知道，妳的每壹次操作，都是有回報的，並且回報就在操作完成時！這就是使得我們能通宵玩遊戲的原因。
對比現實生活中的學習卻相反。今天妳費勁心力背了50個單詞，幾乎完全不能立刻看出妳付出努力的成效：之前看不懂英文書還是看不懂，之前聽不懂的英文電臺還是聽不明白。妳只有持之以恒的堅持很多年，才會突然有壹天發現妳的英語水平漲了。但是這個反饋鏈條未免也太長了吧。
包括英語的很多學科、乃至很多技能的學習的反饋鏈條都很長。例如小提琴和二胡。直到妳付出非常長時間的枯燥的練習之後，妳拉出的聲音才不至於讓人立刻想把妳趕走。自己的努力不能得到即時反饋，就是很多人不能靜心下來學習的主要原因。
忍不住想起了左小祖咒唱的這個《交作業》的這首歌
天哪，這個反饋鏈條如此之長，並且回報充滿了如此之多的不確定性，難怪沒有動力交作業啊。。。。
怎麽破？其實核心就在於如何縮短這個反饋鏈條。例如背單詞的時候，妳可以引入獎勵機制或者自我成就機制，例如每次完成50個單詞的任務，就給自己壹個獎勵，或者在妳的完成任務列表上重重的打壹個勾！
從另外壹個角度而言，我們需要訓練自己的延遲滿足的能力。延遲滿足，就是壹種克服當前的困難以獲得長遠利益的能力。 通俗地說，就是堅韌(Grit)。堅韌不拔的忍耐能力，對壹個人極其重要。
我們今天的收獲是：