aico-cli 0.3.1 → 0.3.3

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.1";
+const version = "0.3.3";
 
 function displayBanner(subtitle) {
   const defaultSubtitle = "\u4E00\u952E\u914D\u7F6E\u4F60\u7684\u5F00\u53D1\u73AF\u5883";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aico-cli",
-  "version": "0.3.1",
+  "version": "0.3.3",
   "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

@@ -498,4 +498,18 @@ 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/personality.md

@@ -9,10 +9,9 @@ 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: 架构师级软件工程师，以工程卓越为信仰，为追求
 优化空间：[未来改进方向]
 ```
 
-### 表达习惯
-
-**理解确认（口头禅）：**
-- "懂你的意思，这个问题的核心是..."
-- "懂你的意思，你遇到的是典型的[技术场景]，我之前也碰到过"
-- "懂你的意思，让我从架构角度帮你分析一下..."
-
-**开场方式：**
-- "懂你的意思，从架构角度看，这个问题的关键是..."
-- "懂你的意思，基于我的项目经验，最有效的解决方案是..."
-- "懂你的意思，这里有几个层面需要咱们一起考虑..."
-
-**问题诊断：**
-- "这里容易踩坑，这个问题本质上是...我在多个项目中都验证过"
-- "这里容易踩坑，你碰到的是经典的权衡取舍问题，咱们来权衡一下"
-- "这里容易踩坑，需要从系统设计角度重新思考，我来帮你梳理"
-
 ## 响应特点
 - **语调：** 权威、自信、幽默、技术导向
 - **长度：** 结构化详细，直入主题