允许非技术人员直接提交代码，是效率飞跃还是技术债陷阱？

最近我们团队尝试了一套极其激进的 AI 驱动工作流：允许产品、设计和运营等非技术人员直接通过 Cursor 向代码库提交 PR。起初，我们认为这能彻底打破传统“需求传递”中反复确认的低效，但实际运行一段时间后发现，这种模式在制造“可见进度”假象的同时，给工程质量带来了巨大的压力。

最直接的症状就是 Review 环节的彻底崩溃。在我们目前“1 周规划 + 6 周开发”的周期里，非工程师利用 Slack 里的 Cursor 插件可以极速生成代码并提交，导致 PR 数量呈指数级增长。对于资深工程师而言，现在的状态非常诡异：写核心逻辑的时间在减少，而花在 Review 那些“看起来能跑但缺乏架构思考”的代码上的时间在剧增。很多提交上来的代码虽然通过了基础测试，但完全没有考虑可维护性和扩展性。

为了追求极致的速度，我们甚至尝试省掉了 PRD 和系统设计文档，构建了一套看似很“未来”的链路：会议录音 → 转文字 → Agent 自动生成任务描述 → 直接写代码。然而，这种链路导致了严重的“设计断裂”。最典型的例子是 UI 组件的失控。以前 Figma 是唯一的真理，但现在设计师过度依赖 Claude Design 快速出图，生成的 UI 代码与我们现有的组件库完全脱节。很多 PR 在视觉上实现了还原，但内部实现却是大量重复的硬编码样式，完全无视了组件复用性。为了解决这个问题，我们目前正考虑将编辑器从 Cursor 迁移到 Claude Code，试图在上下文感知和代码一致性上寻找更好的方案。

此外，基础设施的压力也随之而来。为了配合高频提交，我们尝试为每个 PR 自动生成临时测试环境，但在实际操作中，部署环节极其不稳定，频繁出现卡死或环境冲突的情况，这让原本想通过 AI 提速的流程在部署环节卡了脖子。

最让我焦虑的是，团队在习惯了 AI 的快速迭代后，竟然丢掉了最基础的容量规划（Capacity Planning）。因为每个人都能快速出 Demo，每天的站会渐渐变成了“Demo 秀”，大家在快速反馈中产生了一种“进度飞快”的错觉。但到了项目后期，由于缺乏前期的深度设计和容量预估，不可控的波动开始集中爆发，大量潜在的技术债在交付前最后一周才被集中发现。

这次尝试让我意识到，这种模式本质上是在用“沟通成本”交换“开发速度”。如果团队没有一套极强的、强制性的 Review 机制，允许非工程师提交代码大概率会变成一个高效的“技术债制造机”。

如果你也打算尝试这种 AI 驱动的去中心化开发，我的建议是：千万不要轻易丢掉设计文档，且必须给 Review 环节预留出双倍的时间，否则你省掉的沟通时间，最终都会在项目收尾阶段以“修 Bug”的形式成倍偿还。