一个 PR，50 万行代码变更，一个工程师独立完成，没有人 Review——因为根本没法 Review。

一次静默的 Agent 性能退化，查日志没报错，查代码没 Crash，查模型没降智——最后把所有工程师拉到会议室，关上电脑一起读 System Prompt，才发现两段描述是矛盾的。

产品经理在 Linear 里提了个 Issue，工程师让 Claude Code 调研了一下，回复了一篇万字长文。然后这个事就没法继续了——你不知道他写的这些话里，有多少是他自己的判断。

这些不是假设，是一家 AI 创业公司在过去一年里真实经历的混乱。讲出这些故事的人叫双扬，YouMind 联合创始人 & CTO。

7 月 18 日，北京，2026 奇点智能产品大会。双扬是为数不多的以 CTO 身份登台的分享嘉宾，面对满场产品人，他坦言心里有点压力。最终他选择了一个角度：AI 原生工程团队的工作模式。这恰好是当前产研协作最痛的问题——效率提升了，然后呢？程序员越来越快，产品经理越来越迷茫，边界模糊，信任和流程正在被撕裂。双扬作为亲历者，毫不避讳地自揭家丑，把踩过的坑、反思与解法一一摊开。现场反响热烈，提问环节几乎停不下来。显然，在 AI 提效的大背景下，这是整个行业共同面对的问题。

以下是双扬的演讲实录。

双扬，YouMind 联合创始人 & CTO

最近一年，大家团队的工程师交付效率到底有没有提升？

先问一个问题：在座的产品朋友们，你们觉得团队里的工程师，最近一年交付效率提升了吗？有人点头。那有没有觉得他们开始“越俎代庖”了？好像什么事不经过产品就能自己干了？

这其实是我们公司也遇到过的现象，甚至一度引发了产研矛盾——产品经理直接开怼：“你这瞎搞什么？”但后来，我们找到了解决路径。

首先，效率的提升是实打实的。我们是一家 to C 的 AI SaaS 公司，2024 年成立，那时候还没有 Claude Code 和 Codex。从第一天起，我们就全面拥抱了 GitHub Copilot。严格来说，最近一年效率可能只提升了 2-3 倍，但跟前 AI Coding 时代相比，10 倍、百倍的提升是有的。

效率提升后，工程师能交付的东西变了。过去在大厂，产品经理有个想法，得先评估技术可行性、工期、风险，然后拆解、写 PRD、讨论、开会、评审，最后才能实现。现在呢？工程师说：“我先给你做个 Demo。”可能花 30 分钟到 1 小时，Demo 就跑出来了。大家直接对着 Demo 聊——这东西能不能做，怎么融入，有什么问题，跟现有系统有没有冲突。讨论成本变低，沟通对象也变得更直观。

在我们创业公司里，流程没那么僵化，程序员甚至可以直接交付“产品”了。

公司启动时不到 10 个人。有位工程师特别想在手机上用我们的产品，能跟 Agent 聊、做创作。但当时我们只有两个产品经理，要兼顾注册、转化、增长等大流程，实在没精力重新设计一个全新的移动端产品。工程师说：“要不我先自己做一版？”

可能就花了一周，移动端就上线了。这个变化意味着什么？当决策成本不高、实现成本极低时，程序员完全可以先交付一个 idea，再去看用户反馈、使用频率、遇到什么问题。

听起来太美好了——程序员效率百倍提升，想法马上上线，代码疯狂 ship。但现实真的这么美好吗？

50 万行代码变更，一个工程师写的，没人 Review

在座有技术背景的同事应该能感受到这个数字的分量——这是我们最近刚提交的一个 PR，50 万行代码变更，一个工程师独立完成，没人 Review，因为根本没法 Review。

这就是一种又喜又悲的感受。作为老板或产品，可能觉得“哇，这个程序员太厉害了，一个人做了个大重构”。但作为 CTO，我看到的是：这东西靠谱吗？

这是效率提升后，研发内部遇到的第一个困境——大家疯狂 ship 代码，但没人关注背后到底发生了什么。

另一个视角：我最近跑了一次代码仓库统计。整个 YouMind 产品的有效代码（排除文档、迁移）已超过 100 万行。过去半年，一个非常明显的变化是：很少有人同时编辑同一个文件了。大家都在写自己的文件，遇到需求就新开一个模块，不会去动别人写过的代码。协作率在明显下降。

同时，增删比也在明显上升。增删比是衡量代码整洁度的指标，指每增加一行代码会删除多少行。原来每增加 1.8 行会删除 1 行，现在是每增加 3 行才删除 1 行。大家疯狂往代码库里堆东西，堆得越多，Context 越大，但很多都是无效的。虽然现在模型的 Context Window 很大，但 100 万行代码对应的 Token 可能是 10 个 Million，无效 Context 很容易撑爆 Agent。

工程师之间也不怎么协作了。今年年初大家还经常合作，核心模块（登录、鉴权、订阅、积分）总有人会碰到。但到今年 4、5 月，大家都不碰了。为什么？工程师领到一个 Issue，他的 Agent 做完事，提个 PR，验证通过，就结束了。为什么要管原有的实现？为什么要复用代码？为什么要保持一致性？这些问题都被忽略了。

研发效率 10 倍提升之后，研发内部首先变“独立”了，变成了孤军奋战。

“问题实在查不出来，我做了一件很挫的事”

是什么时候让我觉得这事不对劲呢？一次静默的 Agent 性能退化。

我们是 AI SaaS 公司，有一套 Eval 评分系统，一直在评测 Agent 表现。5 月份，分数突然开始缓慢下降，不是陡降，是缓慢下降。用户也开始抱怨，说 Agent 回复效果不好，做 PPT 或写文档时偶尔会犯错。

查日志，没报错；查代码，没 Crash；查模型，没降智。一开始怀疑是不是哪家模型偷偷降智了，但没看到同期有其他反馈，模型参数和 Thinking Effort 也没变。审查最近的代码提交 PR，改动看起来也没什么问题。

最后实在查不出来，我做了一件很挫的事——把所有工程师拉到会议室，让大家一起来读最终生成的 System Prompt 和 Tool Description。关上电脑，看线上 Runtime 生成的 System Prompt 到底对不对。

一读就发现问题了：System Prompt 里有两段描述是矛盾的。前面说“你可以编辑什么什么文件”，下面某个模块里又说“这个文件不能编辑”。Agent 自然就困惑了，到底能不能编辑？不够清晰的 Prompt 导致了行为偏离。

为什么会这样？我们的 System Prompt 代码是模块化的，最终可能几万字的 Prompt 由不同模块拼成——主角色定义、工具、安全隔离、防注入、防越狱。每个模块内部看都合理，但拼在一起就出问题了。

可能有人会问：现在 Claude Code、Codex 这么强，为什么还会发生这种事？原因很简单：我们的代码库有 100 多万行，是一个很大的 monorepo，哪怕是最强的模型，一次性也读不完所有代码。受限于 Context Window 和推理算力，很多 Coding Agent 在执行任务时，也不会倾向于做冗余检查。比如，给它一个指令说“有用户用 Prompt 注入攻破了我们的系统，你要保护一下”，它就会去改安全隔离模块，加一段描述防止注入。站在它单点的视角，问题解决了，看似完美。但没人看到，在 System Prompt 的另一处，还有一段冲突的描述。

这就是协作时代，大家交付很快、很独立之后带来的问题——没人看全局，只顾着解决自己名下的 Issue。

“工程师给 Agent 套 Harness，我给工程师套 Harness”

这个问题怎么解决？思路是：该快的地方还是可以快，该拉紧的地方要拉紧。不可能因为担心出错就把工程师限制住。某种程度上，研发团队的管理也是在套 Harness。工程师给 Agent 套 Harness，技术管理者给工程师套 Harness。

怎么套？影响面小、可以快速迭代、不容易出错、哪怕出错也能快速修复的，交给工程师快速去飞、去 solo。但另一方面，该拉紧的地方必须拉紧——核心模块，如登录鉴权、订阅注册、涉及安全问题的，一旦出问题会造成不可逆损伤的，坚决要限制住，不允许飞太快，要慢下来，大家一起讨论、共同决策后才能变更。

我们在 GitHub 里加了 Code Owners。如果改动涉及这些模块，必须有指定的人 Review 通过才能合入主干分支。这是一个很简单的技术操作，但确保了在效率提升 10 倍、百倍之后，关键闸门依然能拉住。

“你提个 Issue，有人回复万字长文，这事就没法继续了”

研发内部的问题有了策略，但产研之间呢？

原来我们是一套标准的瀑布流式开发——需求迭代、设计师设计、研发验收。现在很多时候会快速 ship 一版。比如订阅按钮的弹出时机，线上数据不好，就快速换个位置或形式，让产品经理真实体验一下，看看数据，快速决策调整。不需要对着空的东西聊，也不用对着假设聊，因为实现成本极低。

听起来也很好，但问题也不少。

第一个问题：我们内部用 Linear 协作，产品经理提了一个 Issue 说“我们做这个事吧”。工程师会干什么？他让他的 Claude Code 去调研一下，回复了一个千字甚至万字长文在 Issue 里。然后，这事就没法继续了——你提个 Issue 说做 ABC，有人回复了万字长文，什么背景、数据、叙事、竞争分析都有。但问题在于：你不知道他写的这些话里，有多少是他自己的思考和判断，有多少是 AI 的输出。人与人之间的交流没了，你都不确定他贴的这段话到底代表不代表他的意思。

我们之前出现过这种情况：产品经理提个 Issue 说“这怎么有问题”，研发贴了一段分析回复。细看发现不是那么回事，研发说“哦对不起，是我的 AI 写的，我也没细看”。连基本的信任都没了。

好处是，你提个 Issue，可能半小时就有回复，但回复是 AI 写的。

后来我们怎么做的？如果你要用 AI 去 draft 回复，可以写千字长文，但必须在回复最前面手动写一段 TL;DR——你自己的总结是什么，哪些事是你判断过的，哪些事你不知道。要把交流的背景交代清楚。否则就变成 AI 对喷了——产品经理也会用 Codex 和 Claude Code，你发千字长文，我让我的 AI 总结一下再回复你，全公司都变成 AI 驱动做事了。

我们观察过 Linear 的 Activity 数据，有一段时间大家非常依赖 AI 回复时，整个 Issue 讨论的热度急剧下降。因为没法聊了——我真心实意提了个问题，你用 AI 敷衍我，这事还怎么继续？

让设计师直接去提 PR

第二个问题：时至今日，Coding Agent 对设计稿的精确还原仍有很大差距。对于有产品设计介入的功能模块，工程师想完美还原视觉设计，很难一键驱动 Agent 实现，尤其涉及过渡效果、阴影等。虽然 Figma 有各种插件，但无法做到完全还原。

工程师已经习惯了“来一个 Issue，交给 AI 写完我验收”，但在设计场景做不到。做不到之后，程序员用自己的 best effort 去做，产品设计就不满意了——“我花了这么多时间做漂亮的圆角阴影，你居然不给我实现？”于是 battle 就来了。

我们怎么解决？首先承认现实：Coding Agent 对设计稿的还原确实有技术限制。我们也很期待有真正 AI Native 的设计产品出现，把工程师从还原设计稿的工作中解脱出来。但在此之前，解法是——让设计师直接去提 PR。

我们给所有产品设计师都开了 Codex 和 Claude Code 的席位，帮他们配置好环境。对于设计师觉得没有完全还原设计意图的功能，直接教他们怎么“口喷”改代码。口喷完马上在本地电脑上看到效果，改到满意了就提个 PR，让工程师看看有没有大问题，没问题就 ship。

这解决了产研之间关于设计细节还原的矛盾。当然，这个改动也和之前的指导原则相关——影响面不大或独立的模块可以这么干，核心模块、影响用户转化和订阅的，还是会有严谨的设计流程。

产品经理从设计页面，转向设计 AI 的行为

当研发交付能力提升、实现成本变低时，产品经理会有点迷茫，不知道该干什么。出现过一个问题：有些功能模块让工程师先交付上线，出现问题再找产品设计介入优化。但人的天性是不愿意接别人的烂摊子——工程师先用 AI 做了个很糙的实现，然后找产品经理说“你来看看怎么优化”，产品经理是很抗拒的。

怎么办？一方面，尽量减少工程实现和产品设计意图的差距，比如做一些 design.md 的设计，去指导 Coding Agent 尽量还原产品设计规范。另一方面，产品经理确实应该从设计表单、按钮、弹窗这些事中解放出来。在 AI SaaS 公司里，他们应该做别的事。

比如，我们已有产品经理开始转型做 skill 的设计。我们的产品 YouMind 是一个创作工具，核心能力是利用各种 skill 帮用户做 PPT、绘图、做视频、发小红书、发微信公众号等。产品经理的工作从设计表单交互，变成了设计一个 skill——这个 skill 怎么帮你做出更好看的 PPT，怎么拆解你的意图。这既复用了他对用户输入和最终实现之间 gap 的理解，也复用了他对用户需求的拆解思路。但最后沉淀的产物不再是 UI 界面，而是一个个 skill。

另一方面，产品经理也从看各种交互细节，变成了去看 Eval 系统里的 bad case。当用户对某个交互流程不满意、在对话系统里点踩时，更多是产品经理去看——为什么用户不满意？是对产物不满意，还是对对话过程 Agent 提供的信息不满意，还是给的选项不够好？

总体来看，产品经理从原来的“设计页面”，逐渐转向了“设计 AI 的行为”。这是一个很有意思的转变。

如果这个“loop”里没人了，那到底谁需要 AI？

最后还有一个事。从技术上说，Agent 是可以自我进化、自我学习的。只要有一套客观的评测系统，看到有人点踩、觉得是 bad response，完全可以让 Agent 去分析对话记录、看 System Prompt 设计，改一下就能把效果迭代好。

但我们没有这么干。因为我们认为，Agent 行为要不要这么做，遇到这种 case 时要不要改，是需要人介入的。并不是因为你点踩我不满意，就要去改这个行为。这里面体现了我们的产品价值观。

所以我们不再那么强调“一切自动化”，不再以提效为唯一核心目标，而是去想：我们到底要做出一个什么样的 AI 产品？一定要在中间强插一个 Human Decision 的节点。

这其实也是我们整个工程团队实践、公司运作机制、以及产品本身的一个实践体现。Human in the loop，大家都听腻了。很多人讲的是怎么把 human 从这个 loop 里干掉，以后不需要 human 了。但我们的价值观更多是：怎么强化 human 在 loop 中的作用。因为每一个 human 都有他的价值观、审美、品味、判断、经验，这些是我们认为能提升 AI 产品效果、提升人和 AI 之间沟通上限的关键。所以，我们一定很强调 human 在过程中的作用。

如果这个 loop 里没人了，那到底谁需要 AI？

“我们给 Agent 发工资”

演讲结束后进入 Q&A 环节，现场提问一个比一个尖锐。

有人问到 KPI 导向的变化——AI 产出井喷，核心角色职能也在变化，怎么牵引大家做更有效的产出？

双扬答：说实话，我们公司没有 KPI，但有一些指导原则。我们的策略是鼓励大家“养 Agent”。我们会给员工养的 Agent 发工资。

比如，我们现在有一个 Agent，一个月给它发 2000 块钱，它负责解决 Linear Issue 的 Triage（分诊）。每天有很多 Issue 进来，有用户反馈、内部建议、其他 Agent 发现的 Bug。这个 Agent 会做预检——如果是用户提的 Issue，它会看用户账户状态、订阅状态、线上有没有报错、之前咨询了什么，然后给出预检报告。这样，人类在处理 Issue 时已经有预回复好的 Context，效率更高。

一开始这是亏钱的。模型效果不够好时，必须用 Claude 这样的模型驱动，一个月光 Token 成本两千块钱打不住。但后来逐渐优化 Agent 效果、简化流程，加上国产模型性能提升，这个员工现在靠这个 Agent 其实是“赚钱”的——花不了两千块 Token 成本，但能把 Issue 分诊解决得很好。

我们通过这种方式，鼓励大家把自己的专业知识或看到的公司问题 Agent 化地去解决，同时给 Agent 发薪水。但不会强行要求一个月用多少 Token，那太虚了。

怎么保证合入的代码对现有功能的影响可控？

有人问了一个纯技术问题：一次 PR 50 万行，项目 100 万行，每个 Owner 对自己的代码很多都是 AI 创造的，没看过。怎么保障合入代码对现有功能的影响？包括产品或设计也能用 Claude Code 写代码提 PR，怎么 Code Review？

双扬：首先，那个 50 万行代码是个特例，本来就应该拒绝这个 PR 合入。所以，我们肯定会拒绝这种超大 PR。

其次，现在我们的代码确实百分之百都是 AI 写的，只是程度不同——有些人写但手工 Commit 手工 Push，有些人连 Push Commit 都是 AI 协作的。在这个过程中，我们会做几件事。

最重要的是线上监控。我们尝试过靠单测驱动、每次合并跑 CI，但发现在 100 万行代码规模下，单测代码本身也会腐坏——测试过时了、错了，跑一个没用的检验。所以，最重要的是看线上监控。因为有 AI Coding 之后，我们的 ship 和 DevOps 都是 AI 驱动的，一个变更可以很快合到线上，然后就有线上生产日志——有没有报错、有没有异常分支、CPU 和内存有没有飙高。这样能很快知道是不是这次变更带来了问题，有问题就尽快处理。监控是最兜底的。

产品经理提的 PR 确实有，但一般是 UI 层面变更，我们只能盲目相信他确实看过了 UI 是 OK 的。同时，也会有 Agent 定时去跑关键链路的截图，但这些是后置流程。核心模块因为卡了强 Review，一定会有一个 Harness 小组讨论为什么要做这个变更、解决哪些 bad case、跑完后 Eval 体系分数有没有下降。不同 PR 和不同场景会有不同策略。但我觉得，现在最依赖的还是线上兜底——监控和 Eval 系统评分。

“实现真的变得很 Cheap，但品味不会”

有人问到一个更深层的焦虑：产品经理做前端提 PR，跟开发做产品，有差别吗？岗位边界变得模糊了。

双扬：我一直相信，AI 时代产品经理的价值会越来越大。因为实现真的变得很 Cheap。做一个什么东西，一开始只能做前端，后来可以做小程序，甚至可以做企业级应用。实现真的很 Cheap。但需求的洞察，想法的实现方式，你的品味是什么——同样做一个记账软件，程序员做出来是什么样，产品经理做出来是什么样？

“胃之书”大家可能都听过。同样一个拍照识别卡路里的工具，技术上很简单——拍个照交给模型，模型返回 JSON 说这个多少卡那个多少卡。但就有产品经理把它做得很好、能做爆。背后是产品经理对用户需求的理解——他要的可能不是卡路里识别，而是情绪价值。这个事，大部分工程师是想不明白的。想明白之后做出来的东西充其量是个工具，很难成为成熟的商业化产品持续迭代。

但程序员也在找新东西。他们能力更强了，可以突破不同端，解决原来解决不了的事。原来工程师内部有分工——前端、服务端、客户端、算法、数据，现在大一统了。工程师在这个时代的价值是做全端解决方案，原来 touch 不到的部分也能靠 AI 实现，可以做全链路。但产品经理的特点一定是更懂用户、更懂大家到底需要什么、更懂怎么把想法更好地呈现给用户，以及后面的增长和商业化。

交付质量，而不是代码质量

有人问传统研发流程的变化——概要设计、详细设计、Coding、测试、反复修改，在 AI 时代变成什么样了？

双扬：我们现在主要依赖监控驱动。你可以快速 ship，但我要求所有可观测性必须做得非常完备。我们公司每个月花在监控上的钱是一笔很大的开支，远超普通创业公司。非常详尽的 log、非常详尽的监控指标，看每个模块运作得合不合理，花很多钱做实时看板。一个模块发上去后，它自己健壮性怎么样、稳不稳定、有没有报错，对公司各个业务指标——比如用户使用相关模块的完成率或满意率有没有波动——我们会从各种维度做归因，来判断这次代码有没有问题，有问题就快速回滚。

我们不太会做非常详尽的 Code Review，根本不会去看代码风格。只确定上线前 CI 能过、类型编译能通过、没有明显错误。其他部分更多交到上线后去保证。

有人问：传统上比较讲究代码的工程质量，现在是不是弱化了这一点，更关注最后的产品质量？

双扬：加上限定词——在 AI 创业公司，我确实更关注的是线上运行的稳定性，以及我们交付的速度与质量。

结语

这是双扬在 2026 奇点智能产品大会上的全部分享与现场问答。一个技术人站在产品人面前，没有讲方法论，没有讲宏大叙事，讲的是自揭家丑——一家 AI 创业公司真实经历的混乱、冲突与重建。效率提升 10 倍之后，研发变独了，产研信任裂了，AI 对喷取代了人的交流。他们的解法不是更多的自动化，而是在关键的地方把人拉回来。

该快的地方飞，该慢的地方拉住。这大概是 2026 年 AI 原生团队最朴素也最难做到的一件事。