提示词助手工作流个人总结

1.claude

【服务器信息】

主机：xxx

密码：xxx

工作路径：/home/swe/liuw/

【核心操作】

登录目标服务器，进入/home/swe/liuw/目录执行git clone ，进入克隆后的项目文件夹；
切换到指定版本：git checkout ；
全维度分析项目：①依赖完整性（版本兼容、包管理器适配）；②测试环境（框架配置、测试单元、外部依赖）；③服务依赖（中间件版本、启动配置）；④构建过程（标准化流程、monorepo适配）；⑤配置文件合规性（对齐CI环境）；
生成Devcontainer配置（仅调整容器配置，非交互模式）：
- 创建.devcontainer目录，包含Dockerfile（基于微软devcontainer镜像+保证能完成项目构建和运行test的必要插件）、devcontainer.json（执行依赖安装）、build_test_project.json；
- build_test_project.json文件内容格式：{
  "build_cmd": "build 命令；monorepo找最小模块最简构建",
  "test_cmd": "test 命令，至少1个成功；test成功后仅调用generate_test_results_xml函数生成test-results.xml",
  "repo_url": "<repo_url>",
  "base_commit": "<base_commit>",
  "group_info": "<group_info>"
  }
- 所有脚本逻辑仅封装在.devcontainer/manual_post_create_command.sh中，按以下规则定义函数：
  1. 函数名遵循「执行阶段+核心功能」规则（示例：modify_project_code、generate_test_results_xml、install_project_deps）；
  2. 每个函数仅实现单一功能，无交叉逻辑；
- 项目代码修改逻辑封装在modify_project_code函数（仅容器创建阶段执行）；
- test-results.xml生成逻辑封装在generate_test_results_xml函数（仅test_cmd执行成功后调用）；
验证流程（失败/超时则重建容器，反复验证直至成功）：
- 构建容器：devcontainer up --workspace-folder . --remove-existing-container --build-no-cache；
- 进入容器：devcontainer exec --workspace-folder . bash；
- 执行容器初始化：bash .devcontainer/manual_post_create_command.sh modify_project_code（仅执行改代码函数，绝对不调用生成XML函数）；
- 执行build_cmd（超时20分钟则缩小构建范围）；
- 执行test_cmd（至少1个成功）；
- test成功后执行：bash .devcontainer/manual_post_create_command.sh generate_test_results_xml（仅执行生成XML函数，绝对不调用改代码函数）；
- 总耗时超1小时则退出重建，直至验证成功。

【约束】

不修改宿主机配置；
所有文件无注释；
服务器权限要求调用脚本需使用bash 命令调用；
仅通过manual_post_create_command.sh封装脚本，不新增其他脚本文件；
依赖安装/构建均为非交互模式；
函数调用严格隔离：容器创建阶段仅调用改代码/装依赖类函数，test成功后仅调用生成XML函数，绝对不交叉执行。

【上方动态信息补充】

project-git-url：

commit-id：

repo_url:

base_commit：

group_info：

2.couser

目标生成一份可以通过Devcontainer CI 验证的Devcontainer配置文件，配置要完全符合 CI 自動化要求

一：项目信息：要自己读取

项目依赖完整性分析
扫描项目全目录下所有对应技术栈的依赖声明文件，完整识别项目所有主依赖、开发依赖、测试依赖；
深度校验所有依赖包的版本兼容性、版本冲突、版本缺失 / 弃用问题，校验运行环境版本与依赖包的匹配度；
校验包管理器兼容性，排查多包管理器共存冲突、包管理器版本与依赖的适配问题，保障依赖安装无报错。
项目测试环境全维度分析
扫描项目测试核心配置文件、测试框架专属配置，完整识别测试框架的初始化逻辑、全局配置、自定义插件 / 夹具规则；
识别测试用例的组织形式、最小可独立运行的测试单元、测试执行的前置条件；
识别测试运行所需的所有测试库、报告生成类依赖，以及测试执行是否依赖外部服务 / 中间件。
项目服务依赖分析
扫描项目内服务相关脚本与配置：scripts/ 目录下的服务启停 / 管理脚本、docker-compose*.yml 等 Docker 相关配置；
识别项目运行 / 测试所需的全部外部中间件服务（Redis、PostgreSQL、MySQL、MongoDB、Kafka、RabbitMQ、Elasticsearch 等）；
校验外部服务与当前项目的版本适配性，确认服务基础环境的配置方式与启动优先级。
项目构建过程标准化分析
扫描项目构建相关核心文件，梳理项目的标准构建流程、构建命令、构建前置条件、构建产物输出路径；
识别项目是否有特殊构建要求（如编译扩展、打包产物、静态资源编译、环境变量注入等），并在 Dockerfile 中完成对应配置；
判定项目为单模块 /monorepo 类型，确定最优构建范围与最简构建命令。
项目配置文件合规性分析
扫描项目内现有容器 / 编辑器配置文件，规避配置项冲突、端口占用、命令覆盖等问题；
扫描项目 CI/CD 配置文件，对齐 CI 环境的依赖版本、运行命令、环境变量、测试规则，保障 Devcontainer 配置与 CI 环境完全兼容；
参考项目开发文档，严格遵循官方指定的开发环境配置规范与命令执行规则。

二：文件生成：切记不要修改宿主机本身的配置，只能调整容器配置，

请按照以下要求生成配置，所产生的所有文件内容，都不要带注释：

一定要注意所有的依赖安装项目构建都采用非交互模式

创建 .devcontainer 目录和必要文件
.devcontainer目录内配置适合项目的 Dockerfile，要求最好使用微软提供的 devcontainer镜像,同时在安装一些运行项目的必要插件：
.devcontainer目录内设置适合项目的 devcontainer.json ，将项目的install依赖在该文件要执行安装步骤，如果后续有必要创建 .devcontainer/manual_post_create_command.sh脚本，bash执行命令要写在这个文件内。
.devcontainer目录内创建包含正确构建和测试命令的 build_test_project.json：build_cmd（build）和执行一test_cmd测试（test）任务。test_cmd全量测试（test）。build_test_project.json文件内容格式示例内容的执行命令根据项目调整：{
"build_cmd": "build 命令；注意：项目如果是属于monorepo仓库，找一个最小模块最简单的构建就行。",
"test_cmd": "test 命令执行一个最简单最小的test就行，test运行成功后，如果test生成xml文件就要把这个文件xml移动到项目根目录上改名test-results.xml文件，项目提供的test 无法生成test-results.xml文件，需要调整代码或者添加支持生成test-results.xml代码也使用.devcontainer/manual_post_create_command.sh 把生成Xml 内容写这个文件内，然后调用的时候使用bash，只调用生成xml部分脚本，类似一个调用一个函数",
"repo_url": "我自己补",
"base_commit": "我自己补",
"group_info": "我自己补"
}
始终要记住坚决不允许直接修改代码，如果需要改代码创建代码调整脚本 .devcontainer/manual_post_create_command.sh，封装方法创建容器时bash 命令调用，如果不需要调整代码就不需要创建了；
6.不要在生成其他文件，如果有必要先提出，谈论后在决定是否生成

三：完成配置文件直接开始验证流程，如果中途失败、从创建容器到最后执行test总时间超过1小时都退出容器，重新更新配置构建容器验证直至成功。切记不要修改宿主机本身的配置，只能调整容器配置

第一步：构建容器：devcontainer up --workspace-folder . --remove-existing-container --build-no-cache
容器成功后
第二步：进入容器：devcontainer exec --workspace-folder . bash
进入容器后
第三步：读取build_test_project.json文件的build_cmd 构建项目，如果构建时间超过20分钟，就立即停止，调整build_cmd命令缩小构建范围重新构建项目
构建项目成功后
第四步：读取build_test_project.json文件的"test_cmd"运行test，至少要有一个test能成功通过，不能全部失败了生成test-results.xml，

最后test_cmd的命令任务成功运行后，然后test命令追加一个任务：如果test生成运行也能生成xml文件就要把这个文件xml移动到项目根目录上改名test-results.xml文件，项目提供的test 无法生成test-results.xml文件，需要调整代码或者添加支持生成test-results.xml代码也使用.devcontainer/manual_post_create_command.sh 把生成Xml 内容写这个文件内，然后调用的时候使用bash，只调用生成xml部分脚本，类似一个调用一个函数。

千万不能影响已经验证完调整好的内容