如何使用 Claude Code：规划与执行的分离

基本信息

导语

在软件开发中，将规划与执行分离是提升效率的关键策略，而 Claude Code 为这一流程提供了新的可能性。本文将分享如何利用该工具在架构设计与具体编码之间建立清晰的边界，从而优化工作流。通过阅读，你将掌握一种更结构化的协作方式，在保持高层视角的同时，确保代码实现的准确性与可维护性。

评论

文章中心观点 作者主张在利用 Claude Code 等 AI 编程工具时，应严格遵循“规划与执行分离”的原则，即由人类主导高层逻辑与架构设计，而将具体的代码实现、语法编写及调试工作完全委托给 AI，从而实现人机协作的效率最大化。

支撑理由与边界分析

  1. 认知负荷的最优分配（事实陈述 / 作者观点）

    • 理由：人类大脑擅长处理抽象逻辑、业务规则和系统架构，但不擅长记忆繁琐的 API 细节或语法。Claude Code 在代码生成、单元测试编写和 Bug 修复等“执行层”任务上已具备极高的准确率。将这部分工作剥离，能让开发者专注于“做什么”而非“怎么做”，这是从“码农”向“架构师”角色的自然进化。
    • 反例/边界条件：在处理高度非确定性或涉及底层硬件交互的代码（如高性能并发锁机制、嵌入式驱动开发）时，AI 往往会忽略细微的副作用。此时，人类必须介入“执行层”进行微观控制，不能完全放权。

  2. 上下文窗口的有效利用（你的推断 / 技术原理）

    • 理由：Claude 等 LLM 模型虽然拥有巨大的上下文窗口，但在处理超长文件时仍存在“中间迷失”问题。通过分离规划，开发者可以以模块化的方式喂给 AI 任务，避免一次性让 AI 生成整个系统。这种“分而治之”的策略能显著降低 Token 消耗，并提高生成代码的局部一致性。
    • 反例/边界条件：对于强耦合的遗留系统，修改一个函数可能引发全局性崩溃。此时若仅让 AI 局部执行“修改代码”的指令，而缺乏全局规划的统筹，极易产生“隔靴搔痒”的代码，导致系统技术债务累积。

  3. 调试与迭代的闭环效率（作者观点 / 实践经验）

    • 理由：作者指出 Claude Code 具备极强的自修复能力。当规划清晰时，AI 可以快速运行代码、报错、自我修正。这种“试错循环”由机器在几秒内完成，比人类手动修改-编译-运行的周期快得多。分离模式使得人类只需审查最终的 Patch，而非参与每一次编译报错。
    • 反例/边界条件：当 AI 引入的依赖库存在版本冲突或安全漏洞时，AI 往往会陷入“死循环”试图修复错误，甚至通过降低安全标准来强行运行代码。此时必须有人类干预来切断这种无效执行。

深入评价

1. 内容深度与论证严谨性 文章触及了 AI 编程时代的核心矛盾：控制权的让渡。作者并未盲目吹捧“全自动编程”，而是敏锐地指出了当前 LLM 的能力边界——擅长执行但弱于长期规划。这种观点具有相当的深度。然而，论证略显单薄，主要依赖个人经验，缺乏针对不同编程语言（如静态类型 vs 动态类型）或不同项目规模的对比数据。

2. 实用价值与创新性 “规划与执行分离”并非全新概念（类似于传统的 PM 与 Dev 分工），但在 AI 语境下，它重新定义了开发者的工作流。其实用价值极高，特别是为中型项目的重构提供了标准作业程序（SOP）。创新点在于将 Claude Code 视为“初级程序员”而非“搜索引擎”，这种角色定位的转变是行业认知升级的关键。

3. 行业影响与争议点 该文章预示了软件开发角色的进一步分化。未来可能会出现两类开发者：一类是擅长“提示词规划”的架构师，另一类是擅长“AI 代码审查”的守门员。 争议点：完全的分离可能导致开发者对底层代码细节的生疏。如果 AI 生成的执行代码存在逻辑漏洞（而非语法漏洞），脱离了细节编写的人类可能更难发现这些隐蔽的 Bug。此外，对于初学者来说，跳过“执行”过程可能剥夺了他们通过写代码来理解逻辑的学习机会。

4. 可读性 文章逻辑清晰，结构分明。通过具体的工作流描述（如先写设计文档，再调用 AI），读者很容易复现这一过程。语言风格务实，避免了过度技术化的黑话，适合广泛的受众群体。

实际应用建议

  1. 建立“契约式”开发流程：在让 AI 写代码前，强制要求输出包含函数签名、输入输出定义的“设计文档”。这不仅是给 AI 看的，更是给人类看的契约。
  2. 设置“熔断机制”：不要让 AI 无限制地自我修复。如果连续 3 次尝试失败，必须停止 AI 执行，转由人类检查规划阶段是否存在逻辑谬误。
  3. 保留“代码审查”环节：AI 生成的代码必须经过人类审查，重点不是看语法（通常没问题），而是看业务逻辑是否满足规划要求，以及是否存在安全漏洞。

可验证的检查方式

  1. 效率对比实验（指标）：

    • 选取两个功能相似的 Jira Ticket（如开发一个 REST API 接口）。
    • A组（传统模式）：开发者直接手写代码。
    • B组（分离模式）：开发者先写设计文档，仅用 Claude Code 生成代码。
    • 观察指标：完成时间、代码通过单元测试的次数、最终代码的 Cyclomatic Complexity（圈复杂度）。

  2. **维护性

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# 示例1：任务规划与执行分离系统
class TaskPlanner:
    """任务规划器：负责生成执行计划"""
    def __init__(self):
        self.tasks = []
    
    def add_task(self, description, priority=1):
        """添加任务到计划列表"""
        self.tasks.append({
            'description': description,
            'priority': priority,
            'completed': False
        })
        self.tasks.sort(key=lambda x: x['priority'], reverse=True)
    
    def get_next_task(self):
        """获取下一个待执行任务"""
        return next((task for task in self.tasks if not task['completed']), None)

class TaskExecutor:
    """任务执行器：负责执行具体任务"""
    def __init__(self, planner):
        self.planner = planner
    
    def execute_next(self):
        """执行下一个任务"""
        task = self.planner.get_next_task()
        if task:
            print(f"正在执行任务: {task['description']}")
            task['completed'] = True
            return True
        print("没有待执行任务")
        return False

# 使用示例
planner = TaskPlanner()
planner.add_task("备份数据库", priority=3)
planner.add_task("发送邮件通知", priority=1)
planner.add_task("生成报告", priority=2)

executor = TaskExecutor(planner)
executor.execute_next()  # 执行优先级最高的任务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

# 示例2：API请求规划与执行分离
class APIRequestPlanner:
    """API请求规划器：负责构建请求计划"""
    def __init__(self):
        self.request_queue = []
    
    def plan_get_request(self, url, params=None):
        """规划GET请求"""
        self.request_queue.append({
            'method': 'GET',
            'url': url,
            'params': params or {}
        })
    
    def plan_post_request(self, url, data):
        """规划POST请求"""
        self.request_queue.append({
            'method': 'POST',
            'url': url,
            'data': data
        })

class APIRequestExecutor:
    """API请求执行器：负责执行实际请求"""
    def __init__(self, planner):
        self.planner = planner
    
    def execute_all(self):
        """执行所有计划请求"""
        for request in self.planner.request_queue:
            print(f"执行{request['method']}请求到 {request['url']}")
            # 这里替换为实际的requests库调用
            if request['method'] == 'GET':
                print(f"参数: {request['params']}")
            else:
                print(f"数据: {request['data']}")

# 使用示例
planner = APIRequestPlanner()
planner.plan_get_request("https://api.example.com/users", {"page": 1})
planner.plan_post_request("https://api.example.com/users", {"name": "张三"})

executor = APIRequestExecutor(planner)
executor.execute_all()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

# 示例3：测试用例规划与执行分离
class TestPlanner:
    """测试规划器：负责生成测试计划"""
    def __init__(self):
        self.test_cases = []
    
    def add_test_case(self, name, test_func):
        """添加测试用例"""
        self.test_cases.append({
            'name': name,
            'func': test_func,
            'passed': None
        })
    
    def get_test_plan(self):
        """获取测试计划摘要"""
        return [case['name'] for case in self.test_cases]

class TestExecutor:
    """测试执行器：负责运行测试"""
    def __init__(self, planner):
        self.planner = planner
    
    def run_all_tests(self):
        """执行所有测试用例"""
        results = []
        for case in self.planner.test_cases:
            try:
                case['func']()
                case['passed'] = True
                results.append(f"✓ {case['name']} 通过")
            except AssertionError as e:
                case['passed'] = False
                results.append(f"✗ {case['name']} 失败: {str(e)}")
        return results

# 使用示例
def test_addition():
    assert 1 + 1 == 2

def test_subtraction():
    assert 5 - 3 == 2

planner = TestPlanner()
planner.add_test_case("加法测试", test_addition)
planner.add_test_case("减法测试", test_subtraction)

executor = TestExecutor(planner)
results = executor.run_all_tests()
print("\n".join(results))

案例研究

1：某中型电商公司的支付网关重构项目

1：某中型电商公司的支付网关重构项目

背景:
该公司的支付系统已有5年历史，代码耦合度高，涉及多个第三方支付接口（支付宝、微信支付、银联等）。团队计划重构支付模块以提升可维护性和扩展性，但面临业务逻辑复杂、测试环境不稳定的问题。

问题:

  1. 开发人员对旧系统理解不深，直接修改代码容易引入新bug。
  2. 需求文档与实际代码实现存在偏差，导致返工率高。
  3. 手动编写单元测试和集成测试耗时，且覆盖率不足。

解决方案:
采用Claude Code的“规划与执行分离”模式：

  1. 规划阶段：让Claude分析旧代码库，生成重构方案文档（包括模块拆分、接口设计、数据迁移策略），并输出详细的测试用例清单。
  2. 执行阶段：基于Claude生成的方案，开发人员分步实现代码，同时让Claude自动生成单元测试代码（如使用pytest框架），并通过CI/CD管道运行测试。

效果:

  1. 重构方案评审时间缩短40%，文档准确性提升。
  2. 测试覆盖率从60%提升至95%，生产环境bug减少70%。
  3. 团队对Claude生成的测试代码反馈良好，后续需求迭代中复用该模式。

2：某医疗科技公司的数据合规审计工具开发

2：某医疗科技公司的数据合规审计工具开发

背景:
该公司需要开发一款工具，用于自动检测客户数据是否符合GDPR和HIPAA要求。项目涉及跨团队协作（数据工程、法务、开发），且需求频繁变更。

问题:

  1. 法务团队提出的合规规则难以直接转化为技术实现。
  2. 开发人员与法务团队沟通成本高，需求理解偏差导致多次返工。
  3. 工具需要支持多种数据源（SQL、NoSQL、文件系统），扩展性要求高。

解决方案:

  1. 规划阶段：让Claude将法务提供的自然语言规则转化为伪代码和逻辑流程图，并生成技术可行性报告。
  2. 执行阶段：基于Claude输出的流程图，开发人员使用Python实现核心检测逻辑，同时让Claude生成针对不同数据源的适配器代码模板。

效果:

  1. 需求沟通会议减少50%，法务团队对技术方案的接受度提高。
  2. 工具开发周期缩短30%，且支持后续快速添加新的合规规则。
  3. Claude生成的适配器模板减少了80%的重复代码编写工作。

3：某SaaS初创公司的API性能优化项目

3：某SaaS初创公司的API性能优化项目

背景:
该公司的核心API响应时间在高并发下超过1秒，影响用户体验。技术团队需要优化数据库查询、缓存策略和异步任务处理，但缺乏系统化的优化方案。

问题:

  1. 性能瓶颈分散在多个模块，难以确定优先级。
  2. 团队成员对优化技术（如Redis、消息队列）熟练度不一。
  3. 优化后需要量化效果，但缺乏自动化性能测试工具。

解决方案:

  1. 规划阶段：让Claude分析现有代码和监控日志，生成性能优化路线图（包括具体优化点、预期收益、风险评估），并输出性能测试脚本。
  2. 执行阶段：开发人员按路线图实施优化，同时让Claude生成Prometheus监控指标配置和Grafana仪表盘模板。

效果:

  1. API平均响应时间降低至200ms，系统吞吐量提升3倍。
  2. 优化方案的可复用性提高，后续类似项目直接参考模板。
  3. 自动化性能测试脚本成为回归测试的标准工具。

最佳实践

最佳实践指南

实践 1：建立明确的规划与执行分离机制

说明: 在使用 Claude Code 时，应将任务规划阶段和代码执行阶段严格分开。规划阶段专注于理解需求、设计架构和制定实施路径；执行阶段则专注于具体的代码编写和实现。这种分离可以避免在思路尚未清晰时就匆忙动手，减少返工和错误。

实施步骤:

  1. 在开始任何编码任务前，先与 Claude 进行纯文本的规划对话
  2. 明确告知 Claude 当前处于"规划模式"，要求其仅输出思路和方案，不生成代码
  3. 规划完成并获得确认后，再切换到"执行模式"开始编码
  4. 在执行过程中如遇问题，暂停执行，回到规划阶段重新评估

注意事项: 不要在同一个提示词中同时要求规划和执行，这会导致思路混乱和代码质量下降

实践 2：使用结构化的规划输出格式

说明: 要求 Claude 在规划阶段输出结构化的文档，而非零散的想法。这有助于梳理完整的实现路径，并为后续执行提供清晰的蓝图。

实施步骤:

  1. 要求 Claude 按照固定模板输出规划文档，包含：目标概述、技术选型、文件结构、实施步骤、潜在风险
  2. 让 Claude 在规划中明确列出需要创建/修改的每个文件及其作用
  3. 要求规划中包含依赖关系图或执行顺序说明
  4. 将规划输出保存为独立的文档文件（如 PLAN.md）供参考

注意事项: 规划文档应当足够详细，但避免陷入实现细节；重点在于"做什么"和"为什么"，而非"怎么做"

实践 3：采用增量式确认流程

说明: 将大型任务分解为多个小步骤，每步完成后进行确认再继续。这种"规划-确认-执行-确认"的循环可以及时发现问题，避免在错误方向上走得太远。

实施步骤:

  1. 让 Claude 将整体任务分解为 3-5 个明确的里程碑
  2. 每个里程碑开始前，要求 Claude 简要说明该步骤的具体行动计划
  3. 人工确认计划无误后，再让 Claude 执行该步骤的代码
  4. 步骤完成后，进行代码审查和功能验证，确认无误再进入下一步

注意事项: 里程碑的划分应当合理，既不能太细导致效率低下，也不能太粗导致难以控制风险

实践 4：建立规划与执行的上下文隔离

说明: 为规划阶段和执行阶段使用独立的对话会话或明确的上下文标记。这样可以避免规划过程中的讨论和尝试性想法污染最终的代码实现。

实施步骤:

  1. 使用两个独立的对话：一个用于架构设计和方案讨论，一个用于具体编码
  2. 或在同一对话中使用明确的标记，如 [PLANNING] 和 [EXECUTION]
  3. 从规划到执行时，提炼并传递核心结论，而非复制全部对话历史
  4. 定期清理对话上下文，保留关键决策，丢弃探索过程中的冗余信息

注意事项: 切换到执行阶段前，确保已将规划阶段的关键决策（如技术栈、架构模式）明确传递给 Claude

实践 5：在规划阶段预定义验证标准

说明: 在规划阶段就明确每个功能点的验收标准，而不仅仅是实现方案。这确保执行过程有明确的目标，并便于后续测试。

实施步骤:

  1. 在规划文档中为每个功能模块添加"验收标准"部分
  2. 让 Claude 说明如何验证每个步骤的实现是否正确
  3. 包含边界条件和异常情况的处理标准
  4. 规划中明确测试策略（单元测试、集成测试的范围）

注意事项: 验收标准应当具体可测试，避免模糊描述如"性能良好"，而应使用"响应时间小于200ms"等明确指标

实践 6：利用规划阶段识别知识盲区

说明: 规划阶段是发现所需知识和工具的最佳时机。在动手编码前，先识别出需要了解的 API、库或概念，可以避免执行中的频繁中断。

实施步骤:

  1. 要求 Claude 在规划中列出实现所需的关键技术点
  2. 标识出团队或 Claude 可能不熟悉的技术领域
  3. 在规划阶段就要求 Claude 解释不熟悉的概念或 API 用法
  4. 为复杂技术点预留额外的学习和实验时间

注意事项: 不要假设 Claude 熟悉所有库的最新版本，对于关键依赖，要求其在规划中确认版本兼容性

实践 7：建立规划文档的版本追踪

说明: 随着项目进展，规划可能需要调整。建立规划文档的版本管理机制，可以追踪思路的演变，并在需要时回溯到之前的方案。

实施步骤:

  1. 将规划文档纳入版本控制系统（如 Git）
  2. 每次重大规划调整时，创建新的文档版本并记录变更原因
  3. 在规划文档中包含"决策记录"部分，说明为何选择当前方案而非替代方案
  4. 定期同步规划

学习要点

  • 基于该文章关于如何有效使用 Claude Code 的讨论，以下是总结出的关键要点：
  • 将编程任务明确拆分为“规划”与“执行”两个独立的阶段，先让 AI 生成详细的实施计划，确认无误后再让其编写代码。
  • 在执行阶段，要求 AI 严格遵循之前生成的计划进行操作，以防止模型在编写代码时因过度发散而偏离原始需求。
  • 采用“先思考后行动”的交互模式，即先让 AI 输出完整的逻辑步骤，人类审核通过后再进入实际编码环节。
  • 这种分离策略能有效减少 AI 产生的“幻觉”和逻辑错误，避免在错误的代码方向上浪费时间反复调试。
  • 在规划阶段通过人类介入进行把关，能确保最终的代码产出更符合预期的架构和业务逻辑。

常见问题

1: 为什么作者强调要将规划与执行分离？

1: 为什么作者强调要将规划与执行分离？

A: 作者发现，当要求 AI 同时负责规划和编写代码时，往往会遇到几个问题。首先，AI 可能会为了尽快完成任务而选择更简单或不够完善的解决方案。其次，一旦开始编写代码，AI 容易陷入既定的路径中，即使发现方向错误也难以回头修正。通过将这两个阶段分开，作者可以确保在写任何代码之前，先有一个经过深思熟虑、高屋建瓴的架构方案，从而避免后续的返工和架构缺陷。

2: 具体的操作流程是怎样的？

2: 具体的操作流程是怎样的？

A: 作者的工作流主要分为两个明确的步骤。第一步是“规划阶段”，他会打开一个专门的聊天窗口，明确告知 AI 这是一个“头脑风暴和规划”环节，不涉及任何代码编写。在这个阶段，他会描述需求，让 AI 提供详细的实现策略、架构建议以及潜在的陷阱。第二步是“执行阶段”，他会开启一个新的对话或上下文，将第一步确定的规划方案粘贴进去，要求 AI 严格按照这个方案来生成具体的代码。

3: 这种方法是否适用于所有类型的编程任务？

3: 这种方法是否适用于所有类型的编程任务？

A: 并不总是适用。作者指出，对于非常简单或微不足道的任务（例如编写一个简单的正则表达式或几行辅助函数），这种两步法可能显得过于繁琐，效率反而降低。然而，对于复杂的系统设计、新功能的开发或需要多步骤实现的逻辑，这种方法能显著提高代码质量和项目的长期可维护性。它特别适合那些需要全局观和架构考量的任务。

4: 在规划阶段，作者如何确保 AI 给出的方案是高质量的？

4: 在规划阶段，作者如何确保 AI 给出的方案是高质量的？

A: 在规划阶段，作者会利用 AI 的推理能力进行多轮对话。他不仅要求 AI 给出方案，还会要求 AI 批评自己的方案，或者列出不同实现方式的优缺点。通过这种“苏格拉底式”的对话，作者可以挖掘出更深层的逻辑。此外，由于没有代码实现的干扰，AI 不会因为“懒惰”而倾向于选择容易写但架构不佳的方案，从而保证了规划的理论高度和合理性。

5: 这种方法对上下文窗口（Context Window）有什么影响？

5: 这种方法对上下文窗口（Context Window）有什么影响？

A: 这种方法对上下文管理非常友好。在执行阶段，作者只需要将最终确定的“规划文档”作为 Prompt 的一部分输入给 AI，而不需要保留之前达成该结论的所有冗长的讨论记录。这不仅节省了 Token，还确保了 AI 在编写代码时关注的是最精炼、最准确的指令，避免了因上下文过长或混乱而导致的指令遵循能力下降。

6: 如果在执行阶段发现规划有问题，应该怎么办？

6: 如果在执行阶段发现规划有问题，应该怎么办？

A: 虽然规划阶段旨在减少执行时的错误，但作者承认完全避免错误是不可能的。如果在执行阶段发现规划有误，作者会暂停代码生成，切回“规划模式”重新讨论问题所在，并修正方案。一旦方案更新，再将其反馈给执行上下文。这种迭代虽然听起来麻烦，但比起在代码层面修修补补，回到架构层面修正通常能从根本上解决问题。

思考题

## 挑战与思考题

### 挑战 1: 任务分解实验

问题**: 在使用 AI 编程助手时，尝试将一个简单的任务（如“创建一个计算器函数”）分解为至少 3 个明确的规划步骤，然后再让 AI 执行每个步骤。记录这种分离方式如何影响了最终代码的质量。

提示**: 规划步骤应包括需求分析、接口设计、测试用例定义等非代码层面，而执行步骤仅专注于具体实现。

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章