SenseNova-Skills 深度研究：outline.json 编排字段契约深度解析——从范式选择、内容单元到证据路由的 heavy 模式报告编排规范

AI 技能人工智能深度研究数据分析媒体生成【免费下载链接】SenseNova-SkillsModular SenseNova skills for building AI-powered office assistants and productivity workflows项目地址https://gitcode.com/gh_mirrors/se/SenseNova-Skills点击查看免费下载本文是 SenseNova-Skills 仓库中 sn-deep-research 技能包报告编排字段契约outline.schema.md的完整技术解读。该契约服务于 heavy 深度研究档位的成品编排阶段研究证据完成后由 report-planner 角色生成outline.json与逐单元证据子集将内容如何推进paradigm与核心信息由什么结构承载organization_decision content_units两个问题固化为可被机器严格校验的 JSON 合同。读完本文你将掌握outline.json全部顶层字段、九种内容单元类型、L0 草稿、样式契约、断言路由表、扫描摘要与证据子集的构造规则并能直接使用仓库内置的validate_outline.py完成硬校验门控。一、契约定位outline.json 在深度研究流水线中的角色在 sn-deep-research 的多 Agent 编排中outline.json只出现在heavy完整审计档位。quick / normal 档位由 report-writer 使用write_modequick_synthesis一次成文不产生 outlineheavy 档位则按scout → plan → research → review/perspective → supplement-planner → report-planner → 并发 writer → stitcher → 终稿 review → render的完整流程执行见 SKILL.md。report-planner 处于证据完成之后、写作之前的编排节点其职责在 report-planner.md 中被明确为回答两个互不替代的问题内容怎么推进 - paradigm 核心信息由什么结构承载 - organization_decision content_units规划器的 payload 由总控角色SKILL.md §5.7派发关键输入输出如下schema_path: {plugin_skills_dir}/sn-deep-research/schemas/outline.schema.md output_outline: {report_dir}/outline.json output_subsets_dir: {report_dir}/content_units/产出物落在单一报告目录{report_dir}下命名规则为YYYY-MM-DD-{topic}-{hex4}4 位随机十六进制运行号其中{report_dir}/outline.json {report_dir}/content_units/{unit_id}.evidence_subset.json {report_dir}/content_units/{unit_id}.md从源码结构可以确认规划器必须先完整读取 schema 再生成 outline且 heavy 模式下outline.json使用content_units键、禁止出现sections键校验器以 U008 错误强制此约定。二、顶层结构一份双轨决策的编排清单outline.json顶层包含七个字段将信息推进方式与产物组织决策严格分离{ paradigm: { main: comparison, secondary: evaluation }, depth_level: deep_analysis, global_arc: 从用户的选择问题出发先统一比较口径再用现有证据呈现差异、冲突和适用边界最后给出有条件的判断。, organization_decision: { ...: 见下文 }, L0_draft: { ...: 见下文也可以为 null }, style_contract: { ...: 见下文 }, content_units: [ ... ], claim_routing_table: { ...: 见下文 }, scan_summary: { ...: 见下文 } }字段类型说明paradigm对象内容推进范式不决定产物结构depth_level枚举overview/deep_analysis/expert_levelglobal_arc字符串非空的全文方向和证据边界不设置字符数限制organization_decision对象证据完成后的结构决定L0_draft对象 /null是否存在由opening_summary决定style_contract对象体裁、语气、术语和引用约定content_units数组1–20 个有序交付单元claim_routing_table对象每个被引用断言的唯一主归属与可选次级引用scan_summary对象规划器扫描证据后得到的可审计摘要两个最关键的顶层语义约束是paradigm只表达论证如何推进不映射到任何产物结构。comparison范式要求让差异可比较但不强制使用表格investigation也可以承载在diagram或narrative单元上。organization_decision必须在扫描完整证据后产生先看 evidence再定组织结构请求级format只锚定最终形式不能反过来推导内容结构。这一设计在 validate_outline.py 的源码注释中得到了直接印证# Organization decision is intentionally separate from paradigm. Nothing here maps one enum to the other.组织决策有意与范式分离此处没有任何枚举映射逻辑。三、paradigm 与 depth_level范式评分的边界paradigm.main与paradigm.secondary只能取六种内容范式之一panorama/comparison/investigation/timeline/evaluation/forecast。校验规则validator 的 U002–U004main必须是六种范式之一secondary必须为null或六种范式之一main与secondary不得相同。范式选择来自scan_summary.reader_task_signal的评分规则在 report-planner.md Phase 2 中规定最高分为paradigm.main第二高且至少 0.2时可作为secondary否则为null。注意范式评分只约束信息推进逻辑绝不允许从最高分自动推出 content unit type——这也是 validator 中不存在任何范式→结构映射表的根本原因。depth_level三档枚举为overview概览/deep_analysis深度分析/expert_level专家级由校验器 U005 强制。四、organization_decision证据完成后的结构决定organization_decision是核心信息由什么结构承载的最终答案包含七个字段结构示例{ reader_task: 让采购负责人按同一口径比较三个方案并识别在不同约束下的适用边界, primary_unit_type: matrix, supporting_unit_types: [callout, narrative], opening_summary: recommendation, toc: false, numbered_headings: false, evidence_fit: 现有证据对三个对象覆盖同一组指标适合用矩阵承载主体分歧和口径限制由 supporting units 解释。 }字段约束说明reader_task非空字符串读者最终要完成的动作理解/复核/比较/筛选/判断/执行/追踪primary_unit_type内容单元枚举承载核心结果的主体结构supporting_unit_types去重数组可为空补充结构的类型集合opening_summarynone/findings/recommendation是否生成开篇摘要及摘要形态toc布尔是否生成目录numbered_headings布尔标题是否带稳定序号evidence_fit非空字符串证据形状与所选结构的匹配理由关键规则supporting_unit_types是去重数组且可为空toc与numbered_headings必须由已确认形式决定不能使用报告式默认值——即使formatreport也不代表自动开启目录或编号标题report-planner Phase 3A 与 stitcher Step 4 均强调这一点。numbered_headingstrue时所有show_headingtrue的单元标题必须在 outline 中直接携带稳定序号如1. ...、2. ...单元文件逐字使用该标题。规划器的决策问题清单Phase 3B是填写该对象的实操路径读者最频繁的动作是什么连续阅读、横向扫读、逐项核对、按时间追踪、按标准评分、按问题查找、理解关系evidence 是否具备该结构需要的共同口径、时间锚点、评分标准或关系链哪种结构能直接承载核心结果而不是只做装饰哪些解释、冲突和限制需要 supporting units五、内容单元类型九种信息语义content_units[]中的每个单元都有一个type基础枚举为narrative连续论述。matrix实体乘维度的二维比较。timeline按时间或阶段组织的事件链。checklist逐项核对状态、要求或完成度。scorecard按标准给出等级、分数或判断。qa独立问题与回答。callout关键事实、冲突、缺口或限制。diagram流程、因果、关系或系统结构。custom用户定义的其他结构必须通过render_contract.instructions说明。三条结构性纪律report-planner Phase 5A 强调结构件可以是主体矩阵、时间线、清单、评分卡和关系图不再只是 narrative 章节的辅助 visualunit 是交付边界不是章节别名只需一张主矩阵时就建立一个 primary matrix unit不为迎合报告样式拆成摘要、三章和结论一个原子结构不要拆成多个 unit同一张主矩阵、同一条连续时间线、同一份检查表应由一个单元完成单元数量由真实交付结构决定最少可以是 1。六、L0_draft受 opening_summary 严格耦合的草稿L0_draft是否存在完全由opening_summary决定opening_summarynone时L0_draft必须为nullopening_summaryfindings|recommendation时L0_draft必须存在。{ headline: 三个方案的最优选择取决于规模门槛与部署约束, key_findings: [ 方案甲在大规模负载下成本最低但前期部署与迁移要求最高, 方案乙在中等规模下保持成本和交付速度的平衡证据覆盖最完整, 方案丙适合快速启动但长期成本与扩展性数据仍存在明显缺口 ], abstract_visual: { form: comparison-table, data_refs: [d1.c1, d2.c1, d3.c1] } }约束validator U020–U024 逐一强制headline必须非空key_findings保持 3–5 条且每条非空abstract_visual的form只能取已定义的视觉形态如bar-chart、comparison-table、metric-strip、timeline、flowchart、evidence-gap-callout等十余种事实型data_refs必须是 1–30 个有效的断言 ID形如d1.c1且这些断言必须进入内容单元路由自然语言字段不设置字符数限制。写作纪律同样重要report-planner Phase 4不把 gap 写成 finding不把 dimension 的 key_findings 直接拼接。L0 的每条 finding 都必须能在正文 primary/supporting 单元中找到对应内容stitcher 在 Step 3 会逐条比对正文没有对应内容的删除、表达过强的收窄并同步回写 outline 的L0_draft。七、style_contract只控表达不控结构{ register: executive_memo, voice: declarative_executive, terminology: { preferred: { 总拥有成本: [TCO, 全周期成本] } }, citation_style: footnote }枚举validator U030–U033 强制registerresearch_brief|academic|executive_memo|industry_report|policy_analysisvoiceneutral_analytical|hedged_scholarly|declarative_executive|opinionated_supportedcitation_stylefootnote|inlineterminology.preferred是一个标准术语 → 变体列表映射供 stitcher 在组装阶段统一自然语言变体但引用键、URL、文件路径、Mermaid 代码块内的标识符、source id、正式产品名与表格数值不得被替换见 report-stitcher.md Step 5。从源码可见terminology.preferred的每个键必须是非空字符串、每个变体也必须非空validator U033。style 只控制表达不控制内容结构——这是整个契约反复强调的边界。八、content_unit可执行的最小交付单元一个完整的内容单元示例{ id: u1, type: matrix, role: primary, title: 三个方案的核心指标与适用边界, reader_task: 按一致口径比较成本、交付、扩展性与主要风险, word_budget: 900, lead: 三个方案没有脱离场景的统一最优解规模门槛和交付约束会改变排序。, render_contract: { mode: markdown_table, show_heading: true, schema: [方案, 成本, 交付周期, 扩展性, 适用边界], instructions: 用一张主矩阵承载所有同口径结果每格只写结论和必要引用口径差异放表注。 }, elements: [ { id: e1, label: 方案甲, purpose: 呈现方案甲在统一指标下的结果与限制, evidence_refs: [ { claim_id: d1.c1, role: primary_support }, { claim_id: d1.c2, role: counter } ], writing_context_refs: [d1.w1] } ], evidence_subset: [d1.c1, d1.c2] }8.1 通用字段字段约束说明id^u\d$内容单元的唯一 IDtype内容单元枚举信息语义不强制具体 Markdown 渲染方式roleprimary|supporting主体或补充结构title非空字符串可展示标题是否显示由渲染契约决定。numbered_headingstrue且显示标题时标题本身必须带稳定序号reader_task非空字符串读者使用该内容单元完成什么任务不要求写成问句word_budget50-3000包含表格、列表和图中可见文字的粗略预算leadnull或非空字符串需要先给结论时使用结构件不需要开场时为nullrender_contract对象Markdown 形态和字段契约elements1–20 项内容单元内的行、问题、事件、检查项、论点或其他可执行元素evidence_subset0–30 个断言写作智能体可见的事实边界仅表达缺口的内容单元可以为空但必须路由写作上下文从 validate_outline.py 的实现看word_budget的机械校验是正整数schema 给出的 50–3000 是推荐的粗略预算区间校验器不强行限制具体范围lead必须为null或非空字符串null时写作端不得补开场白。8.2 渲染契约type 与 mode 不做硬映射{ mode: prose|markdown_table|ordered_list|checklist|qa|callout|mermaid|mixed|custom, show_heading: true, schema: [字段或列名], instructions: 非空的具体渲染约束 }mode与type不做硬编码映射。timeline可渲染为表格、列表或 Mermaidinvestigation也可以使用diagram或narrative。type 描述信息语义mode 描述 Markdown 实现。schema是 0–20 个去重字段名。矩阵可以填写列名timeline可以填写事件字段narrative可以留空。instructions必须说明本内容单元如何承载主要信息不能只写按要求输出validator U053 强制非空。渲染契约与下游 writer 的对应关系见 report-writer.md Step 3值得单列markdown_tableschema原样成为列名不能临时增删列checklist使用- [x]/- [ ]或状态标签只有证据足以确认时才勾选callout使用 Markdown blockquote明确区分关键事实、证据冲突、证据缺口或限制不把冲突双方合成折中说法mermaid只承载当前 evidence refs 支持的关系、时间或数值标签内避免未转义的:[]custom逐字落实instructions仍须遵守 element、evidence 和引用边界。8.3 元素与证据边界硬约束每个元素字段id内容单元内唯一匹配^e\d$。label非空字符串。purpose非空字符串。evidence_refs0–10 条每条包含合法的claim_id和叙事角色。为空时writing_context_refs必须非空并且只能表达有记录支撑的证据缺口。writing_context_refs可选0–20 个dN.wM。evidence_refs[].role沿用证据体系的叙事角色枚举primary_support|supporting_context|quantifier|counter|reference_only。边界是硬约束validator U064–U068、U070 逐一强制单个元素最多包含 10 个证据引用断言与写作上下文不得同时为空。单个内容单元的evidence_subset最多包含 30 个去重断言。evidence_subset必须与所有elements[].evidence_refs[].claim_id的去重并集完全相同。写作智能体只能读取和引用自己的证据子集不得从其他内容单元或完整证据中补充材料。dN.cM/dN.wM的 ID 体系来自 evidence.schema.mdclaims[]的 ID 形如d1.c1属于维度 d1 的第 1 条断言writing_context[]的 ID 形如d1.w1维度 d1 的第 1 条写作上下文。outline 只是引用这些 ID不复制证据全文。九、claim_routing_table断言的路由纪律claim_routing_table为每个被引用的断言分配唯一的主归属和可选的次级引用{ d1.c1: { primary: u1, secondary: [ { unit: u3, role: supporting_context } ] } }四条路由纪律validator U080–U086 强制每个进入任一evidence_subset的断言必须有且只有一个主内容单元主内容单元必须实际在元素中使用该断言即primary值必须真实出现在某元素的evidence_refs中次级角色只能是supporting_context|reference_only以避免在多个内容单元中重复展开同一断言路由键集合必须精确覆盖所有内容单元引用的断言不允许存在未使用的路由项也不允许空路由或隐藏复用。从源码确认claim_routing_table的每个键必须匹配^d\d\.c\d$primary必须是 outline 中存在的单元 IDsecondary数组内的unit不能与primary重复、也不能在数组内重复次级role只接受supporting_context或reference_onlyvalidator U086。当同一断言需要在多个单元详细展开时规划器应选择最贴合reader_task的单元作为 primary其余降级为次级引用report-planner Phase 6。十、scan_summary可审计的证据扫描摘要scan_summary是规划器扫描全部 evidence 后留下的可审计痕迹{ totals: { claims: 18, sources: 12, primary_ratio: 0.67 }, topic_clusters: [], conflicts: [], key_entities: [], timeline_density: [], gaps: [], reader_task_signal: { panorama: 0.05, comparison: 0.55, investigation: 0.05, timeline: 0.05, evaluation: 0.25, forecast: 0.05 } }字段契约validator U100–U104totals.claims/totals.sources为非负整数primary_ratio必须在[0, 1]区间topic_clusters、conflicts、key_entities、timeline_density、gaps均为数组conflicts[]对象带有severitylow|medium|highreader_task_signal只为六种内容范式评分与paradigm枚举完全一致每项取值在[0, 1]合计约为 1。Schema 原文强调reader_task_signal只为六种内容范式评分不增加结构类型得分也不用于自动映射primary_unit_type。结构决定写入独立的organization_decision。规划器扫描时还需提炼全局图谱claim/source 总数与 primary ratio、主题簇、跨维度重复 claim、support/refute 冲突、关键实体、同口径可比维度、时间密度和证据缺口——各维度的key_findings只是扫描起点outline 的判断必须跨维度重新提炼。十一、evidence_subset.json写作智能体的事实边界每个内容单元配套一份{unit_id}.evidence_subset.json{ content_unit_id: u1, claims: [ { id: d1.c1, text: ..., kind: factual, polarity: neutral, topic_tag: cost, narrative_role: primary_support, evidence: [...] } ], writing_context: [], sources: [] }输出规则content_unit_id必须存在于outline.content_unitsvalidator U203 强制且文件名必须精确为{unit_id}.evidence_subset.jsonclaims、writing_context与sources中的对象必须具备合法字段传入原始证据时断言和写作上下文 ID 必须存在于所提供的 evidence 文件中子集必须包含本内容单元元素实际引用的断言和写作上下文额外对象不会仅因重复索引关系而直接判错sources必须覆盖断言和写作上下文引用的来源 IDvalidator U211 强制 sources[] does not cover all referenced source_ids。从 validate_outline.py 可确认子集缺失单元元素实际引用的断言会直接报 U210 错误子集文件名与content_unit_id不一致报 U200 错误outline 中每个内容单元必须恰好对应一份子集文件缺失或重复都会报错U200。被当前 outline 引用但属于旧运行遗留的子集文件会被记为 U200 警告并忽略。十二、最小示例一份可运行的 outline.json以下是最小合法示例覆盖 checklist 主单元、无开篇摘要、research_brief 样式契约与完整路由{ paradigm: { main: evaluation, secondary: null }, depth_level: overview, global_arc: 围绕用户需要作出的选择按统一标准核对关键证据、相反信息和适用边界给出受证据强度约束的判断。, organization_decision: { reader_task: 快速核对方案是否满足关键条件并看到每项判断的证据边界, primary_unit_type: checklist, supporting_unit_types: [], opening_summary: none, toc: false, numbered_headings: false, evidence_fit: 现有证据逐项对应明确条件适合直接核对无法确认的项目可以保留未知状态而不扩写成章节。 }, L0_draft: null, style_contract: { register: research_brief, voice: neutral_analytical, terminology: { preferred: {} }, citation_style: footnote }, content_units: [ { id: u1, type: checklist, role: primary, title: 关键条件核对, reader_task: 逐项确认关键要求是否满足以及证据是否充分, word_budget: 500, lead: null, render_contract: { mode: checklist, show_heading: true, schema: [条件, 状态, 依据, 限制], instructions: 每项只给满足、不满足或证据不足三种状态并在同一项内附引用和限制。 }, elements: [ { id: e1, label: 条件甲, purpose: 核对条件甲是否满足并呈现证据限制, evidence_refs: [ { claim_id: d1.c1, role: primary_support } ], writing_context_refs: [] } ], evidence_subset: [d1.c1] } ], claim_routing_table: { d1.c1: { primary: u1, secondary: [] } }, scan_summary: { totals: { claims: 1, sources: 1, primary_ratio: 1.0 }, topic_clusters: [], conflicts: [], key_entities: [], timeline_density: [], gaps: [], reader_task_signal: { panorama: 0.0, comparison: 0.0, investigation: 0.0, timeline: 0.0, evaluation: 1.0, forecast: 0.0 } } }注意最小示例中的两处典型写法opening_summarynone时L0_draft必须为nullparadigm.secondary可为null。这两处是初学者最容易违反的耦合约束。十三、硬校验门控validate_outline.py 的使用与错误码体系report-planner 在写完 outline 与全部子集后必须运行仓库内置校验脚本这是 Phase 8 的硬门控validator 通过前不算完成# 仅校验 outline.json python3 validate_outline.py outline.json # 校验 outline 子集 与 evidence 文件的交叉引用检查 python3 validate_outline.py outline.json \ --subsets content_units/ \ --evidence sub_reports/d1.evidence.json sub_reports/d2.evidence.json注意report-planner 的 payload 要求把evidence_paths的每一条绝对路径全部展开为独立参数不允许只取前两个维度花括号占位符必须在执行前替换。脚本 validate_outline.py 为纯标准库实现无第三方依赖输出 stdout JSON 与退出码{ok: true, errors: [], warnings: [...], stats: {...}} {ok: false, errors: [...], warnings: [...]}退出码0 通过允许 warnings1 存在任一 U### 错误2 文件不存在或 JSON 非法。校验覆盖大纲与子集两大部分主要错误码可按下表速查错误码范围校验对象典型规则U002–U008顶层paradigm 枚举、main≠secondary、depth_level、global_arc 非空、禁止 sections 键U010–U015organization_decisionreader_task 非空、primary_unit_type 合法、supporting 去重、opening_summary 枚举、toc/numbered_headings 布尔、evidence_fit 非空U020–U024L0_draft与 opening_summary 的耦合、headline 非空、key_findings 3–5 条、abstract_visual form/data_refs 合法U030–U033style_contractregister/voice/citation_style 枚举、terminology.preferred 结构U040–U047content_units长度 1–20、id 唯一且^u\d$、type/role 合法、title/reader_task 非空、word_budget 正整数、lead 可空U050–U053render_contractmode 枚举、show_heading 布尔、schema 0–20 且去重、instructions 非空U060–U068elements长度 1–20、id^e\d$唯一、label/purpose 非空、evidence_refs 0–10、claim_id 合法、role 合法、writing_context_refs 0–20、至少路由一条断言或上下文U070–U074evidence_subset长度 0–30、去重、ID 合法primary 单元类型必须匹配 primary_unit_typeU072/U074U080–U086claim_routing_table键合法、primary 是存在的单元、secondary 不重复、次级角色受限U100–U104scan_summarytotals 非负整数、primary_ratio∈[0,1]、conflicts severity、reader_task_signal 合法U200–U216evidence_subset 文件文件名匹配 content_unit_id、每单元恰好一份、claims/sources/writing_context 字段与引用覆盖stats汇总通过时输出包括paradigm、depth_level、headline、primary_unit_type、content_units_count、primary_units_count、total_word_budget、routing_table_size——总控可据此在完成回复中汇报单元数量、primary/supporting 分布和总预算。十四、下游消费链路writer、stitcher 与 render 的边界执行outline 与证据子集写好并通过校验后进入三条下游消费链路1. report-writerwrite_unit / revise_unit。每个 writer 只读取outline.json中自己的内容单元与其evidence_subset.json不得读取其他单元的 subset、完整 evidence 或其他单元草稿。写作决策优先级依次为当前单元证据子集 → 单元 elements 与 render_contract → organization_decision → payload 的 format → style_contract见 report-writer.md Decision priority。引用纪律是引用键必须是source.id绝不是claim.id该指标在 2024 年达到 68%[^official_report_2024]。禁止输出[^d1.c3]形式的 claim-id 脚注脚注定义与参考文献章节统一留给 render 阶段。2. report-stitcher。按organization_decision把各单元文件组装为stitched.md可以修改文档级 H1、L0 摘要文本、无新事实的连接句和术语变体不能修改单元内事实、数字、引用键、判断强度、表格单元格、清单状态或 Mermaid 关系。组装前先跑contract gate每个单元.md存在、无[^dN.cM]泄漏、无 H1、无脚注定义、主 Markdown 形态与 render mode 一致任一硬合同失败即返回VERDICT: revise不写stitched.md。3. rendersn-prepare-citations。heavy 档位以stitched.md为输入、带--outline参数固定传--no-l0L0 已由 stitcher 写入organization_decision.tocfalse时传--no-toc为 true 时让脚本替换 stitcher 放置的 TOC placeholder。渲染门控检查 stdout JSONorphan_citations非空或claim_id_leakage.unresolved非空时不交付回 writer/stitcher 修正。十五、总结这套契约的设计原则纵观 outline.schema.md 全文及其在仓库中的实现可以提炼出四条贯穿始终的设计原则范式与结构分离paradigm管论证推进organization_decision管结构承载中间没有映射表杜绝因范式而预设结构的偷懒设计证据边界是硬合同element ≤ 10 条引用、unit ≤ 30 条去重断言、子集必须等于元素引用并集、路由必须精确覆盖——每条都以 U### 错误码机械强制结构优先于文章化矩阵、时间线、清单等结构件可以作为成品主体stitcher 不负责把一切变成文章机器可审计scan_summary、claim_routing_table与validate_outline.py的组合使编排决策是否忠实于证据可以被第三方复查。对于希望深度定制 heavy 报告编排的开发者建议的阅读顺序是先通读本文对应的 outline.schema.md 字段契约再对照 evidence.schema.md 理解dN.cM/dN.wM引用体系最后以 validate_outline.py 作为可执行的规则全集反复校验自己的 outline 产物——三者结合即构成 heavy 模式报告编排的完整闭环。赞分享AI 技能人工智能深度研究数据分析媒体生成【免费下载链接】SenseNova-SkillsModular SenseNova skills for building AI-powered office assistants and productivity workflows项目地址https://gitcode.com/gh_mirrors/se/SenseNova-Skills点击查看免费下载相关推荐SenseNova-Skills 深度研究 CLI 实战指南独立安装、Harness 编排与可恢复研究报告运行SenseNova Skills 深度研究 CLI 实战指南独立安装、Harness 编排与可恢复研究报告运行 本文围绕 SenseNova Skills 仓AI 技能人工智能深度研究数据分析媒体生成SenseNova-Skills 深度研究Deep Research技能全解析多 Agent 编排、三档流水线与证据链校验SenseNova Skills 深度研究Deep Research技能全解析多 Agent 编排、三档流水线与证据链校验 本篇技术指南系统讲解 SensAI 技能人工智能深度研究数据分析媒体生成BMAD Deep Recon 研究报告模板全解research.template.md 的元数据契约与报告装配规范BMAD Deep Recon 研究报告模板全解research.template.md 的元数据契约与报告装配规范 导读 本指南围绕 BMAD METHOAI 技能人工智能开发工具上一篇终极Cult-UI动画组件指南text-animate、dynamic-island、texture-button深度体验下一篇文本生成新纪元text-generation-webui v3.4.1核心功能与性能优化全解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考