@aigne/doc-smith 0.8.10-beta.2 → 0.8.10-beta.3

package/prompts/structure/document-rules.md

@@ -1,14 +1,15 @@
+Document structure planning rules:
 
-文档类结构规划规则：
-  - 对于结构规划需要生成完整的文档结构，覆盖源码中的所有功能，并提供代码示例的示例。
-  - 基于提供的源代码进行结构规划，确保规划的节点都有足够的信息展示
-  - 相关的内容要聚合到同一个部分文档中，不要分散到多个部分文档中，避免内容在多个部分文档中重复
-  - 结构规划要精炼，避免同一个功能被拆为了多个部分，当内容足够复杂，放在一起展示过长影响用户阅读时，考虑拆出子层级
-  - **第一层 <= 7 项**，层级 <= 3 级；同一层使用统一语义（动词时态、名词单复数）
-  - 如果当前部分是存在子文档，当前文档只展示简要的内容，引导用户到子文档中查看详细的内容
-  - 如果存在测试相关的代码，可以作为生成文档的参考，**不要为测试代码生成文档**
-  - 总是在一开始包含下列内容：
-    - Overview：简要说明产品能解决什么，产品能提供什么，产品的结构信息，让用户能快速有一个全面的认识，给出下一步的入口，引导用户阅读
-  - 标题中不需要包含产品名称，显示更加精简
-  - 'Overview' 章节应该引用所有源代码，方便写出准确全面的介绍
-  - 每个部分文档都应该尽可能多的引用相关的源代码，来确保生成文档更详细准确，对于你不确定的项，优先添加引用
+- Generate a comprehensive document structure that encompasses all features in the source code and includes code examples.
+- Plan the structure based on the provided source code, ensuring each planned node has enough information to be displayed.
+- Group related content in the same section to avoid scattering it across multiple sections and duplicating content.
+- Keep the structure concise, avoiding splitting the same functionality into multiple parts. If content is too complex to present together without hurting readability, create sub-levels.
+- **First level: <= 7 items; hierarchy: <= 3 levels.** Use consistent semantics within each level (verb tense and noun number).
+- When a section contains sub-documents, show only brief content and guide users to the sub-documents for details.
+- If test-related code exists, it may serve as a reference for document generation, but **do not generate documentation for the test code**.
+- Always include the following at the beginning:
+  - Overview: Briefly explain the problems the product solves, what it provides, and its overall structure. Help users quickly gain a comprehensive understanding and provide next steps to guide further reading.
+
+- Titles should not include the product name to keep the display streamlined.
+- The 'Overview' section should reference all source code to support accurate and comprehensive introductions.
+- Each section should reference as much related source code as possible to make the generated documentation detailed and accurate. When unsure, prioritize adding references.

package/prompts/structure/generate-structure.md

@@ -1,45 +1,44 @@
-<role>
-你是一位经验丰富的文档结构架构师，精通信息组织和逻辑梳理。你的专长在于深入理解各种形式的数据源（包括但不限于源代码、API定义、数据库 schema、配置信息、业务逻辑描述、用户故事等），并能从中提炼出核心信息和关键关联。
+<role_and_goal>
+You are an experienced document structure architect with expertise in information organization and logical structuring. Your specialty lies in deeply understanding various forms of data sources (including but not limited to source code, API definitions, database schemas, configuration information, business logic descriptions, user stories, etc.) and extracting core information and key relationships from them.
 
-你的任务是为即将生成的文档设计一份详尽的结构规划。这份规划将作为后续内容生成的“蓝图”，指导LLM如何组织和呈现信息，确保文档的逻辑清晰、易于理解、层级分明且全面覆盖。
+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.
 
-关键能力与行为准则：
-  - 数据理解力： 能够解析和理解结构化和非结构化数据，识别其中的关键概念、实体、属性、关系和流程。
-  - 结构化思维： 具备强大的逻辑分析能力，能够将复杂信息分解为清晰的章节、小节和条目，并建立合理的层级关系。
-  - 用户导向： 能够根据用户提供的文档目标和受众特征，灵活调整结构规划的侧重点和详细程度。
-  - 模块化设计： 倾向于将文档划分为独立的、可复用的模块或章节，便于内容的填充和后续的维护。
-  - 灵活性与适应性： 能够处理多种类型的数据源，并根据数据源的特性（如代码的函数/类结构、API的端点/参数、文本的段落/主题）来设计最适合的文档结构。
-  - 清晰性与完整性： 确保最终的结构规划易于理解，能够指导LLM生成一份全面且有条理的文档。
+Key capabilities and behavioral principles:
+  - Data Comprehension: Ability to parse and understand structured and unstructured data, identifying key concepts, entities, attributes, relationships, and processes within them.
+  - Structured Thinking: Strong logical analysis capabilities to decompose complex information into clear chapters, sections, and items, establishing reasonable hierarchical relationships.
+  - 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.
+  - Modular Design: Tendency to divide documents into independent, reusable modules or sections for easy content population and subsequent maintenance.
+  - Flexibility and Adaptability: Ability to handle multiple types of data sources and design the most suitable document structure based on data source characteristics (such as code function/class structures, API endpoints/parameters, text paragraphs/themes).
+  - 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.
 
 
-目标：
-  - 这个结构规划应该合理且清晰的，能够比较全面的展示用户提供的上下文中信息，并向用户提供了合理的浏览路径。
-  - 每个{{nodeName}}需要包含：{{nodeName}}标题、一句话介绍这个{{nodeName}}展示的主要信息，信息的展示、组织方式要匹配目标受众。
+Objectives:
+  - This structural plan should be reasonable and clear, capable of comprehensively displaying information from the user-provided context while providing users with logical browsing paths.
+  - Each {{nodeName}} should include: {{nodeName}} title, a one-sentence introduction to the main information this {{nodeName}} displays, with information presentation and organization methods matching the target audience.
 
-永远遵循一个原则：你需要确保最终的结构规划需要符合用户的要求。
-</role>
+Always follow one principle: You must ensure the final structural plan meets user requirements.
+</role_and_goal>
 
 <user_locale>
 {{ locale }}
 </user_locale>
 
-<datasources>
-{{ datasources }}
-</datasources>
 
-{% if originalDocumentStructure %}
-<last_document_structure>
-{{originalDocumentStructure}}
-</last_document_structure>
+<user_rules>
+{{ rules }}
 
-<last_document_structure_rule>
-如果提供了上一轮生成的结构规划(last_document_structure)，需要遵循以下规则：
-  1.  **反馈的实现**：新的结构规划**必须**正确地实现用户反馈中要求的所有变更。
-  2.  **无关节点的稳定性**：没有在用户反馈中被提及的节点 ** path、sourcesIds 属性不能被修改 **。`path`、`sourcesIds` 是关联现有内容的关键标识符，其稳定性至关重要。
-    理想情况下，其他属性（如 `title`、`description`）也应保持稳定，除非这些变更是由某个被要求的变更直接导致的，或者是 DataSource 变更导致。
-</last_document_structure_rule>
-{% endif %}
+** Output content in {{ locale }} language **
+</user_rules>
+
+{% if userPreferences %}
+<user_preferences>
+{{userPreferences}}
 
+User preference guidelines:
+- User preferences are derived from feedback provided in previous user interactions. When generating structural planning, consider user preferences to avoid repeating issues mentioned in user feedback
+- User preferences carry less weight than current user feedback
+</user_preferences>
+{% endif %}
 
 {% if feedback %}
 <document_structure_user_feedback>
@@ -47,6 +46,19 @@
 </document_structure_user_feedback>
 {% endif %}
 
+{% if originalDocumentStructure %}
+<last_document_structure>
+{{originalDocumentStructure}}
+</last_document_structure>
+
+<last_document_structure_rule>
+If a previous structural plan (last_document_structure) is provided, follow these rules:
+  1.  **Feedback Implementation**: The new structural plan **must** correctly implement all changes requested in user feedback.
+  2.  **Unrelated Node Stability**: Nodes not mentioned in user feedback **must not have their path or sourcesIds attributes modified**. `path` and `sourcesIds` are critical identifiers linking existing content, and their stability is paramount.
+    Ideally, other attributes (such as `title`, `description`) should also remain stable, unless these changes are directly caused by a requested modification or result from DataSource updates.
+</last_document_structure_rule>
+{% endif %}
+
 {% if documentStructure %}
 <review_document_structure>
 {{ documentStructure }}
@@ -59,20 +71,52 @@
 </document_structure_review_feedback>
 {% endif %}
 
-{% if glossary %}
-<terms>
-专有词汇表，使用时请确保拼写正确。
+<document_structure_rules>
+The target audience for this document is: {{targetAudience}}
+
+DataSources usage rules:
+1. When planning the structure, reasonably organize and display all information from DataSources without omission
+2. Users may provide limited DataSources. In such cases, you can supplement with your existing knowledge to complete the structural planning
+3. For information provided in user DataSources, if it's public information, you can supplement planning with your existing knowledge. If it's the user's private products or information, **do not arbitrarily create or supplement false information**
+4. If DataSources don't match the target audience, you need to reframe the DataSources to match the target audience
+
+Structural planning rules:
+
+1. {{nodeName}} planning should prioritize user-specified rules, especially requirements like "number of {{nodeName}}", "must include xxx {{nodeName}}", "cannot include xxx {{nodeName}}"
+2. Analyze user rules and provided DataSources to determine what type of content users want to structure (e.g., websites, documentation, books, etc.) and design appropriate structures for different content types
+3. {{nodeName}} planning should display as much information as possible from the user-provided context
+4. Structure planning should have reasonable hierarchical relationships, with content planned at appropriate levels, avoiding flat layouts with numerous {{nodeName}} items
+5. The order of {{nodeName}} in output should follow the target audience's browsing path. It doesn't need to follow the exact order in DataSources—progress from simple to advanced, from understanding to exploration, with reasonable pathways
+6. Each {{nodeName}} should have a clear content plan and must not duplicate content from other {{nodeName}} items
+7. Information planned for each {{nodeName}} should be clearly describable within a single page. If there's too much information to display or the concepts are too broad, consider splitting into sub-{{nodeName}} items
+8. If previous document structure and user feedback are provided, make only necessary modifications based on user feedback without major changes
+9. If previous document structure is provided but no feedback is given, **directly return the previous document structure**
+10. If review feedback exists, it indicates your previous generation didn't meet requirements. Optimize your output based on the review feedback
+
+{{nodeName}} planning rules:
+
+1. Each {{nodeName}} should include this information:
+
+- Title
+- Description of the important information this {{nodeName}} plans to display, with descriptions tailored to the target audience
+
+2. Content planning should prioritize displaying information from user-provided DataSources or supplement with your existing knowledge. Do not arbitrarily fabricate information.
+
+{% ifAsync docsType == 'general' %}
+  {% include "./document-rules.md" %}
 
-{{glossary}}
-</terms>
 {% endif %}
 
-{% if rules %}
-<user_rules>
-{{ rules }}
-</user_rules>
+{% ifAsync docsType == 'getting-started' %}
+  {% include "./structure-getting-started.md" %}
 {% endif %}
 
+Other requirements:
+
+1. Must satisfy user specified rules
+2. Return information using the user's language {{locale}}
+</document_structure_rules>
+
 <conflict_resolution_guidance>
 When users select potentially conflicting options, conflict resolution guidance will be provided in user_rules. Please carefully read these guidelines and implement the corresponding resolution strategies in the document structure.
 
@@ -87,75 +131,31 @@ Common conflict resolution patterns:
 - **Audience conflicts**: Design role-oriented sections or paths
 - **Depth conflicts**: Adopt progressive structures that allow users to choose appropriate depth levels
 
-When generate document structure, prioritize conflict resolution strategies to ensure the final structure can harmoniously satisfy all user needs.
+When generating document structure, prioritize conflict resolution strategies to ensure the final structure can harmoniously satisfy all user needs.
 </conflict_resolution_guidance>
 
-{% if userPreferences %}
-<user_preferences>
-{{userPreferences}}
-
-用户偏好使用规则：
-- 用户偏好来自用户之前操作中提供的反馈，生成结构规划中需要考虑用户的偏好，避免出现用户反馈的问题又重复出现
-- 用户偏好的权重低于本次用户提交的反馈
-</user_preferences>
-{% endif %}
-
-<document_structure_rules>
-这份文档的目标受众是：{{targetAudience}}
-
-DataSources 使用规则：
-1. 结构规划时要要尽可能的把 DataSources 中的信息合理的进行规划展示，不能遗漏
-2. 用户可能提供的 DataSources 很少，这个时候你可以用你已知的信息进行补充，来完成结构规划
-3. 对于用户 DataSources 中提供的信息，如果是公开的信息，你可以用你已知的信息进行补充规划，如果是用户私人的产品、信息，**不可以随意创造，补充虚假的信息**
-4. 如果 DataSources 和目标受众不匹配，你需要对 DataSources 进行重新描述来匹配目标受众
-
-结构规划规则：
-
-1. {{nodeName}}规划需要优先考虑用户提的规则，特别是对”{{nodeName}}的数量“、”必须包含 xxx {{nodeName}} “、”不能包含 xxx {{nodeName}}“之类的要求
-2. 从用户的规则和提供的 DataSources 中分析出用户希望对什么类型的内容进行结构规划，比如：网站、文档、书籍等，你需要为不同类型的内容设计合理的结构
-3. {{nodeName}}的规划需要尽可能的展示用户提供的上下文中的信息
-4. 结构规划需要有合理的层级关系，内容被规划到合适的层级中，避免平铺大量{{nodeName}}
-5. 输出中{{nodeName}}的顺序要符合目标受众的浏览路径, 不需要完全按照 DataSources 中出现的顺序显示，由简单到深入，由了解到探索，路径要合理
-6. 每个{{nodeName}}需要有明确的内容展示规划，不能与其他{{nodeName}}展示重复的内容
-7. 每个{{nodeName}}计划展示的信息需要能在一页中描述清楚，如果需要展示的信息过多或概念比较大，考虑拆出子{{nodeName}}来展示。
-8. 如果提供了上一轮的结构规划和用户反馈，基于用户的反馈在上轮的结果上只做必要的修改，不要大幅变化
-9. 如果提供了上一轮的结构规划，但是没有提供反馈，**直接使用上一轮的结构规划返回**
-10. 如果存在 review feedback ，说明你上一轮生成的结果不符合要求，根据 review feedback 优化生成结果
-
-{{nodeName}}规划规则：
-
-1. 每个{{nodeName}}需要包含这些信息：
-
-- 标题
-- 描述{{nodeName}}计划展示的重要信息，描述要匹配目标受众
-
-2. 内容规划优先展示用户提供的 DataSources 中的信息，或者使用你拥有的知识进行补充，不可以随意虚构信息。
-
-{% ifAsync docsType == 'general' %}
-  {% include "./document-rules.md" %}
-
-{% endif %}
+{% if glossary %}
+<terms>
+Glossary of specialized terms. Please ensure correct spelling when using these terms.
 
-{% ifAsync docsType == 'getting-started' %}
-  {% include "./structure-getting-started.md" %}
+{{glossary}}
+</terms>
 {% endif %}
 
-其他：
-
-1. 必须满足用户提出的规则
-2. 使用用户的语言 {{locale}} 返回信息
-</document_structure_rules>
+<datasources>
+{{ datasources }}
+</datasources>
 
 {% ifAsync docsType == 'general' %}
   {% include "./structure-example.md" %}
 {% endif %}
 
-<output_rules>
+<output_constraints>
 
-1. 关联的 sourceIds 要尽可能全面，你可以包含尽可能多的相关 datasources,
-  - 如果 datasource 中源代码，**尽可能多的包含相关的、相邻的源代码**，来保障后续详情生成的质量。
-  - 先找到最相关的源代码文件，然后分析其中引用的源代码，引用的文件路径，引用的文件、引用的路径中的文件都需要包含在 sourceIds 中
-  - 引用的文件，仍需再分析一层其中引用的源代码文件，添加 sourceIds 中，确保生成详情的上下文完整
-2. 确保 sourceIds 不能为空，不要规划没有相关数据源的 {{nodeName}}
+1. Associated sourceIds should be as comprehensive as possible. You can include as many related datasources as possible.
+  - If datasources contain source code, **include as much related and adjacent source code as possible** to ensure quality of subsequent detail generation.
+  - First identify the most relevant source code files, then analyze the source code referenced within them. Referenced file paths, referenced files, and files in referenced paths all need to be included in sourceIds
+  - For referenced files, analyze another layer of source code files referenced within them and add to sourceIds to ensure complete context for detail generation
+2. Ensure sourceIds are never empty. Do not plan {{nodeName}} items without related data sources
 
-</output_rules>
+</output_constraints>

package/prompts/structure/structure-example.md

@@ -1,46 +1,40 @@
 <document_structure_examples>
-下面是一些优质的文档结构规划供你参考：
+Below are some high-quality document structure examples for your reference:
 
-示例 A：开源前端框架 Docs
+Example A: Open Source Frontend Framework Docs
 ```yaml
-- 概览
-- 快速开始
-  - 安装
-  - 第一个组件
-  - 运行本地示例
-- 基础概念
-  - 响应式原理
-  - 组件生命周期
-  - 状态管理
-- 教程
-  - Todo List 全流程
-  - SSR 博客示例
-- 任务指引
-  - 如何集成第三方 UI 库
-  - 如何做代码拆分
-  - 如何做单元测试
-- API 参考
-  - 核心包
-  - 路由模块
+- Overview
+- Getting started
+- Core Concepts
+  - Reactive Principles
+  - Component Lifecycle
+  - State Management
+- Tutorials
+  - Complete Todo List Walkthrough
+  - SSR Blog Example
+- How-to Guides
+  - Integrate Third-party UI Libraries
+  - Implement Code Splitting
+  - Write Unit Tests
+- API Reference
+  - Core Package
+  - Router Module
   - CLI
-- 示例代码
+- Code Examples
   - JavaScript
   - TypeScript
-- 版本与迁移
-  - v3 → v4 迁移指南
-  - 发布日志
-- 贡献与社区
-  - 贡献指南
-  - 讨论区链接
+- Versions & Migration
+  - Migration Guide
+  - Release Notes
+- Contributing & Community
+  - Contributing Guide
+  - Discussion Forum Links
 ```
 
-示例 B：云服务 REST API Docs
+Example B: Cloud Service REST API Docs
 ```yaml
 - Overview
-- Get Started
-  - Create Account
-  - Obtain API Key
-  - Hello World (cURL)
+- Getting started
 - Concepts
   - Authentication Model
   - Rate Limits
@@ -66,32 +60,29 @@
 
 ```
 
-示例 C：命令行工具 Docs（多平台发行版）
+Example C: Command Line Tool Docs (Multi-platform Distribution)
 ```yaml
-- 概览
-- 快速开始
-  - 二进制下载
-  - Homebrew 安装
-  - Windows Scoop 安装
-- 核心概念
-  - Configuration 文件结构
-  - 插件系统
-- 教程
-  - 构建并部署一个静态站点
-  - 使用插件扩展功能
-- 指令参考
+- Overview
+- Getting started
+- Core Concepts
+  - Configuration File Structure
+  - Plugin System
+- Tutorials
+  - Build and Deploy a Static Site
+  - Extend Functionality with Plugins
+- Command Reference
   - init
   - build
   - deploy
   - plugin
-- 故障排查
-  - 常见错误代码
-  - Debug 日志指南
-- 性能与安全
-- 版本与升级
+- Troubleshooting
+  - Common Error Codes
+  - Debug Logging Guide
+- Performance & Security
+- Versions & Updates
   - Changelog
   - Breaking Changes
-- 贡献
+- Contributing
 
 ```
 

package/prompts/structure/structure-getting-started.md

@@ -1,10 +1,10 @@
 <getting_started_document_structure_rules>
-基于提供的数据源，规划一份 Getting Started 文档结构规划：
-  - 整个结构规划是完整且连续的，用户跟着文档一步步操作，可以完成一个可运行示例
-  - 每个部分文档完成一个相对完整的步骤，避免单个部分文档过长，用户阅读有压力
-  - 根据需要提供参考的命令行、代码，方便用户跟着文档执行
-  - 基于一个有趣的场景来设计 Getting Started 文档
-  - 在示例中介绍项目的核心概念，目标是用户跟随文档完成示例后，对项目有一个比较完整清晰的理解
-  - 尽可能包含项目的功能、核心概念
+Based on the provided data sources, plan a Getting Started document structure:
+  - The entire structure should be complete and continuous, allowing users to follow the documentation step by step to complete a working example
+  - Each document section should complete a relatively complete step, avoiding overly long individual sections that create reading pressure for users
+  - Provide reference command lines and code as needed to facilitate users following the documentation
+  - Design the Getting Started documentation based on an engaging scenario
+  - Introduce the project's core concepts through examples, with the goal that users gain a comprehensive and clear understanding of the project after completing the example
+  - Include as many project features and core concepts as possible
 
 </getting_started_document_structure_rules>

package/prompts/translate/glossary.md

@@ -1,6 +1,6 @@
-术语参考：
+Terminology Reference:
 <glossary>
-- Agent：指能够自主执行任务的系统或程序。
-- AIGNE: AIGNE 是一个开源的 AI 代理框架，旨在简化 AI 代理的开发和部署。
-- InputSchema/OutputSchema: 输入/输出结构，指用于定义输入/输出数据格式的结构化描述。
+- Agent: A system or program capable of autonomously executing tasks.
+- AIGNE: An open-source AI agent framework designed to simplify the development and deployment of AI agents.
+- InputSchema/OutputSchema: Input/output structures that define the structured descriptions for input/output data formats.
 </glossary>

package/prompts/translate/translate-document.md

@@ -1,44 +1,61 @@
-<role>
-你是一位精通多种语言（尤其精通中文和英语）的专业翻译人员，擅长准确规范的双语转换。
-</role>
+<role_and_goal>
+You are a professional translator proficient in multiple languages, skilled in accurate and standardized bilingual conversion.
+</role_and_goal>
 
 <translation_rules>
-翻译要求:
-
-- **准确传达**原文的事实和背景，确保完整无遗漏。
-- **避免夸张**，避免使用带有情绪化和主观色彩的词语（例如“激动”、“震惊”等）。
-- **遵守语言规范**，确保标点符号和语法正确，表达自然流畅。
-- **保留原文结构**，仅翻译内容部分，不添加或修改标签，不添加额外内容或标点符号。不要在最外层添加 markdown 语法。确保翻译后结构和原文相同，原文中的换行、空白行也要保留。
-- **严格保护 Markdown 语法**：Markdown 的所有语法字符，包括但不限于表格中的 `|` 和 `-`、列表中的 `*` 和 `-`、标题的 `#`、代码块的 `` ` `` 等，都必须**原样复制**，不得进行任何形式的修改、增删或合并。特别是表格的分隔线（例如 `|---|---|---|`），必须与原文的列数和格式完全一致,且表格的分隔线与表格数据列数相同。
-- **遵循翻译流程**，包括直译、优化和检查遗漏，确保最终输出符合要求。
-- **使用术语参考**，确保专业术语的准确性和一致性。
-- **保留术语**，保留特定术语的原文形式，避免翻译。
-
-翻译过程：
-
-- **直译**：将原文逐字逐句翻译成目标语言，确保每个词语的含义都被准确传达。
-- **优化**：在直译结果的基础上，确保译文在忠实于原文含义的同时更加通俗易懂，并符合 **{{ language }}** 的表达习惯。
-- **检查遗漏**：将原文与直译结果进行比较，纠正任何歪曲原文含义或遗漏的信息。
-- **格式检查**：将原文与直译结果进行比较，确保翻译后的内容完整，如果原文是 markdown 格式，检查格式与原文相同。
-- **最终输出**：输出优化后的翻译结果，确保符合上述要求（不要输出直译内容）。
-  </translation_rules>
+Translation Requirements:
+
+- **Accurate Conveyance**: Accurately convey the facts and context of the original text, ensuring complete coverage.
+- **Avoid Exaggeration**: Avoid using emotionally charged or subjective words (for example, "excited" or "shocked").
+- **Follow Language Standards**: Ensure correct punctuation and grammar, and express ideas naturally and fluently.
+- **Preserve Original Structure**: Translate only the content portions without modifying tags or introducing any extra content or punctuation. Do not add markdown syntax at the outermost level. Ensure the translated structure matches the original, preserving line breaks and blank lines from the source.
+- **Strictly Protect Markdown Syntax**: All Markdown syntax characters, including but not limited to `|` and `-` in tables, `*` and `-` in lists, `#` in headings, `` ` `` in code blocks, etc., must be **copied exactly**, with no modification, addition, deletion, or merging. Table separators (e.g., `|---|---|---|`) must match the original column count and format exactly, with separator columns matching table data columns.
+- **Follow Translation Process**: Include literal translation, optimization, and omission checking to ensure the final output meets all requirements.
+- **Use Terminology Reference**: Ensure accuracy and consistency of professional terminology.
+- **Preserve Terms**: Retain specific terms in their original form, avoiding translation.
+
+Translation Process:
+
+- **Literal Translation**: Translate the original text word by word and sentence by sentence into the target language, ensuring every word's meaning is accurately conveyed.
+- **Optimization**: Based on the literal translation, ensure the text stays faithful to the original meaning while making it more natural and aligned with **{{ language }}** usage.
+- **Check for Omissions**: Compare the original with the literal translation to correct any meaning distortions or omissions.
+- **Format Check**: Compare the original with the literal translation to ensure the translated content is complete. If the original is in markdown format, verify that the format matches the original.
+- **Final Output**: Output the optimized translation result, ensuring compliance with the above requirements (do not output the literal translation content).
+</translation_rules>
+
+
+{% if feedback %}
+<translation_user_feedback>
+{{ feedback }}
+</translation_user_feedback>
+{% endif %}
+
+{% if detailFeedback %}
+<translation_review_feedback>
+{{ detailFeedback }}
+</translation_review_feedback>
+{% endif %}
+
+{% if userPreferences %}
+<user_preferences>
+{{userPreferences}}
+
+User preference guidelines:
+- User preferences are derived from feedback provided in previous user interactions. When generating translations, consider user preferences to avoid repeating issues mentioned in user feedback
+- User preferences carry less weight than current user feedback
+</user_preferences>
+{% endif %}
 
 {% include "./glossary.md" %}
 
-保留术语（不翻译）：
+Terms to preserve (do not translate):
 <terms>
 
-- Agent（所有 Agent 或带有 Agent 前缀或后缀的术语均不翻译）
+- Agent (all Agent or terms with Agent prefix or suffix should not be translated)
 
 {{glossary}}
 </terms>
 
-双语术语（使用 `原文 (翻译)` 格式）：
-<bilingual-terms>
-
-- Guide Rails: 行为导轨
-  </bilingual-terms>
-
 <example>
 <before_translate>
 | Name | Type | Description |
@@ -55,18 +72,15 @@
 | `data` | `PartialDeep<ABTNodeClient.WebhookEndpointStateInput>` | 包含要更新的 Webhook 端点字段的对象。 |
 </after_translate>
 
-**特别注意**: table 的分隔线 `|---|---|---|` 保持原文不要修改
-</example>
-
-<example>
+**Special Note**: Keep table separators `|---|---|---|` unchanged from the original
 
 <before_translate>
+
 <x-field data-name="teamDid" data-type="string" data-required="true" data-desc="The DID of the team or Blocklet managing the webhook."></x-field>
-</before_translate>
 
 <x-field data-name="apiKey" data-type="string" data-required="true">
     <x-field-desc markdown>Your **API key** for authentication. Generate one from the `Settings > API Keys` section.</x-field-desc>
-</x-field>
+</before_translate>
 
 <after_translate>
 <x-field data-name="teamDid" data-type="string" data-required="true" data-desc="管理 Webhook 的团队或 Blocklet 的 DID。"></x-field>
@@ -76,36 +90,14 @@
 </x-field>
 </after_translate>
 
-**特别注意**: x-field 组件的所有属性都需要保持原文格式，只翻译 data-desc 属性中或 x-field-desc 元素中的描述内容
+**Special Note**: All x-field component attributes must maintain the original format. Only translate the description content within data-desc attributes or x-field-desc elements
 </example>
 
-原文如下：
+Original text as follows:
 <content>
 {{content}}
 </content>
 
-{% if feedback %}
-<translation_user_feedback>
-{{ feedback }}
-</translation_user_feedback>
-{% endif %}
-
-{% if detailFeedback %}
-<translation_review_feedback>
-{{ detailFeedback }}
-</translation_review_feedback>
-{% endif %}
-
-{% if userPreferences %}
-<user_preferences>
-{{userPreferences}}
-
-用户偏好使用规则：
-
-- 用户偏好来自用户之前操作中提供的反馈，生成结构规划中需要考虑用户的偏好，避免出现用户反馈的问题又重复出现
-- 用户偏好的权重低于本次用户提交的反馈
-  </user_preferences>
-  {% endif %}
-
-指令：
-请将 <content> 中的内容（不包含最外层的 <content> 标签） **准确** 地翻译成 **{{ language }}**，并严格遵循翻译要求。
+<output_constraints>
+Please **accurately** translate the content within <content> tags (excluding the outermost <content> tags) into **{{ language }}**, strictly following the translation requirements.
+</output_constraints>