YouMind CTO 亲述：AI Coding 提效后，产研协作为何几近崩盘

在 2026 奇点智能产品大会上，YouMind 联合创始人兼 CTO 杨森（双扬）以「自揭家丑」的方式，讲述了其团队在过去一年全面拥抱 AI Coding 后所经历的混乱与反思。这家 2024 年成立的 to C AI SaaS 公司，从成立第一天起就在 GitHub Copilot、Claude Code、Codex 等工具加持下作业，工程师交付效率相对前 AI Coding 时代提升 10 倍甚至百倍。然而，效率的跃升并没有带来秩序，反而撕开了产品与研发之间、以及研发内部原本脆弱的协作平衡。

工程师越来越快，产品经理越来越迷茫

效率提升后，工程师能交付的东西不一样了。过去一个想法要先评估、写 PRD、评审、排期才能落地；现在工程师花 30 分钟到 1 小时就能跑出一个 Demo，直接对着 Demo 讨论。在不到 10 人启动的 YouMind，甚至出现过工程师自己花一周时间把移动端做出来上线的案例——产品经理没空设计、工程师直接交付产品。

这一变化看似美好，但很快暴露出代价。

50 万行代码的 PR 与百万行代码库

杨森展示了一个近期合并的 PR：单工程师产出 50 万行代码变更，没有人 Review，也「没办法 Review」。他统计了 YouMind 当前的代码仓库：

有效代码（剔除文档、migration 等）超过 100 万行；
近半年内「同时编辑同一文件」的情况显著下降，协作率明显下滑；
增删比从约 1.8 升至 3，工程师更倾向于「堆代码」而非清理。

结果就是无效 Context 急剧膨胀。100 万行代码折算到 Token 量级约 1000 万，远超任何 Coding Agent 一次能读完的窗口。工程师之间也不再协作——每个人领一个 Issue，让 Agent 把事做完、提 PR、通过验证就结束，没人关心原有实现、代码复用与一致性。

一次静默的 Agent 性能退化

更棘手的是 5 月份出现的一次 Agent 分数缓慢下降。日志没报错、代码没 Crash、模型没降智。最终杨森把所有工程师拉进会议室，关上电脑，一起读线上 Runtime 拼装出来的几万字 System Prompt，才发现问题：主角色定义、工具描述、安全隔离等不同模块各自合理，但拼在一起后出现了一段「可以编辑某文件」与另一段「该文件不能编辑」的矛盾描述，Agent 因此行为偏离。

杨森认为，根本原因在于：

百万行 monorepo 的代码体量远超任何 SOTA 模型的单次 Context 窗口；
Coding Agent 基于成本与算力考虑，不会主动做冗余校验；
没有人在看全局，每个模块的 Agent 只优化自己名下的 Issue。

解决方案：给工程师套 Harness

杨森的应对思路是「该快的地方继续快，该拉紧的地方要拉紧」：

影响面小、可快速迭代、出错可快速回滚的部分，交给工程师 solo；
登录鉴权、订阅注册、安全相关的核心模块，设置 Code Owners，强制指定人 Review 后才能合入主干；
把研发团队的管理视作「给工程师套 Harness」的过程。

万字长文回复与产研信任崩塌

产研之间的问题同样尖锐。原来瀑布流式的需求—设计—研发流程被「快速 ship 一版」取代。然而新的协作工具链又带来新问题：

产品经理在 Linear 提一个 Issue，工程师让 Claude Code 调研后回复一篇万字长文，涵盖背景、数据、竞争分析；
这段文字到底是工程师本人的判断，还是 AI 的输出？越来越难分辨；
曾出现研发贴出分析、细看却与事实不符、最后回一句「对不起，是我的 AI 写的，我也没细看」的尴尬场面；
Linear Activity 数据显示，大家高度依赖 AI 回复的时段，Issue 讨论热度急剧下降——「你用 AI 敷衍我，这事聊不下去了」。

YouMind 后来立了一条规矩：可以用 AI draft 回复，但必须在回复最前面手动写一段 TL;DR，明确说明哪些是自己判断过的、哪些是自己不知道的。否则就变成「AI 对喷」。

设计还原：仍未解决的硬骨头

最后一类问题是 Coding Agent 对设计稿的精确还原能力仍有明显短板，圆角、阴影、过渡效果等细节无法一键驱动 Agent 实现。工程师用 best effort 做、产品经理不满意，battle 不断。杨森坦言，在真正 AI Native 的设计产品出现之前，工程师暂时还得在还原设计稿这件事上与产品经理「拉扯」。

演讲的最后，杨森没有给出终极答案，但他反复强调的核心判断是：AI Coding 提效不会自动带来更好的产品与团队，反而把原本被流程掩盖的协作问题放大了。产研之间、工程师之间、以及人与 Agent 之间的信任与边界，正成为 AI 时代每一个技术团队必须重新回答的问题。