/code2patent

项目技术方案画像规范

本规范用于在进入代码细节前，先建立项目边界、依赖结构、运行时形态和可申请技术机制的整体认识。 适用于“代码仓库转专利交付”的所有场景，无论最终产物是技术交底书还是发明专利初稿。 本规范不是模块清单模板；项目分析的结论应服务于权利要求布局和具体实施方式，而不是把代码目录改写成正文。

一、目标

完成项目分析阶段后，应至少回答以下问题：

1. 当前项目可能包含哪些可申请的软件/算法类技术机制
2. 是否存在 monorepo、workspace、共享包、submodule 或私有依赖
3. 哪些关键能力来自第三方库、云服务、模型平台或中间件
4. 创新点主要落在算法步骤、状态表示、数据流、调度逻辑、权限控制、上下文编排还是异常回退
5. 哪些目录和模块只是证据位置，不能成为交底书或权利要求的正文主线
6. 项目架构可以转译为哪些技术对象、对象关系、状态表示、动作更新和输出结果
7. 哪些能力不宜直接写成申请人的核心技术特征

二、分析顺序

建议按“先宏观、后局部”的顺序推进：

1. 先读用户提供的候选方案清单、PRD/需求说明、沟通纪要、技术描述、Word 模板
2. 再读代码仓库中的 README、架构文档、接口文档和目录说明
3. 再读项目边界和依赖文件
4. 再读部署与运行文件
5. 最后围绕已确认候选方案进入关键流程代码，抽取 S1...Sn 步骤、F1...Fn 技术特征和 E1...En 证据编号

三、优先查看的文件

1. 边界与依赖文件

这些文件用于判断能力归属和证据边界，不用于生成“重点模块清单”作为交底书正文。

• package.json
• pnpm-workspace.yaml
• turbo.json
• pyproject.toml
• requirements.txt
• go.mod
• Cargo.toml

2. 部署与运行文件

• Dockerfile
• docker-compose.yml
• .env.example
• 启动脚本
• CI 配置

3. 项目说明文件

• README.md
• PRD.md、产品方案、需求说明文档
• 架构文档
• 接口文档
• 目录说明

4. 运行时编排文件

重点观察运行时如何组织算法步骤、状态流、权限流、上下文流和异常回退，而不是仅列出配置文件名称。

• workflow 配置
• agent 配置
• prompt 配置
• 任务调度配置
• 缓存配置
• 消息队列配置
• 向量库配置

四、必须完成的判断

1. 边界判断

• 当前仓库哪些目录是主项目自研代码，仅作为证据边界
• 哪些目录是 workspace 包、共享包、submodule 或外挂仓库

2. 依赖判断

• 哪些能力来自第三方库、外部 SDK、模型平台、中间件或云服务
• 这些依赖在项目中承担什么角色

3. 创新判断

• 创新是否发生在单个算法步骤内部
• 创新是否更主要体现在状态表示、特征计算、调度逻辑、缓存机制、上下文注入、鉴权、异常回退或数据流设计
• 创新是否可整理为权利要求中的步骤 S1...Sn 或特征 F1...Fn
• 项目架构是否可以表达为“对象-关系-状态-动作-输出”的技术机制链

4. 归属判断

• 哪些内容是第三方能力本身，不应直接写成申请人的创新
• 哪些内容是本项目对第三方能力的组织、改造和组合使用方式，可作为重点申请对象

五、依赖可读性标注

若部分依赖或关联仓库无法读取，必须显式标注状态：

• 已读取：当前已直接查看相关代码或配置
• 未读取但可推断：虽未直接查看，但可从调用方式、配置或文档合理推断
• 未读取且影响判断：当前无法读取，且会直接影响创新归属或实现判断

六、标准产出

建议至少形成以下文档：

1. 00-输入材料摘要.md
2. 01-项目边界与依赖画像.md
3. 03-项目技术方案画像.md

如当前只做初步预研，可至少先产出前两项。

03-项目技术方案画像.md 应优先按“技术问题、候选机制、S 步骤、F 特征、E 证据、待确认事项”组织。不要按 controller/service/component/package 等工程目录层级展开正文；这些信息只放在证据列或附录索引中。

建议在画像中增加一张“架构转译表”：