[aide] task-optimize: 开始任务准备: 重写 README.md，提供快速上手指南
This commit is contained in:
@@ -1,38 +1,224 @@
|
||||
# Aide 默认配置（由 aide init 生成）
|
||||
# runtime: aide 自身运行要求
|
||||
# task: 任务文档路径
|
||||
# env: 环境模块配置
|
||||
# flow: 环节名称列表，供流程校验使用
|
||||
################################################################################
|
||||
# Aide 配置文件 (config.toml)
|
||||
################################################################################
|
||||
#
|
||||
# 本配置文件为 Aide 工作流体系的核心配置，由 `aide init` 命令生成。
|
||||
# 所有配置项都有详细说明，用户可仅通过本文件了解所有支持的功能。
|
||||
#
|
||||
# 配置操作说明：
|
||||
# - 读取配置：aide config get <key> 例：aide config get flow.phases
|
||||
# - 设置配置：aide config set <key> <value> 例：aide config set task.source "my-task.md"
|
||||
# - 支持点号分隔的嵌套键，如：env.venv.path
|
||||
#
|
||||
# 注意：LLM 不应直接编辑此文件，必须通过 aide 命令操作。
|
||||
#
|
||||
################################################################################
|
||||
|
||||
################################################################################
|
||||
# [general] - 通用配置
|
||||
################################################################################
|
||||
# 控制 Aide 的全局行为设置。
|
||||
|
||||
[general]
|
||||
# 是否在 .gitignore 中忽略 .aide 目录
|
||||
# - true（默认）：自动添加 .aide/ 到 .gitignore，不跟踪 aide 状态
|
||||
# - false：不修改 .gitignore，允许 git 跟踪 .aide 目录
|
||||
# 适用于需要在多设备同步 aide 状态的场景
|
||||
gitignore_aide = false
|
||||
|
||||
################################################################################
|
||||
# [runtime] - Aide 运行时要求
|
||||
################################################################################
|
||||
# 定义 aide 程序本身的运行环境要求。
|
||||
# 这些配置用于 `aide env ensure --runtime` 检测。
|
||||
|
||||
[runtime]
|
||||
# Python 最低版本要求
|
||||
# 格式："主版本.次版本"，如 "3.11"、"3.12"
|
||||
python_min = "3.11"
|
||||
|
||||
# 是否要求使用 uv 包管理器
|
||||
# - true：检测 uv 是否安装
|
||||
# - false：不检测 uv
|
||||
use_uv = true
|
||||
|
||||
################################################################################
|
||||
# [task] - 任务文档配置
|
||||
################################################################################
|
||||
# 定义任务相关文档的默认路径。
|
||||
|
||||
[task]
|
||||
# 任务原文档路径（用户提供的原始任务描述）
|
||||
# /aide:prep 命令在未指定参数时读取此文件
|
||||
source = "task-now.md"
|
||||
|
||||
# 任务细则文档路径（aide 生成的可执行任务细则）
|
||||
# /aide:exec 命令在未指定参数时读取此文件
|
||||
spec = "task-spec.md"
|
||||
|
||||
################################################################################
|
||||
# [env] - 环境检测配置
|
||||
################################################################################
|
||||
# 配置项目的开发环境检测模块。
|
||||
#
|
||||
# 模块分为两类：
|
||||
# 类型A - 无需配置即可检测（全局工具）：
|
||||
# python - Python 解释器版本检测
|
||||
# uv - uv 包管理器检测
|
||||
# rust - Rust 工具链（rustc + cargo）检测
|
||||
# node - Node.js 运行时检测
|
||||
# flutter - Flutter SDK 检测
|
||||
# android - Android SDK 检测
|
||||
#
|
||||
# 类型B - 需要配置路径才能检测（项目级）：
|
||||
# venv - Python 虚拟环境
|
||||
# requirements - Python 依赖文件（requirements.txt）
|
||||
# node_deps - Node.js 项目依赖（package.json）
|
||||
#
|
||||
# 模块实例化（多项目场景）：
|
||||
# 格式：模块类型:实例名
|
||||
# 例如：node_deps:frontend、node_deps:backend
|
||||
# 各实例独立配置：[env."node_deps:frontend"]
|
||||
|
||||
[env]
|
||||
# 启用的模块列表
|
||||
# 只有列在此处的模块才会被 `aide env ensure` 检测
|
||||
# 示例：
|
||||
# - 纯 Python 项目：["python", "uv", "venv", "requirements"]
|
||||
# - Rust 项目：["rust"]
|
||||
# - Node.js 项目：["node", "node_deps"]
|
||||
# - 多语言项目：["python", "uv", "venv", "node", "node_deps:frontend"]
|
||||
modules = ["python", "uv", "venv", "requirements"]
|
||||
|
||||
# -------------------------------
|
||||
# 以下为各模块的详细配置示例
|
||||
# -------------------------------
|
||||
|
||||
# Python 版本要求（可选，默认使用 runtime.python_min）
|
||||
# [env.python]
|
||||
# min_version = "3.11"
|
||||
|
||||
# 虚拟环境配置（类型B模块，必须配置）
|
||||
# Rust 版本要求（可选）
|
||||
# [env.rust]
|
||||
# min_version = "1.70"
|
||||
|
||||
# Node.js 版本要求（可选）
|
||||
# [env.node]
|
||||
# min_version = "18"
|
||||
|
||||
# Flutter 版本要求（可选）
|
||||
# [env.flutter]
|
||||
# min_version = "3.0"
|
||||
|
||||
# 虚拟环境配置（类型B模块，启用时必须配置）
|
||||
# path: 虚拟环境目录路径，相对于项目根目录
|
||||
[env.venv]
|
||||
path = ".venv"
|
||||
|
||||
# 依赖文件配置（类型B模块，必须配置）
|
||||
# Python 依赖文件配置（类型B模块，启用时必须配置）
|
||||
# path: requirements.txt 文件路径，相对于项目根目录
|
||||
[env.requirements]
|
||||
path = "requirements.txt"
|
||||
|
||||
# Node.js 依赖配置示例（类型B模块）
|
||||
# 注意：需先在 modules 中添加 "node_deps" 才会生效
|
||||
# [env.node_deps]
|
||||
# path = "." # package.json 所在目录
|
||||
# manager = "npm" # 包管理器：npm、yarn、pnpm
|
||||
|
||||
# 多项目实例化示例（前端 + 后端分离项目）
|
||||
# modules = ["node_deps:frontend", "node_deps:backend"]
|
||||
#
|
||||
# [env."node_deps:frontend"]
|
||||
# path = "frontend"
|
||||
# manager = "pnpm"
|
||||
#
|
||||
# [env."node_deps:backend"]
|
||||
# path = "backend"
|
||||
# manager = "npm"
|
||||
|
||||
################################################################################
|
||||
# [docs] - 项目文档配置（面向 LLM）
|
||||
################################################################################
|
||||
# 配置面向 LLM 的项目文档系统。
|
||||
# 这些文档用于帮助 LLM 理解项目结构，支持增量更新。
|
||||
|
||||
[docs]
|
||||
# 项目文档目录路径
|
||||
# 存放总导览和各区块文档
|
||||
# 默认：.aide/project-docs
|
||||
path = ".aide/project-docs"
|
||||
|
||||
# 区块计划文档路径
|
||||
# 记录文档区块划分和生成进度，用于多对话续接
|
||||
# 默认：.aide/project-docs/block-plan.md
|
||||
block_plan_path = ".aide/project-docs/block-plan.md"
|
||||
|
||||
################################################################################
|
||||
# [flow] - 流程追踪配置
|
||||
################################################################################
|
||||
# 配置任务执行流程的追踪和校验。
|
||||
|
||||
[flow]
|
||||
# 环节名称列表（有序）
|
||||
# 定义任务执行的标准流程，用于校验环节跳转合法性
|
||||
# 标准环节：
|
||||
# task-optimize - 任务优化阶段（/aide:prep 使用）
|
||||
# flow-design - 流程设计（创建流程图）
|
||||
# impl - 迭代实现
|
||||
# verify - 验证交付
|
||||
# docs - 文档更新
|
||||
# finish - 收尾
|
||||
phases = ["task-optimize", "flow-design", "impl", "verify", "docs", "finish"]
|
||||
|
||||
# 流程图目录路径
|
||||
# 存放 PlantUML 源文件（.puml）和生成的图片（.png）
|
||||
# flow-design 阶段会校验此目录下的 .puml 文件
|
||||
diagram_path = ".aide/diagrams"
|
||||
|
||||
################################################################################
|
||||
# [plantuml] - PlantUML 配置
|
||||
################################################################################
|
||||
# 配置 PlantUML 流程图生成工具。
|
||||
|
||||
[plantuml]
|
||||
# PlantUML jar 文件路径
|
||||
# 支持绝对路径或相对于 aide-program 目录的相对路径
|
||||
# 默认使用 aide-program/lib/plantuml.jar
|
||||
jar_path = "lib/plantuml.jar"
|
||||
|
||||
# Java 命令路径（可选）
|
||||
# 默认使用系统 PATH 中的 java
|
||||
# java_path = "/usr/bin/java"
|
||||
|
||||
################################################################################
|
||||
# [decide] - 待定项确认配置
|
||||
################################################################################
|
||||
# 配置待定项 Web 确认界面。
|
||||
|
||||
[decide]
|
||||
# HTTP 服务起始端口
|
||||
# 如果端口被占用，会自动探测下一个可用端口
|
||||
port = 3721
|
||||
|
||||
# 监听地址
|
||||
# - "127.0.0.1"（默认）：仅本机访问
|
||||
# - "0.0.0.0"：允许外部访问（注意安全风险）
|
||||
bind = "0.0.0.0"
|
||||
|
||||
# 自定义访问地址（可选）
|
||||
# 为空时自动生成为 http://{bind}:{port}
|
||||
# 适用于反向代理或自定义域名场景
|
||||
# 示例：url = "https://decide.example.com"
|
||||
url = "http://m1.dev.net:3721"
|
||||
|
||||
# 超时时间（秒）
|
||||
# - 0（默认）：不超时，等待用户完成
|
||||
# - >0：超时后自动关闭服务
|
||||
timeout = 0
|
||||
|
||||
################################################################################
|
||||
# 配置文件版本信息
|
||||
################################################################################
|
||||
# 本配置文件格式版本，用于未来兼容性检查
|
||||
# _version = "1.1.0"
|
||||
|
||||
@@ -1,65 +0,0 @@
|
||||
{
|
||||
"input": {
|
||||
"task": "测试任务",
|
||||
"source": "test.md",
|
||||
"items": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "认证方式选择",
|
||||
"options": [
|
||||
{
|
||||
"value": "jwt",
|
||||
"label": "JWT Token",
|
||||
"score": 85.0,
|
||||
"pros": [
|
||||
"无状态"
|
||||
],
|
||||
"cons": [
|
||||
"无法主动失效"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "session",
|
||||
"label": "Session",
|
||||
"score": 70.0,
|
||||
"pros": [
|
||||
"简单"
|
||||
],
|
||||
"cons": [
|
||||
"需要存储"
|
||||
]
|
||||
}
|
||||
],
|
||||
"context": "选择合适的认证方式",
|
||||
"recommend": "jwt"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "数据库选择",
|
||||
"options": [
|
||||
{
|
||||
"value": "mysql",
|
||||
"label": "MySQL"
|
||||
},
|
||||
{
|
||||
"value": "postgres",
|
||||
"label": "PostgreSQL"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"output": {
|
||||
"decisions": [
|
||||
{
|
||||
"id": 1,
|
||||
"chosen": "jwt"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"chosen": "mysql"
|
||||
}
|
||||
]
|
||||
},
|
||||
"completed_at": "2025-12-15T02:12:09+08:00"
|
||||
}
|
||||
@@ -1,297 +0,0 @@
|
||||
{
|
||||
"input": {
|
||||
"task": "Aide 工作流体系重构",
|
||||
"source": "statements/1.md",
|
||||
"items": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "新 Commands 命名方案",
|
||||
"options": [
|
||||
{
|
||||
"value": "env_ctx_docs",
|
||||
"label": "/aide:env + /aide:ctx + /aide:docs",
|
||||
"score": 90.0,
|
||||
"pros": [
|
||||
"语义清晰明确",
|
||||
"与功能高度匹配",
|
||||
"简洁易记"
|
||||
],
|
||||
"cons": [
|
||||
"ctx 可能不够直观"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "setup_load_docs",
|
||||
"label": "/aide:setup + /aide:load + /aide:docs",
|
||||
"score": 75.0,
|
||||
"pros": [
|
||||
"动词形式更直观",
|
||||
"setup 表达初始化含义"
|
||||
],
|
||||
"cons": [
|
||||
"setup 与 env ensure 功能重叠",
|
||||
"load 语义较模糊"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "env_init_docs",
|
||||
"label": "/aide:env + /aide:init + /aide:docs",
|
||||
"score": 80.0,
|
||||
"pros": [
|
||||
"保留 init 命名习惯",
|
||||
"env 明确表达环境功能"
|
||||
],
|
||||
"cons": [
|
||||
"init 原本包含更多功能，可能造成混淆"
|
||||
]
|
||||
}
|
||||
],
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 9,
|
||||
"end": 25
|
||||
},
|
||||
"context": "原 init 命令需要拆分为环境管理（cmd-1）和项目认知（cmd-2）两部分，同时新增文档管理命令（cmd-3）。需要确定这三个命令的正式名称。",
|
||||
"recommend": "env_ctx_docs"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "流程图强制要求的例外情况",
|
||||
"options": [
|
||||
{
|
||||
"value": "always_required",
|
||||
"label": "所有任务必须有流程图",
|
||||
"score": 70.0,
|
||||
"pros": [
|
||||
"规则简单统一",
|
||||
"强制规范化思考",
|
||||
"用户审阅体验一致"
|
||||
],
|
||||
"cons": [
|
||||
"简单任务效率降低",
|
||||
"可能流于形式"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "allow_exceptions",
|
||||
"label": "允许简单任务跳过",
|
||||
"score": 85.0,
|
||||
"pros": [
|
||||
"平衡效率和质量",
|
||||
"避免形式主义"
|
||||
],
|
||||
"cons": [
|
||||
"需要定义\"简单任务\"标准",
|
||||
"判断标准可能不一致"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "llm_judgment",
|
||||
"label": "由 LLM 根据复杂度判断",
|
||||
"score": 80.0,
|
||||
"pros": [
|
||||
"灵活适应不同场景",
|
||||
"利用 LLM 判断能力"
|
||||
],
|
||||
"cons": [
|
||||
"判断标准不够稳定",
|
||||
"可能被滥用跳过"
|
||||
]
|
||||
}
|
||||
],
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 58,
|
||||
"end": 66
|
||||
},
|
||||
"context": "任务描述要求\"不论是什么任务，只要有任务就必须有流程图\"。但对于简单任务（如修改文档、单文件小改动），强制流程图可能降低效率。需要确定是否允许例外。",
|
||||
"recommend": "allow_exceptions"
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "PlantUML 依赖处理方式",
|
||||
"options": [
|
||||
{
|
||||
"value": "local_java",
|
||||
"label": "添加 java + plantuml 环境检测模块",
|
||||
"score": 85.0,
|
||||
"pros": [
|
||||
"离线可用",
|
||||
"完全本地化",
|
||||
"渲染速度快"
|
||||
],
|
||||
"cons": [
|
||||
"增加环境依赖",
|
||||
"Java 环境配置可能复杂"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "online_server",
|
||||
"label": "使用在线 PlantUML Server 渲染",
|
||||
"score": 75.0,
|
||||
"pros": [
|
||||
"无需本地环境",
|
||||
"配置简单"
|
||||
],
|
||||
"cons": [
|
||||
"依赖网络",
|
||||
"隐私考虑",
|
||||
"可能有延迟"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "syntax_only",
|
||||
"label": "仅校验语法，不强制本地渲染",
|
||||
"score": 70.0,
|
||||
"pros": [
|
||||
"最小依赖",
|
||||
"快速验证"
|
||||
],
|
||||
"cons": [
|
||||
"无法生成图片",
|
||||
"用户需自行渲染查看"
|
||||
]
|
||||
}
|
||||
],
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 67,
|
||||
"end": 71
|
||||
},
|
||||
"context": "流程图功能依赖 PlantUML，而 PlantUML 需要 Java 环境。需要决定如何处理这个依赖关系。",
|
||||
"recommend": "local_java"
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "任务复杂度判断标准",
|
||||
"options": [
|
||||
{
|
||||
"value": "module_count",
|
||||
"label": "涉及 3 个以上独立模块",
|
||||
"score": 70.0,
|
||||
"pros": [
|
||||
"标准明确可量化",
|
||||
"易于判断"
|
||||
],
|
||||
"cons": [
|
||||
"模块定义可能不清晰",
|
||||
"不适用于所有项目类型"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "code_lines",
|
||||
"label": "预估代码变更超过 500 行",
|
||||
"score": 65.0,
|
||||
"pros": [
|
||||
"量化标准",
|
||||
"与工作量直接相关"
|
||||
],
|
||||
"cons": [
|
||||
"难以准确预估",
|
||||
"代码行数不等于复杂度"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "llm_guidelines",
|
||||
"label": "LLM 综合判断（提供指导原则）",
|
||||
"score": 90.0,
|
||||
"pros": [
|
||||
"灵活适应各种场景",
|
||||
"可结合多维度考量",
|
||||
"避免机械判断"
|
||||
],
|
||||
"cons": [
|
||||
"判断可能有主观性",
|
||||
"需要明确的指导原则"
|
||||
]
|
||||
}
|
||||
],
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 52,
|
||||
"end": 56
|
||||
},
|
||||
"context": "需要在任务分析阶段判断任务复杂度，对过于复杂的任务进行拆分。需要确定判断标准。",
|
||||
"recommend": "llm_guidelines"
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "prep+exec 合并后的命令命名",
|
||||
"options": [
|
||||
{
|
||||
"value": "aide_task",
|
||||
"label": "/aide:task",
|
||||
"score": 90.0,
|
||||
"pros": [
|
||||
"语义明确",
|
||||
"涵盖准备和执行",
|
||||
"任务导向"
|
||||
],
|
||||
"cons": [
|
||||
"与 task 工具可能混淆"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "aide_run",
|
||||
"label": "/aide:run",
|
||||
"score": 80.0,
|
||||
"pros": [
|
||||
"简洁有力",
|
||||
"动作导向"
|
||||
],
|
||||
"cons": [
|
||||
"语义不如 task 完整",
|
||||
"可能暗示只是执行"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "aide_exec",
|
||||
"label": "/aide:exec（保留原名）",
|
||||
"score": 75.0,
|
||||
"pros": [
|
||||
"保持命名连续性",
|
||||
"用户无需重新适应"
|
||||
],
|
||||
"cons": [
|
||||
"原名仅强调执行，不含准备含义"
|
||||
]
|
||||
}
|
||||
],
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 26,
|
||||
"end": 31
|
||||
},
|
||||
"context": "将 prep（任务准备）和 exec（任务执行）合并为一个命令，需要确定新命令的名称。",
|
||||
"recommend": "aide_task"
|
||||
}
|
||||
]
|
||||
},
|
||||
"output": {
|
||||
"decisions": [
|
||||
{
|
||||
"id": 1,
|
||||
"chosen": "setup_load_docs"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"chosen": "always_required"
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"chosen": "local_java",
|
||||
"note": "plantuml的运行使用本地java+本地jar，当前系统环境在`/home/user/env-hub/jar/plantuml.jar`有plantuml的jar包，可以复制到aide-program目录下（并且把复制后的相对路径写入aide程序的配置字段或配置文件中），便于后续统一打包快速启动，"
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"chosen": "llm_guidelines",
|
||||
"note": "你要充分的自由发挥你的创造性和专业性，拟一份详细完善且清晰明确的指导原则"
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"chosen": "aide_run"
|
||||
}
|
||||
]
|
||||
},
|
||||
"completed_at": "2025-12-15T17:42:41+08:00"
|
||||
}
|
||||
@@ -1,272 +0,0 @@
|
||||
{
|
||||
"task": "Aide 工作流体系重构",
|
||||
"source": "statements/1.md",
|
||||
"items": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "新 Commands 命名方案",
|
||||
"options": [
|
||||
{
|
||||
"value": "env_ctx_docs",
|
||||
"label": "/aide:env + /aide:ctx + /aide:docs",
|
||||
"score": 90.0,
|
||||
"pros": [
|
||||
"语义清晰明确",
|
||||
"与功能高度匹配",
|
||||
"简洁易记"
|
||||
],
|
||||
"cons": [
|
||||
"ctx 可能不够直观"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "setup_load_docs",
|
||||
"label": "/aide:setup + /aide:load + /aide:docs",
|
||||
"score": 75.0,
|
||||
"pros": [
|
||||
"动词形式更直观",
|
||||
"setup 表达初始化含义"
|
||||
],
|
||||
"cons": [
|
||||
"setup 与 env ensure 功能重叠",
|
||||
"load 语义较模糊"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "env_init_docs",
|
||||
"label": "/aide:env + /aide:init + /aide:docs",
|
||||
"score": 80.0,
|
||||
"pros": [
|
||||
"保留 init 命名习惯",
|
||||
"env 明确表达环境功能"
|
||||
],
|
||||
"cons": [
|
||||
"init 原本包含更多功能，可能造成混淆"
|
||||
]
|
||||
}
|
||||
],
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 9,
|
||||
"end": 25
|
||||
},
|
||||
"context": "原 init 命令需要拆分为环境管理（cmd-1）和项目认知（cmd-2）两部分，同时新增文档管理命令（cmd-3）。需要确定这三个命令的正式名称。",
|
||||
"recommend": "env_ctx_docs"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "流程图强制要求的例外情况",
|
||||
"options": [
|
||||
{
|
||||
"value": "always_required",
|
||||
"label": "所有任务必须有流程图",
|
||||
"score": 70.0,
|
||||
"pros": [
|
||||
"规则简单统一",
|
||||
"强制规范化思考",
|
||||
"用户审阅体验一致"
|
||||
],
|
||||
"cons": [
|
||||
"简单任务效率降低",
|
||||
"可能流于形式"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "allow_exceptions",
|
||||
"label": "允许简单任务跳过",
|
||||
"score": 85.0,
|
||||
"pros": [
|
||||
"平衡效率和质量",
|
||||
"避免形式主义"
|
||||
],
|
||||
"cons": [
|
||||
"需要定义\"简单任务\"标准",
|
||||
"判断标准可能不一致"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "llm_judgment",
|
||||
"label": "由 LLM 根据复杂度判断",
|
||||
"score": 80.0,
|
||||
"pros": [
|
||||
"灵活适应不同场景",
|
||||
"利用 LLM 判断能力"
|
||||
],
|
||||
"cons": [
|
||||
"判断标准不够稳定",
|
||||
"可能被滥用跳过"
|
||||
]
|
||||
}
|
||||
],
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 58,
|
||||
"end": 66
|
||||
},
|
||||
"context": "任务描述要求\"不论是什么任务，只要有任务就必须有流程图\"。但对于简单任务（如修改文档、单文件小改动），强制流程图可能降低效率。需要确定是否允许例外。",
|
||||
"recommend": "allow_exceptions"
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "PlantUML 依赖处理方式",
|
||||
"options": [
|
||||
{
|
||||
"value": "local_java",
|
||||
"label": "添加 java + plantuml 环境检测模块",
|
||||
"score": 85.0,
|
||||
"pros": [
|
||||
"离线可用",
|
||||
"完全本地化",
|
||||
"渲染速度快"
|
||||
],
|
||||
"cons": [
|
||||
"增加环境依赖",
|
||||
"Java 环境配置可能复杂"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "online_server",
|
||||
"label": "使用在线 PlantUML Server 渲染",
|
||||
"score": 75.0,
|
||||
"pros": [
|
||||
"无需本地环境",
|
||||
"配置简单"
|
||||
],
|
||||
"cons": [
|
||||
"依赖网络",
|
||||
"隐私考虑",
|
||||
"可能有延迟"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "syntax_only",
|
||||
"label": "仅校验语法，不强制本地渲染",
|
||||
"score": 70.0,
|
||||
"pros": [
|
||||
"最小依赖",
|
||||
"快速验证"
|
||||
],
|
||||
"cons": [
|
||||
"无法生成图片",
|
||||
"用户需自行渲染查看"
|
||||
]
|
||||
}
|
||||
],
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 67,
|
||||
"end": 71
|
||||
},
|
||||
"context": "流程图功能依赖 PlantUML，而 PlantUML 需要 Java 环境。需要决定如何处理这个依赖关系。",
|
||||
"recommend": "local_java"
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "任务复杂度判断标准",
|
||||
"options": [
|
||||
{
|
||||
"value": "module_count",
|
||||
"label": "涉及 3 个以上独立模块",
|
||||
"score": 70.0,
|
||||
"pros": [
|
||||
"标准明确可量化",
|
||||
"易于判断"
|
||||
],
|
||||
"cons": [
|
||||
"模块定义可能不清晰",
|
||||
"不适用于所有项目类型"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "code_lines",
|
||||
"label": "预估代码变更超过 500 行",
|
||||
"score": 65.0,
|
||||
"pros": [
|
||||
"量化标准",
|
||||
"与工作量直接相关"
|
||||
],
|
||||
"cons": [
|
||||
"难以准确预估",
|
||||
"代码行数不等于复杂度"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "llm_guidelines",
|
||||
"label": "LLM 综合判断（提供指导原则）",
|
||||
"score": 90.0,
|
||||
"pros": [
|
||||
"灵活适应各种场景",
|
||||
"可结合多维度考量",
|
||||
"避免机械判断"
|
||||
],
|
||||
"cons": [
|
||||
"判断可能有主观性",
|
||||
"需要明确的指导原则"
|
||||
]
|
||||
}
|
||||
],
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 52,
|
||||
"end": 56
|
||||
},
|
||||
"context": "需要在任务分析阶段判断任务复杂度，对过于复杂的任务进行拆分。需要确定判断标准。",
|
||||
"recommend": "llm_guidelines"
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "prep+exec 合并后的命令命名",
|
||||
"options": [
|
||||
{
|
||||
"value": "aide_task",
|
||||
"label": "/aide:task",
|
||||
"score": 90.0,
|
||||
"pros": [
|
||||
"语义明确",
|
||||
"涵盖准备和执行",
|
||||
"任务导向"
|
||||
],
|
||||
"cons": [
|
||||
"与 task 工具可能混淆"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "aide_run",
|
||||
"label": "/aide:run",
|
||||
"score": 80.0,
|
||||
"pros": [
|
||||
"简洁有力",
|
||||
"动作导向"
|
||||
],
|
||||
"cons": [
|
||||
"语义不如 task 完整",
|
||||
"可能暗示只是执行"
|
||||
]
|
||||
},
|
||||
{
|
||||
"value": "aide_exec",
|
||||
"label": "/aide:exec（保留原名）",
|
||||
"score": 75.0,
|
||||
"pros": [
|
||||
"保持命名连续性",
|
||||
"用户无需重新适应"
|
||||
],
|
||||
"cons": [
|
||||
"原名仅强调执行，不含准备含义"
|
||||
]
|
||||
}
|
||||
],
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 26,
|
||||
"end": 31
|
||||
},
|
||||
"context": "将 prep（任务准备）和 exec（任务执行）合并为一个命令，需要确定新命令的名称。",
|
||||
"recommend": "aide_task"
|
||||
}
|
||||
],
|
||||
"_meta": {
|
||||
"created_at": "2025-12-15T17:33:16+08:00",
|
||||
"session_id": "2025-12-15T17-33-16"
|
||||
}
|
||||
}
|
||||
@@ -1,56 +0,0 @@
|
||||
@startuml overall-flow
|
||||
!theme plain
|
||||
title Aide 工作流体系重构 - 总体执行流程
|
||||
|
||||
start
|
||||
|
||||
:读取任务细则;
|
||||
note right: .aide/task-spec.md
|
||||
|
||||
partition "子计划 1: 配置系统增强" {
|
||||
:修改 config.py;
|
||||
:自文档化配置模板;
|
||||
:复制 plantuml.jar;
|
||||
:更新 aide init 逻辑;
|
||||
}
|
||||
|
||||
partition "子计划 2: aide flow 状态查看" {
|
||||
:设计 flow 状态数据格式;
|
||||
:实现 flow status;
|
||||
:实现 flow list;
|
||||
:实现 flow show;
|
||||
:更新 skill 文档;
|
||||
}
|
||||
|
||||
partition "子计划 3: aide flow 流程图集成" {
|
||||
:创建 plantuml 环境模块;
|
||||
:实现校验功能;
|
||||
:实现构建功能;
|
||||
:集成到 flow 逻辑;
|
||||
}
|
||||
|
||||
partition "子计划 4: 项目文档体系" {
|
||||
:设计文档结构规范;
|
||||
:设计创建/更新流程;
|
||||
:创建 /aide:docs command;
|
||||
}
|
||||
|
||||
partition "子计划 5: Commands 重组" {
|
||||
:创建 /aide:setup;
|
||||
:创建 /aide:load;
|
||||
:重构 /aide:run;
|
||||
:更新 plugin.json;
|
||||
}
|
||||
|
||||
partition "子计划 6: 任务分析增强" {
|
||||
:复杂度评估指导原则;
|
||||
:子计划结构设计;
|
||||
:循环执行机制;
|
||||
}
|
||||
|
||||
:验证所有功能;
|
||||
:更新文档;
|
||||
:清理收尾;
|
||||
|
||||
stop
|
||||
@enduml
|
||||
@@ -1,66 +0,0 @@
|
||||
@startuml subplan1-config
|
||||
!theme plain
|
||||
title 子计划 1: 配置系统增强
|
||||
|
||||
start
|
||||
|
||||
:读取当前 config.py;
|
||||
note right: aide-program/aide/core/config.py
|
||||
|
||||
partition "1. 新增配置项支持" {
|
||||
:添加 [general] 节;
|
||||
note right
|
||||
gitignore_aide = true/false
|
||||
end note
|
||||
|
||||
:添加 [docs] 节;
|
||||
note right
|
||||
path = "..."
|
||||
block_plan_path = "..."
|
||||
end note
|
||||
|
||||
:添加 [flow] 节扩展;
|
||||
note right
|
||||
diagram_path = "..."
|
||||
end note
|
||||
|
||||
:添加 [plantuml] 节;
|
||||
note right
|
||||
jar_path = "lib/plantuml.jar"
|
||||
end note
|
||||
}
|
||||
|
||||
partition "2. 自文档化配置模板" {
|
||||
:编写 DEFAULT_CONFIG;
|
||||
:添加完整 TOML 注释;
|
||||
:所有配置项含说明;
|
||||
:提供示例值;
|
||||
}
|
||||
|
||||
partition "3. 复制 plantuml.jar" {
|
||||
:创建 lib/ 目录;
|
||||
:复制 jar 文件;
|
||||
note right
|
||||
从: /home/user/env-hub/jar/plantuml.jar
|
||||
到: aide-program/lib/plantuml.jar
|
||||
end note
|
||||
}
|
||||
|
||||
partition "4. 修改 aide init 逻辑" {
|
||||
:读取 gitignore_aide 配置;
|
||||
if (gitignore_aide == true?) then (是)
|
||||
:添加 .aide/ 到 .gitignore;
|
||||
else (否)
|
||||
:不修改 .gitignore;
|
||||
endif
|
||||
}
|
||||
|
||||
partition "5. 更新设计文档" {
|
||||
:更新 formats/config.md;
|
||||
:更新 README.md;
|
||||
}
|
||||
|
||||
:验证配置功能;
|
||||
|
||||
stop
|
||||
@enduml
|
||||
@@ -1,69 +0,0 @@
|
||||
@startuml subplan2-flow-status
|
||||
!theme plain
|
||||
title 子计划 2: aide flow 状态查看功能
|
||||
|
||||
start
|
||||
|
||||
partition "1. 设计数据存储格式" {
|
||||
:分析现有 flow-status.json;
|
||||
:设计任务列表索引;
|
||||
note right
|
||||
.aide/flow-index.json
|
||||
记录所有任务的 task_id 和概要
|
||||
end note
|
||||
:设计归档命名规则;
|
||||
}
|
||||
|
||||
partition "2. 实现 flow status" {
|
||||
:读取 flow-status.json;
|
||||
if (文件存在?) then (是)
|
||||
:解析当前状态;
|
||||
:输出格式化信息;
|
||||
note right
|
||||
环节: impl
|
||||
步骤: 3
|
||||
简述: xxx
|
||||
时间: 2025-12-15 10:30
|
||||
提交: abc1234
|
||||
end note
|
||||
else (否)
|
||||
:输出 "当前无活跃任务";
|
||||
endif
|
||||
}
|
||||
|
||||
partition "3. 实现 flow list" {
|
||||
:读取 flow-index.json;
|
||||
:读取 logs/ 目录下归档文件;
|
||||
:合并任务列表;
|
||||
:按时间倒序排列;
|
||||
:输出任务列表;
|
||||
note right
|
||||
[1] 20251215-103000 Aide重构 (finish)
|
||||
[2] 20251214-090000 贪吃蛇游戏 (impl)
|
||||
end note
|
||||
}
|
||||
|
||||
partition "4. 实现 flow show" {
|
||||
:接收 task_id 参数;
|
||||
:查找对应状态文件;
|
||||
if (找到?) then (是)
|
||||
:解析历史记录;
|
||||
:格式化输出;
|
||||
note right
|
||||
输出每个历史条目:
|
||||
环节、简述、时间戳、git提交
|
||||
end note
|
||||
else (否)
|
||||
:输出错误 "任务不存在";
|
||||
endif
|
||||
}
|
||||
|
||||
partition "5. 更新相关文档" {
|
||||
:更新 aide skill SKILL.md;
|
||||
:更新 flow 设计文档;
|
||||
}
|
||||
|
||||
:测试新命令;
|
||||
|
||||
stop
|
||||
@enduml
|
||||
@@ -1,81 +0,0 @@
|
||||
@startuml subplan3-plantuml
|
||||
!theme plain
|
||||
title 子计划 3: aide flow 流程图集成
|
||||
|
||||
start
|
||||
|
||||
partition "1. 创建 plantuml 环境模块" {
|
||||
:创建 env/modules/plantuml.py;
|
||||
:继承 BaseModule;
|
||||
:实现 check() 方法;
|
||||
note right
|
||||
检查:
|
||||
- java 命令可用
|
||||
- jar 文件存在
|
||||
end note
|
||||
:注册到 registry;
|
||||
}
|
||||
|
||||
partition "2. 实现校验功能" {
|
||||
:创建 flow/plantuml.py;
|
||||
:实现 validate_puml(file_path);
|
||||
note right
|
||||
调用: java -jar plantuml.jar -checkonly file.puml
|
||||
返回: (success, error_message)
|
||||
end note
|
||||
:实现 validate_all(directory);
|
||||
note right
|
||||
遍历目录下所有 .puml 文件
|
||||
返回: [(file, success, error)]
|
||||
end note
|
||||
}
|
||||
|
||||
partition "3. 实现构建功能" {
|
||||
:实现 build_puml(file_path);
|
||||
note right
|
||||
调用: java -jar plantuml.jar -tpng file.puml
|
||||
生成: file.png
|
||||
end note
|
||||
:实现 build_all(directory);
|
||||
note right
|
||||
遍历目录下所有 .puml 文件
|
||||
批量生成 PNG
|
||||
end note
|
||||
}
|
||||
|
||||
partition "4. 集成到 flow 逻辑" {
|
||||
:修改 hooks.py;
|
||||
|
||||
:修改 next-step 钩子;
|
||||
if (当前环节 == flow-design?) then (是)
|
||||
:校验流程图目录;
|
||||
if (校验通过?) then (是)
|
||||
:继续执行;
|
||||
else (否)
|
||||
:记录问题到 git;
|
||||
:返回错误提示;
|
||||
endif
|
||||
endif
|
||||
|
||||
:修改 next-part impl 钩子;
|
||||
if (从 flow-design 进入?) then (是)
|
||||
:校验所有 .puml 文件;
|
||||
if (校验通过?) then (是)
|
||||
:批量构建 PNG;
|
||||
:继续执行;
|
||||
else (否)
|
||||
:记录问题到 git;
|
||||
:返回错误提示;
|
||||
endif
|
||||
endif
|
||||
}
|
||||
|
||||
partition "5. 更新设计文档" {
|
||||
:更新 hooks 设计文档;
|
||||
:更新 flow 设计文档;
|
||||
}
|
||||
|
||||
:测试集成功能;
|
||||
|
||||
stop
|
||||
@enduml
|
||||
@@ -1,109 +0,0 @@
|
||||
@startuml subplan4-docs-system
|
||||
!theme plain
|
||||
title 子计划 4: 项目文档体系设计与实现
|
||||
|
||||
start
|
||||
|
||||
partition "1. 设计文档结构规范" {
|
||||
:设计总导览文档格式;
|
||||
note right
|
||||
# 项目导览
|
||||
## 项目简介
|
||||
## 架构概述
|
||||
## 区块索引
|
||||
- [区块A](./blocks/a.md)
|
||||
- [区块B](./blocks/b.md)
|
||||
end note
|
||||
|
||||
:设计子区块文档格式;
|
||||
note right
|
||||
# 区块名称
|
||||
## 概述
|
||||
## 文件清单
|
||||
## 核心组件
|
||||
## 接口说明
|
||||
## 依赖关系
|
||||
end note
|
||||
|
||||
:制定区块划分规则;
|
||||
note right
|
||||
1. 按目录结构自然划分
|
||||
2. 按功能模块语义划分
|
||||
3. 单个区块不超过 5000 行
|
||||
4. 保持区块间低耦合
|
||||
end note
|
||||
}
|
||||
|
||||
partition "2. 设计文档创建流程" {
|
||||
:目录探索;
|
||||
note right
|
||||
遍历目录结构
|
||||
统计文件数量和大小
|
||||
识别 .gitignore 排除项
|
||||
end note
|
||||
|
||||
:初步区块划分;
|
||||
note right
|
||||
根据目录结构和文件类型
|
||||
生成初步区块计划
|
||||
end note
|
||||
|
||||
:区块验证;
|
||||
note right
|
||||
浅层探索各区块
|
||||
验证划分合理性
|
||||
调整区块边界
|
||||
end note
|
||||
|
||||
:逐区块深度了解;
|
||||
note right
|
||||
每个区块完整阅读
|
||||
提取核心信息
|
||||
生成文档
|
||||
end note
|
||||
|
||||
:进度检查点;
|
||||
note right
|
||||
记录进度到区块计划文档
|
||||
支持多对话续接
|
||||
end note
|
||||
}
|
||||
|
||||
partition "3. 设计文档更新流程" {
|
||||
:分区块验证;
|
||||
note right
|
||||
对比文档与代码
|
||||
识别差异
|
||||
end note
|
||||
|
||||
:差异检测;
|
||||
note right
|
||||
标记需要更新的部分
|
||||
end note
|
||||
|
||||
:增量更新;
|
||||
note right
|
||||
只更新有变化的区块
|
||||
更新导览索引
|
||||
end note
|
||||
}
|
||||
|
||||
partition "4. 创建 /aide:docs command" {
|
||||
:创建 commands/docs.md;
|
||||
:定义命令流程;
|
||||
note right
|
||||
- 检查文档目录配置
|
||||
- 首次创建/更新逻辑
|
||||
- 区块进度追踪
|
||||
- 多对话续接支持
|
||||
end note
|
||||
:强制触发 aide skill;
|
||||
}
|
||||
|
||||
partition "5. 更新相关文档" {
|
||||
:创建文档规范文档;
|
||||
:更新 plugin 设计文档;
|
||||
}
|
||||
|
||||
stop
|
||||
@enduml
|
||||
@@ -1,109 +0,0 @@
|
||||
@startuml subplan5-commands
|
||||
!theme plain
|
||||
title 子计划 5: Commands 重组
|
||||
|
||||
start
|
||||
|
||||
partition "1. 创建 /aide:setup" {
|
||||
:创建 commands/setup.md;
|
||||
|
||||
:定义职责;
|
||||
note right
|
||||
独立运行的环境管理命令
|
||||
专注: 分析、配置、检测、修复
|
||||
end note
|
||||
|
||||
:定义流程;
|
||||
note right
|
||||
1. 强制触发 env-config skill
|
||||
2. 运行 aide env ensure --runtime
|
||||
3. 分析项目依赖
|
||||
4. 配置环境模块
|
||||
5. 运行 aide env ensure
|
||||
6. 处理问题（重试或询问）
|
||||
end note
|
||||
}
|
||||
|
||||
partition "2. 创建 /aide:load" {
|
||||
:创建 commands/load.md;
|
||||
|
||||
:定义职责;
|
||||
note right
|
||||
项目文档按需载入
|
||||
由 /aide:run 调用
|
||||
end note
|
||||
|
||||
:定义流程;
|
||||
note right
|
||||
1. 检查项目文档目录配置
|
||||
2. 读取总导览文档
|
||||
3. 建立项目脉络认知
|
||||
4. 支持后续按需深入
|
||||
end note
|
||||
|
||||
:处理文档不存在;
|
||||
note right
|
||||
提示用户先执行 /aide:docs
|
||||
或按需创建文档
|
||||
end note
|
||||
}
|
||||
|
||||
partition "3. 重构 /aide:run" {
|
||||
:创建 commands/run.md;
|
||||
|
||||
:强制触发 aide skill;
|
||||
|
||||
:检查 flow 状态;
|
||||
if (flow 为空或已 finish?) then (是)
|
||||
:启动新 flow;
|
||||
note right
|
||||
aide flow start task-optimize "..."
|
||||
end note
|
||||
:执行 task-optimize 阶段;
|
||||
:处理待定项;
|
||||
:生成任务细则;
|
||||
else (否)
|
||||
:分析当前进度;
|
||||
:调用 /aide:load 载入文档;
|
||||
:续接任务;
|
||||
endif
|
||||
|
||||
:执行 flow-design 阶段;
|
||||
note right
|
||||
创建流程图
|
||||
end note
|
||||
|
||||
:执行 impl 阶段;
|
||||
:执行 verify 阶段;
|
||||
:执行 docs 阶段;
|
||||
:执行 finish 阶段;
|
||||
}
|
||||
|
||||
partition "4. 处理旧命令" {
|
||||
:重命名 init.md → _deprecated_init.md;
|
||||
:重命名 prep.md → _deprecated_prep.md;
|
||||
:重命名 exec.md → _deprecated_exec.md;
|
||||
note right
|
||||
保留旧文件便于参考
|
||||
但不再注册到 plugin
|
||||
end note
|
||||
}
|
||||
|
||||
partition "5. 更新 plugin.json" {
|
||||
:移除旧命令注册;
|
||||
:添加新命令注册;
|
||||
note right
|
||||
/aide:setup
|
||||
/aide:load
|
||||
/aide:docs
|
||||
/aide:run
|
||||
end note
|
||||
}
|
||||
|
||||
partition "6. 更新设计文档" {
|
||||
:更新 docs/commands/;
|
||||
:更新 docs/README.md;
|
||||
}
|
||||
|
||||
stop
|
||||
@enduml
|
||||
@@ -1,99 +0,0 @@
|
||||
@startuml subplan6-task-analysis
|
||||
!theme plain
|
||||
title 子计划 6: 任务分析阶段增强
|
||||
|
||||
start
|
||||
|
||||
partition "1. 复杂度评估指导原则" {
|
||||
:整理评估维度;
|
||||
note right
|
||||
结构维度: 模块数、文件数、依赖关系
|
||||
逻辑维度: 业务复杂度、状态管理
|
||||
集成维度: 外部依赖、数据格式
|
||||
风险维度: 技术风险、影响范围
|
||||
end note
|
||||
|
||||
:定义复杂度等级;
|
||||
note right
|
||||
简单: 直接执行
|
||||
中等: 直接执行，注意顺序
|
||||
复杂: 必须拆分子计划
|
||||
超大: 拆分为独立任务
|
||||
end note
|
||||
|
||||
:制定拆分标准;
|
||||
note right
|
||||
1. 涉及 3+ 独立模块
|
||||
2. 自然分为多个阶段
|
||||
3. 存在高风险环节
|
||||
4. 明确的前后依赖
|
||||
5. 需要多次对话
|
||||
end note
|
||||
}
|
||||
|
||||
partition "2. 设计子计划结构" {
|
||||
:设计任务导览格式;
|
||||
note right
|
||||
# 任务导览
|
||||
## 任务概述
|
||||
## 子计划列表
|
||||
| 序号 | 名称 | 状态 | 依赖 |
|
||||
## 当前进度
|
||||
end note
|
||||
|
||||
:设计子计划细则格式;
|
||||
note right
|
||||
# 子计划 N: 名称
|
||||
## 目标
|
||||
## 成功标准
|
||||
## 执行步骤
|
||||
## 交付物
|
||||
end note
|
||||
}
|
||||
|
||||
partition "3. 实现拆分逻辑" {
|
||||
:修改 /aide:run 的 task-optimize;
|
||||
|
||||
:任务分析;
|
||||
:复杂度评估;
|
||||
|
||||
if (复杂度 >= 复杂?) then (是)
|
||||
:识别可独立交付阶段;
|
||||
:按依赖关系排序;
|
||||
:生成任务导览文档;
|
||||
:生成各子计划细则;
|
||||
else (否)
|
||||
:生成单一任务细则;
|
||||
endif
|
||||
}
|
||||
|
||||
partition "4. 实现循环执行机制" {
|
||||
:修改 /aide:run 执行逻辑;
|
||||
|
||||
:读取任务导览;
|
||||
:确定当前子计划;
|
||||
|
||||
while (还有未完成的子计划?) is (是)
|
||||
:执行 flow-design;
|
||||
:执行 impl;
|
||||
:执行 verify;
|
||||
:执行 docs;
|
||||
:标记子计划完成;
|
||||
:更新任务导览;
|
||||
endwhile (否)
|
||||
|
||||
:执行 finish;
|
||||
}
|
||||
|
||||
partition "5. 更新 /aide:run command" {
|
||||
:整合上述逻辑;
|
||||
:更新命令文档;
|
||||
}
|
||||
|
||||
partition "6. 更新设计文档" {
|
||||
:创建复杂度评估指南;
|
||||
:更新 run command 文档;
|
||||
}
|
||||
|
||||
stop
|
||||
@enduml
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 103 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 83 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 106 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 125 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 128 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 152 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 151 KiB |
@@ -1,191 +0,0 @@
|
||||
{
|
||||
"task_id": "2025-12-15T17-28-53",
|
||||
"current_phase": "finish",
|
||||
"current_step": 23,
|
||||
"started_at": "2025-12-15T17:28:53+08:00",
|
||||
"history": [
|
||||
{
|
||||
"timestamp": "2025-12-15T17:28:53+08:00",
|
||||
"action": "start",
|
||||
"phase": "task-optimize",
|
||||
"step": 1,
|
||||
"summary": "开始任务准备: 阅读任务原文档"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T17:31:21+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "task-optimize",
|
||||
"step": 2,
|
||||
"summary": "任务分析完成：识别 6 个子任务和 5 个待定项",
|
||||
"git_commit": "7defeac3c64c7918a3187b03158f9570b3b30fc3"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T17:32:45+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "task-optimize",
|
||||
"step": 3,
|
||||
"summary": "任务优化完成，生成待定项",
|
||||
"git_commit": "2bc86b1d893d57e24083775cd51437de6adc46bf"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T17:43:38+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "task-optimize",
|
||||
"step": 4,
|
||||
"summary": "用户完成待定项确认",
|
||||
"git_commit": "5cf5a5810c4bd45f4aa18758e1a1e4475e03c175"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T17:45:21+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "task-optimize",
|
||||
"step": 5,
|
||||
"summary": "整合用户决策，生成任务细则",
|
||||
"git_commit": "244e8c8f050c6a3b2f3c5c44b90b58ea84016c31"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T17:50:11+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "task-optimize",
|
||||
"step": 6,
|
||||
"summary": "用户确认任务细则",
|
||||
"git_commit": "c4119bd8cc9394cfda69113a883dd4d9b2b19554"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T17:50:23+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "task-optimize",
|
||||
"step": 7,
|
||||
"summary": "任务准备完成",
|
||||
"git_commit": "dbd2323a045312d03c018bffaa24b6c8c030ae7f"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T17:51:56+08:00",
|
||||
"action": "next-part",
|
||||
"phase": "flow-design",
|
||||
"step": 8,
|
||||
"summary": "进入流程设计环节",
|
||||
"git_commit": "7e1f0263a9e74ee40a3680a407a7fc26b58041e6"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T17:58:46+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "flow-design",
|
||||
"step": 9,
|
||||
"summary": "流程图设计完成: 1个总体流程图 + 6个子计划流程图",
|
||||
"git_commit": "46435c031cb933b04ddb4a01ee761b97f6016abf"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T17:58:58+08:00",
|
||||
"action": "next-part",
|
||||
"phase": "impl",
|
||||
"step": 10,
|
||||
"summary": "流程设计完成，进入实现环节",
|
||||
"git_commit": "5f27bb7424cc5ce2f18ab30a9f1a0ad9a626b604"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:09:36+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "impl",
|
||||
"step": 11,
|
||||
"summary": "子计划1: 配置系统增强完成 - 自文档化配置模板、gitignore配置、plantuml.jar",
|
||||
"git_commit": "79facec0a3db9ffcf936772930cc695ca9bf263d"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:11:39+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "impl",
|
||||
"step": 12,
|
||||
"summary": "子计划2: aide flow 状态查看功能完成 - status/list/show 子命令",
|
||||
"git_commit": "6a1b230cc98ff5535fd8cbc1d9490293e2ef6845"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:12:50+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "impl",
|
||||
"step": 13,
|
||||
"summary": "子计划3: aide flow 流程图集成完成 - PlantUML 校验/构建钩子增强",
|
||||
"git_commit": "5f7c91afa1723e327f04f14f245c3e51d3e49fc7"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:15:56+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "impl",
|
||||
"step": 14,
|
||||
"summary": "子计划4+5: 项目文档体系和Commands重组完成 - 新增setup/load/docs/run命令",
|
||||
"git_commit": "4a7751d7ff5d0e0cbbdbe15063b1b8bd855c0317"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:17:20+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "impl",
|
||||
"step": 15,
|
||||
"summary": "子计划6: 任务分析阶段增强完成 - 更新aide skill文档，添加flow status/list/show说明",
|
||||
"git_commit": "c599089eabcc4b071e37d31226e992c724743d78"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:17:39+08:00",
|
||||
"action": "next-part",
|
||||
"phase": "verify",
|
||||
"step": 16,
|
||||
"summary": "实现完成，进入验证环节",
|
||||
"git_commit": "741fec15fc06446854d270e2414069c75883b317"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:18:16+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "verify",
|
||||
"step": 17,
|
||||
"summary": "验证完成: 所有成功标准均已满足",
|
||||
"git_commit": "de51e4207ac73440c55b15fe31206e6a5fa4506c"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:18:25+08:00",
|
||||
"action": "next-part",
|
||||
"phase": "docs",
|
||||
"step": 18,
|
||||
"summary": "验证通过，进入文档环节",
|
||||
"git_commit": "0b69f9587d04e199327ed9aa6d5ed1b3e41d20a5"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:19:26+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "docs",
|
||||
"step": 19,
|
||||
"summary": "文档更新完成: CHANGELOG.md 和 README.md",
|
||||
"git_commit": "13f238e2b61ccad5071d650e97807c28976b9fc3"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:19:34+08:00",
|
||||
"action": "next-part",
|
||||
"phase": "finish",
|
||||
"step": 20,
|
||||
"summary": "文档更新完成，进入收尾",
|
||||
"git_commit": "6f80b47c08438219851b01dc14838da647666ba1"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:19:54+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "finish",
|
||||
"step": 21,
|
||||
"summary": "任务完成",
|
||||
"git_commit": "cf3bf69dd2339862e81abee331474a1d3494162d"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:23:50+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "finish",
|
||||
"step": 22,
|
||||
"summary": "同步更新 aide skill 文档: 新增命令体系、数据存储结构、完整流程示例",
|
||||
"git_commit": "cc959ee7cfb3ac4a70cb15b35ffec6574d35c05e"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-15T18:25:17+08:00",
|
||||
"action": "next-step",
|
||||
"phase": "finish",
|
||||
"step": 23,
|
||||
"summary": "同步更新 env-config skill: 添加与新命令体系的关系说明",
|
||||
"git_commit": "67162d23370766258fffd10ec0e476c8bca86924"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -1,176 +0,0 @@
|
||||
{
|
||||
"task": "Aide 工作流体系重构",
|
||||
"source": "statements/1.md",
|
||||
"items": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "新 Commands 命名方案",
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 9,
|
||||
"end": 25
|
||||
},
|
||||
"context": "原 init 命令需要拆分为环境管理（cmd-1）和项目认知（cmd-2）两部分，同时新增文档管理命令（cmd-3）。需要确定这三个命令的正式名称。",
|
||||
"options": [
|
||||
{
|
||||
"value": "env_ctx_docs",
|
||||
"label": "/aide:env + /aide:ctx + /aide:docs",
|
||||
"score": 90,
|
||||
"pros": ["语义清晰明确", "与功能高度匹配", "简洁易记"],
|
||||
"cons": ["ctx 可能不够直观"]
|
||||
},
|
||||
{
|
||||
"value": "setup_load_docs",
|
||||
"label": "/aide:setup + /aide:load + /aide:docs",
|
||||
"score": 75,
|
||||
"pros": ["动词形式更直观", "setup 表达初始化含义"],
|
||||
"cons": ["setup 与 env ensure 功能重叠", "load 语义较模糊"]
|
||||
},
|
||||
{
|
||||
"value": "env_init_docs",
|
||||
"label": "/aide:env + /aide:init + /aide:docs",
|
||||
"score": 80,
|
||||
"pros": ["保留 init 命名习惯", "env 明确表达环境功能"],
|
||||
"cons": ["init 原本包含更多功能，可能造成混淆"]
|
||||
}
|
||||
],
|
||||
"recommend": "env_ctx_docs"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "流程图强制要求的例外情况",
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 58,
|
||||
"end": 66
|
||||
},
|
||||
"context": "任务描述要求\"不论是什么任务，只要有任务就必须有流程图\"。但对于简单任务（如修改文档、单文件小改动），强制流程图可能降低效率。需要确定是否允许例外。",
|
||||
"options": [
|
||||
{
|
||||
"value": "always_required",
|
||||
"label": "所有任务必须有流程图",
|
||||
"score": 70,
|
||||
"pros": ["规则简单统一", "强制规范化思考", "用户审阅体验一致"],
|
||||
"cons": ["简单任务效率降低", "可能流于形式"]
|
||||
},
|
||||
{
|
||||
"value": "allow_exceptions",
|
||||
"label": "允许简单任务跳过",
|
||||
"score": 85,
|
||||
"pros": ["平衡效率和质量", "避免形式主义"],
|
||||
"cons": ["需要定义\"简单任务\"标准", "判断标准可能不一致"]
|
||||
},
|
||||
{
|
||||
"value": "llm_judgment",
|
||||
"label": "由 LLM 根据复杂度判断",
|
||||
"score": 80,
|
||||
"pros": ["灵活适应不同场景", "利用 LLM 判断能力"],
|
||||
"cons": ["判断标准不够稳定", "可能被滥用跳过"]
|
||||
}
|
||||
],
|
||||
"recommend": "allow_exceptions"
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "PlantUML 依赖处理方式",
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 67,
|
||||
"end": 71
|
||||
},
|
||||
"context": "流程图功能依赖 PlantUML，而 PlantUML 需要 Java 环境。需要决定如何处理这个依赖关系。",
|
||||
"options": [
|
||||
{
|
||||
"value": "local_java",
|
||||
"label": "添加 java + plantuml 环境检测模块",
|
||||
"score": 85,
|
||||
"pros": ["离线可用", "完全本地化", "渲染速度快"],
|
||||
"cons": ["增加环境依赖", "Java 环境配置可能复杂"]
|
||||
},
|
||||
{
|
||||
"value": "online_server",
|
||||
"label": "使用在线 PlantUML Server 渲染",
|
||||
"score": 75,
|
||||
"pros": ["无需本地环境", "配置简单"],
|
||||
"cons": ["依赖网络", "隐私考虑", "可能有延迟"]
|
||||
},
|
||||
{
|
||||
"value": "syntax_only",
|
||||
"label": "仅校验语法，不强制本地渲染",
|
||||
"score": 70,
|
||||
"pros": ["最小依赖", "快速验证"],
|
||||
"cons": ["无法生成图片", "用户需自行渲染查看"]
|
||||
}
|
||||
],
|
||||
"recommend": "local_java"
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "任务复杂度判断标准",
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 52,
|
||||
"end": 56
|
||||
},
|
||||
"context": "需要在任务分析阶段判断任务复杂度，对过于复杂的任务进行拆分。需要确定判断标准。",
|
||||
"options": [
|
||||
{
|
||||
"value": "module_count",
|
||||
"label": "涉及 3 个以上独立模块",
|
||||
"score": 70,
|
||||
"pros": ["标准明确可量化", "易于判断"],
|
||||
"cons": ["模块定义可能不清晰", "不适用于所有项目类型"]
|
||||
},
|
||||
{
|
||||
"value": "code_lines",
|
||||
"label": "预估代码变更超过 500 行",
|
||||
"score": 65,
|
||||
"pros": ["量化标准", "与工作量直接相关"],
|
||||
"cons": ["难以准确预估", "代码行数不等于复杂度"]
|
||||
},
|
||||
{
|
||||
"value": "llm_guidelines",
|
||||
"label": "LLM 综合判断（提供指导原则）",
|
||||
"score": 90,
|
||||
"pros": ["灵活适应各种场景", "可结合多维度考量", "避免机械判断"],
|
||||
"cons": ["判断可能有主观性", "需要明确的指导原则"]
|
||||
}
|
||||
],
|
||||
"recommend": "llm_guidelines"
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "prep+exec 合并后的命令命名",
|
||||
"location": {
|
||||
"file": "statements/1.md",
|
||||
"start": 26,
|
||||
"end": 31
|
||||
},
|
||||
"context": "将 prep（任务准备）和 exec（任务执行）合并为一个命令，需要确定新命令的名称。",
|
||||
"options": [
|
||||
{
|
||||
"value": "aide_task",
|
||||
"label": "/aide:task",
|
||||
"score": 90,
|
||||
"pros": ["语义明确", "涵盖准备和执行", "任务导向"],
|
||||
"cons": ["与 task 工具可能混淆"]
|
||||
},
|
||||
{
|
||||
"value": "aide_run",
|
||||
"label": "/aide:run",
|
||||
"score": 80,
|
||||
"pros": ["简洁有力", "动作导向"],
|
||||
"cons": ["语义不如 task 完整", "可能暗示只是执行"]
|
||||
},
|
||||
{
|
||||
"value": "aide_exec",
|
||||
"label": "/aide:exec（保留原名）",
|
||||
"score": 75,
|
||||
"pros": ["保持命名连续性", "用户无需重新适应"],
|
||||
"cons": ["原名仅强调执行，不含准备含义"]
|
||||
}
|
||||
],
|
||||
"recommend": "aide_task"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -1,310 +0,0 @@
|
||||
# 任务细则：Aide 工作流体系重构
|
||||
|
||||
## 任务目标
|
||||
|
||||
对 Aide 工作流体系进行全面重构，包括：
|
||||
1. Commands 体系重组（拆分 init、合并 prep+exec、新增文档管理）
|
||||
2. aide flow 功能增强（状态查看、流程图集成）
|
||||
3. 配置系统完善（自文档化、新增配置项）
|
||||
4. 项目文档体系建立（面向 LLM 的区块化文档系统）
|
||||
5. 任务分析阶段增强（复杂度评估、子计划拆分）
|
||||
|
||||
## 成功标准
|
||||
|
||||
1. **Commands 重组完成**
|
||||
- `/aide:setup` 命令实现环境依赖分析、配置、检测、修复功能
|
||||
- `/aide:load` 命令实现项目文档按需载入功能
|
||||
- `/aide:docs` 命令实现项目文档创建和维护功能
|
||||
- `/aide:run` 命令整合原 prep 和 exec 功能，支持流程状态检测和续接
|
||||
|
||||
2. **aide flow 增强完成**
|
||||
- 支持 `aide flow status` 查看当前任务状态
|
||||
- 支持 `aide flow list` 查看所有任务列表
|
||||
- 支持 `aide flow show <task_id>` 查看详细状态
|
||||
- flow-design 阶段强制 PlantUML 流程图，集成校验和构建
|
||||
|
||||
3. **配置系统完善**
|
||||
- 配置文件完全自文档化（所有配置项含注释说明）
|
||||
- 新增 `.gitignore` 忽略 `.aide` 目录的可配置选项
|
||||
- 新增项目文档路径配置项
|
||||
- 新增流程图目录路径配置项
|
||||
- PlantUML jar 路径配置
|
||||
|
||||
4. **项目文档体系建立**
|
||||
- 文档结构规范设计完成
|
||||
- 区块划分规则制定完成
|
||||
- 支持总导览 + 多子区块的文档结构
|
||||
- 支持增量更新（无需了解全局即可修改局部）
|
||||
|
||||
5. **任务分析增强完成**
|
||||
- 复杂度评估指导原则制定
|
||||
- 复杂任务自动拆分为子计划
|
||||
- 子计划循环执行机制实现
|
||||
|
||||
---
|
||||
|
||||
## 技术决策
|
||||
|
||||
### 1. Commands 命名方案
|
||||
| 命令 | 功能 | 独立运行 |
|
||||
|------|------|----------|
|
||||
| `/aide:setup` | 环境依赖分析、配置、检测、修复 | 是 |
|
||||
| `/aide:load` | 项目文档按需载入，了解项目脉络 | 否（由 run 调用） |
|
||||
| `/aide:docs` | 项目文档创建和维护 | 是 |
|
||||
| `/aide:run` | 任务准备 + 任务执行（合并 prep+exec） | 否 |
|
||||
|
||||
### 2. 流程图要求
|
||||
- **强制要求**：所有任务必须有流程图，无例外
|
||||
- **目的**：规范化思考，方便用户审阅，早期发现逻辑错误
|
||||
|
||||
### 3. PlantUML 依赖处理
|
||||
- **方式**：本地 java + 本地 jar
|
||||
- **来源**：复制 `/home/user/env-hub/jar/plantuml.jar` 到 `aide-program/` 目录
|
||||
- **配置**：jar 路径写入 aide 程序配置
|
||||
|
||||
### 4. 任务复杂度判断
|
||||
- **方式**：LLM 综合判断
|
||||
- **依据**：详细的指导原则（见附录）
|
||||
|
||||
### 5. prep+exec 合并命令
|
||||
- **命名**：`/aide:run`
|
||||
- **行为**：启动时检查 flow 状态，根据状态决定新建或续接
|
||||
|
||||
---
|
||||
|
||||
## 执行步骤
|
||||
|
||||
本任务拆分为 **6 个子计划**，按依赖顺序执行：
|
||||
|
||||
### 子计划 1：配置系统增强
|
||||
|
||||
**目标**：完善 aide 配置系统，为后续功能提供基础支持
|
||||
|
||||
**步骤**：
|
||||
1. 修改 `aide-program/aide/core/config.py`，增加新配置项支持
|
||||
2. 更新配置文件模板，添加完整注释（自文档化）
|
||||
3. 新增配置项：
|
||||
- `[general]` 节：`gitignore_aide = true/false`
|
||||
- `[docs]` 节：`path = "..."`, `block_plan_path = "..."`
|
||||
- `[flow]` 节：`diagram_path = "..."`
|
||||
- `[plantuml]` 节：`jar_path = "..."`
|
||||
4. 修改 `aide init` 逻辑，根据 `gitignore_aide` 配置决定是否添加忽略项
|
||||
5. 复制 plantuml.jar 到 aide-program 目录
|
||||
6. 更新相关设计文档
|
||||
|
||||
**交付物**：
|
||||
- 更新后的 `config.py`
|
||||
- 自文档化的配置文件模板
|
||||
- `aide-program/lib/plantuml.jar`
|
||||
|
||||
---
|
||||
|
||||
### 子计划 2：aide flow 状态查看功能
|
||||
|
||||
**目标**：支持查看流程信息，为 `/aide:run` 续接功能提供依赖
|
||||
|
||||
**步骤**：
|
||||
1. 设计 flow 状态数据存储格式（`.aide/flow-status.json` 增强）
|
||||
2. 实现 `aide flow status` 子命令：
|
||||
- 显示当前任务进度（环节、简述、时间戳、git 提交标识）
|
||||
3. 实现 `aide flow list` 子命令：
|
||||
- 列出所有任务的名称和 task_id
|
||||
4. 实现 `aide flow show <task_id>` 子命令：
|
||||
- 显示指定任务的详细状态历史
|
||||
5. 更新 skill 文档（aide skill）
|
||||
6. 更新设计文档
|
||||
|
||||
**交付物**：
|
||||
- flow 子命令增强实现
|
||||
- 更新后的 skill 文档
|
||||
|
||||
---
|
||||
|
||||
### 子计划 3：aide flow 流程图集成
|
||||
|
||||
**目标**：在 flow-design 阶段集成 PlantUML 校验和构建
|
||||
|
||||
**步骤**：
|
||||
1. 创建 PlantUML 环境检测模块 `aide-program/aide/env/modules/plantuml.py`
|
||||
2. 实现 PlantUML 语法校验功能
|
||||
3. 实现 PlantUML 构建功能（生成 PNG）
|
||||
4. 修改 flow 相关逻辑：
|
||||
- `next-step` 在 flow-design 阶段校验流程图目录下的 .puml 文件
|
||||
- `next-part impl` 时先校验，通过后批量构建 PNG
|
||||
- 校验失败时记录状态并提交 git，返回错误提示
|
||||
5. 更新设计文档
|
||||
|
||||
**交付物**：
|
||||
- `plantuml.py` 环境模块
|
||||
- flow 流程图集成逻辑
|
||||
- 相关设计文档
|
||||
|
||||
---
|
||||
|
||||
### 子计划 4：项目文档体系设计与实现
|
||||
|
||||
**目标**：建立面向 LLM 的区块化项目文档体系
|
||||
|
||||
**步骤**：
|
||||
1. 设计文档结构规范：
|
||||
- 总导览文档格式
|
||||
- 子区块文档格式
|
||||
- 区块划分规则
|
||||
2. 设计文档创建流程：
|
||||
- 目录探索 → 区块划分 → 逐区块深度了解 → 文档生成
|
||||
3. 设计文档更新流程：
|
||||
- 分区块验证 → 差异检测 → 增量更新
|
||||
4. 创建 `/aide:docs` command 执行文件
|
||||
5. 更新相关 skill 文档
|
||||
6. 更新设计文档
|
||||
|
||||
**交付物**：
|
||||
- 文档结构规范文档
|
||||
- `/aide:docs` command
|
||||
- 相关 skill 和设计文档
|
||||
|
||||
---
|
||||
|
||||
### 子计划 5：Commands 重组
|
||||
|
||||
**目标**：重新组织 aide-plugin 的 commands
|
||||
|
||||
**步骤**：
|
||||
1. 创建 `/aide:setup` command：
|
||||
- 强制触发 env-config skill
|
||||
- 专注环境依赖分析、配置、检测、修复
|
||||
- 独立运行设计
|
||||
2. 创建 `/aide:load` command：
|
||||
- 项目文档按需载入
|
||||
- 初次仅了解项目脉络
|
||||
- 支持后续按需深入
|
||||
3. 重构 `/aide:run` command（合并 prep + exec）：
|
||||
- 启动时检查 flow 状态
|
||||
- flow 为空或已 finish：启动新 flow（从 task-optimize 开始）
|
||||
- flow 未完成：分析进度，按需载入文档，续接任务
|
||||
- 强制触发 aide skill
|
||||
4. 删除或重命名原 init/prep/exec commands
|
||||
5. 更新 plugin.json
|
||||
6. 更新设计文档
|
||||
|
||||
**交付物**：
|
||||
- `/aide:setup` command
|
||||
- `/aide:load` command
|
||||
- `/aide:docs` command（子计划 4 产出）
|
||||
- `/aide:run` command
|
||||
- 更新后的 plugin.json
|
||||
|
||||
---
|
||||
|
||||
### 子计划 6：任务分析阶段增强
|
||||
|
||||
**目标**：支持复杂任务识别和拆分
|
||||
|
||||
**步骤**：
|
||||
1. 制定任务复杂度评估指导原则（见附录）
|
||||
2. 设计子计划结构：
|
||||
- 任务计划总导览格式
|
||||
- 子计划细则格式
|
||||
3. 实现复杂任务拆分逻辑（在 `/aide:run` 的 task-optimize 阶段）
|
||||
4. 实现子计划循环执行机制：
|
||||
- task-optimize → [flow-design → impl → verify → docs] × N → finish
|
||||
5. 更新 `/aide:run` command
|
||||
6. 更新设计文档
|
||||
|
||||
**交付物**：
|
||||
- 复杂度评估指导原则文档
|
||||
- 子计划相关格式规范
|
||||
- 更新后的 `/aide:run` command
|
||||
|
||||
---
|
||||
|
||||
## 约束与边界
|
||||
|
||||
### 范围内
|
||||
- aide-plugin 的 commands 和 skills 修改
|
||||
- aide-program 的功能增强
|
||||
- 相关设计文档更新
|
||||
|
||||
### 范围外
|
||||
- 现有环境检测模块（python, uv, rust, node 等）的修改
|
||||
- aide decide 功能的修改
|
||||
- docs/ 下的教程文档（如自定义斜杠命令指南等）
|
||||
|
||||
### 技术约束
|
||||
- Python >= 3.11
|
||||
- 使用 uv 管理虚拟环境
|
||||
- 输出使用 `core/output.py` 格式
|
||||
- PlantUML 使用本地 java + jar 方式
|
||||
|
||||
---
|
||||
|
||||
## 附录：任务复杂度评估指导原则
|
||||
|
||||
### 一、评估维度
|
||||
|
||||
#### 1. 结构维度
|
||||
- **模块数量**：涉及多少个独立的功能模块或代码区块？
|
||||
- **文件数量**：预计需要创建或修改多少个文件？
|
||||
- **依赖关系**：模块之间的依赖关系是否复杂？是否存在循环依赖？
|
||||
|
||||
#### 2. 逻辑维度
|
||||
- **业务逻辑**：是否涉及复杂的业务规则或算法？
|
||||
- **状态管理**：是否需要管理复杂的状态转换？
|
||||
- **边界条件**：是否存在大量需要处理的边界情况？
|
||||
|
||||
#### 3. 集成维度
|
||||
- **外部依赖**：是否需要集成外部服务或 API？
|
||||
- **数据格式**：是否涉及复杂的数据转换或格式处理？
|
||||
- **兼容性**：是否需要考虑向后兼容或多版本支持？
|
||||
|
||||
#### 4. 风险维度
|
||||
- **技术风险**：是否涉及不熟悉的技术栈或新框架？
|
||||
- **影响范围**：修改是否会影响现有功能的稳定性？
|
||||
- **回滚难度**：如果出错，是否容易回滚？
|
||||
|
||||
### 二、复杂度等级
|
||||
|
||||
| 等级 | 描述 | 特征 | 处理方式 |
|
||||
|------|------|------|----------|
|
||||
| **简单** | 单一明确的小任务 | 单文件或少量文件修改，逻辑清晰，无复杂依赖 | 直接执行 |
|
||||
| **中等** | 涉及多个相关组件 | 2-4 个模块，有一定依赖关系，需要协调修改 | 直接执行，注意顺序 |
|
||||
| **复杂** | 跨多个子系统的任务 | 5+ 模块，复杂依赖，涉及架构调整 | **必须拆分为子计划** |
|
||||
| **超大** | 系统性重构或新系统 | 10+ 模块，全面重构，涉及多个子系统 | 拆分为多个独立任务 |
|
||||
|
||||
### 三、拆分判断标准
|
||||
|
||||
当满足以下任一条件时，**应当拆分为子计划**：
|
||||
|
||||
1. **模块标准**：涉及 3 个以上相对独立的功能模块
|
||||
2. **阶段标准**：任务自然分为多个可独立交付的阶段
|
||||
3. **风险标准**：存在高风险环节，需要阶段性验证
|
||||
4. **依赖标准**：存在明确的前后依赖关系，前置任务完成后才能进行后续任务
|
||||
5. **上下文标准**：单次对话可能无法完成，需要多次对话续接
|
||||
|
||||
### 四、拆分原则
|
||||
|
||||
1. **独立性**：每个子计划应该有独立的目标和交付物
|
||||
2. **完整性**：每个子计划完成后应该是可验证的完整状态
|
||||
3. **顺序性**：子计划之间的依赖关系要明确，执行顺序要清晰
|
||||
4. **粒度适中**：子计划不宜过大（难以完成）或过小（增加管理开销）
|
||||
|
||||
### 五、评估流程
|
||||
|
||||
```
|
||||
1. 阅读任务描述，识别所有涉及的功能点
|
||||
2. 分析功能点之间的依赖关系
|
||||
3. 按四个维度评估复杂度
|
||||
4. 确定复杂度等级
|
||||
5. 如果是复杂或超大任务：
|
||||
a. 识别可独立交付的阶段
|
||||
b. 按依赖关系排序
|
||||
c. 为每个阶段制定子计划
|
||||
6. 如果是简单或中等任务：
|
||||
a. 直接制定执行计划
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*文档版本：1.0.0*
|
||||
*生成日期：2025-12-15*
|
||||
*基于用户决策生成*
|
||||
1
.gitignore
vendored
1
.gitignore
vendored
@@ -2,3 +2,4 @@ anthropic-agent-skills/
|
||||
__pycache__/
|
||||
.venv/
|
||||
test-cache/
|
||||
.aide/
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "aide-plugin",
|
||||
"description": "Aide 工作流体系插件，提供环境配置、项目认知、文档管理和任务执行的标准化流程",
|
||||
"version": "2.0.1",
|
||||
"version": "2.0.3",
|
||||
"author": {
|
||||
"name": "Aide Team"
|
||||
},
|
||||
|
||||
@@ -1,210 +0,0 @@
|
||||
---
|
||||
description: 任务准备流程。分析用户任务描述，优化表述，处理待定项，产出可执行的任务细则。
|
||||
argument-hint: [任务原文档路径]
|
||||
---
|
||||
|
||||
# Aide 任务准备
|
||||
|
||||
你正在执行 Aide 任务准备流程。将任务描述转化为清晰、可执行的任务细则。
|
||||
|
||||
## 参数
|
||||
|
||||
- `$ARGUMENTS`：任务原文档路径（可选）
|
||||
- 未传入时使用配置中的默认路径
|
||||
|
||||
---
|
||||
|
||||
## 前置准备
|
||||
|
||||
**首先触发 `aide` skill 学习 aide 命令的使用方法。**
|
||||
|
||||
这是必要步骤，确保你了解 `aide flow` 等命令的正确用法。
|
||||
|
||||
---
|
||||
|
||||
## 开始
|
||||
|
||||
### 启动流程追踪
|
||||
|
||||
```bash
|
||||
aide flow start task-optimize "开始任务准备: <任务简述>"
|
||||
```
|
||||
|
||||
### 确定任务文档
|
||||
|
||||
```bash
|
||||
# 如果传入了参数
|
||||
任务文档 = $ARGUMENTS
|
||||
|
||||
# 如果未传入参数，使用配置默认值
|
||||
aide config get task.source
|
||||
```
|
||||
|
||||
读取任务文档内容。如文档不存在，询问用户提供任务内容或指定文档路径。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 1：任务分析
|
||||
|
||||
### 深度理解任务
|
||||
|
||||
- 任务要解决什么问题？
|
||||
- 最终交付物是什么？
|
||||
- 成功的标准是什么？
|
||||
- 涉及哪些模块/系统？
|
||||
- 是否有技术难点？
|
||||
|
||||
### 分析项目环境
|
||||
|
||||
根据需要阅读相关代码/文档，理解任务与项目现有结构的关系。
|
||||
|
||||
> 复杂任务（多子目标、多方案对比）建议使用 sequential-thinking 进行结构化分析
|
||||
|
||||
### 记录进度
|
||||
|
||||
```bash
|
||||
aide flow next-step "任务分析完成"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 阶段 2：任务优化
|
||||
|
||||
### 准确性优化
|
||||
|
||||
- 识别**歧义**和**不明确之处**
|
||||
- 识别**隐含假设**和**未说明的前提**
|
||||
- 明确任务**边界**
|
||||
|
||||
### 简洁性优化
|
||||
|
||||
- 识别**冗余表述**
|
||||
- 区分**真冗余**与**必要强调**
|
||||
|
||||
### 可执行性优化
|
||||
|
||||
- 将抽象要求转化为**具体步骤**
|
||||
- 确保每个步骤有明确的**输入、输出、验证标准**
|
||||
- 识别可能的**替代方案**
|
||||
|
||||
### 生成待定项
|
||||
|
||||
对于存在多种方案、有歧义、需要用户确认的内容，准备待定项数据。
|
||||
|
||||
### 记录进度
|
||||
|
||||
```bash
|
||||
aide flow next-step "任务优化完成，生成待定项"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 阶段 3：待定项处理
|
||||
|
||||
### 有待定项时
|
||||
|
||||
1. 将待定项数据写入 JSON 文件（如 `.aide/pending-items.json`）
|
||||
2. 提交待定项数据：
|
||||
|
||||
```bash
|
||||
aide decide submit .aide/pending-items.json
|
||||
```
|
||||
|
||||
3. 告知用户访问输出的链接进行确认
|
||||
4. 用户完成后获取结果：
|
||||
|
||||
```bash
|
||||
aide decide result
|
||||
```
|
||||
|
||||
### 记录进度
|
||||
|
||||
```bash
|
||||
aide flow next-step "用户完成待定项确认"
|
||||
```
|
||||
|
||||
### 无待定项时
|
||||
|
||||
任务描述已足够清晰，直接进入下一阶段。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 4：结果生成
|
||||
|
||||
### 生成任务细则
|
||||
|
||||
整合原始描述、优化结果、用户决策，产出任务细则：
|
||||
|
||||
```markdown
|
||||
# 任务细则
|
||||
|
||||
## 任务目标
|
||||
[清晰描述任务要达成的目标]
|
||||
|
||||
## 成功标准
|
||||
[明确的、可验证的成功标准]
|
||||
|
||||
## 执行步骤
|
||||
1. [步骤1]
|
||||
2. [步骤2]
|
||||
...
|
||||
|
||||
## 技术决策
|
||||
[已确认的技术选型]
|
||||
|
||||
## 约束与边界
|
||||
[任务范围边界]
|
||||
```
|
||||
|
||||
### 记录进度
|
||||
|
||||
```bash
|
||||
aide flow next-step "生成任务细则，等待用户确认"
|
||||
```
|
||||
|
||||
### 用户确认
|
||||
|
||||
向用户展示任务细则，询问确认：
|
||||
- **确认**：保存到任务细则文档
|
||||
- **需修改**：根据反馈调整
|
||||
|
||||
```bash
|
||||
aide flow next-step "用户确认任务细则"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 完成
|
||||
|
||||
任务准备完成，任务细则已保存。
|
||||
|
||||
```bash
|
||||
aide flow next-step "任务准备完成"
|
||||
```
|
||||
|
||||
提示用户：
|
||||
```
|
||||
任务细则已保存到 task-spec.md
|
||||
|
||||
可执行 /aide:exec 开始任务执行
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 处理问题
|
||||
|
||||
遇到问题时：
|
||||
|
||||
```bash
|
||||
# 一般问题
|
||||
aide flow issue "<问题描述>"
|
||||
|
||||
# 严重错误
|
||||
aide flow error "<错误描述>"
|
||||
```
|
||||
|
||||
需要回退时：
|
||||
|
||||
```bash
|
||||
aide flow back-step "<原因>"
|
||||
```
|
||||
@@ -54,10 +54,19 @@ aide config get task.source
|
||||
|
||||
#### 1.3 任务分析
|
||||
|
||||
##### 深度理解任务
|
||||
|
||||
- 任务要解决什么问题？
|
||||
- 最终交付物是什么？
|
||||
- 成功的标准是什么？
|
||||
- 涉及哪些模块/系统？
|
||||
- 是否有技术难点？
|
||||
|
||||
##### 分析项目环境
|
||||
|
||||
根据需要阅读相关代码/文档，理解任务与项目现有结构的关系。
|
||||
|
||||
> 复杂任务（多子目标、多方案对比）建议使用 sequential-thinking 进行结构化分析
|
||||
|
||||
#### 1.4 复杂度评估
|
||||
|
||||
@@ -68,10 +77,26 @@ aide config get task.source
|
||||
|
||||
#### 1.5 任务优化
|
||||
|
||||
- 识别歧义和不明确之处
|
||||
- 识别隐含假设
|
||||
- 明确任务边界
|
||||
- 生成待定项（如有）
|
||||
##### 准确性优化
|
||||
|
||||
- 识别**歧义**和**不明确之处**
|
||||
- 识别**隐含假设**和**未说明的前提**
|
||||
- 明确任务**边界**
|
||||
|
||||
##### 简洁性优化
|
||||
|
||||
- 识别**冗余表述**
|
||||
- 区分**真冗余**与**必要强调**
|
||||
|
||||
##### 可执行性优化
|
||||
|
||||
- 将抽象要求转化为**具体步骤**
|
||||
- 确保每个步骤有明确的**输入、输出、验证标准**
|
||||
- 识别可能的**替代方案**
|
||||
|
||||
##### 生成待定项
|
||||
|
||||
对于存在多种方案、有歧义、需要用户确认的内容，准备待定项数据。
|
||||
|
||||
#### 1.6 待定项处理（如有）
|
||||
|
||||
|
||||
103
statements/1.md
103
statements/1.md
@@ -1,103 +0,0 @@
|
||||
# 要求
|
||||
|
||||
首先阅读 @statements/optimize.md，还有 @README.md 并根据其指引了解该体系的commands+skills+aide program的所有信息
|
||||
|
||||
# 想法
|
||||
|
||||
我想对当前的体系做一些调整：
|
||||
|
||||
把commands/init拆分为两部分（新的命令可能不再适合init这个名称，需要重新命名合适的名称）：
|
||||
- （暂时称为cmd-1）一部分完全专注于环境依赖分析、环境配置、环境检测、环境修复，要求强制触发学习env-config skill，这一command将会是“独立运行”的，执行任务前不会再执行此命令，不再专门关注和处理环境问题，除非突发遇到意外错误
|
||||
- （暂时称为cmd-2）另一部分专注于命令LLM按需载入项目文档（由cmd-3创建和维护的），初次触发时仅了解项目结构、大意、脉络，且仅了解到此为止，目的是让LLM有对项目情况的大致认知，同时让LLM在后续了解了任务内容后，综合任务内容和项目脉络概况分析，先对相关内容进行更详细深入的了解，再执行任务，
|
||||
|
||||
创建一个新的command（暂时称为cmd-3），专门用于处理为项目创建和维护文档（这一command将会是“独立运行”的）：
|
||||
- 在环境配置中建立一条用于记录项目文档目录路径的数据
|
||||
- 如果项目文档目录路径不存在或该路径下文档为空，触发浅了解进行区块划分再进行完全深度了解然后新建文档
|
||||
- 先探索目录文件结构，文件大小，然后根据文件名、文件类型、目录结构可能含有的模块化语义等，对整个项目建立分初步区块计划，
|
||||
- 然后再逐个区块的尝试探索其各关键文档信息，验证区块划分是否合理，
|
||||
- 确定区块划分合理后，制定更详细和准确的区块分划计划文档，
|
||||
- 最后逐个区块的进行完全深度了解，并创建对应部分的文档，直到全部完成，
|
||||
- 注意，每当初次开始处理时都要检查区块计划文档，根据当前记录中的进度，接着完成接下来的任务，因为如果项目过大，可能需要多个全新对话多次重新执行才能完成所有区块的任务
|
||||
- 为了稳定多个不同步骤的关键联系，即区块计划文档，可以为这个文档建立一条环境配置数据记录其路径
|
||||
- 若项目文档存在则分区块进行完全深度了解，对文档内容进行验证和同步更新
|
||||
- 验证文档内容是否属实，是否与最新实现效果保持一致
|
||||
- 若不一致则以实现为准更新文档内容
|
||||
|
||||
把prep和exec两个command合并为一个，然后：
|
||||
- 这个命令的开发部分，除了现有的要强制触发aide skill的学习，
|
||||
- 还应该要求LLM检查当前flow状态（当前flow实现暂不支持通过aide flow查看进度状态，只能手动用git看，下文会提出实现此功能），查看最新的flow数据进度状态，
|
||||
- 只有最新的进度已经到finish了，或者flow数据为空暂不存在记录，这两种情况才应该start一个新flow，从task-optimize开始新记录，
|
||||
- 如果最新的进度还没有到finish，则应该根据进度状态进行分析，然后按需载入项目文档，接着之前的进度继续任务
|
||||
|
||||
aide flow目前不支持查看流程信息，我希望能让flow支持查看所有的任务流程名与task_id和根据task_id查看详细的目标flow状态详情，避免只能通过git尝试了解进度情况，比如我用git可以看到下面这样的信息：
|
||||
不过我希望flow的详细状态不用这么多，只要能看到impl、docs、finish等进度信息和简述、时间戳，git提交标识，这4项就够了，
|
||||
```
|
||||
* 79ac9a3 - [aide] finish: 文档更新完成，进入收尾 (11 小时前) <sayurinana(vm)>
|
||||
* bf5f813 - [aide] docs: 文档更新完成 (11 小时前) <sayurinana(vm)>
|
||||
* 1d5a015 - [aide] docs: 验证通过，进入文档环节 (11 小时前) <sayurinana(vm)>
|
||||
* 94aa3b1 - [aide] verify: 验证完成: 所有成功标准均已满足 (11 小时前) <sayurinana(vm)>
|
||||
* 0a97929 - [aide] verify: 实现完成，进入验证环节 (11 小时前) <sayurinana(vm)>
|
||||
* f772acf - [aide] impl: 核心功能实现完成，编译通过 (11 小时前) <sayurinana(vm)>
|
||||
* 65c2907 - [aide] impl: 流程设计完成，进入实现环节 (12 小时前) <sayurinana(vm)>
|
||||
* b9f9ccf - [aide] flow-design: 流程图设计完成（本任务暂不绘制，计划清晰） (12 小时前) <sayurinana(vm)>
|
||||
* a49ddbe - [aide] flow-design: 完成流程设计：已制定执行计划（4阶段） (12 小时前) <sayurinana(vm)>
|
||||
* c595425 - [aide] flow-design: 进入流程设计环节 (12 小时前) <sayurinana(vm)>
|
||||
* 2520fb1 - [aide] task-optimize: 整合用户决策，生成任务细则 (12 小时前) <sayurinana(vm)>
|
||||
* 44cad9f - [aide] task-optimize: 用户完成待定项确认 (12 小时前) <sayurinana(vm)>
|
||||
* d8fc11e - [aide] task-optimize: 任务优化完成,生成待定项 (12 小时前) <sayurinana(vm)>
|
||||
* 81b0786 - [aide] task-optimize: 任务分析完成 (12 小时前) <sayurinana(vm)>
|
||||
* 772e402 - [aide] task-optimize: 开始任务准备: Rust Terminal 贪吃蛇游戏 (12 小时前) <sayurinana(vm)>
|
||||
```
|
||||
|
||||
对于任务的分析优化阶段，我希望能对任务的复杂度（是指工作量上的复杂度）进行分析，
|
||||
- 对过于复杂的任务，梳理为多个完整的小任务，
|
||||
- 出一个任务计划总导览和多个完整的子计划的细则，然后依序完成，
|
||||
- 这类任务的执行过程，当完成task-optimize后，从flow-design到docs为一个完整子计划的全过程，多次循环逐个完成所有子计划的内容，一个子计划执行完docs后，开始下一个子计划的flow-design，最后全部完成后再finish
|
||||
- 比如现在的这个任务，就比较庞大，当前整个文档所描述的内容，应该在分析优化阶段被梳理为多个完整的子计划，再逐个实现
|
||||
|
||||
调整在流程图阶段的要求：
|
||||
- 强化流程图的要求，不论是什么任务，只要有任务就必须有流程图，
|
||||
- 因为整个任务的具体实现主要是LLM来完成，实际上用户主要处理的只是提供原任务信息和处理优化待定项的决定，还有后续可能的审阅，
|
||||
- 但是如果审阅时要每一个文件的改动细节够一个一个看的话太过于耗费时间，
|
||||
- 如果有图像形式的流程图，这会对用户很友好，而且如果能在流程图阶段就发现业务流上的逻辑错误，将能避免很多沉没成本，避免花了大量时间查看细节但其实大方向上就有错误浪费了时间
|
||||
- 我需要的流程图是那种，比如一个C/C++程序一般是从main函数开始，同时程序的本质其实就是顺序执行或分支/循环结构这些都能用流程图体现出来，代码的本质是为了实现业务逻辑也就是说可以把代码细节抽象为语义化简述（其实应该是写代码就是为了把高级抽象的人类语言业务逻辑实现为底层程序代码的过程），所以其实可以使用流程图把程序的逻辑流以语义化的方式呈现出来，
|
||||
- 而且一个函数可以被封装为一个用有规定的预期输入+输出的盒来表示，一个函数或模块就是一个子系统，子系统可以在一个单独的流程图中呈现其细节，就像是写代码时的模块化思维，封装分装到多个代码文件里那样类似的
|
||||
- 而对于有些不是写程序代码的任务也同样需要流程图，用户可以通过流程图来看出计划，将要做什么事，做事的顺序，
|
||||
|
||||
aide flow在flow-design阶段的实现好像不完善，
|
||||
- 我期望的行为是在进入flow-design时从环境配置中读取流程图目录路径，提醒LLM绘制流程图，
|
||||
- 其中的每一个next-step都预期LLM至少完成了一个完整的plantuml源文件，
|
||||
- 将会在每一个next-step时对流程图目录路径下的所有文件进行plantuml校验，没有错误时才运行进入下一步，否则将提示相关情况，反馈LLM要求先解决发现的问题，
|
||||
- 在next-part impl时先校验，有问题则先反馈要求解决（next-step和next-part时的校验如果发现问题，虽然进入下一步但也应该进行对应的状态记录并进行git提交，至于issue和error那是在impl阶段当LLM主动发现问题时才需要由LLM主动执行的问题状态进度而不是由aide程序检验发现问题时用的记录，同理task-optimize阶段结束进入下一环节时若检验优化结果细则文档或任务导览+子计划细则不存在，也要记录并提交同时反馈给LLM要求先解决问题），若plantuml源文件校验无误则将其全部构建为png文件，然后才进入下一环节
|
||||
|
||||
aide的环境配置文件中要加入是否在.gitignore中忽略.aide目录，不然有时我可能希望每次`git add .`提交都要保存.aide的状态，但每次任务的init阶段都会把.gitignore中加上.aide/忽略项，我都需要手动删除，会很麻烦，
|
||||
|
||||
而且我希望的是aide的环境配置文件要完全自文档化，用户直接打开配置文件查看就能知道所有支持的配置项，即使默认不启用的默认关闭的内容，也应该在注释中进行讲解且给出充足的示例用于参考学习，用户可以仅靠配置文件内含的注释就了解到所有支持的配置、模块、参数、格式等信息，而无需单独学习配置的详细规划文档信息，
|
||||
- 因为LLM操作环境配置文件数据的读/写完全是通过命令进行的，且不允许LLM直接读写此数据文件，所以即使文件内容大小本身再多再膨胀也不用担心污染token和上下文，只要尽可能考虑对用户友好即可
|
||||
|
||||
# 一些特定行为描述
|
||||
|
||||
独立运行：
|
||||
- 指通常会在一个独立启动的全新的对话中直接执行
|
||||
- 并在确认这部分任务目标完全解决后就退出关闭对话
|
||||
|
||||
项目文档：
|
||||
- 这里的项目文档指的是专用于面向LLM的文档
|
||||
- 专用于为LLM保存上下文
|
||||
- 把上下文记忆信息转储为持久化的文档内容
|
||||
- 和初始化上下文
|
||||
- 新对话中让LLM对项目结构、内容等有一个适当的认知，允许LLM先是只能看到脉络（先有对概况的认识，便于更好的分析任务提供帮助，又不会什么都还没干就消耗过多token和上下文），
|
||||
- 然后以此可以允许LLM在实际过程中对项目按需细化深化的进行了解，追溯枝叶根须
|
||||
- 所以对于这个项目文档的创建和维护时的编辑规范，相关的规则、约定等，可以针对面向LLM做优化、特化
|
||||
- 我希望文档被分为（或者你觉得我下面的分划方式不具备普遍适用性、泛用性的话，你可以根据上面所述的项目文档的期望效果，制定更合适的规划）一份总导览和多个子区块部分，
|
||||
- 但必须在子区块局部文档信息完整详细的同时保证总的来说语义一致，他人能仅依赖于子区块的文档及子区块本身的目录文件信息完全了解这个区块，并接手其后续工作，比如需要进行一些调整、删除、添加，
|
||||
- 以当前目录下的项目为例子，我想达到的效果是，如果后续我想对commands中init的业务细节、职能界定等进行调整：
|
||||
- 比如有一个新来的人，仅学习过docs/下那样的内容会写claude code的commands和skills，但是他对这个项目本身没有任何知识基础，那么我希望他可以在仅通过导览文档，知道他应该看哪个文档来完全掌握aide-plugin:init的信息和情况，然后对commands/init.md进行修改，还有更新对应子区块的文档，但仅需要更新子区块，而不用完整的知道aide-requirements.md（或者说所有所有子区块的信息，不必知道所有区块才行动，将文档区块化后我将会删除原aide-requirements.md）的全部内容
|
||||
- 还比如我想对aide程序中的env子命令进行功能调整，那位开发人员可以仅知道跟aide env有关的文档（导览 → aide程序体系导览 → env子命令细节），而不必在完整了解整个commands+skills+完整aide程序设计后才开始行动，
|
||||
- 并且对功能的调整也可以仅涉及相关代码文件和子命令细节文档，涉及导览时更新导览信息即可，导览远比全部的完整信息要轻量得多，
|
||||
|
||||
完全深度了解：
|
||||
- 指对于涉及的内容，比如一个项目就是该项目下的所有目录及其子目录下的每一个文件，
|
||||
- 如果是一个区块就是区块分划中制定的所有文件和目录及其子目录下的每一个文件，
|
||||
- 除非特别制定了应该忽略的文件和目录，默认情况下存在.gitignore文件则遵循其忽略项配置，比如如果.gitignore中设置了忽略`cache/`和`node_modules/`，则忽略这两个目录，不需要了解，
|
||||
- 对于未指定应该忽略掉的文件和目录，要每一个文件都进行读取和审阅分析，了解其内容含义
|
||||
6
task-now.md
Normal file
6
task-now.md
Normal file
@@ -0,0 +1,6 @@
|
||||
1. 首先阅读 @statements/optimize.md，还有 @README.md 并根据其指引了解该体系的commands+skills+aide program的所有信息
|
||||
2. 然后把原本的README.md移至docs目录下，重命名为project-details.md
|
||||
3. 编写新的README.md，内容要求：
|
||||
- 指导用户如何快速上手
|
||||
- 如何从此处安装插件
|
||||
- 如何安装和使用aide程序
|
||||
Reference in New Issue
Block a user