先给结论
- 产品结构有两种，缺一不可。物理结构＝拆得开、看得见的部分（件、料、装配）；逻辑结构＝拆不开、只能画出来的部分（功能块、数据流、接口）。
- 只拆物理结构，材料读起来像代工厂的产能介绍；只拆逻辑结构，对方会追问「这东西你究竟怎么做出来的」。
- 一句话分工：物理结构决定「你有什么」，逻辑结构决定「你做了什么」。这两句话在材料里是两栏，不能合成一栏。
- 两类结构各自对应一类知识产权。物理侧多为实用新型、外观设计与结构类专利；逻辑侧多为发明专利与软件著作权。选错侧，专利写了也用不上。
- 最快的自检：把设备拆开摆在桌上，如果你自己都看不出「哪一部分是你做的」，说明逻辑结构没拆。
四种拆解方法里提到过，结构拆解与原理拆解常被当成一件事。其实结构拆解本身就分两层，而且这两层不是深度的差别，是方向的差别——一层向外看，看的是看得见的构成；一层向内看，看的是看不见的关系。
把这两层分开，是材料从「像说明书」变成「像技术档案」的关键一步。说明书人人都会写，技术档案才是能支撑申报与融资的那一份。
一、为什么必须拆成两张图
因为对方要看的是两件事。第一件是「你手里有什么」，第二件是「其中哪一部分是你的」。前者靠物料与工艺能回答，后者只有逻辑结构能回答。
只交一张图会出两种偏差：
| 只交哪张图 | 对方会形成什么印象 | 典型后果 |
|---|---|---|
| 只有物理结构 | 有设备、有物料、有工序，像一家做得不错的加工厂 | 被判定技术含量不足，往上游的资质够不着 |
| 只有逻辑结构 | 框图很清楚，但东西是怎么做出来的没人知道 | 被追问实现路径，一旦答不上来就变成「纸上方案」 |
两张图的作用正好互补：物理结构回答「凭什么做得出来」，逻辑结构回答「凭什么值得被保护」。
二、物理结构：拆到件、料、工艺
物理结构是向外的一层，颗粒度可以沿四个层级往下走。拆到哪一层，取决于你要证明什么：
| 层级 | 拆到什么颗粒度 | 主要用途 |
|---|---|---|
| 整机 / 系统 | 产品本身的边界：它包含哪些子系统 | 产品目录、技术领域定位 |
| 单元 / 部件 | 能独立更换或独立供货的模块 | 核心知识产权对应、售后与服务收入 |
| 零件 / 物料 | 决定性能与成本的关键件 | 供应链稳定性、成本结构与议价能力 |
| 装配 / 工艺 | 把这些件装成产品的过程与方法 | 工艺类证据、生产条件、质量一致性 |
物理结构里最值得标出来的是「自做与外购的分界线」。这条线一画，材料立刻从「我们买了什么」变成「我们做了什么」。很多企业明明自己做了最关键的算法与运动控制，却因为没画这条线，整台设备被当成组装件看。
一个实操建议：在物理结构图上，把自做的部分用一种颜色标出来，外购的部分用另一种。标完之后自己看一遍——如果自做的部分只占很小一块，而你申报的却是偏技术类的项目，说明要么真没做那么多，要么做了但没体现在图上。两种情况都要处理，前者要调整申报策略，后者要重新拆。
三、逻辑结构：拆到功能块、数据流、接口
逻辑结构是向内的一层，它拆的不是物件，是关系。四个抓手：
| 抓手 | 拆什么 | 它回答的问题 |
|---|---|---|
| 功能块 | 整个产品被切成几个功能单元，各自的职责边界 | 哪几块是你自研的，哪几块是通用的 |
| 数据流 | 数据从哪进、经过哪些处理、从哪出 | 价值的增量发生在哪一步 |
| 接口 | 模块之间的边界条件与协作约定 | 为什么换掉其中一块，整体功能就变了 |
| 控制逻辑与算法 | 判断规则、参数区间、异常处理 | 这部分经验是买不来的，只能自己攒 |
逻辑结构最容易踩的坑，是把它画成组织架构图。「研发部—生产部—品质部」是分工，不是功能块。功能块应该按「这件事由哪一段逻辑完成」来切，而不是按「这件事归哪个部门管」来切。
软件类的产品尤其如此。界面与功能清单属于浅层，真正的逻辑结构要拆到数据怎么流转、规则怎么判定、异常怎么兜底。这一点在软件产品评估与首版次软件类的材料里，是区分「套壳」与「自研」的分水岭。
四、两张图对不上，是材料最早露馅的地方
分开拆完，一定要把两张图放在一起对一遍。对不上的地方，就是后面会被问到的地方。
| 对不上的样子 | 对方会怎么理解 |
|---|---|
| 逻辑图上有「自研控制算法」，物料清单里对应的控制器是整块外购的黑盒 | 要么算法其实没落地，要么做的部分比说的少 |
| 软著登记的模块名，在产品目录里找不到对应的产品 | 成果与产品对不上号，转化计数会被打折 |
| 同一模块在技术方案、软著、专利里叫三个不同的名字 | 无法确认是不是同一件东西，核对成本转嫁给了对方 |
算一笔账：一个模块在技术方案里叫「智能识别单元」、在软著里叫「图像分析子系统」、在专利里叫「视觉处理装置」。对熟悉的人来说这是同一件事，但对第一次读你材料的人来说，这是三件需要分别核实的东西。核实成本一旦高到某个程度，对方就会选择「存疑」而不是「追问」。统一命名不花钱，但能省下大量被存疑的机会。
五、落到材料：物理侧与逻辑侧各交什么
| 证据类型 | 来自物理结构 | 来自逻辑结构 |
|---|---|---|
| 产品类 | 产品目录、规格参数、物料与关键件清单 | 功能清单、模块划分、版本记录 |
| 知识产权类 | 实用新型、外观设计、结构类专利 | 发明专利、软件著作权、技术秘密 |
| 研发类 | 工艺改进、装备改造、样机试制 | 算法迭代、规则调优、数据积累 |
| 能力类 | 产能、良率、交付周期、质量一致性 | 技术可迁移性、二次开发能力、维护与升级收入 |
知识产权的搭配可以再看知识产权管理体系的国标与 ISO 对比那一篇；如果产品里有软件形态，软著怎么定位、与高企怎么联动，软件企业申报高企的特殊要点里讲得更细。首版次软件这类需要产品「首版首发」属性的项目，则要在物理侧把版本与投产时间线交代清楚。
六、三个常见的坑
- 把「结构」默认理解成硬件结构。软件工具、数据服务类产品的物理结构很薄，真正的主体在逻辑结构里。这类企业如果照硬件企业的模板写材料，会写出大量空洞的「服务流程」。
- 逻辑结构画成组织架构图。按部门切是最省事也最没用的切法，读者看完只知道谁负责，不知道东西怎么运转。
- 两张图各写各的，从不比对。结构拆解的产出必须回到业务流上核对一遍：模块的边界是不是对应收入的边界、对应交付的边界。对不上，说明拆得还不够细。
本文为申报方法论梳理，属实务建议层，不涉及具体政策条文。文中涉及的技术领域分类引自《国家重点支持的高新技术领域》（《高新技术企业认定管理办法》国科发火〔2016〕32号附件）；具体归口与知识产权类型的选择，请以当年度申报通知及主管部门口径为准。
