huawu矿业收购决策系统：需求文档

版本：v1.1 / 首期需求基线
日期：2026年10月6日
状态：依据业务方逐轮确认及“没有了继续吧”整理为首期需求基线；实现细节以SPEC和设计评审稿补充
适用阶段：需求定义；不包含技术选型、系统架构和实现SPEC

v1.1修订说明：原章节仍定义首期模拟范围；末章补充后续Z.ai模型及专项训练设计。没有新增首期真实服务，也没有实施或验收后续能力。

1. 文档目的与执行顺序

明确系统要解决的业务问题、用户、流程、数据、功能、边界与验收方式，为后续SPEC、设计、架构和并行开发提供可追溯依据。

按以下顺序推进，每阶段形成可审阅产物：

1. 需求：确认业务范围、规则、优先级及验收目标，形成需求基线。
2. SPEC与设计：将需求转成字段定义、规则、状态、交互、接口行为及测试情景，并设计页面与用户操作流程。
3. 架构细化：确定模块边界、数据契约、安全边界、依赖与部署方式，记录选型理由。
4. 开发拆分：形成agent任务书、文件或模块归属、接口契约、交付物与检查清单。共享契约先确定，再开展可独立任务的并行开发。
5. 开发与集成：按任务执行，维护需求到实现和测试的映射。
6. 验收：依据已批准文档及固定测试数据验收，区分演示验收、技术验收与业务有效性验证。

需求阶段已完成。当前进入SPEC与交互设计，尚未开展架构实施或agent开发。此前静态演示文件不属于本基线交付。

2. 需求依据与确认状态

2.1 已由业务方确认

2.2 尚属建议，不能视为已确认

此前讨论的5—7人核心团队、具体审批机制、岗位数量、开源组件、流程关口和估值方法均为建议，须在需求阶段确认。开源项目仅为候选参考，不代表最终采用。

尚未确认系统预算、上线日期、部署环境、用户数、模型服务、资料出境限制、自动采集范围、正式版是否覆盖投产经营。

3. 业务目标与评价方法

系统应将原始资料、事实与疑点、技术经济假设、计算结果、交易条件和专业意见记录连接起来。

不将短期矿价涨跌、单个项目盈利或AI回答流畅度作为系统有效性的唯一证明。不承诺AI能够保证储量真实性、交易安全或投资收益。

4. 范围与交付层次

4.1 首期应覆盖的业务闭环

项目登记与初筛 → 桌面初评 → 尽调计划与费用测算 → 专项核验 → 增值与退出情景估值 → 方案比较与评估报告 → 价值提升计划跟踪及评估更新。销售、最终投资决策和交易审批在本系统范围外。

首期应能覆盖三项核心目标，不应只交付问答机器人或项目看板。

4.2 原型、试点与正式版的区别

模拟原型通过不能等同于真实项目有效性、法律合规或生产安全通过。

4.3 已确认的首期交付范围

首期使用模拟数据验证流程。首期应实际实现项目筛选、证据状态管理、尽调任务、可复算情景估值、分析质量提示、历史记录和摘要导出等交互；AI解析、问答、区域图层和专家意见可采用预设模拟结果，但必须在界面与导出中标明。

首期不导入真实敏感资料、不调用实际AI服务、不接入外部业务数据，不交付生产权限、安全及运营能力。已确认修改应在关闭重开后保留；保存范围、方式和重置规则在SPEC中定义，用户必须知道是否保存成功。

模拟资料至少覆盖勘探与待建两个阶段，包含正常、缺失、冲突和明确阻断事项。原型需验证：未知不是低风险、核验不是批准、条件变化需要复审；勘探项目不能因远期DCF为正自动获得收购批准。

第8节P0表示目标业务系统闭环的重要性，不代表所有P0能力都要在演示阶段完整实现。SPEC须逐项标记“实际交互”“预设模拟”或“后续试点”，不能将模拟能力计为真实功能完成。

4.4 已确认的主要交易路径

首期至少提供直接受让矿业权、收购持权公司股权各一个模拟案例，展示两种结构对尽调、估值和交易条件的不同影响。项目阶段与交易结构是独立维度：勘探项目不自动对应合作勘探，待建项目也不自动对应股权收购。

合作勘探与分阶段取得权益保留结构标签和业务说明；完整合同、付款里程碑和增持计算暂不作为首期强制演示能力。后续如选为试点，再补齐专项规则。

两条主要路径的法律条件由专业人员核定；原型采用明示的模拟条件，不形成通用法律结论。

4.5 已确认的资金评估原则

不设置统一的单项目金额门槛，不仅因项目资金需求较大自动淘汰。按项目阶段、交易结构和开发方案评估所需资金，再由授权人员确认投入约束与预算。

• 分别展示收购对价、交易费用、补充勘探、建设、营运资金及其他适用投入，避免混淆收购价与总资金需求。
• 展示分阶段现金支出和时间，注明测算范围、资金来源、尚未落实资金及压力情景；全项目投资与公司实际出资采用各自明确口径。
• 区分测算金额、申请金额和批准预算；尚未确定预算不能解释为零或无限额度。
• 对已批准预算跟踪使用及超支风险；超支或关键假设变化标记相关资金分析需更新，不执行预算审批。
• 最高可接受报价仍需基于项目收益与风险要求等明确约束；没有统一投入范围不等于可自动确定报价上限。

首期模拟案例展示上述状态与资金拆分，不表示真实融资已经落实。具体收益分析口径和融资安排尚待确认。

4.6 已确认的投资与退出策略

首期以“收购—补充勘探与技术核验—提升可被买家认可的项目价值—转让退出”为主要投资闭环。资源价值提升可能来自新增资源、提高可信度、改善技术经济证据或解决关键约束；具体增值方式须由证据支持，不能将资源量增加直接等同于售价增加。

每个项目需要表达：入场依据、增值计划、阶段预算、关键成果、退出估值条件、退出交易结构和时间情景。销售系统负责买家信息与跟进；本系统只使用必要的退出评估输入。

估值分为两个层次：

1. 投资退出模型：测算收购与后续投入、可能退出净所得和时间，比较成功增值、部分增值、延期、退出受阻或失败等情景；作为投资回报与报价讨论的主要依据。
2. 买家经济性参照：必要时分析矿山开发现金流，解释潜在买家为什么认可该项目；不得直接将开发净现值当作公司的退出售价。

退出收入需注明交易范围、证据、参考日期与适用限制，可依据经核实可比交易、买方报价或有依据的估值区间。没有证据的退出价格须标为假设；不机械套用每吨资源单价，不默认市场始终有买家。

展示退出税费与交易费用、承担义务、资金占用和延期成本。折现率、目标收益及情景概率未确认时保持待定，不任意填入行业默认值。按交易结构明确项目层面与公司权益层面的现金流，避免重复扣减债务或费用。

首期增加价值提升计划、里程碑和退出情景交互。完整生产运营系统不在首期范围。

4.7 已确认的销售系统边界

本系统聚焦矿业项目的收购价值、风险、尽调、增值投入与投资退出分析。买家档案、联系人、需求采集、沟通纪要、意向分级、销售机会、买家匹配及客户跟进均不在现阶段范围。

公司通常有明确买家才启动项目是业务背景，本系统不据此增加销售立项关口，不强制用户登记买家、录入口头需求或维护承诺状态。

退出估值所需的价格区间、时间、费用及成立条件可由评估人员录入，或依据销售侧提供的材料形成输入。保留这些输入的来源、日期与假设状态，但不要求建立买家实体或解析销售需求。首期不建设与销售系统的自动接口。

退出假设改变时更新估值并按评估规则复审；本系统不负责监测买家沟通或销售状态。退出假设不足时明确展示无法确定项，不擅自补出确定收入。

4.8 已确认的价值提升手段

不同项目可组合使用以下手段，不要求每个项目都执行全部手段，也不假定所有权属或许可障碍都能解决。

每项增值行动记录当前基线、待解决问题、预期成果、预算、时间、前置依赖、执行人与复核人。结果区分未开始、执行中、成果待核验、达成、部分达成、未达成及暂停等业务含义；具体状态与规则在SPEC定义。

将“任务完成”“证据确认”“风险变化”和“估值变化”分开。估值影响由明确参数、外部价格依据或有条件情景表达；不将各项预期增值简单相加，避免将资源增量、可信度改善与许可改善重复计价。

首期模拟资料至少包括四类行动的示例、一个前置依赖，以及一次不利结果：例如追加勘探未达预期，或选矿回收率低于原假设。用户应能更新结果、复核证据并看到退出评估和投资建议需要重算或复审。已投入成本不能因项目暂停而消失。

4.9 已确认的经济性判断边界

目前无固定收益指标或门槛。系统不预设统一最低收益、折现率、成功概率或综合分数来决定收购；无固定指标不等于不考虑经济性。

首期作为决策支持，展示口径明确的投资退出现金流、预计净收益、投入与回收金额、回报倍数、资金占用时间、下行情景和资金缺口。适用时可计算年化回报，但必须定义方法；现金流不足、没有可用解或存在多解等情况下明确说明，不强行给出单个数字。具体公式与适用边界在SPEC确认。

保留人工综合意见及理由，将指标与地质证据、权属约束、增值可实现性、退出假设和资金安排一起呈现。不同矿种、阶段与交易结构比较时标明口径和证据差异。

没有目标收益及其他必要约束时，不生成权威的最高可接受报价，不将净现值为正视为充分投资依据。允许评估人员在明确标记的假设下试算价格和回报关系；这些参数是本次试算输入，不自动成为公司投资政策。

R-06应据已知成本、退出条件及经授权的人工意见判断。不能满足数据条件时标记无法判断；有依据的负收益情景应清楚显示，但下行情景为负不自动等于所有方案被否决。

4.10 已确认的决策支持边界

系统输出事实与疑点、资料完整性、专业核验意见、风险及适用规则、增值计划、资金需求、退出情景和可复算估值，支持用户在系统外作出决定。

不设置最终投资决策页面、审批流、投票、收购批准按钮或交割放行。首期也不实现预算审批及交易执行流程；外部确定的预算或条件如需录入，仅作为评估输入，不代表系统授权。

核验人确认的是证据或专业意见，不能解释为批准交易。流程关口改为分析阶段与质量检查；阻断事项表示当前方案存在不宜推进的专业结论或无法分析的条件，不由系统禁止或授权实际交易。

风险清单、参数、意见和评估报告保留版本及操作记录。关键依据变化标记相关分析需更新，并可生成新版报告；不追踪最终投资决议、投票或签约批准。

演示终点是可供讨论的项目评估报告及方案比较，而不是提交审批或获得收购许可。

4.11 已确认的多项目演示及建议案例组合

多项目演示已确认；以下4个案例的数量及具体组合为建议，待SPEC冻结，不代表真实项目或实际投资偏好。案例名称、资料、价格和参数全部虚构，具体数值须在SPEC定义并用独立算例验证。

不以地区或矿种标签预设某类风险必然存在。案例中的问题只来自模拟证据。海外数据结构保留，但首期不因此自动增加真实海外规则或完整海外案例。

每个案例应能查看同一套核心输出：项目与标的、证据缺口、专业意见、增值行动、分阶段投入、退出假设及情景、报告版本。案例之间使用不同资料完整性和不同结果，避免仅换名称和数字。

跨项目对比包括：阶段与交易结构、当前证据质量、关键未解决风险、后续投入、资金占用时间、退出价格依据、适用收益指标及下行情景。按共同估值日期、币种和定义展示；不可比或缺失项明确标记，不填零、不强制给综合排名。

首期至少演示同时选择2个项目比较，并允许查看全部4个项目。修改某项目的参数、核验或方案，仅影响其自身分析；返回项目池时提示该项目更新。保留版本后可以恢复或对照，但不能将一个项目的状态误写到另一个项目。

4.12 已确认的电脑与手机使用范围

首期采用浏览器可访问的响应式体验建议，不额外建设原生手机应用。电脑和手机使用相同的初始模拟案例、参数口径和评估规则；修改分别保存在各自设备，不跨设备同步。

建议功能分配如下，具体页面与交互在设计文档确认：

验收包括：小屏无整页横向溢出、操作可触达、无仅悬停才能获得的信息、提示不被遮挡、表格与数字不截断。局部表格允许带明确提示的横向滚动。关键出处、未知项与估值限制不得为了手机简洁而隐藏到不可发现的位置。

手机与电脑都应可完成项目切换、查看风险证据、修改情景、比较项目与阅读报告的核心路径。触屏选择、数字输入、长名称、长内容和键盘弹出状态纳入检查。测试尺寸与浏览器在SPEC中固定。

4.13 已确认的演示状态保存

关闭并重新打开后恢复模拟参数及核验状态。建议同时保存用户修改的任务结果、增值计划、专业意见、评估版本及相关操作记录，使参数、证据和报告保持一致；具体保存字段由SPEC列明。系统固定案例原始数据须可区分于用户修改。

不默认每次打开都恢复初始案例。保存应有可见状态或最后保存时间；失败时明确提示，不能在未保存时显示已保存。恢复后按已有数据重算或核对结果，不能保留与参数不一致的过期显示。

提供单项目恢复默认和全部重置的建议交互，两者均说明影响范围并在执行前确认，避免误删其他项目。状态损坏、浏览器存储不可用或版本不兼容时，先提示并尽量保留可恢复数据，不静默覆盖为默认。

首期仅保存模拟数据，不据此宣称具备生产备份、安全审计或真实资料保管能力。已确认各设备独立保存、不做跨设备同步。建议采用浏览器本地存储，不为演示状态增加账号、后台数据库或多人协作能力。实际保存边界是同一设备、浏览器配置及访问来源；不同浏览器、隐私模式、访问地址变化或清理站点数据可能导致无法读取原状态。访问方式和存储兼容性在SPEC固定并验收，不能将本地文件来源的存储行为假定为所有浏览器一致。

报告导出与状态备份不同。完整状态导入导出不作为首期默认必需功能；保存版本兼容方式在SPEC确定。首期不做跨设备同步，不将报告下载当作恢复全部演示状态的能力。

4.14 范围建议

首期支持国内重点区域，数据模型保留海外项目必要信息；海外具体国家的规则和数据接入在目标国家确定后验收。

投后阶段首期重点追踪补勘、技术核验、价值提升、交易承诺和退出里程碑；建设信息用于买家经济性或必要增值计划的评估。完整生产调度、设备管理、ERP和实时经营优化后续另行定义。

三维地质建模、物探反演、全自动资源估算、无人审批交易、自动法律结论、无授权大规模采集不作为首期默认功能。

5. 用户与组织职责

岗位是职责边界，不要求每个职责对应一名员工。

建议保持提案、关键参数核验和评估结论之间的独立复核。具体访问与专业核验权限及允许的兼岗情况待确认。

6. 分析流程与质量检查

这些阶段用于组织分析，不是交易或预算审批流程。

资料缺失、冲突和未知不能默认为低风险。核验完成与交易决定分开；关键依据变化后标记相关分析需更新，保留历史。暂停或否决规则在本系统中是专业建议及其依据，不是执行实际交易的控制指令。

6.1 项目否决与暂停规则：共同制定的建议稿

以下规则供业务讨论，除R-04的可重评原则已获确认外，其余具体规则及执行门槛尚待确认，不应作为完整正式投资政策自动执行。法律及技术认定须由相应专业人员完成，并说明证据、适用范围和时间。

处理分为四类：

1. 否决：关键事实已核实且不存在合法、技术或公司可接受的解决路径，停止正常收购推进。
2. 暂停：事实不明、条件未满足或解决路径尚待证明，允许有明确上限的补证或研究，不允许视为已通过收购关口。
3. 附条件继续：存在可行处理路径，责任、费用、期限与失败后果明确；继续评估不等于授权付款或交割。
4. 风险定价：可量化且符合经确认的风险承受要求，将影响纳入估值、预算和交易条款。不能用价格折让覆盖不可合法解决的障碍。

6.2 规则展示与原型表现：建议稿

• 每条规则显示未评估、待核实、存在阻断、附条件可评估或已处置等业务含义，附认定人、时间、证据及适用方案。
• AI提示可能的问题，专业人员确认意见；无记录不等于无风险。
• 阻断项或缺失项影响评估完整性与建议，不形成批准、否决交易的系统权限。
• 新证据或方案调整可形成新版评估，但不能抹去原问题；报告显示处理依据和残余风险。
• 已确认允许关键地质或化验造假在独立重建及条件调整后重评；其他诚信问题不自动套用该原则。
• 原型演示资料不足、补证完成、确认阻断和重报价四类情况，并展示评估结论、限制及版本如何变化，不设置提交审批按钮。

6.3 已确认的造假事项重评路径

仅针对已确认的卖方关键地质或化验数据故意伪造：允许独立重建与调整交易条件后重新评估。具体重评材料与权限如下为建议，待后续规则确认。

1. 标记当前方案需重评，将受影响数据、资源解释及模型标记为不可直接沿用或需复核；保存原件、问题范围及认定证据，不删除、不覆盖。
2. 制定独立重建计划，明确样品与原始数据来源、质量控制、执行机构、复核人、预算及通过标准。可信的未受影响数据可以在说明依据后复用；不能把原报告换名作为重建。
3. 按重建结果重新确认资源依据、可实施性及退出情景，列明部分重建、失败及成本超支结果。已发生核验和重建费用计入项目投入。
4. 法律与财务人员核查历史责任及合同保护的可执行性。价格调整、分期支付、保证措施或先决条件可作为候选方案，不假定存在即可消除风险。
5. 形成新版评估与交易方案，关联原风险、重建报告和变更清单，由相应技术、法律财务及投资授权人员重新评审。
6. 若无法取得可信基础、剩余责任不可接受或新方案不符合投资要求，则继续暂停或终止；允许重评不要求最终收购。

系统需表达“造假已确认／原方案暂停／重建中／重建结果待复核／新版方案待评审”等业务含义。事项后续可标记为已采取处置并披露残余风险，但不得改写为未发生造假。普通项目编辑或勾选任务完成不能使旧评估自动重新有效。

首期模拟一个完整场景：发现问题 → 旧估值需更新标记 → 独立重建产生较低资源参数 → 增加重建成本 → 调整对价与条件 → 形成新版方案评估。历史问题、原参数和评估版本应可查阅。

7. 领域对象与数据要求

本节定义业务概念，具体字段、约束和状态编码在SPEC阶段细化。

数据约束：

• 金属含量、矿石量、资源量、储量及可采量不能混用。
• 不同资源报告标准、版本和分类保留原文；任何映射须有规则及专家确认，不能自动假定等价。
• 品位、重量、价格等均保存单位；金克/吨与百分比等转换须明确。
• 保存原币金额、汇率来源和日期，展示币种转换过程。
• 空间数据保存坐标参考系、精度、来源及版本；未知坐标系统不能进行可靠叠加结论。
• 报告日、收集日、有效期、模型估值日应分开。
• 零值与未提供不同；未提供关键参数不能静默补零或填入默认值。

8. 功能需求

优先级定义：P0为目标业务闭环的核心需求，P1为增强能力，P2为后续扩展。首期是模拟演示，不按P0字样直接验收所有真实系统能力；逐项交付层次见SPEC范围映射。

8.1 项目管理与筛选

8.2 文档、证据与AI辅助

扫描或表格识别失败必须披露，不能把无法提取解释为资料中没有该项。原型中的预设摘要必须标记，不能称为实际AI分析。

8.3 地图与区域分析

空间风险不能仅凭未经验证的图层自动形成最终法律结论。

8.4 风险与尽调

8.5 估值与交易情景

正式模型的税务、财务及专业假设须由对应负责人确认。概率与置信度如缺少校准依据，不得给出伪精确百分比。

8.6 决策支持、输出及知识积累

9. 数据来源与资料清单

9.1 初筛资料

项目介绍、目标权益及报价、矿业权与持有人信息、位置和范围、现有地质报告目录、资源估计概述、阶段和重大已知限制。

9.2 尽调资料

完整勘查与资源报告、原始钻孔及化验数据、采样和质量控制记录、估算模型及方法、选矿试验、采矿和建设方案、基础设施条件、环境和许可文件、公司股权与负担、历史合同债务、财务税务资料。

是否必须获取某项由项目阶段与关键疑点决定，不能要求所有勘探项目先具备待建项目的全部资料。

9.3 交易资料

如需核查交易条件，接收专业意见、交易合同及适用审批与转让材料、权属和负担解决证明、支付条件、交割条件及核验记录。

9.4 外部数据

区域地质、空间边界、交通能源、金属价格、汇率、法规、企业与司法信息及可比交易。每类数据都需确认提供方、获取方式、授权、覆盖、时效、费用和证据效力。

公开可见不等于可任意抓取或商业复用。外部来源未落实时，应支持人工导入，并明确覆盖不足。

10. 非功能与安全需求

处理时延、识别质量、最大文件大小、并发用户数与可用性不能在缺少环境依据时虚设承诺，须在需求基线中补齐。

11. 端到端验收情景

首期验收范围：AC-01、AC-02、AC-04、AC-08至AC-12、AC-15、AC-17至AC-20、AC-23至AC-29以模拟资料验证流程与实际计算。AC-13海外估值及资源标准转换留至后续试点；首期只保留相关字段，不验收完整海外功能。其中AC-02验证预设冲突的展示和处置，不验收自动识别准确率；AC-04验证人工修改与复审状态；AC-11、AC-12可用代表性简化算例，但必须明确公式与缺项；AC-15验证本次演示期间的历史版本。AC-03、AC-05至AC-07、AC-13、AC-14、AC-16属于后续试点或正式能力验收，首期只展示相关交互说明，不作能力通过声明。具体测试步骤与预期数值将在SPEC冻结。

验收数据包含正常、缺失、矛盾、过期、错误单位、多版本与权限受限案例。试点专家先标注预期结果，再评测系统，避免使用系统自己的答案作为标准答案。

12. 需求追踪与变更控制

每条P0需求应关联SPEC规则、设计页面、架构模块、agent任务及验收用例。后续维护以下矩阵：

需求ID → SPEC条款 → 页面／流程 → 模块和契约 → agent任务 → 检查或测试 → 验收记录。

需求新增或修改记录原因、范围、影响、负责人及批准状态。需求和接口变更需先同步相关任务，不能由各agent自行改变共同契约。

正式基线冻结前可讨论调整；冻结后以变更记录修订。无法验证或尚未定义的条件不得计为已验收。

13. 首期基线与后续待办

首期采用4个虚构案例，覆盖两个阶段、两条主要交易路径、四类增值手段及风险分支；SPEC规定数据、状态、公式和验收步骤。桌面与手机核心功能一致，各设备独立保存，无账号、同步、销售管理、投资审批或真实AI调用。

具体页面、示例数值、错误处理和测试浏览器属于实现细节，不是已经由业务方逐项批准的投资规则。第6节除造假数据允许独立重建后重评的原则外，风险政策仍采用明确标注的演示建议，不宣称公司正式制度。

真实试点前另行确认：资料保密及授权、实际用户权限、目标国家、专业估值和税务口径、真实AI及数据服务、预算时间、生产性能与验收专家。以上不阻断模拟原型SPEC。

14. 需求阶段结论与后续顺序

已确认首期范围，继续SPEC与交互设计。后续先评审两份文档，再细化架构、共享契约及agent任务归属，最后开展并行开发与依据文档验收。

需求ID和原验收ID保持稳定；已移除的销售功能FR-007至FR-009、AC-21及AC-22不重新占用。规则调整或功能范围变更须记录影响，不静默改写历史文档。

本基线不保证真实矿业投资结果；演示通过仅说明交互、模拟流程和算例符合文档。

15. v1.1：Z.ai后训练能力的设计范围

本次将后续模型应用及专项训练纳入系统设计；首期交付仍按第4节，以四案例模拟流程验收。后训练效果、合作资源、预算和生产配置尚未证明。原FR/AC编号稳定，新能力使用AI-01至AI-07及S/D/A/J-AI编号追踪。

每台设备独立工作区仍是首期要求。后续服务器存放授权原件或运行记录，不能据此自动扩展成跨设备工作区同步。真实资料、权限和密钥不以localStorage实现。

完整数据路径、六项训练门槛及共享契约见整合说明。模型事实来自Astra方案v2.0，业务功能属于设计建议。真实资料、API和训练可用性落实后进入后续试点；本次不启动开发或训练。