103 lines
13 KiB
Markdown
103 lines
13 KiB
Markdown
# 要求
|
||
|
||
首先阅读 @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/`，则忽略这两个目录，不需要了解，
|
||
- 对于未指定应该忽略掉的文件和目录，要每一个文件都进行读取和审阅分析，了解其内容含义 |