34 lines
2.7 KiB
Markdown
34 lines
2.7 KiB
Markdown
对当前的commands&skills&aide做一些调整，记得完成调整后同步更新所有相关文档
|
||
|
||
我想为run添加一些步骤规定，同时更新aide配合实现目标，对一些可程序化的行为进行封装
|
||
|
||
我的想法如下：
|
||
|
||
---
|
||
|
||
1.
|
||
|
||
创建和维护一份用于记录git分支概况的文档，
|
||
当start一个新任务时，检查git状态是否干净，若有未跟踪未暂存的文件状态，使用git add .跟踪和暂存所有这些所有文件，然后创建一个提交保存状态版本，然后记录下这个提交的哈希，
|
||
如果已经是干净的状态了则无需新建提交，直接记录下目前最新的提交的哈希，
|
||
如果当前是空状态还没有任何提交，则（如果不在仓库没有被git管理就git init初始化一个仓库）创建一个空的.gitkeep文件然后创建一个初始化提交，记录下这个提交的哈希
|
||
然后从当前记录的提交，创建一个新的分支，并将分支名和该起始提交哈希还有从哪个分支创建出来的都记录到文档，
|
||
后续所有的流程变动与集成的git操作都是在这个分支上进行的，
|
||
最后finish之后，把finish时的哈希记录到那个文档中，作为结束提交哈希，
|
||
然后此时因为要记录下最后的结束哈希，flow的状态数据和那个文档都会有更新，把这些都git add .然后创建一个提交，此时仓库状态是干净的了，
|
||
从这个提交合并到原本的分支去，回到原来的分支后，使用git reset --soft 软重置到起始提交，
|
||
然后再git add . ，再根据那个分支所执行的任务名生成提交信息，创建一个新提交，
|
||
这样在原本的分支可以只留下极少的提交，同时又能切换到任务分支查看变更的细节，（提交主要是便于回溯，实际上如果问题最终解决了，即使过程中出了点问题，最后解决了，任务完成后可能也不会回去看了，我希望我的git记录能干净些，而且就算有查看细节的需求，也可以通过查那份维护的文档切换到目标分支去看步骤细节）
|
||
|
||
我希望可以尽可能少的改动commands&skills，把这些全部封装到aide flow中，可能都不需要改commands，只要在skill中更新一部分信息让LLM简单了解到aide flow会发生这些副作用即可，
|
||
这样的封装能实现吗？
|
||
|
||
---
|
||
|
||
2.
|
||
|
||
我发现command/run中对细则信息的创建相关的规范比较简陋，只是简单提及了，
|
||
|
||
实际上我希望的是完成分析优化和待定项处理后是必须生成和保存结果的，也就是任务细则文档，
|
||
|
||
还有，待定项处理和产出结果保存细则文档这两步，都是必须用户确认后才能继续工作的，不论是否顺利，任务是否简单，都必须由用户确认才能继续 |