这期是少见的直接点到你名字的一期:讲者开场那张图里,"收下用户需求、一股脑丢进 Jira、从此再没人见过"的那个人,就是 ERP 产品经理。所以这段值得写厚。
一、Holdwell ERP 的活:你拒掉的长尾需求,可能不是优先级问题
① 长尾需求的真正解法,不是排得更准,是让它离开你的队列
- 怎么做的:Kenton 把矛头从"产品经理不够勤快"挪开,指向更底下那个前提——一份代码要同时服务所有人。在这个前提下,一个只有一小撮用户要的功能,进队列会脏代码、不进队列会得罪人,两头都不对。他的破法是把这类需求整个移出中央队列:核心 app 保持干净,用户自己的 agent 在自己的实例里加功能,"谁也不用被别人的功能拖累"。
- 你可以怎么做:拿 ERP 积压的需求清单做一次新的分类,别按优先级分,按"这条到底该不该由我们来实现"分——分三堆:(a) 真·核心,必须进版本;(b) 其实是"某个客户/某个岗位的私人偏好"(报表列怎么排、导出模板长什么样、提醒规则怎么设、列表视图默认过滤什么);(c) 一次性、看完就扔的。第 (b) 堆是这期给你的靶子:这些东西每条单独排队都排不上,合起来却是最大的抱怨来源,而它们几乎都不需要动核心逻辑。这一堆的正确问法从"排第几"换成"能不能让提需求的人自己搞定"。这件事不需要立项,你一个下午就能做完,而且它会直接改变你下次评审时的发言。
② 把约束放进环境,而不是放进规范和评审
- 怎么做的:这是全场最可迁移的一条。分享和权限"由平台实现,不是由 app 自己实现",Kenton 给的理由是——这样"让 gadget 自己根本没机会把这块做错"。安全那一段同理:他不是要求 AI 写出更安全的代码,而是把代码能造成的最大破坏预先压到接近零(数据出不去、外部连不上、别人的碰不到)。安全性来自环境的形状,不来自代码的质量。
- 你可以怎么做:你那套 PRD 工厂最疼的地方是碰撞协议的纪律靠自觉——规矩写了(独立初稿互不可见、评审意见按归属回炉),但没有结构挡住绕过去的人。Kenton 的答案很直接:靠"要求大家遵守"永远漏,靠"结构上做不到违规"才不漏。落到你手上就是一次替换练习:挑一条你最怕被糊弄的规矩(比如独立初稿阶段互看、评审意见没回炉就出全量快照),把它从"协议里的一行字"改成"结构上根本做不到违规"——比如初稿阶段两个 agent 压根读不到对方的产出目录、快照生成缺少回炉记录就直接不出活。一次只改一条,改完看下个月还有没有人绕。
③ 别再用"等新架构就绪"挡需求
- 怎么做的:他讲的 plugin 死循环是一个完整的失败故事:为了以后能快,宣布重写;重写期间所有需求都被"等 plugin 系统"挡回;"几年过去了,新架构还没就绪,功能一个都没实现",用户开始怀疑产品被放弃了。这套说辞的可怕之处在于它每一句都是对的——现在硬做确实会返工。
- 你可以怎么做:你的多角色 PRD 工厂刚换上碰撞协议、产出的可验证性还没建起来,这正是最容易说出"等流程跑顺再说"的时候。给自己设一条硬线:**任何以"等重构/等流程跑顺"为理由的挡回,最多只用两次;第三次就必须给出一个不依赖新架构的丑陋版本。**丑陋版本的价值不是解决问题,是证明这条路还活着——Kenton 故事里的开发者输就输在几年里一件事都没交出去。
二、app_incubator:这期给了你一个反向解法
① "把该做什么前移到 agent"的反面:把决定权推到运行时
- 怎么做的:你现在的方向是把"该做什么"尽量往前挪,让 agent 在开工前就想清楚。Kenton 走的是完全相反的路:**开发者只做第一版,剩下的决定留到运行时,由用完发现缺什么的那个人当场补。**他的原话是"开发者做出 app 的第一版,交给用户;用户需要新功能时,可以直接让自己的 AI agent 单独为自己写这个功能、加进 app 里"。他甚至现场演示了这件事——为了做这场演讲的 slides,他允许 Claude 直接改幻灯片工具本身。
- 你可以怎么做:你的造 App 链路目前是"设计稿即工程强制契约"的前置重路线,好处是产出可控,坏处是前面越想越全、越走越慢,而且你永远猜不准第一批用户到底缺什么。这期提供的是另一个开关:让产出的 app 自带一个"让用户的 agent 改我"的口子。哪怕最小实现只是——生成的 app 里带一个对话框,用户说"这个列表我想按金额排序",agent 就改这份实例的代码。你不需要现在就换路线,但值得在下一个试验里做一次 A/B:同一个需求,一次走"前置想全",一次走"薄核心 + 运行时扩展",比一比哪边更快拿到一个用户真的在用的东西。
② AI 生成的代码怎么才敢让它跑:抄这套四层隔离
- 怎么做的:他的隔离配方是现成可抄的四件套——前端跑在不属于任何域名的 iframe 沙箱里(拿不到主站 cookie 和数据)+ 内容安全策略白名单收紧到"发不出去任何东西"+ 唯一出口是向父窗口递消息的那一条窄通道(上面跑定义好的远程调用)+ 服务端也关在沙箱里、同样不能连外网。结论是"这段代码里你不可能写出一个有杀伤力的安全漏洞"。
- 你可以怎么做:你的造 App 链路里,最让人不敢放手的一环就是"agent 写的代码我没逐行看过,敢不敢真跑"。这套配方给的是一个不依赖代码审查的安全底:只要生成物被关在这样一个盒子里,它写错了也只能自己坏掉。具体动作:给 app_incubator 的预览/试跑环节套一层这样的沙箱,先把最便宜的两层做上(不属于任何域名的 iframe + 内容安全策略白名单),亲手验一次"故意让 agent 写一段偷 cookie 的代码,看它是不是真的发不出去"。验过之后你对"让 agent 直接跑代码"的心理阈值会整个下移,这比多加三道评审有用。
③ 一个实例=一样东西:这是你"首屏体验"的现成答案
- 怎么做的:Gadgets 里实例化幻灯片 app 得到的不是一个工具,而是一份 deck;要多份就实例化多个。整个平台被组织成"像 Google Docs 一样,里面几百上千个东西,打开一个、编辑、分享"。
- 你可以怎么做:你的痛点是"激活/首屏体验"——用户打开看到什么。Kenton 的答案是:首屏不该是一个空的创作台,而该是一屋子已经能用的东西(他自己的白板、西语邮件筛选器、GitHub 待评审整理器,都是列在那儿的现成实例)。再加上他的 blueprint(导出代码、不带数据,别人拿去实例化成自己的)——这就是一条完整的冷启动路径:**先有一柜子样例,用户从"复制一个改改"开始,而不是从空白 prompt 框开始。**下一版首屏值得试这个方向。
三、一人公司 build-in-public:这期是一条现成的选题
- 怎么做的:这场演讲有一个极好的钩子——"你的功能请求被产品经理丢进 Jira 就再没人见过",台下笑,因为所有人都经历过;而讲者本人是 Cloudflare Workers 的作者,2017 年起做到今天数百万开发者、每天数万亿次请求,这个身份让这句吐槽站得住。他还留了个大方的空白:项目当天没有开源(CTO 上周四叫停),也就是说"这套东西到底行不行"目前没有第二个人验证过。
- 你可以怎么做:这条同时满足你两个卡点。选题角度:你就是那个被吐槽的产品经理本人,这是别人抢不走的视角——"Cloudflare 的大佬说我们产品经理是需求坟场,我认了,然后我拿自己的 ERP 需求池数了一遍"。验证体角度:更值钱的是第二篇——他说 AI 写的代码只要关进这样一个盒子就"不可能写出有杀伤力的漏洞",你可以拿造 App 链路真的搭一次这个盒子,然后故意让 agent 写恶意代码去撞它,把结果(成本、翻车、哪层拦住了)写出来。这一篇天然过得了你的"删掉我的判断和实测还成立吗"这道闸——因为全篇是实测,而且目前全网没人能验(代码还没开源),你会是最早的实操样本之一。可抄物很清楚:那四层隔离的清单,读者照着就能搭。
四、Personal Thinking:他的 gadget 就是你的 skill
- 怎么做的:Kenton 展示的私人 gadget 全是"只服务他一个人"的小工具——筛西班牙语邮件、整理待评审的 pull request、一次 prompt 出来的协同白板。没有一个是打算做成产品的,它们的价值全在"正好贴合我一个人的工作流"。
- 你可以怎么做:这跟你这本第二大脑里那一批技能是同一种东西(视频转文字、播客流水线、书籍上传……都是只服务你一个人的工具)。他多给的一步是 blueprint——导出代码、不带数据,让别人从中实例化自己的。你的技能目录已经有这个形态但没这么想过:**哪几个技能是可以"脱掉我的私人数据、只留骨架"分享出去的?**这既是给一人公司号的弹药(可抄物),也是逼你把技能里写死的个人配置抽出来的好理由。
更深三角度
该反着用:Kenton 敢说"这段代码里不可能有有杀伤力的漏洞",是因为运行时是他自己写的——他有整个 Cloudflare Workers 做底座,能重新定义"代码能碰到什么"。你没有这个层级的控制权,而且 ERP 碰的是订单、库存、资金这类真会出事的数据。所以正确的借鉴是反过来缩小适用面:不要试着搭一个通用沙箱平台(那是你精力的黑洞),而是把"让用户当场扩展"只开在最没有杀伤力的那一层——展示层、报表视图、导出模板、个人化的提醒规则,全部只读、只影响提出人自己那一份视图,永远不碰写入路径。他靠环境的形状拿到安全,你靠范围的窄拿到安全,同一个原理,两种成本。
和你现在做法冲突:你在 app_incubator 上的赌注是"把该做什么前移到 agent"——让链路在动手前就想得更全。这期整场演讲在说反话:**想得更全是错的方向,因为你永远猜不到用户要什么;正确的做法是让核心尽量小、把决定权交给用完之后才知道自己缺什么的那个人。**两边都有道理(他做的是通用办公套件,你做的是有明确交付物的造 App 链路),但张力是真实的:**如果"前移决策"这条路走得吃力,别只怀疑 agent 不够聪明,也该怀疑"决策能不能前移"这个前提本身。**这个结论我不替你下,但下次评估链路卡点时,值得把这个问题摆上桌。
对你的镜子:你每天在做的需求取舍,一直被当成"判断力的成果"——排得准不准、拒得对不对。这期给出另一个读法:**你那些必须拒掉的长尾需求,很大一部分不是你判断的产物,是"一份代码服务所有人"这个前提逼你做的取舍。**你的优先级排得再好,也只是在给这个约束打补丁。真正的杠杆不在你的排序能力上,而在你有没有权限去动那个约束——哪怕只动一小块。
所以呢
可迁移思维模型
- 【耐用】把约束放进环境,而不是放进规范。"让它根本没机会做错"比"要求它别做错"强一个数量级。这条对你的关卡执行、对 AI 生成代码的安全、对权限设计,全部适用,而且不会因为技术换代而失效。
- 【耐用】**长尾需求是架构问题,不是优先级问题。**每次面对"这个只有少数人要"的需求,先问"能不能让提的人自己搞定",再问"排第几"。
- 【耐用】**"为了以后能快,先停下来重构"是一条会吞掉几年的路。**用"两次为限"这样的硬规则拦住自己。
- 【会过期】那套具体的四层隔离组合(不属于任何域名的 iframe + 内容安全策略 + 窄通道 + 沙箱化后端)。它依赖今天的浏览器和平台能力,而且这套东西当天并没有开源,你现在只有一段演讲的口头描述,没有可读的实现。当参考配方用,别当结论抄。
判断更新:过去你会把"用户功能请求太多、排不过来"当成产品管理问题。这期之后可以加一个反问:**这些需求里有多少,是因为我们的软件只能有一份、所以只能由我来裁决?**同时,"AI 生成的代码不敢直接跑"这个顾虑,也应该从"需要更严的审查"改成"需要更小的爆炸半径"——后者便宜得多,也可靠得多。
这周一个赌注:拿 ERP 积压需求清单里最近的 30 条,花一个下午分成上面那三堆,数一数第 (b) 堆(私人偏好类)占多少。如果超过三分之一,你就拿到了一个可以正式提的议题:**这一类需求不该走路线图,该走"用户自己配"。**这件事零成本、不需要授权、结论无论正负都有用——而且它顺手就是一人公司号的第一篇稿子。