@aigne/doc-smith 0.8.12-beta.5 → 0.8.12-beta.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.aigne/doc-smith/history.yaml +37 -0
- package/.aigne/doc-smith/preferences.yml +12 -0
- package/.aigne/doc-smith/upload-cache.yaml +30 -0
- package/.release-please-manifest.json +1 -1
- package/CHANGELOG.md +19 -0
- package/agents/generate/update-document-structure.yaml +9 -3
- package/agents/history/view.mjs +5 -2
- package/agents/publish/publish-docs.mjs +12 -10
- package/agents/update/generate-document.yaml +10 -4
- package/agents/update/update-document-detail.yaml +9 -3
- package/agents/update/user-review-document.mjs +2 -1
- package/docs/guides-cleaning-up.ja.md +16 -15
- package/docs/guides-cleaning-up.md +5 -4
- package/docs/guides-cleaning-up.zh-TW.md +16 -15
- package/docs/guides-cleaning-up.zh.md +12 -11
- package/docs/guides-generating-documentation.ja.md +34 -32
- package/docs/guides-generating-documentation.md +15 -13
- package/docs/guides-generating-documentation.zh-TW.md +34 -32
- package/docs/guides-generating-documentation.zh.md +30 -28
- package/docs/guides-managing-history.ja.md +17 -20
- package/docs/guides-managing-history.md +5 -8
- package/docs/guides-managing-history.zh-TW.md +18 -21
- package/docs/guides-managing-history.zh.md +13 -16
- package/docs/guides-translating-documentation.ja.md +17 -17
- package/docs/guides-translating-documentation.md +1 -1
- package/docs/guides-translating-documentation.zh-TW.md +21 -21
- package/docs/guides-translating-documentation.zh.md +18 -18
- package/docs/guides-updating-documentation.ja.md +35 -35
- package/docs/guides-updating-documentation.md +4 -4
- package/docs/guides-updating-documentation.zh-TW.md +27 -27
- package/docs/guides-updating-documentation.zh.md +26 -26
- package/docs/overview.ja.md +13 -13
- package/docs/overview.md +1 -1
- package/docs/overview.zh-TW.md +19 -19
- package/docs/overview.zh.md +16 -16
- package/package.json +1 -1
- package/prompts/common/afs/afs-tools-usage.md +5 -0
- package/prompts/common/afs/use-afs-instruction.md +1 -0
- package/prompts/detail/generate/system-prompt.md +0 -13
- package/prompts/detail/generate/user-prompt.md +7 -0
- package/prompts/detail/update/system-prompt.md +1 -2
- package/prompts/detail/update/user-prompt.md +7 -0
- package/prompts/structure/generate/system-prompt.md +0 -19
- package/prompts/structure/generate/user-prompt.md +22 -1
- package/prompts/structure/update/system-prompt.md +0 -17
- package/prompts/structure/update/user-prompt.md +24 -0
- package/tests/agents/history/view.test.mjs +97 -0
- package/tests/agents/publish/publish-docs.test.mjs +0 -33
- package/tests/utils/history-utils.test.mjs +125 -97
- package/utils/auth-utils.mjs +2 -2
- package/utils/file-utils.mjs +1 -1
- package/utils/history-utils.mjs +3 -3
- package/agents/update/fs-tools/glob.mjs +0 -184
- package/agents/update/fs-tools/grep.mjs +0 -317
- package/agents/update/fs-tools/read-file.mjs +0 -309
- package/tests/agents/update/fs-tools/glob.test.mjs +0 -438
- package/tests/agents/update/fs-tools/grep.test.mjs +0 -279
- package/tests/agents/update/fs-tools/read-file.test.mjs +0 -549
|
@@ -1,76 +1,76 @@
|
|
|
1
1
|
# 更新文档
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
维护文档的准确性和相关性是一个持续的过程。随着代码库的演进或收到新的反馈,您将需要修改现有文档。`update` 命令提供了一种结构化的方式,可以用新的指令重新生成特定文档,确保其保持最新。
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
本指南将解释更新文档的两种主要方法:用于对单个文档进行详细优化的交互模式,以及用于一次性将变更应用于多个文档的批处理模式。
|
|
6
6
|
|
|
7
7
|
## 两种操作模式
|
|
8
8
|
|
|
9
|
-
`update`
|
|
9
|
+
`update` 命令根据您选择的文档数量和提供的选项,在两种模式之一中运行。
|
|
10
10
|
|
|
11
|
-
1.
|
|
12
|
-
2.
|
|
11
|
+
1. **交互模式**:当您更新单个文档且未使用 `--reset` 标志时触发。此模式专为迭代优化而设计,允许您提供反馈、审查变更并重复此过程,直到文档符合您的标准。
|
|
12
|
+
2. **批处理模式**:当您同时更新多个文档或使用 `--reset` 标志时使用。此模式会在单次操作中将您的反馈应用于所有选定的文档,对于大范围的变更非常高效。
|
|
13
13
|
|
|
14
14
|
## 交互模式:优化单个文档
|
|
15
15
|
|
|
16
|
-
|
|
16
|
+
交互模式提供了一个受控的环境,可以对单个文档进行精确的更改。当您需要根据特定反馈仔细审查和调整内容时,这是理想的选择。
|
|
17
17
|
|
|
18
|
-
|
|
18
|
+
要启动交互会话,请运行 `aigne doc update` 命令并从列表中选择单个文档。
|
|
19
19
|
|
|
20
20
|
```bash
|
|
21
21
|
aigne doc update
|
|
22
22
|
```
|
|
23
23
|
|
|
24
|
-
|
|
24
|
+
该工具将引导您完成以下步骤:
|
|
25
25
|
|
|
26
26
|
1. **文档分析**:系统首先会显示所选文档的结构大纲,展示其主要标题。
|
|
27
|
-
2.
|
|
28
|
-
*
|
|
29
|
-
*
|
|
30
|
-
*
|
|
31
|
-
3.
|
|
32
|
-
4.
|
|
27
|
+
2. **用户操作**:然后系统会提示您选择以下三种操作之一:
|
|
28
|
+
* **查看文档**:显示当前版本文档的全部内容,并在您的终端中渲染以便于阅读。
|
|
29
|
+
* **提供反馈**:提示您输入修改请求。这可以是任何内容,从“添加一个关于错误处理的部分”到“阐明 `config` 对象的用途”。
|
|
30
|
+
* **完成**:退出交互会话并保存最后生成的文档版本。
|
|
31
|
+
3. **内容重新生成**:在您提交反馈后,AI 会根据您的指令重新生成文档内容。然后会显示新的标题结构。
|
|
32
|
+
4. **迭代或完成**:您可以继续这个查看、提供反馈和重新生成的循环,直到您对结果满意为止。一旦选择“完成”,该过程即告结束。
|
|
33
33
|
|
|
34
|
-
|
|
34
|
+
这种迭代循环可以对最终输出进行微调控制,确保更新后的文档准确而完整。
|
|
35
35
|
|
|
36
|
-
##
|
|
36
|
+
## 批处理模式:更新多个文档
|
|
37
37
|
|
|
38
|
-
|
|
38
|
+
批处理模式专为提高效率而设计,适用于需要将相同的通用反馈应用于多个文档或完全重新生成它们的情况。如果您选择多个文档或使用 `--docs` 或 `--reset` 等命令行标志,此模式将自动激活。
|
|
39
39
|
|
|
40
40
|
### 使用特定反馈进行更新
|
|
41
41
|
|
|
42
|
-
|
|
42
|
+
您可以直接从命令行提供反馈来更新一个或多个文档,而无需进入交互会话。
|
|
43
43
|
|
|
44
44
|
```bash title="使用反馈更新单个文档"
|
|
45
|
-
aigne doc update --docs
|
|
45
|
+
aigne doc update --docs overview.md --feedback "Add a section explaining the authentication flow"
|
|
46
46
|
```
|
|
47
47
|
|
|
48
48
|
```bash title="使用相同的反馈更新多个文档"
|
|
49
|
-
aigne doc update --docs
|
|
49
|
+
aigne doc update --docs overview.md --docs guides-getting-started.md --feedback "Improve the clarity of all code examples"
|
|
50
50
|
```
|
|
51
51
|
|
|
52
|
-
###
|
|
52
|
+
### 重置和重新生成
|
|
53
53
|
|
|
54
54
|
`--reset` 标志指示工具忽略文档的先前版本,并根据源代码从头开始重新生成它们。当代码中的重大变更使现有文档过时时,这非常有用。
|
|
55
55
|
|
|
56
56
|
```bash title="从头开始重新生成特定文档"
|
|
57
|
-
aigne doc update --docs
|
|
57
|
+
aigne doc update --docs overview.md --reset
|
|
58
58
|
```
|
|
59
59
|
|
|
60
60
|
## 命令参考
|
|
61
61
|
|
|
62
|
-
`update`
|
|
62
|
+
`update` 命令接受几个标志来控制其行为。
|
|
63
63
|
|
|
64
64
|
| Parameter | Description | Example |
|
|
65
65
|
| :--- | :--- | :--- |
|
|
66
|
-
| `--docs <path>` | 指定要更新的一个或多个文档路径。可多次使用。 | `--docs
|
|
67
|
-
| `--feedback <text>` | 提供有关内容变更的指令。 | `--feedback "
|
|
66
|
+
| `--docs <path>` | 指定要更新的一个或多个文档路径。可多次使用。 | `--docs overview.md --docs guides-generating-documentation.md` |
|
|
67
|
+
| `--feedback <text>` | 提供有关内容变更的指令。 | `--feedback "Add more detail to the installation steps"` |
|
|
68
68
|
| `--glossary <file>` | 指定一个术语表文件,以确保在重新生成期间术语的一致性。 | `--glossary @/path/to/glossary.md` |
|
|
69
69
|
| `--reset` | 一个布尔标志,强制完全重新生成所选文档,忽略其先前版本。 | `--reset` |
|
|
70
70
|
|
|
71
71
|
## 总结
|
|
72
72
|
|
|
73
|
-
`update`
|
|
73
|
+
`update` 命令提供了一个灵活的工作流,可让您的文档与项目保持一致。使用交互模式对单个文档进行详细的迭代更改,使用批处理模式高效地将广泛的更新应用于多个文件。
|
|
74
74
|
|
|
75
75
|
有关相关任务,请参阅以下指南:
|
|
76
76
|
- [生成文档](./guides-generating-documentation.md)
|
package/docs/overview.ja.md
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
# 概要
|
|
2
2
|
|
|
3
|
-
AIGNE DocSmith
|
|
3
|
+
AIGNE DocSmithは、人工知能を利用してプロジェクトのソースコードからドキュメントを自動的に作成するツールです。これは[AIGNE Framework](https://www.aigne.io/framework)上に構築されており、コードベースを正確に反映した構造化された多言語ドキュメントを生成するように設計されています。
|
|
4
4
|
|
|
5
|
-
DocSmith
|
|
5
|
+
DocSmithの主な目的は、手動でのドキュメント作成に伴う一般的な課題、例えば作成に時間がかかる、コードの変更に伴い内容が古くなる、一貫性に欠けるといった問題に対処することです。このプロセスを自動化することで、DocSmithはドキュメントを常に最新かつ正確に保つ手助けをします。
|
|
6
6
|
|
|
7
7
|
## 仕組み
|
|
8
8
|
|
|
@@ -32,13 +32,13 @@ DocSmith -> Docs: "生成"
|
|
|
32
32
|
|
|
33
33
|
## 主な機能
|
|
34
34
|
|
|
35
|
-
DocSmith
|
|
35
|
+
DocSmithは、作成から公開までのドキュメントライフサイクルを管理するための一連の機能を提供します。
|
|
36
36
|
|
|
37
|
-
* **AI
|
|
38
|
-
* **多言語サポート**:ドキュメントを英語、中国語(簡体字)、日本語を含む12
|
|
39
|
-
* **LLMとの統合**:さまざまな大規模言語モデル(LLM
|
|
40
|
-
*
|
|
41
|
-
*
|
|
37
|
+
* **AIによる生成**:コードベースを分析し、論理的なドキュメント構造を提案し、コードの機能を説明するコンテンツを生成します。
|
|
38
|
+
* **多言語サポート**:ドキュメントを英語、中国語(簡体字)、日本語を含む12言語に翻訳します。翻訳プロセスは、技術的な正確性を維持するために文脈を認識します。
|
|
39
|
+
* **LLMとの統合**:さまざまな大規模言語モデル(LLM)と連携します。デフォルトでは、[AIGNE Hub](https://www.aigne.io/en/hub)を使用します。これは、個別のAPIキーを必要とせずにGoogle GeminiやOpenAI GPTのようなモデルを切り替えることができるサービスです。プロバイダーに直接アクセスするために、独自のAPIキーを設定することもできます。
|
|
40
|
+
* **スマートアップデート**:ソースコードの変更を検出し、ドキュメントの対応するセクションを更新します。また、生成されたコンテンツを洗練させるために、具体的なフィードバックを提供することもできます。
|
|
41
|
+
* **公開オプション**:単一のコマンドで生成されたドキュメントを公開します。公式のDocSmithプラットフォーム、または独自の[Discuss Kit](https://www.web3kit.rocks/discuss-kit)インスタンスにデプロイできます。Discuss Kitは、ドキュメントをホスティングおよび表示するためのサービスです。
|
|
42
42
|
|
|
43
43
|
## 利用可能なコマンド
|
|
44
44
|
|
|
@@ -47,15 +47,15 @@ DocSmithは一連のコマンドを通じて操作されます。以下の表は
|
|
|
47
47
|
| コマンド | 説明 |
|
|
48
48
|
| :--- | :--- |
|
|
49
49
|
| `generate` | ソースファイルから新しいドキュメントセットを作成します。 |
|
|
50
|
-
| `update` |
|
|
51
|
-
| `translate` | ドキュメントをサポートされている12
|
|
50
|
+
| `update` | コードの変更や新しいフィードバックに基づいて既存のドキュメントを修正します。 |
|
|
51
|
+
| `translate` | ドキュメントをサポートされている12言語のいずれかまたは複数に翻訳します。 |
|
|
52
52
|
| `publish` | ドキュメントをライブでアクセス可能なURLにデプロイします。 |
|
|
53
53
|
| `evaluate` | 生成されたドキュメントの品質と完全性を評価します。 |
|
|
54
|
-
| `history` |
|
|
54
|
+
| `history` | ドキュメントに加えられた更新履歴を表示します。 |
|
|
55
55
|
| `chat` | ドキュメント作成タスクを支援するための対話型チャットセッションを開始します。 |
|
|
56
|
-
| `clear` |
|
|
56
|
+
| `clear` | 生成されたファイル、設定、キャッシュデータを削除します。 |
|
|
57
57
|
| `prefs` | ドキュメント生成のために保存された設定や構成を管理します。 |
|
|
58
58
|
|
|
59
59
|
---
|
|
60
60
|
|
|
61
|
-
この概要では、AIGNE DocSmith
|
|
61
|
+
この概要では、AIGNE DocSmithの目的と機能の全体像を説明しました。ツールの使用を開始するには、インストールとセットアップの手順が記載されている[スタートガイド](./getting-started.md)に進んでください。
|
package/docs/overview.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Overview
|
|
2
2
|
|
|
3
|
-
AIGNE DocSmith is a tool that uses Artificial Intelligence to automatically create documentation from your project's source code. It is built on the AIGNE Framework and is designed to produce structured, multi-language documents that accurately reflect your codebase.
|
|
3
|
+
AIGNE DocSmith is a tool that uses Artificial Intelligence to automatically create documentation from your project's source code. It is built on the [AIGNE Framework](https://www.aigne.io/framework) and is designed to produce structured, multi-language documents that accurately reflect your codebase.
|
|
4
4
|
|
|
5
5
|
The primary goal of DocSmith is to address the common challenges of manual documentation, such as being time-consuming to write, becoming outdated as code changes, and lacking consistency. By automating this process, DocSmith helps ensure your documentation remains current and accurate.
|
|
6
6
|
|
package/docs/overview.zh-TW.md
CHANGED
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
# 總覽
|
|
2
2
|
|
|
3
|
-
AIGNE DocSmith
|
|
3
|
+
AIGNE DocSmith 是一款利用人工智慧從您專案的原始碼自動建立文件的工具。它建構於 [AIGNE Framework](https://www.aigne.io/framework) 之上,旨在產出能準確反映您程式碼庫的結構化、多語言文件。
|
|
4
4
|
|
|
5
|
-
DocSmith
|
|
5
|
+
DocSmith 的主要目標是解決手動編寫文件的常見挑戰,例如編寫耗時、隨著程式碼變更而過時,以及缺乏一致性。透過自動化此流程,DocSmith 有助於確保您的文件保持最新和準確。
|
|
6
6
|
|
|
7
7
|
## 運作方式
|
|
8
8
|
|
|
9
|
-
DocSmith
|
|
9
|
+
DocSmith 透過分析您專案的原始碼來運作,以理解其結構、元件和功能。根據此分析,它會產生一套完整的文件,從高階指南到詳細的 API 參考資料。
|
|
10
10
|
|
|
11
11
|
```d2
|
|
12
12
|
direction: down
|
|
@@ -22,40 +22,40 @@ DocSmith: {
|
|
|
22
22
|
}
|
|
23
23
|
|
|
24
24
|
Docs: {
|
|
25
|
-
label: "
|
|
25
|
+
label: "產生的文件"
|
|
26
26
|
shape: rectangle
|
|
27
27
|
}
|
|
28
28
|
|
|
29
29
|
Source-Code -> DocSmith: "分析"
|
|
30
|
-
DocSmith -> Docs: "
|
|
30
|
+
DocSmith -> Docs: "產生"
|
|
31
31
|
```
|
|
32
32
|
|
|
33
33
|
## 核心功能
|
|
34
34
|
|
|
35
|
-
DocSmith
|
|
35
|
+
DocSmith 提供了一系列功能來處理從建立到發布的整個文件生命週期。
|
|
36
36
|
|
|
37
|
-
* **AI
|
|
38
|
-
* **多語言支援**:將文件翻譯成 12
|
|
39
|
-
* **與大型語言模型 (LLM)
|
|
40
|
-
*
|
|
41
|
-
*
|
|
37
|
+
* **AI 驅動的生成**:分析您的程式碼庫以提出合乎邏輯的文件結構,並產生解釋您程式碼功能的內容。
|
|
38
|
+
* **多語言支援**:將文件翻譯成 12 種語言,包括英語、簡體中文和日語。翻譯過程能感知上下文,以保持技術準確性。
|
|
39
|
+
* **與大型語言模型 (LLM) 整合**:連接各種大型語言模型 (LLM)。預設情況下,它使用 [AIGNE Hub](https://www.aigne.io/en/hub),這是一項服務,讓您可以在 Google Gemini 和 OpenAI GPT 等模型之間切換,而無需單獨的 API 金鑰。您也可以設定自己的 API 金鑰以直接存取供應商。
|
|
40
|
+
* **智慧更新**:偵測您原始碼中的變更,並更新文件的相應部分。您還可以提供具體的回饋來完善產生的內容。
|
|
41
|
+
* **發布選項**:使用單一指令發布您產生的文件。您可以部署到官方 DocSmith 平台或您自己的 [Discuss Kit](https://www.web3kit.rocks/discuss-kit) 實例。Discuss Kit 是一項用於託管和顯示文件的服務。
|
|
42
42
|
|
|
43
43
|
## 可用指令
|
|
44
44
|
|
|
45
|
-
DocSmith
|
|
45
|
+
DocSmith 透過一組指令進行操作。下表總結了主要指令及其功能。
|
|
46
46
|
|
|
47
47
|
| Command | Description |
|
|
48
48
|
| :--- | :--- |
|
|
49
|
-
| `generate` |
|
|
49
|
+
| `generate` | 從您的來源檔案建立一套新文件。 |
|
|
50
50
|
| `update` | 根據程式碼變更或新的回饋修改現有文件。 |
|
|
51
51
|
| `translate` | 將文件翻譯成 12 種支援語言中的一種或多種。 |
|
|
52
|
-
| `publish` |
|
|
53
|
-
| `evaluate` |
|
|
54
|
-
| `history` |
|
|
52
|
+
| `publish` | 將您的文件部署到一個可即時存取的 URL。 |
|
|
53
|
+
| `evaluate` | 評估您所產生文件的品質和完整性。 |
|
|
54
|
+
| `history` | 檢視您文件的更新歷史記錄。 |
|
|
55
55
|
| `chat` | 啟動一個互動式聊天會話,以協助處理文件任務。 |
|
|
56
|
-
| `clear` |
|
|
57
|
-
| `prefs` |
|
|
56
|
+
| `clear` | 移除產生的檔案、設定和快取資料。 |
|
|
57
|
+
| `prefs` | 管理用於文件生成的已儲存偏好設定和組態。 |
|
|
58
58
|
|
|
59
59
|
---
|
|
60
60
|
|
|
61
|
-
本總覽提供了 AIGNE DocSmith
|
|
61
|
+
本總覽提供了 AIGNE DocSmith 的用途和功能的高階摘要。若要開始使用此工具,請前往 [快速入門](./getting-started.md) 指南以取得安裝和設定說明。
|
package/docs/overview.zh.md
CHANGED
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
# 概述
|
|
2
2
|
|
|
3
|
-
AIGNE DocSmith 是一款利用人工智能从项目源代码自动创建文档的工具。它基于 AIGNE
|
|
3
|
+
AIGNE DocSmith 是一款利用人工智能从项目源代码自动创建文档的工具。它基于 [AIGNE Framework](https://www.aigne.io/framework) 构建,旨在生成能够准确反映代码库的结构化、多语言文档。
|
|
4
4
|
|
|
5
|
-
DocSmith
|
|
5
|
+
DocSmith 的主要目标是解决手动编写文档时常见的挑战,例如耗时、代码变更后内容过时以及缺乏一致性。通过自动化此过程,DocSmith 有助于确保您的文档保持最新和准确。
|
|
6
6
|
|
|
7
7
|
## 工作原理
|
|
8
8
|
|
|
9
|
-
DocSmith 通过分析项目的源代码来理解其结构、组件和功能。基于此分析,它会生成一套完整的文档,从高级指南到详细的 API
|
|
9
|
+
DocSmith 通过分析项目的源代码来理解其结构、组件和功能。基于此分析,它会生成一套完整的文档,从高级指南到详细的 API 参考。
|
|
10
10
|
|
|
11
11
|
```d2
|
|
12
12
|
direction: down
|
|
@@ -17,7 +17,7 @@ Source-Code: {
|
|
|
17
17
|
}
|
|
18
18
|
|
|
19
19
|
DocSmith: {
|
|
20
|
-
label: "AIGNE DocSmith\n
|
|
20
|
+
label: "AIGNE DocSmith\n(AI 分析引擎)"
|
|
21
21
|
shape: rectangle
|
|
22
22
|
}
|
|
23
23
|
|
|
@@ -34,11 +34,11 @@ DocSmith -> Docs: "生成"
|
|
|
34
34
|
|
|
35
35
|
DocSmith 提供了一系列功能来处理从创建到发布的整个文档生命周期。
|
|
36
36
|
|
|
37
|
-
* **AI
|
|
38
|
-
* **多语言支持**:可将文档翻译成 12
|
|
39
|
-
* **与 LLM
|
|
40
|
-
*
|
|
41
|
-
*
|
|
37
|
+
* **AI 驱动的生成**:分析您的代码库以提出逻辑化的文档结构,并生成解释代码功能的内容。
|
|
38
|
+
* **多语言支持**:可将文档翻译成 12 种语言,包括英语、中文(简体)和日语。翻译过程能够感知上下文,以保持技术准确性。
|
|
39
|
+
* **与 LLM 集成**:可连接各种大语言模型 (LLM)。默认情况下,它使用 [AIGNE Hub](https://www.aigne.io/en/hub),该服务允许您在 Google Gemini 和 OpenAI GPT 等模型之间切换,而无需单独的 API 密钥。您也可以配置自己的 API 密钥以直接访问提供商。
|
|
40
|
+
* **智能更新**:检测源代码中的更改并更新文档的相应部分。您还可以提供具体反馈以优化生成的内容。
|
|
41
|
+
* **发布选项**:通过单个命令发布您生成的文档。您可以部署到官方 DocSmith 平台或您自己的 [Discuss Kit](https://www.web3kit.rocks/discuss-kit) 实例。Discuss Kit 是一项用于托管和展示文档的服务。
|
|
42
42
|
|
|
43
43
|
## 可用命令
|
|
44
44
|
|
|
@@ -46,16 +46,16 @@ DocSmith 通过一组命令进行操作。下表总结了主要命令及其功
|
|
|
46
46
|
|
|
47
47
|
| 命令 | 描述 |
|
|
48
48
|
| :--- | :--- |
|
|
49
|
-
| `generate` |
|
|
50
|
-
| `update` |
|
|
51
|
-
| `translate` | 将文档翻译成 12
|
|
49
|
+
| `generate` | 从您的源文件创建一套新的文档。 |
|
|
50
|
+
| `update` | 根据代码更改或新的反馈修改现有文档。 |
|
|
51
|
+
| `translate` | 将文档翻译成 12 种支持语言中的一种或多种。 |
|
|
52
52
|
| `publish` | 将您的文档部署到一个可实时访问的 URL。 |
|
|
53
|
-
| `evaluate` |
|
|
54
|
-
| `history` |
|
|
55
|
-
| `chat` |
|
|
53
|
+
| `evaluate` | 评估您生成的文档的质量和完整性。 |
|
|
54
|
+
| `history` | 查看对您的文档所做的更新历史。 |
|
|
55
|
+
| `chat` | 启动一个交互式聊天会话,以协助处理文档任务。 |
|
|
56
56
|
| `clear` | 删除生成的文件、配置和缓存数据。 |
|
|
57
57
|
| `prefs` | 管理用于文档生成的已保存偏好和配置。 |
|
|
58
58
|
|
|
59
59
|
---
|
|
60
60
|
|
|
61
|
-
|
|
61
|
+
本概述对 AIGNE DocSmith 的用途和功能进行了高级总结。要开始使用该工具,请继续阅读 [快速入门](./getting-started.md) 指南以获取安装和设置说明。
|
package/package.json
CHANGED
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
<afs-tool-usage>
|
|
2
|
+
When to use Tools:
|
|
3
|
+
- During document generation, if the given context is missing or lacks referenced content, use afs_list/afs_search/afs_read to obtain more context
|
|
4
|
+
- Code examples in generated documents must use APIs and packages defined in the input data sources. Do not generate non-existent code out of thin air. Use afs_list/afs_search/afs_read to query related code or references
|
|
5
|
+
</afs-tool-usage>
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
Use AFS tools to list/search/read files to obtain more context or references. Ensure all content is accurate, relevant, and well-structured.
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
<role_and_goal>
|
|
2
2
|
{% include "../../common/document/role-and-personality.md" %}
|
|
3
3
|
|
|
4
|
-
Your task is to generate detailed document for the current {{nodeName}} based on user-provided information: current {{nodeName}} details (including title, description, path), DataSources, documentStructure (overall structural planning), and other relevant information.
|
|
5
4
|
</role_and_goal>
|
|
6
5
|
|
|
7
6
|
|
|
@@ -50,18 +49,6 @@ Diagram generation rules:
|
|
|
50
49
|
</content_generation_rules>
|
|
51
50
|
|
|
52
51
|
|
|
53
|
-
<tool-usage>
|
|
54
|
-
1. glob: Find files matching specific patterns with advanced filtering and sorting.
|
|
55
|
-
|
|
56
|
-
2. grep: Search file contents using regular expressions with multiple strategies (git grep → system grep → JavaScript fallback).
|
|
57
|
-
|
|
58
|
-
3. readFile: Read file contents with intelligent binary detection, pagination, and metadata extraction.
|
|
59
|
-
|
|
60
|
-
When to use Tools:
|
|
61
|
-
- During document generation, if the given context is missing or lacks referenced content, use glob/grep/readFile to obtain more context
|
|
62
|
-
- Code examples in generated documents must use APIs and packages defined in the input data sources. Do not generate non-existent code out of thin air. Use glob/grep/readFile to query related code or references
|
|
63
|
-
</tool-usage>
|
|
64
|
-
|
|
65
52
|
|
|
66
53
|
<output_constraints>
|
|
67
54
|
|
|
@@ -52,3 +52,10 @@ User feedback on previous generation:
|
|
|
52
52
|
{{feedback}}
|
|
53
53
|
</feedback>
|
|
54
54
|
{% endif %}
|
|
55
|
+
|
|
56
|
+
{% include "../../common/afs/afs-tools-usage.md" %}
|
|
57
|
+
|
|
58
|
+
<instructions>
|
|
59
|
+
Generate detailed document for the current {{nodeName}} based on user-provided information: current {{nodeName}} details (including title, description, path), DataSources, documentStructure (overall structural planning), and other relevant information.
|
|
60
|
+
{% include "../../common/afs/use-afs-instruction.md" %}
|
|
61
|
+
</instructions>
|
|
@@ -1,7 +1,5 @@
|
|
|
1
1
|
<role_and_goal>
|
|
2
2
|
{% include "../../common/document/role-and-personality.md" %}
|
|
3
|
-
|
|
4
|
-
Your task is to analyze the original document content and user feedback, then use available tools to implement the requested improvements while maintaining the document's integrity and style.
|
|
5
3
|
</role_and_goal>
|
|
6
4
|
|
|
7
5
|
|
|
@@ -108,6 +106,7 @@ Error handling:
|
|
|
108
106
|
|
|
109
107
|
{% include "../generate/detail-example.md" %}
|
|
110
108
|
|
|
109
|
+
|
|
111
110
|
<output_format>
|
|
112
111
|
** Only output operation execution status **:
|
|
113
112
|
- Only return 'success' if operation executed successfully
|
|
@@ -31,3 +31,10 @@
|
|
|
31
31
|
<user_feedback>
|
|
32
32
|
{{feedback}}
|
|
33
33
|
</user_feedback>
|
|
34
|
+
|
|
35
|
+
{% include "../../common/afs/afs-tools-usage.md" %}
|
|
36
|
+
|
|
37
|
+
<instructions>
|
|
38
|
+
Analyze the original document content and user feedback, then use available tools to implement the requested improvements while maintaining the document's integrity and style.
|
|
39
|
+
{% include "../../common/afs/use-afs-instruction.md" %}
|
|
40
|
+
</instructions>
|
|
@@ -1,25 +1,6 @@
|
|
|
1
1
|
<role_and_goal>
|
|
2
2
|
You are an AI document strategist with the personality of an **INTJ (The Architect)**. Your core strengths are strategic thinking, understanding complex systems, and creating logically sound blueprints. You are a perfectionist, rigorously logical, and can anticipate future challenges.
|
|
3
3
|
|
|
4
|
-
|
|
5
|
-
Your task is to design a detailed structural plan for the document to be generated. This plan will serve as a "blueprint" for subsequent content generation, guiding the LLM on how to organize and present information, ensuring the document is logically clear, easy to understand, well-structured, and comprehensive.
|
|
6
|
-
|
|
7
|
-
Key capabilities and behavioral principles:
|
|
8
|
-
- Data Comprehension: Ability to parse and understand structured and unstructured data, identifying key concepts, entities, attributes, relationships, and processes within them.
|
|
9
|
-
- Structured Thinking: Strong logical analysis capabilities to decompose complex information into clear chapters, sections, and items, establishing reasonable hierarchical relationships.
|
|
10
|
-
- User-Oriented Approach: Ability to flexibly adjust the focus and level of detail in structural planning based on document objectives and audience characteristics provided by users.
|
|
11
|
-
- Modular Design: Tendency to divide documents into independent, reusable modules or sections for easy content population and subsequent maintenance.
|
|
12
|
-
- Flexibility and Adaptability: Ability to handle multiple types of data sources and design the most suitable documentation structure based on data source characteristics (such as code function/class structures, API endpoints/parameters, text paragraphs/themes).
|
|
13
|
-
- Clarity and Completeness: Ensure the final structural plan is easy to understand and can guide the LLM to generate a comprehensive and well-organized document.
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
Objectives:
|
|
17
|
-
- Create a clear and logical structural plan that comprehensively presents information from the user-provided context while providing users with intuitive navigation paths.
|
|
18
|
-
- Each {{nodeName}} should include: a {{nodeName}} title, a one-sentence introduction describing its main content, with presentation and organization methods tailored to the target audience.
|
|
19
|
-
|
|
20
|
-
{% include "../../common/document-structure/intj-traits.md" %}
|
|
21
|
-
|
|
22
|
-
Always follow one principle: You must ensure the final structural plan meets user requirements.
|
|
23
4
|
</role_and_goal>
|
|
24
5
|
|
|
25
6
|
|
|
@@ -60,4 +60,25 @@ Sub-structures must meet the following requirements:
|
|
|
60
60
|
- Further break down and comprehensively display the content planned in the parent document
|
|
61
61
|
- All sub-structures must have their parentId value set to {{parentDocument.path}}
|
|
62
62
|
</parent_document>
|
|
63
|
-
{% endif %}
|
|
63
|
+
{% endif %}
|
|
64
|
+
|
|
65
|
+
<instructions>
|
|
66
|
+
Your task is to design a detailed structural plan for the document to be generated. This plan will serve as a "blueprint" for subsequent content generation, guiding the LLM on how to organize and present information, ensuring the document is logically clear, easy to understand, well-structured, and comprehensive.
|
|
67
|
+
|
|
68
|
+
Key capabilities and behavioral principles:
|
|
69
|
+
- Data Comprehension: Ability to parse and understand structured and unstructured data, identifying key concepts, entities, attributes, relationships, and processes within them.
|
|
70
|
+
- Structured Thinking: Strong logical analysis capabilities to decompose complex information into clear chapters, sections, and items, establishing reasonable hierarchical relationships.
|
|
71
|
+
- User-Oriented Approach: Ability to flexibly adjust the focus and level of detail in structural planning based on document objectives and audience characteristics provided by users.
|
|
72
|
+
- Modular Design: Tendency to divide documents into independent, reusable modules or sections for easy content population and subsequent maintenance.
|
|
73
|
+
- Flexibility and Adaptability: Ability to handle multiple types of data sources and design the most suitable documentation structure based on data source characteristics (such as code function/class structures, API endpoints/parameters, text paragraphs/themes).
|
|
74
|
+
- Clarity and Completeness: Ensure the final structural plan is easy to understand and can guide the LLM to generate a comprehensive and well-organized document.
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
Objectives:
|
|
78
|
+
- Create a clear and logical structural plan that comprehensively presents information from the user-provided context while providing users with intuitive navigation paths.
|
|
79
|
+
- Each {{nodeName}} should include: a {{nodeName}} title, a one-sentence introduction describing its main content, with presentation and organization methods tailored to the target audience.
|
|
80
|
+
|
|
81
|
+
{% include "../../common/document-structure/intj-traits.md" %}
|
|
82
|
+
|
|
83
|
+
Always follow one principle: You must ensure the final structural plan meets user requirements.
|
|
84
|
+
</instructions>
|
|
@@ -6,23 +6,6 @@ Your task is to understand user requirements and execute the appropriate structu
|
|
|
6
6
|
|
|
7
7
|
{% include "../../common/document-structure/intj-traits.md" %}
|
|
8
8
|
|
|
9
|
-
Processing workflow:
|
|
10
|
-
|
|
11
|
-
- If user feedback is not in English, translate it to English first to better understand user intent
|
|
12
|
-
- Analyze user feedback to understand the specific intent (add, delete, update, or move sections)
|
|
13
|
-
- Determine which tools to use based on the user's requirements
|
|
14
|
-
- Execute the appropriate operations using available tools
|
|
15
|
-
- Ensure all modifications maintain documentation structure integrity
|
|
16
|
-
- Return 'success' when the latest version of websiteStructure meets user feedback
|
|
17
|
-
|
|
18
|
-
Rules:
|
|
19
|
-
** All changes must be made using Tools. **
|
|
20
|
-
** Carefully check if the latest version of documentStructure data meets user requirements, must avoid duplicate Tool calls. **
|
|
21
|
-
|
|
22
|
-
Objectives:
|
|
23
|
-
- Create a clear and logical structural plan that comprehensively presents information from the user-provided context while providing users with intuitive navigation paths.
|
|
24
|
-
- Each {{nodeName}} should include: a {{nodeName}} title, a one-sentence introduction describing its main content, with presentation and organization methods tailored to the target audience.
|
|
25
|
-
|
|
26
9
|
</role_and_goal>
|
|
27
10
|
|
|
28
11
|
|
|
@@ -20,3 +20,27 @@ Initial Documentation Structure:
|
|
|
20
20
|
<user_feedback>
|
|
21
21
|
{{ feedback }}
|
|
22
22
|
</user_feedback>
|
|
23
|
+
|
|
24
|
+
{% include "../../common/afs/afs-tools-usage.md" %}
|
|
25
|
+
|
|
26
|
+
<instructions>
|
|
27
|
+
|
|
28
|
+
Objectives:
|
|
29
|
+
- Create a clear and logical structural plan that comprehensively presents information from the user-provided context while providing users with intuitive navigation paths.
|
|
30
|
+
- Each {{nodeName}} should include: a {{nodeName}} title, a one-sentence introduction describing its main content, with presentation and organization methods tailored to the target audience.
|
|
31
|
+
|
|
32
|
+
Processing workflow:
|
|
33
|
+
|
|
34
|
+
- If user feedback is not in English, translate it to English first to better understand user intent
|
|
35
|
+
- Analyze user feedback to understand the specific intent (add, delete, update, or move sections)
|
|
36
|
+
- Determine which tools to use based on the user's requirements
|
|
37
|
+
- Execute the appropriate operations using available tools
|
|
38
|
+
- Ensure all modifications maintain documentation structure integrity
|
|
39
|
+
- Return 'success' when the latest version of websiteStructure meets user feedback
|
|
40
|
+
|
|
41
|
+
Rules:
|
|
42
|
+
** All changes must be made using Tools. **
|
|
43
|
+
** Carefully check if the latest version of documentStructure data meets user requirements, must avoid duplicate Tool calls. **
|
|
44
|
+
|
|
45
|
+
{% include "../../common/afs/use-afs-instruction.md" %}
|
|
46
|
+
</instructions>
|
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
import { afterEach, beforeEach, describe, expect, test, mock, spyOn } from "bun:test";
|
|
2
|
+
import { existsSync, mkdirSync, rmSync, writeFileSync } from "node:fs";
|
|
3
|
+
import { join } from "node:path";
|
|
4
|
+
import { DOC_SMITH_DIR } from "../../../utils/constants/index.mjs";
|
|
5
|
+
import viewHistory from "../../../agents/history/view.mjs";
|
|
6
|
+
|
|
7
|
+
const TEST_DIR = join(process.cwd(), `${DOC_SMITH_DIR}-test`);
|
|
8
|
+
const ORIGINAL_CWD = process.cwd();
|
|
9
|
+
|
|
10
|
+
describe("History View", () => {
|
|
11
|
+
let consoleLogMock;
|
|
12
|
+
|
|
13
|
+
beforeEach(async () => {
|
|
14
|
+
// Clean up test directory
|
|
15
|
+
if (existsSync(TEST_DIR)) {
|
|
16
|
+
rmSync(TEST_DIR, { recursive: true });
|
|
17
|
+
}
|
|
18
|
+
mkdirSync(TEST_DIR, { recursive: true });
|
|
19
|
+
|
|
20
|
+
// Change to test directory
|
|
21
|
+
process.chdir(TEST_DIR);
|
|
22
|
+
|
|
23
|
+
// Spy on console.log
|
|
24
|
+
consoleLogMock = spyOn(console, "log");
|
|
25
|
+
});
|
|
26
|
+
|
|
27
|
+
afterEach(() => {
|
|
28
|
+
// Restore original directory
|
|
29
|
+
process.chdir(ORIGINAL_CWD);
|
|
30
|
+
|
|
31
|
+
// Clean up
|
|
32
|
+
if (existsSync(TEST_DIR)) {
|
|
33
|
+
rmSync(TEST_DIR, { recursive: true });
|
|
34
|
+
}
|
|
35
|
+
|
|
36
|
+
mock.restore();
|
|
37
|
+
});
|
|
38
|
+
|
|
39
|
+
test("should display message when no history exists", () => {
|
|
40
|
+
// No history file exists
|
|
41
|
+
const result = viewHistory();
|
|
42
|
+
|
|
43
|
+
expect(result).toEqual({});
|
|
44
|
+
expect(consoleLogMock).toHaveBeenCalledWith(expect.stringContaining("No update history found"));
|
|
45
|
+
});
|
|
46
|
+
|
|
47
|
+
test("should display formatted history entries", async () => {
|
|
48
|
+
// Create history file with sample data
|
|
49
|
+
const historyPath = join(process.cwd(), DOC_SMITH_DIR, "history.yaml");
|
|
50
|
+
mkdirSync(join(process.cwd(), DOC_SMITH_DIR), { recursive: true });
|
|
51
|
+
|
|
52
|
+
const historyData = {
|
|
53
|
+
entries: [
|
|
54
|
+
{
|
|
55
|
+
timestamp: "2023-01-01T00:00:00.000Z",
|
|
56
|
+
operation: "document_update",
|
|
57
|
+
feedback: "Updated documentation",
|
|
58
|
+
documentPath: "/readme.md",
|
|
59
|
+
},
|
|
60
|
+
{
|
|
61
|
+
timestamp: "2023-01-02T00:00:00.000Z",
|
|
62
|
+
operation: "structure_update",
|
|
63
|
+
feedback: "Reorganized sections",
|
|
64
|
+
},
|
|
65
|
+
],
|
|
66
|
+
};
|
|
67
|
+
|
|
68
|
+
// Use YAML format instead of JSON
|
|
69
|
+
const { stringify } = await import("yaml");
|
|
70
|
+
writeFileSync(historyPath, stringify(historyData), "utf8");
|
|
71
|
+
|
|
72
|
+
const result = viewHistory();
|
|
73
|
+
|
|
74
|
+
expect(result).toEqual({});
|
|
75
|
+
expect(consoleLogMock).toHaveBeenCalledWith(expect.stringContaining("📜 Update History"));
|
|
76
|
+
expect(consoleLogMock).toHaveBeenCalledWith(expect.stringContaining("document_update"));
|
|
77
|
+
expect(consoleLogMock).toHaveBeenCalledWith(expect.stringContaining("structure_update"));
|
|
78
|
+
expect(consoleLogMock).toHaveBeenCalledWith(expect.stringContaining("Updated documentation"));
|
|
79
|
+
expect(consoleLogMock).toHaveBeenCalledWith(expect.stringContaining("Reorganized sections"));
|
|
80
|
+
});
|
|
81
|
+
|
|
82
|
+
test("should handle empty history entries", async () => {
|
|
83
|
+
// Create history file with empty entries
|
|
84
|
+
const historyPath = join(process.cwd(), DOC_SMITH_DIR, "history.yaml");
|
|
85
|
+
mkdirSync(join(process.cwd(), DOC_SMITH_DIR), { recursive: true });
|
|
86
|
+
|
|
87
|
+
const historyData = { entries: [] };
|
|
88
|
+
// Use YAML format instead of JSON
|
|
89
|
+
const { stringify } = await import("yaml");
|
|
90
|
+
writeFileSync(historyPath, stringify(historyData), "utf8");
|
|
91
|
+
|
|
92
|
+
const result = viewHistory();
|
|
93
|
+
|
|
94
|
+
expect(result).toEqual({});
|
|
95
|
+
expect(consoleLogMock).toHaveBeenCalledWith(expect.stringContaining("No update history found"));
|
|
96
|
+
});
|
|
97
|
+
});
|