一、复盘背景与AI开发整体感知
本次复盘时间为版本割接日，全天工作围绕版本开发、界面调色及配套材料准备展开。
近期使用AI辅助开发的过程中，有明显感知：AI虽然提升了开发效率，但也让原本可做可不做、耗时较高的优化项被提上日程。比如借助AI开发速度变快后，会倾向于把功能做得更完善、更稳定，甚至提前实现原本规划在未来的功能，反而导致整体投入的时间越来越多——因为需求调整、开发、调测、测试的全链路较长，并非AI生成代码后就能直接投入使用。
二、AI使用实践、现存问题与局限
我目前养成了一个习惯：无论AI生成的代码质量好坏，都必须逐行过审。AI产出的代码越多，需要的评审时间就越长，因此我一直坚持小步快走的策略：针对单个功能提小优化需求，AI输出后立刻评审，不会把大型需求直接丢给AI从零实现。毕竟作为功能主责人，AI只是辅助工具，必须确保所有功能都在自己的掌控范围内，避免出现未知的漏洞或隐患。在逐次代码审查的过程中，也能同步了解AI的实现逻辑，提前排查潜在风险。
今天用AI完成了三四轮开发，其中几轮就发现AI存在考虑不周全的问题：按AI的逻辑调整代码后，表面看代码没有问题，但实际业务效果与预期存在偏差，可见完全把工作交给AI是不可行的。 最近很多文章都提到“认知负担”的话题：AI生成代码的速度越快，开发者的认知负担反而越重。因为需要花大量时间思考AI的实现逻辑、排查潜在问题，简单代码可以快速过审，但涉及复杂业务逻辑时，必须仔细推敲，不能仅以“AI确认可行、测试用例通过”为验收标准。
当前存在的核心问题是：现有测试用例只能验证代码能否正常运行，无法确认功能是否符合实际业务需求。如果能让生成的测试用例匹配真实业务流程，才能有效发现问题；否则生成代码越多，越难保障最终产出的可用性。
也有人提出“用AI打败AI”的思路，即用另一个AI做代码评审，但这依然无法解决业务漏洞的问题：AI只能排查通用性问题、通用漏洞，无法从代码层面识别业务缺陷——比如某个字段未设置特定值导致的业务逻辑错误，这类问题需要结合需求文档、业务逻辑、历史旧业务文档才能判断，而这类业务知识目前还没有被AI有效掌握。
三、业务实践现实与AI能力边界
如果能搭建完善的知识库，向AI输入表模型、表定义、枚举值、表间关联关系、业务规则、业务诉求等信息，AI才有可能识别这类业务问题。但从零搭建底层业务知识库的成本极高，目前来看，AI只是提升了开发速度，反而带来了更大的压力：一方面是职业焦虑，担心被AI优化；另一方面AI产码速度快，倒逼开发者承担更多额外工作。
在实际业务工程实践中，代码开发的时间仅占30%-40%，剩下的时间都用在需求澄清、需求确认、业务测试、链路打通等环节，这些工作依然占据大量精力。
现有代码大模型的能力已经比较成熟，生成的普通增删改查类代码大多可直接使用，这类工作确实可以被AI替代，但仅限这部分内容。目前很多团队都在探索方向：沉淀领域/业务模型，由经验丰富的成员抽象沉淀业务经验，让AI基于现有业务做适配，这是很好的思路，我们也正在打磨这套方案。
四、AI时代的竞争力与行动准则
从零开发的产品，哪怕用AI快速生成了初版，好不好用、稳不稳定，依然需要经过多轮打磨，要深入了解业务痛点、用户真实诉求——这些是AI从零开始无法知道的。从管理者视角来看，产品从零到一落地后，后续的维护、扩展能力才是更需要思考的问题，这非常考验开发者的综合素质：要站在架构师的角度思考代码的复用性、可扩展性，能否支撑后续业务迭代。AI能力的提升会放大个人能力的差异：能力越强，越能产出优质产品；如果只会简单照搬修改、没有独立思考和业务诉求判断，很容易被淘汰。
所以在我看来，这个时代不变的准则是持续学习与自我精进，不能坐吃山空，要不断扩充能力边界，将新知识融入自身知识体系。无论身处哪个业务领域，除业务能力外，综合素质（包括思考方式、沟通能力等）都是核心竞争力。尽管当下社会氛围浮躁，但做好自我磨练、持续精进，在任何时代都是最重要的。
