从终端到全流程接管opencode这款开源AI编码代理我用了两个月后的真实体验如果你最近刷技术社区大概率会看到opencode这个词。简单说它是一款跑在终端里的开源AI编码代理AI Coding Agent定位和Claude Code、Codex CLI、Google的 Jules 类似但走的是“本地优先、厂商中立”的路线。你给它一个任务它会自己读代码、改文件、跑命令、看报错再决定下一步干什么几乎不需要你手动复制粘贴报错日志。我上手opencode两个月从最初的“玩具心态”试水到后来真的拿它接了一个中型重构任务中间踩了不少坑。这篇东西不打算写成工具文档而是想从一个实际使用者的角度聊聊opencode到底能干什么、怎么装、怎么配模型、怎么和编辑器配合以及那些文档里不会写清楚的坑。如果你正在几个终端AI工具之间犹豫或者刚装上opencode不知道怎么开始这篇应该能帮你省下不少试错时间。1. 先搞清楚opencode是什么以及它和Claude Code、Codex CLI的差别1.1 opencode的定位一个开源的、模型无关的终端Agent很多人第一次听说opencode是因为它在GitHub上星标涨得很快。但星标多不代表好用真正让我决定深入试它的是它的架构思路。opencode的核心是一个“Agent循环”agentic loop它把“读懂需求 → 规划步骤 → 调用工具 → 观察结果 → 修正计划”这个循环做成了产品内核。你在对话里给它一个高层次的指令比如“看看这个仓库里登录流程的Bug”它会自己去搜索代码、定位敏感词、修改文件、跑测试然后告诉你它改了什么、为什么这样改。这一点和Cline、Continue这类“辅助补全型”工具完全不同。那些工具更像“高级版的自动补全”你告诉它改哪里它帮你写代码。而opencode是“代理型”的你告诉它要什么结果它自己想办法。这个区别决定了它的使用方式你得学会“放权”学会把任务描述清楚而不是逐行指挥。1.2 横向对比opencode vs Claude Code vs Codex CLI vs Cline我三款都重度用过简单说下我的感受方便你判断自己适合哪家。维度opencodeClaude CodeCodex CLICline开源性质完全开源MIT闭源免费额度有限开源但绑OpenAI账号开源VS Code插件模型支持任意模型OpenAI/Anthropic/本地仅Claude仅OpenAI系任意但需配置运行环境终端TUI终端TUI终端TUIVS Code插件挂载第三方Skills支持机制灵活官方支持有限不支持免费可用性接免费模型即可有免费次数有限接免费API可用从纯技术角度说opencode最打动我的是“模型无关”这四个字。Claude Code绑死AnthropicCodex绑死OpenAI而opencode通过一个Provider接口可以接任何兼容OpenAI格式的商业API也可以接本地跑的Ollama、vLLM。这意味着你不需要因为换模型就换工具也不担心某天某家API涨价导致工作流瘫痪。而且因为它是完全开源的整个Agent循环、工具调用框架你都可以审阅和改。对于有安全洁癖的团队这点很重要——你知道这个Agent到底在你的机器上执行了什么而不是把终端权限交给一个黑盒。1.3 opencode适合谁来用我觉得有三类人会特别受益第一类是“多模型流”用户。你既想用Claude写复杂重构又想让GPT-4o跑一些琐碎的脚本任务还偶尔想本地跑个小模型验证隐私数据。opencode能让你在同一个界面里切换模型不用来回换终端工具。第二类是“插件控”和“工作流党”。opencode对Skills和MCPModel Context Protocol的支持很完整你可以把团队的工具链、代码规范、测试流程都挂进去让Agent遵循你的团队标准干活。第三类是“隐私敏感”的开发者。因为可以接本地模型你完全可以把代码库留在本地让Agent通过Ollama处理敏感数据不出机器。如果只是想在IDE里有个能聊天的补全工具opencode现阶段不是最优解。它更擅长的是“独立执行任务”而不是“陪着你写每一行代码”。2. 安装与初始化多平台避坑指南以及那个最容易卡住的“cmdlet报错”2.1 一键脚本、Homebrew、Go install到底该用哪个opencode的安装方式不少官方推荐的是脚本安装。但经过我的折腾不同场景下最优选择不一样。方式一官方一键脚本推荐给Linux/macOS用户curl -fsSL https://opencode.ai/install | bash这个脚本会把二进制装到系统PATH里然后你直接敲opencode就能进终端界面。我实测在macOS和Ubuntu上都顺利脚本本身还会检测系统架构不会有装错版本的问题。方式二HomebrewmacOS用户最顺手brew install opencode-ai如果你已经习惯用Homebrew管理开发工具这个方式最省心。升级也方便一条brew upgrade opencode-ai就完事。注意官方仓库名是opencode-ai不是opencode我第一次搜Homebrew搜错包装了个无关的东西。方式三Go install有Go环境的朋友go install github.com/sst/opencodelatest说实话这种安装方式适合熟悉Go工具链的人装完记得确认go/bin在PATH里。不过不推荐作为首选因为Go install默认装的是“当前GitHub主分支版本”可能是开发版稳定性不如发布版。方式四二进制手动安装Windows用户最稳的路径从GitHub Releases页面下载对应系统的压缩包解压后把opencode.exe的路径加进系统PATH。2.2 我的主力Windows机器踩坑实录“无法将opencode识别为cmdlet、函数、脚本文件或可运行程序的名称”这个报错几乎每个Windows用户都会遇到。热搜词里也出现了说明受害者不止我一个。这个错误的意思很简单PowerShell在当前目录和所有PATH目录里都找不到opencode这个命令。原因基本就是三选一原因一Path没加对。很多人下载了exe直接放在C:\tools以为就能用了结果忘了把C:\tools加到系统PATH。解决方法是右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 在“系统变量”里找到Path → 新增一行填exe所在目录 → 确定 →重启终端。记住最后一步很多人改完不重启终端发现还是报错以为步骤错了。原因二PowerShell执行策略限制。如果是用官方脚本在PowerShell里装的可能遇到“无法加载文件因为在此系统上禁止运行脚本”的提示。这时用管理员身份打开PowerShell执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser然后按Y确认。这样当前用户运行本地脚本不受限也能正常跑opencode的启动脚本。原因三装的是压缩包里的“读我文档”而不是exe。听着离谱但真有朋友下载完看都没看就双击运行那当然不行。还有一个检查技巧装完后先执行where opencode如果PowerShell能返回路径说明识别没问题如果显示“找不到”继续查PATH。先确认这一点再往深层排查。2.3 初始化配置auth login和第一份opencode.json装好只是开始。你还需要让opencode能访问模型而这步是整个使用体验的“地基”。运行opencode进入终端界面第一次它会提示你配置模型。最简单的路径是opencode auth login你会看到一个交互菜单里面有各家Provider的选项OpenAI、Anthropic、OpenRouter、Ollama等。选择你有的粘贴API Key进去它会保存到本地auth.json里权限设置得比较严只有当前用户能读。如果你用的是OpenRouter这类聚合服务那就更简单了。OpenRouter一个Key可以访问几百个模型包括很多免费模型后面详细说我推荐大多数人从OpenRouter开始试错成本低。配置文件放在~/.config/opencode/opencode.json这是全局配置。但如果某个项目需要特殊模型或权限策略你也可以在项目根目录放一个opencode.json项目级配置优先级更高。我第一次配置的时候犯了个典型错误把API Key直接写在了项目配置文件里后来提交代码时差点推上去。记住密钥走opencode auth login管理配置文件里只写模型名、系统提示词这类非敏感信息。3. 模型配置与免费模型的正确打开方式3.1 不花一分钱跑起来OpenRouter免费模型和本地Ollama很多人问opencode能不能免费用答案是能而且路径不止一条。路径一OpenRouter的:free模型。在OpenRouter的模型列表里标注为“free”的模型可以直接用只要你的OpenRouter账号有API Key就行不需要预充值。这个热词里出现了“hy3-free下线了吗”这种问题其实就是免费的第三方模型经常下线或改名不像商业模型那么稳定。我实际操作中配置一个免费模型是这样的在opencode.json里指定模型ID比如{ $schema: https://opencode.ai/config.json, model: google/gemma-3-27b-it:free }然后启动opencode它会自动通过OpenRouter路由到这个免费模型。路径二本地Ollama。如果你机器内存够大建议16GB以上装个Ollama拉一个7B或14B的量化模型然后把Provider配成Ollamaopencode auth login # 选择 Ollama默认会识别本地运行的 OLLAMA_BASE_URL本地模型的好处是零延迟、零费用、数据不出本机缺点是能力上限有限。我实测下来本地7B模型处理“改个变量名”“写个正则表达式”这类小任务可以做跨文件的复杂重构还是乏力。建议新手先别执着于纯本地把OpenRouter免费模型和Ollama都配上根据任务难度切换。3.2 配置多模型切换而不是锁定一个模型opencode有个很灵活的设计你可以在配置里定义多个模型然后用快捷指令或斜杠命令切换不需要改配置文件重启。我的工作习惯是这样的日常杂活写测试、修小Bug用OpenRouter上便宜大碗的模型复杂架构调整切到Claude Sonnet或GPT-4o这类高端模型涉及本地隐私数据时用Ollama。opencode适合这种“混合多模型”的工作流因为切换成本极低。具体做法是在opencode.json里把不同场景的模型都配好然后启动后输入/models就能看到所有可用模型上下键选择回车即可。这里有一个经验免费模型有一个共同坑——限流。OpenRouter的免费模型经常返回“429 Rate Limit”而且上下文窗口可能被压缩到很小。处理办法是别让它处理太长的文件把任务拆小或者准备几个备用免费模型限流了就切另一个。3.3 API Key和Model配置的填写逻辑再具体一点以最常见的OpenAI兼容Provider为例你要理解的配置逻辑是provider定义谁来提供API服务比如openai、anthropic、openrouter、自定义网关model定义具体的模型ID每个Provider的模型ID格式不同要按Provider的文档来apiKey不会写进配置文件一般通过auth login管理对于公司内部有API网关的团队opencode也支持自定义Base URL这正好接上热搜词里的“opencode mvn配置”。在Java/Maven项目里你可以在配置文件中设置环境变量比如export OPENCODE_CUSTOM_BASE_URLhttps://internal-gw.example.com/v1然后在opencode里选Custom Provider填对应的URL和Key就行。简单说任何“长得像OpenAI API”的服务都能用这个方式接进去包括一些国产大模型的商业化API兼容OpenAI格式的那种。4. 核心工作流实战从“帮我看看这段代码”到“独立完成一个模块重构”4.1 Agent模式到底帮你干了什么活装好配好之后你面对的是一个深色背景的终端界面。第一反应可能是“这跟ChatGPT网页版有啥区别”区别大了去了。ChatGPT你只能对话但opencode的对话框下面挂着一大堆“手”和“脚”——它能执行命令、读写文件、调用LSP语言服务器协议获取代码诊断、甚至操作浏览器做前端调试这就是热词里“opencode playwright怎么测试前端bug”的来历。我来拆解一个具体任务让你感受一下它的工作流。假设你接手了一个老项目需求是“把用户模块的登录逻辑从Session改成JWT”。传统做法你要自己打开代码找到所有跟Session相关的中间件、控制器、测试用例逐个替换。而opencode的Agent模式会这样跑搜索用grep搜索项目里所有session相关关键词找出核心文件。梳理读取路由、控制器、鉴权中间件的代码理解现有登录流程。规划在对话窗口里输出一段“我的实施计划”列出要改哪些文件、新增哪些依赖。执行逐个文件修改每次修改会展示diff你同意后才写入。验证自动找测试文件或直接跑编译命令如果报错就继续修复。这个过程中你随时可以打断说“等一下这里不要动”“换个方案”。这就是为什么不叫“自动编程”而叫“结对编程”——你仍然掌握方向盘它负责踩油门。4.2 TUI界面的常用快捷键和斜杠命令opencode的界面设计得挺克制信息密度高但不混乱。核心区域是对话消息流底部是输入框。常用的快捷键CtrlL清空当前对话上下文CtrlO打开对话历史记录文件以markdown格式放在本地目录ShiftTab在可用工具之间切换如果你有多个工具模块/调出斜杠命令菜单类似Slack可以快速执行保留命令Esc中断当前Agent循环斜杠命令里最实用的是/session查看和管理当前会话/compact压缩上下文长任务跑久了上下文会膨胀压一压能省不少token/plan进入规划模式它会先写实施计划不直接改代码等你确认后再动手这个/plan模式是我最喜欢的功能之一。它相当于在你和Agent之间加了一道“写作提纲确认”环节。我一般跑复杂任务前都会先让它出一个计划。计划里如果少了某个关键点你就直接说“漏了数据库迁移脚本”它会把计划补上。如果让它直接动手再改起来就麻烦得多。4.3 LSP与自动诊断Agent不用“猜”代码有一个细节让opencode用起来比早期终端Agent顺手得多它把LSPLanguage Server Protocol集成到了Agent循环里。简单解释说LSP就是给编辑器提供“代码智能”的后台服务。VS Code里你能看到红色波浪线的拼写错误和类型错误靠的就是LSP。opencode启动时如果检测到项目里有适合的LSP服务器它会自动启动一个并且让Agent在修改完代码后调用LSP接口重新诊断看有没有引入新的编译错误或类型错误。这个机制的效果是Agent改完代码不是“改完就不管了”而是会检查一遍有没有搞坏东西再决定是继续修还是报告任务完成。实测中这个LSP诊断能力很大程度上减少了“看着改了一跑就崩”的问题。不过它也有注意点LSP服务器本身吃内存项目大的话比如巨型Java仓库启动LSP可能很慢这时你可以在配置里关掉换回传统的编译命令检查。4.4 Skills和超级扩展把团队的规范“挂”给Agent热词里的“opencode skills”“opencode安装superpowers”“opencode oh-my-claudecode”值得单独聊一聊。Skills这个概念简单说就是把“专业技能包”做成markdown文件Agent在干活前会先读这些文件学习“规矩”。就像新员工入职先读公司规范手册一样。官方支持在~/.config/opencode/skills目录下放一堆.md文件每个文件描述一个技能的使用场景、步骤、注意事项。你还可以给每个技能配一个SKILL.md清单告诉Agent“遇到什么任务必须触发什么技能”。第三方生态里比较火的是superpowers一个Skills集合里面包含了几十个工程实践技能例如“先把需求拆成小任务再动手”“遇到重构先写测试再改代码”、oh-my-claudecode原先是给Claude Code用的配置增强包后来社区做了opencode兼容版。我目前的用法是把团队的代码审查清单做成一个Skill每次让opencode生成MR描述前它会自动加载这个清单确保提交信息包含改动模块、影响范围、测试结果。这比“人来遵守流程”靠谱得多——人总有忘了的时候Agent只要加载了规范就不会漏。5. 编辑器与桌面端不一定换掉IDE但能换个姿势5.1 VSCode插件和JetBrains插件跟终端版有什么区别opencode的官方插件很多人理解为“在IDE里嵌个聊天窗口”。但实际用下来它的价值不局限于聊天而是把Agent的能力融进了编辑器的上下文里。在VSCode里装好opencode插件后你可以选中一段代码右键“发送到opencode”Agent就能直接看到选中代码不用你在终端里描述“哪一段函数”。也可以直接把当前打开文件作为上下文传给Agent它基于整个文件的完整内容做修改建议。还有一个实用的点是Agent在终端里修改文件后IDE这边会同步更新而不是像老式工具那样要你手动刷新。JetBrains系的插件起步比VSCode晚一些但目前基本功能都有。我用IDEA比较多装了插件后最常用的场景是让Agent扫描一个类里所有的TODO注释生成一份待办清单或者让Agent直接根据一个接口文档生成DTO和Mapper代码。这个玩法贴合“opencode jetbrains idea插件”“idea opencode插件”这些热词指向的需求——在写Java业务代码尤其是Spring Boot那一套CRUD时Agent能省下大量模板代码时间。注意一点IDE插件的本质是连接“IDE ↔ opencode服务”。它需要你本机有opencode这个二进制文件。所以如果你连命令行里的opencode都没跑通插件装上了也没用。先用终端把配置折腾好再装插件会顺很多。5.2 桌面版Windows用户的新选择还有一个“opencode desktop”的热词说的是官方出的桌面客户端目前Windows支持比较完善。它本质上是给终端TUI套了一个本地窗口外壳集成了登录、配置编辑和终端交互。对于不习惯黑底白字终端的人桌面版有更好的视觉分区和更友好的按钮式配置界面。我实测下来的感觉是桌面版的终端渲染比Windows自带Terminal更平滑中文显示不乱码原生PowerShell有时候中文对齐有问题。不过它依赖本地opencode服务所以你依然需要先把命令行工具装好。5.3 opencode serve和“其他工具接入opencode”如果你对自动化有更高需求可以了解一下opencode serve。这个命令会启动一个本地的HTTP服务暴露Agent的API接口。别的程序可以通过这个接口调起opencode的Agent能力。举个例子你可以写一个Git提交钩子pre-commit hook当检测到代码变更时调用opencode serve的API让Agent自动生成提交信息。这也解释了“opencode接入superpower”“ccswitch配置opencode”“opencode codex pi哪个agent好用”这些搜索背后的动机——大家都在尝试把opencode嵌入自己的开发流程里有的通过配置工具切换模型网关有的通过API桥接多个Agent工具。核心思路都是让opencode成为“Agent能力的基础设施”而不是一个孤立的聊天工具。6. 遇到问题怎么排查高频报错和解决思路的完整速查6.1 “unexpected server error. check server logs”到底怎么查热搜词里有一大串报错场景最扎心的就是opencode error: unexpected server error. check server logs。我第一次遇到这个报错差点劝退因为界面直接卡住不知道去哪查。后来摸清套路了。这个报错本质上说明opencode能启动但底层Agent服务返回了未预期的HTTP错误。常见原因API Key失效或额度用尽。你的Provider账号欠费了、Key被删了或者免费额度见底。排查方法先去Provider控制台看看账户状态或者直接在命令行用curl测一下API连通性。模型ID拼写错误。你在配置里写的模型ID不存在比如免费模型刚下线了服务端会返回404opencode把这种错误也归为“unexpected server error”。本地代理或网络问题。如果你的机器走代理访问API代理不稳定也会导致这种错误。检查一下系统代理设置或者试试关掉代理直连。那“check server logs”到底看哪opencode的日志默认在~/.local/share/opencode/log/下Linux/macOS或%USERPROFILE%\.local\share\opencode\log\下Windows找到最近的*.log文件打开看最后的stack trace。看到401就是认证问题404就是模型不存在429就是限流。对症下药基本能解决九成的“unexpected server error”。6.2 Windows下中文乱码和PATH问题的终极解法Windows用户除了“cmdlet报错”还会频繁遇到中文乱码。这个问题的根源是Windows的默认代码页是GBK而opencode输出UTF-8。解决办法有两个任选其一在PowerShell里先执行chcp 65001切到UTF-8代码页再运行opencode。或者更好的方式用Windows Terminal不是老的conhost右键打开设置把“默认代码页”设为UTF-8。另外如果你在Windows上做Java开发就是Maven那类项目写完配置后可能会遇到OPENAI_API_KEY这类环境变量没识别的情况。注意Windows设置环境变量之后已经打开的终端进程不会自动读取新值必须重启终端。这个“重启才能生效”的坑我踩了不止一次。6.3 模型回答质量差、Agent“假装干了活”怎么治比报错更隐蔽的问题是Agent看起来干活了实际上没有真干或者改的代码质量很糟糕。我总结了几个常见诱因和应对方法。第一上下文不够。如果Agent只看到了你给它的那一小段代码它不知道整个项目的结构自然容易乱改。解决方法是让它先用/search或grep全局搜索相关代码把项目全貌梳理一遍再动手改。你也可以主动给它喂文件路径让它读取后再改。第二系统提示词缺失。如果你没在配置文件里加项目规范Agent不知道你的代码风格。我通常会在opencode.json里放一段“项目说明”用instructions字段指定一个说明文档路径告诉Agent“本模块依赖某框架”“函数注释必须写中文”“不要改动生成目录下的文件”。相当于给Agent立了规矩回来质量会好一个档次。第三任务太大一步到位。让Agent一次改10个文件出错概率会指数上升。我把一个大任务拆成几个子任务每个子任务引导它走完“搜索→计划→修改→验证”循环。实测下来这样虽然对话次数多但总体的正确率明显更高。6.4 常见问题速查表问题现象首要排查项解决动作提示“cmdlet/function/script”找不到PATH没有配置或终端没重启把opencode目录加进PATH重启终端unexpected server error查看日志里的HTTP状态码401查Key404查模型ID429限流代理/网络报错系统代理设置关闭代理或检查代理可用性模型回答质量差上下文不足、缺少项目规范加instructions字段、拆任务免费模型间歇性失败免费模型额度/限流备用免费模型切换或换商业模型中文乱码Windows代码页不对用chcp 65001或Windows TerminalLSP诊断慢或卡顿项目太大LSP启动吃内存关掉LSP改用命令检查改完代码后有编译错误Agent没做LSP诊断手动要求它跑一次编译命令7. 进阶技巧让opencode从“能用”变成“好用”7.1 编写属于你自己的项目级Skill如果你已经跑通基础功能我强烈建议从“使用第三方Skills”迈到“写自己的Skills”。不需要多复杂一个场景一个文件就够。比如我可以分享我的代码审查Skill是怎么写的。在~/.config/opencode/skills/code-review/SKILL.md里我写了这样一段逻辑触发条件当用户要求“审查代码”“review”时。执行步骤先读取变更文件的diff逐文件检查是否有安全隐患硬编码密钥、SQL注入痕迹、是否有明显性能问题、是否有不符合项目约定的命名或注释。输出格式按“问题严重程度”分级列出问题每项标注文件路径和行号最后给修改建议。有了这个Skill我每次让Agent“帮我看看这次改动”它都会按这套流程走输出的内容比我口头描述再让它自由发挥要规范得多。团队里如果有统一的代码规范写成Skill后所有用opencode的同事都能一键复用。7.2 用好MCP把私有数据源和内部API接进来MCPModel Context Protocol是Anthropic推的一个标准化协议opencode社区很快就跟进支持了。MCP本质上解决的是“怎么让Agent安全、可控地访问外部数据或操作外部系统”的问题。举个例子如果你开发时经常要查内部Wiki或公司的API文档你可以写一个MCP服务器封装“根据关键词搜索Wiki”的能力然后在opencode配置里注册这个MCP服务器。之后Agent在遇到不知道的接口时会主动去搜Wiki而不是瞎猜接口签名。这比你把Wiki内容全部复制到对话里当上下文要高效得多。安装MCP服务器也有现成方案。opencode支持在配置文件的mcp字段里声明服务器命令比如{ mcp: { internal-wiki: { command: node, args: [/path/to/wiki-mcp-server/index.js] } } }启动opencode后/mcp命令可以查看已加载的MCP服务器状态。实测下来MCP服务器要是没启动成功Agent会自动跳过它不会导致对话崩溃——这个兜底行为很关键不然一个MCP出问题整个Agent都没法用。7.3 用环境变量和配置文件分层管理密钥最后聊一下生产环境落地的问题。如果你不是一个人用而是团队要推广密钥管理一定要“分层”全局配置~/.config/opencode/opencode.json存放通用默认模型、默认权限。项目配置项目/.opencode/opencode.json存放项目专属模型、项目指令。环境变量OPENAI_API_KEY等存放密钥不要在以上两个配置里写明文密钥。这样团队拉仓库的时候项目配置跟着走密钥还是各自管理。opencode会识别本地auth.json和环境变量不需要把密钥写进共享代码库安全性和可维护性都好很多。在权限策略上我也建议用“最小授权”起步先禁用所有需要权限的工具比如文件写入、命令行执行用强制审批模式。等你对Agent的行为模式熟悉了再逐步放开。第一次用opencode就把“允许自动执行所有命令”打开的基本都会后悔——Agent可能把你的Git仓库改得乱七八糟。8. 一些个人体会opencode值得长期押注吗如果非要给一个结论目前开源终端Agent里opencode是我愿意持续用下去的一个。原因是它的生态位很巧妙——不绑模型、不绑编辑器、完全开源又是用Go写的单二进制部署资源占用低。这个设计让它像一块“Agent基建”你可以在上面接任何模型、任何工具、任何规则。当然它还在快速迭代不少功能一天一个样。今天好用的配置写法可能过两个版本就变了第三方Skills也有不少还比较粗糙。这确实是个“追新”成本较高的工具。但如果你的诉求和我一样是想要一个能把零散的AI能力串起来、真正干活的终端Agent那现阶段花点时间学opencode我觉得是值得的。我现在已经养成了习惯接到新需求第一反应不是自己打开IDE写而是先让opencode帮我跑一遍初稿和方案梳理我再在它的基础上改。在这个过程中我自己从“写代码的人”慢慢变成了“审代码、定方向的人”——这大概就是AI编程时代一个普通开发者的日常切片。
