这半年我一直在做一件事把AI当成项目技能的陪练来用而不是当成代码生成器。带团队接项目的时候经常遇到新人问这个该怎么写但很少有人问这个改动会影响哪些模块上线失败了怎么回滚。后者才是项目技能。前两篇聊了让AI帮我们做需求分析和制定学习路线这篇想聊聊怎么用AI练判断力——也就是拆解任务、审查代码、做技术决策、做项目复盘这些真正值钱的软技能。适合那些已经会用AI写代码、但总觉得进步不够快的人。如果你也处于AI输出我能看懂但遇到新项目还是不知道怎么下手的阶段这篇的内容应该能帮你找到一条更实在的练习路径。1. 先搞清楚向AI学项目技能到底学什么我知道很多人会觉得项目技能这个词有点虚。你打开招聘JD上面写着熟悉Spring Cloud掌握Kubernetes好像这些技术栈就是项目技能。但真正做过项目的人都有体会你会用某框架和你能在项目中把这个框架用对是两码事。项目技能的核心是判断力面对一堆含糊的需求知道先做什么面对一个老代码库知道改动会影响哪几个模块面对两个方案知道该牺牲什么保住什么。AI恰恰是训练判断力最好的工具因为它有足够广的知识又愿意陪你反复推演。关键是你得换个问法。1.1 项目技能不是会某样工具而是能做出判断我举个例子。一个朋友接手了一个内部后台系统需求是加一个批量导出Excel功能。他上来就用AI生成了一段导出代码粘进去跑了一下能跑通但测试环境一压测就内存溢出。后来他跟AI对话时才意识到这个后台本来就有定时任务在跑大量数据导出功能如果直接在主线程里同步处理会把内存直接打爆。AI其实在第一轮回答里就提醒过注意数据量大时的内存峰值只是他根本没把这句话当回事。这件事让我印象很深工具能力是会用AI写代码项目技能是能从AI的输出里识别出哪些点会变成项目的坑。前者问帮我写后者问我要改这个老系统帮我列出所有可能被影响的地方以及每个地方的风险等级。这两种提问练出来的东西完全不一样。1.2 从问怎么做升级到问为什么很多人用AI是当一个快速答案机我也一样。但后来我发现如果想让AI帮自己长本事就得强制它输出理由而不是结果。我现在的默认Prompt会让AI先别给代码而是解释方案的决策逻辑。比如我在做一个订单中心技术栈是Java Spring Boot数据库用MySQL目前有一个比较老的库存扣减逻辑用的是同步事务。我要改成先扣减库存再异步通知请先别给我写代码帮我分析这个方案的关键决策点为什么异步通知是合理的不这么改造的话代价是什么如果要改造哪些地方最容易被忽略这样问出来的答案里代码反而是次要的决策树才是重点。AI会告诉你同步事务在大流量下会锁竞争激烈但异步通知会带来最终一致性问题你需要补偿机制。你看每条信息都对应一个项目里真实存在的坑。把这些坑记住下一次遇到类似场景你就能提前判断该怎么设计了。2. 把AI当成能挑刺的代码审查员如果说上一部分是学决策这一部分是学审查。我自己带过几个项目发现大部分团队最缺的不是写代码的人而是会说这么写有问题的人。但没有资深同事可以随时帮你review的时候AI其实能顶上一个很不错的审查者。2.1 让AI挑毛病比让AI写代码更值钱为什么这么说AI写代码你拿到的是一段看起来能跑的产物你大概率不会去追问它为什么这么写。但AI审你的代码你得先把代码梳理清楚、把上下文交代明白这个过程本身就是一次高质量的技术表达训练。更重要的是AI的审查意见通常带着理由它会说第X行这里用了全局锁在高并发下会成为瓶颈建议换成乐观锁这句话比100段代码都更能提高你的项目敏感度。我自己现在写核心代码写完第一遍不会马上提交而是先把代码丢给AI做一轮恶意审查。我告诉它你要用最挑剔的眼光看不要夸任何优点只输出会导致线上事故的问题。哪怕最后它只找到一个有效问题这一轮交互也值了。2.2 怎么设计Prompt才能让AI认真审查这里有一个很多人没注意的细节你直接丢一段代码说帮我看看有什么问题AI通常会给你一段总体不错但有以下几点可以优化的废话。原因是你没有给它审查的上下文和标准。我一般用这个结构你是一个有10年经验的代码审查者精通Java/Spring Boot/MySQL请审查下面这段代码。 项目背景这是一个支付回调接口要求高可用异常不能丢失QPS在高峰期接近2000。 审查要求 1. 按严重程度从高到低列出问题 2. 每个问题必须说明会引发什么具体后果 3. 给出修改建议但不要直接重写代码 4. 忽略代码风格问题只关注逻辑正确性、并发安全、资源释放、异常处理。加了背景和约束之后AI的审查质量会上一个台阶。因为它有了判断基准不是泛泛地谈可读性而是真的在项目约束下去发现问题。我也建议你在审查后追问一句如果这个问题上线后才暴露会是什么样的故障表现让AI帮你把问题变成画面。2.3 一次真实的代码审查练习我拿最近改的一个支付回调接口当例子。原来的代码是这样写的外层一个大try-catch捕获所有异常日志里打个error然后直接返回成功。当时我的想法是回调不能报错报错了供应商那边会一直重试压力太大。我把这段代码发给AI做审查它的反馈让我挺意外的。它说你这种写法是典型的吞异常防重试但你没有区分异常类型。如果网络抖动导致的超时你吞掉之后回调状态永远不更新后面用户订单会卡死如果是业务校验失败你更不应该返回成功因为那会让上游以为你已经处理了。它建议我改成网络异常返回可重试的失败码业务校验失败落库记录并人工标记只有真正处理成功了才返回成功。这几个建议后来我们上线运行了两周确实比之前稳很多。这件事给我的启发是AI审查的价值不在找出bug而在逼你先把自己的防御性思路写出来然后让AI帮你验证这种思路在极端情况下成不成立。这就是实战经验积累的过程。3. 用AI拆解开源项目把看懂变成能做很多想提升项目技能的人会去看开源项目但大多数人的体验是代码下载下来目录看了一眼就放弃了或者对着某个源码文件一行行读读完还是不知道这个项目是怎么工作的。AI能帮我们把这件事变得有效率得多。3.1 让AI给项目画地图我现在的做法是拿到一个不熟悉项目的源码之后不是自己乱翻而是先把整个项目的基本信息喂给AI。比如让AI读一下README、pom.xml或go.mod、目录结构然后让它输出一张项目的逻辑地图入口在哪里核心模块有哪些模块之间的依赖关系是什么哪些是可以独立变更的哪些是牵一发动全身的。AI不一定会给出100%准确的地图但足够让你快速建立第一版认知。有了这张地图你再去看具体代码就不会迷路。这就像你到了一个陌生城市先看地图知道哪是中心哪是郊区再决定去哪儿逛而不是一下飞机就开始乱走。3.2 让AI扮演架构师给你讲模块设计光有地图还不够。我会挑一个业务核心模块让AI用架构师的角色给我讲设计思路。比如对一个开源的订单系统我会问假设你是这个项目的架构师请解释订单模块的整体设计思路。重点说明 1. 订单状态机是怎么设计的为什么用状态机而不是一堆if判断 2. 订单创建和库存扣减之间的一致性是怎么保证的 3. 如果要在这个模块上增加一个订单改价功能你会怎么设计涉及哪些类的变更这种问法能同时练两件事一是理解别人的设计意图二是预判如果需求变化系统会怎么被改动。我第一次试的时候就发现AI给出的改价功能涉及哪些类的变更和我后来实际去看代码得出的结论高度重合。这不就是项目里最值钱的影响面评估能力吗。3.3 从拆解到重构动手改一个小功能拆解的目的不是为了看懂是为了能做。我的建议是拆完一个开源项目一定要给自己布置一个改造任务。任务不用大比如把某个接口的返回字段格式改成前端需要的风格或者给某个实体加一个索引字段。关键是你动手前先用自己的话写下我预计要改哪些文件、每个文件改什么然后再让AI验证你的预估。这种先预估、再验证的练习做上几次你会慢慢建立起对代码改动范围的直觉。因为项目里最容易被低估的部分就是我以为只改这一个小地方结果牵扯到六个模块。反复用这种方式训练你对改动范围的判断会越来越准。这个直觉就是高级工程师和初级工程师最实质的差距。4. AI陪你做技术决策建立自己的判断框架做项目总会遇到技术选型、方案取舍。这种决策通常没有标准答案比起搜到一个答案更值钱的是形成自己的判断框架。AI在这个环节能扮演一个很好的陪练。4.1 用AI做方案对比时最容易踩的坑我见到的第一个坑就是把AI当成一个投票器。比如有人直接问消息队列选RabbitMQ还是KafkaAI肯定会给你一个标准的对比列表吞吐量高、分区机制、生态丰富……但你依然不知道怎么选。因为选型不该是选最好的技术而是选最匹配当前约束的技术。正确的做法是把你手头的约束全给它现在的团队熟哪个业务是偏实时还是偏吞吐消息丢失和消息乱序哪个更不能接受有多少预算在引入AI之前我先自己把能想到的约束列出来再让AI基于这些约束做权衡。你会发现AI在这时候给出的建议明显更落地因为它不再是在回答一道开放题而是在帮你在具体条件里找最优解。4.2 让AI扮演不同技术角色的辩论赛我还有一个比较喜欢用的方法让AI同时扮演几个角色对同一个方案进行辩论。比如我要评估支付服务要不要独立拆分我会让AI分别扮演后端架构师、运维负责人、业务产品经理。架构师说独立拆分能隔离故障运维说会增加部署成本产品经理说会影响发布节奏。三个角色一轮轮发言最后我再让AI给一份共识清单。这个方法可能听起来有点花哨但实际效果很好。因为项目里的大多数决策问题本质上是不同角色的利益冲突。AI的知识面足够广它完全能模拟出不同角色的关注点帮你提前想清楚我的方案在汇报时会被哪一方挑战、我需要准备什么数据来回应。这个过程练的就是项目沟通里的预判能力。4.3 把AI的输出变成决策清单无论AI给了多少分析最后都要落到一份能执行的决策清单上。我现在每次做完方案对比都会让AI把讨论结果整理成如下格式决策项结论必须满足的条件可妥协的条件需要验证的假设回滚方案这样一张表比一长段对话有用得多。因为项目决策最终是要对团队负责的你需要交代清楚基于什么约束做了这个选择如果约束变了要怎么调整。AI给你的不是答案而是帮你把决策过程结构化。这个结构化的过程恰恰是你自己判断水平提升的证据。5. 让AI帮你做项目复盘把隐藏经验挖出来最后一个想聊的是复盘。很多项目做完之后团队就散了经验永远留在那几个人的脑子里。但如果你会向AI学习复盘可以变成一个把隐性知识变成显性知识的过程。5.1 复盘不是总结是找根因我看过很多项目复盘写来写去就是三句话工期预估不准确沟通不到位上线过程有风险。看起来写了问题实际上什么都没写。因为这不叫复盘叫记录失败。真正的复盘要回答为什么会预估不准确。AI在这里的价值是它可以当一个不客气的主持人。我会把项目的关键事件按时间线写给它然后要求它用5Why的方法逐层追问。比如为什么上线延期了AI会问因为联调多花了一周为什么联调多花了一周因为接口约定在联调期间改了三次为什么接口约定会改因为需求在开发中段又有了变化而当时的接口评审没有预留变更流程。这样追问下去根因就浮出水面了。5.2 用AI模拟如果再来一次追问到根因以后还可以再往前走一步让AI基于当时的场景模拟几个不同的决策路径。比如我会问如果当时在接口评审阶段增加一个变更冻结期后面会发生什么还有哪些风险是被这个方案忽略的AI会根据项目的常见经验帮我推演替代方案可能的成本和新的风险。这个练习的核心价值是让我不再把复盘局限在对与错上而是知道即使重来一次也不会有一个完美的选择。你需要在多个都不完美的选项里做权衡这就是真实项目的感觉。经过几次这样的模拟复盘我面对新项目时明显会多一层警觉我在入场时就会主动去问需求变更流程是谁来定义而不是等到联调阶段再被折腾。6. 向AI学习项目技能的三个原则写了这么多最后分享几条我自己踩过坑之后总结出来的原则不保证对每个人都适用但至少能帮你少走一些弯路。6.1 别让AI替你思考让AI逼你思考AI最诱惑人的地方是快。但项目技能恰恰不能快它需要在思考里沉淀。我现在的习惯是拿到AI的输出第一件事不是照着做而是先不看它的方案自己写一个方案再跟AI的方案做对比。哪怕我的方案差得要死这个对比过程也能让我看清自己差在哪。AI应该是一个逼迫你交作业的老师不是一个替你写作业的枪手。6.2 每个AI输出都要带回你的项目语境AI给的任何建议默认都是通用版不是你项目的定制版。你团队的水平、老板的耐心、历史的债务、现有的监控都是AI看不见的。所以每次拿到AI的分析我都会问自己这个建议在我的项目里会触发什么特殊情况如果回答不了我就会把项目里的约束再喂回给AI让它重新给一版。千万别把AI的建议当最终决策它只是决策的输入之一。6.3 定期让AI考考你用输出倒逼输入最后一个建议每个季度挑一个你在项目里最不自信的领域让AI出题考你。比如你可以让它模拟一个线上事故场景让你给出排查思路或者让它描述一个系统设计问题要求你用文字画出方案。这种考试比看十篇文章都管用因为输出会逼迫你把模糊的知识变成清晰的表达。我最近的一次考试是让AI扮演一个刚入职的同事让我给它讲清楚我们的定时任务为什么容易堆积讲完之后我自己都想明白了好几个之前没串起来的点。这就是我为什么坚持跟AI学项目技能的原因它不一定比资深前辈厉害但它胜在随时在线、永不嫌烦、而且敢说实话。只要你会提问、会追问、会带着项目语境去验证它就是练项目判断力最好的沙袋。