
点击文末“阅读原文”即可参与节目互动剪辑、音频 / 卷圈 运营 / 卷圈监制 / 姝琦 封面 / 姝琦产品统筹 / bobo 场地支持 / 声湃轩天津录音间一个常见的场景正在反复出现。有人兴冲冲地打开 AI 编程工具输入几句需求等上几个小时得到一个“看起来什么都有”的结果。页面能点功能也像是有了演示时甚至还颇有几分惊艳。可再往下走两步问题就开始冒出来了。逻辑不稳边界没兜住需求一改就乱真要给别人用更是处处心虚。这不是 AI 不会写代码。恰恰相反AI 已经越来越会写代码了。真正的问题是写代码这件事从来都不是做产品最难的那一部分。过去很长一段时间里很多人把“不会做产品”误以为是“没人帮我写代码”。今天 AI 把这一层障碍迅速压低之后另一层更真实的门槛反而暴露出来了你是否真的知道自己要做什么为什么这样做以及它最终要给谁用。这期节目里几位嘉宾讨论的核心其实正是这个问题。AI 正在让“做一个东西”变得越来越容易但“做出一个产品”依然是一件高度依赖判断力的事。代码的门槛在下降产品的门槛没有AI 编程最先改变的是实现效率。很多过去“想做但一直没空做”的东西现在确实可以更快落地了。一个内部小工具一套自动化脚本一个原本只是停留在脑子里的功能想法只要需求足够清楚AI 往往就能把它变成一个可运行的结果。这种体验很容易让人上头因为它第一次让很多非专业开发者感受到自己离“做软件”原来并没有那么远。但问题也恰恰出在这里。离“做软件”近了一点不等于离“做产品”近了同样多。软件是实现产品是系统。前者强调把东西做出来后者强调把东西做对、做稳、做得能长期使用。两者并不等价。一个自己用的小工具坏了可以重来逻辑粗糙一点也未必有太大代价。可一旦它要给别人用事情就变了。你要开始考虑边界条件要考虑多人协作要考虑稳定性、成本、维护、反馈、迭代甚至还要考虑用户会不会按你意想不到的方式去使用它。很多人以为自己卡在“编码能力”上实际上卡在的是这些更靠后的问题。AI 能把前半段做得更快但后半段依然要靠人来决定。真正稀缺的不是代码能力而是把需求说清楚的能力节目里有一个很有代表性的判断AI 编程对什么人最好用答案不是“最会写代码的人”而是“最清楚自己要什么的人”。这听上去像一句废话实际上并不简单。很多人说自己有需求其实只是有一个模糊愿望。想做一个系统想做一个工具想让 AI 帮自己省点事这些都不算真正的需求。真正的需求至少要清楚到可以回答几个问题它解决什么问题给谁用在哪个场景里用输入是什么输出是什么失败会发生在哪里哪些条件不能碰哪些效果必须实现。当这些东西模糊的时候AI 只能在模糊里替你猜。它不是不能生成结果而是很容易生成一个表面合理、实则偏题的结果。越是复杂一点的系统这种偏差放大的速度就越快。这也是为什么很多人会产生一种落差。明明 AI 已经表现得很聪明了为什么最后做出来的东西还是“不太对”。原因往往不在 AI而在于提出问题的人还没有把问题真正定义清楚。从这个意义上说AI 编程并没有取消产品经理、架构师、工程负责人这类角色的重要性。它只是把这些角色的价值暴露得更直接了。过去这些工作常常隐藏在漫长的开发流程里不容易被看见现在代码能更快产出前面的判断是否扎实反而会被更快检验出来。Demo 很容易产品化很难很多关于 AI 编程的误解都来自于把 Demo 当成了产品。一个 Demo 的目标是证明“这件事可以做”一个产品的目标是证明“这件事值得长期使用”。前者追求的是可见性后者追求的是可靠性。两者之间隔着的不只是多写一点代码而是一整套工程化和产品化的思维方式。节目里提到一个很关键的区别自己用和给别人用是两种完全不同的难度。自己用的时候很多问题可以容忍。偶尔报错没关系数据丢了可以补流程绕一点也能接受因为使用者就是你自己你知道它哪里有坑也知道怎么绕过去。可一旦给别人用所有“自己心里有数”的地方都会变成风险。别人不会像你一样理解这个系统也不会替你补齐那些你没说出口的前提。于是真正麻烦的部分开始出现了。不是功能有没有实现而是架构是否撑得住不是页面能不能打开而是高负载时会不会崩不是能不能处理一条数据而是能不能稳定处理一千条、一万条不是“能不能用”而是“出了问题谁来负责”。这些问题很多都不是一句提示词能解决的。它要求你本来就对软件系统的运行方式有基本理解或者至少知道该如何提出这些问题、如何验证这些问题。所以“一句话生成一个产品”之所以迷人是因为它把产品这件事描述得过于轻巧了。现实是AI 可以把原本最耗体力的那部分工作大幅缩短但它还不能替你承担产品判断也不能替你为结果负责。AI 最适合接手的恰恰是人最不爱做的那些事节目里还有一个很值得玩味的观察AI 在软件开发里最有价值的地方未必是“替人写业务代码”而是替人完成那些本来就重要、但长期没人愿意认真做的工作。比如测试。比如文档。比如注释。比如代码审查。比如变更记录。比如对旧系统的梳理和补全。这些事情传统上都很反人性。团队知道它们重要但现实里总是容易被省掉。时间紧的时候先不上测试需求急的时候先别补文档能跑就行先上线再说。久而久之系统越来越复杂文档越来越不准测试越来越不全最后谁也不敢动老代码。而 AI 的特殊之处在于它不嫌麻烦。只要你给它足够清楚的要求它可以很耐心地补测试、补文档、生成计划、做审查、帮你梳理模块关系。过去这些工作之所以做不好很多时候不是因为人不知道它们重要而是因为人既没耐心也没有足够稳定的执行力。AI 恰好填上了这个空。这件事带来的启发很重要。它说明 AI 并不是推翻软件工程而是在某种程度上重新证明软件工程。那些过去被反复强调、但经常在现实中做不扎实的方法并没有过时只是以前人很难稳定做到现在机器反而更适合去做。换句话说AI 让“好流程”第一次变得没那么昂贵了。普通人做不出产品不是因为不够聪明而是因为太容易低估复杂度今天很多人对 AI 编程最深的误判不是高估了 AI而是低估了产品这件事本身的复杂度。看一个成品界面容易觉得它不过如此。真正难的是你得知道它为什么长成这样它背后接了哪些服务哪些看起来顺滑的细节其实要靠很多工程约束撑住哪些成本是上线之后才开始显现的哪些异常只会在真实用户进入后才暴露出来。这些复杂度过去被专业分工吸收掉了。产品经理、开发、测试、运维、架构师各自负责一部分于是很多外行人会误以为做产品最贵的只是“请程序员写代码”。现在 AI 把编码成本迅速压下去大家才第一次更直接地看见原来真正贵的是那些看不见的判断、取舍和经验。这并不是在给普通人泼冷水。恰恰相反它是在提醒一件更有建设性的事普通人当然可以用 AI 做产品但前提不是把 AI 当魔法而是把它当作一个需要被指挥、被约束、被验证的协作对象。你越清楚自己的问题AI 越像杠杆。你越想跳过思考AI 越像放大器把原本含混的地方成倍放大出来。未来会不会真的变成一句话做产品也许会。从长期看大模型的能力当然还会继续提升。未来某一天很多今天看来仍然很专业的工程问题可能真的会被进一步抽象掉变成更自然的交互、更自动的推理、更低门槛的生成。这种方向没有什么悬念。但至少在今天尤其是在需要长期使用、多人协作、面对真实用户的产品场景里我们离“一句话就把产品做对”还很远。这不是因为 AI 不够强而是因为产品本来就不是一句话能说清的东西。产品是对现实世界的一次建模而现实世界最麻烦的地方恰恰在于它从不按理想状态运行。用户会误操作需求会变化成本会波动系统会老化团队会更替旧代码会留下历史包袱。把这些因素组织起来本来就是产品工作的核心。所以真正值得讨论的问题可能不是“AI 会不会取代做产品的人”而是“在 AI 已经能大幅接管实现工作的前提下什么能力会变得更值钱”。答案大概已经很清楚了。不是多会写几行代码不是多会背几个框架而是能不能把一个模糊想法拆成明确问题能不能看见边界能不能理解场景能不能做取舍能不能对结果负责。代码正在越来越便宜。判断反而越来越贵。AI 开始写代码确实是一个时代变化的信号。但它真正改变的也许不是谁会失业、谁会被替代而是它迫使每个人重新面对一个更本质的问题当实现越来越容易时我们到底凭什么做出一个真正有价值的产品。对很多人来说这个问题未必轻松。它甚至有点残酷因为它会比以前更快地暴露出能力的真空地带。但换一个角度看这也是一次重新分配价值的机会。那些过去藏在流程深处、不容易被看见的能力正在变成最关键的能力。AI 能写代码当然重要。但决定一个产品能不能成立的依然是人。本期主播及嘉宾朱峰「津津乐道播客网络」创始人产品及技术专家。微博zhufengme高春辉「科技乱炖」主播。“中国互联网站长第一人”科技、互联网领域的连续创业者。微博高春辉微信公众号老高的互联网杂谈张乐 津津乐道播客主播连续创业未果的老程序员。王大夫硬件工程师数码爱好者伪电工刷一切可刷之 firmware喜欢跟儿子一起玩玩具节目里提及的产品声湃·Notes https://notes.wav.pub某高老师的新产品https://auralwise.cn/关于「科技乱炖」朱峰、高春辉等多位知名 IT 业者主持的科技资讯点评播客。主播和嘉宾利用多年经验和业内视角嬉笑怒骂之间把近期科技热点变成犀利、独到、深刻的独家观点。在一派纷繁芜杂里我们为愉悦双耳而生。科技、教育、文化、美食、生活、技能、情绪……严肃认真却不刻板拒绝空泛浮夸。与专业且有趣的人携手缔造清流分享经历传播体验厘清世界与你的关系。更多播客节目精选往期节目红黑榜 | 用“配料表干净”给自己贴金脸都不要了邪修真香邪修真香控糖控的到底是什么大多数人都理解错了订阅节目苹果播客 | 小宇宙App | 汽水儿App | Spotify喜马拉雅 | 网易云音乐 | QQ音乐 | 微信听书 | 荔枝FM央广云听 | 听听FM | Sure竖耳AppBilibili | YouTube搜索「科技乱炖」订阅收听为了保证第一时间收到不被阉割的节目且可以同步读到更多背景资料强烈建议您在订阅和收听时采用「通用型播客客户端」公众号中回复“收听”了解具体订阅方法