oh-my-openagent 的 /refactor 命令怎么用 LSP 和 AST-grep 完成带 TDD 验证的重构【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagentoh-my-openagent 的/refactor是 Ultimate EditionOpenCode 插件版内置的斜杠命令用于做“全代码库感知”的重构先映射依赖和影响面、评估测试覆盖、生成分步计划执行时用 LSP 工具完成符号级重命名用 ast-grep 做结构性改写并在每一步改动后跑测试和诊断lsp_diagnostics、测试命令、类型检查验证零回归。适用前提是通过bunx oh-my-openagent install安装了 Ultimate Edition且你的项目有可运行的测试命令。1. 准备条件按 安装指南 安装 Ultimate Editionbunx oh-my-openagent install/refactor属于内置命令输入后由auto-slash-commandhook 展开成完整命令模板注入提示词。注意两点如果配置了disabled_commands并禁用了refactor该命令不可用。命令依赖两类工具面LSP 工具由内置lspMCP 提供lsp_diagnostics、lsp_rename等 8 个别名AST-grep 通过内置ast-grepskill 提供skill 自带sgCLI 和 Python 封装脚本scripts/ast_grep_helper.py。需要结构性匹配时先加载该 skill。命令会在第 3 阶段自动探测测试设施package.json的 scripts、pytest.ini/pyproject.toml、*_test.go等所以目标项目必须有一个可执行的测试入口否则覆盖率为 NONE 时命令会拒绝激进重构。2. 调用 /refactor/refactor refactoring-target [--scopefile|module|project] [--strategysafe|aggressive]参数含义来自命令模板 refactor.ts 的 Usage 段参数说明refactoring-target重构目标。可以是文件路径src/auth/handler.ts、符号名AuthService class、结构模式all functions using deprecated API或自然语言描述extract validation logic into separate module--scope重构范围默认module。file仅单文件module目录级project整个代码库--strategy风险偏好默认safe。safe保守、要求最大测试覆盖aggressive允许更大改动但同样要求覆盖充分3. 命令实际执行的流程命令模板把重构组织成 6 个阶段读者在会话中看到的待办todos就按这个顺序推进PHASE 0 Intent Gate强制第一步解析请求类型。目标是具体文件/符号时直接进入代码库分析目标模糊如只说 Improve、Clean up时命令会先反问具体改进点、模块范围或期望结果不会直接动手。PHASE 1 Codebase Analysis并行后台exploreagent 找目标定义、依赖方、相似模式、相关测试、架构上下文同时直接用工具做精确分析。PHASE 2 Build Codemap产出核心文件清单含行号、依赖图imports from / imported by / used by、影响区表格Zone / Risk Level / Files / Test Coverage。PHASE 3 Test Assessment探测测试命令、分析目标代码覆盖决定验证策略见下一节。PHASE 4 Plan Generation由 Plan agent 产出原子步骤——每步独立可验证、按依赖排序、指定到具体文件和行范围、含回滚策略和提交检查点。PHASE 5/6 执行 最终验证逐步执行并逐步验证最后跑全量测试和回归检查。4. TDD 验证策略是怎么定的PHASE 3 根据测出的测试覆盖水平决定验证策略这是整个“带 TDD 验证”的核心分叉覆盖水平策略HIGH80%每步之后运行现有测试MEDIUM50-80%运行测试 补充安全断言LOW50%PAUSE先提议补测试再重构NONEBLOCK拒绝激进重构覆盖率为 LOW 或 NONE 时命令会停下来给出三个选项先加测试再重构推荐、带额外小心地继续并需要手动验证、或中止。之后会产出一份 VERIFICATION PLAN列出测试命令unit/integration、类型检查命令如tsc --noEmit以及每个重构步骤后的三个检查点lsp_diagnostics无新增错误、测试命令全部通过、类型检查干净。5. 执行阶段如何选 LSP 与 AST-grep 工具PHASE 1 的分析阶段会用到// LSP精确定位与影响面 LspGotoDefinition(filePath, line, character) // 定义在哪 LspFindReferences(filePath, line, character, includeDeclarationtrue) // 所有使用点 LspDocumentSymbols(filePath) // 文件结构 LspWorkspaceSymbols(filePath, query[target_symbol]) // 按名搜索 lsp_diagnostics(filePath) // 记录改动前的错误基线执行阶段PHASE 5对每类改动有明确的工具选择符号重命名——先验证、后执行lsp_prepare_rename(filePath, line, character) // 确认符号可重命名 lsp_rename(filePath, line, character, newName) // 跨工作区执行重命名结构模式改写——用 ast-grep必须“先预览、后应用”。sg的关键坑是--json和--update-all互斥同时传时返回 JSON 但不会修改文件所以预览和应用要跑两遍详见 ast-grep SKILL.md# pass 1预览哪些内容会被改 sg run -p console.log($MSG) -r logger.info($MSG) --jsoncompact . # pass 2确认预览无误后实际应用 sg run -p console.log($MSG) -r logger.info($MSG) --update-all .或者用 skill 自带的 helper默认 dry-run加--apply才会真正改文件内部自动完成两遍流程# 预览默认不修改文件 python3 scripts/ast_grep_helper.py replace console.log($MSG) logger.info($MSG) --lang ts src/ # 实际应用 python3 scripts/ast_grep_helper.py replace console.log($MSG) logger.info($MSG) --lang ts src/ --apply模式写法注意ast-grep 的通配符是$VAR单个 AST 节点和$$$零个或多个节点正则语法\w、.*、|会静默匹配不到模式本身必须是可解析的代码例如写function $NAME($$$) { $$$ }而不是function $NAME。怀疑模式写错时可用python3 scripts/ast_grep_helper.py validate pattern --lang ts离线检查不依赖sg。精确小改动——用 Edit 工具做字符串级替换。每步后的强制验证MANDATORYlsp_diagnostics(filePath) // 必须与基线一致或更干净 bash(bun test) // 或项目对应的测试命令 bash(tsc --noEmit) // 或对应类型检查验证通过才标记该步骤完成任一项失败则进入恢复协议立即 STOP → REVERT 该步改动 → 诊断原因然后在“修复后重试 / 跳过仅可选步骤/ 咨询 oracle agent / 问用户”中选一个。模板明确写着 NEVER proceed to next step with broken tests——带失败的测试绝不进入下一步。每完成一个逻辑改动组后做提交检查点git add [changed-files] git commit -m refactor(scope): description [details of what was changed and why][changed-files]、scope和描述需要替换为你实际的改动文件与说明。6. 最终验证与结果判断PHASE 6 依次执行并作为“重构完成”的判定依据完整测试套件bun test或npm test、pytest、go test等项目对应命令全量类型检查tsc --noEmit或等价命令Lint如eslint .构建验证如适用bun run build或npm run build对所有改动文件跑lsp_diagnostics必须全部干净生成总结文档改动内容、修改的文件清单、验证结果Tests / Type Check / Lint / Build结论为“所有现有测试通过、未引入新错误”才算完成。7. 中止条件与硬性限制模板列出的中止条件触发即 STOP 并咨询用户目标代码测试覆盖为零改动会破坏公共 API重构范围不明确连续 3 次验证失败违反用户定义的约束同时是一组“绝不做”规则跳过改动后的lsp_diagnostics检查、带失败测试继续、不理解影响就改代码、用as any/ts-ignore/ts-expect-error、删测试让它通过、提交坏代码。两个适用边界/refactor属于 Ultimate Edition 的内置命令模板见 templates/refactor-sections/在 Codex Light Edition 中使用时模板内置了工具映射表call_omo_agent、task、team_*等 OpenCode 专用工具调用需改写为 Codex 原生multi_agent_v1.*等价形式不能照抄。遇到废弃 API 时命令会主动用librarianagent 查官方文档和替代方案但不会在你未明确要求时自动升级库版本。工具与流程细节的完整出处见 docs/reference/features.md 中的 Commands、LSP Tools 和 AST-Grep Skill 三节。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考