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能力的提升会放大个人能力上的差距：能力越强，越能产出优质产品；如果仅会简单地照搬修改、缺乏独立思考和对业务诉求的判断，则很容易被淘汰。
因此，在我看来，这个时代永恒不变的原则就是持续学习与自我提升，不能固步自封，必须不断拓展能力边界，将新知识融入自身知识体系。无论身处哪个业务领域，除了业务能力之外，综合素质（包括思维方式、沟通能力等）才是核心竞争力。尽管当下社会氛围浮躁，但做好自我磨练、持续精进，在任何时代都是至关重要的。
如欲追踪我更多动态，请关注我的公众号
- 文章结束 -
1、AI编码助手：潜在安全风险与可靠性考量
2、Chatterbox：轻量级开源TTS，革新语音合成效率与边界
3、AI大模型核心：Transformer架构深度解析与Hugging Face实践
4、Hermes Agent部署：集成企业微信AI助手
5、DeepWiki：革新代码理解，让GitHub仓库“开口说话”
6、突破性LLM压缩技术DFloat11：实现零精度损失、推理加速及显存优化
觉得本文有价值？请分享给更多人
点赞与在看，是对我最大的支持❤️