134 lines
9.9 KiB
Markdown
134 lines
9.9 KiB
Markdown
# 对已发现的可能存在的问题的答复
|
||
|
||
## 状态记录的必要性存疑
|
||
|
||
要把保存状态记录的操作程序化
|
||
|
||
记录每一个步骤的状态变更是因为实际使用时可能会中断任务执行，但恢复时可能不再使用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数据结构，
|