财顾报告智能化生成产品MVP版本需求文档
需求概述
本期建设背景
本项目拟建设财务顾问报告智能生成系统，但本阶段并不以完整平台建设为目标，而是以最小可行产品（MVP）的方式，优先验证核心链路的可行性。系统最终服务于财务顾问主服务报告的智能化撰写支持，覆盖项目融资、资产管理、并购重组三类报告类型，但本期建设重点不是一次性完成所有平台能力，而是在现有行内技术环境和模型能力约束下，尽快形成可运行、可演示、可迭代的原型系统。
结合当前项目推进情况可以明确，完整产品规划中将包含知识体系配置、数据资源配置、运行任务执行、结果查看与持续迭代等多类能力，但如果在MVP阶段同步建设全部内容，将显著增加系统复杂度和开发周期，也不利于快速验证智能生成效果。因此，本期需求文档的核心任务，是在保留完整产品主干思路的前提下，对功能范围、交互深度和实现方式进行收敛，优先打通最关键的业务闭环。
本期MVP的设计出发点，主要聚焦以下维度：
在行内模型能力条件下，是否能够通过分阶段方式稳定完成报告生成；
以知识单元为核心组织对象的设计，是否能够支撑报告大纲决策、数据准备和段落生成；
在不建设完整配置端的情况下，是否仍可通过预置知识体系快速跑通运行链路；
业务人员是否能够在关键节点进行必要确认，从而使生成结果具备可用性与可控性。
本期建设目标
本期MVP的建设目标聚焦于“验证生成链路可行性”和“形成可持续迭代的最小系统形态”，而不是追求一次性建设完整平台。系统需围绕报告生成的核心过程，完成从任务发起到结果输出的最短业务闭环，并在此过程中尽量减少与验证目标无直接关系的复杂功能。
本期建设的核心目标包括以下几个方面。
（1）验证报告智能生成主链路可跑通
本期需要重点验证，系统是否能够按照既定流程完成以下关键环节：
业务人员录入任务基础信息；
系统基于知识体系生成报告大纲；
业务人员对大纲进行受控确认；
系统围绕已确认的知识单元完成数据准备；
业务人员对数据结果进行确认和必要补录；
系统基于知识单元和数据结果逐段生成报告内容；
最终形成可在线查看、可导出的完整报告。
这一目标强调的是“全流程闭环可执行”，而不是单点能力演示。
（2）验证结构化生成方式的有效性
本期不采用一次性长文本自由生成方式，而是采用“大纲生成—数据准备—报告生成”三阶段执行机制，并以知识单元作为最小执行对象。MVP需要验证这种结构化方式是否能够适配行内模型能力约束，并在生成稳定性、可控性和可复核性方面优于直接长文本生成。
这一目标对应的验证重点包括：
大纲是否能够基于输入信息和知识体系生成合理结果；
大纲是否能够下钻到知识单元级别；
数据准备是否能够围绕知识单元展开；
段落级生成是否能够支持最终报告拼接。
（3）验证知识单元驱动的系统设计是否成立
本期MVP虽然不建设完整配置端，但运行链路必须建立在知识单元体系基础上。系统需要验证以下设计是否可落地：
一个知识单元对应一个最终输出段落；
知识单元可作为大纲生成的最终选择对象；
知识单元可关联对应的数据需求和提示词模板；
系统可基于知识单元ID完成后续数据准备和内容生成。
如果这一设计在MVP中得到验证，后续即可较低成本扩展至其他报告类型和更多知识内容。
（4）控制开发复杂度，优先实现可演示原型
本期建设需充分考虑实际开发周期与实现成本，优先交付一版可以真实演示的系统原型。因此，需求设计应当始终围绕“是否影响主链路验证”进行取舍。凡是不影响主链路跑通的复杂能力，原则上均可后置。
本期系统应达到的最低目标不是“功能齐全”，而是：
页面可操作；
流程可执行；
结果可展示；
逻辑可说明；
后续可扩展。
本期建设范围的总体取舍
为了确保MVP可以快速落地，本期需求在完整产品思路基础上进行了明显收敛。整体上，本期采用“运行端优先、配置端弱化、确认节点保留、复杂交互后置”的建设策略。
从整体范围来看，本期的建设重点是运行端，即围绕一次报告任务的执行过程建设系统能力；而配置端虽然在完整产品中十分关键，但本期暂不单独建设前台页面，仅保留其后台预置和运行支撑作用。
本期范围的总体取舍如下。
【本期重点建设内容】
本期必须落地的内容主要集中在以下几个方面：
面向业务人员的报告任务发起能力；
面向业务人员的大纲生成及人工确认页面；
基于已确认知识单元的数据准备执行能力；
数据结果展示与文本补录能力；
基于知识单元与数据结果的段落生成能力；
报告结果在线展示与导出能力；
整体任务状态流转和阶段衔接能力。
【本期简化处理内容】
为了保证主链路优先，本期以下内容可以采用简化实现方式：
知识体系配置通过数据库或初始化数据维护，不建设完整配置界面；
数据资源配置通过代码绑定和预置关系实现，不建设专门的运维配置页面；
数据准备结果只要求支持展示与文本补录，不要求复杂结构化编辑；
报告生成结果只要求支持在线查看和导出，不要求本期支持富文本在线编辑；
大纲调整仅允许在已配置知识体系范围内进行勾选和取消勾选，不开放自由新增与自由改写。
【本期暂不纳入的能力】
以下内容从完整产品角度是必要的，但本期原则上不作为强制交付范围：
面向业务人员的完整知识体系配置端；
面向运维人员的数据资源配置页面；
段落级重生成和局部重跑能力；
报告在线精细编辑与版本比对能力；
更细粒度的角色权限拆分；
更复杂的任务协同、审核与留痕能力。
本期在需求文档中需要对这些能力进行必要说明，但应明确其属于后续迭代方向，不纳入本期必须完成范围。
本期系统实现原则
本期MVP的需求设计与开发实现，需要统一遵循以下原则，以避免系统在早期阶段因范围失控而偏离目标。
（1）主链路优先原则
所有功能设计均应优先服务于“任务发起—大纲生成—数据准备—报告生成—结果输出”这一主链路。对主链路无直接支撑作用的复杂能力，本期一律后置。
（2）受控生成原则
系统生成过程必须建立在已配置知识体系基础上，不能允许业务人员在运行过程中自由新增系统未配置内容。所有生成、确认和调整动作，均应在既有知识单元范围内完成。
（3）人工确认保留原则
本期系统虽强调智能生成，但关键节点仍需保留业务人员确认机制。至少应在大纲生成后、数据准备后保留人工确认，以降低模型输出不稳定对结果质量的影响。
（4）弱配置、强运行原则
配置端能力本期不追求前台化、可视化和精细化，而是优先通过后台预置支撑运行端闭环。系统建设重点应放在运行逻辑是否顺畅，而非配置体验是否完善。
（5）低耦合扩展原则
虽然本期进行了大量简化，但对象模型和流程设计仍应具备后续扩展能力。例如，当前数据资源通过代码绑定实现，但在设计上应预留后续剥离为独立配置模块的空间；当前结果页只支持查看与导出，但生成结果对象和任务状态设计应支持后续扩展编辑与重生成能力。
本期验证重点
从MVP项目管理角度看，本期最需要被验证的是以下几项关键判断是否成立。
第一，系统是否能够在三阶段流程下稳定运行，而不依赖一次性长文本生成完成整篇报告。
第二，知识单元是否能够真正成为系统运行的核心对象，即既能用于大纲选择，也能用于数据准备与正文生成。
第三，业务人员是否能够通过有限确认动作介入关键节点，而无需承担过重的人工编辑成本。
第四，在不建设完整配置端的前提下，系统是否仍然可以通过预置知识体系和预置数据映射方式快速落地。
第五，以项目融资报告为重点验证对象形成的运行模式，是否能够较低成本复制到资产管理和并购重组两类报告。
上述五项内容，构成本期MVP成败判断的核心依据，后续各章节的功能设计、输入输出设计和交互逻辑设计，均应围绕这些验证重点展开。
MVP建设范围与边界
建设范围说明
本章所述“建设范围”，主要用于界定本期MVP在系统层面实际需要交付的能力边界，即哪些内容属于本期必须建设的运行能力，哪些内容仅作为后台支撑存在，哪些内容在本期采用简化方式实现，以及哪些内容明确留待后续版本补充。其目的不是再次说明项目背景，而是为后续功能设计、页面设计和开发实施提供统一范围口径。
本期MVP的建设范围，应围绕一次报告生成任务的完整执行过程进行界定。系统需要支持业务人员从任务创建开始，依次完成大纲生成与确认、数据准备与补录、报告生成以及结果查看与导出，并保证各阶段之间存在清晰的输入输出衔接关系。换言之，本期范围的核心不是建设完整的平台能力体系，而是建设一条可以独立运行的任务执行链路。
在范围划分上，本期应当将能力分为三类来看待：
第一类是前台可见、需要业务人员直接操作的运行能力；
第二类是支撑运行能力正常执行的后台预置能力；
第三类是完整产品中应具备、但本期暂不纳入交付的扩展能力。
基于上述划分，本章后续内容将分别说明：
本期实际纳入建设的功能内容、本期为控制复杂度而采取的简化实现方式、以及明确不纳入本期范围的内容边界。通过这种方式，可以避免在需求设计和开发实施过程中，将后台预置能力误认为前台功能，或将后续规划能力误纳入本期交付范围。
本期纳入范围
结合本期MVP的交付目标，纳入范围的内容应限定为完成一条报告生成任务所必需的运行能力，以及支撑该运行链路落地的必要后台预置能力。判断某项内容是否纳入本期，核心标准不在于其是否属于完整产品规划的一部分，而在于其是否直接影响“任务可发起、流程可执行、结果可输出”这一最小闭环的形成。
基于这一原则，本期纳入范围主要包括五类前台运行能力和一类后台支撑能力，分别对应任务发起、大纲生成与确认、数据准备与补录、报告生成、结果展示与导出，以及支撑上述流程运行的预置知识与数据绑定内容。以下对各项纳入内容进行具体说明。
报告任务发起能力
系统需支持业务人员发起一次新的报告生成任务。任务发起时，业务人员需录入本次任务的基础信息，用于支撑后续大纲生成与知识单元适配判断。该能力是整条链路的起点，本期必须建设。
本期该模块至少应支持以下输入内容：
报告类型选择，包括项目融资、资产管理、并购重组三类主服务报告；
客户及项目相关基础信息录入；
与报告结构判断相关的关键业务信息录入；
与知识单元适用条件判断相关的必要补充信息录入；
业务人员上传辅助材料，用于后续RAG召回或人工参考。
本期该模块的输出结果为一次已创建的报告任务，以及该任务对应的结构化输入信息集合，供后续大纲生成模块调用。
大纲生成与确认能力
大纲生成是本期MVP最核心的模块，也是本期必须具备明确页面承载和人工确认机制的模块。系统需基于业务人员录入的信息、预置的知识体系内容以及既定提示词模板，分阶段生成本次报告的结构结果，并将结果以可操作方式提供给业务人员确认。
本期该模块应包括两个连续环节：
第一步，生成一级章节结构及每个一级章节可分配的知识单元数量或范围，以及整篇报告的撰写思路说明。
第二步，基于一级章节结果逐章生成最终拟纳入执行的知识单元清单，以及对应一级章节的撰写思路。考虑到模型输出知识单元ID可能存在不稳定情况，本期系统在输出阶段不能直接将模型结果作为最终执行依据，而应提供人工确认页面进行受控校验。业务人员在该页面中看到的并不是自由文本编辑框，而是基于已配置知识体系展示的树状目录结构，其中模型已选中的知识单元默认勾选，业务人员仅可在已配置范围内进行以下操作：
保留已勾选内容；
取消部分已勾选内容；
从未勾选但已配置的知识单元中重新勾选；
对已配置内容进行有限顺序调整。
本期不允许业务人员在该环节自由新增系统未配置的章节或知识单元，也不开放大段自由改写能力。该设计的目的在于保证最终确认结果仍然严格落在知识体系可控范围内，避免后续数据准备和报告生成无法衔接。
本期该模块的输出结果为经业务人员确认后的最终知识单元清单及其层级顺序，作为后续数据准备和报告生成的唯一执行依据。
数据准备与补录能力
在业务人员确认大纲后，系统需基于最终知识单元清单进入数据准备阶段。该阶段的目标不是泛化取数，而是围绕每个知识单元所需的数据需求，调用预先绑定的数据处理逻辑，形成可供提示词模板直接使用的数据结果。
结合当前设计，本期数据准备能力需支持至少三类数据来源：
API接口类数据，例如工商、风险等信息，通过接口调用获取；
行内指标平台类数据，例如财务指标类结果，通过行内已有能力获取；
基于业务人员上传材料的召回结果，通过RAG方式获取相关文本内容。
由于不同数据来源底层返回格式不同，本期系统不要求前台对所有结构化结果做复杂统一编辑，而是以“结果展示 + 文本补录”的方式进行简化承载。也就是说，系统自动获取的数据结果在界面上进行展示后，业务人员只需进行以下操作：
查看系统返回的数据是否可用；
对缺失或不足内容进行文本补充；
确认当前知识单元所需数据已准备完成。
本期不要求业务人员在线修改复杂JSON结构，也不要求建设多类型数据编辑器。所有进入后续提示词拼接的数据，在MVP阶段均以可替换占位符的结果形式进入生成环节。
本期该模块的输出结果为：按知识单元整理后的数据结果集合，以及业务人员补录后的最终可用数据内容。
报告生成能力
在大纲和数据均确认完成后，系统需进入报告生成阶段。本产品需严格基于知识单元清单逐段执行生成。系统根据每个知识单元对应的提示词模板、知识单元基础信息以及已准备好的数据内容，逐个触发模型调用，生成对应段落文本，最终按既定顺序拼接为完整报告。
该模块在本期的重点不是丰富编辑能力，而是验证以下几点是否成立：
知识单元是否能够稳定驱动单段内容生成；
数据准备结果是否能够有效支撑提示词占位符替换；
多段内容是否能够按大纲顺序拼接成结构完整的报告成果。
考虑到本期建设重点在于打通链路，该模块暂不强制要求支持段落级重生成、局部重跑、在线精细编辑等复杂能力，但在对象设计和状态设计上应预留后续扩展空间。或者也可以基于开发资源情况酌情开发，最终产出该模块的输出结果为一篇按知识单元顺序拼接完成的完整报告内容。
报告结果展示与导出能力
系统需支持业务人员对最终生成结果进行在线查看，并将结果导出为标准文档。该能力虽然交互复杂度不高，但属于MVP闭环中不可缺失的一环，因为只有结果能够被查看和导出，系统原型才具备完整演示价值和业务可用性。
本期该模块至少应支持以下输出形式：
在线展示完整报告内容；
按章节和段落结构展示报告；
导出标准格式文档。
本期不要求在结果页中实现富文本编辑、批注流转、版本对比等增强功能，或者也可以基于开发资源情况酌情开发。
后台预置能力
虽然本期不建设完整配置端，但运行端的所有能力都依赖后台预置内容支撑。因此，以下后台能力虽不以前台功能形式体现，但仍属于本期范围内必须存在的支撑内容：
知识体系及知识单元基础信息预置；
这些能力本期可通过数据库维护、初始化脚本或代码绑定方式实现，无需单独建设面向业务或运维的配置页面，但在设计说明中必须明确这些预置内容是运行端正常执行的前提。
本期简化实现内容
为保障MVP可以在较短周期内落地，本期虽保留完整主流程结构，但在多个模块上采用简化实现策略。此类内容并非不重要，而是从实现速度和验证优先级角度出发，暂不在本期做完整工程化展开。
配置端能力简化
从完整产品角度看，知识体系配置和数据资源配置应当分别由业务人员和运维人员在线完成，并形成可持续维护的平台化能力。但本期不建设相关前台页面，而是采用后台预置方式承载。
具体而言，本期做法如下：
知识体系、知识单元、适用条件、提示词模板等内容通过数据库预置维护；
数据资源调用关系、接口名称、参数映射、指标来源等内容通过代码或配置文件绑定；
前台运行流程仅消费这些已预置内容，不承担配置职责。
该方案可以显著降低本期建设复杂度，但在文档中需明确说明，这只是MVP阶段的简化实现，后续应逐步剥离为独立配置能力。
大纲调整能力简化
从完整产品角度看，大纲确认环节可以进一步支持自由编辑、个性化备注、动态插入内容甚至人工重构章节结构。但本期不开放这类高自由度能力，而是采用“树状结构 + 勾选确认”的受控方式。
该简化策略意味着：
业务人员仅能在已配置知识体系范围内进行选择；
不可新增系统未配置内容；
不以自由改写目录文本作为主要交互方式；
模型结果不是最终结果，业务确认后结果才进入后续环节。
这一设计能够降低后续链路不确定性，同时减少前端复杂编辑器的开发成本。
数据编辑能力简化
本期数据准备结果虽然来源多样，但不在前台构建复杂的多类型数据编辑能力。业务人员在本期仅需完成“查看、确认、文本补录”三个动作，无需对结构化结果进行复杂改写。
该简化方式能够有效降低前端开发成本，也便于与提示词模板的占位符替换机制衔接。后续若需要进一步提高数据准备阶段的可控性和精细化程度，再逐步扩展为结构化编辑能力。
结果处理能力简化
本期最终结果页以“查看与导出”为主，不在本期建设复杂的后处理功能。也就是说，报告生成完成后，系统主要承担展示和导出职责，而不在本期承担富文本在线编辑、差异比对、重生成入口统一管理等增强能力。
这一简化并不意味着后续不需要这些功能，而是说明本期建设的重点仍然是验证报告是否能够被稳定生成出来，而不是验证复杂编辑体验。
本期不纳入范围
为避免MVP阶段范围膨胀，以下内容明确不纳入本期必须交付范围。
完整知识配置端
本期不建设面向业务人员的知识体系维护页面，包括但不限于：
在线新增、修改、删除知识单元；
配置知识单元适用条件；
配置知识单元提示词模板；
管理不同报告类型的知识体系版本。
上述能力属于完整平台的重要组成部分，但本期仅通过后台预置实现。
完整数据资源配置端
本期不建设面向运维人员的数据资源配置页面，包括但不限于：
在线配置接口名称与调用方式；
在线维护调用参数和字段映射；
在线配置知识单元与取数方式的绑定关系；
在线测试不同数据源调用结果。
上述能力本期通过代码层面实现绑定，需求文档中只需说明运行逻辑和后续剥离方向。
段落级编辑与重生成能力
以下能力从完整产品视角具备较高价值，但本期不强制纳入：
单段重生成；
指定知识单元重跑；
在线逐段编辑；
局部修订后重新拼接；
多版本结果对比。
本期结果页不承载上述增强能力，但对象设计应保留后续扩展可能。
精细角色与权限体系
本期用户角色统一按“业务人员”处理，不进一步细分客户经理、审批支持人员、运维人员、管理员等不同角色，也不建设复杂权限控制体系。后续若平台化程度提升，再根据组织分工进行角色拆分。
复杂协同与审核流程
本期不纳入以下能力：
多人协同编辑；
审批流或审核流转；
操作留痕精细追踪；
历史版本比对与回滚；
任务协作分派。
这些能力虽然在完整生产系统中可能逐步需要，但不属于本期验证智能生成链路的必要条件。
本期与后续版本的衔接要求
虽然本期采取了大量简化策略，但相关设计不能以牺牲后续可扩展性为代价。因此，本期在建设过程中仍需注意与后续版本的衔接关系，确保系统后续能够平滑扩展，而不是推倒重来。
本期至少应在以下几个方面预留扩展空间：
对象层面：知识单元、提示词模板、数据需求、任务结果等对象应具备独立标识和可追踪关系；
流程层面：大纲生成、数据准备、报告生成三个阶段应具备清晰状态边界，便于后续支持局部重跑与局部编辑；
配置层面：当前通过代码绑定的数据资源关系，后续应能够平滑迁移为配置化管理；
前台交互层面：当前简化的查看和确认页面，后续应具备继续扩展为精细编辑页面的基础；
报告类型层面：本期虽以项目融资为重点验证对象，但不应将模型、流程或页面写死为单一报告类型逻辑。
因此，本期MVP的边界并不是“只做最简单的临时Demo”，而是在保证实现速度的前提下，交付一套具备明确对象模型、清晰状态流转和后续演进空间的最小系统版本。
本章结论
综合来看，本期MVP的范围应当始终围绕“运行主链路验证”这一核心目标展开。凡是直接影响任务闭环跑通的能力，均应纳入本期；凡是虽有价值但不影响主链路验证的复杂工程化能力，则应明确后置。通过这种方式，本期系统既能够快速形成可演示成果，又能够在对象设计和流程设计上为后续平台化演进打下基础。
用户角色与整体业务流程
用户角色说明
MVP阶段系统用户暂按单一业务角色进行设计，不进一步区分客户经理、审批支持人员、运维人员或管理人员等不同类型角色。该设计主要是为了降低本期需求复杂度，使系统功能描述能够聚焦于报告生成主流程本身，而不被多角色权限差异所干扰。
从实际使用方式看，本期业务人员既是报告任务的发起者，也是大纲确认、数据补录、结果查看的主要操作主体。系统在本期不承担复杂协同分工职责，而是围绕单用户完成一轮报告生成任务进行设计。因此，后续各功能模块中的“用户”或“业务人员”均指同一类操作对象。
在本期范围内，业务人员主要承担以下职责：
发起报告生成任务并录入基础业务信息；
触发系统进行报告大纲生成；
对系统生成的大纲结果进行人工确认和受控调整；
查看数据准备结果，并对缺失内容进行文本补录；
触发系统生成完整报告；
在线查看最终报告并导出结果。
在上述流程中，系统负责完成结构推荐、数据处理和段落生成等工作，业务人员负责在关键节点完成确认与有限调整。该方式体现了本期MVP“系统辅助生成、人工保留判断”的基本设计原则。
整体流程说明
本期MVP的整体流程，围绕一次报告任务的完整执行链路展开。系统运行从业务人员创建任务开始，经过大纲生成与确认、数据准备与补录、报告生成、结果查看与导出等环节，最终形成一篇可供业务使用的财务顾问主服务报告。具体流程如下：
从流程结构上看，本期业务流程可划分为五个阶段：
第一阶段为任务发起。业务人员选择报告类型并录入本次任务所需的基础信息，同时上传必要辅助材料，作为后续知识单元适配判断和数据召回的输入基础。
第二阶段为大纲生成与确认。系统基于输入信息、知识体系和提示词模板，先生成一级章节结构及数量分配结果，再进一步生成知识单元清单。系统将结果以树状结构方式展示给业务人员，由业务人员在已配置范围内完成勾选确认和有限调整，形成最终执行大纲。
第三阶段为数据准备与补录。系统根据已确认的知识单元清单，逐项执行对应的数据处理逻辑，从接口、指标平台或上传材料中获取所需数据。业务人员对系统返回结果进行查看和确认，并在必要时补充文本内容，形成最终可用于生成的段落数据。
第四阶段为报告生成。系统依据最终知识单元清单、各知识单元对应的提示词模板及准备完成的数据内容，逐个知识单元调用模型生成段落文本，并按大纲顺序完成拼接，形成完整报告。
第五阶段为结果输出。系统向业务人员展示完整报告结果，并提供导出能力，供后续使用。至此，一次报告生成任务完成闭环。
上述流程中，大纲确认和数据确认是本期必须保留的两个关键人工节点。其作用不在于增加人工操作负担，而在于提高模型输出的稳定性和业务可控性，避免系统直接沿用不适配的大纲或不完整的数据进入后续生成阶段。
业务流程分阶段说明
任务发起阶段
任务发起阶段是整条流程的起点，其核心作用是收集驱动后续判断所需的基础输入。系统在该阶段不直接生成报告内容，而是将业务人员输入的信息结构化为任务上下文，供后续大纲生成模块调用。
业务人员在该阶段至少需要完成以下操作：
选择本次任务对应的报告类型；
录入客户、项目及报告相关基础信息；
录入与知识单元适用判断相关的关键业务要素；
上传可供后续RAG召回使用的辅助材料。
系统在该阶段完成任务创建，并将录入结果保存为本次任务的输入数据集。后续所有生成动作，均围绕该任务上下文展开。
该阶段的输出为：一条已创建的报告任务，以及一组结构化的任务输入信息。
大纲生成与确认阶段
大纲生成与确认阶段是本期MVP的核心控制环节，其主要作用是确定“本次报告究竟写哪些内容”。由于报告不能依赖固定模板简单套用，因此系统必须先基于任务输入和知识体系结果，形成适用于本次场景的执行大纲。
本期该阶段采用两步式生成机制：
第一步，由模型结合任务输入、报告类型及知识体系内容，生成一级章节结构及各一级章节拟分配的知识单元数量或范围及报告整体撰写的逻辑。该步骤解决的是整篇报告的宏观结构问题。
第二步，系统基于一级章节结果，按章节逐个生成最终拟执行的知识单元清单还有每个一级章节撰写的逻辑。该步骤解决的是各章节下具体写哪些段落的问题。
该阶段的确认结果一旦提交，即形成后续数据准备和报告生成的唯一执行范围。系统在此之后不再接受运行过程中自由新增知识单元。
该阶段的输出为：经人工确认后的最终知识单元清单。
数据准备与补录阶段
数据准备阶段的目标，是围绕已确认的知识单元清单，为每个知识单元准备生成所需的数据内容。该阶段的处理对象不是“整篇报告的数据”，而是“每个知识单元对应的数据需求”。
系统依据预置绑定关系，为不同知识单元调用不同的数据处理逻辑。当前本期可支持的数据来源包括：
外部接口返回的数据结果；
行内指标平台返回的指标结果；
基于业务人员上传材料召回的文本内容。
由于不同来源的数据格式不一致，本期并不要求对其进行统一结构化编辑，而是由系统直接展示处理结果，再由业务人员进行人工确认和文本补录。该阶段业务人员的核心动作包括：
查看系统返回的数据内容是否满足当前知识单元生成需求；
补充系统未获取到但业务上需要纳入的文本内容；
确认当前知识单元所需数据已准备完成。
在这一阶段结束后，系统应形成面向各知识单元的最终可用数据集合，并使其能够直接参与提示词模板占位符替换。
该阶段的输出为：按知识单元整理完成的数据结果集合，以及业务补录后的最终生成输入内容。
报告生成阶段
报告生成阶段的核心任务，是基于已确认的大纲和已准备完成的数据，逐知识单元完成段落生成，并最终拼接形成完整报告。
具体执行逻辑为：
系统按大纲顺序依次读取知识单元；
读取该知识单元对应的提示词模板；
将任务基础信息、知识单元信息及数据准备结果拼接进提示词；
按知识单元逐次调用模型生成段落内容；
将各段落结果按既定顺序拼接为完整报告。
该阶段的输出为： 一篇按既定大纲顺序拼接完成的完整报告文本。
结果查看与导出阶段
在报告生成完成后，系统需向业务人员提供结果查看与导出能力。该阶段不再参与内容生产，而是承担结果承载和交付作用。
本期业务人员在该阶段可以完成以下操作：
在线查看完整报告内容；
按章节或段落浏览结果；
导出报告成果用于后续线下使用。
该阶段的输出为： 可在线浏览、可导出的报告结果。
系统实现逻辑设计
设计说明
本章用于说明MVP版本在系统内部的实际处理逻辑，重点面向开发人员、实施人员及后续参与技术方案细化的产品人员展开。与前文从业务视角描述“用户如何发起和完成一次报告任务”不同，本章聚焦系统在各阶段如何接收输入、组织处理、保存中间结果并驱动后续执行。
本期MVP的实现逻辑遵循以下原则：
一是系统运行必须围绕知识单元展开，不能以自由生成整篇长文本作为核心实现方式；
二是每一阶段都必须形成明确、可落库、可复用的中间结果，后续阶段只能消费前一阶段的确认结果；
三是关键节点必须保留人工确认，以降低模型输出不稳定对结果质量的影响；
四是本期虽然采用简化实现方式，但对象设计和阶段划分仍需为后续迭代预留扩展空间。
基于上述原则，本期系统内部的实现链路可以概括为系统先接收并保存任务输入，再基于任务上下文完成一级大纲生成和二级大纲生成；在业务人员完成大纲确认后，系统围绕最终知识单元清单逐项执行数据准备；数据确认完成后，系统再按知识单元逐段调用模型生成内容，并将结果拼接为完整报告，最终提供展示与导出能力。整个过程中，任务对象、知识单元清单、知识单元数据包和报告结果对象共同构成系统运行的核心载体。
核心运行对象设计
为了支撑本期MVP的分阶段执行机制，系统内部至少需要围绕若干核心对象进行设计。这些对象既是各阶段输入输出的承载体，也是任务状态流转和结果追踪的基础。
报告任务对象
报告任务对象是一次报告生成请求的主对象，用于承载本次任务的整体上下文。该对象在任务创建时生成，并贯穿后续所有阶段。后续大纲、数据、生成结果均应与该任务对象建立明确关联。
该对象建议至少包含以下信息：
任务唯一标识
任务基础输入信息
上传材料关联信息
当前任务状态
创建时间、更新时间
任务执行结果摘要信息
报告任务对象的作用不只是保存前台录入内容，更重要的是为后续各模块提供统一的任务入口，并作为所有中间结果的关联主键。
一级大纲结果对象
一级大纲结果对象用于保存系统在一级大纲生成阶段形成的结果，包括模型原始输出和结构化整理后的结果。该对象主要服务于后续二级大纲生成，因此其内容不能只保留为自然语言描述，而应尽量结构化。该部分内容会在提示词中对输出格式进行约束。但是针对类似任务ID等与大模型交互无关的内容不会由大模型进行输出。
该对象建议至少包含以下信息：
所属任务ID
一级章节知识单元ID
一级章节顺序
各一级章节拟分配的知识单元数量对应的码值（逻辑撰写至提示词内）
整篇报告撰写逻辑（用于后续拼接至段落提示词模板中）
模型原始输出内容
结构化解析结果
生成时间
一级大纲结果对象的核心作用，是将“整篇报告的宏观结构判断”固化为可供后续程序消费的中间结果。
最终知识单元清单对象
最终知识单元清单对象用于保存经系统生成并由业务人员确认后的最终执行范围，是后续数据准备和报告生成的唯一依据。系统在该对象生成后，不应再允许运行过程中新增未配置知识单元。需要注意的是，因为知识体系的配置是树状结构，因此虽然一级章节不是最末级节点，但同样拥有知识单元ID。
该对象建议至少包含以下信息：
所属任务ID
知识单元ID
知识单元名称
知识单元顺序
是否选中
是否由模型默认选中
是否被人工调整
确认版本信息
这一对象是本期MVP最关键的运行对象之一。系统后续所有自动取数和逐段生成动作，都应严格以该清单为准。
知识单元数据包对象
知识单元数据包对象用于承载某一知识单元最终用于生成的数据内容。其来源既包括系统自动获取的结果，也包括业务人员在数据确认环节补录的文本内容。对于MVP而言，该对象不要求完全统一底层数据结构，但必须能够支撑提示词模板中的占位符替换。
该对象建议至少包含以下信息：
所属任务ID
知识单元ID
自动获取的数据结果
人工补录文本
数据整理后的最终结果
数据确认状态
数据更新时间
该对象的核心作用，是将来源不同、格式不同的数据整合为某一知识单元可直接消费的最终输入。
单段生成结果对象
单段生成结果对象用于保存单个知识单元对应的模型生成结果。虽然本期MVP不强制支持段落级重生成，但从实现上仍建议将每个知识单元的结果单独保存，以便后续问题排查、质量分析和功能扩展。
该对象建议至少包含以下信息：
所属任务ID
知识单元ID
实际拼接后输入prompt
模型生成结果
生成时间
生成状态
单段生成结果对象是完整报告拼接的原子来源，也是未来扩展局部重跑能力的重要基础。
完整报告结果对象
完整报告结果对象用于保存最终拼接完成的整篇报告内容，并作为结果页展示与导出的唯一来源。该对象不应依赖页面实时拼接生成，而应在系统完成报告生成后统一落库保存。
该对象建议至少包含以下信息：
所属任务ID
报告标题或结果名称
完整报告正文
报告结构信息
生成完成时间
导出状态或导出记录摘要
该对象的作用是将“分段生成结果”固化为可交付、可查看、可导出的最终成果。
分阶段处理逻辑与输入输出设计
任务创建处理逻辑
任务创建阶段的处理目标，是将前台录入信息和上传材料组织为标准化任务上下文，并形成后续流程的统一输入基础。
页面示例
该阶段输入
任务基础信息
报告配置信息
上传材料（MVP版本上传的数据为固定好的excel模板，后续正式版本取消类型的限制）
额外说明
目前规划的输入内容和维度主要是以项目融资服务报告的内容进行参考的，后续随着覆盖报告类型的增加，存在新增更多录入项或勾选项的情况，视后续实际情况进行迭代。
系统在该阶段的处理逻辑
接收前台提交的任务信息；
校验必填字段和基础格式；
创建任务主记录；
保存输入字段；
保存上传材料与任务的关联关系；
初始化任务状态。
该阶段输出
已创建的报告任务对象；
结构化任务上下文；
附件关联信息；
初始任务状态。
该阶段建议落库的内容包括任务主表、任务输入信息表、任务附件关联表等。只有任务创建成功后，系统才进入后续大纲生成阶段。
一级大纲生成处理逻辑
一级大纲生成阶段的处理目标，是完成本次报告的宏观结构判断，即确定一级章节范围和各章节拟承载的内容规模。
该阶段输入
业务录入信息
知识体系中“level”字段为“1”的一级章节列表
系统在该阶段的处理逻辑
根据任务所属报告类型读取对应的一级章节知识范围；
将任务输入与一级章节相关信息组装为一级大纲生成Prompt；
调用模型生成一级大纲结果；
接收模型输出；
对模型输出进行基础解析和结构化整理；
保存一级大纲结果对象。
该阶段输出
一级章节清单；
一级章节顺序；
各一级章节对应的知识单元数量建议或区间；
一级大纲原始输出及解析结果。
整篇报告撰写逻辑
该阶段建议落库的内容包括一级大纲原始结果、解析后结构化结果、生成时间、生成状态等。一级大纲结果将直接作为下一阶段逐章生成知识单元清单的输入。
该阶段prompt模板
你是一名具有银行投行、对公授信及财务顾问报告经验的专业报告结构规划助手。
你的任务是：基于输入的报告背景信息、协议金额约束和一级章节候选清单，判断本次报告中每个一级章节是否应当呈现，并为每个章节分配段落数量枚举值，同时输出整篇报告撰写的逻辑说明。你的输出将直接作为系统后续自动处理的输入，因此你必须严格遵守以下要求。
###
【任务边界】
你只负责完成一级章节层面的结构判断，包括：
判断每个一级章节是否呈现
为每个一级章节分配段落数量枚举值
输出整篇报告撰写的逻辑说明
你不得执行以下内容：
不得撰写任何正文内容
不得判断二级章节或最末级知识单元
不得新增、删除、合并、拆分、改写一级章节名称
不得输出枚举值以外的数量表达
不得输出 JSON 结构以外的任何内容
不得展示你的推理过程或计算过程
###
【判断规则】
1. 判断范围约束
你只能在下方提供的【一级章节候选清单】中进行判断。
输出结果必须与输入候选章节一一对应，顺序保持一致，不可缺失，不可新增。
2.段落数量枚举
你只能使用以下枚举值：
P0：不呈现
P1：1段
P2：2–5段
P3：5–10段
P4：10段及以上
3.协议金额与整体规模约束
你必须先根据协议金额判断本次报告整体允许的段落规模区间，再进行各一级章节的数量分配。
协议金额与目标段落区间规则如下：
<50万 → 10–20段
50–100万 → 20–30段
100–500万 → 30–40段
>=500万 → 40–50段
4.你在内部判断时必须同时考虑：
协议金额对应的总段落预算范围
各章节重要性
是否存在独立专项报告
章节的额外说明 / 知识边界说明
章节适用条件
各章节下可供分配的最末级段落统计上限
报告结构完整性与论证顺序合理性
但你不得在输出中展示计算过程。
5. 重要性选择规则
你必须根据“是否存在独立报告”来选择适用的重要性字段：
若存在独立报告，则使用“重要性（有独立报告）”
若不存在独立报告，则使用“重要性（无独立报告）”
重要性处理原则如下：
必定：原则上应保留，除非明确不适用
高：优先保留，但可在总量约束下压缩篇幅
中、低：可根据整体结构需要压缩或舍弃
若额外说明中明确指出“存在独立报告时仅需简单介绍”，则即使保留，也应优先分配较低段落级别
6. 适用条件规则
若章节存在适用条件，则必须结合输入背景信息判断。
若条件不满足，则该章节可判断为不呈现。
若条件满足，也仍需结合重要性、整体规模约束和结构合理性综合判断。
###
【输入信息】
1. 报告背景信息
报告类型：{{report_type}}
协议金额：{{agreement_amount}}
企业类型：{{enterprise_type}}
集团板块名称：{{group_business_segments}}
行业类型：{{industry_type}}
是否存在独立调查报告：{{has_independent_report}}
独立报告类型：{{independent_report_types}}
拟分析融资工具：{{candidate_financing_tools}}
拟最终推荐融资工具：{{recommended_financing_tools}}
其他要求：{{other_requirements}}
2. 一级章节候选清单
{{chapter_candidates_block}}
###
【输出要求】
你必须仅输出一个合法的 JSON 对象，不得输出任何其他说明文字、标题、注释、Markdown 标记或代码块标记。
输出 JSON 结构必须严格如下：
{
"chapter_results": [
{
"chapter_id": "string",
"chapter_name": "string",
"paragraph_count_enum": "P0 or P1 or P2 or P3 or P4",
"reason": "string"
}
],
"overall_logic": "string"
}
###
【输出约束】
你必须严格遵守以下输出约束：
chapter_results 数组长度必须与输入的一级章节候选数量完全一致
chapter_results 中各元素顺序必须与输入候选顺序完全一致
chapter_id 和 chapter_name 必须与输入内容原样一致，不得改写
reason 必须是一句简洁自然语言，只说明该章节是否保留及其段落级别的核心原因
overall_logic 必须是一段自然语言，只说明一级章节的组织顺序、核心与承接关系、整体结构如何服务最终方案论证
overall_logic 不得出现具体数量计算过程，不得出现 JSON 之外的层级结构
输出必须是可被程序直接解析的合法 JSON
###
【输出字段说明】
chapter_results：一级章节判断结果列表，按输入候选章节顺序逐项输出
chapter_id：一级章节唯一标识，必须与输入一致
chapter_name：一级章节名称，必须与输入一致
paragraph_count_enum：章节段落数量枚举，P0 表示不呈现，P1 表示1段，P2 表示2–5段，P3 表示5–10段，P4 表示10段及以上
reason：该章节判断结果的简要原因说明，使用一句自然语言表达
overall_logic：输出整篇报告撰写的逻辑说明，用一段自然语言说明章节顺序及整体论证关系
相关页面示例
备注说明：目前版本提示词模板已剔除“呈现方式”字段
二级大纲生成与确认处理逻辑
二级大纲生成阶段的处理目标，是在一级大纲结果基础上，进一步确定每个一级章节下本次需要执行的知识单元。该阶段的系统输出结果在业务确认后，才可成为正式执行依据。
该阶段输入
一级大纲结果；
对应一级章节下的知识单元候选集合；
知识单元基础信息；
二级大纲生成提示词模板；
任务上下文。
系统在该阶段的处理逻辑
按一级章节逐个读取该章节下的知识单元候选集合；
将章节信息、任务信息及候选知识单元信息拼接为章节级Prompt；
逐章节调用模型生成知识单元选择结果；
接收并汇总所有章节的结果；
形成完整的待确认大纲树；
将结果渲染为树状结构供前台展示。
在业务确认环节，系统需要支持以下处理
展示已配置知识体系树；
对模型默认选中的知识单元进行勾选标记；
接收业务人员勾选、取消勾选及顺序调整结果；
保存确认后的最终知识单元清单；
更新任务状态。
该阶段输出
待确认知识单元树；
经确认后的最终知识单元清单；
知识单元顺序信息；
大纲确认结果版本。
该阶段建议落库的内容包括二级大纲模型输出、树状候选结果、最终确认结果、人工调整标记、确认时间等。只有最终知识单元清单确认完成后，系统才能进入数据准备阶段。
该阶段prompt模板
你是一名具有银行投行、对公授信及财务顾问报告经验的专业报告结构装配助手。
你的任务是：基于已确定的一级章节约束、输入背景信息和末级章节候选清单，判断当前一级章节下哪些末级章节需要纳入，生成真实报告可用的章节编号结构，并输出一段简要的结构构建逻辑说明。你的输出将直接作为系统后续数据准备和段落生成的输入，因此你必须严格遵守以下要求。
###
【任务边界】
你只负责当前一级章节下的末级章节结构装配，包括：
判断哪些候选末级章节需要纳入
按真实报告逻辑生成章节顺序
生成可直接用于报告拼接的章节编号结构
对批次处理型章节按输入对象展开子章节
输出一段结构构建逻辑说明
你不得执行以下内容：
不得撰写任何正文内容
不得输出解释性分析
不得输出推理过程
不得新增候选清单中不存在的知识单元
不得修改输入中已有章节名称
不得改变候选清单原有层级
不得输出 JSON 结构以外的任何内容
###
【核心判断规则】
1. 上游约束继承规则
你必须严格继承上游一级大纲结果，仅对当前一级章节进行处理。
2. P 枚举使用规则
上游输入中的段落数量枚举值仅作为规模参考，不是严格上限。若为了保证论证完整性、批次展开或结构闭环，需要超出该规模参考，可以适度扩展。你不得在输出中体现任何数量推演过程。
P枚举值对应段落数量关系：
P0：不呈现
P1：1段
P2：2–5段
P3：5–10段
P4：10段及以上
3. 重要性优先规则
你必须根据“是否存在独立报告”选择对应的重要性字段：
若存在独立报告，则使用“重要性（有独立报告）”
若不存在独立报告，则使用“重要性（无独立报告）”
判断原则如下：
必定：必须纳入
高：原则上纳入，除非条件不满足或与其他内容明显重复
低：仅在增强论证闭环、满足输入触发条件或对结构完整性有必要时纳入
不撰写：必须排除
4. 条件触发规则
若候选章节存在备注中的适用条件，则必须结合输入背景信息进行判断。
若条件不满足，则该候选章节不得纳入。
若条件满足，则结合重要性和整体结构合理性判断是否纳入。5. 批次处理型展开规则
若候选章节的“知识单元类型”为 批次处理型，则必须按输入对象逐一展开，并生成独立子章节。
展开规则如下：
每个输入对象生成一个独立章节节点
子章节名称使用输入对象名称
自动补全对应层级编号
该类展开不受上游 P 枚举的严格限制
展开后的章节层级必须保持稳定，不得跳级
例如：若某候选章节要求按“集团板块名称”展开，则你必须基于输入中的所有集团板块名称逐一生成子章节。
6. 结构完整性优先规则
若仅按上游规模参考不足以覆盖关键知识单元或无法形成完整论证闭环，则应优先保证结构完整性，并适度扩展章节数量。
但不得无依据地纳入大量低重要性内容。
###
【章节编号规则】
你必须生成真实报告可用的章节编号结构。
编号规则如下：一级章节：1
二级章节：1.1
三级章节：1.1.1
四级章节：1.1.1.1
你必须遵守以下要求：
编号必须连续，不得跳号
顺序必须稳定
编号层级必须与候选章节原始层级一致
若为批次处理型展开，可在原有允许层级下生成对应子节点
不得将低层级内容提升或降级为其他层级
输出结果必须可直接用于报告拼接
###
四、输入信息
1. 已确定的上游约束
一级章节名称：{{chapter_name}}
一级章节编号：{{chapter_no}}
段落数量：{{chapter_paragraph_count_enum}}
判断说明：{{chapter_reason}}
整体写作逻辑说明：{{overall_logic}}
2. 报告背景信息
报告类型：{{report_type}}
协议金额：{{agreement_amount}}
企业类型：{{enterprise_type}}
集团板块名称：{{group_business_segments}}
行业类型：{{industry_type}}
是否存在独立调查报告：{{has_independent_report}}
独立报告类型：{{independent_report_types}}
拟分析融资工具：{{candidate_financing_tools}}
拟最终推荐融资工具：{{recommended_financing_tools}}
其他要求：{{other_requirements}}
3. 最末级章节候选清单
{{leaf_chapter_candidates_block}}
###
【输出要求】
你必须仅输出一个合法的 JSON 对象，不得输出任何其他说明文字、标题、注释、Markdown 标记或代码块标记。
输出 JSON 结构必须严格如下：
{
"chapter_name": "string",
"chapter_no": "string",
"chapter_structure": [
{
"node_id": "string",
"node_name": "string",
"node_no": "string",
"node_level": 2,
"parent_node_id": "string or null",
"source_type": "single or batch",
"source_candidate_name": "string",
"is_selected": true
}
],
"structure_logic": "string"
}
###
【输出字段说明】
chapter_name：当前一级章节名称，与输入一致
chapter_no：当前一级章节编号，与输入一致
chapter_structure：当前一级章节下最终纳入的章节结构列表
node_id：章节节点唯一标识
node_name：章节名称
node_no：章节编号
node_level：章节层级，按数字表示
parent_node_id：父节点ID，一级下直接子节点可为 null 或一级节点ID
source_type：来源类型，single=单元呈现型，batch=批次处理型
source_candidate_name：该节点对应的原始候选章节名称
is_selected：是否纳入，固定为 true
structure_logic：当前一级章节内部结构构建逻辑说明
###
【输出约束】
你必须严格遵守以下输出约束：
只输出最终纳入的章节节点，不输出未纳入节点
chapter_name 和 chapter_no 必须与输入完全一致
chapter_structure 必须按最终报告顺序输出
node_name 必须来源于输入候选章节名称或批次展开对象名称，不得随意改写
source_candidate_name 必须与输入候选章节名称完全一致
source_type 只能取 single 或 batch
node_level 必须与实际编号层级一致
structure_logic 只能写一段自然语言，不得分点，不得写数量，不得新增结构概念
输出必须是可被程序直接解析的合法 JSON
相关页面示例
数据准备与补录处理逻辑
数据准备阶段的处理目标，是针对最终知识单元清单逐项生成可用于提示词替换的数据内容，而不是对整篇报告统一进行数据汇总。
该阶段输入
最终知识单元清单；
各知识单元绑定的数据处理逻辑；
任务上下文；
上传材料关联信息。
系统在该阶段的处理逻辑
遍历最终知识单元清单；
按知识单元查询对应的数据来源和数据处理方式；
根据绑定关系调用接口类数据服务；
根据绑定关系调用指标平台类数据服务；
根据上传材料调用RAG召回服务；
汇总自动获取结果；
以知识单元为粒度展示数据准备结果。
在人工补录环节，系统需要支持
接收业务人员的文本补录内容；
将自动获取结果与人工补录结果合并；
形成知识单元最终数据包；
标记知识单元数据确认状态；
更新任务整体数据确认进度。
该阶段输出
各知识单元自动获取结果；
各知识单元人工补录结果；
各知识单元最终数据包；
数据确认状态。
该阶段建议落库的内容包括数据获取原始结果、整理后的展示结果、人工补录文本、最终数据包、数据确认时间等。该阶段完成后，系统方可进入报告生成阶段。
相关页面示例
报告生成处理逻辑
报告生成阶段的处理目标，是按照知识单元顺序逐段调用模型生成内容，并将所有结果拼接为完整报告。
该阶段输入
最终知识单元清单；
知识单元顺序；
各知识单元对应的提示词模板；
各知识单元最终数据包；
任务上下文。
系统在该阶段的处理逻辑
按顺序遍历知识单元清单；
读取当前知识单元对应的模板；
将任务基础信息、知识单元信息及最终数据包填充至模板；
逐知识单元调用模型生成段落内容；
保存每个知识单元的单段生成结果；
按顺序汇总全部段落；
拼接形成完整报告；
保存完整报告结果；
更新任务状态为可查看结果。
该阶段输出
单段生成结果集合；
完整报告结果；
报告生成状态。
该阶段建议落库的内容包括单段结果、完整报告正文、生成时间、生成状态、失败信息等。系统不应仅在前台临时展示结果，而应形成稳定的持久化对象。
相关页面示例
结果展示与导出处理逻辑
结果展示阶段的处理目标，是将系统已生成的完整报告结果输出给业务人员查看和使用。该阶段不再承担内容生成职责，而是作为任务的最终交付环节。
该阶段输入
完整报告结果对象；
报告结构信息；
任务基础信息。
系统在该阶段的处理逻辑
按章节和段落顺序展示完整报告；
提供结果查看页面；
提供标准文档导出能力；
记录查看和导出相关状态。
该阶段输出
可在线查看的报告结果；
可导出的文档结果；
最终完成状态。
该阶段建议落库的内容包括报告查看状态、导出记录摘要等。业务人员完成查看和导出后，任务可进入完成态。
相关页面示例
模型调用逻辑设计
本期MVP将模型调用拆分为三个不同层次的处理动作，分别承担不同职责。这种拆分方式既是对行内模型能力限制的适配，也是提升系统可控性的重要设计。
第一类调用为一级大纲生成调用。该调用负责判断整篇报告的一级章节结构及各章节内容规模，输入为任务上下文、一级章节候选范围和一级大纲模板，输出为结构化一级大纲结果。
第二类调用为二级大纲生成调用。该调用不是整体调用一次，而是按一级章节逐个执行。每次调用负责判断某一章节下应纳入哪些知识单元，输入为章节上下文、知识单元候选集合和章节级模板，输出为该章节知识单元清单。
第三类调用为报告生成调用。该调用按知识单元逐个执行，每次调用只负责生成一个知识单元对应的段落内容，输入为任务信息、知识单元信息、知识单元数据包和段落模板，输出为单段结果。
采用这种拆分机制有三个直接作用：
其一，可以将大模型任务拆解为更短、更聚焦的推理过程，降低长文本生成失败或失控的概率；
其二，可以使各阶段结果分别接受人工确认，从而增强业务可控性；
其三，可以使系统未来更容易扩展局部重跑和单段重生成能力。从实现上看，模型调用模块至少需要记录每次调用对应的任务ID、阶段类型、输入摘要、输出结果、调用时间及状态信息，以支撑问题排查和后续效果优化。
数据处理逻辑设计
本期MVP的数据处理逻辑，可理解为“面向知识单元的数据准备机制”。其核心思想是：知识单元决定需要什么数据，系统根据知识单元绑定关系去执行对应的数据处理逻辑，最终形成该知识单元的生成输入。
当前数据来源主要包括三类：接口类数据、指标平台类数据和RAG召回数据。三类数据的底层返回格式不一致，因此本期不要求系统在前台构建复杂统一编辑模型，而是重点保证两件事：一是系统能按知识单元正确拉起相应的数据处理逻辑；二是最终结果能整理成可用于提示词替换的内容。
系统在该部分的实现逻辑应包括：
根据知识单元ID读取绑定的数据处理方式；
按不同数据源类型调用不同服务；
接收各类原始数据结果；
按知识单元汇总结果；
形成前台展示内容；
接收人工文本补录；
合并形成知识单元最终数据包。
这里需要特别强调，MVP中的“数据最终结果”不是要求业务人员理解不同数据源的原始结构，而是要求系统将其整理为对段落生成有用的输入内容。因此，本期对开发团队而言，更重要的是保证知识单元到数据结果之间的映射关系跑通，而不是追求前台编辑能力完备。
状态流转与执行控制设计
为了保证任务能够按预期阶段推进，本期系统必须建立基础状态流转机制。虽然本期无需引入复杂流程引擎，但至少应通过统一状态控制页面行为和后台执行顺序。
建议本期至少设置以下状态：
待生成大纲
待确认大纲
待准备数据
待确认数据
待生成报告
报告生成中
待查看结果
已完成
执行失败
各状态的进入条件应清晰定义。任务创建成功后进入“待生成大纲”；一级和二级大纲结果生成后进入“待确认大纲”；确认完成后进入“待准备数据”；系统完成自动数据准备后进入“待确认数据”；业务补录并确认完成后进入“待生成报告”；报告正式执行时进入“报告生成中”；结果生成完成后进入“待查看结果”；业务人员查看并导出后可进入“已完成”；任一关键节点发生异常时可进入“执行失败”。
除状态本身外，系统还应基于状态控制前台可执行动作。例如，在“待确认大纲”状态时，应允许业务人员进行大纲勾选确认，但不允许直接触发报告生成；在“待确认数据”状态时，应允许进行文本补录和确认提交；在“待查看结果”状态时，应开放查看和导出入口。
通过这种状态控制，可以保证主链路执行顺序清晰，并为后续扩展失败重试、阶段回退和局部重跑打下基础。
模块职责划分
从实现落地角度看，本期MVP虽可不严格拆分为独立微服务，但在设计层面仍建议明确各模块职责边界，避免后续开发过程中逻辑耦合过深。
任务管理模块负责创建任务、保存输入、关联附件、维护任务状态，并向其他模块提供任务上下文读取能力。
大纲生成模块负责一级大纲和二级大纲的Prompt组装、模型调用、结果解析与保存。
大纲确认模块负责将系统生成结果按树状结构展示给业务人员，接收确认结果，并输出最终知识单元清单。
数据准备模块负责根据知识单元绑定关系调用各类数据服务，汇总自动获取结果并生成前台展示数据。
数据确认模块负责接收人工补录文本，形成知识单元最终数据包，并更新确认状态。
报告生成模块负责逐知识单元组织生成输入、调用模型生成单段内容、保存单段结果并拼接完整报告。
结果展示模块负责展示完整报告、处理导出，并记录结果查看和导出状态。
通过上述划分，即使本期在工程上采用相对简化的实现方式，也能保证系统在逻辑上具备较清晰的内部结构，为后续平台化改造和能力扩展提供基础。
完整产品配置体系设计（非MVP需求）
章节说明
前文所述内容主要围绕MVP版本的运行链路展开，重点在于验证财务顾问报告智能生成场景下“大纲生成—数据准备—报告生成”这一主流程的可行性。为控制本期建设复杂度，MVP阶段对配置端能力进行了大量简化处理，知识体系、业务规则和数据资源等内容主要通过数据库预置或代码绑定方式维护，并未作为独立产品能力展开建设。
但从完整产品视角看，系统若要真正具备可持续运营、可扩展复制和可由业务持续驱动迭代的能力，则必须同步建设与运行端相配套的配置体系。其核心作用在于：将报告生成过程中原本依赖业务专家经验完成的结构判断、知识选择、数据映射和提示词调用逻辑，以可配置、可维护、可治理的方式沉淀下来，使系统能够在不同报告类型、不同业务场景和不同输入条件下，稳定输出符合业务要求的结果。结合本产品的设计思路，配置端主要包含三类配置内容：
知识体系配置
业务体系配置
数据资源管理及配置
其中，知识体系配置主要由业务人员维护，用于定义报告可用的章节、知识单元及其相关业务属性；业务体系配置主要用于沉淀会影响智能体决策的支撑性业务体系，并作为规则适配和大纲判断的依据；数据资源管理及配置则主要由运维或技术支持人员维护，用于将业务侧配置的数据需求映射到实际接口、指标平台和外部能力。
配置体系的总体定位
完整产品中的配置体系，主要服务于运行端的稳定执行与持续迭代，其建设目标是通过可视化、结构化的配置方式，将影响报告生成结果的关键业务知识和运行规则从代码中剥离出来，转化为可独立维护的配置资产，令业务人员可在不轻易改变代码的前提下，进行快速的配置和知识的沉淀。
从系统整体关系看，配置体系与运行体系共同构成完整产品的两大基础部分。
配置体系负责定义“系统可以识别什么、在什么条件下执行什么、执行时需要调用什么数据、使用什么模板、产出什么结果”；
运行体系则负责基于一次具体任务的输入，在既有配置基础上完成动态判断、数据准备和报告生成。两者之间并非前后独立关系，而是配置驱动运行、运行反哺配置的关系。
因此，完整产品配置端需要满足以下几方面要求：
能够承载不同报告类型下的知识内容配置；
能够承载影响大纲生成和章节装配的业务判断规则；
能够承载知识单元与数据资源之间的映射关系；
能够支撑不同提示词模板在不同节点下的调用；
能够支持配置内容的持续维护、版本更新和效果迭代。
从使用主体上看，完整产品中的配置体系不应只面向单一角色，而应根据配置类型的不同，由不同职责人员参与维护。其中，知识体系和业务规则更适合由业务专家或产品人员维护；数据资源和接口映射更适合由运维或技术支持人员维护；模板和执行策略则通常由产品、业务和算法协同维护。虽然在MVP阶段无需严格划分角色，但在完整产品设计中应预留这种分工协作的能力基础。
配置端总体设计思路
从产品形态看，配置端首页应作为统一配置入口，支持用户在系统中进入不同配置域进行维护。结合当前设计，首页至少应支持以下两类配置入口：
新建或进入知识体系
新建或进入业务体系
其中，知识体系当前建议按报告类型进行区分管理，即不同报告类型分别维护对应的知识体系；业务体系则作为跨报告类型的基础业务支撑体系存在，用于沉淀可能影响智能体决策的业务分类、业务标签和判断依据。
在展示方式上，知识体系和业务体系均建议采用树状结构进行管理。原因在于两类配置本质上都存在明显的层级关系：知识体系需要体现章节、子章节与知识单元之间的结构关系，业务体系需要体现业务分类、子分类及具体业务项之间的归属关系。树状结构既有利于业务人员理解，也便于后续运行端按层级读取和匹配。
两类体系虽然都采用树状结构，但配置重点不同：
业务体系节点配置相对轻量，主要用于录入业务分类及其说明信息；
知识体系节点配置相对复杂，尤其是最末级知识单元，需要配置业务属性、规则属性、数据需求以及后续生成所需的辅助信息。
此外，数据资源管理虽然与知识体系存在强关联，但不建议直接与知识体系树完全混合在同一页面中维护，而应在业务人员完成知识单元数据需求配置后，通过弹窗、侧边抽屉或关联配置入口的形式，由运维人员补充实际技术参数、接口信息、指标映射和调用方式。这样既能保证业务配置与技术配置职责分离，也能避免业务人员误操作技术配置内容。
配置端首页
页面效果示例
知识体系配置
配置定位
知识体系配置是配置端最核心的部分，主要用于沉淀不同报告类型下的完整知识结构，并将其中真正参与运行端执行的最末级节点定义为知识单元。知识体系既可以维护为一个完整的大一统体系，也可以按不同报告类型拆分为多套体系。从底层逻辑上看，这两种方式并无本质差异，区别主要在于实现复杂度、维护方式和后续运维便利性。
结合当前场景，知识体系更适合先按报告类型进行区分管理。这样一方面可以降低单棵知识树的复杂度，另一方面也更利于业务老师按具体报告场景维护内容。后续若产品成熟，也可以在底层对象统一的前提下，逐步沉淀共享节点、共享模板和跨报告类型复用能力。
知识体系中的每个节点都应支持基础属性配置，但只有最末级节点才作为运行端真正的知识单元参与大纲生成、数据准备和段落生成。因此，配置端需要明确区分“结构节点”和“执行节点”两类对象。
页面组织方式
知识体系配置页面建议采用“左侧树结构 + 右侧配置面板”的方式展开。左侧用于展示当前知识体系的层级结构，支持新增、删除、复制、移动、启停等基础操作；右侧用于展示当前选中节点的配置项。
在交互上，建议支持以下能力：
新建知识体系
选择所属报告类型
在树上新增同级节点或子节点
调整节点顺序
删除节点
复制节点
标记节点是否为最末级节点
查看节点配置是否完整
保存草稿与发布版本
对于最末级节点，应在树上给予明显标识，以便业务人员快速识别哪些节点是真正参与执行的知识单元。
页面效果示例
知识体系列表页
新建知识体系弹窗
知识体系详情配置页
1新增节点弹窗
节点配置内容
知识体系中的每个节点均可配置相关要素，但配置深度随节点层级不同而不同。非最末级节点主要承担结构组织作用，配置内容相对简化；最末级节点需要完整配置与运行端执行相关的业务属性、规则属性和数据需求。
大纲生成相关业务属性
该部分主要用于支持一级大纲生成和完整大纲装配，是知识体系中所有节点都应具备的基础配置。建议包括以下字段：
知识名称（章节名称）：用于定义节点在报告结构中的显示名称，是大纲生成和树状展示的基础字段。
适用报告类型：用于说明该节点适用于哪些报告类型，支持同一节点跨报告类型复用或仅在某一报告类型下生效。
重要性（无独立报告）：用于描述在不存在独立专项报告情况下，该节点在本报告中的重要程度。
重要性（有独立报告）：用于描述在已存在独立专项报告情况下，该节点在主报告中的重要程度。
知识单元类型（技术实现方式）：仅最末级节点需要配置。可选值包括：单元呈现型、批次处理型、外部获取型。该字段用于决定后续完整大纲生成、数据准备和报告生成的执行方式。
额外说明：用于补充该节点在大纲生成阶段的适用边界、压缩原则、特殊要求等，作为模型判断和人工维护时的辅助说明信息。
其中，重要性字段是大纲生成阶段的关键输入，额外说明则用于承接一些难以通过枚举值表达的业务经验，例如“存在独立报告时仅需简单带过”“该内容通常作为承接性章节出现”“在总量受限时可优先压缩”等。
业务规则配置
业务规则配置主要用于描述该知识单元在什么条件下适用、该段落属于什么类型、应如何生成和注意什么问题。该部分与知识单元是一对多关系，也就是说，同一个知识单元可以配置多条业务规则，以适应不同条件下的执行方式。
建议配置内容包括：
规则适用条件：用于定义该规则在何种业务条件下生效，可通过规则引擎表达，例如“企业类型=集团企业”“行业类型=基础设施建设”“报告类型=项目融资主服务报告”等。后续也可逐步支持更复杂的条件组合。
段落类型：用于标识该知识单元应使用哪类提示词模板。当前建议分为：信息陈述型、对象分析型、指标数据描述型、综合判断型。
段落定位说明：用于说明该段落在整篇报告中的写作目标和位置作用，例如“用于交代项目基本事实”“用于承接前文并引出后续融资分析”“用于对已确定方案进行论证说明”等。业务老师撰写后将基于对应的段落类型拼接至响应的提示词模板中。
段落撰写逻辑：用于沉淀该段落的具体写作思路和内容展开逻辑，是后续生成提示词的重要来源之一。业务老师撰写后将基于对应的段落类型拼接至响应的提示词模板中。
输出示例：非必填。主要用于向维护人员说明该段落输出形式和文本风格，不作为固定生成内容。
注意事项说明：用于补充该段落生成时需重点关注的问题，例如“不得进行归因分析”“不得作最终结论”“应强调客观描述”等。
该部分配置的核心价值，在于把“业务老师脑中对这段应怎么写”的隐性经验结构化下来，后续不仅可支撑提示词模板调用，也可为新老师理解知识单元提供直接依据。
数据需求配置
数据需求配置与业务规则配置对应，每条规则原则上对应一套数据需求。原因在于同一知识单元在不同规则条件下，可能使用不同的数据类型或数据重点，因此不能简单将数据需求固化在知识单元层，而应更多与具体规则绑定。
建议配置内容包括：
数据需求：用于配置当前规则需要调用的数据大类，例如工商信息、财务指标、项目信息、股权信息、外部政策信息等。
指标需求：用于配置数据大类下的详细指标或具体内容要求，例如“营业收入、净利润、总资产”“股权结构图、主要股东信息”“项目总投资、建设内容、建设周期”等。
这部分配置由业务人员从“业务上需要什么数据”的角度进行维护，不要求其理解具体接口名称、技术参数或调用方式。其作用是告诉系统和运维人员，该知识单元在该规则下究竟需要哪些内容来支撑生成。
知识单元类型说明
为了支撑运行端差异化执行，知识体系中的最末级节点必须明确知识单元类型。当前建议分为以下三类：
单元呈现型知识单元
单元呈现型知识单元是指：
每次执行时只生成一个固定段落内容的知识单元。
在这种情况下，段落内容对应的是一个明确的章节段落，其生成结果通常只有一段或一组固定内容。例如企业基本情况、项目基本情况、行业概况、财务数据情况说明等。这类内容在报告中通常只出现一次，因此系统只需要调用一次提示词模板即可生成完整段落。
从业务角度来看，单元呈现型知识单元主要用于生成背景说明类或单一分析类内容。在配置时，业务人员只需要确定该段落的提示词模板、所需数据以及撰写逻辑即可，无需考虑重复生成的问题。
典型示例包括：
企业基本情况说明
项目基本情况介绍
行业发展情况说明
财务指标情况描述
融资方案总体说明
这些内容在一篇报告中通常只出现一次，因此适合采用单元呈现型知识单元进行配置。
批次处理型知识单元
批次处理型知识单元是指：
在同一章节中，需要针对多个对象重复生成结构相同的段落内容。
在这种情况下，段落的写作逻辑是相同的，但需要针对不同对象分别生成内容。例如在融资工具分析章节中，报告通常需要分别分析多种融资工具；在集团企业分析章节中，也可能需要分别分析多个业务板块。
对于这类情况，如果采用单元呈现型方式逐个配置，会导致配置工作量较大。因此系统提供批次处理型知识单元，通过一次配置即可针对多个对象自动生成多个段落。
从业务角度来看，批次处理型知识单元通常用于结构相同、对象不同的分析类段落。系统会根据输入数据中的对象列表，逐一调用同一提示词模板生成对应段落，并最终形成完整章节内容。
典型示例包括：
融资工具分析（例如分别分析银行贷款、债券融资、融资租赁等）
集团企业业务板块分析
担保措施分析
还款来源分析
在这些章节中，每一个对象对应一段分析内容，但写作逻辑基本一致，因此适合使用批次处理型知识单元。
外部获取型知识单元
外部获取型知识单元是指：
该类知识单元对应的段落内容，主要不依赖行内系统内置的知识规则、数据加工流程和提示词模板逐步生成，而是通过外部渠道直接获取相对完整的分析结果。
在这种情况下，系统不再重点解决“如何围绕该知识单元组织数据并驱动模型生成”的问题，而是重点解决“如何对接外部能力并接收其返回结果”的问题。也就是说，该类知识单元的核心实现方式，不是内部生成，而是外部获取后接入系统。
对于这类情况，如果仍然按照单元呈现型或批次处理型知识单元进行配置，就需要在行内系统内重复维护大量业务规则、数据需求和生成逻辑，不仅配置成本较高，也可能受限于行内模型能力或数据资源能力，难以稳定产出效果。因此系统提供外部获取型知识单元，用于承接那些更适合由外部专业能力直接完成的段落内容。
从业务角度来看，外部获取型知识单元通常用于对外部信息依赖较强、分析逻辑相对独立、且可由外部成熟产品或智能体直接提供结果的内容。系统在执行时，只需基于当前任务上下文调用外部能力，接收对应分析结果，并将其作为该知识单元的最终段落内容纳入报告。
典型示例包括：
●行业分析
●政策环境分析
●区域经济环境分析
●外部市场趋势分析
在这些章节中，段落内容往往高度依赖外部数据、外部研究能力或外部分析模型，因此更适合通过外部获取型知识单元进行处理。对于系统而言，该类型知识单元的重点不在于配置详细的段落撰写逻辑，而在于配置好外部能力的接入方式、调用关系和结果承接方式。
知识单元提示词模板分类说明
prompt分类说明
信息陈述型模板说明
信息陈述型提示词模板主要用于生成报告中的背景说明类内容。
此类段落的核心作用是对企业、项目或相关事项的基本情况进行客观描述，为后续分析章节提供必要的信息基础。在使用该模板时，模型只负责对已有信息进行整理和展开说明，例如企业基本情况、项目基本情况、建设内容、实施背景等。这类内容通常以事实描述为主，不涉及分析判断或结论推导。
需要特别注意的是，在信息陈述型模板下，模型不会进行原因分析、经营判断或方案建议。生成内容应以客观说明为主，强调信息的完整性与表达的规范性，而不是分析深度。
因此，当业务老师需要生成的是**“介绍情况”或“说明事实”**类段落时，应优先选择信息陈述型模板。
对象分析型模板说明
对象分析型提示词模板主要用于生成报告中的专题分析类内容。
此类段落通常围绕某一具体对象展开，例如融资工具、业务板块、担保方式或市场环境等。在使用该模板时，模型会围绕当前对象从多个角度进行分析和说明，例如对象的基本特征、应用方式、实施条件以及在当前项目背景下的适用情况等。其目的是帮助读者理解该对象在项目中的作用和特点。
需要注意的是，对象分析型模板虽然允许进行分析，但不用于形成最终决策或方案推荐。模型不会对不同对象进行优劣比较，也不会给出明确的推荐结论。
因此，当业务老师需要对某一事项进行多维度分析说明，但尚未进入最终方案决策阶段时，应选择对象分析型模板。
指标数据描述型模板说明
数据描述型提示词模板主要用于生成报告中的指标情况说明类内容。
此类段落通常围绕财务指标、经营指标或项目数据展开，例如收入规模、利润情况、资产结构或资金安排情况等。在使用该模板时，模型的主要任务是对输入数据进行客观描述，例如说明数据规模、结构特征或变化情况。生成内容重点呈现“数据本身”，而不是对数据进行解释或归因。
需要特别注意的是，在数据描述型模板下，模型不会进行原因分析、经营判断或趋势预测。这样设计的主要目的是避免模型生成错误的归因分析，从而保证生成内容的准确性和可靠性。
因此，当业务老师需要展示数据情况或指标表现时，应选择数据描述型模板，而具体的分析判断可以在后续章节中由人工补充或在综合分析章节中统一展开。
综合判断型模板说明
综合判断型提示词模板主要用于生成报告中的方案论证类内容。
此类段落通常位于报告后半部分，例如融资方案说明、融资路径安排或产品选择结论等。在使用该模板时，模型会围绕已经确定的方案或安排进行系统性论述，对方案的实施逻辑、结构安排以及适配性进行充分说明。其主要作用是将既定结论转化为完整、连贯的报告文本。
需要特别注意的是，综合判断型模板并不用于进行方案选择或决策。方案本身通常已经由业务规则或前序模块确定，模型的职责是对该方案进行论证和说明，而不是重新进行决策。
因此，当业务老师需要生成的是方案说明或结论性章节时，应选择综合判断型模板。
补充说明
基于上述知识单元分类，其提示词模板会存在细节内容的差异：
蓝色变量内容为需要基于任务起点用户勾选或录入的内容进行填充 。
橙色变量内容为任务过程中获取的结果，例如大纲生成阶段输出的报告撰写思路说明，数据处理阶段处理后的数据。
红色变量内容为需要业务人员提前配置好的知识单元中的内容，拼接至该prompt中。
prompt模板
信息陈述型
【角色与任务定义】
你是银行正式{报告类型}报告中的正文生成模块，当前负责生成报告中的一个章节段落内容。
你的任务是：
在不进行分析推理、不形成结论判断、不进行方案比较的前提下，基于输入信息与输入数据，对相关情况进行完整、连续、规范的说明性描述，生成可直接用于正式财务顾问报告正文的章节段落内容。
本模块生成的内容属于报告正文部分，需要保证行文完整、语气审慎、结构清晰，整体风格应符合银行正式财务顾问报告的写作规范。
###
【整篇报告撰写思路与整体语境】
{报告整体撰写逻辑说明}
说明：
该部分用于描述整篇报告在当前项目背景下的总体写作视角、分析逻辑与行文思路，用于保证各章节之间的表达方式保持一致。
生成本章节内容时必须保持与上述整体语境一致。
###
【当前一级章节写作逻辑】
{当前一级章节写作逻辑}
说明：
该部分用于描述当前一级章节在整篇报告中的功能定位，以及该章节在整体报告结构中的作用。生成内容时必须围绕该章节的主题展开，不得偏离章节核心内容。
###
【段落定位】
{段落定位说明}
说明：用于描述本段落的撰写目标及在整篇报告中的定位说明。
###
【输入信息】
{任务起点业务录入信息}
###
【相关数据】
{段落相关数据，涵盖指标、文本、json等}
###
【段落撰写逻辑】
{段落撰写逻辑}
###
【输出示例（非必须）】
{示例}
说明：示例内容仅用于说明文本结构形式，实际生成内容应结合输入信息进行调整。
###
【任务要求】
当前需要生成的内容属于一级章节中的具体段落内容，其主要作用是对相关情况进行客观说明，为其他分析章节提供基础信息支撑。
本段落属于说明性内容，仅用于说明事实情况，不承担分析判断或方案设计功能。
###
【需要特别注意的事项】
生成内容时必须严格遵守以下要求：
1、不得进行分析推理：不得出现“因此”“可以看出”“说明了”“表明”等明显分析性表述。
2、不得形成结论判断：不得对企业、项目或任何事项作出评价性结论。
3、不得进行方案比较：不得出现不同对象之间的比较描述。
4、不得逐条解释输入信息：输入信息与输入数据应自然融入叙述文本，不得直接按输入结构进行罗列。
5、不得引入外部信息：不得引用输入信息之外的行业数据、政策条款或其他外部资料。
6、不得出现系统或规则说明：不得提及模型、规则、判断逻辑、数据处理过程或任何系统行为。
7、保持正式报告语气：整体语气必须稳健、客观、专业，符合银行正式财务顾问报告的写作风格。
###
【其他需要特别注意的事项】
{注意事项说明}
说明：除了上述共性约束外的单独注意事项。
对象分析型
【角色与任务定义】
你是银行正式{报告类型}报告中的正文生成模块，当前负责生成报告中的一个章节段落内容。
你的任务是：
围绕当前分析对象，在不进行方案选择、不进行对象之间优劣比较的前提下，基于输入信息与输入数据，对相关对象进行多维度分析与说明，生成可直接用于正式财务顾问报告正文的章节段落内容。
本模块生成的内容属于报告正文部分，需要保证行文完整、语气审慎、结构清晰，整体风格应符合银行正式财务顾问报告的写作规范。
###
【整篇报告撰写思路与整体语境】
{报告整体撰写逻辑说明}
说明：
该部分用于描述整篇报告在当前项目背景下的总体写作视角、分析逻辑与行文思路，用于保证各章节之间的表达方式保持一致。
生成本章节内容时必须保持与上述整体语境一致。
###
【当前一级章节写作逻辑】
{当前一级章节写作逻辑}
说明：
该部分用于描述当前一级章节在整篇报告中的功能定位，以及该章节在整体报告结构中的作用。生成内容时必须围绕该章节的主题展开，不得偏离章节核心内容。
###
【段落定位】
{段落定位说明}
说明：用于描述本段落的撰写目标及在整篇报告中的定位说明。
###
【输入信息】
{任务起点业务录入信息}
###
【相关数据】
{段落相关数据，涵盖指标、文本、json等}
###
【段落撰写逻辑】
{段落撰写逻辑}
###
【输出示例（非必须）】
{示例}
说明：示例内容仅用于说明文本结构形式，实际生成内容应结合输入信息进行调整。
###
【任务要求】
●当前需要生成的内容属于一级章节中的具体段落内容，其主要作用是围绕当前分析对象展开系统性说明与分析，为后续方案设计或综合判断提供分析基础。
●本段落属于分析性内容，需要围绕对象本身展开多维度说明与分析，但不得形成最终结论或方案建议。
●分析应围绕对象的特征、应用方式、实施条件或相关背景展开，通过连续段落形成完整论述，不得仅进行简单描述。
###
【需要特别注意的事项】
生成内容时必须严格遵守以下要求：
1、不得进行方案选择：不得明确推荐某一方案或路径。
2、不得进行对象优劣比较：不得出现“更适合”“优于”“相比之下”等比较性表述。
3、不得形成最终结论：不得给出明确决策性判断。
4、不得逐条解释输入信息：输入信息与输入数据应自然融入叙述文本，不得直接按输入结构进行罗列。
5、不得引入外部信息：不得引用输入信息之外的行业数据、政策条款或其他外部资料。
6、不得出现系统或规则说明：不得提及模型、规则、判断逻辑、数据处理过程或任何系统行为。
7、保持正式报告语气：整体语气必须稳健、客观、专业，符合银行正式财务顾问报告的写作风格。
###
【其他需要特别注意的事项】
{注意事项说明}
说明：除了上述共性约束外的单独注意事项。
指标数据描述型
【角色与任务定义】
你是银行正式{报告类型}报告中的正文生成模块，当前负责生成报告中的一个章节段落内容。
你的任务是：
基于输入信息与输入数据中的相关指标，对企业或项目相关情况进行客观的数据情况描述，生成可直接用于正式财务顾问报告正文的章节段落内容。
本模块生成的内容属于报告正文部分，需要保证行文完整、语气审慎、结构清晰，整体风格应符合银行正式财务顾问报告的写作规范。
###
【整篇报告撰写思路与整体语境】
{报告整体撰写逻辑说明}
说明：
该部分用于描述整篇报告在当前项目背景下的总体写作视角、分析逻辑与行文思路，用于保证各章节之间的表达方式保持一致。
生成本章节内容时必须保持与上述整体语境一致。
###
【当前一级章节写作逻辑】
{当前一级章节写作逻辑}
说明：
该部分用于描述当前一级章节在整篇报告中的功能定位，以及该章节在整体报告结构中的作用。生成内容时必须围绕该章节的主题展开，不得偏离章节核心内容。
###
【段落定位】
{段落定位说明}
说明：用于描述本段落的撰写目标及在整篇报告中的定位说明。
###
【输入信息】
{任务起点业务录入信息}
###
【相关数据】
{段落相关数据，涵盖指标、文本、json等}
###
【段落撰写逻辑】
{段落撰写逻辑}
###
【输出示例（非必须）】
{示例}
说明：示例内容仅用于说明文本结构形式，实际生成内容应结合输入信息进行调整。
###
【任务要求】
●当前需要生成的内容属于一级章节中的具体段落内容，其主要作用是基于相关指标数据，对企业或项目的相关数据情况进行客观描述。
●本段落属于数据描述型内容，应围绕输入数据中的指标信息，对指标规模、结构特征或变化情况进行说明。
●内容应重点呈现数据情况本身，通过连续段落进行描述，但不得对数据形成原因解释或经营判断。
###
【需要特别注意的事项】
生成内容时必须严格遵守以下要求：
1、不得编造数据：所有涉及指标的描述必须基于输入数据，不得虚构或补充未提供的数据。
2、不得进行原因分析：不得解释指标变化的原因，不得进行归因分析。
3、不得形成经营判断：不得出现“说明企业经营良好”“体现企业盈利能力提升”等评价性表述。
4、不得进行趋势推断：不得对未来情况进行预测或判断。
5、不得逐条解释输入信息：输入信息与输入数据应自然融入叙述文本，不得直接按输入结构进行罗列。
6、不得引入外部信息：不得引用输入信息之外的行业数据、政策条款或其他外部资料。
7、不得出现系统或规则说明：不得提及模型、规则、判断逻辑、数据处理过程或任何系统行为。
8、保持正式报告语气：整体语气必须稳健、客观、专业，符合银行正式财务顾问报告的写作风格。
###
【其他需要特别注意的事项】
{注意事项说明}
说明：除了上述共性约束外的单独注意事项。
综合判断型
【角色与任务定义】
你是银行正式{报告类型}报告中的正文生成模块，当前负责生成报告中的一个章节段落内容。
你的任务是：
在既定方案或既定结论基础上，对相关安排进行系统性论述和合理性说明，生成可直接用于正式财务顾问报告正文的章节段落内容。
本模块生成的内容属于报告正文部分，需要保证行文完整、语气审慎、结构清晰，整体风格应符合银行正式财务顾问报告的写作规范。
###
【整篇报告撰写思路与整体语境】
{报告整体撰写逻辑说明}
说明：
该部分用于描述整篇报告在当前项目背景下的总体写作视角、分析逻辑与行文思路，用于保证各章节之间的表达方式保持一致。
生成本章节内容时必须保持与上述整体语境一致。
###
【当前一级章节写作逻辑】
{当前一级章节写作逻辑}
说明：
该部分用于描述当前一级章节在整篇报告中的功能定位，以及该章节在整体报告结构中的作用。生成内容时必须围绕该章节的主题展开，不得偏离章节核心内容。
###
【段落定位】
{段落定位说明}
说明：用于描述本段落的撰写目标及在整篇报告中的定位说明。
###
【输入信息】
{任务起点业务录入信息}
###
【相关数据】
{段落相关数据，涵盖指标、文本、json等}
###
【段落撰写逻辑】
{段落撰写逻辑}
###
【输出示例（非必须）】
{示例}
说明：示例内容仅用于说明文本结构形式，实际生成内容应结合输入信息进行调整。
###
【任务要求】
●当前需要生成的内容属于一级章节中的具体段落内容，其主要作用是在既定方案或既定安排基础上，对相关方案的合理性与实施逻辑进行系统说明。
●本段落属于综合判断型内容，应围绕既定方案或既定安排展开论述，通过连续段落对方案背景、实施逻辑及结构安排进行完整说明。
●内容应重点说明该方案在当前项目条件下的适配性、实施基础以及整体安排逻辑，但不得改变既定方案或新增其他方案。
###
【需要特别注意的事项】
生成内容时必须严格遵守以下要求：
1、不得改变既定方案：必须基于输入信息中已经确定的方案或安排进行说明，不得新增、替换或删除方案。
2、不得进行方案选择过程说明：不得描述筛选逻辑、比较过程或规则判断过程。
3、不得进行方案之间的比较：不得出现“更适合”“优于”“相比之下”等比较性表述。
4、不得引入新的决策判断：不得提出新的融资工具、融资路径或方案设计。
5、不得逐条解释输入信息：输入信息与输入数据应自然融入叙述文本，不得直接按输入结构进行罗列。
6、不得引入外部信息：不得引用输入信息之外的行业数据、政策条款或其他外部资料。
7、不得出现系统或规则说明：不得提及模型、规则、判断逻辑、数据处理过程或任何系统行为。
8、保持正式报告语气：整体语气必须稳健、客观、专业，符合银行正式财务顾问报告的写作风格。
###
【其他需要特别注意的事项】
{注意事项说明}
说明：除了上述共性约束外的单独注意事项。
业务体系配置
配置定位
业务体系配置主要用于沉淀和管理可能影响智能体实际决策的支撑性业务体系。它并不直接参与段落生成，而是作为知识单元适配、大纲生成判定和规则触发的基础支撑。
简单来说，知识体系回答的是“系统可以写什么”，业务体系回答的是“在什么业务分类和业务条件下应当如何判断”。
例如企业类型、行业类型、报告类型、融资工具类型等，均属于会直接影响知识单元适配结果的重要业务体系。
页面组织方式
业务体系配置同样建议采用树状结构管理，但相较知识体系，其节点配置应更轻量。首页进入业务体系后，可按业务类别分别建立体系，例如：
企业类型体系
行业类型体系
报告类型体系
融资工具体系
其他决策影响体系
每类体系下再按业务实际情况逐步扩展子节点。由于这部分内容本质上更接近业务基础字典与业务分类知识，因此建议仅开放给运维或产品管理角色维护，业务人员不得直接编辑，以保证其稳定性和统一性。
页面效果示例
业务体系列表页
新增业务体系弹窗页
同知识体系新增弹窗示例
业务体系详情页
节点配置内容
当前业务体系节点建议至少支持以下内容：
业务项名称
上级业务项
业务项说明文本
是否启用
适用范围说明
其中，业务项说明文本主要用于录入该业务项在实际业务中的解释和边界，例如某类企业类型的定义、某类行业的适用说明、某类报告的适用条件等。后续这些内容既可用于规则配置界面引用，也可作为模型判断时的辅助说明。
与知识体系的关系
业务体系配置并不是孤立存在的，其核心用途是为知识体系中的业务规则提供可引用的判断维度。
例如，某知识单元的规则可配置为：当企业类型 = 集团企业时生效
当行业类型 = 基础设施建设时生效
当报告类型 = 项目融资主服务报告时生效
也就是说，业务体系更多承担“标准化业务选项池”的作用，便于规则配置时统一引用，而不是让每位业务老师用自由文本方式反复录入。
数据资源管理及配置
配置定位
数据资源管理及配置主要用于承接业务人员在知识单元中配置的数据需求，并将这些业务需求映射为实际可执行的技术参数。
该部分不由业务人员维护，而主要由运维或技术支持人员结合实际数据情况进行配置。其核心目的是打通知识单元“需要什么数据”和系统“如何取得这些数据”之间的链路。
页面组织方式
数据资源配置不建议与知识体系主页面完全混合，而应作为知识单元的关联配置能力存在。
具体实现上，可以在业务人员完成某一知识单元的数据需求配置后，额外提供“数据资源配置”入口，由运维老师通过弹窗、抽屉页或独立配置页补充实际技术参数。这种方式的好处在于：
业务老师只关心“需要什么数据”
运维老师只关心“怎么取到这些数据”
两类配置职责清晰，不相互干扰
页面效果示例
数据资源配置抽屉页
注：该部分页面主要参考逻辑，实际页面元素需结合行内实际数据库、API接口等实际数据资源情况进行设计。
配置内容
运维侧数据资源配置建议至少包括以下内容：
对应知识单元 / 对应业务规则
接口ID或数据源标识
数据资源类型（接口、指标平台、RAG、外部服务等）
输入参数配置
参数映射方式
返回字段说明
结果整理方式
是否启用
异常处理说明
其中，输入参数配置和参数映射方式是该部分最关键的内容。因为业务侧配置的数据需求通常只写“需要哪些数据”，而真正落地到技术执行层时，还需要明确这些数据通过哪个接口获取、传什么参数、参数从任务输入的哪个字段映射而来、结果返回后如何整理成知识单元可消费的内容。
与知识体系和业务规则的关系
数据资源配置本质上是对知识单元数据需求的技术实现补全，因此其配置粒度不宜只停留在知识单元层，更适合与“知识单元 + 业务规则”组合关联。原因在于：同一个知识单元在不同规则场景下，可能需要调用不同的数据资源或采用不同的数据重点。因此，完整产品中建议采用如下关系：
业务老师在知识体系中配置知识单元及其规则
在规则下配置业务数据需求
运维老师再针对该规则配置对应的数据资源和技术参数
通过这种方式，可以使业务配置与技术配置一一对应，避免后续运行端无法判断某条规则究竟该调用哪组数据资源。
配置端角色分工建议
从完整产品角度看，配置端不应由单一角色全权维护，而应根据配置类型划分职责边界。
业务人员主要负责知识体系配置，包括章节结构、知识单元重要性、知识单元类型、业务规则、段落类型、段落撰写逻辑及数据需求等内容。
运维或技术支持人员主要负责业务体系维护和数据资源管理配置，包括业务分类维护、接口参数配置、指标映射、外部能力接入等内容。
产品人员则负责统筹配置口径、字段设计、模板分类和配置规范，确保不同配置之间能够形成统一的逻辑闭环。这种分工方式能够避免业务人员承担过多技术配置工作，也能避免运维人员直接参与知识逻辑维护，从而保证配置端长期运行的稳定性和可维护性。