大家好，我是杉森楠。这是我的第 70 篇原创，请多指教。
欢迎来到《 AI 奇奇怪怪产品 No.1000 计划 》。
今天我们来聊聊：
480 万人看过的 Claude Code 方法论
昨天刷 X 的时候，我注意到关注列表里一位影响力很大的 AI 投资人 Allie K. Miller 转推了一篇长文，目前已经有 480 万人看过了，也获得了 13 K 的点赞。
她此前在 AWS 负责机器学习业务，还是在 IBM 带过 AI 团队，她的转发通常都指向一些比较有方向的内容。
这篇文章的作者叫 Eyad。从履历看，是典型的技术老兵：在 Amazon、Disney、Capital One 这样的巨头公司做过 7 年工程，参与过面向百万级用户的系统开发。现在，他是初创公司 Varickai 的 CTO。
为什么在这个时间点聊他？
原因其实很简单：他和我们大多数人一样，每天高强度使用 Claude Code 编程。但在长期实战中，他发现一个现象：很多人，包括不少经验并不浅的程序员，用 AI 写代码的方式，从第一步开始就已经偏了。
不少人觉得 AI 编程“越用越不对劲”“写着写着逻辑就崩”，直觉上会把问题归结为模型不行。但在 Eyad 看来，真正的原因往往不是模型不够聪明，而是人太着急，跳过了本该由人完成的那部分思考。
他把这些踩坑经验整理成了一篇方法论。
下面，我会把其中最核心、也最容易被忽视的几个点拆开来讲，比如
（1）配置 CLAUDE.md：把项目规范和常用命令写进这个文件，让 AI 像老员工一样干活。
（2）警惕上下文性能：模型在占用率达到 30% 时，逻辑能力就开始变差。不要等它彻底报错，要及时清理对话。
（3）使用自动化模式：利用 Headless Mode 让 AI 自动运行测试和修复 Bug。
接下来，我分享下里面的几个重要的观察。
大多数人都犯了一个错：直接动手
你要知道，写下这些经验的人，是在亚马逊、迪士尼和 Capital One 这些巨头公司里摸爬滚打过 7 年的老兵。他写的代码是给几百万人用的，系统要是崩了那是大事故。
现在他自己创业做 CTO，Claude Code 就是他每天干活的工具。
他上来就指出了一个现象：绝大多数人拿到了 AI 工具，第一反应就是“直接开干”。
但这绝对是你能犯的最大的错误。真的，十次有十次，如果你能忍住不直接打字，而是先按下两次 Shift + Tab 进入“计划模式（Plan Mode）”，最后出来的结果绝对比你直接把需求甩给 AI 要强得多。这两者根本就不在一个段位上。
我也知道，有些朋友可能觉得：“我没有那么深厚的架构经验，我不知道怎么规划啊。”
这位老哥给了两条路：
第一，去学。如果你从来不碰架构，那你永远是在给自己设限。
第二，也是更实际的，你可以跟 ChatGPT 或者 Claude 进行深度的对话。你告诉它你想做什么，问它：“在系统设计上我有哪几种选择？”然后你们一来一回，把方案敲定。
记住，是你和 AI 互相提问，不是你单方面下指令。
这个原则适用于所有事。哪怕只是写个邮件总结，或者重构代码，甚至是调试 Bug。在动手之前，先搞清楚你的目标是什么，你手里的信息越多，AI 输出的质量就越好。
这里有个特别重要的概念叫“架构”。在软件工程里，架构不能留有“操作空间”。比如，你不能只说“给我做一个认证系统”。
如果你这么说，AI 就只能瞎猜。
你得这么说：
“用现有的 User 模型构建邮箱/密码认证，把 session 存在 Redis 里，设置 24 小时过期，并且添加中间件保护 /api/protected 下的所有路由。”
连按两次 Shift + Tab，花 5 分钟做计划，能省下你以后好几个小时的调试时间。
给 AI 发一本“员工手册” (CLAUDE.md)
所有人都知道项目里有个叫 CLAUDE.md 的文件。这不是个普通的 Markdown 文件。每次你启动 Claude 的时候，它做的第一件事就是读这个文件，算是给 AI 做“入职培训”。
很多人要么完全无视它，要么往里面塞了一堆垃圾信息。你要知道，Claude 一次只能靠谱地记住大约 150 到 200 条提示词，再多它就开始随机遗忘了。
所以，这个文件要怎么写？
他说：
首先，保持简短。别把这里当成写小说的地方。
其次，要具体。别跟它解释什么是“组件文件夹”，它懂。你要告诉它的是那些只有你知道的怪癖，比如那些必须运行的 Bash 命令，或者你独特的工作流。
最关键的一点是：告诉它“为什么”，而不仅仅是“做什么”。在这点上，Claude 特别像人。比如，你别光说“使用 TypeScript 严格模式”，你要说“使用严格模式，因为我们在生产环境里被隐式 any 类型导致的 Bug 坑过”。有了这个背景，Claude 就能在遇到类似情况时，做出你意想不到的准确判断。
还有，这个文件是活的。
你在工作的时候，如果发现某个事你得纠正 Claude 两次，那就按下 # 键，把它加到 CLAUDE.md 里去。
好的 CLAUDE.md 看起来不像是一本员工 SOP 手册，它更像是：如果你知道明天自己会失忆，你会留给自己的那张最重要的便签。
上下文窗口只有“30%”
现在的模型，比如 Opus 4.5，号称有 20 万 token 的上下文窗口。但这位 CTO 说：千万别以为它能一直撑到 100% 还保持清醒。
实际上，当上下文用到 20% 到 40% 的时候，它就开始退化了。虽然可能一开始不明显，但输出质量确实在下降。
如果你这时候用 /compact 命令去压缩上下文，你会发现出来的结果依然很烂，因为压缩并不能把已经“变傻的脑子”救回来。
那么，怎么避免这种“痴呆”的情况呢？
第一，别在一个会话里干杂活。一个对话只干一件事。别一会儿让它写认证系统，一会儿又让它去重构数据库。这会让上下文混在一起，Claude 会懵逼的。
第二，用“外脑”。如果你在干复杂的任务，让 Claude 把计划和进度写进一个实际的文件里（比如 SCRATCHPAD.md）。这样即使你关了对话，明天回来，它也能读文件接上进度。
第三，也是他最常用的一个：“复制粘贴重置法”。当发现上下文太长、AI 开始胡说八道时，直接从终端里复制所有重要的内容，运行 /compact 拿到摘要，然后 /clear 彻底清空记忆，再把摘要粘贴回去。
一个全新的、清醒的 AI，绝对比一个在这个混乱的上下文里的 AI 要好用得多。
记住一点：Claude 是“无状态”的。除了你明确给它的东西，它什么都记不住。你得按这个逻辑去规划你的工作。
提示词就是一切，别怪模型烂
人们愿意花几周去学一个新的框架，却不愿意花几分钟学学怎么跟 AI 说话。提示词工程真不是什么玄学，它就是最基本的沟通。就像跟人说话一样，清晰永远比模糊好。
你要明确你想要什么。给它一个清晰的目标，而不是一个模糊的方向。
同样重要的是，你要告诉它“不要做什么”。特别是 Claude 4.5，它有个毛病就是喜欢过度设计（Overengineer）。如果你只是想写个简单的功能，它可能会给你整出 12 个文件、一堆不必要的搞抽象行为。
这时候你就得明确告诉它：“保持简单。别加我没要的抽象行为。能用一个文件解决就别用两个。”
还要给它关于“为什么”的上下文。
告诉它“这个代码我们需要跑得飞快”，或者“这只是个原型，用完就扔”。这会完全改变它写代码时的权衡取舍。
如果你发现输出的代码很烂，那就认清现实：通常是因为你的输入很烂。不要怪模型不够聪明，瓶颈几乎总是源于人这边的原因。
说到模型，他给出了省钱又高效的搭配：Opus 虽然慢且贵，但它逻辑强，适合做规划、做架构决策。Sonnet 又快又便宜，适合干脏活、累活。
所以高效的工作流是：先用 Opus 思考和规划，然后按 Shift+Tab 切换到 Sonnet 去写具体代码。因为有 CLAUDE.md 兜底，它们能配合得很好。
要把工具用到极致 (MCP & Hooks)
Claude 有一堆功能：MCP、Hooks、自定义命令……如果你买了 Pro Max 会员，却不用这些，那真是在浪费钱。
MCP 绝对要用。
如果你发现自己老是从 Slack、GitHub 或者数据库里复制东西给 Claude 看，那你该找个 MCP 工具了。它可以让 Claude 直接连上这些服务，自动获取数据。
Hooks 是防止技术债的好工具。
你可以设置一个钩子，让 Claude 在修改任何文件前后，自动运行一下代码。比如，想让它每次写完代码都跑一遍 Prettier 格式化？或者跑一遍类型检查？用 Hook。
这样能立刻发现错误，而不是等代码堆积如山了再改。
自定义命令，也要用。
如果你经常干某件事，比如调试、部署，你就把那一长串提示词写进一个 markdown 文件，放到 .claude/commands 文件夹里。以后你只要输入 /debug，它就自动按你的套路干活了。
还有，别因为第一次尝试不好用就放弃。
这些模型进化得太快了，上个月不行的功能，这个月可能就修好了。保持好奇心，多做实验。
当它卡住的时候，千万别硬顶
有时候，你肯定遇到过这种情况：Claude 陷入了死循环，写出来的代码报错，它改了，又报错，再改，还是那个错。
这时候，你的本能可能是继续给它解释、继续给提示词。但这时候停下来才是对的。
直接 /clear，清空重来。积累的错误上下文只会让它越来越笨。
如果它在复杂的任务上卡住了，把任务拆小。分块解决。
如果它总是听不懂你想要什么，就别解释了，直接动手写一个最小化的例子给它看：“我就要输出成这个样子的。”
Claude 模仿例子的能力，远比理解那些篇幅很长解释要强得多。
或者换个角度。如果你一直让它“处理这些状态转换”，它搞不定，那你试着说“把这个当成一个状态机来实现”。
换个框架，往往就能解决问题。
不要只做一次性任务，要构建系统
真正的高手，不仅仅是用 Claude 聊聊天、写写代码片段。他们是在构建系统。
Claude Code 有一个参数叫 -p，也就是 headless mode。这意味着你可以写脚本，让 Claude 在后台默默地干活，根本不需要你盯着。
你可以把输出结果传给其他工具，或者连上 Bash 命令。
现在很多企业就在利用这一点：自动审查代码 PR，自动回复简单的技术工单，自动更新文档。这些操作都会被记录下来，你可以回头检查日志，发现哪儿做得不好，就去改 CLAUDE.md 或者调整工具。
这就形成了一个“飞轮效应”：
AI 犯错 -> 你检查日志 -> 你优化规则 -> 下次 AI 做得更好。
随着时间的推移，这套系统会通过复利效应，变得越来越强大。
回过头看，这篇文章真正有价值的地方，其实不在于哪一个技巧、哪一个命令，而在于它传达了一种非常工程化、也非常克制的 AI 使用观。
这位 CTO 并没有把 Claude Code 当成“全自动程序员”。在他的工作流里，AI 更像是一名能力很强、但需要被清晰管理和持续训练的同事。
你要给它规则、给它上下文、给它反馈机制，甚至要为它设计“犯错后的纠偏路径”。
一次性的成功没有意义，能被复用、能持续变好的工作方式，才是真正的效率提升。
如果你读完这篇文章，只记住了一点，那可能就是这句话：AI 写代码的上限，几乎永远取决于你是否愿意先把事情想清楚。
工具在变，模型在变，但这个原则大概率不会变。
看到这里，辛苦啦。
感谢你的阅读和「在场」！
文章来自于微信公众号 “AI Humanist by杉森楠”，作者 “AI Humanist by杉森楠”