本文由作者?黃聯樵?于社區發布

長文預警，建議先收藏

查理的頭都要炸了。查理他開了一家公司，公司年后要擴張，找投資人要錢投資人不給，投資人說，你的公司有它的獨特條件，可以找政府拿獎勵啊，干嘛讓我白掏錢，自己申請去。

查理上政府網站隨便打開一個政策一看，確實是這么回事，只要符合條款里的各種條件，就能申請到政府的獎勵。然而這些網站太多了，政策也太多了，條款也太復雜了。查理不知道怎么找到自己夠格申請的政策，更算不出能拿到多少錢——查理當然不是做不到，只是，查理真的不大愿意做。這太費時間，也太痛苦了。所以查理就開車到附近的市中心散步去了。

走在市中心，查理的兩邊都是各種巨大又嘈雜的商場，他就在這條路上走啊走，突然看見了一個很違和的建筑。這個建筑周圍空蕩蕩的，只有平整的綠地。建筑本身也簡潔得有點奇怪，沒有門，沒有窗戶，沒有屋檐和管道，是一個標準的正方體，就像美術課里畫畫用的石膏方塊。

這塊大石膏上只有五樣東西。墻壁正面凹下去的刻字招牌，寫著“政策配對工廠”。墻上掛著一支筆和一張表格紙。從厚厚的墻壁里，延伸出來一條切割得非常平整的矩形開口，而開口的正下方是一個跟墻壁幾乎融為一體的，凸起的按鈕。

查理拿起表格，看到上面寫著：“在表格里勾勾畫畫幾下，然后扔進來，然后按按鈕，我們就能很快幫你找到所有符合你條件的政策，并且幫你計算出你能獲得的具體政府獎勵金額”——查理一看還有此等好事？馬上花了3分鐘把表勾好，然后就扔進那個非常平整的矩形開口里了……

這篇文章將為你闡述一個通用的問卷運算系統（在本文的預設中，一個政策配對和計算系統，然而它完全可以實現很多其它的場景）從后臺到C端的完整設計。

在講述上，我采用的思路是：一塊磚、兩塊磚，不斷砌在一起、不斷變得更大。如果你對后臺設計有興趣，你只要一直盯著我怎么砌磚的，不要眨眼，你就一定能看懂并學會。而如果你恰好對后臺產品經理有偏見，覺得不過是去堆砌一些復雜的頁面，對用戶體驗的貢獻近乎為零，不妨你也看到結尾，想一想如果只有前端產品設計，那么良好的用戶體驗還是否擁有存在的可能。

現在我們開始吧。

黃聯樵 / 微信：arubagod

1

門檻 / 款項門檻

如果我們不了解查理是否能辦理一個政策，就直接讓他填寫各種數據，這顯然會讓用戶付出額外勞動。對于一個政策來講，我們應該先讓查理回答一些簡單的選擇題，先保證查理能辦這個政策，然后再讓他填寫一些具體的數據來計算能拿到多少錢也不遲——這就是一個政策的門檻。

一個政策經常會劃分成一些具體的款項，它們的辦理條件是有差異的。例如，有一個政策是針對一些二道房東（科技創新載體）來發放租房的補貼，細分成針對孵化器的，和針對眾創空間的，這么兩個款項。

對于眾創空間來講，我們要求你是科技載體；而對孵化器來講，你除了是科技載體之外，你的工位數量還不能小于200個——那么“工位數量大于等于200”就是“孵化器”款項的門檻了。

所以我們要配置一些選項，把其中一些選項標注成這個款項的門檻。你也許會說，為什么圖中有兩個選項都符合這個款項？不能在文案上進行合并嗎？例如第一項是“工位數量300以上”，第二項是“工位數量200到300”，我們把它合并成“工位數量200或以上”不就剛好是這個款項的門檻了嗎？

這是因為一個問題設計好之后，是可以抽出來變成通用問題的。可能這個問題在這個政策里只考察你的工位是不是200以上，而在另外的政策里，200個工位和300個工位是區分對待的。后面在提到通用問題的時候會來介紹。

然后我們加上問題描述和一些操作按鈕，就形成對一個門檻問題的配置了。對了，這里的設計有一個坑，就是缺少了一個排他的“無”的選項。查理選擇了“無”之后，就不能再繼續多選了。請大家假裝看到了我已設計排他選項的功能。

那么對于這個問題來講，它會有一些報錯的情況。我的所有報錯都是層層遞進的。比如一個低級模塊有3個報錯，那么這3個報錯會反映到上一級模塊的報錯區域，形成1個關于這個低級模塊的報錯，具體報錯內容就是“下面有個模塊存在3個報錯”，至于是哪3個報錯，運營的人往下追查就行了——這個報錯思路在后面更復雜的地方你可能會被繞暈，所以我先聲明一下。

一個款項的門檻問題可能不止一個，所以我們在左側加上問題列表。列表沒什么好講的，唯一需要注意的是，不管運營的人配置了多少個問題，查理在回答這些問題的時候，必須全部選中了準入的選項。有任何一題回答錯誤，查理都會失去申報這個款項的機會。

你可以看到，剛才問題的報錯傳遞給了問題列表，問題列表由傳到了這里。這里就來到了頁面的頭部，右側是對整個款項的屬性的設置。前面介紹的情況，是這個款項需要獨立配置自己的門檻，也就是“依賴通用+額外門檻”的情況。

另外一種情況則是“僅依賴通用”，如果切換就到這個選項，那么款項本身就不能在配置問題了——只要滿足通用條件，查理就可以辦理這個款項。例如，當這個款項是針對眾創空間的，那么由于眾創空間沒有額外的要求，所以查理只要在通用門檻里確認了“我是符合條件的科技載體”，就可以直接辦理“眾創空間”這個款項了。

所以再把這個頭部安上去，這個款項門檻的配置頁面就搞定了。

講完了簡單的款項門檻，在這個基礎上，你想理解通用門檻就比較快了，所以我們點擊這個分段控制，進入這個政策的通用門檻吧。

2

門檻 / 通用門檻和“通用的”門檻

一個政策的通用門檻配置頁面看上去跟剛才也差不多，只是多了一些東西，下面我就來介紹多出來的東西。

把鏡頭拉近，看一下問題的配置，這里就跟具體款項門檻的配置不太一樣，這里的邏輯會比較繞，請認真看下面這幾點——

1、回到上一章我們講的款項。如果把一個款項設置為“僅依賴通用”，也就是說，只要查理符合整個政策的門檻，就可以直接辦理那個款項，那么，對于一個通用問題來講，它的選項配置成“僅為通用門檻”時，就說明只要用戶選擇了這個選項，用戶就符合了整個政策的大要求，同時也直接符合了那些不做特殊要求的具體款項；

2、但是，像我們上一章提到的情況，一個款項除了要求符合整個政策的大條件，還要符合具體的一些特殊要求時，我們會把那個款項設置為“依賴通用+額外門檻”。例如我們前面提到的，對于孵化器這個款項來說，你除了滿足整體對你科技載體資質的要求，你的工位還得超過200個；

3、那么這個時候，我們很顯然會去孵化器款項里面，配置關于工位數量的調查問題。但是天有不測風云啊，如果整個政策也對工位數量有要求，只是沒有孵化器款項要求的這么高呢？例如，整個政策不管你是什么東西，我都要求你有超過20個工位，而如果你申請的是孵化器款項，我會提高要求，你的工位數量不是要超過20個，而是要超過200個；

4、那么這個時候我們怎么辦？我們難道要分別配置兩個問題？在通用問題里，先問用戶是不是超過20個工位，然后在孵化器款項里，又去問用戶是不是超過200個工位？煩不煩啊？用戶不就多回答了一個問題嗎？所以我們這個時候直接在通用問題里一個問題問完不就行了嗎？

5、所以，我們在通用問題里配置了上圖的問題，問用戶“你的工位情況是怎樣的”，然后配置3個選項，分別是：“20個以下”、“大于等于20個小于200個”，以及“200個或以上”。然后，我們把“20個以下”設置為忽略，“大于等于20個小于200個”設置為純粹的通用門檻，最后，我們把“200個或以上”設置為除了它符合通用條件，它還符合孵化器的條件。那么這樣之后，我們就不需要在孵化器款項里單獨設置這個問題了。

其實我說了這么多，總結一點，就是避免了問題的重復性。只讓查理點選項就能篩選政策還不夠好，能再少點一次那就更好了。我們愛查理，查理更輕松了他就更開心，查理開心了我們就開心，這是設計后臺產品最大的樂趣。

所以我們把剛才提到的邏輯簡單設計一下交互，一個通用問題的配置就設計完了。

接下來就是針對這個具體問題的控制欄，這里就要談到“通用的”問題了。當我們把一個問題設置成“通用的”問題時，它可能是一個通用的“通用問題”，也可能是一個通用的“款項問題”。“通用的”和“通用”兩者是不同的概念。任何一個問題都可以設置成“通用的”，或者直接從通用庫里引用一個過來。

這樣設計的目的依然是繼續減少查理的操作。當查理選了2個政策，一起進行過濾的時候，可能這2個政策共享3個通用問題，那么查理就可以少回答3個問題了。查理同時進行過濾的政策越多，通用問題的交叉程度也就越顯著，我們替查理節省的時間也就越多。

查理是善良的，BE LIKE 查理。但是有些運營人員是邪惡的，他們比較喜歡偷懶，我們要提防好他們。當一個通用的問題被運用在很多政策的時候，牽一發而動全身的情況就會出現，可能運營人員只是改了按鈕上的一個文案，就導致30個政策的問題出現描述上的嚴重歧義。因此防呆策略是必不可少的。

當運營人員修改了一個通用問題的描述，或者其中按鈕上的一個字之后，他本來是想著去喝一杯咖啡享受一會午后時光的。但是我們不能讓他們這樣做。修改完成之后，回到總控制頁面，運營人員會發現閃亮的300個報錯，這300個政策都使用了那個通用問題，所以運營人員需要一個個點進去，一個個地人工確認這個問題在這300個政策里都依然正常。

這是沒辦法的事。為了查理方便，我們就需要設計通用問題。通用問題的應用范圍越廣越交錯，查理就越開心。這個鍋不是用戶來背就只能靠我們來背。只是說現階段我們需要通過人力的工作量證明機制來解決，而未來階段會有更好的更智能的方法，但是鍋的主角一定是后臺，不能推給查理。

具體款項的門檻配置完了，通用的門檻也配置完了，那么我們就完成了一個政策的門檻的所有配置。對查理來講，也許是5個簡單的選項題，如果查理都回答對了（符合條件了），那么接下來我們就要讓查理回答這些具體款項的一些數字類的問題，以便我們告訴查理他最終可以申請到多少錢（其實所有政府的資金政策都有具體的額度運算條款，只是沒幾個人有功夫一個一個政策的去查條款、去運算）。

上文就是整個后臺系統的鋪墊，下面我們就點進“額度運算”，正式進入這個后臺的HARD CORE部分。

3

額度運算 / 生成數字區間

假設查理滿足了一個具體政策款項的辦理條件，我們讓他填寫了3個數字，分別是員工里博士以上的人數、本科以上的人數，以及本科以下的人數。然而具體運算可以給查理多少錢之前，我們要先根據公司總人數來劃分一些數字的區間，因為這個款項已經提到了，對于不同的員工人數的公司，具體獎勵的資金計算方法是不同的。

例如100個員工以內的公司，政策會按照每平米200塊錢來發放租房的補貼，而100到500個員工的公司，政策會按照每平米300塊錢來發補貼，而且還會額外給你一些其它的獎勵。所以這個時候我們就要先生成區間，然后才能進行具體的不同的運算。

運算區間當然要先寫公式了，在上面這個彈窗里面，我們把查理填寫的三個數字加起來就得到了員工的總數。這個公式編輯器是通用的，后面具體運算的時候也要用到。有的人就要問了，你干嘛不讓查理直接填員工總數呢？

記住我們后臺產品的宗旨——讓查理開心。查理要另外多填寫一個數字，查理就不開心；如果查理要填寫的不是一個簡單加起來的數字，而是要計算出來的數字，查理還要去算數學題，查理就會很生氣。

設上面的公式最終運算出來的數字是X，顯然，X比負無窮要大，比正無窮要小……我們配置100和500這兩個關鍵點。每個關鍵點都有一個開閉符號，點擊就可以上下翻轉。例如，當我們把方括號都朝中間翻轉的時候，整個區間就分成了 ( -∞ , 100 ) [ 100 , 500 ] ( 500 , ∞ ] 。

然而大家有沒有想過一個問題。區間之內是要進行具體的運算的，或者用來存放下一層區間的（后面會講），那么在運營人員調整這些區間點的時候，會打亂這些“區間子民”的順序；而當運營人員調整區間點排序，或是刪除了某些區間點的時候，這些“區間子民”甚至會擠在同一個區間。所以在設置區間點的時候，我們必須開放調整這些“區間子民”的功能。

如上圖中，下面三個區間子民都擠在500到800這個區間里了，所以它們的氣泡就是紅色的，無法點擊提交，必須把它們上下移動位置，直到完全分開，每個區間里最多只有一個子民才能提交。如果說運營人員把區間刪除到太少了，裝不下這么多子民了，你會發現我們還提供了刪除子民的功能。

把區間和它的子民放在這個彈窗里全局操作是比較好的體驗。如果按照通常后臺產品的做法，那就是先要在外面把這個子民刪除掉，然后才能動這個區間。同時呢，如果修改這個區間的數字，也會引起報錯，因為區間的相對順序會被打亂，那么運營人員又要先去調整其它的區間。這樣操作來操作去的，整個人都不好了。

所以我們把它們之間的關系全部放在一個彈窗里，運營人員在中途操作的時候，不需要有任何的忌諱或者顧慮，可以隨意打亂數字之間的順序，隨意增刪區間節點，出現多少報錯都沒關系，只要最后提交答卷的時候所有東西都是正確的，中途犯的錯又有什么所謂呢？

因此我們就得到了區間配置的彈窗。這個彈窗還有一個特殊集合區，可以在這里設置一些特殊的數字集合。例如，一個政策說了，你有多少個工位，我就給你多少個100塊錢，但是如果你的工位恰好是888個，那么恭喜發財，我多給你十萬的紅包。

這一章節花了這么大力氣，我們最終得到了什么呢？我們最終得到了在額度運算頁面的一個小方塊。這個小方塊把查理填寫的一些數字，用一個公式，轉化成了如圖所示的3個區間和1個特殊集合。也就是形成了一個主區間。那么接下來我們就可以對這個主區間進行下一步的操作了。

4

額度運算 / 最終節點運算

在剛才得到的主區間的基礎上，我們向右擴展，就可以得到子區間、子子區間、子子子區間……為什么我們不能把主區間直接拆得松散一點來解決問題，而是要從主區間的某一個具體區間里，創造下層的子區間呢？這是因為，我這里的不同層次的區間運算公式是不同的。

比如說，我們在第一層區間里，通過查理填寫的公司面積，劃分出了幾個主區間。然而在公司面積5000到10000平方米這個檔口上，資金的運算方法出現了變化，需要根據另外的東西，例如公司的人數，來重新劃分運算方法。

例如，在5000到10000平方米公司面積時，查理可以按照每平米100元來接受補貼，同時，由于這個公司面積的企業比較大佬，政府想要額外提供獎勵，所以針對這個面積范圍，還另外有員工人數的獎勵，其中如果你的員工是1000人以上，我會按照每人50元再另外發放“員工休息區擴張”的租房補貼。

于是，在配置好了所有區間之后，我們就可以對這些最終的區間進行運算的輸出了，例如，在某個最終區間之下，我們填寫的公式是每平方米發放200塊錢。需要注意的是，如果一個上級區間被拆分成更小的子區間了，那么這個上級區間本身就不存在輸出公式了，所以這里的布局剛好是一行一行沒有嵌套的。

由此，再加上報錯區，我們就獲得了一個完整的“運算單元”。查理填寫了5個數字，運算單元先根據其中3個數字進行區間劃分，選準了某一行區間，然后再根據這一行區間對應的具體公式，使用其中的4個數字（跟前者會有重復引用）進行最終的運算，最后獎勵了查理兩萬塊錢。

報錯區的報錯，主要都來自于區間配置上的不合理。

上面講述的這個運算單元，由于最終輸出的是遠大于1的數字，代表具體獎勵的金額，所以它實際上是一個“道具”類的運算單元。說起道具，很多人就會聯想到BUFF，沒錯，道具代表直接給錢，而BUFF代表了對其它的錢產生一個增益（或減益）的效果，那么其它的錢又是怎么來的呢？

講到“其它的錢”，我們就要回到查理的視角。在我們對查理進行“孵化器”這個款項的金額運算的時候，我們剛才問的是第一個問題，這第一個問題里面，查理填寫了5個數字，但是這個問題只是考察了查理在公司面積上的數據，給的是“公司面積獎勵”這一份錢。

但是“孵化器”給的不止“公司面積獎勵”這一份錢，而是兩份錢（其實不止，后面會談到額外的錢，現在我們先簡化問題），還有一份叫做“專利數量獎勵”的錢。所以“孵化器”這個政策款項要問查理的不是一個問題，而是兩個問題。查理填寫的不只是第一個問題的5個數字，而是兩個問題的一共10個數字。

一個問題代表一份錢（其實也不一定，后面會談到另一種情況，現在我們先簡化問題），查理回答了兩個問題，但是這兩份錢并不一定是獨立計算的。當查理填寫了第一個問題的5個數字的時候，除了這個問題（公司面積獎勵）直接發放給查理兩萬塊錢，同時，由于查理其中的一個數字特別好看，例如說，查理的博士人數特別多，所以第二個問題的第二份錢（專利數量獎勵）可以直接獲得一個BUFF，在運算出來的基礎上，直接增加X%。

所以，當整個運算單元不是道具，而是BUFF的時候，最終輸出的就是一個徘徊在1左右的數字，用來給其它問題加BUFF。

例如，在20個博士的數量以內，查理的每個博士都可以為“專利數量獎勵”增加3%的金額，專利數量獎勵本身運算出來是100萬，而查理有3個博士（沒有突破該區間上界），那么運算單元就會輸出“1.09”這個數字，把后者獎勵提高到了109萬元。

一個問題（查理填寫的5個數字）除了可以對其它問題（圖中下面的Q2和Q15）同時施加BUFF，還可以對這個款項的保底額度（只要符合款項辦理條件就直接無條件給的錢）和最終運算出來的總額施加BUFF。

所以，查理在回答一個問題，填寫了5個數字之后，除了獲得這個問題本身獎勵的那一份錢（道具），還獲得了保底額度、最終運算出來的總額，以及另外兩個問題的錢的加成（BUFF）。一份道具、N份BUFF，它們共同構成了這個問題（其實是這個問題的某條最終分支，后面會講）的“最終節點運算”。

有的人又要說了，你搞這么多BUFF干嘛呀？你玩魔獸只修神牧的嗎？為什么不直接在每個問題里、在這個具體政策款項的保底金額里，以及在款項最終運算出的總金額中，直接提問呢？——實際上，我是一名坦克玩家。我搞這么多BUFF不為別的，都是為了讓查理開心啊。一個數字如果在不同的地方填寫了好幾次，查理又會不開心了。

那么一個數字到底在哪個問題里作為道具，讓查理具體填寫，又在哪些問題里只作為傳遞過來的BUFF，不需要查理填寫，這就要看這個數字在哪個問題里作為道具的產生條件了。這樣的設計不可避免地帶來了問題之間數據耦合的問題。

要想徹底消滅耦合，我們必須把所有的問題里面的所有的數字全部拆出來當做獨立的變量，把它們全部平鋪在一個大桌面上，然后對這些變量直接進行全局的可視化編程。那是個看上去界面簡單不少，實際上工作量更大的后臺。這杯酒先存著，等以后我寫可視化編程的產品文章時，再跟你娓娓道來。

5

額度運算 / 問題的樹

上一章我們提到的整個的“最終節點運算”，都屬于圖片上部分的“字段節點”里面的配置。字段節點負責在一個問題里面收集一些字段。你可以看到字段節點的入口上，展現了運營人員配置的字段，以及當前它有沒有配置道具、有沒有配置各種BUFF的情況。

而圖片下部分是“選項節點”。選項節點在問題里就是一個具體的選項按鈕，例如“我司具備拯救世界的條件”，用戶選擇了這個選項之后，不需要進行數字的運算，而是直接發放固定的獎勵（道具），直接給其它東西施加固定的BUFF，屬于最終節點運算模塊的閹割版。所以就不再額外介紹它了。

一個節點如果是選項類的，那么當然它可以添加平級的選項。

自然地，只要這個節點是選項，那么它就可以自由添加前后的分支。

這個問題的樹由一層層的選項節點構成，直到遇到一個字段節點，不能往下繼續走了；或者遇到了最后一層的選項節點，運營不再配置了——這些走到頭的節點，你可以看見它們的名字是展現為藍色的，它們就是“最終節點”，也就是前一章的“最終節點運算”模塊的所在。

而這些節點最終就形成了一個問題的樹。黑色的最終節點是當前選中的節點，我們上一章所有的運算邏輯都是屬于這個節點的。在這個樹里面，上一層選項節點的標題就是它自身的按鈕文字，而它的描述——如果它的下層還是一些選項節點的話，則是下一層選項按鈕的提示文字。

對于一個問題來講，查理有很多條路可以走，最終查理走到了一個最終節點上，如果這個節點是數字類的，那么查理還要填寫一些數字。然后這個問題就按照最終這個節點的邏輯進行運算，算出能給查理的最終的錢的數量，以及相關的BUFF。

舉例來說，查理回答“孵化器”這個政策款項的提問時，遇到的最后一個問題是“你更愛你的家人還是你的朋友？”，此時查理面對的是第一層的3個選項節點，節點的標題分別是“家人”、“朋友”和“都不怎么愛”。其中“都不怎么愛”不再有分支，是一個最終節點，這個節點配置的“最終節點運算”只有一個針對款項總額的BUFF，由于只是一個枚舉值，不存在數字變量，不能撰寫公式，所以BUFF的數值直接寫死為0.01。

幸好查理選擇的是“家人”，選擇了家人之后，查理來到了第二層節點，這個節點的屬性是字段節點，因此不再具備同級的其它選項，查理只看到了一段描述和一個數字框，描述是“你愛你的家人多少？”，查理在下面的數字框里填上了“3000”。然后點擊了確認。

在這個“愛多少”的最終節點運算的配置里，“3000”被劃分到了第三個、最后一個主區間，這個主區間的運算公式采用梯度計價，首先獎勵520元，對于超過520的部分，每份愛獎勵兩塊錢，所以查理在這個問題下直接獲得了5480元。

同時，這個“愛多少”的配置里不光有道具，還另外設置了一個總額BUFF。這個總額BUFF的政策指導是，在不超過20%的情況下，每一份愛增加0.01%的增幅，因此“3000”這個數值被直接劃分到了( 2000 , ∞ ) 這個區間，直接輸出1.2的固定數值，用來乘以最后的總額。

最后，總額的輸出一共是350萬，那么再考慮到“愛多少”對總額施加的BUFF（聰明的朋友這個時候會想到運算優先級的問題了，這一塊在下文），最終總額輸出時一共給查理算了420萬。因此我們可以發現，查理對家人的愛可以兌換成人民幣705,480元。

那么對于一整個問題來講，我們可以配置它的封頂金額。例如一個政策款項來講，最高可以拿到500萬元，而其中關于公司面積的獎勵不管再多，也不能超過30萬元，那么就在此處把上限設為30萬元。可能你會想到，一個問題除了上界，是否還會存在下界，也就是說，一個問題不管查理是怎么回答的，他最少都能獲得1000元的保底金額？

——上界是每個問題的，而下界是可以歸納在一起的。我們只需要把每個問題的下界加在一起，設置為整個款項的保底金額，就能實現同樣的效果。

至于一個問題的內部是否會對它本身的保底金額產生BUFF，以至于合并后的款項保底金額失去了一部分運算信息？這個是可以避免的，方法就是禁止一個問題對它自身產生BUFF。一切問題自身的運算直接反應在它的道具本身，任何程度的，對自我增益邏輯開設的方便之門，都會導致不必要的邏輯混亂。

這就是“牛頓的烈焰激光劍”原理（Newton’s Flaming Laser Sword）。當你有一個簡單的實現方案，而你的同事或老板提出一種看似更貼近現實卻徒增邏輯復雜度的需求，而你用奧卡姆剃刀又砍不過他們的時候，記得這把劍。

所以，當我們把這個頭部安上去之后，我們就獲得了關于一個政策款項的一個問題的樹。

6

額度運算 / 完成界面

整個問題的樹，來自于對一個具體問題的選中。從上圖你可以注意到，下方的這個問題的道具總數為0，也就是說，這個問題本身的任何節點都不存在道具的配置，換句話說，這個問題不管查理怎么答，都沒有一分錢可以拿。這是因為有些問題是純玩輔助的，這些問題存在的目的就是給總額、保底額或者其它問題提供BUFF。

這些問題構成了這個政策款項的問題列表。

一個款項除了擁有一串問題列表之外，還得有兩種配置信息。其一是前文已經提到的，這個款項的上下限的配置，而其二（右邊）是這個款項對于同一個政策的其它款項的作用力的配置。你可以大致理解為當查理夠資格辦理這個款項時，這個款項對其它兄弟款項發出的BUFF，當然了，只有對方也可以辦理時，這個BUFF才成立。

款項之間的BUFF跟款項內部問題之間的BUFF區別主要在于兩點。其一是款項之間的BUFF沒有什么運算規則，更簡單，只要A款項用戶可以辦，那么就會向B款項傳遞一個BUFF數值，沒有區間的劃分，也沒有太多變量可以用，在這里運營人員可以使用的變量只有三個：款項保底額、款項最高限額，以及款項實際運算出來的總額。

其二是款項A對款項B不光可以施加一個BUFF，還可以發射一個“拋射型道具”，也就是直接發射多少多少人民幣給款項B。

這里之所以跟我前面用到牛頓烈焰激光劍的地方不同，是因為款項之間的界限比較大。如果查理符合申請款項A之后，再申請同一政策下的款項B可以直接獲得20萬元的加成，只有用拋射型道具直接扔錢過去這一種解決之道。

于是我們把剛才的兩個彈窗做成標簽式（可以直接展現內部配置）的按鈕，再加上報錯，就形成了整個政策款項額度運算界面的頭部。

再把之前提到的問題列表、和運營在問題列表中選擇一個具體問題時，上一個章節提到的“問題的樹”模塊也扔進來，就形成了上圖的界面（還沒完）。

再把運營人員選中了問題的樹的其中一個最終節點，對它進行“最終節點運算”配置的界面扔進來，我們就得到了關于一個政策的——具體一個款項的——額度運算的——具體配置——的完整頁面。

這個頁面看上去雖然很寬，不過，首先問題列表是可以折疊的，而問題樹平時一般也只有一兩層，所以實際使用的時候一般不會這么寬。

其次更重要的是，問題之間有各種BUFF相互關聯，問題之間的問題樹的具體配置，也需要運營人員來回切換、反復權衡。如果不放在同一個頁面里，而是一個問題跳轉一頁，會在實際工作中造成相當大的困難。

這個困難不一定導致運算邏輯出錯，但是缺少了視覺上大局觀的強化，運營人員可能沒有那么好地對問題之間進行來回斟酌，查理就可能要填寫更多的回答，查理又會不開心了。

那么是不是這個款項就搞定了呢？可以運算了呢？運算是可以運算，但是一定會出錯，而且會錯很遠。因為前面我已經提到了，由于運算的流程比較長，各種運算模塊之間也會有BUFF關聯，所以會存在優先級的問題；同時，每一層模塊都有數值上界，所以又存在要不要突破上界的問題。

這些邏輯在實際的政策中不一定說得那么明顯，但是都會有嚴格的邏輯需要被執行。所以我們接下來就點擊“款項總額運算管理”，進入后臺設計部分的最后一個章節。

7

額度運算 / 穿透與迭代

經過前面一兩章的反復提及，你一定知道了對于一個具體問題來說，它可能會收到來自其它問題對它施加的BUFF。例如上圖這個問題1就收到了來自問題2、問題4和問題15里，某些具體最終節點的BUFF。

假設問題1本身設置了自己的金額上限，整個款項也設置了自己的金額上限，那么對于這三個BUFF而言，我們就要在三個格子里讓運營點擊，選擇它們自身對于這兩層上限的穿透性。如上圖——

Q2對于Q1的BUFF穿透性設為普通，也就是不能超過Q1本身的上限。例如Q1本身上限是20萬，而Q1自身的道具就已經運算出15萬了，所以Q2不管想讓Q1增加多少倍，最多就只剩5萬元的增長空間；Q4設置為可以穿透問題的上限，但不能穿透總額的上限，也就是說，Q4可以直接無視20萬元的Q1問題上限，但是不能突破款項總額的500萬上限。而Q15則象征著完全的自由。

而對于Q1本身來講，它自己的道具是不能突破自己的上限的，否則問題上限就純粹地失去了它的意義。所以你可以看到這里是灰色不可點的。

前面提到的情況是一個問題比較“發育健全”的情況，也有不健全的情況。當一個問題不存在上限時，理所應當地，也就沒有針對這個問題上限的穿透性可以選了；而當一個問題連道具也不存在的時候，它就什么都不可以選了。

那么為什么會有這種完全沒有錢的問題？前文我已經提過了，這是純輔助的問題，只為了給其它人加BUFF而生。至于沒什么東西要調，我為什么要把它也放進這個頁面里面來？因為這樣看起來比較連貫啊。

然后，就輪到迭代出場了。Q1有來自這么多問題的BUFF，其中你如果細心看圖的話會發現，Q13竟然還傳了兩個BUFF過來。其實這是來自Q13的兩個最終節點，一個問題對于一個用戶來講只能走一條唯一的線路，所以查理最多只能享受到其中一個BUFF。

那么這個迭代是干嘛的呢？其實迭代就相當于數學里面的括號。首先，一個問題的基石是它自身的道具，也就是自身算出來多少錢，它的迭代被固定成0，不能更改。然后，運營把其它的BUFF設置成了一共5次迭代（別忘了迭代0也是一次）。系統這個時候會老老實實按照迭代次數來運算這些BUFF。具體怎么運算的呢？

假設Q1本身的金額（道具）運算出來是X1，系統先找迭代0的，找到了Q4這個BUFF，那么Q4的BUFF就直接乘以這個問題的金額，然后我們就獲得了新的Q1的總額——X2。

這個時候迭代0已經算完了，系統接著找迭代1的BUFF，這個時候系統找到了Q2和Q25，它們的BUFF都是迭代1，所以它們其實是各自跟X2相乘，分別運算出一個增加值（不排除是負值），這個增加值最后都加在X2頭上，讓它變成X3——這就是迭代的目的。

在同一次迭代里，BUFF不管再多，都是跟上一輪迭代的初始值來計算，不會像滾雪球一樣越算越大。

為了照顧運營的體驗，迭代采用了防呆設計，保證怎么點都不會故障。

然后，我們把保底金額和其它所有問題都堆進來，就形成了一個個迭代組。保底金額也會收到BUFF，所以在本模塊跟一般的問題是沒有太大區別的。這些迭代組各自算各自的，都是從迭代0開始運算，互相之間不會出現任何影響，各算各的錢。

然后我們把每個問題單獨迭代運算出來的錢，以及保底金額的錢，全部加在一起，就形成了初步的這個款項的總額預測，例如300萬。但是我們不能就告訴查理你可以拿300萬了，事情還沒完。

我們把剛才初步的總額運算叫做第一個迭代大組，而最終的運算還需要經過兩個迭代大組。

在第二迭代大組，我們要把初步總額再跟指向總額的問題的BUFF進行運算，獲得經過總額BUFF加權的新總額。

然后，在第三迭代大組，在這個新總額的基礎上，我們再考慮其它款項（如果那些款項可以辦理）對這個新總額施加的BUFF，以及拋射的道具。

然后這三個迭代大組一起放進頁面，就基本完成了這個界面。

三個迭代大組其實很容易理解，因為它們分別代表著：問題各自運算然后累計出總額、款項內部的BUFF調整總額，以及最后，款項之間再對總額進行最后的修正。

最終，這個界面的邏輯對整個運算流程進行了精確的把控，幫查理計算出了他申請“孵化器”這個款項到底可以拿到多少錢。而這個預測是可以精確到每一塊錢的。

現在我們終于可以從一個政策里面出去了，去看看整個后臺長什么樣吧。

沒錯，總控制臺沒什么好講的，所以整個后臺我用了1萬2千多字，終于把它的主流程介紹完了。

這篇文章我說過了，標題也寫上了，是跟你介紹這個產品的后臺和用戶端的，是完整介紹整個系統的。所以這個文章只寫完了一半，接下來我就跟你介紹用戶端，讓我們看一看，在查理的視角里，這個產品是怎么用的。

8

查理和他的白色石膏房子

由于以上后臺界面比較丑陋，所以先強調一下，以下的頁面也是我設計的，用的是AdobeXD（PC用戶沒有Sketch）。我在設計后臺的時候喜歡使用賽博朋克風格，拼拼接接、能用就行。而在設計用戶端的時候，就需要考慮一下體驗的問題了。

查理選擇了十幾個政策，進到了匹配第一頁，回答政策的門檻問題。

回答完門檻問題之后，系統幫他過濾掉了其中一大半的政策，留下剩余政策的額度運算問題，讓查理在問題樹中穿行（注意第二個方塊帶后退鍵，不是問題樹的第一層），并且填寫一些數字。

時間終于來到了文章的一開頭。

查理看著這個白色的、簡單得像美術課上的石膏體一樣的白色石膏方塊屋子，把他花了3分鐘填寫的表格扔進了這個石膏房子唯一的開口，一個規整的沒有額外修飾的矩形開口，通進厚厚的石膏墻壁里。然后查理按下了那個開口正下方，整個石膏房子唯一的按鈕。

查理的表格通過石膏開口里面的氣動管傳到了這座房子地下50米深的一個工廠，值班經理拿著查理的表格按下了開工鈴，鏟煤的工人扔下手里的雪茄，甩掉臉上的油汗，點燃了巨大的鍋爐，工廠里頓時到處冒著蒸汽，蒸汽管道在工廠各處的泄壓閥呲呲呲地響了起來，蒸汽工廠開工了。

幾十個秘書在圖書館里匆忙地跑來跑去收集各種資料，把它們整理好交給會計。會計透過厚厚的鏡片一手唰唰地翻閱這些材料，另一只手把算盤撥出了殘影。

工廠的另一頭，噴著臟汗的伐木工人終于把木頭砍碎，扔進一個巨大的攪拌機里，順勢大聲呵斥他的學徒，學徒連忙把剛割下來的羊毛、亞麻絲和天鵝絨也扔了進去。紙漿機排水管道的另一頭，齊聲唱歌的女工把紙漿壓扁、烘干，再噴上特質的以佛手柑為后調的天然香水，只要淡淡的一點就好。

再回到圖書館，值班經理彎著腰認真聽著老會計的耳語，然后奔跑前往活字印刷工的所在之處。印刷工仔細校對了最終的鋼板，涂上厚重的黑色油墨，把剛做好的散發著佛手柑香氣的天鵝絨紙片擺在中間，大力壓了下去。

一直守在旁邊的經理趕緊把紙片放回了氣動管道。隨著鍋爐的蒸汽，紙片嗖地飛上了50米上方的白色石膏房子，飛出了剛才查理扔進表格的那個，白色石膏房子的唯一的開口。

查理把表格扔進房子之后就走神了，遠處的云才剛移過遠處的樹。查理發著呆，一邊看著那棵樹，一邊挖鼻屎。天鵝絨紙片從開口飛出來就落在了平整的草地上，紙片又小又輕，沒發出任何聲音。要不是一些蝴蝶以為它是佛手柑，查理可能就會錯過了。

------正文分割線------

好文推薦：

產品經理面試如何做自我介紹

萬字干貨?|?認真教新手設計一個頂級表單定制后臺PRD

埋點、數倉到中臺：數據體系的從0到1

點個“在看”吧

總結

以上是生活随笔為你收集整理的查理和政策配对工厂——设计一个问卷运算系统的B端到C端的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。