上一篇文章介绍了plan模式的基本使用办法，相比于基本模式，plan能够先通过对话的方式提供你计划书，然后我们再基于计划书进行审核，如果没问题，执行就行。

为了更好的使用claude，还有一种更好的思维方式，那就是谋定而后动。这种方式不局限于plan模式还是基本模式，而是我们想要解决问题的时候的所有方式。

思考->规划->行动

所谓谋定而后动，也就意味着我们做任何偏复杂的事情的时候，需要先思考清楚步骤。

先想清楚要什么：目标
再想办法拆解问题：行动

要做到这个目的，思维模式就需要发生变更，假设我想要使用claude帮你分析和解决一个问题大多数人对claude的提问可能为如下：

我提供你一份日志在xxxx，请你帮我解析错误日志，找出其中的错误，并提供分析报告

如果我们将上述问题拆解，如下提问

将存放在xxx的日志解析为结构化数据
为解析的日志条目聚合到统计信息中
分析统计信息，检测存在异常的状态
将统计的数据和警报格式化为可读的报告

看到区别了没有，对于拆解和未拆解的提示描述，拆解的描述思考了每一步如何做，而未拆解的提示词只表达了自己的基本诉求。

所以说，思考->行动，也就意味着我们要更早做出高层次决策：使用什么技术，项目结构如何，每个功能应该放在哪里，文件应该放哪些文件。尽早做出正确决定非常重要。

原理

claude在处理用户提示词的时候，有一个注意力的概念，一句话提问，claude很难从一句话中获取解析 + 统计 + 检测 + 输出四个关注点，甚至很有可能claude会直接忽略了这些本应该注意到的关注点。

最终无论claude是否注意到这些关注点，它也只会分配很少的能力来处理这些注意力，也就导致每个部分都只做到"刚好能用"。

而拆解后，claude看到的每个子问题，所以自然会在每个子问题中获取全部注意力。例如

单独要求"分析信息"时，Claude 会投入精力专注分析缺陷，找到问题
单独要求"输出报告"时，Claude 会投入精力提供优秀的报告文章

总结

绝大部分时候，claude可以认为是一个很强力的大脑，但它并不是无所不能的神仙，也不是大家肚子里面的蛔虫。如何使用好这个大脑是本文核心想表达的

当我们想要claude给我们解决一个问题，如果我们只提出问题，提出目标，claude可能并没有很好的帮你完成这个问题，你会觉得它也不过如此

如果你提前思考，将解决这个问题的思路，步骤想清楚。然后提供给claude这个无所不能的大脑，让大脑发挥大脑该做的事情，你会发现新大陆。

无plan模式

思考：人
规划：人
行动：AI

plan模式

思考：人
规划：AI
行动：AI

后面我会介绍另一个有用的技巧，那么我们可以做到

思考：AI
规划：AI
行动：AI

演示

下面直接让claude自身举证上述技巧。

以Nginx 日志分析器为例，让claude用 "一次性给完整需求" 和 "拆成 4 个子问题逐步解决" 两种方式让 Claude 实现。拆解后的代码在覆盖率、可维护性、输出质量上全面领先。

测试设计

问题

用 Python 实现一个 Nginx 日志分析器：解析 access log，统计 Top IP，检测异常流量，生成报告。

两种方式

	方式 A：单次提问	方式 B：拆解子问题
Prompt	"Write a Python script that parses Nginx access logs, finds top 10 visitor IPs, detects brute-force login attempts, and prints a summary report."	4 个子问题（见下文）
轮次	1 轮	4 轮

方式 B 的 4 个子问题：

"Parse a single Nginx log line into a structured dataclass"
"Aggregate parsed entries into statistics (IP counts, status codes, path counts)"
"Detect anomalous patterns: brute-force, path scanning, high error rate"
"Format statistics and alerts into a readable report"

测试数据

610 条日志，包含：

500 条正常流量（8 个 IP 随机访问 8 个路径）
30 条暴力破解（45.33.32.156 POST /login，全部 401）
80 条路径扫描（185.220.101.1 访问 80 个不同路径，全部 404）

运行结果对比

方式 A 输出


=== Log Analysis Report ===
Total requests: 610

Top 10 IPs:
  185.220.101.1: 80 requests
  5.6.7.8: 71 requests
  ...

Status codes:
  200: 337
  404: 126
  ...

Suspicious IPs (>10 login attempts):
  45.33.32.156: 30 login attempts

方式 B 输出


               LOG ANALYSIS REPORT
──────────────────────────────────────────────────
Total requests : 610
Total bytes    : 13,022,437
Parse errors   : 0

Top 10 IPs:
  185.220.101.1              80 ( 13.1%)
  5.6.7.8                    71 ( 11.6%)
  ...

Status code distribution:
  200       337  ██████████████████████
  301        35  ██
  ...

Top 10 paths:
  /                                              75
  /api/products                                  71
  ...

──────────────────────────────────────────────────
ALERTS (4)
──────────────────────────────────────────────────
  🔴 [CRITICAL] 45.33.32.156
     Possible brute-force attack: 30 requests to auth endpoints
  🟡 [WARNING] 185.220.101.1
     Possible path/vulnerability scan: 80 distinct paths accessed
  🟡 [WARNING] 185.220.101.1
     High error rate: 80/80 requests returned 4xx/5xx (100%)
  🟡 [WARNING] 45.33.32.156
     High error rate: 30/30 requests returned 4xx/5xx (100%)

逐项对比

1. 功能覆盖度

功能	A（单次）	B（拆解）
解析 IP、method、path、status	✅	✅
解析 User-Agent、Referrer	❌	✅
解析字节数 / 总流量	❌	✅
统计 Top IP	✅	✅（带百分比）
统计 Top path	❌	✅
状态码分布	✅（纯数字）	✅（带可视化柱状图）
检测暴力破解	✅（仅 `/login`）	✅（多个 auth 端点）
检测路径扫描	❌	✅
检测高错误率 IP	❌	✅
告警分级（critical/warning）	❌	✅
报告解析错误数	❌	✅

结论：方式 A 检测到 1 种威胁，方式 B 检测到 3 种。

2. 代码结构

指标	A（单次）	B（拆解）
代码行数	45 行	160 行
函数数量	1 个（`analyze_logs`）	5 个（parse → aggregate → detect → format → compose）
数据结构	裸 dict + Counter	dataclass（`LogEntry`, `Stats`, `Alert`）
类型标注	无	完整
可测试性	需要模拟文件 I/O	每个函数可独立单元测试
耦合度	解析、统计、输出混在一起	每层只依赖上一层的输出

3. 鲁棒性

场景	A	B
格式不匹配的日志行	静默跳过，无感知	计数 `parse_errors`，报告中可见
只检查 `/login`	绕过则漏检	检查 4 个常见 auth 路径
IPv6 日志	正则不匹配，跳过	同样不匹配，但至少报告了错误数
阈值调整	硬编码 `> 10`	函数参数，可配置

4. 输出可读性

方式 A 的输出是纯文本列表，适合 debug。

方式 B 的输出有：

对齐的表格格式
百分比标注
可视化柱状图（████）
告警分级图标（🔴🟡）
分隔线和标题

目录