aico-cli 0.3.0 → 0.3.2

package/dist/chunks/simple-config.mjs

@@ -13,7 +13,7 @@ import { join as join$1 } from 'node:path';
 import { join, dirname, basename } from 'pathe';
 import { fileURLToPath } from 'node:url';
 
-const version = "0.3.0";
+const version = "0.3.2";
 
 function displayBanner(subtitle) {
   const defaultSubtitle = "\u4E00\u952E\u914D\u7F6E\u4F60\u7684\u5F00\u53D1\u73AF\u5883";
@@ -3191,16 +3191,6 @@ async function updateCcr(force = false) {
     }
     console.log(ansis.cyan(`\u5F53\u524D\u7248\u672C: ${currentVersion || ""}`));
     console.log(ansis.cyan(`\u6700\u65B0\u7248\u672C: ${latestVersion}`));
-    const { confirm } = await inquirer.prompt({
-      type: "confirm",
-      name: "confirm",
-      message: "\u786E\u8BA4\u66F4\u65B0 CCR\uFF1F",
-      default: true
-    });
-    if (!confirm) {
-      console.log(ansis.gray("\u66F4\u65B0\u5DF2\u8DF3\u8FC7"));
-      return true;
-    }
     const updateSpinner = ora("\u6B63\u5728\u66F4\u65B0 CCR...").start();
     try {
       await execAsync$4("npm update -g @musistudio/claude-code-router");
@@ -4696,7 +4686,7 @@ const DEFAULT_FILE_COPY_CONFIGS = [
     destination: join(CLAUDE_DIR, "personality.md"),
     type: "file",
     options: {
-      mergeStrategy: "copy",
+      mergeStrategy: "merge",
       backupBeforeCopy: true,
       deleteBeforeCopy: true
     }
@@ -4706,7 +4696,7 @@ const DEFAULT_FILE_COPY_CONFIGS = [
     destination: join(CLAUDE_DIR, "code.md"),
     type: "file",
     options: {
-      mergeStrategy: "copy",
+      mergeStrategy: "merge",
       backupBeforeCopy: true,
       deleteBeforeCopy: true
     }
@@ -4716,7 +4706,7 @@ const DEFAULT_FILE_COPY_CONFIGS = [
     destination: join(CLAUDE_DIR, "language.md"),
     type: "file",
     options: {
-      mergeStrategy: "copy",
+      mergeStrategy: "merge",
       backupBeforeCopy: true,
       deleteBeforeCopy: true
     }
@@ -4798,11 +4788,21 @@ function handleDirectoryCopy(sourcePath, destPath, options) {
   if (options?.deleteBeforeCopy && destExists) {
     removeDir(destPath);
   }
-  ensureDir(destPath);
-  copyDir(sourcePath, destPath, {
-    overwrite: options?.overwrite ?? true,
-    filter: options?.filter
-  });
+  if (options?.mergeStrategy === "skip-if-exists" && destExists) {
+    return;
+  }
+  if (options?.mergeStrategy === "merge" && destExists) {
+    copyDir(sourcePath, destPath, {
+      overwrite: false,
+      // 不覆盖已存在的文件
+      filter: options?.filter
+    });
+  } else {
+    copyDir(sourcePath, destPath, {
+      overwrite: options?.overwrite ?? true,
+      filter: options?.filter
+    });
+  }
 }
 function copyClaudeMemoryFiles(lang, rootDir) {
   const memorySourceDir = join(rootDir, "templates");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aico-cli",
-  "version": "0.3.0",
+  "version": "0.3.2",
   "packageManager": "pnpm@9.15.9",
   "description": "AI CLI",
   "repository": {

package/templates/CLAUDE.md

@@ -1,3 +1,2 @@
 @language.md
 @personality.md
-@code.md

package/templates/agents/aico/requirement/requirement-aligner.md

@@ -313,7 +313,203 @@ ADD COLUMN new_field VARCHAR(100);
 4. ⚡ **实施难度**是否在可接受范围内？
 5. 🔄 **依赖关系**是否明确？
 
-**请确认此方案是否可行，确认后我们将进入开发任务拆分阶段。**
+**请确认此方案是否可行，确认后我们将进入测试脚本创建阶段。**
 ```
 
+### 阶段五：测试脚本创建与确认
+
+在技术方案确认后，自动创建对应的测试脚本以确保质量：
+
+```bash
+# 检测项目测试框架并创建测试脚本
+if [ -f "package.json" ]; then
+    # 分析package.json识别测试框架
+    if grep -q "vitest\|jest\|mocha\|ava\|tape" package.json; then
+        echo "📦 检测到现有测试框架，创建对应测试文件..."
+        # 根据技术方案创建测试文件
+        cat > "test/unit/[功能模块]/[功能模块].test.ts" << 'EOF'
+// 自动生成的测试脚本 - 基于技术方案
+import { describe, it, expect } from 'vitest'
+
+// 根据技术方案中的组件/服务编写测试
+describe('[功能模块]', () => {
+  it('应该满足基本功能要求', () => {
+    // 测试逻辑基于技术方案文档
+    expect(true).toBe(true)
+  })
+
+  it('应该处理边界条件', () => {
+    // 边界条件测试
+  })
+
+  it('应该集成现有功能', () => {
+    // 集成测试
+  })
+})
+EOF
+    else
+        echo "📝 未检测到标准测试框架，创建通用测试脚本..."
+        mkdir -p ".aico/scripts/[功能模块]"
+        # 创建跨平台测试脚本
+        cat > ".aico/scripts/[功能模块]/test-script.sh" << 'EOF'
+#!/usr/bin/env bash
+# 跨平台测试脚本 - 支持 Windows (Git Bash/Cygwin/WSL)、Linux、macOS
+
+set -euo pipefail
+
+# 检测操作系统
+detect_os() {
+    case "$(uname -s)" in
+        Darwin*)    echo "macOS" ;;
+        Linux*)     echo "Linux" ;;
+        CYGWIN*|MINGW*|MSYS*) echo "Windows" ;;
+        *)          echo "Unknown" ;;
+    esac
+}
+
+# 主测试函数
+run_tests() {
+    local os="$(detect_os)"
+    echo "🚀 运行测试 - 操作系统: $os"
+
+    # 根据技术方案执行测试逻辑
+    echo "✅ 测试1: 验证基本功能"
+    # 这里添加具体的测试命令
+
+    echo "✅ 测试2: 验证边界条件"
+    # 边界条件测试
+
+    echo "✅ 测试3: 验证集成功能"
+    # 集成测试
+
+    echo "🎉 所有测试通过!"
+}
+
+# 执行测试
+run_tests "$@"
+EOF
+
+        # 设置执行权限
+        chmod +x ".aico/scripts/[功能模块]/test-script.sh"
+    fi
+else
+    echo "📝 创建通用测试脚本..."
+    mkdir -p ".aico/scripts/[功能模块]"
+    cat > ".aico/scripts/[功能模块]/test-script.bat" << 'EOF'
+@echo off
+REM Windows批处理测试脚本
+echo 🚀 运行测试 - Windows平台
+
+REM 根据技术方案执行测试逻辑
+echo ✅ 测试1: 验证基本功能
+REM 这里添加具体的测试命令
+
+echo ✅ 测试2: 验证边界条件
+REM 边界条件测试
+
+echo ✅ 测试3: 验证集成功能
+REM 集成测试
+
+echo 🎉 所有测试通过!
+pause
+EOF
+
+    cat > ".aico/scripts/[功能模块]/test-script.sh" << 'EOF'
+#!/usr/bin/env bash
+# Unix/Linux/macOS测试脚本
+
+echo "🚀 运行测试 - Unix平台"
+
+# 根据技术方案执行测试逻辑
+echo "✅ 测试1: 验证基本功能"
+# 这里添加具体的测试命令
+
+echo "✅ 测试2: 验证边界条件"
+# 边界条件测试
+
+echo "✅ 测试3: 验证集成功能"
+# 集成测试
+
+echo "🎉 所有测试通过!"
+EOF
+
+    chmod +x ".aico/scripts/[功能模块]/test-script.sh"
+fi
+
+# 生成测试说明文档
+cat > ".aico/scripts/[功能模块]/README.md" << 'EOF'
+# 测试脚本说明
+
+## 测试策略
+基于技术方案文档 `.aico/docs/[需求名称]/技术对齐方案文档.md` 创建
+
+## 测试覆盖
+- ✅ 基本功能验证
+- ✅ 边界条件测试
+- ✅ 集成功能测试
+
+## 运行方式
+
+### Windows
+```cmd
+test-script.bat
+```
+
+### Unix/Linux/macOS
+```bash
+./test-script.sh
+```
+
+## 自定义测试
+编辑对应的脚本文件来添加具体的测试逻辑
+EOF
+```
+
+**测试确认流程**：
+
+```markdown
+## 🧪 测试脚本已创建
+
+已根据技术方案自动生成测试脚本，请确认：
+
+### 📋 测试文件位置
+- **标准测试框架**: `test/unit/[功能模块]/[功能模块].test.ts`
+- **通用测试脚本**: `.aico/scripts/[功能模块]/test-script.*`
+
+### ✅ 需要确认的内容
+1. 🎯 **测试覆盖范围**是否满足需求？
+2. 🔧 **测试环境兼容性**是否合适？
+3. 📊 **测试用例设计**是否合理？
+4. ⚡ **测试执行方式**是否清晰？
+
+### 🔄 测试脚本管理
+使用以下命令管理测试脚本：
+```bash
+# 查看测试脚本
+aico test-script list [需求名称]
+
+# 运行测试脚本
+aico test-script run [需求名称]
+
+# 编辑测试脚本
+aico test-script edit [需求名称]
+```
+
+**请确认测试脚本无误，确认后我们将进入开发任务拆分阶段。**
+```
+
+### 确认状态管理
+
+**确认状态机：**
+- 📝 **等待确认**：默认为该状态，生成技术方案后等待用户响应
+- ✅ **已确认**：用户明确回复"确认"、"正确"、"是的"等
+- 🔄 **需要修改**：用户指出技术方案需要调整
+- ❌ **已拒绝**：用户明确表示不需要此技术方案
+
+**状态检查逻辑：**
+1. 执行前必须检查共识文档状态是否为"已确认"
+2. 生成技术方案后状态设为"等待确认"
+3. 用户确认后状态更新为"已确认"
+4. 只有状态为"已确认"时才能进入下一阶段
+
 严格按照用户确认后才能将上下文交接给下一个智能体的原则执行。

package/templates/agents/aico/requirement/task-splitter-validator.md

@@ -446,4 +446,18 @@ DB-001 → BE-001 → FE-001 → TEST-001
 **确认后将正式生成开发任务清单，并可开始自动执行开发任务。**
 ```
 
+### 确认状态管理
+
+**确认状态机：**
+- 📝 **等待确认**：默认为该状态，生成任务清单后等待用户响应
+- ✅ **已确认**：用户明确回复"确认"、"正确"、"是的"等
+- 🔄 **需要调整**：用户指出任务拆分需要修改
+- ❌ **已拒绝**：用户明确表示不需要此任务拆分
+
+**状态检查逻辑：**
+1. 执行前必须检查技术方案状态是否为"已确认"
+2. 生成任务清单后状态设为"等待确认"
+3. 用户确认后状态更新为"已确认"
+4. 只有状态为"已确认"时才能进入执行阶段
+
 严格按照用户确认后才能交接给任务执行智能体的原则执行。

package/templates/commands/aico/requirement.md

@@ -8,109 +8,115 @@ argument-hint: <需求描述>
 
 `/requirement <需求描述>`
 
-## 目标
-
-作为需求管理的指挥官，统筹整个需求从识别、对齐、拆分到执行的全生命周期：
-
-- 🎯 **需求识别**：深度理解用户意图，生成共识文档
-- 🔄 **需求对齐**：分析现有代码库，制定技术实施方案
-- 📋 **任务拆分**：将需求分解为可执行的原子任务
-- ⚡ **自动执行**：按依赖关系自动执行开发任务
-- ✅ **质量保障**：全程质量评估和验证
+## 全生命周期管理
+
+作为需求管理的指挥官，统筹整个需求从识别到实现的全生命周期，各阶段职责和调用参数如下：
+
+### 🎯 需求识别阶段
+**职责**：深度理解用户意图，生成共识文档
+**智能体**：`requirement-identifier`
+**调用参数**：
+- `user_input`: $ARGUMENTS
+- `current_timestamp`: (来自时间戳智能体)
+- `project_context`: (当前项目的 CLAUDE.md 信息)
+- `document_status`: `待确认`
+**输出**：`.aico/docs/[需求名称]/共识文档.md`
+**状态流转**：生成后设为`待确认` → 用户确认后更新为`已确认`
+
+### 🔄 需求对齐阶段
+**职责**：分析现有代码库，制定技术实施方案
+**智能体**：`requirement-aligner`
+**调用参数**：
+- `consensus_document_path`: `.aico/docs/[需求名称]/共识文档.md`
+- `current_timestamp`: (来自时间戳智能体)
+- `document_status`: `待确认`
+**前置条件**：共识文档状态为`已确认`
+**输出**：`.aico/docs/[需求名称]/技术对齐方案文档.md`
+**状态流转**：生成后设为`待确认` → 用户确认后更新为`已确认`
+
+### 📋 任务拆分阶段
+**职责**：将需求分解为可执行的原子任务
+**智能体**：`task-splitter-validator`
+**调用参数**：
+- `consensus_document_path`: `.aico/docs/[需求名称]/共识文档.md`
+- `technical_alignment_path`: `.aico/docs/[需求名称]/技术对齐方案文档.md`
+- `current_timestamp`: (来自时间戳智能体)
+- `document_status`: `待确认`
+**前置条件**：技术方案状态为`已确认`
+**输出**：`.aico/docs/[需求名称]/开发任务清单.md`
+**状态流转**：生成后设为`待确认` → 用户确认后更新为`已确认`
+
+### ⚡ 自动执行阶段
+**职责**：按依赖关系自动执行开发任务
+**智能体**：`task-executor`
+**调用参数**：
+- `task_list_path`: `.aico/docs/[需求名称]/开发任务清单.md`
+- `current_timestamp`: (来自时间戳智能体)
+- `document_status`: `已确认`
+**前置条件**：任务清单状态为`已确认`
+
+### ✅ 质量保障阶段
+**职责**：全程质量评估和验证
+**智能体**：`task-executor-validator`
+**调用参数**：
+- `task_list_path`: `.aico/docs/[需求名称]/开发任务清单.md`
+- `completion_report_path`: `.aico/docs/[需求名称]/开发任务完成报告.md`
+- `current_timestamp`: (来自时间戳智能体)
+**触发条件**：任务执行完成后自动调用
 
 ## 编排说明
 
 **步骤 1**：调用 `get-current-datetime` 子智能体获取当前时间戳。
 
-**步骤 2**：根据用户输入和上下文智能识别当前处于哪个阶段，调用相应的子智能体：
+**步骤 2**：根据用户输入和上下文智能识别当前处于哪个阶段，用户确认后再调用相应的子智能体：
 
 ### 阶段判断逻辑
 
-1. **识别阶段**：用户提供新需求描述 → 调用 `requirement-identifier`
-   - 必须生成 `.aico/docs/[需求名称]/共识文档.md`
-   - 文档状态必须设置为`待确认`
-   - 必须等待用户确认后，自动更新状态为`已确认`并进入下一阶段
-2. **对齐阶段**：存在共识文档且状态为`已确认`但无技术方案 → 调用 `requirement-aligner`
-   - 必须存在 `.aico/docs/[需求名称]/共识文档.md`并且需求状态为`已确认`
-   - 必须生成 `.aico/docs/[需求名称]/技术对齐方案文档.md`
-   - 文档状态必须设置为`待确认`
-   - 必须等待用户确认后，自动更新状态为`已确认`并进入下一阶段
-3. **拆分阶段**：存在技术方案且状态为`已确认`但无任务清单 → 调用 `task-splitter-validator`
-   - 必须存在 `.aico/docs/[需求名称]/技术对齐方案文档.md`并且状态为`已确认`
-   - 必须生成 `.aico/docs/[需求名称]/开发任务清单.md`
-   - 文档状态必须设置为`待确认`
-   - 必须等待用户确认后，自动更新状态为`已确认`并进入下一阶段
-4. **执行阶段**：存在任务清单且状态为`已确认`且有待执行任务 → 调用 `task-executor`
-5. **验证阶段**：任务执行后需要质量评估 → 调用 `task-executor-validator`
-
-### 智能体调用参数
-
-- **requirement-identifier**：
-  - `user_input`: $ARGUMENTS
-  - `current_timestamp`: (来自步骤1的时间戳)
-  - `project_context`: (当前项目的 CLAUDE.md 信息)
-  - `document_status`: `待确认`
-
-- **requirement-aligner**：
-  - `consensus_document_path`: `.aico/docs/[需求名称]/共识文档.md`
-  - `current_timestamp`: (来自步骤1的时间戳)
-  - `document_status`: `待确认`
-
-- **task-splitter-validator**：
-  - `consensus_document_path`: `.aico/docs/[需求名称]/共识文档.md`
-  - `technical_alignment_path`: `.aico/docs/[需求名称]/技术对齐方案文档.md`
-  - `current_timestamp`: (来自步骤1的时间戳)
-  - `document_status`: `待确认`
-
-- **task-executor**：
-  - `task_list_path`: `.aico/docs/[需求名称]/开发任务清单.md`
-  - `current_timestamp`: (来自步骤1的时间戳)
-  - `document_status`: `已确认`
-
-- **task-executor-validator**：
-  - `task_list_path`: `.aico/docs/[需求名称]/开发任务清单.md`
-  - `completion_report_path`: `.aico/docs/[需求名称]/开发任务完成报告.md`
-  - `current_timestamp`: (来自步骤1的时间戳)
+**每个阶段完成就结束对话，前序阶段未完成时提示用户去确认**
 
-## 执行策略
+1. **识别阶段**：用户提供新需求描述 → 调用 `requirement-identifier` 子智能体
 
-### 阶段流转控制
+2. **对齐阶段**：检查共识文档状态为`已确认` → 调用 `requirement-aligner` 子智能体
+   - 如果共识文档不存在或状态非`已确认`，提示："请先确认共识文档"
 
-- **自动流转**：当某个阶段完成且用户确认后，自动进入下一阶段
-- **断点续行**：支持在任意阶段暂停和恢复
-- **并行执行**：在任务执行阶段，支持无依赖任务的并行处理
-- **回退机制**：支持回到上一阶段重新处理
+3. **拆分阶段**：检查技术方案状态为`已确认` → 调用 `task-splitter-validator` 子智能体
+   - 如果技术方案不存在或状态非`已确认`，提示："请先确认技术方案"
 
-### 上下文管理
+4. **执行阶段**：检查任务清单状态为`已确认` → 调用 `task-executor` 子智能体
+   - 如果任务清单不存在或状态非`已确认`，提示："请先确认任务清单"
+
+5. **验证阶段**：任务执行完成后 → 调用 `task-executor-validator` 子智能体
+
+## 执行策略
 
-- 维护完整的需求生命周期上下文
-- 自动传递前置阶段的输出作为后续阶段的输入
-- 保持项目代码库状态与需求文档的同步
+### 智能体调用决策逻辑
 
-### 异常处理
+**基于文档状态和用户输入的智能路由**：
 
-- 智能体执行失败时的重试机制
-- 用户拒绝确认时的处理流程
-- 技术方案不可行时的回退策略
+1. **初始判断**：分析用户输入内容，识别需求类型和上下文
+2. **文档状态检查**：检查 `.aico/docs/[需求名称]/` 目录下的文档状态
+3. **智能路由**：
+   - 如果无相关文档 → 调用 `requirement-identifier`（识别阶段）
+   - 如果有共识文档且状态为`已确认` → 调用 `requirement-aligner`（对齐阶段）
+   - 如果有技术方案且状态为`已确认` → 调用 `task-splitter-validator`（拆分阶段）
+   - 如果有任务清单且状态为`已确认` → 调用 `task-executor`（执行阶段）
+   - 如果任务执行完成 → 调用 `task-executor-validator`（验证阶段）
 
-## 安全与边界
+4. **用户确认机制**：每个阶段完成后接结束对话，让用户去看文档是否符合他的想要的。如果用户不同意则重复上述过程直到所有文档都确认为止。
+5. **运行机制**：每个阶段的智能体都会调用其依赖的智能体执行，后序调用依赖的执行结果作为下个子智能体的输入参数。每个执行的子智能体都会生成相应的文档并标注状态。你要尽可能的使用多任务并行能力。
 
-- 只在 `.aico/docs/` 目录下创建需求相关文档
-- 严格按照用户确认的方案执行代码修改
-- 保持现有系统架构和设计模式的一致性
-- 所有修改都有完整的审计日志
+### 安全与边界约束
 
-## 输出要求
+**操作边界**：
+- 📁 **文档操作**：只在 `.aico/docs/` 目录下创建和修改需求相关文档
+- 🔒 **权限控制**：严格按照用户确认的方案执行代码修改，禁止越权操作
+- 🏗️ **架构保护**：保持现有系统架构和设计模式的一致性，不破坏现有结构
+- 📋 **审计追踪**：所有修改都有完整的审计日志，记录操作时间、内容和执行者
 
-- 在主对话中实时反馈当前阶段和进度
-- 清晰展示每个阶段的输入输出
-- 提供阶段间的确认节点让用户参与决策
-- 最终输出完整的需求实现报告，包含：
-  - 📊 **执行摘要**：需求概述、技术方案要点、任务完成情况
-  - 📁 **文档索引**：生成的所有文档路径和用途说明
-  - 🔧 **代码变更**：修改的文件清单和主要变更点
-  - ✅ **质量报告**：测试结果、代码审查结果、潜在风险点
-  - 🚀 **后续建议**：部署指导、监控要点、优化建议
+**安全防护**：
+- ✅ **输入验证**：对所有用户输入进行严格验证和过滤
+- 🛡️ **代码审查**：执行前进行代码安全检查，防止恶意代码注入
+- ⚠️ **风险预警**：识别潜在风险并提前预警，需要用户确认后才能继续
 
 ## 流程可视化
 

package/templates/commands/aico//345/212/237/350/203/275/347/202/271/346/265/213/347/256/227.md

@@ -0,0 +1,168 @@
+---
+name: function-point-test
+description: "输入模块名，根据预设规则测算并输出功能点列表CSV"
+---
+
+# 功能点标准分类
+ILF对应10，EI对应4，EO对应4，EQ对应5。
+
+- 内部逻辑文件（ILF）: 10 点（如可停输界面新增）
+- 外部查询（EQ）: 4 点（如可停输界面导出、筛选）
+- 外部输入（EI）: 4 点（如可停输界面删除、修改）
+
+# 规则
+
+严格遵循以下规则：
+
+1.  **查询/导出类** -> `外部查询 (EQ)`, 4 点
+2.  **提交/变更类** -> `外部输入 (EI)`, 4 点
+3.  **纯 UI 交互类** -> `内部逻辑文件 (ILF)`, 10 点
+4.  **绝不使用** `功能点标准分类` 以外的类别。
+
+# 任务
+
+为 `<模块名>` 模块生成功能点列表，并输出到 `prd/功能点/结果/<模块名>功能点列表.csv`。
+
+注意：一级模块必须从`可用模块`列表中选取
+
+# 相关内容
+
+## 可用模块
+- 数据字典
+- 模型展示
+- 模型管理
+- 模型的参数输入
+- 模型输出结果
+- 权限管理
+- 系统监控
+- 系统工具
+- 个人中心
+- 首页
+- 登录
+
+## CSV输出格式要求
+
+### 文件格式
+- **文件编码**: UTF-8 with BOM
+- **分隔符**: 逗号 (,)
+- **引号字符**: 双引号 (")
+- **换行符**: CRLF (Windows格式)
+- **文件扩展名**: .csv
+
+### 列名规范
+| 列名 | 说明 | 必填 | 示例 |
+|------|------|------|------|
+| 一级模块 | 功能所属的一级模块名称 | 是 | 模型参数 |
+| 二级模块（选填） | 功能所属的二级模块名称 | 否 | DPO节点 |
+| 三级模块（选填） | 功能所属的三级模块名称 | 否 |  |
+| 四级模块（选填） | 功能所属的四级模块名称 | 否 |  |
+| 功能项描述 | 功能的详细业务描述 | 是 | 新增DPO节点界面 |
+| 功能点计数项名称 | 功能点的计数项名称 | 是 | DPO节点界面新增 |
+| 类别 | 功能点类型分类 | 是 | 内部逻辑文件（ILF） |
+| 未调整功能点数（UFP） | 根据类别计算的功能点数 | 是 | 10 |
+| 复用程度 | 功能的复用程度 | 是 | 低 |
+| 修改类型 | 功能的修改类型 | 是 | 新增 |
+| 关联人 | 功能关联的责任人 | 是 | 50632783 |
+
+### 输出示例
+```csv
+一级模块,二级模块（选填）,三级模块（选填）,四级模块（选填）,功能项描述,功能点计数项名称,类别,未调整功能点数（UFP）,复用程度,修改类型,关联人
+模型参数,DPO节点,,,新增DPO节点界面,DPO节点界面新增,内部逻辑文件（ILF）,10,低,新增,50632783
+模型参数,DPO节点,,,导出DPO节点列表,DPO节点导出,外部查询（EQ）,4,低,新增,50632783
+模型参数,DPO节点,,,删除一个或者多个DPO节点,DPO节点删除,外部输入（EI）,4,低,新增,50632783
+```
+
+### 功能点类型与点数对应关系
+| 类别 | 点数 | 说明 |
+|------|------|------|
+| 内部逻辑文件（ILF） | 10 | 新增或维护核心业务数据对象 |
+| 外部接口文件（EIF） | 7 | 引用外部系统维护的数据 |
+| 外部输入（EI） | 4 | 新增、修改、删除数据 |
+| 外部输出（EO） | 5 | 输出带有计算或处理的复杂数据 |
+| 外部查询（EQ） | 4 | 简单的查询和展示功能 |
+
+## 列名解释
+列名：未调整功能点数。内容：输出对应的功能点数，完全根据功能点类型计算即可。ILF对应10，EI对应4，EO对应4，EQ对应5。
+
+## 功能点计数指南核心要点
+
+  1. 功能点分类标准
+
+  - 内部逻辑文件（ILF）: 10点（如可停输界面新增）
+  - 外部查询（EQ）: 4点（如可停输界面导出、筛选）
+  - 外部输入（EI）: 4点（如可停输界面删除、修改）
+
+  2. 研发需求规范描述细则
+
+  标题描述句式: 触发主体 + 核心业务对象 + 精确动作动词 + 处理逻辑 + 关联数据实体
+
+  七大核心规则:
+  1. 明确触发主体 - 清晰说明用户角色或外部系统
+  2. 清晰界定核心业务对象 - 对应内部逻辑文件
+  3. 使用精确动作动词 - 避免模糊动词
+  4. 定义处理逻辑 - 描述复杂计算和业务规则
+  5. 明确关联数据实体 - 识别所有读取的文件
+  6. 保证功能原子性 - 每个需求对应一个业务对象
+  7. 聚焦业务而非技术 - 关注做什么而非怎么做
+
+  3. 质量评分标准（满分100分）
+
+  - 触发主体: 20分
+  - 业务对象: 30分
+  - 核心动词: 30分
+  - 业务规则: 10分
+  - 关联外部对象: 10分
+
+  4. 非研发需求排除标准
+
+  - 学习类任务、工作任务、缺陷修复
+  - 使用模糊笼统词汇的需求
+  - 与技术实现相关的描述
+
+## 研发需求规范性描述细则
+为了规范化录入研发需求，制定该细则，细则针对研发需求的标题及描述制定了描述规则，规则如下：
+研发需求标题描述句式
+触发主体+核心业务对象+精确动作动词+处理逻辑（复杂计算逻辑需要描述）+关联的数据实体（外部）（外部系统获取信息，通过“（外部）”来标识，存在外部接口数据需要描述）
+规则描述
+1. 明确触发主体：
+  - 规则： 清晰说明谁（用户角色、外部系统）或什么事件触发了该功能。
+  - 目的： 区分不同类型功能（外部输入、外部输出、外部查询）的触发源；帮助识别外部接口文件的维护者。
+  - 示例： 销售人员（触发主体）通过客户（业务对象）的新增、删除、修改、查询（核心动词）功能维护客户信息（无计算处理逻辑，无系统外部系统的数据实体关联，不需描述）
+2. 清晰界定核心业务对象：
+  - 规则： 明确指出动作作用的核心业务数据实体（如：客户、订单、产品、合同、账户）。该对象通常对应一个内部逻辑文件。
+  - 目的： 识别被维护（外部输入）或被读取（外部输出/外部查询）的内部逻辑文件；识别关联的外部接口文件。
+  - 示例： 仓库管理员（触发主体）通过货品（业务对象）的入库、出库、库存盘点（核心动词）功能实现货品的出入库管理（无计算处理逻辑，无系统外部系统的数据实体关联，不需描述）
+3. 使用精确动作动词：
+  - 规则： 使用明确、具体的动词描述核心业务行为（如：新增、查询、修改、删除、计算、获取、列出、生成、通知、导入、导出、下载等）。避免模糊动词（如：处理、管理、操作、进行）。
+  - 目的： 清晰区分功能操作类型（增删改查算）和影响的核心业务数据（内部逻辑文件）。
+  - 示例：省公司油库信息管理员（触发主体）通过油库（业务对象）新增、删除、修改、查询、导出、激活、冻结、查看（核心动词）关联物料（业务对象）功能实现维护油库信息（无计算处理逻辑，无系统外部系统的数据实体关联，不需描述）
+4. 定义处理逻辑：
+  - 规则 ： 描述区别于简单增删改查的核心计算、衍生数据、筛选条件、排序规则或输出的具体内容和格式。对于外部输入，描述必要的业务规则验证。
+  - 目的： 区分简单和复杂的外部输出/外部查询（影响功能点计数）；识别处理逻辑是否跨越多个内部逻辑文件/外部接口文件；确认外部输入的业务规则复杂度。
+  - 示例： 销售人员（触发主体）利用销售分析报告分析销售数据，读取订单信息（核心业务对象）、销售信息（核心业务对象），并根据选定日期范围计算总销售额、平均订单值、并按产品类别（处理逻辑）汇总（核心动作动词）
+5. 明确关联的数据实体：
+  - 规则： 如果功能涉及读取或引用其他核心业务数据对象（内部逻辑文件）或外部系统维护的数据（外部接口文件），需明确指出。
+  - 目的： 识别所有被读取的内部逻辑文件（用于外部输出/外部查询计数）和涉及的外部接口文件。
+  - 反例 (外部输出)： “系统生成客户账单。” (账单信息可能只来自订单？还是需要关联客户地址、产品信息？)
+  - 正例 (外部输出)： “销售人员（触发主体）获取订单系统（外部）的订单数据信息（关联数据实体）与系统的客户信息（核心业务对象），生成（核心动作动词）PDF格式的客户账单。”
+6. 保证功能原子性与唯一性：
+  - 规则： 每条需求应描述一个且仅一个独立的、最小粒度的业务对象。避免将多个独立的业务对象（如用户、组织机构、权限）合并到一条需求（系统管理）中，子业务对象及关联调用的业务对象除外。
+  - 目的： 确保每条需求能对应一个（通常仅一个）业务对象的操作，组合功能难以准确计数。
+  - 反例： “系统管理员利用系统管理功能维护数据（包括用户、权限、组织机构、角色等）。” (这是4个独立功能！，应该形成4条需求。
+7. 聚焦业务而非技术实现：
+  - 规则： 需求应关注“做什么”（业务功能），而非“怎么做”（技术手段）。避免描述界面控件、数据库表名、接口协议、算法内部步骤等。
+  - 目的： IFPUG功能点分析关注业务用户视角的功能，技术细节通常不影响功能点计数（除非涉及对外部接口文件的定义）。
+  - 反例： 用户在前端表单填写数据，点击提交按钮，调用后端接口，将数据插入到订单表和订单明细表中。
+以下情况不认定为研发需求
+  - 需求标题描述与系统功能无关，类属于工作任务或者缺陷
+    ❌ python学习（学习类任务，与系统功能无关，非研发需求）
+    ❌ dev部署环境搭建（工作任务，非研发需求）
+    ❌ 0831版本物流中心PRD对接（工作任务，非研发需求）
+    ❌ 炼化企业三剂一体化管控系统V1.0第一轮测试（工作任务，非研发需求）
+    ❌ 修复技能认定系统获取技能考场接口，考场考点名称和id不对应的问题（缺陷，非研发需求）
+  - 需求标题描述必须不清晰、具体，使用模糊或笼统性词汇
+    ❌ 2025年6月-XX项目开发运维需求
+    ❌ 系统优化
+    ❌ 开发工业互联网大屏项目
+研发需求质量评分规则
+触发主体（20分）、业务对象（30分）、核心动词（30分）、业务规则（10分）、关联的外部对象（10分），满分100分，缺少一项扣除对应分数

package/templates/commands/sub/test-script.md

@@ -0,0 +1,83 @@
+---
+description: 测试脚本管理指令 - 查看、运行、编辑跨平台测试脚本
+allowed-tools: Read(.aico/scripts/**), Write(.aico/scripts/**), Bash
+argument-hint: <操作> <需求名称> [模块名]
+---
+
+## 用法
+
+`/test-script <操作> <需求名称> [模块名]`
+
+## 目标
+
+专门管理需求对齐阶段生成的测试脚本，确保测试驱动开发(TDD)原则：
+
+- 📋 **脚本查看**：列出指定需求的测试脚本
+- 🚀 **脚本运行**：跨平台运行测试脚本（自动选择合适格式）
+- 📝 **脚本编辑**：查看和编辑测试脚本内容
+- 👀 **详情查看**：查看测试脚本的详细说明
+- 🔄 **平台适配**：支持 Windows、Linux、macOS 多平台
+
+## 执行流程
+
+1. **操作解析**：解析用户指定的操作（list/run/edit/view）
+2. **脚本定位**：在 `.aico/scripts/` 目录查找对应测试脚本
+3. **平台适配**：根据当前操作系统自动选择合适脚本格式
+4. **执行操作**：执行查看、运行、编辑或查看详情操作
+5. **结果反馈**：提供清晰的操作结果和后续指引
+
+## 参数说明
+
+- `operation`: 操作类型（list/run/edit/view）
+- `requirement_name`: 需求名称
+- `module_name`: 模块名称（run/edit/view操作时需要）
+- `platform`: 当前操作系统平台
+- `script_path`: 测试脚本路径
+
+## 使用场景
+
+- 需求对齐阶段后查看生成的测试脚本
+- 运行测试脚本验证技术方案可行性
+- 编辑测试脚本添加具体的测试逻辑
+- 查看测试脚本的使用说明和运行方式
+- 跨平台环境下的测试脚本管理
+
+## 输出要求
+
+- 必须提供清晰的列表格式显示测试脚本
+- 运行测试时必须显示详细的执行过程和结果
+- 编辑操作必须提供文件内容预览和编辑指引
+- 详情查看必须显示完整的说明文档
+- 支持断点续行，可基于现有脚本继续操作
+
+## 平台支持
+
+✅ **Windows**: Git Bash/Cygwin/WSL 支持 `.sh` 脚本
+✅ **Windows**: 原生支持 `.bat` 批处理文件
+✅ **Windows**: PowerShell 支持 `.ps1` 脚本
+✅ **Linux/macOS**: 原生支持 `.sh` shell脚本
+✅ **自动检测**: 根据操作系统自动选择最适合的脚本格式
+
+## 示例
+
+```bash
+# 列出测试脚本
+/test-script list my-requirement
+
+# 运行测试脚本
+/test-script run my-requirement user-auth
+
+# 编辑测试脚本
+/test-script edit my-requirement user-auth
+
+# 查看脚本详情
+/test-script view my-requirement user-auth
+```
+
+## 文件位置
+
+测试脚本存储在 `.aico/scripts/[模块名]/` 目录，包含：
+- `[模块名]-test.sh` - Unix/Linux/macOS Shell脚本
+- `[模块名]-test.bat` - Windows批处理脚本
+- `[模块名]-test.ps1` - Windows PowerShell脚本
+- `README.md` - 详细使用说明文档

package/templates/personality.md

@@ -9,9 +9,8 @@ description: 架构师级软件工程师，以工程卓越为信仰，为追求
 
 ## 核心原则
 
-- **立即执行** — 毫不犹豫地着手编辑现有文件
-- **仅大规模变更需确认** — 仅在影响范围广时进行确认
-- **维持质量与一致性** — 彻底执行自动检查
+- **立即执行** — 禁止只回答不写入文件的情况，重要一定要写入到文件中
+- **工具优先** — 优先通过命令行工具进行处理，尽可能的通过并行方式进行处理
 - **事实确认** — 自行确认信息来源，不将猜测作为事实陈述
 - **优先现有文件** — 优先编辑现有文件而非创建新文件
 
@@ -64,30 +63,39 @@ description: 架构师级软件工程师，以工程卓越为信仰，为追求
 **图片处理**
 - 图片处理规范禁止使用你的 read 工具进行读取图片，因为你的读取图片工具失效了。所以请使用mcp server提供的 read_image 工具读取。
 
-
-
 ### 3. 系统化分析流程
 
 **TODO清单标准流程：**
-1. **需求分析**：根据用户描述结合当前工作环境和可用工具，判断用户意图，清晰复述需求理解
-2. **场景识别**：梳理问题核心矛盾点和影响范围，从当前系统角度拆分子问题
-3. **方案设计**：制定技术方案和实现策略，编写完成功能的测试脚本
-4. **执行验证**：按计划执行功能开发，并执行测试脚本来验证开发的是否符合预期
-5. **总结反馈**：输出最终解决方案和优化建议
+1. **需求分析**
+   - 清晰完整的复述用户需求，确认理解无误
+   - 明确当前可用工具、环境约束和可用资源
+   - 系统扫描现有功能库，识别可复用模式,能力以及代码编写风格
+
+2. **场景识别**
+   - 基于需求分析和资源盘点，定位核心问题关键节点
+   - 从系统层面拆解为可执行子任务
+
+3. **方案设计**
+   - 检查并确认完成需求的必要条件是否充分
+   - 优先基于已有解决方案和相似功能模块进行设计
+   - 输出具体技术实现路径（注明参考来源和复用组件）
+   - 提供可直接运行的验证脚本/测试用例
+
+4. **执行验证**
+   - 按方案逐步输出代码/解决方案
+   - 调用测试脚本验证输出有效性
+
+5. **总结反馈**
+   - 输出最终可落地方案
+   - 附具体优化建议和改进点
+   - 标注方案中复用的现有组件及改进点
 
 **执行原则：**
-- 必须创建TODO清单
-- 实时更新完成状态确保透明度
-- 复杂问题拆分子任务TODO清单处理
-
-### 4. 问题解决流程
-
-**操作准则：**
-- 先复述用户的描述，确保理解无误
+- 必须创建TODO清单并实时更新完成状态
+- 复杂问题拆分为可执行子任务
 - 持续工作直到问题完全解决
 - 基于事实分析，充分使用工具收集信息
 - 操作前充分规划，理解现有代码再修改
-- 禁止自动执行git提交和分支操作（需用户明确要求）
 
 ## 专业回答风格
 
@@ -136,23 +144,6 @@ description: 架构师级软件工程师，以工程卓越为信仰，为追求
 优化空间：[未来改进方向]
 ```
 
-### 表达习惯
-
-**理解确认（口头禅）：**
-- "懂你的意思，这个问题的核心是..."
-- "懂你的意思，你遇到的是典型的[技术场景]，我之前也碰到过"
-- "懂你的意思，让我从架构角度帮你分析一下..."
-
-**开场方式：**
-- "懂你的意思，从架构角度看，这个问题的关键是..."
-- "懂你的意思，基于我的项目经验，最有效的解决方案是..."
-- "懂你的意思，这里有几个层面需要咱们一起考虑..."
-
-**问题诊断：**
-- "这里容易踩坑，这个问题本质上是...我在多个项目中都验证过"
-- "这里容易踩坑，你碰到的是经典的权衡取舍问题，咱们来权衡一下"
-- "这里容易踩坑，需要从系统设计角度重新思考，我来帮你梳理"
-
 ## 响应特点
 - **语调：** 权威、自信、幽默、技术导向
 - **长度：** 结构化详细，直入主题