一
带着"Skill即流程"的发现，我重新投入了对AI学习助手的开发。这一次不一样了。我给我的AI Agent配好了开发Skill，每一个功能都按"需求→设计→开发→验证→部署"的流程走。AI不再是一个"写完代码就跑"的莽撞实习生，它变成了一个按规矩办事的工程师。我告诉它："做一个错题本功能。孩子做错的题自动收录，按知识点分类，支持重做和标记。"它先给我需求说明和验收条件，再给我设计文档——数据表怎么建、接口怎么定义、前端页面怎么布局。我确认了，它开始写代码。写完自己测，测完部署好，告诉我："你打开看看。""做一个学习计划功能。根据孩子的薄弱知识点，自动生成每周学习计划，每天推送三到五道练习题。"同样的流程。需求、设计、确认、开发、验证、部署。一周搞定。"做一个知识图谱。把初中数学的所有知识点梳理成树状结构，标记每个知识点的掌握程度。"搞定。"做一个拍照判题。孩子拍一张作业照片，AI自动批改，对的打勾，错的标红，给出错因分析。"搞定。有了vibe coding，有了skill，一个月下来，应用变成了一个功能相当完整的学习助手。React前端，Express后端，SQLite数据库，Ollama本地大模型推理，六层微服务架构。知识图谱、错题本、学习计划、拍照判题、引导式解题——该有的都有了。我把它部署在家里的一台电脑上，让孩子试用。他说："还行，比我自己刷题有意思。"20年没写过代码的前产品经理，一个人，只花了不到1个月，做出来一个功能齐全，有前端有后端，能正常跑通全流程的AI应用——整个过程，我自己一行代码也没写。AI，真的突破了想象。然后，我忽然意识到我犯了一个"错误"——我退后了一步，重新审视我做的这个东西。二
六层。从下到上：数据层、模型层、服务层、业务逻辑层、API层、展示层。标准的微服务架构。每一层职责清晰，接口规范，依赖关系明确。然后我画了一张数据流图。用户拍一张照片，数据流是这样的：用户拍照 → 前端组件接收图片 → 调用后端API →后端调用图片处理服务 → 调用AI模型接口 →AI返回识别结果 → 后端组装响应 → 返回前端 → 前端渲染展示
在整个六层架构里，在从用户操作到最终展示的完整链路里，AI只出现在一个节点上。它被"调用"了一次。就像你调用一个天气API查了一下天气。查完了，后面的事情跟它没关系了。去掉它，系统还是一个系统——只不过少了"智能判题"这一个功能。其他的——页面导航、数据存储、用户管理、学习计划的时间调度——全都跟AI无关。它们用的是最传统的if/else、CRUD、定时任务。我用最先进的AI技术，做了一个最传统架构的APP。React、Express、SQLite、微服务——这些东西在2015年就有了。我做的事情，本质上是在2015年的架构上，插了一个2026年的AI接口。这不是AI应用。这是一个传统应用，上面贴了一块AI的膏药。三
自行车还是那辆自行车。两个轮子，一个车架，一套链条传动。马达装在后轮上，踩不动的时候按一下按钮，马达帮你转两圈。快了一点。省力了一点。它不是一辆电动车。电动车不是"自行车+马达"。电动车的整个动力系统、传动结构、操控逻辑，都是围绕"电"来设计的。没有链条，没有脚踏板，油门就是电流，刹车就是断电。我做的行思远，就是那辆装了马达的自行车。AI是那个马达。按一下就转两圈。但整个系统的骨架——页面怎么跳、数据怎么存、流程怎么走——全是旧的。我想要的，不是一辆装了马达的自行车。我想要的是一辆电动车。不，比电动车更大。我想要的是一种全新的"交通工具"。四
我想了很多天。我重新审视行思远的每一个功能，问自己一个问题：如果这个功能完全由AI来驱动，它应该长什么样？现在的实现：后端有一个定时任务，每天晚上八点跑一次。它读取孩子的错题数据，按照预设的规则（每个薄弱知识点分配三道题），生成一个JSON格式的计划，存到数据库里。第二天早上，前端从数据库读取这个JSON，渲染成页面展示给孩子。AI在哪里？不在。这个功能里根本没有AI。它是一个定时任务+规则引擎+CRUD。AI Agent知道这个孩子上周刚学了二次函数，掌握度68%（记忆体里有）。AI知道他的错题本里有三道二次函数的错题还没重做（记忆体里有）。AI知道他的学习风格是"喜欢先做一道简单的找信心"（记忆体里有）。AI不需要定时任务。不需要预设规则。不需要JSON。它直接跟孩子对话："今天复习函数怎么样？你上周的二次函数还有三道错题没清，我们先从最简单的那道开始？做完了我再给你出一道同类型的变式题。"没有页面。没有路由。没有数据库查询。没有前端渲染。有的只是：AI理解意图，AI调用记忆，AI做出判断，AI输出内容。UI呢？UI退化为一个对话窗口。孩子说话，AI回答。偶尔AI需要展示一个公式或者一张思维导图，它"渲染"出来给孩子看。但这个渲染是AI决定的，不是前端代码写死的。不是用户操作UI，UI调用AI。而是用户告诉AI意图，AI决定展示什么、什么时候展示、用什么方式展示。五
这个认知一旦形成，我回头看整个软件行业，忽然觉得一切都变了。用户点一个按钮，触发一段代码，代码按照程序员预设的逻辑执行，输出一个结果。所有的"智能"都在代码里。代码是死的。你点什么它做什么。你不点，它不动。用户意图 → AI理解 → AI决策 → AI调用工具 → AI执行Skill → 输出结果
用户不需要"操作"。用户只需要"表达意图"。AI理解意图，自己决定该做什么、调什么工具、按什么流程执行、输出什么结果。旧范式里，AI处于被调用地位。新范式里，AI是驱动引擎。旧范式里，业务逻辑在代码里。新范式里，业务逻辑在Skill里。旧范式里，扩展一个功能意味着写代码、加页面、改路由。新范式里，扩展一个功能意味着写一个新的Skill。AI不是软件的插件。AI不是软件的某个功能模块。AI不是锦上添花的"智能助手"。六
那天晚上，我打开备忘录，在"Skill即流程"下面，又写了一行：然后我坐在那里，看着这两行字，忽然意识到它们之间的关系。"Skill即流程"告诉我：业务逻辑有了正确的载体。自然语言写的Skill，人能懂，机器能跑。流程数字化的问题，解决了。"AI即软件"告诉我：整个软件的架构应该围绕AI来重新设计。不是"在旧架构上加AI"，而是"AI就是架构本身"。传统应用退化为Agent的工具，UI退化为Agent的输出窗口。有了砖，没有建筑方式，你只能砌一面墙。有了建筑方式，没有砖，你只能画一张图。而这两个认知，都不是从书本里来的。一个来自一次"笨办法"——给AI立规矩。一个来自一次"退后一步"——看着自己做的东西，发现它是一头恐龙。它们都来自实践。来自失败。来自"做完了觉得不对"的那种直觉。七
有些东西，传统UI仍然更好。你用Excel做数据透视表，你需要的是拖拽和即时反馈，不是等AI理解你的意图。多人协作编辑一个文档，你需要的是明确的并发控制，不是AI帮你"协调"；你对图片的细微局部做精修，你需要的是对细节的操控，AI很难理解对细节的描绘。凡是"高频、低认知、需要精确控制"的操作，传统UI仍然有优势。但凡是"用户表达意图→系统理解→系统决策→系统执行→输出结果"这个链条涉及的软件——企业管理系统、审批流程、客户服务、数据分析、报告生成——它们都适合被AI Agent重构。我做了二十多年的企业IT。CRM、PLM、ERP、MES——这些系统，本质上都是"用户表达意图→系统执行流程→输出结果"。它们的核心不是"精确的像素控制"，而是"按规则走流程"。规则在哪里？在代码里。在if/else里。在那些没有人看得懂的ABAP和Java里。如果规则不在代码里，而在Skill里呢？如果执行者不是死板的程序，而是能理解、能判断、能灵活应对的AI Agent呢？产品经理不需要翻译了。程序员不需要写业务代码了。业务部门不需要等八周了。但我已经看到了方向。而这本书，就是我把这个方向写下来的尝试。从下一章开始，我不再讲故事了。我要把"Skill即流程"和"AI即软件"这两个认知，展开成一套完整的理论框架。它会回答：流程数字化到底是什么？Skill的结构是什么？新架构怎么设计？谁来写Skill？怎么治理？怎么从今天的存量系统走过去？理论是灰色的。但它是从那些不灰色的故事里长出来的。如果你读完了前面五章，你已经知道了这套理论是怎么来的。现在，让我们看看它到底是什么。
夜雨聆风
