如何評價演算法本身的理解不重要 ，只要會用現成的開源工具來實現就可以這種觀點？
之前沒有說清楚，這裡對演算法的理解指的是專業方向的理解，比如用CNN 去做圖像識別，不需要深入理解CNN ,只是將CNN當作一個黑盒子，能夠在caffe上簡單改代碼去實現就可以了，諸如此類觀點
==============================================================最近在一家公司演算法崗實習，聽到一些觀點說在工業應用上，對演算法本身的理解並沒有那麼重要，而且有時候是浪費時間的，只要會利用開源工具儘快實現就可以了。想問一下大家這種觀點是否有道理？
既然成熟的演算法不去理解，那麼新出的論文就更看不懂了，既然看不懂，就自己實現不了新的演算法，既然自己實現不了，就只好等眼巴巴的等別人造輪子了。如果別人造了輛破車，你開上路發現跑不起來，自己又修不了，就只好罵娘了 ...
我是針對題主的問題答的，既然他是演算法崗，我主要指的就是他要靠著吃飯的方向的演算法。如果你在工地里刷牆砌磚，懂建築力學確實用處不大。
人生苦短，有理解演算法的能力不代表有理解演算法的必要。就像我想吃冰淇淋，不必須要從奶油、蛋清、糖開始買起自己做一樣。當然有時候我比較關心冰淇淋是否健康，也會稍微看一下成分表。再進一步，我想吃一種特定奶油製成的冰淇淋，又買不到，就要學習一下冰淇淋的製作過程，自己親自搭了。
這是我自己的一些經驗，並不保證正確。
我的感覺是，如果對於工具只停留在會用的程度，有可能局限你的視野。在工作中，有些同事說，做演算法不就是實驗嗎。有一個問題，把所有方法都試一遍，哪個好就用哪個。所以我聽到一種說法，做演算法就是拼體力。
還有同事說，做演算法不就是看運氣嗎？那個人拍腦袋想到了這種方法，試驗了一下，果然成功了。我就是沒那個運氣。我私下以為這是未了解本質的緣故。我並不是說我自己就了解多少，我也在探索。
但是我確實感到，多思考，多學習是有幫助的。
不是體力勞動。拿到問題之後，有些人覺得可選的方法太多了。可有經驗的人覺得，都是套路。這個問題沒什麼路可選，就只有幾種可能的做法，所以可以節約時間。前者有點像新手程序員上來做技術選型，感覺什麼都可以。而後者就是架構師了，懂得什麼問題上什麼方法。不是運氣。就好像做面試演算法題，我們有的時候會奇怪，別人怎麼一下子就想出來了？那是因為看到同一道題，有經驗的人不是看字面，而是看到這道題背後的原理，和其他題目的相似之處。所以拿到題目，就能夠在八竿子打不著的地方找到答案。不過，不是機械的理解演算法，看懂了演算法，會自己推了之後，還要多比較總結。看共性，所以了解機器學習紛繁的演算法背後的本質，看區別，所以了解一個統一的學習問題是怎麼被大家分解成子問題的。
不只是理解演算法，還要看應用。看演算法在各種地方的應用。看明白了，同樣是總結。看共性，看區別。不用著急，慢慢來。看多了，就從可能世界走向了必然世界。有個球的道理喲，符合預期的時候還行，不符合預期就束手無策。可惜符合預期的情況太少了。就像寫程序一樣，簡單實現點功能，一切正常的時候，也不用理解底層的原理。但是出現bug了，出現了非預期問題，不了解底層原理怎麼解決，只能麻爪。
看工作需要，比如說預算，deadline。如果預算有限，時間比較緊迫，那麼工業界一般優先考慮先使用成熟開源方案。這我覺得是合格工程師的基本素養。畢竟公司是產品導向的
但是事情也有另一面，公司的關鍵問題要攻關，有足夠的錢，那麼就需要你無論多難的演算法都要深入底層。只不過這樣的人都是公司信任的骨幹
所以問題的關鍵還在於你自己。很可能作為實習生，你花了很多時間造了一個低水平的輪子，別人在委婉地提醒你這個觀點的錯誤點在於目前機器學習的模型沒有一個是可以當做黑盒子使用的，都有一些假設或者trick,所以最低的要求是要理解這些模型適用場景以及局限性，適合的數據規模
砌磚按照圖紙正常情況下能完工，因為砌磚是典型的勞動密集型工作，如果認為軟體也是一樣，則是非常愚蠢的想法。實際上軟體開發本身是一個複雜適應性系統。在這一類系統中, 可預測性降低，不確定性增加；不存在一個項目，只調用API就能夠按時交付；面對這類系統，最有效的工作方式是探索-感知-響應。相比原砌磚工人，市場之所以給程序員更好的待遇，其本質原因是編程需要程序員的探索-感知-響應的能力，其實也就是學習能力。只願意調用API解決問題是程序員對自己的否定。
如果一個士兵只願意服從命令，而不願意站在將領的角度去看問題，去從戰場中學習，他永遠都無法成為一個將軍。同樣的連演算法都不願意去學習的程序員，如何能夠在遇上實際問題的時候找到思路？不知道SSL原理的情況下也許用開源框架實現HTTPS，但開源框架不會告訴你，證書如何存放，多少位秘鑰當前情況下是安全的。如果人人都這麼想的話，程序開發這個行業不會用明天。
不好奇，不學習，憑什麼你比砌磚的待遇好？
拿自己舉例。
之前實習，公司在解決問題時使用的是CRF，由一位同事找到的CRF++實現了。後來，需要把這個項目部署到伺服器上做成一個在線的持久化服務，並且增加一個相同樣本加頻數參數，做批量處理的功能，哥們不會改不了代碼。我看了一周代碼和論文，最後決定改寫iitb的Java版的CRF，花了10天改寫了IO模塊和核心計算模塊。現在，他還在那家公司繼續最NLP和一些繁瑣的重複勞動，我去別家做深度學習了???
沒有覺得他那樣不好，關鍵看樓主是想要什麼。如果不求甚解，就可能會在實際問題時遇到瓶頸。這個應該和你的需求有關，如果只是需要一個功能，自然不需要了解太多。但是，如果需要作為產品的一部分發布，那必然要花時間進行源碼質量的測試評估和實現思想的分解，畢竟在未來的版本中，這部分開源代碼可能成為產品的軟肋。從個人成長的目的上來講，熟練使用開源工具只是level1，level2則需要你理解設計者當年的思考路徑。而最有意思的其實是level3：相同的問題交給你，你的解決方案是怎樣的，和現有的工具相比，牛逼在哪裡傻逼在哪裡;現有的解決方案的下一步的改進方案在哪裡;我有沒有能力做到更好。對！魅力的核心是思想的堆疊以及pk，而且還是跨越了時間的。
這也是在收入普遍不高的今天(沒股票)，我還能在華為待下去的少數的幾個原因之一。
找個工程師優化演算法的工資還不如直接買個大內存大ssd來的效果好。
個人理解：往低說，就是普通工人與工程師的區別，往高說，就是普通工人與藝術家的區別.如果真的完全看不到一個演算法的美的話，真的挺累的.另外，萬一人家的工具有bug呢？萬一你要改改才能適應你的情況呢，萬一精度達不到要求你想改進一下呢？有精力的話，多看看還是不會錯的...沒精力的話，那就真的只能靠人品了.
這個CNN功能明天下班前灰度測試
如果你的目標是當個老老實實的理工男走學術道路或者在工業界靠技術吃飯做牛做馬，那麼最好還是把演算法弄明白一些。
否則的話，技術就是個工具，會用就行。真把茴香豆的茴字有幾種寫法都搞明白的，這一輩子就只有被人管的份了。把精力多花在和人交流聊天讓別人知道你在幹什麼想什麼以及做presentation向領導彙報忽悠吹水上遠比你一個人琢磨演算法來的有價值的多。抬頭往上看看那些可以管到你的人，有幾個是技術或者演算法很牛逼的？
中國的傳統的理工科教育一個不好的地方就在於教出來的人過分注重技術等所謂的「真本領」，只會幹活，不會說話，不會和人交往，看到陌生人害怕走開，上台講話紅著個小臉很緊張結結巴巴，開會的時候不積極主導會議進程，頂多說一些自己做的東西沉默冷場了，對別人講的東西和發出的信號也不能給出積極的正反饋。
日常生活中也挺無趣，駝背戴眼鏡一把年紀了還穿的像學生一樣，被challenge了照樣一棍子打不出個屁來，很是讓人討厭。
推薦閱讀：
※如何用TensorLayer做目標檢測的數據增強
※Coursera吳恩達《卷積神經網路》課程筆記（3）-- 目標檢測
※分分鐘帶你殺入Kaggle Top 1%