AIプログラミングツールのトークン消費とタスク実行エラーを削減するために、プロジェクトドキュメントとコード実行タスクのプロンプトを生成します。

オリジナル・プロジェクト文書のプロンプト・ワードを書く

You are my software architect. You will help me write down specific user stories and **functional requirements** based on the project description. Do not provide code.

We will be using a tool called bolt.new - to build this entire project. Imagine bolt.new to be like an LLM - where you give instructions to it, and it will write the code for you.




I need you to be my software architect and help me **write down all functional requirements**. This document will be sent to bolt (an LLM which will write code), so you have to be specific about the functional requirements.

Try to write the requirements as detailed as possible, but if it exceeds 200 words, then split it further into multiple functional requirements (so that you don't overwhelm the LLM).

You should **write only functional requirements** and not include the tech stack needed.

プロジェクト・ドキュメンテーション用のプロンプト・ワードの翻訳を書く

你是我的软件架构师。你将根据项目描述帮助我编写具体的用户故事和**功能需求**。不要提供代码。

我们将使用一个名为 bolt.new 的工具来构建整个项目。可以将 bolt.new 想象成一个大语言模型（LLM）——你向它提供指令，它会为你编写代码。

我需要你担任我的软件架构师，帮助我**编写所有功能需求**。该文档将发送给 bolt（一个会编写代码的 LLM），因此你必须明确具体的功能需求。

尝试尽可能详细地编写需求，但如果超过 200 个单词，请进一步拆分为多个功能需求（以免让 LLM 过于负担）。

你应该**只编写功能需求**，而不要包括所需的技术栈。

コード作成タスクのリマインダーの原文を実行する。

## Project Overview

I've uploaded the project file structure in project knowledge - this is what we've built so far. I need you to go through it and understand the complete flow, based on the functional requirements document also uploaded to project knowledge.

## Functional Requirements Components

I have also added the different components of the Functional Requirements into separate files, for you to have more context:
- `<component 1>`
- `<component 2>`
- `<component 3>`

## Development Environment

I am working with `bolt.new` (which is like an LLM which writes the code and executes based on prompts that I give).

## Current Version and Next Steps

I have built the first version of the `<your product>`. Here's what we need to do now:
- [Describe the issue you're facing, or the new functionality you'd want to implement]

## Important Notes

Especially if you're a non-dev and struggle to pinpoint which file causes the issue, in a large project:

Please tell me which files do you need the code to review, from the project structure. I need you to ask me all the info you need, to be able to fix this. We do not want to add new features - we should just fix this issue alone. You need to do a code review and fix the existing implementation, use the current structure, variables used and then tell me how to fix this.

コードライティング・タスクを実行するためのプロンプトの翻訳

## 项目概述

我已将项目文件结构上传到项目知识中——这是我们目前构建的内容。我需要你浏览它并根据上传到项目知识中的功能需求文档，理解完整的流程。

## 功能需求组件

我还将功能需求的不同组件分成了单独的文件，以便你获得更多上下文：
- `<组件 1>`
- `<组件 2>`
- `<组件 3>`

## 开发环境

我正在使用 `bolt.new`（类似于一个根据我提供的提示生成代码并执行的 LLM）。

## 当前版本和下一步工作

我已经构建了 `<你的产品>` 的第一个版本。以下是我们现在需要完成的任务：
- [描述你遇到的问题，或者需要实现的新功能]

## 重要说明

特别是当你不是开发人员并且在大型项目中难以确定哪个文件导致问题时：

请告诉我你需要查看哪些文件中的代码（根据项目结构）。我需要你询问所有需要的信息，以便解决这个问题。我们不想添加新功能——我们只需要解决这个问题。你需要进行代码审查并修复现有实现，使用当前的结构和所用的变量，然后告诉我如何修复此问题。

使用方法

http://bolt.new ヒント
複雑なプロジェクトを作るときは、http://bolt.new トークン 使用量は70%減少した（背景：私の現在のプロジェクトには35ページのPRDと16のデータベーステーブルがある）！
From: 1M トークン 加工 3-4 ヒント
To:同じ1Mトークンで10～12チップを扱えるようになった！

私の経験では、http://bolt.new、実装を成功させる鍵は的確な問題解決、つまり何が問題で、どうすれば解決できるかを正確に知ることだ。開発者であれば、問題を特定し、それを修正することが容易であるため、この能力は向上する。しかし、もしあなたが私のような非開発者であるなら、それは次のようになることがわかりました。 クロード ソフトウェア・アーキテクト」を設定することが、このレベルの精度を達成する鍵である。

詳細なFRD（機能要件文書）に関する前回のヒントを基に、私が開発した構造化システムを紹介しよう：

Boltのファイルとフォルダ構造

まずはファイル構成表から。私はボルトに、各ファイルをリストアップし、フォルダ階層を維持する「http://fileNames.md」を作らせた。各エントリには、そのコンポーネントの目的と機能を1行で説明しています。これが私たちのプロジェクトの地図となった。

クロード・プロジェクト

クロードに "問題解決 "専用プロジェクトを立ち上げる。修正とアップデートを処理するために、専用のクロード・プロジェクトを作成した。プロジェクト・ナレッジに

• 完全なファイル構造（http://fileNames.md より）
• 主な機能要件文書
• コンポーネント別FRD（ユーザーフローに基づく）
• http://bolt.new の機能を説明する文書

問題解決を合理化する：

修正や新機能のたびに、私はこのクロード・プロジェクトに入り、特定のプロンプト構造を使う。これが私のワークフローだ：

• まず、"System Tip "でコンテクストを設定した。
• そして、それぞれの修正／機能リクエストに対して、「実行プロンプト」を使う。<つのプロンプトの書式は以下の通りです。

私が問題/機能を説明するために使用する特定のフォーマットは、クロードがhttp://bolt.new、関連するファイルを特定し、最もトークンを節約するアプローチを提案し、さらには問題を解決するための具体的な手順を提供するために最適化されたヒントを書くのに役立ちます。

.bolt/ignoreを使用：

私はクロードと協力して、LLMコンテキストにある必要のないファイルを特定し、それらを.bolt/ignoreに追加した。これにより、開発効率を維持しながら、トークンの使用量を大幅に減らすことができました。修正する内容によっては、この作業を何度も行う必要があることに注意してください。

結果は？

私は実際に2層のシステムを作った：

• クロードは「ソフトウェア・アーキテクト」として問題を分析し、解決策を設計する。
• http://bolt.new 「開発者」となり、これらのソリューションを効率的に実装する！

このアプローチは、私の開発プロセスに革命をもたらした。トークンの制限や不明確なプロンプトにとらわれることなく、機能の構築と改善に集中できる。

はい、初期設定には時間がかかります。トークンの制限やエラー・ループに悩まされることもあるだろう。しかし、物事が複雑になったときにあきらめることを選択することは、http://bolt.new の真の可能性を見逃していることになる。この構造は、トークンの使用量を減らし、開発の道筋を明確にするという点で価値があります。

スタックブリッツ
機能や最適化はすでに猛烈なスピードでリリースされており、必要なのはほとんどの問題の解決策を見つけることだけだ。

あなたのプロジェクトにこの方法を導入したい場合、または説明が必要な場合は、返信またはプライベート・メッセージでお気軽にお問い合わせください。

追伸：今でも時々、このセットアップのビデオを作るべきかどうか悩むことがある。もし参考になるようでしたら教えてください。