这一期是在茶馆顺手录下来的。
我们本来是来谈业务的，谈完之后，我顺嘴提了一句上一期跟徐文浩录的播客——他讲怎么治理“屎山代码”。
王建硕端着茶杯说了一句：「我不太同意。」
我把录音打开。
* *
一、要不要治“屎山代码”
徐文浩前一期的立场清晰：AI 写出来的代码就是屎山——人不可读、不可维护——所以要用 skill、用最佳实践、用各种治理工具，把它治理得可维护起来。
王建硕的回应是：屎山代码就是不可维护的代码，它根本不需要被维护。
我一开始没听懂。他给我解释——
「至少大家都已经承认，除了最最核心的内核，今天已经没人能直接去改汇编了。可以，但没人会做。即便你真要改一个 bug，做法也不是改汇编——是改它上一层的 C 语言。」
「然后通过编译，让汇编自动跟着变。」
我反应过来——他的意思是，AI 写出来的所谓“屎山代码”，对应到这张图里，就是新一代的“汇编”。
它在底下跑得好不好不是问题。问题是你跑去那一层维护它——你站错了。
「屎山只要不被人看到，它就不是屎山。」
下一段他给我重新定义了 bug：
「代码不存在错误，只存在跟你的 intention 不一致。所谓错误，要么是 bug 本身，要么是 feature 写得不对。」
他举了一个例子——你在 C 语言里写print color，没指定颜色，编译器给你 print 出白色。这是 bug 吗？不是。这是你没说要蓝色。
「现在很多人觉得 LLM 不对——是因为他想要蓝色，但只说了print color，结果 LLM 给他打了白色。然后他跑去改 Python 那一层，而不是改最上面的那条自然语言——以为这样问题就解决了。」
他承认徐文浩讲的治理方法都对——用 skill、用最佳实践、用 harness——但他认为这些都是给“自然语言层”用的工具，不是给“代码层”用的工具。
「不管哪种解法，你去直接改 source code 都是不对的。所以刚才我们在讲的，已经把 source code 这一层给干掉了。」
我后来想，这不是“王建硕用了更好的方法治屎山”——是他认为徐文浩不应该在那一层做治理。
* *
二、用户写反馈，5 分钟后 APP 改完了
讲完这一段，王建硕给我看他做的一个 APP。
我以为他要讲他怎么用 Claude Code 写代码。但他给我看的不是代码，是 APP 上的一个功能——
「最重要的功能，叫'用户反馈'。」
这不是传统的“用户反馈”。
「你可以在上面写——比如'希望字体大一点'、'希望增加一个 XX 功能'。然后比较搞笑的事情是——你那个 APP 过几个小时就会更新，按照你的要求，AI 就把它自己重写了一遍。」
我又跟他确认了一遍：用户写反馈，5 分钟之后 APP 就改完了？
他说，对。
整套技术链路其实非常朴素——
用户在 APP 里写下反馈
反馈自动落到 GitHub 上变成一个 Issue
Claude Code 监听到 hook，把代码拉下来
AI 读 Issue，自己写代码、跑测试、合主分支
自动 build
自动推到 TestFlight
几个小时之后 App Store 审完核，新版本上线到所有人手机上
王建硕的原话：
「从你提交问题，到你的手机上能测试它——大概五分钟左右就更新一个版本。审核完上线，大概一两天就出来了。」
我以为这已经够离谱了。过了几天他又跟我说——
「我现在不需要用户反馈了。它自己想想要更新什么东西，它就自己更新自己。」
* *
三、连用户反馈也不需要了
这一层是怎么做的？
他给那个 APP 接了一个 PM Agent。
按他的原话，PM 团队的工作是这样的：
「用户是可以随便提的，那 PM 总归是要做一个审核——把一些很不靠谱的、不一致的给去除。即使有一个功能，也不是用户说什么就是什么。它如何和现在的东西重，我们再想一些办法——这部分我们还没做，现在正在建。」
PM Agent 像一个真实的产品经理：审反馈、排优先级、做一致性判断、过滤奇怪需求。
至于在没有用户反馈进来的时候 PM Agent 具体怎么自主判断“下一版做什么”——这部分我没有跟王建硕逐条核对实现细节，是我自己的推论。但从他那句“它自己更新自己”推断，大概率是 PM Agent 也承担了一部分主动产出需求的工作。
他跟我形容这个状态：
「我每天大概每隔一两个小时，TestFlight 就咚地一下，说新版本发布了。我就很好奇——今天它又变成了什么样。」
注意他用的词——“很好奇”。
王建硕从 APP 的开发者，变成了那个翻手机看自己 APP 又变成什么样的好奇用户。
过去 30 年，软件开发者和软件用户是两种身份——你写代码，你知道下一版长什么样；用户用，用户不知道下一版长什么样。
王建硕做的这个 APP，把这两个身份合到了同一个人——他既是开发者（写了 PM Agent 的 prompt），又是用户（每两小时翻一下 TestFlight 看 APP 又变成什么样了）。
* *
四、几个 Agent 团队
光有 PM Agent 显然不够。
他在节目里描述了几个正在跑的 Agent 团队。原话是这样：
「我有一个市场团队是每天早上 6 点钟干活。然后我的工程团队，每 4 个小时醒一次干活，有需求的时候随时响应。然后再加 PM 团队——我准备在需求和开发之间再加一层 PM 团队。或许未来，还要再加一个客服团队。」
四个角色，一个人在跑——市场、工程、PM、客服。
他对“团队”的定义特别朴素：
「所谓的团队，你可以认为就是——一个子文件夹里面的一堆代码，加上一个定期执行。在我脑子里面，这就是一个团队了。」
一个 Agent 团队 = 一个文件夹 + 一个 schedule。
他的形容：一个真的很难的工程师一周才能干完的活儿，Agent 一天就干完了。一个人就是一家公司。
但这不是“一键生成”，不是甩手掌柜。他反复强调一句话：
「我所说的自然语言，是真的手写——不是大语言模型生成的。光你自己一个字一个字敲的自然语言，可能你都至少要敲个几百行。但你自己亲手一个字一个字敲的自然语言的数量——几乎可以等同于你对这个项目的控制颗粒度。」
你写得越多，控制得越细。你越偷懒，AI 给你的就是它的缺省值——而它的缺省值，不是你的内容。
* *
五、几万行 .md，就是他的源代码
那这“几万行自然语言”长什么样？
王建硕在节目里给了两段描述——一段泛泛讲程序员的工作目录，一段具体举他做小红书 marketing 自动化项目的目录。
第一段，讲所有程序员的工作目录：
「真正的程序员的工作目录里，至少会有好多个文件夹。一个叫 model，一个叫 view，一个叫 control。然后每一个里面有更多的子文件夹，最后形成一个 project。」
第二段，他具体讲他那个 marketing 项目的目录：
「会有一个叫做'角度.MD'——切入这个推广角度。然后由它再产生一个角度点。」
「然后会有 'VI.MD'——讲整个视觉的东西，红颜色还是蓝颜色，logo 是什么样子。然后会有一个叫做 'voice 的 MD'——规定它以什么样的口吻、哪些词儿可以说、不可以说。」
「这边会有一个叫 platform 的 folder——里面对小红书我是什么样的尺寸、Facebook 应该是什么样的。这边还会有一个叫做 generation 的 folder——里面定义图像怎么生成。」
加起来——几万行的.md和 folder。
每天有一个 schedule 定期执行，从入口往下扫描所有源代码，每小时或每天跑一次。
王建硕的总结：
「这跟我过去 20 年写 C 和 Python 的工作流，本质是一模一样的——唯一的区别是，千万别再去碰代码。」
我后来看着笔记想到一件事——那些 .md 文件其实就是新一代的源代码。不是“AI 写代码的提示词”，也不是“你跟 AI 聊天的备忘录”。
LLM 是新一代的编译器，自然语言是新一代的“汇编”——但人类写的不是汇编，人类写的是 .md。
这也是王建硕为什么不同意徐文浩——徐文浩想治理的“屎山代码”，对王建硕来说是编译产物。你不该在编译产物那一层做治理，你该把时间投到上一层，写更多的 .md。
我自己把这一段总结成一句话送给 PM 朋友——把 PRD 当源代码写。这是新时代的编程。（这句是我自己提炼的，不是王建硕原话。）
* *
六、聊天和写程序，是两件事
我问王建硕：你这套东西，跟我们平时跟 ChatGPT 聊天写代码，到底有什么区别？
他的回答很清晰：
「聊天是一种非常快速的 debug 方法。但它不是你写程序的方法。」
他用一段话定义了“程序”：
「程序，就是确定的、可以被定期或被 trigger 执行的、给你出结果的那个东西。」
它的反面，是每一次都从零开始打开一个窗口、跟 AI 从头聊一遍。
他估算，现在 90% 的人用 AI 还停留在“打开 Python 命令行学语言”那一层——不积累、不沉淀，明天再来还是一样。
「这种聊法你无法积累。你今天写完，明天再敲二十行，你跟前一天的上下文已经接不上了。」
他给所有人留了两句话：普通人要少跟 AI 聊天，多写程序。程序员要少写代码，多写程序。
后面这一句，是给程序员的。
* *
七、抬轿子、车、和驾驶员
我问他：那程序员呢？他们怎么办？
王建硕的判断不太温和——程序员，是这一轮 AI 浪潮里比较危险的一群人。不是因为他们笨，是因为他们太熟练。
他用了一个隐喻：
「我们以为抬轿子是真的力气，是大事儿。是。」
「然后忽然变成车了。车往前走的动力，已经比我们人强很多很多了——我们天然以为'动力这件事不该是车干的'。但其实这就是车该干的。」
「但前提是你必须学会开车。当你只会抬轿子、还没学会开车的时候，这辆车是不好用的——你也不知道把它带去哪里。」
抬轿子的，是过去那批人的工作。教父，是教别人开车的人。驾驶员，是真正驾驭这辆车的人。
程序员现在被困在哪个位置？王建硕的判断是，旧时代教父的位置。
他们的代码能力可以被 AI 完全替代——但他们的驾驶能力，因为各种各样的情感蒙蔽了眼睛，学开车的意愿反而远远低于一个普通人。
他还接了一句更重的：
「很有可能，当周围很多新一代没有学过编程的人，已经把驾驶学得很好的时候——我们现在的程序员，封闭在抬轿这个圈子里面，然后被整个时代抛弃。」
「离新技术越近的产业工人，是越惨的。」
历史上反复出现过这种模式——工业革命淘汰的不是农民是熟练工，互联网革命淘汰的不是文盲是报社的金牌编辑。这一次也一样。
回到徐文浩 vs 王建硕：徐文浩想做的事，本质是把程序员训练成更好的抬轿子的人（治理屎山代码、最佳实践、harness）。王建硕想做的事，是让程序员放下轿子、去学开车。
如果王建硕对——“治理 source code”这件事本身，方向就是错的。你不是在帮程序员，你是在让他们更熟练地做一份正在消失的工作。
* *
八、Token 使用量是硬指标
聊到最后，王建硕给了我一个判断公司有没有真的在用 AI 的指标——只有一个：
「你公司的总 Token 使用量是多少？乘以单价，就是你每天在 Token 上烧了多少钱。这是一个像 GDP 一样的硬指标。」
他自己一天烧多少？两千美金。
「广告兑换很难的——一天要花两千美金，不容易的。」
他说这个指标如果上不去，其他认知都是白谈：
「这个指标如果上不去，其他什么认知都是白谈——因为这个才是真正的衡量。」
「A 组织和 B 组织——我们看一下它的 Token 使用量。这个年代的胜者，就是这么决出来的。」
下面这一句他说得有点重——
「省 Token 这件事，会遮蔽你的双眼。很多人以为我没什么商业判断——觉得我只是不愿意花钱。但你试试——你把钱放开以后，你才发现，真正的瓶颈是你的脑子、你的想象力。」
他后来做了一张海报：「使用 Token 拥抱浪费」。
「如果你不把'拥抱浪费'写在海报上——你很容易以'防止浪费'为名，蒙蔽自己的双眼，看不清我们没有能力使用 AI 的现实。」
「省钱这件事，就像身体上的一个脓疮——你不把它清掉，你看不到真正里面到底是什么问题。你总以为是脓。」
我们这一代人，是在智能稀缺的世界里长大的——脑子是贵的，时间是贵的，工时是贵的。所以我们考虑问题的解法，下意识用“节约”的方式去解决。
但 AI 时代不是。
* *
收口
王建硕这一段，我其实接得有点慢——
因为我一开始想的是“屎山代码该不该治”，听完两个小时之后才意识到，他真正在说的是另一件事：很多事情，我们都在错的层做。
我们花时间把 PPT 写得更好，但其实应该改的是生成 PPT 的那条 prompt。 我们花时间把 to-do list 排得更清晰，但其实应该改的是布置任务的那个早晨的脑子。 我们花时间把今天的输出再雕琢一遍，但其实应该改的是给 AI 的那条自然语言。
王建硕这一段，不只是给程序员的。
是给所有用 AI 的人的。
