📃 docs: 准备用sonnet[1m]重启任务
This commit is contained in:
@@ -1,397 +0,0 @@
|
||||
# Aide 系统需求规格
|
||||
|
||||
## 一、项目背景
|
||||
|
||||
### 1.1 现状问题
|
||||
|
||||
原有 `ai-agent-memory/` 体系存在以下问题：
|
||||
|
||||
| 问题类型 | 具体表现 |
|
||||
|---------|---------|
|
||||
| 信息过载 | CLAUDE.md 包含完整流程规范，每次对话都需加载 |
|
||||
| 操作繁琐 | CSV 状态需手动编辑、PlantUML 命令冗长、Git 多步操作 |
|
||||
| 输出冗余 | 命令执行输出大量日志，无论成功失败 |
|
||||
| 流程耦合 | AB 部分虽拆分但仍需手动切换和阅读大量文档 |
|
||||
|
||||
### 1.2 转型目标
|
||||
|
||||
将原有内容体系转化为 Command + Skill 体系：
|
||||
|
||||
- **CLAUDE.md 精简化**：仅保留项目文件结构说明，不再指导规则和流程
|
||||
- **流程按需触发**：通过 Command 主动触发流程指导和规则启示
|
||||
- **操作确定性封装**：通过 Skill + 定制脚本简化操作，减少不确定性
|
||||
|
||||
---
|
||||
|
||||
## 二、核心设计原则
|
||||
|
||||
### 2.1 渐进式披露
|
||||
|
||||
- 按需调用、触发
|
||||
- 不在 CLAUDE.md 中堆积所有规则
|
||||
- 用户/LLM 主动调用时才加载相关指引
|
||||
|
||||
### 2.2 确定性封装
|
||||
|
||||
- 将可变过程转化为固定接口
|
||||
- 只暴露脚本程序和参数信息
|
||||
- 内部处理流程固定化，减少多余输出
|
||||
|
||||
### 2.3 信息隔离
|
||||
|
||||
- LLM 只传核心语义数据
|
||||
- 程序负责格式化、渲染、美化
|
||||
- 返回结果极简，只含决策所需信息
|
||||
|
||||
### 2.4 核心与形式分离
|
||||
|
||||
| 类型 | 定义 | 处理方式 |
|
||||
|------|------|----------|
|
||||
| 核心信息 | 分析思考、优化思考、业务决策 | LLM 自由发挥，不受限制 |
|
||||
| 形式问题 | 待定项呈现、状态记录、环境配置 | 程序封装，减少 token 污染 |
|
||||
|
||||
---
|
||||
|
||||
## 三、组件职责定义
|
||||
|
||||
### 3.1 Command（命令）
|
||||
|
||||
**本质**：对 LLM 的要求和规则
|
||||
|
||||
**内容焦点**：
|
||||
- 思考方法论：怎么分析、怎么优化、怎么执行
|
||||
- 流程指导：阶段划分、核心必做、质量要求
|
||||
- 决策边界：哪些由 LLM 自主完成，哪些需要用户确认
|
||||
|
||||
**设计要求**：
|
||||
- 聚焦核心思考，不涉及工具调用细节
|
||||
- 指导方向而非限制形式
|
||||
- 结果输出不受格式约束，让 LLM 竭尽全力发挥
|
||||
|
||||
### 3.2 Skill（技能）
|
||||
|
||||
**本质**：告诉 LLM 有什么工具可用
|
||||
|
||||
**内容焦点**：
|
||||
- 工具使用说明：命令、参数、输出格式
|
||||
- 调用示例：典型场景的命令示例
|
||||
- 输出解读：各种输出前缀的含义
|
||||
|
||||
**设计要求**：
|
||||
- 纯工具说明，不涉及流程指导
|
||||
- 精简明确，便于快速查阅
|
||||
- 封装形式问题，减少 LLM 认知负担
|
||||
|
||||
---
|
||||
|
||||
## 四、命令清单
|
||||
|
||||
### 4.1 /aide:init - 认知初始化
|
||||
|
||||
**触发时机**：进入项目开始工作时
|
||||
|
||||
**职责**：
|
||||
1. 触发 LLM 对项目内容的主动认知
|
||||
2. 检测开发环境并自动修复问题
|
||||
3. 介绍 aide 流程体系和可用能力
|
||||
|
||||
**特点**：
|
||||
- 环境问题在此阶段解决，避免后续业务逻辑被打扰
|
||||
- 沉没成本小：发现严重问题可重开对话
|
||||
|
||||
### 4.2 /aide:prep - 任务准备
|
||||
|
||||
**触发时机**：准备开始新任务时
|
||||
|
||||
**职责**：
|
||||
1. 任务分析（理解目标、识别复杂度、分析环境）
|
||||
2. 任务优化（准确性、简洁性、可执行性）
|
||||
3. 待定项处理（通过 `aide decide` 程序化呈现）
|
||||
4. 结果生成（LLM 自由发挥，产出 task-spec.md）
|
||||
|
||||
**核心原则**：
|
||||
- 分析和优化阶段：指导 LLM 思考方向，让其竭尽全力发挥
|
||||
- 待定项处理：程序化呈现，减少 token 污染
|
||||
- 结果生成：不受格式限制，由用户直接审阅
|
||||
|
||||
**运行特点**：
|
||||
- 轻量化：不创建工作目录、不记录状态、不 git 提交
|
||||
|
||||
### 4.3 /aide:exec - 任务执行
|
||||
|
||||
**触发时机**：任务准备完成，开始执行时
|
||||
|
||||
**职责**：
|
||||
1. 流程规划（理解细则、制定计划、环境准备）
|
||||
2. 迭代实现（按计划执行、状态同步、阻塞处理）
|
||||
3. 验证交付（对照标准、功能验证）
|
||||
4. 文档收尾（变更记录、版本发布）
|
||||
|
||||
**核心原则**：
|
||||
- 业务代码编写：LLM 自由发挥，不加程序约束
|
||||
- 状态管理、版本控制：通过 `aide flow` 程序处理，避免信息污染
|
||||
|
||||
---
|
||||
|
||||
## 五、技能清单
|
||||
|
||||
### 5.1 aide flow - 进度追踪
|
||||
|
||||
**用途**：记录任务执行状态 + Git 自动提交 + 流程校验
|
||||
|
||||
**核心命令**：
|
||||
- `aide flow start <环节名> <总结>` - 新任务开始
|
||||
- `aide flow next-step <总结>` - 小步骤前进
|
||||
- `aide flow back-step <总结>` - 小步骤回退
|
||||
- `aide flow next-part <环节名> <总结>` - 大环节前进
|
||||
- `aide flow back-part <环节名> <总结>` - 大环节回退
|
||||
- `aide flow issue <描述>` - 记录问题
|
||||
- `aide flow error <描述>` - 记录严重错误
|
||||
|
||||
**设计要点**：
|
||||
- 集成 git 操作：每次步骤变化自动 `git add . && git commit`
|
||||
- 流程校验：检测环节跳转是否符合预期流程
|
||||
- 环节特定行为：
|
||||
- flow-design 环节：检验 PlantUML 语法
|
||||
- docs-upgrade 环节：检验 CHANGELOG 更新
|
||||
- 静默原则：无输出 = 正常
|
||||
|
||||
### 5.2 aide decide - 待定项确认
|
||||
|
||||
**用途**：程序化呈现待定项，通过 Web 界面获取用户确认
|
||||
|
||||
**核心命令**：
|
||||
- `aide decide '<json>'` - 提交待定项数据，启动 Web 服务
|
||||
- `aide decide result` - 获取用户决策结果
|
||||
|
||||
**设计要点**：
|
||||
- LLM 传入精简 JSON 数据
|
||||
- 程序启动 Web 服务，输出访问链接
|
||||
- Web 界面渲染原文高亮、选项卡片
|
||||
- 用户操作后存储决策
|
||||
- LLM 读取精简决策结果
|
||||
|
||||
### 5.3 aide env - 环境管理
|
||||
|
||||
**用途**：检测并修复项目开发环境
|
||||
|
||||
**核心命令**：
|
||||
- `aide env ensure` - 检测环境并自动修复
|
||||
|
||||
**设计要点**：
|
||||
- 成功时输出极简：`✓ 环境就绪 (python:3.12)`
|
||||
- 自动修复小问题时简短提示
|
||||
- 仅无法修复时才需要 LLM 关注
|
||||
|
||||
---
|
||||
|
||||
## 六、信息流设计
|
||||
|
||||
### 6.1 待定项处理流程
|
||||
|
||||
```
|
||||
LLM 程序 用户
|
||||
│ │ │
|
||||
│ JSON (精简数据) │ │
|
||||
│─────────────────────→│ │
|
||||
│ │ 启动Web服务 │
|
||||
│ │ 输出访问链接 │
|
||||
│ │─────────────────────→│
|
||||
│ │ │
|
||||
│ │ Web界面交互 │
|
||||
│ │←─────────────────────│
|
||||
│ JSON (决策结果) │ │
|
||||
│←─────────────────────│ │
|
||||
```
|
||||
|
||||
### 6.2 输出精简原则
|
||||
|
||||
| 场景 | 输出策略 |
|
||||
|------|----------|
|
||||
| 成功 | 极简确认：`✓ 操作完成` |
|
||||
| 自动修复 | 简短提示：`✓ 已修复: xxx` |
|
||||
| 警告 | 告知但可继续：`⚠ 警告内容` |
|
||||
| 失败 | 详细原因：`✗ 失败原因及建议` |
|
||||
|
||||
### 6.3 错误恢复机制
|
||||
|
||||
| 级别 | 处理方式 |
|
||||
|------|----------|
|
||||
| ⚠ 警告 | 记录，分析是否影响继续，记录"继续-xxx"或"解决阻塞-xxx" |
|
||||
| ✗ 错误 | 必须先记录并解决。默认自行取最优解，3次尝试失败则停止等待用户。成功解决时在 discuss/ 创建分析文档 |
|
||||
|
||||
---
|
||||
|
||||
## 七、LLM 自由发挥边界
|
||||
|
||||
### 7.1 需要程序约束的场景
|
||||
|
||||
- 环境检测与修复
|
||||
- 待定项呈现与确认
|
||||
- 状态记录与更新（含 git 提交）
|
||||
|
||||
### 7.2 不需要程序约束的场景
|
||||
|
||||
- 任务分析思考
|
||||
- 任务优化思考
|
||||
- 业务决策判断
|
||||
- 任务细则编写（task-spec.md）
|
||||
- 业务代码编写
|
||||
- 结果文档产出
|
||||
|
||||
---
|
||||
|
||||
## 八、数据格式规范
|
||||
|
||||
### 8.1 待定项数据格式
|
||||
|
||||
**输入格式（LLM → 程序）**：
|
||||
|
||||
```json
|
||||
{
|
||||
"task": "任务简述",
|
||||
"source": "now-task.md",
|
||||
"items": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "问题标题",
|
||||
"location": {
|
||||
"file": "now-task.md",
|
||||
"start": 5,
|
||||
"end": 7
|
||||
},
|
||||
"context": "详细说明（可选）",
|
||||
"options": [
|
||||
{
|
||||
"value": "option_a",
|
||||
"label": "选项A描述",
|
||||
"score": 85,
|
||||
"pros": ["优点1", "优点2"],
|
||||
"cons": ["缺点1"]
|
||||
}
|
||||
],
|
||||
"recommend": "option_a"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**输出格式（程序 → LLM）**：
|
||||
|
||||
```json
|
||||
{
|
||||
"decisions": [
|
||||
{"id": 1, "chosen": "option_a"},
|
||||
{"id": 2, "chosen": "option_b", "note": "用户备注"}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
> 注：`note` 字段仅在用户有备注时出现
|
||||
|
||||
### 8.2 输出前缀规范
|
||||
|
||||
| 前缀 | 函数 | 用途 |
|
||||
|------|------|------|
|
||||
| ✓ | `ok` | 成功 |
|
||||
| ⚠ | `warn` | 警告（可继续） |
|
||||
| ✗ | `err` | 失败 |
|
||||
| → | `info` | 进行中 |
|
||||
| [n/m] | `step` | 步骤进度 |
|
||||
|
||||
---
|
||||
|
||||
## 九、数据存储
|
||||
|
||||
### 9.1 存储位置
|
||||
|
||||
所有 aide 自动创建和管理的数据文件统一存放在项目路径下的 `.aide/` 目录：
|
||||
|
||||
```
|
||||
.aide/
|
||||
├── config.toml # 项目配置（自文档化，带注释）
|
||||
├── flow-status.json # 当前任务进度状态
|
||||
├── decisions/ # 待定项决策记录
|
||||
│ └── {timestamp}.json
|
||||
└── logs/ # 操作日志
|
||||
```
|
||||
|
||||
### 9.2 .gitignore 处理
|
||||
|
||||
- `aide init` 时自动检查 `.gitignore`
|
||||
- 默认添加 `.aide/` 为忽略项
|
||||
- 可在配置中指定不忽略
|
||||
|
||||
### 9.3 配置机制
|
||||
|
||||
- 配置文件不存在时输出 `⚠ 配置文件不存在，使用默认配置`
|
||||
- `aide init` 时自动创建默认配置
|
||||
- 配置文件自带详细注释（自文档化）
|
||||
- **LLM 不允许直接读取配置文件**（避免污染上下文）
|
||||
- 通过 `aide config get <key>` 读取配置
|
||||
- 每次设置/获取都集成验证
|
||||
|
||||
---
|
||||
|
||||
## 十、实施结构
|
||||
|
||||
### 10.1 最终产出
|
||||
|
||||
1. **README.md** - 用户入口文档
|
||||
2. **插件市场目录** - 可快速安装的 Claude Code 插件
|
||||
3. **aide 程序目录** - 运行时脚本系统
|
||||
|
||||
### 10.2 插件目录结构
|
||||
|
||||
```
|
||||
aide-marketplace/
|
||||
├── .claude-plugin/
|
||||
│ └── marketplace.json
|
||||
└── aide-plugin/
|
||||
├── .claude-plugin/
|
||||
│ └── plugin.json
|
||||
├── commands/
|
||||
│ ├── init.md
|
||||
│ ├── prep.md
|
||||
│ └── exec.md
|
||||
└── skills/
|
||||
└── aide/
|
||||
└── SKILL.md
|
||||
```
|
||||
|
||||
### 10.3 程序目录结构
|
||||
|
||||
```
|
||||
aide/
|
||||
├── aide.sh # Linux/Mac 入口
|
||||
├── aide.bat # Windows 入口
|
||||
├── main.py # Python 主入口
|
||||
├── core/
|
||||
│ ├── config.py # 配置读写
|
||||
│ └── output.py # 输出格式（✓/⚠/✗）
|
||||
├── flow/ # aide flow
|
||||
│ ├── tracker.py # 进度追踪
|
||||
│ ├── git.py # git 自动提交
|
||||
│ └── validator.py # 流程校验
|
||||
├── decide/ # aide decide
|
||||
│ ├── server.py # HTTP 服务
|
||||
│ └── web/ # 静态 React 前端
|
||||
└── env/
|
||||
└── ensure.py # 环境检测修复
|
||||
```
|
||||
|
||||
### 10.4 分发方式
|
||||
|
||||
初期：打包压缩包分享，验证可用后考虑远程仓库 + 包托管
|
||||
|
||||
---
|
||||
|
||||
## 十一、待设计内容
|
||||
|
||||
以下内容将在后续讨论中逐步细化：
|
||||
|
||||
- [ ] Commands 详细内容（init.md / prep.md / exec.md）
|
||||
- [ ] SKILL.md 详细内容
|
||||
- [ ] aide flow 子命令详细设计
|
||||
- [ ] aide decide Web 界面设计
|
||||
- [ ] 配置文件完整字段定义
|
||||
@@ -1,28 +0,0 @@
|
||||
先对目前存在的问题进行讨论
|
||||
|
||||
是的，期望的行为是用户只需通过README学习可用的command即可，通过快捷命令触发流程启动，也无需关心skills，它被command自动触发学习和使用，
|
||||
|
||||
我认为需要封装的操作是一些流程与形式上的操作，以此减少不确定性并减少token污染减少不必要的LLM注意，
|
||||
把核心的分析、思考、业务内容交给LLM不加限制竭尽所能尽情发挥，
|
||||
我这里有一点前期设计草案，
|
||||
|
||||
这套系统开发好后我希望成品是3项：
|
||||
- 一个可供用户快速上手且能引导用户根据需要进行深入了解的README.md
|
||||
- 一个可以快速安装的插件市场（在README中提供快捷指令）
|
||||
- 一套实现了目标程序系统的项目目录
|
||||
|
||||
我希望的下发/分享方式是把这1个文档+2个目录打包为一个压缩包分享（先以此为暂定目标，当该体系经验证可用且高效后再考虑更好的形式：再把插件市场迁入远程仓库，把程序投放到一些包托管平台，便于快速安装，然后只需以网页或文档的形式分享README即可），
|
||||
|
||||
@aide-requirements.md 是一个我原本暂定的细则文档（如果它有任何不合理之处，你都可以质疑，这只是个草案，不要被它的定式限制），现在需要你根据我前述的需求，评估这个文档是否满足：仅以这一份文档为核心，辅以原 ai-agent-memory/ 和 docs/ 目录下的信息，开始实际开发任务，得到3项最终产出
|
||||
|
||||
关于 @aide-requirements.md 的补充：
|
||||
1. prep和exec的细节都要从原ai-agent-memory目录下的相关文档中获取，
|
||||
2. 其实我希望你可以完全忽略我在aide-requirements.md中aide程序的细节设计，
|
||||
- 就是说，保留`aide env`和`aide progress`等主要支项（这个也可以忽略，不遵循，仅部分参考，后续可以增添或删减），但完全忽略`aide env check`、`aid env ensure`、`aide progress init`等更细节的内容，还包括具体的输入输出数据结构等，
|
||||
- 因为我希望你可以引导我对aide程序体系进行重新设计，部分参考原本的设计，找出可能存在的不足，可以完善的部分，可能存在的伪需求，可以删减的部分，
|
||||
3. 关于待定项的交互流程，我想实现一个程序（最终要把它集成到aide中，以aide为入口启动），启动这个程序后，它会读取相关的数据文件（用户提出的原始任务文档及其他本次任务涉及到的文件、LLM分析得出的待定项数据），基于这些数据渲染成对用户友好的web界面，提供网页的HTTP链接供用户访问，用户在网页界面中以图形化的方式交互式操作数据，程序把用户的操作结果（用户的决定）存储到一个新的数据文件，然后LLM请求用户意见结果时，aide读取这个文件把用户的决定反馈给LLM
|
||||
4. 我希望最外层的aide入口封装使用平台的shell脚本，但仅仅只是封装部分，这个封装的任务是检查python虚拟环境或系统环境的python，然后通过检测到的python执行真正的python入口程序，
|
||||
- 封装部分仅负责检测python并执行真正的入口，在检测到不存在时抛出致命错误，需要用户处理好至少先提供一个可用的基本的python3才能继续
|
||||
- 封装部分教轻量，可以为win、linux/mac单独编写也不会太麻烦
|
||||
- 由封装调用真正的python入口程序后，处理更核心的逻辑，
|
||||
- 使用python是为了减少统一跨平台、开发、调试与测试运行的成本，同时还可以作为胶水语言在适当的时候引入其他语言更好的完成部分任务，比如前面说的处理待定项交互的程序，就很适合用ts+react+nextjs这样的全栈技术栈来实现，同时兼顾界面和后端，还能快速落地，前端比flutter轻量，后端比rust轻量，且性能完全满足需求，
|
||||
@@ -1,133 +0,0 @@
|
||||
# 对已发现的可能存在的问题的答复
|
||||
|
||||
## 状态记录的必要性存疑
|
||||
|
||||
要把保存状态记录的操作程序化
|
||||
|
||||
记录每一个步骤的状态变更是因为实际使用时可能会中断任务执行，但恢复时可能不再使用claude code，而是其他agent cli，或者是直接由真实开发人员接手，此时可以通过状态记录追溯当前进度和操作痕迹，甚至是通过git提交看到每一个步骤的细节，
|
||||
|
||||
但是为了减轻负担，所以把这个其实不太必要，任务简单但却频繁重复的过程封装为固定程序，
|
||||
|
||||
创建一个独立的aide二级命令<1>完成这项任务
|
||||
|
||||
> 我会在答复中把我认为应该创建为单独二级命令的部分提出来，但是我不会立刻为其命名，仅标记为"二级命令<n>"，后续我们再详细谈明确的命令职责界定，业务细节，及其命名，
|
||||
|
||||
## 伪需求/过度封装
|
||||
|
||||
其实我想说的忽略掉细节的命令分支比如二级命令env、build、version等，三级命令check、ensure、init、update等，不是说要在新设计中去除掉所有的二三级命令，而是希望你忽略原有的设计定式，引导我进行重新设计，使所有的命令都更符合需求、符合场景，
|
||||
|
||||
env的check和ensure确实存在伪需求现象，仅保留ensure即可
|
||||
|
||||
workspace、version和build都可以删去，uml图的图像输出和版本控制都完全交由二级命令<1>在流程中动态反馈，
|
||||
|
||||
## aide-version
|
||||
|
||||
是的，claude code本身能很好地完成git操作，但它会出于一些难以预见的实际项目情况考虑，频繁大量使用git status、git stash等操作，每一次操作的输出都会大量污染LLM的上下文
|
||||
|
||||
git操作单独封装确实价值很有限，我想把这部分操作集成进二级命令<1>中，细节后面我会单独提意见
|
||||
|
||||
## aide:init
|
||||
|
||||
它主要是触发agent cli中LLM对项目内容详情的主动认知，并对项目所需的开发环境进行检测和自动修复，避免后续因为环境报错导致不必要的上下文污染，
|
||||
|
||||
LLM确实能在遇到问题时很好地解决问题，但我希望它在处理业务逻辑时不要被这些不必要的问题所打扰，
|
||||
|
||||
若在init阶段发现并解决了环境问题，此时的沉没成本很小，我可以在解决问题后直接结束本次对话，重新开始新的对话，此时的init就只会看到一些✓，然后我可以放心的继续接下来的任务计划完成，
|
||||
|
||||
## Web待定项界面
|
||||
|
||||
这部分实现确实具有不小的复杂度，
|
||||
|
||||
我想把它单独创建为一个二级命令<2>，
|
||||
|
||||
## 缺失：错误恢复机制
|
||||
|
||||
> 原设计定义了输出前缀（✓/⚠/✗），但没有定义：
|
||||
> - 错误发生后LLM应该如何响应
|
||||
> - 是否需要重试机制
|
||||
> - 如何处理部分成功的情况
|
||||
|
||||
我的想法：
|
||||
|
||||
遇到⚠时使用二级命令<1>记录，分析其是否影响继续执行，若不影响原定计划实现，则记录“继续-（遇到的问题信息）”，若影响则记录“解决阻塞-（遇到的问题 + 受影响的部分），
|
||||
|
||||
若遇到✗则不论是否阻塞计划，都要先记录并解决，同时注意：
|
||||
- 默认情况都自行取最优解以解决阻塞，失败则尝试更换解决方案，中途无需记录对解决方案的分析思考和决定，仅在成功解决时才在 discuss/ 目录下创建问题的分析和解决记录文档，若3次尝试都无法解决则强制停止计划执行并创建错误报告然后通知用户等待用户给出下一步意见，
|
||||
- 如果用户明确指出，不应该自行解决遇到的✗，则每遇到✗时停止或按用户的特定指导进行操作
|
||||
|
||||
## 缺失：配置的默认值与覆盖机制
|
||||
|
||||
配置文件不存在时输出⚠警告消息并视为未指定配置文件
|
||||
|
||||
运行aide-init时，若看到配置不存在的警告，应该按照全局默认配置并根据项目创建项目下默认配置文件，然后根据项目情况分析后对配置文件进行针对性设置更新（通过skill学习然后操作aide进行设置，不允许直接读配置文件，因为我希望配置文件自带大量详细的注释和配置示例实现子文档化，对用户友好，但这样的文件被LLM读取会严重污染上下文，LLM只被允许通过aide读取环境配置）
|
||||
|
||||
对于配置文件，后续有可能会为其开发像待定项web界面那样专用的面向用户的图形化交互式界面，
|
||||
|
||||
配置不需要单独的验证指令，每一次的设置和获取都应该封装好集成的验证，若无问题则表现为无事发生，仅在自动检验出现异常现象时输出✗错误，
|
||||
|
||||
# 对一些二级命令的想法💡
|
||||
|
||||
因为希望你根据功能为各命令进行命名，使其名称可以简短的同时能见名知意、名副其实
|
||||
|
||||
但是有个名称更便于指代，所以后续我都用cmdn来作为临时名称，例如二级命令<1>就暂称为`aide cmd1`
|
||||
|
||||
## 二级命令`<1>`
|
||||
|
||||
预期的行为（本节下面出现的`<desc>`表示必填占位描述，`[desc]`表示选填占位描述）：
|
||||
|
||||
- `aide cmd1 start <task-optimize> <开始tui贪吃蛇程序设计>`
|
||||
- `aide cmd1 next-step <完成任务分析，输出待定项，等待用户确认>`
|
||||
- `aide cmd1 back-step <用户确认待定项同时提出新的意见>`
|
||||
- `aide cmd1 next-step <重新分析优化待定项，等待用户确认>`
|
||||
- `aide cmd1 next-step <用户完成待定项处理并确认继续>`
|
||||
- `aide cmd1 next-step <生成优化结果-任务细则，等待用户确认>`
|
||||
- `aide cmd1 next-part <flow-design> <任务细则经用户确认，进入流程图设计环节>`
|
||||
- `aide cmd1 next-step <流程图设计完成>`
|
||||
- `aide cmd1 next-step <解决流程图报错>`
|
||||
- `aide cmd1 next-part <main> <成功生成png流程图像，进入主体环节>`
|
||||
- `aide cmd1 next-step <mod1完成>`
|
||||
- `aide cmd1 next-step <mod2完成>`
|
||||
- `aide cmd1 back-part <task-optimize> <用户中断，用户分析流程图后提出问题，返工重新制定任务>`
|
||||
- `aide cmd1 next-step <重新分析优化待定项，等待用户确认>`
|
||||
- ……
|
||||
- `aide cmd1 next-step <mod1完成>`
|
||||
- `aide cmd1 issue <⚠实现mod2时遇到阻塞性问题>`
|
||||
- `aide cmd1 next-step <问题解决，mod2完成，保存问题分析报告>`
|
||||
- `aide cmd1 issue <⚠实现mod3时遇到阻塞性问题>`
|
||||
- `aide cmd1 error <✗问题无法解决，保存错误报告，等待用户处理>`
|
||||
- ……
|
||||
|
||||
|
||||
以上，从前到后，是任务过程中预期的一种流程（此处为了演示和为分析提供信息，含有较多返工和警告与错误，实际情况可能问题较少能一直next），及其预期的参数形式
|
||||
|
||||
其中只有start和next-part、back-part这三项除了总结还需要携带具体的指定大环节名，其他的则只需要LLM为当前小步骤生成一句总结即可，
|
||||
|
||||
start需要是因为任务开始时不能保证一定是从最初的任务优化开始的，start会触发aide cmd1生成新的项目任务工作空间，
|
||||
|
||||
next-part和back-part需要是因为进入下一环节时简单的增强一下“现在你已经进入了xxxx大环节了”的概念，一个环节名不会花费多少token但能稍微聚焦一下注意力，而back则是非常需要，因为aide没法自行确定应该返工到的是哪一个环节，返工不一定只返上一个环节，也不一定每次都要返回到最初的环节，
|
||||
|
||||
我希望aide cmd1可以集成对git的处理，每一次的步骤变化，都把环节名加上LLM生成的总结作为提交信息，自动使用`add .`添加然后完成提交，完全不需要LLM再关注版本控制问题，skills中也不再需要单独处理，
|
||||
|
||||
aide cmd1还有一个作用就是，按既有流程顺序对环节的变化做检验，比如task-optimize时的下一环节应该是flow-design，但如果LLM此时调用了next-part main，则aide cmd1会小小的输出一个⚠警告，动态反馈给LLM提醒流程有误
|
||||
|
||||
当已处于flow-design这一环节时，每一次的next-step，cmd1都应该尝试校验环境配置中流程图文件目录下的所有文件，当校验出错时输出一个⚠警告，提醒LLM需要解决流程图错误，当next-part时，除了检验还要生成png图像输出，出错则警告，顺利完成则无输出，进行git提交后正常进入下一环节
|
||||
|
||||
当进入docs-upgrade环节时，cmd1输出普通消息提醒LLM记得更新CHANGELOG，对CHANGELOG文件的修改不需要封装，交给LLM自由发挥，已处于docs-upgrade环节尝试next-part时，cmd1要检验CHANGELOG是否有更新，并从git提交记录中找到旧的CHANGELOG文件，检查版本号部分是否正常更新，
|
||||
|
||||
一般情况下aide cmd1无输出，“没有消息就是好消息”
|
||||
|
||||
aide cmd1的数据文件不保存在项目目录下，而是和一般的APP一样保存在自己的用户数据目录下属于这个程序的存储路径中，
|
||||
|
||||
cmd1不需要和start、next-*等命令同级的complete命令用于完成时，即使最后一环节步骤全部完成也不需要，用户随时有可能返工或重新切入任务流程重新启动
|
||||
|
||||
## 二级命令`<2>`
|
||||
|
||||
暂时仅规定它需要输入的数据格式和它应该输出的数据格式，及其启动入口，
|
||||
|
||||
另外再单独讨论其实现细节，
|
||||
|
||||
它本身可以是任何形式的比如web、app、cli等，只要满足输入输出要求即可，但是APP过于重量级，而cli也较为麻烦需要用户单独启动一个终端并进入目标目标运行，一键启动的前后端分离式web形式对用户最友好，启动后简单输出链接地址，用户直接访问网页链接即可进行操作，
|
||||
|
||||
我希望使用python+静态react，不用nextjs全栈，但需要python在启动时，不仅提供用于操作本地文件的后端API，还封装好类似nginx的web服务器，它基于静态的index.html提供前端的web访问，避免用户还要自行部署react才能访问
|
||||
|
||||
关于待定项的典型数量和复杂度等输入数据格式细节，你可以尝试以 @now-task-example.md 为一个待分析和优化的用户任务，对其按照原体系中的task-builder要求进行处理，输出原版待定项文档，然后从中提取和转化出含有完整关键信息但更精简的json数据结构，
|
||||
@@ -1,17 +0,0 @@
|
||||
使用rust编写一个terminalUI的cli贪吃蛇游戏
|
||||
|
||||
支持引入随机数和一些难度递增规则自动生成后续关卡
|
||||
|
||||
支持游戏历史记录数据的自动保存和自动读取
|
||||
|
||||
游戏启动界面可以读取存档或创建新存档，支持设置难度递增速度、设置玩家名
|
||||
|
||||
游戏界面显示关卡信息、分数信息等丰富玩家体验
|
||||
|
||||
支持暂停
|
||||
|
||||
除了设置玩家名这样的，其他所有输入都要是无缓冲输入，按下即生效
|
||||
|
||||
要能让界面自动适应终端窗口大小（界面实时显示界面大小），且不要那种滚轮往上滑满是被刷屏的之前的旧帧，要直接修改字符坐标，
|
||||
|
||||
退出程序后我不想看到往上翻全是被刷满屏的样子（不是说用clear清屏，是希望不要用疯狂刷屏来刷新界面），
|
||||
@@ -1,17 +0,0 @@
|
||||
1. 你的理解准确无误
|
||||
2. 命名分别选用`aide flow`和`aide decide`
|
||||
3. json数据结构大体上设计的挺好的，还有小部分我不太满意，你看看我的意见是否合理：
|
||||
- json的数据可以不再需要Uxxx这样的编号形式，直接1、2、3简单递增即可
|
||||
- 仅给出了LLM自行生成的问题简述，我需要的是具体的指出原文的哪一行到哪一行，（后续我希望web界面呈现问题时渲染出原文件的局部，带行号，模糊/歧义/可优化的来源部分高亮显示）
|
||||
- 同样决策中的编号也只需简单序号即可
|
||||
- 非常棒，额外的意见字段只需要在有的时候才出现，没有备注时连"note"键都不应该出现
|
||||
4. 新的意见，我想把所有由aide自动创建、统一管理的数据文件都默认保存到项目路径下的`.aide`目录下，比如环境配置文件、状态更新数据文件（之前计划的是和一般的APP一样保存在自己的用户数据目录下属于这个程序的存储路径中，现在改到.aide），默认情况下在init环境检查`.gitignore`,为.aide添加为忽略项，除非在环境配置中指定不忽略
|
||||
|
||||
---
|
||||
|
||||
另外，我想知道目前为止的所有信息是否已经足够建立一份核心文档，足够以这一份文档为核心，辅以原 ai-agent-memory/ 和 docs/ 目录下的信息，开始实际开发任务，得到3项最终产出（README+插件市场目录+程序系统目录）
|
||||
|
||||
若已经足够我希望能先对原有的aide-requirements.md（以它为核心文档）进行更新，补充完善不足之处，删去即将讨论和重新定义的部分，
|
||||
接下来开始引导我对aide整个系统进行重新设计，
|
||||
这个过程中我希望你的所有想法、建议、报告等等信息全部以.md文档报告的形式保存到 discuss/ 目录下（从现在之后开始，刚刚这次不需要重新建立报告），这便于我仔细查阅和思考，
|
||||
而我也会把我的回复创建.md文档报告保存到 reply/ 目录下并告诉你文件名（就像现在这个答复文档这样），
|
||||
@@ -1,3 +0,0 @@
|
||||
1. 我同意方案A
|
||||
2. 由你在遵循commands设计理念的规则下自行发挥，编写能实现目标效果的最优commands
|
||||
3. 连续完成commands和skills部分，暂时不处理aide细节设计，
|
||||
@@ -18,3 +18,4 @@
|
||||
3. 而且我希望的是prep的最开始就要执行aide flow，我在before-2.md中已经举了很详细的从头开始的先后调用的示例了，你要更正prep的指导内容，并更新skill中关于开头部分的flow环节名
|
||||
|
||||
4. 我想要prep和exec都要可以接受传入指定文档路径参数，prep指定任务原文档，exec指定任务细则文档，当未传入时，使用项目的环境配置文件中设置的默认的原文档和细则文档（这个配置应该要在init阶段最后检查项目环境配置时由aide env输出反馈给LLM，通常默认情况下原文档默认为task-now.md， 细则文档默认为task-spec.md），
|
||||
|
||||
|
||||
Reference in New Issue
Block a user