diff --git a/README.md b/README.md
index e6d9b1a..9cffaab 100644
--- a/README.md
+++ b/README.md
@@ -67,6 +67,30 @@ With auto-started dashboard:
 }
 ```
 
+With Chinese language templates:
+```json
+{
+  "mcpServers": {
+    "spec-workflow": {
+      "command": "npx",
+      "args": ["-y", "@pimzino/spec-workflow-mcp@latest", "/path/to/your/project", "--language", "zh"]
+    }
+  }
+}
+```
+
+**中文用户快速开始：**
+```json
+{
+  "mcpServers": {
+    "spec-workflow": {
+      "command": "npx",
+      "args": ["-y", "@pimzino/spec-workflow-mcp@latest", "/你的项目路径", "--language", "zh", "--AutoStartDashboard"]
+    }
+  }
+}
+```
+
 ### Step 2: Choose your interface
 
 **Option A: Web Dashboard** (Required for CLI users)
@@ -78,6 +102,30 @@ npx -y @pimzino/spec-workflow-mcp@latest /path/to/your/project --dashboard
 
 Install [Spec Workflow MCP Extension](https://marketplace.visualstudio.com/items?itemName=Pimzino.spec-workflow-mcp) from the VSCode marketplace.
 
+## 🌏 Language Support
+
+Spec Workflow supports multiple languages for templates. Use the `--language` flag to specify your preferred language:
+
+```bash
+# Use Chinese templates
+npx -y @pimzino/spec-workflow-mcp@latest /path/to/your/project --language zh
+
+# Use Japanese templates  
+npx -y @pimzino/spec-workflow-mcp@latest /path/to/your/project --language ja
+
+# Use English templates (default)
+npx -y @pimzino/spec-workflow-mcp@latest /path/to/your/project --language en
+```
+
+**Supported Languages:**
+- `en` - English (default)
+- `zh` - 中文 (Chinese)
+
+When you specify a language, the system will:
+1. Look for templates in the language-specific subdirectory (e.g., `templates/zh/` for Chinese)
+2. Fall back to English templates if language-specific templates don't exist
+3. Apply the language setting to both the MCP server and dashboard interface
+
 ## 📝 How to Use
 
 Simply mention spec-workflow in your conversation:
@@ -86,6 +134,11 @@ Simply mention spec-workflow in your conversation:
 - **"List my specs"** - Shows all specs and their status
 - **"Execute task 1.2 in spec user-auth"** - Runs a specific task
 
+**中文使用示例：**
+- **"创建一个用户认证功能的规格说明"** - 创建完整的中文规格工作流
+- **"列出我的所有规格文档"** - 显示所有规格文档及其状态
+- **"执行用户认证规格中的任务1.2"** - 运行特定任务
+
 [See more examples →](docs/PROMPTING-GUIDE.md)
 
 ## 🔧 MCP Client Setup
@@ -151,6 +204,18 @@ Or with auto-started dashboard:
   }
 }
 ```
+
+Or with Chinese language templates:
+```json
+{
+  "mcpServers": {
+    "spec-workflow": {
+      "command": "npx",
+      "args": ["-y", "@pimzino/spec-workflow-mcp@latest", "/path/to/your/project", "--language", "zh"]
+    }
+  }
+}
+```
 </details>
 
 <details>
diff --git a/src/core/workspace-initializer.ts b/src/core/workspace-initializer.ts
index cc09c44..493cf1c 100644
--- a/src/core/workspace-initializer.ts
+++ b/src/core/workspace-initializer.ts
@@ -8,10 +8,12 @@ const __dirname = dirname(fileURLToPath(import.meta.url));
 export class WorkspaceInitializer {
   private projectPath: string;
   private version: string;
+  private language: string;
   
-  constructor(projectPath: string, version: string) {
+  constructor(projectPath: string, version: string, language: string = 'en') {
     this.projectPath = projectPath;
     this.version = version;
+    this.language = language;
   }
   
   async initializeWorkspace(): Promise<void> {
@@ -64,11 +66,31 @@ export class WorkspaceInitializer {
   }
   
   private async copyTemplate(templateName: string, targetDir: string): Promise<void> {
-    // Use simple filename without version
     const targetFileName = `${templateName}.md`;
     const targetPath = join(targetDir, targetFileName);
     
-    const sourcePath = join(__dirname, '..', 'markdown', 'templates', `${templateName}.md`);
+    // 基础模板路径
+    const baseTemplateDir = join(__dirname, '..', 'markdown', 'templates');
+    
+    let sourcePath: string;
+    
+    if (this.language === 'en') {
+      // 英文模板直接使用根目录下的文件
+      sourcePath = join(baseTemplateDir, `${templateName}.md`);
+    } else {
+      // 其他语言使用对应的子目录
+      const langTemplatePath = join(baseTemplateDir, this.language, `${templateName}.md`);
+      const defaultTemplatePath = join(baseTemplateDir, `${templateName}.md`);
+      
+      try {
+        // 首先尝试语言特定模板
+        await fs.access(langTemplatePath);
+        sourcePath = langTemplatePath;
+      } catch {
+        // 语言特定模板不存在，使用英文模板
+        sourcePath = defaultTemplatePath;
+      }
+    }
     
     try {
       const content = await fs.readFile(sourcePath, 'utf-8');
diff --git a/src/index.ts b/src/index.ts
index 5b7f209..d084b27 100644
--- a/src/index.ts
+++ b/src/index.ts
@@ -30,6 +30,8 @@ OPTIONS:
                          If not specified, uses an ephemeral port
   --config <path>         Use custom config file instead of default location
                          Supports both relative and absolute paths
+  --language <code>       Set language for internationalization (e.g., zh, en, ja)
+                         Supported languages: en, zh, ja, es, fr, de, it, ko, ar
 
 CONFIGURATION:
   Default config: <project-dir>/.spec-workflow/config.toml
@@ -81,11 +83,19 @@ EXAMPLES:
   # Custom config with dashboard
   spec-workflow-mcp --config ./dev-config.toml --dashboard --port 3000
 
+  # Set language to Chinese
+  spec-workflow-mcp --language zh
+
+  # Chinese language with dashboard
+  spec-workflow-mcp --language zh --AutoStartDashboard
+
 PARAMETER FORMATS:
   --port 3456             Space-separated format
   --port=3456             Equals format
   --config path           Space-separated format
   --config=path           Equals format
+  --language zh           Space-separated format
+  --language=zh           Equals format
 
 For more information, visit: https://github.com/Pimzino/spec-workflow-mcp
 `);
@@ -110,18 +120,21 @@ function parseArguments(args: string[]): {
   const autoStartDashboard = args.includes('--AutoStartDashboard');
   let customPort: number | undefined;
   let configPath: string | undefined;
+  let customLang: string | undefined;
   
   // Check for invalid flags
-  const validFlags = ['--dashboard', '--AutoStartDashboard', '--port', '--config', '--help', '-h'];
+  const validFlags = ['--dashboard', '--AutoStartDashboard', '--port', '--config', '--language', '--help', '-h'];
   for (const arg of args) {
     if (arg.startsWith('--') && !arg.includes('=')) {
       if (!validFlags.includes(arg)) {
-        throw new Error(`Unknown option: ${arg}\nUse --help to see available options.`);
+        throw new Error(`Unknown option: ${arg}
+Use --help to see available options.`);
       }
     } else if (arg.startsWith('--') && arg.includes('=')) {
       const flagName = arg.split('=')[0];
       if (!validFlags.includes(flagName)) {
-        throw new Error(`Unknown option: ${flagName}\nUse --help to see available options.`);
+        throw new Error(`Unknown option: ${flagName}
+Use --help to see available options.`);
       }
     }
   }
@@ -181,6 +194,25 @@ function parseArguments(args: string[]): {
     }
   }
   
+  // Parse --language parameter (supports --language zh and --language=zh formats)
+  for (let i = 0; i < args.length; i++) {
+    const arg = args[i];
+    
+    if (arg.startsWith('--language=')) {
+      // Handle --language=zh format
+      customLang = arg.split('=')[1];
+      if (!customLang) {
+        throw new Error('--language parameter requires a value (e.g., --language=zh)');
+      }
+    } else if (arg === '--language' && i + 1 < args.length) {
+      // Handle --language zh format
+      customLang = args[i + 1];
+      i++; // Skip the next argument as it's the language code
+    } else if (arg === '--language') {
+      throw new Error('--language parameter requires a value (e.g., --language zh)');
+    }
+  }
+  
   // Get project path (filter out flags and their values)
   const filteredArgs = args.filter((arg, index) => {
     if (arg === '--dashboard') return false;
@@ -189,8 +221,10 @@ function parseArguments(args: string[]): {
     if (arg === '--port') return false;
     if (arg.startsWith('--config=')) return false;
     if (arg === '--config') return false;
-    // Check if this arg is a value following --port or --config
-    if (index > 0 && (args[index - 1] === '--port' || args[index - 1] === '--config')) return false;
+    if (arg.startsWith('--language=')) return false;
+    if (arg === '--language') return false;
+    // Check if this arg is a value following --port, --config, or --language
+    if (index > 0 && (args[index - 1] === '--port' || args[index - 1] === '--config' || args[index - 1] === '--language')) return false;
     return true;
   });
   
@@ -203,7 +237,7 @@ function parseArguments(args: string[]): {
     console.warn('Consider specifying an explicit path for better clarity.');
   }
   
-  return { projectPath, isDashboardMode, autoStartDashboard, port: customPort, lang: undefined, configPath };
+  return { projectPath, isDashboardMode, autoStartDashboard, port: customPort, lang: customLang, configPath };
 }
 
 async function main() {
diff --git a/src/markdown/templates/zh/design-template.md b/src/markdown/templates/zh/design-template.md
new file mode 100644
index 0000000..38e197e
--- /dev/null
+++ b/src/markdown/templates/zh/design-template.md
@@ -0,0 +1,96 @@
+# 设计文档
+
+## 概述
+
+[功能的高级描述及其在整体系统中的位置]
+
+## 指导文档一致性
+
+### 技术标准 (tech.md)
+[设计如何遵循文档化的技术模式和标准]
+
+### 项目结构 (structure.md)
+[实现将如何遵循项目组织约定]
+
+## 代码重用分析
+[将利用、扩展或与此功能集成的现有代码]
+
+### 要利用的现有组件
+- **[组件/工具名称]**：[将如何使用]
+- **[服务/助手名称]**：[将如何扩展]
+
+### 集成点
+- **[现有系统/API]**：[新功能将如何集成]
+- **[数据库/存储]**：[数据将如何连接到现有模式]
+
+## 架构
+
+[描述使用的整体架构和设计模式]
+
+### 模块化设计原则
+- **单一文件职责**：每个文件应该处理一个特定的关注点或领域
+- **组件隔离**：创建小型、专注的组件而不是大型单体文件
+- **服务层分离**：分离数据访问、业务逻辑和表示层
+- **工具模块化**：将工具分解为专注的、单一用途的模块
+
+```mermaid
+graph TD
+    A[组件A] --> B[组件B]
+    B --> C[组件C]
+```
+
+## 组件和接口
+
+### 组件1
+- **目的：** [此组件的作用]
+- **接口：** [公共方法/API]
+- **依赖：** [它依赖的内容]
+- **重用：** [它构建的现有组件/工具]
+
+### 组件2
+- **目的：** [此组件的作用]
+- **接口：** [公共方法/API]
+- **依赖：** [它依赖的内容]
+- **重用：** [它构建的现有组件/工具]
+
+## 数据模型
+
+### 模型1
+```
+[用您的语言定义Model1的结构]
+- id: [唯一标识符类型]
+- name: [字符串/文本类型]
+- [根据需要添加其他属性]
+```
+
+### 模型2
+```
+[用您的语言定义Model2的结构]
+- id: [唯一标识符类型]
+- [根据需要添加其他属性]
+```
+
+## 错误处理
+
+### 错误场景
+1. **场景1：** [描述]
+   - **处理：** [如何处理]
+   - **用户影响：** [用户看到什么]
+
+2. **场景2：** [描述]
+   - **处理：** [如何处理]
+   - **用户影响：** [用户看到什么]
+
+## 测试策略
+
+### 单元测试
+- [单元测试方法]
+- [要测试的关键组件]
+
+### 集成测试
+- [集成测试方法]
+- [要测试的关键流程]
+
+### 端到端测试
+- [E2E测试方法]
+- [要测试的用户场景]
\ No newline at end of file
diff --git a/src/markdown/templates/zh/product-template.md b/src/markdown/templates/zh/product-template.md
new file mode 100644
index 0000000..3d4f5d2
--- /dev/null
+++ b/src/markdown/templates/zh/product-template.md
@@ -0,0 +1,51 @@
+# 产品概述
+
+## 产品目的
+[描述此产品/项目的核心目的。它解决了什么问题？]
+
+## 目标用户
+[谁是此产品的主要用户？他们的需求和痛点是什么？]
+
+## 关键功能
+[列出为用户带来价值的主要功能]
+
+1. **功能1**：[描述]
+2. **功能2**：[描述]
+3. **功能3**：[描述]
+
+## 业务目标
+[此产品旨在实现哪些业务目标？]
+
+- [目标1]
+- [目标2]
+- [目标3]
+
+## 成功指标
+[我们将如何衡量此产品的成功？]
+
+- [指标1]：[目标]
+- [指标2]：[目标]
+- [指标3]：[目标]
+
+## 产品原则
+[指导产品决策的核心原则]
+
+1. **[原则1]**：[解释]
+2. **[原则2]**：[解释]
+3. **[原则3]**：[解释]
+
+## 监控与可见性（如适用）
+[用户如何跟踪进度和监控系统？]
+
+- **仪表板类型**：[例如，基于Web、CLI、桌面应用]
+- **实时更新**：[例如，WebSocket、轮询、推送通知]
+- **显示的关键指标**：[最重要的信息是什么]
+- **共享功能**：[例如，只读链接、导出、报告]
+
+## 未来愿景
+[我们预见此产品在未来将如何发展？]
+
+### 潜在增强功能
+- **远程访问**：[例如，与利益相关者共享仪表板的隧道功能]
+- **分析功能**：[例如，历史趋势、性能指标]
+- **协作功能**：[例如，多用户支持、评论]
\ No newline at end of file
diff --git a/src/markdown/templates/zh/requirements-template.md b/src/markdown/templates/zh/requirements-template.md
new file mode 100644
index 0000000..b3a0134
--- /dev/null
+++ b/src/markdown/templates/zh/requirements-template.md
@@ -0,0 +1,50 @@
+# 需求文档
+
+## 引言
+
+[提供功能的简要概述、目的以及对用户的价值]
+
+## 与产品愿景的一致性
+
+[解释此功能如何支持product.md中概述的目标]
+
+## 需求
+
+### 需求1
+
+**用户故事：** 作为[角色]，我想要[功能]，以便[收益]
+
+#### 验收标准
+
+1. 当[事件]发生时，[系统]应该[响应]
+2. 如果[前提条件]，则[系统]应该[响应]
+3. 当[事件]和[条件]同时发生时，[系统]应该[响应]
+
+### 需求2
+
+**用户故事：** 作为[角色]，我想要[功能]，以便[收益]
+
+#### 验收标准
+
+1. 当[事件]发生时，[系统]应该[响应]
+2. 如果[前提条件]，则[系统]应该[响应]
+
+## 非功能性需求
+
+### 代码架构和模块化
+- **单一职责原则**：每个文件应该有单一、明确的目的
+- **模块化设计**：组件、工具和服务应该独立且可重用
+- **依赖管理**：最小化模块间的相互依赖
+- **清晰接口**：定义组件和层之间的清晰契约
+
+### 性能
+- [性能需求]
+
+### 安全性
+- [安全需求]
+
+### 可靠性
+- [可靠性需求]
+
+### 可用性
+- [可用性需求]
\ No newline at end of file
diff --git a/src/markdown/templates/zh/structure-template.md b/src/markdown/templates/zh/structure-template.md
new file mode 100644
index 0000000..10d5848
--- /dev/null
+++ b/src/markdown/templates/zh/structure-template.md
@@ -0,0 +1,145 @@
+# 项目结构
+
+## 目录组织
+
+```
+[定义您的项目目录结构。以下为示例 - 根据您的项目类型进行调整]
+
+库/包项目示例：
+project-root/
+├── src/                    # 源代码
+├── tests/                  # 测试文件  
+├── docs/                   # 文档
+├── examples/               # 使用示例
+└── [build/dist/out]        # 构建输出
+
+应用程序项目示例：
+project-root/
+├── [src/app/lib]           # 主要源代码
+├── [assets/resources]      # 静态资源
+├── [config/settings]       # 配置
+├── [scripts/tools]         # 构建/工具脚本
+└── [tests/spec]            # 测试文件
+
+常见模式：
+- 按功能/模块分组
+- 按层次分组（UI、业务逻辑、数据）
+- 按类型分组（模型、控制器、视图）
+- 简单项目使用扁平结构
+```
+
+## 命名约定
+
+### 文件
+- **组件/模块**：[例如，`PascalCase`、`snake_case`、`kebab-case`]
+- **服务/处理器**：[例如，`UserService`、`user_service`、`user-service`]
+- **工具/助手**：[例如，`dateUtils`、`date_utils`、`date-utils`]
+- **测试**：[例如，`[filename]_test`、`[filename].test`、`[filename]Test`]
+
+### 代码
+- **类/类型**：[例如，`PascalCase`、`CamelCase`、`snake_case`]
+- **函数/方法**：[例如，`camelCase`、`snake_case`、`PascalCase`]
+- **常量**：[例如，`UPPER_SNAKE_CASE`、`SCREAMING_CASE`、`PascalCase`]
+- **变量**：[例如，`camelCase`、`snake_case`、`lowercase`]
+
+## 导入模式
+
+### 导入顺序
+1. 外部依赖
+2. 内部模块
+3. 相对导入
+4. 样式导入
+
+### 模块/包组织
+```
+[描述您的项目导入/包含模式]
+示例：
+- 从项目根目录的绝对导入
+- 模块内的相对导入
+- 包/命名空间组织
+- 依赖管理方法
+```
+
+## 代码结构模式
+
+[定义组织文件内代码的常见模式。以下为示例 - 选择适用于您项目的]
+
+### 模块/类组织
+```
+示例模式：
+1. 导入/包含/依赖
+2. 常量和配置
+3. 类型/接口定义
+4. 主要实现
+5. 助手/工具函数
+6. 导出/公共API
+```
+
+### 函数/方法组织
+```
+示例模式：
+- 首先进行输入验证
+- 中间是核心逻辑
+- 始终进行错误处理
+- 清晰的返回点
+```
+
+### 文件组织原则
+```
+选择适用于您项目的：
+- 每个文件一个类/模块
+- 相关功能组合在一起
+- 公共API在顶部/底部
+- 隐藏实现细节
+```
+
+## 代码组织原则
+
+1. **单一职责**：每个文件应该有一个明确的目的
+2. **模块化**：代码应该组织成可重用的模块
+3. **可测试性**：结构化代码以便于测试
+4. **一致性**：遵循代码库中建立的模式
+
+## 模块边界
+[定义项目不同部分如何交互并保持关注点分离]
+
+边界模式示例：
+- **核心 vs 插件**：核心功能 vs 可扩展插件
+- **公共API vs 内部**：暴露的内容 vs 实现细节  
+- **平台特定 vs 跨平台**：操作系统特定代码隔离
+- **稳定 vs 实验**：生产代码 vs 实验功能
+- **依赖方向**：哪些模块可以依赖哪些
+
+## 代码大小指南
+[定义项目的文件和函数大小指南]
+
+建议指南：
+- **文件大小**：[定义每个文件的最大行数]
+- **函数/方法大小**：[定义每个函数的最大行数]
+- **类/模块复杂度**：[定义复杂度限制]
+- **嵌套深度**：[最大嵌套级别]
+
+## 仪表板/监控结构（如适用）
+[仪表板或监控组件如何组织]
+
+### 示例结构：
+```
+src/
+└── dashboard/          # 自包含的仪表板子系统
+    ├── server/        # 后端服务器组件
+    ├── client/        # 前端资源
+    ├── shared/        # 共享类型/工具
+    └── public/        # 静态资源
+```
+
+### 关注点分离
+- 仪表板与核心业务逻辑隔离
+- 独立的CLI入口点用于独立操作
+- 对主应用程序的最小依赖
+- 可以在不影响核心功能的情况下禁用
+
+## 文档标准
+- 所有公共API必须有文档
+- 复杂逻辑应该包括内联注释
+- 主要模块的README文件
+- 遵循特定语言的文档约定
\ No newline at end of file
diff --git a/src/markdown/templates/zh/tasks-template.md b/src/markdown/templates/zh/tasks-template.md
new file mode 100644
index 0000000..45cf34a
--- /dev/null
+++ b/src/markdown/templates/zh/tasks-template.md
@@ -0,0 +1,139 @@
+# 任务文档
+
+- [ ] 1. 在src/types/feature.ts中创建核心接口
+  - 文件：src/types/feature.ts
+  - 定义功能数据结构的TypeScript接口
+  - 扩展现有base.ts中的基础接口
+  - 目的：为功能实现建立类型安全
+  - _利用：src/types/base.ts_
+  - _需求：1.1_
+  - _提示：角色：专门从事类型系统和接口的TypeScript开发者 | 任务：创建功能数据结构的全面TypeScript接口，遵循需求1.1，扩展现有基础接口 | 限制：不要修改现有基础接口，保持向后兼容性，遵循项目命名约定 | 成功：所有接口无错误编译，正确继承基础类型，完全覆盖功能需求_
+
+- [ ] 2. 在src/models/FeatureModel.ts中创建基础模型类
+  - 文件：src/models/FeatureModel.ts
+  - 实现扩展BaseModel类的基础模型
+  - 使用现有验证工具添加验证方法
+  - 目的：为功能提供数据层基础
+  - _利用：src/models/BaseModel.ts，src/utils/validation.ts_
+  - _需求：2.1_
+  - _提示：角色：具有Node.js和数据建模专长的后端开发者 | 任务：创建扩展BaseModel的基础模型类，使用现有验证模式实现验证，遵循需求2.1 | 限制：必须遵循现有模型模式，不要绕过验证工具，保持一致的错误处理 | 成功：模型正确扩展BaseModel，实现验证方法并测试，遵循项目架构模式_
+
+- [ ] 3. 添加特定模型方法到FeatureModel.ts
+  - 文件：src/models/FeatureModel.ts（从任务2继续）
+  - 实现创建、更新、删除方法
+  - 添加外键关系处理
+  - 目的：完成CRUD操作的模型功能
+  - _利用：src/models/BaseModel.ts_
+  - _需求：2.2，2.3_
+  - _提示：角色：具有ORM和数据库操作专长的后端开发者 | 任务：在FeatureModel.ts中实现CRUD方法和关系处理，遵循需求2.2和2.3，扩展src/models/BaseModel.ts中的模式 | 限制：必须保持事务完整性，遵循现有关系模式，不要重复基础模型功能 | 成功：所有CRUD操作正确工作，关系得到正确处理，数据库操作是原子且高效的_
+
+- [ ] 4. 在tests/models/FeatureModel.test.ts中创建模型单元测试
+  - 文件：tests/models/FeatureModel.test.ts
+  - 为模型验证和CRUD方法编写测试
+  - 使用现有测试工具和固件
+  - 目的：确保模型可靠性并捕获回归
+  - _利用：tests/helpers/testUtils.ts，tests/fixtures/data.ts_
+  - _需求：2.1，2.2_
+  - _提示：角色：具有单元测试和Jest/Mocha框架专长的QA工程师 | 任务：为FeatureModel验证和CRUD方法创建全面单元测试，覆盖需求2.1和2.2，使用现有测试工具 | 限制：必须测试成功和失败场景，不要直接测试外部依赖，保持测试隔离 | 成功：所有模型方法都经过良好覆盖测试，涵盖边缘情况，测试独立且一致运行_
+
+- [ ] 5. 在src/services/IFeatureService.ts中创建服务接口
+  - 文件：src/services/IFeatureService.ts
+  - 定义带有方法签名的服务契约
+  - 扩展基础服务接口模式
+  - 目的：为依赖注入建立服务层契约
+  - _利用：src/services/IBaseService.ts_
+  - _需求：3.1_
+  - _提示：角色：专门从事面向服务架构和TypeScript接口的软件架构师 | 任务：设计遵循需求3.1的服务接口契约，使用src/services/IBaseService.ts中的现有模式进行依赖注入 | 限制：必须保持接口隔离原则，不要暴露内部实现细节，确保与DI容器的契约兼容性 | 成功：接口定义良好，方法签名清晰，适当扩展基础服务，支持所有必需的服务操作_
+
+- [ ] 6. 在src/services/FeatureService.ts中实现功能服务
+  - 文件：src/services/FeatureService.ts
+  - 使用FeatureModel创建具体服务实现
+  - 使用现有错误工具添加错误处理
+  - 目的：为功能操作提供业务逻辑层
+  - _利用：src/services/BaseService.ts，src/utils/errorHandler.ts，src/models/FeatureModel.ts_
+  - _需求：3.2_
+  - _提示：角色：具有服务层架构和业务逻辑专长的后端开发者 | 任务：遵循需求3.2实现具体FeatureService，使用FeatureModel并扩展BaseService模式，使用src/utils/errorHandler.ts进行适当错误处理 | 限制：必须精确实现接口契约，不要绕过模型验证，保持与数据层的关注点分离 | 成功：服务正确实现所有接口方法，实现健壮的错误处理，业务逻辑封装良好且可测试_
+
+- [ ] 7. 在src/utils/di.ts中添加服务依赖注入
+  - 文件：src/utils/di.ts（修改现有文件）
+  - 在依赖注入容器中注册FeatureService
+  - 配置服务生命周期和依赖
+  - 目的：启用应用程序中的服务注入
+  - _利用：src/utils/di.ts中的现有DI配置_
+  - _需求：3.1_
+  - _提示：角色：具有依赖注入和IoC容器专长的DevOps工程师 | 任务：遵循需求3.1在DI容器中注册FeatureService，使用src/utils/di.ts中的现有模式配置适当的生命周期和依赖 | 限制：必须遵循现有DI容器模式，不要创建循环依赖，保持服务解析效率 | 成功：FeatureService正确注册且可解析，依赖配置正确，服务生命周期适合用例_
+
+- [ ] 8. 在tests/services/FeatureService.test.ts中创建服务单元测试
+  - 文件：tests/services/FeatureService.test.ts
+  - 使用模拟依赖为服务方法编写测试
+  - 测试错误处理场景
+  - 目的：确保服务可靠性和正确处理错误
+  - _利用：tests/helpers/testUtils.ts，tests/mocks/modelMocks.ts_
+  - _需求：3.2，3.3_
+  - _提示：角色：具有服务测试和模拟框架专长的QA工程师 | 任务：为FeatureService方法创建全面单元测试，覆盖需求3.2和3.3，使用tests/mocks/modelMocks.ts中的模拟依赖 | 限制：必须模拟所有外部依赖，隔离测试业务逻辑，不要测试框架代码 | 成功：所有服务方法都经过正确模拟测试，涵盖错误场景，测试验证业务逻辑正确性和错误处理_
+
+- [ ] 4. 创建API端点
+  - 设计API结构
+  - _利用：src/api/baseApi.ts，src/utils/apiUtils.ts_
+  - _需求：4.0_
+  - _提示：角色：专门从事RESTful设计和Express.js的API架构师 | 任务：遵循需求4.0设计全面的API结构，利用src/api/baseApi.ts中的现有模式和src/utils/apiUtils.ts中的工具 | 限制：必须遵循REST约定，保持API版本兼容性，不要直接暴露内部数据结构 | 成功：API结构设计良好且有文档，遵循现有模式，支持所有必需的操作，具有适当的HTTP方法和状态码_
+
+- [ ] 4.1 设置路由和中间件
+  - 配置应用程序路由
+  - 添加身份验证中间件
+  - 设置错误处理中间件
+  - _利用：src/middleware/auth.ts，src/middleware/errorHandler.ts_
+  - _需求：4.1_
+  - _提示：角色：具有Express.js中间件和路由专长的后端开发者 | 任务：遵循需求4.1配置应用程序路由和中间件，集成src/middleware/auth.ts中的身份验证和src/middleware/errorHandler.ts中的错误处理 | 限制：必须保持中间件顺序，不要绕过安全中间件，确保正确的错误传播 | 成功：路由正确配置，中间件链正确，身份验证工作正常，错误在整个请求生命周期中得到优雅处理_
+
+- [ ] 4.2 实现CRUD端点
+  - 创建API端点
+  - 添加请求验证
+  - 编写API集成测试
+  - _利用：src/controllers/BaseController.ts，src/utils/validation.ts_
+  - _需求：4.2，4.3_
+  - _提示：角色：具有API开发和验证专长的全栈开发者 | 任务：遵循需求4.2和4.3实现CRUD端点，扩展BaseController模式并使用src/utils/validation.ts中的验证工具 | 限制：必须验证所有输入，遵循现有控制器模式，确保适当的HTTP状态码和响应 | 成功：所有CRUD操作正确工作，请求验证防止无效数据，集成测试通过并覆盖所有端点_
+
+- [ ] 5. 添加前端组件
+  - 规划组件架构
+  - _利用：src/components/BaseComponent.tsx，src/styles/theme.ts_
+  - _需求：5.0_
+  - _提示：角色：具有React组件设计和架构专长的前端架构师 | 任务：遵循需求5.0规划全面的组件架构，利用src/components/BaseComponent.tsx中的基础模式和src/styles/theme.ts中的主题系统 | 限制：必须遵循现有组件模式，保持设计系统一致性，确保组件可重用性 | 成功：架构规划良好且有文档，组件组织正确，遵循现有模式和主题系统_
+
+- [ ] 5.1 创建基础UI组件
+  - 设置组件结构
+  - 实现可重用组件
+  - 添加样式和主题
+  - _利用：src/components/BaseComponent.tsx，src/styles/theme.ts_
+  - _需求：5.1_
+  - _提示：角色：专门从事React和组件架构的前端开发者 | 任务：遵循需求5.1创建可重用UI组件，扩展BaseComponent模式并使用src/styles/theme.ts中的现有主题系统 | 限制：必须使用现有主题变量，遵循组件组合模式，确保可访问性合规 | 成功：组件可重用且主题正确，遵循现有架构，可访问且响应式_
+
+- [ ] 5.2 实现功能特定组件
+  - 创建功能组件
+  - 添加状态管理
+  - 连接到API端点
+  - _利用：src/hooks/useApi.ts，src/components/BaseComponent.tsx_
+  - _需求：5.2，5.3_
+  - _提示：角色：具有状态管理和API集成专长的React开发者 | 任务：遵循需求5.2和5.3实现功能特定组件，使用src/hooks/useApi.ts中的API钩子并扩展BaseComponent模式 | 限制：必须使用现有状态管理模式，正确处理加载和错误状态，保持组件性能 | 成功：组件功能齐全，具有适当的状态管理，API集成流畅，用户体验响应且直观_
+
+- [ ] 6. 集成和测试
+  - 规划集成方法
+  - _利用：src/utils/integrationUtils.ts，tests/helpers/testUtils.ts_
+  - _需求：6.0_
+  - _提示：角色：具有系统集成和测试策略专长的集成工程师 | 任务：遵循需求6.0规划全面的集成方法，利用src/utils/integrationUtils.ts中的集成工具和测试助手 | 限制：必须考虑所有系统组件，确保适当的测试覆盖，保持集成测试可靠性 | 成功：集成计划全面且可行，所有系统组件协同工作，集成点得到良好测试_
+
+- [ ] 6.1 编写端到端测试
+  - 设置E2E测试框架
+  - 编写用户旅程测试
+  - 添加测试自动化
+  - _利用：tests/helpers/testUtils.ts，tests/fixtures/data.ts_
+  - _需求：全部_
+  - _提示：角色：具有E2E测试和测试框架（如Cypress或Playwright）专长的QA自动化工程师 | 任务：实施覆盖所有需求的全面端到端测试，使用测试工具和固件设置测试框架和用户旅程测试 | 限制：必须测试真实用户工作流，确保测试可维护且可靠，不要测试实现细节 | 成功：E2E测试覆盖所有关键用户旅程，测试在CI/CD管道中可靠运行，从头到尾验证用户体验_
+
+- [ ] 6.2 最终集成和清理
+  - 集成所有组件
+  - 修复任何集成问题
+  - 清理代码和文档
+  - _利用：src/utils/cleanup.ts，docs/templates/_
+  - _需求：全部_
+  - _提示：角色：具有代码质量和系统集成专长的资深开发者 | 任务：完成所有组件的最终集成，执行覆盖所有需求的全面清理，使用清理工具和文档模板 | 限制：不得破坏现有功能，确保满足代码质量标准，保持文档一致性 | 成功：所有组件完全集成且协同工作，代码干净且有文档，系统满足所有需求和质量标准}
\ No newline at end of file
diff --git a/src/markdown/templates/zh/tech-template.md b/src/markdown/templates/zh/tech-template.md
new file mode 100644
index 0000000..99d1094
--- /dev/null
+++ b/src/markdown/templates/zh/tech-template.md
@@ -0,0 +1,99 @@
+# 技术栈
+
+## 项目类型
+[描述这是什么类型的项目：Web应用程序、CLI工具、桌面应用程序、移动应用、库、API服务、嵌入式系统、游戏等]
+
+## 核心技术
+
+### 主要语言
+- **语言**：[例如，Python 3.11、Go 1.21、TypeScript、Rust、C++]
+- **运行时/编译器**：[如果适用]
+- **语言特定工具**：[包管理器、构建工具等]
+
+### 关键依赖/库
+[列出项目依赖的主要库和框架]
+- **[库/框架名称]**：[用途和版本]
+- **[库/框架名称]**：[用途和版本]
+
+### 应用程序架构
+[描述应用程序的结构方式 - 可以是MVC、事件驱动、基于插件、客户端-服务器、独立、微服务、单体等]
+
+### 数据存储（如适用）
+- **主要存储**：[例如，PostgreSQL、文件、内存、云存储]
+- **缓存**：[例如，Redis、内存、磁盘缓存]
+- **数据格式**：[例如，JSON、Protocol Buffers、XML、二进制]
+
+### 外部集成（如适用）
+- **API**：[您集成的外部服务]
+- **协议**：[例如，HTTP/REST、gRPC、WebSocket、TCP/IP]
+- **认证**：[例如，OAuth、API密钥、证书]
+
+### 监控与仪表板技术（如适用）
+- **仪表板框架**：[例如，React、Vue、原生JS、终端UI]
+- **实时通信**：[例如，WebSocket、服务器发送事件、轮询]
+- **可视化库**：[例如，Chart.js、D3、终端图表]
+- **状态管理**：[例如，Redux、Vuex、文件系统作为真实来源]
+
+## 开发环境
+
+### 构建与开发工具
+- **构建系统**：[例如，Make、CMake、Gradle、npm脚本、cargo]
+- **包管理**：[例如，pip、npm、cargo、go mod、apt、brew]
+- **开发工作流**：[例如，热重载、监视模式、REPL]
+
+### 代码质量工具
+- **静态分析**：[代码质量和正确性工具]
+- **格式化**：[代码风格强制执行工具]
+- **测试框架**：[单元、集成和/或端到端测试工具]
+- **文档**：[文档生成工具]
+
+### 版本控制与协作
+- **VCS**：[例如，Git、Mercurial、SVN]
+- **分支策略**：[例如，Git Flow、GitHub Flow、基于主干]
+- **代码审查流程**：[代码审查的进行方式]
+
+### 仪表板开发（如适用）
+- **实时重载**：[例如，热模块替换、文件监视器]
+- **端口管理**：[例如，动态分配、可配置端口]
+- **多实例支持**：[例如，同时运行多个仪表板]
+
+## 部署与分发（如适用）
+- **目标平台**：[项目运行/部署的位置：云、本地、桌面、移动、嵌入式]
+- **分发方法**：[用户获取软件的方式：下载、包管理器、应用商店、SaaS]
+- **安装要求**：[先决条件、系统要求]
+- **更新机制**：[更新的交付方式]
+
+## 技术需求与约束
+
+### 性能要求
+- [例如，响应时间、吞吐量、内存使用、启动时间]
+- [具体基准或目标]
+
+### 兼容性要求  
+- **平台支持**：[操作系统、架构、版本]
+- **依赖版本**：[依赖项的最低/最高版本]
+- **标准合规性**：[行业标准、协议、规范]
+
+### 安全与合规
+- **安全要求**：[认证、加密、数据保护]
+- **合规标准**：[GDPR、HIPAA、SOC2等（如适用）]
+- **威胁模型**：[关键安全考虑因素]
+
+### 可扩展性与可靠性
+- **预期负载**：[用户、请求、数据量]
+- **可用性要求**：[正常运行时间目标、灾难恢复]
+- **增长预测**：[系统需要如何扩展]
+
+## 技术决策与理由
+[记录关键架构和技术选择]
+
+### 决策日志
+1. **[技术/模式选择]**：[为什么选择这个，考虑的替代方案]
+2. **[架构决策]**：[理由、接受的权衡]
+3. **[工具/库选择]**：[推理、评估标准]
+
+## 已知限制
+[记录任何技术债务、限制或改进领域]
+
+- [限制1]：[影响和潜在的未来解决方案]
+- [限制2]：[存在原因和可能解决的时间]
\ No newline at end of file
diff --git a/src/server.ts b/src/server.ts
index cf53ff1..e3415f7 100644
--- a/src/server.ts
+++ b/src/server.ts
@@ -73,7 +73,7 @@ export class SpecWorkflowMCPServer {
       const __dirname = dirname(fileURLToPath(import.meta.url));
       const packageJsonPath = join(__dirname, '..', 'package.json');
       const packageJson = JSON.parse(readFileSync(packageJsonPath, 'utf-8'));
-      const workspaceInitializer = new WorkspaceInitializer(this.projectPath, packageJson.version);
+      const workspaceInitializer = new WorkspaceInitializer(this.projectPath, packageJson.version, this.lang);
       await workspaceInitializer.initializeWorkspace();
       
       // Initialize session manager