DDD落地实战：领域驱动设计从代码分层到聚合建模的工程指南
2026/10/13 8:20:01
刚接触 AI 辅助编程那阵子，我跟大多数人一样，在 VS Code 里靠插件做辅助编辑，装了一堆补全类扩展。后来我换成了 Claude Code 加 DeepSeek 的组合，让代理工具直接在终端里帮我读项目、改代码，体验完全不一样。小函数自动补全确实方便，但真到跨文件重构、追一个复杂报错、批量补测试这种活，纯补全根本接不住。这篇文章就把这套组合的配置过程、真实用法和踩坑记录一次性讲透，不管你是写了多年代码的老手，还是刚想尝试 AI 辅助编程的新手，照着做基本都能跑起来。
1. 为什么偏偏是 Claude Code 加 DeepSeek 这个组合
1.1 我真正想解决的编辑痛点
辅助编辑这件事，说出来很虚，落到日常无非三类：改一段指定代码、顺着报错找原因、按项目风格生成新代码。这三类里最折磨人的是第一类。改一个函数，还得同步它的调用方；删一个旧接口，还得把引用它的测试用例一起更新。补全工具能给你一段候选代码，但它不会主动去搜项目里还有哪些地方引用了这个函数，哪些地方会因为你的改动而报错。
我需要的是"一个能读整个项目、能定位具体文件、能亲自动手改、改完还让我逐行 review 的协作对象"，而不是"一个猜测你下一个字符是什么的输入法"。前者解决的是任务，后者解决的只是输入。这个区别听起来不大，实际用起来是天壤之别。
1.2 Claude Code 的"代理"模式恰好对上了需求
Claude Code 默认的工作模式是代理而不是补全。你在终端里给它一句话，它会自己去读文件、搜索代码、修改多个文件，并把每一步改动显示出来。它靠的是项目上下文，而不是你光标旁边那几十个字符，所以它能理解"这个函数被三个地方调用""这个常量定义在配置文件里"这类全局信息。
这种模式用来做辅助编辑，体验差别非常明显：你不再需要把相关代码手动复制进对话框，它自己会去翻项目。我第一次让它改一个工具函数时，它顺手把项目里两个调用点也一起更新了，那一刻我基本就放弃了传统补全方案。
1.3 DeepSeek 补上了成本这一环
Claude Code 本身支持更换后端模型。我一开始用的默认模型，日常写写没问题，但一旦高频来回改动，费用就开始按天跳。后来我把后端切到 DeepSeek，成本一下子降到原来的零头，而大多数重构、排错、写测试的任务，完成质量对我来说完全够用。
这里要说明一下：并不是说 DeepSeek 在所有任务上都能等同默认模型，而是它在"代理框架负责上下文理解、模型负责单次推理"这种分工里，性价比特别贴合我这种日常开发者的使用频率。复杂到极致的架构设计我可能还是会用更强的模型，但日常辅助编辑，DeepSeek 完全撑得住。这套组合的核心逻辑，就是让代理框架解决"理解力"，让 DeepSeek 解决"单次成本"，两边各管一段。
1.4 这套组合适合谁
日常用 VS Code 写中小型项目、经常被重复性改动和琐碎排错消耗时间的开发者，最适合这套方案。比如业务系统、工具脚本、个人项目、课程作业，都属于典型的适用场景。不适合的场景我也提前说：对代码保密性有严格要求、仓库超大需要全量扫描、或者任务要求极复杂长链条推理的项目，这套组合要谨慎使用。认清适用边界，后面用起来才不会踩坑。
2. 环境准备：装好之后先别急着写代码
2.1 两个前置依赖要提前确认
Claude Code 是命令行工具，跑在 Node 环境里，所以机器上得先有 Node.js 和 npm。安装前一定要先确认版本，我见过不少装不上、启动闪退的案例，最后排查下来都是 Node 版本太老导致的。
node -v npm -v # 如果 npm 版本过旧，先升级 npm 再装其他东西 npm install -g npm@latest确认没问题后，再全局安装 Claude Code：
npm install -g @anthropic-ai/claude-code claude --version装完之后先别急着启动，接下来要处理环境变量，这一步才是最容易翻车的地方。很多人以为装好了就能用，结果卡在认证上大半天，基本都是环境变量没设对。
2.2 环境变量配置：别把两种接口格式搞混
Claude Code 默认对接的是它自己的 CLI 接口格式，而 DeepSeek 官方提供了多种兼容格式的接口地址。很多人做实验时就是栽在这里：拿着另一种兼容格式的地址填给 Claude Code，结果认证一直失败。要给 Claude Code 用，必须指向它能正确识别的兼容地址，并且环境变量要用对应的 Token 字段名去填，不能用平时习惯的那个名字。
以 Linux/macOS 为例，在~/.bashrc或~/.zshrc里加两行：
export ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic" export ANTHROPIC_AUTH_TOKEN="sk-你的密钥"Windows PowerShell 用户如果是临时试用，可以这样设置：
$env:ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic" $env:ANTHROPIC_AUTH_TOKEN="sk-你的密钥"具体接口地址建议以官方文档为准，我这边用的上面这个地址，一直比较稳定。设置完成之后，务必要重新开一个终端窗口，让环境变量生效，否则会在老窗口里折腾半天还报错。
2.3 连通性自检三步走
配置完先别急着重开 VS Code，先在一个普通终端里做三件事，确认链路是通的：
- 跑一句最简单的对话，确认认证和网络都正常：
claude -p "用一句话说明你是谁，以及当前模型配置"能正常回复说明接口通了。如果看到 401 认证错误，优先检查ANTHROPIC_AUTH_TOKEN是否填对；如果提示模型找不到，重点检查 base_url 是不是填成了另一种兼容地址。
- 确认模型名能被识别。我日常默认用的是
deepseek-chat，遇到复杂排错会切到deepseek-reasoner。启动时用--model参数指定：
claude --model deepseek-chat- 用交互模式让它读一个项目里的文件，确认文件访问没有权限障碍：
claude --model deepseek-chat --allowedTools Read进去之后输入"请读取当前目录下的 README.md"，它能正确贴出内容才算通过。这一步很多人会偷懒跳过，等到真正要在 VS Code 里干活时才发现权限没开，结果更懵。
注意：环境变量是会话级配置，如果启动前忘了 export，会话会默认回退到 Claude Code 自带的模型配置，表现就是"我明明配了 DeepSeek 为什么没生效"。遇到这种问题，先在终端里执行
echo $ANTHROPIC_BASE_URL看一眼，十有八九是空的。
3. 在 VS Code 里把辅助编辑的流程跑顺
3.1 用集成终端而不是另开窗口
既然目标是辅助 VS Code 编辑，那就别在系统终端里另外开一个窗口操作。直接按 `Ctrl + `` 呼出 VS Code 内置终端，cd 到项目根目录，再启动 claude。这么做的好处是：终端里的报错、编辑器里的文件、Claude 的对话全部在一个界面里，它每改完一个文件，右侧编辑器会立刻刷新内容，体验非常顺畅。
我习惯把集成终端放在编辑器下方，高度只留三行左右的对话空间，上面全部留给代码。这样它改代码的时候，我能实时看到它动了哪些文件、改成了什么样子，不用来回切换窗口。别小看这个布局细节，窗口切来切去非常打断心流，固定之后整个协作节奏都会顺很多。
3.2 权限模式：先只读分析，再给编辑权
Claude Code 默认会提示你授权它执行命令和修改文件，初次启动时注意看权限提示。我的建议是第一次进项目先用只读模式，让它先分析理解，不要一上来就放开所有编辑权限。你可以在交互里对工具授权只选 Read，或者用权限模式参数控制：
claude --model deepseek-chat --permission-mode default等它把分析结果说清楚之后，你再在对话里明确说"可以修改 src/ 目录下的文件"，让它按需申请权限。这样做的核心原因是防止它一上来就顺手改了配置文件、动了不该动的文件。我用这个流程跑了一阵子之后，几乎没有出现过"它自作主张改了无关文件"的情况，而很多直接放权的朋友第一周就遇到过这种事。
3.3 把"改完代码立刻被看到"变成默认体验
Claude Code 修改的是磁盘上的真实文件，不是给你一段代码让你自己粘回去。所以它每次改完，你不需要复制粘贴，编辑器会自动刷新。配合 VS Code 自带的源代码管理面板看 diff，体验就非常舒服。我常用的复核节奏是这样的：
- 先让代理改，改完立刻切到源代码管理面板；
- 逐个文件看 diff，确认没有删错逻辑、没有改坏默认值；
- 有问题的行直接在编辑器里手动修，再把修改反馈给它，让它继续下一步；
- 对拿不准的重构，先在对话里写死一句"只改这些文件，不要动测试和配置文件"。
这套节奏本质上等于把 AI 当结对程序员用：它动手，你 review，所有最终决定权都在你手里。这比让它一股脑改完再回头看要可靠得多，因为代理工具的改动是自动的，越到后面越容易越界，及时 review 才能把风险摁住。
4. 三场真实干活记录：重构、排错、写测试
4.1 场景一：给老模块做拆分重构
有一次我要把一个 600 行的服务类拆成仓储层加服务层。这类任务交给代理模型，最怕它改出行为不一致的代码。我的做法是分三步走：第一步只让它通读文件并输出拆分计划，明确禁止它写代码；第二步让它按计划动手改，并反复强调"保持对外方法签名不变、行为不变"；第三步立刻跑关联测试，验证结果。
实际跑下来，它确实能把数据库查询和 HTTP 调用拆到不同目录，保留原有接口，还会顺手补上 import 路径。但有一个细节让我印象很深：它把旧逻辑里某一个默认值悄悄改掉了，如果不是我在看 diff 时逐行核对，这个变化会一直藏在代码里。所以做拆分重构，一定要 review diff，不能因为代理说"测试通过了"就完全放心。
4.2 场景二：跟着报错日志一路追根因
有一次线上日志里抛了一个很罕见的空指针异常，报错堆栈指向的工具类代码，我一时没看懂。我的处理方式是把整个堆栈直接粘给 Claude，让它"顺着调用链找根因，不要急着改代码"。它读完之后指出的真正问题，根本不在堆栈指向的那一行，而在上游一个我传给它的参数没有做判空处理。
这个场景里最关键的一步，是先声明"只读分析，不改代码"。很多代理工具拿到报错就喜欢直接开改，结果改了一堆无关代码，问题还在。我现在的固定话术是"先定位根因，给出证据链，确认无误后再给修复方案"，这样既能避免乱改，也方便我自己验证它说的对不对。实测下来，这样追问的准确率比直接让它修要高不少。
4.3 场景三：补齐单元测试和注释
补测试和补注释这类活，价值密度不算高但非常消耗时间，让代理处理正合适。我的做法是把要补测试的函数清单发给它，要求覆盖正常、异常、边界三类情况，测试风格参考项目里已有的用例。它生成的测试大部分能跑通，但偶尔会有两个问题：一是断言写得过于宽松，等于没测；二是对异步代码的处理方式和项目现有模式不一致。
针对第一个问题，我会在指令里写明"断言必须具体到返回值，不允许只断言不报错"；针对第二个问题，我会让它先看项目里已有的两三个测试文件，模仿风格再写。有了这两条约束之后，生成的测试质量稳定了很多。补注释同理，只需要在 CLAUDE.md 里写清楚注释的格式偏好，它每次都会照着来。
4.4 从三场记录里总结出的协同套路
不管哪类任务，我最后都沉淀成了同一套节奏：先说清楚任务边界和目标，再让它做只读分析，拿到分析结果后确认计划，最后才授权修改，改完逐个 review diff。这套流程看起来繁琐，但实际每次也就多花一两分钟，换来的是改动质量和可控性的大幅提升。
尤其是用 DeepSeek 这类高性价比模型时，把任务拆小、把边界说细，产出的稳定性会明显提高。它并不是执行不了复杂任务，而是复杂任务越拆越稳，每个环节都能验证。如果一上来丢给它一个"把这个项目重构了"这种巨型任务，再强的模型也容易翻车，这和带一个新人程序员是同一个道理。
5. 这几个月踩过的坑和我现在的固定用法
5.1 高频翻车点排查表
我把这几个月遇到最多的问题整理成一张表，照着查能省不少时间：
| 现象 | 常见根因 | 解决办法 |
|---|---|---|
| 启动后提示认证失败 | Token 环境变量没设置，或设成了别的变量名 | 重新确认两个环境变量，重开终端 |
| 提示模型不存在 | base_url 填成了另一种兼容格式的地址 | 换成 Claude Code 能识别的兼容地址 |
| 对话正常但不会改文件 | 权限模式限制，或没授予文件编辑权限 | 在交互里明确授予具体目录的编辑权 |
| 改着改着"忘了"之前的约定 | 上下文过长，代理丢失了早期指令 | 把关键约定写进 CLAUDE.md，或重开会话 |
| 生成的代码风格和项目不一致 | 没给项目规范 | 在 CLAUDE.md 里写明命名、错误处理、注释规则 |
| 悄悄改了计划外的文件 | 任务边界没说清 | 每个任务都明确"只改哪些文件" |
CLAUDE.md 这个文件值得单独拎出来说。Claude Code 每次启动都会自动读取项目根目录下的 CLAUDE.md，用来记住项目约定。它相当于这个代理的"入职手册"，你可以把模块结构、代码风格、禁止改动目录都写在里面。这样每次对话它都天然遵守，不需要你一遍遍重复。我大概花了半天时间把几个常用项目的约定写好，后续协作效率提升非常明显。
5.2 我的当前配置与日常工作流
直接上配置，方便你抄作业：
# ~/.bashrc 或 ~/.zshrc export ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic" export ANTHROPIC_AUTH_TOKEN="sk-你的密钥"启动习惯：
cd /path/to/your/project claude --model deepseek-chat日常任务我用deepseek-chat，速度够快、成本低；遇到需要长链路推理的疑难杂症，我会单独开一个会话用deepseek-reasoner，跑一次拿到结论之后再回到原来的会话继续干活。任务之间记得用/clear清空上下文，避免上一个任务的记忆污染下一个任务。每完成一个任务，我会顺手把新学到的项目经验写回 CLAUDE.md，比如"这个模块的缓存策略不要动""这个目录下的配置是自动生成的"，时间长了，这套组合会越来越懂你的项目。
5.3 什么时候不要用这套组合
最后说几个劝退场景。涉及敏感数据的项目，别把代码喂给外部接口，再便宜的模型也不值得冒这个风险。超大单一仓库项目，代理每次都要扫描大量文件，这个组合跑起来会明显变慢，体验远不如把模块拆开单独用。另外，如果你的开发环境本身无法稳定访问外部 API，这套流程基本就是空转，还不如老老实实回到本地补全工具。
我个人的体会是，工具始终是工具，真正让这套组合发挥价值的不是某个模型多强，而是你作为使用者有没有把"边界清楚、先分析后动手、改完必 review"这三个习惯执行到位。把这些习惯固定下来之后，哪怕以后换别的模型、换别的代理框架，你的工作流都能平滑迁移。这也是我在折腾了几个月之后，觉得最值得分享的东西。