当AI写代码成为常态，协作方式必须彻底变革。WorkOS创始人用Claude写出15000行代码，一行未读；创业者们正重新定义代码审查、会话管理和团队协作工具。这场405人的Demo Night，揭示了AI参与软件开发后的新规则。

你有没有想过，写代码这件事的对象正在悄悄换人？上周一晚上，我在旧金山Market Street上WorkOS的办公室里待了将近两个小时，看了二十几个现场demo。进门之前我以为这只是一场普通的创业展示夜，但看完之后我意识到，这群人在展示的根本不是产品，而是他们对”写代码、用代码、读代码”这件事本身的理解，已经发生了多深的变化。

规则很简单：现场演示，不许放PPT，不许讲公司，每人五分钟。405个人挤在一起，还有人因为名额满了只能看直播。这场活动来自WorkOS创始人Michael Grinich一周半前随手发的一条推特。

第一个上台的人，把自己最恨的软件重新做了一遍

Grinich自己第一个上台。他说他讨厌LinkedIn，但作为创始人又离不开它，招人全靠它。他最受不了的是那个私信界面：只能显示几条消息，要来回点击不同的收件箱，里面还夹着广告，搜索功能慢得离谱，用他的话说，”最不想看到的就是在垃圾堆里再看到更多垃圾”。

于是他自己做了一个。照着Superhuman邮件客户端的思路，做了一套完整的键盘快捷键体系，搜索、归档、切换收件箱、标记未读、按未读过滤，全部能用键盘秒操作。背后有一个同步引擎，把账号里的消息全部拉下来本地存着，完全可以离线使用。他的账号半年下来同步了将近3400条消息。

更关键的细节是：整个项目大概一万五千行TypeScript，九百多个测试，代码全是Claude写的，他说自己一行没读过。做完时间是去年阵亡将士纪念日周末，他坐在泳池边完成的。现在免费开源在GitHub上。

这个开场看似随意，但它定了当晚的基调。以前觉得改一个工具要大动干戈，现在一个周末、一个AI，就能做出一万五千行带测试的东西。这件事已经不稀奇了，但在场的人对这件事的反应，让我感觉大家对这个现实的接受程度比我想象的更平静，平静到几乎是理所当然。

个人用AI是快了，但团队协作的断层正在从审代码这一步爆开

做ref.tools的Matt讲了一个很戳我的问题。他说单个工程师用AI写代码确实快了，但整个团队并没有跟着变快。他在demo开始之前做了一个现场调查：举手问有多少人用agent写计划文档，有多少人会把这个计划分享给队友看。结果是，举手写计划的人不少，但留着手分享给队友的人明显少很多。

他的判断是，协作的节点必须往前挪。传统上，代码审查是大家同步认知的关卡，但代码大量由AI生成之后，让人逐行去审AI写出来的东西，效率极低，越来越做不到。真正应该对齐的，是做决策的那一刻，而不是代码已经写完了才来对齐。

ref本质上是一个协作文档，支持Markdown和HTML富文本，可以嵌入原型和可视化，支持评论，背后挂了一个托管的Claude Code实例，可以直接从评论里拉起来干活。他现场演示的是当天真实发生的一个bug，图片在ref里加载不出来，这个bug是从他们团队的Slack里反馈进来的。agent先把方案写好，他加了几条评论，同事Sever看过之后批准，他又追加了关于验证方式的几点想法，最后才让agent真正动手改。

他说这里最重要的转变是把”状态”和”动作”拆开了。所有上下文都沉淀在这份共享文档里，没有任何一个agent独占上下文，也没有任何一个人独占信息。同事Sever可以随时拿起这份文档，看清楚到底在做什么、为什么这么做，直接把上下文装进脑子里，然后接着往下走。他演示结束前说了一句话让我印象很深：”如果你现在还没有把计划分享给队友的习惯，试试看，这是我们作为人类做得太少的一件事。”

让团队实时看着agent改代码，这件事比想象中难得多

HumanLayer的Kyle做的方向跟ref类似，但问题落在另一处：当coding agent在工作的时候，怎么让其他人也能实时看到它在做什么、能插上话、能随时给它改方向。

他现场展示的agent会话跑在同事Dexter的设备上，是被远程拉起来的，Kyle自己用另一台机器在旁边实时看着。他们做了一个diff查看器，能实时显示agent正在对哪些文件做什么改动，Kyle可以直接在上面留评论，评论会发回给agent，agent根据反馈调整方向继续工作。

实现这套东西，他们参考了Figma的双轨同步架构。Figma有两条同步通道，一条快的处理光标位置和在线状态，一条慢的走数据库落盘。他们也做了类似的设计：慢通道走Postgres，快通道用他们自己搭的durable streams，有点像给网页用的Kafka，事件以文件形式存在磁盘上，客户端用长轮询或者server-sent events去订阅，延迟在几十到几百毫秒之间。

还有一个更细的工程问题，他们专门维护了一份影子git索引来追踪文件变化。原因是agent每次调用工具都可能改文件，但哪个工具调用会真的改文件、哪个不会，事先根本不知道，所以只能每次工具调用完之后都跑一个hook，把当前文件状态跟影子索引对比一次，检查有没有新的变化。之所以不直接提交到主分支，是因为那样会让push变得很慢，整个工作流都会拖垮。

他们还在搭这套东西，但背后的判断我认为是对的。现在大多数coding agent的体验都是单机单人的，你启动它，等它跑完，然后去看结果。这在个人用的时候没问题，但如果团队里多个人同时在用agent，agent之间的工作彼此有关联，这种模式就根本撑不住了。

在终端里审代码，以及让agent帮你讲清楚这次改了什么

Modem的Mike Clark当天演示了两个他们开源的工具，切入点都很实在。

第一个叫Hunk，brew install就能装。它在终端里把diff查看体验做到接近GitHub网页的水准，文件列表在左边，可以用键盘快速在文件之间跳转，支持查看、评论、标记。但比界面更有意思的是agent集成：你可以让agent直接在diff上打评论，标出哪里是回归测试要重点关注的，哪里有潜在的问题。他演示的场景是，他当天在路上用Claude Code做了一个spike，研究要不要把认证方案从Better Auth换成WorkOS，做完之后产生了一堆文件改动，他用Hunk让agent帮他过了一遍这些改动，让agent做code review，打评论。他演示途中agent真的在diff里发现了一个用户封禁逻辑有漏洞，其他路径还能绕进来，他当场说要回家修。

第二个叫SideShow，免费，托管服务，用GitHub账号就能注册。它让agent把一次代码改动做成一个可分享的网页，用大白话解释清楚这次改了什么，配上徽章和可视化。网页上可以留评论，agent会实时处理评论里的反馈并更新页面，也有分享按钮可以直接发给别人看。他说他们团队里有实习生，动不动就提一百个文件的PR，没有人能看懂，SideShow就是用来解决这个沟通问题的。他演示的时候让agent用SideShow解释了一遍Better Auth和WorkOS的对比，然后问台下的Grinich这个总结准不准确，台下的人笑着说有点过度简化了。

我看完这两个工具之后的感受是，代码diff这件事正在变成人和agent之间最重要的沟通介质，不只是开发者之间的沟通，而是人和agent之间的沟通。以前大家总想着怎么跳过代码审查，现在反而有一批工具在认真想怎么让这件事变得更可见、更好理解。

Agent的会话记录，正在变成比代码本身更值钱的东西

做Entire的Patent有一个我觉得很深刻的判断：agent的每一次会话，应该被当成和代码等价的资产来存和管理。

他们做的事情是把agent session跟git提交记录绑在一起。你在用他们的CLI工具时，只要开启了Entire，下一次提交时这次的会话就会自动关联上去，形成一个”checkpoint”。每个checkpoint都带着这次工作的意图、结果、收获的小结，以及agent用了哪些工具、花了多少token，还有哪些文件发生了变化。

团队成员可以在界面里看到同事的会话历史，不只是自己的。他演示的一个场景是：让agent在仓库里搜索过去关于某个不稳定测试的历史记录。agent很自然地用上了Entire提供的搜索能力，自己在所有历史checkpoint里找，把当时的上下文和解决思路都拿了回来。他还展示了一个叫”trail”的功能，类似他们自己版本的pull request，每次提交会根据对应的agent会话质量和diff内容自动打分，找出潜在问题。

他们还自己搭了一套分布式git网络，在四个地区互相镜像仓库，在不同地区工作的工程师可以从距离最近的节点拉取代码。

这触到了一个真实的痛点。现在大家的做法基本是每次开一个新的agent会话，把背景重新交代一遍，跑完了关掉，什么都不留。但那些会话里其实沉淀着大量有价值的东西：当时的决策逻辑、踩过的坑、试错的过程。把这些系统地存下来，让agent下次能调用，让新人能翻阅，这才是把AI真正融进团队工作流的做法。

让agent打宝可梦，不只是好玩

Brian Douglas的demo是当晚最好玩的，但背后的思路是认真的。

他让Claude Code去打宝可梦红，从宝可梦中心出发，一路推进翠绿森林。agent每次跑到同一个位置就被地图上的树桩卡住，因为它不知道那些障碍不可穿越。他的解法是把每次会话的完整轨迹录下来，做成一个开源工具叫tapes，高保真地存在本地机器上，默认保留30天，可以改成更长。然后他把这些轨迹喂回给agent，让它从过去的失败里形成一种观察式记忆，具体表现是在下次会话开始时附上这些观察作为上下文。

这套流程他照着Anthropic给团队版做的付费功能Dreams来做的，觉得没必要花钱，干脆自己用tapes实现了一个。Dreams的概念是agent回顾过去的会话，生成反思和观察。他在上面加了一层叫Inceptions，把这些Dreams重放、干预，再拿去跑新的任务，验证观察是否真的有效。他说这套东西还能让agent自己判断，这个任务根本不需要最贵的模型，打宝可梦用Haiku就够了，用Opus是浪费。

他还专门搭了一套multiplexer，让多个agent会话同时并行跑，像tmux那样在一个终端里同时看多个会话的状态。当晚演示时他同时跑着宝可梦的实时会话和Dreams的分析进程，两个窗口同时在动。他把同样的思路用在了公司内部，把工程师过去的会话记录喂给agent，让它自动帮新人搭测试环境，而不是每次都从头教。他和朋友们一共玩了超过四千个小时，差不多一百个人参与，留下了1100多个Claude Flow的分支。

产品界面是为人设计的，但agent根本看不懂

做venture studio的Alex，年初写过一篇关于agent-native架构的文章，当晚把整个流程在现场走了一遍，号称有100%的成功率，结果GitHub在他demo开始时真的挂了，他只好用了备份方案。

他找了一个自己完全不掌控的开源仓库OpenStatus，现场git clone、安装依赖、迁移Turso数据库，设置环境变量，跑起dev server，然后用他们自己的CLI工具做了一次改造，整个过程零AI参与，纯程序化的。改造完之后，产品页面上多了一个小聊天框，挂着四个工具：状态查看、写应用、检查应用、提交应用。改造完的产品，agent可以直接在里面导航和操作，不需要做DOM解析，不需要截图理解界面，不需要computer use，就算用本地小模型也能跑起来。而且原有的代码逻辑一行没动。

做MCPJam的Marcelo接着揭了这条路上一个被忽视的问题。MCP名义上是个统一标准，但每家客户端实现出来的行为差异极大。他现场用同一个提示词，让ChatGPT、Claude、Copilot分别去调用同一个展示地铁线路的MCP服务。结果ChatGPT和Copilot都正常显示了地图，Claude却没有。原因是Claude的执行环境不支持window.open这个接口，它转而用了渐进式工具发现机制，先搜索可用工具再调用，但这个过程把关键的显示步骤弄丢了。他现场还展示了Copilot只实现了MCP能力子集的情况，某些协议层的特性比如elicitation，目前只有Cursor支持，但下周的新规范里就会出现，大家都会开始用。

他们做了一个每天自动更新的静态网站，追踪各家客户端实际支持哪些能力，可以直接搜索某个特性，看哪些客户端支持、哪些不支持。他的说法是，以前做产品要考虑浏览器兼容性，现在做MCP server要考虑的是你的用户到底在哪家AI客户端里，而且这件事比浏览器兼容性更复杂，因为各家的行为差异比浏览器大得多。

真正的普及，不是让更多人学会用Cursor

做Charming的团队做的事情是让agent不只能帮你写应用，还能让agent自己也用这个应用，普通人也能用。他用ChatGPT加上他们的MCP服务器，现场一句话生成了一个小费计算器应用，整个过程几分钟之内完成，生成完之后可以直接在手机上装、在浏览器里开、分享给朋友用。

他还提前搭好了一个家庭仪表盘，记录冰箱库存、家务分工和共同开支，跟室友共享。这个应用可以被任何agent直接查询和操作，比如问一句”家里还有没有牛奶”，agent查完仪表盘直接给答案，还能通过agent往里面加数据、更新记录，改动会实时同步到应用里。他还展示了一个自己做的更复杂的东西：一个连着本地电脑上运行的服务的移动端控制界面，类似OpenAI收费2.3美元的Codex Micro功能，他在Charming上自己免费实现了一个。

他把定位说得很清楚：这是给不懂技术的人用的，比如他的父母。父母不会用Lovable，不会用v0，但他们已经会用ChatGPT了。从ChatGPT的插件商店装一个插件，解决一个具体的生活问题，这才是普通人能用起来的门槛。

NoInfra.ai的Nikhil动机更直接。他妈妈跟他住一起，从今年一月起就一直追问什么时候给她弄一个自己的agent。他做的东西流程极简：登录、选模型、创建agent、开始试用。后台用他们自己搭的推理网关跑开源模型，当天演示已经接入了GLM 5.2，用户完全不需要自己搞API key，也不需要理解token是什么。他还专门做了邮件服务和电话服务，agent可以给你发邮件、打电话，你也可以给agent打电话。甚至给agent配了一个加密钱包，用的是Coinbase，token用完了agent自己会充值，完全不需要人介入。他妈妈通过Telegram跟自己的agent对话，懂技术的用户则可以拿到完整的root和SSH权限，上传文件，做任何事。

这两个demo背后是同一件事。真正的普及不是让更多人学会用Cursor，而是让那些从来不会用Cursor的人，也能拥有一个能帮自己干活的agent。

如果写代码的主要是agent，语言该长什么样子

当晚还有人现场展示了一门自己做的新编程语言，专门为agent设计，不是为人。

他把代码表示成图而不是一行行文本，图上的每个节点可以点击直接跳到对应的代码，展开之后可以看到这个节点内部的逻辑结构。他说图上的diff比行级diff直观得多，看一眼就知道结构变了什么，而不是逐行对比。运行时默认给每一行代码打上埋点，自动生成精确的火焰图，agent可以直接在生产数据里查询，比如筛出”user.images里调用generate_image、内容超过50个字符、延迟超过五秒的所有调用”，完全不需要手工加监控代码。他说这些数据在事后才有用是一个误解，真正有价值的是一直跑着，随时可以查。

这门语言里写的每一个函数，都可以直接在Python或者TypeScript里调用，类型安全，不需要写任何胶水代码。他的逻辑是，TypeScript当年是在正确性和开发效率之间做妥协，但如果写代码的主要是agent，效率对人友不友好已经不重要了，那为什么不直接只为正确性设计？他还提到一个细节，用他们的工具搜代码不用写正则，直接描述你想找的东西，系统帮你找；运行一个函数不需要搭脚手架，直接把函数名当成CLI命令跑，类型不对自动报错。

这个demo有点硬核，五分钟很难讲清楚一门语言的设计哲学，但他提的问题我认为是真问题。我们现在用的那些语言，都是建立在人写代码这个假设之上的。如果这个假设正在改变，语言该长什么样子，目前还没有人认真回答过。

两个多小时之后，我在想的是另一件事

当晚有好几个人demo到一半WiFi就断了，有人干脆放弃投屏，徒手把剩下的时间讲完。有个演示卡在等GitHub加载，等了将近两分钟。做游戏demo的那个人结束时说，他和朋友们一共玩了超过四千个小时，一百个人，1100多个Claude Flow的分支，游戏本来只是为了让朋友们能一起玩，结果歪打正着变成了一套验证agent学习机制的试验场。

把二十几个demo连起来看，我感受到的不是某一款产品有多厉害，而是一个集体的认知转变。大家已经不再讨论”AI能不能写代码”了，而是在认真讨论一个更深的问题：当agent成为软件系统里的正式参与者，协作的方式要怎么变，工具要怎么变，产品本身要怎么变。

开场Grinich那个LinkedIn客户端，他说自己一行代码没读过，全是Claude写的，Memorial Day周末在泳池边做完的。这句话两年前说出来会让人觉得是在吹牛，那天晚上在场的四百个人听了之后只是点点头，觉得理所当然。

我认为这个”理所当然”，才是当晚最值得记录的东西。