{{workflow_name}}流程指南¶
注释：
将{{workflow_name}}换成具体流程名，例如“主流模型量化”、“新模型接入量化”。名称应能让读者立刻知道要完成哪件事。必选章节只有三块：1.适用范围、2.输入和交付件、3.操作步骤。标题带
[OPTIONAL]的章节按需保留；不需要就整节删除。
1. 适用范围¶
{{applicable_scope}}
注释：
写清楚：谁用这份流程、在什么场景用、什么情况不要用。例如：已在支持矩阵验证且可用一键量化的模型；未验证模型应改走新模型量化流程。
2. [OPTIONAL] 流程关系与前置条件¶
上级流程：{{parent_workflow}}
前置条件：
- {{prerequisite_item_1}}
- {{prerequisite_item_2}}
后续操作：{{follow_up_action}}
注释：
- 上级流程：本流程从哪个需求/流程接过来，例如“模型上线评审通过后”。
- 前置条件：动手前必须已具备的环境、材料或决策，写成可核对条目，例如“已安装兼容版本的 msModelSlim”、“已拿到浮点权重与 tokenizer”。
- 后续操作：本流程走完后进入什么，例如“进入发布与监控”或“精度不达标则进入调优”。
3. 输入和交付件¶
| 类型 | 名称 | 来源或保存位置 | 格式或约束 | 验收方式 |
|---|---|---|---|---|
| 输入 | {{input_name}} | {{input_source}} | {{input_constraint}} | {{input_acceptance_method}} |
| 交付件 | {{deliverable_name}} | {{deliverable_location}} | {{deliverable_constraint}} | {{deliverable_acceptance_method}} |
注释：
- 输入行：流程开始前就要准备好的东西。名称要具体（如“浮点模型目录”），来源写从哪拿，约束写目录应含哪些文件或版本要求，验收方式写如何确认可用（如“可被目标 Transformers 版本加载”）。
- 交付件行：流程结束后必须交出的东西。名称要具体（如“量化权重目录”），保存位置写路径，约束写必须含哪些文件，验收方式写如何确认合格（如“含 quant_model_description.json 且推理冒烟通过”）。
不要写“相关文件”、“处理结果”这类无法定位的名称。按需增加表格行。
4. [OPTIONAL] 流程总览¶
{{workflow_overview}}
flowchart LR
stageA[阶段A] --> stageB[阶段B] --> stageC[阶段C]注释：
在操作步骤前给出端到端阶段图，帮助读者先建立全局顺序。
鼓励用 mermaid 或其他流程图：把 阶段A/阶段B/阶段C 换成真实阶段名，必要时在边上标注主要输入/输出。
图只做总览，不能替代下面的“操作步骤”。不要在 mermaid 代码里写{{placeholder}}，花括号会被当成节点形状语法而报错。
5. 操作步骤¶
步骤 {{step_number}}：{{step_name}}¶
注释：
按真实执行顺序复制本节。步骤标题用“动词+对象”，例如“确认模型与量化方案”、“执行一键量化”。
每个步骤最少必须写“操作”和“输出”；其余字段按需保留。
[OPTIONAL] 目标：{{step_objective}}
注释：
用一句话说明本步骤要达到的状态，例如“确认 model_type、quant_type 与目标推理场景匹配”。
[OPTIONAL] 输入：{{step_input}}
注释：
列出本步骤会直接用到的材料，优先写上一步输出或“输入和交付件”表中的具体项，例如“步骤1确认的量化方案、校准集路径”。
[OPTIONAL] 执行前检查：{{pre_execution_check}}
注释：
开始本步骤前必须核对的条件，例如“支持矩阵中该模型量化模式为已验证”、“NPU 设备可用”。若已在“全局验收条件”中统一写过同类要求，这里可不重复。
操作：{{step_action}}
注释：
写可照着做的动作：命令、配置改哪些字段。命令里的参数要说明含义；涉及 trust_remote_code 等风险参数时写清启用条件。
输出：{{step_output}}
注释：
写本步骤完成后新产生、可供后续步骤使用的结果，例如“量化权重目录${SAVE_PATH}”。输出应能被下一步直接引用。
[OPTIONAL] 通过条件：{{step_acceptance_criteria}}
注释：
判断本步骤是否做完的客观标准，例如“日志输出 SUCCESS 且目录含 quant_model_description.json”。不要只写“成功/完成”。若已在“全局验收条件”中统一写过，这里可不重复。
[OPTIONAL] 审计记录：{{retained_evidence}}
注释：
写需要留下来供核对、复现或审计的信息，不是操作日志流水账。按场景举例：量化权重文件 MD5/SHA256、实际使用的 YAML 路径与内容哈希、测评报告版本号、服务配置快照、debug_info 目录路径。
[OPTIONAL] 异常处置：{{exception_handling}}
注释：
写本步骤失败或出现异常时怎么做：先查什么、能否重试、回退到哪一步、何时升级。若已在“全局异常处置”中统一写过，这里可不重复。
6. [OPTIONAL] 验收条件¶
{{global_acceptance_criteria}}
注释：
整篇流程级别的通过要求，相对步骤内“通过条件”、“执行前检查”更宏观，例如“未建立浮点基线不得宣称精度收益”、“产物缺描述文件不得部署”。
7. [OPTIONAL] 异常处置¶
{{global_exception_handling}}
注释：
整篇流程级别的异常处理约定，例如“精度不达标按调优指南排查后重跑量化与测评”、“无法达标则发布浮点或更高精度回退版本”。
若各步骤“异常处置”已覆盖，可删除本章节以免重复。
8. [OPTIONAL] 案例列表¶
| 案例 | 简述 | 链接 |
|---|---|---|
| {{case_name}} | {{case_summary}} | 《[{{case_link_text}}]({{case_link}})》 |
注释：
只做索引表：案例名、一句场景简述、可点击链接。详细步骤写在被链接的文档里，不要在本流程指南里展开长文。
9. [OPTIONAL] 术语¶
| 术语 | 简述 | 链接 |
|---|---|---|
| {{term_name}} | {{term_summary}} | 《[{{term_link_text}}]({{term_link}})》 |
注释：
只做索引表：术语名、一句白话简述、指向权威定义或支持矩阵/算法文档的链接。不要在本表写长定义。
10. [OPTIONAL] 接口文档列表¶
| 接口或能力 | 简述 | 链接 |
|---|---|---|
| {{interface_name}} | {{interface_summary}} | 《[{{interface_link_text}}]({{interface_link}})》 |
注释：
只做索引表：命令/API/配置协议名、一句用途简述、权威文档链接。参数细节写在被链接文档里。工具类流程建议保留本章节。
11. [OPTIONAL] 安全说明¶
{{security_considerations}}
注释：
写本流程特有的安全约束：例如 trust_remote_code 仅可信模型可开、权重与校准数据的权限要求、日志是否含敏感内容。没有额外安全要求时可删除本章节。
12. [OPTIONAL] 产品形态与资源限制¶
{{product_form_and_resource_constraints}}
注释：
写目标产品形态与资源边界，例如：在线推理服务 / 离线批处理；单机多卡 / 分布式；最低 NPU 型号与卡数；显存/内存下限；支持的 CANN、PyTorch、推理框架版本组合；Atlas 推理系列产品仅支持单卡量化。
没有形态或资源约束差异时可删除本章节。