Anthropic估值3800亿了，但Claude Code解决不了企业最头疼的5个问题

Anthropic 估值冲到 3800 亿美元，Claude Code 也跟着风生水起。我身边不少团队都在用，有的甚至把整个 sprint 的代码生成任务丢给它。一个朋友上周跟我说，他们组用 Claude Code 一天写了 3000 行代码，CTO 高兴得不行，觉得终于可以裁两个外包了。

结果第二周就翻车了。Claude Code 生成的代码跑起来没问题，单测也过了，但到了集成测试阶段——三个模块的数据口径完全对不上。销售模块算出来的"活跃客户"和财务模块的"活跃客户"差了 40%，排查了两天才发现，两边的"活跃"定义根本不是一回事。

CTO 的表情，你可以想象。

我不是来唱衰 AI 编程的。我自己天天用 Claude Code，效率确实提了不少。但做了十几年企业系统，我得说句实话：AI 写代码的能力在涨，但企业落地的瓶颈根本不在代码层面。今天聊聊我踩过的五个坑，以及为什么 DDD 和本体工程才是真正的解法。

先搞清楚：AI 编程到底解决了什么

AI 编程工具干的事，说白了就是帮你把"想清楚的东西"快速变成代码。需求明确、逻辑清晰的情况下，它写得又快又好。CRUD 接口、单测、重构、前端页面，这些它确实能扛。

AI 擅长的写代码 / 重构 / 单测 / 接口AI 勉强的跨系统对齐 / 业务推理AI 干不了的定义业务边界企业真正卡住的地方 → 越往右越痛代码写得好不好，往往是最不头疼的问题

图：AI 编程的能力边界 vs 企业的真实痛点

但企业系统的难点，从来不是"代码写得快不快"。是业务逻辑对不对、数据口径一不一致、跨系统能不能对上。这些事情，你让 AI 看 10 万行代码也没用，因为答案不在代码里。

5 个 AI 编程解决不了的企业难题

问题 1

业务逻辑不写在代码里，写在老员工的脑子里

"这个审批为什么要绕过部门经理？""因为 2023 年那次组织调整之后，张总说过这事归他直接管。"——这种规则没有任何文档记录，代码里也找不到，但它确实是系统的一部分。AI 能读代码、读文档，但读不了人的记忆。

问题 2

同一个概念，N 个系统 N 种定义

"活跃客户"在销售系统是 30 天内有下单，在财务系统是当月有开票，在运营系统是 7 天内有登录。每个定义在各自系统里都没错，合在一起就打架。AI 可以帮你写接口对接代码，但它不知道该信哪个定义，更不知道哪个才是"对的"。

问题 3

遗留系统的依赖关系像一团毛线球

企业系统往往经过了十年以上的缝缝补补。一个看似简单的修改，可能牵扯 5 个系统的 20 张表，还有 3 个存储过程和 1 个已经没人维护的定时任务。AI 看到的是当前代码快照，它不知道这团毛线球的历史，也理不出哪些线头能拉、哪些一拉就散。

问题 4

数据语义需要推理，不是查询

"这个客户能不能享受大客户折扣？"——这不是一个 SQL 能查出来的。你得知道客户的等级、历史合作记录、当前合同条款、行业折扣政策，还得结合"上个月刚调整过的大客户认定标准"一起判断。AI 可以写查询，但它不天然具备你们公司的业务推理能力。规则一旦变复杂，它就开始猜。

问题 5

合规审计要求每一步都可追溯

金融、政务、国企这些场景，代码不光要能跑，还得能审计。"为什么这段逻辑是这样写的""这个决策依据是什么"——AI 生成的代码能跑通，但你说不清它的决策链路。审计一查，全是黑盒。这在企业环境里是硬伤。

这五个问题有个共同点：它们不是编码问题，是知识问题。AI 缺的不是写代码的能力，是对企业业务的理解。

DDD：很多团队已经迈出了第一步

说到"统一业务概念"，做过后端架构的人应该会想到一个词——DDD（领域驱动设计）。

Eric Evans 二十年前提出来的时候，核心就一句话：让代码和业务说同一种语言。他给了几个关键工具：

• 通用语言（Ubiquitous Language）：产品、开发、测试，所有人都用同一套词汇。你说"客户"，大家都知道指的是签了合同的法律实体，不是注册用户。概念统一了，沟通成本就降了。
• 限界上下文（Bounded Context）：承认不同子系统有自己的语境。销售上下文里的"客户"和财务上下文里的"客户"可以不一样，只要边界划清楚，别串。
• 领域模型（Domain Model）：把业务规则写在模型里，而不是散落在 Service 层的 if-else。模型自己知道"订单超过 50 万要副总审批"，不用每个调用方自己判断。

我接触过不少团队，做过 DDD 实践的，上面五个问题里至少能缓解前两个。概念对齐了，开发扯皮就少了；边界划清了，系统集成的时候知道去哪找定义。

但说实话，DDD 在企业里推得并不顺。我见过太多团队，做了事件风暴、画了上下文图、写了一堆领域文档，然后……就没有然后了。文档躺在 Confluence 里半年没更新，新来的人还是得靠老员工口口相传。

DDD 的天花板：知识还是"半隐性"的

问题出在哪？DDD 的知识载体是自然语言和代码。领域文档是人写的，给人读的。代码是开发者写的，也是给人读的。这两种载体都有一个毛病：模糊、易腐、机器读不懂。

举个具体的例子。DDD 会让你写一个领域文档：

"订单金额超过 50 万的紧急订单，需经副总审批后方可进入生产排期。"

人看了没问题，能理解。但你把这段话丢给 Claude Code，让它写审批逻辑，它会怎么写？大概率写一个 if (amount > 500000 && type == "URGENT") { sendToVP(); }。看着对，但问题一堆：

• "金额"是含税还是不含税？
• "紧急"是谁标记的？销售自己标算不算？
• "50 万"是人民币还是美元？跨国订单怎么办？
• 副总的审批权限有没有额度上限？
• 如果副总 48 小时没审批，自动进排期还是升级？

这些细节，DDD 文档里大概率没写，或者写了但散在不同段落。人能脑补，AI 补不了——它要么瞎猜，要么写个 TODO 让你填。

这就是 DDD 的天花板：它把隐性知识变成了半显性知识，但还是"人读"的，不是"机器可推理"的。

本体工程：把 DDD 的领域模型"升级"成可推理的

本体（Ontology）干的事，说白了就是把 DDD 的领域模型往前推一步——从"人能读"变成"机器能推理"。

怎么推？我列个对照表，你一看就明白：

看起来很学术？我翻译成人话。

DDD 说"活跃客户 = 30天内有下单的客户"，写在文档里。本体说同一个意思，但用的是逻辑语言：ActiveCustomer ≡ Customer ⊓ ∃hasOrder.(Order ⊓ orderDate ≥ today−30d)。人看这两句话意思一样，但第二句话机器能推理——给它一条订单数据，它能自动判断这个客户算不算"活跃"，不用写代码。

更关键的是，本体能发现 DDD 发现不了的矛盾。

比如销售上下文定义"活跃客户 = 30天内有下单"，财务上下文定义"活跃客户 = 当月有开票"。DDD 会告诉你"这是两个不同的上下文，各管各的"。但本体推理器会追问：那如果一个客户 30 天内有下单但没开票，他到底算不算活跃？两个定义在语义上是否矛盾？能不能统一？——DDD 把矛盾藏起来了，本体把矛盾暴露出来了。

DDD 层（人读）通用语言文档 / 词汇表限界上下文上下文图领域模型对象 / 代码形式化升级本体层（机器可推理）形式化词汇表OWL Class + 约束本体模块Import + 映射推理逻辑模型 + 规则DL + SWRL / SHACL

图：从 DDD 到本体——同一套领域知识，从"人读"升级到"机器可推理"

说个我自己的体会。我带团队做 DDD 做了好几年，事件风暴、上下文映射、领域服务，套路都熟。但每次到系统集成阶段，还是会被概念冲突搞得焦头烂额。后来引入本体之后，最大的变化是——矛盾在建模阶段就暴露了，而不是等到集成测试才炸。

还有一个变化：以前换一个开发，得给他讲两天业务背景。现在直接把本体文件丢给他，概念之间的关系、约束条件、推理规则都在里面，他自己就能查。这比文档好使多了，因为本体是结构化的，IDE 里能跳转，推理器能验证，不会像文档一样写完就过期。

AI 编程 + DDD + 本体：三件套才齐活

回到 Claude Code 的话题。3800 亿美元的估值说明 AI 编程的能力上限很高，但在企业场景里，光有 AI 编程不够，你得给它喂"对的知识"。

我的建议是三件套配合用：

1. DDD 做业务梳理：事件风暴把业务流程理清楚，限界上下文把边界划好，通用语言让团队对齐。这一步解决"人对人的沟通"问题。
2. 本体做知识形式化：把 DDD 的产出升级成机器可推理的本体模型。概念定义、关系约束、业务规则全部形式化。这一步解决"人对机器的沟通"问题。
3. AI 编程做实现：让 Claude Code 在本体的约束下生成代码。它知道每个概念的准确定义、知道规则的完整条件链，就不会再写出"能跑但语义不对"的代码。

DDD业务梳理人对人沟通本体工程知识形式化人对机器沟通AI 编程代码实现机器干活缺 DDD → 业务对不齐　缺本体 → AI 猜业务　缺 AI → 手写太慢

图：企业 AI 编程的三件套——DDD + 本体 + AI 编程

一个我亲历的反面教材

去年有个做供应链的团队找过来。他们 DDD 做得不错——事件风暴画了三天墙，上下文图也理清了，领域服务拆得挺干净。然后信心满满地用 Claude Code 重构了订单模块，代码确实漂亮，比原来缩短了 60%。

但上线后客户投诉激增——因为 AI 不知道"紧急订单"在他们公司有个隐藏规则：金额超过 50 万的紧急订单必须走副总审批，不能直接进生产排期。

这条规则写在三年前一份会议纪要里，从没进过 DDD 文档，更没进过本体。老员工知道，新来的产品经理不知道，Claude Code 更不知道。

后来我们做的事：先补 DDD——把这些隐性规则从老员工脑子里挖出来，写进领域文档。然后再往前推一步，把文档里的规则形式化进本体。最后让 Claude Code 在本体的约束下重新生成代码。效果是——代码量没减少多少，但返工率降了 70%。

DDD 让人理解了业务，本体让机器理解了业务，AI 编程让机器快速实现业务。三者缺一，就会翻车。

给企业落地的三条建议

1. 没做过 DDD 的，先补 DDD

别跳步。如果你团队连通用语言都没对齐，上下文边界都是糊涂账，直接上本体工程会死得很惨——你连要形式化什么都不知道。先做事件风暴，先把核心概念写下来，先把上下文图画出来。这一步做扎实了，后面的本体工程才有料可喂。

2. 做过 DDD 的，把高频歧义概念升级成本体

不用全公司搞本体工程。找到那 5-10 个"每个上下文定义都不一样"的核心概念——客户、订单、产品、合同——把 DDD 文档里的自然语言定义，转成形式化的本体定义。加约束、加关系、加规则。这一步做完，跨上下文的概念冲突就能自动检测出来，不用等到集成测试再吵。

3. 让 AI 编程工具读本体，而不是读文档

这一步最关键。你把本体文件放到项目里，让 Claude Code 在生成代码之前先读本体。它会知道"活跃客户"的准确定义是什么、"紧急订单审批"的完整条件链是什么。这不是 prompt engineering 能解决的——你得给它结构化的、可推理的知识输入，而不是一堆 Markdown 文档。

写在最后

Anthropic 值 3800 亿美元这个事，说明市场认可 AI 编程的价值。但企业要落地，光有写代码的工具远远不够。DDD 解决人对人的沟通，本体解决人对机器的沟通，AI 编程解决机器干活的效率。三件套配齐了，企业 AI 编程才算真正跑通。

AI 编程的天花板，不在模型有多强，在你企业的知识结构有多清晰。

你们团队做过 DDD 吗？推到哪一步了？是停在文档阶段，还是真的落到了代码里？有没有想过把领域模型再往前推一步？评论区聊聊，我挑几个有意思的案例下期专门拆。