待翻譯：Claude Code Best Practices: 3 Lessons from 400,000 Sessions

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

--> Claude Code Best Practices for Maximum Efficiency India's Most Futuristic AI Conference Is Back – Bigger, Sharper, Bolder d : h : m : s Career GenAI Prompt Engg ChatGPT LLM Langchain RAG AI Agents Machine Learning Deep Learning GenAI Tools LLMOps Python NLP SQL AIML Projects Reading list How to Become a Data Analyst in 2025: A Complete RoadMap A Comprehensive Learning Path to Tableau in 2025 A Comprehensive NLP Learning Path 2025 Learning Path to Become a Data Scientist in 2025 Step-by-Step Roadmap to Become a Data Engineer in 2025 A Comprehensive MLOps Learning Path: 2025 Edition Roadmap to Become an AI Engineer in 2025 A Comprehensive Learning Path to Master Computer Vision in 2025 Best Roadmap to Learn Generative AI in 2025 GenAI Roadmap for Enterprises Large Language Models Demystified: A Beginner’s Roadmap Learning Path to Become a Prompt Engineering Specialist Claude Code Best Practices: 3 Lessons from 400,000 Sessions Sree Vamsi Last Updated : 06 Aug, 2026 11 min read I used to think Claude Code best practices were a matter of taste. Plan mode or not. Long CLAUDE.md or short. Pick what suits you, move on. Then Anthropic scored roughly 400k sessions from over 235k users against hard evidence of success. Tests passing, commits landing, users confirming they got what they asked for. Taste turned out to be measurable. In this article, I’ll walk through what separated the sessions that worked from the ones that didn’t. Table of contents Lesson 1: Precision in How You Ask Lesson 2: Give Claude Something It Can Check Lesson 3: Who Ends Up Correcting Whom The Workflow That Ties All Three Together Five Ways Sessions Go Wrong Scaling Past One Session The Part That Stayed With Me Frequently Asked Questions The gap had nothing to do with the model. It was behaviour. And the study didn’t define expertise by job title or years of experience. It read three things off the transcript: Precision: how precisely the person framed their directions Verification: what they asked Claude to check before trusting it Correction direction: whether the person corrected Claude, or Claude corrected the person One thing to note before we get into them: expertise here is task-specific. A senior engineer asking their first Rust question is a beginner at Rust. An accountant who’s never written Python, but who tells Claude exactly which reconciliation rules to enforce and catches the edge case it fumbles at month end, is an expert at that task. All ten of the largest occupation groups landed within seven points of software engineers. Lesson 1: Precision in How You Ask The study found that in novice sessions, each prompt set off about five Claude actions and roughly 600 words of output. In expert sessions, each prompt set off about twelve actions and 3,200 words. More than twice the work and five times the output, from the same tool. The difference is not prompt length. It is whether the prompt contains the things Claude cannot infer: which file, which scenario, what counts as done, and what pattern to follow. The four upgrades that matter most Instead ofSay this add tests for foo.pywrite a test for foo.py covering the case where the user is logged out. avoid mocks. why does ExecutionFactory have such a weird api?look through ExecutionFactory’s git history and summarise how its api came to be add a calendar widgetlook at how existing widgets work on the home page. HotDogWidget.php is a good example. follow that pattern for a calendar widget with month select and year pagination. no new libraries. fix the login bugusers report login fails after session timeout. check src/auth/, especially token refresh. write a failing test that reproduces it, then fix it. Notice what the right-hand column has in common. Each one names a location, a scenario, and a definition of done. None of them is longer than two sentences of real information. Stop describing files, start handing them over This is the habit I picked up latest and regret most. Rather than telling Claude where something lives, give it the thing directly: # Reference a file inline, Claude reads it before answering > explain the token refresh logic in @src/auth/session.ts # Pipe data straight in, works on files outside the project cat error.log | claude -p "group these errors by root cause" # Paste or drag an image directly into the prompt > [screenshot] implement this design You can also give Claude URLs for API docs and let it fetch what it needs itself. Use /permissions to allowlist domains you hit often so you are not approving the same fetch repeatedly. Give Claude the right tools, not just the right words A precision habit that is easy to miss: the tools available to Claude shape how precisely it can act. CLI tools are the most context-efficient way to reach an external service, because the output comes back compact and Claude already knows the syntax. If you use GitHub, install the gh CLI. Claude will use it to open issues, create pull requests, and read comments. Without it, Claude falls back to the GitHub API, where unauthenticated requests hit rate limits. The same applies to aws, gcloud, and sentry-cli. It also learns tools it has never seen. This prompt shape works surprisingly well: Use 'foo-cli-tool --help' to learn about foo tool, then use it to solve A, B, C. For services with no good CLI, MCP servers are the answer. Our guide to connecting MCP servers with Claude covers the setup for both Claude Desktop and Claude Code. For anything large, let Claude interview you first This one felt strange the first time and is now how I start every feature bigger than a day of work. Instead of writing a long spec yourself, make Claude extract it from you: I want to build [brief description]. Interview me in detail using the AskUserQuestion tool. Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered. Keep interviewing until we've covered everything, then write a complete spec to SPEC.md. It surfaces the decisions you’d otherwise hit halfway through implementation. Once the spec is done, start a fresh session to build it, so the implementation has clean context and a written document to work against. The best specs name the files and interfaces involved, state what’s out of scope, and end with an end-to-end check that proves the feature works. Time spent sharpening the spec pays back more than time spent watching the build. Try this now: Take the next feature on your list. Paste the interview prompt above with a one-line description. Answer honestly, including the questions you don’t have answers to yet. That gap is the actual work. Lesson 2: Give Claude Something It Can Check This is the habit that pays back most, and the one I see skipped most. Claude stops when the work looks done. If there is no check it can run, then “looks done” is the only signal available, and you become the verification loop. Every mistake waits for you to notice it. Give Claude something that returns pass or fail and the loop closes on its own. Claude does the work, runs the check, reads the result, and iterates until it passes. A test suite, a build exit code, a linter, a script that diffs output against a fixture, a browser screenshot compared to a design. Anything that produces a signal it can read. # Weak: no way to know when it is done > implement a function that validates email addresses # Strong: the check is in the prompt > write a validateEmail function. test cases: [email protected] is true, 'invalid' is false, '[email protected]' is false. run the tests after implementing. Four levels of how hard the check gates the work Once a check exists, you choose how strictly it stops Claude from declaring victory. Each level trades a bit of setup for a bit less of your attention: LevelHow it worksSetup cost In one promptAsk Claude to run the check and iterate in the same messageNone, works today Across a sessionSet the check as a /goal condition. An evaluator re-checks after every turn and Claude keeps going until it holdsLow As a hard gateA Stop hook runs your check as a script and blocks the turn from ending until it passesMedium, one script Second opinionA verification subagent or dynamic workflow has a fresh model try to refute the resultMedium Worth knowing about Stop hooks: Claude Code overrides the hook and ends the turn after 8 consecutive blocks. It will not loop forever if your check can never pass. The prompt version works on any task right now. The /goal and Stop hook versions are what let an unattended run finish correctly while you are somewhere else. That is the real payoff. Ask for evidence, not assurance Related habit that costs nothing: tell Claude to show the test output, the command it ran and what came back, or a screenshot of the result. Reading evidence is faster than re-running the verification yourself, and it is the only way to review a session you were not watching. The adversarial review step The longer Claude works without you, the more an independent check matters before you call it done. A reviewer running in a fresh subagent context sees only the diff and the criteria you give it, not the reasoning that produced the change. So it judges the result on its own terms. Use a subagent to review the rate limiter diff against PLAN.md. Check that every requirement is implemented, the listed edge cases have tests, and nothing outside the task's scope changed. Report gaps, not style preferences. Because the reviewer is a subagent, findings come back into the same session, so Claude can fix them and re-review without you copying text between windows. There is also a bundled /code-review skill that reviews the current diff for bugs in a fresh subagent if you just want a correctness pass. A trap to know about: a reviewer asked to find gaps will usually report some, even when the work is sound, because that is the job you gave it. Chasing every finding leads to over-engineering, extra abstraction, and tests for cases that cannot happen. Tell the reviewer to flag only gaps affecting correctness or your stated requirements, and treat the rest as optional. Lesson 3: Who Ends Up Correcting Whom The third signal the classifier looked for was direction of correction. In weaker sessions, Claude spends its time correcting the user’s misunderstanding of their own codebase. In stronger ones, the user catches Claude early and redirects. The study found something blunt about what happens when this goes wrong. Among sessions that hit real trouble, 19% of novice-rated ones were abandoned outright with zero lines of code written, against 5 to 7% for everyone else. The gap is not in hitting problems. It is in recovering from them. Course-correct immediately, not eventually ActionWhat it does EscStop Claude mid-action. Context is preserved so you can redirect. Esc Esc or /rewindOpen the rewind menu. Restore conversation, code, or both. “undo that”Have Claude revert its own changes. /clearReset context entirely between unrelated tasks. The two-correction rule This is the rule that changed my sessions the most, and it is counterintuitive. If you have corrected Claude more than twice on the same issue in one session, stop correcting. The context is now full of failed approaches, and every further attempt is reasoning against that noise. Run /clear and start fresh with a better prompt that includes what you just learned. Try this now: Next time you are on your third correction of the same problem, resist the fourth. Copy what you have learned into a note, run /clear, and write one specific prompt that rules out the approaches that failed. Compare how that goes. Manage context before it degrades your output Nearly every best practice traces back to one constraint: the context window fills fast and output quality [truncated for AI cost control]