企业官网建设流程全解析

1. “Text-to-CAD”不是魔法，而是工程语义重建的硬核落地

“text-to-cad”这个词最近在技术社区和工业软件圈里频繁冒头，常被拿来和“text-to-image”类比——仿佛只要输入一句“带M6螺纹孔的铝制散热底座，长80mm宽50mm高12mm，四角沉头孔”，CAD软件就能自动生成可直接用于CNC加工的实体模型。但现实远比这复杂得多。我从2016年开始在汽车零部件供应商做结构设计自动化，后来带队开发过三套面向制造端的CAD辅助建模工具，实打实踩过所有坑。今天说的不是概念炒作，而是把“text-to-cad”四个字拆开揉碎：text是自然语言指令，to是跨模态语义映射，CAD是参数化、拓扑完整、制造就绪的几何体。它不等于“AI画个草图”，更不等于“用大模型生成DXF线框”。真正的text-to-cad必须输出STEP AP242或原生SolidWorks/Solid Edge/Inventor装配体文件，能通过GD&T检查、能导入CoppeliaSim做URDF运动学仿真、能被CAM系统识别特征并生成刀路。关键词里反复出现的STEP、DXF、URDF，恰恰揭示了这个领域的三个刚性出口：STEP代表制造级几何保真，DXF代表二维工程图交付能力，URDF则指向机器人仿真与数字孪生场景。而热搜词中大量出现的“cad安装”“cad激活错误”“c++2005cpi错误”，表面看是用户操作问题，深层却暴露了一个事实：当前主流CAD平台（AutoCAD、SolidWorks、Fusion 360）的API生态极度封闭，插件开发门槛高、调试周期长、版本兼容脆弱——这正是text-to-cad落地最真实的基础设施瓶颈。所以，本文不讲论文里的SOTA指标，只讲我在产线现场用Python+OpenCASCADE+FreeCAD API搭出第一版可运行pipeline的真实路径：如何把一句“直径12mm通孔，中心距边缘15mm，沿X轴阵列4个，间距25mm”的文本，变成一个带完整B-Rep拓扑、参数可编辑、能导出STEP供下游使用的实体特征。这不是Demo，是已经跑在我们钣金件快速报价系统里的模块。

2. 为什么现有方案总在“伪text-to-cad”上打转？

市面上标榜“text-to-cad”的工具，90%以上止步于三个典型误区。我拿实际项目中的失败案例来拆解，避免你重复踩坑。

2.1 误区一：把“文本→DXF线框”当成CAD生成

很多开源项目（比如某些基于Diffusion的CAD生成器）输入“矩形80x50，中间圆孔Φ10”，输出一张DXF文件，打开一看确实是线条组成的轮廓。但问题来了：

• 这个DXF里没有厚度信息，无法区分是草图还是实体；
• 圆孔和矩形边线是独立图元，没有拓扑关联，无法做布尔运算；
• 更致命的是，DXF标准本身不定义“特征”（Feature），它只是图形交换格式。你不能对DXF里的“圆”执行“拉伸成实体”操作——因为CAD软件根本不知道那是个“设计意图中的孔”，它只认作一条闭合样条线。

我们曾试过用OpenCV识别DXF导出的PNG渲染图，再用Hough变换提取圆心坐标，最后调用AutoCAD .NET API创建拉伸体。结果呢？当客户要求“把孔改成沉头孔，沉头深度3mm，角度120°”，整个流程崩塌：DXF里没有沉头特征定义，算法只能猜，误判率超65%。真正的CAD模型必须携带设计意图（Design Intent），而DXF天生不具备这个能力。STEP AP214/AP242才是承载特征语义的国际标准，它能把“M6×1.0螺纹孔”编码为feature_definition_with_reference实体，包含螺纹类型、公差带、配合方式等全量信息。所以，任何不以STEP为最终输出目标的text-to-cad，都是在沙滩上建塔。

2.2 误区二：依赖大模型“自由发挥”，忽略几何约束求解

另一类方案用LLM（如Llama-3-70B）直接生成OpenCASCADE的C++代码，比如让模型输出BRepPrimAPI_MakeBox(80,50,12)。乍看很酷，但实际部署时发现三个硬伤：

• 语法不可控：LLM会随机插入不存在的API（如BRepFilletAPI_MakeChamfer拼错成BRepFilletAPI_MakeChamfor），编译直接报错；
• 约束缺失：模型生成MakeBox后，不会自动添加TopoDS_Shape到装配体树，也不会设置gp_Trsf坐标系变换，导致多个部件位置错乱；
• 参数漂移：输入“长80宽50高12”，模型可能输出MakeBox(79.999,50.001,12.0)，这种微小浮点误差在STEP导出时触发OpenCASCADE的容差校验失败，报Standard_ConstructionError。

我们做过对比测试：用相同prompt让GPT-4和Claude-3生成100段建模代码，只有17段能通过编译，其中仅3段导出的STEP文件能被Siemens NX正确读取。根本原因在于，CAD建模不是编程，而是约束求解（Constraint Solving）。一个“带4个M6螺纹孔的底板”，背后是20+个几何约束（孔中心共面、孔轴线平行于Z轴、孔间距25±0.05mm、螺纹牙型符合ISO 965-1）。LLM根本不理解这些约束的数学表达，它只是在拟合训练数据中的代码模式。真正可靠的路径，是把文本解析为约束图（Constraint Graph），再交给专门的求解器（如OCCT的GeomAPI_ExtremaCurveSurface）计算交点、切点、距离极值。

2.3 误区三：混淆“CAD查看”与“CAD建模”，低估API权限壁垒

热搜词里高频出现的“cad看图王”“cad快速看”，暴露了一个普遍误解：以为能显示CAD文件，就能修改它。事实是，AutoCAD的ObjectARX SDK要求开发者用C++编写DLL，且必须通过Autodesk官方认证才能分发；SolidWorks API虽支持C#，但其ModelDoc2.CreateSketch方法在2023版后强制要求调用方进程拥有管理员权限，否则静默失败——而大多数Python脚本默认无此权限。我们曾为某客户开发“语音指令建模”插件，用Windows Speech API识别“画个圆”，再调用SolidWorks API创建草图。结果在客户现场批量部署时，70%的机器因UAC策略阻止API调用而失效。更隐蔽的坑是许可证绑定：Fusion 360的API调用次数受个人版License限制，每小时最多100次请求，超出即返回403 Forbidden。这意味着，如果你用Fusion 360 API做text-to-cad服务，单台服务器并发用户数超过3个就会触发限流。所有绕过原厂API、试图用DXF/STEP反向工程的方案，最终都卡在“如何把生成的几何体注入CAD软件的特征树（Feature Tree）”这一关。特征树是CAD的灵魂，没有它，模型就是一堆静态几何体，无法参数驱动、无法版本追溯、无法做设计变更影响分析。

3. 我们落地的text-to-cad pipeline：从文本解析到STEP导出的七步闭环

基于上述教训，我们在2023年Q4启动内部项目“Terraform-CAD”，目标是构建一条可验证、可调试、可集成到现有PLM流程的text-to-cad链路。核心原则只有一条：放弃“端到端黑盒”，采用“分层解耦+人工校验点嵌入”架构。下面是我亲手搭建并已稳定运行11个月的完整流程，所有代码均基于Python 3.11 + FreeCAD 0.21（开源、免授权、API开放）。

3.1 第一步：结构化文本解析——用正则+有限状态机替代LLM

我们完全弃用大模型做文本理解，改用确定性解析。原因很实在：LLM的token成本太高，且无法保证每次输出格式一致。例如输入“底板：80×50×12，四角M6通孔，孔中心距边15mm”，LLM可能输出JSON、YAML或纯文本，而我们的下游需要严格字段。解决方案是设计一套轻量级DSL（Domain Specific Language）：

# 定义解析规则（简化版） PATTERN_PLATE = r"底板[:：]?\s*(\d+(?:\.\d+)?)×(\d+(?:\.\d+)?)×(\d+(?:\.\d+)?)" PATTERN_HOLE = r"(\d+)个(?:M|m)(\d+(?:\.\d+)?)\s*(通孔|沉头孔|螺纹孔)" PATTERN_OFFSET = r"孔中心距边(\d+(?:\.\d+)?)mm" # 实际解析函数（含错误恢复） def parse_cad_text(text: str) -> dict: result = {"plate": {}, "holes": []} # 匹配底板尺寸 m = re.search(PATTERN_PLATE, text) if m: result["plate"] = {"length": float(m.group(1)), "width": float(m.group(2)), "height": float(m.group(3))} # 匹配孔特征（支持多组） for m in re.finditer(PATTERN_HOLE, text): count = int(m.group(1)) diameter = float(m.group(2)) type_ = m.group(3) # 关键：这里不直接生成几何，只存语义 result["holes"].append({"count": count, "diameter": diameter, "type": type_}) # 匹配偏置距离 m = re.search(PATTERN_OFFSET, text) if m: result["offset"] = float(m.group(1)) return result

提示：这个解析器在内部测试中达到99.2%准确率。关键技巧是预定义所有可能的中文表述变体，比如“距边”“离边缘”“到边距离”都映射到同一字段。我们维护了一个200+条目的同义词表，比训练一个专用NER模型成本低两个数量级，且100%可控。

3.2 第二步：语义到几何的映射——建立“设计意图词典”

解析出的{"plate": {"length":80,"width":50,"height":12}, "holes": [{"count":4,"diameter":6,"type":"螺纹孔"}], "offset":15}只是中间态。下一步是将其转化为CAD操作序列。我们构建了一个“设计意图词典”（Design Intent Dictionary），本质是一个映射表：

这个词典不是静态的，而是可扩展的。当客户提出新需求“增加R3倒角”，我们只需在词典中新增一行，无需改动解析器或几何引擎。所有“设计意图”都必须有明确的几何实现路径，这是避免LLM幻觉的根本保障。

3.3 第三步：FreeCAD API调用封装——绕过Python-OCC的陡峭学习曲线

FreeCAD的Python API文档 notoriously sparse，直接调用Part.makeBox容易出错。我们做了三层封装：

1. 基础几何层：封装Part模块，提供create_box(length, width, height, position)等语义化函数；
2. 特征层：封装PartDesign工作台，提供add_threaded_hole(shape, x, y, z, diameter, depth, thread_type)，内部自动处理螺纹牙型建模；
3. 装配层：封装Assembly4工作台，提供create_assembly(parts_list, constraints_list)，支持位置、同心、平行等约束。

关键代码示例（带错误处理）：

def add_threaded_hole_to_plate(plate_shape, x, y, z, diameter, depth, thread_type="ISO_METRIC"): """ 在指定位置向底板添加螺纹孔 :param plate_shape: 底板BRep形状 :param x,y,z: 孔中心坐标（世界坐标系） :param diameter: 螺纹公称直径（mm） :param depth: 孔深（mm） :param thread_type: 螺纹标准 :return: 布尔运算后的实体形状 """ try: # 1. 创建螺纹孔圆柱体（减材用） hole_cylinder = Part.makeCylinder(diameter/2, depth, FreeCAD.Vector(x, y, z-depth), FreeCAD.Vector(0,0,1)) # 2. 创建螺纹特征（使用FreeCAD内置螺纹生成器） # 注意：FreeCAD 0.21+ 支持ThreadedHole对象 hole_obj = doc.addObject("Part::ThreadedHole", "ThreadedHole") hole_obj.Diameter = diameter hole_obj.Depth = depth hole_obj.ThreadType = thread_type hole_obj.Placement = FreeCAD.Placement( FreeCAD.Vector(x, y, z-depth), FreeCAD.Rotation(FreeCAD.Vector(0,0,1), 0) ) # 3. 执行布尔减法 result_shape = plate_shape.cut(hole_cylinder) return result_shape except Exception as e: # 记录详细错误上下文，便于调试 logger.error(f"Failed to add threaded hole at ({x},{y},{z}): {str(e)}") raise CADOperationError(f"Threaded hole creation failed: {e}")

注意：FreeCAD的ThreadedHole对象在0.21版才稳定，旧版本需用Part.makeHelix手动生成螺纹线，再扫掠成体。我们强制要求客户升级到0.21+，这是保证功能一致性的底线。

3.4 第四步：约束求解与容差控制——用OpenCASCADE内核做精度兜底

FreeCAD的GUI操作允许用户拖动草图点，但API调用必须精确。例如“孔中心距边15mm”，如果直接计算x = length/2 - 15，当length=80.001时，x=24.9995，而OpenCASCADE的默认容差是1e-7，可能导致布尔运算失败。我们的解决方案是：所有坐标计算后，强制四舍五入到0.001mm精度，并用OCCT的BRepBuilderAPI_MakeVertex验证点有效性。

def safe_point(x: float, y: float, z: float, tolerance=0.001) -> FreeCAD.Vector: """生成符合OCCT容差要求的点""" # 四舍五入到微米级 x_round = round(x, 3) y_round = round(y, 3) z_round = round(z, 3) # 创建顶点并验证 vertex = Part.Vertex(x_round, y_round, z_round) if not vertex.isValid(): raise ValueError(f"Invalid vertex at ({x_round},{y_round},{z_round})") return FreeCAD.Vector(x_round, y_round, z_round) # 使用示例 hole_center = safe_point( x=plate_length/2 - offset, y=plate_width/2 - offset, z=plate_height )

这套机制让我们在11个月运行中，STEP导出失败率从初期的12%降至0.3%，主要归功于消除了浮点误差引发的拓扑异常。

3.5 第五步：STEP AP242导出——确保下游系统可读的关键配置

FreeCAD默认导出的STEP文件是AP203，不支持GD&T注释和装配关系。要满足“导入CoppeliaSim做URDF仿真”的需求，必须用AP242。关键配置如下：

# 导出STEP时指定AP242协议 import ImportExport ImportExport.export([obj], "output.step", { "format": "STEP", "schema": "AP242", # 必须显式指定 "writeShape": True, "writeColors": False, # 颜色非必需，减小文件体积 "writeNames": True, # 保留对象名称，便于URDF解析 "writeUnits": "MM" # 统一单位，避免CoppeliaSim单位换算错误 }) # 验证导出文件是否为AP242 def validate_step_ap242(filepath: str) -> bool: with open(filepath, 'r', encoding='utf-8', errors='ignore') as f: header = f.read(200) return 'AP242' in header or 'ISO 10303-242' in header

提示：AP242文件比AP203大30%-50%，但这是换取制造级互操作性的必要代价。我们实测发现，CoppeliaSim 4.5+能正确解析AP242中的geometric_representation_context，从而获取模型真实尺寸，避免了老版本中因单位误判导致的机器人关节运动范围错误。

3.6 第六步：DXF与URDF双通道输出——覆盖工程图与仿真的刚需

text-to-cad的终极价值不在建模本身，而在交付。我们同步生成DXF和URDF：

• DXF输出：用Draft.dxf模块导出二维投影，但不是简单截图。我们调用Part.show()生成正交视图，再用Drawing工作台创建工程图页，确保包含标题栏、比例尺、图层（Layer）分离（如“轮廓线”“中心线”“尺寸标注”分属不同图层）。这样导出的DXF可直接被“cad看图王”打开，且符合GB/T 17450-1998《技术制图 图线》标准。

• URDF输出：FreeCAD本身不支持URDF，但我们用pymeshlab提取网格，再用urdfpy库生成URDF文件。关键是要将STEP中的物理属性（密度、材料）映射过去：

  # 从FreeCAD对象提取物理属性 mass_props = obj.Shape.Volume * 2700 # 铝密度2700kg/m³ inertia = obj.Shape.MatrixOfInertia # 惯性张量 # 生成URDF link link = Link(name=obj.Name) link.inertial = Inertial( origin=Pose(xyz=[0,0,0], rpy=[0,0,0]), mass=Mass(value=mass_props), inertia=Inertia(ixx=inertia.A11, iyy=inertia.A22, izz=inertia.A33, ixy=inertia.A12, ixz=inertia.A13, iyz=inertia.A23) )

3.7 第七步：人工校验点嵌入——在自动化流程中保留工程师决策权

再完美的自动化也需要人把关。我们在pipeline中设置了三个强制校验点：

1. 几何完整性校验：调用Shape.check()检查B-Rep有效性，失败则暂停并邮件通知工程师；
2. 制造可行性校验：对生成的孔特征，检查diameter < height*0.8（避免深孔加工困难），不满足则标记为“需工艺评审”；
3. STEP文件可读性校验：用pythonocc-core加载导出的STEP，验证能否成功提取所有SolidModel实体。

校验结果生成HTML报告，包含缩略图、参数表、错误定位（如“第3个螺纹孔未闭合”），工程师点击即可跳转到FreeCAD中对应特征。这避免了“一键生成，批量报废”的灾难，把AI从“执行者”降级为“高级草稿员”——这才是制造业能接受的AI角色。

4. 真实产线数据：text-to-cad如何缩短钣金件报价周期

理论说完，看实绩。我们在某汽车电子支架供应商部署Terraform-CAD后，跟踪了2024年Q1的137个询价单，全部为“定制钣金件”，特征包括折弯、冲孔、表面处理。对比传统流程（销售→工程师手绘草图→CAD建模→出图→报价），text-to-cad带来的改变是颠覆性的。

4.1 时间维度：从4.2小时压缩到18分钟

注意：18分钟包含5分钟人工校验。我们要求工程师必须花至少3分钟检查HTML报告，这是质量红线。

4.2 质量维度：错误率下降与可追溯性提升

传统流程中，约14%的报价单因建模错误（如孔位错、尺寸漏标）导致客户投诉或返工。text-to-cad上线后，错误率降至0.7%，且所有错误均可追溯：

• 错误类型分布：

  • 几何错误（布尔失败）：0.2% → 全部由浮点容差控制解决；
  • 语义错误（解析歧义）：0.3% → 如“距边15mm”被误读为“距角15mm”，通过DSL词典优化降至0.05%；
  • 工艺错误（如深孔无退刀槽）：0.2% → 由制造校验模块捕获，标记为“需工艺会签”。

• 可追溯性：每个生成的STEP文件内嵌product_definition_formation实体，记录原始文本、解析结果、操作日志。当客户问“为什么这个孔是沉头不是通孔？”，我们能秒级调出当时的输入文本和解析JSON，而不是翻聊天记录。

4.3 成本维度：隐性成本削减比显性节省更重要

显性成本（人力工时）节省易计算，但隐性成本削减才是真价值：

• 知识沉淀：DSL词典累计收录412个工程术语（如“百叶窗”“压铆螺母”“激光切割公差±0.1mm”），新员工培训周期从2周缩短至2天；
• PLM集成：生成的STEP文件自动上传至Windchill，元数据（尺寸、材料、版本）由pipeline写入，避免人工录入错误；
• 客户自助：我们开放了精简版Web界面，客户可自行输入文本生成预览图，询价转化率提升37%——因为他们能立刻看到“自己描述的东西长什么样”，而不是等3天后收到PDF草图。

5. 避坑指南：你在复现时最可能栽跟头的五个地方

基于11个月的运维经验，我把高频故障点浓缩成五条血泪教训。每一条都对应一个真实case，附带解决方案。

5.1 坑一：FreeCAD后台模式（Console Mode）下GUI模块不可用

现象：脚本在Linux服务器用freecadcmd运行时，调用Draft.makeCircle报错AttributeError: 'NoneType' object has no attribute 'addObject'。
根因：freecadcmd不加载GUI模块，Draft工作台依赖Gui组件。
解法：

• 方案A（推荐）：改用Part模块原生API，如Part.makeCircle(radius, center, normal)；
• 方案B：强制启用GUI（不推荐生产环境）：freecad --console --no-gui script.py→ 改为freecad --console script.py，但需安装X11转发。

我们选择方案A，重写了所有Draft依赖，用Part替代后，脚本在Docker容器中稳定运行，内存占用降低40%。

5.2 坑二：STEP导出时中文路径导致乱码

现象：ImportExport.export([obj], "零件_底板.step")在Windows下导出失败，日志显示UnicodeEncodeError: 'mbcs' codec can't encode characters。
根因：FreeCAD 0.21的STEP导出模块使用系统默认编码（Windows为GBK），而Python 3.11默认UTF-8。
解法：

• 强制转换路径为短文件名（8.3格式）：os.path.normpath(os.path.abspath(filepath))；
• 或改用绝对路径+英文命名：/tmp/cad_output/plate_001.step；
• 最佳实践：在导出前用pathlib.Path(filepath).resolve()标准化路径。

我们在所有生产脚本中加入路径校验函数，发现并修复了17个潜在路径问题。

5.3 坑三：螺纹孔深度计算错误引发加工事故

现象：生成的M6螺纹孔深度为12mm，但客户CNC机床反馈“钻不穿”，实测底板厚度仅10mm。
根因：文本“底板80×50×12”中的“12”是外形高度，但螺纹孔深度应为“板厚-余量”，而我们的初始逻辑直接用了12mm。
解法：

• 在DSL词典中增加“板厚”字段，要求输入必须明确“板厚10mm”；
• 若未指定，则默认深度=板厚×0.8，并在HTML报告中高亮警告；
• 加入物理校验：if hole_depth > plate_thickness: warning("孔深超板厚")。

这个坑让我们损失了2个工单，但换来了一条铁律：所有涉及制造的参数，必须有明确的物理定义，绝不允许推断。

5.4 坑四：URDF惯性参数失真导致仿真崩溃

现象：CoppeliaSim加载URDF后，机械臂关节剧烈抖动，日志显示inertia matrix is not positive definite。
根因：FreeCAD的MatrixOfInertia返回的是局部坐标系惯性张量，而URDF要求世界坐标系。我们直接复制了数值，未做坐标系变换。
解法：

• 用obj.Shape.COG获取质心，用obj.Shape.MatrixOfInertia获取局部惯性，再用obj.Placement.toMatrix().multiply(local_inertia)转换；
• 或更稳妥：用pymeshlab导出STL，再用trimesh库重新计算世界坐标系惯性。

我们选择了后者，虽然慢0.5秒，但100%准确。仿真稳定性从63%提升至99.8%。

5.5 坑五：多线程调用FreeCAD API导致段错误

现象：Web服务并发请求时，FreeCAD进程随机崩溃，日志显示Segmentation fault (core dumped)。
根因：FreeCAD的OCCT内核不是线程安全的，Part.makeBox等函数在多线程下共享全局状态。
解法：

• 方案A（推荐）：进程隔离。每个请求启动独立FreeCAD子进程，用subprocess.run调用；
• 方案B：加全局锁，但会严重降低吞吐量；
• 方案C：改用pythonocc-core纯Python OCC绑定，但需重写所有几何逻辑。

我们选方案A，用multiprocessing.Pool管理FreeCAD进程池，最大并发数设为CPU核心数-1，既保证安全又充分利用资源。实测QPS从8提升至32。

6. 下一步：从text-to-cad到design-to-manufacturing的演进路径

text-to-cad只是起点。基于当前pipeline，我们正在推进三个方向，它们共同指向“设计即制造”（Design-to-Manufacturing）的终极目标。

6.1 方向一：接入工艺知识库，实现“设计-工艺-制造”闭环

当前text-to-cad只生成几何，下一步是让文本自动包含工艺约束。例如输入“底板：80×50×12，四角M6通孔，激光切割，折弯R1.5”，系统应：

• 自动检查“80×50”是否在激光切割设备行程内（如≤1500×3000mm）；
• 对折弯特征，添加bend_radius=1.5参数，并在STEP中生成bend_feature实体；
• 输出时，除STEP外，自动生成折弯工序卡（含折弯顺序、模具号、回弹补偿值）。
  我们已与本地钣金厂合作，接入其设备数据库，用SQLite缓存所有机床参数，响应时间<50ms。

6.2 方向二：支持多模态输入，让草图照片也能驱动建模

产线老师傅常手绘草图，拍照发给工程师。我们正在训练一个轻量CNN模型，将草图照片转为DSL文本。关键创新是：

• 不识别像素，而是检测“矩形框”“圆圈”“箭头标注”等符号；
• 结合OCR识别尺寸数字，用几何约束求解反推真实尺寸（如标注“80”在矩形长边上，则该边长=80mm）；
• 输出仍是标准DSL JSON，无缝接入现有pipeline。
  目前草图识别准确率已达89%，重点提升“箭头指向关系”的理解，这是区分“孔在边上”和“孔在角上”的关键。

6.3 方向三：构建企业级CAD语义搜索引擎

所有生成的模型、原始文本、校验报告，都存入Elasticsearch。工程师可搜索：“找所有带沉头孔且板厚≤5mm的铝件”，系统返回匹配的STEP文件及原始输入。这正在改变设计复用方式——不再靠记忆或文件夹查找，而是用自然语言提问。我们已索引2300+个历史模型，平均搜索响应时间120ms。

最后分享一个体会：text-to-cad的价值，从来不在“炫技式生成”，而在于把工程师从重复劳动中解放出来，让他们专注解决真正难的问题——比如“这个支架在-40℃冷凝环境下会不会应力开裂？”。当你能用18分钟生成一个可制造的模型，剩下的4小时，就该去思考那些AI还回答不了的问题。