← 主页 NO.41
专栏 · AI 时代的产品经理 › 第 41 期 · AGENT 工程 · 收录于 2026 年 8 月 16 日
如何打造 agent 原生产品——Mike Krieger
双人对谈 · 本期速读电台 00:00 / 38:37
TL;DR · 三句话
- 一AI 时代真正变难的不是「动手建」而是「想清楚该砍什么」。 嘉宾原话：「今天的 model 很擅长往产品里加功能，但不太擅长判断该砍掉什么」——而「该砍什么」的直觉只能靠大量真实世界使用慢慢磨。Claude 能在几小时内把产品从零做到头（zero to end，不是 zero to one），但它一路替你拍了一大堆板。→ 详细
- 二产品第一原则是 agent-native（智能体原生）： 凡是用户在 app 里能做的事，agent（能自己规划并动手干活的 AI）也必须能做，且每个 primitive（最基本的功能积木）都要被模型「知道」并「可修改」。这个词 Krieger 坦言是从 Claude Code「偷」来的。→ 详细
- 三在模型每 3–6 个月就逼你「扔掉一半产品」的节奏下，团队要刻意保持小、要愿意整段重写，还要把企业客户当成「会一直往前开的列车 + 沿途给你开关」来服务。→ 详细
01
嘉宾与开场
- 主持人 Dan Shipper（Every 创始人、《AI and I》主理人）对谈 Mike Krieger——Instagram 联合创始人、现任 Anthropic 首席产品官 / Anthropic Labs 负责人。贯穿全场的问题：当做产品的底层基底（substrate）彻底变了，哪些变简单、哪些变难、哪些没变。→ 详细
02
核心金句：模型擅长加功能，不擅长想清楚该砍什么 🎯
- 全片第一句、也是招牌判断：「今天的 model 很擅长往产品里加功能，但不太擅长判断该从产品里砍掉什么（good at adding features, not necessarily good about figuring out what to cut out）」——判断「该砍什么」不是靠想，得靠大量真实世界使用一点点磨出来。→ 详细
- 他特意纠正常用说法：模型能几小时把产品做出来，「不只是 zero to one，而是 zero to end（直接做到头）」——一口气端出一个看起来完整的产品。代价是「它一路上替你做了一大堆决定」，而「什么才真正该放进去」的直觉只能靠时间积累。→ 详细
- 由此的反直觉观察：即便在 AI 加速开发的时代，也没冒出多少现象级消费产品——因为「你到底想对这个世界做出什么样的干预（what sort of intervention you want to make on the world）」仍要花时间打磨。他称之为 2026 年软件设计的「艺术与科学」。→ 详细
03
思想实验：让 Claude 两小时重做 Instagram 前身
- Instagram 前身 Bourbon 做了近一年没起来，转型后「三个月做出 Instagram」。几周前 Krieger 真做了实验：让 Claude 把 Bourbon 整个重做，「大概两小时就功能齐全」，模型还主动加了滤镜——Bourbon 当年根本没有滤镜，那是后来 Instagram 才加的。他的解读：模型「知道这个产品最终会演变成什么样」。动手建的部分如今轻松得不可思议；但当年走弯路把产品「搞得过于复杂」的那一年，恰恰教会了他「删」。→ 详细
- 花絮：当年 Kevin Systrom 一周做完 V1 全部滤镜、Krieger 做其余部分；他自曝「熬到凌晨四点、睡到中午」的天然作息。→ 详细
04
「室内长树」+「扔进大结局」：一次性甩出整棵树，对做的人和用的人都是灾难 🎯
- Dan 的比喻一：树若养在室内、不经风吹，长出来就歪、不结实——树生长时「需要这些力来回推它」。映射到产品：开发被「加速得太猛」，本该「一次只做一件事、拿给用户去试」的循序渐进，被压缩成「在室内一下子把整棵树养出来」——你手上突然有个完整的东西，但「没有每一步积累起来的直觉、没经受过经验的检验」。→ 详细
- Krieger 担心的两种坏结果：只图快而不建直觉，「要么做出特别套路、不太可能爆的产品，要么做出没体现你对领域更深直觉的东西」。→ 详细
- 比喻二：过度建设对用户同样是灾难。好产品应像电视剧让你「一集一集认识角色」；过度建设等于把用户「直接扔进大结局那一集」——「等等，这都是些什么、这些人是谁？我却被默认已经掌握了所有背景。」室内树的成因：vibe coding（凭对话让 AI 写代码）太顺，「你噼里啪啦把任务派出去，吃个午饭回来东西做完了」，不断顺手加功能，最后「造出一个功能的矩阵」——临上线才发现难测试、难维护、难解释。→ 详细
- 贯穿全片的原则（原话）：「不是说你能做，就意味着第一版里就该把它放进去（just because you can doesn't mean it should be in the first version）。」→ 详细
05
Proof 案例：Dan 亲身踩坑，推倒重来只留一个链接 🎯
- Proof = Dan 做的 agent-native 协作式 markdown 编辑器。前几版失败：因为「vibe coding 实在太好玩、太上瘾」，他总忍不住加功能，结果「造出一个四不像（monstrosity）」——亲身踩中「室内长树」。→ 详细
- 转折来自 Every 另一个产品 Monologue（JM Naveen 负责的极简语音转文字 app）——「极度专注于把一件简单的事做到极好」。Dan 由此悟到：人人都能做产品的时代，管用的是「打磨得特别精致、把自己那件事做到极致好用」的东西。于是他「把那个产品整个扔了，从头来过」，只做一个「可分享的 markdown 链接」——在 Every 内部病毒式传开，正式上线后「一下就爆了」。→ 详细
- 上线的代价（真实感十足）：Dan「整夜没睡修它」12 个小时，内部拉了支「特种突击队（SWAT team）」帮忙，结果还得先给救火队「做入职引导」——连他自己都得「反复跟模型来回折腾把术语定义清楚」才能解释代码库怎么运作。→ 详细
06
Bourbon 的教训 + 重写不再可怕
07
更早上线：Cowork 的 10 天 V1，真实世界接触 > 内测 🎯
- Anthropic「正在学着更早地上线」。内部有支自称「ant footers」的内测队伍，但「这只能帮你走到一定程度，再往后你需要真实世界的接触」——同事永远测不出真实用户会怎么用，「用户绝对还是会给我们惊喜的」。→ 详细
- Cowork 案例：琢磨了很久的产品，一拍板「把我们认为能以最精简方式解决问题的 V1 做出来，10 天内放出去」。「V1 本该或本可以有上百样东西，但它没有」，可它「已经够好用，足以在外面验证出点什么」。他甚至怀疑「再多开发两个月、加 50 个功能」只会「又在搭室内的树——一接触真实世界发现根本没人想要那个，大家想要的是另外那块」。金句收束：「精益创业那些最初的直觉到今天依然在，只是以不同的时间尺度显现。」→ 详细
08
agent-native 的定义与「偷师」Claude Code 🎯
- 第一原则（原话）：「anything a user can do in the app, the agent can do」——凡是用户能做的，agent 都能做。这是 Krieger「用得最多的词」，坦承「基本是从你们（Every 的 Dan）那里偷来的」；Dan 那篇 agent-native 文章被他称为「这一主题的范式级探讨」。范本是 Claude Code：一个 agent，「能在你电脑上做你能做的任何事，且可定制、灵活、可扩展」——「容易上手，又能做出设计师事先没想到的事」。→ 详细
- 非技术用户视角的金句：一位非技术人士对他说——「你们整天聊 agent，但对我来说，就是『电脑现在终于能用了』（computers just work now）。」以前要「知道咒语、敲对命令行、
brew install装好」才能办的事根本没人去做；现在 Claude 替你做，「电脑就感觉像一个与你并肩的工具」。他的定性：这「不只是给新软件加能力，更是把那些本就该存在、却对人极难的功能解锁出来」。→ 详细
09
反面教材 Claude AI + 让软件「自知」 🎯
- 自家对照：「Claude Code 做得好，Claude AI 还需要大量进化。」案例：用户在 project 里建了个 artifact，说「把这个加进我的 project knowledge」，Claude 竟回「好，让我告诉你步骤……」。Krieger 吐槽：「这本该是它能原生直接做的事。」病根：Claude AI 是「2024 年的产品」，「没有从一开始就把『每个 primitive 都该被它知道、能被它修改』烙进去（baked in from the very beginning）」。更下一层级的预告：有些团队的 harness（包住模型、装上工具和循环的运行框架）已能让 agent「修改 harness 本身」。→ 详细
- 「自知」的现身说法：他把 Dan 那篇文章「做成一个 skill」（可复用的知识包），Claude 答「当然，我正在查我那个『做 skill 的 skill』……你得重启一下，走起」——「整个过程里它对自己有认知，这又解锁了非常多能力」。Labs 正攻的真问题：「怎么让 Claude 构建的软件更『懂 Claude』、天生带着 agent-native 意识？」难点是「几十年积累的软件根本不是这样的」。→ 详细
10
模型选型与「模板化 vs skill 化」
- 「Claude 模型在 agent-native 上是最强的，Codex 那类一般没这么好」——因为「模型你不推它一把，它就像传统工程师那样思考」：想要护栏、测试、让用户只有一条路可走，恰与 agent-native 要的「可扩展、超级灵活」相反。→ 详细
- 教模型 agent-native 的第一半（「平淡但值钱」）：给它准备好优秀的范式和模式，关键是找「模板化（固定骨架）和 skill 化（打包成可调用技能）之间的平衡点」。例子：他们做了个 Claude API 的 skill——因为新模型一发布「就不在模型固有知识里」，会出现模型嘴硬「不，我知道你打错字了，那叫 Sonnet 45」的鸡同鸭讲，一个 skill 就省掉。→ 详细
11
验证「保真度」：Claude 自言自语与演练 harness 🎯
- 更有意思的另一半：agent-native 软件「是一种完全不同类型的测试」——「很难写端到端功能测试，因为它本身带着不可预测性」。Labs 反复琢磨的是「怎么提高验证的『保真度』（fidelity of verification）」——让自动测试尽量逼近真实使用。→ 详细
- 趣闻（涌现行为）：他做一个「工作日志、反思」类 agent-native iOS 原型，让 Claude 去交互，结果 Claude 在 app 聊天功能里跟自己聊起来了——一个说「唉，我老板对我特别凶，今天过得很难」，另一个回「哦，真替你难过」。点睛：「你不会为这种情况写单元测试，而且说不定它还会冒出涌现的点子。」方向：搭 harness「尽可能多地演练那些 agent-native 能力」——「你不确切知道它会做什么，Claude 会尝试你压根想不到的事，可能把你的 app 带进全新的状态」。→ 详细
12
「安全的游乐场」+ 建在沙子上还是有结实主干 🎯
- Dan 的框架：「能有游乐场的唯一前提，是它的边缘是安全的」——把外围护栏（数据安全、不越权、不崩）做死，中间才敢让 agent 自由发挥。Krieger：「我们一开始把游乐场做得太小太受限；如今模型变了可以放开很多」，但他诚实承认「还没完全搞清楚边界线在哪」。→ 详细
- 稳健性的对照：有些产品「好像只差一个错误命令、一次误点击就要卡死」。他的 Instagram 私信案例：V1 是他自写的定制实时系统，「消息可能到达也可能到不了」「崩过好多次」；V2 就「狠狠打磨可靠性」。标尺：不必做到 WhatsApp「荒郊野外一格信号也努力发出去」，「但至少加载时感觉稳、显示已发送就是真发了——那里有个小小的对勾」。agent-native 在此之上再加一层考验：「我能不能推它一把？一推就垮，还是『我有一根结实的主干（a solid trunk）——你可以随便推，但数据是安全的，它不会一个 deploy 就彻底崩掉』。」→ 详细
13
价值单元升级：从「工作量证明」到「用心程度证明」 🎯
- Dan 的概念：如今的价值单元是「工作量证明 / 使用证明（proof of work / proof of use）」——收 PR 时他想看的不是测试通过（那是默认），而是「给我发一段你或你的 agent 在用它的录屏（send me a loom）」。Krieger 说这大概有三层。→ 详细
- 第一层 = 证明你实际演练过：「我现在在所有 prompt 里都这么干了」——「提 PR 之前，先向你自己、再向我证明它确实按预期工作。」绝不能任由模型走捷径说「我读了代码，看起来没问题」；他的反驳很经典：「代码就是你写的，我才不信你呢（you wrote the code, I don't trust you）。你必须真的去测一遍。」这还会逼你改变搭脚手架的方式，让 Claude 至少能简洁地测试改动。→ 详细
- 第二层 = 用心程度证明（proof of thoughtfulness）：模型会替你做大量决策，他常问工程师「你为什么选这种做法」，「很多时候答案是：他们没选，那是模型做的选择」——也许还算合理，「但不是放进整个范式里最优的那个」。正面例子：有工程师说「我知道你会问一堆问题，所以提前把 Claude 做的东西都过了一遍」。分寸：大多数 PR 不逼问；但「重构系统、引入新 primitives」的 PR 必须问透——否则「很容易堆出一座你自己都没意识到的『假设之塔』（a tower of assumptions）」，一个个想当然的小决定叠起来，地基早歪了你还不知道。→ 详细
14
招人与技术把关：两个方向都重要
- Every 的写作产品 Spiral 刚招了位「技术偏轻、但产品和写作直觉特别拔尖」的 GM——「现在能招这样的人了，一年前不行，因为编程模型还不够好」。但 Dan 抛出隐忧：没人懂全部技术细节，产品会不会不够稳健？→ 详细
- Krieger：两个方向都重要。方向一 = primitives 与架构稳健，仍需资深技术人——他上周「跟 Claude 就『系统要不要 Redis 还是 Postgres 就够』长时间辩论」，能辩纯粹因为「以前实打实用过这些技术，心里有底」。方向二 = 工具集架构是否做对：「你是用一堆 system prompt 修补把问题糊弄过去了（papered over），还是真把工具架构做对了？」比喻：就像不会靠「5 秒后重试肯定能成」糊弄分布式系统，也别往 prompt 里塞「永远永远，全大写，用 markdown」——「它们都是同一个问题的症状：底下那块东西稳不稳健。」→ 详细
- prompt 侧的「开发循环」陷阱：见过有人（内部也是）陷进「加 prompt→出错→再加」的循环。妙喻：「给新员工第一天甩一百条指令，他多半只记你最后说的那条，或干脆短路掉」——模型也一样。解法：与其塞一个 prompt，不如拆成「两个不同的工具、两个各带更少 context 的 agent」。所以 Labs 仍在招系统专长的人（权限、资源分配、早期测试）——「这类活对 Claude 也难，它自己改不了权限，也不该能改」。→ 详细
15
组织配对：applied AI 团队与「设计师兼构建者」
16
启动新项目的把关因素：必须有人抱「极强信念」 🎯
- Labs 启动新项目「最重要的把关因素（gating factor），是得有一个人抱极强信念（extreme conviction）」。澄清信念落点：「不一定是对具体想法——对具体想法太执着其实很危险——但至少是对那个问题领域。」劲头要到联合创始人级别：「我会一直撞墙，直到这事要么被证明成立、要么彻底死掉。」→ 详细
- 反面信号（项目的「丧钟」）：被叫停的项目复盘时「经常发现团队里没一个人真觉得这就是那件值得做的事，大家只是觉得『嗯，听起来挺合理』——那种态度对项目就是丧钟（the death knell）」。这个人可以是设计师或有产品思维的工程师，「很少是纯粹的 PM」——整个 Labs 目前只有一个 PM。→ 详细
17
两种孵化结构：Labs 双周估值 vs Every 的 GM 全栈
18
加人临界点 + 每 3–6 个月扔掉一半产品 🎯
- 何时该加人：标准是「你脑子里已经装不下整件事了」——这条线「以前小得多，现在大多了」。Instagram 的消息功能从「一周搞定」长成「几乎需要自己一支团队」。→ 详细
- Labs 不显而易见的发现：想法还装得进一个人脑子时，「加人其实会拖慢团队」「扩张太快是净负面（a net negative）」——人多了「把所有时间花在协调上」、开一堆对齐会。Instagram「就我们俩，让两个人想到一块就已经够难」；他的第二家公司 Artifact 头几个月俩人单干，后来招到约八人，「还没找到 PMF 就八个人开着 Zoom 讨论下一步，而你其实只想坐一个房间里聊透」。教训：「别太早把团队提前扩张起来，否则陷进『元协调』游戏。」该加人的两种情形：① 有足够 context 和范围让第二个人「再装下另一块复杂的东西」；② 有人「在同一个想法上空转了两周、四周」，注入新思路和紧迫感。→ 详细
- AI 节奏下保持小尤其重要：「每隔 3 到 6 个月，你就得把产品里差不多一半的东西扔掉」——跟一大堆人协调这事很难做，「但如果只有一个 GM 自己意识到『我得直接扔掉这一半，因为模型强太多了』，转向就容易多了」。配套心态 = 删功能当使命：「Claude Code 团队在这点上做得特别好——几乎把删功能当成团队成员的一种使命（deleting features as an imperative）」；判断标准：「这东西没起作用，就下掉（unship）」，新东西哪怕没完全取代旧的、只要做到足够程度，就该「废弃然后移除」。→ 详细
19
企业客户让「删功能」变难：20 小时培训与 styles 案例
- 入职半年他主导 Claude AI 大改版，好评如潮——然后收到愤怒邮件：「我刚为公司录了 20 个小时的企业版上手培训，现在全得重录。」教训：不可能一年只发两次，但「面向企业那侧推出时把节奏稍微收敛一点」。→ 详细
- styles 案例：用的人不多但「用的人用得非常重」，讨论移除时发现它「对几家公司的整个使用场景是『承重』的（load-bearing）」——有公司 CEO 亲自写了一套风格发给每个员工。解题方向：用 custom instructions、projects、skills 做替代，长远「搞出一套 plugins/skills 体系，让功能不必活在核心产品里」——「最难删的永远是发给所有人的核心东西」，且不该「给每个未来新注册的人增加复杂度」。→ 详细
20
「会过时的版本」陷阱 + 列车与开关 🎯
- Dan 的尖锐观察：「在 AI 领域卖给企业，哪怕产品现在很现代，它也会相当快过时——可你的客户偏偏想要那个过时的版本。」「只要你为『巨型上市公司现在会买的东西』做优化，就很容易被颠覆。」Krieger 补困局画像：很多两三年前起步的创业公司，「有套特定技术栈、特定『我们这么做 AI』的思路，模型已天差地别，但跟客户签的合同还按那套过时的来」——「你看 Copilot 之类的，差不多就那种感觉」。→ 详细
- Anthropic 的应对范式（原话）：「把它当成『这趟列车会一直往前开』，沿途提供面向企业的开关（enterprise toggles），但核心持续演进——这就是那个押注，也是你和我们合作要接受的前提。」企业能安心签一年长约，「唯一的原因恰恰是相信它会沿途持续演进」；Coda 案例从第一天就有「不想让员工用就关掉」的开关。→ 详细
- 对创业者的主张：「公司应该远比现在更愿意重写技术栈。」以前「开掉一部分客户」是多年尺度的事，「现在是『三个月前的产品对比现在』」。操作：愿意推出大的重新构想的 V3/V4，设过渡期两版并行托管一阵，「但接着你也得愿意去切（cut over）」——否则「要么被下一家从零重新构想它的公司取代，要么自己取代自己」。「同一个老故事，只是被压缩到了以月为单位。」→ 详细
21
open claw：把「早已可能的事」打包成可上手的形态
- Krieger 评价 open claw（把工具尽量交给模型、让它自主行动的开放形态）：「当你能让人们看到一个早就可能实现、但现在被打包成人们真的可以上手去试的形态」——类比 Replit / Lovable / V0 那批低代码工具把「用模型写代码」真正放进大众手里。它「差不多是那个理念最纯粹的表达：把工具交给模型，让它自己往前搭」。最好笑的案例：「一个朋友说『我觉得我老婆在吃我 open claw 的醋』，因为他跟它聊得太多了。」→ 详细
- 边界之问：V1 时代是「这是你能用的三个工具，永远只能用这三个」；到 open Claude「口径（aperture）宽到我看不到边」——「它居然打电话帮我处理邮件，我都不知道它能干这个」。他圈定「从现在到八月底」最有意思的产品问题：在「梭哈型（yolo）open 产品」和「带门禁、会请求权限的 copilot」之间是什么形态？两条路：① 彻底切换范式，开放但带大量安全保障；② 找到一条界线，界线内依然强大有用，「又不至于给你每个联系人都发邮件、整个失控（go haywire）」。→ 详细
22
Claude 的私人化关系：命名、个性与「宜家效应」
- Dan 的微妙感受：看别人用 Claude 有种「脱衣舞娘喜欢上我了」的错位感——Claude 对谁都热情。命名案例：「我的 Claude 叫 R2-C2，我女朋友的叫 Shelly」——命名 + 映照自己性格让人觉得「它真真切切是我的」。Krieger 的框架：「单一那一个」很有道理，它是「协调者或委派者」，你自然想给它起名、赋予个性（他点名 007 的 Q、Moneypenny、《2001》的 HAL）。再加「宜家效应」：装一套 open Claude 挺麻烦，「正因为折腾了一通，你会觉得『是我亲手生出了 Shelly』」。→ 详细
23
架构选择：委派给子智能体，保持主循环常开 🎯
- Krieger 在 Claude Code 里「强烈写了一条 prompt」：「你自己别干太多活，把活委派给子智能体（delegate it to sub agents）。」好处：「大部分时候主运行循环（run loop）都空着，随时能跟你对话」——open Claude 和 Pi 也是类似架构。这恰恰是体验分野的关键：「感觉更像一个你在跟其对话的『人』，而不是一个你把活丢给它、然后它因为在跑复杂任务而卡上五分钟的『工具』。」→ 详细
24
「影子组织架构图」+ 隐私两面 + 收尾
- Every 基于 open Claude 做了个一键接入 Slack 的实现，也在争论「要一个智能体还是很多个」。Dan 发现的模式（信任链）：「我用我的智能体干我擅长的事→别人看着就知道我擅长什么→他们信任它因为信任我→它又根据我自我调整→组织里的人开始用它干这类事」——最后长出「影子组织架构图（shadow org chart）」：每个人的 Claude 因主人擅长的事被大家知道、被大家用。→ 详细
- 由此引出的研究问题：人们「第一次真切体会到隐私——我的智能体了解我什么，对照它向别人透露什么」。Krieger 强调正面版本：理想的个性化是「它通过你所有交互学到的东西，被真正用在解决别的问题上」，而不是「跟别人的没两样、只是有个名字绑在你身上」。→ 详细
- 收尾：本期无独立闪电问答，自然收尾；Mike 的联系方式「X 上找 MikeyK」。结尾是一段明显 AI 生成的浮夸订阅口播彩蛋（「藏宝箱里装的不是金子，是知识炸弹」「Dan，我已经无可救药地爱上你了」）。→ 详细
25
联系方式
- Mike Krieger：X（推特）账号 @MikeyK。
- 主持人 / 节目：Dan Shipper，Every 旗下播客《AI and I》。
- 视频原链接：https://www.youtube.com/watch?v=KRv9GpJYrUA
26
术语速查
- agent-native（智能体原生）：产品从根上设计成「凡是用户能做的，agent 都能做」，每个 primitive 都被模型知道且可改。本片最核心的词。
- primitive（基本积木）：产品里最基础、不可再分的功能单元（一条文档、一个项目）。
- zero to end（直接做到头）：模型不只帮你迈出第一步（zero to one），而是一口气端出看起来完整的产品。
- vibe coding（氛围编程）：靠对话、凭感觉让 AI 写代码，不手写。太上瘾容易越加越乱。
- 室内长树：开发被加速太猛，跳过「一步步经风吹」的过程一次性长出整棵树，缺直觉、缺经验检验。
- 扔进大结局：过度建设让新用户像被丢进电视剧最后一集，全是没交代的背景。
- harness（运行框架/外壳）：包裹住模型、给它装上工具和循环、让它真正干活的那套代码。
- skill（技能包）：一包可复用的知识/技能，装上后模型每次自动调用（如「Claude API skill」）。
- proof of work / proof of thoughtfulness（工作量证明 / 用心程度证明）：验收 agent 产出的两层尺——你真演练过了吗 + 你把每个选择想透了吗。
- 假设之塔（tower of assumptions）：一堆「看起来合理」的小决定叠起来，地基早歪了还不自知。
- sub agent / run loop（子智能体 / 运行循环）：主 agent 把杂活派给子分身、自己主循环常开随时对话；是「伙伴感 vs 工具感」的关键。
- shadow org chart（影子组织架构图）：每个人的 agent 因主人擅长的事被大家信任、调用，长出一张隐形分工图。
- enterprise toggle（企业开关）：核心持续演进、但给企业留「不想用就关掉」的旋钮（Coda 案例）。
- PMF（产品市场契合，product market fit）：产品真正被市场需要的那个匹配点。
- second system syndrome（第二系统综合症）：做第二版时把第一版被迫砍的花哨功能一股脑塞回去，把它做臃肿做垮（出自《人月神话》）。