使用Claude Code后，感受到了AI软件时代的通货紧缩

看见未来

AI 刚火起来的时候，大家就在想象未来人类是如何操作 AI 干活的。但是如果回到现实，很多从业者并不认为 AI 真的能取代自己的工作，毕竟那时 AI 还有点儿傻，而人的经验依旧很重要。

AI 编程火起来的时候，我们也是一样的，我们一方面认可 AI 的编程能力，但依然不觉得自己的工作会被取代，毕竟它只能写一些代码片段，而一旦到了项目规模的，还是需要人工介入才能保障质量。

但是当我用上了 Claude Code，用上了 skills 后，我的想法有所改变了。编程模型的能力在不断地提升，尽管它会慢慢接近天花板，但是我们还是可以通过优化上下文管理，优化工具链，来提升 AI 编程工具整体的项目开发能力。

我似乎看到了未来我自己，不，应该是每个人，控制着不同的智能体，相互协调地完成一个复杂工作，其中就包括完成一个复杂的大规模软件项目。

被遗忘的古法

我没有系统地学习过软件工程，一切都是在工作中慢慢摸索出来的，这似乎也没什么问题，因为工作中落地的软件工程，跟当年书本上的软件工程相差甚远。当互联网成为世界上发展速度最快的领域时，一切知识都在快速过时。

我刚刚走进这个领域时，被使用了几十年的瀑布模型已经不受大家待见了，人们纷纷转向敏捷，项目周期从以年计，到以月计，再到以周计。也没人再去追求一步到位，都努力设计各种 MVP，要快，要准，很多软件工程的方法渐渐变成了传说。

我有一段时间会热衷于敏捷，热衷于领域驱动设计，还有测试驱动开发，热衷于优化规范和流程，觉得似乎找到了提升软件质量的方法。最终自然是取得一些成果，但距离我想象中的目标还是相差甚远。

我也渐渐明白，这些人们不太爱用的软件方法，不是因为大家不了解他们的好处才不用的，而是它带来的好处对每个人来说，都没那么值得付出。

那时，当然也包括现在，每天都会有无数的项目上线与关停，一个程序员在一家公司待上一两年就能算是老员工了。当项目上线时，谁也不知道它是否能活过一年，更别说五年十年了。而且就算它能存活很多年，又跟过阵子就离职的自己能有多大关系呢。

而我所热衷的那些软件方法，它们固然能提升软件质量，但它们最大的价值不在当下，而在长远，它们起到的作用是让软件可以长期的高效迭代，但同时，它们在当下的所产生的成本也非常可观。而在很多时候，眼前的成果总是比未来的更重要。

对于一个生死未卜、可能活不过一年的创业项目，花两周时间去打磨一套完美的领域模型，或者让开发人员写出比业务代码还多的测试用例，在经济账上是算不过来的。于是，我们只能选择了“先跑起来再说”，留下一地鸡毛和技术债。

AI 软件时代的通货紧缩

然而，随着 AI 编程时代的到来，这笔“经济账”正在被重构。我们惊叹 AI 的编程能力，但它更大的价值是让那些“高价值但高成本”的工程实践变得廉价且可行，这是软件行业的一场通货紧缩。

通货紧缩不是说什么东西在缩减，而是指生产要素的价格在持续下降，也就是说你的购买力在不断提升。在软件开发中，有了 AI 的助力，使得原来成本高昂的古法，边际成本趋近于零，但它们所能带来的好处却并没有什么变化。

TDD

就说测试驱动开发（TDD）吧。过去很难推广，核心阻力是“反人性”。让研发们在写业务逻辑之前先写测试代码，既繁琐又没有成就感。很多团队尝试过，最后都退化成了“补单测”甚至“不写单测”。

但有了 AI，TDD 可能就是最适合 AI 的开发模式。想象这样一个场景，你不再直接让 AI 写代码，而是先让 AI 根据需求生成测试用例，然后再让它编写代码，而最终的验收标准就是跑通所有测试。

在这个流程中，测试用例变成了验收标准，是不是大大提升了验收效率。而多出的开发测试用例的成本，不过是多说几句话而已。AI 把 TDD 从一种“道德约束”变成了“自动化工序” 。

DDD

再说领域驱动设计（DDD），我之所以喜欢 DDD，是因为我觉得它能从根本上解决鸡同鸭讲的问题，它能改善产品与研发的沟通，能改善新老员工的沟通，也能让你理解多年前的你。当所有人都能对齐认知的时候，我们的专业技术才能发挥最大的功效。

可实际执行中，统一语言很难落地，因为在执行层面上，所有人的利益都被局限在了当下，而统一语言所带来的长期优势完全比不过当下产生的成本。产研概念的不统一，文档与代码的脱节，已经成了开发过程中的常态。

而当 AI 成为软件的核心生产力时，我突然发觉 DDD 似乎就是在为这一天准备的。既然是大语言模型，那完全可以使用 DDD 来作为指导上下文管理的方法论。

反正产品与研发都是 AI 在做，统一语言变得毫无成本了，限界上下文的概念是不是可以用来指导 AI 拆分任务，作为划分子代理（subagent）的依据。

由 AI 负责维护的领域模型，可以随时对需求变更做出反应，自我迭代，继而触发代码的修改。这使得领域模型不再是沉积在文件夹中的图纸，而是成了一个活在代码库里的、与代码实时同步的知识图谱 。​

我们只要在战略设计阶段为 AI 划定好边界，指明方向，然后利用 DDD 的方法论，一个由 AI 组成的智能体团，就可以自我驱动起来。你睡觉前提出的 bug，甚至是新需求，转天早晨起床时就已经部署到了测试环境等你验收了。

当然，以上这些都是理论推演，但我相信此时此刻，在世界范围内已经有不少一线的研发团队在进行这样的尝试了，甚至你当下看到的 AI 开发流程可能就会有 DDD 的影子，毕竟这些思考不可能是我最先想到的。我相信今年在这方面一定会有一些出圈的成果的。

虽然我这里提到的是 TDD 和 DDD，但重要的不是这两个概念，而是整个软件工程发展过程中那些合理有效的流程和方法论。它们很多被淹没在历史的长河中，有的确实不再适用，但有些只是因为成本过高，不再适用于十年前的互联网开发而已。

或许 AI 可以激发起一场技术复古的潮流，好把那些仍有价值的理论，重新变造为属于 AI 时代的软件工程方法。基于这样的思考，也许我们应该提前想一想，到那时，自己应该充当一个什么样的角色。

AI 时代需要什么样的开发者

首先，一个普通的代码编写者肯定是没有生存空间了，别说 AI 时代了，就是倒退五年，这样的编码者也是可以随时撤换的战力，那时你要是技术好些或许还有些竞争力，可到了 AI 时代，除非你的编码能力是第一梯队的，不然怎么比得过 AI 呢？

普通编码者最大的问题就是受限于自己的技术视角，我也是从那个时候走过来的，我们关心的是实现产品需求，是修复 bug，是按时上线。我们甚至不知道这个产品的用户是谁，解决了用户的什么问题，我们不知道每一次技术上的取舍，对产品价值起到了什么作用。

我们把这些问题都交付给了产品，交付给了公司领导，尽管 AI 的出现也能降低这类工作的成本，但相对开发工作而言，这类决策工作需要人工的比例还是非常高的。也就是说，未来 AI 驱动的软件开发流程，更需要这样角色的人来参与。

可能你也认识一些技术转行的同事，比如技术出身的产品经理，技术出身的项目经理，技术出身的售前售后。我认识的这类人中，他们的专业能力往往要强于不懂技术的同事。AI 的到来对他们而言就是一场泼天的富贵，我相信他们会更懂得如何发挥出技术的价值。

在一个通货紧缩的 AI 软件时代，你必须有从挖掘需求到交付成品的全局视角，才能最大化发挥 AI 的开发能力。未来 AI 程序员的主要工作可能更像是项目经理，他需要协调各个角色的智能体，设计各种场景的 SOP，优化上下文管理和工作流，还得能充分发挥 AI 在人类非工作时间的利用率。

你若也想成为能够驱动 AI 开发的角色，基础的技术能力还是要有的，也得懂一些软件工程，但更重要的还是全局视角，从挖掘需求到交付成品，端到端的全过程你都要了解。你设计的 AI 工作流覆盖范围越广，使用的有效方法就能越多，降低成本的幅度就越大，而所有环节的收益就越能收拢于你的身上。 ​

总结

我以前跟团队里的小伙伴们说过，写代码是最容易的，如今最容易的这部分果然先被取代了。未来对开发者的要求是什么，可能还需要探索，但在这个通货紧缩的 AI 软件时代，你必须认识到自己的购买力已经增强了，很多好东西你已经可以很便宜地买来用了。

那些十几年前曾被我们抛弃的软件古法，在 AI 时代或许又能焕发新的生机了。技术复古或许是一种诙谐的说法，但探索软件工程中真正有价值的东西，却是需要实实在在行动的。在这个过程中，我们的身份正在经历一场深刻的蜕变，从单纯的实现者转变为规划者，从工匠进化为指挥官。

未来的开发者，本质上是在经营一家由硅基员工组成的软件公司。你的代码品味决定了 AI 的产出上限，你的架构思维决定了 AI 的协作效率，你对软件工程本质的理解决定了这套自动化产线的稳健程度。

AI 的变革不只是工具的升级，更是对我们工程师身份的一次重新定义，它截断了我们平庸的道路，推着你再往上迈出一步，让你成为真正意义上的创造者与构建者。