⚡

AI辅助任务分解与实施计划制定Skill ai-factory.task

这个技能利用人工智能自动生成详细的任务分解和实施计划，帮助用户将复杂项目分解为可执行、可追踪的步骤，提高项目管理效率。适用于软件开发、产品管理、团队协作等领域。关键词：AI计划制定、任务分解、实施计划、项目管理、自动化工具、智能辅助。

项目管理 0 次安装 0 次浏览 更新于 3/18/2026

name: ai-factory.task description: 为功能或任务创建一个逐步的实现计划。将工作分解为通过任务系统追踪的可操作任务。当用户说“计划”、“创建任务”、“分解”或“为…制定计划”时使用。 argument-hint: <任务描述> allowed-tools: Read Write Glob Grep Bash(git *) TaskCreate TaskUpdate TaskList AskUserQuestion Questions disable-model-invocation: false

任务 - 实施计划制定

创建一个详细、可操作的实施计划，分解为可追踪的任务。

工作流程

步骤 0：加载项目上下文

首先： 如果存在，读取 .ai-factory/DESCRIPTION.md 以了解：

  • 技术栈（语言、框架、数据库、ORM）
  • 项目架构
  • 编码规范
  • 非功能性需求（日志记录、错误处理）

使用此上下文当：

  • 探索代码库（知道要查找的模式）
  • 编写任务描述（使用正确的技术）
  • 规划文件结构（遵循项目规范）

步骤 0.1：确保 Git 并确定计划文件

检查 Git 仓库：

git rev-parse --is-inside-work-tree 2>/dev/null || git init

确定计划文件名：

  1. 如果从 /ai-factory.feature 调用 - 使用传递的计划文件名（例如，.ai-factory/features/feature-user-auth.md）

  2. 如果直接调用（/ai-factory.task） - 始终使用 .ai-factory/PLAN.md

    • 不要检查当前分支
    • 直接任务规划 = 临时计划在 .ai-factory/PLAN.md 中

步骤 1：分析需求

从 $ARGUMENTS 中识别：

  • 要实施的核心功能
  • 需要更改的组件/文件
  • 任务之间的依赖关系
  • 需要处理的边缘情况

步骤 2：询问澄清问题（如果需要）

如果需求模糊：

在创建计划之前，我需要一些澄清：

1. [关于范围的具体问题]
2. [关于方法的问题]

步骤 3：检查测试偏好

如果未指定（从 /ai-factory.feature），询问：

我应该在计划中包含测试任务吗？
- [ ] 是，包含测试
- [ ] 否，跳过测试

重要： 如果用户对测试说否：

  • 不要创建任何测试相关任务
  • 不要在任务描述中提及测试
  • 不要添加“编写测试”步骤

步骤 4：探索代码库

在规划之前，理解现有代码：

  • 找到相关文件和模式
  • 识别需要更改的地方
  • 注意要遵循的现有规范

步骤 5：创建任务计划

使用 TaskCreate 创建任务，包含清晰、可操作的项目：

## 实施计划：[功能名称]

### 任务：

1. **[任务主题]**
   描述：[需要完成的内容]
   文件：[要修改/创建的文件]

2. **[任务主题]**
   描述：[需要完成的内容]
   文件：[要修改/创建的文件]

...

任务指南：

  • 每个任务应可在一次专注会话中完成
  • 任务应按依赖关系排序（先做 X 后做 Y）
  • 包含更改将进行的文件路径
  • 具体说明要实施的内容，不要模糊

步骤 6：设置依赖关系

使用 TaskUpdate 设置 blockedBy 关系：

  • 如果任务 2 依赖于任务 1 的输出，则任务 2 被任务 1 阻塞
  • 保持依赖链逻辑性

步骤 7：保存计划到文件

将计划写入确定的计划文件：

# 实施计划：[功能名称]

分支：[当前分支或“无”]
创建日期：[日期]

## 设置
- 测试：是/否
- 日志记录：详细/标准/最小
- 文档：是/否

## 提交计划
<!-- 对于有 5+ 任务的情况，定义提交检查点 -->
- **提交 1**（任务 1-3 后）：“feat: 添加基础模型和类型”
- **提交 2**（任务 4-6 后）：“feat: 实现核心服务逻辑”
- **提交 3**（任务 7-8 后）：“feat: 添加 API 端点”

## 任务

### 阶段 1：设置
- [ ] 任务 1：[描述]
- [ ] 任务 2：[描述]

### 阶段 2：核心实施
- [ ] 任务 3：[描述]（依赖于 1、2）
- [ ] 任务 4：[描述]
<!-- 🔄 提交检查点：任务 1-4 -->

### 阶段 3：集成
- [ ] 任务 5：[描述]（依赖于 3、4）
<!-- 🔄 提交检查点：任务 5+ -->

提交计划规则：

  • 5+ 任务 → 每 3-5 个任务添加提交检查点
  • 少于 5 任务 → 最后单一提交，无需提交计划
  • 将逻辑相关任务分组到一个提交中
  • 建议有意义的提交消息，遵循常规提交规范

保存前，确保目录存在：

mkdir -p .ai-factory/features  # 仅当保存到 features/

保存到：.ai-factory/PLAN.md（直接调用）或 .ai-factory/features/<分支名称>.md（从 /ai-factory.feature）

步骤 8：确认计划

呈现给用户：

计划已保存到：[文件名].md

准备开始？使用 `/ai-factory.implement` 开始执行。

任务创建格式

TaskCreate:
  subject: “实施用户登录端点”
  description: |
    创建 POST /api/auth/login 端点，要求：
    - 接受邮箱和密码
    - 根据数据库验证凭证
    - 成功时返回 JWT 令牌
    - 无效凭证时返回 401

    文件：src/api/auth/login.ts, src/services/auth.ts
  activeForm: “实施登录端点”

示例

示例 1：API 功能（无测试）

输入： /ai-factory.task 添加产品搜索 API 测试： 否

计划：

  1. 创建带有过滤逻辑的搜索服务
  2. 添加 GET /api/products/search 端点
  3. 实现查询参数解析
  4. 添加分页支持
  5. 更新 API 文档

（无测试任务包含）

示例 2：完整功能（有测试）

输入： /ai-factory.task 添加产品搜索 API 测试： 是

计划：

  1. 创建带有过滤逻辑的搜索服务
  2. 添加 GET /api/products/search 端点
  3. 实现查询参数解析
  4. 添加分页支持
  5. 编写搜索服务的单元测试
  6. 编写搜索端点的集成测试
  7. 更新 API 文档

重要规则

  1. 如果用户说否，无测试 - 不要偷偷加入测试任务
  2. 无报告 - 不要在最后创建总结/报告任务
  3. 可操作任务 - 每个任务应有清晰可交付成果
  4. 正确粒度 - 不要太大（压倒性），不要太小（噪音）
  5. 依赖关系重要 - 排序任务以便顺序完成
  6. 包含文件路径 - 帮助实施者知道在哪里工作
  7. 大型计划的提交检查点 - 5+ 任务需要提交计划，每 3-5 个任务有检查点
  8. 直接调用的 .ai-factory/PLAN.md - 直接调用时始终使用 .ai-factory/PLAN.md，分支命名文件仅来自 /ai-factory.feature

关键：任务描述中的日志记录

每个任务描述必须包括日志记录要求。 AI 生成的代码常有微妙错误 - 详细日志记录对调试至关重要。

编写任务描述时，包括：

  • 要记录的内容（输入、输出、状态变化、错误）
  • 日志格式建议（尽可能使用结构化 JSON）
  • 日志关键检查点

带日志记录的任务示例

TaskCreate:
  subject: “实施订单处理服务”
  description: |
    创建带有 processOrder 方法的 OrderService，要求：
    - 验证订单数据
    - 使用税金计算总计
    - 提交到支付网关
    - 返回确认

    日志记录要求：
    - 记录函数入口，包括订单 ID 和项目数量
    - 记录验证结果（通过/失败及原因）
    - 记录支付网关请求和响应
    - 记录任何错误，包含完整上下文（订单状态、错误详情）
    - 使用格式：[ServiceName.method] 消息 {数据}
    - 使用日志级别（DEBUG/INFO/WARN/ERROR）
    - 使日志可通过 LOG_LEVEL 环境变量配置

    文件：src/services/order.ts
  activeForm: “实施订单服务”

可配置日志记录

任务描述应指定日志必须：

  • 基于级别 - DEBUG 用于详细，INFO 用于重要事件，ERROR 用于失败
  • 环境控制 - LOG_LEVEL 或 DEBUG 环境变量
  • 轮换感知 - 对于文件日志，提及轮换要求
  • 生产安全 - 可在无代码更改下减少

不要创建没有日志记录说明的任务 - 这会导致难以调试的实施。

规划后

告诉用户：

计划已创建，包含 [N] 个任务。
计划文件：[文件名].md

要开始实施，运行：
/ai-factory.implement

要查看任务：
/tasks（或使用 TaskList）

上下文清理

规划后上下文较重。所有结果已保存到计划文件 - 建议释放空间：

AskUserQuestion: 继续前释放上下文？

选项：
1. /clear — 完全重置（推荐）
2. /compact — 压缩历史
3. 保持现状

计划文件处理

.ai-factory/PLAN.md（直接 /ai-factory.task 调用）：

  • 快速任务的临时计划
  • 完成后，/ai-factory.implement 会询问删除
  • 不绑定任何分支

分支命名文件（从 /ai-factory.feature）：

  • 功能工作的永久文档
  • /ai-factory.implement 不会建议删除
  • 用户在合并前决定保留或删除