宝玉

@dotey · 2026-10-04

我记得半年前我说自己不怎么 Review PR 了，评论区很多人不认同，觉得这样不靠谱。现在再看，不 Review PR 的人越来越多。比如我刚看的这期播客，在 SpaceXAI 做 Grok Bot 的 Lauren Tan，一个月合并 2500 个 PR，也是不逐个 Review 的：晚上让 AI 自己检查、自己合并，第二天早上她再抽查。 不 Review 不等于不管质量，她靠另外两个办法来保证： 一是让 AI 能像真人用户一样把程序用一遍，自己发现问题； 二是给代码定下很多规矩，让 AI 很难写出烂代码。 她把自己这套做法写成了一组 Skill，公开了出来，叫 pstack。 顺便说一下，这期播客的主持人 Matt Pocock 原本是知名的编程课讲师，他公开的技能库在代码托管网站 GitHub 上有二十多万个星标，是最受欢迎的技能库之一，所以这期算是两位同行对谈。Lauren 之前在 Meta 做网页开发框架 React，今年 3 月加入 AI 编程工具公司 Cursor；Cursor 今年 8 月被 SpaceX 收购，并入旗下的 AI 部门 SpaceXAI。 根据播客的内容，我把 Lauren 的这套做法简单总结一下，我自己的点评在结尾处。 一、先让 AI 能检查自己干的活 Lauren 说，就算不用她的 pstack，每个人最该有的一项技能也是“验证”：给 AI “手和眼睛”，让它能把自己写的程序跑起来，像普通用户一样点一遍，看看结果对不对。 这是她吃过亏之后得出的结论。今年 4 月她在 Cursor 解决一个窗口卡顿的问题，一开始全靠手工：她自己去看各种性能数据，再把看到的转述给 AI，AI 改完她再去看。她形容自己成了 AI 和检测工具之间的“人肉中转站”。她在 Cursor 写的第一个技能就是验证。在这之前，AI 看不到自己改动的效果，只能等她来回传话；有了验证，AI 可以自己改、自己看结果、不满意再改，一轮一轮往下做，不需要她守着。现在她所在的团队里每个产品都配有这样的验证技能，全团队都在用。 做这个技能时她还总结出一条原则：工作里有的部分需要动脑判断，有的部分只是照章办事，照章办事的部分应该写成固定的程序，只把需要判断的留给 AI。起因是她发现，每个 AI 在检查前都要自己从头写一遍检查用的小程序，各写各的，有的能用有的不能用，用完就扔，又慢又浪费。她把这部分做成一个现成的工具，所有 AI 直接调用。 二、AI 反复犯的错，去改规矩，不去改 AI Lauren 不喜欢“软件工厂”这个流行说法，她更愿意把自己的工作比作经营一家米其林餐厅的后厨。主厨不用亲手做每道菜，但要安排好整个厨房：食材什么时候进、怎么存，每个人用什么工具，菜按什么流程出。工程师现在也一样，不再亲手写代码，却仍然要对结果负责。她认为工程师现在最重要的工作就是把这个“厨房”布置好。没花时间布置的人，信不过 AI 的产出，只能盯着它一步步干，忙到没空改进工具，就像一直拿钝刀切菜。 她举了自己的例子。Grok Bot 最早几版的代码挤在八个巨大的文件里，每个至少一万行，AI 加新功能时就接着往里塞，越塞越乱。她后来定了规矩：每个功能必须放在自己单独的文件夹里，做一件事只允许一种写法，不合规矩的代码会被自动检查拦下来。这样 AI 加功能时不用多想，按规矩放就行。她的习惯是一直观察 AI 在哪里出错，每看到一次就问自己：能不能加一条规矩，让这种错以后根本写不出来。 不逐个检查，靠的也是这套办法。她说，开了几家餐厅的老板不可能尝每一道菜，只能抽查。她每天挑一些改动仔细看，如果只是偶然出错就算了；如果好几个 AI 都在走同一条捷径，说明该改的是规矩和工具。她的 pstack 里有一个全自动模式：每次改动都会派出一批专门负责检查的 AI，把程序打开到处点，找出问题就自己修，反复到没问题再合并。早上她翻一遍改动记录，发现不对就撤回，再补一条新规矩。 她说第一次让 AI 整夜自己合并代码时很害怕，担心半夜把线上产品弄坏，现在反而睡得更好。她也提醒，走到这一步很难，要花大量时间观察和调整，装上 pstack 并不能直接做到。Matt 问，如果改动是没法撤回的，比如会丢数据，或者是医疗、金融这类领域怎么办？她说这取决于工作成果能不能被程序自动检查，软件大部分可以，很难自动检查的领域就很难这样做，她自己也没有答案。 三、2500 次改动从哪来：她不再当传话的人 这 2500 次改动并不是她发起了 2500 次对话。用户反馈的问题散落在聊天工具、邮件和社交媒体上，以前要靠她自己去看，再转述给 AI。现在她让 Grok Bot 来盯这些渠道。Grok Bot 是 SpaceXAI 今年 8 月推出的产品，是能登录邮箱、聊天工具等各种应用、替人办事的 AI 智能体。它一发现新的问题反馈，就转给一个负责“协调”的 AI。这个协调者自己不写代码，只负责拆分任务、分派给其他 AI、盯进度，相当于她的后厨主管。 为什么不直接一个问题派一个 AI 去修？她说，一批反馈往往出自同一个根源，分开修会重复劳动，也看不出真正的毛病在哪，放在一起看才看得出来。她现在同时开着十多个这样的协调者，各管一摊。她一直在问自己一个问题：哪一步还卡在我身上，AI 为什么非得来问我？然后想办法教 AI 自己去拿到真实的信息。 她也说明，2500 次改动里新功能不占多数，很多是整理代码这类维护工作。 四、懂行的人更吃香，哪怕不会写代码 Matt 问，大家都靠 AI 了，专业知识是不是不值钱了？Lauren 的看法相反。模型越来越强，卡住人的已经变成你能不能把自己想要什么讲清楚。所以她认为，医生、律师这类在某个领域懂得很深的人，只要稍微懂一点技术、会用 AI 智能体，就能做出很好的产品。 两人都认为，技能没有什么神秘的，就是把自己的做事流程写成文字。Lauren 建议回头翻自己和 AI 的聊天记录，找出那些自己反复纠正、反复插手的地方，把它们写成技能或规矩。别人的技能可以拿来拼着用，但每个人最后都该有一套自己的，就像厨师换了餐厅也会带着自己的刀。 五、最后 很多人看完这期访谈会觉得，以后自己也可以像 Lauren 那样不 Review PR 了，装上她的 Skill，让模型帮忙验证一下就行。我自己现在的做法和她差不多，每天也有大量 PR，也不 Review。但我的建议是先别急着学她怎么做，先弄明白她凭什么能这么做。 1. 你能不能用上最好的模型，Token 够不够 在用上 Fable 和 Opus 5.5 之前，AI 写的代码我是不太放心的；用上之后，我才真的敢让 AI 去写而不怎么 Review。模型能力很重要，能力没到，就先别想这件事。 还有成本。像我这样没有大公司可以依靠的，得自己掏钱买 2 个 Claude Max 20x 账号，还得省着用。Lauren 在大公司，不用考虑 Token 消耗，全程用最好的模型、开最快的模式都没问题。 不过也别着急。Fable 这个级别的模型，也许半年以后就能像现在的 DeepSeek V4.1 Flash 一样便宜，人人用得起。梁圣加油。 2. 不能完全依赖 AI 的验证 哪怕现在 GPT-6 操作电脑的水平已经超过真人了，让它去做验证，也只能替代一部分，不能真的全交给它，自己还是要看。 可以做的是把那些手动重复做的事情，一点点沉淀成 Skill 和自动化脚本，把体力活解放出去。 3. 方向得靠你自己的专业来指 再聪明的 AI，也没办法替你决定该往哪个方向走。就像给车子装上火箭发动机，也得你来告诉它往哪开，走偏了要及时调整，不然跑得再快也是南辕北辙。 做软件也一样。你不能指望一句提示词做出一个淘宝。你得先做一个能发商品、能浏览的小网站，再加上用户注册，还得区分买家和卖家，然后是支付和安全，功能做完了还要扛得住很多人同时用。稍微复杂一点的软件，都没法完全依赖 AI，要人去拆解、规划，分成一个个小版本、小里程碑，做完要验证，出现偏差要重新指方向。甚至做着做着，你自己的想法都变了，AI 不可能知道你真正想要的是什么。 所以就像播客里说的：模型越来越强，卡住人的已经变成你能不能把自己想要什么讲清楚。 4. 不一定要用他们的 Skill，但要学着把事情交给 Agent 去做 Matt 和 Lauren 的 Skill 都很受欢迎，但你不一定要用。 一方面，软件工程的基础知识，现在的模型已经学得很好了。Lauren 在播客里也说，去年的 Skill 还得写清楚具体该敲哪条命令，现在这些都可以删掉，只留流程步骤，Skill 会越写越短。 另一方面，他们的开发流程和环境，跟你的很可能不一样。Lauren 的 Skill 都是从她自己的工作里总结出来的：验证技能来自她当“人肉中转站”的那段日子；另一个叫 recall 的技能，来自她每次开新对话，都得把上一个对话里的背景再讲一遍。 所以更重要的是从你自己每天的开发流程出发。那些还要你手动操作的环节，尽可能交给 Agent 去做；Agent 做顺了，再把它的操作过程沉淀成 Skill，反复迭代优化。 如果不知道从哪里下手的话，可以参考 Lauren 的办法：翻自己和 AI 的聊天记录，找那些你反复纠正、反复插手的地方。这样迭代出来的 Skill 才真正适合你，用她的话说，每个厨师都该有一套自己的刀。

jiangkoumo

@jiangkoumo_ · 2026-10-04

HN 181 分的热帖《Agents Don't Need Memory. They Need Documentation.》，直接把市面上的 Agent 记忆插件批判了个遍：给模型挂向量数据库检索历史对话，往往像在 RAG 里抽奖一样 这类插件的运作套路很固定：切碎对话记录、存进向量库、每次交互检索 top-5 相似片段塞进上下文。为了给召回打补丁，插件又堆出夜间重写记忆的后台守护进程、去重与重排，持续烧掉大量 token。 依赖相似度召回有几个无法避免的缺陷：向量距离近不代表信息仍然有效，代码库一旦变更，翻出来的历史片段很容易误导模型，而且上万条向量埋在 SQLite 里，哪条失效、哪条在起反作用，人类根本无法审计发现 而人类团队是不会为了确认接口约束去重看三年前的会议录像 文章主张把 Agent 的执行链条，从“提问、生成、遗忘”换成“查阅、构建、更新” Agent 现在需要的是包含设计规范、决策记录和背景索引的 Markdown 文档库。执行前先读文档获取完整上下文，执行后顺手更新过时内容。所有记录都在 Git 版本控制里，随时能读、能审、能回滚

陈大黄

@realchendahuang · 2026-10-06

三年前大语言模型刚席卷全球时，整个技术圈处于一种既兴奋又处处受限的尴尬状态。 当时整个行业公认有几道极难逾越的技术关卡： 模型的记忆窗口太短，输入稍微长一点就记不住； 底层计算架构太吃算力，长文本计算量呈几何级数爆炸； 调用一次的账单开销居高不下，企业根本不敢放开给业务使用； 而所谓的自主智能体只要多跑几步，就会在概率偏差里彻底失控。 三年过去，回头梳理这些难题的演进过程，会发现行业真正走通的解法极具启发性。 许多当年被寄予厚望的数学构想，在真实工程中被现实物理规律上了一课； 而那些看起来无法逾越的成本与算力障碍，反而被极为扎实的底层工程逐一推平。 第一个经历深刻演变的方向，是上下文长度与知识检索。 在早期阶段，大模型处理文本的基本单位叫 token，通常几个英文字符或一个汉字对应一个 token。当时主流模型的上下文窗口普遍只有几千个 token，连一本薄薄的技术手册都塞不进去。更麻烦的是，当输入文本变长时，注意力机制会出现中间信息遗失现象，也就是模型只能记住开头和结尾，中间的大段内容会被直接忽略。 为了绕开这个瓶颈，全行业最流行的解法是检索增强生成，也就是 RAG。 这套机制的逻辑是先做文本切片，把一份几十万字的长文档按段落强行切成几百字的小碎片；再利用向量模型把每个小碎片映射到高维坐标系里，存入专用的向量数据库。当用户提问时，系统把问题也转成向量，去数据库里比对几何距离，捞出字面最相关的三五个碎片拼进提示词，最后递给模型作答。 很多团队把这套切片与向量匹配技术视为自身的核心资产。 然而真正在复杂业务场景里跑起来，这套方案暴露出了根本缺陷。 真实世界的业务逻辑是环环相扣的整体。一旦把长篇文档硬生生切碎，上下文之间的因果链条就被物理切断了。只要问题涉及跨章节的逻辑推演，或者需要对全文做全局归纳，向量检索立刻失效，拼出来的碎片往往前言不搭后语。 真正让长文本处理走入正轨的，是硬件显存带宽的提升，配合工程上的一项核心机制：前缀缓存，也就是 Prefix Caching。 大模型在处理前文内容时，会把注意力层产生的中间计算结果保存为键值缓存，即 KV Cache。在过去，每次向模型提问，哪怕前面几万字的项目文档完全没变，系统依然需要从头重新计算整篇文本的注意力矩阵，算力开销极大。 而前缀缓存机制允许系统把公共文档计算好的键值缓存常驻在显存里，后续提问只需要针对新追加的几十个字做增量计算。 当超长文本的单次推理开销被大幅度压缩，原本复杂的切片管道迅速失去了生存空间。直接把成百上千个代码文件整本喂进百万级上下文窗口，让模型自己在全局语义里完成推演，效果远比在外围拼凑碎片干净稳定得多。 第二个遭遇现实撞墙的方向，是寻找颠覆 Transformer 的新架构。 目前主流大模型几乎全部基于 Transformer 架构，它的核心机制是自注意力机制。这种机制要求输入文本里的每一个词，都要跟上下文里的其他所有词逐一计算关联度。 这意味着文本长度一旦翻倍，计算量就会呈四倍、甚至成百上千倍地剧烈膨胀，这在数学上被称为二次方复杂度。 面对这种随着长度暴涨的算力消耗，学术界一直试图寻找更轻巧的替代品。研究人员设计出了许多状态空间模型，比如 S4、Mamba 等架构。这类模型在数学形式上具备线性复杂度，文本长度翻倍，计算量仅仅线性翻倍，数学公式看起来极其优美。 然而三年过去，处于行业最前沿的模型，依然牢固地建立在 Transformer 及其变体之上。 理论上更省算力的新架构之所以没能胜出，核心在于现代计算芯片的物理特性与生态规模。 现代 GPU 芯片的核心运算单元是张量核心，也就是 Tensor Core。这个硬件结构在物理层面上，就是为了高密度、超大吞吐的规则矩阵乘法量身定做的。 Transformer 虽然数学计算量大，但它的每一次计算都是规规整整的大矩阵运算，刚好能把显卡的硬件流水线全速跑满。 相反，那些在数学上复杂度更低的线性模型，在推理过程中往往包含大量细碎的状态循环与递归更新。这些操作在计算核心与显存之间频繁倒腾数据，硬件调度开销极高，实际跑起来很难吃满芯片的峰值性能。 再加上全行业在过去数年里，围绕矩阵乘法积累了数以万计的算子编译优化与集群调度工具链，一个在纸面上更轻巧的算法，很难轻易击败与万亿级硬件生态深度绑定的成熟工业架构。 第三个让技术真正普及的变化，是推理成本与模型角色的演进。 在大模型问世初期，千亿参数规模的模型加载进显存需要巨大的集群支持，单次调用的硬件折旧与电费成本极高，企业面对生产级账单往往望而却步。 成本能够快速平民化，首先得益于模型量化技术。 计算机最初用十六位甚至三十二位的高精度浮点数来记录模型权重，工程师后来发现，通过量化算法把这些参数压缩成八位甚至四位整数存储，模型的综合推理能力几乎没有明显损耗，但对显存的占用直接降到了原先的几分之一。 其次是知识蒸馏技术。通过让千亿参数的庞大教师模型输出高质量推理数据，去指导训练几十亿参数的小型学生模型，让轻量模型也学会复杂的逻辑推导套路。 但更深层的降本逻辑，来自于架构设计上的任务分流。 早期大家习惯用一个昂贵的全能模型去承担所有工作，这就相当于雇佣顶尖学者去从事端茶倒水的体力劳动，哪怕只是改两个错别字，也要支付极高的咨询费。 现在的工程实践转向了清晰的角色分工： 日常绝大部分文本提取、格式规整、语义分类与轻度代码补全，直接分流给经过蒸馏的小型模型或者响应极快的轻量版本。这些模型运行开销极小，毫秒级返回结果，单次成本低至几厘钱。 只有当遇到涉及复杂边界、多步骤推演的疑难排查时，系统才会把长链条思考的大模型调动出来。 按任务复杂度合理分流，才让大模型的大规模商业化落地真正具备了经济可行性。 第四个方向，是智能体从虚火走向务实。 三年前开源社区狂热追求全自动智能体，也就是 Autonomous Agent。 当时的设想是给模型一个宏观目标，让它自己打开浏览器翻找网页、调用接口、发送邮件，自主解决一切问题。 但在真实业务里跑一圈就会发现，大模型本质上是一个基于概率分布的预测系统，每推演一步都有极微小的误差概率。如果让它完全脱离约束连续执行数十步，这些微小的误差会以指数级累积放大，最终导致程序卡死在死循环里，或者产生彻底偏离意图的混乱输出。 今天真正在生产环境中稳定干活的编程智能体和流程系统，转向了极为务实的工程路径： 首先是渐进式披露。系统不再试图把成百上千个复杂的外部接口说明一股脑塞进提示词，而是只给模型提供精简的目录清单，由模型在需要时自主按需查阅具体文档。 其次是命令行沙箱化。系统放弃了让模型去识别花哨的网页界面和模拟鼠标点击，而是直接为模型提供标准隔离的命令行沙箱环境。大模型在训练阶段学习过海量真实代码，让它编写标准的 Python 或 Bash 脚本去直接调用底层接口，执行确定性远高于图形交互。 最后是引入了测试闭环。由严谨的代码测试套件充当裁判，模型每写完一段逻辑，系统立刻在沙箱里运行自动化测试；一旦报错，控制台输出的真实错误堆栈会被直接喂回给模型，辅助它针对具体报错逐行修复。 让大模型留在方案推导层，把具体的物理执行交还给严格的代码沙箱，智能体才真正具备了工程可用性。 而在过去几年列出的所有难题中，真正至今依然难以在模型内部完全消除的，依然是幻觉问题。 大语言模型的根本工作原理是自回归预测，也就是根据已经出现的上文序列，从词表概率中挑选下一个最合理的字词。它的内部没有关于客观物理世界的硬性事实数据库，只有字词连贯出现的统计规律。既然依赖概率推测，就必然存在推测失误的可能。 试图单靠优化提示词让模型保证客观，或者让大模型自己去复核自己的输出，在本质上依然是在拿概率纠偏概率。 这也是为什么在过去三年里，大模型在编程和自动化脚本领域的发展最为扎实。 在纯文字论述的语境下，似是而非的幻觉很难被人一眼识破；但在计算机的世界里，代码具备绝对的诚实。 语法写错一个字符，编译器当场报错；逻辑出现一处偏差，测试用例立刻拒绝通过。 正是代码执行环境这种非黑即白的确定性反馈，给大模型的概率飘移套上了最坚固的物理缰绳。 梳理这三年的技术演进脉络，会发现一条清晰的轨迹： 行业并没有像早期狂热者设想的那样，迅速出现无所不能的通用神迹；但也没有被理论上的数学复杂度困死在原地。 能在生产线上长期沉淀下来的，始终是那些能够与现有硬件生态深度咬合、用确定性的工程机制不断包容概率波动的务实方案。 看懂了这些在真实业务里摸索出来的物理边界，面对层出不穷的技术新概念时，自然能分清哪些是纸面上的概念包装，哪些是真正能放进自己工具箱里的生产力底座。 一手出处： https://huyenchip.com/2023/08/16/llm-research-open-challenges.html

陈大黄

@realchendahuang · 2026-10-07

经常用 AI 写代码的朋友们，可以了解一下领域驱动设计（DDD）这个概念。它的英文全称是 Domain-Driven Design。 平时做开发，很多人习惯先建数据库表、写增删改查，然后把一堆复杂的业务判断散落在控制器和前端组件里。一旦需求变多，字段和逻辑到处缠绕，改一个地方就坏一片。 DDD 的核心思想，就是把重心从底层的数据库和框架，拉回到真实的业务本身。在动手敲代码之前，先理清楚现实业务里的概念、规则和流转关系，让代码直接反映业务本身的逻辑。 在传统软件工程里，落地 DDD 通常围绕三个核心动作展开。 第一个是建立统一语言（Ubiquitous Language）。 在整个项目里，把所有的业务名词定下唯一标准。同一个业务概念，不能在需求里叫客户，在代码里叫用户，在数据库里又叫账号。统一了词汇表，沟通损耗直接抹平。 第二个是划分限界上下文（Bounded Context）。 再大的项目，也不能揉成一团。按照业务职责把系统切分成几个明确的独立边界。比如电商项目里，商品展示、库存流转、支付结算各自是一个独立的上下文，每个上下文只管好自己的规则，跨边界调用只通过清晰的接口契约进行。 第三个是构建充血的领域模型。 不要写那种只有字段、没有业务行为的空壳数据类。把属于某个实体的业务校验、计算逻辑和状态流转，直接封装在实体内部，让核心业务逻辑保持稳定。 搞懂了这套心智，在 Vibe Coding 时代跟 AI 协同就会顺手得多。 大模型写具体代码的速度极快，但它本质上是个概率系统。你给它一段模糊的需求，它顺着概率去猜，必然会胡乱生成一堆缺乏边界的胶水代码。 结合 AI 使用 DDD，最舒服的姿势是做好分工：人类负责搭建领域模型与划定边界，模型负责高效地补全具体实现。 具体的最佳实践可以总结为以下四步： 第一步，建立全局的领域词汇表与契约文件。 在项目根目录的规则文件或者系统提示词里，花几分钟把核心实体名词、状态枚举和核心行为定义清楚。给大模型一套毫无歧义的统一语言，它在命名变量、写类型定义和生成接口时就不会前后打架。 第二步，按照限界上下文限制 AI 的注意力范围。 不要试图让大模型一次性通读并理解几万行的大工程。按照业务边界把代码组织成清晰的模块。每次派发任务时，只把当前上下文里的实体定义、接口契约和相关文件喂给模型。把上下文体积控制在极小范围，模型的幻觉和误改率会大幅下降。 第三步，明确要求模型把规则内聚在实体内部。 给 Agent 提要求时，限制它不要在外层写一堆零散的条件判断补丁，而是把业务规则封装在对应的领域实体里。外层的调用代码越干净，后续让模型修改逻辑或者新增特性时，波及的范围就越小。 第四步，用行为测试作为确定性契约。 在让 AI 敲具体实现之前，先把领域实体的行为测试用例立起来。跑测试通过了才算交付。用严格确定性的单测和编译器，把大模型的概率漂移稳稳按在轨道里。 人类理清概念与划定边界，AI 负责快速落地代码。

uudon

@uudonX · 2026-10-04

很多人觉得业务开发就是 CRUD，做基础设施才有技术含量。这就是大多数人看不起业务复杂度的原因。 订单取消之后，库存、优惠券、支付、退款、结算分别应该发生什么？ 如果只取消一部分，又该怎么算？ 接口本身可能很简单，规则之间的关系很复杂。 能把业务约束转化成清晰的模型，让变化有地方落，错误有办法查，这里面有很扎实的工程能力。

程序员鱼皮

@yupi996 · 2026-10-07

生怕你不知道 > 网页上那些滚动动画，其实都有专门的名字，直接报给 AI 比费力写提示词更好使！🤫 1️⃣ Scroll-triggered，滚进屏幕就自己播完，比如卡片淡入 2️⃣ Scroll-linked，滚多少动多少，比如顶部的阅读进度条 3️⃣ Parallax，背景比前景滚得慢 4️⃣ Sticky，滚到顶就钉住，比如通讯录的字母标题 5️⃣ Scroll Snap，一次停一屏 6️⃣ Horizontal Scroll，往下滚，卡片横着走 下次跟 AI 说「导航栏用 Sticky，首屏背景做成 Parallax」就行！

程序员鱼皮

@yupi996 · 2026-10-04

📚 论文原文在这 https://arxiv.org/abs/2609.00006 论文最后还给了一个 90 行左右的 Python 版最小 Agent，核心就是一个 while 循环加 4 个工具。