如何正確回應攻擊文章

最近馮大輝（Fenng）從丁香園離職的事情鬧得沸沸揚揚。後來又出現一位匿名用戶，撰文指責馮大輝不是個稱職的CTO（該答案已被刪除）。後者迅速撰文駁斥（一個不寫代碼不稱職被扒皮的水貨 CTO 的自白書）。

然而，這篇逐條駁斥的文章，不得不說是錯失了焦點。一時之間，「Fenng不會寫代碼」的傳言甚囂塵上。一篇駁斥文是如何產生了這種效果的呢？我只能說：以錯誤的方式說話，只會越說越錯。我們不妨來盤點一下，那篇駁斥文錯在哪裡，正確的回應方式又該是什麼。

還沒有度過那篇文章的讀者，不妨先通讀一遍，再讀下文。

針對一篇攻擊性的文章所做的辯駁，需要始終注意以下幾點：

第一，辯駁不是和攻擊者吵架：

你不大可能說服攻擊你的對手，所以寫文章的目的絕不應該以說服對手為目的。一般的目的，首先是為了消除攻擊性文章的負面影響。也就是說，你寫的辯駁，應該是針對旁觀者或某些特定的旁觀者的一篇說明文，而不是與攻擊者的對話。這一點在行文取捨之中是非常重要的。

比方說原文這一段：

在丁香園寫代碼時間並不短，說一下我知道事情，確切的說是我理解的事實，因為也不是最早加入的，有些事兒是聽公司老程序員說的。（Fenng: 姑且當你真的是程序員。）

Fenng的這句評論感覺上是針對攻擊者說的。在旁觀者看來，這簡直毫無意義，反而讓人覺得Fenng認可了這個人確實是個程序員，反而有點Fenng自己要為這個人後面的說法背書的意思。

再比如說這一段：

後來也慢慢了解了，因為他在丁香園任職 CTO，一行代碼都沒有寫過，一行都沒有。（Fenng: 在丁香園寫代碼能證明什麼？哪一個 CTO 會自豪自己每天可以寫代碼？嗯，確實有，用自己標準評價別人的 CTO 都是這個心態。順便說過，在阿里做了五年技術，我也沒寫過一行代碼，從沒寫過。有人問，寫 SQL 不是寫代碼嗎？怎麼能算呢。）

「順便說過，在阿里做了五年技術，我也沒寫過一行代碼，從沒寫過。有人問，寫 SQL 不是寫代碼嗎？怎麼能算呢。」這句話雖說是自嘲，但如果是不了解情況的旁觀者會怎麼理解呢？是不是Fenng是在承認自己就是不會寫代碼呢？

這一段和接下來幾段的辯駁錯誤，導致「Fenng不會寫代碼」的傳言甚囂塵上。行文並沒有考慮到旁觀者——包括Fenng未來可能的投資人、合伙人、員工——有可能並不熟悉CTO的工作內容以及一些內行人的調侃。

所幸後來有人來替他擦了這個屁股，罷免了 「首席科學家」，替換掉了 Redis，改回了 MySQL 資料庫，雲管家項目才得以順利上線和運營。（Fenng: 替換 Redis 這種小屁問題，還用「有人」來解決嗎？「有人」當初還計劃這玩意兒要再找幾個人，替換現在的團隊，然後搞幾個月再上線呢。順便說一下，大概你也不知道當初為什麼做雲管家吧？不知道是誰的建議吧？不知道之前做了多久的規劃和調研吧？)

那麼，到底是為什麼要做雲管家呢？是誰建議的呢？做了多久的規劃和調研呢？更關鍵的是，這個事情的經過是被攻擊者用來證明「Fenng是個不稱職的CTO，技術選型和人員選拔全都是稀爛」，而這個論證，卻並沒有被Fenng的這種「和攻擊者吵架」的行文方式所駁斥。

和攻擊者吵架，與說服旁觀者，是兩種不同的事情。不要覺得在口舌上似乎戰勝了攻擊者就能讓旁觀者覺得攻擊者說的就是錯的。專註於與旁觀者溝通，才是應對這類攻擊文章的首要任務。

第二，不要被攻擊者帶偏節奏：

攻擊者有其組織論點和論據的邏輯。如果按照攻擊者的節奏去打，必然是事倍功半，很容易被帶偏。一個被攻擊者帶偏節奏的典型行為就是按照攻擊者的文章組織來逐條反駁。攻擊者的論點、論據組織順序，是為了證明他的觀點而制訂的。按照這個順序，顯然你無法很好地組織素材證明自己的觀點。

逐條反駁，往往是看完攻擊者的文章之後，在情緒尚未平復時倉促而寫，也是一種沒有經驗的表現。這種眉毛鬍子一把抓、按對方節奏來辯論的方式，最終會讓自己的辯駁喪失了焦點，讓人整篇文章看下來思緒混亂，不知所云。

第三，不要被自己的情緒驅使：

看完攻擊文之後立刻發表反駁通常是不智之舉。由於情緒的高漲，很多辯駁的言辭，其實是經不起推敲的。自以為反駁命中紅心，其實回頭看來完全脫靶。

如果說從大輝身上學到了點什麼，那就是如何噴人吧，怎麼噴同事，怎麼噴同行，怎麼噴很多其實和我們毫無關係的人和事，然後感嘆時間不夠用，應該把時間用在 「美好的事情」 上。(Fenng: 其實，我覺得「噴人」沒什麼不好，至少我沒有匿名，我公開的說。)

這一段Fenng本意可能是想嘲諷攻擊者的匿名攻擊行為，這是很情緒化的行為。尤其是放在這一段後面，簡直是坐實了攻擊者「無腦噴」的指責。

————————————————————————————

所以

第一，應該針對旁觀者來駁斥；

第二，要按照自己的立論節奏來組織文章；

第三，寫完辯駁之後，要站在攻擊者角度來攻擊自己的辯駁，尋找薄弱環節，並進行相應的修改。這樣反覆「迭代」數次，才能寫出比較好的辯駁。

————————————————————————————

那麼針對這篇行文混亂的攻擊文，應該怎麼寫辯駁呢？

攻擊的重點，其實只有一個問題：Fenng不是個稱職的CTO。

關鍵論點大致有三：

1，Fenng不懂技術，不寫代碼，也不懂寫代碼；

2，Fenng不關心技術工作，卻跑去帶產品；

3，技術問題都是由別人解決的；

其他諸如刷微博、噴人、培訓不足等等，全都是次要問題，完全可以一筆帶過，因為這些問題存在與否和核心論點基本無關。

所以立論的方向當然是應該以定義CTO的職責為核心的。攻擊方的論點2，可以直接被這一立論打掉。

這個時候顯然不能說什麼「一個 CTO 的工作怎麼評估？我是當事人不好說。」這是示弱的表現，會讓旁觀者覺得你真的不知道，或者你自覺辯駁無力。CTO的工作每一個公司都不是很一樣，所以一開始當然應該說：

「每個公司的CTO的職責是不太一樣的，因為每個公司的構架、傳統和業務都不同。這個職責範圍，是整個管理層統一協調而定的，所以並不是說CTO一定只能管技術工作而不能管產品工作。在丁香園，就我的理解，CTO負責了技術人員的招聘、技術預研、產品以及XXXXX這些業務。」

關於第三點完全可以說：

「到了丁香園這個規模，CTO就不見的需要直接介入到具體問題的解決過程之中了。技術問題往往需要專註。而在丁香園目前這個階段上，CTO其他工作比較多，比較難以專註在某一兩個技術問題上面。因此，在這個階段，當有技術問題需要解決的時候，CTO最好的做法當然是在業界找到合適的人，招收進來，解決問題，或將潛在的技術問題消滅在襁褓中。而我也是這樣做的。」

第一點論點更是不堪一擊：

「我當然是能寫代碼的，之前那些不能寫代碼的說法，都不過是自嘲或者朋友開玩笑。但是到了丁香園目前這個階段，CTO自己來寫代碼就有可能是添亂了。編寫代碼也好，code review也好，都有更了解代碼細節、更專註於開發的下屬來處理。早期公司的CTO還可能自己動手來解決問題，但到了丁香園現在這個階段，CTO在這些方面的職責，主要是招收、調配專業的人來處理這些問題。」

攻擊文章的其他細節雖然也十分狠，但太過繁雜，其實旁觀者是不會太在意的。一筆帶過即可。就算攻擊者再次撰文就這些細節進行攻擊，也可以從容應對。因為他放棄了本來的核心論點，至少在表面上已經是在核心論點上認輸了，後面的辯駁只要抓住這一點，攻擊者就沒什麼機會翻盤了，所以這些莫須有的細枝末節問題，根本無須辯駁，如果辯駁了，反而會模糊自己的論點，甚至和攻擊者陷入一些微小問題的爭吵，讓旁觀者覺得簡直是兩個人廝打在一起，並不好看。

所以，針對攻擊性文章的辯駁一定要有策略，否則反而可能坐實了攻擊者的論點。

推薦閱讀：