通过前几篇文章从2个不同的应用角度讲述了AI对嵌入应用交付的使用情况。其实用简单的方式讲就是：使用AI来写需求代码。这里面要有一个大前提：需求。需求是怎么来的？这个问题再简单不过了，就是我们的用户、甲方、“衣食父母”所要求、提出的。所以说，需求就是每个研发人员立命的根本。

对于需求从用户、业务、项目、产品、最后到研发会经历很复杂的过程，曾经有人在网上吐槽过：本来用户是要一枚螺丝钉，结果业务改一点、项目挑一部分、产品“升华”一下，最终研发可能开发出了一个螺丝母。 

当然本文章不讲需求，从需求提出到AI研发，后面会用单独的一篇文章讲解。确切的讲可能几篇文章都理不清它们之间的关系。我们今天主要看一下对于一个需求如何能在生产环境做到以灰度的方式做切换，并且AI在此过程中发挥着如何的作用。

搞过研发的人员对灰度这个词不会陌生，而且提到灰度这个词就会想到：这个需求绝对不是一次、二次的需求，可能是经历了多次迭代的结果。所以，讲灰度之前就要先把需求讲明白。

对于商旅系统中不同平台、不同系统的整合，就会有一些看似搞笑的需求。商旅系统有些数据是需要给用户开放的，虽然是开放，还是要有一定的权限。就是说：A企业只能访问A企业的数据，不能访问到B企业的数据；A集团的财务可能需要访问A和B两家，甚至是更多的数据。这样就引出了权限问题。

讲到这里，都会觉得这种需求有什么难的，赶紧上权限平台不就可以了吗。看似很简单的事情，却都习惯用一句话做了解答。

当时我们面对是什么样的场景呢？APP端基本功能已经完成、后端系统也已经线上运营、用户PC系统建设了大半部分、而权限平台还处在建设的初级阶段。我们的“上帝”提出了用户PC系统数据权限的要求，不同公司的财务人员要看不同的商旅数据。

在生活中我们也都要有抓大放小的意识，对于需求我们更要有抓大放小的情形。用户提出这样的需求，实现数据权限的归类已经是迫在眉睫。一边是用户的催促、一边是权限平台建设的困难重重，在这种情况下就必须有个临时方案：用一张临时表，账号和账号所属的公司存储到表中，以此来确定当前这个账号可以看到哪些企业公司数据。可以有一家、也可以有多家，只要不重复即可。

这样的需求本来可以通过权限平台、系统间调度来满足要求。然而，实际情况必须要“屈服”于客户的要求。这么看来临时表方案也算是一种较为合理的这种方案。

俗话讲：“甘蔗没有两头甜”。这句话其实央视曾经有过类似的报道，验证了这句话是错误的。甘蔗要么是不甜、要么是都甜，不存在没有两头甜的情况。当然这句话只是为了表达出它的哲理性而已，我们就不过多纠结，总之任何事都有两面性。

快速迭代也一定会有其他代价的付出。说回上面的需求，为了能快速实现用户所谓的数据权限需求，我们不得不引进临时表方案。这个方案总结一个字就是“快”。代价呢？还是有一些，比如：只能用公司ID去区分；每一个有账号的人都可以查询；而且没有菜单、按钮的鉴权过程；最主要是不能区分功能，就是一个账号能把全部PC用户的事情都干了。俗话讲：这里有明显的越权行为。 

这样的代价是快速迭代所赋予的。当然前面也说了，权限平台也是在建设中，这么一来就会诱发了另一个更大的代价：当权限平台建设好后，一定会带来临时表和权限平台的互换，而且对于临时表中的账号都存在着不友好状况。

可能有的人会说，那有什么啊，当权限平台上线以后，将临时表的账号都切过去不就行了吗。说着简单，做着难。最简单的例子，临时表已经陆续创建了几千个账号，怎么能保证一次性、完美无缺的切换到权限平台呢。

当面临这种情况时，每个场景就会面对不同的诉求和反馈。

业务：我的账号已经有相关的权限，不管怎么变，反正不能影响当前的使用；

运营：我已经配置了众多账号，你现在再让我重新配置一遍，我是在陪你们玩吗；

产品：当时的设计就是为了更好的兼容，你们在开发的时候为什么不多想一步呢；

测试：测一遍全流程是多么的不容易，你还要让我再来一遍吗；

研发：我们的问题，我们正在积极排查、努力改正、等待最后的结果......。

看到这些不知道你心里作何感想，应该不会太爽。这时候我们是不是要重新给研发做一次定位或升级呢？先姑且放下争议，把这样的情况更加优美的处理掉才是最紧迫的事情。

这种情况的解决通常的做法就是开关，用于区分权限鉴权，判断鉴权该走权限平台还是临时表。这一方案会比较简单，加一个总开关，哪种状态做哪种判断。

这种方案有很大的短板，就是：无法区分账号，只能做到一刀切。要么是正、要么是负，给系统稳定性增加了很大的难度，确切的讲：并没有实现权限平台在这个问题上的平稳过渡，只是做了个研发性质的回滚操作罢了。

之前我们用AI做了模板式代码和任务式代码开发，在任务知识库积累的情况下，还精准解决线上难以分析的问题。所以，也可以通过AI来做一下架构优化方案。

本着提出问题、明确问题、解决问题和问题落地等要求，用AI任务拆解任务方式梳理出该灰度架构的方案。

这是向AI提出问题，我们看看AI是如何给出架构优化的解决方案： 

除了方案，AI还给出了R1开关的执行情况：

AI还提供了都要修改哪些环节：

到这里灰度方案的架构优化基本得到了解决，通过加一张账号表，对应账号和开关标识，对每个账号做处理，能更加清晰的让每个账号是走权限平台还是沿用原临时表方案。

二次审查是为了让AI的架构方案更加合理化落地。不仅要明确数据表、字段的状态类型；还要明确都要修改哪些部分；重点要审查对鉴权的影响，灰度开关(俗称：小开关)是否打乱了权限平台正常的鉴权情况。

AI同样给出了每个状态的执行True和False：

经过复查，以及修改代码的Codings分析，确定无误就可以执行代码修改，这样就保证了架构方案的准确落地。

无论什么样的方案，也都离不开数据的支持与维护。在没有维护页面时，需要考虑在受限的条件下，让数据能按架构优化后的逻辑规则运行，从而对业务、运营、产品、测试等等多个角色做好权衡。

到此，AI对权限平台的平稳过渡、生产账号的灰度做到了完美的处理。虽然也不能算什么经典的案例，最多就是加了张表而已。但是最终的效果可能是让系统，乃至各个方面人员都得到很好的解决方案。就像那句话：“招数不在新，管用就行”。

本次灰度架构方案完全是AI+人工审核的结果，是不是全是AI的工作，这也要做一些区分，毕竟方案的审核、执行、落地也都是人工在做着精准处理。

AI在这次架构优化也给出了非常出色的解决方案，AI的方案源自什么？也是需要重点思考的问题。AI的方案还是由前期大量知识库和代码实现，以及业务逻辑做支撑。如果没有这些，只是让AI来生成一个架构优化方案，也一定能给出方案，但是这个方案到底适不适合当前的业务流程是很难断定。 

再就是给出的架构方案并不是拿来就用，也是经过了人工重点审核，而且还做了二次验证，最终加入了维护数据流程，这些都更加贴近实战，是对线上生产环境的准确结合。

如何让AI参与到需求交付中，并且能精准、高效的完成项目需求，会是未来近10年大家都要彼此争论、博弈、尝试、调整、优化的话题。

临时方案如何平稳退出：AI参与权限平台灰度上线实战

后端

架构设计

人工智能

AI如何通过灰度架构优化权限平台平稳过渡？本文以商旅系统数据权限需求为例，展示AI辅助方案分析、二次审查与落地维护，解决临时表切换难题，实现账号级灰度切换，兼顾业务连续性与系统稳定，为快速迭代下的架构升级提供高效参考。

数据管理

数据流

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

临时方案如何平稳退出：AI参与权限平台灰度上线实战

临时方案如何平稳退出：AI参与权限平台灰度上线实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐