夜雨聆风
摘要：2020年，我写过一篇旧文 《互联网软件还有机会吗？》，讨论QQ、微信、邮件为什么替代不了OA。当时我说，软件是把业务数据结构化、传递、处理和跟踪的系统。五年半后再看，这句话其实已经摸到了AI时代的核心：软件不是界面，不是表单，而是给人和AI共同使用的上下文窗口。
故事的开始：翻到旧文的那个晚上
周日晚上十点多，我看了一眼天气，深圳福田多云，28度。窗外没有戏剧性的雨声，楼下路灯刚刚熄灯。
我本来只是想整理一下旧文章，把以前公众号里一些能用的素材翻出来。结果翻着翻着，看到了一篇2020年11月21日发的旧文，标题叫《互联网软件还有机会吗？》。
严格算起来，那不是整整六年前，是五年半多一点。但从2020年到2026年，中间隔了一个AI时代。这个跨度，体感上比六年还长。
第一段读完，我人就被拽回去了。
当时我写的是，前一天和一个哥们聊天，聊到"怎么样通过一套OA系统来提高沟通效率"。他的观点很直接：QQ、微信、邮件不也能沟通吗？为什么一定要上钉钉、OA、系统？
这个问题现在看特别有意思。
2020年的争论是："聊天工具能不能替代业务系统？"
2026年的争论变成了："AI聊天框能不能替代业务系统？"
换了个壳，问题没变。
我继续往下看。当时我给"软件"下了一个很土、但现在看还挺准的定义：根据特定的业务需要，把业务数据信息化，并进行传递和处理的系统。
那篇文章里还举了个很生活化的例子。原文写得也不严谨，叫"明天下午10点，去A小区302栋做厨房保洁服务"。
如果这句话出现在微信里，它就是一段文本。相关人员要自己读，自己记，自己判断时间、地点、服务内容。要是有人甩一段语音，体验更糟。你得点开听，听完还得再转述。
但如果它进入一套业务系统，事情就不一样了。
时间会变成字段，地点会变成字段，服务项目会变成字段，负责人会变成字段。系统可以提醒，可以改派，可以提前确认，可以在服务前一小时发现风险。
我看到这里，突然愣了一下。
这不就是我这几个月一直在写的"上下文"吗？
只不过，2020年的我还没有今天这套AI语境。当时我把它叫"信息化"、"结构化"、"流程跟踪"。现在换个说法，它其实就是在给组织构造一个可执行的上下文窗口。
老实说，看到这里我有点复杂。
一方面觉得，自己当年写得挺粗糙，错别字都有，"OCR"还被我打成了"orc实图"。另一方面又觉得，有些直觉还真没变。六年前我以为自己在写"软件还有没有机会"，现在回头看，那篇文章真正问的是：
一个组织，怎样把口头信息变成可以被系统、被人、被AI共同处理的上下文？
犀利的观点：软件没有过时，它变成了上下文
这几年有一个说法很流行：AI会吃掉软件。
这句话听起来很刺激，但我现在越来越觉得，它只说对了一半。
AI确实会吃掉一大批低价值的软件界面。很多表单、很多查询页、很多机械报表，未来可能都不需要用户一格一格填写、一页一页点击了。你说一句话，AI就能帮你抽取字段、调用接口、生成结果。
但这不等于软件消失了。
软件真正的价值，从来不是"让用户点按钮"，而是把业务状态变成可传递、可校验、可追踪、可复用的上下文。
以前这个上下文长得像表单，像OA流程，像项目管理里的任务卡片。
现在它可能长得像一段Prompt，像一个Agent能读取的知识库，像一份结构化输出的JSON Schema，像一个MCP连接起来的业务工具。
界面会变，底层逻辑没变。
这也是为什么我不太相信"一个超级聊天框替代所有企业软件"这种说法。聊天框能让输入变自然，但它解决不了所有问题。它可以帮你把"明天下午去A小区做厨房保洁"拆成字段，但拆完以后呢？
谁负责？
什么时候提醒？
服务人员来不了怎么办？
客户临时改时间，原来的排班怎么调整？
什么状态算完成？
什么情况必须人工介入？
这些问题不是"能不能理解自然语言"的问题，而是业务系统的问题，是流程的问题，也是判断标准的问题。
说白了，AI聊天框像一个特别聪明的前台。你说什么，它都听得懂。但公司真正能不能运转，靠的不是前台聪不聪明，而是后面有没有排班表、工单系统、异常处理规则和责任人。
如果后面什么都没有，那前台越聪明，越容易把事情接得满满当当，最后全堵在后厨。
这也和我最近写的几篇文章接上了。
去年十月我写"首席上下文官"，说管理者的工作不是分配任务，而是设计上下文窗口。四月写"基建存款"，说AI落地的速度取决于过去有没有沉淀标准化模板、流程SOP和数据治理。后来写"AI流水线幻觉"，说工具换了，流程没换，AI放大的不是效率，是混乱。再到五月写"判断力"，我又补了一句：上下文是输入，判断标准才是筛选器。
现在看，2020年那篇旧文像一个很早的草稿。
当时我还没有这些词。但我已经隐约意识到：聊天不是流程，文本不是状态，信息看见了不等于业务被处理了。
事实的演进：从"表单"到"上下文窗口"的软件进化史
回头看，企业软件这二十多年，其实一直在做同一件事：把人的口头协作，慢慢变成机器可处理的上下文。
第一阶段：表单时代 (约2000年 - 2015年)
这个阶段的软件很朴素。
你要报销，就填报销单。你要请假，就填请假单。你要派工，就填派工单。姓名、电话、地址、时间、金额、审批人，一个字段一个字段填。
很多人讨厌表单，觉得它笨、慢、反人类。
我现在也讨厌。
但站在系统角度看，表单有它的历史价值。它把一句模糊的话拆成了机器能处理的字段。只有拆成字段，系统才能校验，才能流转，才能提醒，才能统计。
2020年那篇文章里，我之所以说自然语言解析还不够准，所以还得靠人把姓名、电话、地址这些东西填进表单，本质上说的就是这个问题。
不是表单高级，而是当时没有更好的结构化入口。
第二阶段：流程时代 (约2015年 - 2023年)
后来，大家不满足于"收集字段"了，开始关心流程。
一个需求从提出到评审到开发到测试到上线，一个客户从线索到报价到签约到交付到回访，一个问题从反馈到定位到修复到复盘，都不只是几个字段，而是一串状态变化。
这个阶段，飞书、钉钉、云效、Jira、Tapd这类工具开始变得重要。它们真正解决的不是"记录信息"，而是"让信息沿着流程走"。
谁卡住了，系统知道。哪个节点超时了，系统知道。哪个需求改了三版还没评审，系统也知道。
我以前总觉得这叫流程管理。现在换一个AI时代的说法，它叫上下文流转。
因为每一个节点都在给下一个节点准备上下文。产品给开发准备上下文，开发给测试准备上下文，测试给运维准备上下文，运维再把线上反馈变成下一轮迭代的上下文。
第三阶段：上下文时代 (2024年至今，AI加速)
AI来了以后，变化变得很明显。
表单不一定要用户填了，AI可以从自然语言里抽取字段。文档不一定要人从零写了，AI可以根据已有模板生成初稿。评审也不一定只能靠人肉看，AI可以先站在不同角色挑一轮毛病。
但这没有让结构化失效，反而让结构化变得更重要。
OpenAI的Structured Outputs，本质上就是让模型输出严格匹配Schema。Anthropic后来写context engineering，说构建Agent越来越不是写一句漂亮Prompt，而是决定哪些信息该进入有限的上下文窗口。MCP要解决的，也是AI怎么安全连接到真实的数据、工具和业务系统。
这些新词看起来很前沿，其实底层味道很熟悉。
2020年我们说："自然语言要解析成时间、地点、服务项目。"
2026年我们说："模型输出要匹配Schema，Agent要拿到正确上下文，工具要有清晰边界。"
说法变高级了，问题还是那个问题：把人的话，变成系统能执行的结构。
只不过现在多了一个新变量。以前结构化主要是给软件用，现在结构化还要给AI用。
而AI比传统软件更敏感。
传统软件拿不到字段，最多报错。AI拿到一堆乱七八糟的上下文，可能不会报错，它会一本正经地胡说八道。这个更危险。因为你看着它说得很顺，就以为它懂了。
它可能只是很会接话。
结论：别把上下文继续丢在聊天框里
看完那篇旧文，我把标题复制到笔记里，下面写了一句话：
表单可能会消失，但结构化不会消失。
又想了想，我把这句话改成了另一句：
界面会消失，上下文不会消失。
这才是我真正想表达的。
如果接下来我要做一件事，不是再去争论"AI会不会替代软件"，而是重新看一遍我们手上的业务流程：哪些信息还躺在微信群里？哪些判断还藏在老师傅脑子里？哪些异常处理还靠某个人"想起来"？哪些文档只是给人看的，AI根本读不懂？
这些东西，就是AI时代真正的基建存款。
我甚至想给团队列一个很土的清单：
哪些聊天记录应该变成任务状态？ 哪些会议纪要应该变成判断标准？ 哪些历史案例应该变成可检索的知识索引？ 哪些表单字段可以交给AI抽取，但必须保留系统校验？
听起来不酷。
但大多数真正有用的事，开始的时候都不酷。2020年写那篇旧文时，我最后用了句有点中二的话："留给我们的时间不多了。"
现在再看，这句话倒也没错。
只是当年我以为，机会在垂直领域软件。现在我会补一句：机会仍然在垂直领域，只不过不再只是做一套SaaS，而是把这个领域的流程、知识、异常、责任和判断标准，整理成AI能用、人也能复盘的上下文系统。
正如《礼记·大学》所言："物有本末，事有终始，知所先后，则近道矣。"
软件的"末"，可能是表单、按钮、页面、聊天框。
软件的"本"，是上下文。
AI来了以后，末会变得很快。本反而更清楚了。
我是 哇塞君。
我相信所有复杂的管理问题，背后都有一个更优的解。如果你也在自己的"铁匠铺"里面对着"天外陨铁"发愁，或许我们可以聊聊彼此锻造"匕首"的故事。
参考资料 (References & Further Reading)
- [1]
Anthropic. (2025). Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents （上下文工程：从Prompt到上下文状态管理） - [2]
OpenAI. (2024). Introducing Structured Outputs in the API. https://openai.com/index/introducing-structured-outputs-in-the-api/ （结构化输出与Schema约束） - [3]
Anthropic. (2024). Introducing the Model Context Protocol. https://www.anthropic.com/research/model-context-protocol （AI系统连接数据源、工具和业务系统的开放协议） - [4]
McKinsey & Company. (2025). The State of AI: Global Survey 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai （AI Agent、业务流程改造和数据基础设施） - [5]
《礼记·大学》. (先秦). "物有本末，事有终始，知所先后，则近道矣。" - [6]
哇塞君. 《互联网软件还有机会吗？》. （2020年旧文，关于软件本质、业务信息化和垂直领域机会） - [7]
哇塞君. 别再只管理"人"了，AI时代下管理者的核心是"上下文". （首席上下文官） - [8]
哇塞君. "基建存款"：为什么同样的AI工具，隔壁用得飞起，你们用得翻车. （结构化模板、流程SOP和数据治理是AI落地本金） - [9]
哇塞君. "AI流水线"的幻觉：工具换了，流程没换. （AI放大的是现有工作方式） - [10]
哇塞君. 管理者的最后阵地：AI时代的判断力. （上下文之后还需要判断标准）
