IndieNests

March 15, 2025

Bolt 修改时重新生成整个文件有很大的问题

随着项目越来越大，每次修改都会不可控，提示词无法准确描述需要修改的部分，就会频繁出错

这个提示会创建项目的时候就新建一个项目地图，然后每次输入提示词的时候先去让 Claude 润色提示词

能大幅减少 Bolt Token 消耗和改错代码的问题

完整提示逻辑：

在开发一个复杂项目时,我将 bolt.new 的令牌使用量减少了70%!(背景:我当前的项目有35页产品需求文档和16个数据库表)

从:每3-4个提示词消耗100万令牌
到:同样100万令牌现在可以处理10-12个提示词

根据我使用 bolt.new 的经验,成功的关键在于精确的问题解决能力 – 准确知道哪里出了问题。作为开发者在这方面更有优势,因为更容易定位和修复问题。但如果你像我一样是非开发人员,我发现将 Claude 设置为你的”软件架构师”是实现这种精确性的关键。

在我之前关于详细功能需求文档(FRD)建议的基础上,以下是我开发的结构化系统:

Bolt 中的文件和文件夹结构:
从文件结构图开始。我让 bolt 创建一个”fileNames.md”,列出每个文件并维护文件夹层次结构。每个条目都包含组件用途和功能的单行描述。这成为了我们项目的地图。

Claude 项目:
在 Claude 中设置专门的”问题解决”项目。我专门创建了一个 Claude 项目来处理修复和更新。在项目知识中,我添加了:

简化的问题解决流程:
对于每个修复或新功能,我都会访问这个 Claude 项目并使用特定的提示结构。以下是我的工作流程:

这种描述问题/功能的特定格式有助于 Claude 为 bolt.new 编写优化的提示,识别相关文件,并建议最节省令牌的方法,甚至为你提供修复问题的具体步骤。

使用 .bolt/ignore:
我与 Claude 合作识别不需要在 LLM 上下文中的文件,并将它们添加到 .bolt/ignore。这显著减少了令牌使用量,同时保持开发效率。注意根据修复内容的不同,我们需要多次执行此操作。

结果如何?
我实际上创建了一个两层系统:

这种方法改变了我的开发流程。我不会陷入令牌限制或不清晰的提示中,而是可以专注于构建和改进功能。

是的,初始设置需要时间。是的,你会遇到令牌限制和错误循环的挑战。但在事情变得复杂时放弃就意味着错过了 bolt.new 真正的潜力。这种结构通过减少令牌使用和更清晰的开发路径证明了其价值。

stackblitz 已经在以闪电般的速度发布功能和优化 – 我们只需要找到解决大多数问题的方法。