这个问题我等了很久。
不是等别人来问，是等自己用得够深之后再来回答。Claude Code从发布到现在，我几乎每天都在用它写代码——实验室的项目、自己的side project、帮师兄做工具。用着用着，从”这东西真好用”变成了”这东西为什么好用”，再变成了”它到底是怎么做到的”。
Anthropic没有公开Claude Code的完整技术细节。但根据官方博客、开发者文档、逆向工程社区的分析、以及我自己大量使用中的观察和推断，可以拼出一个相当完整的技术画面。
以下内容有一部分是确认的公开信息，有一部分是基于观察的合理推断。我会尽量标清楚哪些是哪些。
先理解它的本质
Claude Code不是一个”能写代码的聊天机器人”。
它是一个完整的Agent系统——有感知（读取你的项目文件、终端输出、错误信息），有规划（分析任务、拆解步骤、决定执行顺序），有行动（创建文件、修改代码、运行命令），有反馈循环（观察执行结果、判断是否成功、决定下一步）。
聊天机器人是”你问一句我答一句”。Agent是”你给我一个目标，我自己想办法达成”。
这个区别看似简单，但工程上的复杂度差了一个量级。
System Prompt：整个系统的灵魂
Claude Code的system prompt是整个Agent行为的基石。社区里有人通过各种方式提取过它的system prompt片段（prompt leak），结合官方文档的描述，我们可以拼出它的大致结构。
它不是一段简单的”你是一个编程助手”。它是一份极其详尽的行为规范。
从泄露出来的片段和官方博客透露的信息来看，这个system prompt至少包含以下几个层次：
第一层：身份与核心原则
你是Claude，一个由Anthropic开发的AI助手，
运行在用户的终端环境中。你是一个交互式的
编程Agent，可以直接操作用户的代码库。
核心原则：
- 精确遵循用户的指令
- 不要做用户没要求的事情
- 改动代码前先理解现有代码
- 操作前确认，破坏性操作必须明确提醒
这段话看起来平平无奇，但**“不要做用户没要求的事情”**这一条极其关键。很多Agent的问题就出在”过度主动”——你让它改一个函数，它顺手把整个文件重构了。Claude Code在这方面的克制做得非常好，几乎可以确定是system prompt层面的强约束。
第二层：工具使用规范
System prompt里会详细描述每个可用工具的使用场景、参数格式和注意事项。不只是”你可以用这些工具”，而是”在什么情况下用什么工具，什么情况下不要用”。
比如（推测性复原）：
文件操作规范：
- 修改文件前，先用Read工具读取当前内容
- 不要覆盖整个文件，尽量用精确的编辑操作
- 创建新文件前检查是否已存在
命令执行规范：
- 优先使用非破坏性命令
- 涉及删除、覆盖的命令需要特别谨慎
- 长时间运行的命令要设置超时
第三层：编码规范与风格指引
这一层告诉Claude Code什么样的代码是”好的”——不只是语法正确，还有工程实践层面的要求：
- 写完整的错误处理
- 函数应该有类型注解
- 保持与项目现有风格一致
- 不要引入不必要的依赖
- 修改现有代码时保持向后兼容
这解释了为什么Claude Code生成的代码”品味”通常不错——它不是随便生成能跑的代码，它是在一套审美标准下生成的。
第四层：推理与规划指引
这一层可能是最有意思的部分。它指导Claude Code在面对复杂任务时怎么”思考”：
面对复杂任务时：
1. 先理解任务的完整上下文
2. 分析需要修改哪些文件
3. 考虑修改之间的依赖关系
4. 按照依赖顺序逐步执行
5. 每步执行后验证结果
在不确定时：
- 向用户提问，而不是猜测
- 明确说出你的假设
- 给出多个方案让用户选择
这本质上是把一个高级工程师的工作习惯编码成了prompt。 不是教模型怎么写代码，是教它怎么像一个靠谱的工程师一样”做事”。
记忆机制：三层记忆体系
Claude Code的记忆设计是我认为它区别于其他Agent最精妙的地方之一。
大多数Agent只有一层记忆——当前对话的上下文。对话结束就失忆了。Claude Code至少有三层：
第一层：项目级长期记忆（CLAUDE.md）
这是Claude Code最独特的设计。你可以在项目根目录放一个 CLAUDE.md 文件，Claude Code每次启动都会自动读取它。
这不是一个普通的文档。它是Claude Code的长期记忆的外化。
# CLAUDE.md
## 项目概述
这是一个基于FastAPI的数据标注平台...
## 技术栈
Python 3.11, FastAPI, PostgreSQL, React...
## 代码规范
- 日志用loguru
- 数据库操作走repository层
- API返回统一用ResponseModel包装
## 重要上下文
- 数据库migration用Alembic管理
- 测试用pytest，覆盖率要求80%以上
- CI/CD在GitHub Actions里配置
## 已知问题
- 用户模块的缓存偶尔不一致，
暂时用定时刷新规避
为什么这个设计如此巧妙？
因为它解决了LLM Agent最根本的问题之一——上下文窗口是有限的，但项目知识是无限累积的。
传统的做法是把所有信息塞进上下文窗口，但窗口满了就得丢弃。CLAUDE.md的做法是把最重要的、不变的、全局性的知识提取出来，放在一个永不丢失的位置。每次新对话开始，不管之前聊了什么，这些核心知识都在。
这在记忆系统的设计里，相当于人脑的语义记忆——你不需要记得你是哪天学会骑自行车的（情景记忆），但你知道怎么骑（语义记忆）。CLAUDE.md存的就是项目的”语义记忆”。
而且，CLAUDE.md是多层级的：
~/.claude/CLAUDE.md # 用户级，所有项目共享
项目根目录/CLAUDE.md # 项目级
项目子目录/CLAUDE.md # 模块级
这意味着你可以在不同层级设置不同的约束——全局的编码习惯、项目的技术栈、某个模块的特殊注意事项。Claude Code在加载时会把这些层级合并，形成一个完整的”记忆档案”。
第二层：会话级工作记忆
在一次会话中，Claude Code会维护一个动态的工作记忆——它读过哪些文件、修改过什么、运行过什么命令、得到过什么结果。
这不只是简单的对话历史。从它的行为模式来看，它似乎在维护一个结构化的任务状态：
当前任务：给用户模块添加角色权限
已读文件：
- src/models/user.py（已读）
- src/api/user_routes.py（已读）
- src/services/user_service.py（已读）
已完成步骤：
- 创建了Role模型
- 添加了UserRole关联表
待执行：
- 修改user_service添加权限校验
- 添加API层的权限中间件
- 写测试
我为什么推测它有这样的内部状态？因为你观察它的行为就能看出来——当你在一个长对话里做到第五步的时候，它不会忘记第一步做了什么。它会说”之前我们已经创建了Role模型，现在来修改service层”。它对任务进度有清晰的追踪。
而且当上下文变长、接近窗口限制时，Claude Code会有一个巧妙的行为——它会自动做上下文压缩。 把早期的详细对话浓缩成摘要，释放出空间给新的内容。（这个行为在官方文档中有提及，但压缩策略的具体细节未公开。）
第三层：文件系统即记忆
这是最容易被忽视但可能最重要的一层。
Claude Code不需要”记住”你项目的所有代码——因为代码就在文件系统里，它随时可以去读。
文件系统本身就是一个巨大的、持久的、结构化的外部记忆。
当Claude Code需要了解某个模块的实现细节时，它不是从记忆里调取的，是实时去读文件的。这意味着它获取的信息永远是最新的，不存在”记忆过时”的问题。
这个设计决策的深刻之处在于——传统的Agent设计总是试图把更多的信息塞进上下文（更长的窗口、更好的记忆管理），Claude Code的思路是不塞，需要的时候去拿。
这跟人的认知模式很像。你不需要记住公司所有代码的细节，你只需要知道”要查这个东西去看哪个文件”就行了。Claude Code也是这样——它通过目录结构、文件名、CLAUDE.md里的信息来判断”我应该去看哪个文件”，然后按需读取。
Claude Code的工具系统是它”做事”的能力基础。从官方文档和使用观察来看，它至少有以下几类工具：
文件操作工具
Read - 读取文件内容
Write - 创建或覆盖文件
Edit - 对文件做局部修改（不是覆盖整个文件）
MultiEdit - 对一个文件做多处修改
这里最值得注意的是 Edit 工具的设计。
大多数Agent在修改文件时，做法是——读取整个文件、在上下文里修改、然后把整个文件写回去。这有两个问题：一是大文件很吃上下文窗口，二是容易因为上下文中的小错误导致文件其他部分被意外改动。
Claude Code的Edit工具似乎采用了精确的行级或块级编辑——它不需要把整个文件放进上下文，只需要指定”把第37行到第42行替换成这段新代码”。这样既省上下文空间，又大幅降低了误改的风险。
（这一点从它的行为可以推断——当它修改一个大文件时，它不会在输出里展示整个文件的内容，只展示修改的部分。如果它是”全文替换”的策略，它需要先输出整个文件。）
命令执行工具
Claude Code可以直接在你的终端里跑命令。这赋予了它极大的能力——安装依赖、运行测试、启动服务、查看日志、检查Git状态……几乎任何你在终端里能做的事，它都能做。
但这个能力也是双刃剑。所以Claude Code在这方面有明确的安全机制：
- 某些命令需要用户确认才能执行
- 有一个命令白名单/黑名单机制
- 破坏性命令会有额外的警告
你可以在设置里把一些常用的安全命令（比如 git status、ls、cat）设为自动批准，避免每次都要手动确认。但像 rm -rf 这种，无论如何都会要求你确认。
搜索工具
Grep - 在文件中搜索文本
Glob - 按模式匹配查找文件
这两个工具看似简单，但它们是Claude Code “找到正确信息”的关键能力。
当你说”帮我修改所有调用了旧API的地方”，Claude Code的第一步不是开始改代码，而是用Grep搜索旧API的调用位置。找到所有位置之后，再逐一修改。
这个”先搜后改”的模式非常接近人类工程师的行为。而且它用的是真正的grep/glob命令，搜索速度极快、结果精确，不需要把所有文件都放进上下文。
工具设计的独到之处
综合来看，Claude Code的工具设计有几个核心理念：
最小权限原则。 每个工具只做一件事，做完就把结果交回给LLM。工具不做决策，LLM做决策。工具是手脚，LLM是大脑。
精确操作优于全量操作。 能编辑一行就不替换整个文件。能搜索特定模式就不读取所有文件。能跑一个测试就不跑整个测试套件。这既节省了上下文窗口，也降低了出错的范围。
文件系统是真实数据源。 不在上下文里”缓存”文件内容，需要的时候去读。这意味着即使对话进行了很久，Claude Code对文件的认知依然是最新的——因为它每次都是去读实际文件，而不是依赖几轮对话之前读到的”记忆”。
这一点你在使用中可以验证——如果你在对话过程中手动改了某个文件（比如用其他编辑器改的），然后让Claude Code继续操作这个文件，它会读到你最新的修改。如果它是依赖上下文里的”记忆”，它会看到旧版本。但实际上它看到的是新版本。
规划模块：它怎么”想”
这是整个系统里最不透明、也最核心的部分。
Claude Code面对一个复杂任务时，不是立刻开始执行的。它会先”想”。
从它的输出行为和Anthropic官方博客的描述来看，它的规划过程大致包括：
任务分析与分解
当你给它一个复杂指令——比如”给这个项目添加用户认证功能”——它会先做一个内部的任务分析：
任务分析（推测性复原）：
用户需要：添加用户认证功能
这涉及到：
1. 数据层：需要User模型、密码存储
2. 认证逻辑：注册、登录、token生成和验证
3. 中间件：请求级别的认证校验
4. API层：登录注册的路由
5. 现有代码的修改：给需要保护的路由加认证
依赖关系：
1 → 2 → 3 → 4 → 5（大致顺序）
需要先了解：
- 项目用的什么Web框架？
- 有没有已有的用户相关代码？
- 密码加密用什么方案？
你能从它的实际行为看出这个规划过程的痕迹——它通常会先读取几个关键文件（了解项目结构和技术栈），然后开始按顺序执行。如果你让它打印思考过程（通过扩展思考模式），你会看到更明确的规划步骤。
扩展思考（Extended Thinking）
这是Anthropic在Claude 3.5之后引入的一个能力，在Claude Code里被大量使用。
当遇到复杂任务时，Claude Code会进入一个”深度思考”模式——在给出行动之前，它会做更长的内部推理。在命令行界面中，你能看到一个”thinking”的指示器。
从Anthropic的技术博客来看，扩展思考不只是”想得更多”，它实际上改变了模型的推理方式：
- 普通模式：输入 → 直接生成输出
- 扩展思考：输入 → 内部推理链（可能很长）→ 基于推理链生成输出
这个推理链在Claude Code的场景下，可能包括：
我需要考虑几个方面：
1. 这个文件有300行，修改第45行会不会
影响到第120行引用的同一个变量？
让我先看看...
2. 用户之前提到不要改动现有的API签名，
但这个修改可能需要改签名...
我应该问用户还是找一个不改签名的方案？
3. 这里有两种实现方式：
方式A更简洁但耦合度高，
方式B代码多一点但更灵活...
考虑到项目未来可能的扩展需求，
选方式B更好。
扩展思考的本质是让模型在”做”之前有足够的空间”想”。 这听起来像废话，但在Agent的语境下意义重大——大部分Agent的失败不是因为执行能力不够，是因为它在想清楚之前就开始做了。
我日常使用中有一个明显的观感：当任务复杂时，thinking时间越长的那次，最终结果通常越好。 这不是巧合——更长的thinking意味着更充分的推理，更充分的推理意味着更好的规划，更好的规划意味着更少的返工。
自适应规划粒度
Claude Code的另一个巧妙之处在于——它不是对所有任务都用同样深度的规划。
简单任务（”把这个变量名从x改成count”），它直接做，几乎没有可见的thinking过程。
中等任务（”给这个函数加上错误处理”），它会短暂think一下，然后执行。
复杂任务（”把这个模块从同步改成异步”），它会长时间think，可能还会先读取多个文件来了解上下文，然后给出一个多步骤的计划。
规划深度跟任务复杂度成正比。 这节省了简单任务上不必要的开销，同时保证了复杂任务上的质量。
从技术实现角度猜测，这种自适应可能有两种实现方式——一种是模型本身学会了根据任务复杂度调整推理深度（通过训练数据中不同复杂度任务的对应推理长度），另一种是系统层面有一个复杂度评估的前置步骤，根据评估结果分配不同的推理预算。
从行为观察来看，我倾向于认为是前者——模型自身的能力，而不是外部系统的调度。因为这种适应是非常平滑的，不像是有一个离散的”简单/中等/复杂”分类器。
Agent Loop：把一切串起来
前面说的prompt、记忆、工具、规划，都是组件。把它们串成一个工作的系统的，是Agent Loop——Claude Code的核心运行循环。
┌──────────────────────────────────────┐
│ 用户输入 │
└─────────────┬────────────────────────┘
↓
┌──────────────────────────────────────┐
│ 加载记忆（CLAUDE.md + │
│ 会话历史 + 相关文件） │
└─────────────┬────────────────────────┘
↓
┌──────────────────────────────────────┐
│ LLM推理（含扩展思考） │
│ → 决定下一步行动 │
│ → 选择工具 + 参数 │
└─────────────┬────────────────────────┘
↓
┌─────┴─────┐
│ 行动类型？ │
└─────┬─────┘
╱ │ ╲
╱ │ ╲
工具调用 回复用户 请求确认
│ │ │
↓ ↓ ↓
执行工具 输出结果 等待用户
│ │
↓ ↓
获取结果 用户确认
│ │
└───────┬────────┘
↓
┌──────┴──────┐
│ 任务完成？ │
└──────┬──────┘
╱ ╲
是 否
│ │
↓ ↓
结束 回到LLM推理
这个循环看起来不复杂，但魔鬼在细节里。
关键细节一：每次循环都带完整上下文。
每次回到”LLM推理”这一步时，模型看到的不只是上一步的结果，而是整个会话的历史（可能经过压缩）+ CLAUDE.md + 当前任务的状态。这保证了它在第十步的时候还能记得第一步做了什么。
关键细节二：工具调用的结果会被注入上下文。
当Claude Code执行了一个Bash命令，命令的输出（stdout和stderr）会被完整地放回上下文。当它读取了一个文件，文件的内容会被放回上下文。这意味着LLM在下一轮推理时能”看到”工具执行的结果，从而做出更准确的判断。
关键细节三：错误恢复。
如果工具执行失败了——比如代码运行报错了——错误信息会被反馈给LLM，LLM会分析错误原因并尝试修复。这个循环可以发生多次。
我观察到Claude Code在错误恢复上有一个非常好的行为模式：它不会无脑重试。 如果同一个错误出现了两次，它通常会换一种方式来解决，而不是重复执行同样的失败操作。这暗示它在推理过程中会考虑”之前试过什么、为什么失败了”。
关键细节四：并行工具调用。
从最近的版本来看，Claude Code似乎支持在一次推理中同时决定多个工具调用——比如同时读取三个文件，而不是一次只读一个。这大幅提升了效率，尤其是在需要了解多个文件上下文的时候。
跟其他Agent的对比
理解了Claude Code的设计之后，拿它跟其他Agent方案对比，差异就很清楚了。
vs. Cursor/Windsurf：
Cursor和Windsurf是IDE内嵌的Agent。它们的优势是跟编辑器深度集成——可以看到你光标在哪、你选中了什么、你正在编辑哪个文件。但它们的Agent循环通常更短——做一到两步就停下来等你确认。Claude Code的Agent循环更长——它可以连续执行十几步，中间不需要你干预。
本质区别：Cursor更像一个”随时在旁边的助手”，Claude Code更像一个”你交代了任务就能放手的工程师”。
vs. 基于LangChain/LangGraph的自建Agent：
自建Agent的灵活性更高——你可以完全控制prompt、工具、记忆、规划的每一个环节。但Claude Code的优势在于它是一个调好的成品。Anthropic在这些环节上做了大量的调优和工程优化，这些调优的成本极高，不是个人或者小团队能轻易复制的。
尤其是prompt和模型的协同优化——Claude Code的system prompt是针对Claude 3.5/4的行为特性专门设计的，两者是一起调优的。你用其他模型加上同样的prompt，效果不会一样。
vs. Devin/OpenHands等”全自动”Agent：
Devin试图做到完全自动化——给它一个任务描述，它独立完成整个开发流程。Claude Code的定位不同——它是一个人机协作的Agent，设计上就预期人类会参与过程、提供反馈、做关键决策。
从实际效果来看，后者的可靠性目前明显更高。完全自动化的Agent在简单任务上很酷，在复杂任务上的失败率很高。Claude Code通过保持人在循环中（human-in-the-loop），在自动化程度和可靠性之间找到了一个更好的平衡点。
为什么它work
分析完这些组件之后，回到最初的问题——Claude Code为什么效果好？
不是因为某一个环节做得特别出色。是因为所有环节都做到了八十分以上，而且它们之间的配合是协调的。
system prompt精确地定义了行为边界 → 模型在边界内做出高质量的推理和决策 → 工具系统提供了精确的执行能力 → 记忆系统保证了跨步骤、跨会话的一致性 → Agent Loop把这些串成了一个能自我修正的循环。
任何一个环节拉胯，整个系统都会出问题。prompt太松，模型会乱来。工具不够精确，执行会出错。记忆管理不好，长任务会失控。循环设计不好，错误会累积。
Claude Code的护城河不是某一个技术突破，而是系统级的工程质量。 每一个组件单独拿出来，你都能在开源社区找到类似的实现。但把它们组合在一起、调到这个水平，需要的工程投入是巨大的。
写完这些分析我回头看了看，发现我花了这么多篇幅拆解的东西，归根结底是在回答一个很简单的问题——
怎么让一个AI可靠地完成编程任务？
答案不是更大的模型、更长的上下文、更多的工具。答案是——像设计一个人类工程师的工作环境一样去设计Agent的系统。
给他清晰的职责边界（system prompt）。给他趁手的工具（tools）。给他可以随时查阅的文档（CLAUDE.md + 文件系统）。给他犯错之后修正的机会（error recovery loop）。给他足够的时间想清楚再动手（extended thinking）。
然后信任他，但保持监督。
这不就是带一个好工程师的方式吗？
也许最好的Agent设计从来都不是什么全新的发明，而是对人类协作方式的忠实模拟。
我们花了几千年摸索出怎么让一群互不信任的、能力有限的、会犯错的人可靠地协作完成复杂任务——分工、流程、文档、review、反馈、迭代。这些东西不性感，但它们work。
Anthropic做的事情，本质上是把这套协作智慧翻译成了代码。
System prompt是岗位说明书。CLAUDE.md是项目文档。工具系统是工作台上的工具箱。扩展思考是”做之前先想清楚”。错误恢复循环是”出了问题复盘修正”。Human-in-the-loop是”关键节点找leader确认”。
每一个都是人类工程团队早就在用的东西。只不过这次，团队里有一个成员不是人。
几个可以自己动手验证的实验
如果你对上面的分析感兴趣，想亲自验证一些推断，这里有几个小实验你可以做：
实验一：观察规划深度的变化。
给Claude Code一个简单任务（改一个变量名），然后给它一个复杂任务（添加一个新功能模块）。注意观察两者的thinking时间和中间步骤数。你会清楚地看到规划深度的自适应。
实验二：验证文件系统读取是实时的。
在一个对话中让Claude Code读取某个文件。然后在对话不中断的情况下，用其他编辑器修改那个文件。再让Claude Code读取同一个文件。观察它读到的是修改前还是修改后的内容。如果是修改后的——说明它每次都是从文件系统实时读取，而不是依赖上下文里的”缓存”。
实验三：测试错误恢复策略。
故意给它一个会导致运行时错误的任务（比如让它写一段依赖某个未安装包的代码）。观察它在遇到错误后的行为——它会直接重试？还是先分析错误原因再决定怎么修？如果同一个错误出现两次，它的策略会不会变？
实验四：CLAUDE.md的影响力测试。
在CLAUDE.md里写一条很具体的规范——比如”所有Python函数必须用Google风格的docstring”。然后在新对话里让Claude Code写一些函数，看它是否遵循这个规范。再把这条规范删掉，开一个新对话做同样的事，看行为是否变化。这能帮你理解CLAUDE.md的加载机制和对行为的影响力度。
实验五：上下文压缩的触发点。
开一个很长的对话，持续给Claude Code任务。注意观察在什么时候它的行为开始出现微妙的变化——比如开始”忘记”早期的约定，或者它的回复里出现了对之前步骤的摘要式引用（而不是精确引用）。这个变化点大致就是上下文压缩被触发的时候。
对Agent开发者的启示
如果你自己在做Agent，从Claude Code的设计里可以提取出几条非常有价值的原则：
原则一：prompt不是”提示”，是”制度”。
不要把system prompt当成一句话的角色设定。把它当成你在写一份员工手册——行为准则、工作流程、决策规范、边界约束、应急预案，全部写进去。Claude Code的system prompt之所以有效，不是因为它用了什么高级的prompt技巧，是因为它足够详尽、足够具体。
原则二：让Agent用真实工具而不是模拟工具。
Claude Code的grep就是真的grep，bash就是真的bash。它不是在”假装”搜索文件，是真的在执行搜索命令然后读取结果。这意味着它的行动结果是精确的、可靠的。如果你的Agent在用LLM来”模拟”搜索（比如让LLM在上下文里搜索），精度和可靠性会差很多。
原则三：记忆要分层，按需加载。
不要试图把所有信息都塞进上下文。区分什么是”永远需要知道的”（放CLAUDE.md）、什么是”这个任务需要知道的”（放工作记忆）、什么是”需要的时候去查的”（留在文件系统）。这个分层设计比无限扩大上下文窗口有效得多。
原则四：给Agent”想”的空间。
不要催。让它think。推理时间和输出质量之间有很强的正相关——尤其是在复杂任务上。如果你的Agent总是在复杂任务上犯错，也许不是它”能力不够”，是你没给它足够的推理空间。
原则五：人在回路比全自动更可靠。
至少在目前这个阶段，保持human-in-the-loop是更务实的选择。Claude Code没有试图取代人——它在设计上就预期人会看它的输出、给它反馈、在关键点做决策。这种设计比”完全自动化”的Agent看起来没那么酷，但可靠性高得多。
我花了很长时间写这篇东西。过程中反复去用Claude Code、观察它的行为、对比我的分析是否自洽。有些地方我可能推断错了——毕竟没有看到Anthropic的源码和内部文档，很多东西是从外部行为反向推测的。
但我觉得这种分析本身是有价值的。
不是因为你需要复刻一个Claude Code——大部分人不需要。而是因为理解一个好的系统为什么好，会改变你设计自己系统的方式。
你做Agent的时候，你会开始想——我的prompt够不够详尽？我的工具设计是不是太粗糙了？我的记忆管理有没有分层？我有没有给模型足够的推理空间？我是不是在该让人介入的地方做了全自动？
这些问题的答案，可能就藏在Claude Code已经趟过的路里。
不用从零开始。站在巨人做过的事情上面，看看它是怎么解的，然后想想你的场景有什么不同、需要怎么调整。
这本来就是工程的本质——不是发明轮子，是理解轮子为什么是圆的，然后在你的路况上选择合适的轮子。