这就是我对氛围编码的感觉。 我尝试的任何有复杂性的项目都会立即出现进展的爆发。事情很棒，感觉就像一种超能力。然后……随着我增加更多复杂性，事情就会停滞不前。 我认为我能创建的唯一项目是那些落在这个“氛围区”的项目。原型、用户界面、产品——任何简单且复杂性低的东西都恰好适合这个区域。概念验证、交互、类似的东西。工具能够制作适合这个位置的东西。 但是。 随着复杂性曲线的增加，一切都崩溃了。问题是，任何好的产品设计过程都有不断增加的复杂性。一个基本原型一旦有了分层交互、过渡、良好的可用性、悬停状态，以及1000个让某物感觉正确和真实的小细节，就会变成一个好的原型。 氛围编码的好处应该是你可以快速移动，可以快速制作东西——让人工智能为你做所有的工作。问题是，一旦添加了必要的复杂性，它就失去了动力。它不断自我重做，重写代码，影响无关的事物，然后导致其他问题。 但是如果你添加了复杂性，每次氛围编码的会话很快就变成了打地鼠的错误修复会话。 我不确定解决方案是什么。对于传统原型设计，解决方案是复制、增加更多复杂性、创建更多框架/场景、调整、分叉等。 然而对于氛围编码，一个小提示可以字面上摧毁一切。有一个阶段，我最终不得不小心翼翼地走在提示的鸡蛋壳上——尽量不给它太多或太少的上下文，以免它失控并破坏一切。 对此只有少数例外。@cursor 和 @framer。 我可以在 Cursor 上取得很大进展，给它狭窄的上下文，并且我必须批准它所做的编辑。这感觉像是一个正确的工作流程。问题是，我看不到它正在制作的东西，因为它是一个集成开发环境，而不是一个可视化环境。是的，我可以创建本地构建并刷新我的浏览器，做所有这些事情。但可视化方面在编码体验中完全丢失了。这是一个开发者工具。 Framer 做得很好，因为它只允许在页面上的单个组件内进行狭窄的更新。是的，这很有限，因为它一次只能做一件事，但至少它不是试图从头开始创建整个页面并通过提示界面管理它。 这些似乎是正确的方法。 @Cursor：允许人工智能编辑任何内容，但允许用户批准这些编辑并在上下文中查看它们。 @Framer：允许人工智能仅狭窄地编辑单个文件或组件，以将复杂性降到最低并减少灾难性编辑。 我对像 @Figma、@Lovable、@Bolt 和 @V0 这样的工具能够制作酷炫原型感到乐观，但当涉及到做任何超出基本交互原型的事情时，我总是遇到障碍。在我看来，它们需要做得更少。 希望这些工具增加更多与 Cursor 和 Framer 相同方向的控制。我还要补充的是，这与我们在 @Basedash 图表生成中所做的类似。但我们并不是通常意义上的氛围工具，因此类比有点难以绘制。