AI 会写代码了，为什么你还是做不出产品？

概览

本期围绕“普通人怎么用 AI 写代码”展开，几位主播从播客工具、运维脚本、数据处理、企业内审、花店运营等真实场景出发，讨论 AI 编程到底能解决什么、不能解决什么。

核心结论是：AI 确实能大幅降低实现成本，尤其适合需求清楚、边界明确、流程重复、规则可审计的工作；但它并不会自动替代产品判断、架构设计、领域经验、提问能力和人与人沟通。

节目反复强调，AI 写代码的关键不是“把一句想法丢给它”，而是把需求、架构、测试、日志、文档、审计和业务流程组织清楚。会用 AI 的人，本质上是在用自己的 know-how 指挥 AI 放大产出。

分段落总结

[00:14] 开场：从普通人使用 AI 写代码聊起

[事实] 本期是“科技乱炖”的特集，参与录制的有老高、张乐、王大夫等人。

[事实] 主持人提出本期主题是“普通人怎么用 web coding”，也就是拿 AI 写代码。

[事实] 嘉宾背景不同：有人是标准程序员，有人是非编程出身但会写脚本的技术人员。

[推测] 节目设置这些不同背景，是为了比较专业程序员、半技术人员和普通使用者在 AI 编程上的差异。

[01:45] 重度使用 AI 编程：把以前没空做的系统做出来

[事实] 主持人说自己最近重度使用 AI 编程，把以前没空写的系统做了出来。

[事实] 他举例做了“声派 notice”系统，用来替代“飞出妙计”的部分功能。

[事实] 这个系统可以上传音频或通过播客导入音频，自动判断录音场景，并按不同模板输出摘要和总结。

[事实] 系统还支持分享和协同标注，用于把节目发给嘉宾，让嘉宾标出需要修改的地方。

[推测] 这个案例说明 AI 编程在需求明确、已有工作流清楚的场景里，能很快转化成可用工具。

[05:04] 自用小工具和产品化系统是两回事

[事实] 主播们讨论到，自己用的临时工具和给别人长期使用的产品，在要求上差别很大。

[事实] 自己用的工具可以“用完就扔”，坏了也只是自己承担后果。

[事实] 产品化系统需要考虑边界条件、多人场景、用户责任和长期稳定性。

[事实] 主持人认为，仅凭几句话让 AI 做出完整可用系统，在当前模型能力下还不稳定。

[推测] 节目对“有想法就能直接做产品”的乐观叙事持保留态度。

[08:29] 测试驱动开发：AI 适合执行反人性的工程实践

[事实] 主持人说自己会要求 AI 用测试驱动开发的理念，先写测试用例，再实现功能。

[事实] 他会要求测试覆盖率，并让 AI 做端到端测试、界面截图等验证。

[事实] 主播们认为写测试、写文档、写注释都是软件开发中的好实践，但人类往往不愿意认真执行。

[事实] AI 不嫌麻烦，适合执行这些重复、细致、流程化的工程要求。

[推测] AI 编程的一个价值不是替代工程方法，而是让过去难以坚持的工程方法更容易落地。

[12:18] 文档、code review 和多 Agent 协作

[事实] 主持人提到可以让一个 AI 写方案和代码，再让另一个 AI 做 code review。

[事实] 他们讨论到，AI 可以把当前更改总结到文档里，也可以生成 API 文档并用于测试。

[事实] 主播们认为，软件工程里很多好实践过去没有问题，只是人执行不到位。

[推测] AI 在团队流程中的位置，不只是“写代码的人”，也可以是文档维护者、测试辅助者和审查者。

[15:52] 成功案例与翻车案例：不能把全自动当成可靠交付

[事实] 主持人说“声派 notice”完成度很高，中间没有出现明显插曲，因为使用了测试驱动等成熟实践。

[事实] 他又尝试让 AI 根据完整产品文档和目标模式自动实现另一个较大的工程，结果实现得“哪儿也不是哪儿”。

[事实] 这个失败项目没有直接扔掉，而是继续由人检查问题，再让 AI 迭代修补。

[推测] 这一段强调，全自动执行在复杂项目上仍然风险很高，人仍然要承担拆解、审查和纠偏工作。

[18:21] 架构 know-how 决定 AI 能不能做成产品

[事实] 主持人指出，普通人很难知道什么服务能满足当前架构需求。

[事实] 他举例说，音频合并、在线处理、网页剪辑大文件、代理剪辑模式等，都涉及架构和成本判断。

[事实] 主播们认为，当前 AI 对程序员视角的提升更明显，对“素人三句话出系统”还很远。

[推测] AI 能写代码并不等于能自动做产品，因为产品还依赖架构、服务选择、成本和边界判断。

[20:00] 确定性强的小任务：运维脚本、Shell 和重构

[事实] 王大夫举例说，运维工作中服务器、集群、软件配置都有固定模板时，AI 写脚本成功率很高。

[事实] 他们提到 Shell 脚本、Python、Perl 改写等任务，以前人工写很烦，现在 AI 能快速完成。

[事实] 主持人也在把以前用 PHP 写的系统逐步抽模块、打补丁、转写和重构。

[事实] 主播们认为，越小、越确定的能力，AI 做起来越快。

[推测] AI 最容易产生稳定价值的地方，是输入约束明确、验收标准清楚的小型工程任务。

[22:25] AI 做数据挖掘：让人追上 AI 的速度

[事实] 王大夫提到他们用 AI 跑数据分析，当前已经消耗约 270 亿 token。

[事实] 他们用 AI 找数据中的相似性、缩写含义和匹配规则，再由人筛选确认。

[事实] AI 产出的一批数据会倒逼团队成员补规则、解释遗漏和提升工作质量。

[事实] 主播们把这类工作类比为审计和流程推动：AI 找出问题，人必须解释和处理。

[推测] 这里的重点不是 AI 完全替代人，而是 AI 让过去难以规模化检查的工作变成可审计、可量化。

[30:17] 企业内部播客合规审核：AI 适合做审计辅助

[事实] 主持人提到一个互联网大厂内部播客项目，需要审核节目内容是否符合内部合规和表达要求。

[事实] 审核规则包括红灯、黄灯、绿灯，涉及一些不能说或需要谨慎表达的内容。

[事实] 他写了一个 AI 审计工具，上传音频后自动标出红灯、黄灯、绿灯问题。

[事实] 内审人员和栏目负责人可以基于 AI 标注确认修改，再把文档交给剪辑师处理。

[推测] AI 在这里承担的是初筛和提示风险，不是最终合规责任人。

[35:19] 懂领域，才能把 AI 用成流程

[事实] 主播们认为，要把 AI 用好，必须懂所在领域的 know-how。

[事实] 他们说，如果不知道一个事情该怎么做，也就很难指挥 AI 做好。

[事实] AI 可以不交社保、不需要离职补偿、可以 24 小时运行，但前提是使用者能设计好流程。

[推测] 节目把 AI 视为“听话的执行者”，而不是替代领域专家的万能方案。

[38:17] 花店外卖运营：用 AI 辅助投流和调价

[事实] 主持人讲到母亲节期间做花店外卖业务，在外卖平台上做上品、调价和投流。

[事实] 美团平台没有提供他想要的数据接口，后台数据也不够直接，需要人工判断。

[事实] 他把后台截图给 AI，让 AI 根据数据判断是调价还是调整投流策略。

[事实] 他说母亲节那一周，新店进入了天津花店榜单的 TOP10。

[推测] 这个案例说明 AI 不只用于写代码，也能把数据分析和运营策略变成更快的决策辅助。

[42:00] AI 难替代人与人沟通

[事实] 主持人说，花店运营中客户沟通仍然必须由人来做。

[事实] 如果顾客要的花材没有货，需要有人解释季节、替换方案、是否加钱、是否退款等问题。

[事实] 主播们认为，服务行业里人情味、临场反应和见机行事仍然很重要。

[事实] 他们把这类问题类比到数字人直播和客服电话，认为很多用户会要求“转人工”。

[推测] AI 可以提高数据和流程效率，但交易能否保住，往往还取决于人际沟通能力。

[49:18] 老系统改造：先补测试和文档，再谈重构

[事实] 张乐提到，企业使用 AI 改造老系统时，不应该一上来就让 AI 重构。

[事实] 更稳妥的做法是先让 AI 阅读老代码，补齐测试和文档，再进行改写或扩展。

[事实] 老系统常见问题包括文档不齐、测试缺失、多人补丁叠加、没人敢动核心代码。

[事实] 主播们认为，AI 读代码和补测试的能力已经比较有用。

[推测] 对企业来说，AI 的第一步价值可能是降低理解老系统和恢复工程秩序的成本。

[55:57] 日志和排错：给 AI 足够多的可观察信息

[事实] 主持人建议在 CloudMD 或 AgentMD 中约束 AI，把尽可能多的详细日志打到控制台。

[事实] 他认为，有足够多的日志，AI 排错时可以先拉日志、定位问题，再修改代码。

[事实] 主播们讨论到，逻辑错误比语法错误更难调，因为代码能跑但结果不符合预期。

[事实] 王大夫说他们的代码很多是数据采集、入库、处理和输出，要求是不出错、运行快。

[推测] AI 调试能力依赖可观察性；没有日志和测试，AI 也很难凭空判断复杂逻辑问题。

[60:28] 运维巡检和业务逻辑优化

[事实] 王大夫提到，运维中需要大量工具和脚本来巡检服务器、CPU、内存和服务状态。

[事实] 他现在用 AI 每天跑多遍巡检，有问题就处理或报错，没问题就通过。

[事实] 他举例 ClickHouse 负载过高，最后不是通过分片解决，而是调整查询顺序和业务逻辑，把负载降下来。

[事实] 主播们认为，很多问题不是机器问题，而是业务逻辑问题。

[推测] AI 给出的标准技术方案不一定最优，真正的优化仍然需要人理解业务优先级。

[63:48] 从基础思维切换到 AI 工程思维

[事实] 主播们认为，人们处理工作和生活问题时，需要从基础思维切换到 AI 工程思维。

[事实] 他们强调，使用者要先知道自己的问题是什么，再判断哪些环节适合让 AI 介入。

[事实] 节目明确说，AI 不是不好，也不是万能，关键在于会不会用。

[推测] “AI 工程思维”在节目中指的是把问题拆解、流程化、审计化，并判断 AI 适合放在哪个环节。

[65:28] 提问能力决定 AI 使用效果

[事实] 主播们讨论到，很多人不知道该问 AI 什么。

[事实] 他们回顾了 BBS、知乎、GitHub、搜索引擎时代关于“如何提问”的经验。

[事实] 他们认为，能把问题问清楚非常关键；如果问题本身问错了，AI 也帮不了。

[事实] AI 能容忍一些错别字、上下文省略和自然语言表达，但不能替代使用者形成正确问题。

[推测] 提问能力从搜索时代延续到 AI 时代，只是表达形式从关键词变成了更长的自然语言描述。

[70:10] 上下文、记忆和账号边界

[事实] 主播们讨论人与人长期合作形成的上下文，比如同事合作十年后，不用讲太多也能理解彼此的想法。

[事实] 他们认为 AI 现在需要把事情讲得更明白，否则可能会做错。

[事实] 他们提到模型记忆和跨产品上下文的体验，也讨论了团队账号与个人账号的数据隔离问题。

[推测] AI 记忆可能改善长期协作体验，但节目对它能否达到人类默契程度仍持保留态度。

[72:48] AI 时代仍需积累的能力

[事实] 主播们总结说，重要能力包括提问题能力、把 know-how 加成成产品的能力、与人沟通的能力、分层判断能力和价值判断链条。

[事实] 他们认为这些能力需要花时间积累，AI 目前搞不定。

[事实] 节目还讨论到，初级程序员等岗位的升级打怪路径可能被 AI 压缩。

[推测] 未来职场可能更依赖两端能力：一端是能清楚指挥 AI 的高阶判断者，另一端是被 AI 承接的大量执行工作。

[75:00] 收尾：不要焦虑，但要持续学习

[事实] 主播们以“最近对 AI 的应用和思考”作为本期总结。

[事实] 他们表示大家如果有问题可以在评论区留言。

[推测] 节目的态度不是劝退 AI，也不是鼓吹万能，而是建议听众在具体工作中寻找适合自己的使用方法。

播客点评/总结

[推测] 本期的价值在于案例非常具体，没有停留在“AI 会不会替代程序员”的抽象争论，而是把 AI 放进真实流程里看：写代码、补测试、审计内容、跑数据、做运营、查日志、改老系统。

[推测] 亮点是多次强调“产品不是代码本身”。节目把需求清晰度、架构判断、测试覆盖、日志、文档、业务 know-how 和人际沟通都纳入讨论，这比单纯展示 AI 写出一个 demo 更接近真实工作。

[推测] 局限是讨论主要来自几位主播自己的实践经验，缺少更系统的数据对比；部分工具名、项目名和技术名在转录中也有识别不稳定之处，因此不适合直接当作工具选型指南。

[推测] 这期适合正在尝试 AI 编程、AI 辅助运营、企业内部流程自动化的人收听，尤其适合已经有领域经验、但想提高实现效率和流程质量的产品经理、程序员、技术管理者和小团队负责人。