1框架来源
这一步只做一件事：定下这份报告基于哪个框架。可以是刚提炼出来的、资产库里攒下的，
或别人给你的 JSON；多主体同构报告（投后报告 / 门店月报这类，一章一个主体）也可以直接用「从名单新建」。
从框架资产库选一份
资产库存在浏览器本地（IndexedDB，一份一条记录），是纯业务资产 —— 将来可以随云端文档库一起走；
密钥不在此列。提炼完成会自动入库，所以资产会一直攒着，不会被下一次提炼覆盖。
2知识卡（垂直领域的专业做法与写法规范）
知识卡库 →
从库里点选知识卡（最多 3 张，按点选顺序生效）：第 ① 张决定文书骨架，
其余张补充专业做法与写法规范 —— 两类卡可以叠着用（如「尽职调查报告」定骨架 ＋「医药行业研究」补行业做法）。
卡片随系统提示词注入到每一个节点的生成里：专业做法 → 文体与必写项 → 措辞禁忌、术语与引用规范。
还没有合适的卡？去「知识卡库」用这个领域的语料生成一张，或直接从预设的 8 张里挑 ——
改名字、删除也在那边做。
知识卡管的是"怎么做才算专业"（专业做法与写法规范），不提供任何事实。
法条原文、判例要旨、监管口径、合同条款这类内容必须靠「挂素材」给原文 ——
卡片不会替你补，素材里没有的一律写成「公开渠道未获取」。
这是故意的：只把措辞模仿得像，专业读者一眼就能看穿；
模型凭记忆写出来的条文，往往最像样、也最危险，正式文书里不能这么用。
3统一口径与全局写作要求
口径锁住"事实与命名"，写作要求锁住"这次的偏好"。加上第 2 步的知识卡，三层都会随每个节点的提示词一起发出：口径 → 知识卡 → 写作要求（后者优先级更高）。
节点一多，最容易跑偏的就是这些：主体一会儿叫全称一会儿叫简称、金额单位前后不一致、
同一个科目两种叫法。口径表就是为了把这类漂移压住 ——
它固定不变，还能命中 prompt 缓存，所以带上它几乎不额外花钱。
全局要求放进系统提示词、节点要求放进用户消息 —— 这样同一批生成里，系统提示词逐字相同，
能命中厂商的 prompt 缓存（DeepSeek 命中价约为未命中的十分之一），批量生成时省钱明显。