公积金贷款试算系统设计：规则校验与策略实现

一、背景：政策条文需要“系统化落地”

公积金贷款政策具有较强的时效性与地域性。以近期某地公布的贷款新政为例，其调整通常集中在三类内容：

• 数值类参数变化：最高贷款额度提高、首付款比例下限明确为不低于20%；
• 准入类规则变化：首套房认定条件放宽；
• 策略类规则变化：贷款次数不再构成限制；符合规定条件的人才，最高贷款额度可上浮至4倍，且多项上浮条件不叠加、由借款人择一执行。

对研发团队而言，每一次政策调整都意味着校验逻辑、计算公式与前端提示的联动修改。如果这些规则以硬编码方式散落在业务代码中，改动成本高、回归风险大。因此，把“政策条文”转化为“可配置、可解释、可测试的规则系统”，是这类业务系统设计的核心命题。本文以“贷款条件校验 + 额度试算”为主线，给出一套可复用的设计思路。

二、领域建模：把办理条件抽象成规则清单

新政公布的办理条件可以归纳为九项，从工程视角看，本质上是三类判定：

1. 主体资格类：具有完全民事行为能力且未达法定退休年龄；持有效身份证件。输入是申请人基础信息，输出为布尔值。
2. 缴存与账户类：申请时账户状态正常；单位职工连续正常缴存至少6个月，且申请当月与最近缴至月份间隔不超过2个月；灵活就业缴存人已缴存至少6个月；无未结清公积金贷款（含公转商贴息贷款）。
3. 交易与能力类：持有经购房地住建主管部门确认的购房合同且为买受人；首付款比例不低于规定值，且首付款加贷款金额等于交易价格；收入稳定、具备偿还能力、信用良好；能提供公积金中心认可的担保。

建模建议：定义统一的规则接口（规则编码、描述、校验方法），每项条件对应一个规则实现，校验服务聚合执行并汇总结果。示意如下：

from abc import ABC, abstractmethod
from dataclasses import dataclass
from datetime import date
@dataclass
class Applicant:
    applicant_id: str
    birth_date: date
    account_status: str        # NORMAL / FROZEN / CLOSED
    continuous_months: int     # 连续正常缴存月数
    gap_months: int            # 申请当月与最近缴至月份的间隔
    applicant_type: str        # EMPLOYEE / FLEXIBLE（单位职工 / 灵活就业）
    has_unclosed_loan: bool    # 是否存在未结清公积金贷款
    is_confirmed_buyer: bool   # 是否为经确认的购房合同买受人
    credit_ok: bool            # 收入与信用是否达标
    guarantee_ok: bool         # 是否提供认可的担保
class EligibilityRule(ABC):
    code: str
    message: str
    @abstractmethod
    def check(self, a: Applicant) -> bool: ...
class ContributeRule(EligibilityRule):
    code = "R_ACCOUNT"
    message = "账户状态正常，连续正常缴存满6个月，且当月与最近缴至月份间隔不超过2个月"
    def check(self, a: Applicant) -> bool:
        min_months = 6
        return (a.account_status == "NORMAL"
                and a.continuous_months >= min_months
                and a.gap_months <= 2)
def run_rules(applicant: Applicant, rules: list[EligibilityRule]):
    return [{"code": r.code, "passed": r.check(applicant),
             "message": r.message} for r in rules]

这样做的好处是：新增或停用某项条件（例如“贷款次数不受限制”意味着原有的次数上限规则要下线）只需增删规则项，而不用改动主流程。

三、时间维度校验：缴存连续性的正确判定

缴存连续性是公积金业务中最容易出错的一类校验，需注意三个细节：

• “连续正常缴存至少6个月”应基于缴存明细按月聚合后判断，而不是简单用当前日期减去开户日期。补缴、封存、启封都可能打断“正常缴存”的连续性，只有逐月核对缴存状态才可靠。
• “间隔不超过2个月”是独立的滑动窗口校验，用于容忍跨月办理的场景，应与连续月数校验解耦，各自独立判定、独立提示，避免一条规则失败掩盖另一条的真实原因。
• 单位职工与灵活就业缴存人规则不同，建议在规则实现中通过“缴存人类型”维度做策略分发，避免用层层嵌套的条件分支堆叠逻辑。

四、额度试算：基础额度、上浮策略与多借款人合并

额度计算通常分三步：

第一步，计算每位符合条件借款申请人的基础额度。 常见做法与账户余额、缴存年限、还款能力系数等因子相关，具体公式以当地政策为准，系统应将公式参数全部外置，不写死在代码里。

第二步，处理上浮策略。 新政的典型表述包含两个关键设计点：一是“不叠加”，多个可上浮条件同时满足时只能生效一个，避免重复放大；二是“可选择”，借款人有权指定采用哪一项，系统在未指定时需有明确的默认策略（例如默认取对借款人最优的一项，具体以业务约定为准）。这正是策略模式的典型应用场景：

class FloatPolicy:
    """上浮策略：多项满足不叠加，可由借款人指定其一，未指定时默认取最优"""
    def __init__(self, base_limit: float, options: list[dict]):
        self.base_limit = base_limit
        self.options = options  # 如 [{"code":"TALENT","name":"人才支持","multiplier":4.0}]
    def calc(self, eligible_codes: list[str], chosen: str | None = None):
        hit = [o for o in self.options if o["code"] in eligible_codes]
        if not hit:
            return self.base_limit, None
        codes = [o["code"] for o in hit]
        target = (next(o for o in hit if o["code"] == chosen)
                  if chosen in codes else max(hit, key=lambda o: o["multiplier"]))
        return self.base_limit * target["multiplier"], target["name"]

第三步，多借款人合并。 当一笔贷款存在多位符合公积金贷款条件的借款申请人时，该笔贷款额度为各申请人额度之和，同时仍受当地最高贷款额度封顶约束：

def merge_limits(per_person: list[float], cap: float) -> float:
    """多借款人额度相加，并做最高额度封顶"""
    return min(sum(per_person), cap)

五、首付与金额等式约束

新政明确两条金额约束：首付款比例不低于20%；首付款金额加上贷款金额应等于住房交易价格。前者是下限校验，后者是等式校验。实践中二者常被合并成一个“比例检查”而漏掉等式，导致试算通过、正式受理时却被退回。建议在试算服务中把两条拆成独立规则分别输出结论：

def check_payment(price: float, down_payment: float, loan: float,
                  min_ratio: float = 0.2):
    return [
        {"rule": "首付比例下限",
         "passed": down_payment / price >= min_ratio,
         "detail": f"实际比例 {down_payment / price:.2%}"},
        {"rule": "首付加贷款等于交易价格",
         "passed": abs(down_payment + loan - price) < 1e-6,
         "detail": f"差额 {down_payment + loan - price:.2f}"},
    ]

六、可解释性输出：让试算结果“说得清”

用户通过官方移动端应用、政务服务平台等渠道查询试算结果时，最差的体验是只看到一个数字或一句“不符合条件”。更好的设计是让试算接口返回结构化的过程数据：

• 每条资格规则的通过/不通过状态与不通过原因；
• 基础额度、生效的上浮策略、最终额度及封顶值；
• 首付款比例、等式校验结果。

这种“可解释性输出”一方面提升用户体验，让用户知道差距在哪、补齐什么即可达标；另一方面也为客服答疑与柜台复核提供统一口径，显著减少争议。

七、配置化与版本管理：应对政策调整

政策调整通常有明确的生效日期，过渡期内还可能新旧并行。工程上有两点建议：

• 参数外置：最高额度、上浮倍数、首付比例下限、连续缴存月数、间隔月数等全部放入配置中心，改参数不改代码。如果团队希望快速搭建试算接口与配置热更新链路，也可以借助云平台提供的函数计算、配置管理等通用托管能力。
• 版本化执行：试算请求携带“购房合同网签时间”或“申请时间”等锚点字段，由系统路由到对应政策版本的规则集，保证过渡期内新旧申请各自适用正确规则，并保留历史版本以便回溯核算。

八、测试策略与边界用例

政策计算类系统的测试重点在边界与组合：

• 缴存月数恰好6个月、间隔恰好2个月、首付比例恰好20%等边界值；
• 多项上浮条件同时满足时“不叠加、择一”的行为，覆盖用户显式指定与默认策略两条路径；
• 多借款人求和后触及最高额度封顶的场景；
• 政策版本切换日当天提交申请的归属判定。

建议将规则清单直接映射为测试用例清单，做到“一条规则至少一条用例”，并在政策发布时以政策原文逐条比对用例，形成验收清单。

九、小结

把政策条文工程化，关键在于三点：规则清单化，让每项条件独立可测；策略与参数配置化，让政策调整以改配置为主、改代码为辅；输出可解释，让每个结果都能追溯到具体规则。掌握这套方法后，无论是公积金贷款试算，还是其他政策驱动的资格判定与金额计算场景，都可以复用同一套设计骨架。