vinext 自动化修复合流全流程指南：基于 .opencode autopilot 命令的 Issue 到 Merge 实战手册

后端Web框架SSR【免费下载链接】vinextVite plugin that reimplements the Next.js API surface — deploy anywhere项目地址https://gitcode.com/gh_mirrors/vi/vinext点击查看免费下载本文围绕 vinext 仓库一个用 Vite 重实现 Next.js API 面、以 Cloudflare Workers 为首要部署目标的 Vite 插件项目内置的 .opencode/commands/autopilot.md 命令完整讲解从 GitHub Issue 到代码修复、独立评审、反馈处理、自动合流的四阶段自动化工作流。读完本文你将掌握如何用ghCLI 与 git worktree 安全地修复 Issue 并提交 PR、如何借助独立 reviewer 子代理完成交叉模型评审、如何分类处理评审意见修复 / 转 Issue / 解释分歧并最终以--auto --squash --delete-branch完成合并以及这条流水线背后与仓库开发规范AGENTS.md的对应关系。一、Autopilot 命令定位与整体架构.opencode/commands/autopilot.md是仓库中 opencode 的 Agent 命令定义同目录还有 fix-issue.md、review-pr.md、address-review.md 三个分步命令。它把一次完整的开源贡献拆成三个串行阶段Phase 1修复 Issue—— 建 worktree、修代码、跑全量检查、提交并创建 PRPhase 2独立评审—— 调用reviewer子代理不同模型做交叉审查Phase 3处理评审反馈—— 逐条分类意见、修复/转 Issue/回复分歧、开启自动合并。该命令的运行入口是Run the full issue-to-merge workflow for GitHub issue #$ARGUMENTS on cloudflare/vinext其中$ARGUMENTS是调用时传入的 Issue 编号。这与仓库的协作规范完全对齐AGENTS.md 明确要求“NEVER push directly to main”“Always create a feature branch and open a PR”“NEVER usegh pr merge --admin”autopilot 正是把这些纪律固化成可重复执行的流程。二、Phase 1从 Issue 到 PR 的修复闭环2.1 理解 Issue第一步是读取 Issue 的完整上下文gh issue view $ARGUMENTS按 fix-issue.md 的说明这一步要搞清楚三件事期望行为是什么、哪里坏了、是否有复现步骤。2.2 创建 worktree 与分支从 Issue 标题生成短 slug小写、连字符、最长 30 字符、无特殊字符然后基于最新的origin/main创建隔离的 worktree 和分支git fetch origin main git worktree add ../vinext-fix-$ARGUMENTS -b fix/$ARGUMENTS-slug origin/main关键约束后续所有命令都必须指向../vinext-fix-$ARGUMENTS/这个 worktree 目录绝不能改动主 worktree。这是 fix-issue.md 反复强调的纪律——“All subsequent commands must target the worktree directory”。随后在 worktree 内安装依赖pnpm install2.3 修复与开发规范在 worktree 中按 AGENTS.md 的指导修复问题。两条最重要的开发规范直接决定修复质量1先查 Next.js 行为再动手写代码。AGENTS.md 明确指出“Always verify Next.js behavior first”因为 vinext 的目标是“match Next.js behavior exactly”。仓库维护了一个被 gitignore 的本地 Next.js 克隆.nextjs-ref用于快速rg检索也允许用gh search code检索 Next.js 的测试用例。修复 Bug 的标准流程是先搜 Next.js 测试套件确认权威行为 → 再搜 Next.js Issues/PR 了解设计意图 → 再看其源码实现 → 最后在 PR 或 Issue 中链接佐证资料。2服务器代码必须做 dev/prod 对齐server parity。autopilot 命令特别强调“If touching server code, check dev/prod parity across all server files”。这四组文件是请求处理逻辑的多份实现必须保持同步packages/vinext/src/entries/app-rsc-entry.ts—— App Router RSC 入口生成器dev/prod 共用packages/vinext/src/server/dev-server.ts—— Pages Router 开发服务器packages/vinext/src/server/prod-server.ts—— Pages Router 生产服务器自带 middleware/routing/SSRcloudflare/worker-entry.ts—— Cloudflare Workers 入口当前仓库中对应实现位于 server/fetch-handler.ts其默认导出转引自virtual:vinext-worker-entry虚拟模块。AGENTS.md 的“Always check dev and prod server parity”小节解释了原因App Router 的生产服务器委托给构建后的 RSC entry因此会继承entries/app-rsc-entry.ts的修复但 Pages Router 的生产服务器有自己的 middleware/routing/SSR 逻辑必须单独同步更新。规则是在一个文件里修 Bug必须在其余文件里检查同样的 Bug 是否存在且应在同一个 PR 中修完不允许留作“follow-up”。2.4 全量检查修复完成后在 worktree 内跑完整检查套件pnpm run build pnpm test pnpm run typecheck pnpm run lint对照仓库根目录 package.jsonpnpm test对应vp test runVitest 全量套件pnpm run build会依次构建cloudflare/workers-response-store、vinext/cloudflare、vinext、create-vinext-app四个包。值得说明的是实际仓库的检查入口更细pnpm run checkformat/lint/type 检查、pnpm run linttype-aware oxlint、pnpm run fmtoxfmt 格式化开发期应优先跑针对性测试文件如pnpm test tests/routing.test.ts让 CI 承担全量验证。2.5 提交、推送、创建 PRgit push -u origin fix/$ARGUMENTS-slug提交信息采用 Conventional Commit 格式fix: description (#$ARGUMENTS)。AGENTS.md 说明仓库的 changeset 是由 CI 从 Conventional Commit 自动生成的scripts/create-changeset.mts因此不要手动运行pnpm changeset写好规范的提交信息即可。创建 PR 的模板如下必须包含对 Issue 的引用、变更摘要与测试计划gh pr create --title fix: description --body Fixes #$ARGUMENTS ## Summary what changed and why ## Test plan what tests were added/updated记住 PR 编号它是 Phase 2 和 Phase 3 的输入。三、Phase 2独立评审不同模型的交叉审查Phase 1 结束后调用 reviewer 子代理做独立评审reviewer Review pull request #PR_NUMBER on cloudflare/vinext. 1. Run gh pr view PR_NUMBER to understand the PR context. 2. Run gh pr diff PR_NUMBER to see all changes. 3. Read the full source files that were modified for surrounding context. 4. Check server parity if any server files were touched. 5. Post your review using gh pr review with inline comments.reviewer的定义在 .opencode/agents/reviewer.md其设计要点值得关注不同模型子代理固定使用openai/gpt-5.5temperature: 0.2与主 Agent 形成交叉验证权限收紧write: false、edit: falsebash 仅放行gh pr *、gh issue *、gh api *、git diff*、git log*、git show*、cat *—— 评审者只能读和评论不能改代码范围约束以$PR_NUMBER环境变量为唯一事实来源禁止评审其他 PR 或 Issue评审标准正确性优先、dev/prod parity、Next.js 行为兼容性、测试覆盖、安全尤其服务器端与 Workers 入口代码。评审流程要求“Read the full source files”——不仅看 diff还要读完整文件理解上下文。发表评审时使用gh pr review $PR阻塞性问题用--request-changes建议用--comment干净则--approve行内评论可用gh api repos/cloudflare/vinext/pulls/$ARGUMENTS/comments -f body... -f path... -F lineN -f sideRIGHT对应的独立命令版本见 review-pr.md。autopilot 规定必须等评审结束才能进入 Phase 3。四、Phase 3处理评审反馈并开启自动合并4.1 读取全部评审意见gh pr view PR_NUMBER --comments gh api repos/cloudflare/vinext/pulls/PR_NUMBER/reviews gh api repos/cloudflare/vinext/pulls/PR_NUMBER/comments4.2 逐条分类三选一对每条评论必须做出明确处置不允许含糊跳过分类处置动作要点Fix needed本 PR 引入的真实问题在 worktree 中修复修完跑全量检查再提交Out of scope / pre-existing真实问题但非本 PR 引入用gh issue create新建 Issue 跟踪严禁跳过且 Issue 中要附带评审上下文与 PR 链接Disagree评审有误或纯风格偏好在 PR 上回复解释理由用理由说服而不是沉默转 Issue 的标准模板见 address-review.mdgh issue create \ --title concise description \ --body Identified during review of #$ARGUMENTS. ## Context what was found and why it matters ## Suggested approach if you have one这一步的意义正如命令文件所写“Do NOT skip this. The whole point is to avoid losing track of work.”——让超出当前 PR 范围的问题有明确归属避免工作流失。4.3 修复、复检、回复修复后再次跑完整检查pnpm run build pnpm test pnpm run typecheck pnpm run lint提交并推送git commit -m fix: address review feedback git push然后对每条已处理的评论确认修复附上 commit 引用gh api repos/cloudflare/vinext/pulls/$ARGUMENTS/comments/{comment_id}/replies \ -f bodyFixed in commit sha对分歧意见同样用 replies 回复你的理由。4.4 开启自动合并gh pr merge PR_NUMBER --auto --squash --delete-branch--auto表示 CI 全部通过后自动合并--squash压缩为单条提交--delete-branch合并后删除分支。这与 AGENTS.md 的 PR 工作流一致必须等所有必需检查Check、Vitest、Playwright E2E变绿如果合并被阻塞要调查是哪个 status check 失败绝不使用--admin绕过分支保护。五、最终输出可追溯的工作总结autopilot 要求在收尾时打印一份总结包含PR URL修复内容已处理的评审意见数量转出的 follow-up Issue带链接自动合并状态worktree 位置及清理命令git worktree remove ../vinext-fix-$ARGUMENTS。这份总结让整个 Issue 到 Merge 的过程完全可审计——每个动作都有对应的 PR/Issue/commit 引用符合仓库以代码证据驱动协作的风格。六、与仓库配套命令的关系与适用前提autopilot.md并非孤立文件它与.opencode/commands/下另外三个命令构成阶梯fix-issue.md —— 只做 Phase 1Issue → PRreview-pr.md —— 只做 Phase 2PR 独立评审address-review.md —— 只做 Phase 3反馈处理 → 自动合并autopilot.md —— 三者的全自动串联。适用前提与限制说明本命令面向cloudflare/vinext仓库本仓库即其镜像$ARGUMENTS必须是仓库内真实存在的 Issue/PR 编号依赖ghCLI 已安装并完成认证且当前 git 仓库指向正确的 remoteworktree 路径../vinext-fix-$ARGUMENTS是相对主仓库的兄弟目录需确保磁盘路径可用命令中的服务器 parity 文件路径与仓库实际布局略有差异如 Workers 入口当前由 server/fetch-handler.ts 转引自virtual:vinext-worker-entry虚拟模块执行时应以仓库当前源码为准pnpm run typecheck等命令在根 package.json 中由vp命令族vp check、vp lint、vp fmt承担实际可运行脚本以仓库为准。这套工作流的核心价值在于把“修复—评审—反馈—合并”这一开源协作中最容易被跳过、被草率处理的部分固化为一个可复现、可审计、带独立模型把关的自动化闭环同时严格遵守仓库“禁止直推 main、禁止绕过分支保护、禁止丢失 out-of-scope 问题”的协作纪律。赞分享后端Web框架SSR【免费下载链接】vinextVite plugin that reimplements the Next.js API surface — deploy anywhere项目地址https://gitcode.com/gh_mirrors/vi/vinext点击查看免费下载相关推荐OpenChamber 功能开发工作流基于 OpenCode 命令从 accepted Issue 到合并闭环的实战指南OpenChamber 功能开发工作流基于 OpenCode 命令从 accepted Issue 到合并闭环的实战指南 本文以 OpenChamber 仓库AI Agent人工智能代码智能体交互助手PyPTO Code Merge Agent 实战指南从代码变更到 Issue/PR 的一键自动化合并流程PyPTO Code Merge Agent 实战指南从代码变更到 Issue/PR 的一键自动化合并流程 导读 本文以 CANN PyPTO 仓库中的 Ag人工智能编译器模型编译深度学习高性能计算CANNAscendCANN社区SiPBot交互命令全指南从PR提交流程到Issue协作的自动化操作手册CANN社区SiPBot交互命令全指南从PR提交流程到Issue协作的自动化操作手册 本文面向所有参与 CANN 社区含 SiP 信号处理算子加速库协算子库高性能计算CANNAscend上一篇ShareUtil 项目推荐下一篇如何用猫抓 3 分钟把网页视频存到本地创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考