本文由作者 黄联樵 于社区发布

长文预警，建议先收藏

查理的头都要炸了。查理他开了一家公司，公司年后要扩张，找投资人要钱投资人不给，投资人说，你的公司有它的独特条件，可以找政府拿奖励啊，干嘛让我白掏钱，自己申请去。

查理上政府网站随便打开一个政策一看，确实是这么回事，只要符合条款里的各种条件，就能申请到政府的奖励。然而这些网站太多了，政策也太多了，条款也太复杂了。查理不知道怎么找到自己够格申请的政策，更算不出能拿到多少钱——查理当然不是做不到，只是，查理真的不大愿意做。这太费时间，也太痛苦了。所以查理就开车到附近的市中心散步去了。

走在市中心，查理的两边都是各种巨大又嘈杂的商场，他就在这条路上走啊走，突然看见了一个很违和的建筑。这个建筑周围空荡荡的，只有平整的绿地。建筑本身也简洁得有点奇怪，没有门，没有窗户，没有屋檐和管道，是一个标准的正方体，就像美术课里画画用的石膏方块。

这块大石膏上只有五样东西。墙壁正面凹下去的刻字招牌，写着“政策配对工厂”。墙上挂着一支笔和一张表格纸。从厚厚的墙壁里，延伸出来一条切割得非常平整的矩形开口，而开口的正下方是一个跟墙壁几乎融为一体的，凸起的按钮。

查理拿起表格，看到上面写着：“在表格里勾勾画画几下，然后扔进来，然后按按钮，我们就能很快帮你找到所有符合你条件的政策，并且帮你计算出你能获得的具体政府奖励金额”——查理一看还有此等好事？马上花了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

点个“在看”吧