Install
openclaw skills install @golngod/wanpaike-opc-tech-due-diligence技术尽调初筛工具,用于投资前的技术可行性评估、团队背景核查、专利验证。适用于科技创新项目的真实性核查,识别虚假技术和夸大宣传。核心能力:技术可行性评估、团队背景核查、专利备案验证、商业模式分析。
openclaw skills install @golngod/wanpaike-opc-tech-due-diligence在使用本技能前,请明确以下边界,避免与其他OPC技能混淆或重复使用。
技术尽调 = 技术真实性核查。本技能聚焦于回答一个核心问题:这项技术是真的吗?团队靠谱吗?参数可信吗?
| 技能 | 核心关注 | 回答的问题 | 交付物 | 适用时机 |
|---|---|---|---|---|
| 技术尽调(本技能) | 技术真实性 | "技术是真的吗?有没有造假?" | 尽调报告+风险评级 | 投资决策前,初筛项目 |
| 商业计划书 | 融资文档质量 | "BP怎么写才能融到资?" | BP文档+路演PPT | 准备融资时 |
| 商业模式分析 | 盈利可行性 | "这个生意能赚钱吗?" | 商业模式画布+盈利模型 | 评估商业逻辑时 |
| 行业分析 | 行业赛道价值 | "这个行业值得投吗?" | 行业研究报告 | 选赛道时 |
| 投资路演 | 融资展示 | "怎么把项目讲给投资人听?" | 路演材料 | 融资路演时 |
场景1:投资初筛 → 先用技术尽调验证技术真实性 → 若通过,再用商业模式分析验证盈利可行性
场景2:融资准备 → 先用商业计划书写好BP → 投资人要求尽调时,用技术尽调配合
场景3:深度决策 → 行业分析看赛道 + 技术尽调看技术 + 商业模式分析看盈利 = 完整投资判断
references/industry_templates.md)references/tech_team_assessment.md)| 检查项 | 检查要点 | 红旗信号 |
|---|---|---|
| 项目代号/备案号 | 是否可查询、来源是否权威 | 无备案或无法核验 |
| 团队成员 | LinkedIn/学术主页是否可查、履历是否一致 | 无可查记录、履历矛盾 |
| 专利信息 | 专利号是否真实、申请人是否匹配 | 伪造专利号、保护期已过 |
| 技术参数 | 是否有具体数值、数据来源 | 模糊描述、无数据支撑 |
执行动作:
⚠️ 行业定制:不同行业的技术尽调侧重点差异巨大。在开始第二层分析前,应先识别项目所属行业,选用对应的行业定制评估模板。详见
references/industry_templates.md
根据项目核心技术选择对应行业模板(详见 references/industry_templates.md):
| 行业 | 核心技术方向 | 专属指标数 | 关键侧重点 |
|---|---|---|---|
| 半导体 | 芯片设计/制造/封测 | 15项 | 制程真实性、良率、供应链自主 |
| 新能源 | 电池/光伏/风电/储能 | 14项 | 物理极限、量产差距、安全性 |
| AI | 大模型/算法/应用 | 14项 | 原创性vs套壳、算力投入、落地验证 |
| 生物医药 | 药物/器械/CRO | 13项 | 临床数据、监管合规、专利保护期 |
跨行业项目:使用主行业模板 + 次行业模板相关指标补充。
核心原则:技术参数是否违反已知的物理定律
| 技术领域 | 关键物理边界 | 常见虚假参数 |
|---|---|---|
| 电池 | 能量密度 ≤ 500 Wh/kg (锂空气理论极限) | 声称 1000+ Wh/kg |
| 超导 | 室温超导需满足零电阻+迈斯纳效应 | 仅测电阻、不测抗磁性 |
| 量子计算 | 量子比特数 vs 逻辑门保真度 | 仅宣传比特数 |
| 核聚变 | Q值 < 1 (目前) | 声称Q > 10 |
📖 量化打分标准:TRL各等级的具体打分标准、案例和专利质量评分表详见
references/TRL_levels.md
| TRL等级 | 定义 | 典型产出 |
|---|---|---|
| TRL 1 | 观察到基本原理 | 论文、专利申请 |
| TRL 2 | 形成技术概念 | 仿真结果 |
| TRL 3 | 关键功能验证 | 实验室原理样机 |
| TRL 4 | 组件/子系统验证 | 测试板、功能验证 |
| TRL 5 | 组件在相关环境中验证 | 工程样机 |
| TRL 6 | 系统模型/原型在相关环境中演示 | 原型 |
| TRL 7 | 系统原型在运行环境中演示 | 示范项目 |
| TRL 8 | 完整系统通过测试 | 商业化准备 |
| TRL 9 | 真实系统通过运行验证 | 规模化商用 |
判断标准:
| 要素 | 检查项 |
|---|---|
| 价值主张 | 是否清晰、可量化 |
| 客户细分 | 目标客户是否明确 |
| 渠道通路 | 商业化路径是否可行 |
| 客户关系 | 如何获取和维护客户 |
| 收入来源 | 收费模式是否合理 |
| 核心资源 | 技术壁垒是否足够 |
| 关键业务 | 商业化需要什么能力 |
| 成本结构 | 成本是否可控 |
| 阶段 | 典型估值 | 对应TRL | 风险特征 |
|---|---|---|---|
| 天使轮 | 1000-3000万 | TRL 2-3 | 极高风险 |
| A轮 | 1-5亿 | TRL 4-5 | 高风险 |
| B轮 | 5-20亿 | TRL 5-6 | 中高风险 |
| C轮+ | 20亿+ | TRL 6+ | 中等风险 |
📖 技术团队能力评估:团队是技术持续迭代的根本保障。对创始团队背景、专利质量、研发投入、核心人员稳定性的系统性评估,详见
references/tech_team_assessment.md
在传统四层验证基础上,新增技术团队能力评估维度,作为风险识别的前置环节:
| 评估维度 | 核心关注 | 评估方法 |
|---|---|---|
| 创始人背景 | 学历/职历真实性、行业经验匹配度 | 学信网/LinkedIn/Google Scholar核查 |
| 专利组合质量 | 发明专利占比、核心技术覆盖度、海外布局 | 专利局网站/专利质量评分表 |
| 研发投入 | 研发费用率、研发人员占比、人均产出 | 财务数据/团队规模核实 |
| 核心人员稳定性 | 关键人风险、团队流失率、股权绑定 | 工商变更/LinkedIn/访谈 |
团队红旗信号(任一项触发即需重点关注):
| 风险类型 | 评估维度 | 高风险信号 |
|---|---|---|
| 技术风险 | 可行性、成熟度、壁垒 | 违反物理定律、无同行评审 |
| 市场风险 | 需求真实性、竞争、时机 | 无明确客户、目标市场模糊 |
| 团队风险 | 背景真实性、稳定性、能力、研发投入 | 履历造假、核心成员缺失、研发费用率<5% |
| 财务风险 | 资金需求、烧钱率、退出路径 | 资金链脆弱、无退出可能 |
| 法律风险 | 知识产权、合规、监管 | 专利侵权、监管障碍 |
| 评级 | 定义 | 建议 |
|---|---|---|
| 🟢 低风险 | 通过四层验证,逻辑自洽 | 可进入深度尽调 |
| 🟡 中风险 | 部分存疑,需进一步核实 | 建议补充尽调 |
| 🟠 高风险 | 多项红旗信号 | 建议回避或极度谨慎 |
| 🔴 极高风险 | 明显违反物理定律或造假 | 强烈建议回避 |
输入:
- 项目商业计划书 / 白皮书
- 技术文档 / 专利文件
- 团队介绍
- 已有数据或测试报告
输出:
- 尽调报告(结构化,含九大章节)
- 红旗信号清单
- 维度关注点总结
- 补充资料清单
- BP修改建议
- 风险评级
- 投资建议
# 技术尽调报告
## 一、项目基本信息
| 项目 | 内容 |
|------|------|
| 项目名称 | |
| 技术领域 | |
| 融资阶段 | |
| 尽调日期 | |
| 尽调人员 | |
## 二、材料完整性评估
### 2.1 可查证项
| 项目 | 核查结果 |
|------|----------|
| 项目备案/代号 | |
| 团队成员 | |
| 专利信息 | |
| 技术参数 | |
### 2.2 红旗信号
- [ ] 列出发现的红旗信号
## 三、技术可行性分析
### 3.1 物理定律核查
| 技术指标 | 声称值 | 物理极限 | 是否合理 |
|----------|--------|----------|----------|
| | | | |
### 3.2 TRL评估
| TRL等级 | 证据支撑 | 可信度 |
|---------|----------|--------|
| | | |
### 3.3 学术基础
| 核心论文 | 发表期刊 | 引用数 | 可信度 |
|----------|----------|--------|--------|
| | | | |
## 四、商业逻辑评估
### 4.1 商业模式画布
[分析各要素完整性]
### 4.2 竞争格局
[竞争者分析]
### 4.3 估值匹配
| 融资阶段 | 声称估值 | TRL对应估值 | 匹配度 |
|----------|----------|--------------|--------|
| | | | |
## 四点五、技术团队能力评估
### 4.5.1 创始人背景评估
| 评估维度 | 评分 | 说明 |
|----------|------|------|
| 学术背景 | X/5 | [验证结果] |
| 职业履历 | X/5 | [验证结果] |
| 行业经验匹配 | X/5 | [评估结果] |
### 4.5.2 专利组合质量
| 维度 | 评分 | 说明 |
|------|------|------|
| 发明专利占比 | X/5 | [具体比例] |
| 核心技术覆盖度 | X/5 | [覆盖情况] |
| 专利-产品关联度 | X/5 | [关联情况] |
### 4.5.3 研发投入评估
| 指标 | 数值 | 行业对比 | 评价 |
|------|------|----------|------|
| 研发费用率 | X% | [基准] | [评价] |
| 研发人员占比 | X% | [基准] | [评价] |
### 4.5.4 核心人员稳定性
| 人员 | 角色 | 任职年限 | 离职风险 |
|------|------|----------|----------|
| | | | |
## 五、风险评估
### 5.1 风险矩阵
| 风险类型 | 风险等级 | 主要风险点 |
|----------|----------|------------|
| 技术风险 | | |
| 市场风险 | | |
| 团队风险 | | |
| 财务风险 | | |
| 法律风险 | | |
### 5.2 综合评级
**[🟢/🟡/🟠/🔴] 综合风险评级**
## 六、维度关注点总结
### 6.1 材料完整性关注点
| 关注点 | 为什么关键 |
|--------|-----------|
| [逐条列出] | [说明对投资决策的影响] |
### 6.2 技术可行性关注点
| 关注点 | 为什么关键 |
|--------|-----------|
| [逐条列出] | [说明对投资决策的影响] |
### 6.3 商业逻辑关注点
| 关注点 | 为什么关键 |
|--------|-----------|
| [逐条列出] | [说明对投资决策的影响] |
### 6.4 综合风险关注点
| 关注点 | 为什么关键 |
|--------|-----------|
| [逐条列出] | [说明对投资决策的影响] |
## 七、补充资料清单
### 7.1 必须补充的资料
| 序号 | 资料 | 重要性 | 不补的后果 |
|------|------|--------|-----------|
| 1 | [资料名称] | 🔴极高/🟡高 | [对投资决策的影响] |
### 7.2 建议补充的加分项
| 内容 | 作用 |
|------|------|
| [资料名称] | [补充后的价值] |
## 八、BP修改建议
### 8.1 必须修改的内容
| 问题 | 当前表述 | 修改为 |
|------|----------|--------|
| [问题描述] | [BP原话] | [修改方向] |
### 8.2 融资条款建议调整
| 条款 | 当前 | 建议 |
|------|------|------|
| [条款名称] | [当前状态] | [调整建议] |
## 九、投资建议
### 9.1 核心结论
[总结关键发现]
### 9.2 建议行动
- [ ] 建议进入深度尽调 / 建议回避 / 补充核实
### 9.3 继续核实清单
- [ ] 待核实事项
用户输入:
"帮我评估这个项目:某公司声称研发出能量密度2000Wh/kg的固态电池,已获得天使轮5000万估值"
执行流程:
| 模式 | 适用场景 | 效率基准 | 验证深度 |
|---|---|---|---|
| 纯Coze模式 | 无IMA知识库资料,需快速初筛 | 15-20分钟 | 依赖网络搜索,无结构化验证 |
| Coze+IMA协同模式 | 有IMA知识库资料,或客户提供原始文档 | 25-30分钟 | 65%+问题已验证,可追溯 |
开始尽调
│
├─ 是否有IMA知识库资料?
│ │
│ ├─ 是 ──→ Coze+IMA协同模式
│ │
│ └─ 否 ──→ 客户是否提供原始文档?
│ │
│ ├─ 是 ──→ 导入IMA → 协同模式
│ │
│ └─ 否 ──→ 纯Coze模式
💡 首次使用建议:从纯Coze模式开始,熟悉流程后再升级到协同模式
详见:
references/Coze-IMA协同尽调流程.md
| 阶段 | 时长 | 主要任务 | 执行主体 |
|---|---|---|---|
| 阶段1:IMA底座搭建 | 3-5分钟 | 搜索/导入项目资料到IMA | IMA API |
| 阶段2:尽调框架搭建 | 8-10分钟 | 生成5维度32项问题清单 | Coze |
| 阶段3:IMA信息验证 | 8-10分钟 | 逐项核查,标注可信度 | IMA API |
| 阶段4:Coze方案生成 | 3-5分钟 | 整合验证结果生成报告 | Coze |
请求Header:
ima-openapi-clientid: {clientid}
ima-openapi-apikey: {apikey}
⚠️ 关键注意:API Key ≠ Client Secret,API Key是更长的那个字符串
5个核心API:
| API | 用途 | 关键参数 |
|---|---|---|
| search_note_book | 搜索知识库 | query_info.title |
| get_doc_content | 获取文档内容 | doc_id |
| list_note_by_folder_id | 列出笔记 | folder_id, cursor分页 |
| import_doc | 导入外部文档 | file, title |
| append_doc | 追加文档内容 | doc_id, content |
| 标注 | 含义 | 处理方式 |
|---|---|---|
| 🟢 已验证 | IMA知识库或二次搜索确认 | 可直接引用 |
| 🟡 部分验证 | 存在矛盾或信息不足 | 补充调研方向 |
| 🔴 未验证 | 无相关资料 | 标注"待核实"+建议行动 |
| 🌐 Web补充 | IMA无结果,用网络搜索 | 标注"非IMA验证" |
# 生成任意公司的技术尽调报告(JSON格式)
python main.py '{"company_name": "某科技公司", "industry": "AI", "findings": {...}}'
main.py 是通用入口,接受参数化JSON输入,返回结构化报告。详见 main.py 文件注释。
# 无参数:使用内置示例数据(河北青山鼎信)
python scripts/generate_report.py
# 带参数:生成指定公司的报告
python scripts/generate_report.py --company "某科技公司" --output "报告路径.docx" [--json "data.json"]
# 无参数:使用内置示例数据(菲瑞药业)
python scripts/generate_docx.py
# 带参数:生成指定公司的报告
python scripts/generate_docx.py --company "某科技公司" --output "报告路径.docx" [--json "data.json"]
⚠️ 本脚本为本地部署参考,依赖 Node.js 环境,在 Coze 环境中请使用
main.py。 需安装npm install docx后运行node scripts/create_report.js。