Claude Code为什么可以独立完成工程任务
不少小伙伴第一次接触 Claude Code，会把它理解成“放在终端里的聊天机器人”。这个说法只能解释它为什么能回答问题，解释不了它为什么能自己搜索代码、修改文件、跑测试，遇到报错以后还会继续排查。
我更愿意从一次工程任务看它。假设我们给出下面这个需求：
订单取消后，已经预占的优惠券没有释放。请先定位调用链，补一个能复现问题的测试，再修复并运行相关测试。不要改数据库表结构。
完成这件事需要连续处理几类信息：
- 理解目标和“不要改表结构”这条边界；
- 找到订单取消、优惠券预占、事务处理相关代码；
- 判断问题发生在状态流转、事件投递还是消费逻辑；
- 修改测试与实现；
- 运行测试，并根据失败结果继续修正；
- 汇报改了什么、验证了什么、还剩什么风险。
LLM 负责语言理解和推理，Claude Code 外面的执行系统负责把推理变成一轮轮可观察的动作。面试里把这两层分开，后面的工具调用、上下文管理、Hooks、多 Agent 就容易讲明白了。
一次任务是怎样跑起来的
Claude Code 收到需求后，通常会反复执行四个动作：读取当前状态、选择下一步、调用工具、吸收结果。这个循环一直持续到任务完成、需要用户决策，或者碰到无法继续的阻塞。
可以把它写成一个简单状态机：
接收目标
↓
读取规则与工作区状态
↓
选择下一步动作
↓
调用工具并取得结果
↓
更新判断、计划和上下文
↓
完成了吗？── 否 ──→ 继续下一轮
│
是
↓
给出结果与验证证据
这里的“选择下一步”由模型完成，“读取文件”“执行测试”“修改代码”由工具完成，工具结果再回到下一轮模型输入。Claude Code 因此具备了闭环能力。它不需要用户把每个命令逐条写出来，但每一步仍然受工具权限和当前环境约束。
第一步，先把问题缩小
面对陌生仓库，直接读取全部文件既慢又浪费上下文。更常见的方式是先用目录、文件名和符号做筛选，再打开关键片段。
订单取消问题可能沿着下面这条线索推进：
- 搜索取消订单的入口方法和状态枚举；
- 找到取消成功后发布的领域事件或消息；
- 搜索优惠券释放方法的调用方；
- 对照正常退款、超时关闭等相似流程；
- 阅读相关测试，确定项目已有的测试写法。
文件路径、类名、导入关系和测试名称本身就是线索。先收窄范围，再读正文，能让窗口里留下更多与当前判断有关的内容。
第二步，把判断变成工具调用
模型不能直接碰磁盘，也不能在脑子里执行 Maven。它只能选择已经注册的工具，并生成工具需要的参数。
例如，它可能决定搜索 releaseReservedCoupon 的调用位置。Agent运行时校验工具名和参数后执行搜索，再把结果返回。模型看到命中的文件与行号，下一轮才决定读哪几个文件。
如果工具参数不合法、命令失败或权限被拒绝，失败结果也会回到循环里。一个成熟的 Coding Agent 需要把错误当作新的环境信息：命令不存在就查项目实际脚本，测试失败就读失败栈，权限被拒绝就换成安全做法或请求用户确认。
第三步，在真实工作区修改
代码修改发生在文件系统中，模型输出的说明并不能代表文件已经改变。Claude Code 需要调用 Edit、Write 一类工具，执行层再把改动落到工作区。
这也解释了为什么验收时应该看 git diff、测试结果和运行行为。模型说“已经修复”只是一段文本；文件变更和验证证据才是工程结果。
Model与Harness分别负责什么
面试官如果追问“Claude Code 强在模型还是框架”，我会先说两边都重要，再给出清楚的职责表。
| 组件 | 主要工作 | 出问题时常见表现 |
|---|---|---|
| 模型 | 理解意图、阅读代码、形成假设、选择工具、组织结果 | 推理方向错、遗漏分支、误解业务语义 |
| System Prompt | 定义角色、默认行为、工具使用说明 | 行为边界含糊、工具选择不稳定 |
| Agent运行时 | 组织循环、注册工具、传递结果、维护会话状态 | 工具结果丢失、状态接不上、流程提前结束 |
| 文件与Shell工具 | 读取、搜索、修改、执行命令 | 参数错误、路径错误、命令返回失败 |
| 权限与Sandbox | 限制可读、可写、可执行范围 | 高风险动作被拦截，或授权过宽造成风险 |
| Hooks | 在固定生命周期节点执行审计、阻断与收尾 | matcher 过宽、脚本超时、错误返回码失效 |
| MCP | 连接 GitHub、监控、数据库等外部系统 | 服务未连接、Schema 太多、凭据或网络问题 |
| 项目规则与Skills | 提供长期约定和按需工作流 | 规则冲突、内容过长、Skill 触发不准 |
模型像一个会分析问题的开发者，Agent运行时提供工作台、工具箱、执行规程和任务记录。模型升级可以提高推理上限，执行系统的设计会影响它能否在真实仓库中稳定完成长任务。
Claude Code能看到哪些环境信息
每轮推理都依赖当前上下文。常见信息来源包括：
- Claude Code 自己的系统指令和工具说明；
- 当前目录及其上层加载到的
CLAUDE.md； - 命中路径条件后加载的
.claude/rules/； - 用户本轮需求和前面的对话；
- 已经返回的文件内容、搜索结果、命令输出；
- 使用中的 Skill 正文；
- Auto Memory 的索引内容；
- MCP、IDE 或客户端注入的环境状态。
信息继续增加也会带来成本。几万行测试日志会挤占目标、约束和关键代码的位置；几十个很少使用的 MCP 工具也会增加选择难度。后面讨论上下文管理时，我会具体讲怎样控制这些信息的进入、保留和淘汰。
权限系统为何必须独立存在
自然语言规则能指导模型，例如“不要修改迁移文件”。模型依然可能误判，长会话里也可能漏掉早期提醒。必须强制执行的边界要落到权限、Sandbox、Hook、CI 或人工审批上。
以数据库迁移为例，可以分三层：
CLAUDE.md解释团队约定：已有迁移文件禁止修改，新变更必须新增版本；permissions.deny或PreToolUseHook 拦截对历史迁移文件的 Edit/Write；- CI 检查迁移文件哈希，防止任何工具或开发者绕过本地规则。
三层承担的职责不同。第一层让模型知道应该怎么做，第二层在本机阻止危险动作，第三层守住团队合并入口。
MCP、Skills、Hooks和Subagent放在执行链的哪里
这几个概念经常被放在一起问，我会按“它给系统增加了什么”来区分。
| 机制 | 增加的东西 | 典型场景 |
|---|---|---|
| MCP | 外部工具与数据入口 | 查询 Sentry、读取设计稿、访问 GitHub、调用内部平台 |
| Skill | 一套按需加载的做事方法 | 接口兼容性检查、故障排查、发版清单 |
| Hook | 某个生命周期节点必定执行的动作 | 修改后校验、调用前拦截、等待权限时通知 |
| Subagent | 一个隔离的支线工作窗口 | 大量搜索、日志归因、独立审查 |
| Agent Teams | 多个可通信的独立会话 | 前后端与测试并行推进、多个假设相互验证 |
一个需求可以同时用到它们。主 Agent 调用 Sentry MCP 拉取错误，交给 Subagent 分析一批日志，加载故障排查 Skill 统一输出格式，并由 Hook 拦截任何生产写操作。它们在一条执行链上配合，职责并不冲突。
工程闭环怎样判断完成
Claude Code 生成了代码，还需要证明任务已经完成。我一般让验收至少覆盖四层。
文件层
检查实际 diff：修改范围是否符合需求，有没有顺手改到无关文件，是否出现生成产物或敏感信息。
结构层
运行编译、静态检查和格式化。它们能发现语法、类型、依赖与风格问题。
行为层
运行能够复现问题的测试。优惠券案例里，至少要证明订单取消后预占记录被释放，同时正常支付、重复取消等原有路径没有被破坏。
运行层
涉及页面、进程、外部服务或异步消息时，还要看真实运行结果。测试全绿只能证明测试覆盖到的行为正确，无法替代页面截图、接口响应、消费日志或观测指标。
Claude Code 可以完成工程任务，靠的是模型和 Agent运行时的配合。模型负责理解目标、阅读代码、形成判断和选择工具；运行时负责加载规则、执行文件与 Shell 工具、传递结果、维护上下文和权限。每次工具返回都会进入下一轮判断，形成“观察、行动、再观察”的循环。最终结果要由 diff、测试和运行证据验收，不能只看模型的文字结论。