朋友们，正式的时刻到了。是时候停止假装只有软件工程师才能使用AI进行编码了，因为事实并非如此。显然，在过去的一年半里，随着Lovable、Replit以及Claude Code和CodeEx等工具的上线，越来越多的非软件工程领域的知识工作者开始摸索如何利用编写代码和构建软件的力量来解决自己的问题。这不仅仅是那些非工程师突然试图扮演软件工程师的角色，而是关于借助他们自己构建的软件找到工作的新方法。
然而对许多人来说，这仍然感觉遥不可及、高不可攀。但这并非必然如此。“AI每日简报”是一档关于最重要AI新闻和讨论的播客和视频节目。最近我与女儿一位朋友的父母进行了一次交谈，这个人使用AI已有几年时间。他订阅了多个不同的高价服务账户，并将大量工作转移到了由AI辅助的工作范式中。
尽管如此，即使是考虑任何与AI编码相关的事情，对他来说依然显得完全陌生。简而言之，他过着一种“协作工作”的生活，从未涉足过AI编码的世界，我认为因此错失了不少好处。我对人们所处的位置不做任何价值判断，但我认为，作为非软件工程领域的知识工作者，如果在你的工具包中没有AI编码工具，在这个阶段确实会让你落后。
本周早些时候，我们做了一期关于OpenAI近期企业研究的节目，研究发现大约在4月底5月初，通过API以代理方式消耗的Token比例超过了非代理方式使用ChatGPT的Token量。而且这个数字一直在上升。我们看到，处于企业用户前10%的公司与平均公司相比，使用的AI量大约是8.3倍。
他们部署的用例要复杂得多，更深入到系统和整体颠覆层面，这进一步印证了AI编码不仅仅是软件工程师的专属领域。虽然从2月份的基准来看，企业中与工程相关的CodeEx用户增长了5倍，但基本上其他所有职能的增长幅度都显著更大。财务和会计部门的使用量是2月份的20倍，销售和会计（原文如此）使用了41倍，而法律部门的使用量则是2月份的108倍。
那么这些人到底在用AI编码做什么呢？在大多数情况下，他们并没有突然试图成为所在组织的软件工程师。我认为这是“氛围编码”（vibe coding）早期的一种误解，尽管这早已不是人们实际所处的状态，但这种观念依然顽固地存在。
作为知识工作者，将AI编码部署为你AI工具包一部分的真正理由并不是你会成为软件工程师，而是因为我们可以看到，那些正在构建的人相对于其他AI用户而言，其收益和优势在不断复利增长。我们看到的典型公司与前沿公司之间8.3倍的差距，在1月份时还是2.6倍。
但还有更多理由让你考虑编码。你已经在做许多非常适合由软件支持的活动，而且那些你认为一直阻碍你的障碍如今已基本消失。现在开始的原因是，在你这样做之前，很难看清工作中哪些问题实际上有软件形态的解决方案。虽然今天我们也会尝试做很多这方面的探讨。
当我遇到像我之前提到的那位朋友这样的人时，我听到了一些常见的原因解释为什么他们还没有完全深入其中。很多都归结为自我认知：认为自己“不是”技术人员，无论这意味着什么。但如果你是一个已经使用AI几年并将时间分散在多个订阅服务中的人，你绝对有足够的技术能力涉足这个领域。
有些人害怕破坏东西。他们担心会犯错，或者授权AI做一些导致不可挽回错误的事情。虽然这里并非没有道理，但当然有办法解决这类担忧。恐惧不应该成为阻碍你的理由。对许多人来说，仍然是感知到的进入壁垒。如果他们首先尝试使用终端界面，可能看一眼就退缩了。
同样地，也许一些入门途径是错误的。如果他们试图在网上寻找教程，可能会让他们尝试构建与他们的工作无关的东西。我认为最大的问题是他们不确定从自己的角度来看，构建和使用AI编码对他们来说到底意味着什么。所以让我们具体回答这个问题。
我们将从三种构建模式开始。你可以将构建模式视为你正在编写的软件与已有工作之间的关系。我认为它分为三类：是复制旧的输出，改变旧工作的完成方式，还是使以前不可能的工作成为可能？第一种模式，我们称之为自动化。同样的工作，同样的输出。
在这种情况下，输出保持不变，但你不再手工制作它。这可能包括重命名文件、同步列表、填写模板、重新处理导出等类型的工作。如果你知道这项工作属于这种构建模式，那么接收该工作输出的人就不会注意到任何变化。如果为你完成这项工作的软件坏了，你只需回到手工操作，手动执行相同的步骤。
对某些人来说，这是一个好的起点，因为他们已经知道什么是正确的结果。而且很多这类重复性工作相对于你实际上可能想在工作中做的事情来说，非常耗费时间和精力。第二种模式我们称之为升级：同样的工作，但新的输出。
这方面的一个例子是报告变成实时仪表板，演示文稿变成Web应用程序，状态邮件变成自助服务页面。与自动化不同，在升级模式中，工作的接收者能够察觉到差异。
另一端得到的结果截然不同，且 presumably 要好得多。如果你的软件因此出错，你可以回退到旧的 PDF、电子表格或会议记录中，但这样做可能会让人相当不满意。升级工作的回报不仅仅是节省时间，而是让这类重复性任务成为一种真正的资产和超越他人、脱颖而出的方式。
第三种模式最令人兴奋，但在我们真正身处其中之前最难理解，那就是发明。换句话说，是新工作、新产出。这种构建模式涉及那些以前不存在的工作，因为用旧的 manual 方式去做从来都不切实际，甚至不可能。面试每一个人、监控数百个来源、测试成千上万种不同的文案组合，在软件出现之前，这些完全超出了可能性的范畴。但现在突然间，通过构建以前不可能实现的东西，这一切都被解锁了。
除了有时很难从外部识别出什么是这种发明类型的良好用途之外，还存在一种风险：由于没有可复制的先例，你可能会发现自己构建了一种最终你自己或任何人都不会使用的能力。当然，我确实构建了比日常工作中实际使用多得多的东西，这只是业务成本的一部分。好了，我们现在有了三种构建模式：自动化、升级和发明。接下来谈谈交付类别。
这关乎所产生的软件的形态，关于谁在使用它以及用于什么目的。理解这一点将决定你需要构建的软件类型需要多少安全性、文档、用户界面（UI）、用户体验（UX）考虑因素以及支持等。事实证明，这里有很大的范围差异。所以让我们谈谈一些非穷尽的分类。
在光谱的一端是原型（Prototypes）。这是一种临时构建，其目的是回答一个问题、测试某种交互或想法，或者帮助推动决策进入下一步。你产生的东西实际上可以相当一次性使用。你可能是在为自己的工作或团队进行原型设计，或者将原型作为一种新的方式来解释你希望看到的特性，并与之前无法接触的其他团队互动。
这些构建优化的是速度、清晰度和代表性示例，而不是安全性、深度或可用性等方面的事。沿着耐用性的阶梯向上移动，我们接下来看到许多人称之为“个人软件”的东西。这是你为自己或身边的小团队构建的工具，以持续可靠的方式处理某些特定需求。
虽然原型只需展示想法即可，但个人软件仍需足够好，以便实际完成你或你的团队需要它做的事情。但你仍然可以在完美用户体验、权限考虑因素、视觉打磨和边缘情况等方面做出妥协。基本上，因为它是为你自己使用的，任何你觉得值得的妥协都可以进行。
这在耐用性阶梯上更进一步的一个类别中有些模糊，我们可以称之为“生产级软件”（Production Grade Software）。这是将由你或你的小团队以外的人使用的软件。在这里，失败可能会损失信任、时间、金钱、访问权限等。它需要足够好，以便用户（再次强调，不是你自己）能够在现实的负载条件下实际使用它。
必须存在解决不可避免出现的问题的途径。它必须具备足够的安全性、访问控制、隐私保护等，以满足任何用户的需求。但你谈论的还不是大规模消费。它仍然非常特定于某些具体目的和特定的人群。
需要注意的是，尽管个人软件和生产级软件比我定义的原型更耐用，但它们仍然可以是可丢弃的。如果你的个人或生产级软件仅对某些特定目标、在特定时间段内有用，然后你停止使用它，这没关系。这是现在构建软件如此不同的地方之一：以前我们不会花费时间去构建一次性使用的软件，我们会通过其他方式解决它。
因为构建那种软件的成本无法由我们为其构建的时间量或特定用例所证明是合理的。这种平衡发生了变化，开启了许多有趣的机会。耐用性和重要性阶梯上最顶层的最后一个类别是真正的产品（Product），它不仅服务于特定的人群，而且服务于整个市场。
在这里你真正像软件工程师一样行事，并发布一些即使是你不认识的人也会以某种方式使用的东西。因此它具有为一般消费构建软件时始终存在的所有考虑因素和负担。现在让我使用来自 AI Daily Brief 的一个演示性例子来让你对此有所感觉。
AI Daily Brief（每日简报）一个有趣的事情是，我听到人们最喜欢的一点是其信息密度。人们非常喜欢他们每分钟获得的价值的比率。然而对于新人来说，这种信息密度可能会造成很大的进入壁垒。所以有一段时间，我有一个想法是将每期内容拆分成更小的部分。
由于我看到的最常见的增长模式是同事之间互相分享节目，我想围绕构成任何节目的特定关键引言、主题、想法或统计数据来组织这些部分，以便听众不仅可以分享整个节目，还可以分享他们认为对同事重要的特定部分。
这就是我们现在在 aidailybrief.ai 网站上的内容。但这个过程始于一个原型。在我实际构建整个系统之前，我做了一些测试来看看我使用的 AI 是否足够好以自动化提取这些主题。简而言之，直到我们获得 Fable 和 GPT-5.6（注：此处原文可能指代特定模型或版本，依音译保留）之前并非如此。
但一旦我通过原型设计确定了它确实足够好，我可以将其移动到下一个类别的个人软件中，在那里我实际构建了提取管道，可以将转录文本转化为网站上的新内容。这里有一些不可妥协的事情和我可以妥协的地方。然后一旦它为我工作了，
为了让它对我团队中的少数人可用，我仍将其归类为个人软件。但我遇到的下一个问题是我在社交方面投入不足。虽然我不认为仅仅自动化内容管道就构成了足够的社交策略，但它确实是任何社交策略的基础。事实是，我生产了如此多的内容，现在它们被分割成易于分享的形式，但之前并未得到分享，这简直太愚蠢了。
因此我构建的下一个东西是另一个管道自动化程序，它将提取网站数据并将其转化为 Twitter 和 LinkedIn 上的社交内容，然后自动发布。在很多方面，这仍然是个人软件，因为我并没有真正让它服务于他人，但随着它与现实世界系统交互，界限开始变得模糊。
对我而言，生产软件的一个更好例子是我实际上不会展示的例子，那就是我正在为赞助商构建的新报告系统。它不再是包含统计列表的电子邮件或电子表格，而是一个登录体验界面，赞助商可以在其中点击浏览，获取关于其广告出现的不同剧集表现的见解。
这绝对属于生产软件的范畴，不仅为我和我小团队服务，也为了服务于他人，尽管这是一个非常具体的、我实际认识的人群。当然，可能存在下一步的飞跃。例如，如果我想将这种赞助商报告软件变成人们可以购买的产品，那么我分享给赞助商的“生产软件”和我向他人出售的“产品”之间将存在巨大的跨越。这就是两者的区别。
好了，我们已经讨论了三种构建模式和四种不同的交付类别，但对你来说呢？你工作中的哪些部分可以转化为软件？这一部分的重大前提是：没有任何外部人员能够确切告诉你，你的工作中哪一部分最适合变成软件。但以下是一些我见过且亲身体验过的常见模式，或许能激发你的灵感。我将它们分为六类：演示工作、内容工作、数据工作、文档工作、收件箱工作和行政工作。
首先是演示工作。我们在某种程度上都需要向人们展示事物，这是升级构建模式的绝佳领域，底层任务保持不变，但输出类型完全不同。请问问自己：你是否有一种演示文稿可以通过互动受益？与其制作 PDF，不如构建一个 HTML 页面。事实上，我在档案中有一整集关于为什么你应该使用 HTML 而不是其他内容形式的讨论。
你是否向不同的人解释相同的事情？如果你已经走过同一套信息一百次，这可能非常适合构建一个交互式说明工具或回答问题的机器人。你是否为不同的人计算相同的内容？这可以变成一个自助计算器。你是否帮助人们比较选项、计划、供应商、场景或套餐？这可以变成一个对比工具。
你是否在引导新员工入职或培训人员？如果你每次都给新客户或新雇员同样的介绍，这可以变成一个 walkthrough（引导流程）、清单甚至测验。你是否告知人们项目、订单或申请的进展状态，以及随之而来的更新邮件？这是在等待一个自动化的状态页面，让他们可以直接查看并停止询问。
你是否反复查找相同的参考资料、费率、规则或联系规格？在我看来，这听起来非常适合构建一个查询工具。下一个类别是内容工作。这是另一个非常常见的类别，AI 最擅长的事情之一就是将一种内容转化为另一种内容。
如果你将转录稿变成摘要，或将长文变短文，或把一篇文章拆分成五篇帖子，这不仅非常适合 AI（你可能已经在这样做了），而且你应该为此构建一个自动化管道。回想一下我为网站提取数据建立的管道：我是否每天可以将当天的转录稿丢进 ChatGPT 或 Claude，要求它提取所有关键标题并给我一个列表，然后我手动输入网页？
当然我可以这样做，这仍然比我手动提取那些部分快得多。但完全没有理由不能让整个过程端到端地自动化。这就是我构建软件来实现这一点的地方。下一个类别是数据工作，这是我在非技术知识工作者开始构建软件以帮助他们时看到的最常见的起点之一。
考虑到许多数据分析师已经有一些编写 Python 来辅助工作的经验，这并不奇怪这也是很多人的入门途径。所以如果你在进行任何类型的重复性数据分析——拉取数字、制作相同的图表、回答“我们表现如何”的问题，构建一个既包含回答这些问题的仪表板又包含允许人们提出不同问题的交互式工具的应用程序，是构建软件的极好用途。
这基本上描述了我刚才为 AIDB 讨论的赞助商门户。数据工作的另一部分与内容工作有些关联，即“数据翻译”，你从某个系统导出数据，手动重新加工成其他人需要的格式，例如将 CRM 导出变成销售表。如果第一步是自动化该过程的某些部分，第二步就是构建一个端到端自动化的软件管道。
这种模式在下一个类别——文档工作中也经常出现，许多知识工作者选择构建软件而不是仅仅使用 AI 的起点是：如果他们发现对于反复做的事情，AI 可以加速该过程，那么可能还有进一步自动化的步骤。如果你构建软件来执行这种自动化——例如反复填写相同的模板，对大量文件做同样的操作（如重命名、转换或调整大小），或者阅读许多文档以查找特定内容。
AI 可以手动帮助你，即你每次将这些东西输入 AI；或者如果你构建软件来实现这一点，它可以在后台自动持续地帮助你。收件箱工作：你是否从人们那里收集东西，如申请、注册请求或提交内容？在许多情况下……
可能已经有现成的软件能为你解决这个问题，但完全不能排除存在某种特定的、离散的需求，无法完美契合任何一家供应商的产品。如果是这样，考虑构建一个数据接入系统就是一个合理的理由。顺便提一下，这引出了另一个我认为很重要的观点：仅仅因为你能构建某样东西，并不意味着你总是需要去构建它。
在你开始踏上利用 AI 进行编程的旅程后，几乎肯定会发现一种情况：你会盯着某个付费服务，心想“我完全可以自己构建这个”，并问自己为什么要为此买单。但通常会有充分的理由不去这样做。那些以响应客户对特定产品需求为全部职责和使命的团队，在把软件做好方面拥有的原始能力，远比你把它作为待办事项清单上的第 68 项任务要强得多。
在决定完全自己构建之前，我几乎总是会先检查是否有现成的东西可以替我做这件事。最近在我构建社交管道时出现了一个例子：我们本可以直接通过 X 和 LinkedIn API 进行自动发帖，但我们发现了一款名为 Typefully 的服务，它原生具备这种能力，并且能与我们构建的管道很好地交互。这为我节省了巨大的痛苦、煎熬以及 Token 消耗。
因此，即使在我的个人软件语境下，这个个人软件也能与别人构建的、旨在成为完整解决方案的非个人软件进行交互。最后，让我们尝试通过六个理论项目将所有内容整合起来。再次声明，这些只是谦卑地作为思维起点提交给你们，并非知识工作者最佳构建项目的典范。每个类别包含两个项目，首先是自动化类：
第一个项目我称之为“周五导出”。这是将你闭着眼睛都能做的电子表格仪式，转化为一个小型、可检查的转换管道。你从某个系统中获取 CSV 或电子表格，重命名、过滤、拆分、连接、计算、重新排序、重新样式化并分析它。你要构建的是一个本地页面，你可以将原始导出文件拖入其中，预览转换结果，查看任何需要关注的内容，并以完全相同的旧格式下载完成后的文件。
这是同样的可信交付物，但你不再需要牺牲你的周五下午了。类似类型的自动化是“发票堆”。你有作为 PDF 或照片到达的发票、收据和账单，还有一个跟踪器，其中供应商日期、金额、类别和参考编号都是手动输入的。你要构建的是一个监视文件夹或放置区，它读取每个文档，规范化其字段，标记低置信度值，捕获重复项，并生成同样的关键电子表格。
但在这里，你只是进行审核，而不是进行手动输入。你可以看到，“自动化”这种构建模式确实是关于节省你的时间和痛苦，并为你留出空间去做其他事情。为此而构建软件只是你工具包中的另一种夺回时间的工具。你先投入少量前期成本来构建软件，然后在另一端获得巨大的时间投资回报率。
接下来我们要讨论的项目属于“升级”类的构建模式。第一个是一个在本集中多次出现的想法，我们称之为“实时报告”。任何时候你都需要在特定的常规间隔内向某人提供一组数字或分析，你可以考虑不再发送快照，而是给他们一个地方来查看持续或定期更新的数据流。
他们有能力对信息进行提问和审查，而不需要你充当中间人。我的赞助商就是一个例子，但也许你有一封每周或每月的数字邮件、一个演示文稿、一份给客户、老板、董事会、朋友或赞助商的 PDF，随后是不同日期范围和分析的请求。你要构建的是一个从数据源刷新的专注页面。
它将向用户显示数据最后更新的时间，自动回答最重要的问题，并提供一定程度的自动化分析。如果你真的想挑战自己，也许你甚至允许他们以某种方式使用 AI 与之交互，尝试在不先找你的情况下获得问题的答案。这不仅是升级的一个例子（工作相同但输出更好），也是生产软件交付类别的一个例子：
你正在构建某样东西，将由其他人使用，但是一个非常具体且可知的“其他人”，你可以基于该受众确定合适的权衡。我们要讲的第二个升级项目称之为“What-If 滑块”。我相信你们中的一些人有某种预测、人员配置计划、报价或情景模型，以及最终不可避免地会提出这样一个问题的演示文稿：“如果我们改变价格、数量、时机或人员配置，会发生什么？”
也许你可以只用电子表格来做这件事。同样，我们不是为了构建软件而构建软件。Excel 和 Google Sheets 在允许你更改数字并查看结果方面确实做得很好。但 Excel 有其局限性，并且可能有很多无法清晰转换为数字的额外变量。个人软件风格的 What-If 滑块——即一个暴露变量并允许人们与之交互、更改它们以查看另一端输出如何变化的页面——可能是那种 What-If 情景规划的更好选择。
最后，关于“发明”方面有两个理论项目。第一个我们称之为“监视器”，基本上就是你的个人代理研究员。想象一下，你有一些随时间变化的信息或数据，了解这些变化对你的工作至关重要。这可能是竞争对手定价、职位发布、资助页面提及、库存或不可预测变化的监管指导。
尝试手动跟踪所有这些内容是可以做到的，但如果这些变化发生的时间有些不可预测，那将花费大量的时间和精力。你可以构建一些检查器来监视这些数据源，清理无关噪音，跟踪历史和变化，并在必要时自动发送更新。这显然是一个以前不存在的监控工作，但现在可以帮助
你将以一种根本更好的方式完成工作。现在的常规听众可能会在心里想，天哪，这听起来有点像你可以用个人代理软件（如 OpenClaw 或最近的 Grockbot）做的事情。而你是对的，我认为在未来几个月和几年里我们需要关注的一点是：有多少我们现在所谓的“构建”项目——即你原本需要定制开发软件的项目——能够通过代理，借助正确的预编程和可定制化组合来解决。
虽然构建东西很有趣，但我们显然应该为更简单的方法感到高兴，因为它们让我们无需花费大量精力就能解决问题。另一个发明项目——老实说可能会最终成为代理的领域——我称之为“模式阅读器”。想象一下，你有一大堆没人有时间去阅读的信息：支持工单、销售对话记录、评论、申请表格、调查回答、面试笔记或事故报告。
你可以构建一个本地分析工具来清理所有这些数据，归类重复出现的主题，比较不同片段或时间段，将主张链接回代表性的原文段落，并提供持续更新的分析。因为这种“模式阅读器”是一个持久存在的软件，它会定期自我更新，你可以在任何时间点与其交互，而无需做大量准备工作来让它回答你的问题。
现在必须注意的是，虽然对我来说列举一些自动化或升级式的构建模式示例相对容易，但在发明方面，几乎无法预知你会发明出什么东西，直到你开始动手尝试。我认为这最终就是建议的核心所在：现在没有任何理由不让你深入其中，开始实验 AI 编程如何支持你的工作。
如果你想从最有帮助的“辅助轮”起步，可以使用 Lovable 或 Replit。如果你希望留在你已经在使用的生态系统中，可以尝试 CodeC or Claw Code。无论哪种情况，都请从我刚才说的所有内容中挑选出你觉得稍微有点感兴趣的东西，然后去看看构建那个东西需要付出什么。
也许它最终什么都不是；也许你立刻放弃了它；也许经过时间和实验后，你决定现有的软件或代理其实什么都能为你做。但我坚信的是：构建软件的目的不是为了发布供他人使用的软件，而是为了更好地完成自己的工作——这现在已经成为知识工作者需要具备的基础能力。
希望在这一集之后，开始这项任务的感觉不再那么令人望而生畏。但就目前而言，今天的 AI 每日简报就到这里了。一如既往地感谢你的收听或观看，我们下次见，再见。