---
title: "小白刚学Claude Code，但开发复杂功能总是返工，有没有成熟的工作流程？ - 杞鋂 的回答"
source: "https://www.zhihu.com/question/1985963602264495442/answer/1986014743077610180"
author:
  - "[[杞鋂​软件开发行业 经营者​ 关注]]"
  - "[[陈佬昔AI编程老司机​ 关注]]"
  - "[[大柳]]"
published:
created: 2026-01-07
description: "Claude Code最好的工作流程，是建基于你会否用「上下文管理」。之前用Claude Code老是掉链子，动不动就开…"
tags:
  - "clippings"
---
Claude Code最好的工作流程，是建基于你会否用「[上下文管理](https://zhida.zhihu.com/search?content_id=761978789&content_type=Answer&match_order=1&q=%E4%B8%8A%E4%B8%8B%E6%96%87%E7%AE%A1%E7%90%86&zhida_source=entity)」。

之前用Claude Code老是掉链子，动不动就开始胡说八道，我还以为是模型不行。

而问题根本不在AI，在你塞给它的上下文太乱了。

这话听着扎心，但确实是这么回事。

你要搞工作流程，你就得会这两点：

第一，上下文工程——别把什么乱七八糟的东西都往Claude嘴里塞，60%是红线，超了就开始出幺蛾子。

第二，[四阶段工作流](https://zhida.zhihu.com/search?content_id=761978789&content_type=Answer&match_order=1&q=%E5%9B%9B%E9%98%B6%E6%AE%B5%E5%B7%A5%E4%BD%9C%E6%B5%81&zhida_source=entity)——[Research、Plan、Implement、Validate](https://zhida.zhihu.com/search?content_id=761978789&content_type=Answer&match_order=1&q=Research%E3%80%81Plan%E3%80%81Implement%E3%80%81Validate&zhida_source=entity)，一步一步来，每步完事儿清一次上下文，别想着一口吃成胖子。

![](https://picx.zhimg.com/50/v2-726bc79bb0d90bb60bbebda253cd1dd7_720w.jpg?source=2c26e567)

听起来简单对吧？

但我敢打赌，99%的人（包括之前的我）都在瞎搞。

### 上下文这玩意儿，真不是越多越好

你塞得越多，Claude Code 越懵。

这跟我们的直觉完全相反啊！

我之前的操作是什么？疯狂@文件，恨不得把整个项目都喂进去，觉得"信息越全面回答越准确"。

结果呢？95%的上下文容量，一堆半成品代码，Claude开始车轱辘话来回说。

所以想要干精活，出高质，就得卡死60%这条线，用/context命令随时监控：

![](https://pic1.zhimg.com/50/v2-03832bc470f519aaf2da651868558a17_720w.jpg?source=2c26e567)

我每次新开会话，光是[CLAUDE.md](https://zhida.zhihu.com/search?content_id=761978789&content_type=Answer&match_order=1&q=CLAUDE.md&zhida_source=entity)、[mcp tools](https://zhida.zhihu.com/search?content_id=761978789&content_type=Answer&match_order=1&q=mcp+tools&zhida_source=entity)、Custom Agents这些系统组件就已经占掉32%了。

也就是说，你真正能用来干活的空间其实只有28%左右，大概56k tokens的样子。

我之前完全没意识到这个问题，难怪老翻车。

### 四阶段工作流，说白了就是"分而治之"

我刷了很多大佬的经验，基本上可以这样做，把整个开发流程拆成四块，每块干完就清上下文：

![](https://picx.zhimg.com/50/v2-40a16adb8ac7721b190490e140ab016b_720w.jpg?source=2c26e567)

打开终端，cd到你的项目根目录，具体操作，就是：

![](https://pic1.zhimg.com/50/v2-c2c925dcfae68b7cd64f61c017677b12_720w.jpg?source=2c26e567)

生成后，得检查一下生成目录是否正确：

![](https://pic1.zhimg.com/50/v2-50b8633de835c2fb0c1eea417ab5571b_720w.jpg?source=2c26e567)

Claude Code的自定义命令是这样工作的：

![](https://pic1.zhimg.com/50/v2-a95950832432a71f77736c042b6add53_720w.jpg?source=2c26e567)

现在我们要做的就是写好这四个md文件，让Claude知道每个阶段该干什么。

也就是挟MD以令Claude Code……

一步一步来，既要明白思路，也要知道怎样操作。

本文只教小白能懂的Prompt方法，还可以用MCP或者其他方法来实现，会在后续教程「泄露」。

### Research阶段：先搞清楚现状，别急着写代码

要知道Coder的铁律：能不Code，就不Code。

因为不写Code，就没有Bug。

你得搞清楚现有代码库是怎么回事。

直接搞四个并行的子代理同时干活：

![](https://picx.zhimg.com/50/v2-07d42765f440e65280f18297cafa62e0_720w.jpg?source=2c26e567)

四个代理同时跑，最后汇总出一份研究文档，里面必须有这几样东西：发现摘要、带file:line编号的代码引用（特别强调）、架构洞察、还有待澄清的问题。

关键是那个file:line编号，后面Plan阶段直接引用这些位置，省得再去定位代码浪费上下文。

具体的操作Prompt：

在`.claude/commands/`下创建`research_codebase.md`：

![](https://pic1.zhimg.com/50/v2-70222dc5689fbb1d076476068e76c809_720w.jpg?source=2c26e567)

直接启动讨论研究：

![](https://pic1.zhimg.com/50/v2-ac0a5941cb02b7c408ac5c8c2ca5fb50_720w.jpg?source=2c26e567)

接下来Claude就会搜索项目中与认证相关的文件，分析现有认证流程，还得检查[thoughts/目录](https://zhida.zhihu.com/search?content_id=761978789&content_type=Answer&match_order=1&q=thoughts%2F%E7%9B%AE%E5%BD%95&zhida_source=entity)有没有相关研究，接着会生成研究文档保存到 `thoughts/shared/research/2025-01-15_oauth2-authentication.md`。

你別以为自己就可以闲着玩手机游戏，你得回答Claude的问题（澄清问题），还得确认研究发现是否准确，不行就得继续深入讨论，还要时不时检查上下文占用（/context），如果超过60%，执行 /clear……

还有在研究当中，很容易遇到的就是聊多了，聊得太多，导致项目已经很大了，研究阶段上下文就会爆！

所以得分多次研究，每次聚焦一个子问题：

![](https://pica.zhimg.com/50/v2-bbe3cbf6360964663d7c38403e2a36e8_720w.jpg?source=2c26e567)

后面再整合成一个文档或多个文档。

**Plan阶段：迭代五次以上，别嫌烦**

我之前做计划基本就是让Claude出一版就开干，结果经常返修。

想不返修，就至少迭代五次，因为事不过三。

本来三次应该够。

但：剪不断，理还乱，是离愁。别是一般滋味在心头。

这个度很难，而5-6次，就是这个黄金分割点。

没得解释，就是人机协助的最佳的检测结果，搞了7次以上，又累效果提升不大。

搞个三次，效果中中，但是与5-6次的差距很大。

![](https://picx.zhimg.com/50/v2-8dc051684ff1c2bace142d595613584b_720w.jpg?source=2c26e567)

基本上花个30-45分钟在计划上，別以为浪费时间。

修个Bug，都是半天以上……

计划文档里要有六样东西：清晰的阶段划分、精确的文件路径、代码片段、自动验证命令、手动验证项、成功标准。可以喵喵这个[BrowserContext](https://zhida.zhihu.com/search?content_id=761978789&content_type=Answer&match_order=1&q=BrowserContext&zhida_source=entity)的例子：

![](https://picx.zhimg.com/50/v2-482b125001837689f33977f015bd9637_720w.jpg?source=2c26e567)

配套的验证标准：

![](https://picx.zhimg.com/50/v2-142db6e635c35a4f55fb875da68babaf_720w.jpg?source=2c26e567)

有了这个，实现的时候就不用再去想"我要改哪个文件""怎么验证对不对"这些事了。

在`.claude/commands/`下创建`create_plan.md`：

![](https://picx.zhimg.com/50/v2-6f441ea02a70d3c72d7a9ed09a020cdc_720w.jpg?source=2c26e567)

一个不小心就启动，并继续之前研究的方案：

![](https://pica.zhimg.com/50/v2-a8928c31a692ceef89d9704f4c9dbaae_720w.jpg?source=2c26e567)

讨论基本就是这样的：

![](https://picx.zhimg.com/50/v2-ae518b18ef2929b237635e53f1e0f770_720w.jpg?source=2c26e567)

讨论完成后就会生成MD文件（thoughts/shared/plans/2025-01-15-google-oauth2.md）。

到了这里，基本上都明白了，这是用MD文件来保存CLaude Code中容易流失的胶原蛋白（上下文）。

### Implement阶段：一次只干一个Phase

不要让CC直接大干特干，而是一个一个地干。

尽管CC自己也有一个Todo，但此Todo不能彼Todo。

你得人机互验相证。

看看有没有猿人相轻，CC看不爽你吖！

团队都不能给你好Code，你不可能指望CC给你好Code。

单阶段执行，干完Phase 1确认没问题再干Phase 2。

![](https://pic1.zhimg.com/50/v2-95963760897ecbf20db090323fb3ca31_720w.jpg?source=2c26e567)

为啥不能一口气全实现完？

因为如果Phase 1有bug，等你做完Phase 4才发现，前面的工作全白费。

一个阶段一个阶段来，问题暴露得早，改起来成本低。

具体操作就在`.claude/commands/`下创建`implement_plan.md`：

![](https://pic1.zhimg.com/50/v2-606ec11be268befad60afdfb30f24e84_720w.jpg?source=2c26e567)

启动命令：

![](https://pica.zhimg.com/50/v2-2be5a17c1c26f8b1e3765c8fab6cebc5_720w.jpg?source=2c26e567)

Claude Code就会读取计划，定位Phase 1来确认变更范围，还得逐个文件执行变更，并运行自动验证，到最后一步就提示你要手动验证。

这一步，你可能要盯很久，这时你就可以玩把英雄连萌，或者学会多邻狗，又或者打一把KOF狗爸。

![](https://pica.zhimg.com/50/v2-cb0b5c1f679ae4c34d9f40ade3b70295_720w.jpg?source=2c26e567)

玩完也就到你出场了，执行一下手动验证，检查一下，并反馈结果给Claude，还/context来检查上下文，决定是否/clear！

不过这里得小心，很经常我是上下文超了但Phase没做完，直接执行 /clear，然后重新加载计划文档继续，因为进度记录在计划文档里，不在上下文里。

![](https://picx.zhimg.com/50/v2-efd1c57fe9f9a18ac83d10f8de69f1fc_720w.jpg?source=2c26e567)

### Validate阶段：安全网，不能省

验证阶段会出一份报告，包含四类内容：

![](https://picx.zhimg.com/50/v2-e8046d563e356ce166da53eea6124370_720w.jpg?source=2c26e567)

这步是安全网，确保发布前没有遗漏。

具体操作，在`.claude/commands/`下创建`validate_plan.md`：

![](https://pica.zhimg.com/50/v2-4b6fce30824a6dcf53c2001892499a51_720w.jpg?source=2c26e567)

启动也一样：

![](https://pic1.zhimg.com/50/v2-676d324eca0c7f6dbf5d1924680691ad_720w.jpg?source=2c26e567)

Claude code就会逐Phase对比计划和实际代码，还会运行所有验证命令，生成完整验证报告。

你就有一份详细的验证报告，告诉你哪些做对了、哪些有偏差、哪些需要修复。

接下来，你就重复重复又重复地精修你的项目。

最后得讲讲thoughts。

### thoughts/目录：上下文外的"外挂记忆"

整个工作流最精髓的设计是这个thoughts/目录。

每个阶段产出的文档都存在这里：

![](https://pic1.zhimg.com/50/v2-a8a359496c96068e1941509b5ac28437_720w.jpg?source=2c26e567)

用npx humanlayer thoughts init就能初始化这个结构。

这玩意儿厉害在哪？

持久记忆。

清理上下文不会丢东西，研究发现和计划都在文件里存着。

团队共享。

sym-link可以跨仓库，团队里其他人也能用你整理的文档。

可以把thoughts/目录用软链接指向共享存储：

![](https://picx.zhimg.com/50/v2-c82ee4f1058647628d89313d997635ca_720w.jpg?source=2c26e567)

或者直接把thoughts/加入git版本控制。

审计轨迹。

几个月后回来看，还能知道当时为啥这么设计。

这相当于是一个妈，三个女人：亲母、养母、干妈……

这个目录可以全局共享，“everyone on your team + org have access”。

等于是把Claude的"短期记忆"问题用文件系统给hack掉了。

所以跟AI协作不是问问题的艺术，是工程化管理上下文的技术。

总之，每次调用Claude，你都在往它的"工作内存"里装东西。

就像你不会为了改一个函数去编译整个代码库一样，也不该为了实现一个功能把整个项目历史都塞进去。

![](https://picx.zhimg.com/50/v2-f04d024ce6b381eaa82ccb697c1dca47_720w.jpg?source=2c26e567)

每个阶段目标明确，产出文件制品，然后清理上下文开始下一轮。

这不就是把软件工程那套"模块化、低耦合"的思想用到了人机协作上吗？

用CC想要高质得严Context60%……

上下文管理：时刻盯着/context，超60%就清理，用文件引用代替内存保持。

研究阶段：即使你觉得自己熟悉代码库也要跑一遍研究，总会发现遗漏的边缘案例。

计划阶段：迭代次数不要省，30-45分钟的计划投入能省掉几小时的返工。

验证：自动测试管代码层面的问题，手动测试管UX和性能，两个都不能少。

thoughts目录:每份研究、计划、笔记都往里扔，未来的自己会感谢现在的自己。

上下文管理才是决定输出质量的关键变量。

另外，有兴趣的可以去下载humanlayer的.claude/commands和.claude/agents，花点时间编辑成适合自己代码库的版本很值得。

有关Vibe coding以及Claude Code的使用技巧可关注专栏：[coder≥Vibe coder码造万物](https://www.zhihu.com/column/c_1989850526460966217)

参考资源

[Effective context engineering for AI agents](https://link.zhihu.com/?target=https%3A//www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

[https://github.com/humanlayer/h](https://link.zhihu.com/?target=https%3A//github.com/humanlayer/humanlayer)