过去几年，AI Coding 快速发展，从代码补全、代码生成，到现在具备任务拆解和自主执行能力的 Coding Agent，AI 正在越来越深入地参与软件研发流程。那么，如何让 AI Coding 从“个人外挂”变成团队生产力？如何保证代码质量，构建可控、可复用、可持续演进的 Agent 工程路径？
近日，InfoQ《极客有约》X AICon 直播栏目特别邀请网易游戏高级技术经理林香鑫担任主持人，和网龙网络资深技术总监陈洁、柏佳辰平凯数据库（TiDB） /智能研发中心负责人、汇丰科技内部开源负责人李渭宁一起，在 AICon全球人工智能开发与应用大会2026 深圳站 即将召开之际，共同探讨 Coding Agent 如何重构需求分析、代码审查、运维排障等软件工程环节。
部分精彩观点如下：
AI 来了并不是说需要减少人，而是可以更快地赋能业务，让产品和服务做得更好。
每个开发都变成 “QA”，关注 End2End。开发人员正在承担更多质量责任：不再把逐行人工审查作为默认方式，而以风险分级审查、自动化门禁和端到端验收为主，把需求、完成条件和最终结果讲清楚、验到位。
代码质量从最开始的纺锤形变成哑铃形，AI Coding agent 更像是自然语言的编译器，我们更在意的是前面的 SPEC 和后边的 testing。
在可逆、低爆炸半径且可追溯的隔离环境内，可以按任务范围给 Agent 完成任务所需的最小充分权限；数据库结构变更、生产环境操作、外部网络访问等高风险动作必须严格收紧权限或设置人工门禁。每个 Agent 都有身份标识，操作日志可追溯，新的安全风险也要持续纳入治理。
没有绝对的安全，没有安全能一劳永逸，都是发现问题快速亡羊补牢。
在 8 月 21-22 日将于深圳举办的 AICon全球人工智能开发与应用大会2026 深圳站上，我们特别设置了【AI 原生新范式：Coding Agent 重构软件研发全流程】专题。该专题将围绕 AI 原生研发的技术演进与工程实践展开，重点关注研发 Agent 的能力边界、工程化落地、质量与安全保障，以及 AI 驱动的软件生产方式如何提升研发效率、降低交付成本，并推动组织研发模式升级。
查看大会日程解锁更多精彩内容：https://aicon.infoq.cn/2026/shenzhen/track
以下内容基于直播速记整理，经 InfoQ 删减。
完整直播回放可查看：https://www.infoq.cn/video/8FaZW1Rx2ffsrru6QYdw?utm_source=home_video&utm_medium=article
从“会用 AI Coding”到“驾驭 AI Coding”
林香鑫： 从大家目前的实践和观察来看，AI Coding 真正进入生产环境后，最大的变化是什么？
柏佳辰： 我们的 AI Coding 产品进入到实际的客户实践，尤其是金融客户实践比较多以后，发现两点。一是遗留代码改造比新功能开发需求更大；二是金融等行业既有企业客户对 AI Coding 流程自动化的适配性，和创业团队、互联网公司不太一样，他们往往有很多需要人去审批的不同阶段，不同的人需要去审批和 review，这对 AI Coding 的产品和范式都提出了更细致、更复杂的需求。第三，我们开发者和早期试用者对 AI Coding 范式亲和性很高，很多实际问题没暴露。但一旦落到金融等行业客户那，组织层面的协同问题就出来了，不同人对 AI 工具的适配性、熟练度、实践是否一致，都会通过产品层暴露出来。
李渭宁：第一个从需求方面，我们以为 AI 会取代人，但实际上，业务需求是大幅增加的，最近也在大规模招人。AI 来了并不是说需要减少人，而是可以更快地赋能业务，让产品和服务做得更好。
第二个从效率层面，我们一直以来衡量生产效率主要看 Dora Metrics，看每人每年发布了多少个 release，生产事故有多少。从去年前年引入 AI Coding，去年开始大规模应用，Dora Metrics 上看有所改善，但也没办法直接证明是 AI Coding 带来的。个人层面分化很明显：技术功底好、认知够、设计能力强的人，AI 来了之后真的是成倍增加效率，但有些同事用了 AI Coding 之后反而造成了很多混乱。
第三个从 token 的使用来说。去年 token 这件事还摆不上台面，以前 GitHub Copilot 都是订阅式的，按月收费。但从今年 6 月 1 号以后，全部转成了 token 消费，这个就突然浮现在台面上了。我们现在每人每月大概几百美金预算，只有少部分人用光了这部分预算。一个重要原因跟金融行业有关系，金融行业做软件都是做精修的，很少说重建一个系统、把原来东西推翻重新再来。金融系统往往希望建一个系统就能够持续迭代十几年，所以 token 的使用情况也反映了这一点。
陈洁：
第一种是我们已经给研发团队推广的一套 AI Coding 与 AI Testing 工作流。它围绕 Claude Code、CodeX 和 Gemini CLI 等 Coding Agent 工具，结合 Superpowers 与研发方法，覆盖需求设计、技术调研、架构设计、详细设计和实现的常规解决方案。大家普遍反馈流程规范，实施细节可以更多交给 Agent，但链路较长。这套方式更适合业务相对稳定、对 AI Coding 接受度仍在提升的团队，属于 Agent 协作、人工主控的模式。
第二种是我直接带的团队，更接近 YOLO Mode。 我们承担的职责更多是 Pilot Team，验证更激进的 AI Coding。我发现，在部分受控开发场景中，团队成员会主动从 Auto Mode 切换到 Bypass Permissions；这是团队的使用选择，不是产品权限模式的默认演进。若每个环节都依赖人工逐项审批，流程会很长，因此我们会先明确目标和边界，再让 Agent 持续执行。需要强调的是，Bypass Permissions 会跳过权限提示和安全检查，不能把它当作通用安全模式。按 Anthropic 当前官方说明，要达到其建议的安全边界，该模式只应在与主机、敏感数据和生产资源隔离、默认无互联网访问的容器、虚拟机或 dev container 中使用；联网、数据库结构变更、生产操作等高风险动作应退出该模式，并走权限控制或人工门禁。在这种迭代式 Agent 执行闭环（业内也称 Loop Engineering）中，我们不再把逐行审查作为默认方式，而是实行风险分级审查，并强化自动化门禁和端到端验收。开发人员也因此更多承担质量责任：把需求讲清楚，设计可验证的完成条件，再检查最终结果。过去端到端质量更多由 QA 兜底，现在开发人员必须补足测试设计能力。复杂场景还需要显式编排任务依赖、分支、并行执行和状态流转。
MCP、Skills、Rules 到底解决什么问题？
林香鑫：最近一年 MCP、Skills、Rules 这些概念非常火。但很多人也有疑问：这些东西只是增加了一套新工具体系，还是真正改变了 AI 和工程系统交互的方式？想请几位老师结合实践分享，这些能力在真实研发过程中解决了哪些问题？
陈洁：
这个问题在我们这里很有代表性。除推动 AI Coding 外，我们还在建设面向集团的 AI 能力中台，并在 AI Hub 中规划建设 Skill Hub：个人可以沉淀 Skill，也可以按治理规则发布共享，让同类场景能够复用。MCP 能以标准化方式连接既有技术资产，但协议本身并不替代认证、授权和数据治理；因此，我们还在建设 MCP Gateway 来统一控制访问边界。不同资产不能绕过网关直接互通，节点间传递还要进行敏感信息检测，避免数据在调用链路中不受控地外流。
对个人而言，以前 CLAUDE.md 容易越写越长，把约束、Rules 和执行步骤全部塞进去。Anthropic 当前建议每个 CLAUDE.md 以少于 200 行为目标；任务型流程放到 Skills，其完整内容在使用时加载；路径相关约束放到带 paths 范围的 .claude/rules/。这里的 Rules 是模型上下文中的行为指引；必须强制执行的安全限制仍要落到 permissions、Hooks 或工程门禁。分层后还要按需加载，尽量给任务保留上下文空间。长程、多轮 Agent 任务尤其需要控制上下文噪声，以降低指令漂移风险。
李渭宁：我们现在一直在尝试解决 AI 的两个问题，一个是动态可规划性，另一个是输出的可控性。为了保证质量，我们依赖原先的整个 SDLC，包括设计评审、代码扫描、自动化测试，这个流程本身没变。有了 MCP 和 Skill、Rules 之后，就想能不能让 AI 多理解我们的上下文和内部知识，在做动态规划的时候利用现有工作流或知识。
MCP 在去年的时候，我们甚至出了一套开发规范，有 12 点的技术标准，包括权限管理、调用限制、日志审计、错误处理。但实际上用的时候卡在数据权限控制，什么数据 AI 可以消费，哪些不能，卡得非常严格，导致 MCP 跟 AI 结合的效果跟原先预计的不太一样，进度比较缓慢，目前 MCP 只能处理一些内部知识和项目 ticket。
MCP 推出不久之后就有了 Skill。原来需要把很多 API 或者系统接口转成 MCP，有了 Skill 之后就不用搞接口转化了，可以把工作流和系统 API 嵌入到 Skill 里面。很多企业也都在做 Skill Hub，全员可以分享和下载。就我们来说，目前 Skill 主要集中在开发环节，每个团队把开发规范、工作流程、自动化东西包装成 Skill 让同事复用，新同事用 Skill 能更快融入团队。这方面做得不错。但除此之外，在其他环节我还没看到 Skill 有太大影响，因为 Skill 毕竟只是一个中间环节。我们更多希望的是一个设计好的 Agent，在可控的环境下、可控的流程里面，有一个比较稳定的输出。我们期待的是这个，而不是 MCP 或者 Skill。
Rules 是因为 Skill 或者 AI 有时候发挥不稳定，不得已用 Rules 去规范它，给它边界和控制规约，让 AI 输出有一些稳定性。除此之外，我们也大量使用传统方式验证 AI 生成的质量，比如基于规则的代码扫描、基于测试案例的最终结果验证。当然 AI 也做一部分代码评审，但更多我们是希望有确定性的东西来验证 AI 生成的效果。我期待未来除了这些小组件之外，是不是可以有一些更好的东西，能让 AI 基于内部知识去做动态规划的能力更强，同时输出的稳定性有一个可期待的效果。
林香鑫：为什么这些东西会出现，确实是因为 agent 在工作表现和结果上存在不确定性，这些东西更多是为了约束 agent 朝着确定性的结果去。传统代码扫描技术不能丢，基于规则的东西更确定，我们实践里也在寻求基于规则和基于 agent 的中间平衡。
柏佳辰： 最早是大模型本身的 tool calling（工具调用），后来发现太固定了就加了 MCP。MCP 本质上是自建的一层 tool calling 机制，好处是功能非常明确，就是为了给 agent 接触外部世界的一双手。但问题在于 MCP tools 的范式很固定，启动时所有工具一次性载入上下文，工具不能太多，多了会对大模型能力提出很高要求，出现越堆越多、性能反而越差的问题。
后来 Anthropic 提出了 Skill 机制，本质上就是 lazy loading（惰性载入），先有 metadata（元数据） 进来再按需载入。但 Skill 的 lazy loading 随着实际使用，你会发现还是会出现治理问题。因为 Skill 大家都觉得很香，都在构建大量组合包。Superpowers、G-Stack、speckit，这三件套装到 agent 里可能就小 100 个 Skill 了，就算做 lazy loading 最后还是会出现使用混淆，Skill 是缺乏治理的。
所以后面回到了比较针对性的规则。工程项目里或者说规约里，需要写清楚要做哪些、不要做哪些。本质上 Skill 是为 agent 铺路，Rules 是加上护栏。我们在客户那里发现，不同阶段有不同上下文需求，如果以单一 agent 把全流程 Skill 全灌进去，就会出现混淆和上下文爆炸问题。所以我们提出了 multi agent，给不同 agent 不同职责，前端做前端、后端做后端、需求做需求、review 做 review，把全链路 Skill 分而治之。每个 Agent 负责单独领域时质量更高、任务更明确，会自发构成调用次序和工作流，在客户落地中非常受欢迎。
林香鑫：现在 Skills 开发成本太低了，非技术同学一天也能造十来个。这些东西经常占用上下文，叫“Token 刺客”，你都不知道它占用了你的上下文，Token 就哗啦啦花出去了。怎么应对 Token 刺客，需要随着 AI 应用深入，针对不同场景做更深度的治理。
如何保证代码质量不失控？
林香鑫：AI Coding 一个明显优势是速度。但速度提升之后，也带来了新的问题。想请各位分享：AI Coding 时代，团队应该如何建立新的质量保障体系？
李渭宁：质量体系，其实我们一直没变过。单元测试通过率、覆盖率，发布频次，P1/P2 生产事故数量，这些指标跟用什么工具不相关。AI 来了之后，我们只是在想怎么给 AI Coding 加上工程护栏，让它能符合我们一直沿用的质量体系。
主要从三方面着手。一是输入输出：需求通过 SPEC 生成代码时，我们以前写 user story 里面的 case、when、then 这些东西要继续沿用。代码规范不管用 Skill 还是 SPEC 都要描述出来，以前是人看文档，现在是让 AI 看 SPEC 去做代码生成。依赖管理也要严格，不能随便下载外部包，只能在内部仓库取，第三方组件有安全漏洞就被禁掉，要不断升级版本。二是怎么持续改进：就像 PDCA 一样，对着目标每次生成完去看差距在哪里，然后不断改进。
林香鑫：那你觉得现在 AI Coding 应用模式下，质量会出现比不上之前的情况吗？还是通过约束之后，仍然能达到原先的质量要求？
李渭宁：质量要求是越来越高的，跟用什么工具不相关。不管用人、找外包还是用 AI，一定要达到那个指标。比如生产平均故障率有多少，发布次数有多少，不看生成多少行代码。这两个指标逐年增长之后现在趋于稳定了，跟工具本身是解绑的。只是有了 AI 之后需求变多了，怎么在需求变多的情况下依然保持较低的生产事故？所以我们把整个 SDLC 的生产流程管控得更严了，每一个地方都要有 checkpoint，过了之后才能往下一个地方走。比如单元测试覆盖率是功能开发覆盖率还是路径覆盖率，要求得很细，通过过程去管控最后的质量。
柏佳辰： AI Coding 时代来临了，每个人的平均生产力是指数级上升，但好像不太有人能拍着胸脯说工程质量也上升了。更多时候我们看到的是人突突突地往里面写了代码之后，整个工程质量变得更加糟糕了。
我们刚开始和客户交接的时候，最开始想的是两个，一个是 SDD（Spec Driven Development），一个是 TDD（Test Driven Development）。我们想的是，代码质量从最开始的纺锤形变成哑铃形。之前我们更多是把最大精力和注意力放在代码实现里边，前面的 SPEC 写作很无聊，后面的 testing 更多是为了覆盖率糊弄事。但到了 AI Coding 之后，AI Coding agent 更像是自然语言的编译器，我们更在意的是前面的 SPEC 和后边的 testing。前面的 SPEC 让人审查，后边的 testing 让 agent 去 harness。这个想法最开始是很丰满的。
后面发现一个很奇妙的事情：用了 AI Coding 写出来的工程，代码覆盖率变得更高了，但是质量变得更低了。因为在这个过程中，我们是把人的眼睛给移除掉了。一个 top coder 可能一天贡献 5000 行、上万行代码，这确实超出了人的 review 能力。我们尝试用 testing 做自动化的质量保证，但发现了若干问题。比如单元测试，AI Coding 写的很有好习惯，会写各种测试案例，但仔细看它写的全都是 happy case，可能不会主动去写 edge case。所以覆盖率很高，但最后代码是有问题的。稍微大一点的 scope 下，testing 有它自己的范围限制，无论单元测试还是集成测试，scope 就只在一个模块、一个组件里边，你可能组件写对了，但在整体的架构里是错误的。再往上一级，端到端的 test 就算符合 SPEC，这个 SPEC 往往也不能够很好地反映人的实际需求。因为产品开发得太快了，SDD 和 TDD 想用 agent 原生方式回归人的需求，但 AI 跟人的背离，就产生了工程质量和实际表现的背离。
陈洁：
从第一性原理来看，代码只是过程产物，真正要保证的是产品功能和用户体验不失控。去年开春后，我们团队取消了前后端角色边界，转向人人全栈；今年团队内除保留 2 名 QA 主要负责预生产环境的端到端业务验证外，其余 QA 同学均转为兼具开发与测试职责的全栈岗位。在我们的团队实践中，AI Coding 提速后，测试一度成为瓶颈，缺陷和回归压力也随之上升。
我们从几个维度控制。第一，我们深度调研了 GitHub SpecKit 和 OpenSpec，并自研适合自己的部分。第二，两者的官方工作流都以 Markdown Artifact 为主；我们没有直接沿用其模板，而是在借鉴流程后采用团队自研的结构化脚本表达，以适配内部可读性、可维护性和 Agent 解析需求。第三，区分 Greenfield（从 0 到 1）和 Brownfield（历史遗留项目）。Brownfield 的难点是：即使读完代码，Agent 也未必能获得隐性业务知识；快速 hotfix 时，团队也容易遗漏更新 Wiki。因此我们设计了以 Issue 作为变更追踪主线，每天抽取变更点生成日报，由程序员判断是否需要更新知识库。我们还设计了团队内部的 ACF（Agent Copilot Flow），让 Agent 先做首轮机械性审查，标出高风险点后再由人复核；业务语义、架构、安全和最终责任仍由人承担。团队也持续探索更适合 Agent 的终端与开发环境，从 iTerm2、Ghostty、Otty，到近期我们开始使用 Orca，并通过 worktree 并行处理任务。这里的 worktree 用于隔离工作目录和分支，并不等同于容器、凭据或网络安全隔离。AI Testing 主要围绕 Browser Use 驱动的浏览器 QA 自动化与评测（Evals）展开，500 多个回归用例中已有 280 个由 AI 执行。香港大学数据智能实验室（HKUDS）的 OpenSpace 可用于跟踪和评估 Skill 的任务表现及演进效果。我们从端到端结果出发，在约束层和需求层设置门禁，并结合单元、集成、回归、安全及非功能测试持续改进 Agent 链路。团队原则上减少直接在 IDE 中手工改代码，把精力更多放在优化 Agent 和验证结果上。
观众： 通过 SDD 约束了需求方，但到测试环节，研发环境跟测试环境是分开的，怎么尽可能保障研发环境产出代码的手测通过率？
陈洁：
今年，除保留 2 名 QA 主要负责预生产环境的端到端业务验证外，其余 QA 同学都已转为兼具开发与测试职责的全栈岗位，开发阶段的测试责任由开发同学承担。我们不再严格区分开发与测试角色，但仍保留预生产环境作为上线前门禁。前面通过 TDD 明确测试用例，Agent 可在受控环境中部署依赖并运行大部分测试。我们也打通了 CI/CD、测试环境和 Agent 运行时，近期在测试环境中接入 Claude Code 做最后调试；它不具备任何生产环境权限。
Agent 应该拥有多大权限？
林香鑫：当 Coding Agent 从辅助工具变成执行者，它开始修改代码、调用工具、访问系统。Agent 到底应该拥有多少权限？什么事可以自动完成？什么事必须经过人工确认？企业应该如何设计 Agent 的安全边界？
柏佳辰： 权限同时包含着不同的客户和使用场景的需求，以及不同的思潮。对于新锐用户，有些同学直接就开 YOLO 了，不开反而不舒服。如果把 agent 只看成是运行在 macOS 或 Linux 上的一个进程，我们会担心它有各种泄露和问题，怕它 rm-rf。但如果换一个思考方式，认为 agent 本身就是未来的 OS 呢？如果我们不再面对 macOS 桌面或者 Linux 界面，面对的就是一个 agent，可能是小龙虾或者别的什么带着 UI 的，那可能它就应该是权限全开的，就应该拥有我们所有资料、所有权限，因为它就该是我们的数字分身。scope（作用域） 本身也是一种权限机制。缺乏治理体系的 agent 跑到一个庞大的工程里，当前模块做好了却把其他东西碰坏了，我认为这也是权限问题。
李渭宁：以前管控手段比较少的时候，经常会发现程序员删库跑路。但当公司的权限矩阵和管理流程规范之后，就不会出现这种情况了，因为程序员不会有生产的权限。agent 也是一样的，它也是一个身份，这个身份能干什么事应该被定义。刚开始在沙箱里玩，因为有些权限还没想清楚，就在沙箱里玩，玩错了就不断改进。等沙箱里验证足够好了再出来，不管在本地、测试还是生产环境上，它就是那个身份，该有什么权限就去做什么事。权限是层层控制的——不只是在前端控制，是在后端、数据库甚至网络级别。有层层把控就不怕它前面乱来，一般不会出什么大事。
林香鑫：本身外部环境就已经约束了 agent 能够做到什么样的程度了。
李渭宁：就跟我们现在权限矩阵一样。它融入到原有的权限体系里面去，层层控制，多层防护机制。
陈洁：
反过来，我认为 Agent 权限是非常重要的事。团队的 Claude Code 终端在受控开发环境中确实经常使用 Bypass Permissions。我们会通过严格脚本设置外部护栏，但脚本并不能恢复该模式已经关闭的原生权限检查，所以还必须依赖环境隔离、最小授权和可追溯日志。
涉及数据库表结构变更和生产环境操作时，我们严格收紧权限，目前不会放开。第二，每个 Agent 都必须可追溯。我们在内部 Agent Registry 中为每个 Agent 注册唯一 ID，并用内部 Agent Card 描述其能力、端点和认证要求。（这里的 ID 是内部字段，并非 A2A 规范中 Agent Card 规定的通用字段。）正如柏老师提到的，Agent 可以被视为数字分身。我们通过 Langfuse 为已纳入插桩的 Agent 链路记录必要 Trace，并持续核查插桩覆盖率和采样策略，同时设置敏感信息脱敏、分级授权和保留周期。需要区分的是，Trace 用于重建和诊断请求链路，并不天然等同于审计日志；审计还要关联身份、授权和高风险动作。经过合规治理的数据，后续可作为评测、复盘和模型优化的候选数据。
昨晚，我在尝试让 Agent 生成教育视频的 POC，它提出要建立双向网络隧道。我一下就警觉起来：公司严格控制这类网络连接，因为它可能扩大外部流量进入内网的攻击面。技术方案本身未必不合理，但它不了解公司的网络安全政策。这已经不只是密钥泄露或删库问题，而是 Agent 是否具备足够的安全上下文。我立即把经过脱敏、审批的安全规则抽象成受控 Skill，供团队复用。看到大家普遍使用 Bypass Permissions，我更意识到必须把权限边界、安全知识和可观测性一起治理。
我的原则是：在可逆、低爆炸半径且可追溯的隔离环境内，可以按任务范围给 Agent 完成任务所需的最小充分权限；数据库结构变更、生产环境操作、外部网络访问等高风险动作必须收紧权限或设置人工门禁。每个 Agent 都有身份标识，操作日志可追溯，新的安全风险也要持续纳入治理。
林香鑫：平时我们留意的都是删库删文件或私密信息泄露，但网络层面确实被很多人忽略，尤其是缺乏这方面安全意识的工程师。像最近 OpenAI 搞 Hugging Face 那个事件，借助 AI 更容易发现高危问题从而被突破。
观众： 如果 agent 它自己有了一个自主意识了，那会不会绕过你设计的这个防护层呢？
李渭宁：人也可能会绕过防护层的，没有绝对的安全，没有安全能一劳永逸，都是发现问题快速亡羊补牢。你要足够快，发现问题了能够及时应对。系统暴露在外面也会有安全漏洞、会被人攻击，发现了就赶紧修，这是一个不断迭代的过程。
如果重新建设 AI 原生研发体系
林香鑫：如果今天重新设计一套 AI Native 的研发体系：你认为最应该优先建设的能力是什么？是模型？是工具？是知识体系？是流程规范？还是团队能力？
陈洁：
我会优先做知识体系。研发链路中的数据资产会因疏忽或遗忘遗漏关键信息；只有知识准确、及时、可追溯，输入给 AI 的上下文才更可靠，也更有助于降低因上下文缺失而产生错误输出的风险。我负责的 5 个项目中，已有 2 个在研发流程中采用多个 Coding Agent 协同；这是我们的内部实践，并不意味着多 Agent 适合所有任务。第二，建设评测门禁。业界近期把未经充分验证的低质量 AI 生成产物称为 Vibe Slop；当生成吞吐提高而验证能力没有同步提升时，这类产物也可能更快堆积。我们通过评测、Trace 和门禁暴露并定位 Agent 执行闭环中的薄弱环节，持续补缺。第三，治理 Skill：这是我们的内部阈值——连续 3 个月零调用的 Skill 先移入待归档区，不直接删除；再结合依赖关系、低频关键场景和真实任务结果复核。我们也正在评估引入香港大学数据智能实验室（HKUDS）的 OpenSpace，用于记录和评估 Skill 质量，辅助决定演进或退役。第四，确定性 SOP 适合用工作流固化，但让人手工拖拽编排效率较低。我们在权限、隔离和审计边界内，将 OpenClaw 的 Gateway 和 Agent 运行能力接入 AI Hub，并建设自然语言生成工作流（NL2Workflow）能力。第五，做全链路效能优化，通过 Trace 同时关注任务成功率、单位成功任务的 Token 成本、时延、错误率和工具调用次数。
柏佳辰： 我认为不是构建什么技能或技术体系，是改变人，让人拥有和机器对话的能力。AI Coding 时代不是说在传统体系里让程序员关掉 VS Code 打开 Claude Code 就立刻变厉害。vibe coding 要求的不再是语言特性掌握或算法数据结构能力，而是大局观念、以产品和架构师角度去构建项目。在大模型参数里面是没有前后端分野的，人要的就是表达全栈需求，剩下的让 AI 解决。硅谷那边很多当红公司的 CEO 也纷纷开始写代码了，因为他们又能瞬间上手了。
李渭宁：以前我在汽车行业干过，从手工生产到流水线自动化，跨时代时第一个想到的是流程管控。用 6 Sigma、PDCA 让整个过程可见、可控、可提高。以前手搓汽车的和自动化流水线的工人是不一样的，先有这个管控框架，大家在框架下去适配流程，让整个效率大幅提高。现在看到很多企业从 prompt engineering、context engineering 到 harness loop engineering、graph engineering 一直在探索。第一步是玩法到底应该怎么玩，人应该怎么适配。玩法在变，人也在不断适配，工具也在不断变化，你方唱罢我登场。最终形成一个 AI 时代 Engineer 的一套 Framework，形成它的相关工具集、最佳实践、对人的要求，整个框架、工具、人就比较和谐地融在一起了，就大幅提效。
观众： 大家都说在 AI 时代，组织要打破传统模式，那目前真的打破传统组织架构了吗？
李渭宁：任何一个新的时代来，组织架构一定会变。我们最近刚刚又有了 CAO（Chief AI Officer）。另一个，AI Coding 来了之后前端工程师的岗位变少了，更多希望全栈，QA 的角色也变少了。新的生产工具来了，一定会有新的生产关系。
柏佳辰： 目前在整个大的范围内还没有实质意义上发生改变，但之后一定会变。一定是自下而上的，以某种工具或具体形态在行业里进行大规模应用，并且获得了足够信任之后，组织架构墙自然被推倒。像福特公司最开始的流水线引入，不是强行推动的，是由利润驱动自发变成范式，发展到让丰田、大众一起来用。AI Coding 也一样，不是上面有个 CXO 强行推动了某种组织架构变革于是我们就变革了，一定是自下而上的，当大家都开始用 AI Coding 并且获得了足够的好处和信任，组织架构墙自然会被打破。
观众： 现在 agent 架构面试看重什么能力呢？如果你现在去面试一个同学，希望能够解决你们现在 AI 层面的落地问题，会比较看重哪方面的技术？
李渭宁：我有个朋友最近去找工作，他面试某个大厂的时候，面试官本来是耷拉着眼睛问问题，我朋友说到正在帮王自如干什么事，面试官一下就精神了。所以不管做 agent、做开发、做任何事，首先是你这个人醒目、勤奋、持续学习，做任何事都不会差。
陈洁：
我非常看重面试同学 AI Coding 的能力，即使你是文史类专业，我也不会因此降低评价。但我一定会问两个问题。第一，你在使用 Claude Code 的过程中是否用过 /insights 命令？它会生成对 Claude Code 会话的分析报告，包括项目领域、交互模式和摩擦点等，帮助使用者复盘改进。第二，如果设计 Agent 架构，我会问：长程、多轮任务中如何管理上下文压缩或重置，并确保关键约束与进度状态不丢失？如何发现和纠正目标偏移？任务状态如何持久化？并行会话如何隔离文件改动、运行环境与权限边界？
观众： 怎么利用 AI，从 0 到 1 推动一个产品落地？
陈洁：
产品落地这个范围太大，我收回到开发过程。首先，根据关键用户路径和预期负载定义可测量的非功能性指标，形成性能瓶颈和容量假设，再通过基准测试或压测验证，并据此评估架构的可扩展性（Scalability），形成总体 Spec。随后按团队既有的 SAFe 或 Scrum 节奏迭代交付；如果目的是验证产品假设，则先以 MVP 获取真实用户反馈。在引入我们内部的需求细化 Skill（Grill-Me）之前，团队更多使用 Superpowers 的 Brainstorming 流程；在我们的场景里，该流程有时会拉长讨论，却未必形成足够可执行的方案。我们的做法是先明确项目框架、技术栈和关键约束，再逐层细化功能需求。此后还要持续维护 Spec、测试资产和知识库。当 AI 生成吞吐提高时，仅靠人工维护这些资产可能跟不上更新节奏；可以由 AI 提议更新，但变更需纳入版本控制和可追溯校验，并保留人工审核与质量门禁。
会议推荐
2026 年 AICon 人工智能开发与应用大会 · 深圳站将于 8 月 21 日—22 日举办，聚焦 AI 基础设施、大模型系统、智能体工程、数据智能、多模态技术与行业落地等关键方向，邀请来自腾讯、阿里、华为、百度、蚂蚁集团等 50 + 头部科技企业技术负责人、科研机构一线专家，系统性分享前沿洞察与实战干货，共同探讨 AI 技术从能力到系统、从实验到生产的真实路径。更多详情可扫码或联系票务经理 13269078023 进行咨询。
