这篇文章的主线其实很简单：先明确需求，再生成原型，接着补建模逻辑、补几何资产、补 Git 发布闭环，最后再回头总结 VS Code 和客户端各自适合什么阶段。

前言：这篇文章想解决什么问题

这篇文章我想认真聊一件事：如果把 Codex 当成一个真正能落地干活的开发搭子，到底应该怎么用，才最顺手，最省时间，最容易做出成果。

网上已经有很多关于 AI 编程的内容了，但不少文章要么停留在“AI 很强”“AI 能写代码”的口号层面，要么就是给几段很短的 demo，告诉你让 AI 写一个登录页、写一个 Todo List、写一个小脚本，然后就结束了。这样的内容当然也有价值，尤其是对刚接触的人来说，它能快速建立一个直观印象：原来现在的模型已经不仅能聊天了，还能真的写代码。

但问题在于，真正有参考价值的，从来不是一句“AI 很厉害”，而是一整套“从需求提出，到代码生成，到页面调整，到模型完善，到版本管理，再到最终发布”的完整工作流。

我这次做的项目，题目并不算特别夸张，但也绝对不是一句 prompt 就能自动长出来的那种：我要做一个“子弹打木块”的经典力学问题项目，而且不是只有一个小动画，而是要逐步升级成：

1. 一个能运行的动力学仿真页面；
2. 一个更像专业 CAE / 显式动力学工作台的仿真界面；
3. 一份 CAD 风格工程图；
4. 一个 OBJ 三维模型和本地 3D 预览页；
5. 一个完整 Git 仓库，最后推到 GitHub。

也就是说，这不是“写一段函数”的事情，而是一个很典型的小型工程项目。它同时涉及前端页面、物理建模、交互优化、文档整理、三维模型、Git 工作流，最后还涉及成果输出和分享。

在这个过程中，我没有把 Codex 当成一个“问答机器人”，而是把它当成一个能够持续推进任务的工程协作对象。事实证明，这种用法才是我目前觉得最有价值的用法。

这篇文章就是我把这套过程尽量完整地梳理出来。一方面，是给自己留下一份工作流复盘；另一方面，也希望给那些已经对 AI 编程感兴趣，但还没有真正把它纳入日常开发的人一个更具体、更接地气、更可复制的参考。

如果你也在想下面这些问题：

1. Codex 到底适合在什么场景下用？
2. 是在 VS Code 里用更好，还是直接在客户端里用更好？
3. 我有一个不算太大、但也不止几百行代码的小项目，AI 到底能帮我做多少？
4. 我应该怎么描述需求，AI 才不会越帮越乱？
5. 一个实际项目到底能不能从想法一路做到 GitHub 发布？

那这篇文章应该会比较对你的胃口。

还有一个我特别想补充的点是，很多人判断一类 AI 工具值不值得长期用，往往只看第一次回答是不是惊艳，或者生成的第一段代码是不是能跑。但从我自己的使用经验看，真正决定它有没有生产力价值的，从来不是那一下“像不像魔法”，而是它能不能在第二轮、第三轮、第五轮反馈之后，依然理解你的意图，没有把整个项目越带越偏。因为真实开发几乎不可能一轮完成，真正高频出现的场景永远是：先做出来，再发现不对，再继续改，再补结构，再补文档，再处理环境问题。如果一个工具只能在第一步看起来聪明，后面几步全靠你自己收残局，那它的价值就会迅速下降。

所以我写这篇文章，还有一个隐含目标，就是尽量把“连续协作”这件事写清楚。不是只展示某一句 prompt 多厉害，也不是只展示某一段界面多漂亮，而是想回答一个更实际的问题：当需求开始分叉、文件开始变多、素材开始增加、排版开始出问题、Git 开始报错时，这个工具还能不能跟得上。对我来说，这恰恰才是判断一套 AI 开发流程值不值得认真投入的标准。

为什么我会想到做这个项目

子弹撞木块，其实是一个挺经典的力学问题。很多人中学、大学学动量守恒和碰撞问题的时候，可能都见过类似题目：子弹射入木块，木块后退，或者子弹嵌入木块，系统一起运动。最基础的时候，这类题目只需要列动量守恒方程，甚至一行就算完了。

但问题是，纸面上的一道力学题，和一个真正能展示过程、展示结构、展示建模思路的项目之间，差距其实非常大。

我最开始的想法很简单：做一个“子弹打木块”的小仿真网页。先把事情跑起来，先看到结果。结果做着做着就发现，这类项目特别适合拿来测试 Codex 的能力边界：

1. 它不只是页面问题，因为里面有物理建模；
2. 它不只是公式问题，因为最后还要展示成能看、能调、能解释的界面；
3. 它不只是单文件问题，因为做着做着就会自然生长出 CAD 图、三维模型、README、Git 仓库这些配套资产；
4. 它还很适合写成案例，因为从“一个想法”到“一个完整小工程”的演化过程非常清晰。

所以这个项目后来就不再只是一个练手页面，而更像一次完整的 AI 协作开发实验。

Codex 到底有哪几种用法

一个更贴近真实使用的理解是：客户端更适合把想法先落地，VS Code 更适合在项目成型后做高频迭代、调试和维护。

我自己的感受是，Codex 至少可以分成三种常见用法。严格来说不一定只有这三种，但这三种最有代表性。

第一种：直接在客户端里用

这也是我这次最核心的使用方式。它的感觉不是“我在 IDE 里找个工具补全代码”，而是“我找了一个能持续陪我把事情推进下去的工程协作者”。

客户端模式最大的特点，是它特别适合从一个模糊想法开始做事。比如我一开始说的其实就是一句很宽泛的话：想做一个“子弹打木块”的动力学分析模型。这个表达方式如果丢给传统编辑器插件，很多时候它只能理解成“请生成一段代码”。但在客户端里，Codex 更容易把这句话理解成一个项目需求，然后主动往下延展：

1. 先确认目录是不是空的；
2. 决定先做一个独立 HTML 页面；
3. 先做出第一版能跑起来的仿真；
4. 然后根据我的反馈，逐步提升它的专业程度；
5. 最后再延展到 CAD 图、OBJ 模型、Git 和 GitHub。

这种使用方式非常像和一个会动手的技术同伴聊天。你不是只问一句，它不是只答一句，而是你们一起把事情往前推。

我觉得这种模式特别适合：

1. 从零开始做新项目；
2. 项目还在定形阶段；
3. 你知道自己想做什么，但还没完全想好结构；
4. 你需要把页面、文件、图、模型、说明文档一起整理出来。

第二种：在 VS Code 里用

VS Code 里的使用方式，优势在于它更接近“正经工程开发”的主阵地。你打开仓库、打开终端、看文件树、看 diff、运行程序、调试报错，所有操作都在一个地方完成。

如果说客户端更像“项目起步器”和“工作流组织者”，那 VS Code 更像“工程深挖器”。它很适合在下面这些阶段发力：

1. 项目结构已经比较清晰；
2. 需要频繁打开多个文件比对；
3. 你对代码变更的颗粒度要求更高；
4. 需要大量反复运行、调试、修复；
5. 已经进入日常维护和迭代阶段。

我自己理解的最佳搭配其实不是二选一，而是：

客户端更适合把一件事“做出来”，VS Code 更适合把一件事“做扎实”。

也就是说，客户端适合我在脑子里还没有完全成型时，快速把东西推到可见状态；VS Code 适合我在可见状态已经有了以后，去进一步打磨结构、提取模块、做长期维护。

第三种：终端、浏览器、GitHub 配合使用

很多人以为 AI 编程就是“模型写代码，编辑器接收代码”，其实真正决定体验上限的，是配套工具能不能联动起来。

这次项目里，我感受很明显的一点就是：当 Codex 能同时访问文件系统、终端、浏览器和 Git，它做事的连续性会高很多。

比如这次项目中，它不是只写了 HTML，而是会继续做这些事：

1. 检查当前目录是否为空；
2. 创建工程文件；
3. 在浏览器里打开本地 HTML 验证；
4. 看控制台有没有报错；
5. 做本地截图和页面检查；
6. 创建 README；
7. 初始化 Git 仓库；
8. 处理 .git/config.lock 这种实际环境问题；
9. 绑定远程仓库；
10. 提交并推送到 GitHub。

如果没有这些外围能力，AI 再会写代码，也很难真正形成一套“闭环工作流”。而一旦这些能力连起来，它的角色就不再只是代码生成器，而更像一个能够把项目从头推到尾的执行者。

这次项目到底是怎么一点点做出来的

第一步：先做一个能跑的版本

刚开始的时候，我并没有要求太多。我只是让它建立一个“子弹打木块”的动力学仿真。这个阶段最重要的事情不是一开始就追求专业，而是先让项目活起来。

这一步里，Codex 做的事情非常典型：

1. 先看目录是不是空的；
2. 决定用单文件 HTML 起步；
3. 搭一个参数面板；
4. 用最基础的物理逻辑做一个碰撞和滑移模型；
5. 先把动画、曲线、结果框这些最容易看见的部分做出来。

这一步最大的意义，不在于“模型是不是最先进”，而在于它把一个抽象需求变成了一个可见、可点、可调的东西。只要第一步走到了这里，后面所有迭代就都变得顺滑起来。

第二步：从“演示动画”升级成“专业工作台”

后来我又提出了一个非常关键的反馈：这个东西不能只是个演示动画，而应该更像专业力学仿真软件的界面。

这句话其实特别重要，因为它把产品方向从“教育演示”推到了“工程表达”。于是后面的页面就开始向 CAE 工作台靠拢：

1. 顶部出现了菜单栏和工具栏；
2. 左侧出现工程浏览器、材料参数、弹体参数；
3. 中间变成主视窗；
4. 右侧变成结果监视器；
5. 下方出现速度时程和阻力曲线；
6. 还补了求解日志和控制方程。

这一类内容如果要配图，我现在反而更建议直接放完整页面截图，而不是只截某个参数区或者变量区。因为这个阶段真正想说明的，不是“某个控件长什么样”，而是整个信息架构已经像一个工作台了，读者需要一眼看到左侧参数区、中间主视窗、右侧结果区和下方曲线区是怎么拼成一个完整界面的。

这个阶段我很明显感受到一个事情：你给 AI 的方向词，其实非常重要。

如果我只是说“把这个页面变好看一点”，那它可能只会做一些表面美化；但我说的是“尽量做成像专业仿真工具那样的页面”，它理解的就会是信息架构、面板布局、工作台感、术语体系和操作逻辑。

所以很多时候不是 AI 能力不够，而是我们给的“目标参照系”太弱了。

第三步：把逻辑从简化碰撞推到更工程化的近似模型

我后来又提了一个要求：不要只做个动画，要尽量用更像真实分析的方法去做。

于是模型就从最基础的动量守恒，逐步变成了更像侵彻近似分析的形式，使用了 Poncelet 型阻力表达：

F_res = sigma A + 0.5 rho Cd A v_rel^2

然后再通过显式时间积分去计算：

1. 子弹和木块之间的相对速度变化；
2. 侵彻深度；
3. 是否穿透；
4. 穿透后的残余速度；
5. 冲量、峰值阻力、能量耗散；
6. 木块碰撞后的滑移距离。

如果想让读者更容易看懂，这里其实很适合插一小段伪代码。因为很多人不一定关心完整 JavaScript 实现，但会关心“这个模型到底按什么步骤在跑”：

given m_bullet, m_block, v0, sigma, rho, Cd, mu
initialize t = 0, x = 0, v_b = v0, v_blk = 0
while t < t_end and x < block_thickness:
    v_rel = v_b - v_blk
    F_res = sigma * A + 0.5 * rho * Cd * A * v_rel^2
    a_b = -F_res / m_bullet
    a_blk =  F_res / m_block
    v_b   = v_b   + a_b * dt
    v_blk = v_blk + a_blk * dt
    x     = x + max(v_rel, 0) * dt
    t     = t + dt
postprocess penetration, residual_velocity, impulse, energy_loss, slide_distance

这一段的价值不在于“展示代码量”，而在于让读者知道这个页面背后不是纯动画拼接，而是有一套很清楚的计算流程。

严格来说，这当然还不是完整的三维高保真有限元，但对一个展示型项目、教学型项目和工程思路展示项目来说，这已经不是“瞎动画”了，而是一个有明确物理含义、有参数含义、也有输出解释逻辑的近似工程模型。

我觉得这就是 Codex 特别适合帮忙的一类事情：把“我大概知道需要什么”慢慢推进到“我已经有一个能说服人的结构化成果”。

第四步：继续延展到 CAD 和 3D 模型

做到这一步，如果只停在 HTML 页面，其实也已经可以交差了。但我后面又进一步让它补了一套几何资产：

1. 一份 CAD 风格工程图 bullet_block_cad_drawing.svg；
2. 一份 OBJ 三维模型 bullet_block_system_model.obj；
3. 一份材质文件 bullet_block_system_model.mtl；
4. 一个本地 3D 预览页面 bullet_block_3d_model.html。

这一步特别有意思，因为它代表着项目从“页面级作品”变成了“工程级作品雏形”。页面是结果呈现，CAD 和三维模型则是结构表达。把这两者结合起来，项目的说服力会高很多。

同样地，这里配图也更适合放完整页面截图，而不是只截模型局部。因为读者真正需要看到的是“这是一个可以旋转查看、带有工程背景信息的完整 3D 预览页”，而不是单个零件的放大图。

而且这一套资产非常适合后续继续扩展。比如如果后面我真的想把这个项目进一步推进，可以继续往下做：

1. 把 OBJ 导入更专业的建模工具继续细化；
2. 把 CAD 图扩展成更完整的装配图；
3. 把仿真页面做成多工况系统；
4. 增加材料切换、参数保存、结果导出；
5. 再往后，甚至可以考虑接真实实验数据做标定。

这就是我很喜欢的地方：Codex 帮我做出来的不只是一个“页面”，而是一个可以继续长下去的项目起点。

如果再把这个问题说得更直白一点，就是很多人做项目时最缺的并不是某一段具体代码，而是“把零散成果接起来”的能力。一个页面单独存在，和一个页面能接到模型、能接到图纸、能接到仓库、能接到文档，完全不是同一个层级。前者更像一次性作业，后者更像真正可复用、可展示、可继续维护的项目雏形。AI 真正帮到我的地方，也恰恰是在这个“把东西接起来”的阶段。

第五步：Git、GitHub 和发布闭环

很多 AI demo 到最后都会在一个很尴尬的地方停住：代码是有了，但项目没有管理，没有提交记录，也没有仓库链接，最后东西还是散在本地。

这次我特意把 Git 这一段也走完整。这个过程非常真实，也很有参考价值，因为它不是一帆风顺的：

1. 先初始化 Git；
2. 结果因为系统权限和锁文件问题失败；
3. 发现 .git/config.lock 残留；
4. 手动确认后清掉；
5. 再次初始化仓库；
6. 设置分支名为 main；
7. 绑定远程仓库；
8. 提交本地文件；
9. 最后推送到 GitHub。

更有意思的是，连这个过程中遇到的权限、锁文件、Git 元数据写入问题，Codex 也不是回一句“你自己去处理”，而是能继续帮我分析、处理、重试，最后把事情做完。

所以从项目视角来看，我得到的不只是“AI 写了几个文件”，而是“AI 帮我把一个项目真的做成了一个仓库”。

如果是在 VS Code 里，我会怎么调用 Codex

这一部分我想写得更实在一点。因为很多人嘴上说“在 VS Code 用 AI”，但实际体验常常是：打开插件，问一句，回一句，然后就没有然后了。

如果换成我现在比较认可的方式，在 VS Code 里使用 Codex，大概应该是这样：

1. 先把项目目录打开

这一点很简单，但非常关键。AI 在“看得见项目”的前提下和“只听你口头描述”的前提下，能做的事情完全不是一个量级。

所以第一步不是让它写代码，而是先让它看到：

1. 当前有哪些文件；
2. 项目是不是空的；
3. 现在已经做到哪一步了；
4. 哪些文件是核心文件；
5. 哪些地方需要改。

这就像你找一个人协作开发，总得先让他看一下项目文件夹，而不是闭着眼睛猜。

2. 提需求时尽量说“目标”和“参照”

我现在很少只说“帮我写一个 XX”。我更倾向于说：

1. 我想达到什么效果；
2. 我希望它更像什么东西；
3. 我现在觉得哪里不对；
4. 我优先要改的是哪一层。

比如我这次提的几个关键反馈其实都很有代表性：

1. 这不是演示动画，而是要更专业的力学仿真；
2. 界面尽量做成类似专业工具页面；
3. 中间视窗再大一点，云图连续性更高一点；
4. 要补 CAD 图和三维模型；
5. 最后还要做 Git 和 GitHub。

这些说法比单纯说“改好看点”“做复杂点”有效得多，因为它们给了模型明确的判断坐标。

3. 让它先做，再基于结果细调

我觉得 AI 协作最容易卡住的情况，就是用户一开始就想把所有要求一次说完。这样往往会导致两个问题：

1. 模型输出会发散；
2. 你自己也不知道真正要的到底是什么。

我的经验是，先让它做一个版本，然后你站在结果上提意见。因为人类对“我要什么”的判断，很多时候是在看到东西之后才突然变清楚的。

这次项目就是一个特别典型的例子：

1. 先有基础动画版；
2. 我才意识到它太像演示，不够专业；
3. 再把它推进成工作台；
4. 推进成工作台以后，又发现可以继续做 CAD 和三维；
5. 做完三维以后，又自然想到 GitHub 发布和写博客。

这就是典型的“结果驱动下一步需求”的过程。

4. 把 AI 当成执行者，不只是解答者

这是我个人特别强烈的一个感受。很多人用 AI 编程时，其实还是拿“问答模式”在用，像这样：

1. 这段代码什么意思？
2. 为什么报错？
3. 帮我写个函数。

这些当然都可以问，但如果一直停在这个层面，那 AI 的价值就被压得很低。

更高价值的方式是，把它当成一个执行者，直接给它任务：

1. 先检查当前目录；
2. 建一个完整页面；
3. 跑起来；
4. 检查报错；
5. 调整 UI；
6. 增加模型；
7. 新增文档；
8. 初始化 Git；
9. 推到仓库。

一旦你用这种方式去配合它，你会明显感觉到，它不是在“回答你”，而是在“和你一起做项目”。

如果是直接在客户端里用，我觉得最爽的地方在哪里

如果让我只选一个词来概括客户端模式的体验，我会选“顺”。

这个“顺”主要体现在几个地方：

1. 想法能直接说出来，不用先切换到代码心态；
2. 页面、浏览器、文件、模型之间切换自然；
3. 需求发散的时候，客户端比 IDE 更包容；
4. 它特别适合长对话式推进；
5. 很适合做“从想法到成品”的起步阶段。

说白了，VS Code 更像工地，客户端更像总控室。
工地当然非常重要，但总控室同样重要。

尤其是像我这次这种任务，里面既有代码，又有模型，又有文档，又有图，又有 Git。如果只放在“代码编辑器”的语境里看，它其实容易被误判成一个前端页面任务。但如果放在客户端的协作语境里，它更容易被组织成一个整体项目。

这次项目里，我最有感触的几个真实体验

1. AI 最强的不是“替我写代码”，而是“替我推进项目”

这句话我真的想强调很多遍。

如果一个人对 AI 的理解还停留在“自动补全”和“帮我生成一个函数”，那他大概率还没有真正吃到这类工具的核心红利。

我这次真正有感触的，不是某一段 JS 写得多漂亮，而是：

1. 我提出需求；
2. 它检查环境；
3. 它建文件；
4. 它验证；
5. 它根据反馈继续改；
6. 它补文档；
7. 它处理 Git；
8. 它发到 GitHub。

这是一条非常完整的链路。你很难说某一个单点特别神奇，但所有单点串起来以后，整体体验就会非常强。

2. 需求越具体，项目就越容易做得“像那么回事”

我这次项目能一步步长成现在这个样子，很大程度上不是因为我一开始就规划得多完美，而是因为我不断补了几个关键方向词：

1. 专业仿真；
2. 类似 CAE 工作台；
3. 补 CAD；
4. 补 3D；
5. 中文化；
6. 视窗做大；
7. 曲线和结果完整；
8. 最后推 GitHub。

这些词看起来不像代码，但实际上它们对最终结果的影响比很多具体代码指令还大。

3. AI 也会遇到真实工程问题，但这反而让我更信任它

比如 Git 初始化失败、权限问题、锁文件问题，这些都不是“理想环境里的干净 demo”，而是现实工程里非常常见的脏问题。

如果一个 AI 工具一遇到这种情况就只能停住，说“请用户自行处理”，那它就很难成为真正的工程搭子。

这次比较让我满意的一点就是，它至少能继续往前走：

1. 识别问题；
2. 说明卡点；
3. 请求必要确认；
4. 处理锁文件；
5. 重试 Git；
6. 最后推送成功。

这让我觉得它不是只会在最顺滑的演示环境里工作。

我会怎么建议新手开始用 Codex

如果你是第一次认真用这类工具，我的建议会非常朴素：

第一，不要一上来就拿大仓库做实验

先拿一个中小型任务，最好是你自己能判断对错的任务。比如：

1. 做一个展示页；
2. 做一个数据处理脚本；
3. 做一个简单的模型页面；
4. 做一个小型可视化项目；
5. 做一个文档和项目配套页。

因为这类任务既不至于过于简单，也不会复杂到你完全失去判断力。

第二，不要只让它“回答问题”，要让它“推进任务”

你可以少问一点“这是什么意思”，多说一点“把这个做出来”“继续改”“检查一下问题”“把它整理成能发布的状态”。

这种用法会更容易让你感受到真正的工作流价值。

第三，不要怕反复改方向

很多人担心自己提示词说得不完美，所以迟迟不敢开始。我现在反而觉得，AI 协作最自然的状态就是：

1. 先做；
2. 看结果；
3. 再细化；
4. 再重构方向。

人本来就是这样工作的。没有必要假装自己在第一句话时就已经拥有全部清晰度。

第四，学会把“主观审美”和“结构要求”都说出来

比如你不满意一个页面，不要只说“这个不好看”。你可以说：

1. 我希望它更像专业工具；
2. 我希望主视窗更大；
3. 我希望中文化；
4. 我希望按钮更明显；
5. 我希望图更细腻；
6. 我希望像某类软件的工作台。

这会极大提高修改质量。

哪些任务我觉得特别适合用 Codex

结合这次经历，我觉得下面这些任务尤其适合：

1. 从零起步的小项目；
2. 前端页面原型；
3. 可视化展示页；
4. 文档整理和说明文稿；
5. 工程 demo；
6. 小型建模和结果展示工具；
7. Git 仓库初始化和项目整理；
8. 多文件配套输出，比如页面 + README + 模型 + 图。

而下面这些任务，虽然也能做，但更适合你自己保留强控制：

1. 复杂业务规则；
2. 高风险生产系统；
3. 涉及大量历史包袱的大仓库架构调整；
4. 强依赖隐性领域知识的核心模块；
5. 对误差极端敏感的工程计算。

这不是说 AI 不能碰，而是说这些地方更适合“你主导，它辅助”。

回到最开始的问题：VS Code 还是客户端，应该怎么选

如果只让我给一句最短建议，那就是：

想法模糊、项目刚起步时，用客户端。项目已经成型、需要高频改代码时，用 VS Code。

如果再展开一点，我的实际建议是：

1. 需求梳理、项目起步、页面原型、素材组织，用客户端；
2. 多文件代码迭代、细节修复、长期维护，用 VS Code；
3. 两者不要对立，最舒服的方式其实是来回切换；
4. 浏览器、终端、Git、GitHub 联动起来以后，体验会明显上一个台阶。

也就是说，不是“哪个更高级”，而是“哪个更适合当前阶段”。

这次项目给我最大的收获

我觉得这次最重要的收获，不是我做出了一个“子弹撞木块”的页面，而是我越来越清楚一件事：

Codex 这种工具，真正值钱的地方，不在于它替你省掉了多少行代码，而在于它把“做一个完整项目”这件事的门槛拉低了。

以前很多想法停在脑子里，不是因为一点都不会，而是因为你知道要把它真正做出来，需要跨很多层：

1. 要有页面；
2. 要有逻辑；
3. 要有结构；
4. 要有图；
5. 要有模型；
6. 要有仓库；
7. 要有文档；
8. 要能发布。

这八步任何一步单独看都不算最难，但串起来就很容易拖垮执行力。

而现在，Codex 最大的意义就是它能陪着你把这些步骤一段段接起来。它不是替你消灭思考，而是替你减少中间那些最消耗意志力的断层。

所以对我来说，这次项目更像一次验证：
原来我完全可以从一个随口说出的想法出发，在 AI 的协作下，把它一路推进成一个真的能展示、能运行、能建模、能上 GitHub 的小工程。

结语：别把 Codex 只当成“会写代码的聊天框”

如果你读到这里，我最想传递的其实只有一句话：

别把 Codex 只当成一个会写代码的聊天框。

你完全可以把它当成一个能陪你从需求、到原型、到实现、到验证、到版本管理、到发布的工程搭子。前提是，你自己也要愿意从“问一个问题拿一个答案”的使用方式，切换到“提出目标、持续迭代、共同推进”的使用方式。

这次“子弹撞木块”的项目，表面上看只是一个小案例，但对我来说它很有代表性。因为它几乎把我最在意的几件事都串起来了：

1. 想法能不能快速落地；
2. 页面能不能逐步专业化；
3. 模型能不能不仅仅停留在动画；
4. 文件和资产能不能越长越完整；
5. Git 和 GitHub 能不能形成真正闭环；
6. 最后还能不能顺手再写一篇像样的博客。

答案是：可以，而且比我原来想象得顺。

如果你也在摸索 AI 编程工具到底该怎么用，我非常建议你别只拿它写一个小函数试试，而是真的找一个你自己有兴趣的小项目，哪怕规模不大，也要让它从头到尾走一遍。只要你真的走完整，你对这类工具的理解会一下子深很多。

最后，文章里提到的这次项目文件包括：

1. 动力学仿真页面 bullet_block_simulation.html
2. 三维系统预览页面 bullet_block_3d_model.html
3. CAD 工程图 bullet_block_cad_drawing.svg
4. OBJ 三维模型 bullet_block_system_model.obj
5. 材质文件 bullet_block_system_model.mtl
6. 项目仓库 https://github.com/Lenny-lab/zidanhemukuai

如果后面我继续把这个项目扩展下去，比如补更多工况、补更完整的材料模型、补更接近真实 CAE 的结果面板，我大概率还会继续用同一套工作流往下做。因为这次已经让我很确定：这不是玩具式的“试试看”，而是一套真的能把项目往前推的生产方式。

---