# You Don’t Know AI Coding: A Non-Engineer’s Guide to Claude Code
**作者**: Tw93
**日期**: 2026-04-29T14:08:59.000Z
**来源**: [https://x.com/HiTw93/status/2049491135522054555](https://x.com/HiTw93/status/2049491135522054555)
---
## TL;DR
AI Coding is not just for programmers.
Last month, I ran an internal session for product, business, and operations teammates on how to get started with Claude Code. That deck eventually grew into this post.
For non-engineers, the first hurdle is usually the command line. It looks like a programmer-only place, but the bar is lower than it seems. If you can use a chatbot like ChatGPT, you can start using Claude Code with a bit of time and patience.
Once you get the hang of it, Claude Code starts to feel like an all-purpose assistant: pulling backend data, writing small tools for specific problems, stitching scattered docs into briefs, prototyping workflows, cleaning up sales reports, and automating repeated work.
Whether you have written code before is not the deciding factor. The shift happens when you stop treating AI as a chatbot and start treating it as an execution partner.
This post is a practical guide for non-engineers who want to use Claude Code for real work.
## The first hurdle is the command line
If you don’t write code, you’re used to chatbot AI like ChatGPT, and the first install of Claude Code feels a bit off. The old loop was a back-and-forth shuttle: you describe what you want, it spits out code, you copy-paste it somewhere else to try. With Claude Code that shuttle step is gone, it runs directly in the terminal.
If you’ve never used a terminal, try Kaku, which I built specifically for AI Coding. Install and go, no fiddling with colors or fonts. Light/dark mode follows the system, split panes with Cmd + D, file manager with Cmd + Shift + Y. The most beginner-friendly part is the built-in AI assist: when a command fails it auto-suggests fixes, and if you can’t remember a command, prefix it with # and type in plain English.
Installing Claude Code is one command, see the official docs, then cd into your project folder and type claude to start coding.
```
curl -fsSL https://claude.ai/install.sh | bash
```
## A bit of technical literacy goes a long way
If you don’t write code but want to actually use Claude Code well, knowing how to describe what you want isn’t enough. A bit of conceptual ground makes debugging way easier later.
What common frameworks do. Knowing roughly what React, Vue, and Next.js solve means you won’t be lost when Claude Code writes something using them.
Basics of common software: terminal commands, Git, VS Code, Chrome DevTools. When something errors out, you can locate it alongside Claude instead of just waiting.
A few core programming ideas: what a function is for, what variables and state are, why we split things into multiple files. Understanding these makes your requirements more precise.
Reading code and reading errors pays off earlier than learning to write code. When it changes a chunk, you can glance at it and roughly tell what’s happening, much faster than asking it to explain. When errors come up, don’t panic, just paste the whole thing back and ask “what does this mean and how do I fix it.” Nine times out of ten it’ll point you to the exact line.
You don’t need to learn enough to write code yourself. Just knowing what these things look like is enough. Spend a couple of evenings on the freeCodeCamp or MDN intro, or pick a free intro course like Crash Course Computer Science or Harvard CS50, and collaboration with Claude Code will feel noticeably different.
Three books I’d recommend most for non-engineers, all easy reads: INSPIRED for product judgment, Linux and the Unix Philosophy for engineering philosophy, and The Pragmatic Programmer for how senior engineers actually think. Reading these makes technical conversations with AI a lot less confusing.
## Account and subscription
Account: sign up at claude.ai with a Google or email account, the most standard flow.
Subscription: three tiers. Free is $0 and only gets you basic chat, no Claude Code. Pro is $20/month, unlocks Claude Code, and is the right entry point for most people. Max comes in $100 and $200 tiers, giving 5x and 20x usage respectively, suited for heavy day-to-day code work.
Start with Pro. Upgrade to Max if quotas feel tight. Subscription follows the account, so an iOS purchase shows up on Android and web too.
## What kind of tasks Claude Code is good at
I’ve tried a fair number of AI Coding tools, Cursor, Windsurf, and Codex are all in regular rotation, but my main driver stays Claude Code.
What sets it apart is the underlying model is already strong, and the Claude Code implementation pushes the harness pattern to the limit, looking at the whole project: it scans the CLAUDE.md and directory structure first to get the context, then edits across files, runs commands, reads errors, edits again, all on its own. On top of that it lives in the terminal, so git, tests, scripts, all the tools you already use, it can call directly without any copy-paste round-trip.
It’s effectively a general-purpose Agent. The Code in the name just reflects its original framing toward writing code. Anthropic has shared that internally many non-engineering teams, sales, risk, finance, are using it to handle CRM data and customer email. If you really don’t want to touch the terminal, the official desktop app Cowork can read and write your Downloads and Documents folders directly, so something like turning a stack of receipt screenshots into an expense report works with one sentence.
There’s another point that I think really matters: when it comes to writing code, speed isn’t what counts, accuracy is. Ten minutes of generation followed by twenty minutes of debugging is much worse than twenty minutes of generation that’s actually verifiable on the spot.
Getting it to be accurate starts with handing it work that is itself clearly defined and easy to verify. Tasks that meet both bars are the best fit, like assigning work to a very literal but technically excellent engineer.
Concretely, a few categories: prototypes and internal tools, where you spell out the requirement and display logic and you have a working version the next day; processing CSVs and building sales reports, with grouping and calculation logic written out clearly, results in minutes; pulling clauses from contracts dozens of pages long, comparing versions, the kind of doc work it really shines at; and finally, feeding it a stack of links or PDFs and asking it to extract information from a specific angle, just spell out the format you want.
## Build software just for yourself
The biggest blocker when starting to “write code” is not knowing what to build. Kevin Roose, a NYT columnist, coined a useful concept: software for one. You don’t need to build something for a million people, you can build something just for you.
He built Stash for himself to organize links, LunchBox Buddy for prepping his kid’s lunches. For you, it might be a tool that turns voice notes into meeting minutes, or a small dashboard that pings you with three things to do every morning. This is exactly the kind of thing product and business folks can actually pull off, because nobody knows your daily friction better than you.
A pace from one day to three month
Don’t start by trying to build “something like Notion.” A pace that works:
Day 1, dip in: have it edit an Excel or Markdown file you already have on hand. Week 1, taste it: build a single-page personal homepage or a daily dashboard, fifteen minutes to get it running. Month 1, ship something: pick one thing you do two or three times a week and turn it into a single command or a single page. Month 3, level up: pick a software-for-one idea and build a real tool just for you.
## Use OpenCLI to turn web operations into commands
A lot of operations work happens in browsers: checking dashboards, sending messages, exporting reports. Most of that can skip the UI entirely and call the underlying API instead.
OpenCLI is built by my friend Cabbi. It ships with built-in CLI adapters for dozens of sites including Reddit, X/Twitter, YouTube, plus a set of generic browser primitives like click, type, scrape, screenshot. It turns web actions into single commands that Claude Code can invoke in one sentence.
Social listening: have Claude Code call opencli reddit to pull data, then categorize and extract trending terms. What used to take half an hour of clicking now takes one sentence.
Sentiment digest: combine the X/Twitter, Reddit, and HackerNews adapters and turn discussion of the same keyword across multiple platforms into a daily report.
Sites without an adapter: describe the flow with browser primitives, like open page, type keyword, scrape table, and Claude Code stitches it together.
Claude Code also has a feature called Routines that stores a workflow in the cloud and triggers it on a schedule, webhook, or GitHub event. I haven’t used it heavily yet, but conceptually something like “every Monday morning, run the weekly report flow” can be handed off to it. See the docs if interested.
## CLAUDE.md: write the project background down clearly first
A lot of people install it and start firing questions. They end up restating the background every time, and after a while it gets old. The reason is almost always the same: no CLAUDE.md.
It lives at the project root, and Claude Code reads it on every startup. Treat it like the onboarding doc you’d write for a new teammate, except this one reads it from scratch every time and follows it strictly.
Three things matter most. Keep it short, ideally under 150 lines. Going longer eats into the conversation budget. Be direct, use the imperative, skip the soft “we tend to prefer” phrasing. “All comments in English” beats “the team prefers English comments” by a wide margin. Make every rule something you can judge against. “Code quality should be high” is useless. “Functions over 50 lines must be split” is something you can actually enforce.
Four rules that earn their keep, take them as-is: ask before acting, prefer simple, only touch what needs touching, verify when done. Expanded: don’t let it guess your intent, spell out the goal first; if two lines do the job, don’t write two hundred, no over-engineering; don’t refactor code you weren’t asked to touch; build and tests pass before calling it done, otherwise don’t.
A template you can adapt by changing the project background:
```
# Project Background
A customer dashboard for the operations team. Stack: Node.js + Next.js,
React on the front end, PostgreSQL database, deployed on Vercel.
PM is Alice, designer is Bob, backend is me.
# Working Rules
- All comments in English, variables and functions in English.
- State what you intend to change before making any edits, wait for my OK.
- For new features, write the implementation, don't add tests unless I ask.
- Database table names use snake_case, e.g. user_profile.
# Don't Do
- Don't proactively refactor files I haven't mentioned.
- Don't delete any file unless I explicitly say so.
- Don't run npm install for new dependencies without confirming first.
# Preserve When Compacting
When the long conversation gets auto-compacted, preserve in this priority:
1. Architecture decisions and the reasoning behind them
2. Which files were changed and what the changes were
3. Current progress state
4. TODOs that aren't done yet
```
That last “preserve when compacting” section looks small but it’s what makes long sessions stay coherent. Claude Code’s context auto-compacts past a threshold, and the reasoning behind decisions is usually the first thing dropped. If you previously said “use POST not GET because the payload is large,” post-compaction it might just become “use POST,” with the reasoning gone. Next time the topic comes up, it might propose something completely different and contradict itself. With this section in place, long sessions stop fighting themselves.
You don’t need to write all of this from scratch. After installing Claude Code, just say “read my project and generate a CLAUDE.md for me.” It’ll scan the code, stack, and structure and hand you a draft. You only need to tweak names and team preferences. Same goes for installing dependencies, configuring aliases, editing ~/.claude/settings.json, just tell it the effect you want and let it figure out, it’s faster than reading docs. Hand off the configuration work, save your energy for the things that actually need judgment.
## The more precise the requirement, the less it diverges
Vague: build me a customer follow-up tool. Precise: build a sales follow-up tool, single-file webpage, store data locally. Left side is a list showing company name, next follow-up date, status. Right side is detail view including communication history, dates, key points. Top has three filters: status, time, keyword. Data lives in browser localStorage, no backend.
The precise version gets you a working prototype the same day. The vague one almost always needs a redo.
Here’s a fully precise example, requirements yetone wrote for a Claude Code build of a macOS voice input tool. You don’t need to follow the code details, the point is how specifically each requirement is broken down.
```
Build me a native macOS voice input tool in Swift:
1. Hold Fn to start recording, release to inject the transcribed text into
the focused input. Prefer streaming transcription (Apple Speech Recognition
framework). Listen for Fn globally via CGEvent tap; suppress Fn event
propagation to avoid triggering the emoji selector.
2. Default language must be Simplified Chinese (zh-CN) — works for Chinese
out of the box. Menu bar can switch to English, Traditional Chinese,
Japanese, Korean; persist choice to UserDefaults.
3. While recording, show a borderless capsule HUD centered at the bottom
of the screen: no traffic lights, no titlebar. Use NSPanel
(nonactivatingPanel) + NSVisualEffectView (.hudWindow material).
Height 56px, corner radius 28px. Left side shows a live audio waveform
(5 vertical bars driven by RMS level), right side shows transcribed text
(160-560px elastic width). Spring entrance 0.35s, text width transition
0.25s, scale exit 0.22s.
4. Inject text via clipboard + simulated Cmd+V. Before injecting, detect
the active input source: if it's a CJK input source, temporarily switch
to ABC, paste, then restore the original input source. Restore the
original clipboard contents afterward.
5. Plug in an LLM to improve recognition accuracy for mixed Chinese/English.
Use an OpenAI-compatible API (configurable Base URL, Key, Model) to refine
transcribed text. The system prompt must be extremely conservative: only
fix obvious speech recognition errors (e.g. "pie son" -> "Python",
"jay son" -> "JSON"), never rewrite or polish text that looks correct,
if it looks right, return it as-is.
6. Menu bar exposes an LLM Refinement submenu with enable/disable toggle and
a Settings entry. Settings window has API Base URL, API Key, Model fields,
plus Test and Save buttons. After Fn release, if LLM is enabled, the HUD
shows Refining... until the response comes back, then injects.
7. Run as LSUIElement (menu bar icon only, no Dock icon). Build with Swift
Package Manager, ship a Makefile (build/run/install/clean).
```
With this kind of description, Claude Code barely needs to guess and produces an installable macOS app directly. Every line is preventing it from guessing wrong on a specific point:
You don’t need to write Swift, but you do need to write the requirement this specifically. Every line in there is a pit yetone has fallen into or anticipated. Each extra concrete detail saves one round of redo.
For business-side requirements, describing the function isn’t enough. Lead with the problem, what are we solving, who is it for, what counts as done. Don’t open with a feature list. Say we’re building a new category landing page for international ticket products, the very first sentence should be: “International ticket products don’t have a dedicated entry point today, users only find them through search, and exposure for non-popular cities is extremely low.” That sentence shapes its judgment when it later runs into questions like “how many popular cities to show” or “should the filter include ‘recently viewed’.”
Next, scope it. Claude Code is eager: ask for a list page and it’ll throw in favorites, sharing, and analytics tracking. Spell out “no auth, no sharing, no SEO, save those for the next iteration” and it stops crossing lines. Edge cases get their own list: API timeout, empty data, missing images, what’s the fallback. Don’t write these down and it either skips them or guesses a fallback you won’t like.
Acceptance criteria need numbers. “Page should be fast” is useless. “First paint under 1.5s” is judgable. “Layout should look right” is useless. “No layout breakage at 375 and 1440 widths” is verifiable.
Don’t write “TBD” or “decide later.” Claude Code will fill those in by guessing, and the guess usually isn’t what you want. Even “hardcode for this version, configurable next version” beats leaving it blank.
## For complex tasks, sync first: Plan and Auto mode
There was one time I asked it to refactor the login module and it deleted a util class I needed downstream. Took me half an hour to roll back. Lesson stuck.
Since then, for anything complex I press Shift+Tab twice to flip into Plan mode first. It lays out what it intends to do, you confirm the direction, then it executes. Same as how things work at the office: you don’t tell a junior engineer to just go build the feature, you have a quick sync on the approach, agree, then they start.
A Plan mode plan looks something like: which files to change, what changes per file, the reasoning, and the expected blast radius. Judging direction from business logic is much easier than judging the code itself. Even if you can’t read code, you can rule on “should this step happen, does this rationale hold.
If asking on every step gets old, switch on Auto mode: cycle Shift+Tab to the auto position. It’s available on Max, Team, and Enterprise; Pro doesn’t have it yet. It judges autonomously: safe operations like reading files run directly, risky operations like database writes or file deletes still ask. Default it on early, you don’t get interrupted by trivial confirmations and it doesn’t go rogue either.
## How do you know it actually got it right
It saying “done” doesn’t mean much, what counts is how you verify. AI also takes the path of least effort.
I check three things. Did the commands pass: build and test go green. Putting “after finishing, run make build && make lint” in CLAUDE.md makes it self-check. Did you actually see it: open the page, eyeball the numbers, walk the key flow. A file edit isn’t the same as the page looking the way you wanted. Did it match the list: walk the acceptance criteria one by one, anything missed isn’t done, send it back.
Recovering from a bad change
The thing non-coders fear most is the code getting tangled past recovery. Two common saves.
Git snapshot: before any big change, have it run git status to see what’s there, then commit a checkpoint once you’re satisfied. If things go bad, just say “roll back to the last checkpoint,” much safer than running checkout by hand.
Undo last step: just say “undo everything you just did,” or use /rewind to return to the previous state.
Don’t let it slide into a try-this-try-that loop
A trap that’s easy to fall into: getting stuck in a try-this-try-that loop. Four or five rounds in, what was a small problem turns into a knot. The cause is always the same: patching before the diagnosis is clear.
The fix in one line: don’t touch code until the root cause is named. Get it to first answer “which file, which line, why does this happen.” If the answer is fuzzy, keep digging. Only edit once the answer is clear. If it opens with “let me try changing X and see,” cut it off and ask for the root cause first.
## After the warm-up: alias, model, long sessions
You don’t need this on day one. Once you’re comfortable, or once Pro starts feeling tight, come back to this section.
How I use my Max subscription
alias, I dropped one line into .zshrc so pressing c launches Claude Code without permission prompts and pushes the auto-compact threshold up to 400k. Letting compaction trigger only when the context is fully maxed gives worse results than triggering a bit earlier. You can paste this snippet into your own Claude Code and have it adapt for you:
```
alias c='CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude --dangerously-skip-permissions'
```
--dangerously-skip-permissions is not for beginners. It literally means “dangerously skip every permission prompt,” so Claude Code won’t ask anything. I use it because I can read what it’s doing at every step, and the constant prompts genuinely slow me down. If you’re not at that level yet, stick with Auto mode.
Use opusplan as the model. The way I’m running it now is to type /model opusplan, a hidden command (these can change between releases, defer to whatever your version supports). It uses Opus for planning and Sonnet for execution: planning gets handed to Opus, execution to Sonnet, saves both money and time overall. Want it faster, run /fast on top, that buys back roughly the tokens you saved.
A key setting: if your version supports it, when using opusplan, set showClearContextOnPlanAccept to true in ~/.claude/settings.json. Without it the Sonnet leg hits a serious cache miss and slows down noticeably. Flipping this on smooths the whole thing out.
What to do about long sessions
Claude Code’s context window is fixed. Push it long enough and early content gets pushed out.
/clear after each task: one task per session. Finish, clear, start the next. Two unrelated things in the same context make it progressively confused.
Have it write a handoff note before a long task ends: just say “write current progress to HANDOFF.md, including what’s done, what didn’t work, what’s next.” Open a fresh session next day, hand it the file, it picks right up. No reliance on the compaction algorithm.
## Waza: turn good habits into muscle memory
AI can move fast on the parts of coding that are clearly defined, but what the thing is supposed to look like still needs to come from you. I’ve been working on a Skill collection called Waza, eight skills mapping to eight habits I think a good engineer should have.
/think makes you think through the technical approach before writing any code. AI writes code fast, but moving fast in the wrong direction just gets you wrong faster. Question the problem first, get the approach right, then let it run. /design helps you design a real product page, no purple-blue gradients and emoji-laden AI templates. /hunt is for debugging, with one rule: don’t touch code until the root cause is named, no try-this-try-that loop. /check is the last gate before wrapping up, walks the diff, fixes what can be auto-fixed, and gathers the rest into questions for you.
The other four are everyday: /read turns any webpage or PDF into clean Markdown for your workflow, /write makes your prose clearer, /learn is a research workflow from gathering material to producing an article, /health runs a checkup on your CLAUDE.md and ruleset, useful when Claude feels off.
Install: npx skills add tw93/Waza -g. The one I’d most recommend for product, business, and ops folks to try first is /design. Drop a screenshot in with /design, and instead of jumping in to edit, it asks you who it’s for, what mood you want, what style you can’t stand, any micro-interactions you want users to remember. Then it goes. Results are typically more stable than just saying “make this look better.”
You can write a Skill yourself
A Skill is just a folder under .claude/skills/ with a SKILL.md describing when to use it and what to do. Claude Code only reads the frontmatter (the trigger description, around 100 chars) at startup, and only loads the full content when the Skill is actually called. So having dozens of Skills installed doesn’t slow startup.
The three types I use most:
Type 1: workflow. Package a fixed sequence you do every time. For example, weekly meeting notes:
```
---
name: weekly-meeting-notes
description: Use when raw meeting notes need to be organized
---
## Output format
**Done this week**: [owner] finished what
**Next week**: [owner] does what, by when
**Open**: blocked on what, needs whose decision
**Action items**: [who] [does what] [by when]
## Rules
- Don't polish, keep the original phrasing
- Missing info gets marked "needs confirmation," don't guess
```
Type 2: checklist. Walk through it before launch, before release, before commit, to prevent omissions. For example, pre-launch:
```
---
name: launch-checklist
description: Run before shipping a feature, confirms nothing's missed
---
## Must all pass before shipping
- [ ] Each acceptance criterion in the PRD confirmed
- [ ] Design and implementation aligned: spacing, copy, interactions
- [ ] Edge states (empty, error, timeout) all handled
- [ ] Analytics events instrumented per spec
- [ ] Verified in staging
## Output
Each item Pass / Fail. Any Fail must be fixed before shipping.
```
Type 3: domain expert. Bake the judgment framework in, so for problems of this kind it walks a fixed path instead of improvising every time. For example, on-call incident triage, or any business SOP you have:
```
---
name: incident-triage
description: Use when an alert fires or a user reports something broken
---
## Collect
- Error screenshot or full error log
- Scope: which users, which page, when did it start
- Recent changes: code releases, config edits, data changes
## Diagnostic matrix
| Symptom | Check first |
| White screen | JS errors → recent releases |
| API timeout | Service monitoring → slow query |
| Bad data | Recent data change → upstream |
## Output format
Root cause / blast radius / fix steps / verification
```
Drop it in .claude/skills/, and when the matching scenario shows up, just say “use weekly-meeting-notes” or “use incident-triage.” You can also have Claude help you write these. Two pitfalls to avoid when writing Skills.
description is the trigger condition, not a feature pitch. “Use when raw meeting notes need to be organized” beats “Turn meeting recordings into structured weekly reports” by a wide margin in trigger accuracy.
One Skill, one job. Don’t bundle review, release, and debug into one. Splitting them gets you more accurate triggering.
## Kami: let AI handle the typesetting
Writing the content is just the first half. Laying it out into something publishable usually takes longer. Kami is an AI typesetting tool I’ve been working on. Hand it your content, say “lay this out as a one-pager” or “make a portfolio,” and it produces a downloadable PDF.
It ships with eight templates: one-pager, portfolio, slides, resume, long doc, letter, research note, changelog. The visual style is consistent: warm parchment background, ink-blue accents, serif typography by default. No need to mess with fonts.
Most useful scenarios: meeting notes laid out as a brief, project status as a one-pager for your manager, your work history as a resume. Used to mean opening Word or Figma and fiddling for half a day. Now you drop the content in, get a first pass that’s already good enough to look at, then fine-tune.
Install: npx skills add tw93/Kami -g
## Claude Design: prototypes without writing code
Claude Design, released by Anthropic in April 2026, is another path: upload a screenshot or document, and it gives you back an interactive prototype, slide deck, or landing page directly. Useful for non-technical folks who want to prototype quickly.
If you don’t want to touch code at all, use this to get something showable first. PMs can sketch a prototype, run a review, then hand the prototype to Claude Code to be turned into real code. Early prototypes don’t have to wait for full design and engineering capacity, you can have something to discuss the same day.
## A few small habits once you’re comfortable
Screenshots are faster than text. To describe a UI issue or reference a design style, just drop the image. Layout, color, hierarchy all come along, less guessing required.
Break tasks small, one at a time. A task you can describe in one sentence almost always gets done correctly. Dump a giant pile of requirements and any one wrong step downstream sends everything off course. Finish and verify one thing before starting the next.
Restart when the conversation drifts. Trying to course-correct a session that’s already drifted just makes it drift more. Clear the context and re-state the requirement, often faster. Picking up the next day, glance at the Recap (the conversation summary auto-generated after /clear) to remember where you were.
Memory remembers your preferences across projects. CLAUDE.md is project-level, you write one per project. Memory is user-level, applies across all projects and all sessions. Just say “remember I want to see the plan first before execution” or “remember to reply to me in English.” It writes to ~/.claude/memory/ and applies on any project from then on. Background you keep restating belongs in here, save yourself the repetition.
Double-tap ESC to edit the previous message. If you misspoke or it drifted, hit ESC twice to jump back to the previous message and edit, no need to restart the session.
## A few safety habits worth building from day one
Have it explain before acting. Add this to CLAUDE.md: “Before running any Bash command or editing any file, explain in one sentence what you’re about to do.” It’ll narrate every step. Not being able to read code is fine, being able to read “I’m about to delete this file” is enough.
Ask about commands you don’t recognize. Don’t approve a command you’ve never seen. Ask “what does this command do, what’s the risk.” Understand it before approving. Don’t copy any command you don’t understand and run it; some of them can quietly download, upload, or leak information.
Don’t practice on production. Local and staging, mess around freely. For anything touching production database or live config, validate in staging first. The cost of one bad SQL or accidental delete is much higher than you’d predict.
Don’t paste secrets directly into chat. For API keys, database passwords, that kind of thing, have them go into environment variables or a .env file. Don’t drop plaintext credentials into the chat window.
One more that’s easy to overlook but really matters: passing tests doesn’t mean it’s safe. AI-generated code can have vulnerabilities. For login, payment, and personal information features, use Clerk or Stripe or similar mature services rather than letting it write from scratch.
## Further reading
1. You Don’t Know Claude Code: Architecture, Governance, and Engineering Practices
2. You Don’t Know Agent: Principles, Architecture, and Engineering Practices
3. You Don’t Know LLM Training: Principles, Paths, and New Practices
4. Claude Code Best Practices - Anthropic Official
5. vibe coding - Andrej Karpathy original tweet
6. Claude Skills are awesome, maybe a bigger deal than MCP - Simon Willison
7. Malleable software in the age of LLMs - Geoffrey Litt
8. Claude Code Starter Pack: Tools, Tutorials & Resources - AI Edge
9. When the Vibes Are Off: The Security Risks of AI-Generated Code - Lawfare
## 相关链接
- [Tw93](https://x.com/HiTw93)
- [@HiTw93](https://x.com/HiTw93)
- [2.5K](https://x.com/HiTw93/status/2049491135522054555/analytics)
- [Kaku](https://github.com/tw93/Kaku)
- [official docs](https://code.claude.com/docs/en/overview)
- [Crash Course Computer Science](https://www.youtube.com/playlist?list=PL8dPuuaLjXtNlUrzyH5r6jN9ulIgZBpdo)
- [Harvard CS50](https://cs50.harvard.edu/x/)
- [INSPIRED](https://www.amazon.com/INSPIRED-Create-Tech-Products-Customers/dp/1119387507)
- [Linux and the Unix Philosophy](https://www.amazon.com/Linux-Unix-Philosophy-Mike-Gancarz/dp/1555582737)
- [The Pragmatic Programmer](https://www.amazon.com/Pragmatic-Programmer-journey-mastery-Anniversary/dp/0135957052)
- [claude.ai](https://claude.ai/)
- [OpenCLI](https://opencli.info/)
- [docs](https://code.claude.com/docs/en/routines)
- [Waza](https://github.com/tw93/Waza)
- [/hunt](https://github.com/tw93/Waza/tree/main/skills/hunt)
- [/check](https://github.com/tw93/Waza/tree/main/skills/check)
- [Kami](https://github.com/tw93/Kami)
- [Claude Design](https://claude.ai/design)
- [You Don’t Know Claude Code: Architecture, Governance, and Engineering Practices](https://tw93.fun/2026-03-12/claude.html)
- [You Don’t Know Agent: Principles, Architecture, and Engineering Practices](https://tw93.fun/2026-03-21/agent.html)
- [You Don’t Know LLM Training: Principles, Paths, and New Practices](https://tw93.fun/2026-04-03/llm.html)
- [Claude Code Best Practices - Anthropic Official](https://code.claude.com/docs/en/best-practices)
- [vibe coding - Andrej Karpathy original tweet](https://x.com/karpathy/status/1886192184808149383)
- [Claude Skills are awesome, maybe a bigger deal than MCP - Simon Willison](https://simonwillison.net/2025/Oct/16/claude-skills/)
- [Claude Code Starter Pack: Tools, Tutorials & Resources - AI Edge](https://x.com/aiedge_/status/2011108297152082250)
- [When the Vibes Are Off: The Security Risks of AI-Generated Code - Lawfare](https://www.lawfaremedia.org/article/when-the-vibe-are-off--the-security-risks-of-ai-generated-code)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:08 PM · Apr 29, 2026](https://x.com/HiTw93/status/2049491135522054555)
- [2,584 Views](https://x.com/HiTw93/status/2049491135522054555/analytics)
- [View quotes](https://x.com/HiTw93/status/2049491135522054555/quotes)
---
*导出时间: 2026/4/29 22:50:30*
---
## 中文翻译
# 你并不了解 AI 编程：非工程师的 Claude Code 指南
**作者**: Tw93
**日期**: 2026-04-29T14:08:59.000Z
**来源**: [https://x.com/HiTw93/status/2049491135522054555](https://x.com/HiTw93/status/2049491135522054555)
---
## TL;DR
AI 编程不仅仅是程序员的专利。
上个月，我为产品、业务和运营团队的同事们举办了一次关于如何上手 Claude Code 的内部分享。那次演示的文稿最终扩充成了这篇文章。
对于非工程师来说，第一道门槛通常是命令行。它看起来像是程序员的专属地盘，但实际门槛并没有想象中那么高。如果你能使用像 ChatGPT 这样的聊天机器人，只要花一点时间和耐心，你就可以开始使用 Claude Code。
一旦掌握了要领，Claude Code 就会开始感觉像一个全能助手：拉取后端数据、为特定问题编写小工具、将分散的文档拼凑成简报、原型化工作流、清理销售报表以及自动化重复性工作。
你是否写过代码并不是决定性因素。当你不再把 AI 视为聊天机器人，而是开始把它当作执行伙伴时，转变就发生了。
这篇文章是一份面向非工程人员的实用指南，旨在帮助大家将 Claude Code 用于实际工作。
## 第一道门槛是命令行
如果你不写代码，那你通常习惯了像 ChatGPT 这样的聊天机器人 AI，初次安装 Claude Code 时可能会觉得有些不适应。过去的工作方式是来回拉锯：你描述你想要的东西，它吐出代码，你复制粘贴到别处去尝试。而在 Claude Code 中，这个中间环节消失了，它直接在终端中运行。
如果你从未使用过终端，可以试试 Kaku，这是我专门为 AI 编程构建的。安装即用，无需折腾颜色或字体。浅色/深色模式跟随系统，Cmd + D 分割窗口，Cmd + Shift + Y 调出文件管理器。对新手最友好的部分是内置的 AI 辅助：当命令失败时它会自动建议修复方案；如果你记不住命令，只需在前面加个 #，然后用普通的英语描述即可。
安装 Claude Code 只需要一条命令，请查阅官方文档，然后 cd 进入你的项目文件夹并输入 claude 即可开始编程。
```
curl -fsSL https://claude.ai/install.sh | bash
```
## 稍微懂点技术能让你事半功倍
如果你不写代码，但想真正用好 Claude Code，光知道如何描述你的需求是不够的。掌握一些概念性的基础会让后续的调试工作容易得多。
了解常见框架是做什么的。大概知道 React、Vue 和 Next.js 解决了什么问题，这样当 Claude Code 使用它们生成代码时，你就不会迷路。
常见软件的基础：终端命令、Git、VS Code、Chrome 开发者工具。当出现错误时，你可以和 Claude Code 一起定位问题，而不是干等着。
几个核心编程概念：函数的作用、变量和状态是什么、为什么要将代码拆分成多个文件。理解这些能让你的需求更精确。
阅读代码和阅读报错比学习写代码回报更快。当它修改了一大块代码时，你可以扫一眼并大致知道发生了什么，这比让它解释要快得多。当错误出现时，别慌，把整个错误信息贴回去问它“这是什么意思，我该怎么修复”。十有八九它会直接指向出错的那一行。
你不需要学到能自己写代码的程度。只要知道这些东西长什么样就够了。花几个晚上看看 freeCodeCamp 或 MDN 的入门教程，或者选一门像《计算机科学速成课程》或哈佛《CS50》这样的免费入门课，你与 Claude Code 的协作体验会有明显不同。
我最推荐给非工程师的三本书，都很好读：《INSPIRED》培养产品判断力，《Linux 和 UNIX 哲学》了解工程哲学，《程序员修炼之道》学习资深工程师的实际思维方式。读过这些书会让与 AI 的技术交流少很多困惑。
## 账号与订阅
账号：在 claude.ai 使用 Google 或邮箱账号注册，这是最标准的流程。
订阅：三个档次。免费版 $0，只能基础聊天，没有 Claude Code。Pro 版 $20/月，解锁 Claude Code，是大多数人的正确入口。Max 版分为 $100 和 $200 两档，分别提供 5 倍和 20 倍的使用量，适合大量日常代码工作。
从 Pro 版开始。如果觉得配额不够再升级到 Max。订阅跟随账号，所以在 iOS 上购买的内容也会在 Android 和网页端显示。
## Claude Code 擅长什么样的任务
我试过相当多的 AI 编程工具，Cursor、Windsurf 和 Codex 都在轮换使用中，但我的主力工具依然是 Claude Code。
它的独特之处在于底层模型本身就很强，而且 Claude Code 的实现将“Harness 模式”发挥到了极致，它会审视整个项目：首先扫描 CLAUDE.md 和目录结构以获取上下文，然后跨文件编辑、运行命令、读取错误、再次编辑，全部自主完成。此外它常驻终端，所以 git、测试、脚本以及你 already 使用的所有工具，它都可以直接调用，无需任何复制粘贴的来回折腾。
它实际上是一个通用 Agent。名字中的“Code”只是反映了它最初针对编写代码的定位。Anthropic 透露，在内部许多非工程团队，如销售、风险、财务，都在用它处理 CRM 数据和客户邮件。如果你真的不想碰终端，官方桌面应用 Cowork 可以直接读写你的下载和文档文件夹，所以像把一堆收据截图变成费用报销单这样的事，一句话就能搞定。
还有一点我觉得非常重要：在写代码时，速度不是关键，准确性才是。生成十分钟然后调试二十分钟，远不如生成二十分钟但能当场验证。
要让结果准确，首先要交给它那些本身定义清晰且易于验证的工作。同时满足这两个标准的任务是最合适的，这就像把工作分配给一个非常照本宣科但技术过硬的工程师。
具体来说，有几个类别：原型和内部工具，你写出需求和展示逻辑，第二天就能有一个能用的版本；处理 CSV 和构建销售报表，把分组和计算逻辑写清楚，几分钟出结果；从数十页长的合同中提取条款、比对版本，这是它真正擅长的文档工作；最后，扔给它一堆链接或 PDF，让它从特定角度提取信息，只要把你想要的格式说清楚就行。
## 只为你自己构建软件
开始“写代码”时最大的阻碍是不知道该构建什么。《纽约时报》专栏作者 Kevin Roose 提出了一个有用的概念：一个人的软件。你不需要为百万人构建东西，你可以只为你自己构建。
他为自己构建了 Stash 来整理链接，构建了 LunchBox Buddy 来准备孩子的午餐。对你来说，这可能是一个将语音笔记转换为会议纪要的工具，或者是一个每天早晨 ping 你三件事的小仪表板。这正是产品和业务人员实际上可以完成的事情，因为没有人比你更了解你日常遇到的摩擦。
从一天到三个月的节奏
不要一开始就试图构建“类似 Notion 的东西”。一个可行的节奏：
第 1 天，试水：让它编辑一个你手头现有的 Excel 或 Markdown 文件。第 1 周，体验：构建一个单页个人主页或日常仪表板，十五分钟就能跑起来。第 1 个月，交付：选一件你每周做两三次的事，把它变成一个命令或一个页面。第 3 个月，升级：选一个“一个人的软件”的想法，为你自己构建一个真正的工具。
## 使用 OpenCLI 将网页操作转化为命令
很多运营工作发生在浏览器中：检查仪表板、发送消息、导出报表。这些大多可以完全跳过 UI，直接调用底层的 API。
OpenCLI 是我的朋友 Cabbi 构建的。它内置了数十个网站的 CLI 适配器，包括 Reddit、X/Twitter、YouTube，外加一套通用的浏览器原语，如点击、输入、抓取、截图。它将网页操作转化为单个命令，Claude Code 可以用一句话调用。
社交聆听：让 Claude Code 调用 opencli reddit 拉取数据，然后分类并提取热门词汇。过去半小时的点击操作现在一句话就能搞定。
情绪摘要：结合 X/Twitter、Reddit 和 HackerNews 的适配器，将对同一关键词在多个平台上的讨论转化为每日报告。
没有适配器的网站：用浏览器原语描述流程，比如打开页面、输入关键词、抓取表格，Claude Code 会将其拼接起来。
Claude Code 还有一个叫 Routines 的功能，它将工作流存储在云端，并通过计划、webhook 或 GitHub 事件触发。我还没重度使用过，但像“每周一早上，运行周报流程”这样的概念确实可以交给它。如果有兴趣请查阅文档。
## CLAUDE.md：先把项目背景写清楚
很多人安装完就开始提问。结果每次都要重申背景，时间久了就烦了。原因几乎总是一样的：没有 CLAUDE.md。
它位于项目根目录，Claude Code 每次启动时都会读取它。把它当作你要给新同事写的入职文档，只不过这位同事每次都从头阅读并严格遵守。
有三点最重要。保持简短，理想情况下在 150 行以内。太长会占用对话额度。直截了当，使用祈使句，跳过那些温和的“我们倾向于……”的措辞。“所有注释用英文”比“团队偏好英文注释”有效得多。让每条规则都可被评判。“代码质量要高”是没用的。“超过 50 行的函数必须拆分”才是你实际能强制执行的。
四条值得保留的规则，直接照用：行动前询问，优先简单，只触碰需要触碰的地方，完成后验证。展开来说：别让它猜你的意图，先明确目标；两行能解决就别写两百行，不要过度工程化；不要重构你没提到的代码；构建和测试通过才算完成，否则不算。
你可以通过修改项目背景来套用这个模板：
```
# Project Background
运营团队的客户仪表板。技术栈：Node.js + Next.js，
前端 React，PostgreSQL 数据库，部署在 Vercel。
PM 是 Alice，设计师是 Bob，后端是我。
# 工作规则
- 所有注释用英文，变量和函数用英文。
- 在进行任何编辑之前说明你打算改变什么，等我确认。
- 对于新功能，编写实现代码，除非我要求，否则不要添加测试。
- 数据库表名使用 snake_case，例如 user_profile。
# 禁止事项
- 不要主动重构我没提到的文件。
- 除非我明确说明，否则不要删除任何文件。
- 未经确认不要为新依赖运行 npm install。
# 压缩时保留
当长对话被自动压缩时，按此优先级保留：
1. 架构决策及其背后的理由
2. 哪些文件被更改以及更改了什么
3. 当前进度状态
4. 尚未完成的 TODOs
```
最后那个“压缩时保留”的部分看起来不起眼，但它能让长会话保持连贯。Claude Code 的上下文超过阈值后会自动压缩，而决策背后的理由通常是首先被丢弃的内容。如果你之前说过“因为负载大所以用 POST 而不是 GET”，压缩后可能就只剩下“用 POST”，理由不见了。下次这个话题出现时，它可能会提出完全不同的方案并自相矛盾。有了这一部分，长会话就不会再自我打架了。
你不需要从头写所有这些。安装 Claude Code 后，只需说“阅读我的项目并为我生成一个 CLAUDE.md”。它会扫描代码、技术栈和结构，交给你一个草稿。你只需微调名称和团队偏好。安装依赖、配置别名、编辑 ~/.claude/settings.json 也是一样，告诉它你想要的效果，让它去弄，比读文档快。把配置工作交出去，把精力留给那些真正需要判断的事情。
## 需求越精确，偏差就越小
模糊：给我建一个客户跟进工具。精确：给我建一个销售跟进工具，单文件网页，数据存储在本地。左侧是显示公司名称、下次跟进日期、状态的列表。右侧是详情视图，包括沟通历史、日期、要点。顶部有三个过滤器：状态、时间、关键词。数据存在于浏览器 localStorage 中，无后端。
精确的版本能让你在同一天得到一个可用的原型。模糊的版本几乎总是需要返工。
这是一个完全精确的例子，是 yetone 为 Claude Code 构建 macOS 语音输入工具编写的需求。你不需要关注代码细节，重点在于每个需求被分解得多么具体。
```
为我用 Swift 构建一个原生的 macOS 语音输入工具：
1. 按住 Fn 开始录音，松开将转录的文本注入到当前输入焦点。
优先使用流式转录（Apple 语音识别框架）。通过 CGEvent tap
全局监听 Fn；抑制 Fn 事件传播以避免触发表情选择器。
2. 默认语言必须是简体中文——开箱即支持中文。菜单栏可切换
到英文、繁体中文、日语、韩语；选择持久化到 UserDefaults。
3. 录音时，在屏幕底部显示一个无边框的胶囊状 HUD：无红绿灯，
无标题栏。使用 NSPanel (nonactivatingPanel) +
NSVisualEffectView (.hudWindow material)。高度 56px，圆角 28px。
左侧显示实时音频波形（5 个由 RMS 电平驱动的垂直条），
右侧显示转录文本（160-560px 弹性宽度）。弹簧进入 0.35s，
文本宽度过渡 0.25s，缩放退出 0.22s。
4. 通过剪贴板 + 模拟 Cmd+V 注入文本。注入前，检测当前输入源：
如果是 CJK 输入源，临时切换到 ABC，粘贴，然后恢复原始输入源。
之后恢复剪贴板原始内容。
5. 接入 LLM 以提高中英混合的识别准确率。使用兼容 OpenAI 的 API
（可配置 Base URL、Key、Model）来优化转录文本。系统提示必须
极度保守：仅修正明显的语音识别错误（例如 "pie son" -> "Python"，
"jay son" -> "JSON"），绝对不要重写或润色看起来正确的文本，
如果看起来是对的，就原样返回。
6. 菜单栏提供一个 LLM 优化子菜单，带有启用/禁用切换和一个设置
入口。设置窗口包含 API Base URL、API Key、Model 字段，以及
测试和保存按钮。Fn 松开后，如果启用 LLM，H
```