关于Claude Code的思想

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

Claude Code 的“新思想”不主要是某个单点功能，而是把 AI 编程从“补全助手”推向了“可控代理”。

我把它拆成几个层面说：

1. 从 Copilot 式补全，转成 Agent 式执行 Claude Code 官方定位已经不是单纯代码补全，而是“读代码库、改文件、跑命令、调用工具、完成任务”的 agentic coding 工具。这个转变本身就是它最核心的新思想：开发者不再只是让模型写一段代码，而是把一个开发任务交给它分解、执行、校验。 ([Anthropic][1])

2. 把“先规划，后执行”做成一等交互 它把 Plan Mode 做成正式工作流：先分析代码、写计划、等待你批准，再进入执行；在 VS Code 里甚至会把计划打开成一个可编辑的 markdown 文档供你批注。这不是普通的“先想想再写”，而是把 规划文档化、可审阅化、可反馈化。这其实是一种很强的方法论：AI 先产出设计，再产出实现。 ([Claude API Docs][2])

3. 把“提示词工程”升级成“上下文工程” Anthropic 后来公开强调过一个方向：对 agent 来说，关键不只是 prompt，而是 context engineering。Claude Code 倾向于不把所有信息一次性塞进上下文，而是保留轻量引用（文件路径、查询、链接等），在运行时按需加载。这个思路很重要，因为它意味着：大型代码库上的 AI 编程，不靠一次性喂全，而靠工具化检索 + 动态取上下文。 ([Anthropic][3])

4. 把“可控性”放在 agent 前面，而不是后面 Claude Code 的 hooks、permissions、plan mode、checkpointing、sandboxing，本质上都在解决同一个问题：如何让 AI 既更自主，又不失控。 尤其 hooks 很有代表性——它允许你在特定生命周期自动触发 shell、HTTP、甚至 prompt 逻辑，而且官方明确说这是为了提供 deterministic control，也就是把一些关键约束从“希望模型自觉遵守”变成“系统强制发生”。这是很新的工程思想：不要只靠模型听话，要靠外部机制管住它。 ([Claude API Docs][4])

5. 把“AI 能力”做成开发环境原生扩展层 它现在强调 Skills、Slash Commands、Plugins、MCP。尤其 Skills 用一个 SKILL.md 就能扩展能力，MCP 则让 Claude Code 接入外部工具和数据源。这里的新思想是：不是让模型什么都内置会，而是让它学会在环境里调用外部能力。 也就是从“大模型本体很强”转向“模型 + 工具生态很强”。 ([Claude API Docs][5])

6. 开始明显走向“多代理 / 分工协作” 官方文档和工程文章已经在讲 subagents、parallel Claudes、长时运行 harness 这些模式。也就是说，它不再默认“一个模型完成全部”，而是更像：主代理负责调度，子代理负责专项处理。 这也是很明显的新思想，尤其适合大仓库、复杂重构、评审和批量分析。 ([Claude API Docs][6])

7. 规划和执行开始“模型分层” Claude Code 甚至把这种思路显式做成配置：例如 opusplan 这种模式，在计划阶段用更强的推理模型，在执行阶段切到更高效的模型。背后思想很清楚：不是所有步骤都要同一种智能密度，规划和施工应该分层。 这比“全程一个模型硬跑”要成熟得多。 ([Claude API Docs][7])

8. 最近公开更新更像是在补齐“代理基础设施” 从官方 release notes 看，近几个月除了常规修 bug，也在补 SDK、MCP 输出、交互模式、plan mode 细节等；而 2025 年底到 2026 年初的模型更新则反复强调更强的 agent planning、长上下文和更可靠的大代码库操作。这说明 Claude Code 的演进重点，确实是在把“代码代理”做得更稳定、更工程化，而不是只卷 benchmark。 ([Claude API Docs][8])

所以如果你问我一句话总结：

Claude Code 真正提出的新思想，不是“AI 会写代码”，而是“把 AI 编程做成一个有计划、可审批、可回滚、可接工具、可分工的代理系统”。

这和早期 Copilot 风格最大的区别是：

早期：你写，AI 补
Claude Code 这一代：你定目标，AI 规划并执行
更进一步：你设计边界，AI 在边界内自主工作 ([Claude API Docs][9])

Claude Code 的“新思想”并不是它第一个会写代码，而是它更早、更系统地把“代理式编程”当成产品核心，而不是编辑器附属功能。 这一点和 Cursor、Copilot、Codex 都有重叠，但侧重点不一样。 ([Anthropic][1])

先看 Claude Code vs Cursor。两者都已经不是传统补全工具了，都会读仓库、改文件、跑命令，Cursor 也明确把自己叫做 AI editor / coding agent，并且有 Agent、Cloud Agent、Hooks、Terminal 控制这些能力。区别在于，Claude Code 更强调 “先规划、再执行、过程可控、可分工”：它把 Plan Mode、Subagents、Hooks、Agent SDK 这些概念串成了一套完整方法论；而 Cursor 更偏向 “把代理无缝塞进编辑器体验里”，让你在 IDE 中自然地使用 agent 和 cloud agent。也就是说，Cursor 更像“AI-native IDE”，Claude Code 更像“agent-first coding runtime”。 ([Cursor][2])

再看 Claude Code vs GitHub Copilot。 GitHub Copilot 早期的思想中心是“pair programmer”，后来才逐步加入 agent mode 和 coding agent。现在 Copilot 也支持在 IDE 中代理式编辑，还提供 coding agent 在 GitHub Actions 环境里自主完成 issue 并发起 PR；甚至还能配自定义 agent。可它的主战场仍然很明显地围绕 GitHub 工作流 展开，也就是 issue、PR、Actions、workspace 这些软件工程节点。相比之下，Claude Code 的思想更像是在说：代理本身就是开发环境，终端、IDE、hooks、subagents、MCP/工具接入都只是这个代理系统的外设。 ([GitHub Docs][3])

再看 Claude Code vs OpenAI Codex。 OpenAI 现在的 Codex 也已经明确是 coding agent，不只是模型名字；官方既有云端 Codex，也有本地终端里的 Codex CLI，还能通过 Agents SDK 和 MCP 接起来。它的思路很强的一点是：让编码代理变成可嵌入、可组合、可编排的基础能力，比如 AGENTS.md、CLI、SDK、MCP server 这些都很工程化。和 Claude Code 比，Codex 更像在铺 “编码代理基础设施”，而 Claude Code 更强调 “如何把代理工作流本身做得更稳、更可控、更适合真实仓库协作”。两者都在走 agent 化，但 Anthropic 更突出 workflow discipline，OpenAI 更突出 platform 化和可集成性。 ([OpenAI开发者][4])

如果只谈“思想创新密度”，我会这么排： Claude Code 最强的是“规划—执行分离、代理可控化、上下文工程化、多代理分工”； Cursor 最强的是“把 agent 深度嵌入 IDE，让代理成为默认编程交互”； Copilot 最强的是“把 agent 接到 GitHub 软件工程闭环”； Codex 最强的是“把 coding agent 做成终端 + 云端 + SDK + MCP 的统一平台”。这些方向都新，但 Claude Code 的特色确实最像一种 开发方法论升级，而不只是产品形态升级。 ([Claude API Docs][5])

那我直接讲最实用的部分：

如果你自己做 AI Agent，最该借鉴 Claude Code 的，不是“做一个会写代码的模型”，而是做一个“有工作流约束的执行系统”。

我建议你按下面这套去设计。

不要让一个 Agent 既负责想，又负责一把梭执行。更稳的做法是拆成两层：

Planner：理解任务、读取必要上下文、输出步骤计划
Executor：按批准后的步骤调用工具、修改文件、运行命令
Reviewer：检查结果、跑测试、判断是否达标

Claude Code 的常见工作流本质上就是这个思路：先理解代码库和任务，再进入修改、测试、提交等执行阶段。Anthropic 也把这种“先分析再动手”做成了正式工作流。([Claude][1])

这套结构的好处很大：

容易审查
容易回滚
容易定位错误到底出在计划还是执行
后面扩展多代理时也自然

很多人做 Agent 时，问题不在模型不聪明，而在于 喂给它的上下文太乱、太多、太旧、太不相关。Anthropic 公开把这个方向称为 context engineering，核心就是：在推理过程中持续维护“当前最合适的信息集合”，而不是一次性把所有东西塞进去。([Anthropic][2])

所以你应该这样做：

只给当前任务相关的文件摘要
大文件先摘要，再按需展开
历史操作保留结构化记录，而不是整段对话硬塞回去
工具输出做裁剪，只保留关键片段
上下文分层：系统规则、项目规则、当前计划、当前步骤、最近观察

一句话： Agent 的稳定性，更多取决于上下文管理，而不是提示词文采。

这是 Claude Code 很值得学的一点。官方明确区分了“说明性指令”和“确定性 hooks”：有些事不能只靠模型自觉，比如“改完必须跑测试”“禁止写某目录”“提交前必须 lint 通过”，这类要求应该交给 hooks 或外部守卫来强制执行，而不是写在 prompt 里碰碰运气。([Claude][3])

你的 Agent 系统至少应该有三类守卫：

前置守卫：执行前检查权限、路径、参数范围
过程守卫：敏感命令二次确认、超时中断、资源配额
结果守卫：测试不过不能提交，格式校验不过不能结束

这背后是一个很重要的思想：

不要只训练 Agent 更聪明，要把环境设计得让它更不容易犯大错。

Anthropic 也强调过，Agent 的效果很依赖工具质量，而不是工具数量。([Anthropic][4])

你一开始最值得做好的，不是 50 个工具，而是 5 个真正可靠的工具：

read_file
search_code
edit_file
run_command
run_tests

然后补两个高价值工具：

make_patch 或 apply_diff
summarizechanges

每个工具都要做到：

输入输出清晰
失败可解释
可重试
可审计
返回尽量结构化

data-pid=“LA3g6kG”>Agent 最怕“工具看起来能用，其实返回一大坨不可控文本”。

OpenAI Agents SDK 现在也把 handoff、tools、tracing 这类东西做成了核心能力，说明业界已经很明确：Agent 不是只要结果，还必须能回溯过程。([OpenAI开发者][5])

你自己的 Agent 至少要记录：

任务目标
当前计划版本
每一步调用了什么工具
读了哪些文件
改了哪些文件
每次失败原因
最终验证结果

没有 trace，Agent 一旦出错，你会完全不知道是：

理解错了任务
找错了文件
改错了逻辑
工具返回异常
测试环境有问题

Claude Code 的 subagents 很有代表性：不是让一个 Agent 什么都做，而是让不同 Agent 做不同类型的任务，比如代码搜索、重构、测试、审查。([Claude][6])

你自己做时，最稳妥的路线是：

阶段 1：单代理 + 工具 阶段 2：Planner / Executor 两代理 阶段 3：加 Reviewer 阶段 4：再拆专项子代理

例如游戏开发里可以拆成：

Gameplay 规则分析代理
UI/UX 代码代理
数据表与配置代理
测试与回归代理
性能检查代理

但别一开始就搞 8 个 agent 编排。多代理的前提是：单代理工作流已经足够稳定。

MCP 的意义就在这里：它把“模型怎么接外部工具和数据源”标准化了，相当于 Agent 生态的通用接口。OpenAI Agents SDK 也把 MCP 当成正式接入方式之一。([OpenAI][7])

这对你自己的系统很重要，因为它意味着：

代码库读取器可以换
issue tracker 可以换
文档系统可以换
测试平台可以换
甚至底层模型也可以换

也就是说，你应该把系统设计成：

Agent Runtime ↓ Tool Interface / MCP Layer ↓ Git / IDE / Docs / CI / Asset Pipeline / DB

而不是把所有东西直接耦死在一个 prompt app 里。

Claude Code 这类系统之所以更像工程工具，是因为它输出的不只是回答，而是：

计划
patch
测试结果
变更摘要
审核点

所以你自己的 Agent 最后也不要只返回“已完成”。应该返回这种结构：

做了什么
改了哪些文件
为什么这么改
哪些地方还不确定
哪些测试通过了
哪些风险仍在

这样用户才能真正把它纳入开发流程。

你之前一直在问游戏开发，这里其实特别适合用 Claude Code 这套思想。

例如做一个 UE / Unity Gameplay Agent，最合理的结构是：

输入需求，比如：

做一个 Buff 系统
新增技能授予逻辑
改造寻路模块
增加行为树节点

输出：

改动模块清单
涉及类和资源
风险点
分步实现计划

真正去：

搜索代码
改 .h/.cpp、cs
改配置和数据表
生成测试脚本
运行编译或单测

检查：

是否破坏现有接口
是否符合项目代码规范
是否遗漏资源引用
是否有性能/GC/蓝图绑定风险

例如：

不允许直接改核心框架目录
任何 Ability/Buff 改动必须跑指定测试
提交前必须更新文档或变更日志

这套其实就已经很像 Claude Code 的“计划—执行—验证—守卫”体系了。

如果你真要自己做 Agent，最该抄的不是某个产品界面，而是这 4 条：

第一，计划和执行分离。 第二，上下文动态装配，不要一次性灌满。 第三，关键规则用系统机制强制，不靠模型自觉。 第四，所有动作都可追踪、可审阅、可回滚。

这四条一旦做好，你的 Agent 就会从“偶尔能用的聊天机器人”，变成“可以进开发流程的工程系统”。这正是 Claude Code 最值得学的地方。([Claude][1])

Claude Code 这类系统的核心不是陪聊，而是把开发任务拆成 规划、执行、验证、约束 四个环节；Anthropic 官方工作流也明确围绕“理解代码库、调试、重构、测试、PR”来组织，而不是单轮问答。与此同时，Claude Code 还提供 Sub-agents、Hooks 这些能力，分别用于任务分工和确定性控制。([Claude][1])

所以游戏开发里的对应目标应该是：

输入一个研发需求 → Agent 自动分析项目 → 产出计划 → 改代码/资源/配置 → 跑验证 → 给出可审阅结果。

不是：

用户提个问题 → AI 回一段建议。

我建议你做成下面这 7 层：

[1] User Task Layer └── 自然语言任务 / issue / 设计需求 / bug 单 
 [2] Orchestrator Layer
 └── 主控代理（任务解析、分派、状态管理、回滚点） 
 [3] Planning Layer
 ├── 需求分析代理 ├── 代码探索代理 └── 实施计划代理 
 [4] Execution Layer
 ├── C++ / C# 代码修改代理 ├── 配置 / 数据表代理 ├── 蓝图 / Prefab / UI 资源代理 └── 命令执行代理（编译、测试、导出） 
 [5] Validation Layer
 ├── 编译验证代理 ├── 单元测试 / 集成测试代理 ├── 静态检查代理 └── 性能 / 风险审查代理 
 [6] Governance Layer
 ├── 权限控制 ├── Hooks / 守卫规则 ├── 审批点 └── Checkpoint / 回滚 
 [7] Context & Tool Layer
 ├── 代码检索 ├── 文档检索 ├── 资源索引 ├── Git / Issue / CI └── MCP / 工具协议层

这套结构背后的依据其实很直接：

Claude Code 官方把“工作流”设计成探索、计划、实施、验证的过程。([Claude][1])
Claude Code 的 Hooks 文档明确强调：把某些行为变成 deterministic control，不要只靠模型临场判断。([Claude][2])
OpenAI Agents SDK 也把 tools、handoffs、trace 作为 agent 应用的基础能力，说明“主控 + 专项代理 + 工具 + 追踪”已经是成熟的工程范式。([OpenAI开发者][3])
MCP 的目的就是把工具和上下文接入标准化，避免整个系统绑死在某一种实现上。([OpenAI][4])

例如用户输入：

“给 Lyra 风格技能系统增加被动 Buff 授予”
“修复 AI 巡逻偶发卡死”
“把旧 Buff 计算器改成表达式树 + 条件分支”
“做一个技能冷却和叠层 UI”

主控代理先把任务转成结构化对象：

“goal”: “新增被动Buff授予”, “domain”: “GameplayAbilitySystem”, “targets”: [“AbilityGrant”, “BuffApply”, “TagCondition”], “risk”: “中高”, “requires_plan”: true, “requires_approval”: true }

先不改代码，先做探索：

哪些模块受影响
哪些类和资源相关
是否已有类似实现
是否涉及多人系统、存档、网络同步、编辑器资源引用

这一步对应 Claude Code 的“understand new codebases / explore before editing”思路。([Claude][1])

输出最好是：

发现： 
               
     
                  
                  Buff 应用在 WFGameplayEffectSubsystem 
                  技能授予在 WFAbilityGrantComponent 
                  被动能力激活依赖 Tag 初始化顺序 
                  有现成的 OnSpawnGrant 逻辑可复用 风险： 
                  
               
     
                  
                  网络同步 
                  重复授予 
                  移除时回收不完整

规划代理产出一个明确计划：

Plan v1 
                
     
                   
                   扩展 AbilityGrantSpec，增加 PassiveBuffDefinitions 
                   在角色初始化后、Tag Ready 后执行被动Buff授予 
                   为每个Buff记录来源AbilityHandle，便于卸载 
                   增加重复授予保护 
                   添加单元测试：授予、重复授予、移除、重生恢复 
                   跑 gameplay tests

这一步最好是 可编辑的计划文档。这正是 Claude Code 的强项之一：先把计划文档化，再进入执行。([Claude][1])

执行代理只做被批准的步骤。不要允许它“想到哪改到哪”。

每一步都应具备：

读取目标文件
生成 diff
应用 patch
记录原因
触发必要验证

例如：

Step ²⁄₆ 修改： 
                 
     
                    
                    WFAbilityGrantComponent.cpp 
                    WFAbilityGrantTypes.h 
                   
 原因： 需要在授予能力时附带被动Buff定义，并记录来源句柄
 验证： 
                 
     
                    
                    编译该模块 
                    跑 AbilityGrantTests.PassiveBuffGrant

验证代理不是简单跑一下编译，而是要按任务类型切验证模板。

编译相关模块
单元测试
标签/状态机回归
重复进入/退出场景
网络同步检查

编译
绑定完整性
资源引用合法性
空数据回退
多分辨率基本检查

行为树是否可加载
黑板键一致性
路径失败回退
tick 成本
死循环/阻塞风险

不要只输出“完成了”。

应输出：

已完成 新增 PassiveBuffDefinitions 配置
 在角色初始化完成后自动授予被动Buff
 增加来源AbilityHandle回收逻辑
 增加重复授予保护
 修改文件 
                   
     
                      
                      Source/…/WFAbilityGrantComponent.cpp 
                      Source/…/WFAbilityGrantTypes.h 
                      Tests/…/AbilityGrantTests.cpp 
                     
 验证结果 
                   
     
                      
                      模块编译通过 
                      3个相关测试通过 
                      1个网络同步测试未覆盖 
                     
 剩余风险 
                   
     
                      
                      重生流程下的跨局恢复尚未验证

这个“交付物”思路，本质上和现代 agent SDK 强调 trace、handoff、tools 可追踪是一致的。([OpenAI开发者][3])

这里我给你一版够实用的拆法。

职责：

接收任务
判断任务类型
决定是否需要计划
调度子代理
保存状态和 checkpoint
汇总最后结果

它不直接大量改代码，它负责“管流程”。

职责：

搜索相关模块
建立调用链
识别关键类、资源、配置项
找相似实现
产出“影响面分析”

适合回答：

这功能现在在哪实现？
改这个系统会波及哪些模块？
有没有现成模式可复用？

这和 Claude Code 内置的 Explore / Plan 类分工非常接近。([Claude][5])

职责：

把需求转成分步计划
标注风险点
标注审批点
指定每一步所需验证

这是整个系统最值钱的代理之一。很多 Agent 失败不是执行差，而是 一开始改错方向。

职责：

改玩法逻辑
处理 Ability、Buff、属性、状态机、AI 规则
更新相关测试

它适合 UE 的：

GAS
Gameplay Tags
Buff / GE
Ability Grant / Activation
AI Combat Logic

也适合 Unity 的：

Character Ability
Buff Stack
Combat Formula
State Machine
ECS Gameplay System

职责：

改 HUD、面板、状态条、技能栏
检查绑定和资源路径
处理缺省态和数据更新链

UI 修改和 Gameplay 修改最好分开，因为这两类任务的风险、上下文和验证方式差异很大。

职责：

改 DataTable / JSON / ScriptableObject / ini / yaml
校验字段合法性
生成默认配置
检查枚举和配置同步

游戏项目里很多 bug 根本不在代码，在配置。

职责：

跑测试
做静态检查
审查接口兼容
查漏改动
输出风险报告

这相当于“AI reviewer”。

职责：

编译指定模块
跑自动化测试
生成工件摘要
汇总失败日志

这类代理可以是半自动的，很多动作更适合通过工具和脚本来完成。

Claude Code Hooks 的价值就在于：某些事必须“总会发生”，不能寄希望于模型记得做。官方文档明确把 hooks 定义为在生命周期特定节点执行的用户自定义命令，用来 enforce project rules 和 deterministic control。([Claude][2])

你在游戏开发里最该做的 hooks / guard，大概是这几类：

限制敏感目录：

Engine/
核心框架
自动生成文件
第三方插件
发布资源目录

规则例子：

禁止修改 /Engine 和 /ThirdParty 修改 /CoreGameplay 需审批 修改 .uasset/.prefab 前必须备份

限制危险命令：

删除大量资源
强制重写 git 历史
全量烘焙/全量打包
外部网络访问
高成本长时命令

例如：

改 C++ 必须编译相关模块
改 Buff/Ability 必须跑 gameplay tests
改 UI 必须检查资源绑定
改配置必须做 schema 校验

例如：

diff 过大时自动转入审查模式
涉及 5 个以上文件时自动要求计划
涉及网络同步模块时自动提高风险等级
测试失败不能标记完成

这些都应该是系统规则，不该只是 prompt 里的愿望。

Anthropic 对“context engineering”的定义很明确：不是只写好 prompt，而是持续维护推理时的最优信息集合。([Anthropic][6])

在游戏项目里，这一点尤其重要，因为上下文非常杂：

代码
资源
配置
设计文档
测试日志
引擎 API
项目约定

所以我建议你把上下文分成 5 层。

永远存在：

你是谁
你能用哪些工具
什么不能做
输出格式要求

比如：

命名规范
模块边界
网络同步约束
Buff / Ability 编码规范
UI 绑定约定

这层很像 Claude 生态里的项目级指导文件思路。

当前任务的信息：

目标
验收条件
风险级别
已批准计划

当前步骤需要的最小文件集：

相关类
关键配置
最近 diff
错误日志片段

只保留当前步骤真正要用的。

保留摘要，而不是原始长对话：

已尝试方案
失败原因
已验证结论
未解决问题

这才是能扩展到大项目的方式。

一开始别搞太复杂，先做这些：

read_file(path) search_code(query) list_directory(path) apply_patch(file, diff) run_command(cmd) run_tests(scope) read_log(file) write_summary(text) git_diff() git_checkpoint()

find_assets(name/type/tag) validate_datatable(path) check_blueprint_refs(asset) profile_scene(scene_name) query_issue_tracker(id) read_design_doc(doc_id)

如果要做长期可维护，最好通过统一协议接工具。MCP 的目标就是标准化“给模型提供工具和上下文”的接口，OpenAI 的文档也把它当成正式支持的接入方式。([OpenAI][4])

C++ 头源文件依赖分析
GAS 专项代理
GameplayTag 检查器
DataTable 校验器
Blueprint 引用与命名检查
网络复制风险检查

ScriptableObject 校验器
Prefab 引用检查
Assembly Definition 依赖检查
Addressables 检查
ECS/System 调度检查
场景资源依赖扫描

最稳的 1.0 版本只做这条线：

需求输入 → Explore → Plan → Gameplay Executor → Test Reviewer → 结果摘要

只支持这两类任务：

Gameplay 小功能新增
Gameplay bug 修复

只支持这些工具：

读文件
搜索代码
改代码
编译
跑测试
输出 diff 和总结

只做文本资源，不碰复杂二进制资源。这样成功率会高很多。

我给你压成 6 句话：

1. 先探索，再规划，再动手。 2. 计划必须可审阅，执行必须受约束。 3. 工具返回要结构化，不能是一坨不可控文本。 4. 关键规则放到 hooks/守卫里，不靠模型自觉。 5. 上下文按步骤动态装配，不要一次性塞满。 6. 结果必须可追踪、可验证、可回滚。

这套思路和 Claude Code 的工作流、Sub-agents、Hooks，以及更广义的 MCP / Agents SDK 方向是对齐的。([Claude][1])

相关推荐