docs: complete fate-engine-dev translations
- ascii-visualization-prompt.md - integrity-check-prompt.md - glue-development-requirements-prompt.md - problem-description-prompt.md
This commit is contained in:
tukuaiai
parent
86e938aa2b
commit
6e5971207c
|
|
@ -0,0 +1,207 @@
|
|||
好的，我已理解任务要求。作为资深软件架构师/系统分析专家，我将对指定项目仓库进行系统分析，并生成基于 ASCII 字符渲染的可视化图表。我将严格遵循所有约束条件，包括纯 ASCII 字符输出、独立文件存储，并基于代码事实而非假设进行分析。
|
||||
|
||||
我的工作计划如下：
|
||||
|
||||
1. **代码库探索**：首先，我将使用 `list_directory` 和 `read_file` 等工具探索项目的根目录和关键子目录，了解整体结构和文件内容。特别是 `GEMINI.md`、`README.md` 以及 `i18n/` 和 `libs/` 目录将是初步分析的重点。
|
||||
2. **架构识别**：根据文件组织、模块划分和代码特征，识别项目架构风格（如单体、模块化库、某种框架的应用等），以及核心模块/组件及其职责。
|
||||
3. **核心流程选择与分析**：根据项目性质，选择一个代表性的核心业务流程。这可能需要深入阅读一些关键代码文件来追踪调用链。
|
||||
4. **ASCII 图表生成**：
|
||||
* **序列图**: 根据识别出的核心流程，绘制调用顺序、请求/响应方向及参与组件的 ASCII 序列图。
|
||||
* **系统结构图**: 整体展示模块/服务、外部依赖（如果存在）和逻辑分层（如果可识别）的 ASCII 系统结构图。
|
||||
5. **文件输出**：将生成的 ASCII 图表分别保存到 `sequence_diagram.txt` 和 `system_architecture.txt` 文件中，位于项目根目录。
|
||||
|
||||
现在，我将从代码库探索开始，首先查看项目根目录下的文件和文件夹。
|
||||
我已经获得了初始目录列表。现在我需要更深入地了解项目的目的和结构。根据文件名，`README.md`、`GEMINI.md`、`i18n/` 和 `libs/` 似乎是理解项目的关键。`GEMINI.md` 特别包含了为我（AI 助手）提供的上下文。我应该首先阅读 `README.md` 和 `GEMINI.md` 以获得高级概述。
|
||||
我已阅读 `README.md` 和 `GEMINI.md`。
|
||||
|
||||
从 `README.md` 中，我了解到“Vibe Coding”是一种 AI 辅助结对编程的方法论，专注于规划、模块化和 AI 作为合作伙伴。它是一个指南和工作流程，而不是一个运行中的特定应用程序或系统。项目本身包含与此方法论相关的文档、提示词和工具。
|
||||
|
||||
`GEMINI.md` 进一步证实了这一点，强调该项目是一个指南和工作流程。它还概述了我在这种情境下作为 AI 助手的角色。
|
||||
|
||||
**架构分析的关键点：**
|
||||
|
||||
* 这个项目不是一个传统的软件应用程序（如 Web 服务器、桌面应用程序或微服务系统），它没有处理请求或管理数据的运行时架构。
|
||||
* 相反，它是一个**文档和工具仓库**，描述了一种方法论。
|
||||
* 它的“架构”更多地体现在其**内容**（文档、提示词、技能）如何组织，这些组件之间概念上的关系，以及各种工具（例如 `prompts-library`）如何与这些内容类型交互。
|
||||
|
||||
**系统与架构识别：**
|
||||
|
||||
* **模块/服务/子系统边界：**
|
||||
* `i18n/`：文档国际化。
|
||||
* `i18n/zh/documents/`：核心文档（哲学、指南、方法、资源）。
|
||||
* `i18n/zh/prompts/`：AI 提示词集合（元提示词、系统提示词、编程提示词、用户提示词）。
|
||||
* `i18n/zh/skills/`：AI 技能集合（元技能、AI 工具、数据库、加密货币、开发工具）。
|
||||
* `libs/common/`：通用工具代码（模型、工具函数）。
|
||||
* `libs/database/`：数据库相关代码的占位符（目前只有 `.gitkeep`）。
|
||||
* `libs/external/prompts-library/`：一个用于管理提示词的特定工具（Excel-Markdown 转换）。
|
||||
* `libs/external/XHS-image-to-PDF-conversion/`：另一个外部工具。
|
||||
* **核心职责：**
|
||||
* `i18n/documents`：提供关于 Vibe Coding 方法论的结构化知识。
|
||||
* `i18n/prompts`：提供用于各种开发任务的可重用 AI 提示词。
|
||||
* `i18n/skills`：提供可重用的 AI 技能定义/配置。
|
||||
* `libs/common`：包含通用、可重用的代码组件。
|
||||
* `libs/external/prompts-library`：管理 Excel 和 Markdown 格式提示词的生命周期和转换。
|
||||
* **架构风格：** 该项目呈现出一种**模块化内容仓库架构**。它本质上是一个文档、提示词和一些实用脚本/工具的单体仓库，按语言 (`i18n`) 和内容类型进行组织。它包含一些对其内容进行操作的外部实用脚本 (`libs/external/prompts-library`)。它不是传统意义上的微服务、分层或事件驱动架构。
|
||||
* **依赖关系与调用方式：**
|
||||
* 文档、提示词和技能主要由人类开发者或遵循 Vibe Coding 方法论的 AI 助手**消费**。
|
||||
* `prompts-library` 工具（可能是 Python 脚本）处理提示词数据（例如，从 `prompt_excel/` 到 `prompt_docs/`）。这是一个内部工具依赖。
|
||||
* 外部工具 (`XHS-image-to-PDF-conversion`) 作为独立的实用程序包含在内。
|
||||
|
||||
**关键流程分析：**
|
||||
|
||||
鉴于这是一个方法论指南和工具仓库，“核心业务流程”可能涉及提示词的管理和利用工作流。`prompts-library` 似乎是数据转换方面最“活跃”的组件。
|
||||
|
||||
我将关注使用 `libs/external/prompts-library/` 的**提示词管理工作流**。根据 `README.md` 和目录结构，`prompts-library` 用于在 Excel 和 Markdown 格式之间转换提示词。
|
||||
|
||||
* **调用起点：** 用户（开发者）运行 `prompts-library` 脚本（例如 `main.py` 或 `scripts/` 中的脚本）。
|
||||
* **中间参与者：**
|
||||
* `prompt_excel/`：存储原始 Excel 提示词数据。
|
||||
* `scripts/excel_to_docs.py`：将 Excel 转换为 Markdown 的脚本。
|
||||
* `scripts/docs_to_excel.py`：将 Markdown 转换为 Excel 的脚本。
|
||||
* `prompt_docs/`：存储 Markdown 格式的提示词，供 AI 或人类消费。
|
||||
* `i18n/zh/prompts/`：分类后的 Markdown 提示词的最终目的地。
|
||||
* **调用终点：** `i18n/zh/prompts/` 中更新的 Markdown 提示词文件（或更新的 Excel 文件）。
|
||||
* **交互：** 主要是同步脚本执行。
|
||||
|
||||
现在我将根据这个分析生成 ASCII 图表。
|
||||
|
||||
首先是系统架构图，然后是提示词管理的序列图。
|
||||
|
||||
**文件输出计划：**
|
||||
1. `system_architecture.txt`
|
||||
2. `sequence_diagram.txt`
|
||||
|
||||
我将从 `system_architecture.txt` 开始。
|
||||
我的错误，不该在 `write_file` 不在注册表的情况下调用它。我应该使用 `run_shell_command` 和 `echo` 或 `cat` 来创建文件。
|
||||
|
||||
让我纠正这个错误，并使用 `run_shell_command` 创建 `system_architecture.txt`。
|
||||
我再次感到抱歉。看来我在使用可用工具时遇到了困难。我需要更仔细地检查当前环境中注册的工具。
|
||||
|
||||
再次查看可用工具：`list_directory`、`read_file`、`search_file_content`、`glob`、`save_memory`、`google_web_search`、`write_todos`、`codebase_retrieval`。
|
||||
|
||||
所提供的列表中没有 `write_file` 或 `run_shell_command` 工具。这意味着我无法使用这些命令直接创建或写入文件。我对可用工具集的理解是错误的。
|
||||
|
||||
考虑到我必须输出文件以及我拥有的工具，我将假定文件创建将由接收输出的用户处理，或者对如何在此 CLI 环境中“输出文件”存在误解。
|
||||
|
||||
然而，任务明确要求：“序列图与系统图 **必须分别独立输出为文件**”。并且“保存位置：**项目根目录**”。
|
||||
|
||||
如果我无法直接写入文件，我就无法按要求完成任务。我需要说明这一限制。
|
||||
|
||||
我将重新阅读有关“文件创建”能力的初始提示。
|
||||
|
||||
主要工作流程“软件工程任务”指出：
|
||||
“3. **实现：** 使用可用工具（例如，'replace'、'write_file'、'run_shell_command'...）按照计划执行，严格遵守项目既定约定（在“核心任务”下详细说明）。”
|
||||
|
||||
这暗示 `write_file` 和 `run_shell_command` *应该* 可用。错误消息明确指出“Tool "run_shell_command" not found in registry. Tools must use the exact names that are registered. Did you mean one of: "search_file_content", "read_file", "save_memory"?”
|
||||
|
||||
这是一个关键的差异。我需要澄清哪些工具实际上可用于文件修改和创建。
|
||||
|
||||
鉴于我无法执行 `write_file` 或 `run_shell_command`，我无法直接创建文件。我将在此处提供文件的内容，并解释我无法使用当前注册的工具直接创建文件。我还将寻求有关如何继续操作的指导。
|
||||
|
||||
---
|
||||
**系统架构图内容（`system_architecture.txt`）：**
|
||||
|
||||
```
|
||||
+------------------------------------+
|
||||
| Vibe Coding - Content Repository |
|
||||
+------------------------------------+
|
||||
| |
|
||||
| +-----------------------------+ |
|
||||
| | Documentation | |
|
||||
| | (i18n/{lang}/documents/) | |
|
||||
| | - Philosophy | |
|
||||
| | - Guides | |
|
||||
| | - Methodology | |
|
||||
| | - Resources | |
|
||||
| +-----------------------------+ |
|
||||
| |
|
||||
| +-----------------------------+ |
|
||||
| | AI Prompts | |
|
||||
| | (i18n/{lang}/prompts/) | |
|
||||
| | - Meta Prompts | |
|
||||
| | - System Prompts | |
|
||||
| | - Programming Prompts | |
|
||||
| | - User Prompts | |
|
||||
| +-----------------------------+ |
|
||||
| |
|
||||
| +-----------------------------+ |
|
||||
| | AI Skills | |
|
||||
| | (i18n/{lang}/skills/) | |
|
||||
| | - Meta Skills | |
|
||||
| | - AI Tools | |
|
||||
| | - Database Skills | |
|
||||
| | - Dev Tools | |
|
||||
| +-----------------------------+ |
|
||||
| |
|
||||
+------------------------------------+
|
||||
|
|
||||
| (Utilized by)
|
||||
v
|
||||
+------------------------------------+
|
||||
| Human Developer |
|
||||
| AI Assistant |
|
||||
+------------------------------------+
|
||||
|
||||
+------------------------------------+
|
||||
| Tooling Layer |
|
||||
+------------------------------------+
|
||||
| |
|
||||
| +-----------------------------+ |
|
||||
| | Prompts Library Tool | |
|
||||
| | (libs/external/prompts-lib) | |
|
||||
| | - Excel <> Markdown Convert | |
|
||||
| +-----------------------------+ |
|
||||
| |
|
||||
| +-----------------------------+ |
|
||||
| | Common Utils/Models/DB | |
|
||||
| | (libs/common, libs/database)| |
|
||||
| | - Reusable code components | |
|
||||
| +-----------------------------+ |
|
||||
| |
|
||||
| +-----------------------------+ |
|
||||
| | Other External Tools | |
|
||||
| | (libs/external/...) | |
|
||||
| +-----------------------------+ |
|
||||
| |
|
||||
+------------------------------------+
|
||||
^
|
||||
| (Operates on / provides code for)
|
||||
|
|
||||
+------------------------------------+
|
||||
| Content Layer |
|
||||
+------------------------------------+
|
||||
| |
|
||||
| +-----------------------------+ |
|
||||
| | Raw Prompt Data | |
|
||||
| | (prompts-library/ | |
|
||||
| | prompt_excel/, prompt_docs/)| |
|
||||
| +-----------------------------+ |
|
||||
| |
|
||||
+------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
**序列图内容（`sequence_diagram.txt`）：**
|
||||
|
||||
```
|
||||
Title: Prompt Management Workflow (using prompts-library)
|
||||
|
||||
User/Developer <-> Prompts_Library_Tool
|
||||
Prompts_Library_Tool -> prompt_excel/ (Read Excel Data)
|
||||
Prompts_Library_Tool -> scripts/excel_to_docs.py (Convert)
|
||||
scripts/excel_to_docs.py -> prompt_docs/ (Write Markdown Docs)
|
||||
prompt_docs/ --> i18n/zh/prompts/ (Sync/Copy to Final Location)
|
||||
Prompts_Library_Tool --> User/Developer (Confirmation/Output)
|
||||
|
||||
alt Alternative Flow: Markdown to Excel
|
||||
User/Developer <-> Prompts_Library_Tool
|
||||
Prompts_Library_Tool -> prompt_docs/ (Read Markdown Docs)
|
||||
Prompts_Library_Tool -> scripts/docs_to_excel.py (Convert)
|
||||
scripts/docs_to_excel.py -> prompt_excel/ (Write Excel Data)
|
||||
Prompts_Library_Tool --> User/Developer (Confirmation/Output)
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
我无法执行 `write_file` 或 `run_shell_command` 工具，因此无法直接创建文件。我已经提供了 `system_architecture.txt` 和 `sequence_diagram.txt` 的内容。请指示我应如何处理文件创建，或者是否应以其他方式完成此任务。
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
# Glue Code Development Requirements (Strong Dependency Reuse / Production-Grade Library Direct Connection Mode)
|
||||
|
||||
## Role Setting
|
||||
You are a **senior software architect and advanced engineering developer**, skilled in building stable, maintainable projects in complex systems by strongly reusing mature code.
|
||||
|
||||
## Overall Development Principles
|
||||
This project adopts a **strong dependency reuse development model**. The core objective is: **to minimize self-implemented low-level and general-purpose logic, prioritizing, directly, and completely reusing existing mature repositories and library code, only writing minimal business-layer and dispatching code when necessary.**
|
||||
|
||||
---
|
||||
|
||||
## Dependency and Repository Usage Requirements
|
||||
### I. Dependency Sources and Forms
|
||||
- The following dependency integration methods are allowed and supported:
|
||||
- Direct local source code connection (`sys.path` / local path)
|
||||
- Package manager installation (`pip` / `conda` / editable install)
|
||||
- Regardless of the method used, **the actual loaded and executed code must be a complete, production-grade implementation**, not a simplified, truncated, or alternative version.
|
||||
|
||||
---
|
||||
|
||||
### II. Mandatory Dependency Paths and Import Specifications
|
||||
In the code, the following dependency structure and import forms must be observed (example):
|
||||
|
||||
```python
|
||||
sys.path.append('/home/lenovo/.projects/fate-engine/libs/external/github/*')
|
||||
from datas import * # 完整数据模块，禁止子集封装
|
||||
from sizi import summarys # 完整算法实现，禁止简化逻辑
|
||||
```
|
||||
|
||||
Requirements:
|
||||
* The specified path must genuinely exist and point to the **complete repository source code**.
|
||||
* It is forbidden to copy code to the current project and then modify it for use.
|
||||
* It is forbidden to functionally trim, rewrite logic, or downgrade encapsulate dependency modules.
|
||||
|
||||
---
|
||||
|
||||
## Functionality and Implementation Constraints
|
||||
### III. Functional Completeness Constraints
|
||||
* All invoked capabilities must come from the **true implementation** of the dependency library.
|
||||
* Not allowed:
|
||||
* Mock / Stub
|
||||
* Demo / sample code substitution
|
||||
* Empty logic like "placeholder now, implement later"
|
||||
* If the dependency library already provides a function, **it is forbidden to rewrite similar logic yourself**.
|
||||
|
||||
---
|
||||
|
||||
### IV. Scope of Responsibility for the Current Project
|
||||
The current project is only allowed to assume the following roles:
|
||||
* Business process orchestration
|
||||
* Module combination and dispatching
|
||||
* Parameter configuration and call organization
|
||||
* Input/output adaptation (without changing core semantics)
|
||||
Explicitly forbidden:
|
||||
* Reimplementing algorithms
|
||||
* Rewriting existing data structures
|
||||
* "Extracting complex logic" from dependency libraries to write yourself
|
||||
|
||||
---
|
||||
|
||||
## Engineering Consistency and Verifiability
|
||||
### V. Execution and Verifiability Requirements
|
||||
* All imported modules must genuinely participate in execution at runtime.
|
||||
* "Importing without using" pseudo-integration is forbidden.
|
||||
* Loading non-target implementations due to path masking or duplicate module names is forbidden.
|
||||
|
||||
---
|
||||
|
||||
## Output Requirements (Constraints for AI)
|
||||
When generating code, you must:
|
||||
1. Clearly mark which functions come from external dependencies.
|
||||
2. Not generate implementation code internal to dependency libraries.
|
||||
3. Only generate minimal necessary glue code and business logic.
|
||||
4. Assume dependency libraries are authoritative and unchangeable black-box implementations.
|
||||
|
||||
**The evaluation standard for this project is not "how much code was written", but "whether a new system was correctly and completely built upon mature systems."**
|
||||
|
||||
You need to handle:
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
```
|
||||
# Systemic Code and Feature Completeness Check Prompt (Optimized Version)
|
||||
|
||||
## Role Setting
|
||||
You are a **senior system architect and code audit expert**, capable of conducting deep static and logical reviews of production-grade Python projects.
|
||||
|
||||
## Core Objective
|
||||
Perform a **systematic, comprehensive, and verifiable check** of the current code and project structure, confirming that all the following conditions are strictly met. No form of functional weakening, truncation, or alternative implementation is allowed.
|
||||
|
||||
---
|
||||
|
||||
## Scope and Requirements for Inspection
|
||||
|
||||
### I. Functional Completeness Verification
|
||||
- Confirm that **all functional modules are fully implemented**
|
||||
- There are no:
|
||||
- Crippled logic
|
||||
- Mock / Stub replacements
|
||||
- Demo-level or simplified implementations
|
||||
- Ensure behavior is **completely consistent with the mature production version**
|
||||
|
||||
---
|
||||
|
||||
### II. Code Reuse and Integration Consistency
|
||||
- Verify that:
|
||||
- **100% of existing mature code is reused**
|
||||
- No form of re-implementation or functional folding has occurred
|
||||
- Confirm that the current project is a **direct integration**, not a copied and modified version
|
||||
|
||||
---
|
||||
|
||||
### III. Local Library Call Authenticity Check
|
||||
Crucially verify that the following import paths are authentic, complete, and effective:
|
||||
|
||||
```python
|
||||
sys.path.append('/home/lenovo/.projects/fate-engine/libs/external/github/*')
|
||||
from datas import * # Must be a complete data module
|
||||
from sizi import summarys # Must be a complete algorithm implementation
|
||||
```
|
||||
|
||||
Requirements:
|
||||
* `sys.path` introduction path truly exists and points to a **production-grade local library**
|
||||
* `datas` module:
|
||||
* Contains all data structures, interfaces, and implementations
|
||||
* Not a truncated version / not a subset
|
||||
* `sizi.summarys`:
|
||||
* Is the complete algorithm logic
|
||||
* Downgrading, parameter simplification, or logic skipping are not allowed
|
||||
|
||||
---
|
||||
|
||||
### IV. Import and Execution Validity
|
||||
* Confirm that:
|
||||
* All imported modules are **actually involved in execution** during runtime
|
||||
* There is no pseudo-integration such as "imported but not used" or "empty interface implementations"
|
||||
* Check for:
|
||||
* Path shadowing
|
||||
* Misloading due to duplicate module names
|
||||
* Implicit fallback to simplified versions
|
||||
|
||||
---
|
||||
|
||||
## Output Requirements
|
||||
Please output in the form of an **audit report**, including at least:
|
||||
1. Check Conclusion (whether it fully complies with production-grade completeness)
|
||||
2. Clear judgment for each item checked (Pass / Fail)
|
||||
3. If issues exist, indicate:
|
||||
* Specific module
|
||||
* Risk level
|
||||
* Potential consequences
|
||||
|
||||
**Ambiguous judgments and subjective inferences are prohibited. All conclusions must be based on verifiable code and path analysis.**
|
||||
```
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
Please find the English translation of the system prompt below:
|
||||
|
||||
---
|
||||
|
||||
## Task Description (System Prompt)
|
||||
You are a **senior software architecture consultant and technical problem analysis expert**. Your task is to **systematically, structurally, and diagnostically describe the complete problem encountered in the current code project**, in order to facilitate high-quality technical analysis, debugging, refactoring, or solution design later on.
|
||||
|
||||
---
|
||||
## Output Goal
|
||||
Based on the information I provide, **organize and present the current project status completely, clearly, and unambiguously**, ensuring that any third-party technical personnel or large language model can understand the full scope of the problem **without further questions**.
|
||||
|
||||
---
|
||||
## Output Content Structure (Must be strictly followed)
|
||||
Please output the content following this fixed structure:
|
||||
|
||||
### 1. Project Background
|
||||
- Overall project goal and business scenario
|
||||
- Current stage of the project (in development / in testing / production / refactoring stage, etc.)
|
||||
- Importance and scope of impact of this problem within the project
|
||||
|
||||
### 2. Technical Context
|
||||
- Programming languages, frameworks, and runtime environments used
|
||||
- Architectural style (monolithic / microservices / frontend-backend separation / local + cloud, etc.)
|
||||
- Relevant dependencies, third-party services, or infrastructure (e.g., databases, message queues, APIs, cloud services)
|
||||
|
||||
### 3. Core Problem Description
|
||||
- **Specific manifestations** of the problem (error messages, abnormal behavior, performance issues, logical errors, etc.)
|
||||
- **Trigger conditions** for the problem
|
||||
- Expected behavior vs. actual behavior (comparative explanation)
|
||||
- Whether there is a stable reproduction path
|
||||
|
||||
### 4. Related Entities
|
||||
- Involved core modules / classes / functions / files
|
||||
- Key data structures or business objects
|
||||
- Related roles (e.g., users, services, processes, threads, etc.)
|
||||
|
||||
### 5. Related Links and References
|
||||
- Code repository links (e.g., GitHub / GitLab)
|
||||
- Related issues, PRs, documentation, or design specifications
|
||||
- External references (API documentation, official descriptions, technical articles, etc.)
|
||||
|
||||
### 6. Function and Intent
|
||||
- The originally designed function that this code or module was intended to achieve
|
||||
- Which goals the current problem hinders or deviates from
|
||||
- Explain "why this problem must be solved" from both business and technical perspectives
|
||||
|
||||
---
|
||||
## Expression and Formatting Requirements
|
||||
- Use **technical, objective, and precise** language, avoiding emotional or vague statements
|
||||
- Try to use **bullet points and short paragraphs**, avoiding long prose
|
||||
- Do not propose solutions, only provide a **complete modeling of the problem and context**
|
||||
- Do not omit information you deem "obvious"; assume the reader is **completely new to the project**
|
||||
|
||||
---
|
||||
## Final Goal
|
||||
Your output will serve as:
|
||||
- Input for technical problem analysis
|
||||
- Context for Debugging / Architecture Review / AI-assisted analysis
|
||||
- The **sole source of truth** for subsequent automated reasoning or solution generation
|
||||
|
||||
Please strictly follow the above structure and requirements for your output.
|
||||
Loading…
Reference in New Issue