How to Start AI Coding If You Haven’t Yet

好吧，朋友们，现在正式到了，正式到了该停止认为用AI写代码只是软件工程师才干的事情的时候了，因为事实并非如此。

显然，在过去一年半的时间里，随着像Lovable、Replit，还有后来的Claude Code和Codex这类工具上线，越来越多非软件工程领域的知识工作者开始学会如何利用写代码和构建软件的力量来解决自己的问题。

这不仅仅意味着那些非软件工程师突然之间要假装自己是软件工程师。

而是他们借助自己能够构建的软件，找到了完成工作新方法。

然而对于很多人来说，这仍然感觉遥不可及、高不可攀，但本不必如此。

The AI Daily Brief是一个每日播客和视频节目，关注AI领域最重要的新闻和讨论。

好了，朋友们，快速通知几件事。

最近我和女儿一个朋友的家长聊了聊，这位家长已经大量使用AI好几年了。

他们为好几项服务都订阅了多个高价套餐，并且把很多工作都转移到了AI辅助的模式下。

但即便对他们来说，考虑任何跟AI写代码相关的事情仍然显得完全陌生。

简而言之，他们一直活在那种用ChatGPT的日常里，从未踏入Claude Code的世界，我觉得因此损失不小。

我完全不去评判每个人处在什么阶段，但我觉得作为一个非软件工程师的知识工作者，如果到现在你的工具箱里还没有AI写代码工具，那确实落后了。

本周早些时候，我们做了一期节目，关于OpenAI最近的企业研究。研究发现，大约在四月底五月初的时候，通过API以Agent方式消耗的token比例，已经反超了通过ChatGPT非Agent方式使用的token量，而且这个比例还在不断攀升。

我们看到，排名前10%的企业用户，相比普通企业用户，AI使用量大约是8.3倍，而且他们部署的应用场景要复杂得多，更多地涉及系统构建和整体性变革。

为了更清楚地说明这不仅仅是软件工程师的事，从二月份基线数据来看，企业中与工程相关的Codex用户增长了5倍，而其他职能部门的增长幅度要大得多。

财务和会计部门对Codex的使用量比二月份增长了20倍，销售和会计部门增长了41倍，法务部门则增长了108倍。

那么，这些人都用AI写代码在做什么呢？

大多数情况下，他们并不是突然就要成为自己公司的软件工程师。

我认为这是早期“vibe coding”的一个误解，这个误解至今仍有点顽固地存在着，尽管很长时间以来这已经不是人们的真实情况了。

对于知识工作者来说，将AI写代码作为自己AI工具箱一部分的真正理由，并不是你要变成软件工程师，而是因为我们看到，那些正在构建东西的人，正在积累相对于其他AI用户的优势和收益。

我们看到的典型企业与前沿企业之间8.3倍的差距，是从一月份的2.6倍差距上升而来的。

但还有更多理由让你应该考虑写代码。

你已经在做很多非常适合用软件支持的工作了。

而且很多以前你认为阻碍你的障碍，现在基本上都消失了。

现在开始的原因在于，在你真正开始之前，你很难看出自己工作中的哪些问题其实有软件化的解决方案。

不过我们今天会试着帮你解决很多这类问题。

每当我遇到像我刚才提到的那位朋友那样的人，总会听到一些常见的、他们还没完全投入的理由。

其中很多都与自我认知有关。

比如觉得自己“不是技术型的人”，不管这到底是什么意思。

但如果你已经用AI好几年了，还在多个订阅服务之间分配时间，那么你绝对足够“技术”到可以涉足这个新领域了。

有些人害怕把东西搞坏。

他们担心会犯错，或者授权AI去做一些会导致无法挽回的错误的事情。

这种担心并非完全没有道理，但当然有办法解决这类问题，而且恐惧绝对不应该成为你的阻碍。

对很多人来说，这仍然是他们感受到的入门门槛。

如果他们一开始尝试使用终端界面，可能看一眼就转身离开了。

与之相关的是，可能一些入门途径本身就不对。

如果他们在网上找教程，可能教程让他们去构建的东西跟他们的工作毫不相关。

我觉得这才是最大的问题：他们从自己的角度出发，不确定构建和使用AI代码到底能为他们带来什么。

那我们就来具体回答这个问题。

我们先从三种构建模式开始。

你可以把构建模式理解为，你编写的软件与现有工作之间的关系。

我认为它分为三类。

是复现旧的产出，改变旧工作的完成方式，还是让以前不可能完成的工作成为可能？

模式一，我们称之为自动化。

同样的工作，同样的产出。

在这种情况下，产出保持不变，但你不再手动制作。

比如重命名文件、同步列表、填写模板、重新处理导出文件之类的事情。

如果接收这份工作产出的人不会注意到有任何变化，那你就知道这份工作属于这种构建模式。

如果你为此构建的软件出了问题，你只需回到手动操作，重新执行相同的步骤。

对有些人来说，这是一个很好的起点，因为他们已经知道正确的结果应该是什么样子。

而且其中很多都是重复性的工作，相比你真正想在工作中做的事情，既费时又费精力。

第二种模式，我们称之为升级。

同样的工作，但新的产出。

举个例子：一份报告变成一个实时仪表盘，一份演示文稿变成一个网页应用，一封状态更新邮件变成一个自助查询页面。

与自动化不同，在自动化中，接收工作的人无法分辨差异。

而在这种模式下，接收方得到的东西是明显不同的，而且很可能好得多。

现在，如果你用于升级的软件出了问题，你可以回退到旧的PDF、电子表格或会议。

但这样做的体验可能很不令人满意。

升级工作的回报不仅仅是节省时间，而是让这类重复性任务变成一种实际资产，以及一种超越他人、脱颖而出的方式。

模式三最令人兴奋，但也是最难理解的，除非我们真正投入其中。

这就是发明。

换句话说，新的任务，新的产出。

这种构建模式涉及之前不存在的工作，因为用老式手动方式去做，从来就不现实，甚至根本不可能。

采访每一个人，监测数百个来源，测试成千上万种不同的文案组合——所有这些，在软件出现之前的世界里，是完全不可能做到的。

但现在，多亏了构建，以前不可能的事情突然变得可行了。

而且，除了有时候从外部很难判断哪些用例适合这种发明之外，还存在一个风险：由于没有现成的成功案例可以模仿，你有时可能会发现自己构建了一个最终连你自己和任何人都用不上的功能。

当然，我构建的东西远远多于我日常实际用到的，这只是做这件事必须付出的成本之一。

好了，我们现在有了三种构建模式：automate、upgrade、invent。

接下来，我们来谈谈交付类别。

这指的是最终产出的软件形态。

它关乎谁在使用它，以及用来做什么。

理解这一点将很大程度上决定你需要构建什么样的软件，需要多少安全、文档、UI/UX 考量、支持等等，也就是你构建的东西实际需要什么。

而实际上，这里面的范围非常广。

那么，我们来聊聊几个不完全的类别。

一端是prototype。

这是一种临时构建，它的目的是回答一个问题，或者测试某种交互或想法。

或者帮助将决策推进到下一步。

你产出的东西其实可以是一次性的。

你可能是在为自己的工作或团队制作原型，或者用原型作为一种新方式，向其他团队解释你希望看到的功能，而以前你做不到这一点。

这些构建，你要优化的是速度、清晰度、有代表性的例子，而不是安全性、深度、可用性之类的。

往上走，在耐久性阶梯上，接下来是很多人称之为personal software的东西。

这是你为自己，或者身边的小团队构建的一个工具，它能持续、可靠地处理某个特定需求。

原型可以只是展示想法，而personal software仍然需要足够好，能真正完成你或团队需要它做的事情，但你仍然可以在完美用户体验、权限考虑、视觉美化、边界情况等方面做出妥协。

基本上，因为它是为你自己做的，只要你觉得某个妥协值得，你就可以做那个妥协。

这有点模糊地过渡到下一个类别，在耐久性阶梯上再往上走，我们可以称之为production-grade software。

这是会被你或你小团队以外的其他人使用的软件。

在这样的软件中，一次失败可能损失信任、时间、金钱、访问权限等等。

它需要足够好，让那些不是你的人能够在真实的负载条件下真正使用它。

必须有解决必然出现的问题的途径。

它必须有足够的安全性、访问控制、隐私保护等，以满足用户的需求，无论用户是谁。

但你还没说到大规模消费呢。

它仍然是非常特定的，用于某个具体目的、某类具体人群。

现在要说明的是，即使我在这里定义的个人软件和生产软件比原型更持久，它们仍然是可以被丢弃的。

如果你的个人软件或生产软件只在某段特定时间内对某个特定目标有用，之后你就不再用了，那也没问题。

这是现在做软件和过去很不一样的一点，以前我们不会花时间去搭一个用完就扔的软件。

我们会用其他方式解决问题，因为建那个软件的成本不值得我们为它花那点时间或那个特定用例。

这个等式变了，也带来了很多有趣的机会。

最后一个类别，沿着持久性和重要性的阶梯往上走，是真正的产品，它不只是服务某个特定群体，而是要服务整个市场。

这就跟你像过去那样当软件工程师一样，发布一个东西，连你都不认识的人会用上它。

这样一来，它就继承了所有为大众消费构建软件时需要考虑的那些问题和负担。

现在，我用AI Daily Brief举个例子来说明。

为了让你有个概念，AI Daily Brief这件事有趣的一点是，我听到最多人喜欢它的原因之一就是信息密度高。

大家真的很喜欢每分钟获得的价值比。

不过，对新人来说，这种信息密度可能成为一个很大的入门障碍。

所以有段时间，我一直想把每期内容拆成更小的片段。

因为我看到最常见的增长模式是同事们互相分享节目，所以我希望把这些片段按照节目里那些关键引语、主题、想法或数据来组织，这样听众不仅能分享整期节目，还能分享他们认为对同事有用的那部分。

现在aidailybrief.ai上的网站就是这么来的。

但这个过程是从一个原型开始的。

在真正搭建整个系统之前，我做了很多测试，看看我用的AI够不够好，能不能自动提取这些主题。

简单说，直到我们有了Fable和GPT-5.6之后才做到。

但当我通过原型验证了它确实够好之后，我就把它推进到下一个类别——个人软件，实际搭建了一个提取管道，能把转录内容转成网站上的新版本。

这里面有些东西是不能妥协的，有些则可以凑合。

然后，当它在我这能用了之后，我需要让团队里少数几个人也能访问，我仍然把这归为个人软件类别。

但接下来我遇到的问题是，我在社交方面投入得还不够。

虽然我不认为只自动化内容管道就足以成为社交策略，但它绝对是任何社交策略的基础。

事实上，我生产了那么多内容，现在被分割成容易分享的形式，却没人去分享，这太蠢了。

所以我接下来建了另一个管道自动化，把网站上的提取内容转成Twitter和LinkedIn的社交文案，然后自动发布。

从很多方面说，这仍然算个人软件，因为我实际上没让它服务别人，但一旦它和真实世界的系统互动，界限就模糊了。

也许在我的世界里，生产软件更好的例子是我不会给你展示的那个，而是一个我正在为赞助商搭建的新报告系统。

它不再是一堆统计数据的邮件或表格，而是一个登录体验，赞助商可以点来点去，了解他们广告所在的不同集数的表现情况。

这是一个完全属于那种生产软件类别的例子，它不仅仅是为我和我的小团队服务的，而是为他人服务的，但这个“他人”是一个非常具体的、我实际上认识的一群人。

当然，现在可能还有下一步可以走。

比如说，如果我想把那个赞助商报告软件变成一种人们可以直接购买的产品，那么我之前与赞助商共享的生产软件和我要卖给别人的产品之间，会有一个巨大的差距。

这就是这两者之间的区别。

我每天都在这个节目里讨论AI潜力和AI现实之间的能力差距。

大多数公司还在摸索如何起步。

AWS高级合作伙伴在一年内规模翻了一倍多，现在有50个职位空缺正在招聘。

如果你是一个知道这个时刻不同寻常的人，想要参与其中，而不是旁观，那么这值得一看。

在Robots and Pencils，最好的想法胜出，团队刻意保持极高的质量。

这是一个你日后回想起来会觉得自己做出了最正确决定的地方。

好了，现在我们讨论了三种构建模式和四种不同的交付类别，但对你来说呢？

你工作中的哪些部分可以变成软件？

在这一部分，我要特别强调的一点是，没有外人能确切地告诉你，你的哪些工作最适合变成软件。

但这些是我见过并经历过的常见模式，也许能激发你的灵感。

我把它分成了六类：展示工作、内容工作、数据工作、文档工作、收件箱工作和管理工作。

首先是展示工作。

几乎我们所有人，在某种程度上都需要向别人展示一些东西。

而这正是“升级构建”模式的最佳领域之一，底层工作保持不变，但输出类型是全新的。

所以想想这些问题。

你有没有某种展示，如果加入互动性会更好？

与其做PDF，不如做一个HTML页面。

事实上，我在节目档案里有一整集专门讲为什么你应该用HTML而不是其他内容形式。

你是否向不同的人解释同样的事情？

如果你已经重复讲过同一套信息100次了，那可能很适合做一个互动讲解器，或者一个能回答问题的机器人。

你是否为不同的人计算同样的东西？

同样，这可以变成一个自助计算器。

你是否帮助人们比较选项？

比如计划、供应商、方案、套餐？

那可以变成一个比较工具。

你是否负责新员工入职或培训？

如果你每次都给新客户或新员工做同样的导览，那可能会变成一次演练、一份清单，甚至是一个小测验。

你会告诉大家目前的进展吗？

项目、订单、申请，以及随之而来的所有更新邮件？

那其实就是在等一个自动化的状态页面，这样他们自己看一眼就好，不用再追着问了。

你是不是总在反复查找同样的参考资料？

比如费率、规则、联系人、规格？

这在我看来，又是一个非常适合用查找工具的场景。

下一类是内容工作。

也是非常常见的一类。

AI最擅长的事情之一就是把一种内容转换成另一种内容。

如果你把文字记录变成摘要，把长篇变成短篇，或者把一篇内容变成五篇帖子，这不仅是AI特别擅长的，而且很可能你已经在用AI做这些事了。

你应该考虑构建一个自动化流程来处理这些工作。

想想我为网站搭建的那个提取流程吧。

我能不能每天都把当天的文字记录扔进ChatGPT或者Claude，让它提取所有关键标题，给我一份列表，然后我再手动把它们粘贴到网页上？

当然可以，那样做已经比我手动提取要快得多了。

但整个流程完全没有理由不实现端到端的自动化，而这就是我决定搭建软件来做这件事的原因。

接下来是数据工作类别，这也是我看到很多非技术背景的知识工作者开始为自己搭建软件时最常选用的起点之一。

考虑到很多数据分析师已经有了一些用Python辅助工作的经验，这一点其实很好理解。

所以它成为很多人的入门方向一点也不奇怪。

所以，如果你在做任何重复性的数据分析——比如拉取数据、制作同样的图表、回答“我们做得怎么样”之类的问题——那么搭建一个应用，既包含回答这些问题的仪表盘，又提供交互式工具让人们能提出不同的问题，

这是非常值得利用软件开发来做的一件事。

这基本上就描述了我刚才提到的AIDB的赞助商门户。

数据工作中还有另一部分，有点回到内容那一块，就是数据转换——从某个系统导出数据，然后手动整理成别人需要的格式，比如把CRM导出数据变成销售表单。

如果第一步是把这个过程中的某些部分自动化，第二步就是搭建一个软件流程，把整个过程完全端到端完成。

这个模式在下一个类别——文档工作中也经常出现。

很多知识工作者开始搭建软件而不只是使用AI，是因为他们发现对于反复做的事情，AI可以加速完成，但如果进一步搭建软件来自动化，还能更进一步。

比如反复填写相同的模板，对很多不同文件做同样的操作（如重命名、转换格式、调整大小），或者阅读大量文档寻找特定内容——AI可以帮你手动完成这些，

也就是说，你每次把这些内容分别喂给AI，或者你也可以搭建软件来自动持久地帮你完成这些操作。

收件箱工作。

你是否从别人那里收集申请、注册请求、提交之类的东西？

现在很多情况下，可能已经有现成的软件能帮你解决这个问题，但也不排除你有一些特定的、零碎的需求，跟那些供应商的产品不完全吻合。

那这就是你考虑搭建一个收件系统的理由。

顺便说一下，这又引出了另一个我觉得很重要的观点。

能自己动手做点什么，不代表你总是需要去做。

一旦你开始踏上自己动手和AI编程的旅程，几乎肯定会遇到这种情况：你盯着某个付费的东西，心里嘀咕，这个我自己也能做啊。

干嘛还要花钱呢？

但往往会有充分的理由让你不去做。

一个团队，他们的全部工作和使命就是围绕某个产品响应客户需求，他们有比你多得多的精力和能力去把软件做好——而对你来说，这只是待办清单上的第68项任务。

几乎每次，在决定完全自己动手之前，我都会先看看有没有现成的东西能帮我搞定。

最近我在搭建社交发布流程时就有个例子：我们本可以直接通过X和LinkedIn的API来自动发帖，但后来找到了一个叫Typefully的服务，它本身就具备这个功能，而且和我们搭建的流程配合得很好。

这省了我大量的烦恼、痛苦和token。

所以即便是针对我个人的软件，它也能很好地跟别人开发的、非常成熟的非个人软件互动，形成一个完整的解决方案。

最后，我们试着通过6个理论上的项目来把这一切串起来。

再次强调，这些只是抛砖引玉，给您一些思路启发，并不是说这就是知识工作者最佳的项目构建范例。

三种不同的构建模式，每种下面各有两个项目。

先说自动化，第一个项目我管它叫“周五导出”。

就是把那个你闭着眼睛都能做的电子表格例行操作，变成一个小型、可核查的转换流程。

就是说，你从一个系统拿到一个CSV或电子表格，然后要重命名、筛选、拆分、合并、计算、重排、重设样式、分析。你接下来的目标是构建一个本地页面：你把原始导出文件拖进去，预览转换效果，看看有没有需要关注的地方，最后下载完成后的文件，格式跟以前一模一样。

交付的结果还是那个大家信赖的东西，但你不用再搭上整个周五下午了。

类似的一种自动化是“发票堆”。

你手头有发票、收据、对账单，有的是PDF，有的是照片；还有一个跟踪表，里面供应商、日期、金额、类别、参考号都是手动输入的。

你接下来要构建的是一个受监控的文件夹或拖放区：它能读取每个文档，标准化字段，标出低置信度的值，识别重复项，然后生成那个原来一样的关键电子表格——只不过你只需要做审核，不用再手动输入了。

你可以看出，自动化的构建模式本质上就是帮你省时间、省烦恼，给你腾出空间做其他事；而写软件来实现这一点，只是你赢回时间的工具箱里的又一件工具而已。

前期投入一点时间把软件建好，后面就能获得巨大的时间回报。

接下来我们要聊的项目属于“升级”这个构建模式。第一个是这期节目里已经提过好几次的想法，我们叫它“实时报告”。

任何时候，只要你需要定期向某人提供一些数据或分析结果，都可以考虑不再发送快照，而是给他们一个地方，让他们能看到持续或定期更新的数据流，并且还能提问和查询这些信息——而不需要你来做中间人。

比如我的赞助商就是一个例子。但也许你每周或每月要给客户、老板、董事会、资助方、赞助商发一封包含数字的邮件、一份PPT或者一个PDF。

然后还会收到要求不同日期范围、不同分类的请求。

你要构建的是一个聚焦的页面，它能从数据源刷新。

它能告诉用户数据是什么时候更新的。

它会自动回答那些最重要的问题。

它还会提供一定程度的自动分析。

如果你真想挑战自己，甚至可以允许他们用AI跟它互动，尝试自己找到问题的答案，而不用先来找你。

这个例子不仅说明升级之后工作内容没变，但产出的质量更好了。

它也体现了生产级软件交付的特点——你构建的东西要给别人用，但对方是特定且可预知的群体，你可以根据他们的需求来决定什么样的取舍是合理的。

第二个升级项目，我们叫它‘假设滑块’。

我知道有人肯定做过预测、人员计划、报价、情景模型和演示文稿，最后总会碰到一个问题：那如果我们改变价格、数量、时间、人数呢？现在你也许可以用电子表格来做。

再说一遍，我们不是为了做软件而做软件，Excel和Google Sheets确实很擅长让你改数字看结果。

但Excel也有局限，有些额外的变量没法很自然地转化成数字。这时候，一个个人风格的‘假设滑块’——就是一个页面，把变量展示出来，让人们可以交互、修改，看到另一端的输出会怎么变——可能更适合那种情景规划。

最后，还有两个理论上的发明型项目。

第一个我们叫‘监控者’，基本上就是你的个人智能研究员。

假设你有一些信息或数据会随时间变化，了解这些变化对你的工作至关重要。

比如竞争对手的定价、招聘信息、资助页面、媒体报道、库存数据、监管指南，这些都可能随时变化。

手动跟踪所有这些东西也能做，但如果变化时间不确定，那就会耗费很多时间和精力。

你可以建一个检查程序，盯着这些数据源，清理无关噪音，记录历史变化，并在关键时候自动发送更新。

显然，这是一种以前没有的监控工作，但现在可以帮助你从更根本的层面提升工作质量。

常听我们节目的听众可能会想，哎呀，这听起来很像用个人智能体软件能做的事，比如OpenClaw，或者最近的GrokBot。

你这么想完全没错。

我认为在接下来几个月到几年里，有一个现象值得关注：多少我们现在认为需要‘自建项目’（也就是你要写定制软件）的任务，会被那些兼具预设编程和可定制性的智能体解决掉。

虽然自己动手做东西很好玩，但如果有更简单的方法能解决问题、不用费那么大劲，那显然我们应该欢呼。

另一个发明型项目，叫‘模式阅读器’，说实话最后可能也会变成智能体的领域。

假设你有一大堆信息，没人有时间读完。

比如客服工单、销售通话记录、用户评价、申请材料、问卷答案、访谈笔记、事故报告。

你可以建一个本地分析工具，清理所有数据，归类重复出现的主题，对比不同时段或板块，把结论链接回有代表性的原始段落，并提供持续更新的分析。

因为‘模式阅读器’是一个会自动定期更新的持久软件，你随时都能调用它，不用再花一堆功夫把它准备好来回答你的问题。

很重要的一点是，虽然我举自动化或升级型构建模式的例子很容易，但说到‘发明’，不真的开始动手折腾，你基本不可能知道自己能发明出什么。

而我觉得这最终就是我推荐的核心。

现在没有任何理由不跳进去，开始尝试AI编程如何辅助你的工作。

如果你想从最稳妥的辅助轮开始，可以用Lovable或Replit。

如果你想留在自己已经熟悉的生态里，试试Codex或Claude。

不管怎样，从我刚才说过的所有内容中，挑出你感觉最模糊有趣的那个，然后就去看看，要构建出那个东西需要怎么做。

可能最终什么都不是。

可能你马上就会放弃。

也许经过时间和实践，你会发现其实现有的软件或agent已经能帮你搞定一切了。

但我坚信，编写软件——不是为了发布给别人用，而是为了让自己工作得更好——现在是知识工作者必备的基础能力。

希望听完这期节目后，你会觉得起步没那么吓人。不过现在，今天的AI Daily Brief就到这里了。

一如既往感谢你的收听或观看，下次再见，Peace。