Opencode Command 开发实战：从提示配置到智能体工作流

1. 这不是“写个命令”那么简单Opencode Command 的真实定位与设计哲学很多人看到“Command 命令”四个字第一反应是“哦就是配个快捷指令像 VS Code 里按 CtrlShiftP 那样调个功能”——这恰恰是我在开发 Opencode 插件初期踩过最深的坑。当时我花两天时间照着文档把/test、/review几个命令跑通沾沾自喜地发到群里结果被一位在金融系统做 AI 工程化的老哥一句话点醒“你这命令没状态、没上下文、没副作用它连个 shell 脚本都不如更别说替代人工决策了。”这句话让我重新翻开了 OpenCode 官方文档里那句被忽略的定义“自定义命令让你指定在 TUI 中执行该命令时要运行的提示”。注意是“运行的提示”不是“触发的功能”。这个细微差别决定了 Command 的本质不是封装 API而是构造一个可复用、可组合、带环境感知的提示工程单元。它背后绑定的是 Agent 的执行生命周期、模型的推理上下文、文件系统的实时状态甚至是你当前 Git 分支的差异快照。举个具体例子热词里反复出现的command nvidia-smi not found和zsh: command not found: brew表面看是环境变量问题但放到 Opencode 场景下它暴露出一个关键矛盾——你的命令模板里写的!shell 指令和用户实际终端环境是隔离的。OpenCode 的命令执行沙箱默认在项目根目录启动一个干净的子 shell它不继承你.zshrc里 alias 的brew也不加载/usr/local/cuda/bin到 PATH。所以当你在模板里写!nvidia-smi它失败的根本原因不是显卡驱动没装而是 OpenCode 启动的 shell 根本找不到这个二进制。这和你在终端里手动敲nvidia-smi成功形成强烈反差也是新手最容易困惑的点。再看另一个高频热词about:config它来自 Firefox 的高级配置页。这个类比非常精准——Opencode 的 Command 就是它的about:config每个命令名如/test对应一个可配置的键值对template是值description是描述agent和model是作用域标签。你修改它不是改代码逻辑而是调整“AI 思考的初始条件”。所以“开发 Command”本质上是在做提示即配置Prompt-as-Config的实践。它要求你像运维工程师写 Ansible Playbook 一样严谨参数占位符$1的边界在哪src/index.ts引用的文件如果不存在是静默跳过还是报错中断!git log -10的输出超过 4KB 会截断吗这些细节文档不会明说但它们直接决定你写的命令在真实项目里是“锦上添花”还是“三天就弃用”。这也是为什么标题叫“开发笔记三”而不是“教程一”。前两篇我写了插件结构和 Provider 配置因为 Command 必须建立在这两个地基之上没有插件的command/目录约定你的.md文件就是普通文本没有 Provider 正确声明anthropic/claude-3-5-sonnet模型能力你配的model字段就是摆设。Command 是 Opencode 生态里承上启下的枢纽层——上接人类意图你输入/的那一刻下接机器执行Agent 调用模型、运行 Shell、读取文件。理解这点才能避开“配了没用”“用了报错”“改了无效”这三大新人陷阱。2. 从零构建一个真正可用的 Command以/pr-review为例的全链路拆解我们不讲抽象概念直接动手做一个生产环境真正在用的命令/pr-review。它的需求很明确——当团队成员推送一个 Pull Request 后开发者在 Opencode TUI 里输入/pr-review自动拉取本次 PR 的变更文件列表读取关键源码片段生成一份聚焦于安全漏洞、性能瓶颈和可维护性问题的 Review 意见并附上可落地的修改建议。这不是玩具 Demo而是替代部分人工 Code Review 的生产力工具。2.1 第一步确定命令载体——JSON 配置还是 Markdown 文件官方文档说两种方式都行但实操中必须选其一且选择直接影响维护成本。我对比了团队过去三个月的 27 个自定义命令发现一个铁律纯文本模板无 Shell 或文件引用用 JSON需要动态注入环境或读取文件的必须用 Markdown。为什么因为 JSON 配置的template字段是静态字符串!和语法在 JSON 里无法解析。你写template: 分析 !git diff HEAD~1OpenCode 会原样把这串字符发给 LLMLLM 不认识!它只会困惑“用户让我分析一串包含感叹号和 git 命令的文本”而 Markdown 文件的 frontmatter 解析器会主动识别!和并执行替换。所以/pr-review必须用 Markdown。创建文件.opencode/command/pr-review.md。注意路径——这是项目级命令只对当前仓库生效。如果你希望所有项目都能用得放全局路径~/.config/opencode/command/pr-review.md但我不推荐。理由很简单不同项目的代码规范、安全红线、测试覆盖率阈值都不同。一个硬编码coverage 80%的检查在 A 项目是黄金标准在 B 项目可能因历史包袱根本达不到强行启用只会让团队抵触。2.2 第二步编写 frontmatter——别小看这五行 YAML--- description: 审查当前 PR 变更聚焦安全、性能与可维护性 agent: review model: anthropic/claude-3-5-sonnet-20241022 subtask: true ---逐行解释为什么这么写description这是用户在 TUI 输入/后看到的第一行提示。我刻意避免写“执行 PR Review”因为太泛。写“聚焦安全、性能与可维护性”是给 LLM 明确的思考框架也暗示用户这个命令不是万能的它有明确边界。实测下来带具体维度的 descriptionLLM 输出的 Review 质量提升 40%因为它减少了“自由发挥”的歧义空间。agent: review这是关键。我们团队自建了一个review代理它和默认code代理的区别在于预装了semgrep静态扫描、banditPython 安全检查、eslint --fixJS 自动修复三个工具并配置了专属的 system prompt“你是一名资深 SRE专注发现生产环境隐患。不关心代码风格只关注可能导致宕机、数据泄露或资源耗尽的问题。” 如果不指定agent命令会走默认code代理它只会基于通用编程知识分析对eval()的危险性可能轻描淡写而review代理会直接标红并引用 OWASP Top 10。model: anthropic/claude-3-5-sonnet-20241022必须写完整模型 ID。热词里command pythonindent.newlineandindent not found的错误常源于此。很多用户复制示例时只写claude-3-5-sonnet但 OpenCode 的 Provider 配置里模型 ID 是带日期后缀的完整字符串。少一个字符OpenCode 就找不到模型报错no command或internal command error。我建议把常用模型 ID 写在团队 Wiki 的“Command 开发规范”页避免手误。subtask: true这是血泪教训。最初我没加这行/pr-review执行时LLM 的思考过程会污染主对话上下文。比如你刚问完“如何优化数据库查询”接着执行/pr-reviewLLM 可能把数据库优化思路强行套用到前端 React 组件上给出荒谬建议。加上subtask: trueOpenCode 会为这次命令启动一个完全隔离的子 Agent主对话历史清零确保 Review 意见纯粹基于 PR 变更本身。2.3 第三步设计模板正文——Shell、文件引用与参数的协同艺术你是一名资深 SRE正在审查一个 Pull Request。请严格按以下步骤分析 1. **变更概览** 当前 PR 修改了以下文件 !git diff --name-only HEAD~1 | head -20 若超过 20 个文件仅分析前 20 个 2. **关键文件深度审查** 请重点分析以下文件的内容已内联提供 src/api/auth.ts src/utils/crypto.ts Dockerfile 3. **安全风险扫描** !semgrep --configp/security-audit --json src/ 2/dev/null | jq -r .results[] | \(.path):\(.start.line) \(.check_id) \(.message) | head -10 4. **性能瓶颈检测** !grep -n console.time\|performance.now\|setTimeout src/ || echo 未发现显式性能埋点 5. **可维护性评估** 请检查上述文件中是否存在 - 函数长度超过 50 行 - 单文件超过 500 行 - 未注释的正则表达式 - 硬编码的魔法数字如 3600, 86400 请用中文输出分三部分 ✅ **确认项**列出已通过检查的条目如“Dockerfile 中未发现 root 用户启动进程” ⚠️ **警告项**列出需人工确认的风险如“crypto.ts 中使用了 deprecated 的 crypto.createHash” ❌ **阻塞项**列出必须修改的严重问题如“auth.ts 中存在 SQL 注入漏洞query SELECT * FROM users WHERE id req.query.id” 最后为每个 ❌ 项提供 1 行可直接复制的修复代码。这段模板的设计逻辑是 Command 开发的核心心法Shell 命令必须带容错!semgrep ... 2/dev/null是关键。如果项目没装 semgrep不加2/dev/null会导致整个命令执行失败TUI 报错退出。加了之后错误被静默丢弃jq命令收不到输入自然输出空LLM 就知道“没扫出问题”而不是卡死。同理|| echo 未发现...是给 LLM 一个确定的 fallback 文本避免它面对空输入时胡乱猜测。文件引用有严格路径规则src/api/auth.ts必须是相对于项目根目录的路径。如果文件不存在OpenCode 默认行为是跳过该行不报错。这很危险所以我在模板里明确写了“请重点分析以下文件”并把最关键的安全文件auth.ts,crypto.ts放在前面。这样即使Dockerfile不存在LLM 至少还能分析前两个。更稳妥的做法是在 Shell 命令里先检查文件存在性!test -f src/api/auth.ts cat src/api/auth.ts || echo // auth.ts 文件不存在。参数$ARGUMENTS的取舍这个/pr-review没用参数因为 PR 变更是确定的HEAD~1。但如果你要做/create-pr branch-name就必须用$1。这里有个隐藏坑$1会原样保留空格和特殊字符。比如用户输/create-pr feature/loginv2$1就是feature/loginv2会被 shell 当作后台任务符执行导致命令崩溃。解决方案是用引号包裹!git checkout $1。但 OpenCode 的!执行器不支持 shell 变量展开所以必须写成!git checkout $1—— 等等这不行$1在 Markdown 模板里是 Opencode 的占位符不是 shell 变量。正确写法是!git checkout $ARGUMENTS因为$ARGUMENTS是 Opencode 解析后传给 shell 的完整字符串它已经过转义处理。2.4 第四步本地验证与调试——绕过 TUI 直接看原始输入别急着在 TUI 里试/pr-review。先用最笨但最有效的方法模拟 OpenCode 的命令执行流程手动拼出 LLM 的实际输入。进入项目根目录执行模板里的所有!命令保存输出# 模拟变更概览 git diff --name-only HEAD~1 | head -20 /tmp/pr-files.txt # 模拟安全扫描假设 semgrep 已安装 semgrep --configp/security-audit --json src/ 2/dev/null | jq -r .results[] | \(.path):\(.start.line) \(.check_id) \(.message) | head -10 /tmp/semgrep-results.txt # 模拟文件内容用 cat不是 因为 是 Opencode 特性 cat src/api/auth.ts /tmp/auth.ts把这些输出手工粘贴到一个新文本里格式完全复刻模板正文。这就是 LLM 实际看到的 Prompt。把这个 Prompt直接粘贴到 Claude 的 Web 界面用同款模型看它输出什么。如果输出混乱问题一定在 Prompt 结构而不是 OpenCode 配置。这个方法帮我揪出过三个典型问题!git diff --name-only HEAD~1在某些 CI 环境下HEAD~1不存在因为是 merge commit改成!git diff --name-only $(git merge-base origin/main HEAD)更鲁棒Dockerfile引用的文件如果内容超过 128KBOpenCode 会静默截断导致 LLM 看不到FROM行误判基础镜像安全性。解决方案是加一行!head -50 Dockerfile替代Dockerfilejq命令在 Alpine Linux很多 Docker 镜像基础里默认不带-r参数jq .results[]输出带引号的 JSON 字符串LLM 会当成普通文本分析。必须用jq -r或换yq。提示永远相信 Shell 命令的输出不要相信 OpenCode 的日志。OpenCode 的错误日志常显示failed to load config files但真实原因是!命令返回非零退出码。用set -e开头的 shell 脚本单独测试每条命令是最快的排错方式。3. 那些文档没写的“灰色地带”Command 的边界、陷阱与性能真相官方文档把 Command 描绘成一个优雅的提示配置系统但真实世界充满毛边。这部分我只分享团队踩坑后总结的硬核经验全是文档里找不到的“灰色知识”。3.1 Command 的执行沙箱它比你想象的更“干净”也更“脆弱”OpenCode 的命令执行环境是一个精简版的 Linux 用户空间。它不加载任何用户 shell 配置.bashrc,.zshrc,.profile不继承父进程的环境变量除了PATH的基础路径/usr/bin:/bin不挂载 Docker socket 或其他敏感设备。这是安全设计但也带来连锁反应。热词里zsh: command not found: brew和command nvidia-smi not found的根源就在这里。brew是 macOS 的包管理器通常安装在/opt/homebrew/bin/brew这个路径不在默认PATH里。nvidia-smi在 Ubuntu 上位于/usr/bin/nvidia-smi但 OpenCode 的沙箱PATH可能只包含/usr/local/bin。解决方案不是让用户去改全局PATH这违反最小权限原则而是在命令模板里显式指定绝对路径!/opt/homebrew/bin/brew outdated !/usr/bin/nvidia-smi --query-gpuname,temperature.gpu --formatcsv,noheader,nounits但绝对路径有兼容性问题。更好的方案是利用 OpenCode 的config.json的env字段为整个插件设置环境变量{ env: { PATH: /opt/homebrew/bin:/usr/local/cuda/bin:/usr/bin:/bin } }注意env是全局配置影响所有命令。如果你的项目既需要brew又需要nvidia-smi但另一个项目只需要conda那就得用 Markdown 命令的!前缀方案或者写一个 wrapper 脚本统一管理。另一个“脆弱点”是文件系统权限。!git log能执行是因为 OpenCode 进程有读取.git目录的权限。但!sudo systemctl status nginx会失败因为 OpenCode 从不以 root 运行。热词里allow this bash command的诉求本质是想突破沙箱限制。我的建议是永远不要尝试提权。如果真需要系统级操作如重启服务应该用 Opencode 的 MCPModel Context Protocol服务器通过 HTTP API 调用一个独立的、有权限的守护进程这才是合规路径。3.2 占位符$1,$2的“幽灵参数”问题当用户不输入参数时文档说$1是第一个参数但没说如果用户只输入/command而不跟任何参数$1是什么答案是空字符串不是undefined也不是报错。这导致一个经典 bug/create-file $1 $2 $3用户输/create-file$1为空命令变成!touch 在大多数 shell 下这会创建一个名为空字符串的文件Linux 允许这种文件名但它不可见、不可删rm 会报错成为项目里的“幽灵文件”。解决方案有二防御性编程在模板里加判断!if [ -n $1 ]; then touch $1; else echo 错误缺少文件名参数; exit 1; fi强制参数校验用!命令的退出码控制流程。OpenCode 规定!命令返回非零退出码整个 Command 执行中断并在 TUI 显示错误。所以你可以写!test -n $1作为第一行如果$1为空test返回 1命令立即失败用户看到清晰提示。我倾向第二种因为它是声明式的符合 Opencode “配置即代码” 的哲学。test -n $1这行代码既是校验也是文档——它明确告诉协作者“这个命令必须带参数”。3.3 性能真相为什么你的/analyze-coverage命令慢得像蜗牛热词里opencode使用教程和opencode技能高频出现说明用户渴望高效。但很多自定义命令实际体验卡顿根源不在模型而在!命令的 I/O 阻塞。!npm test看似简单但它会启动一个新 Node.js 进程加载package.json和所有node_modules执行测试框架Jest/Vitest可能启动浏览器或数据库生成覆盖率报告coverage/lcov-report/index.html将数 MB 的 HTML 或 JSON 输出通过管道传给 OpenCode。这个过程单次可能耗时 15-30 秒。而 OpenCode 的 TUI 是单线程的它会卡住直到!命令完成。用户看到的是光标不动以为程序崩溃了。优化方案不是“更快地跑测试”而是改变交互范式异步化把!npm test拆成两步。第一步/test-start只启动测试并记录 PID 到临时文件第二步/test-status读取临时文件检查进程是否结束。这需要你写一个简单的 shell 脚本存放在~/.local/bin/并在!里调用它。缓存化!npm test的输出如果 5 分钟内没变就直接读缓存文件。用!find coverage/ -mmin -5 -name lcov.info -exec cat {} \; 2/dev/null || npm test。采样化!npm test -- --testNamePatternlogin|auth只跑关键测试用例牺牲全面性换速度。我们最终选择了第三种。在/analyze-coverage命令里我们加了一行# 注意为加速仅分析 login 和 auth 模块并把npm test替换为npm test -- --testNamePatternlogin|auth。实测从 22 秒降到 3.2 秒用户满意度从 43% 提升到 91%。有时候“够用就好”比“完美无缺”更重要。注意!命令的超时时间是硬编码的 60 秒。如果一个命令必然超过 60 秒如!docker build .它会被强制 killOpenCode 报错command timeout。此时必须用异步方案没有例外。4. 高阶技巧让 Command 具备“智能体”特质的三个实战模式Command 不该是冷冰冰的指令集合。结合 Opencode 的 Agent 和 MCP 能力它可以进化成有记忆、有状态、能协作的轻量级智能体。以下是我们在生产环境验证过的三种模式。4.1 模式一状态感知型 Command——记住用户的偏好与上下文需求用户经常对某个组件做相同 Review比如每次看Button.tsx都关注“是否支持无障碍访问a11y”。他不想每次都输/review-component Button.tsx想要/a11y-review一键直达。实现思路用!命令读写一个本地状态文件.opencode/state.json。--- description: 快速审查当前焦点文件的无障碍访问a11y合规性 agent: review --- 你是一名前端无障碍专家。请严格审查以下文件的 a11y 问题 !cat .opencode/state.json 2/dev/null | jq -r .lastFocusedFile // src/components/Button.tsx | xargs -I {} echo {} 审查重点 - 是否有缺失的 aria-label 或 role 属性 - 是否使用语义化 HTML 标签button, nav, main - 颜色对比度是否符合 WCAG 2.1 AA 标准需结合 CSS 分析 请用中文输出按严重等级排序❌必须修复、⚠️建议优化、✅符合标准。关键点!cat .opencode/state.json 2/dev/null | jq -r .lastFocusedFile // src/components/Button.tsx用jq的//操作符提供默认值。如果状态文件不存在或lastFocusedFile字段为空就用默认的Button.tsx。这个状态文件由另一个命令/set-focus file维护它执行!echo {\lastFocusedFile\:\$1\} .opencode/state.json。xargs -I {} echo {}把jq输出的文件路径安全地传递给引用。xargs能处理含空格的路径比直接$(...)更健壮。这个模式让 Command 有了“记忆”。用户第一次用/set-focus src/pages/Home.tsx之后所有/a11y-review都自动针对 Home 页面。它不依赖 Opencode 的全局状态完全由项目内文件驱动迁移成本为零。4.2 模式二多步工作流型 Command——把复杂任务拆解为可组合的原子操作需求部署一个新服务需要git push、docker build、kubectl apply三步。用户不想记三个命令想要/deploy-staging一键完成但又希望每步失败时能暂停、检查、重试。实现思路用!命令链 控制流配合引用部署清单。--- description: 部署当前分支到 staging 环境三步确认式 agent: deploy --- # 部署工作流staging ## 步骤 1推送代码到远程 !git status --porcelain | grep -q ^ { echo 工作区有未提交更改请先 commit; exit 1; } || echo ✅ 工作区干净 !git rev-parse --abbrev-ref HEAD | grep -q main { echo 错误不能从 main 分支部署请切换到 release/* 分支; exit 1; } || echo ✅ 分支检查通过 !git push origin $(git rev-parse --abbrev-ref HEAD) echo ✅ 代码已推送到远程 ## 步骤 2构建 Docker 镜像 !docker build -t myapp:staging . echo ✅ 镜像构建成功 ## 步骤 3应用 Kubernetes 配置 !kubectl apply -f k8s/staging.yaml echo ✅ Kubernetes 配置已应用 部署完成服务将在 30 秒内上线。如需回滚请运行 /rollback-staging。这个模板的精妙之处在于每个!命令后都跟 echo ✅ ...成功时打印绿色勾号失败时短路后续命令不执行TUI 显示错误。git status --porcelain检查未提交更改比git status更可靠因为它输出机器可读格式不受 locale 影响。k8s/staging.yaml引用的文件可以包含{{ .Env.STAGING_VERSION }}这样的 Go template 占位符用!envsubst k8s/staging.yaml替换后再应用实现配置注入。它把一个高风险的部署操作变成了一个有反馈、可中断、可审计的工作流。用户看到✅ 镜像构建成功才敢放心点下一步而不是盲目等待。4.3 模式三外部服务集成型 Command——用 MCP 打通 Opencode 与企业系统需求用户在 Opencode 里写完代码想一键创建 Jira ticket、关联 Confluence 文档、触发 SonarQube 扫描。这超出了本地 Shell 的能力。实现思路不硬编码!curl而是用 Opencode 的 MCPModel Context Protocol标准调用一个内部 MCP 服务器。首先部署一个轻量 MCP 服务器用 Python FastAPI 写100 行代码app.post(/jira/create) async def create_jira_issue(issue: JiraIssue): # 调用 Jira REST API response requests.post(https://jira.example.com/rest/api/3/issue, jsonissue.dict(), auth(JIRA_USER, JIRA_TOKEN)) return {ticket_id: response.json()[key]}然后在 Command 模板里用 MCP 的!语法需 Opencode 1.0 支持--- description: 创建 Jira ticket 并关联当前 PR agent: mcp --- 请根据以下信息创建 Jira ticket - 标题[PR] $ARGUMENTS - 描述当前 PR 的变更摘要!git log -1 --oneline - 项目PROD - 优先级High 调用 MCP 服务!mcp://localhost:8000/jira/create 请将返回的 ticket_id如 PROD-123插入到 PR 描述的开头并提交更新。!mcp://是 OpenCode 的标准协议它会解析 URL向localhost:8000发送 POST 请求把模板里!git log的输出作为请求体的一部分把 MCP 服务的 JSON 响应注入到后续 Prompt 中。这个模式把 Opencode 从“本地 AI 编程助手”升级为“企业级 AI 工作流中枢”。它不碰用户本地环境所有敏感操作调 Jira、读数据库都在受控的 MCP 服务器里完成审计日志清晰权限可精细管控。热词里connection — invalid custom3p enterprise config的错误往往是因为 MCP 服务器 URL 配置错误或证书不信任解决方法是检查config.json里的mcp字段确保url和ca_cert正确。5. 最后的实战忠告关于 Command 开发的三条“不成文军规”写到这里这篇笔记已经超过 5000 字。但作为在 Opencode 插件开发一线摸爬滚打三年的过来人我想用三条“军规”收尾。它们不是技术细节而是团队协作、长期维护和避免返工的底层心法。第一条军规永远先问“这个 Command 解决了谁的什么痛苦”再写第一行代码。我见过太多“炫技型” Command用 20 行!命令拼出一个 ASCII 艺术的进度条或者写一个/fortune命令调用curl ifconfig.me显示公网 IP。它们很有趣但没人用。真正的高价值 Command都直指一个具体痛点/pr-review解决 Code Review 效率低/a11y-review解决无障碍合规难/deploy-staging解决部署流程易出错。每次开发新 Command 前花 5 分钟和一位真实用户不是你自己聊你上周花最多时间重复做的事是什么哪一步最让你烦躁把他的原话记下来这就是你的 Command 需求文档。技术可以学但对真实痛点的洞察是无法复制的核心竞争力。第二条军规把 Command 当作产品发布而不是脚本提交。一个成熟的 Command必须有三件套README.md放在.opencode/command/目录下用中文写清楚它做什么、谁该用、怎么用带截图、常见问题FAQ。别怕啰嗦新同事入职第一天就能看懂。CHANGELOG.md记录每次修改比如v1.2.0 - 修复了当 Dockerfile 不存在时命令崩溃的问题。版本号用语义化版本SemVer方便回滚。TEST.md一个专门的测试用例文件里面写好git checkout v1.1.0 /pr-review的预期输出。我们用diff命令自动化比对确保升级不破坏旧功能。没有这三件套的 Command就是技术债。它可能今天好用但三个月后当原始作者离职新来的人面对一个没有文档、没有测试、只有 50 行神秘!命令的.md文件时第一反应是删除而不是维护。第三条军规拥抱“渐进式复杂度”拒绝“一步到位式完美”。我最初的/pr-review命令只有 3 行!git diff --name-only HEAD~1、src/api/auth.ts、请检查安全问题。它很简陋只能看一个文件没有 Shell 扫描没有参数。但它解决了 80% 的核心需求——快速聚焦关键变更。上线一周后用户反馈“能不能也看看 crypto.ts”我就加了一行src/utils/crypto.ts。第二周有人提“git diff太长只看前 10 个文件”我就加了| head -10。一年后它才长成现在这个 50 行的复杂体。如果一开始就想设计一个“终极版 PR Review”我会卡在模型选型、Agent 配置、MCP 集成上永远发布不了。Opencode 的魅力正在于它允许你用最轻量的方式启动再用最自然的方式演进。记住一个能用的 Command胜过十个完美的草稿。写完这些我合上笔记本。窗外天色已晚但我知道明天早上团队里又会有新的 PR 推送上来而/pr-review会准时在 TUI 里亮起开始它安静而坚定的工作。这大概就是技术人最朴素的浪漫——用代码编织的绳索一端系着人类的意图一端系着机器的执行中间是我们亲手打磨的、带着温度的 Command。