official-doc-ch04-technical-route

name	official-doc-ch04-technical-route
description	第四章“技术路线”section skill。仅在 /official-doc-write 的 ch04-technical-route 中使用。必须为每个 task_id 提供同主题技术路线块。不执行外部调研。
allowed-tools	Read Write Edit Bash

技术路线（ch04-technical-route）

必须配合 official-doc-section-common 使用。

写作对象为：

## （二）项目建设方案
### 1. 技术路线

写作目的

说明项目如何通过体系架构、数据流、模型/工具链、接口链、验证、工程应用和安全机制实现建设目标与研发任务。

必须遵守的逻辑

按以下顺序展开：

总体技术路线总述 -> 架构分层 -> 数据流/业务流 -> 模型链/工具链 -> 模块和接口关系 -> 任务建设路线 -> 验证路线 -> 工程应用路线 -> 安全与自主可控 -> 合理性和可行性

至少覆盖四类架构层或等价链条：

• 数据资源
• 数据处理
• 模型与算法
• 知识与规则
• 工程工具
• 应用生成
• 验证与运行

模板化写法

本 section 应像模板第四章“技术路线”一样，以连续工程说明为主，配合路线图和验证表，不能写成 Markdown 技术文档。

本 section 虽然是技术章节，但仍属于正式公文正文，不得写成软件操作说明或英文术语堆叠的技术报告。软件、算法、文件格式和标准机构名称必须遵守以下规则：

• 能中文化的优先中文化，例如 PCA 写作 主成分分析，Python 写作 脚本工具 或 工程脚本，Word/PDF 写作 文字处理文档和便携式文档格式。
• 必须保留的专有名词，采用中文说明在前、英文括注在后的方式，只在首次出现时括注一次。
• 同一自然段不得连续堆叠多个英文缩写；不得出现英文词与中文短语黏连导致的“中英文术语污染”。
• 不得使用 唯一可行路径、国际先进水平、显著提升、大幅提升、形成闭环 等强宣传表述，应改为“有助于提升……能力”“形成……衔接关系”“支撑……应用验证”等稳健写法。

推荐句式链条：

本项目技术路线以...为主线，按照...顺序组织实施 -> 在总体架构上，系统由...组成 -> 在数据流转方面，... -> 在任务路线方面，任务一/二/三分别... -> 在验证方面，... -> 在工程应用方面，...

任务路线块推荐句式：

任务一技术路线围绕...展开。前置输入为...，首先...，其次...，再次...，最终形成...。该路线的关键难点在于...，拟通过...予以解决，输出结果将承接至...。

标题层级要求：

• 正式正文只能保留 ### 1. 技术路线 这个 section 标题。
• 内部不得使用 ####、##### 或更深 Markdown 标题。
• 内部层次用自然段段首“第一，”“第二，”“任务一技术路线...”“在验证路线方面...”表达。
• 图4-3 放在技术路线总述后；任务路线图分别放在对应任务路线块开头或任务路线块之后；测试验证表放在验证路线说明后。

任务到路线门禁

• ch04-rd-content 中每个 task_id 都必须有同主题技术路线块。
• tech_route_id 只在交接说明中使用，不进入正式正文。
• 不得把无关任务合并成一个空泛路线。

深度和字数

本 section 是第四章锚点章节。如果没有更强要求，硬性最低字数为 7000 中文字符，目标为 8000-12000 中文字符。

本 section 必须是第四章最长部分之一。扩写必须来自工程细节，而不是重复表述：

• 对每项研发任务，写同主题路线块，覆盖 前置输入 -> 处理步骤 -> 关键难点 -> 中间输出 -> 下游承接 -> 验证方式。
• 对架构层，写清 输入 -> 处理动作 -> 输出 -> 支撑后续环节。
• 对数据流，区分源数据、中间数据、规范化数据、可生成报告数据和追溯记录。
• 对模型/工具链，区分机器学习分类、确定性有限元脚本、规则/知识检索、大模型生成和人工复核。
• 对接口，保守描述有限元软件、知识库平台、动态模板工具、报告输出工具和交接格式。
• 对验证，区分单元验证、集成验证、样例报告验证、用户试用和最终人工复核。
• 对工程应用，说明试点场景、扩展场景、反馈机制和适配边界。
• 对安全与自主可控，说明私有化部署、敏感工程数据边界、日志、权限和可复用组件边界。

输出要求

• 不重复“项目研发内容”，必须解释实施链条。
• 不把全部能力归因于大模型或单一通用技术。
• 不编造输入中没有的接口、模块或验证阈值。
• 输入信息足够时，可加入路线与任务、指标、验证对应表。
• 正式正文不得暴露 task_id、tech_route_id、output_id、indicator_id、validation_id，只使用可读任务名称。
• 正式正文不得密集使用英文缩写；必要缩写应纳入中文句式，不得让英文词承担段落逻辑。