AI编码工具应用的现状与问题 - 行业中出现AI编码工具能显著提升代码产出和研发效率的说法，例如“代码产出提升40%”、“研发效率翻倍”[1] - 许多团队在引入AI编码工具后，出现了代码量增加、交付速度变慢、线上问题增多以及工程师更加疲惫的负面现象[1] - 管理层在推行AI编码助手时，往往只关注代码产出速度的提升，而忽略了整个交付流程中的其他关键环节[2] 对“速度提升”的误判与约束理论 - 单纯提升写代码环节的速度是一种误判，因为写代码在软件交付流程中可能并非瓶颈环节[3] - 根据1984年提出的约束理论，每个系统都有且只有一个瓶颈，优化非瓶颈环节不仅不会让系统变快，反而可能导致系统更加“崩溃”[6][7] - 在非瓶颈环节加速，例如让A工位生产飞快而B工位（瓶颈）处理能力不变，会导致工作量暴涨、交付周期变长、优先级混乱和质量暴跌[7] AI提升代码产出后的实际困境 - 开发者提交PR的速度因AI辅助而加快，但负责Review的人数并未相应增加，导致PR开始积压，等待时间可达一天、两天甚至一周[9] - PR积压导致Review过程流于形式，代码质量下降，合并后CI流程耗时（如45分钟）且可能失败重跑[10] - 部署流程中的手动审批、会议延误等因素，导致功能在测试环境闲置多日，上线速度反而变慢[10] - 最终结果是产出了更多代码，但上线了更少的软件，周期时间（衡量向用户交付价值速度的指标）变得更差[10] - AI生成的代码可能缺乏深度理解，当线上出现Bug时，值班人员或提示编写者可能无法有效解释和修复，扩大了故障面并减少了能理解系统的人数[12] 软件交付流程中真正的瓶颈 - 真正的瓶颈需要通过分析价值流来发现，即跟踪一个功能从想法到用户使用的全过程[14] - 整个系统的吞吐量由瓶颈决定，在解决瓶颈之前，优化其他地方毫无意义[15] 需求定义不明确 - 产品开发可能缺乏与真实用户的沟通，需求定义模糊，导致工程师需要做出大量关于行为、边界和异常处理的微决策[16] - 存在团队花费6周开发一个功能，但最终客户并未购买，该功能仅有11人使用（其中9人为内部测试）的案例[16] - 在需求不明确的环境下提升代码速度，只是更快地做错事[18] 代码完成后的流程延迟 - 编写代码可能只占整个流程的20%，另外80%的时间是代码在各种队列中等待的时间[19] - 代码可能一下午就写完，但上线却花了两个月，延迟主要来自PR评审、CI、测试环境、QA、安全评审、产品验收、发布窗口和灰度发布等一系列环节的等待和排队[19] - 真正慢的环节是“等待”，而非开发本身[21] 发布恐惧症 - 许多团队因用例不稳定、可观测性差、对灰度流程缺乏信心或过往糟糕的发布经历而害怕发布[22] - 这种恐惧导致团队将变更攒成更大的发布包，但更大的包意味着更高的风险，从而形成“发布恐惧循环”[22] - 更快的代码产出会加剧这一问题，为原本就不敢上线的团队增加更多不敢上线的理由[23] 缺乏上线后反馈 - 功能上线后缺乏有效的数据分析和用户访谈，无法验证功能是否真正解决问题，导致下一个功能的开发继续基于猜测[24] - 整个产品路线图成为一连串“有根据的推测”，中间没有反馈闭环[25] - 在此环境下加快代码速度，只是让“做→上线→无所谓”的循环转得更快，无法从中学习[25] 组织协作与结构问题 - 瓶颈有时并非技术或代码问题，而是组织协作、政治和决策流程的问题[26] - 具体问题包括：需要等待会议才能做出决策；团队间缺乏沟通（如三个团队一个月未讨论接口契约）；架构师作为唯一审批人导致流程积压至少两周；季度规划耗时过长（6周），紧急需求因“不在计划内”而需额外等待（5周）[27] - AI编码工具无法解决这些组织层面的瓶颈问题[26] 提升交付效率的有效方法 - 有效的方法通常“不酷、不AI、不好卖”，但确实能解决问题[28] 分析与优化价值流 - 需要从想法到上线，一步步记录每个步骤的耗时和步骤间的等待时间，这些等待间隙是周期时间的杀手[29] 关注正确的指标 - 应关注周期时间（从提交到用户用上的时长），而非代码行数或合并PR数等错误指标[30] 减少等待状态 - 针对PR等待评审（如两天），可采取结对编程、提交更小的PR、固定评审时间等方法[31] - 针对发布需要手动审批，应推动自动化或简化为Slack按钮操作，减少对会议的依赖[31] - 针对决策依赖开会，应尝试将大决策拆分为小决策，使许多决策无需开会即可做出[31] 控制并行任务数量 - 限制在制品数量，完成3件事远比10件事都只做一半要强，并行任务会导致切换成本，消耗工程师精力[32] 倾听一线工程师意见 - 一线工程师通常清楚瓶颈所在，他们的反馈（如在站会上吐槽、在Slack发梗图）值得被倾听[33] 核心结论与竞争优势 - 真正的竞争优势不在于写代码最快的团队，这类团队反而容易被淹没在AI生成的PR队列中[35] - 能够想清楚要构建什么、能够构建出来并快速交付到用户手中的团队，才是真正成功的团队[35] - 管理层应关注并优化整个交付流程中的等待时间（例如将功能平均9天的等待时间减半），而非仅仅宣扬代码产出的提升[34] - 写代码的速度本身通常不是问题，认为它是问题的“认知与现实的差距”，才是真正的问题所在[35]