airz-uniapp/docs/需求与评估结果数据契约.md

# 融资需求与评估结果数据契约

版本：v1.5（需求/报告v2、目录冻结及规则匹配落库已实施；匹配读接口与页面待接）。日期：2026-09-24。配套：[开发文档](开发文档.md)、[开发进度](开发进度.md)。

本文补充融资需求字段、资料完整度与准备等级、产品匹配解释三个范围，作为后续前后端、数据迁移及验收的共同依据。依据为[开发说明书](开发说明书.docx)第2—5节及[原型图](原型.jpg)第02—05、09屏，并遵循用户后续确认的无草稿、H5优先、数据库存元及复用评估/报告表的约定。

**实施状态：需求v2、用途字典、完整度/准备状态、执行策略快照和报告v2自填支线已实现。** DEC-DEMAND和DEC-READINESS已按用户授权采用首版开发配置；新提交冻结targetResultVersion=2。升级前未带该标记或目标1的输入仍走resultVersion=1，旧成功报告不重算。真实匹配及产品解释待DEC-MATCH/产品资料，v2有限真实模型样例现已通过，生产业务和大样本语义验收仍待完成；证据见开发文档0.7、开发进度6.7及[真实模型验证记录](报告v2真实模型验证.md)。

## 1. 范围与业务含义

| 概念 | 回答的问题 | 不能表示的含义 |
| --- | --- | --- |
| 融资需求 | 用户希望获得多少资金、使用多久、用在哪里 | 银行批准额度、实际利率或放款承诺 |
| 资料完整度 | 当前版本列明的自填信息项有多少有效填写 | 真实性、信用评分、所有银行所需材料已齐全 |
| 融资准备等级 | 按已发布资料规则，哪些信息缺失、矛盾或可以进入人工核对 | 风险等级、授信等级、获批概率 |
| 产品匹配 | 在指定时点、产品版本和已知事实下，具体条件是否满足 | 审批结论；自填条件满足也未经机构核验 |

最初契约不新增页面，需求录入放评估页的“资金需求”步骤/分组，确认页、档案、报告同步显示。2026-09-24用户明确要求补齐04—10，现以[页面改造方案](原型04-10页面改造与跳转方案.md)为准：新增对比/下一步行动页并将PDF纳入一期任务；其余渠道、注销、知识库未随本次扩大。原型默认最多三个候选，不足不补造；匹配解释仍在现有产品详情展示，传递assessmentId与productId。

本次只增加共同融资需求字段。年龄段/工作年限、企业开票/纳税/流水/法人等补充资料另在 ASSESS-001 的字段字典阶段细化；当前已有 `year_invoicing/year_tax_amount` 可复用，但没有录入/API支撑时不能启用依赖它们的准入规则或宣称相关完整度已覆盖。企业成立月数与经营月数不等同，不能互相代填。

## 2. 融资需求输入

### 2.1 请求与字段

新增输入格式 `inputVersion:2`，仍使用 `POST /api/v1/assessments`。顶层保留 type、requestId、moneyUnit、form、documents、consentIds；新增 inputVersion:int。下列字段放入 form，个人/企业共用；现有姓名、证件、收入等必填约束本次不放宽。

| API字段 | 类型/单位 | v2提交约束 | fa_user_info已实现存储 |
| --- | --- | --- | --- |
| requestedAmountYuan | string，元 | 必填，`0.01`—`999999999.99`，规范两位小数，禁止JSON number、指数、负数、逗号、空格 | 新增 requested_amount DECIMAL(11,2) NULL |
| requestedTermMonths | int，月 | 必填，1—9999；禁止0、小数、数字字符串；范围为技术表示上限，不表示产品支持如此长期限 | 新增 requested_term_months SMALLINT UNSIGNED NULL |
| purposeCode | string，稳定枚举 | 必填，必须在本次类型允许的已发布用途字典内 | 新增 purpose_code VARCHAR(32) NULL，ASCII区分大小写 |
| purposeDetail | string或null | purposeCode=other时必填，trim后2—200个字符；禁止HTML/控制字符；其余用途必须null或缺省 | 新增 purpose_detail VARCHAR(200) NULL |
| inputVersion（顶层） | int | 新客户端发送2；服务端版本策略见第7节 | 新增 input_version TINYINT UNSIGNED NOT NULL DEFAULT 1 |

金额继续由客户端字符串运算完成万元→元，服务器以十进制处理；例如 `12.345678 万元` 对应 `123456.78` 元。需求金额不是已有负债、年营收或产品最高额度，不复用这些列。未知需求不以0代填；v2正式提交缺少上述必填字段时返回422，表单仍只保留当前流程内存，不增加保存草稿接口。

**用途字典已发布：`financing-purposes-20260923-v1`（DEC-DEMAND）：**

| 评估类型 | 允许code及显示名 |
| --- | --- |
| personal | daily_consumption 日常消费、education 教育进修、home_improvement 家居装修、personal_business 个体经营周转、other 其他用途 |
| enterprise | working_capital 经营周转、inventory_purchase 采购备货、equipment_purchase 设备购置、business_expansion 经营扩展、other 其他用途 |

字典需包含版本、适用type、code、label、requiresDetail和启用状态。`GET /dictionaries` 已返回 assessmentInputVersions、minNewAssessmentInputVersion、financingPurposes及其版本，公开且no-store；当前由服务端配置发布，无后台编辑。移除配置条目即停用新建用途，变更需提升版本。正式提交事务内保存所用字典版本及用途项快照，显示名变化或后续停用不更改已提交记录的用途含义，也不阻止原请求幂等重放；保存位置见第6.2节。用途类别本身不表示机构允许；是否允许由产品规则及正式来源确定，尤其不能把“其他用途”直接判为满足。

### 2.2 服务端校验与隐私

- 同一requestId比较规范化的**全部输入**，包括 inputVersion 和四个新字段；缺省可选值归一为null，非法值不得静默丢弃。只允许目标类型的用途code，个人用途不能混入企业提交。
- 规范金额格式 `^(?:0|[1-9][0-9]{0,8})\.[0-9]{2}$` 后，再检查严格大于零。客户端展示万元，所有API及JSON快照金额均为元字符串。
- 用途说明是用户自由文本，只在本人只读详情及有权限的后台展示；不写请求日志，不作为可执行规则，不直接发送模型。后续报告v2的AI仅可接收经过白名单处理的用途code/标签、需求金额和期限事实；当前v1报告尚未接入这些新事实。说明中即使含“忽略规则”等内容也不影响匹配。
- 格式合法但互相矛盾的数据另做一致性校验。例如信用卡已用额度大于总额度时，v2提交返回422 FIELD_INCONSISTENT；不自动改小金额或改成0。不能从“贷款笔数为0”简单推断其他全部债务余额必为0，不做未经定义的跨概念推导。
- `documents/consentIds` 当前只能为空。后续接入授权后，拒绝可选征信查询不阻止自填提交，不为未付费查询扣资料完整度分，也不将未查询当成征信正常。

### 2.3 已实现请求示例

以下为本地已支持的合成企业请求样例，不代表生产已发布：

```json
{
  "inputVersion": 2,
  "type": "enterprise",
  "requestId": "needs_submit_example_001",
  "moneyUnit": "yuan",
  "form": {
    "name": "示例联系人",
    "phone": "19900000000",
    "city": "深圳市",
    "cityCode": "440300",
    "enterpriseName": "示例企业",
    "businessCode": "91440300123456789A",
    "occupation": "科技服务",
    "operatingMonths": 24,
    "annualRevenue": "1000000.01",
    "totalDebtBalance": "0.00",
    "monthlyLoanPayment": "0.00",
    "requestedAmountYuan": "123456.78",
    "requestedTermMonths": 12,
    "purposeCode": "working_capital",
    "purposeDetail": null
  },
  "documents": [],
  "consentIds": []
}
```

HTTP201接受回执保持 `{assessmentId:string,submissionStatus:"accepted"}`；新需求不进入会变化的回执。状态与报告仍通过assessmentId读取。GET详情返回 inputVersion 与四个需求字段，金额不转number；历史v1新增字段null并显示“当时未采集”。

## 3. 资料完整度

### 3.1 字段集合与计算

完整度由服务端确定性计算，保存 policyVersion、适用字段集合、逐项状态和计算时点。前端只渲染服务端结果，不沿用本机表单百分比充当正式报告结果。**首版已采用等权字段计数，不引入风险权重；DEC-READINESS开发版为self-reported-base-20260924-v1，后续变更需版本化发布。**

已实现首版字段集 `self-reported-base-20260924-v1` 只覆盖已实现资料和新增需求，不声称覆盖说明书尚未接入的全部经营资料：

| 分组 | 个人适用字段 | 企业适用字段 |
| --- | --- | --- |
| 基础描述（2项） | city、occupation | city、occupation（行业） |
| 融资需求（3项） | requestedAmountYuan、requestedTermMonths、purposeCode | 同左 |
| 收入/经营 | monthlyIncome、socialSecurity、housingFund（3项） | annualRevenue、operatingMonths（2项） |
| 债务情况 | totalDebtBalance、monthlyLoanPayment、creditLoanCount、creditCardCount、creditCardTotalLimit、creditCardUsedLimit（6项） | totalDebtBalance、monthlyLoanPayment（2项） |
| 条件项 | purposeCode=other时加入purposeDetail（1项） | 同左 |

因此个人基础分母14、企业基础分母9；选择other各加1。表单无需为达到100%而强迫填写不适用字段。姓名、证件、手机号、企业名称/代码属于身份/提交校验，不计入这个资料完成比例；附件数量、授权选择、第三方付费查询、房车有无均不计分。city有效文本计已填；cityCode未知单独影响地区规则的unknown，不反向把已有城市输入当空。

逐项 `state=provided|missing|invalid|not_applicable`：

- provided：适用且通过类型、枚举、范围校验；合法 `0`、`"0.00"`、`none`、`no` 都是有效回答，不因金额小或选择“无”降低完整度。
- missing：适用但null/未采集；空字符串在请求校验/规范化时处理，禁止写成“未知”字符串冒充已填。
- invalid：历史或内部数据未通过字段校验，不计已填；v2新提交原则上在写库前拒绝。
- not_applicable：由已发布的type/条件规则判定，排除分母；不能由客户端传入，也不能为了提高比例自行排除。

`applicableCount` 为非not_applicable项数，`providedCount`为其中provided项数。`percent=ROUND_HALF_UP(100×providedCount/applicableCount)`，整数0—100，整数/十进制运算，不用二进制浮点。已发布策略的分母为0视为配置错误，任务failed、errorCode=ASSESSMENT_POLICY_INVALID，不生成正式completeness或成功报告，不能给0或100分。未填项按字段清单输出 missingFields；invalidFields单独列出。一致性问题使用 consistencyIssues 记录，不因单字段都已填而消失。

验证样例：个人普通用途14项中11项provided，返回79；企业9项中8项provided，返回89；全部provided且含债务金额为0时仍100。该比例仅表示当前字段集填写情况，与收入高低、产品数量、查询授权无关。

### 3.2 完整度DTO

`completeness={status,policyVersion,providedCount,applicableCount,percent,items,missingFields,invalidFields}`。

- status：evaluated / policy_unconfirmed / legacy_unavailable。
- evaluated时 policyVersion非空，计数/percent为整数，items完整包含 `{fieldKey,label,state}`；字段顺序由策略固定。missingFields/invalidFields为fieldKey数组，可由items复算。
- 规则未发布时 status=policy_unconfirmed，policyVersion/计数/percent=null，items与缺失数组为空；前端展示“资料完整度规则待配置”，不展示0分。可以在其他区域继续呈现实际输入和缺失事实。
- 历史v1报告不事后添加试算分：适配为legacy_unavailable/null，或沿用v1展示“未计算”。新字段集发布只影响新评估，不重算旧比例。

## 4. 融资准备等级

### 4.1 建议策略与发布闸门

首版采用可解释的资料状态；以下规则已按本轮授权落地为 **DEC-READINESS开发版**，生产业务验收仍需人工样例，不使用A/B/C信用分：

| 判断顺序 | 条件 | 已实现code / label |
| --- | --- | --- |
| 1 | 尚无已发布的完整度/准备策略，或记录不支持该输入版本 | code=null；状态policy_unconfirmed或legacy_unavailable；显示未评定 |
| 2 | 存在invalid字段或已定义的consistencyIssues | needs_verification / 需核实资料 |
| 3 | 适用字段存在missing | needs_information / 待完善资料 |
| 4 | 当前字段集全部provided，且无上述问题 | ready_for_review / 可进入资料核对 |

等级依赖实际计数而非四舍五入后的percent，避免99.x%显示100后误升等级。没有任意80/90分门槛；若业务希望使用分档或权重，应先提交版本化规则和人工样例，经确认后另发策略。上述“可进入资料核对”只针对当前自填字段集，即使完整度100也可能缺少银行要求的材料，不代表满足某产品，更不代表已经核验、可以获批或可以申请。

准备等级不读取候选产品数量、不依赖AI生成成功与否、不以收入额度高低给人分级。外部资料未查询单独写 verificationStatus=not_verified 和风险提示；可选授权的拒绝本身不降级。

### 4.2 准备等级DTO与解释

`readiness={status,policyVersion,code,label,basis,verificationStatus}`；status同完整度，未计算时code/label/policyVersion=null、basis=[]。evaluated时保存稳定code、显示标签和 `basis:[{basisId,code,fieldRefs,issueRefs,message}]`，basisId在本报告内唯一且稳定。basis由服务端模板生成，fieldRefs引用本次字段清单，issueRefs引用一致性问题ID。模型可解释既有basis，但无权改code/label/优先级。

`consistencyIssues:[{id,code,fieldRefs,message}]`只使用已发布校验规则。例如 `CREDIT_CARD_USED_EXCEEDS_LIMIT` 引用creditCardUsedLimit和creditCardTotalLimit。历史异常仍保留原值供本人/有权限后台核对，不用AI猜测正确数值。

## 5. 产品匹配与结果解释

2026-09-24已接通发布预检、字段编译、目录冻结、三态判定、productId升序及正式任务落库；不启用评分。快照结构见[产品规则开发契约](产品匹配规则开发契约.md)第7节。本地经用户授权上架6条演示产品，用于联调；匹配读接口/页面、真实产品规则与人工金标准仍待验收。

### 5.1 候选判定与未知值

1. 先验证产品发布状态、有效期、适用对象和配置完整性，冻结本次可评估产品集合。草稿/下架/过期产品不进入本次集合；无真实产品或无已发布规则时 matching.status=unavailable。
2. 产品所引用字段必须在服务器规则白名单内，有已定义类型/单位/来源；不支持的字段或操作符阻止发布。不得从 condition、grade、recommendation、deprecated 等任意描述文本直接推断准入。
3. 每条规则返回 `pass|fail|unknown|not_applicable`。客户端不能指定not_applicable；未知金额、未提供cityCode、未查询的信用信息不能当作0或正常。规则所需证据必须达到 rule.requiredSource=self_reported或verified；自填满足阈值不能冒充verified。
4. 硬规则中任一fail → eligibility=ineligible；无fail但任一unknown → unknown；适用硬规则全部pass → eligible。fail与unknown并存时仍ineligible，同时保留未知项。不能把零条有效硬规则当作默认通过：产品必须有有效发布校验及本节需求规则。
5. 产品配置缺失/非法与用户信息缺失不同。产品amount/term为null不能当“无限制”，regions=[]是全国、regions=null是未配置。配置损坏时整次匹配failed并记录安全错误，不悄悄跳过产品后宣称完整匹配。用户字段缺失才使用unknown。

**需求匹配口径：单产品完整覆盖。** `amountMinYuan ≤ requestedAmountYuan ≤ amountMaxYuan`、`termMinMonths ≤ requestedTermMonths ≤ termMaxMonths`，边界包含；禁止自动修改用户需求、拆金额或拼多个产品凑额度。产品用途白名单放入带版本的eligibility_rules；没有明确用途依据则阻止发布，“其他用途”需人工核实，返回unknown，不从purposeDetail自由文本自动推断。

unknown不是建议申请；ineligible不是永久拒绝。展示应为“本次资料不满足已知条件”或“缺少判断依据”，并说明所用资料未经核验。only eligible进入默认候选列表。

### 5.2 排序、理由与证据

- `score` 为number|null。业务评分尚未定稿时始终null，不显示匹配百分比。DEC-MATCH定稿后才允许0—100的规则匹配指标，存scorePolicyVersion；仍不代表审批概率。overallScore也不由模型生成。
- 发布时必须提供稳定排序策略版本。建议无评分首版按运营已确认优先级、productId升序排序；如优先级尚未配置，显式使用productId升序作为稳定展示顺序，标注“不代表优劣排序”。不可临时用AI结果排序。
- eligible项rank从1递增；ineligible/unknown的rank=null，不进入候选排名。默认最多展示三家且有查看更多；其他结果独立显示“条件不符”与“待补资料”，不混入推荐卡片。若提供额度/利率排序，仅改变客户端显示顺序，不覆盖历史rank。
- 推荐依据 `positiveReasons`、不符条件 `blockingReasons`、待核实/注意事项 `cautions` 分开保存。首页各组最多展示三条；没有证据就不生成，详情可读完整列表。通过部分条件的不适配产品，其positiveReasons不能标成“推荐该产品”。
- 理由 `{reasonId,code,text,evidenceRefs}` 由确定性规则/模板生成，evidenceRefs至少一个且只引用本项证据。失败条件、未知依据全部保存，不能因为只展示三条而丢掉阻断项。产品公共优势不是用户个性化理由。
- 证据 `{evidenceId,ruleId,ruleVersion,kind,fieldRefs,operator,expected,actual,outcome,source,observedAt}` 固定类型、单位和来源。evidenceId在整份报告内唯一且稳定，例如由productId、ruleId和条目序号组成，不能让不同产品的同名规则共用ID。kind=hard/soft，source=self_reported/verified/product_snapshot；expected/actual金额保持元字符串，未知actual=null。规则快照保存requiredSource，复核时能判明证据是否够用。
- 单项 `aiExplanation={status,text,evidenceRefs}`，status=not_requested/completed/failed；只解释服务端已生成的理由，不能新增规则、伪造优势/风险或改判定。模型内容缺证据、含审批承诺或改写数值时拒绝保存该段，保留规则理由并显示解释暂不可用。不存在“必须每家补足三正三反”的生成要求。

证据类型增补：source在事实完全缺失/无法确定来源时允许null，不捏造self_reported/verified；observedAt未知也为null。额外提供requiredSource、reasonCode、valueType及unit，现已映射入正式match_result。not_applicable以product_snapshot作为适用范围依据来源。

### 5.3 结果存储与接口

仍在 `fa_ai_chat.match_result` 保存有序JSON数组，数据库键沿用snake_case，DTO层转camelCase；不新建匹配表，不把有序数组改为对象。每项包含：

| API键 | 持久化键 | 类型与约束 |
| --- | --- | --- |
| productId / productVersion | product_id / product_version | string / int；ID传输用字符串，版本为冻结版本 |
| eligibility / rank / score | eligibility / rank / score | eligible或ineligible或unknown；rank:int或null；score:number或null |
| scorePolicyVersion | score_policy_version | 未评分时null |
| reasons | reasons | string[]，保留已有键供服务端迁移兼容；由positive/blocking/cautions确定性汇总，不能作为唯一证据 |
| positiveReasons / blockingReasons / cautions | positive_reasons / blocking_reasons / cautions | 理由对象数组 |
| evidence / aiExplanation | evidence / ai_explanation | 证据数组及可空解释对象，嵌套对象也显式映射键名 |
| productSnapshot | product_snapshot | 不可变产品参数、适用对象/地区/用途规则、材料、来源引用、采集/更新时间、产品版本；金额元字符串，期限月，年化百分数字符串 |

`Assessment::complete()`现已对v2按冻结目录复算并比对整个匹配数组与统计，允许未评分score=null及非候选rank=null，禁止非法组合/引用写入；v1保留旧格式。匹配读接口尚未实现。19项正式任务测试已覆盖合法null落库及旧冻结引擎兼容。

聚合对象 `matching={status,reasonCode,ruleVersion,orderingPolicyVersion,catalogSnapshotId,candidateCount,ineligibleCount,unknownCount}` 存在report_data，不放入match_result数组头部：

- status=unavailable：未运行，reasonCode=PRODUCT_CATALOG_UNAVAILABLE / MATCH_RULES_UNPUBLISHED / LEGACY_INPUT / DEMAND_INCOMPLETE；三个计数为null，match_result=[]。
- status=completed：已完成规则执行，计数为非负整数，允许candidateCount=0；应结合另外两个计数解释原因，不能把unknown说成不符合。
- status=failed：执行器/存储/配置异常，计数null；整次评估维持failed，不向报告接口暴露部分成功的正式报告。失败信息由状态接口提供，需用户重试。

未具备真实产品时，可以先成功生成需求/完整度自填报告并标unavailable；这只是内部开发支线，**不改变一期必须完成真实产品匹配及外部渠道验收的既定范围**。

| 方法/路径（/api/v1前缀） | 实施状态 | data与行为 |
| --- | --- | --- |
| GET /assessments/:id/report | 已支持v1/v2自填支线 | 本人成功记录；resultVersion辨识格式，未完成409、越权/不存在404；no-store |
| GET /assessments/:id/matches | 计划新增 | 参数eligibility默认eligible，可选ineligible/unknown；limit默认3、1—50，cursor可空。data={assessmentId,resultVersion,matching,items,hasMore,nextCursor}；unavailable返回200＋空数组及明确状态，不冒充零候选 |
| GET /assessments/:id/matches/:productId | 计划新增 | 只返回本次已评估的产品结果/全部理由/快照；未在快照内或越权404。不能拿公共当前产品临时拼出旧评估结论 |
| GET /products/:id | 计划新增 | 公开当前产品资料；无用户等级、理由或匹配分；与个人化结果分离 |

matches只读成功评估，未成功409；参数错误422。服务端先鉴权归属，再解析游标；游标绑定assessmentId、resultVersion、冻结结果摘要、eligibility和偏移量，非法/不匹配游标422。快照不可变，分页不能混用当前产品列表。v1成功报告也可返回matching.status=unavailable/reasonCode=LEGACY_INPUT；不回填历史match_result。

当前产品是否下架单列 `currentAvailability=available|unavailable|unknown`，由读取时受限查询得到，不写回productSnapshot、不改历史rank；当前不可用或查询失败时，申请准备页说明状态，不能继续显示“立即申请”。本项目仍只做资料引导，不向银行提交申请。

## 6. 报告v2与任务快照

### 6.1 报告组合契约

`resultVersion=2`、`reportType=financing_needs_analysis`。服务端组装报告：

| 字段 | 生成方与约束 |
| --- | --- |
| assessmentId、inputVersion、generatedAt、modelCode | 服务端；modelCode为实际指定模型快照 |
| overallScore | 首版null，无已确认评分规则不生成 |
| demand | 服务端冻结 requestedAmountYuan/requestedTermMonths/purposeCode/purposeLabel；不含自由说明正文 |
| facts | 服务端白名单事实，fieldKey、valueType、value、unit、source、observedAt；金额value为元字符串、月/数量为int、枚举为code、未知null；不含身份资料 |
| completeness、readiness、consistencyIssues、matching | 服务端按第3—5节计算；模型无修改权限 |
| summary、strengths、improvements、riskWarnings | AI定性文本；summary为string，后三者为 `{text,evidenceRefs}[]`，证据不足可为空；风险提示另含服务端固定“自填未核验”等提示 |
| disclaimer、policyVersions、systemWarnings | 服务端固定模板及版本集合；systemWarnings为固定风险提示字符串数组，独立于模型风险引用；政策、字段字典和模型版本不能省略 |

报告标准区块为“需求概况—资料完整度—准备等级—主要优势—待完善项—风险提示—候选及解释—免责声明”。不必为每个区块生成长文本；缺数据时明确未提供。需求金额/期限、比例、等级、匹配理由通过结构化事实呈现，AI正文继续只作定性解释。

v2模型输出不直接作为完整Report入库。服务端仅接受固定四个模型字段summary/strengths/improvements/riskWarnings；summary 2—600字符，各数组0—6项，每text 2—400字符，每条evidenceRefs 1—5个且去重，只引用输入的facts/ruleEvidence/readinessBasis公共引用ID。统一引用命名空间 `fact:<fieldKey>`、`rule:<evidenceId>`、`readiness:<basisId>`，使用第4.2/5.2节保存的唯一ID；无引用的优势不能存。外发提供allowedEvidenceRefs，但不传完整度计数/百分比；单项建议1—3个引用，服务端上限仍为5。不得从自填零负债推断信用记录，不得从资料齐全推断受理资格；not_applicable不是缺失。保留禁止数值复述、HTML和控制字符的校验，补中文项数/“为零”等模式；新增结构不得沿用当前只支持observations/suggestions/dataGaps的v1解析器。summary仅概括事实且不能改变结构化结论。

禁止输出保证通过、审批概率、已核验信用良好、内部渠道等无依据结论。语义校验和提示词不能保证模型绝无错误，需用人工金标准样例持续验收；数值、等级和准入结果始终由服务端权威字段控制。主报告结构不合法时任务failed；单产品AI解释失败时保留确定性匹配理由，不触发无限收费重试。

### 6.2 冻结与持久化

- 已为 `fa_ai_chat` 新增 `analysis_context JSON NULL`，仅用于正式assessment会话的依据快照，不新建业务表。快照分成不可覆盖的input_snapshot和execution_snapshot两个部分，分别只写入一次。
- **提交时冻结输入依据：** 正式提交事务在保存fa_user_info和会话的同时写入input_snapshot，已实现inputVersion、normalizationVersion、targetResultVersion及完整purposeDictionary（version、items，含type/code/label/requiresDetail/enabled）。基础字段规范化由固定版本代码处理，未冻结全部字段校验规则全文；未来变更须保留原版本规范化路径。输入原值仍冻结在fa_user_info，不重复存整包身份资料。此时execution_snapshot=null；用途改名/停用不影响已接受输入，读取和分析使用提交时的标签。快照写入失败则整个提交回滚，不能只保存输入而丢失其解释依据。
- **执行时冻结计算依据（新目标v2已实现自填支线）：** worker首次抢占后、任何外部调用前，在事务内一次性补入execution_snapshot：目标resultVersion、完整度与准备策略、evaluatedAt和匹配不可用原因。本轮真实产品未就绪，productSnapshots=[]、matchingRules/orderingPolicy=null；真实集合、产品快照、匹配规则全文及排序策略随PRODUCT实施，不伪造快照。沿用input_snapshot的输入含义，不重新套用当前用途启用门槛；没有可用策略也保存明确的unavailable原因。
- analysis_context只由服务端写，具有schemaVersion、inputHash、executionHash、contentHash和上述版本集合；以规范化JSON计算SHA-256，输入和执行部分分别校验，executionHash/contentHash在执行部分冻结前为null，冻结后生成且不再变化。快照包含可重现的实际策略内容，不能只留版本号而覆盖后台配置。当前引擎equal-fields-v1的类型范围与舍入算法固定在代码，快照保存definitions/fields/conditionalFields/consistencyRules/readinessOrder/labels及版本；算法变化须支持旧引擎，不原地改旧版本语义。catalogSnapshotId由冻结集合内容摘要形成，不要求新增产品集合表。容量和产品数量须在实际产品规模确定后设置有界限制，超限明确失败，禁止悄悄截断候选范围。
- 失败重试在相同assessmentId下复用已经冻结的两部分快照；更换taskId仅代表新执行尝试。若尚未成功冻结execution_snapshot，则下一次在首次可用的抢占阶段补入并记录当时策略版本，不声称采用提交时未取得的规则；input_snapshot始终不变。重复消费不得覆盖任一已有部分，哈希不符时明确失败。旧v1记录的context可继续为null，不伪造历史字典。
- 需要更新需求、采用最新产品/规则或补充资料时，创建新assessmentId。成功报告不提供“原地刷新结论”。运行中产品下架不能改写快照；读取时另附currentAvailability。外部数据若后续接入，同样先冻结授权结果的来源/时间，不回写原表单。
- 完成事务原子写report_data、match_result、result_version、rule_version、模型快照及succeeded。rule_version标识整套报告策略发布版本；各子策略版本保存在policyVersions/context中。消息与tokens继续写fa_ai_chat_log，未知用量null。
- analysis_context不存密钥、证件或重复整包自由文本；可凭assessmentId读取冻结输入。存取权限按评估归属，公共产品API不返回这些context。后台不得修改已提交输入、context或历史结论。

## 7. 版本兼容与迁移

1. **目标版本冻结（已实施）：** 新提交input_snapshot.targetResultVersion=2；发布前无该标记或显式1则仍使用v1，不因重试升级。`assessment.new_result_version`仅影响新提交，改配置不重算旧报告。

2. **版本相互独立：** inputVersion是提交字段结构，resultVersion是结果JSON结构，policyVersion是计算策略，productVersion是产品修订；不能只用某一个version替代全部。
3. **旧记录不补造：** 新增输入列先可空，input_version默认1，历史需求字段均null，不用收入/负债猜需求；旧报告仍resultVersion=1。v2只在新提交校验中强制需求字段，不能直接给全部历史行加NOT NULL。
4. **兼容窗口：** 服务端先支持v1/v2及双版本报告读取，再发布发送v2的前端。部署配置minNewAssessmentInputVersion明确新建最低版本；兼容窗口可为1，切到2后新requestId缺省或显式1返回422 INPUT_VERSION_UNSUPPORTED。切换时点由发布记录确认，不允许永久依赖缺省v1绕过必填。
5. **幂等优先：** 鉴权后先定位(userId,requestId)。已有记录按其原inputVersion及冻结的normalizationVersion/输入字典做结构校验、规范化并与原规范值比较；v1使用保留的v1规范化路径。同内容仍HTTP201固定回执，即使当前最低版本为2或原用途已停用；不得重新套用当前字典的启用门槛。输入版本或合法内容冲突409 REQUEST_CONFLICT，格式本身非法仍422。不得先套v2必填而拒绝原v1成功请求的重放。软删除旧键仍409，不能重建。
6. **旧重试：** 已有v1失败记录保持v1输入和v1自填分析，不因升级自动获得v2完整度/等级/匹配；迁移时为旧任务选择v1处理路径。若需v2需求分析，用户重新填写并正式提交新记录。旧重试键仍返回原taskId，不换版本重跑。旧报告结构不支持时显示明确格式提示，不用当前规则重新计算。
7. **增量迁移（本地已执行，部署其他环境仍须预检）：** 先预检版本/异常金额/业务行数，备份目标结构与数据；追加fa_user_info五个字段、fa_ai_chat.analysis_context；新增金额/期限非负和范围CHECK允许历史NULL，用途字典在服务端校验。稳定查询确有需求再加索引，不为每个需求字段预先建索引。迁移工具需可重复执行、校验列类型与约束，不只检查列名。
8. **回滚：** 发布前停止或排空旧worker，再部署支持新context和v1/v2的消费者；重启后验证积压任务。回滚优先关闭新建v2、保留新列和兼容读取；存在v2任务/报告时不得直接退回只认v1的旧代码、删列或覆盖备份。恢复备份须先核对备份后新增业务数据，不自动重跑旧空库迁移。


## 8. 验收样例与任务归属

以下为验收条件全集。需求输入、字典/历史冻结、版本回放及重试保持已由76项专项检查和H5验证；41项基础、29项任务、15项HTTP回归通过。新增54项覆盖完整度/准备状态、执行快照、报告v2与模型引用校验，H5已验证个人79%、企业100%和未发布无分。三态匹配、真实产品证据、v2真实模型语义与渠道验收仍待完成，不能以已通过子集替代。

| 场景 | 验收结果 | 任务 |
| --- | --- | --- |
| 需求金额 | 12.345678万元精确往返123456.78元；0/负数/超上限/JSON number拒绝 | ASSESS-001、ASSESS-003、ASSESS-004 |
| 期限与用途 | 期限整数边界通过；0/小数拒绝；other缺说明拒绝，非other带说明拒绝，跨类型用途拒绝 | ASSESS-001、ASSESS-003 |
| 原键重放 | 同键同内容仍原回执；只改金额/期限/用途/说明/版本任一项409 | ASSESS-003 |
| 用途版本变化 | 提交后改名/停用不改旧标签，不阻断原键重放；新提交按当前发布字典校验 | ASSESS-003、REPORT-002 |
| 版本切换 | 最低新建版本2时，旧v1原键可重放，新v1键422；旧报告/失败重试保持v1 | ASSESS-002、ASSESS-003、REPORT-002 |
| 完整度 | 个人11/14=79，企业8/9=89；0/none计已填、null不计；other增加条件项 | REPORT-003 |
| 等级 | 未发布规则无分数/等级；所有字段已填但一致性异常仍需核实；100%不表示授信 | REPORT-003、REPORT-004 |
| 授权与来源 | 拒绝可选查询不扣完整度，不宣称信用正常；verified要求不可用self_reported替代 | FILE-004、PRODUCT-002、REPORT-003 |
| 产品边界 | 金额/期限等于上下界通过，超界fail；不拆额度、不改需求；other用途unknown | PRODUCT-002 |
| 三态合并 | fail＋unknown→ineligible并保留两类证据；无fail有unknown不得进入候选 | PRODUCT-002 |
| 配置异常 | 无支持字段/非法操作符/用途或地区配置缺失阻止发布；运行配置损坏或完整度分母0明确failed，不生成成功报告 | PRODUCT-001、PRODUCT-003、REPORT-003 |
| 解释证据 | 所有理由可追溯到冻结规则/事实；不凑三条；模型不能改判定或宣称获批 | PRODUCT-004、REPORT-003 |
| 空结果 | 未运行unavailable≠已运行零候选≠执行failed；unknown单列显示 | PRODUCT-004、REPORT-004 |
| 快照与分页 | 改价/下架/规则更新不改历史；游标绑本人评估和结果；跨账户详情404 | ASSESS-002、PRODUCT-004 |
| 历史写入 | score/rank合法null可以写；违规组合拒绝；报告和匹配同事务，无部分成功报告 | REPORT-003 |
| 输入最小化 | 模型无手机号/证件/自由用途说明；任意文本不影响规则；错误日志不泄露资料 | ASSESS-003、REPORT-001 |
| 任务跨发布 | worker重启、重复消费、过期和重试保持冻结版本，旧taskId无权回写 | REPORT-002 |

实施顺序：DEC-DEMAND定用途/必填和字段 → ASSESS-001迁移与字典 → ASSESS-003 v2校验和幂等 → ASSESS-002/004确认与历史 → DEC-READINESS与REPORT-003完整度/等级 → DEC-MATCH、PRODUCT-001/002确定性匹配 → PRODUCT-003真实资料发布 → PRODUCT-004/REPORT-004解释和全链路验收。上下游可独立做规则测试，外部数据和真实产品未就绪时保持完整一期未验收。

本次沿用现有60个任务编号并扩展相关交付项，不把文档完成记成业务完成。原69—117人日是历史全量基线；新增版本兼容、上下文快照和解释交互须在上述决策完成后重估，不声称全部增量已包含原工时，也不把基线直接当最新剩余工作量。