如果到现在你还在把AI当成一个高级自动补全我建议你先合上这篇手册。AI Native团队这个词过去一年在技术社区几乎被说烂了但真正把“AI Native”落到开发流程里的团队十个里面未必有三个。我过去一年带着核心研发团队完整走了一遍这条转型路从IDE插件开发、Agent skills沉淀、统一工程模板、多语言混合开发到内网工具链部署、代码评审协议重建每一步都是实打实的坑。这篇落地手册就是我整理出来可以“抄作业”的部分适合正在带团队的技术负责人、想系统引入AI协作的中大型研发团队也适合那些已经不满足于“用AI写函数”、想学会“编排AI干活”的一线开发。1. AI Native不是口号先想清楚它在团队里到底改了什么1.1 范式转移从“人写代码AI辅助”到“Agent协作开发”AI辅助和AI Native的根本差异在于工作主体变了。传统模式下开发者是生产线上唯一的书写者AI只是补全工具你说一句它补一句代码的质量、结构、边界条件全部依赖人的心智。而AI Native模式下Agent成为真正的执行者人从“写代码的人”变成“拆任务的人”“评审的人”“验收的人”。我拿生活打个比方以前你是请了一个打字特别快、偶尔能帮你查资料的秘书字是你一个个敲的思路也是你的现在你是招了一个能独立跑完小任务的实习生你需要把需求拆到他听得懂、有明确验收标准的程度他说做完了你得检查他交上来的东西到底能不能用。这个转变不是“代码丢给AI”就完了团队的整个工作链路都要跟着变。我见过太多团队买了几十个账号把大模型接进IDE让每个人自己随便用结果三个月后一切回到原点。原因很简单大家还是在用AI辅助写代码而不是在建设一支能让Agent稳定产出的团队。前者的重心在“人的能力”后者的重心在“团队的工程基础设施和协作协议”。1.2 角色重组AI Native团队里不再只有“码农”传统研发团队是产品、前端、后端、测试、运维各管一摊AI Native团队把边界打散了。我这一年实际运行下来的感受是团队里需要出现几个过去没有的岗位或职能。第一个是需求工程师他的核心能力不是写文档而是把模糊的自然语言转成Agent可执行的规格说明。以前PRD写得含糊一点无所谓开发会自己脑补“产品说的就是这个意思”现在Agent不会脑补它只会按照你写的字面意思执行需求说不清楚它交出来的东西就一定跑偏。第二个是Agent编排者负责把一个大目标拆成多个Agent的并行任务管理它们的上下文边界和依赖关系。这很像传统后端里做服务编排的人只不过编排的对象从微服务变成了一个个AI工作进程。第三个是模型路由和工具链负责人要决定什么任务交给什么模型、什么任务走本地模型、什么任务必须上云、哪些代码库允许Agent直接操作哪些只能只读。很多团队忽略这个角色结果就是Agent在各种模型之间反复横跳产出风格极度不稳定。第四个是验收与安全守护者。Agent写的每一行代码今天都必须有人负责看而且最容易被忽略的是权限管理Agent有没有资格访问生产数据库有没有资格往主分支推送这些事没人盯着早晚出事。我团队里有个十年的嵌入式老手转型前他觉得自己那套C语言功底快没用了结果他是全组适应最快的。他不是去跟Agent比谁写STM32初始化写得快而是比Agent更清楚什么情况下标准库写法会踩坑。后来他变成了“嵌入式场景翻译官”把剩下的经验全部文档化喂给Agent用。这个角色定位的变化值得每一个老程序员想清楚。1.3 研发流程关键节点变化需求、编码、评审、发布需求阶段是最先要改的。以前PRD是给人看的现在一份合格的PRD要同时给人和Agent看意味着必须有可验证的验收标准、有明确的边界条件、有“绝对不要做”的负面约束。我在团队里推进用结构化需求模板把“用户故事技术约束验收清单禁忌事项”四段式写清楚Agent开工之前必须先回复自己的理解确认无误再动手。这一步看起来很啰嗦但它把大量后期的无效返工消灭在了源头。编码阶段的变化是最直观的。Agent负责实现人负责提供上下文和反馈。这里有个关键认知人给Agent的上下文质量直接决定代码质量。你把一个一万行的旧仓库直接丢给Agent让它改它大概率会给你编一个看似合理实则崩坏的方案你给它一份精简过的模块说明、几条关键约束和一个最小可复现的失败用例它反而能交出高质量代码。评审阶段从“读代码找逻辑漏洞”变成了“看diff、看测试覆盖、看Agent的推理过程”。我用了一段时间之后发现纯靠人肉去逐行Review Agent代码效率并不高更有效的做法是让Agent自己先做一轮自审附上每一步的推理依据人只需要重点看关键决策和风险点而不是逐行看实现。测试阶段同样要交给Agent去写传统的“开发写完代码再补测试”在AI Native流程里太慢了应该是Agent写完实现之后立刻生成测试人只负责补几个老程序员才知道的边界用例。发布阶段的变化被很多人忽视。以前我们的发布检查单是人肉过的现在我把检查单变成了一个半自动化的Agent流程Agent根据本次改动自动生成影响面分析、回滚预案、灰度建议。这个过程不需要太复杂但非常能提升安全感。2. 先做基建再谈智能AI Native团队的工程环境清单2.1 必须统一脚手架与模板拒绝一人一套环境AI Native团队要面对的技术栈五花八门。我扫了一眼团队月度复盘里提到的项目几乎就是一个全栈混合大杂烩前端是vue3的新项目后端有Flask、Node.js、Django嵌入式那边有基于标准库的STM32F103C8T6工程、ESP8266 NONOS环境还有ROS机械臂、Android、Qt桌面工具、HBase数据操作甚至还有人在研究怎么用Qt开发Web。这还只是一个中等规模的团队。如果每个工程师都保留自己的“祖传模板”Agent每次进入不同项目都要重新适应一遍目录结构、构建命令、代码风格产出质量根本没法稳定。所以AI Native落地的第一件事不是买模型而是把所有常用技术栈的工程模板收编统一进一个脚手架仓库。我用的是cookiecutter加自研CLI的组合ai-team new frontend-vue3、ai-team new embedded-stm32、ai-team new python-api-server生成的模板必须包含Agent需要的最低上下文信息——目录结构说明、常用的构建测试命令、代码风格约定、禁止事项清单。有个细节值得说模板里的“禁止事项”很重要。比如嵌入式模板里明确写“禁止在中断处理函数里调用耗时API”“禁止直接修改HAL库文件”前端模板里写“禁止使用any类型”“禁止直接修改package-lock.json”。Agent读了这个文件之后踩坑概率明显下降。2.2 开发环境标准化本地、虚拟机、容器三层隔离环境隔离是Agent可靠工作的前提。之前热搜里有一条特别接地气“本地虚拟机多端口nginx开发环境多站点自定义域名配置”这几乎是我见过所有团队都会遇到的需求。开发环境是本地联调环境在虚拟机CI打包环境在容器里三个环境如果不一致Agent在本地产出的代码一上CI就挂开发者还得半夜爬起来修环境问题。我的标准做法是本机统一用Docker Compose提供中间件依赖比如MySQL、Redis、HBase这些全部固定版本虚拟机承载联调环境用nginx把多个站点路由到不同端口同时配上自定义域名改hosts文件实现“前端开发机访问api.xxx.dev就能打到虚拟机对应端口”。这里直接给一份我团队实际在用的nginx多站点配置核心片段# 虚拟机内的多站点配置 server { listen 8080; server_name admin.xxx.dev; location / { proxy_pass http://127.0.0.1:9100; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } server { listen 8080; server_name api.xxx.dev; location / { proxy_pass http://127.0.0.1:9200; proxy_set_header Host $host; } } server { listen 8081; server_name docs.xxx.dev; root /srv/docs_site/dist; index index.html; }本地的hosts里加上192.168.1.100 admin.xxx.dev api.xxx.dev docs.xxx.devAgent和人都用域名访问再也不需要记几十个裸端口。这套方案的好处是Agent在任何时候都知道“访问管理后台就用admin.xxx.dev”不用猜测环境上下文干净了出错率自然下降。2.3 多技术栈的AI友好配置统一脚手架只是第一步真正让Agent干活顺手得在每个技术栈里做针对性配置。前端方向我建议2026年的新vue3项目直接默认Vite加TypeScript加unplugin-auto-import把依赖自动导入配好。项目根目录放一个AGENTS.md里面写清楚页面路由统一约定在src/router/routes.ts注册组件目录按页面划分状态管理用Pinia且禁止在组件里直接改store之外的全局状态样式统一用CSS变量。Agent每次改前端代码之前先读这个文件产出的代码风格一致性会好很多。嵌入式方向VSCode搭建STM32开发环境加J-Link下载环境那条热搜我很有共鸣。过去用Keil现在AI Native团队最好迁移到VSCode加CMake加arm-none-eabi-gcc工具链模板直接基于标准库的STM32F103C8T6工程因为CubeMX生成的HAL工程对Agent来说结构太绕。模板里固定好芯片头文件路径、链接脚本、烧录任务VSCode里配置好Cortex-Debug和J-Link这样Agent才知道怎么编译、怎么烧录、怎么用日志调问题。后端方向Python平台用Flask或Django都行但必须在模板里配好gunicorn启动脚本、健康检查端点、日志格式规范。Node.js项目则统一ESM规范、固定包管理器版本避免lock文件冲突。这里有一个核心原则所有配置都不是给开发工程师一个人看的而是要给Agent当“入职培训材料”用的。你配置写得多明白Agent的起点就有多高。2.4 内网环境的模型与工具链部署很多团队忽略了一个现实企业的研发代码是不能随便出内网的。不是不信任云服务而是法务和合规就不允许。这时候必须做模型分层非敏感任务走云端API敏感代码片段、公司核心业务逻辑必须走内网部署的私有模型。落地起来其实不复杂。内网服务器部署开源模型不做微调主要做代码补全、日志分析、知识库问答这些任务。外网模型负责代码审查、需求分析、复杂重构方案设计这些“不需要知道具体业务代码也能干”的活。中间用一层统一网关做转发按项目打标路由。我再提醒一个配套动作模型网关的日志一定要开。因为内网模型回答的质量可能不如云端模型把每次调用记录下来团队才能通过真实数据判断“哪类任务必须走外网哪类任务内网足够”。我团队第一次做这个统计的时候发现内网模型在日志分析上的准确性其实也很能打但一旦涉及多文件联动的重构明显不如云端模型这就是分层路由的依据。3. Agent协作体系让AI真正成为团队的一份子3.1 一套“AI入职文档”是最高优先级Agent没有入职培训就干不好活就像新同事不读文档不问老员工只凭想象写代码一样。我踩过最大的坑就是一开始直接把整个仓库丢给Agent它自己翻代码翻到上下文爆炸然后开始编一个“看起来合理”的架构来糊弄我。现在团队里的强制要求是每个仓库根目录必须有AGENTS.md内容至少包含五部分。第一部分是仓库架构用几句话描述这个服务的核心模块、数据流向、依赖关系。第二部分是常用命令包括如何跑测试、如何构建、如何本地起服务、如何检查lint。第三部分是代码风格约束比如Go项目禁止用全局变量、前端项目禁止用any、后端接口必须做参数校验。第四部分是评审标准告诉Agent什么情况下算“完成了”什么情况下算“不合格”。第五部分是禁忌事项比如“禁止改动公共底层库”“禁止在提交里包含自动生成的IDE配置文件”。我直接放一个精简模板# AGENTS.md ## 仓库定位 支付网关服务负责外部支付渠道的签名、请求转发、回调验签。 ## 常用命令 - 本地启动: python app.py --envlocal - 跑全部测试: pytest tests/ -v - Lint: ruff check . ## 代码风格 - 所有外部接口必须做参数白名单校验 - 禁止使用 print 输出日志必须用 logger - 回调处理逻辑必须幂等 ## 评审标准 - 单测覆盖新增代码的关键分支 - 不引入新的全局可变状态 - 签名算法改动必须附带兼容旧签名的方案 ## 禁止事项 - 禁止在回调接口里做阻塞式HTTP调用 - 禁止把密钥写入代码仓库这套文档越写越好之后我发现一个额外收益它成了新员工培训手册人也能用Agent也能用一套资产两处收益。3.2 Skills机制把团队经验固化为技能让Agent在单个仓库里干活是第一步让它在组织范围内复用特定领域的经验是第二步这就是Skills机制的价值。热搜里那群人老在说的“前端开发skills”“agent开发skills”“嵌入式开发skills”本质都是同一件事把某个领域专家脑子里的方法论提取成Agent能加载的技能包。比如我团队沉淀了一个“RAG应用开发skill”内容不只包含怎么搭dify工作流还包括公司内部知识库的分块策略、检索词改写规则、候选段落重排的参数经验。再比如“嵌入式低功耗调优skill”内置了STM32在睡眠模式下外设时钟配置的检查清单。Agent一但加载这些技能它就从一个“只会写代码的通用助手”变成了“懂这片业务的老员工”。Skills的形态不用太统一团队里好用才是标准。我用得比较顺手的结构是YAML头部加一段说明--- name: frontend-vue3-review description: Vue3项目代码评审技能按团队前端规范检查新提交的diff version: 1.0.0 rules: - 禁止使用 any - 路由必须注册在 routes.ts - 样式变量必须从 styles 目录引入禁止魔法数字 - API调用必须走 src/api 封装禁止直接fetch ---Agent读到这个文件再配合AGENTS.md它对“团队期望”的理解会清晰很多。这里还有一个关键心得skills文件一定要放在能版本控制的目录里谁改了什么一清二楚不要放在个人笔记里。3.3 IDE插件开发与本地Agent的深度集成很多团队一谈AI Native就想着接一个网页端聊天机器人这是最大的误区。开发者的主场在IDE里Agent不能只活在聊天窗口里。我团队花了大力气做IDE插件开发目的就是让Agent直接嵌入开发者的日常工作流。以JetBrains系IDEA为例我们开发了一个内部插件把需求系统、代码仓库、Agent执行器串在一起。开发者在IDE里选中一段代码右键就能看到“让Agent解释这段逻辑”“按项目规范重构这一段”“为这个方法生成单测”三个入口。点下去之后插件会把当前文件、选中范围、项目AGENTS.md一并打包发给本地Agent结果以diff形式展示在IDE的差异面板里。开发者不用切走看完直接决定接受还是拒绝。VS Code这边也是一样extension把Claude Code这类CLI工具封装了一下我们在命令面板里加了几个自定义命令比如“新增前端页面”“为当前服务增加一个新接口”它会自动按仓库模板生成骨架代码。整个过程不需要开发者反复写prompt插件把所有上下文都拼好了。这个工作不难但价值极高。因为它把“使用AI”这个动作从额外成本变成了顺手的事。IDE里的一个按钮比让开发者在终端里敲十几行prompt要高效得多。你要是团队里有人做过JetBrains或VS Code插件开发这是性价比最高的投入点。3.4 代码审查、测试生成、文档同步三件套Agent协作体系里我把代码审查、测试生成、文档同步称为“三件套”因为它们几乎能覆盖团队日常最耗时的三类杂活。代码审查这一块让Agent先做第一轮机械审查它的强项是捕捉明显的空指针、资源泄漏、无分支覆盖、硬编码密钥这些模式化问题。流程上是Agent先对提交的diff做一轮“预审查”输出风险点列表和修改建议开发者在此基础上做第二轮人工审查。需要注意的是不要让Agent直接给出“LGTM”这种结论必须附上依据不然它会变成一种迷之自信的橡皮图章反而有害。测试生成的价值被很多人低估。过去团队新功能开发占八成时间写测试占两成但真正漏到生产环境的bug往往就出在那两成没写好的测试里。让Agent根据接口输入输出约束生成测试用例覆盖正常分支和异常分支人能省很大一块时间。实际用下来Agent生成单测的通过率在七成以上剩下三成需要补齐的参数化用例正好是领域专家最擅长补的部分。文档同步是最容易见效的。很多代码库的README和注释早就不维护了Agent每次读仓库都能发现一堆“文档说的是A代码写的是B”的问题。我让Agent在每轮代码提交前自动生成本次改动的变更说明追加到指定文档里保持文档和代码同步演进。三个月之后团队里所有仓库的文档新鲜度有了肉眼可见的提升。3.5 Agent上下文管理上下文是agent开发的生命线。一个大仓库动辄几万文件、几十万行代码不可能一次性全塞给Agent。很多人遇到的情况是Agent用着用着就开始“失忆”前一句还在说A方案后一句就自己改了主意。这不完全是模型问题更多是上下文被撑爆了。我有三招可以分享。第一招是按模块拆不要让Agent负责“整个系统”只让它负责某个模块。如果任务跨度太大就拆成多个子Agent每个Agent管一块最后再汇合。第二招是按任务粒度切一个任务尽量控制在半天能完成的量级太大就继续拆。第三招是给Agent递“线索链”把最关键的约束、最常见的踩坑点、最新的接口定义作为步骤3、步骤4的输入再喂一遍而不是指望它记住最开始的会话内容。这第三招最反直觉但最好用。我团队里现在写prompt都有一个习惯在关键节点主动“重复关键信息”。比如让Agent写数据库迁移脚本任务描述里先放一次约束交付前再让它“确认本次迁移必须兼容MySQL 5.7版本不允许使用窗口函数”它犯错的概率会低很多。本质上我们不能要求Agent像人一样拥有稳定记忆那就通过主动喂信息来补偿。4. 完整落地路线试点、推广、复盘4.1 第一步选一个高价值、低风险的切入场景任何团队都不该一上来就搞“全面AI化”那是灾难。正确做法是先选一个高价值、低风险的场景做验证。判断标准有三个场景是否高频是否好验收失败是否会引发事故。我推荐按这个表来评估候选场景候选场景价值风险上不上内部工具脚本生成高低优先测试用例自动生成高低优先提交信息与文档同步中低可以代码预审查高中试点核心业务代码自动生成高高缓一缓内部工具脚本和测试生成几乎是无痛场景就算写得不好改的成本也低。核心业务代码自动生成先别碰除非团队已经有很强的验收能力不然就是给自己挖坑。我团队第一次试点选的是“测试用例自动生成”两周时间把三个存量模块的测试覆盖率从四成拉到了七成这个结果让团队里反对的声音小了很多。4.2 第二步定义质量门槛与退出机制试点不能靠感觉得提前定指标。我团队实际在用的指标有五项首次通过率Agent交付的代码不经修改直接通过评审的比例目标不低于五成返工轮次单个任务从开始到验收经历的修改轮数目标不超过三轮代码评审耗时单次评审时间如果比人工时代还长说明Agent没起到作用测试覆盖率新增代码覆盖率必须达到团队既定门槛线上事故数这是底线指标任何流程改动都不能让这个数字抬头这里有个容易被忽视的点退出机制同样重要。当某个场景连续两周“首次通过率低于两成”或“返工轮次高于五次”就得停下来诊断不要硬扛。不是每个场景都适合Agent承认某些场景不适合本身就是一种成熟。我见过有团队为了证明AI有效硬逼着Agent改老掉牙的祖传代码最后所有人都痛苦不堪。果断退出再选下一个场景才是可持续的打法。4.3 第三步全员培训和结对实践推广的最大阻力永远是人的习惯而不是技术。一线开发者的心态通常分三类第一类是兴奋型什么都想试试要引导他们不要乱来第二类是观望型想用但怕出丑要给他们低难度的成功体验第三类是抵触型觉得AI写的是垃圾与其说服他们不如让他们在试点场景里看到实例。最有效的方式是结对实践。让一个已经熟练使用Agent的“AI熟手”和一个很少用的“AI新手”结对开发新人负责定义任务和验收熟手负责演示怎么拆解需求、怎么给Agent喂上下文、怎么Review产出。这一个周期走下来新人比看十场培训都管用。培训内容上核心不是教“怎么用某个工具”而是教“怎么写出一段让Agent一次跑对的任务描述”。我会让新人练习用四段式描述任务目标是什么、边界是什么、输入是什么、验收标准是什么。能把这四句话说清楚Agent的产出质量立刻上一个台阶。4.4 第四步效果度量与持续改进落地进入稳定期后把指标贴到公共看板上每周复盘。我看着数据发现一个规律Agent的首次通过率会随着仓库文档质量的提升而稳定上涨。这说明AI Native不是单方面压榨Agent而是逼着团队把文档、规范、脚手架这些被长期忽视的基础设施补起来。Agent成了团队工程质量的“照妖镜”哪里乱它就在哪里翻车。复盘会上反复讨论最多的不再是谁写的代码多而是“哪个模块的文档该更新了”“哪个任务的描述方式值得沉淀成模板”。这就是正循环的开始。持续改进的节奏一般是两周一次每次找出一个影响效率最大的瓶颈集中解决一个不贪多。5. 踩坑实录AI Native团队最容易翻车的几个地方5.1 上下文幻觉“懂王模式”害死人Agent最让人头疼的问题是它非常擅长一本正经地胡说八道。我遇到过Agent在改造一个老项目时完全不看仓库里现有的架构直接按自己训练数据里的“最佳实践”吹了一个新框架方案还把理由写得头头是道。它以为它是懂了其实只是触发了“懂王模式”。对策其实很简单在任务描述和AGENTS.md里反复强调“以仓库现有实现为准优先最小改动禁止引入未要求的新依赖”。如果任务里涉及的模块比较复杂就把现有模块的入口文件、核心数据结构直接贴给Agent让它先概述它对现有实现的理解再动手。先复述后动手这一个动作能干掉七成的胡编乱造。5.2 认证与权限Agent不能有万能钥匙这是安全上最容易被忽略的一环。初期我们图省事给Agent配了全仓库的读写权限结果它有一次在“优化代码”时把一个公共库的文件整个格式化了一遍附带着改了行尾符diff直接爆掉团队成员花了半个下午才把那些无效改动挑出来。更危险的是Agent有权限访问生产环境的日志查询接口我们直到一次安全审计才关掉。经验原则有三条一是Agent默认只读写操作必须人在对话里明确允许或者走评审流程二是密钥不落地永远不要让Agent访问包含密钥的文件使用环境变量或专用密钥管理服务传递三是对外请求要审计Agent发出的请求最好经过统一网关方便追溯。记住一句话Agent不该有主人没同意就能执行的“万能操作”。5.3 输出不稳定带来的评审负担同一个任务不同模型跑出来的方案可能完全不同同一个模型不同prompt写法也能产出天壤之别的结果。如果团队没有统一约束评审者的负担会比原来更重因为他要同时评两份完全陌生的代码。解法是给Agent上“缰绳”固定模型版本、固定提示词模板、固定输出格式要求。我在团队里要求每个Agent工作流必须声明“底模锁定到具体版本”避免模型厂商悄悄升级导致输出风格漂移。同时要求所有Agent输出必须自带“改动说明测试结果影响范围”格式不达标一律视为未完成。这一个动作让评审效率提升了将近一倍。5.4 看似自动化的工具链拼凑很多团队喜欢给Agent外面套一堆脚本今天写个Python脚本发通知明天写个shell脚本拉代码后天再用另一个脚本调接口。结果工具链越来越多真正出问题时你分不清是模型的问题、脚本的问题还是环境的问题。我中间有一阵就是这个状态最后痛下决心收敛所有Agent相关操作统一走自己那个IDE插件和CLI入口中间不去手工穿插其他脚本。要新增能力就扩展原有工具链而不是另起炉灶。可观测性也得跟上每个Agent任务的输入、输出、耗时、模型、费用都要有日志这样出了问题才有迹可循。5.5 快速排查表症状可能原因处理办法Agent产出与仓库实际架构不符上下文不够没读关键模块重贴入口文件与核心数据结构强制先复述理解Agent在同一个问题上反复改来改去验收标准不明确补充量化验收指标说清楚“什么样算完成”生成代码覆盖测试全红环境变量或依赖缺失把本地起服务和跑测试的最小命令写进AGENTS.mdAgent悄悄改了无关文件权限过大默认只读撤销无关路径的写权限评审耗时没有下降输出风格不统一固定模型版本、固定prompt模板、要求统一输出格式模型回答质量突然下降模型版本变更或缓存异常锁定模型版本检查网关日志清理上下文缓存最后说一个我在实际落地中体会最深的点AI Native最难的不是技术而是让人接受“自己的判断力才是稀缺资源”。最初团队里最抵触这套模式的是几个十年经验的老手因为Agent写的代码他们一眼就能看出问题而他们恰恰是唯一能让Agent第一次就跑对的人——只要他们愿意把脑海里的约束写进文档。这套模式的启动成本远比想象中低你不需要一开始就买最贵的模型、搭最复杂的平台先拿一个仓库写一份AGENTS.md挑一个低风险场景让Agent跑一个完整任务看看。我始终相信AI Native落地不是技术选型问题而是团队把自己多年攒下的经验重新变成可传播资产的问题谁先想明白这一点谁就能真正跑赢这一轮。