Having AI Deliver a 3D Narrative Website on Its Own: A Complete Practice from Requirements to a Runnable Deliverable

1. Experiment Background and Goal Setting

Code generation is where large language models are already fairly mature, but whether a model can independently carry a full project to completion — one that requires aesthetic judgment, technology selection, and a mandatory runnable deliverable — remains a meaningful benchmark of engineering readiness. That question was the starting point of this hands-on test of Kimi K3.1 Pro: give the model an open-ended creative task and observe how it performs across the entire process, from concept to final delivery.

The task: build a Chinese-language interactive website that explains to a general audience how the David statue is progressively “subtracted” out of raw stone. The brief was deliberately open — narrative angle, visual style, interaction model, and technical stack were all left for the model to decide. Only three constraints were imposed: after viewing, the audience should come away with a new understanding of carving as a subtractive process; they should be willing to slow down and observe the details of the work; and the deliverable had to be runnable and experienceable, not stop at the plan or mockup stage.

The value of this setup is that it tests four capabilities at once: organizing domain knowledge, making interaction design judgments, choosing frontend and 3D technologies, and — most important — closing the loop on engineering delivery.

2. Technical Route and Asset Strategy

2.1 Sourcing and Licensing 3D Assets

The core asset of a sculpture-focused 3D narrative site is a high-precision model. The common practice is to use models from open cultural-heritage scanning projects, which are typically published under Creative Commons licenses that require attribution and share-alike terms. In practice, three points deserve attention:

• License verification: confirm whether the model permits commercial or non-commercial use, whether attribution is required, and whether derivatives are allowed;
• File format and size: STL and GLB are the common formats, and raw scans carry high polygon counts that need decimation;
• Loading performance: for web delivery, convert to a compression-friendly format and pair it with progressive loading.

The asset processing pipeline can be summarized as:

Raw scan model (high polygon count)
   → Mesh simplification (preserve silhouette features)
   → Format conversion (compression-friendly web format)
   → Texture/normal baking (optional)
   → Chunked loading + first-screen placeholder

2.2 Choosing a Frontend 3D Rendering Approach

Web-based 3D rendering is usually built on WebGL wrapper libraries, and the choice involves trade-offs among bundle size, material quality, and interactivity. For a “single sculpture + layer-by-layer removal” scenario, the key requirement is localized mesh visibility and staged animation, not complex lighting. Viable approaches include:

• Splitting the model by height or region into mesh groups, and controlling each group’s visibility to reveal the sculpture layer by layer;
• Using a clipping plane that advances along a single axis to simulate stone being removed in layers;
• Adding particle or debris animation to reinforce the physical feel of chiseling.

Illustrative code for the clipping-plane approach is shown below. The core idea is a dynamically updated plane parameter that controls the visible region:

// Pseudocode: peel the stone from bottom to top along the Y axis
const clipPlane = new THREE.Plane(new THREE.Vector3(0, -1, 0), 0);
renderer.clippingPlanes = [clipPlane];
function onChisel(progress) {
  // progress goes from 0 to 1; the plane constant advances with it
  clipPlane.constant = modelHeight * progress;
  renderer.render(scene, camera);
}

This approach is cheap to implement and gives direct visual feedback, which suits the “press and hold to chisel” interaction metaphor. Its limitation is that the clipped edge is too clean — it lacks the roughness of real chisel marks — which can be compensated for with noise perturbation or debris particles.

3. Comparing Two Narrative Structures

The experiment produced two very different implementations, which happen to represent two typical paths for 3D narrative websites.

3.1 The Immersive “Subtractive” Path

The first distills the narrative into a philosophical proposition: the finished work is “what remains” of the stone. The page is staged as a dark room with the raw stone standing at the center; pressing and holding a button triggers layer-by-layer removal, and the sculpture’s silhouette gradually emerges. The pacing emphasizes instant feedback and a controllable process — the interaction itself replaces textual lecturing.

The highlight is that a single interactive action carries the entire narrative: the user is not “reading about” the carving process, they are “performing” it. One detail is particularly clever: the interface includes an “Undo” button, and clicking it responds with “Stone has no undo key.” The design turns a technical limitation into narrative expression and reinforces the irreversibility of subtractive creation.

From an engineering perspective, the key implementation points are lighting contrast in the dark environment, easing curves for the removal progress, and a unified abstraction over mobile touch events and desktop mouse events.

3.2 The Exhibition Catalog Path

The second implementation adopts an exhibition-catalog style of information architecture: a light paper-toned background, chaptered sections, and a slider that moves the stone from a raw block to the finished form. The narrative center of gravity shifts from “operating” to “observing,” which suits viewers who want to closely compare how the shape changes.

The technical crux is the linear mapping and state synchronization between the slider and the model: slider values must map reliably to removal progress, and dragging backward must restore the model correctly. The recommended implementation is to parameterize the removal process as a single scalar, from which every visual representation is derived, so states cannot drift out of sync:

// A single source of truth for state
const state = { carveProgress: 0 };
function applyState() {
  // All visual output derives from carveProgress
  updateClipPlane(state.carveProgress);
  updateParticles(state.carveProgress);
  updateCaption(state.carveProgress); // chapter captions switch with progress
}

The two paths are not mutually exclusive. In practice, “precise slider control” and “press-and-hold fast removal” can be combined to serve both close observation and immediate experience.

4. From Website to Video: Extending into Multimodal Delivery

After the website was delivered, the model was further asked to produce a 60–90 second vertical short video, in Chinese, to introduce the essence of the site to a general audience and spark further interest. This stage tests asset reuse and cross-modal recomposition: the model, scenes, animations, and copy from the website can all serve as video material, but a video needs its own camera language and pacing.

The key constraints for this kind of task include:

• Aspect ratio and duration: 9:16 vertical, 60–90 seconds, with a visual hook inside the first 3 seconds;
• Narrative compression: compress the “subtractive” concept into a sequence of visualized actions;
• Editable delivery: beyond the final cut, provide the project files and a list of asset sources so the video can be revised later;
• Pre-delivery self-check: actually play the video before handing it over, and fix obvious issues such as black frames, audio-video desynchronization, or subtitles overflowing the frame.

From an engineering-management standpoint, video generation should be treated as an independent pipeline rather than being coupled with website development. It pays to structure the reusable assets early in the project — model chunks, removal animation keyframes, color schemes — so cross-modal reuse stays cheap.

5. Key Findings and Engineering Lessons

5.1 Balancing Capability and Cost

During the experiment, stronger models were lively at the ideation stage and could propose valuable narrative angles and interaction metaphors, but on long-chain tasks they tended to start strong and finish weak — complete plans, incomplete delivery. Optimized variants, by contrast, showed clear improvements in response speed and invocation cost, making them better suited to engineering tasks that need multiple rounds of iteration.

This leads to a general conclusion: creative tasks and delivery tasks ask different things of a model. The former rewards divergence and judgment; the latter rewards stability, context retention, and error self-repair. In real projects, split the work and match each stage to the appropriate cost tier.

5.2 Task Decomposition Is the Key to Delivery Success

Asking a model to do “research + design + coding + asset processing + integration + self-check” in a single prompt creates an excessively long chain, and any failed link makes the whole deliverable non-runnable. A more dependable practice is to explicitly split the work into verifiable stages:

Stage	Deliverable	Acceptance Criteria
Asset preparation	Simplified model file	Controlled polygon count, loads correctly
Rendering skeleton	A rotatable 3D scene	Placeholder appears within 3 seconds of first render
Interaction layer	Removal progress control logic	Consistent state in forward and reverse operation
Narrative layer	Chapter copy and effects	Strictly synchronized with progress
Self-check	Multi-device verification records	No obvious performance or display issues

Accepting each stage independently substantially reduces the risk that the final deliverable won’t run.

5.3 Performance and Compatibility Cannot Be Ignored

How a 3D site behaves on mobile is a common blind spot. Practical recommendations:

• Raw scan models must be decimated; on mobile, keep them in the tens-of-thousands-of-polygons range;
• Use a low-poly placeholder on first load, and load the refined model after interaction begins;
• Provide a static-image fallback for environments without WebGL support;
• Listen for page visibility changes and pause the render loop when the page goes to the background to reduce power consumption.

6. Conclusion

This experiment shows that AI has the potential to independently deliver a 3D interactive website with aesthetic judgment. Whether it can reliably deliver a runnable result, however, depends on the granularity of task decomposition, compliant handling of assets, and the design of staged acceptance mechanisms. On the technical side, subtractive interaction built on clipping planes or mesh grouping is cheap to implement and highly expressive, making it the preferred choice for this kind of subject. On the narrative side, immersive operation and exhibition-style observation each have their place, and they can be combined.

For developers, the pragmatic posture is to treat AI as “a high-output collaborator that still needs managing”: constrain its output with clearly staged deliverables, support cross-modal reuse with structured assets, and safeguard quality with self-checks on real devices. That is how creative ideas reliably land as experienceable products.