作者 | 唐小引出品 | CSDNIDCSDNnews一个 PR50 万行代码变更一个工程师写出来的没有人 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 只有一个 MillionToken 可能是 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 发工资”演讲结束后进入 QA 环节现场观众的提问一个比一个尖锐。有人问到了 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 原生团队最朴素也最难做到的一件事。2026 奇点智能产品大会汇聚 40 位一线产品技术专家与行业实践者围绕 Agent、企业级 AI、AI Coding、具身智能、AI 原生组织、行业应用落地等方向分享了大量 AI 产品实践与落地思考。我们将陆续整理嘉宾演讲内容帮助大家复盘现场精彩观点。欢迎读者朋友们扫码领取大会 PPT 合集获取一线专家的实践经验与深度洞察。
