夜雨聆风敏捷开发中由人工智能驱动的范式转变已经到来。过去那种依赖足够好的敏捷实践就能稳定换来收入或发展前景的阶段，正在快速结束。你是准备主动适应，还是被动落后，这件事已经不太像一道选择题了。
范式转变已经发生。特斯拉 AI 前总监、OpenAI 联合创始人 Andrej Karpathy 最近坦言，自己从未像现在这样强烈地感到落后。如果连他这样的人都感到压力扑面而来，我们普通从业者更没有理由把这波变化当成远处的新闻。
接下来从战略、产品和个人三个层面来看这场变化。每个层面需要的应对方式都不一样，而过去那种足够好就行的敏捷能力，已经越来越难支撑持续的收入和职业前景。真正的问题不是变没变，而是你现在已经走到了哪一步。
作为程序员，从未感觉自己如此落后。随着程序员亲手完成的部分越来越少，整个行业都在被重新拆开再组装。如果能把过去一年涌现出来的资源真正整合起来，个人能力可能提升一个数量级；而做不到这件事，本身就会变成新的能力短板。
说这话的人，并不是刚被 JavaScript 框架折腾晕的新手，而是站在 AI 一线的从业者。连他都公开承认跟不上，这个信号就值得每一个敏捷实践者停下来认真看一眼。
在继续讨论工具、数据中心、电力基础设施和投资回报之前，更重要的是先消化一个事实：敏捷开发不会再回到以前的样子。罗伊·阿马拉定律在这里依然成立，人们总会高估一项技术的短期影响，却低估它的长期影响。放到今天的语境里，这句话几乎像一条提醒：眼前也许还没完全重排座次，但规则已经变了。
过去那种仅靠主持回顾会、整理共识、包装流程就能获得不错回报的时代，正在退潮。真正被重新定义的，不只是某个岗位的工作内容，而是价值是如何被创造、验证和放大的。从这个角度看，我更愿意把这场变化拆成三个层面来理解，因为它们分别指向三类完全不同的问题。
在战略层面，最关键的问题不是该不该上 AI，而是组织准备在什么地方、用什么方式、为了什么目标使用 AI。如果一家采用产品运营模式的敏捷组织，本来就是围绕客户价值来运转，那么 AI 的引入也不该是一次孤立的技术采购，而应该是一次价值创造方式的重构。
和大多数变革举措一样，真正的难点并不在理解概念，而在处理情绪。组织要面对的，从来不只是工具能不能接上去，而是人愿不愿意相信这次变化和自己有关，愿不愿意重新定义自己的工作边界，愿不愿意接受旧优势正在失效。很多时候，AI 转型首先是人的问题，其次才是工具的问题。
如果从这个角度看，敏捷环境下的 AI 应用和过去熟悉的转型工作其实很像。文化、治理、协作方式、授权边界，这些老问题一个都不会自动消失。你甚至会看到非常熟悉的失败路径：管理层把 AI 试点当成一块漂亮的绿地，单独划出来做实验，却没有把它和真实客户价值、组织文化约束、治理要求连起来。最后试点看起来热闹，推广却推进不动。
这类失败模式并不新鲜。曾经很多敏捷转型也是这么失手的，流程照着抄了，真正让流程发挥作用的前提条件却没有动。如今到了 AI 转型阶段，同样的坑只是换了一个更时髦的名字。工具升级了，组织惯性却还在原地。
到了产品层面，变化会更直接，也更扎心。过去我们在思考做什么产品、投什么方向时，编码成本一直是非常现实的约束条件。很多想法不是不想做，而是算不过来。可一旦代码越来越便宜，真正昂贵的就不再是实现，而是判断。
这会把产品开发的重心整体往前推。以前编码成本像一道门槛，会逼着团队对需求做筛选，对想法做取舍，对开发节奏做克制。可当实现成本快速下降之后，真正稀缺的能力就变成了另一件事：你是否足够快地发现值得解决的问题，并验证它确实值得解决。
于是，产品探索的重要性会进一步抬高，而且探索本身的形式也会改变。两年前，一张纸面原型可能还够用；现在，很多场景已经更期待一个能跑起来、能承载讨论、能暴露问题的原型。克里斯蒂娜·沃德克把这件事称为探索式编码，本质上就是为了学习而构建，而不是为了交付而构建。说白了，先把东西做出来看看，很多时候比围着白板争论两周更接近现实。
这也会把产品经理和产品负责人的职责往前再推一步。他们未必需要写生产代码，但很可能必须具备和编程相关的操作能力，至少要能更快地拉起原型、验证假设、比较方案。否则，明明大家都拿到了更强的杠杆，只有自己还在靠嘴描述产品，那就容易在节奏上输掉先手。
更有意思的是，AI 带来的机会并不只是在传统 SaaS 上做增量优化，它还在把我们推向一个更细颗粒度的阶段，也就是个性化软件。过去很多需求因为太小众、不够标准化、开发成本不划算，所以只能委屈在通用工具里凑合。现在情况开始变了，一款完美贴合具体场景的软件，第一次变得现实。
比如你完全可以设想这样一条工作流：从 Slack、邮件、客户支持系统、会议记录、用户访谈里提取反馈，把它们整理成 Markdown，再放进你的上下文系统中，最后在每天 8 点前自动生成一份晨间更新，告诉你客户情绪和利益相关者反馈是否在发生变化，并给出后续行动建议。这样的工作流足够具体，也足够个性化，以至于市场上几乎不会有完全一致的现成产品。到那时，当别人问你在用什么工具，也许最有竞争力的回答真会变成一句：这是我自己做的。
如果把镜头拉回到个人层面，敏捷实践者接触 AI 的路径，其实已经出现了一条相当稳定的演进曲线。
最开始，你会把 AI 当成一个响应很快的助手，给它提问，让它帮你解决某个具体问题。接着你会发现，它不只是能回答问题，还能在一定边界内自我引导。当你开始理解记忆、上下文、项目配置这些概念后，就会慢慢意识到，创建 GPT、项目或 Gems，并不是花哨动作，而是在提升工作质量和产出数量。
很多人会停在这里，把 AI 当成一个更聪明的搜索引擎。但真正往前走的人，会开始理解上下文管理的重要性。你会整理文件、拆分信息、引入连接器，让模型拿到更结构化的背景材料。这个阶段最容易踩的坑也很典型：把一堆文件毫无组织地塞进去，直到触发上下文限制，然后抱怨模型忘性太大。问题通常不在模型，而在信息组织方式本身。
再往下一步，你会发现另一个真正有杠杆的能力，也就是技能。这时，你不再只是一次次手动指挥模型执行具体动作，而是在搭建一个系统，让它能根据任务场景自主调用说明、知识和流程来完成工作。当然，这里也有新的风险，比如技能蔓延。技能如果彼此重叠、互相冲突，看上去像能力增强，实际上只会把系统搞得一团乱麻。
继续往前，就是AI 代理的自主运行。Claude Code 在 Claude Opus 发布之后迅速升温，并不是偶然。与此同时，越来越多人开始接受 Markdown 文档，把知识放进像 Obsidian 这样的互联文件系统里，也不是偶然。因为一旦这些能力接起来，你第一次有机会搭建出一个真正贴合自己工作方式的个性化操作系统，连那些过去更偏向 CLI 用户的能力，也开始变得对普通人可用。
从这个意义上说，Claude Cowork 这样的产品之所以值得关注，并不是因为它又多了一个新名字，而是因为它让更多敏捷实践者第一次具体感受到自主 AI 代理究竟意味着什么。这不是把原来工作流换个皮，而是把工作方式整体推进到一个新阶段。
这场范式转变至少发生在三个层面，而且每一层都不能只靠惯性应对。
• 战略层面：要把人工智能的采用理解为文化挑战，而不是一次工具推广。 • 产品层面：要接受代码变便宜之后，真正更重要的是发现问题、验证问题和判断价值。 • 个人层面：要从偶尔提示模型，走向能够编排技能、整合上下文并驱动代理行动。
还要特别警惕一点：如果个人层面的成长没有和组织战略形成协同，最终就会演变成能力孤岛。个体越来越强，组织却接不住，这种落差一旦被高能力者看清楚，挫败感就会迅速转化为流失风险。放到 AI 人才竞争里，这几乎就是最贵的一类战略失误。
我接触到的大多数从业者，其实都还处在个人旅程的中段。他们已经会用 ChatGPT 或 Claude 解决具体任务，但还没有把自己的工作流程真正沉淀进技能、系统或代理里。这很正常，谁都不是一上来就全套配齐。
但变化不会因为大家都没准备好就暂停。偶尔提示一下和真正拥有 AI 代理之间的差距，正在越拉越大。能跨过去的人，会逐步获得新优势；跨不过去的人，会发现自己的价值被一点点压缩。说到底，眼下最重要的问题不是 AI 会不会改变敏捷开发，而是你准备怎么参与这场改变。
FunTester 原创精华
