相信每个人在使用AI的时候都会有这样、那样的困惑，对用AI做项目交付需求开发代码更是有许多不理解的地方。在众多的困惑、疑问当中，最大的问题也许就是：“为什么AI总是不按着要求来呢？为什么让AI做这个，他偏偏却做了其他的呢？”。这就相当于我们经常说的那句俗语：“让你往东你偏往西、让你打狗你偏追鸡”。

对于这个问题，我们可以想一下，到底是AI的问题，还是我们的问题。追究这一问题也是很没有意义的。毕竟AI只是一堆算力非常惊人服务器，如果说你非得要把问题结果归咎与AI，AI也给不了你任何的补偿。

所以我们就不应该把这种问题一定追究个是非对错。唯一好方法就是：如何更好的去引导AI，让AI尽量避免类似问题发生。这才是破解之道吧。  

说到商旅，我们就继续用商旅的需求，来看一看AI针对这一需求是如何“跑偏”；而且又是怎么一步步返回到“正规”的；在AI使用复盘的过程中，又是怎么含糊其辞让人难理解；最终是什么方式让AI综合做了准确评估。

在互联网公司研发代码，尤其是在项目工程类业务逻辑中，审批流对于每个研发人员都不会陌生。因为有两个字贯穿于工程类的全篇，那就是“流程”。有了流程，就必然会有审批，有了审批，则更是必然有审批流。这就是人们常说的：“天道循环”吧。

提到审批流，总会有一定的程序员宿命，什么宿命？那就是谁是负责审批流的人员，他一定是团队的核心人员，绝对受到团队的各种眷顾。很简单的道理，谁才能审批流程啊？肯定都是领导，是领导就必然会关注业务流程的审批过程，让对应的研发人员受到领导的瞩目，使研发人员成为核心骨干是顺理成章的事情。 

说了这么多，还是着重看一下商旅的审批流。审批流大体会有几个重点步骤：公司体系结构、人员基本信息、申请单模版、审批流模版、公司部门人员关系、公司部门借调关系、申请单模版挂靠、审批流模版选择、审批流触发、审批流类型、审批流审批、审批流任务流转、审批流撤回、审批流结束等等，如果要更加详细的列能列一篇文章。

为了能对商旅审批流有更好的印象。重点介绍三张表，这里就不介绍表中都包含哪些字段到底干什么了。主要介绍表在审批流的作用和使用场景，表包括：审批流创建表、审批流审批人表、审批流节点表。这三张表是什么关系呢？

审批流创建表：审批流是谁创建的，哪个公司、哪个部门、哪种类型审批流，相当于审批流的最基本信息；

审批流审批人表：这张表就要和审批流创建表做关联了，一个审批流会有多个人，所以就要将这些审批人记录到审批人表中；

审批流节点表：每个审批人在审批流中负责的角色是不同的。有单一节点审批、多个节点审批、单一节点会签、单一节点或签等等，这些都要在节点表做重复体现。

商旅审批流正常流程会有所依赖，大部分是发生在提交出差申请单的时候。按着人员、公司配置的审批流，来启动审批流。出差申请单是商旅服务的“基石”，审批流就是出差业务的“触发器”，只有这两步都完成了，才可以进行出差交通工具和住宿酒店的预订。这也就能看出商旅审批流的重要性。

把小需求做成大需求的例子在互联网行业笔笔皆是。曾经就有人说过这么一个例子：原本的需求就是要每个部门、每个月统计一下，到底有多少汇总数据。仔细分析后，这家公司的数据量并不是夸张的离谱，况且还是按月统计。很简单，如果是微服务架构用：Java+Spring+Dubbo+MySQL完全能搞得定。 

我们看看这个团队是怎么做的：底层研发还是这个架构：Java+Spring+Dubbo+MySQL。然而数据产生之后，为了适配大数据，引入了：Hadoop+Hive+Kafka等；为了提升操作速度将数据同步到缓存：Redis；为了查询条件更加灵活引入了：ES；最后微服务的工具类架构引入了配置中心：Nacos；为了多服务之间的协调引入了各种框架：SpringCloud+OpenFeign等； 

仅仅是工具就引入了多少，仅为了每个月统计部门的一点数据。这个团队引入这么庞大工具体系后，使得系统变得臃肿了很多，本来就不是一个只有正、反的情况。后来从团队线上维护描述中得到这样结果：各种工具经常因不兼容导致系统异常；本来就是同一条数据，要同步到各个工具链路中，很难保证数据的一致性；每次线上有问题，不确定到底在哪里下手，甚至导致各个团队的不信任和推诿等等。 

说到这里，有时我们真的要扪心自问一下：“这么多工具的问世，到底是让数据变得简单了，还是更加复杂了呢？”。

说回到审批流，毕竟现在开发需求都离不开AI工作，我们也要看看AI对于小需求是如何干成了大需求，从哪些方面偏离了原本的需求初衷。

这次就是有关审批流的一个小需求。需求是：在审批流管理中需要可以通过审批人查询，选择不同公司的审批人后可以查询到相关节点审批流，然后选择返回结果的审批流将审批人做批量替换。描述过于笼统，程序员都习惯用一句话来描述：就是将查询到的审批流中的审批人做替换。

之前不断讲了AI在研发过程中应该使用拆分任务的方式让AI精准的做代码执行，我们看看AI对这个需求是怎么操作的。

AI通过需求描述和冻结检查表，生成了任务明细表。能看出切片任务明细基本上是符合产品和业务逻辑要求的。这时候按着以前的方式，通过任务生成Codings明细表。然后做Codings代码生成，很容易的完成这一需求。

如果剧情这么简单，就不会有那么多跌宕起伏的人生了。在开始测试后，突然测试询问到：按“王一”这个审批人查询时，不论是单条选择还是批量选择，都不会有对应的审批流结果，什么原因？

看到这里其实自己心里还有一点迷糊。迷糊什么？明明AI已经按着需求做了分析，怎么就出现这么无法解释的问题呢。“解铃还须系铃人”，看看AI头脑风暴一下是不是就解决了呢？列出AI的问题任务。

瞬间给出了AI三连鞭，核心的问题就是想知道：为什么审批人查询的结果集会丢审批流？我们一起看看AI给出了哪些回答？

问题看似描写的比较清晰了。第一:人员ID是不同的，原公司用户ID和借调公司用户ID是不一样的，当前查询条件只认 nodeId，这个nodeId都是原公司ID；第二:不论是“选择”还是“批量选择”都会传公司信息orgId或orgIds这样就会让SQL语句带上额外条件，会使得查询结果发生了变化。

问题找到了，剩下的就是解决问题是非常easy的事情了。上面说到了，我们的人生会有更多的版本，哪能就这么轻易的去躺平。这时继续和AI做交流逐步将需求实现带跑偏了。

AI给出了还算正确的问题分析： 

AI的分析结果，表明为什么所属公司的用户能查到对应的审批流，而借调公司却无法查到对应的审批流。最初的查询条件把nodeId作为了用户ID，所属公司用户ID没有问题，但是借调公司用户ID并非这一ID，所以无法查到。 

继续给AI提要求，希望能给出精准的解决方案。然而，这时候AI却对解决方案和业务需求没做很好的对应，让整体需求研发方向发生了改变。

AI的解决方案就是：拿到查询条件的nodeId后，然后去借调表中将对应的借调人员ID全部拿出来，将对应这些人的审批流信息全部拿到。

AI继续也给出了代码处理情况，和上面的解决方案一致。虽然通过nodeId将借调人员过滤出来，然后通过orgIds将无用数据再过滤掉，这样的操作看似是解决了问题，但还是暴漏了一些问题：第一:点击“选择”会将借调公司不该显示的审批流展示；第二:多了很多次查询操作的语句。

这种情况下就开始不断的向AI提出问题，让AI给出解决方案。然而，整个痛苦的过程距离真正的需求是越跑越远，甚至到了南辕北辙的程度。我们不看AI给的结果，看一看提出的问题就能想到结果的错误。

列出了这么多的问题，现在的结论就是：彻底乱了。

看着问题，以及AI逐渐跑偏的方向，这时候该怎么处理。应该想到当前我们最值得去推崇的那句话：不忘初心。

对于AI和当前审批流这一需求，最初的初心是什么？非常的明确，就是：通过审批人可以查询到对应审批流，然后选择审批流后可以做审批节点审批人的批量替换。其实上文也已经列出了到底是在哪个环节被带偏的，只是当讨论的问题过于多，而且无法精准明确后，很难去发现这个节点。

所以，可以抛弃以前的AI的全部切片任务，重新开启一次AI的研发过程，这就是最早的初心。也许有人也会问：推倒重来之前的工作不就白做了吗？并不会，毕竟之前的知识库还是保存了下来，哪怕是错误的知识库。 

重新列出改审批流需求的切片任务：

再一次列了很多项AI交流的过程，这次重点是UC-FLOW-BUSINESS-03和UC-FLOW-BUSINESS-07，可以仔细阅读一下切片任务。UC-FLOW-BUSINESS-03主要做了放弃原来传递公司ID的参数，通过每条选择记录的人员ID作为参数用于查询；UC-FLOW-BUSINESS-07解决了在替换审批人提交时，被替换人的用户ID传递错误。

AI这次纠偏主要还是在任务UC-FLOW-BUSINESS-03，找到了问题的根本原因，然后解决掉。在这里也可以复盘一下，问题到底出在哪？最后是什么起到了解决的作用？ 

如果就看这个需求，是在选择NodeId和用户人员ID、以及公司ID的参数与查询场景的不对应导致；解决问题的关键就是在对用户人员ID做了查询收口，其他都不作为主要的查询信息，这让AI又重回康庄大道。

这么简单的一个需求，却经历了这么漫长和痛苦的波折。在上文中也是复盘了问题，不过我们也应该从AI的使用方向上重新归纳一下。在这个需求中还是有AI的使用问题。

首先就是切片任务的颗粒度太过“臃肿”，一个任务几乎包含了整个需求想要的东西，AI在处理过程中一定会彼此关联而导致错误；其次就是每天任务执行的边界还是模糊不清，并没有给任务太多的限制，导致了AI的随意发挥；最后就是反馈结果和任务掺杂在一起，有些反馈结果是AI给出的建议，如果和任务掺杂在一起一定会让AI执行代码发生不可预料的错误，毕竟商旅审批流已经是一个庞大的系统。

所以后面继续使用AI编码一定要对此有所规范。切片任务一定要小，俗话说：“小步快跑”就是这个道理；然后就是边界限制要精准明确，任务起始就要限定边界，而不是先做工作，工作都做了再限定边界。

通过这么小一个需求，让AI的问题逐步暴漏出来，避免更多的反反复复讨论而无法确定的问题持续发生，这也是本需求乃至AI嵌入交付式需求的初心。

一个审批人替换需求，为什么把AI逼得反复跑偏？

人工智能

AI商旅审批流开发中常因任务切片臃肿、参数传递混乱导致需求偏离，如审批人查询结果集缺失或借调公司数据异常。本文通过具体案例复盘AI从“跑偏”到“纠偏”过程，揭示核心解法：以人员ID为查询收口参数，小步快跑精准限定任务边界，避免工具过度引入，确保AI编码回归真实业务需求。

微服务架构

数据同步

大数据

服务器

Hadoop 

Kafka

MySQL

Redis

Hive

Java

让每一个 Agent，都跑在云上

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

一个审批人替换需求，为什么把AI逼得反复跑偏？

一个审批人替换需求，为什么把AI逼得反复跑偏？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐