Kevin Ma (@kevinma_dev_zh)

说真的, @mattpocockuk 的 grill-me，应该是我使用频率最高，同时也觉得最有用的 Skill 之一。 我在做产品和技术设计时，经常会用它来帮我检查，还有哪些地方没有真正想清楚。 很多时候，大的交互框架、产品流程和技术方向其实已经比较明确了，但往下落到细节，就会发现还有很多模糊的地方。有些是自己遗漏了，有些是之前压根没有想到，还有一些更常见的情况是，AI 已经给出了方案，甚至做出了 Mock UI，我看完却总觉得不太对。 麻烦就在这里。 我知道自己不满意，却又很难立刻说清楚，到底哪里有问题，以及我真正想要的是什么。 这时候我通常会先把目前的想法、目标和已有方案告诉 Agent，然后直接来一句：grill me。 接下来，Agent 就会开始不断盘问我。 它会沿着设计中的一个个分支继续往下问，把那些原本模糊的地方一点点挖出来：这个功能到底解决什么问题？这个状态应该怎么处理？用户为什么要在这里做这个动作？两种方案之间你真正看重的是什么？ 很多问题，我其实从来没有认真想过。 而在一轮轮回答这些问题的过程中，原本只是脑子里一个模糊的感觉，会逐渐变成非常具体的产品决策。 这也是我觉得 grill-me 最有价值的地方。 有时候你缺的并不是 AI 再给你一个方案，而是有人不断追问，帮你把自己真正想要的东西想明白。

为什么“软件工厂”会失败？ Dex 这篇《Why Software Factories Fail》第二部分，核心观点很简单： 别把需求扔给 AI，等它一次性写完几千行代码，再指望最后 review 一下就能上线。 至少在今天，这条路大概率会把开发效率从“写代码”转移到“清理 AI 产生的混乱”。 --- 很多人期待的是： “我描述一下需求，模型自己做完，代码自然能长期演化。” 但现实是，模型在局部任务上很强，在长期维护代码质量、理解隐性约束、处理架构取舍上，依然不够可靠。 所以问题不是要不要用 AI。 问题是：人应该在哪些环节保留判断力。 --- 作者的答案是：把 review 前移。 与其等 AI 写完一大坨代码后，再花几个小时改 PR；不如在写代码前，先花 30 分钟把关键问题想清楚。 这不一定让你 10 倍、100 倍更快。 但很可能让你稳定地快 2–3 倍，而且不会留下一个越来越难维护的代码库。 --- 一个更稳的流程，可以分成四步： 1. 产品设计：先说清楚用户到底有什么问题，什么结果算成功。能画界面就不要只写几段模糊文字。 2. 系统架构：明确服务、接口、数据模型和存储之间怎么协作。 3. 程序设计：继续往下细化到类型、函数签名、调用链和文件结构。这里最容易被忽略，但恰恰决定 AI 写出的代码会不会跑偏。 4. 垂直切片开发：每次只做一个能端到端验证的小闭环，而不是先写完数据库、再写服务层、再写 API、最后才打开前端看结果。 --- 所谓“垂直切片”，就是尽快把一个最小功能跑通： 先定义接口，返回 mock 数据； 然后让前端接起来，在浏览器里看效果； 再逐步接入服务、数据库、业务逻辑和异常处理。 每走一步都能验证，也都能及时纠偏。 这比一次生成 2,000 行代码，最后才发现方向错了，要便宜得多。 --- 作者还有一句很值得记住： 你不是 PR 太多，而是坏 PR 太多。 好的 PR 并不难 review。 因为关键决策早就在产品、架构和程序设计阶段对齐了。最后的代码只是把已达成共识的方案实现出来。 真正痛苦的是那种“一次性 AI 生成”的 PR：看起来量很大，但其中 20%、50%，甚至更多都需要返工。 --- 所以，AI 编程真正的杠杆不是“让模型替你思考”。 而是把人从重复劳动里解放出来，让人把注意力集中在更高价值的事情上： 需求是否正确； 架构是否合理； 程序结构是否清晰； 每一步是否真的在朝正确方向前进。 --- 一句话总结： 别追求让 AI 黑箱式地把软件做完。把 AI 放进一个有清晰约束、频繁验证、持续纠偏的开发流程里，才更可能真正变快。 —- 如果你想要阅读原文，推荐你使用 SentiaRead 来阅读这篇英文文章。 你可以直接复制链接导入到 SentiaRead 里面，或者使用浏览器插件。这个工具随时可以根据上下文语境来查询不认识的单词，或者把复杂的句子重写成简单、容易读懂的句子

这一点我是同意轮子哥的：开发不仅仅应该是全栈，不仅要做测试，还应该对上线过程以及上线之后的跟踪负责，这才是“真全栈”。避免无谓的沟通和商量，才是最高效的。 举个例子，以前我的团队有好几个小伙伴都能够独当一面。我们当时是怎么做的呢？ 这些成员是直接对接产品经理的，负责某一个模块或某一块业务。他们会全权负责从需求的讨论、评估、评审，到开发，再到上线过程以及上线之后的跟踪和问题处理。 这种模式的效率非常高： 1. 开发者对整个业务非常了解，对线上的运行情况也很熟悉。 2. 在业务开发和迭代的过程中，他们能提前预想到线上生产环境可能会出现的一些情况。 3. 团队整体的交付质量和开发效率都非常高。 现在到了 AI 时代，我觉得更应该是这样： * 业务层面：没有必要再刻意划分专岗去分前端、后端、运维和测试了。业务开发应该是从前到后、从头到尾的“真全栈”。 * 基建层面：只有做基础设施的同学才需要分专岗。专岗的同学把基建做好，这样业务同学去做全栈时才会比较容易。

订阅了 Lenny's Newsletter 的朋友们，还记得之前 Lenny 向会员开放了所有 300 多篇 newsletter 文稿和 podcast 字幕稿吗？ 这么优质的资源千万不要浪费了，让 Fable 5 给你基于这些优质内容，写一个超级顾问 Skill， 也可以拆分多个场景化的 Skill。会非常爽的。 数据下载地址：

给 SentiaRead 移动端和桌面端增加了 YouTube 视频观看功能，和播客一样边听边看字幕，遇见不懂的词汇随时查，并加入生词本。 还在打磨，即将发布。

字节发布了新的豆包大模型 Doubao-Seed-2.1-Pro，我拿它写了几轮代码，帮大家看看实际是什么水平。 一段 prompt，让它做一个完整的产品落地页，hero、桌面 app mockup、价格表、FAQ 全在，一把就跑起来了。 入口很简单：下载 TRAE Work CN（免费），模型选 Doubao-Seed-2.1-Pro。 下面几个案例一个一个说：内容系统产品落地页制作、VLM 界面还原、failing test 自定位自修、3D 小游戏自测自修。

这篇文章最近很火，被众多大佬转发，有 400 多万的曝光。 强烈推荐看一看这篇文章。 使用 SentiaRead 浏览器插件阅读英文，太舒服了。既能学知识，又能积累词汇量。

鼓励每个人都努力用上 Claude Max 和 ChatGPT Pro ，不用纠结哪个好。 两个都很好，多在工作生活中使用，也不用纠结一定要把额度消耗完才睡觉。 几个月之后，你一定会感到非常超值。

我从去年开始至今的策略一直没有变，要编码，永远用最顶级的工具和模型，否则就是纯粹浪费时间。 不是说其它模型完全不行，从能力特长、稳定性和价格方面，把它们用到合适的场景是很有必要的。 对于 thinking, design, coding, 用最好的模型和工具，虽然贵点但节省时间，实际效益是更高的。

Luo 哥的分享跟我自己的观点和感悟挺一致的。我之前也看过”12个月做12个产品”这种模式，想想还是觉得不太适合我，但里面有一点值得学的，就是执行力。 我可能还是偏”古典”一点。SentiaRead 这款产品不是拍脑袋想出来的，而是我长期学英语积累下来的——用过市面上一堆现有产品，等 AI 技术成熟之后，自己思考出来的东西。 开始做之前我也担心会不会闭门造车，所以挺认同 ShipFast 那套理念：快速把东西做出来推到市场上看反馈，别一个人闷头搞太完美，但核心功能要可用。 我在正式动手之前先发了一条帖子，分享了自己的痛点和想做的东西。那条帖子的互动数据挺好的，说明不止我一个人有这种痛点，大概率还有不少人和我需求一样。 基于这个判断我就开始做了。我的开发和发布速度其实不算快，多多少少受完美主义影响，但整体上我清楚：不能追求太完美，要尽早把 MVP 做出来看反馈。 我用的是拉微信群这种比较老派的方法，喜欢直接跟用户聊。我工作和生活分得没那么开，所以也不太在意晚上很晚被用户打扰。我挺享受通过这种交流去观察他们怎么学英语、痛点在哪、习惯跟我的理念差在哪。 这款产品其实更多是围绕我自己的需求和出发点打磨的。这样吸引来的用户，本身也是有类似痛点、认同同一套学习理念的人。在这个基础上，我再去观察大家更细的习惯和需求。 中间也碰到过一些我一开始不太认同的方法，但慢慢我发现，学习方法没有绝对的对错，更多是看它离我的产品理念和定位偏差大不大、能不能帮到不少人。 产品就是一个节点一个节点往前推。内测结束后正式发布，观察大家的付费意愿——我发现还真有不少内测用户愿意付。 虽然挺多人觉得我定价不低，但发布当周就有人付了。让我意外的是，还有一些不在内测群的用户，看到我分享的帖子去体验了一下，直接就下单了。这样一个个事情给了我持续迭代的信心。 我的方法比较”古典”，就是这样一步步推进、验证、拿反馈。用自己舒服、做得到的方式来做产品。如果不是围绕我自己的观察和需求出发，我可能很难洞察到到具体的痛点，也很难很好地解决它。