一个 PR，50 万行代码变更，一个工程师写出来的，没有人 Review——因为没办法 Review。
一次静默的 Agent 性能退化，查了日志没报错，查了代码没 Crash，查了模型没降智，最后把所有工程师拉到会议室里关上电脑一起读 System Prompt，才发现两段描述是矛盾的。
产品经理在 Linear 里提了一个 Issue，工程师让 Claude Code 调研了一下，回复了一篇万字长文。然后这个事就没法继续了——你不知道他写的这些话里，有多少是他自己的判断。
这些不是假设，是一家 AI 创业公司在过去一年里真实经历的混乱。讲出这些故事的人叫双扬，真名杨森，YouMind 联合创始人 & CTO。
7 月 18 日，北京，2026 奇点智能产品大会第二天。双扬是为数不多的 CTO 角色的分享嘉宾，面对满场的产品人，他心里是有点压力的。今年 6 月，在玉伯的支持下，我邀请双扬来奇点智能产品大会做分享，特别跟他同步了大会的用户画像——更侧重产品认知与产品构建，也分享了往届 PPT 作为参考。我建议他从 AI 原生的组织、产品与商业，或者 AI 驱动的软件生产力革命出发，分享自己及团队实实在在的思考与实践经验。几经思考，他选了一个角度：AI 原生工程团队的工作模式。
我一听就觉得好。这是当前产研协作最痛的问题，效率提升，然后呢？程序员越来越快，产品经理越来越迷茫，边界模糊，中间的信任和流程正在被撕裂。而双扬作为亲历者，对其中的痛处有着非常深刻的体会，如数家珍（尽管他用“自揭家丑”来形容）地分享他及团队踩过的坑、反思与解法。观众们对他的演讲评价很高，现场提问也是接连不断。显然，这是在 AI 提效的大背景下，我们所面临的共同问题。
以下是双扬在奇点智能产品大会上的演讲实录。
双扬，YouMind 联合创始人 & CTO
最近一年来，大家团队的工程师交付效率在提升吗？
我想先请问一下在座的朋友们，因为大部分应该是产品的角色，你们有觉得最近一年来你们团队的工程师、程序员，他们的交付效率在提升吗？
我看到有人点头。有没有觉得他们甚至开始越俎代庖了？好像什么事都不用经过产品就可以自己干了？有这样的感受吗？
这个其实是我们公司也遇到的一个非常明显的现象，甚至有一段时间都引起了产研的矛盾——产品说你这什么瞎搞？但我们可以看看后面到底是怎么解决这个问题的。
首先效率绝对是提升了。我们是一家 to C 的 AI SaaS 公司，2024 年成立，那时候还没有 Claude Code 和 Codex，最早从 GitHub Copilot 开始，公司成立第一天就全面拥抱 AI Coding。所以我们的效率如果严格来讲，最近一年可能不是 10 倍，可能只提升了两三倍，但相比于前 AI Coding 时代，10 倍百倍的提升是不止的。
在这个时候会发现效率提升之后工程师能交付的东西不一样了。过去在大厂的时候，产品经理有个想法，要让技术评估靠不靠谱，大概做多久，有没有风险，然后拆解、写 PRD、讨论、开会、评审，最后才能实现。
但现在有了个想法之后，工程师说我先给你做个 Demo，可能花 30 分钟至一个小时 Demo 跑出来了，我们直接对着 Demo 聊——这个东西能不能做，怎么融入进去，会有哪些问题，跟现在的东西有没有冲突。讨论的成本变得更低，讨论的对象也变得更直观。
甚至在我们的创业公司里面，因为流程没有那么僵化，我们的程序员可以直接交付产品了。
我们公司启动的时候大概只有不到 10 个人，有一位工程师说特别想要在手机上能用我们的产品，能跟 Agent 聊、做一些创作的事情，特别想做移动端。但那时候我们只有两个产品经理，要看整个大的流程，又要关心注册、转化、增长，没有那么多人。产品经理说我实在没时间去重新设计一个全新的端上产品，它是全新的流程、全新的界面、全新的交付。
然后工程师说：要不我先自己做一版？
可能就花了一周的时间，我们的移动端就上线了。这个变化体现在什么呢？很多时候当你的决策成本没有那么高，或者当你的实现成本非常低的时候，可能真的就程序员可以直接先去交付一个 idea，然后再去看用户的反馈，看看用户是不是喜欢、是不是在高频使用，再看他们遇到哪些阻塞。
听起来好像太好了——程序员真的效率百倍提升了，有想法马上就可以上线，大家疯狂 ship 代码。但实际上真的这么美好吗？
50 万行代码变更，一个工程师写出来的，没有人 Review
在座如果有懂技术的同事可以看到，这是我们最近刚提交的一个 PR——50 万行代码的变更。一个工程师写出来的。然后没有人 Review，因为没办法 Review。
这就是一个又喜又悲的感受。作为老板或者产品说哇这个程序员太厉害了，他自己做了一个特别大的项目重构。但作为 CTO，作为技术负责人，我看到的是：这东西靠谱吗？
这是效率提升之后在研发内部遇到的第一个困境——大家开始疯狂 ship 代码，疯狂写、疯狂发布、疯狂上线，但是没有人在看这背后到底是什么。
另一个视角，我最近跑了一次代码仓库的统计。我们现在整个 YouMind 的产品有效代码——刨除掉各种文档、migration——超过 100 多万行。过去半年里发生了一个非常明显的变化：很少有人去同时编辑同一个文件。大家都写自己的文件，需要做一个需求就新开一个模块，不会去编辑别人写过的代码。协作率在明显下降。
同时增删比也在明显上升。增删比什么意思呢？就是每增加一行代码会删多少行代码，这是程序员内部评估代码整洁度的一个指标。原来是每增加 1.8 行代码会删除一行代码，现在是每增加 3 行代码才会删除一行。
大家疯狂往代码库里堆东西，堆的东西越多，Context 就越大，但很多都是无效的 Context。虽然现在模型的 Context Window（上下文窗口）很大了，但对于 100 万行代码，Code Lines 只有一个 Million，Token 可能是 10 个 Million，无效的 Context 很容易把整个 Agent 的上下文撑爆。
不仅如此，工程师之间也不怎么协作了。今年年初大家还经常协作，一个产品里总有些核心模块——登录、鉴权、订阅、积分——不会所有人都不碰到。但到今年 4、5 月份，大家都不协作了。为什么？工程师领到的是一个 Issue，他的 Agent 把事做完了，提了一个 PR，验证了说 OK 这事就解决了。为什么要管原有的实现是怎样的？为什么要管代码有没有复用？为什么要管是不是一致？这些问题都被工程师忽略掉了。
研发效率 10 倍提升之后，研发内部首先大家就变独立了，变成了孤军奋战。
“问题实在查不出来，我就做了一件很挫的事情”
是什么时候让我觉得这事不太对劲呢？一次静默的 Agent 性能退化。
因为我们是一个 AI SaaS 公司，有一套 Eval 评分系统，一直在评测 Agent 表现怎么样。大概 5 月份有一天分数突然开始缓慢降低，也不是一下陡降，就缓慢地开始降低。用户也开始抱怨说 Agent 回复效果不好，做 PPT 或者写文档的时候偶尔会犯错。
但我们看日志没有报错，代码没有 Crash，也没有变更。一开始怀疑是不是有哪家模型偷偷降智了，但没有看到同期有其他反馈，模型参数、Thinking Effort（思考力度）也没变更。审查了最近的代码提交 PR，改动好像也没什么问题。
最后实在查不出来，我就做了一件很挫的事情——把所有工程师拉到会议室里面，让大家一起来读我们最终生成的 System Prompt 和 Tool Description。关上电脑，就来看一看线上 Runtime 生成的这个 System Prompt 到底对不对，出了什么问题。
一读很快就发现问题了：System Prompt 里有两段描述是矛盾的。前面说“你可以编辑什么什么文件”，下面某个模块里又说“这个文件不能编辑”。Agent 自然就会困惑，到底能不能编辑？不够清晰的 System Prompt 自然就导致了 Agent 行为的偏离。
为什么会发生这样的事情？我们的 System Prompt 代码是模块化的，最终可能几万字的 System Prompt 是不同模块拼出来的——主角色定义、工具、安全隔离、防注入、防越狱。不同模块在自己内部看都是合理的，但拼在一起就出问题了。
可能不知道在座的朋友会不会困惑说，现在 Claude Code、Codex 这么强了，为什么还会发生这样的问题？第一个原因是我们代码库本来就 100 多万行，是一个 monorepo 非常大，哪怕是给最强力的 SOTA 模型，它一次性读不完所有的代码。基于 Context Window 的限制以及模型推理的算力考量，很多 Coding Agent 在执行任务的时候也不会倾向于帮你做各种不必要的冗余检查。比如给它一个指令说有用户用 Prompt 注入攻破了我们的什么东西，你要保护一下。它就会去改安全隔离的模块，加一段描述防止 Prompt 注入。站在它单点的视角，这个事情非常合理，Prompt 注入问题也确实解决了，看似阖家完美。但是没有人看到在整个 System Prompt 的另一个地方，还有一段冲突的描述。
这就是协作时代大家交付很快、很独立之后带来的一个很大的问题——没有人看全局，大家只顾着解决自己名下的 Issue。
“工程师给 Agent 套 Harness，我给工程师套 Harness”
那这个问题怎么解决呢？我想到的解法是：该快的地方还是可以快，该拉紧的地方要拉紧。
不可能因为担心出错就把工程师限制住。某种程度上，研发团队的管理也是在套 Harness 的过程。我们的工程师给 Agent 套 Harness，我作为技术管理者给工程师套 Harness。
怎么套？影响面比较小的、可以快速迭代的、不容易出错的、哪怕出了错可以快速修复的，还是交给工程师快速去飞、去 solo、去快速迭代。但另一方面，该拉紧的地方还是要拉紧——核心的 Harness 模块，登录鉴权、订阅注册、涉及安全问题的、一旦出问题会造成不可逆损伤的事情，坚决要限制住，不允许飞太快，要慢下来，要大家一起讨论、共同决策之后才能做变更。
我们在 GitHub 里加了 Code Owners，如果你的改动涉及到了这些模块，你一定要有指定的人 Review 通过才能合到主干分支。这是一个很简单的技术操作，但确保了在效率提升 10 倍百倍之后，还是有一些关键的闸门能拉住，关键的限制能加上。
“你提个 Issue，有人给你回复万字长文，这个事就没法继续了”
研发内部的问题有了策略，但产研之间呢？
原来我们是一套标准的流程，瀑布流式的开发——需求迭代、设计师设计、研发验收。但现在很多时候我们真的是会快速 ship 一版。比如订阅按钮的弹出时机，我们看到线上数据不太好，就快速换一个弹出的位置或形式，快速上一版，让产品经理真实去体验一下效果好不好，看看数据对不对，就可以快速做决策和调整。不需要对着一个空的东西聊，也不需要对着假设聊，因为实现成本变得非常低了。
听起来好像也很好。但实际上也不是这样的，也有很多问题。
第一个问题：我们内部用 Linear 系统协作，产品经理提了一个 Issue 说我们做个这个事吧。然后工程师会干什么？工程师让他的 Claude Code 去调研一下，回复了一个千字/万字长文在 Issue 里面。
然后这个事就没法继续了，你们理解吗？你提个 Issue 说我们做 ABC，有人给你回复了一个千字长文甚至万字长文，什么背景、数据、叙事、竞争分析等等。
为什么会出现这种情况？你不知道他写的万字长文背后，有多少是他自己的思考，有多少是他自己的判断——都变成了 AI 的判断和输出了。这就造成一个非常严重的问题：人与人之间的交流没了，我都不知道你贴的这段话到底是不是代表你的意思。
我们之前出现过这种情况：产品或者老板提个 Issue 说这怎么有问题，研发贴了一段分析回复，我们细看一下好像不是这么回事，然后研发说“哦对不起，是我的 AI 写的，我也没细看”。连基本的信任都没了。你回复这么一大段话，又不代表你的看法、不代表你的判断，那我到底要不要仔细读呢？
好处是什么？好处就是你提个 Issue，可能半个小时就有回复。但回复不好意思，是 AI 写的。
我们后来怎么做？如果你要用 AI 去 draft 你在 Linear 或者 IM 里面的回复，你可以用 AI 写千字长文，但你必须在回复最前面手动写一段 TL;DR（太长不看）——你自己的总结是什么，哪些事情是你判断过的，哪些事情是你不知道的。要把交流的背景交代清楚。要不然就变成 AI 对喷了——因为现在我们产品经理也会用 Codex 也会用 Claude Code，你发个千字长文，那我就让我的 AI 总结一下给你回复一下，公司全变成大家用 AI 驱动做事了。
我们观察 Linear 的 Activity 数据，有一段时间大家非常依赖 AI 回复的时候，整个 Issue 讨论的热度急剧下降。因为没办法聊了——说明我真心实意提了一个问题，你用 AI 敷衍我，这事聊不下去了。
让设计师直接去提 PR
第二个问题是时至今日，Coding Agent 对于设计稿的精确还原依然有非常大的能力差距。这就导致对于一些有产品设计介入的功能模块，工程师想完美还原视觉设计，没办法一键驱动 Coding Agent 实现，尤其涉及过渡效果、阴影这些，虽然现在有 Figma 的各种插件或类似功能，但没法做到完全还原。
工程师已经习惯了“来一个 Issue，交给 AI 写完我验收就好了”，但在设计这个场景做不到。做不到之后，程序员用自己的 best effort 去做，产品设计就很不满意——我花了这么多时间给你做的这么漂亮的圆角阴影，你居然不给我实现？就会有很大的 battle 在这里。
我们怎么解决？首先要承认这个现实，Coding Agent 对于设计稿的还原确实有技术上的限制。我们也很期待有一个真正 AI Native 的设计产品出现，完全把工程师从还原设计稿的工作中解脱出来。但在这之前，解法就是——让设计师直接去提 PR。
我们给所有产品设计师都开了 Codex 和 Claude Code 的席位，帮他把环境配置好。对于设计师觉得没有完全还原设计意图的功能，直接教设计师怎么口喷改代码。他口喷完马上在本地电脑上就能看到效果，改到满意了就提个 PR，让工程师看一看有没有大问题，没问题就 ship。
这样就解决了产研之间关于产品设计细节还原的矛盾。当然这个改动和刚才讲的工程师什么时候可以 solo 的指导原则也是相关的——对于影响面不大或比较独立的模块我们会这么干，对于核心模块、影响到用户转化和订阅的，还是会有比较严谨的设计流程。
产品经理从设计页面，转向设计 AI 的行为
当研发的交付能力提升，实现成本变得很低的时候，产品经理会有点迷茫，或者说不知道该干什么。出现过一个问题：我们有些功能模块让工程师先交付上线，上线后出现问题再找产品设计介入看怎么优化。但人的天性都是不愿意接别人的烂摊子——工程师先用 AI 做了个很糙的实现，然后找产品经理说来你看看怎么优化一下，产品经理是很抗拒的。
那我们怎么办？一方面肯定是尽量减少工程实现和产品设计意图的差距，我们会做一些比如 design.md 的设计，去指导 Coding Agent 尽量还原整个产品的设计规范。另一方面我们会想，产品经理也确实应该从设计一个表单、设计一个 button、设计一个弹窗怎么弹这种事情中解放出来。在一个 AI SaaS 公司里面，他们应该做的可能是别的事情。
比如我们现在有产品经理开始转型做 skill 的设计。我们的产品叫 YouMind，是一个创作工具，核心能力是利用各种 skill 帮助用户做 PPT——包括这个 PPT 也是 YouMind 做的——然后绘图、做视频、做各种创作内容，发小红书、发微信公众号等等。
产品经理的工作从设计流程表单交互，变成了去设计一个 skill——一个 skill 怎么帮助你做出更好看的 PPT，怎么拆解你做 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 原生团队最朴素也最难做到的一件事。
