Editing AI assistants in coding (section)

== Prompts cases ==
=== Improve the quality of Meta-prompt ===
Prompt
<pre>
Now we need to review and improve the development discussion of a file management tool. Please analyze from the following three aspects:

1. Original Problem Analysis
  Please analyze in this discussion:
  - Initial technical issues and error situations
  - Original solution attempts
  - Key technical barriers discovered during discussion

2. Extended Requirements and Improvement Opportunities
  Based on the discussion process:
  - List functionality points that were not considered but are actually important
  - Identify potential technical risks and limitations
  - Propose possible optimization directions

3. Professional Specification Writing Guidelines
  Please provide:
  - Specification structure suitable for this type of tool
  - Key items and content suggestions
  - Technical documentation points that need special attention

Based on these three aspects, please provide a complete prompt template for guiding similar tool development discussions.
</pre>

<pre>
現在需要回顧並改進一個檔案管理工具的開發討論。請從以下三個面向分析：

1. 原始問題分析
   請分析這段討論中：
   - 最初提出的技術問題和錯誤情況
   - 原始的解決方案嘗試
   - 討論過程中發現的關鍵技術障礙

2. 延伸需求和改進機會
   基於討論過程：
   - 列出原本未考慮到但實際重要的功能點
   - 識別潛在的技術風險和限制
   - 提出可能的改善方向

3. 專業規格書撰寫指引
   請提供：
   - 適合此類工具的規格書架構
   - 關鍵項目和內容建議
   - 特別需要注意的技術文件要點

以上述三個面向為基礎，請提供一個完整的 prompt 模板，用於指導類似工具的開發討論。
</pre>

=== Prompt for refactor source code ===
Prompt
<pre>
refactor the code

```
(place your source code here)
```
</pre>

=== Prompt for function name suggestion ===
==== 國語版 ====
<pre>
請提供函數名稱修改建議，函數命名指南：
- 功能明確性： 名稱應清楚描述函數作用，如「檢查」、「解析」。
- 簡潔性： 選擇簡短具體的名稱，提高可讀性。
- 一致性： 遵循項目或語言的命名慣例。
- 可讀性： 使用完整單詞，避免不明確的縮寫。
- 反映返回類型： 若函數返回布林值，考慮使用「is」、「has」等前綴。
- 避免歧義： 名稱應清晰，不與其他函數混淆。
- 反映數據類型： 如果處理特定數據，應在名稱中指明，如「JSON」。

```php
附上程式碼
```
</pre>

==== 英文版 ====
<pre>
Function Naming Guidelines:
- Function Clarity: The name should clearly describe the function's action, such as "check," "parse."
- Conciseness: Choose short, specific names to improve readability.
- Consistency: Follow the naming conventions of the project or language.
- Readability: Use complete words, avoiding unclear abbreviations.
- Reflect Return Type: If the function returns a boolean value, consider using prefixes like "is," "has."
- Avoid Ambiguity: The name should be clear and not confused with other functions.
- Reflect Data Type: If handling specific data, this should be indicated in the name, such as "JSON."

```php
source code
```
</pre>

=== Prompt for Generate Unit Tests ===
JetBrain 推出 [https://plugins.jetbrains.com/plugin/22282-ai-assistant AI Assistant 外掛]功能，目前付費客戶可以免費試用 7 天。它下的 prompt，供大家參考

==== 國語版 ====
<pre>
為 "XXXClass" 類別中的 "xxx" 方法撰寫 "XXXClassTest" 測試。 指南：

- 撰寫類別和方法的測試描述。
- 測試檔案應該是完整且可編譯的，不需要進一步的操作。
- 確保每個測試專注於單一用例，以保持清晰和可讀性。
- PHP 測試檔案必須以 PHP 開頭標籤 ?php 開始
- 生成的測試類別應該在命名空間 XXX
- 檔案：XXXClass.php

```php
附上程式碼
```
</pre>

==== 英文版 ====
<pre>
Write "XXXClassTest' tests for the
'xxx' method in the
"XXXClass' class. Guideline: '*' 
- Write a description of the class and the method being tested. 
- Test file should be complete and compilable, without need for further actions. 
- Ensure that each test focuses on a single use case to maintain clarity and readability. 
- PHP test file MUST starts with php opening tag ?php 
- Generated test class should be in namespace XXX''* File: XXXClass.php 

'''php ?php class
   XXXClass {  ... 
'''
</pre>


Simple version
<pre>
Write PHPUnit test case including edge cases

'''php 
   function xxx(){ ...
'''
</pre>

=== Prompt for Find Problems (or fix this) ===
Example 1
<pre>
Help me fix the problem
'''
error message or error description ...
'''

Relevant Source Code:
```
source code ...
```
</pre>

Example 2
<pre>
Help me fix the SQL query
'''
error message or error description ...
'''

SQL Query in Question:

```
SQL syntax ...
```
</pre>


=== Prompt for Direct Code Analysis ===
Use Case: When AI debugging tools aren't working (agents, IDEs, etc.), try a clean approach: Use web-based AI with just the code—no context, no error messages. Simply ask "What's wrong with this code?" or "Find any issues?"

This fresh perspective often solves stubborn problems by avoiding bias from error messages and predetermined fix patterns, uncovering root causes that were previously missed.

Example 1
<pre>
Find any issues in this code:
```
source code ...
```
</pre>

Example 2
<pre>
What problems do you see in this code?
```
source code ...
```
</pre>

Example 3
<pre>
Review this code and identify potential issues:
```
source code ...
```
</pre>