最近经手了一个很典型的任务：给一个已经跑了多年的收费系统，接入一种全新的第三方代扣（微信托收）能力，同时要求旧的托收渠道零改动。整个实现由 AI 编码代理承担了从设计文档到落地代码的主要工作，最终拆成 15 个任务、跑通近 90 个单元测试，但一次独立的整体评审依然揪出了 2 个会导致资金重复扣款的致命问题。这篇文章不讲这个具体渠道怎么接，只谈从这次经历里提炼出来的一套通用方法：怎么在动手写代码之前快速吃透一个陌生业务系统的具体逻辑，以及怎么把散落在几十张表、几十个类里的业务规则，收拢成一张能反复复用的数据流图。
三天，四个仓库，41 个提交，约一万行新增，给飞享IM 加了一个听起来很小的功能：把「保存到通讯录的群组」「会话置顶」「消息免打扰」同步到服务端，换设备或重装后能拉回来。这篇复盘的重点不是功能本身，而是人与 AI 的分工是怎么切的：AI 负责设计、计划、实现、审查、修复的完整闭环，人负责定产品约束、做技术裁决、在 AI 判断失灵时给出现场证据。过程中同一类缺陷在四个端上换了四种形态，被这套协同流程拦下三次、漏掉一次——漏掉的那次，恰恰最说明协同的边界在哪。
飞享 IM 桌面端（electron-vue-chat-pro）收到一条反馈：切到含超长 Markdown 表格（系统通知日报）的会话时，界面会冻结小半秒，即便每会话消息数已经限制在 50 条以内。这篇文章记录的不是"我们做了个虚拟列表"，而是从这句模糊反馈到一个可放心合并的实现之间，中间每一步该做、且没有跳过的判断——用 Claude Code 全程执行，人负责拍板方向和最终验收。
这是一篇关于「人不看代码、AI 全程执行」的真实工程记录。ios-chat-pro 是飞享 IM 的 iOS 原生客户端，用 Swift + UIKit 实现，对接自研 TCP 协议和 protobuf 二进制消息，功能覆盖单聊、群聊、音视频通话、好友管理、群组管理、消息撤回。
