2026-08-29 Workshop文字版

许多自动化机会，都从一句“这怎么还得手动搞”开始。

“这怎么还得手动搞？”我们都冒出过这个念头。可能是在几个系统之间复制同一份信息，可能是每天整理同一张表，也可能是又一次依靠记忆，把一个本该由系统接住的流程勉强做完。抱怨之后，我们通常还是会把事情做完。熟练的人甚至能把坏流程做得又快又稳，久而久之，摩擦被勤奋遮住，重复被习惯合理化，原本应该改变的事情，变成了“工作本来就是这样”。

自动化，就是拒绝接受这个默认答案。它不是按下一个神奇按钮，也不只是写几行代码，而是把一段依赖耐心、记忆和重复劳动的工作，重新组织成可以稳定运行的系统。这要求我们看清事情怎样发生：什么触发它，信息从哪里来，中间需要哪些判断，遇到例外怎么办，做错以后谁能发现、谁可以叫停、最后由谁负责。自动化当然很难，第一版会笨拙，模型会犯错，原本以为清楚的流程也会在动手之后暴露出更多例外。

但我仍然希望大家继续尝试。不是因为人工智能已经无所不能，而是因为今天的我们，第一次拥有了更低的成本，去挑战那些过去只能忍受的问题。真正值得鼓起热情去做的，恰恰不是最容易的事，而是那件你已经抱怨过很多次、也放弃过很多次，却依然相信不应该永远靠人重复完成的事。

把抱怨变成发现问题的能力#

Larry Wall 曾把懒惰、急躁和傲慢称为程序员的三种美德。这三个词听起来并不体面，却很准确地描述了自动化的起点：懒惰让人不愿意重复已经做过的机械劳动，急躁让人无法忍受不合理的等待，傲慢则让人相信流程可以被自己改变，并愿意对改变后的结果负责。它们的正面版本，是发现痛点的眼睛、自动化流程的动力，以及不把最终结果推出自己责任边界的 Ownership。

不过，抱怨本身并不会产生改进。“这个系统很烂”只是在表达情绪；“昨天上午，我为了确认一个订单状态，在三个地方查了四十分钟”才开始接近一个可以解决的问题。后者包含人物、时间、动作和代价，可以继续追问触发条件、输入来源、判断规则与最终输出。我把这种追问称为生产性的抱怨：烟感器响了，不是和烟感器争论态度，而是去看哪里冒烟。

很多坏流程之所以能长期存在，并不是因为没有人看见，而是因为总有优秀的人把它保护了下来。每天更新的表格永远很漂亮，每周复制粘贴的报告从来不出错，需要在五个系统里找答案的人已经熟练到两分钟就能完成。勤奋本身当然值得尊重，但它也可能让组织感受不到改变的紧迫性，因为总有人在最后一米把错误接住、把缺口补上。自动化不是否定这种勤奋，而是希望把人的努力从“维持坏流程”转移到“改变坏流程”。

坏流程最稳定的时候，往往正是有人熟练地替系统补偿缺陷的时候。

很多问题不是没有价值，只是过去不值得#

一件小事要变成可靠的软件，过去需要付出远超代码本身的成本。需求要被理解，问题要被定义，方案要被选择，流程要被设计，系统还要经过测试、部署、监控和维护。就像一家真正能运转的餐厅不只是会做一道菜，它还需要采购、排班、库存、收银、卫生和经营管理。为了吃一碗完全符合自己口味的面而开一家餐厅，听起来当然荒谬；为了一个只属于几个人的特殊流程组织起完整的软件生产线，过去同样不划算。

过去为一个 niche 需求开发定制软件，常常像为了吃一碗面而开一家餐厅。

这也是标准化软件长期占据主流的原因。软件公司收集许多人的需求，寻找最大的公约数，再设计一套能服务尽可能多用户的产品。这种模式创造了巨大的价值，但代价也很熟悉：现成的软件满足了你百分之八十的需求，同时带来大量用不到的功能；剩下的百分之二十，只能靠人削足适履。高度定制的软件则通常只有规模足够大的企业才承担得起，因为它不仅要支付开发成本，还要支付理解、协调和长期维护的成本。

人工智能带来的重要变化，不只是让一段代码生成得更快，而是让理解、试做、修改和执行的部分成本同时下降。成熟的云服务、开源软件和通用基础设施已经提供了身份、权限、数据、集成、日志等底层能力，AI coding 又让上层应用更容易按真实流程进行调整。原来需要一条组织链才能跨越的距离，现在可能由一个更小的团队，甚至一个同时理解问题和工具的人推动。问题没有突然变得简单，但“多小的问题才值得解决”这条边界正在移动。

这并不意味着每个愿望最后都应该变成一家长期运营的软件公司，但它意味着每一个真实的 niche 需求，都值得被做出来验证一次。过去，一个需求必须先证明市场足够大，才能获得开发资源；现在，它只需要证明对某个具体的人或团队足够重要，就值得做一个低成本实验。我们不应该继续沿用五年前的“不可能”，而应该重新计算：这件事发生得多频繁，等待和错误造成了什么损失，做出一个贴合流程的小工具需要多少成本。过去被归类为“有点价值，但不值得专门做”的问题，今天都应该重新进入候选名单。

Software 3.0 改变的是问题的经济性#

为了描述这种变化，我习惯借用 Software 1.0、2.0 和 3.0 这三个说法。它们的区别不只在于用了什么技术，更在于人用什么方式告诉计算机“我要什么”，以及软件最终以什么形态交付给用户。Software 1.0 把人的规则写成代码，Software 2.0 把人的样本训练成模型，而 Software 3.0 则开始把人的需求直接转化为能够运行的软件。

Software 1.0 的核心是人写规则。工程师把业务逻辑、条件判断和操作流程翻译成代码，代码就是软件的蓝图：输入什么、经过哪些步骤、出现不同情况时如何处理，都要尽量提前写清楚。这种软件确定、可靠、容易追溯，但修改它需要重新理解、设计、编码、测试和发布。因为每一次变化都很贵，软件自然要寻找尽可能多的共同需求，用同一套代码服务尽可能多的人。

Software 1.0：人把规则写进代码，软件沿着预先定义的路径执行。

SaaS 正是 Software 1.0 经济性发展到成熟阶段的代表。产品团队收集大量用户反馈，找到 common 需求，把它们固化为功能、页面和标准流程，再通过规模化销售摊薄研发成本。无法进入 common roadmap 的需求，要么等待排期，要么用配置、插件和人工流程勉强适配。用户买到的是一套已经做好的软件：它可能覆盖自己百分之八十的需求，但用户必须改变工作方式，去适应软件预先决定的边界。

过去的 SaaS：先寻找足够大的 common 需求，再把它们固化为一套标准产品。

Software 2.0 改变了程序内部的一部分。我们不再为文字识别、图像分类或推荐结果手写所有规则，而是提供大量数据，让神经网络学习一种概率性的决策函数。过去无法穷举的复杂输入因此可以进入软件，产品能力大幅扩展。但从用户角度看，2.0 时代的软件形态并没有发生根本变化：模型通常只是固定应用中的一个智能模块，页面、流程、权限和功能边界仍然由产品团队预先设计，产品依然需要围绕 common 需求规模化交付。

Software 2.0：人提供数据，神经网络学习过去无法穷举的复杂模式。

许多今天被称为 Software 3.0 的产品，其实仍停留在这一步：在原有 SaaS 里增加一个聊天框、一个内容生成按钮，或者一个更聪明的推荐模块。模型能力变强了，软件的外壳却没有改变。用户仍然需要进入一个固定产品，在产品允许的菜单、字段和流程里表达自己的需求。这当然有价值，但它还没有触及 Software 3.0 最根本的变化。

Software 3.0 的转折点，是 Agent 开始具备生成代码的能力。它不仅能生成一段文字，还能理解一个人的目标，阅读现有系统和数据，拆解任务，编写代码，调用工具，运行测试，并根据反馈继续修改。代码不再只是人提前写好、再交付给所有用户的固定产品；它开始成为 Agent 根据具体需求生成和维护的中间产物。用户表达的是“我希望这段工作怎样运行”，Agent 负责把这种意图转化为界面、流程、集成和自动化。

Software 3.0：代码成为 Agent 根据具体诉求生成和持续修改的中间产物。

这带来的定制化，不是过去 SaaS 意义上的“多开放几个配置项”。同一个通用底座之上，不同团队可以拥有完全不同的上层软件：客户支持可以按照自己的分类、升级和复核规则运行，销售团队可以使用自己的机会判断方式，一家小店甚至可以只为每天发生三次的特殊流程生成一个工具。软件不再要求所有用户先证明自己拥有 common 需求，才能获得一个功能；软件可以围绕每一个具体使用者，长成最适合他的形状。

从这个意义上说，过去那种“只有找到足够大的 common 需求，才值得开发软件”的 SaaS 模式，作为软件生产的唯一默认范式，已经走到头了。这不是说 SaaS 公司会消失，也不是说所有基础能力都要从零生成。身份、权限、支付、数据、日志、合规和模型服务仍然需要稳定、通用的基础设施，甚至会比过去更加重要。真正被终结的，是上层产品必须先服务一个巨大公约数，才能获得开发资格的逻辑。

未来更可能出现的形态，是通用 Infra 加高度定制的智能 App。底层能力继续规模化、标准化，上层应用则由 Agent 按具体诉求快速生成、持续修改。过去的 SaaS 试图把一百个客户装进同一个产品，Software 3.0 则可以让一百个客户共享同一个可靠底座，同时拥有一百种贴合各自工作流的软件。这不是把规模化丢掉，而是把规模化从“统一产品”下沉到了“统一基础设施”。

新的规模化发生在通用 Infra，面向用户的上层 App 则可以高度定制。

于是，任意 niche 的需求都值得做。这里的“值得”不等于每个需求都会成为大生意，也不等于生成出来的第一版可以直接进入生产环境；它意味着实现成本已经低到足以让我们先做出来、用真实样本验证，再决定继续还是停止。过去要先证明市场足够大，才能获得软件；现在可以先拥有软件，再用结果判断需求究竟有多大。Software 3.0 改变的不是一句开发口号，而是谁有资格拥有属于自己的软件。

当然，确定性的规则并不会因此失去价值。权限、金额、状态和不可逆动作，往往仍应由传统逻辑控制；模型适合处理语言、图片、模糊上下文和难以穷举的输入；Agent 则负责理解目标、组织步骤和生成必要的代码。可靠的 Software 3.0 不是让模型接管一切，而是让规则、模型、Agent 与人各自在适合的位置发挥作用，并且为确认、监控和失败回退留下清楚的边界。

一个小到过去不值得做的例子#

我做过一个叫 Stocker 的游戏。玩家可以回到不同的历史时期，在不知道真实公司名称和真实年份的情况下，交易一段已经发生过的市场历史。为了保持沉浸感，游戏里的新闻不能直接泄露真实公司和事件，也不能永远重复几份固定模板。市场每天发生什么、哪些变化值得报道、同一件事应该先出现传闻还是正式消息，这些内容会直接影响玩家如何理解局势。

如果完全依靠人工，开发者需要提前阅读行情、判断新闻价值，再用不同口气写出大量内容。规则填空可以撑住少量场景，但玩家很快会认出模板；直接使用真实新闻又会破坏游戏的未知感。为了几局朋友之间的游戏，维护一条长期内容生产线显然不划算。这个需求不是没有价值，而是生产成本高过了它能带来的体验价值，因此它过去不值得做。

现在的做法不是让模型从零开始担任“总编”。游戏引擎仍然决定哪一天发生什么、是真实冲击还是传闻、应该使用哪个化名，以及哪些信息绝对不能泄露；模型只负责把已经确定的事实写成符合场景的新闻文本。生成失败时，系统可以回到模板，游戏房间不会因为模型出错而无法继续。换句话说，值班表是人排的，模型只写句子。

Stocker 运行时生成的新闻	游戏中的 Agent 聊天室

Stocker 把生成能力放进现有游戏引擎；模型负责表达，引擎负责事实、规则与失败回退。

这个案例真正证明的，不是模型有多聪明，而是成本曲线变了。过去需要预先堆积大量稿件，现在可以按天、按事件生成，并且为失败准备退路。一个原本不值得建立内容生产线的小体验，因为智能模块可以嵌入现有系统，第一次变得可行。自动化最值得期待的地方正在这里：它不只是替代已有劳动，也可能创造过去根本负担不起的产品和体验。

自动化的难点，从来不只是模型#

许多团队把人工智能想象成一个 Easy Button：把文档、规则和历史记录放进去，按一下，系统就能替人完成工作。真正动手后才会发现，最难的问题并没有消失。哪些规则适用于当前场景，数据缺失时怎么办，两个来源冲突时相信谁，什么动作可以撤销，什么时候必须停下来找人，这些问题都无法靠一句更长的 Prompt 自动解决。

我们还需要区分两种复杂度。有些复杂度来自问题本身，例如财务计算的正确性、权限边界、安全风险和现实中的大量例外；这些本质复杂度需要认真理解、建模和取舍。另一些复杂度来自工具、流程和组织，例如重复录入、环境配置、无意义审批和跨系统搬运；这些偶然复杂度才应该优先被简化、消除或自动化。AI 可以大幅降低后一种复杂度，却不会替我们消灭前一种复杂度。

模型的能力也不应该通过排行榜决定。速度、成本、上下文长度和基准测试都可以提供参考，但真正可靠的方法，是拿自己的真实任务做一组小评测：准备一批有代表性的样本，先定义什么叫好，再记录模型在哪些地方失败。一次漂亮演示不等于稳定能力，一个综合排名也不能替代具体工作里的结果。选模型只是自动化工程中的一小部分，问题定义、数据质量、流程设计和失败处理通常更加重要。

正因为如此，自动化值得我们怀着热情去做，也值得我们保持耐心。第一次失败并不一定说明方向错了，它可能只是在揭示一条以前从未被写下来的规则；一次模型答错，也可能帮助我们发现原流程本来就依赖某个人的经验。动手把隐性的工作显性化，本身就是进步。自动化不是把复杂现实藏进一个黑箱，而是逼着我们更诚实地理解现实。

智能体可以执行，但不能负责#

随着模型能够完成越来越完整的任务，人们很容易把能力和责任混在一起。模型可以生成、分类、总结、规划，甚至在授权后调用工具执行动作，但责任仍然属于部署和使用它的人与组织。社会不会接受“这是 AI 自己决定的”作为最终解释，用户也不应该承担一个系统内部如何分工的后果。能力可以交出去，责任不能凭空消失。

确定性系统掌握事实、权限与动作，模型处理语言和不确定输入。

因此，每一项自动化都应该先回答几个朴素的问题：做错以后谁会发现，错误能不能修改或撤销，哪一步需要一个人明确确认，谁有权叫停系统，最终结果写谁的名字。风险低、容易检查、能够恢复的任务，可以给系统更大权限；涉及金钱、合同、医疗、安全或不可逆动作时，权限应该更谨慎。边界并不是限制想象力，而是让自动化能够真正进入现实世界。

一个实用的做法，是逐步扩大权限。最开始让系统充当助手，只整理信息，由人判断和执行；有了证据以后，再让它成为副手，生成建议或草稿，由人批准；只有当错误类型、监控方式和回退路径都足够清楚时，才让它在明确范围内自动行动。不要一开始就追求最高自治，先找到价值，再让权限随着证据增长。

从一件真实发生过的事开始#

开始自动化时，不要先说“我要做一个智能体”，也不要先列一串想使用的工具。回到最近一次真实发生的事情：每当什么事件出现，谁要花多少时间，从哪里取得信息，做出什么判断，最后完成什么动作。这个句子看起来朴素，却能把抽象愿望变成一段可以观察的工作流。如果连最近一次发生的时间都说不清楚，这个问题可能还没有具体到值得动手。

接下来，明确你需要的输出和已经拥有的输入。你需要的是一份摘要、一封回复草稿、一个排序、一个提醒，还是一个真正执行的动作？输入来自邮件、聊天、订单、图片、规则还是历史记录？其中哪些步骤只是确定性转换，哪些地方真的需要模型判断？哪一步的错误最严重，又由谁检查？当这些问题逐渐清楚，技术方案反而会变得简单。

第一个实验不需要是一套完整系统。你可以先用十个历史样本，手工把输入交给模型，再由人逐条检查结果；可以暂时不接所有系统，也不做完整界面；可以只验证输出是否有用，而不是假装已经实现全自动。一个好的实验，应该能在一周后提供足够证据，让你决定继续、调整或停止。最小实验的目标不是证明自己是对的，而是用最低成本减少一个关键的不确定性。

如果你本身就是这段流程的使用者，可以从零号用户开始。先为自己做，亲自使用，记录自己判断错了什么；再让第二个人试用，让他暴露你的个人习惯和隐藏假设；更多用户出现以后，才判断这是共性需求还是个人偏好。为自己做并不等于闭门造车，前提是你愿意承认第一版不完整，也愿意让真实使用不断纠正自己的理解。

继续去做那些困难但值得的事#

自动化不会因为有了人工智能就变成轻松的工作。你仍然要理解流程、面对例外、整理数据、设计边界、观察失败，并对结果负责。有时候你花了一周，只证明原来的设想不成立；有时候系统省下的不是几小时，而只是每天五分钟；有时候最好的结论，是某个高风险动作仍然应该由人完成。这些都不是失败，而是我们终于不再凭想象讨论问题。

我希望大家多用人工智能，因为持续使用才能形成自己的判断；也希望大家多抱怨，因为每一次“这怎么还得手动搞”都可能是一只烟感器；还要多从不同地方学习，因为自动化不仅是技术问题，它同时涉及业务、体验、沟通、安全与责任。技术同学可以向真实问题多走一步，非技术同学也可以向可验证的方案多走一步。双方覆盖的范围越宽，真实需求和可运行系统之间的距离就越短。

我们不需要等到完全懂了才开始，也不需要假装第一次就能成功。选一件最近真实发生、你已经忍了很久的事情，把它拆开，做一个小实验，观察结果，然后再向前走一步。自动化很难，但这正是它值得做的原因：容易的部分迟早会被解决，真正需要人的热情、判断和勇气的，是那些还没有现成答案，却值得被改变的事情。

过去，很多问题不是没有价值，只是不值得为它组织起一条完整的软件生产线。现在，这条边界正在移动。愿我们不要只把人工智能用来更快地完成昨天的工作，也愿我们鼓起热情，继续尝试，勇敢地把那些本不该永远由人重复承担的事情，变成明天真正可以运行的自动化。