一篇文章的解釋權屬於作者還是讀者？

01-28

這是一個獨立成型的問題，但我問這個問題，純是為了解答在這個問題下不少討論者的疑問：《道德經》講了什麼？為什麼它廣受推崇？ - in nek 的回答。
當然我可以直接在那個回答中補充，但作為一個程序員，我不喜歡在一個函數或者一個模塊中補充同級別的其他獨立論述……所以，讓我在這裡開一個獨立的主題吧。因為這個確實也可以作為一個獨立主題來討論：）

【介紹】

在下面這個討論中：《道德經》講了什麼？為什麼它廣受推崇？ - in nek 的回答，不少人在糾纏《道德經》的版本問題，某個字是什麼含義的問題，等等。我在寫這個回答的時候就知道這種事情肯定會發生的，因為這正是某些人越不過去，無法理解老子的原因。

所以我在整個回答的開頭，放了一個「我操」的故事，但那個故事太簡單了。在那裡只能這樣，因為那個主題不是這個，在那裡展開會削弱表達，但這個故事其實是很值得展開來說的，我在這裡展開。

在那個故事中，我說了兩個情節，第一個是，如果這個人死了，你問都不能問，而他僅僅說了一句話，無法互相參照，你無法憑著兩句話理解他是什麼意思。第二情節是，這個人被救回來了，你問他當時什麼意思，他的回答是他的第二遍意思，那個意思也不見得真正是他的意思。

所以，在一般的語言交流中，當一句話說完了，這句話的解釋權屬於讀者（作者是其中一個讀者），而不是作者。但請你也要注意了，這個「讀者」，到底是一個「讀者」，還是一群「讀者」，這也要問你的上下文是什麼了。因為整個解讀，不過是一群人在建共同的名稱空間的過程。一群傻子也可以建出他們自己的《道德經》名稱空間，只是他們見不出邏輯，而且不能用來解決問題而已。

【共識】

對此，我們有必要簡單探討一下什麼是「共識」，

正如我在那個故事的描述中提到的，語言的表述是永遠都存在歧義的，無論你用世界上哪種語言來描述。這正是「道可道非常道，名可名非常名」的原因。因為每個名都需要用名和道來解釋（道本身——無論是類型還是變數——就是名），我們之所有能有共識，是我們可以「匹配」。我看到一個藍色的東西，我說這是「blue」，你看到的其實是一個我認識中的淺藍，但你接受，因為下次看到一個類似的東西，我還是說「blue」，你是覺得可以接受的。假設你的感光系統很奇怪，對光線頻率的感知是離散的，藍和淺藍對你來說是完全不同的東西，反而和淺紅非常類似，我們就無法匹配了，這個名就無法在你我之間存在下去。

我們人和人之間今天可以擁有的共識，是一系列匹配，淘汰過程中形成的，有些東西我們覺得順理成章，其實不那麼順理成章的。而且很多共識其實是不能細化的，就如同前面那個藍和淺藍的認識，交流下去我們的共識就可能不同，你覺得用頻率可以讓我們有共識，那只是我們在「數字」上有共識，不是我們在「藍色」上有共識。在知乎上，都說「好人都有好報」，我們兩個可能就覺得對方是知己了，下一步交流，原來你說的好人是「不做犬儒，我要真普選」，我說的好人是「來了就是深圳人，來了就當志願者」，我們可能就開始拍桌子，把手指頭放在對方的腦門上了。

如果你可以理解這一點，你就應該明白，那個「我操」確實是無法最終解釋的，包括作者自己都不具有對它的最終解釋權。正如我說的，你把他救回來，問他，「你到底當時什麼意思？你丫的說錯了打死你」，他可能就給你解釋「我當時的意思就是感謝上帝，沒有別的意思，Wo是火星文中感謝的意思，Cao是潘多拉星球上帝的意思」，你能怎麼著？

所以，當我去解讀一個完整的文檔，其實我不太在乎在經過漫長的歷史中經過了多少傳遞的損失和修改，我關注的是它的「架構」，就是它在歷史長河中被完整保存，持續不變的那個含義，那些什麼哪裡出土了什麼真本，然後什麼顛覆什麼人的世界觀了，那種東西我也不是不知道，但我看這種東西仍是把它看作是構架下的某種變體，除非你能在那個之外建出合理的構架模型來，我還有可能正眼看你一下，否則，等文字研究人員多扭幾年（並把概念傳遞到我們這些交流對象中）再說吧。這就是「眼前此刻」的其中一個解釋。

用眼前此刻為基礎來看世界，可能是我們能達成的最好的不被洗腦的狀態了。

【架構】

這裡談到架構，就要涉及到我的獨特名稱空間了——其實，我是一個軟體架構師：）

希望讀者可以忍耐一下，我盡量說得通用一點，但願這個可以類比到您的行業。

什麼是軟體架構？有一本很出名的軟體架構的書（好像叫《軟體架構編檔》吧）裡面有一個很精彩的描述：軟體架構就是架構師眼中的設計。

這句話非常精準，但對於外行來說，這句話說了等於沒有說。讓我換一種說法，比如我設計一款產品，6月上市，這款產品每個特性都要完成了，你才能往外賣吧。然則，實現這個產品的所有技術，方方面面，就稱為設計（區別於生產，因為生產是設計結果的多次重複）。但這個產品完成後，它只是1.0，以後我還要升級的，明年6月，我可能就出一個V2.0，V2.0就不會從頭開始了，它是基於1.0的技術進行改進的，對於軟體來說，這一點表現得更徹底，因為這個修改會直接發生在V1.0上。軟體的生產最便宜（僅僅是編譯，甚至不需要編譯），設計就是軟體的代碼本身。

作為一個同時要負責V1.0, V2.0, V3.0這樣一個持續的開發過程的人，我就要從1.0開始，就要考慮到對未來的變化，而在我的軟體的實現的時候，我就能預期什麼樣的變化是容易的，什麼變化是困難的，困難的變化就會成為未來的約束，這些東西就是我的軟體架構。而軟體架構師的工作，是對未來做出準確的判斷，確定把「約束」建立在什麼地方，接受什麼作為約束。

這個概念應該在每個行業都是存在的，比如建築師看到一個房子，他會知道哪裡是承重牆，哪裡是普通牆，哪裡可以打掉，哪裡可以組合成一個房間。在考慮這個問題的時候，他們眼中沒有了房子，只有這個房子的架構，裝修的時候他們就可以玩出千變萬化來。又比如企業家在組織一個公司的時候，開始的時候可能要一個人同時負責研發和銷售，但他考慮清楚了商業模型，知道什麼東西應該自己做，什麼東西外包，什麼東西外購，這樣他這個公司發展過去，部門組織也是可以有控制地發展的。其他搞政治，搞娛樂，都是這樣，我們總是需要在發展和生存間取得平衡。而不懂做事的人，只能看到眼前的東西，總在問為什麼不這樣，為什麼不那樣，那樣不是更合理嗎？他們不明白，你以為我不知道什麼是合理嗎？合理是要成本的好不好？

但是，你們要注意，架構很大程度上，不是被設計出來的，精巧的架構往往生命力不強。因為你的腦子再強，你也掌握不了細節，控制不了世界。掌握不了細節決定你無法做出完全正確的判斷，控制不了世界決定了你不能保證計劃按設想運行。所以，架構師更多時候要接受架構離開自己的控制，或者接手別人的構架。架構師的能力就是用很短的時間內，從別人的軟體設計中發現這個設計的架構是什麼。

我的工作很特殊，我同時是消費晶元，IT晶元，專用設備晶元的軟體解決方案架構師，我為我們的晶元確定使用什麼軟體解決方案，判斷支持什麼方案的代價是什麼，所以我常常需要分析很多很多已經存在的開源的非開源的軟體代碼。在我眼中，架構早已經不屬於作者了，架構屬於它現在的那個樣子，是現有設計的一部分，是我在看待未來的時候，現有設計不可改變（或者改變的成本很高）的部分。

【結論】

我繞了一大圈，現在你們可以明白我在說什麼嗎？當我解讀道德經的時候，我採取的是我看軟體一樣的模式，我在解讀的是它的架構，一兩個字的含義，只要不對上下邏輯對齊產生影響，我只當它是個小bugfixing，無關緊要的東西（從投資角度來說），我才不關心呢：）

而我認為，一個「知識」，如果它能拿來用，我們關心的顯然是他被使用的部分，而不是者原始表達的部分。而一個「精華經驗」，顯然也是它被千百年「折騰」以後，流傳下來的東西，留下來的那些不變的東西，老子本身，已經毫無意義了。那時研究歷史這個角度的人的問題，不是我們這些閱讀求得益的人的問題。

初稿2015-4。 Kenneth-Lee。

答主有大智慧，希望看到關於定性書、識仁篇的解讀。

我把答主關於道德經的一系列回答全部列印出來了。看了一下午，感覺真有趣味。希望答主還可以繼續來點。