{"slug": "how-i-turned-claude-code-into-my-personal-operating-system", "title": "How I Turned Claude Code into My Personal Operating System", "summary": "A developer built a personal operating system for Claude Code, an AI coding assistant, to address recurring issues like misunderstood requirements, out-of-scope modifications, and false completion claims. By adding structured components such as project context files, planning steps, rules, hooks, reusable skills, and validation checks, the developer transformed Claude Code from a chaotic chat interface into a reliable tool that respects boundaries and verifies results. The system evolved organically as the developer patched each pain point, resulting in a tailored workflow that reduces rework and frees attention for higher-level tasks.", "body_md": "副标题：后来我才发现，AI 越强，就越需要被磨成一把顺手的工具。\n\n我最近越来越强烈地感觉到一件事：\n\nAI 明明已经很强了，但很多人并没有因此真正变强。\n\n我们每天都在用 AI。学习时用它，写文章时用它，做项目时用它，改代码时也用它。它确实能回答问题、生成方案，也能帮我们把很多事情做得更快。\n\n但用得越久，一个问题反而越明显：\n\nAI 很强，不代表我们就能稳定地把事情做好。\n\n很多时候，我们不是不会用 AI，而是太随便地使用 AI。想到什么就问一句，遇到报错就贴一下，想写文章就让它生成一版，想改功能就直接让它动手。\n\n短期看，好像每一步都有结果。时间一长，却会发现自己总是在反复解释、反复返工、反复验证，甚至反复收拾 AI 留下来的残局。\n\n一开始我以为，这是因为 AI 还不够聪明。\n\n后来我也换过更强的模型，用上了当时公认的最顶级的模型。我原本以为，只要模型能力足够强，那些理解错误、越界修改和虚假完成的问题自然就会减少。\n\n结果并没有。\n\n模型确实变强了。它理解代码更快，给出的方案更完整，执行复杂任务的能力也更强。\n\n但它依然可能没理解清楚就开始动手，顺手改掉我没让它碰的地方，再很自信地告诉我：“已经修复完成。”\n\n等我重新运行项目，报错可能还在那里。\n\n我对这件事感受最深的时候，是在用 Claude Code 做项目。\n\n刚开始，我只是想让它帮我把项目做得快一点。遇到 Bug，就把报错贴给它；想加功能，就直接告诉它需求；哪里样式不对，就让它顺手改一下。\n\n任务很小时，这套用法没什么问题。一个文件、一个函数、一个明确的报错，它通常都能处理得不错。\n\n真正的问题，是从项目开始变复杂之后出现的。\n\n我只是让它修一个小问题，它却顺手改了更多文件。这些修改不一定完全错误，甚至有些看起来很合理，但它们根本不在这次任务的范围里。\n\n它给出的方案可能很完整，解释也很自信，可我重新运行项目，报错仍然存在。它说“已经修复完成”，我看到的却是又一轮返工。\n\n前几天刚提醒过的项目规则，打开新会话后，它也可能像一个刚入职的人一样，重新问、重新猜、重新犯差不多的错。\n\n这些事情单独看，好像都不严重。\n\n改多了，可以回滚；没修好，可以继续贴报错；忘了规则，也可以再提醒一次。\n\n真正折磨人的，是它们会反复发生。\n\n同一个项目背景，我讲了一遍又一遍；同一种边界问题，我提醒了一次又一次；同一句“已经修复完成”，我相信了一次，又被现实打回来一次。\n\n时间久了，人真的会被搞得心烦意乱。\n\n明明我是想让 AI 帮我提高效率，结果却花了大量时间检查它有没有跑偏。\n\n我开始怀疑自己。\n\n是不是我需求没说清楚？是不是我不会用 AI？是不是别人用 Claude Code 都很顺，只有我一直在收拾残局？\n\n我也开始怀疑 AI。\n\n它到底是真的理解了，还是只是看起来理解了？它是真的修好了，还是只是很会把“修好了”说得像真的？\n\n后来我慢慢发现，最难受的不是 Claude Code 偶尔犯错，而是我一直在用一种临时、粗糙的方式驱动它。\n\n它很强，但我没有给它稳定的项目背景；它很快，但我没有让它先把方向想清楚；它很主动，但我没有给它清楚的边界；它很自信，但我没有建立真正的验收方式。\n\n问题可能不只是模型够不够强，也和我怎么使用它有关。\n\n于是，我先做了一个很小的改变。\n\n我不再直接让它动手，而是让它先说明：它理解的问题是什么，准备改哪里，为什么这么改，哪些文件不能碰，最后怎么验证。\n\n这个改变很小，但效果很明显。\n\n以前一旦方向错了，我往往要等它改完几个文件，甚至运行失败以后才发现。\n\n现在很多问题在计划阶段就会暴露出来：它准备修改哪些文件，有没有超出范围，理解的需求是不是我真正想要的。\n\n我只需要在它动手前纠正一次，而不是在它改完后重新返工。\n\n后来，我又把项目背景写进 CLAUDE.md，给它补上 Rules 和任务边界，用 Hooks 把危险操作和交付检查变成强制执行，再把常用流程沉淀成 Skills。\n\n这些改变单独看都不复杂，但叠在一起之后，Claude Code 开始慢慢变得不一样。\n\n不是它突然换了一个更聪明的模型，而是它做事开始有了背景、有了方向、有了边界，也有了验收标准。\n\n我也不再只是想着，怎么写出一句更厉害的 Prompt。\n\n我开始想的是：怎么先把自己手里的工具磨顺。\n\n以前我把 Claude Code 当成一个更强的聊天框：遇到问题就问，拿到答案就让它动手。\n\n但项目越复杂，我越发现，这种用法不够。\n\nClaude Code 更像一个执行力很强、但刚进入项目的新搭档。它有能力，也愿意主动做事，但它不了解项目历史，也不知道边界和验收标准。\n\n如果我要让它长期参与项目，就不能只靠每次临时说一句需求。\n\n我要给它项目说明、工作流程、行为边界、强制检查、可复用的工具和明确的验收方式。\n\n这些东西加起来，就是我后来慢慢搭出来的 Claude Code OS。\n\n我说的 OS，不是一个新的软件，而是一套让 Claude Code 了解项目、遵守边界、复用能力并接受验收的工作环境。\n\n它不是我一开始设计好的一套系统。\n\n更真实的情况是：我每踩一个坑，就往里面补上一块。\n\n第一块，是 **CLAUDE.md**。\n\n以前每次打开新会话，我都要重新介绍项目：它是做什么的，哪些目录不能动，哪些地方不能顺手重构，修改完必须怎么验证。\n\n所以我把这些稳定信息写进 CLAUDE.md，让它开始工作前，先知道自己站在哪里。\n\n第二块，是 **Plan**。\n\n以前我看到 Claude Code 写得很快，就容易直接让它动手。可方向一旦错了，速度越快，返工反而越多。\n\n所以我开始要求它先说清楚：理解的问题是什么，准备改哪里，为什么这么改，最后怎么验证。\n\n先对准方向，再开始执行。\n\n第三块，是 **Rules 和任务边界**。\n\nClaude Code 很容易“顺手多做一点”。\n\n你让它修一个 Bug，它可能顺手重构；你让它改一个页面，它可能顺手动到其他组件。\n\n所以我会在 Rules 里写下长期需要遵守的规则，也会在每次任务开始前，单独说明这次允许修改的范围。\n\n只改任务要求的内容，不确定先问，涉及高风险修改必须提前说明。\n\n第四块，是 **Hooks**。\n\n写下规则以后，我发现有些事情仍然不能只靠提醒。\n\n危险命令、敏感文件、连续失败、交付前验证，这些一旦出问题，代价太高。\n\n所以我用 Hooks 把它们变成真正会执行的门禁：该停的时候必须停，该检查的时候必须检查。\n\n第五块，是 **Skills**。\n\n调试、代码审查、项目初始化、交付验证，这些任务会反复出现。\n\n如果每次都靠临时 Prompt 重新解释，做法很容易变形：有时很细，有时很粗，有时会验证，有时又漏掉关键步骤。\n\n所以我把常用流程沉淀成 Skills，让 Claude Code 不再完全依赖现场发挥，而是逐渐有了自己的工具箱。\n\n第六块，是 **Validation**。\n\n这是我最不敢省掉的一块。\n\nClaude Code 说“已经修复完成”，不代表项目真的能跑。\n\n所以我不再只看它怎么说，而是看构建、类型检查、Lint、测试、关键路径和 Diff。\n\n只有证据站得住，任务才算真的完成。\n\n这六块东西没有让 Claude Code 突然变成一个完美的 AI。\n\n但它开始变得更顺手了。\n\n它进入项目时知道背景，动手前会先对准方向，执行时有边界，危险操作会被拦住，常用能力可以复用，最后的结果也有证据可以检查。\n\n到这里，Claude Code 才不再只是一个很强、但经常让我心烦意乱的聊天框。\n\n我开始有了一套真正适合自己的使用方式：它知道我的项目背景，理解我的工作习惯，也会按照我能接受的边界和标准完成任务。\n\n回头看，我真正得到的，并不是一份可以复制给所有人的“最强配置”。\n\n因为每个人遇到的问题都不一样。\n\n有人最受不了 Claude Code 总是改出任务范围，所以他需要更清楚的边界。\n\n有人最怕它说“已经修复完成”，结果项目根本跑不起来，所以他最需要的是验证。\n\n也有人每天都在重复同一种任务，那他最值得做的，可能是把流程沉淀成 Skill。\n\n所以真正重要的，不是把别人用过的 CLAUDE.md、Rules、Hooks 和 Skills 全部照搬回来。\n\n而是先看清楚：你使用 AI 时，究竟是哪一个问题在反复消耗你。\n\n哪里总在返工，就补哪里。\n\n哪里容易失控，就约束哪里。\n\n哪里一直重复，就沉淀哪里。\n\n我现在这套 Claude Code OS，就是这样一点点长出来的。\n\n它不一定最全面，也不一定适合所有人，但它越来越适合我的项目、我的习惯和我在意的边界。\n\n而工具真正变顺手的标志，也不是它从此不再犯错。\n\n而是那些原本需要我反复解释、反复提醒、反复检查的事情，开始有了稳定的处理方式。\n\n我的注意力终于可以从“它这次会不会又跑偏”，重新回到“我真正想把事情做成什么样”。\n\n这才是我最终想要的。\n\n不是一个配置最多的 Claude Code，而是一套真正适合我、能够让我更专注地做事的使用方式。\n\n你也不需要一开始就搭出一套完整系统。\n\n先找出最近最让你返工的一件事，把它变成一条规则、一个固定流程，或者一次必须执行的检查，就已经是在让工具变得更顺手。\n\n这篇总篇，我不想再把每一个配置重新讲一遍。\n\nCLAUDE.md 怎么写，Rules 怎么划边界，Hooks 怎么把规则变成强制检查，Skills 怎么沉淀常用能力，Validation 怎么判断任务是否真的完成，前面的文章里都已经分别展开过。\n\n这篇文章，我更想留下一个整体判断：\n\nAI 时代，决定我们能走多远的，或许不只是 AI 本身有多强，还在于我们如何看待它，又选择用什么样的方式驾驭它。\n\n把它当成一个随叫随到的聊天框，我们得到的可能只是一次次临时生成的答案。\n\n把它当成一件值得长期打磨的工具，我们才会开始为它准备背景、建立流程、划清边界、沉淀能力，并认真验证最终的结果。\n\n模型的能力，决定了这把工具可以有多锋利。\n\n而我们使用它的方式，决定了它最终能不能真正为我们所用。", "url": "https://wpnews.pro/news/how-i-turned-claude-code-into-my-personal-operating-system", "canonical_source": "https://dev.to/guanyi_liu_21a5d7417eb332/how-i-turned-claude-code-into-my-personal-operating-system-95a", "published_at": "2026-06-19 05:34:55+00:00", "updated_at": "2026-06-19 06:00:46.620763+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "large-language-models", "ai-agents"], "entities": ["Claude Code", "Anthropic"], "alternates": {"html": "https://wpnews.pro/news/how-i-turned-claude-code-into-my-personal-operating-system", "markdown": "https://wpnews.pro/news/how-i-turned-claude-code-into-my-personal-operating-system.md", "text": "https://wpnews.pro/news/how-i-turned-claude-code-into-my-personal-operating-system.txt", "jsonld": "https://wpnews.pro/news/how-i-turned-claude-code-into-my-personal-operating-system.jsonld"}}