AI 编程的讨论常年在两个极端之间摇摆：要么「程序员要失业了」，要么「AI 写的代码根本不能用」。作为每天和它协作的团队，我们记录了整整一个月的真实使用数据——补全、生成、评审、提交四个阶段，各做对了什么、又在哪里掉链子。
阶段一：补全——最成熟，也最安静
行级与函数级补全是体验最成熟的能力：写下一行注释或半个函数名，合适的实现就出现在光标后。它不惊艳，但每天都在节省击键——我们团队的接受率稳定在 30% 到 40%，被接受的部分几乎不需要修改。这一层的正确用法是「思路在你、击键给它」：先想清楚函数签名和边界条件，再让 AI 完成模板化的部分。
阶段二：生成——适合从零开始，不适合猜心思
模块级生成的成败几乎完全取决于需求描述的精度。实测规律：输入是一段清晰的功能描述加接口约定时，首版可用率约七成；输入是一句模糊的「帮我实现个登录功能」时，产出往往方向全错。和 AI 协作像带一个执行力极强但完全没有背景的工程师——把上下文、约束条件、验收标准交代清楚，是一笔高回报的投资。
阶段三：评审——查得比人快，判得比人浅
让 AI 参与代码评审，优势在覆盖面：空指针风险、资源未释放、边界遗漏、命名不一致，它几乎不会漏。局限在深度：涉及业务语义的权衡（这个重试次数是否合理、这个埋点有没有破坏幂等）仍需人来判断。我们的流程是 AI 先过一遍存量问题、人再审增量逻辑——评审意见的密度上去了，人工聚焦在真正需要判断的地方。
阶段四：提交 PR——用可以，签名得是你
Agent 形态的助手已经能把「提一个修复」的任务跑到 PR 阶段：读 issue、改代码、跑测试、发起合并请求。实测在边界清晰的修复类任务上效率惊人，但团队必须守住三条纪律：改动范围写死在任务里（防止它顺手重构）；CI 与测试覆盖率是硬闸门；PR 描述必须注明 AI 参与（便于追溯与学习）。最终合入的每一行代码，责任仍然在人。
一个月的量化结论
我们记录了两组数字：常规开发任务的平均耗时下降约三成；但代码评审的耗时略有上升——因为生成的代码变多了。结论不是「效率翻倍」这种夸张叙事，而是——AI 把「写」的成本压低了，把「读、审、想」的价值放大了。开发者的核心竞争力正在向需求拆解与质量判断迁移，这恰是 AI 短期内替代不了的部分。
模型训练与适配的路线选择见《大模型微调怎么选》；任务化 Agent 的工程要点见《AI 智能体落地五道关》；研发效能工具链合作欢迎通过联系合作交流。