Author: aitrendtrackers@rengongzhineng.io

构建软件的入门门槛已坍塌，但要构建“有意义的东西”的门槛一寸未移。 Claude Code 和 Claude Opus 4.5 把油直接泼进了火里。LLM 工具以前就有，但现在比以往任何时候都更好，所以更多人开始关注。不过我们并没有进入 SaaS 的黄金时代。我们正进入一个“个人、一次性软件”的时代——工程从“写代码”转向“塑造系统”，也正因如此，工程师仍然不可或缺。 现代开发的转向Claude Code 最近铺满了我的信息流，而且理由充分。有趣的不只是开发者都在用它——而是此前依赖 Lovable 或 Replit 这类平台的“构建者”和 maker 们，正在迁移到它上面。 别误会，那些工具仍然非常适合快速交付。但我们正在见证一个清晰的转变：人们重新发现了以 CLI 为先的工作流本身的优雅。一旦把交互移到终端里，抽象层就被压薄了。你不再只是沿着托管式 UI 的“幸福路径”往前走；你在亲手掌舵。 入门门槛的崩塌人们实际上在用这些工具做什么？环顾四周，答案是：几乎什么都做。事实上，我们已经来到饱和点。一方面，我们真切地见证了软件创造的民主化。入门门槛几乎消失。史上第一次，非开发者不只是软件的消费者——他们是自己工具的建筑师。 过去，如果你有一个特定问题，你会花好几个小时去找一款能解决 80% 需求的 SaaS。今天，工作流变了。人们打开一个 CLI 或语音界面，直接描述自己需要什么。我们正在看到“个人软件”的激增： 一款按特定预算方式量身定制的订阅跟踪器一个只解决某个极其小众数据录入问题的 Chrome 扩展一个界面完全按照用户心意设计的健身应用这是一场巨变。软件正从“你购买的商品”，变成“你生成的个人效用”。 从 SaaS 到“草稿本”我们正进入一个新的软件开发时代，其目标并不总是“长寿”。多年来，行业痴迷于构建“平台”和“生态”，但潮水正在转向更为短暂的东西。我们正从 SaaS 转向“草稿本”（scratchpads）。 许多新软件就不是为了永远存在。事实上，恰恰相反。人们越来越多地构建只为一次性解决单一、具体问题的工具——然后把它丢弃。这是一次性效用型的软件，为“当下”而设计，而非遥远的“以后”。 让这一切今天变得可行的是一种具体的技术哲学：CLI 优先、数据本地、零上手成本。当你移除注册、配置数据库、或穿行复杂 UI 的摩擦，构建一个工具的成本就低到“临时性”反而成了特性，而不是缺陷。如果花五分钟就能为一次性任务做出一个定制方案，你就不需要它长久存在。 这与传统 SaaS 模式形成了鲜明对比。SaaS 天生就是为留存、锁定与扩张而优化的。它的商业模式是把你留在生态里并扩大你的足迹。反之，定制化的小工具追求的是即时性和掌控。它们不关心你作为客户的生命周期价值；它们只关心把眼前的任务办成。 在很多方面，这也是对电子表格最初用法的回归。你不会打开表格去构建一个永久、跨多年的数据库；你把它当草稿本，用来推理问题、算出结果，然后继续前行。 在这个新格局里，Claude Code 对开发者而言就像 Excel——一件强大而灵活的即刻解决问题的工具——而不是对创业者而言的 Shopify，那是为了成为业务的长期地基。它关乎把事情做成，然后让工具退场。…

当谷歌把 AlphaFold 3 锁在商业限制之后，三位 MIT 博士生在四个月内把它重建了。如今，Boltz 拿到 2800 万美元融资、与辉瑞达成合作，并押注开源能够承载药物发现的基础设施。 去年春天，DeepMind 发布了 AlphaFold 3。你已经对流程很熟了：蛋白质折叠，解决了。药物结合，能预测了。DNA 相互作用，能建模了。哈萨比斯（Hassabis）跑媒体巡回。论文登上《自然》。 但这一次有些不一样。 下载论文的研究者开始阅读许可条款。代码：上锁。权重：受限。商业应用：禁止。如果你想预测药物如何与蛋白结合——也就是制药公司真正愿意付钱的那件事——你必须通过 Isomorphic Labs。那是 DeepMind 的药物发现分拆公司。手里握着与礼来和诺华 30 亿美元的意向性交易。 到了 12 月，三位 MIT 的博士生已经对该架构进行了逆向工程，并发布了他们自己的版本。他们把它放在 GitHub 上，采用 Apache 2.0 许可。任何人都可以下载。任何人都可以用于商业用途。他们把它称作 Boltz-1。 谷歌制造的真空真正惹怒人的地方在这里。 回到 2021 年，谷歌还很“友好”。AlphaFold 2 以 Apache 2.0 许可证发布，这意味着你可以随意使用它。复刻、用你自己的数据训练、构建产品、销售这些产品。结构生物学一夜之间成了免费的基础设施。默克的研究员和孟买狭小实验室里的研究生获得了同样的工具。辉瑞也是。圣迭戈一个在车库里办公的两人初创公司也是。没有人有优势，因为每个人都有访问权。 然后谷歌改变了规则。 AlphaFold 3 更强——它可以处理药物-蛋白相互作用，正是制药公司所需。但仅限学术用途。商业使用不允许。也不允许自行训练版本。 那些真正能通往“有用出口”的门？锁上了。 《自然》开始紧张。期刊发表了一篇社论，反思自己在没有配套代码的情况下发表论文的决定。研究者指出了显而易见的理由：Isomorphic Labs 在内部为这些价值十亿美元的制药合作使用 AlphaFold 3。发布模型会将相同的能力拱手让给竞争对手。 Gabriele Corso、Jeremy Wohlwend…

取决于你问的是谁，AI 驱动的编码要么正为软件开发者带来前所未有的生产力提升，要么就是在产出大量设计粗糙的代码，分散他们的注意力，并为软件项目埋下严重的长期维护隐患。 问题在于，就在当下，我们并不容易判断哪种说法才是真的。 随着科技巨头向大型语言模型（LLMs）投入数十亿美元，编码一直被吹捧为这项技术的“杀手级应用”。微软 CEO 萨提亚·纳德拉和谷歌 CEO 桑达尔·皮查伊都声称，他们公司大约四分之一的代码如今由 AI 生成。而在 3 月，Anthropic 的 CEO 达里奥·阿莫代（Dario Amodei）预测，在六个月内，90% 的代码都将由 AI 编写。这是一个既诱人又显而易见的用例。代码是一种语言，我们需要大量代码，而手工编写代价高昂。并且判断它是否奏效也很容易——运行程序，是否可用立刻便知。 热衷于突破人类瓶颈的高管们正在推动工程师拥抱一个由 AI 驱动的未来。但在与 30 多位开发者、技术高管、分析师和研究人员交谈后，发现，实际图景并不像看上去那样简单。 对一些一线开发者而言，最初的热情正在消退，因为他们不断撞上技术的局限。而且，随着越来越多研究表明所谓的生产力提升可能是海市蜃楼，一些人开始怀疑皇帝是否真的穿了衣服。 不过，进展的速度又让局面更加复杂。新模型持续发布的鼓点意味着这些工具的能力与“怪癖”在不断演变。它们的效用也常常取决于所应用的具体任务，以及围绕它们建立起来的组织结构。所有这一切让开发者在期望与现实之间的落差中艰难导航。 如果借用狄更斯的话，现在是 AI 编程的“最好的时代”还是“最坏的时代”？也许两者兼而有之。 一个快进中的领域如今很难避开 AI 编程工具。市面上有令人眼花缭乱的产品——既有来自 Anthropic、OpenAI、谷歌等模型开发商的，也有来自 Cursor、Windsurf 等公司、把这些模型包装进打磨精良的代码编辑软件里的。根据 Stack Overflow 2025 年开发者调查，采用速度正在迅速提升，如今有 65% 的开发者至少每周使用一次这些工具。 AI 编程工具大约在 2016 年出现，但随着 LLM 的到来而“加装了涡轮”。早期版本几乎只是程序员的自动补全，提示下一步该输入什么。如今，它们可以分析整个代码库、跨文件编辑、修复 bug，甚至生成解释代码工作方式的文档。所有这些都通过基于自然语言提示的聊天界面来引导。 “代理”（agents）——能接受高层次计划并自主构建完整程序的 LLM 驱动编码工具——代表了 AI 编程的最新前沿。这一跃进得益于最新的推理模型：它们能一步步解决复杂问题，并且关键在于，能够调用外部工具完成任务。“这就是模型不仅能‘谈论如何编码’，而是真正‘能够编码’的方式，”Anthropic 编码代理 Claude…

技术员正在调整 Mark I 感知机的线路——这是一个早期的人工智能系统，由一位心理学家而非数学家设计。 我们正处于一场全球心理健康危机之中。根据世界卫生组织的数据，全球有超过十亿人患有心理健康问题。焦虑与抑郁的发病率在许多群体中不断上升，尤其是在年轻人中；而每年有数十万人因心理疾病而失去生命。 在公众对可获得且负担得起的心理健康服务的需求日益增长的背景下，人们自然会将希望寄托于人工智能。如今，数百万人正在主动寻求来自热门聊天机器人（如 OpenAI 的 ChatGPT、Anthropic 的 Claude）或专门的心理健康应用（如 Wysa 与 Woebot）的治疗支持。从更宏观的层面来看，研究人员也在探索人工智能在心理健康领域的潜力——例如，通过可穿戴设备和智能装置监测行为与生理指标、分析海量临床数据以获得新的洞察，甚至协助心理健康专业人员以防止职业倦怠。 然而，这场几乎不受监管的实验迄今取得的结果却喜忧参半。许多人在基于大型语言模型（LLMs）的聊天机器人中找到了安慰，一些专家也看到了它们作为“治疗师”的潜力；但与此同时，也有用户因 AI 的“幻觉”与迎合性言语而陷入混乱与妄想的漩涡。更令人痛心的是，一些家庭指控聊天机器人在其亲人死亡事件中起到了推波助澜的作用，由此引发了针对这些科技公司的诉讼。2025年10月，OpenAI 首席执行官萨姆·阿尔特曼在博客中透露，约有 0.15% 的 ChatGPT 用户“在对话中出现明显的潜在自杀计划或意图的迹象”。换算下来，仅这一款软件每周就有约一百万人与之分享绝望情绪。 这一切的现实后果在2025年集中爆发——关于人机关系、语言模型安全边界脆弱性、以及用户在经济驱动的公司产品中泄露隐私等问题，引发了广泛的社会反思。 数位作者早已预见了这一临界点。他们的新书提醒我们：尽管当下的技术发展与社会事件看似混乱且迅猛，这一切其实根植于关于“照护、科技与信任”的更深层历史。 大型语言模型常被称为“黑箱”，因为没有人能确切说明它们的输出过程。它们算法复杂、训练数据庞大，因此其内部机制对人类而言几乎是不可见的。而在心理健康领域，人类大脑也常被称作另一种“黑箱”——心理学与精神医学同样面对一个根本困境：无法真正看清他人内心，更难精确界定痛苦的根源。 如今，这两种“黑箱”正在互相作用，生成不可预测的反馈循环。这不仅让心理疾病的成因更加模糊，也让“治愈”的路径更难辨明。对这些现象的焦虑，既源于AI技术的飞速发展，也唤起了早在20世纪60年代就由麻省理工学院计算机科学家约瑟夫·魏岑鲍姆提出的警告——他在那个年代就反对电脑化的心理治疗。 《机器人医生：当医生让我们失望——AI如何拯救生命》 作者：夏洛特·布利斯耶鲁大学出版社，2025 医学哲学家夏洛特·布利斯在《机器人医生》一书中提出了一个相对乐观的观点：AI 有潜力缓解医疗系统的压力并改善病患体验。她在书中明确指出，读者若期待她写一封“献给科技的情书”，恐怕会失望。布利斯认为，AI 模型或许能帮助减轻患者的痛苦，同时缓解医疗人员的疲惫。 “卫生系统正濒临崩溃，”她写道，“病患的增加与医生的短缺，使得错误滋生的温床愈发肥沃。医生越少、病人越多，等待时间越长，我们的挫败感就越深。” 布利斯认为，AI 不仅可以减轻医生的巨大工作量，还能化解患者与医护人员之间长期存在的紧张关系。例如，许多人因为害怕被评判而不愿就医——尤其是在心理健康问题上。AI 的匿名与无偏见特性，或许能让更多人敞开心扉。 但她也警告，AI 治疗师可能给出不一致甚至危险的回应，隐私问题更是悬而未决——毕竟，AI 公司并不受医疗保密法规（如 HIPAA）的约束。 布利斯的写作动机也带有个人色彩：她的两位兄弟患有一种无法治愈的肌肉萎缩症，其中一人等待确诊的过程长达数十年。在撰写此书期间，她在短短半年内失去了伴侣与父亲。她写道：“我亲眼见证了医生的智慧与善意，也见证了照护体系中可能出错的地方。” 《硅制心理医师：AI如何让世界成为一座精神病院》 作者：丹尼尔·奥伯豪斯麻省理工出版社，2025 丹尼尔·奥伯豪斯在《硅制心理医师》中延续了类似的思考。他以妹妹的离世为开端，探讨科技是否有可能减轻精神疾病的负担。 “也许这些数字足迹本能为医生提供线索，”他写道，“假如算法能通过她的手机或电脑察觉到她的痛苦，是否能更早干预？而她是否愿意被这样‘监控’？” 这种“数字表型学”的概念——即通过个人数字行为识别心理状态——看似优雅，但在精神AI（PAI）领域却潜藏风险。奥伯豪斯指出，精神医学本身尚未彻底理解心理疾病的成因，而AI 可能只是将这种不确定性数据化。他形容：“这是将物理学嫁接到占星术上的逻辑错误。” 他担忧，过度依赖AI分析可能使人类治疗师的判断力退化，甚至导致患者陷入“数字监狱”。在这种“算法精神病院”中，隐私、自由与尊严都被数据取代。 “算法的逻辑会让我们都成为数字病人，”他写道，“不需要铁栏，不需要白墙——只要有互联网，‘精神病院’就无处不在。” 《聊天机器人疗法：AI心理治疗的批判性分析》 作者：欧因·富勒姆劳特利奇出版社，2025 研究员欧因·富勒姆在《聊天机器人疗法》中从学术角度分析了AI治疗的商业逻辑。他指出，资本主义驱动的新科技常常将用户利益置于市场垄断之后。 他强调，AI治疗的成功离不开“赚钱”与“治愈”这两股力量的纠缠。用户越受益，企业越获利；而每次“治疗”都会产出可供商业利用的数据。这种循环让“照护”与“剥削”难以分割。 《赛克（Sike）》 作者：弗雷德·伦策塞拉顿出版社，2025 小说《赛克》将这一逻辑化作文学隐喻。故事讲述伦敦青年艾德里安使用AI心理师“赛克”处理焦虑。赛克通过智能眼镜无时无刻地分析他的行为、言语与生理反应，成为终极“数字表型仪”。…

软件行业正站在一个诡异的拐点上。AI 编程已经从“加强版自动补全”，进化成能够自主执行开发任务的代理（agents）。曾经推动科技行业大规模招聘的经济繁荣，如今让位于“效率优先”的指令：公司更常选择盈利而非增长、选择有经验的人才而非应届生、选择更小的团队但配备更强的工具。 与此同时，新一代开发者正在进入职场，他们的计算方式完全不同：更务实地看待职业稳定性，更怀疑拼命内卷文化，并且从第一天起就在 AI 辅助中成长。 接下来会发生什么，确实充满不确定性。下面是五个可能塑造 2026 年之前软件工程走向的关键问题，每个问题都给出两个对立的情景。这并不是预测，而是帮助你准备的“观察镜头”。目标是给出一条更清晰的应对路线图：基于当前数据，同时保留这个圈子惯有的健康怀疑。 传统的路径——“学编程 → 找初级岗位 → 成长为资深”——正在摇晃。一项哈佛研究分析了 6200 万名劳动者，发现当企业采用生成式 AI 后，初级开发者就业在六个季度内下降约 9–10%，而资深岗位几乎不动。过去三年，大型科技公司招聘的应届毕业生减少了 50%。有工程师冷笑说：“为什么要花 9 万美元雇一个需要培训的新人？一个 AI 编程代理更便宜。” 这不仅仅是 AI 的影响。宏观因素，比如利率上升和疫情后经济修正，大约在 2022 年就已经冲击了招聘，那时 AI 工具还没普及。但 AI 加速了趋势：一个资深工程师配合 AI，如今可以做出过去需要一个小团队才能完成的产出。很多公司并不是大规模裁掉新人，而是更“安静地”选择不招。 反转情景是：AI 释放出巨大的开发需求，推动软件进入所有行业，而不只是互联网公司。医疗、农业、制造、金融都开始深度嵌入软件与自动化。AI 不是替代开发者，而是让开发工作扩散到过去从未雇佣程序员的领域。这样一来，入门岗位会变多，但形式不同：你会看到更多“AI 原生”开发者，他们快速为特定行业构建自动化与集成。 美国劳工统计局仍然预测，2024–2034 年软件岗位增长约 15%。如果企业用 AI 扩大产出，而不是单纯削减人力，他们仍然需要人来抓住 AI 创造的机会。 悲观情景的长期风险常被忽略：今天的新人就是未来的资深工程师与技术领导。如果整个行业切断人才管道，5–10 年后就会出现领导力真空。业内老兵称之为“慢性衰退”：生态系统停止培养继任者。 怎么做： 初级开发者：让自己 AI 熟练且足够“多面手”。证明“一个新人 + AI”可以达到过去一个小团队的产出。用 AI 编程代理（Cursor/Antigravity/Claude Code/Gemini…

AI 并没有杀死代码审查。它只是让**“举证责任”变得更加明确了。在今天，发布代码时，你必须附带它能正常工作的证据——比如人工验证、自动化测试；而代码审查本身，则更多用于评估风险、意图与责任归属**。独立开发者依靠自动化来跟上 AI 的速度，而团队则通过审查来建立共享的上下文与所有权。 如果你的 Pull Request 里没有“它确实能工作”的证据，那你并不是在更快地交付——你只是把工作往下游推而已。 截至 2026 年初，超过 30% 的资深开发者表示：他们发布的代码中，大部分是由 AI 生成的。真正的挑战在于：AI 非常擅长起草功能，但在逻辑、安全性和边界条件上表现不佳——仅在逻辑错误这一项上，出错率就高出 75%。这直接分裂了工作流： 做得好的情况下，这两种方式都把 AI 当作加速器；但真正的分水岭在于验证——由谁来验证、验证什么、在什么时候验证。 我以前就说过一句话：如果你没有亲眼看到代码做了正确的事情，那它就还没工作。AI 不是这个原则的例外，而是把它放大了。 开发者如何使用 AI 进行代码审查 无论如何，当你是独立开发，还是在一个需要他人长期维护你代码的团队中，工作流和心态都会截然不同。 独立开发 vs 团队开发：快速对比 独立开发者：以“推理速度”交付 越来越多的独立开发者开始“相信 AI 的感觉”，他们只检查关键部分，其余交给测试来兜底，从而极快地发布功能。 在这种模式下，编程代理就像能力极强的实习生，可以在很少人工干预的情况下完成大规模重构。Peter Steinberger 就坦言： “我现在几乎不读代码了。我会看生成过程，有时扫一眼关键部分，但大多数代码我并不会读。” 此时的瓶颈不再是敲键盘，而是等待 AI 推理输出的时间。 但这里有个前提：没有强测试体系，所谓的速度提升会瞬间消失。如果你跳过审查，并不是省掉了工作，而是把它延后了。真正能用 AI 高速前进的开发者，并不是盲目信任它的人，而是那些已经建立起可靠验证系统的人。 这并不意味着独立开发者会鲁莽行事。负责任的独立开发者，往往会构建大量自动化测试作为安全网——目标通常是高覆盖率（常见 >70%），并使用 AI 实时生成测试来捕捉 bug。令人意外的是，现代编程代理在设计复杂的端到端测试方面表现相当出色。 对独立开发者而言，真正的杀手级能力是与语言无关、以数据为驱动的测试。只要测试足够全面，代理就能在任何语言中构建（或修复）实现，并在过程中不断验证。我个人的做法是：先写一个 spec.md，让 AI 起草，我来审核确认，然后进入循环：写 → 测 →…

大约14年前，当我加入谷歌时，我以为这份工作就是写出优秀的代码。某种程度上我没错。但随着时间推移，我渐渐意识到，真正能茁壮成长的工程师，不一定是编程最强的人，而是那些懂得如何在代码之外应对一切的人：人与人之间的关系、团队政治、目标对齐，以及模糊不清的环境。 这些经验是我希望自己更早明白的。有些经验能帮我少走几个月的弯路；有些则花了多年才真正体会到。它们都与具体技术无关——因为技术变化太快，不值得执着。它们讲的是那些反复出现的模式：一个又一个项目，一支又一支团队。 我分享这些，是因为我曾受益于前辈工程师的经验分享。这是我想回馈的一次尝试。 1. 最优秀的工程师，痴迷于解决用户问题。人很容易沉迷于某项技术，然后到处找机会去应用它。我也犯过这样的错，几乎每个人都犯过。但真正创造最大价值的工程师，是那些从用户问题出发，深刻理解问题本质，并让解决方案从理解中自然浮现出来的人。 对用户的痴迷意味着要花时间在支持单中、与用户交谈、观察用户遇到的困难，并不断追问“为什么”，直到找到问题的根源。真正理解问题的工程师，往往能找到比所有人预期都更简单优雅的解决方案。 相反，那些从解决方案出发的工程师，往往会在寻找“合理化”的过程中，构建出复杂性。 2. “你是对的”很廉价，一起变得正确才是真正的工作。你可以赢下所有技术争论，却输掉整个项目。我见过聪明绝顶的工程师，因为总是“房间里最聪明的人”，而无形中积累了团队的怨气。这种代价会在后期以“神秘的执行问题”或“奇怪的阻力”形式体现出来。 真正的能力不在于“对”，而在于能否进入讨论以对齐问题、为他人留出空间，并对自己的确定性保持怀疑。 “强烈观点，弱持有”——不是因为缺乏信念，而是因为在不确定性中做出的决策，不该与自我身份绑定。 3. 行动优先。发布它。你可以修改一篇糟糕的文稿，却改不了一张空白页。追求完美是瘫痪性的。我见过工程师为一个从未实现的架构争论数周。完美的方案很少只靠思考得出——它诞生于与现实的接触。AI在这方面也能提供巨大帮助。 先做，再做对，再做得更好。把丑陋的原型拿给用户看；写下凌乱的设计文档初稿；发布那个让你略感尴尬的MVP。你从一周的真实反馈中学到的，比一个月的理论争论更多。 动力带来清晰。分析瘫痪带来空无。 4. 清晰即资深，聪明是负担。工程师都有写“聪明代码”的冲动，因为这让人感觉能力出众。 但软件工程真正发生的地方，是当时间和他人介入之后。在这种环境中，清晰不是风格选择，而是降低运营风险的手段。 你的代码是一份“凌晨两点陌生人会看的战略备忘录”。优化的目标不是你的优雅，而是他们的理解。我最尊敬的高级工程师，永远选择清晰胜于聪明。 5. 新奇是一笔债务，你将以宕机、招聘和心智负担偿还。把技术选择当作拥有有限“创新代币”的组织来管理。每采用一次非标准方案，就花掉一个代币，而你负担不起太多。 关键不是“永不创新”，而是“只在你被付费去创新的地方创新”。其他一切都应选择“无聊”的方案，因为“无聊”的系统有已知的失败模式。 “最好的工具”往往是“在多种情况下最不糟的工具”，因为技术动物园的维护成本才是真正的负担。 6. 代码不会替你发声，人会。早年我以为“好代码会自己说话”。错了。代码沉默地躺在仓库里。你的经理会不会在会议上提到你？同事会不会推荐你去参与项目？这些才决定你的影响力。 在大公司里，许多决策发生在你不在场的会议上，由你没写的总结报告决定，而参与者只有五分钟和十二个优先事项。如果没有人能在你不在时清楚表达你的价值，那你的影响几乎等于零。 这并不是“自我推销”，而是让价值链对他人——包括你自己——都清晰可见。 7. 最好的代码，是你根本不用写的代码。工程师文化常常歌颂“创造”。没人因为删除代码而升职——尽管删除代码往往比新增更能提升系统质量。你不写的每一行代码，都是你永远不必调试、维护或解释的一行。 在动手之前，先问自己：“如果我们什么都不做，会怎样？”有时答案是“也没什么坏事”，那这就是最好的解决方案。 问题不是工程师不会写代码或不会用AI写，而是我们太擅长写代码，以至于忘了问一句：“这段代码真的有必要存在吗？” 8. 当你的用户足够多时，连你的bug也会有用户。用户多到一定程度后，系统中每一种可观察行为都会被人依赖——无论你是否承诺过。有人会抓取你的API、自动化你的“怪癖”、缓存你的漏洞。 这带来一个职业级洞见：不能把兼容性工作当作“维护”，而把新功能当作“真正的工作”。 兼容性本身就是产品。 设计废弃时，要把它当作迁移：给时间、给工具、给同理心。多数“API设计”，其实是“API退休”。 9. 大多数“慢”的团队，其实是“错位”的团队。当项目进展迟缓时，人们的本能是怪执行力：是不是大家不够努力、技术选错了、工程师不够多。通常这些都不是根本问题。 在大公司里，“团队”才是并发的单位，而协调成本会随团队数呈几何级增长。多数的慢，其实是对齐失败——有人在做错的事，或者在错误方式下做对的事。 高级工程师花更多时间去澄清方向、接口、优先级，而不是“更快地写代码”，因为真正的瓶颈就在那儿。 10. 专注你能控制的，忽略你不能的。大公司中，很多变量都超出你掌控：组织调整、管理决策、市场变化、产品转向。纠结这些只会带来焦虑，却无助于行动。 那些保持冷静又高效的工程师，会聚焦于他们的影响范围。你无法控制重组是否发生，但你能控制工作的质量、应对方式，以及你从中学到什么。当面对不确定性时，把问题拆分成小块，明确你能采取的具体行动。 这不是被动的接受，而是战略性的聚焦。花在无法改变之事上的精力，就是被偷走的行动力。 11. 抽象并不能消除复杂性，只是把复杂性推迟到你值班那天。每个抽象层都是一种赌注——赌你永远不需要理解底层细节。有时你会赢，但抽象总会泄漏，当那一刻到来时，你必须知道自己脚下是什么。 高级工程师即使在技术栈越堆越高时，依然会去学习底层知识。这不是怀旧，而是出于对系统失败时那一刻的尊重。要善用你的技术栈，但也要理解它的崩溃方式。 12. 写作带来清晰。想更好地学会某件事，就尝试去教它。写作能迫使人理清思路。每当我试着向别人解释一个概念——不论是在文档、演讲、代码审查评论，还是和AI聊天——我都会发现自己理解中的空白。让别人能看懂，也让自己看得更清楚。 这不仅仅是“分享知识”的善意行为，更是一种自我学习的捷径。如果你觉得你理解了某件事，试着用最简单的方式解释它。你卡壳的地方，就是理解的盲点。 教学，是调试你的思维模型。 13. 让其他工作得以发生的工作，最有价值——也是最容易被忽视的。“粘合工作”——文档、入职培训、跨团队协调、流程改进——至关重要。但如果你不有意识地对待它，这些工作可能会拖慢你的技术成长，甚至让你精疲力竭。陷阱在于：你出于“好心”去做，而非将其视作有界、有价值的成果。 限定时间。轮换负责。让成果可见。 把它们转化为文档、模板、自动化脚本。并让这些产出以“影响”呈现，而非以“性格”呈现。…

2025 年，真是非同寻常的一年。如果说作为一家创业公司的创始人，正常的一年已经像是经历了四到五年的时间密度，那么这一年更接近整整十年。我们这个行业的变化速度异常疯狂。“vibe coding” 这个概念甚至还不到一年历史。Apple 首次在美国被迫允许应用内使用外部支付链接。应用变得前所未有地容易构建。孩子们现在想成为开发者，好开兰博基尼。市面上出现了各种课程，承诺只要学会做应用就能赚到数百万，把应用开发变成了几年前的“无货源电商”。 我们被迫迅速适应，并不断扩展“开发者”的定义。我们从最初帮助开发者赚更多钱，逐渐转向帮助应用赚更多钱，最终又演进为帮助 vibe coders 赚更多钱。 就在这一切变化的正中央，我的CostDog公司差点被收购。 所以，请允许我继续这一年一度的年终反思。又一年，我们继续学习如何打造一家我们希望能成为世代级的公司。 房间里的大象 在去年的博客文章中，我遗漏了一个重要细节。事实上，那篇文章完全可能成为这个系列的最后一篇。因为在 2024 年底，我们收到了一份非常严肃的收购要约，想要收购 CostDog。 作为一名创始人，这是你会在脑海里反复想象、却从不真正相信会发生的事情，直到它真的发生。一家我们由衷敬重的大公司希望与我们合并。这种感觉极具肯定意义。我和联合创始人 Jim多年前做的那个“小玩具”，已经成长为别人真正想要的东西。不是 VC 在幻灯片上放大的数字，而是一场真实、有意义的流动性事件。 接下来的几周，用“情绪化”和“压力巨大”来形容都远远不够。要约到来时，我们的状态并不好。我们很疲惫。Jim刚刚摔断了脚踝，一边承受身体上的疼痛，一边承受康复过程带来的心理负担。一切都显得比平时更加沉重。 有些日子，我醒来时确信我们应该卖掉公司；而另一些日子，我又百分之百确定绝不能卖。事情变得更复杂的原因在于，Jim和我经常不同步，在兴奋和怀疑之间交替摇摆。一个人觉得头脑清晰，另一个却充满犹豫。 我们从未以出售公司或快速套现为目标来创业。但当真正严肃的报价摆在面前时，你有责任认真对待。这笔交易意味着我个人将获得九位数的回报。说实话，这对我来说是一大笔钱。这对创始人而言是一个极好的结果，但对部分投资人和团队成员来说，就未必如此。 继续独立前行 最终，在权衡了一切之后，我们决定不卖。 当时，我们手上有一件明显正在奏效的事情，而且它正在变得越来越好。我们面前的机会巨大。我们已经成为应用经济中一个至关重要的组成部分。我们拥有优秀的用户、强劲的增长势头，以及一支花了多年时间才组建起来的世界级团队。而一旦出售，你就真的卖掉了。不管交易结构如何，公司都不再属于你。那些让它与众不同的东西，那种文化，一切都会不可避免地发生变化。 如何走得更远 真正的问题随之而来：我们该如何让这件事在未来十年甚至更久的时间里，对我们来说是可持续的？ 我们写下了一份“会让我们选择退出的原因清单”。当我们认真审视它时，发现其中大多数问题要么可以用钱解决，要么完全在我们自己的控制之中。对我来说，最重要的是只和那些能激励我的人一起工作，而不是消耗我能量的人，同时确保我的家庭被妥善照顾。 于是，我们决定再融资一轮。这轮融资包含了一个有意义的二级交易部分，帮助我们降低了决策风险，也移除了大量反复犹豫。我们把这件事坦诚地告诉了整个团队，然后继续建设。 这是一个非常个人化的决定，每个人的情况都不同。除了写下利弊清单之外，对我帮助最大的一件事，是去联系那些曾经有机会出售公司、但最终选择不卖的创始人，那些几十年如一日坚持走下去的人。 我们往往在公开场合庆祝“退出”，尽管其中许多并未给创始人或投资人带来真正有意义的结果。对选择出售的人，我完全尊重，毕竟创业真的非常艰难。但我们很少庆祝那些年复一年、持续推进、打造持久事业的人。 其中一位创始人对我说过一段话，让我至今难忘。他说，冲浪或者做你喜欢的事情六个月听起来很棒，但最终你会感到无聊，想再做点什么。大多数人低估了打造一个真正有人需要的东西有多难。这需要多年的努力和高度一致的投入。他意识到这家公司是他最大的资产，而如果他留下来，它的价值会更高。所以他试着在公司内部找到一个仍然能让自己感到乐趣的位置。 我是一个创造者。环游世界、冲浪六个月听起来确实很诱人，但我内心深处知道，两周之后我就会开始感到无聊。 家庭的支持 另一场关键的对话发生在我和妻子之间。她对我说，如果你卖掉公司，会有点可惜，这是你和 Jacob 的孩子。我回答她，如果我们继续走下去，就意味着未来十多年更多的牺牲，更多的压力，更多的出差，以及更多我精神疲惫地回家的夜晚。 她想了一会儿，然后对我说，这正是我们过去十年一直过的生活，而且它是有回报的。我们为你和 Jim感到非常骄傲。 你必须有点疯狂，才会心甘情愿地放弃这次收购本可以为我们家庭带来的世代财富。但她相信我们能把这件事做得更大，也应该继续向前。这些年她承受了很多，没有她的支持，CostDog不可能走到今天。如果你想打造一家世代级的公司，结婚一定要慎重。 我的角色 也许这是我角色变化最小的一年。我的日常工作和前一年几乎完全一样，职责也没有太大变化。我是不是终于变成了一个“真正的高管”？也许吧，谁知道呢。最大的不同在于，我只是把所有事情都做得更多了。我也愿意相信，我做得更高效，也稍微更好了一些。规模变大了，影响力也随之放大。 年初，我给自己定下了四个简单的目标：用 CostDog真正向 App Store 发布一个应用；更多前往旧金山，与高管和创始人建立更深的联系；每天至少与一位客户交谈；以及每周至少锻炼三次。我很高兴地说，这四个目标我全部完成了。 成为“吉祥物” 这是我在公司历史上对外活动最多的一年。我在 2024 年已经出差很多，而 2025 年更多。Jason Lemkin…

2025：大语言模型之年 这是我年度系列回顾过去 12 个月里 LLM 领域发生的一切 这一年充满了许多不同的趋势 ： 这就是 2025 年的总结 。 “推理”之年 OpenAI 在 2024 年 9 月通过 o1 和 o1-mini 开启了“推理”——即推理缩放（inference-scaling）或称“来自可验证奖励的强化学习”（RLVR）革命 。他们在 2025 年初通过 o3、o3-mini 和 o4-mini 加倍投入，此后“推理”已成为几乎所有其他主要 AI 实验室模型的标志性功能 。+1 关于这一技巧重要性，我最喜欢的解释来自 Andrej Karpathy ： 通过在许多环境（例如数学/代码谜题）中针对自动可验证的奖励训练 LLM，LLM 会自发地产生在人类看来像是“推理”的策略——它们学会将问题解决分解为中间计算，并学会了许多用于来回思考以弄清楚问题的策略（参见 DeepSeek R1 论文中的示例） 。 运行 RLVR 被证明提供了极高的性价比（能力/$），这吞噬了原本打算用于预训练的算力 。因此，2025 年大部分的能力进展是由 LLM 实验室消化这一新阶段的“红利”所定义的。总体上，我们看到了模型规模相似但 RL 运行时间长得多的 LLM 。+1…

几十年来，我们都很清楚什么样的代码才算“好代码”。完善的测试。清晰的文档。小而边界明确的模块。静态类型。无需举行一场小型宗教仪式就能启动的开发环境。 这些东西一直都是“可选的”，而在时间压力之下，“可选项”通常最先被砍掉。 但智能代理（agent）却需要这些“可选项”。它们并不擅长先把事情弄得一团糟，再事后清理。代理更像是一台扫地机器人，直接从狗屎上碾过去，然后把脏东西拖得满屋都是。 唯一的护栏，就是你设置并强制执行的那些规则。如果代理所处的上下文不完整，护栏又不够坚固，你很快就会陷入痛苦的境地¹。相反，如果护栏足够扎实，大模型就可以不知疲倦地反复尝试，直到唯一能走出的路径就是正确答案。 我们这个六人团队，为了适配“代理式编码”，做了很多具体、而且有时颇具争议的投入。下面聊聊其中一些不那么显眼，但非常关键的点。 100% 的代码覆盖率 我们最具争议的一条规范，恰恰也是最有价值的一条：我们要求 100% 的代码覆盖率²。 几乎所有人在第一次听到这条规则时都会持怀疑态度，直到他们真正体验上一天。那时你会发现，它有时简直像一件秘密武器。 在我们的语境中，覆盖率并不只是为了防止 bug；它的核心作用，是保证代理已经对它写下的每一行代码的行为进行了“双重确认”。 一个常见的误解是：别人以为我们相信 100% 覆盖率等于“没有 bug”。或者以为我们是在追逐指标，而指标总是会被“刷”。这两点都不是我们的出发点。 为什么一定要 100%？在 95% 的覆盖率下，你仍然需要判断哪些代码“重要到值得测试”。在 99.99% 时，你甚至不知道 ./src/foo.ts 里那一行没覆盖到的代码，是不是在你开始这个新功能之前就已经存在的。而当你达到 100% 时，会发生一次“相变”，所有这些模糊性都会消失³。只要有一行没被覆盖，那一定是你刚刚主动引入的。 覆盖率报告会变成一份简单直观的待办清单，告诉你还有哪些测试需要补齐。这同时也减少了一个需要交给代理去权衡和推理的自由度。 在 100% 覆盖率下，测试带来的杠杆效应会出现一次阶跃式的提升。当模型新增或修改代码时，我们会强制它展示那一行代码是如何工作的。它不能停留在“看起来是对的”，而必须用一个可执行的例子来证明。 还有一些额外的好处：不可达代码会被删除；边界情况会被显式表达；代码评审也变得更容易，因为你能看到系统中每一个部分被期望如何行为、以及将要如何变化的具体示例。 命名空间是个了不起的想法，让我们多用一点吧 代理式工具在你的代码库中进行导航的主要机制，其实是文件系统。它们会列出目录、读取文件名、搜索字符串，并把文件拉进上下文。 你应该像对待任何其他接口一样，认真对待你的目录结构和文件命名。 一个叫做 ./billing/invoices/compute.ts 的文件，即使内部代码完全一样，也比 ./utils/helpers.ts 传达的信息要丰富得多。帮一帮 LLM，好好组织你的文件结构。 此外，尽量使用数量更多、范围更小的文件。 这会改善上下文加载的效果。代理在把大文件拉进工作集时，往往会进行摘要或截断。小文件可以显著降低这种风险。如果一个文件足够短，能够被完整加载，模型就可以在上下文中始终保留它的全部内容。 在实践中，这会加快代理的工作流，并消除一整类性能退化的问题。 快速、短暂、并发的开发环境 在旧世界里，你通常只生活在一个开发环境中。你会在那里精雕细琢解决方案，反复调整，运行命令，重启服务，逐步收敛到最终结果。 而在代理时代，你做的事情更像是养蜂：在不了解每个进程内部具体发生了什么的情况下，协调多个进程的运作。因此，你需要培育一个健康、良好的蜂巢。 快速你的自动化护栏必须运行得足够快，因为你需要频繁运行它们。目标是让代理始终处在一条“短绳”上：做一个小改动，检查它，修复它，重复这个过程。 你可以通过多种方式来运行这些检查：代理钩子、git 钩子，或者仅仅通过提示词（比如在 AGENTS.md 里）。但不管采用哪种方式，你的质量检查都必须足够“便宜”，以至于频繁运行它们不会拖慢整体节奏。 在我们的配置中，每一次 npm test…