一周737星的Tidewater：一座靠AI写出来的海边小镇，藏着什么

先说结论

Tidewater不是普通的三维场景Demo，它是一个用Anthropic Opus 5.5一次写出来的完整海边小镇，开源一周就在GitHub上拿到了737颗星。JavaScript生态里，能在如此短时间内冲到这种热度的项目极少，更别说它本质上是一份“AI一次性写代码”的演示。

它火的原因不复杂：以前AI只能写代码片段，这次它写出了能跑、能交互、还挺好看的完整世界。视觉冲击力直接拉满。

真正的问题

仔细看仓库和讨论，会发现争议点其实不在“AI能不能写代码”。代码生成早就是Claude、GPT、Cursor的常规动作了。真正让大家停下来说两句的，是下面三件事：

第一，一次性生成的质量边界到底在哪。Tidewater的代码、贴图、海岸线逻辑看上去都到位，但一旦你想加一个新建筑、改一套UI、扩展一种天气系统，AI原生的代码结构能不能撑住？这决定了它到底是个Demo，还是能继续长的项目。

第二，生成的资产能不能商用。Repo主要语言是JavaScript，但里面大概率还混着AI生成的贴图、模型和着色器。这些素材在不同协议下的授权情况差异很大，开发者拿去做自己项目时，许可证一栏不能含糊。

第三，它究竟证明了模型的能力，还是验证了提示词工程的价值。同样是Opus 5.5，给一个拆解得很细的提纲，和丢一个模糊需求，出来的成品会差出几个量级。Tidewater背后那份提示词，可能比模型本身更值得研究。

怎么做更省力

对普通内容创作者和开发者来说，与其盯着“AI写了一座镇”这个结果，不如把它的方法论拆出来用。下面这套流程可以马上试：

1。 先定视觉锚点。在动键盘之前，先写清楚场景的氛围、镜头语言、配色范围和参考风格。两到三段文字就够，但必须写。 2。 拆需求，不堆需求。把“一座海边小镇”拆成地形、建筑、灯光、交互四个模块，每个模块单独写提示词，最后再让AI汇总。一次喂太杂是质量崩盘的常见原因。 3。 锁定模型版本。Opus 5.5的能力不能简单套到别的模型上。复刻这个工作流，第一步就是固定模型，否则就是拿不同厂商的尺子量同一块布。 4。 保留人工修订环节。AI写的代码要跑、要改、要重构，必须留出Review时间。把它当一个能力很强的初级程序员，而不是独立交付的承包商。

这一步如果不想自己写提纲，可以用需求拆解专家把模糊想法拆成场景、任务和验收标准；要是准备把这个过程写成公众号教程，再丢给公众号AI排版编辑器精排一下，会省下不少排版功夫。

哪些坑要避开

• 把Demo当生产力。一次性生成好看，不代表可维护。准备接手二次开发前，先评估模块解耦程度。
• 忽略协议风险。AI生成的贴图、模型、代码段，商用前逐项核对授权，别只看仓库主协议。
• 盲目复制提示词。别人的提示词是为他的项目调过的，直接套到自己场景大概率水土不服。
• 追热度代替做产品。737星这个数字很亮眼，但它只说明关注度，不等于生产可用。

现在就能动手

打开仓库https://github.com/dgreenheck/tidewater，先跑一遍Demo，感受一下"AI写出来的世界"到底长什么样。然后做三件事：把项目结构截图保存，把视觉锚点写下来，再用上面那四步流程复刻一个小得多的场景，比如一间咖啡馆或一段栈道。

跑通之后，你就拥有了一份属于自己的“AI生成式3D工作流”，比单纯收藏又一个Star仓库有用得多。