非洲傳統價值觀「Ubuntu」的意思是為「人性」，人的存在少不了他人的存在，以及彼此的信任。此時訊息的傳遞就變成重要的話題。
教育理論有一個針對英文教學方法的爭論：究竟是應該鼓勵學生多使用語言，還是應該不時糾正學生的錯誤文法問題呢？有一派認為與其多使用語言，讓訊息成功傳遞才是更重要的課程。
文章架構要清楚，要邏輯，要循序漸進。別人能讀懂你的文章，那麼你的文章才算是寫的好。
本次呢，要來談作為終端使用者的我，在寫科技類文章，介紹新科技的時候，應當避免訊息無法傳遞的問題，並探討改善方案。
（此處的科技類文章可以延伸到科普文章、技術文章上）
1. 了解文章的價值#
對不起讓我自吹自擂一下。我不做新聞報導的跟風貼文內容，我絕對不會寫「近日根據XXX報導，YY公司怎樣…」的時效性文章，那種的po在社群媒體就夠了。主力文章要寫鐵定是偏review性質的文章，包含我的使用心得在內的，並可能隨時效變動。
考慮到SEO的問題，標題和行文絕對不做賤自己，認為寫的東西總是有價值的，所以會盡全力寫並適當加入個人想法，以求有風格。再稍微做些關鍵字研究來調整內容，不會完全當日記處理。
可是，要如何防止文章變成太geek的自言自語、只有技術圈宅宅看得懂，這是另一個課題了。
2. 防止「geek般的自言自語」#
英文的geek可以指電腦奇才，近年來較多人使用的是tehc-savvy一詞。那麼不熟科技的人自然是non-tech-savvy了。
我喜好開源軟體，雖然熱衷發掘各種Github開源專案並撰文介紹，老實說太geek的東西我也很難下筆的。除了我自己看不懂外，更多的是讓文章變流水帳的機率大增。
比如：純C語言實作的 llama.cpp V.S. 大型語言模型整合前端 Serge，那麼我是偏好研究後者方案的。因為對我們這些不直接參與程式開發，而是拿來用的終端使用者來說，能馬上「使用」的東西自是比較有價值的了。
回到剛才說的，如果寫的文字太技術性，文章開頭都是「XXX是一款幫你OOO的軟體，感興趣的可以下載看看。」那麼自己也會感到千篇一律，讀不下去，太多的科技名詞(jargon)容易讓人摸不著頭腦，乾癟的宣傳文字也只能吸引到圈內人注意。
真的看過太多文章這樣介紹一種新技術/新軟體的呢，可你是在寫部落格，不是新聞報導好不。
撰文的時候要知道我不是在寫技術文件，如果只有一篇文章的篇幅要講完一個軟體的用法和優缺點，卻鉅細靡遺的列出所有選項，供使用者選擇這個選擇那個…到頭來只是混亂。如果只是教科書的寫完安裝流程，那麼他們按翻譯機去看原文不就好了？我的價值，難道只是充當訊息搬運工而已？
我不是在做論文研究，如果在軟體安裝前花大篇幅介紹某個軟體背後使用的程式語言、跑分性能比其他的要好屬於過當了…讀者知道這個幹嘛？為什麼不要一句話「這個軟體屌打A軟體」帶過就好了。如何讓枯燥的數據變成有趣的文字敘述，是我一直在訓練的行文技巧。
比起軟體背後的技術堆棧(stack)，我更喜歡讀軟體開發者的製作動機，以及背後故事。這樣的話吸收後作為我文章的素材，可以增添趣味，讓我們不用執著於技術的枝微末節。
務求在這其中追求平衡，想知道每個參數用途的去看文件，我喜歡先弄常用的就好，起碼要用最短路徑讓軟體成功安裝，在電腦上動起來。如此一來作為終端使用者，我們才可以開始東摸西摸，從實際使用中去學習、去試誤軟體。
得特別強調，這種「先斬後奏」是我個人經驗的用法啦，從錯誤中學習。有些人倒喜歡先全部搞懂背後技術，才敢使用新軟體。
畢竟軟體重點是要用的，不是研究的。
為避免自己文章變成說明書一樣的操作手冊，我不吝於加入一些個人想法與搞怪元素，讓文章有生命力，有獨到之處，而非那種迅速消逝在社群媒體動態牆的一個短篇消息。
3. 我認為太geek的例子#
例子1，很多AI聊天程式，在 Text Generation WebUI這種大一統方案成熟前都是要打指令的，這種我推不下去。就算不是UI設計師，如果你連WebUI都懶得做，那就不該使用此專案了。
Stable Diffusion WebUI也是一樣，如果沒有網頁界面誰敢試呢？很多開發者提出了一鍵安裝的方案，讓使用門檻大大降低，如果沒有破壞自訂性的話，那我也確實該使用那些方案。
例子2， ReDroid，這個專案很棒，可是偏原型(prototype)階段，無法跟商業Android模擬器競爭，想當雲手機DIY成份又太大。你看我一篇文章裝那些東西花好多時間了呀，轉譯器、GAPPS都要自己安裝。連我自己在推廣ReDroid方案的時候也用了太多術語導致異常艱深。
ReDroid開發者基於各種因素無法提供開箱即用的方案，在回覆issue的時候總是給出工程師一樣的各種選擇。開發者確實博學，可沒有直接解決問題，就是個問題了。
我講個比喻：ReDroid vs Android模擬器的差距，好似Arch Linux vs Ubuntu的差別。ReDroid有潛力，可是難以上手。
軟體開發者應該照顧到終端使用者的需求，考慮到推廣一種具有潛力的方案，務求讓使用者可以開箱即用才是最好的，而不是每一個步驟都要編譯東編譯西的，看了就煩。
我沒有譴責ReDroid做的不好，這些類似原型的東西也不是壞事，其作為日後更強大的軟體基石，其貢獻也是不可磨滅的。
4. 改善#
因為我不是專業開發者，很難給出具體步驟建議，只能在這裡講一些空話，甚是抱歉。
我可以理解工程師總是得追求精確的解決方式，以達到正確的途徑。所以程式部份很強，但對外溝通又需要另一番功夫，有的工程師不擅長經營宣傳，在專案README裡面花太多篇幅說明技術性的東西，就讓他們的專案變成生硬的理論磚頭屬實可惜。然後被同樣很geek的同業看到，在轉述的時候也寫的很geek，好像沒什麼強化宣傳的效果。
若是流水帳的報導新科技東西，那麼我能期待訊息成功傳遞嗎？或許讀者看到了新資訊，但是因為沒有太多值得咀嚼的部份，難以進入大腦的長期記憶區域。這個時候，個人風格的文章就顯得重要，可以給人留下印象。
開源專案稍微做的有點起色的，應該要逐漸轉向把Quick Start、對終端使用者有益的內容放在前面，之後再討論技術性的東西。即使是推廣新技術的文章，也應當如此。
切勿妄自菲薄的認為本專案僅是學術研究的東西！No！如是所有的信仰使人渺小，既然有好的點子為何不讓更多人知道呢。
不妨學習「麥肯錫30秒電梯理論」，想想自己的專案有什麼優勢，盡全力在README列出優勢，做好宣傳工作讓人快速上手，這樣不只可以吸引知名度，程式碼貢獻者也會自然來了。
作為終端用戶，要寫技術文，在寫文章前先列出大綱便是最好的方式了，方便抓重點。切勿在且寫文章的時候當作個人筆記，而導致流水帳無重點。就算是筆記也要好好抄寫才有給人看的價值吧。
我個人喜愛提供一鍵安裝環境的程式開發者，讓使用者可以快速嘗到軟體的甜頭，而不是先嘗盡苦頭。畢竟不是每個人都喜歡玩vim自定義，多半會先找個預設設定檔開始用。如此一來對終端使用者方便，對推廣者也有好處。
我也得自我批判一番，因為長期使用Linux，在寫文章的時候，安裝軟體章節忽略了很多人連英文都看不懂，更別說安裝檔的下載了，所以有時候軟體安裝過程太簡略也是個問題。
這個時候就只能多得一點指示了，可是我真不想寫到那種連下載資料夾在哪裡都要明確告訴讀者的低階程度啊。這個尺度得自行拿捏，知道目標讀者的大略程度在哪裡，才有辦法寫出大多數人可以接受的文章。
5. 結論#
開頭說了，非洲傳統價值觀「Ubuntu」是「人性」，有你才有我。那麼在最後，我覺得可進一步延伸為「我在乎你能不能真正了解到我的想法」「訊息有沒有正常傳遞」這樣我們才能互相理解，達成更好的目的。在撰寫科技文章的時候也是這樣，如果讓訊息成功傳遞到對方，那麼這篇文章就不只是電子訊號，而是進到人們心坎裡的靈魂波動了。