落樱小镇寿司屋2026
37.80M · 2026-03-30
过去一年，如果你经常写代码，大概率已经被各种 AI Coding 工具教育过一轮了。
最开始大家关注的是补全。
后来开始比谁能改代码、谁能解释报错、谁能生成函数。
再往后，工具开始支持 Agent、支持多文件改动、支持接入更多上下文。
但如果你最近认真看过 Claude Code 的产品形态，会发现一个很明显的变化：
AI 编程这件事，正在从“IDE 里的助手”，往“工程工作流里的代理”迁移。
这是我觉得 Claude Code 真正值得关注的原因。
它的重点已经不只是“帮你写代码”，而是开始进入更完整的软件工程链路：读仓库、跑命令、改文件、接规则、接工具、接 Git、接 CI。
这和我们过去理解的 AI Coding，已经不是同一个层面的问题了。
我自己的判断是：值得，而且越是认真做工程的人，越应该早点上手。
但有个前提得先说清楚：
Claude Code 不是一个“更会写代码的聊天机器人”。
它更接近一个能在终端里执行任务的 coding agent。
这句话听起来像定义，但背后其实对应的是完全不同的使用方式。
如果你对 AI 编程工具的理解还停留在下面这些事：
那你看到的还是第一阶段。
Claude Code 真正往前推了一步的地方在于：
它开始进入完整的软件工程流程，而不是只停在“写代码”这一个动作上。
所以讨论 Claude Code，不能只问“它好不好用”，而应该问下面这些更关键的问题：
下面就按这个逻辑往下讲。
因为如果不先讲 Cursor，很难看清 Claude Code 到底“新”在哪。
过去一年，很多开发者真正第一次高频使用 AI Coding，不是从 Claude Code 开始，而是从 Cursor 开始。
这不是偶然。
Cursor 最大的贡献，不只是做了一个很好用的编辑器，而是它定义了第一代主流 AI 编程工具的核心心智：
以 IDE 为中心，把 AI 注入编码过程。
它的产品演化路径其实很典型：
Tab 补全Inline EditAsk / AgentBackground AgentMCP、Automations、CLI、JetBrains 等能力这条路线本身没有问题，而且非常成功。
它把很多开发者从“AI 补全很好用”带到了“AI 可以实际参与编码任务”。
但 Cursor 也有一个天然边界：
它本质上还是 IDE-first。
而现实中的软件工程，远不只是“打开编辑器写代码”。
很多真正影响交付效率的动作，其实发生在 IDE 之外：
你越往工程深处走，越会发现一件事：
真正耗时间的，不一定是“把代码写出来”，而是把代码放进一个可验证、可交付、可回滚的流程里。
这也是为什么 AI 编程工具发展到下一阶段，产品形态一定会从“编辑器助手”走向“工作流代理”。
Claude Code，刚好踩在这个转折点上。
Anthropic 对 Claude Code 的定位其实很直白：
它是一个 lives in your terminal 的 agentic coding tool。
这句话表面上只是产品描述，但它其实已经把 Claude Code 和很多 IDE 类 AI 工具区分开了。
Claude Code 的中心，不在编辑器，而在 终端和工作流。
如果让我用更工程化一点的话来概括，我会把 Claude Code 理解成三层能力的叠加。
最表层的理解当然没错：你可以在终端里直接和它对话，问它问题，让它分析仓库，让它给出方案。
但只把它理解到这里，其实是低估它了。
Claude Code 和普通聊天式工具最大的区别，不是它“懂不懂代码”，而是它能不能推进任务。
它不只是告诉你“应该怎么改”，而是真的可以参与下面这些动作：
这就意味着，Claude Code 的价值不在于“回答得多漂亮”，而在于它能不能把一个软件任务往前推。
这点很多人第一次用的时候最容易忽略。
Claude Code 不是一个孤立的本地 CLI 工具。
它周围已经有一整套工程化配套能力：
CLAUDE.md 继承项目规则所以从工程视角看，Claude Code 更准确的定位其实是：
一个运行在终端里的工程代理。
它开始具备进入团队工作流的条件，而不只是给个人提建议。
理解一个工具，除了看它能做什么，更重要的是看它不该被当成什么。
我觉得 Claude Code 至少不应该被误解成下面这几类东西。
这是最常见的误区之一。
Claude Code 确实有 IDE 集成，但它的核心产品逻辑并不是“替代 VS Code、Cursor 或 JetBrains”。
它真正补的是另一块：
让 AI 进入 IDE 之外的工程链路。
所以它和 Cursor 的关系，不是简单的替代关系，更像是关注点不同：
很多人第一次看到它能读仓库、改文件、跑命令，就会立刻想象成一个全自动开发者。
这其实不对。
恰恰因为它能执行任务，所以官方才会同时提供：
这背后传达的信号很明确：
它不是拿来无限制放权的。
你可以把它当高执行力的代理，但不能把它当无约束的自动化脚本。
如果你只是拿 Claude Code 来问这些问题：
那当然也能用，但这基本没有发挥它真正的价值。
Claude Code 的优势不是抽象知识问答，而是：
它能进入具体仓库和具体工程环境里，处理多步软件任务。
这是最关键的一点。
很多团队在引入 Agent 类工具时，最大的误判就是觉得“工具变强了，流程要求可以降一点”。
现实往往相反。
Agent 越强，越需要规则、测试、边界和约束。
因为一个高执行力系统最大的风险，不是它什么都不会做，而是它会在错误目标上高效率地做很多事。
如果把 Claude Code 的能力拆开看，我觉得可以归纳成六类。这里不说宣传页上的能力列表，而是从工程使用感受出发，谈哪些能力真的会改变开发方式。
很多工具都说自己“理解项目”，但真正有价值的不是一句泛泛的理解，而是它能不能快速建立出一张可用的代码地图。
在陌生仓库里，Claude Code 的价值主要体现在几件事上：
很多人第一次认真用 Claude Code，最强烈的感受并不是“它写代码真快”，而是：
它熟悉一个仓库的速度，比人手动翻目录快很多。
这件事在中大型项目里非常值钱。
真实软件需求很少只落在一个文件里。
一个看起来不大的改动，背后往往会同时影响：
Claude Code 的一个明显强项，是它不只会做局部 patch，而是能在多文件上下文里推进同一个任务。
这和传统的“生成一个函数”是两件事。
这是它和很多 IDE 类工具真正拉开差距的地方。
现实开发里，代码改完通常才只是开始。
后面还要做很多事：
当 AI 进入终端之后，它不再只是“建议者”，而是开始进入执行路径。
这件事的意义不只是省几次复制粘贴，而是让 AI 真正具备了“完成一个工程任务”的基础条件。
Claude Code 很工程化的一点，是它支持把项目规则写进 CLAUDE.md。
这听起来像个小功能，但实际非常关键。
因为日常使用里最烦的一件事，就是你每次都在重复解释同样的上下文：
这些信息如果不能沉淀，每一次对话都会变成一次重复劳动。
而一旦项目规则能被稳定继承，Claude Code 才从“偶尔好用的工具”变成“长期可复用的工程助手”。
通过 MCP，Claude Code 的上下文来源不再局限于本地仓库。
理论上，它可以接入很多组织系统：
这件事的意义不在于“能连很多东西”，而在于：
它开始有条件同时理解代码上下文和组织上下文。
这会直接提高它在复杂任务中的判断质量。
Claude Code 已经不只是本地开发工具，它也开始往 PR、Issue、CI 这些环节延伸。
比如：
@claude 触发分析一旦这类能力逐渐成熟，Claude Code 的身份就不再只是“个人提效工具”，而是会变成团队流程中的一个节点。
任何 AI 工具都有边界。
如果你对它期待过高，最后一定失望；如果你把它看得太轻，又会白白浪费它的能力。
所以我觉得，理解 Claude Code，最重要的不是只看上限，而是看清边界。
Claude Code 最适合的是这类任务：
典型场景包括：
这些任务有个共同点：
不是纯开放式思考，而是有执行目标、有上下文、有反馈机制。
Claude Code 不擅长的，通常是下面几类情况：
比如下面这种话：
这类问题当然可以拿来讨论，但很难直接拿来执行。
它可以帮你拆解问题，但前提仍然是：
你得先把任务收敛到可以操作的粒度。
还有一个特别容易被忽略的点：
Claude Code 能看到代码，也能跑命令，但这不代表它天然掌握真实系统状态。
如果这些条件不成立：
那它的判断上限就会明显受限。
所以很重要的一句话是：
Claude Code 对“代码世界”的理解很强，但对“运行时现实”的判断，仍然依赖你给边界。
这是大家最爱问的问题，但我其实不太认同“二选一”的提法。
更准确的问法应该是：
你的工作重心更偏编辑器内，还是更偏工程流程？
如果你的日常工作主要是下面这些：
那 Cursor 往往会更自然。
它的优势是编辑器内的流畅感非常强，AI 交互几乎贴着你当前工作区发生，心智负担比较低。
如果你的工作更偏下面这些：
那 Claude Code 通常会更强。
如果一定要一句话概括，我会这样说：
长期看，两边其实会互相逼近。
Cursor 在补 CLI、Background Agent、Automations、MCP；Claude Code 也在补 IDE 集成、GitHub Actions、技能体系。
但至少在当前这个阶段，Claude Code 在“把 AI 深度接进工程系统”这件事上，路线更明确。
很多人不是不会装工具，而是不会把工具用对。
下面这些经验，我觉得比“某个 prompt 模板”更重要。
很多人一上来就问大而空的问题，结果当然不稳定。
Claude Code 在任务足够清晰的时候，表现会明显更好。
好的输入通常具备四个要素：
比如下面这种说法就太虚：
而下面这种就明显更像工程任务：
区别很简单：
前者是在提愿望，后者是在下任务。
CLAUDE.md这个文件是 Claude Code 从“偶尔好用”走向“持续可用”的分水岭。
没有它，你每次都得重新解释项目背景。
有了它，很多工程规则就能被稳定继承。
一个最小可用版本可以长这样：
# Project Rules
## Build & Test
- Install: `pnpm install`
- Dev: `pnpm dev`
- Test: `pnpm test`
- Lint: `pnpm lint`
## Coding Standards
- Prefer TypeScript strict mode
- Do not introduce new state libraries
- Reuse existing UI primitives in `src/components/ui`
## Workflow
- For changes larger than 3 files, propose a plan first
- Run relevant tests before finishing
- Do not modify `.env*` files
别把这个文件当装饰。
它本质上是在定义：AI 进入你这个项目以后，应该怎么工作。
Claude Code 提供不同权限模式，这不是“高级模式选择器”，而是风险控制手段。
比较稳妥的做法是：
plan一句话：
高权限不是能力的体现，而是责任的放大。
专业团队做风险控制，不会靠“你别乱动哈”这种方式。
更可靠的做法，是把敏感资源明确写进 deny 规则里，比如：
.env例如：
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Bash(curl:*)"
]
}
}
能制度化的，就不要口头化。
很多团队的问题不是 Agent 不够强，而是每次都从头来。
你真正高频做的事情其实很有限，比如：
这类事情不要永远依赖“临场 prompt 发挥”，而应该尽量沉淀成 skill 或固定流程。
这样做有几个好处：
看到 MCP 很容易兴奋，觉得什么系统都能连一下。
但真正应该接入的，不是“能接”的系统，而是接进来后能显著提高判断质量的系统。
一个比较务实的优先级大概是：
判断标准始终只有一个：
它能不能让 Claude 的决策更靠谱。
很多人把 Claude Code 用成了“终端里的聊天工具”，这当然也有价值，但其实只发挥了它一部分能力。
Claude Code 真正的潜力，来自下面这些东西的组合：
CLAUDE.md当这些东西开始组合起来，它就不再只是一个工具，而是工程系统里的一个 Agent 节点。
如果你刚开始接触 Claude Code，我不建议一上来就追求自动化 PR、团队流程接入、复杂技能体系。
更稳的路径是分阶段走。
这一阶段先别急着让它改代码。
多用它来回答这些问题：
这一阶段的目标不是“产出代码”，而是快速建立项目地图。
到这一步，可以让它做一些边界清晰的小任务，比如：
重点不是任务大小，而是学会这几件事：
这一阶段开始做工程化沉淀：
CLAUDE.md这一步很关键。
因为从这里开始，你不再只是“偶尔用一用”，而是在建立可复用的使用基线。
到这一步，再考虑更复杂的东西：
@claude in PR / IssueClaude Code 到这里，才真正从“个人工具”变成“团队流程的一部分”。
再往上走，拼的已经不是谁 prompt 写得花了，而是谁更会设计系统。
你会开始思考这些问题：
走到这一步，你已经不是在“使用 Claude Code”，而是在设计自己的 AI-native 工程工作流。
这里给一个具体一点的场景。
假设现在有一个支付模块 bug，要让 Claude Code 参与处理，我比较建议的流程是三步走。
先让它读相关目录、读测试、看最近改动，要求它先给出判断，不要直接动代码。
例如：
阅读 src/payments、tests/payments 和最近与 payment 相关的改动。
不要直接修改代码，先给我一个三部分计划：
1. 你认为 bug 的最可能根因
2. 最小修复路径
3. 你准备跑哪些测试验证
这样做的目的是先看它有没有把问题理解对。
当计划合理，再让它进入执行阶段：
按你刚才的最小修复路径执行。
要求：
1. 不修改无关文件
2. 跑相关测试
3. 最后给我一份变更说明和风险说明
这一步的核心是把执行范围和交付要求说清楚。
这一步很多人最容易省掉，但我觉得恰恰最值钱。
你要它最后明确交代：
这么做的价值不是形式感，而是能显著提高 review 效率。
这其实是误判。
它更像一个执行速度很快的系统。
规则清晰时它会非常高效，规则缺失时它也会把错误高速放大。
如果团队经验都停留在“某某人有几个好 prompt”，那基本不可能规模化。
真正应该沉淀的不是个人技巧，而是这些东西：
CLAUDE.md比较稳的顺序应该是：
很多团队一开始就冲着“自动修复、自动提 PR”去，最后往往不是失控，就是很快放弃。
Secrets、生产命令、危险脚本、跨目录读取，这些都不该靠提醒来管。
凡是高风险操作，都应该尽量在配置层控制。
真正重要的不是“一小时写了多少代码”，而是：
写得快从来不是唯一目标。
可验证、可维护、可复用，才是工程质量。
这里说三个判断。
它们带有明显的推断性质，但我觉得方向已经很清楚了。
如果你把 Claude Code 当前的能力拼在一起看：
CLAUDE.md你会发现它不是在做一个“更好的终端聊天工具”，而是在做一个能被组织管理、能接工程系统、能进入 CI 的工程代理。
这和“帮你写代码”已经不是一个维度的事情了。
过去团队沉淀的资产主要是这些：
未来会多出来一层非常重要的东西：
CLAUDE.md这层资产定义的不是“代码怎么写”，而是：
AI 在这个项目里应该怎么参与工程。
我很看重这件事，因为它很可能会逐步变成新的组织能力差异。
未来真正有竞争力的人，可能不是那个纯粹“敲得最快”的人，而是那个能把下面这些东西组合起来的人：
说白了，未来强开发者的定义会变。
他不只是 coder，也会越来越像一个 AI-native workflow architect。
如果说 Cursor 让 AI 真正进入了 IDE，那么 Claude Code 正在把 AI 继续往前推，推到软件工程主流程里去。
它真正值得研究的，不是“能不能帮你少写几行代码”，而是下面这些问题：
如果这些问题的答案逐渐变成“能”，那 AI Coding 的意义就不再只是局部提效，而是在重构软件工程的执行方式。
这也是为什么我会觉得：
Claude Code 代表的，不是另一个 AI 编程工具，而是 AI 编程进入下一阶段的信号。
