過年閒來無事，研究了幾款低程式碼平臺，選擇了其中一家，做了個小DEMO。本文將基於我虛構的“幼兒園健康上報系統”為例，演示如何用低程式碼平臺快速搭建一套應用系統，並介紹演示國內外一些知名的aPaaS產品，例如Mendix、Outsystems、宜搭、明道雲，試圖探討低程式碼平臺在產品設計上的核心本質，從而讓大家對低程式碼有一個更直觀的理解。在案例開始之前，我們先聊聊基本概念。
01 低程式碼是什麼
低程式碼平臺是繼中臺之後又一個火爆的話題，實際上低程式碼本身並不是一個新穎的話題，也不是最近才有的技術突破和創新，而是存在了十幾二十年的概念。早期的大型管理軟體套件，都有類似於可拖拽式的快速開發平臺，方便技術人員不用寫程式碼，快速實現某些基礎功能。
低程式碼雖然現在習慣被稱作aPaaS，好像看起來是一種PaaS，顯得和SaaS有密切關係，但大家需要認識到，低程式碼開發平臺並不是因為SaaS才有的概念，而是遠古時期就已經存在了的。
簡單來講，低程式碼平臺是一套期望透過拖拽配置，就能實現一套業務型軟體系統的開發平臺，並能無縫的部署上線執行。在這個過程中，當然也允許編寫部分程式碼，但更重要的是，大量基礎性的編碼工作，都可以被低程式碼平臺快速的自動化實現。
低程式碼的第一個應用場景，是為了幫助成熟的軟體產品，低成本的支援個性化需求，提高開發速度，甚至做到拓展客群。
例如，很多成熟商業軟體（包括私有化部署的商業軟體套件以及SaaS形式的產品），期望透過低程式碼平臺的建設，加強產品擴充套件能力，更好、更快的服務客戶，以及與 ISV協作，將產品的目標客群拓展到更廣泛的領域和行業。
在這種情況下，低程式碼平臺是低成本高效解決個性化需求終極方案。此時，低程式碼的目標使用者可能包括工程師、實施顧問。
國外的SAP、Oracle、SalesForce，國內的用友、金蝶、北森、銷售易等，都有基於自身軟體產品作為基礎核心的低程式碼解決方案。
低程式碼第二個應用場景，是為了幫助甲方企業，低成本快速搭建全新的應用系統，尤其是讓不懂程式設計的業務人員也能自主實現，從而讓企業以更低的成本享受數字化技術賦能業務的好處。
實際上，在企業中大量的應用系統都是流程型的，對於邏輯相對簡單，流程鏈條並不複雜的業務場景，找套裝軟體支援大材小用，找外包開發獨立系統成本又高，那麼低程式碼平臺可能是一個不錯的選擇。此時，低程式碼平臺的目標使用者可能包括甲方企業的業務人員，或者IT人員。
國外的OutSystems、Mendix，國內的明道雲、氚雲，都屬於這種情況。
需要留意的是，目前國內有些做報表平臺、流程引擎的廠商，為了蹭熱度，也都稱自己是低程式碼平臺。嚴格來講，這些廠商提供的產品能力，只是完整低程式碼平臺所需具備能力的子集，並不能算低程式碼產品。
說了這麼多概念，想必大家對低程式碼的印象依然比較模糊。
接下來，我將透過一個案例，帶著大家去體驗一款低程式碼產品的使用。開始之前，還有幾個問題需要和大家強調：
1.低程式碼只是應用系統建設執行層面的工具，而軟體產品設計中的思考方式和建模過程才是核心，所以我們的案例會花一部分筆墨講述設計過程，理解後再去學習應用低程式碼平臺就會簡單很多。
2.我選擇了明道雲作為演示產品，第一是因為他比較容易上手，第二是因為明道雲的老闆任向暉大佬平日喜歡寫公號做分享，我很喜歡他的文章，為了致敬，因此選擇了明道雲。需要宣告的是我和明道雲沒有任何關係，甚至試用期間連銷售都沒加過，試用期全程都是我自己對著幫助手冊學習操作的。
3.明道雲的學習我大概用了一個小時（主要是看幫助文件），具體上機實操將案例中的功能實現大概用了兩個小時，整體還是非常好用，容易上手。但這也可能是因為我以前做過研發，對很多基礎概念都比較容易理解。
好了，接下來，讓我們進入案例。
02 小豚鼠幼兒園的低程式碼應用
需求調研
李校長是小豚鼠幼兒園的校長，最近她遇到了一個煩心事，根據教委統一要求，疫情期間，需要家長每天上報小朋友的健康狀況，學校統一管理，但是教委又沒有提供統一的技術支援。
李校長的侄子小王是一名B端產品經理，在閒聊中得知了李校長的難題，心思一動，問道：
小王：姑姑，您說的這事兒，或許我能幫上忙，做一套軟體系統，就可以很好地解決您的問題！
李校長：真的嗎，那太好了，但是我們沒有很多預算啊！
小王：不用花您一分錢，我幫您免費做，不過我想先了解下您對這個業務管理的訴求和期望。
李校長：多謝啊！我的訴求很簡單，就是讓家長們每天打卡，如果有健康異常的情況，我能第一時間收到提醒，還能讓老師們去跟進，看看到底啥問題。另外，就是最好能有一些實時報表，讓我看到最新的健康上報情況。
小王：得嘞，我瞭解了，這事兒交給我了，我幫您設計一套操作的流程，和支撐的系統，免費給您用！
瞭解了大概的背景後，小王開始構思這套給小豚鼠幼兒園使用的幼兒健康上報系統的設計方案。
李校長：太棒啦，期待！
產品概要設計
小王瞭解完基本需求後，開始構思這套系統該如何設計。首先整理下這套系統涉及到的利益方，分別如下：
校長：業務決策人，系統使用者，希望系統能支撐教委的健康打卡要求，並管理好打卡業務。老師：業務執行者，系統使用者，需要管理班級和學生，安排打卡，跟蹤體溫異常的情況。家長：業務參與者，系統使用者，需要完成每日健康上報打卡工作。雖然業務本身過程很簡單，但因為畢竟是一套從無到有搭建的管理系統，有些基礎資料準備工作需要完成。小王思考了一會兒後，繪製出了一份簡明的業務流程圖，如下。
可以看到，期望家長能打卡，有些基礎資料要先維護好，根據常識，需要維護包括班級資訊、學生資訊，而打卡動作是針對學生的，因此要對學生關聯打卡資訊。另外需求中提到了，如果打卡體溫異常，需要有老師跟進，我們考慮生成一個待辦任務分配給老師，這條待辦任務關聯在異常的打卡記錄上。
對業務有了以上分析和思考，我們可以繪製出業務背後的ER模型圖（領域模型），如下圖。
每名老師可以管理多個班級，每個班級只能有一名老師管理。每個班級可以有多個學生，每名學生有多個健康上報記錄（打卡記錄），每個健康上報記錄可以產生一條體溫異常跟蹤記錄。
這些抽象出來的實體，是我們要設計的這套健康上報系統的核心，因為打卡（健康上報）的過程，實際上就是對這些實體資料做增刪改查而已。
產品細節設計
接下來，我們基於流程圖，來思考系統落地執行的頁面流轉圖。
校長管理班級，需要有班級的列表頁、詳情頁（帶有編輯功能）。
老師管理學生，需要有學生的列表頁、詳情頁（帶有編輯功能）。
家長上報健康記錄，需要有健康記錄填報頁。
老師查閱健康打卡記錄，需要有健康打卡列表頁。
老師跟進體溫異常情況，需要有提問異常任務的列表頁、詳情頁（帶有編輯功能）。
除了這些頁面級別的操作需求，還有一些業務規則需求，例如：
如果健康上報體溫異常，自動生成一條待跟進任務，傳送給該學生班主任，並推送訊息給校長。
總之，我們會發現，涉及到業務運作的功能頁面，主要就是ER實體的列表頁、詳情頁（建立編輯），並且，不同的使用者對不同頁面以及不同的資料具有不同的許可權。
經過整理分析，我們可以列示出系統涉及到的相關頁面，以及許可權表如下（此處僅僅是簡單示意，後邊在明道雲中我們會展示更加全面詳細的許可權設計，包括資料許可權的管理設計方案）：
經過以上分析，雖然細節還不完備，但我們對“幼兒園健康上報系統”的設計思路已經瞭然於胸，接下來，我們直接進入低程式碼平臺的開發演示環節！
低程式碼實現——透過工作表定義資料實體
接著，我們針對ER模型中的四個實體，分別建立工作表，下圖所示是建立班級實體的工作表編輯頁面。
工作表是明道雲的概念，所謂工作表，實際上對應著ER建模中的實體，工作表中的相關控制元件，定義了實體的欄位。例如班級表單中定義了自增長的“班級ID”，字串型別的欄位“班級名稱”，列舉欄位“狀態”等。
透過表單來呈現出實體，是一種容易讓人理解的設計方式。而實體背後的本質，是所謂的“物件”，以及最終會轉移成資料庫的表。在有些低程式碼平臺中，則透過物件編輯器來定義管理實體，這是一種靈活性更強，但用起來更復雜的方案，在後文我們還會進一步介紹。
不論是表單編輯器，還是物件編輯器，原理是一樣的，管理的都是提煉出的實體。對於非技術人員來講，表單可能更容易理解接受一些。
在班級表單中，有一個“學生”的控制元件，是一種關聯記錄元件。因為班級和學生是一對多關係，每個班級可以擁有多個學生，所以在班級表單中，我們允許看到關聯在班級下的所有學生列表，這在B端產品互動中是非常常見的一種設計形態。
實體之間所謂一對多、多對多的關係，體現的是多個表之間的關聯，在設計器中可以輕鬆地定義班級和學生的一對多關係，如下圖：
實現了關聯後，表單和表單之間建立了連線，在詳情頁（單條表單資料的呈現頁面）展現上，也都會完美的自動完成。例如下圖是針對某一條班級資料的詳情頁（PC版本）：
aPaaS平臺都會自動完成PC版本和移動版本的適配，並且格式都是可調整的。例如上圖呈現的是PC版的班級詳情頁，下圖則是移動版本。
低程式碼實現——透過檢視編輯器定義資料列表呈現
接下來，我們依次完成“學生”、“健康上報”、“體溫異常跟蹤”三個實體的表單配置。下圖中，橫排的“校園管理”、“校長控制檯”，可以理解成我們針對系統配置的一級導航，豎排的四張表單，表示歸屬於某個一級導航，而每個表單在右側主區域配置的列表檢視，就是二級導航選單，如下圖針對班級的表單，定義了“全部”、“生效中的班級”、“已畢業的班級”、“我的”四個列表檢視，也即“校園管理”一級選單下的四個二級選單。那麼，什麼是列表檢視呢？
工作表只是定義了實體的具體欄位，如何將實體的列表資料呈現出來呢？例如，如何將“班級”列表資料以不同的展現形式呈現出來呢？這就需要檢視編輯器了！
在檢視編輯器中，可以定義實體對應的多條資料的列表化呈現，包括列表資料預設的篩選條件，預設的展示欄位，預設的欄位排序，都可以輕鬆定製。如上圖所示。
在大多數自研的B端產品中，列表頁（也就是檢視）是最常見的功能頁面，而一般情況下，這類頁面都是硬編碼實現，而非透過類似於檢視編輯器這樣的前端元件實現。在成熟的軟體產品中，已經沒有列表頁的概念，都會透過檢視編輯器來處理，這樣就大量的簡化編碼工作。
如下圖，我們針對“班級”表單，定義了四個檢視，分別是“全部”、“生效中班級”、“已畢業班級”、“我的”，其中截圖呈現的是針對“生效中班級”檢視的預設搜尋條件配置，可以看到，我們設定了該檢視預設查詢條件，是“狀態”欄位為“教學中”的所有班級資料。
我們先前提到，在“班級”表單中建立了和“學生”記錄的一對多關係，在“學生”表單中，同樣需要有一個欄位，關聯了“班級”表單的“班級ID”欄位，從而完成一對多關係的定義。但是，如果我們希望在學生表單中呈現出所在班級的名稱，以及在學生檢視中呈現出所在班級的欄位，該如何實現呢？
因為在建立一對多關係式，我們只是定義了ID之間的聯絡，所以，如果想在“學生”表單中呈現“班級”名稱，必須做一個變數引入的特殊處理，在明道雲中，採用了一種叫做“他表字段”的設計方式，簡單講，就是把關聯表的某個欄位引入過來，進行展現，如下圖：
下邊的紅框，定義了ID之間的關聯，上邊的紅框，引入了“班級”表的“名稱”欄位，以便在“學生”表單和檢視中展現。
在其他低程式碼產品中，針對這類訴求的解決方案不太相同。嚴格來講，表單只是資料物件的外化呈現，根據軟體設計MVC的分層理念，資料定義和前端呈現要分層隔離，物件編輯器嚴格定義了資料實體本身，而如果在表單或檢視中需要做多表連線去呈現其他相關表的某些欄位，則是視覺化層面需要解決的問題。因此，在很多更復雜一些的低程式碼產品中，所有視覺化的部分，都是基於頁面編輯器來完成，和底層資料定義是互相獨立的兩件事。
因為明道雲的產品，為了在很大程度上降低使用者的學習成本，所以將資料底層的物件編輯器，和展示層的表單編輯器融合在一起了。
現在，我們來解決一個棘手的問題。
如果我們希望在學生檢視中，呈現出該學生的老師姓名，該如何做到呢？透過學生，可以找到所在班級，但是，負責班級的老師是誰呢？如何定義呢？
一種做法，是針對“班級”表單增加一個欄位，可以關聯老師的賬號，完成老師和班級的關係對映。
在明道雲，我們採用了另一種取巧的方式，需要由校長，將每一條班級資料的擁有者，修改成具體的老師賬號，如下圖，圖中“王老師”，是一名角色為“老師”的獨立使用者。
透過這個動作，實現了對班級負責老師的分配。接下來，再利用前邊提到過的“他表字段”功能，將這個欄位值引入其他表單物件中。
如此一來，所有針對某個班級下邊關聯的學生，以及針對學生關聯的健康上報記錄，我們就都可以追溯到所負責的老師了。
這對下一個需求的實現至關重要！
低程式碼實現——透過流程編輯器定義業務過程和事件
我們回憶下，現前有這樣一條需求：
如果健康上報體溫異常，自動生成一條待跟進任務，傳送給該學生班主任，並推送訊息給校長。
這個需求該如何實現呢？這就用到了aPaaS平臺中非常核心且重要的流程編輯器功能，可以說流程編輯器是低程式碼平臺的靈魂！
將上述需求，進一步準確描述：如果新增或編輯“健康上報”表單資料時，其中的“體溫是否正常”欄位選擇了“否”，則自動生成一條狀態為“待跟進”的“體溫異常跟蹤”資料，併發送訊息給校長，以及該學生的老師。
在低程式碼平臺中，透過流程編輯器，來實現類似於以上這類帶有自動化觸發執行，以及多表資料自動更新的功能。
我們來到流程編輯器，建立“異常體溫上報觸發跟進任務記錄”流程，如下圖：
在圖中，我們設計了三個流程節點。
第一個觸發節點，定義了當“健康上報”表單在新增或更新資料時，如果發現“提問是否正常”欄位等於“否”，則往下執行。
第二個節點，當發現體溫異常時，建立一條“體溫異常跟蹤”資料，分配給上報記錄學生的老師。
第三個節點，傳送應用內訊息給校長和老師，提醒處理，效果如下圖：
由工作流建立的資料，建立者欄位顯示為工作流，如下圖：
流程編輯器，不是簡單地工作流引擎，我們一般理解的工作流引擎，例如審批流，只是針對單一資料物件的多節點處理。而真正複雜的流程編輯器BPM，需要在流程中對不同資料實體進行復雜處理，這也是很多B端業務的核心處理邏輯和過程。
當然明道雲的流程編輯器功能很多，如下圖，我們不再贅述。
截止現在，還有個核心功能，我們沒有實現。家長如何上報資料？
一種辦法，是針對每個家長開通一個賬號，賬號和學生做關聯，家長登入系統，提交表單時預設會提交相關學生的“健康上報”記錄。
另一種辦法，是將“健康上報”的表單公開出去，任何人都可以提交，這樣做的好處是不需一個一個維護家長賬號，壞處是因為系統無法識別提交人和對應的兒童，需要提交人手工從學生清單中選擇學生，操作比較繁瑣。
如下圖，我們將表單設定了公開連結。
低程式碼實現——透過報表編輯器定義報表和儀表盤
走到這一步，涉及到業務流程的核心功能和資料表單都開發完畢了，接下來，我們需要給李校長配置她的管理工作臺，也就是dashboard。
透過類似報表引擎的功能，配置出校長的監控儀表盤，我們將其放在“校長控制檯”的一級導航下邊，如下圖：
該功能的使用，和經典的報表引擎相通，不再贅述。
低程式碼實現——配置角色、許可權
最後，我們進行角色、許可權的設定。
我們設定了兩個角色，“校長”和“老師”。
下圖是明道雲的資料許可權配置管理全貌。
可以看到，每個針對每個角色，設計不同表單檢視的檢視、編輯許可權，這是功能許可權。
甚至還可以針對具體的欄位設定更精細化的許可權，如上圖左下角視窗所示意。
完成以上配置，我們的低程式碼平臺開發工作就完畢了，明道雲的應用系統不需要釋出，配置後立即生效。所有使用者需要註冊明道雲賬號來使用配置好的系統。配置完成的應用沒有獨立的應用程式，透過訪問明道雲官網登陸後使用，移動版需要下載明道雲APP，登陸後進行使用。
最後給大家展示下移動版應用的截圖，這些都是自動生成的預設設計，沒有做過調整。
03 低程式碼平臺的本質
透過以上例子，相信大家對低程式碼平臺的能力已經有了一個直觀的感受。
軟體產品設計的標準結構是MVC模型，即Model（資料）、Controller（邏輯）、View（互動介面），低程式碼平臺正是通過幾個核心元件，完成了對MVC三層架構模型的支撐，對應著MVC模型，這三個核心元件分別是資料模型設計器（對應Model）、流程設計器（對應Controller）、頁面設計器（包括了報表設計器，對應View）。
資料模型設計器
資料模型設計，實現了對底層資料物件的定義。我們之前已經提到過，不同低程式碼平臺，對資料物件的定義實現方式並不相同。
資料模型設計器的第一種實現方式，是透過物件編輯器實現資料定義。
這種方式靈活程度最高，將底層資料模型和前端檢視分離，模型聚焦底層，檢視是視覺化的呈現。
國外的低程式碼平臺Mendix，國內的華為雲AppCube都採用了這種方式。另外大型商用軟體的低程式碼平臺也都採用同樣的設計，例如SalesForce、紛享銷客等。
下圖是Mendix的物件編輯器，在Mendix中叫做Domain Model（領域模型），實際上領域模型和物件編輯都是屬於面向物件程式設計的概念。嚴格來講領域模型和我們之前提到的ER模型並不完全相同，領域模型擁有面向物件程式設計的特徵，例如泛化、聚合，這些概念ER模型中是沒有的。
另外圖中展現的是Mendix的Windows客戶端版本，除了Web版，Mendix還提供了功能更加強大的Windows客戶端。經過簡單體驗，這套客戶端更像是開發整合編輯器IDE（程式設計師寫程式碼的軟體平臺）。Mendix本身的功能也非常強大，當然學起來也更困難。
國外另一個知名aPaaS產品outsystems也採用了底層物件驅動的設計，並且也提供了windows版本的客戶端，安裝後有一個step by step的tutorial，非常驚豔！整套IDE風格的產品化設計，也非常強悍，讓人印象深刻！
華為雲的AppCube貌似也是物件編輯器的設計方式，但因為我的試用申請一直未透過，所以只是透過幫助文件做了猜測，無法具體體驗，如下圖。
資料模型設計的第二種實現方式，是表單引擎。
對於設計人員來講，只需要把底層的資料物件，理解成Excel的多張獨立的表，每個表透過表單採集資料。使用者定義資料模型，只需要將表單中的資料採集控制元件定義即可。
例如下圖，是釘釘的宜搭的表單編輯器，設計思路和明道雲的表單編輯器類似。表單編輯器將資料底層設計和視覺化呈現打包在一起，對於非技術人員更容易理解，但也會喪失前後端分離的靈活性。
流程設計器
定義了底層資料後，下一步要定義工作流。對於業務型軟體產品，工作流是支撐業務運作的核心。業務執行的本質，就是一個個工作流的執行。
淺層次的工作流，是類似於Workflow這樣的審批流，是對單一資料物件的處理；深層次的工作流，需要能夠支援多資料實體在流程中的自動化處理。後者是低程式碼產品的核心功能之一，如果不具備後者的能力，基本上除了問卷表，什麼系統都搭不出來。
什麼叫多資料實體在流程中的自動化處理呢？比如說銷售型CRM系統，當線索的狀態變為已核實，就需要自動生成一條待跟進的商機記錄，並將商機分配給合適的銷售，同時還要生成對應的聯絡人記錄和客戶記錄，商機、聯絡人、客戶的部分欄位資料來自於線索實體。這個業務邏輯規則，就需要複雜的工作流編輯器實現，在這條自動化處理流程中，涉及到了四個實體資料的增刪改查（線索、商機、客戶、聯絡人）。
下圖展示的是Mendix的Windows客戶端版本下的流程編輯器。
下圖展示的是國內產品釘釘宜搭的工作流編輯器，感覺似乎過於簡單，只是一個審批流編輯器。也可能是我沒找到完整功能的配置介面？
頁面設計器
對於業務型軟體產品，主要功能是對資料的增刪改查，而涉及到的互動頁面，多數也都是底層資料物件對應的列表頁、詳情頁，除此以外，還包括報表、儀表盤，以及其他型別頁面。
對頁面設計器的設計理念，明顯體現出了不同低程式碼平臺的產品思路，整體來看，可以總結為兩類形態。
第一種，是純粹的前端頁面編輯器，包括了報表、列表、檢視、表單，都在這一體化的頁面編輯器中實現。比如Outsystems的頁面編輯器，如下圖。
可以看到，這是一套複雜的前端互動元件設計器，包括了類似於資料表集合Table Records的整合控制元件，也包括了表單控制元件Form，以及其他各型別控制元件集合，例如複選框Check Box，單選框Radio Button等等。
在這套編輯器中，操作者可以定義例如列表頁、詳情頁、報表、儀表盤各型別前端頁面。
再比如Mendix的頁面編輯器，也是同樣的設計思路，如下圖。
即便是dashboard，也是在同樣的頁面編輯器實現，如下圖是Mendix的dashbaord的demo。
低程式碼平臺的報表設計器元件，和傳統的報表引擎沒有太大區別，都是基於底層的資料，實現前端視覺化輸出，包括表格輸出和圖形輸出。
以上是第一種前端互動設計的產品形態，可以看出，功能強大、靈活，學習成本也比較高。
第二種，是大大簡化了的頁面配置器。
將不同型別的頁面，進行模板化配置，主要分為以下幾類。
首先，將資料物件和表單相結合，透過定義表單（Form），完成了資料物件的定義，同時也構建出了詳情頁。
其次，透過檢視編輯器這類元件，定義了針對資料物件的列表頁。
最後，透過單獨的dashboard配置器，完成類似於報表引擎的定義功能。
當然，低程式碼產品也會提供整合頁面的配置，但功能要比前邊提到的功能弱很多。
前文已經大量描述了明道雲的檢視編輯器，不再贅述。
下圖是宜搭的頁面編輯器，展示了對某個系統首頁的編輯。相對明道雲，宜搭的頁面編輯器更復雜一些，功能也更強大一些。
再例如，下圖是宜搭的報表編輯器
資料模型設計器、流程設計器和頁面設計器，是低程式碼平臺的核心，如果你理解軟體設計的MVC分層架構，就很容易理解低程式碼平臺的核心產品功能，以及不同的產品思路。
當然不同低程式碼平臺還有更多各具特色的強悍功能，有興趣的讀者可以進一步研究。
04 結語
可以看出，不同的低程式碼平臺，設計思路並不相同。
產品的易用性和產品的靈活性之間存在平衡和取捨。例如，對於資料底層，究竟選擇表單驅動的設計，還是領域驅動的設計？這兩者區別非常大，後者對於非技術人員，基本不可用，而前者雖然易於學習理解，但功能確實也要弱化很多。
因此，低程式碼平臺要明確目標使用者群體，究竟是給ISV或IT團隊使用的專業開發輔助工具，還是給非技術人員使用的強化版提效工具？前者更像是IDE的超級外掛包，後者更像是Excel + VBA的超強易用版。
對於B端產品經理來講，體驗下類似於明道雲這樣的低程式碼產品，對理解軟體設計很有益處，不論是表單，還是流程，還是許可權管理，所有核心的產品設計問題都會涉及到，並且能夠加深理解。
另外，萬一業務有個大型需求，研發沒排期，你3個小時就用aPaaS配置出來了，年度CEO特別獎不給你給誰呢！