周末一口气把 GPT-6 的官方入口全试了一遍三个项目都在同一时间线上推进一个用自然语言生成 3D 模型构造指令一个让 AI 直接画电路原理图还有一个开 Codex 模式硬啃一个写坏了的代码模块。听起来像是什么极客爱好者的自我折磨其实更像是一顿操作猛如虎的真实压力测试。如果你正准备用 GPT-6 干点正经活而不是只在线聊天那这篇文章就是给你看的。我把同一天里跑出来的经验、教训和一批可复用的提示词写法直接摊开来讲包括哪些入口适合干什么事、为什么有时候输出看起来靠谱实际却坑人、以及最终我怎么用一套“先给目标、再给参数、最后给约束”的提示顺序救了场。往下看你会得到一套能直接抄作业的用法。1. 周末试跑前的规划我为什么同时开三个入口1.1 三个官方入口的实际分工平时大多数人用大模型就是打开聊天窗口问一句答一句但真正拿来干活的时候这种用法太浪费了。我这周末做的事本质上是把 GPT-6 当成了三个不同岗位的员工聊天窗口适合做方案推演、需求澄清、生成初始的代码片段交互速度快不用等到天荒地老。Codex 模式适合进代码仓库里干活能自动阅读文件、跑测试、修改代码并重新跑一遍属于“动手执行型员工”。多模态接口我这边管它叫 Astra 通道能接收图片和混合输入适合做原理图解析、手绘图转结构、照片参数提取这类任务。一开始我把它们混着用结果发现不行。比如我在 Astra 里让它修改代码它虽然能做但每次都要我把现有文件完整贴进去来来回回把窗口挤爆。反过来在 Codex 模式里让它看一张板卡照片它只能通过 OCR 和图像描述猜个大概完全没有发挥出多模态的长处。所以第一天的上午我几乎都在做“分诊”把任务拆分按类型分配给不同入口。这个动作看着简单但实际上决定了后面两个项目的效率差距有多大。1.2 关于“狂蹬”的真正含义别让上下文淹没“狂蹬”不是说要一口气在对话框里输入几百条指令而是说你要不断切换思维给 AI 分配串联的任务同时还要保持每个任务的上下文足够干净。我踩过一个很典型的坑在同一个窗口里先聊了 3D 模型需求又插进来问了一句原理图的事结果再让它改模型时它把原理图里的元件参数带进了建模参数导出的零件尺寸完全错乱。后来我把每个项目拆成独立的会话并且每次新任务开头都用一段“任务卡片”重置上下文效果立刻不一样了。所谓任务卡片就是先用几句话说明当前目标、已有的约束条件、期望的输出格式然后再开始对话。1.3 成本和时间确实是在狂烧这里得说实话整个周末的算力消耗相当大尤其是 Codex 模式它会自动执行工具链、读文件、迭代测试每轮消耗的 token 比普通聊天多出一个量级。我中间一度因为没控制住迭代次数把任务额度用掉了一大半。后来我学到一个控制办法每次启动 Codex 前先明确“最多迭代三轮”和“只修这一个问题”并在提示里写清楚边界。模型在有明确指令的情况下很少会越界扩张任务范围。这一点后面我会详细展开。2. 第一个项目用“3D模型构造指令”直接生成可装配零件2.1 为什么我不用“直接生成 STL”这条路很多人一上来就问能不能让 GPT-6 直接输出一个 STL 文件我试了结果就是在生成的网格数据里出现了大量空洞、非流形边和翻转法线放进切片软件根本没法用。问题出在“构造”和“生成”的差别上。神经网络擅长的是理解语义、推断形状、输出参数化描述但直接生成二进制网格文件时它对几何拓扑的理解会被压缩成概率采样于是容易在细小结构上出错。相比之下让它生成一段可执行的代码再由 CAD 软件去执行每一步都是确定性的计算误差就小得多。所以我的选择是让 GPT-6 输出 OpenSCAD 脚本并把它当作描述 3D 模型的首选格式。OpenSCAD 是程序化建模工具所有几何体都由代码定义既能看到设计意图也能方便地改参数。2.2 一份能直接跑通的“构造指令”提示这里是我真正用到的提示文本你照抄就能用意图生成一个可 3D 打印的电机安装支架。 功能要求 1. 底部有 4 个 M3 通孔孔间距 25.4mm排布成正方形。 2. 上方有半圆形抱箍内径 22mm用于固定 42 步进电机。 3. 整体壁厚不得小于 3mm。 4. 底板四角做 5mm 倒角减少打印翘边。 输出要求 - 使用 OpenSCAD 语法。 - 所有尺寸用变量定义方便调整。 - 禁止硬编码数值必须通过变量给出。我把这一段粘贴进去第一次生成的脚本虽然结构完整但 4 个 M3 通孔里有一个被模型错误地定义成了沉头孔。原因是它在理解“通孔”和“沉头孔”时自行脑补了“可能需要更精细”的设计。解决方案很简单我在参数表里明确加了一句“孔类型只允许两种值through 或 blind不得出现其他变体。”第二次生成的脚本就完全对了用 OpenSCAD 打开后可以直接预览。2.3 离线验证3D 打印前的两道检查代码生成了不等于模型就能打。我把 OpenSCAD 导出的 STL 文件放进切片软件前做了两件事。第一是壁厚检查。我用的切片软件是 PrusaSlicer它自带的“检测薄壁”功能能直接把壁厚不足的区域标红。GPT-6 在生成螺丝柱的时候把螺纹芯和外部支撑体合并成了一个特征局部壁厚只有 1.8mm虽然模型看起来完整但打出来一掰就断。这个只能在切片软件里才能看出来光看预览图很难发现。第二是干涉检查。我用 FreeCAD 把电机模型和支架模型简单装配了一次发现抱箍的内径和电机外壳是过盈配合而不是间隙配合0.2mm 的干涉在实际打印中完全可以靠材料变形勉强装上但如果换成金属打印就会直接卡死。我把配合间隙需求补进提示改成内径 22.4mm重新生成的脚本就正确了。2.4 三种输出方式的对比别太迷信“一步到位”输出方式上手难度出图速度实际可用度我的评价直接输出网格文件低快很低模型花哨但没法加工生成 OpenSCAD 脚本中较快高首选改参数方便生成 FreeCAD Python API 脚本高慢较高适合复杂装配但调试时间长我的建议是除非你有成熟的网格修复流水线否则默认让 AI 输出 OpenSCAD 脚本比直接生成网格文件更可靠。这个经验在后面的机械零件建模里反复验证过。3. 第二个项目让 Astra 画电路原理图结果被网表教育了3.1 问题起点Astra 能画电路原理图吗搜索热词里有一个很直接的问题gpt6 astra 可以画电路原理图吗。我的答案是有条件地能。它能画出结构清晰、符号正确的原理图特别是当你把需求描述得足够完整时AI 会根据它见过的海量参考电路进行组合。但问题也出在这里它画出来的图“太像真的了”而实际上某些连接关系完全不符合电气规范。我这次想做的是一个 USB 供电的电流检测板核心芯片是 INA219板上要有一路 5V 转 3.3V 的 DC-DC再加一块 0.96 寸 OLED 显示屏接口。提示我写得很完整设计一个电流检测原理图 1. USB 输入 5V稳压输出 3.3V。 2. 使用 INA219 采集负载电流通过 I2C 输出。 3. OLED 显示屏接 I2C地址由硬件跳线决定。 4. 电源输入增加 LC 滤波防止 USB 电源纹波干扰测量。 输出格式 - KiCad 原理图可读的网表。 - 文本形式列出所有元件的连接关系。Astra 在几秒钟内就给出了一份结构完整的网表甚至帮我选好了电容、电感和稳压器型号。但我把网表导进 KiCad 后发现一个问题INA219 的采样电阻位置不对。它把采样电阻画在了负载回路之外看起来图面很漂亮测量结果却会完全错误。3.2 到底是哪里错了原理图不只是“连线正确”原理图漂亮与否和它能不能工作是两回事。我复盘的时候发现Astra 的生成逻辑更多是基于“常见电路拓扑的组合”而不是基于“这个电流要流经哪些路径”的物理推导。它对 INA219 的功能有一定的理解但忽略了 INA219 有两种常见接法高侧采样和低侧采样。不同接法下采样电阻的位置完全不同。我提示里没有明说要用哪种接法它就默认选了低侧采样但元件摆放却按高侧采样的习惯排布结果网表里的连接关系自洽实际测量区域却覆盖不到负载电流。这种错不是语法错而是设计意图错。AI 没有办法像工程师一样盯着 PCB 布线图盯着看几分钟就发现采样回路被切割了。3.3 怎么把它拉回正轨把数据手册的关键参数喂进去我后来把 INA219 数据手册里关于采样电阻的部分复制出来放进对话里并明确要求“采用高侧采样拓扑采样电阻位于电源正极和负载正极之间电流路径必须经过采样电阻。”Astra 重新生成的网表就正常了。这个经验的核心是对安全关键的电路不能靠自然语言里的隐含假设必须把电气约束写成硬性规则。就像你给一个实习生派活只说“做一个电路”他可能给你做出十个不同版本但如果你给他数据手册和拓扑图他就能在约束范围内完成任务。3.4 人工审核清单AI 画完图后我必查的四件事电源路径从输入到输出按电流走向完整走一遍看有没有断开或并联错误。地平面和回流检查地线是否在原理图中被正确连接尤其是 IC 的散热焊盘。去耦电容位置AI 经常把去耦电容放得离电源引脚太远甚至并联在错误节点上。引脚极性电解电容、二极管、稳压器的 pin1 方向AI 偶尔会搞反。做完这套检查我才放心把生成的原理图放进 PCB 设计工具继续布线。整个流程下来AI 确实帮我把从“想法到第一版原理图”的时间压缩了大约百分之八十但它不可能取代最后的验证环节。4. 第三个项目半夜三点Codex 帮我查出等价类边界错了4.1 Codex 的定位它不只是一个聊天框Codex 模式用起来更像是有个同事坐在你电脑前能自己翻代码、运行测试、修改文件然后把结果汇报给你。我这次处理的是一个验证函数的错误表面上只是某个参数校验失败但实际上一连串测试都没过属于典型的“根因在一个地方症状在另一个地方”。具体代码大概是这样的fn validate_item(code: str) - Result(), ValidationError { if code.len() 6 { return Err(ValidationError::TooShort); } if code.contains(__) { return Err(ValidationError::InvalidSeparator); } // ... Ok(()) }所有测试里有一条失败了当传入的 code 是空字符串时函数返回的是 TooShort但测试期望返回 EmptyInput。这看起来是一个很小的边界问题。4.2 第一次尝试我让它直接修结果它过度优化了我犯了一个新手都会犯的错直接告诉 Codex “修复这个测试失败”。结果它没有只修函数而是把整个验证模块的代码重新组织了一遍还解耦了错误类型看似干净整洁可测试日志里冒出了三个新的失败。后来我意识到Codex 在意图不明确时会倾向于“重构代码”而不是“修复缺陷”。因为重构可以让它的修改显得更有成效却不一定能解决根本问题。这个行为很像是有些工程师在接到 bug 单时喜欢顺手把周边代码“优化”一下。正确的做法是在提示里明确限定范围不要重构不要修改其他函数。 只修复 validate_item 中空字符串输入时返回错误类型错误的问题。 先运行相关测试再给出修改。加了这句话之后Codex 就只改了一行测试立刻通过。4.3 等价类划分Codex 教会我的测试方法论真正让我觉得“值回票价”的是 Codex 在多次失败后生成的测试矩阵。它没有停留在“修一个 bug”层面而是把输入空间拆成了四个等价类空字符串长度不足含非法分隔符正常输入然后为每个等价类生成了边界测试用例比如长度恰好为 6 的输入、长度恰好为 5 的输入、包含连续下划线的输入、包含一个下划线的输入。这些测试用例帮我确认了修改没有引入回归。我之前手动写测试时经常倾向于选几个代表性输入就完事很少系统性地覆盖边界。而这个等价类划分方法天然适合用大模型来做因为它只要理解了规则就能输出穷举式的边界组合。4.4 一个重要的使用心得给 Codex 设定迭代上限如果你也打算在周末熬夜跑 Codex我强烈建议在启动时设置迭代次数上限否则它会因为它自己生成的测试失败而无限循环下去。我见过它为了满足某个测试用例不断调整逻辑结果陷入“修好一个又坏掉另一个”的死循环。合理的用法是把它限制在“最多迭代三轮每轮都先读取测试失败信息再修改代码最后运行测试”。这样即使第一次没有修对也能快速收敛不会让它自己在代码里探索出越来越多的分支。5. 三个项目跑完我对 GPT-6 的使用习惯发生了什么变化5.1 提示顺序比提示词本身更重要周末这一轮折腾下来我最深刻的体会是提示词不是越多越好关键是顺序。一个有效的任务提示应当遵循“目标-参数-约束-输出”这个顺序。目标给的是大方向让模型知道你要什么参数给的是具体量让模型有据可依约束给的是边界让模型知道不能做什么输出给的是格式省去后面解析的麻烦。我后面所有项目都按这个顺序写成功率明显提升。比如生成 3D 模型时我先说“做电机支架”再说“孔间距 25.4mm”再说“禁止硬编码”最后说“用 OpenSCAD”。这个顺序看起来简单但实际效果差别很大。5.2 AI 生成的工程文件不等于成品三个项目都验证了一件事无论是一段 3D 建模脚本、一张电路原理图还是一段代码AI 生成的结果都只能看作“草稿”。它最大的价值是把一个项目从零推到百分之七八十的完成度剩下的百分之二三十需要人来判断、验证、修整。这不是一个悲观结论反而是最实用的用法。如果我把 AI 生成的内容当成品用大概率会被网表里的采样电阻坑到打板回来才发现问题。但把它当草稿用我就可以在十分钟之内拿到一版正式发布前的原型然后花更多时间在真正重要的验证上。5.3 后续可以怎么扩展这周末只用来跑了边缘样例但已经足够说明问题。下一步我打算把三个项目的提示模板抽象成一套自定义工作流检测到自然语言输入后先自动拆分为目标、参数、约束再交给对应入口执行最后把输出统一收集回项目看板。这样不仅省去手工复制粘贴的麻烦也能让 AI 在不同阶段之间保持上下文连续。我也建议你不要只在一个入口里死磕多试试不同模式的组合。真正高效的状态不是“AI 代替我干活”而是“AI 帮我挡住大量重复劳动让我集中精力判断那些它判断不了的事情”。