这次测试的对象来自我之前的 Houdini + UE PCG 项目。我从项目里选了一个模块。这个模块负责处理地块，任务边界比较清楚。输入是地块几何，输出是点数据。
我之前已经完成过这个模块，也知道自己的结果，所以可以拿它做一个 human baseline。这次我没有测试 AI 能不能回答 Houdini 问题。我想测试的是：Codex 能不能通过 computer use 操作 Houdini，并完成一个实际任务。
测试统一使用 GPT-6 Astra High。
原来的任务
我当时给自己的题目是：给定一组不规则地块，给建筑生成系统找出矩形可用空间。
输入是地块几何。输出是点。点上保存沿街宽度、深度、朝向和可用空间信息。这些数据会进入 UE5，后面的 PCG 系统会读取这些数据。
我当时的实现用了多个 Wrangle。我把计算拆开，让节点处理 point 或 primitive。不同分支之间需要对应关系，我就给数据保留 ID，后面的节点通过 ID 找回关系。这样可以减少按 parcel 执行的 For-Each。
这套方法不是标准答案，也不是唯一答案。它是我当时实际使用的方法。在这次测试里，它只承担一个作用：baseline。
我的版本执行时间在 0.2 秒到 0.3 秒之间。
测试 1：只规定输入和输出
第一轮我只给输入和输出要求，没有限制实现方式。
AI 开始接管屏幕和鼠标。它打开 Houdini，开始建立节点，也打开了 Python Shell。这个时候我已经有一点不祥的预感。
30 分钟后，它完成了第一版。这一步消耗了 5% 的 Codex 周用量。我的订阅是 Pro5x。
第一版使用了 Python。output0 基本满足要求。output1 有问题，无效地块没有正确输出，它输出了所有地块的顶点。
我让它修改。第二次修改用了 6 分钟，消耗了 2% 的周用量，结果基本符合要求。
然后我重新 Cook。问题出现了。单独计算 building rectangles 就需要接近两分钟。这个速度无法用于我的工作流，所以第一轮测试到这里停止。
第一轮总耗时是 36 分钟，总用量是 7%。
测试 2：禁止 Python
第二轮重新开始。这次我加入了一条限制：禁止 Python。
我把这条要求写得很明确。AI 这次没有打开 Python Shell，而是开始使用 Wrangle 和 VEX。
22 分钟后，它完成了第一版。这一步消耗了 3% 的周用量。功能可以工作，实现方式也符合我的要求。
接下来测试性能。Performance Monitor 显示，这个版本需要约 20 秒。这个结果仍然离我的需求很远。我的版本需要约 0.2 秒到 0.3 秒。
我继续给它一个目标：执行时间控制在 1 秒以内。 我允许一定的精度损失。
AI 开始修改自己的方案。这次用了 27 分钟，消耗了 7% 的周用量。结果降到了 0.68 秒。这个数字已经可以接受。
第二轮总耗时是 49 分钟，总用量是 10%。这一轮也让我第一次感受到用量的压力。一次修改就用了 7% 的周额度。
测试 3：给 AI 我的逻辑图
第三轮继续测试。这次我改变输入。除了任务要求，我还把自己的算法逻辑图交给了 AI。
我想看看一件事：如果 AI 知道我的思路，它会不会得到另一种结果。
27 分钟后，它完成了第一版。这一步消耗了 4% 的周用量。
然后我测试性能，结果是 35 秒。这个数字比测试 2 的第一版还高。
我继续让它优化，目标还是 1 秒以内。我也允许一定的精度损失。
修改过程中，Houdini 发生了一次崩溃。AI 识别到了崩溃，重新启动 Houdini，然后继续执行任务。
26 分钟后，优化完成。这一步消耗了 5% 的周用量。最后的执行时间是 0.85 秒左右。
第三轮总耗时是 53 分钟，总用量是 9%。
数据
三轮测试的数据如下。
测试实现方式初版性能优化后时间周用量
数据
Human baseline：Wrangle / VEX。执行时间约 0.2–0.3 秒。
Test 1：Python。初版执行时间约 120 秒。总耗时 36 分钟。周用量 7%。
Test 2：Wrangle / VEX。初版执行时间约 20 秒。优化后约 0.68 秒。总耗时 49 分钟。周用量 10%。
Test 3：参考我的逻辑图。初版执行时间约 35 秒。优化后约 0.85 秒。总耗时 53 分钟。周用量 9%。
三轮一共消耗了约 26% 的周用量。对于这个任务，我没有继续测试。
一些感受
GPT-6 Astra 的 computer use 可以完成任务。它可以操作 Houdini，可以建立和修改节点，也可以检查结果。Houdini 崩溃后，它也可以识别状态，重新启动程序，然后继续任务。这部分给我的感受很好。
第二个感受来自任务边界。AI 会选择自己的实现方式。第一轮没有限制，它直接选择了 Python。Python 本身没有问题。我在这个任务里更关注执行时间，所以加入限制以后，它开始使用 Wrangle 和 VEX。
性能目标也是一样。我没有规定性能时，第二轮的结果需要 20 秒。我给出 1 秒目标后，它把时间降到了 0.68 秒。所以很多要求需要写进任务。
第三个感受来自成本。后两轮测试平均消耗了约 9.5% 的周用量。这个成本不小。一个测试里还可能包含多次修改。任务规模增加以后，用量也可能继续增加。
这次测试的任务不复杂。输入和输出都比较集中。它没有测试长节点网络，也没有测试跨模块依赖，更没有测试 Houdini 和 Unreal 之间的完整流程。
这些问题需要新的测试。这次先到这里。
This test comes from my previous Houdini + UE PCG project.
I picked one module from the project. This module processes land parcels. The task has a clear boundary. The input is parcel geometry. The output is point data.
I had already built this module before. I also knew the result of my own implementation. So I could use it as a human baseline.
This test was not about whether AI can answer Houdini questions. I wanted to test something else:
Can Codex use computer use to operate Houdini and finish a real task?
I used GPT-6 Astra High for all tests.
The Original Task
I gave myself this task:
Given a group of irregular parcels, find a rectangular usable area for the building generation system.
The input is parcel geometry. The output is a point.
The point stores the street-facing width, depth, orientation, and usable area data. These values go into UE5. The later PCG system reads this data.
My original implementation used multiple Wrangles.
I split the calculation into several steps. Each node processes points or primitives. Different branches need to keep their relationships. I used ID attributes for this. Later nodes use these IDs to match the data again.
This also reduces the need for a For-Each loop for every parcel.
This is not the standard solution. It is not the only solution. It is simply the method I used in the project.
In this test, it works as a human baseline.
My version takes about 0.2 to 0.3 seconds to run.
Test 1: Only Define the Input and Output
In the first test, I only defined the input and output.
I did not limit the implementation method.
The AI took control of the screen and mouse. It opened Houdini and started building the setup. It also opened the Python Shell.
At this point, I already had a bad feeling.
After 30 minutes, it finished the first version. This used 5% of my weekly Codex allowance. My subscription is Pro5x.
The first version used Python.
output0 was mostly correct. output1 had a problem. It was supposed to contain invalid parcels. Instead, it contained the vertices of all parcels.
I asked it to fix the problem.
The revision took 6 minutes. It used another 2% of the weekly allowance. The result was mostly correct.
Then I cooked the network again.
The performance was the main problem.
The building rectangle calculation alone took almost two minutes. This was not usable for my workflow.
I stopped Test 1 here.
The total time was 36 minutes. The total usage was 7%.
Test 2: No Python
I restarted the task for Test 2.
This time, I added one rule:
Do not use Python.
I made this rule explicit.
The AI did not open the Python Shell this time. It used Wrangles and VEX instead.
After 22 minutes, it finished the first version. This used 3% of my weekly allowance.
The result worked. The implementation also followed my rule.
Then I tested the performance.
Performance Monitor showed about 20 seconds.
This was still far from what I wanted. My own version takes about 0.2 to 0.3 seconds.
I gave the AI another goal:
Reduce the execution time to less than one second.
I allowed some loss of precision.
The AI started to optimize its own solution.
The optimization took 27 minutes. It used 7% of my weekly allowance.
The final execution time was 0.68 seconds.
This was acceptable for me.
Test 2 took 49 minutes in total. It used 10% of my weekly allowance.
This was also the point where I started to notice the cost. One optimization step alone used 7% of the weekly allowance.
Test 3: Give the AI My Logic Diagram
I changed the input again for Test 3.
This time, I gave the AI my own logic diagram together with the task description.
I wanted to see what would happen if the AI knew my original approach.
After 27 minutes, it finished the first version. This used 4% of my weekly allowance.
Then I tested the performance.
The result took 35 seconds.
This was slower than the first version from Test 2.
I asked it to optimize again. The goal was still less than one second. I also allowed some loss of precision.
Houdini crashed during the revision.
The AI detected the crash. It restarted Houdini and continued the task.
The revision took 26 minutes. It used 5% of my weekly allowance.
The final execution time was about 0.85 seconds.
Test 3 took 53 minutes in total. It used 9% of my weekly allowance.
Results
Human baseline: Wrangle / VEX. Execution time was about 0.2–0.3 seconds.
Test 1: Python. Execution time was about 120 seconds. Total working time was 36 minutes. Weekly usage was 7%.
Test 2: Wrangle / VEX. The first version took about 20 seconds. The optimized version took about 0.68 seconds. Total working time was 49 minutes. Weekly usage was 10%.
Test 3: The AI received my logic diagram. The first version took about 35 seconds. The optimized version took about 0.85 seconds. Total working time was 53 minutes. Weekly usage was 9%.
The three tests used about 26% of my weekly allowance.
I stopped testing this task after that.
Some Thoughts
GPT-6 Astra can use computer use to finish the task.
It can operate Houdini. It can create nodes and modify them. It can also check the result.
It can recover from some problems. Houdini crashed once during the test. The AI noticed the crash, restarted the program, and continued the task.
My second impression was about task boundaries.
The AI tends to use the method it prefers.
In Test 1, I did not limit the method. It used Python.
There is nothing wrong with Python. I simply wanted faster execution for this task.
After I added the restriction, it used Wrangles and VEX.
The same thing happened with performance.
Without a performance target, the first VEX version took 20 seconds. After I gave it a one-second target, it reduced the time to 0.68 seconds.
So some requirements need to be written into the task.
My third impression was about cost.
Tests 2 and 3 used about 9.5% of my weekly allowance on average.
That is not a small amount for me.
One test can also need several revisions. A larger task may need more usage.
This task was not complex. The input and output were both concentrated.
It did not test a long node network. It did not test dependencies between several modules. It also did not test a full Houdini-to-Unreal workflow.
Those cases need more testing.
This test stops here.