• 自由主义和资本主义都是“次优”制度，跟人天生的道德直觉对着干，所以每一代人都得重新被说服一次。否则文明会退回更小、更符合直觉的社会形态。

• 人们心中的最优方案，政治上是社群主义，大家价值观一致、彼此高度信任、关系紧密；经济上是社会主义，既然分工本质上是合作，那就应该用合作的规范来管，大家无私出力、平分成果。可现实制度恰恰挡着这些理想。

• 最优方案在小社区里确实行得通。我们只说“紧密的小社区”，是因为根本不存在靠这种规范运转的大社区，高信任关系没法规模化。合作的人一多，就得引入正式权威、层级、成文法和专门的执法机构，也就是国家。随之就有“好国王问题”：掌权的人有公心，系统就运转良好；掌权的人不是，就是灾难。最成功的应对是给权威结构绑上手脚，拿到一部分好处，避开最坏的后果，这就是自由主义的核心，也就是有限政府。它之所以是次优，是因为它主动放弃了一些本来有益的国家权力用法，赌的是长期来看，这种克制对所有人更好。

• 文明的定义：一种制度结构，能把合作扩展到成员凭天生的行为倾向维持不了的范围。所以文明总有碎裂成更小、心理上更直观的社会形态的危险，必须主动守护，首先要防的是自己人口里从来没真正接受这套安排的大多数人。自由民主不是靠公众普遍持有自由或民主的价值观维持的。民主制度基本是精英强加给人民的。所以制度能延续，靠的是留住精英的忠诚。

• 精英中妨碍文明再生产的三类人

  • 理想主义者：拿小镇、教区、少棒队这类小规模合作的直觉去要求大制度；左翼指向未来的乌托邦，右翼指向虚构的过去，本质都是乌托邦主义

  • 普通人（normies）：真心喜欢"《权利法案》加百思买"，认为自由主义和资本主义就是理想方案

    • 名义上站对了边，但给理想主义者送了靶子，坐实了"反对者要么想象力贫乏、要么道德败坏"的看法

    • 捍卫者因此处境尴尬：在最优原则上同意理想主义者，却要为现有安排做更复杂的辩护

  • 年轻人：社会学老话说文明不断被"野蛮人"入侵，形式是孩子

    • 年轻人天然倾向理想主义；反驳需要历史知识，而历史充满偶然，总能讲"要不是……"的故事

    • 所以还需要年轻人信任上一代确实真诚尝试过

    • 这种信任在现代格外难建立：60 年代那代人第一次形成代际意识，代内交流量已超过代际交流，技术变化让老一代的经验失效；"别相信 30 岁以上的人"演变成对上一代的轻视，以及"上一代没实现理想是道德缺陷"的看法；捍卫次优方案的人容易被怀疑"卖身"或不够努力

比较有共鸣的几点：

• 提出“做什么”，而不是“怎么做”。先描述你想实现什么，再说明如何实现。这样往往能取得更好的结果。“让字节码编译器和虚拟机尽可能快。在速度提升到原来的两倍之前，绝不停止。” “最终它应该这样工作”

• 让整个软件开发生命周期（SDLC）对代理而言一目了然。是什么遏制了“幻觉”？是工具调用。它们让代理能够接触到我们的现实。如果代理看不到某些内容，它就会凭空编造出来。因此，让它端到端地运行自己构建的代码，让它读取生产日志、进行部署、观察发布过程、发布版本、切换标志、对错误报告进行分类处理，并向客户发送电子邮件。凡是你能看到的内容，代理也应该能看到。

• 为它提供支持软件开发生命周期（SDLC）的工具。我们提供了用于提交错误报告、向用户发送邮件、检查“系统是否正常运行”以及启用功能开关的自定义插件。

• 本地开发环境现在用起来真让人不舒服。每个代理都应该能够安装并运行完成任务所需的任何软件。在远程机器上这很简单，但在本地开发环境中却很麻烦。当需要代理进行端到端测试时，本地环境中很难避免资源冲突。

• 不要让智能体直接进行迭代。让它构建用于迭代的工具。不要说“我们试试这个……啊，不行，那试试那个”，而应该说：“生成 20 种变体，并生成一个小页面，让我可以组合并测试它们。”这不仅适用于解空间，也适用于问题空间：“给我 4 种关于‘为什么这很慢’的理论，然后验证这四种理论。”

• 别再手动管理上下文了。你每花一点时间去琢磨“它到底用了 30 万还是 38 万个令牌？”，都是白费工夫。压缩机制的效果非常出色。不要手动管理上下文。一个线程 = 一项任务。有些线程包含 46 条消息，有些则有 3,714 条。

• 作者用农业革命类比 AI 革命。农业革命之后，大多数人不需要自己种地，却能吃到比以前任何时候都更丰富的食物。作者认为，AI 革命之后，大多数人也不需要自己生产太多智力，却可以消费更多智力。

• 作者认为，对智力的需求不是固定的。以前获取智力很贵，要请专家、要自己花很多年学习，所以大家用得很少。AI 让获取智力的成本大幅降低，人们就会想用它做更多以前做不到、也想不到的事，需求也会跟着变大，而且看不到上限。就像工业革命前，茶、糖、棉布变得便宜以后，普通英国人开始想要这些东西，甚至愿意为此每年多工作 50 天左右。

作者整理了 300 多个专门适合独立开发者和创业者推广产品的渠道。

• 当我们告诉别人 Linear 奉行“零缺陷”政策时，人们通常会表示难以置信。这听起来或许是个荒谬的做法，但我们之所以这样做，是因为除此之外别无他法。

• “零缺陷”方针意味着我们会立即处理缺陷，具体处理天数取决于缺陷的严重程度：低优先级缺陷需在 7 天内处理，高优先级缺陷则需在 2 天内处理。我们于两年前正式确立了这一做法。其实，推动这一举措的契机，源于我曾向某款热门消费类应用的团队报告的一个缺陷。 终于在两年前——也就是我首次报告该漏洞五年后——我看到它被修复了。我不禁心想：“天哪，数百万用户多年来毫无理由地饱受这个漏洞之苦。”如果该公司最终都要修复这个漏洞，那当初立即修复岂不是好得多？

• 一旦我们达成共识，认为“零缺陷”政策是唯一正确的道路，第一步就是清理积压的缺陷。当时我们大约有 175 个未解决的缺陷，于是我们预留了三周时间来修复所有这些缺陷。在此期间，我们暂停了所有其他项目。大家除了修复缺陷，什么都不做。到最后，我们彻底清除了所有缺陷，实现了“零缺陷”。

来自 Claude 团队：

• 模型能做的远比大多数人要的多，瓶颈在人这边，人类不敢开口要。

• 高度（Altitude）：往上一层想，要结果而不是要任务。

  • 从"帮我修这个 crash"变成"让 app 不再 crash"。

  • 比如对于季度汇报，让它设计一个比季度汇报更好的机制，用历史数据证明新机制能更早发现问题，并行跑一个季度。

• 深度：把任务做到专家水平

  • 坚持用行业顶尖的工具。

  • 定不合理的目标，并告诉模型这很合理。要 5 秒加载就说要 200 毫秒；模型说做不到，就说可以，继续。

  • 要求模型在重写任务前先说清四点——专家会多做什么、会从什么原始材料入手、用什么方法工具、除了你我之外什么能证明结果对。

• 广度：从别的领域借方法

  • 组建团队。为了做好这份汇报，你会请谁？分析师、记者、编辑，可能还有动效和音频设计师；再加一个红队，比如做空者和法证会计师。

• 看看你的牙医、保险公司、孩子所在学校，或者任何政府部门的网站，你会发现这些软件之所以糟糕，并不是因为没人知道如何开发更好的软件，而是因为需要这些软件的人在当前价格下负担不起更好的软件。

• 软件开发中剩下的工作，就是弄清楚人们真正想要什么，对其进行精确定义，并确保其使用体验良好。这部分成本是按每款软件计算的且无法转移，因此随着软件数量趋于无限——而需求没有上限，这一成本终将占据整个工作的全部。

• 软件开发中持久且能带来报酬的部分：在于你比客户更深入地理解问题，并比他们更深入地思考解决方案。

• 市场需要既懂行业背景又有品位的人才，而我们根本没有培养这类人才。“需求分析”是一门人们愿意付费学习的课程。

• 这个职位被称为产品工程师。