freedak/RiskAgent
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
c670b9e454edc15080439e5eb9b3df17cbef2634
RiskAgent/.kiro/specs/outsourcing-risk-assessment/requirements.md
T
freedakgmail c670b9e454 外包风险评估系统：领域引擎+前端+服务端持久化与生产部署 
- 确定性领域引擎(分类/评分/分级/红线/费用/裁决)+LLM(通义千问)语言理解
- 6步评估向导、服务端草稿持久化(跨设备/编辑草稿保护)
- 工作流(草稿→风控→管理层)、RBAC、报告导出、校准、客户/费率/红线/最低工资管理
- 专业图标体系替换全部emoji、看板美化
- 生产化:API_BASE可配置(同源反代)、auth密钥惰性读取修复RBAC
- 444单测+204前端测试+51 e2e
2026-06-13 01:06:39 +08:00

35 KiB
Raw Blame History

Requirements Document

Introduction

本功能构建一个外包项目风险评估 AI 智能体（以下统称 System）。用户输入外包项目描述后，System 基于结构化、可配置的风险指标体系，通过多轮对话式追问补全关键信息，对项目进行多维度加权评分与分级，校验红线，输出可量化的费用/定价测算，并给出"风险是否可接受 + 如何接受 + 如何应对（管理措施与费用措施）"的结论与建议，最终生成可导出的风险评估报告并持久化存档。

System 覆盖五类外包业务：岗位外包、劳务派遣、业务/服务外包、BPO、项目制外包；面向商务/销售、风控、管理层三类角色提供差异化交互与视图；首版实现中国大陆劳动法合规体系，并在架构上以地域参数预留跨境扩展。

本文档定义可验收的功能需求，遵循 EARS 模式与 INCOSE 质量规则。

Glossary

  • System：外包项目风险评估智能体系统整体。
  • Classifier：业务类型与行业识别组件，负责从项目描述中判定外包业务类型与所属行业。
  • Question_Engine：自适应追问引擎，根据信息缺口动态生成补全问题。
  • Config_Center：模型配置中心，供管理员维护维度/指标/权重/模板/红线，并执行配置校验。
  • Scoring_Engine：评分引擎，读取配置对项目进行加权评分、归一化、分级、红线校验。
  • Cost_Engine：费用测算引擎，计算风险溢价、垫资利息、保险费用、准备金及风险调整后报价。
  • Strategy_Engine：应对策略推荐引擎，生成管理措施、费用措施与接受条件清单。
  • External_Data_Adapter：外部数据适配层，可插拔接入企业资信/征信/涉诉/失信/工商等外部数据。
  • Report_Generator：报告生成与导出组件。
  • Knowledge_Base：分行业知识库，按行业分区存储指标、模板、权重、红线、案例与追问话术。
  • Compliance_Rule_Set：地域化合规规则集（社保基数、经济补偿 N/N+1、派遣比例上限、最低工资等）。
  • Risk_Model：风险模型，三层结构 模型→维度(Dimension)→指标(Indicator)→评分项(Scoring_Rule)。
  • Dimension：风险维度，如客户风险、用工与人力风险等，可增删、启停、调权。
  • Indicator：维度下的风险指标，可增删、启停、调权，含评分标准、证据要求、追问话术。
  • Scoring_Rule：指标的评分项，定义 1-5 级风险等级的含义与判定标准。
  • Redline：红线规则，命中即触发一票否决。
  • Template：风险模型模板，按业务类型与行业组织，支持自定义与继承。
  • Risk_Level：单项风险等级，取值 1 至 5 的整数。
  • Risk_Score：归一化后的风险总分，取值范围 0 至 100。
  • Risk_Grade：风险分级，取值为 低 / 中 / 高 / 极高 四级之一。
  • Region：地域参数，标识适用的合规规则集，首版取值为中国大陆（CN）。
  • Assessment：一次完整的项目风险评估记录，含输入、评分、报告与元数据。
  • Administrator：管理员角色，唯一可修改 Risk_Model 配置的角色。
  • Assessor：评估者角色，包含商务/销售、风控、管理层，可使用但不可修改 Risk_Model。
  • Data_Provenance：数据来源标注，取值为 用户输入 / 外部数据 / 智能体假设 之一。
  • Confidence：置信度，标注某一数据点可信程度的量化指标。
  • UI：System 的 Web 用户界面整体，承载评估流程交互、数据可视化与结果呈现。
  • Design_System：统一设计系统，定义可复用组件库、排版层级、配色规范、间距标度与图标集，供 UI 全局一致引用。
  • Color_Token：配色令牌，Design_System 中具名且取值稳定的颜色变量，含风险等级语义化配色（低/中/高/极高）。
  • Theme：界面主题，取值为 明亮（Light）或 暗黑（Dark）之一，决定 UI 的整体配色方案。
  • Viewport：浏览器视口，以 CSS 像素表示的可视区域宽度，用于响应式适配判定。
  • Chart：UI 中的数据可视化图表组件，含风险热力图、风险总分仪表盘、关键风险图、费用对比图与组合对比图。
  • Risk_Badge：风险分级徽章，以语义化配色与文字标签同时呈现 Risk_Grade 的可视化元素。
  • Wizard：向导式分步评估流程组件，将评估过程拆分为带进度指示的有序步骤。
  • Draft：评估草稿，尚未完成的 Assessment 的可保存中间状态，用于断点续评。
  • WCAG：Web 内容无障碍指南（Web Content Accessibility Guidelines）2.1 版本 AA 级，作为 UI 可访问性达标基准。
  • Loading_State：加载态，UI 在数据请求或处理进行中向用户呈现的等待反馈。
  • Empty_State：空数据态，UI 在无可呈现数据时向用户呈现的占位提示。

Requirements

Requirement 1: 业务类型与行业识别

User Story: 作为评估者，我希望 System 从项目描述中识别外包业务类型与所属行业，以便加载匹配的风险模型模板。

Acceptance Criteria

  1. WHEN 评估者提交有效项目描述文本, THE Classifier SHALL 将该项目判定为下列业务类型中 Confidence 最高的唯一一项：岗位外包、劳务派遣、业务/服务外包、BPO、项目制外包。
  2. WHEN 评估者提交有效项目描述文本, THE Classifier SHALL 判定该项目所属行业，并在行业无法判定时输出取值为"未识别"的行业标记。
  3. THE Classifier SHALL 为业务类型判定结果与行业判定结果分别输出取值范围 0 至 1、保留两位小数的 Confidence。
  4. IF 业务类型判定的 Confidence 低于 0.6, THEN THE System SHALL 向评估者展示按 Confidence 由高到低排序、至多 3 项的候选业务类型列表并请求评估者确认。
  5. IF 行业判定的 Confidence 低于 0.6 且行业标记不为"未识别", THEN THE System SHALL 向评估者展示按 Confidence 由高到低排序、至多 3 项的候选行业列表并请求评估者确认。
  6. IF 评估者提交的项目描述文本为空、仅含空白字符或有效字符数少于 10, THEN THE System SHALL 拒绝执行业务类型与行业判定并返回提示项目描述信息不足的错误。
  7. WHEN 评估者修改 System 判定的业务类型或行业, THE System SHALL 采用评估者确认的业务类型与行业作为后续加载模板的依据。

Requirement 2: 模板加载与风险模型实例化

User Story: 作为评估者，我希望 System 根据业务类型与行业自动加载对应的风险模型模板，以便在标准化基线上开展评估。

Acceptance Criteria

  1. WHEN 评估者确认的业务类型与行业确定, THE System SHALL 从 Knowledge_Base 加载与该业务类型和行业组合精确匹配的 Template，并将其实例化为本次 Assessment 的 Risk_Model。
  2. IF 不存在与业务类型和行业组合精确匹配的 Template, THEN THE System SHALL 加载该业务类型的默认 Template 实例化为本次 Assessment 的 Risk_Model，并在本次 Assessment 中输出取值为"未匹配行业专用模板"的标记。
  3. WHEN 加载 Template, THE System SHALL 在实例化的 Risk_Model 中保留该 Template 定义的全部 Dimension、Indicator、权重、Scoring_Rule、Redline、追问话术，以及各 Dimension 与 Indicator 的启用/停用状态。
  4. IF 待加载的 Template 缺少 Dimension、Indicator、权重或 Scoring_Rule 中任一必填组成项，或其同级 Dimension 权重之和或同级 Indicator 权重之和不等于 100%, THEN THE System SHALL 不实例化 Risk_Model、终止本次 Assessment，并向评估者返回指明模板数据错误的提示。
  5. WHERE Template 通过模板继承派生, THE System SHALL 应用父模板的全部组成项配置，并以子模板中存在差异的组成项逐项覆盖父模板的对应组成项。
  6. IF 既不存在与业务类型和行业组合精确匹配的 Template、也不存在该业务类型的默认 Template, THEN THE System SHALL 不实例化 Risk_Model、终止本次 Assessment，并向评估者返回指明无可用模板的提示。
  7. IF 模板继承链中存在循环引用或继承层级超过 5 层, THEN THE System SHALL 不实例化 Risk_Model、终止本次 Assessment，并向评估者返回指明模板继承错误的提示。

Requirement 3: 自适应信息追问

User Story: 作为评估者，我希望 System 针对信息缺口动态追问，以便补全评分所需关键信息。

Acceptance Criteria

  1. WHEN Risk_Model 实例化完成, THE Question_Engine SHALL 将每个处于启用状态且已知信息不足以依据其 Scoring_Rule 判定 Risk_Level 的 Indicator 标记为信息缺口。
  2. THE Question_Engine SHALL 仅为标记为信息缺口的 Indicator 生成追问问题，并按 Indicator 权重由高到低排序；当 Indicator 权重相同时，按其所属 Dimension 权重由高到低排序消歧。
  3. WHEN 评估者回答一个追问问题, THE Question_Engine SHALL 更新对应 Indicator 的已知信息并重新识别剩余信息缺口。
  4. IF 评估者对追问问题给出空回答或不满足证据要求的回答, THEN THE Question_Engine SHALL 保持该 Indicator 的信息缺口标记并返回需补充信息的提示。
  5. THE Question_Engine SHALL 将单个 Indicator 的追问轮次限制在最大追问轮次以内，最大追问轮次为可配置正整数且默认值为 3。
  6. WHERE 某 Indicator 的信息在追问轮次达到上限后仍缺失, THE System SHALL 对该 Indicator 采用行业默认值并将其 Data_Provenance 标注为"智能体假设"。
  7. WHERE 某 Indicator 的 Data_Provenance 已被标注为"智能体假设", THE System SHALL 在该标注被应用后永久保留该标注，即使评估者后续补充了对应信息。
  8. THE Question_Engine SHALL 为每个追问问题关联其对应的 Dimension 与 Indicator。

Requirement 4: 风险评分与归一化

User Story: 作为风控，我希望 System 基于加权模型计算风险得分，以便获得可量化的风险结果。

Acceptance Criteria

  1. THE Scoring_Engine SHALL 为每个启用的 Indicator 计算评分项得分，评分项得分等于该 Indicator 的 Risk_Level（取值 1 至 5）乘以该 Indicator 的权重。
  2. THE Scoring_Engine SHALL 计算每个启用的 Dimension 的得分为其下各启用 Indicator 评分项得分的加权求和。
  3. THE Scoring_Engine SHALL 将各启用 Dimension 的得分加权汇总后线性映射归一化为 Risk_Score，使全部纳入计算的 Indicator 的 Risk_Level 同取最小值 1 时 Risk_Score 映射为 0、同取最大值 5 时 Risk_Score 映射为 100，并将 Risk_Score 四舍五入取整为 0 至 100 的整数。
  4. THE Scoring_Engine SHALL 在汇总计算中仅纳入处于启用状态的 Dimension 与 Indicator。
  5. IF 本次 Assessment 不存在任何启用的 Indicator 或 Dimension, THEN THE Scoring_Engine SHALL 终止评分、不产生 Risk_Score 并返回评分数据不足的错误。
  6. THE Scoring_Engine SHALL 为每个评分项记录其 Data_Provenance（取值为 用户输入 / 外部数据 / 智能体假设 之一）与取值范围 0 至 1 的 Confidence。

Requirement 5: 风险分级

User Story: 作为评估者，我希望 System 将风险总分映射为风险等级，以便快速判断风险高低。

Acceptance Criteria

  1. WHEN Scoring_Engine 完成 Risk_Score 归一化计算, THE Scoring_Engine SHALL 在 0 ≤ Risk_Score ≤ 25 时将 Risk_Grade 判定为"低"。
  2. WHEN Scoring_Engine 完成 Risk_Score 归一化计算, THE Scoring_Engine SHALL 在 25 < Risk_Score ≤ 50 时将 Risk_Grade 判定为"中"。
  3. WHEN Scoring_Engine 完成 Risk_Score 归一化计算, THE Scoring_Engine SHALL 在 50 < Risk_Score ≤ 75 时将 Risk_Grade 判定为"高"。
  4. WHEN Scoring_Engine 完成 Risk_Score 归一化计算, THE Scoring_Engine SHALL 在 75 < Risk_Score ≤ 100 时将 Risk_Grade 判定为"极高"。
  5. THE Scoring_Engine SHALL 为每次 Assessment 输出且仅输出一个 Risk_Grade。

Requirement 6: 红线一票否决

User Story: 作为风控，我希望命中红线的项目被强制判定为不可接受，以便规避不可承受的风险。

Acceptance Criteria

  1. WHEN Scoring_Engine 完成评分, THE Scoring_Engine SHALL 逐条校验本次 Assessment 是否满足每一个启用的 Redline 的触发条件，并将满足触发条件的 Redline 标记为命中。
  2. IF 本次 Assessment 命中任一启用的 Redline, THEN THE System SHALL 将可接受性结论判定为"不可接受"，且该判定优先于基于 Risk_Grade 得出的可接受性判定。
  3. IF 本次 Assessment 命中任一启用的 Redline, THEN THE System SHALL 在报告中列出每个被命中的 Redline 及其被触发的条件与对应的判定依据数据。
  4. THE Scoring_Engine SHALL 独立于 Risk_Score 与 Risk_Grade 的高低执行全部启用 Redline 的校验。
  5. IF 某个启用的 Redline 的触发条件所需数据缺失，或其 Data_Provenance 为"智能体假设"以致无法确定是否命中, THEN THE System SHALL 将该 Redline 标记为"待核实"、在报告中列出该 Redline 并说明无法判定的原因，且不将其计为命中。
  6. WHEN 本次 Assessment 未命中任何启用的 Redline, THE System SHALL 不因红线校验而改变基于 Risk_Grade 得出的可接受性结论。

Requirement 7: 风险热力图与关键风险清单

User Story: 作为管理层，我希望看到风险的可视化分布与关键风险排序，以便聚焦最重要的风险点。

Acceptance Criteria

  1. THE System SHALL 输出以 Dimension 为行、以 Indicator 为列、以 Risk_Level（取值 1 至 5）度量严重度的风险热力图数据。
  2. THE System SHALL 输出按评分项得分由高到低排序的 Top N 关键风险清单，N 为可配置正整数，取值范围 1 至 50，默认值为 10。
  3. WHEN 评分项得分相同, THE System SHALL 先按所属 Dimension 权重由高到低、再按 Indicator 权重由高到低确定其在关键风险清单中的排序。
  4. WHERE 启用的评分项数量少于 N, THE System SHALL 在关键风险清单中输出全部启用评分项。
  5. THE System SHALL 为关键风险清单中的每个风险项提供其所属 Dimension、Indicator、得分与判定依据。

Requirement 8: 费用与定价量化测算

User Story: 作为商务/销售，我希望 System 输出具体金额的风险溢价与成本测算，以便基于风险定价。

Acceptance Criteria

  1. WHEN 风险评分完成且成本输入可用, THE Cost_Engine SHALL 依据 Risk_Grade 与风险评分计算取值为具体金额区间或百分比区间的风险溢价加价区间。
  2. THE Cost_Engine SHALL 计算垫资利息、保险费用、补偿准备金与坏账准备金各项的具体金额，并为每项标注计算所依据的输入项与所采用的费率或参数来源。
  3. THE Cost_Engine SHALL 输出基准报价与风险调整后报价的对比及各项成本拆解。
  4. WHERE 测算所需的成本输入项缺失, THE Cost_Engine SHALL 采用行业默认值并将该输入项的 Data_Provenance 标注为"智能体假设"。
  5. IF 风险评分尚未完成, THEN THE Cost_Engine SHALL 拒绝执行费用测算并返回评分未完成的提示。
  6. THE Cost_Engine SHALL 为每一项测算金额标注其计算所依据的输入项。

Requirement 9: 可接受性结论与应对策略

User Story: 作为评估者，我希望 System 给出明确的可接受性结论与应对方案，以便据此决策与执行。

Acceptance Criteria

  1. WHEN Scoring_Engine 完成评分与红线校验, THE Strategy_Engine SHALL 输出取值为 可接受 / 有条件接受 / 不可接受 之一的可接受性结论。
  2. WHEN 可接受性结论为"有条件接受", THE Strategy_Engine SHALL 输出接受条件清单，且清单中每个条件关联至少一个关键风险清单中的风险项。
  3. WHEN 可接受性结论为"可接受"或"有条件接受", THE Strategy_Engine SHALL 输出管理层面应对措施，且为合同条款、用工合规整改、退场预案、过程监控四类中的每一类各输出至少一项措施。
  4. WHEN 可接受性结论为"可接受"或"有条件接受", THE Strategy_Engine SHALL 输出费用层面应对措施，且为风险溢价定价、预付/保证金、保险转移、账期成本、准备金计提五类中的每一类各输出至少一项措施。
  5. WHEN 可接受性结论为"有条件接受", THE Strategy_Engine SHALL 为接受条件清单中每个条件输出取值为具体金额或金额区间的成本影响测算。
  6. WHERE 本次 Assessment 未命中任何启用的 Redline 且 Risk_Grade 为"低"或"中", THE Strategy_Engine SHALL 将可接受性结论判定为"可接受"。
  7. WHERE 本次 Assessment 未命中任何启用的 Redline 且 Risk_Grade 为"高", THE Strategy_Engine SHALL 将可接受性结论判定为"有条件接受"。
  8. IF 本次 Assessment 命中任一启用的 Redline 或 Risk_Grade 为"极高", THEN THE Strategy_Engine SHALL 将可接受性结论判定为"不可接受"。

Requirement 10: 评估报告生成与导出

User Story: 作为评估者，我希望 System 生成结构化报告并支持导出，以便归档与共享。

Acceptance Criteria

  1. WHEN 本次 Assessment 的风险评分、红线校验、费用测算与可接受性结论均已生成完成, THE Report_Generator SHALL 生成包含以下内容的报告：项目概要与业务类型判定、风险总分与分级、风险热力图、各维度风险明细、Top 关键风险清单与红线校验结果、可接受性结论、应对方案、假设与信息缺口说明；其中红线校验结果在未命中任一 Redline 时亦明确标注为"无红线命中"。
  2. WHEN 评估者在报告已生成后请求导出报告, THE Report_Generator SHALL 在评估者请求后 30 秒内将报告导出为包含第 1 条全部报告内容的完整且自包含的可下载文件。
  3. THE Report_Generator SHALL 在各维度风险明细中为每个评分项展示评分、判定依据、风险影响、Data_Provenance 与 Confidence。
  4. IF 评估者在第 1 条所述评估流程完成前请求生成或导出报告, THEN THE Report_Generator SHALL 拒绝该请求并返回指示评估流程尚未完成的提示。
  5. IF 报告导出过程失败, THEN THE Report_Generator SHALL 中止本次导出、保留已生成的报告内容不变，并向评估者返回指示导出失败的错误。

Requirement 11: 管理员配置风险模型

User Story: 作为管理员，我希望统一配置维度、指标、权重、模板与红线，以便维护风险模型而无需改动代码。

Acceptance Criteria

  1. WHERE 操作者角色为 Administrator, THE Config_Center SHALL 允许对 Dimension 与 Indicator 执行新增、删除、启用与停用操作，且对停用项保留其配置数据但不纳入评分。
  2. WHERE 操作者角色为 Administrator, THE Config_Center SHALL 允许将 Dimension 权重与 Indicator 权重调整为取值 0 至 100 的值，并在保存时自动按比例归一化使同级启用项权重之和等于 100% 且保留两位小数。
  3. WHERE 操作者角色为 Administrator, THE Config_Center SHALL 允许自定义 Indicator 的 Scoring_Rule、证据要求与追问话术，且自定义的 Scoring_Rule 须覆盖 Risk_Level 1 至 5 各级的判定标准。
  4. WHERE 操作者角色为 Administrator, THE Config_Center SHALL 允许配置 Redline 规则，且每条 Redline 含唯一标识、触发条件与一票否决后果。
  5. WHERE 操作者角色为 Administrator, THE Config_Center SHALL 允许将当前配置另存为自定义 Template 并支持基于已有 Template 派生新 Template。
  6. WHEN Config_Center 保存配置, THE Config_Center SHALL 校验权重合法性、必填项完整性与红线唯一性。
  7. IF 配置校验失败, THEN THE Config_Center SHALL 拒绝保存、保留上次有效配置不变并返回指明失败项的校验错误。
  8. IF 某同级启用项权重之和为 0 以致无法归一化, THEN THE Config_Center SHALL 拒绝保存并返回权重校验错误。

Requirement 12: 配置访问权限控制

User Story: 作为系统所有者，我希望仅管理员能修改风险模型，以便保证评估模型的一致性与可信度。

Acceptance Criteria

  1. IF 操作者角色为 Assessor 且请求修改 Risk_Model 配置, THEN THE System SHALL 拒绝该修改请求、保持当前 Risk_Model 配置不变，并向操作者返回指示权限不足的错误。
  2. WHERE 操作者角色为 Assessor, THE System SHALL 允许使用当前 Risk_Model 执行评估。
  3. IF 请求修改 Risk_Model 配置的操作者角色既非 Administrator 也非 Assessor（含未认证或未授权操作者）, THEN THE System SHALL 拒绝该修改请求、保持当前 Risk_Model 配置不变，并返回指示权限不足的错误。
  4. WHEN System 成功提交一次 Risk_Model 配置变更, THE System SHALL 记录该变更的操作者身份、变更时间（精确到秒）与发生变更的配置项标识。
  5. WHEN System 拒绝一次 Risk_Model 配置修改请求, THE System SHALL 记录该被拒绝请求的操作者身份与请求时间（精确到秒）。

Requirement 13: 角色化交互与视图

User Story: 作为不同角色的用户，我希望获得与我职责匹配的交互深度与视图，以便高效完成本职工作。

Acceptance Criteria

  1. WHEN 商务/销售角色用户打开一个已完成的 Assessment, THE System SHALL 展示包含可接受性结论、接受条件清单与风险调整后报价的视图。
  2. WHEN 风控角色用户打开一个已完成的 Assessment, THE System SHALL 展示包含评分项明细（含 Risk_Level、判定依据、Data_Provenance）、红线校验结果与信息缺口尽调事项的视图。
  3. WHEN 管理层角色用户打开一个已完成的 Assessment, THE System SHALL 展示包含 Risk_Grade、风险热力图、Top N 关键风险与利润对风险对比的高层看板视图。
  4. WHEN 管理层角色用户请求组合看板, THE System SHALL 展示跨项目汇总的组合看板视图。
  5. IF 用户未分配商务/销售、风控或管理层任一角色, THEN THE System SHALL 拒绝展示评估视图并提示需分配角色。
  6. WHERE 管理层请求的组合看板对应的 Assessment 集合为空, THE System SHALL 展示空组合看板并提示无可汇总的评估。

Requirement 14: 分行业知识库管理

User Story: 作为管理员，我希望按行业分区管理知识库，以便针对不同行业提供专属模型与话术。

Acceptance Criteria

  1. THE Knowledge_Base SHALL 按行业标识分区存储内容，且每个行业分区包含该行业的 Indicator、权重模板、Redline、典型案例与追问话术全部五类内容。
  2. WHERE 操作者角色为 Administrator, WHEN 新增一个行业分区, THE System SHALL 在不修改 Scoring_Engine 源代码的前提下使该行业分区的 Template 可被 System 加载。
  3. WHEN 业务类型与行业确定, THE System SHALL 依据业务类型与行业的组合从 Knowledge_Base 选择对应行业分区中匹配的 Template。
  4. IF 新增的行业分区缺少 Indicator、权重模板、Redline、典型案例或追问话术中的任一类内容, THEN THE System SHALL 拒绝创建该行业分区、返回指明缺失内容类别的校验错误，并保持 Knowledge_Base 中已有分区不变。
  5. IF Knowledge_Base 中不存在与已确定行业匹配的行业分区, THEN THE System SHALL 选择默认行业分区的 Template 并标注未匹配到行业专用分区。

Requirement 15: 外部数据接入与来源标注

User Story: 作为风控，我希望可插拔接入外部可信数据并标注来源，以便提升客户风险评估的客观性。

Acceptance Criteria

  1. WHERE 外部数据源已配置, WHEN External_Data_Adapter 在单次请求 10 秒内收到成功响应, THE External_Data_Adapter SHALL 获取企业资信、征信、涉诉、失信或工商数据用于客户风险相关 Indicator 取值。
  2. THE External_Data_Adapter SHALL 为每个数据点标注取值为"外部数据"的 Data_Provenance 与取值范围 0 至 1 的 Confidence。
  3. IF 外部数据源连接失败、超过 10 秒未返回或返回错误响应, THEN THE External_Data_Adapter SHALL 回退到用户输入并将受影响数据点的 Data_Provenance 标注为"用户输入"。
  4. IF 外部数据回退后用户输入仍不完整, THEN THE System SHALL 将缺失数据点的 Data_Provenance 标注为"智能体假设"并继续执行评估、不中断流程。
  5. THE System SHALL 在不修改 Scoring_Engine 源代码的前提下支持新增外部数据源适配器。

Requirement 16: 地域化合规规则

User Story: 作为评估者，我希望 System 依据中国大陆劳动法规则进行合规相关测算，并在架构上预留跨境扩展，以便当前合规且未来可扩展。

Acceptance Criteria

  1. WHERE Region 取值为中国大陆（CN）, THE System SHALL 加载并应用中国大陆 Compliance_Rule_Set 对本次 Assessment 执行合规判定，判定项覆盖社保缴费基数、经济补偿 N 与 N+1、劳务派遣用工比例上限 10% 与当地最低工资标准。
  2. WHERE Region 取值为中国大陆（CN）, THE System SHALL 依据中国大陆 Compliance_Rule_Set 测算经济补偿（N 与 N+1）金额、社保缴费金额与相关合规费用，并为每项金额标注其所依据的规则项与输入项。
  3. IF 本次 Assessment 的合规判定中存在任一不满足项（社保缴费基数低于法定下限、劳务派遣用工比例超过 10% 或约定薪酬低于当地最低工资标准）, THEN THE System SHALL 将该项标注为合规不通过，并在报告中列出对应规则项与判定依据。
  4. WHEN 创建一次 Assessment, THE System SHALL 记录该 Assessment 所采用的 Region。
  5. IF 创建 Assessment 的请求未指定 Region, THEN THE System SHALL 采用中国大陆（CN）作为该 Assessment 的默认 Region 并标注该 Region 为系统默认值。
  6. IF 请求的 Region 当前无对应 Compliance_Rule_Set, THEN THE System SHALL 拒绝该 Region 的合规判定与费用测算、不为该 Assessment 生成合规结论，并向评估者返回提示该地域暂不支持的消息。

Requirement 17: 评估持久化与历史管理

User Story: 作为评估者，我希望评估结果被持久化并可检索复用，以便查询、复评与跨项目对比。

Acceptance Criteria

  1. WHEN 一次 Assessment 完成, THE System SHALL 持久化存储该 Assessment 的输入、评分结果、报告与元数据，且元数据至少包含业务类型、行业、Region、Risk_Score、Risk_Grade、创建时间与评估者身份。
  2. IF 持久化存储失败, THEN THE System SHALL 保留本次 Assessment 数据于当前会话并返回存储失败的错误。
  3. WHEN 评估者发起对历史 Assessment 的复评, THE System SHALL 基于原 Assessment 的输入创建新的 Assessment 并保留原 Assessment 不变。
  4. IF 复评引用的历史 Assessment 不存在, THEN THE System SHALL 拒绝复评并返回该评估不存在的提示。
  5. WHEN 评估者请求跨项目对比且选中 2 个及以上 Assessment, THE System SHALL 返回被选中 Assessment 的 Risk_Grade、Risk_Score 与关键风险的对比数据。
  6. IF 跨项目对比选中的 Assessment 少于 2 个, THEN THE System SHALL 拒绝对比并提示至少需选择 2 个评估。
  7. WHEN 评估者按业务类型、行业、Risk_Grade 或创建时间范围检索历史 Assessment, THE System SHALL 返回匹配的 Assessment，并在无匹配时返回空结果集。

Requirement 18: 可解释性与证据标注

User Story: 作为风控，我希望每个风险项都有可追溯的依据，以便避免黑箱打分并支撑决策。

Acceptance Criteria

  1. THE Scoring_Engine SHALL 为每个评分项输出非空的判定依据，且该判定依据引用其所属 Dimension、Indicator、Scoring_Rule 及导致该 Risk_Level 的数据点取值。
  2. THE Scoring_Engine SHALL 为每个评分项输出非空的风险影响说明。
  3. THE Scoring_Engine SHALL 为每个评分项输出非空的建议。
  4. THE System SHALL 为每个评分项展示其 Data_Provenance（取值为 用户输入 / 外部数据 / 智能体假设 之一）与取值范围 0 至 1 的 Confidence。
  5. WHERE 评分项的 Data_Provenance 为"智能体假设", THE System SHALL 在报告的信息缺口说明中列出该项。
  6. WHERE 评分项的 Data_Provenance 为"智能体假设", THE System SHALL 为该项输出关联对应 Indicator 的建议补充尽调事项。

Requirement 19: 统一设计系统与视觉规范

User Story: 作为评估者，我希望 UI 在所有页面采用统一的组件、排版与配色规范，以便获得专业一致的使用体验。

Acceptance Criteria

  1. THE UI SHALL 在全部页面从同一 Design_System 引用按钮、表单控件、表格、卡片、对话框、导航与提示组件，且同类组件在不同页面的外观与交互行为一致。
  2. THE Design_System SHALL 定义不少于 4 级的文本排版层级，每级具有具名标识、固定字号与固定行高，且 UI 的全部文本从该排版层级取值。
  3. THE Design_System SHALL 为 Risk_Grade 的 低、中、高、极高 四级各定义一个唯一且稳定的 Color_Token，且 UI 在 Risk_Badge、风险热力图与关键风险图中对同一 Risk_Grade 一致使用其对应 Color_Token。
  4. THE Design_System SHALL 定义以 4 像素为基数的间距标度，且 UI 组件间距取值为该基数的整数倍。
  5. THE Design_System SHALL 提供单一来源的图标集，且 UI 的全部图标从该图标集引用。
  6. THE UI SHALL 提供 明亮（Light）与 暗黑（Dark）两种 Theme，并在切换 Theme 时对全部页面应用所选 Theme 对应的 Color_Token。
  7. WHEN 用户在一次会话内切换 Theme, THE UI SHALL 在 1 秒内对当前页面应用所选 Theme 且不丢失当前页面已录入的数据。

Requirement 20: 数据可视化的专业呈现

User Story: 作为管理层，我希望风险与费用数据以专业、易读的图表呈现，以便快速理解评估结论。

Acceptance Criteria

  1. THE UI SHALL 提供风险热力图、风险总分仪表盘、Risk_Badge、Top N 关键风险图、费用拆解图、基准报价与风险调整后报价对比图，以及跨项目组合对比图。
  2. THE UI SHALL 为每个含两个及以上数据系列或类别的 Chart 提供图例，且图例标签与 Chart 中对应数据元素一致。
  3. THE UI SHALL 为每个 Chart 的坐标轴、数据点或分区提供文本标签，且标签文本不被相邻元素遮挡。
  4. WHILE 某个 Chart 对应的数据为空, THE UI SHALL 为该 Chart 呈现 Empty_State 并提示无可展示数据。
  5. WHILE 某个 Chart 对应的数据正在请求或计算中, THE UI SHALL 为该 Chart 呈现 Loading_State。
  6. THE UI SHALL 在风险总分仪表盘中同时呈现 Risk_Score 数值与其对应的 Risk_Grade。
  7. THE UI SHALL 在费用对比图中同时呈现基准报价金额、风险调整后报价金额及二者差额。

Requirement 21: 便捷易用的评估流程

User Story: 作为评估者，我希望评估流程有清晰引导与顺畅交互，以便高效完成评估而不遗漏关键信息。

Acceptance Criteria

  1. THE UI SHALL 以 Wizard 形式将评估流程拆分为有序步骤，并在每一步呈现当前步骤序号、步骤总数与已完成步骤的进度指示。
  2. WHEN 评估者在 Wizard 中从对话式追问切换至表单录入或从表单录入切换至对话式追问, THE UI SHALL 保留切换前已录入的数据。
  3. WHILE 本次 Assessment 存在标记为信息缺口或待补充的项, THE UI SHALL 以区别于常规文本的醒目样式呈现全部该类项并提供定位至对应录入位置的入口。
  4. THE UI SHALL 为提交评估、保存草稿与导出报告各提供一个一键触发的操作入口。
  5. WHEN 评估者请求保存草稿, THE UI SHALL 将当前 Assessment 持久化为 Draft 并保留全部已录入数据。
  6. WHEN 评估者打开一个已保存的 Draft, THE UI SHALL 恢复该 Draft 的全部已录入数据并定位至保存时所处的 Wizard 步骤。
  7. IF 评估者在存在未保存修改时请求离开当前评估流程, THEN THE UI SHALL 提示存在未保存修改并请求确认。

Requirement 22: 响应式与多视口适配

User Story: 作为评估者，我希望 UI 在不同分辨率下都能正常使用，以便在多种设备上查看评估结果。

Acceptance Criteria

  1. THE UI SHALL 在 Viewport 宽度大于等于 1280 CSS 像素时以桌面布局呈现全部功能。
  2. WHILE Viewport 宽度处于 768 至 1279 CSS 像素, THE UI SHALL 调整布局使全部内容在不产生横向滚动条的前提下完整可见。
  3. WHILE Viewport 宽度小于 768 CSS 像素, THE UI SHALL 在看板视图中保留 Risk_Score、Risk_Grade 与 Top N 关键风险清单的呈现。
  4. WHEN Viewport 宽度变化跨越布局断点, THE UI SHALL 应用与当前 Viewport 宽度匹配的布局且不丢失当前页面已录入的数据。

Requirement 23: 可访问性达标

User Story: 作为依赖辅助技术的用户，我希望 UI 满足无障碍标准，以便我能够无障碍地完成评估操作。

Acceptance Criteria

  1. THE UI SHALL 使全部交互控件可通过键盘获得焦点并触发其操作。
  2. WHILE 某交互控件获得键盘焦点, THE UI SHALL 为该控件呈现可见的焦点指示。
  3. THE UI SHALL 使正文文本与其背景的对比度不低于 4.5:1，使大号文本与其背景的对比度不低于 3:1。
  4. THE UI SHALL 为每个表单输入控件关联可被辅助技术识别的文本标签。
  5. IF 表单校验失败, THEN THE UI SHALL 为每个校验未通过的输入控件呈现可被辅助技术识别的错误提示文本。
  6. THE UI SHALL 在 Chart 中以颜色之外的文本标签或图案区分各数据类别，使数据类别不依赖颜色即可识别。

Requirement 24: 操作反馈与状态提示

User Story: 作为评估者，我希望每次操作都能得到清晰反馈，以便了解系统状态并在出错时知道如何修正。

Acceptance Criteria

  1. WHILE 一次用户触发的操作正在处理中, THE UI SHALL 呈现 Loading_State 指示该操作进行中。
  2. WHEN 一次用户触发的操作成功完成, THE UI SHALL 呈现指示操作成功的反馈。
  3. IF 一次用户触发的操作失败, THEN THE UI SHALL 呈现可读的错误信息，且该错误信息说明失败原因并提供指向修正路径的操作入口。
  4. WHILE 报告导出操作正在执行, THE UI SHALL 呈现进度反馈，且在评估者请求导出后 30 秒内呈现导出完成或导出失败的结果。

Requirement 25: 角色化默认视图

User Story: 作为不同角色的用户，我希望登录后直接进入与我职责匹配的视图，以便减少导航成本快速开展工作。

Acceptance Criteria

  1. WHEN 商务/销售角色用户登录, THE UI SHALL 将该用户默认导航至面向商务/销售的视图。
  2. WHEN 风控角色用户登录, THE UI SHALL 将该用户默认导航至面向风控的视图。
  3. WHEN 管理层角色用户登录, THE UI SHALL 将该用户默认导航至面向管理层的高层看板视图。
  4. THE UI SHALL 在默认视图中将与当前用户角色匹配的功能入口呈现于不需额外导航即可见的位置。
  5. IF 登录用户未分配商务/销售、风控或管理层任一角色, THEN THE UI SHALL 呈现提示需分配角色的视图且不呈现评估数据。
Reference in New Issue View Git Blame Copy Permalink