24 lines
2.9 KiB
Markdown
24 lines
2.9 KiB
Markdown
# 补充的部分
|
||
|
||
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
|
||
|
||
# 需要我确认的问题
|
||
|
||
1. Q1在上面的第3点已经答复了
|
||
2. 我希望最外层的aide入口封装使用平台的shell脚本，但仅仅只是封装部分，这个封装的任务是检查python虚拟环境或系统环境的python，然后通过检测到的python执行真正的python入口程序，
|
||
- 封装部分仅负责检测python并执行真正的入口，在检测到不存在时抛出致命错误，需要用户处理好至少先提供一个可用的基本的python3才能继续
|
||
- 封装部分教轻量，可以为win、linux/mac单独编写也不会太麻烦
|
||
- 由封装调用真正的python入口程序后，处理更核心的逻辑，
|
||
- 使用python是为了减少统一跨平台、开发、调试与测试运行的成本，同时还可以作为胶水语言在适当的时候引入其他语言更好的完成部分任务，比如前面说的处理待定项交互的程序，就很适合用ts+react+nextjs这样的全栈技术栈来实现，同时兼顾界面和后端，还能快速落地，前端比flutter轻量，后端比rust轻量，且性能完全满足需求，
|
||
|
||
# 我的想法
|
||
|
||
上述回答是否足够？
|
||
若已经足够我希望能先对原有的aide-requirements.md进行更新，补充完善不足之处，删去即将讨论和重新定义的部分，
|
||
接下来开始引导我对aide整个系统进行重新设计，
|
||
这个过程中我希望你的所有想法、建议、报告等等信息全部以.md文档报告的形式保存到 discuss/ 目录下，这便于我仔细查阅和思考，
|
||
而我也会把我的回复创建.md文档报告保存到 reply/ 目录下并告诉你文件名， |