✨ feat: 准备处理解耦
This commit is contained in:
55
cache/p2/example-1.md
vendored
Normal file
55
cache/p2/example-1.md
vendored
Normal file
@@ -0,0 +1,55 @@
|
|||||||
|
proc environment manager
|
||||||
|
|
||||||
|
## 说明
|
||||||
|
|
||||||
|
`proc`是一个已经被用户正确安装的程序,可以像`ls`、`cd`、`cat`,`curl`等常用命令一样通过`proc`这个命令名直接随时调用而无需关心其安装路径和程序配置,
|
||||||
|
|
||||||
|
proc是一套针对性设计用于专业步骤流程的程序系统的访问入口,
|
||||||
|
|
||||||
|
可通过`proc`访问其一系列子程序,例如现在将要具体学习的`proc env`,`env`子项专用于处理项目开发时的开发环境情况问题,
|
||||||
|
|
||||||
|
## 行为与用例
|
||||||
|
|
||||||
|
> 下方代码片段是用空行分隔的多组命令调用示例,每一段注释后直到下一个空行前的一条或多条shell命令是一组,同一组的命令是等效的(通常较短的命令是其他长命令的参数缺省形式),
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 对于已启用的项目(python、jdk、gcc、cmake、cargo、rustc、uv、nodejs等)检测其环境的可用性及版本,由默认配置或工作目录下的默认环境配置文件决定启用哪些项目的检测
|
||||||
|
proc env
|
||||||
|
proc env check
|
||||||
|
proc env check --all
|
||||||
|
proc env check --all --env-config ./env-config.toml
|
||||||
|
# 这一组(也包括下一组`proc env show`)中的`--env-config`选项需要一个文件路径参数用于指定环境配置文件,其默认值是工作目录下的`./env-config.toml`
|
||||||
|
|
||||||
|
# 列出所有支持的环境模块并显示:
|
||||||
|
# 1.当前配置下该环境检测模块是否启用
|
||||||
|
# 2.该模块支持的操作(有些模块可能仅支持check而不支持ensure操作)
|
||||||
|
proc env show
|
||||||
|
proc env show --all
|
||||||
|
proc env show --all --env-config ./env-config.toml
|
||||||
|
|
||||||
|
# 支持的参数选项同上,运行所有已启用的环境模块检测其环境的可用性及版本,当目标环境不可用时尝试按既定程序修复环境,仅当所有修复都失败时输出失败消息
|
||||||
|
proc env ensure
|
||||||
|
|
||||||
|
# 运行指定的环境模块检测其环境的可用性及版本,且不论其是否已在环境配置中启用
|
||||||
|
proc env check --spec ['python']
|
||||||
|
proc env check --spec ['java','rust','uv']
|
||||||
|
# 这一组中的`--spec`选项需要一个字符串列表参数(即使只有一项),支持的选项可通过`proc env show`获取
|
||||||
|
|
||||||
|
# 运行指定的环境模块检测其环境的可用性及版本,且不论其是否已在环境配置中启用,当目标环境不可用时尝试按既定程序修复环境,仅当所有修复都失败时输出失败消息
|
||||||
|
proc env ensure --spec ['python']
|
||||||
|
proc env ensure --spec ['java','rust']
|
||||||
|
```
|
||||||
|
|
||||||
|
## IO约定与示例
|
||||||
|
|
||||||
|
- env子项仅支持[行为与用例](#行为与用例)中所示的参数选项,不支持动态输入其他参数值
|
||||||
|
- 输出前缀:
|
||||||
|
- 成功:✓
|
||||||
|
- 警告:⚠
|
||||||
|
- 失败:✗
|
||||||
|
|
||||||
|
### 输出示例
|
||||||
|
|
||||||
|
```
|
||||||
|
✓ 虚拟环境可用: /home/user/.local/pro-process-program/.venv/bin/python
|
||||||
|
```
|
||||||
@@ -16,12 +16,40 @@ claude code正在辅助我完成一项任务
|
|||||||
|
|
||||||
## 细节补充
|
## 细节补充
|
||||||
|
|
||||||
前面已经根据 @aide-requirements.md 产出了 discuss/ 目录下的信息,当前完成了01报告中的Phase 1和Phase 2,产出了 aide-marketplace/ 和02报告,然后我提出了 @reply/re-03.md 中所述的意见,现在re-03已经完成,
|
前面已经根据 @aide-requirements.md 产出了 discuss/ 目录下的信息,
|
||||||
|
|
||||||
|
当前完成了01报告中的Phase 1和Phase 2,产出了 aide-marketplace/ 和02报告,
|
||||||
|
|
||||||
|
然后我提出了 @reply/re-03.md 中所述的意见,现在re-03已经完成,
|
||||||
|
|
||||||
|
然后除了flow和decide之外的aide程序已实现在 aide-program/ 目录下,并产出了报告04,
|
||||||
|
|
||||||
# 要求
|
# 要求
|
||||||
|
|
||||||
|
## 首先必须
|
||||||
|
|
||||||
基于上述状态信息:
|
基于上述状态信息:
|
||||||
|
|
||||||
你必须亲自完整仔细的阅读所有提及的文件、目录及其子目录下所包含的所有文件内容(除了anthropic-agent-skills/仅要按需学习即可),必须一行不漏的完全审阅了所有文件,然后继续完成任务,
|
你必须亲自完整仔细的阅读所有提及的文件、目录及其子目录下所包含的所有文件内容(除了anthropic-agent-skills/仅要按需学习即可),必须一行不漏的完全审阅了所有文件,然后继续完成任务,
|
||||||
|
|
||||||
在aide-program/目录下,实现aide程序系统(入口脚本封装+python实现,但不要考虑、不要实现aide flow和aide decide,它们留到后面单独讨论细节),
|
## 然后现在的要求
|
||||||
|
|
||||||
|
遵循 @statements/optimize.md 对下述内容进行处理
|
||||||
|
|
||||||
|
## 想法口述
|
||||||
|
|
||||||
|
我想把一份完整的aide-requirements.md拆分为一份总导览和多个子区块部分,但必须在子区块局部文档信息完整详细的同时保证总的来说语义一致,他人能仅依赖于子区块的文档及子区块本身的目录文件信息完全了解这个区块,并接手其后续工作,比如需要进行一些调整、删除、添加,
|
||||||
|
|
||||||
|
比如我想达到的效果是,如果后续我想对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程序设计后才开始行动,
|
||||||
|
|
||||||
|
并且对功能的调整也可以仅涉及相关代码文件和子命令细节文档,涉及导览时更新导览信息即可,导览远比全部的完整信息要轻量得多,
|
||||||
|
|
||||||
|
对了:
|
||||||
|
1. 我希望跟aide program的文档不论是导览(感觉这个应该做成它的README就好了?)还是其他文档,都放在aide-program/docs目录下,
|
||||||
|
2. 我前面说的“子区块”可能并不准确或者并不适合,你可以不必完全遵循我的预想,若有更合适的解决方案就取更优解就好
|
||||||
17
statements/optimize.md
Normal file
17
statements/optimize.md
Normal file
@@ -0,0 +1,17 @@
|
|||||||
|
沟通准则(优化版)
|
||||||
|
|
||||||
|
1. 理解层面
|
||||||
|
- 语义解析:分析口语化表达,提取核心意图和真实需求
|
||||||
|
- 目标识别:明确你想要达成的最终目标,而非仅关注表面描述
|
||||||
|
2. 批判性分析
|
||||||
|
- 逻辑漏洞:指出推理链条中的致命错误或逻辑矛盾
|
||||||
|
- 盲点与不足:识别被忽略的重要因素或潜在风险
|
||||||
|
- 过度设计:标记不必要的复杂性或多余的考虑
|
||||||
|
3. 建设性建议
|
||||||
|
- 优化空间:提出可以改进的具体方向
|
||||||
|
- 替代方案:对于关键步骤,给出多种可行路径供选择
|
||||||
|
- 权衡分析:说明不同方案的利弊
|
||||||
|
4. 沟通方式
|
||||||
|
- 坦诚直接:发现问题直接指出,不回避冲突
|
||||||
|
- 优先级排序:按重要程度排列反馈,关键问题优先
|
||||||
|
- 追问确认:遇到歧义时主动澄清,而非猜测
|
||||||
Reference in New Issue
Block a user