AI 明明越来越强,为什么我们还是一直在收拾残局?
后来我才发现,AI 越强,就越需要被磨成一把顺手的工具。
我最近越来越强烈地感觉到一件事:
AI 明明已经很强了,但很多人并没有因此真正变强。
我们每天都在用 AI。学习时用它,写文章时用它,做项目时用它,改代码时也用它。它确实能回答问题、生成方案,也能帮我们把很多事情做得更快。
但用得越久,一个问题反而越明显:
AI 很强,不代表我们就能稳定地把事情做好。
很多时候,我们不是不会用 AI,而是太随便地使用 AI。想到什么就问一句,遇到报错就贴一下,想写文章就让它生成一版,想改功能就直接让它动手。
短期看,好像每一步都有结果。时间一长,却会发现自己总是在反复解释、反复返工、反复验证,甚至反复收拾 AI 留下来的残局。
一开始我以为,这是因为 AI 还不够聪明。
后来我也换过更强的模型,用上了当时公认的最顶级的模型。我原本以为,只要模型能力足够强,那些理解错误、越界修改和虚假完成的问题自然就会减少。
结果并没有。
模型确实变强了。它理解代码更快,给出的方案更完整,执行复杂任务的能力也更强。
但它依然可能没理解清楚就开始动手,顺手改掉我没让它碰的地方,再很自信地告诉我:“已经修复完成。”
等我重新运行项目,报错可能还在那里。
我对这件事感受最深的时候,是在用 Claude Code 做项目。
刚开始,我只是想让它帮我把项目做得快一点。遇到 Bug,就把报错贴给它;想加功能,就直接告诉它需求;哪里样式不对,就让它顺手改一下。
任务很小时,这套用法没什么问题。一个文件、一个函数、一个明确的报错,它通常都能处理得不错。
真正的问题,是从项目开始变复杂之后出现的。
我只是让它修一个小问题,它却顺手改了更多文件。这些修改不一定完全错误,甚至有些看起来很合理,但它们根本不在这次任务的范围里。
它给出的方案可能很完整,解释也很自信,可我重新运行项目,报错仍然存在。它说“已经修复完成”,我看到的却是又一轮返工。
前几天刚提醒过的项目规则,打开新会话后,它也可能像一个刚入职的人一样,重新问、重新猜、重新犯差不多的错。
这些事情单独看,好像都不严重。
改多了,可以回滚;没修好,可以继续贴报错;忘了规则,也可以再提醒一次。
真正折磨人的,是它们会反复发生。
同一个项目背景,我讲了一遍又一遍;同一种边界问题,我提醒了一次又一次;同一句“已经修复完成”,我相信了一次,又被现实打回来一次。
时间久了,人真的会被搞得心烦意乱。
明明我是想让 AI 帮我提高效率,结果却花了大量时间检查它有没有跑偏。
我开始怀疑自己。
是不是我需求没说清楚?是不是我不会用 AI?是不是别人用 Claude Code 都很顺,只有我一直在收拾残局?
我也开始怀疑 AI。
它到底是真的理解了,还是只是看起来理解了?它是真的修好了,还是只是很会把“修好了”说得像真的?
后来我慢慢发现,最难受的不是 Claude Code 偶尔犯错,而是我一直在用一种临时、粗糙的方式驱动它。
它很强,但我没有给它稳定的项目背景;它很快,但我没有让它先把方向想清楚;它很主动,但我没有给它清楚的边界;它很自信,但我没有建立真正的验收方式。
问题可能不只是模型够不够强,也和我怎么使用它有关。
于是,我先做了一个很小的改变。
我不再直接让它动手,而是让它先说明:它理解的问题是什么,准备改哪里,为什么这么改,哪些文件不能碰,最后怎么验证。
这个改变很小,但效果很明显。
以前一旦方向错了,我往往要等它改完几个文件,甚至运行失败以后才发现。
现在很多问题在计划阶段就会暴露出来:它准备修改哪些文件,有没有超出范围,理解的需求是不是我真正想要的。
我只需要在它动手前纠正一次,而不是在它改完后重新返工。
后来,我又把项目背景写进 CLAUDE.md,给它补上 Rules 和任务边界,用 Hooks 把危险操作和交付检查变成强制执行,再把常用流程沉淀成 Skills。
这些改变单独看都不复杂,但叠在一起之后,Claude Code 开始慢慢变得不一样。
不是它突然换了一个更聪明的模型,而是它做事开始有了背景、有了方向、有了边界,也有了验收标准。
我也不再只是想着,怎么写出一句更厉害的 Prompt。
我开始想的是:怎么先把自己手里的工具磨顺。
我开始把 Claude Code 当成一个项目搭档
以前我把 Claude Code 当成一个更强的聊天框:遇到问题就问,拿到答案就让它动手。
但项目越复杂,我越发现,这种用法不够。
Claude Code 更像一个执行力很强、但刚进入项目的新搭档。它有能力,也愿意主动做事,但它不了解项目历史,也不知道边界和验收标准。
如果我要让它长期参与项目,就不能只靠每次临时说一句需求。
我要给它项目说明、工作流程、行为边界、强制检查、可复用的工具和明确的验收方式。
这些东西加起来,就是我后来慢慢搭出来的 Claude Code OS。
我说的 OS,不是一个新的软件,而是一套让 Claude Code 了解项目、遵守边界、复用能力并接受验收的工作环境。
它不是我一开始设计好的一套系统。
更真实的情况是:我每踩一个坑,就往里面补上一块。
我主要给 Claude Code 补了六块东西
第一块,是 CLAUDE.md。
以前每次打开新会话,我都要重新介绍项目:它是做什么的,哪些目录不能动,哪些地方不能顺手重构,修改完必须怎么验证。
所以我把这些稳定信息写进 CLAUDE.md,让它开始工作前,先知道自己站在哪里。
第二块,是 Plan。
以前我看到 Claude Code 写得很快,就容易直接让它动手。可方向一旦错了,速度越快,返工反而越多。
所以我开始要求它先说清楚:理解的问题是什么,准备改哪里,为什么这么改,最后怎么验证。
先对准方向,再开始执行。
第三块,是 Rules 和任务边界。
Claude Code 很容易“顺手多做一点”。
你让它修一个 Bug,它可能顺手重构;你让它改一个页面,它可能顺手动到其他组件。
所以我会在 Rules 里写下长期需要遵守的规则,也会在每次任务开始前,单独说明这次允许修改的范围。
只改任务要求的内容,不确定先问,涉及高风险修改必须提前说明。
第四块,是 Hooks。
写下规则以后,我发现有些事情仍然不能只靠提醒。
危险命令、敏感文件、连续失败、交付前验证,这些一旦出问题,代价太高。
所以我用 Hooks 把它们变成真正会执行的门禁:该停的时候必须停,该检查的时候必须检查。
第五块,是 Skills。
调试、代码审查、项目初始化、交付验证,这些任务会反复出现。
如果每次都靠临时 Prompt 重新解释,做法很容易变形:有时很细,有时很粗,有时会验证,有时又漏掉关键步骤。
所以我把常用流程沉淀成 Skills,让 Claude Code 不再完全依赖现场发挥,而是逐渐有了自己的工具箱。
第六块,是 Validation。
这是我最不敢省掉的一块。
Claude Code 说“已经修复完成”,不代表项目真的能跑。
所以我不再只看它怎么说,而是看构建、类型检查、Lint、测试、关键路径和 Diff。
只有证据站得住,任务才算真的完成。
这六块东西没有让 Claude Code 突然变成一个完美的 AI。
但它开始变得更顺手了。
它进入项目时知道背景,动手前会先对准方向,执行时有边界,危险操作会被拦住,常用能力可以复用,最后的结果也有证据可以检查。
到这里,Claude Code 才不再只是一个很强、但经常让我心烦意乱的聊天框。
我开始有了一套真正适合自己的使用方式:它知道我的项目背景,理解我的工作习惯,也会按照我能接受的边界和标准完成任务。
最重要的不是配置越多,而是哪里不顺就磨哪里
回头看,我真正得到的,并不是一份可以复制给所有人的“最强配置”。
因为每个人遇到的问题都不一样。
有人最受不了 Claude Code 总是改出任务范围,所以他需要更清楚的边界。
有人最怕它说“已经修复完成”,结果项目根本跑不起来,所以他最需要的是验证。
也有人每天都在重复同一种任务,那他最值得做的,可能是把流程沉淀成 Skill。
所以真正重要的,不是把别人用过的 CLAUDE.md、Rules、Hooks 和 Skills 全部照搬回来。
而是先看清楚:你使用 AI 时,究竟是哪一个问题在反复消耗你。
哪里总在返工,就补哪里。
哪里容易失控,就约束哪里。
哪里一直重复,就沉淀哪里。
我现在这套 Claude Code OS,就是这样一点点长出来的。
它不一定最全面,也不一定适合所有人,但它越来越适合我的项目、我的习惯和我在意的边界。
而工具真正变顺手的标志,也不是它从此不再犯错。
而是那些原本需要我反复解释、反复提醒、反复检查的事情,开始有了稳定的处理方式。
我的注意力终于可以从“它这次会不会又跑偏”,重新回到“我真正想把事情做成什么样”。
这才是我最终想要的。
不是一个配置最多的 Claude Code,而是一套真正适合我、能够让我更专注地做事的使用方式。
你也不需要一开始就搭出一套完整系统。
先找出最近最让你返工的一件事,把它变成一条规则、一个固定流程,或者一次必须执行的检查,就已经是在让工具变得更顺手。
写在最后
这篇总篇,我不想再把每一个配置重新讲一遍。
CLAUDE.md 怎么写,Rules 怎么划边界,Hooks 怎么把规则变成强制检查,Skills 怎么沉淀常用能力,Validation 怎么判断任务是否真的完成,前面的文章里都已经分别展开过。
这篇文章,我更想留下一个整体判断:
AI 时代,决定我们能走多远的,或许不只是 AI 本身有多强,还在于我们如何看待它,又选择用什么样的方式驾驭它。
把它当成一个随叫随到的聊天框,我们得到的可能只是一次次临时生成的答案。
把它当成一件值得长期打磨的工具,我们才会开始为它准备背景、建立流程、划清边界、沉淀能力,并认真验证最终的结果。
模型的能力,决定了这把工具可以有多锋利。
而我们使用它的方式,决定了它最终能不能真正为我们所用。
更多推荐

所有评论(0)