日常生產力：行事曆、提醒事項、email 摘要、每日規劃，全部是 Claude Code 黏著原生 Apple app，零 SaaS 訂閱
投資基礎設施：券商 API 串接、持倉異常掃描、選擇權籌碼快照，跑在排程上
沒請員工，沒買 SaaS。系統的邊際成本是每月的 Claude 訂閱費。
如果你想開始
不用一次建完。我的建議順序：
先寫一份最小的 CLAUDE.md：你是誰、專案在哪、有什麼絕對不能做
每次 AI 犯錯，把教訓寫回去（這一步是複利的來源）
檔案變大之後再拆層：規則、記憶、wiki
最後才是多機、多角色
Hoffman 那段訪談還有一句：“Even most people who say ‘Oh yeah I’m using AI’ are not using it seriously enough.” 認真用的意思，不是 prompt 寫得多漂亮，是願意把工作結構打掉重組。
English
CLAUDE.md Is a Score: Running a One-Person Company as an AI Conductor
In an interview, Reid Hoffman said:
“I’m more of a conductor than I am a violin player or a piano player.”
That line stuck with me. When most people say “I’m using AI,” they mean they’re using it to speed up a step: translate a bit faster, autocomplete code a bit faster. That’s not where the real dividing line is. The line is whether you restructure the work itself into something an AI can take over. This post is how I do that, and what the system has grown into after a year.
Two Machines, Two Roles
My system runs on two Macs:
MacBook Pro (M1 Max): the interactive workhorse. This is where I talk to Claude Code, build things, and make decisions.
Mac mini (M1, 8GB): unattended. It runs scheduled jobs — pulling liquidity indicators every Monday morning, sweeping the health of my cron jobs daily, updating futures price levels before the open, and pushing anything anomalous straight to Discord.
Each machine has its own Claude Code agent (I call them Pro CC and Mini CC), and they hand off work state through a shared handoff note. While I sleep, Mini CC is working; when I sit down at my desk, Pro CC picks up where the last session left off from the handoff summary.
CLAUDE.md Is a Score
A conductor doesn’t play the violin, but there’s a full score on the stand. My score is a Markdown file called CLAUDE.md — loaded automatically at the start of every session, defining what this agent can do, where it has tripped before, and how to avoid tripping again.
The point isn’t writing rules. The point is making the rules grow. Every time I hit a trap, the lesson gets written back into the system:
## F-0. Git Discipline (hard rule, added after the pack-swallowing incident)
- Forbidden: `git add -A`, `git add .` — always use an explicit pathspec
- Reason: the cloud-sync tool hardlinks .git/objects/pack/*.pack
into the worktree, so a blanket add swallows the pack and makes
the repo balloon exponentially (this repo once hit 2.0TB)
This rule came out of a real incident: a cloud-sync tool got into a fight with git, and the repo ballooned to 2TB. After I fixed it, the lesson became a hard rule, and no agent session repeats the mistake. The longer I use it, the better the system understands me — and that’s worth more than any model upgrade.
Memory in Three Layers
A single giant file blows up your token budget, so memory is layered by reusability:
Episodic memory: dated session logs, for tracing “what happened that day”
Semantic memory: knowledge reusable across sessions, organized by topic
Hard rules: constraints that hold no matter the context
Once episodic memory piles up enough, it gets distilled into semantic memory; semantic memory then condenses upward into wiki articles. Add lazy loading (a session only reads the core-identity file at startup, and loads other modules on demand), and token consumption drops about 70% compared to one big file.
Four Roles, Each With a Boundary
When I was building an iPhone keyboard app, I split the agent into four roles: PM analyzes requirements and writes the spec, Designer produces the mockups, Engineer implements, QA reviews and gatekeeps. The key is that the boundaries are locked in by policy: the PM never touches code, only the Engineer can commit, QA blocks the release.
This isn’t a role-playing game. The boundaries exist for the same reason they do on a human team: the person who wrote the code shouldn’t sign off on their own code. One of the iron laws in my verification discipline is “the author never verifies their own work” — an implementer’s output only counts once another independent agent, or I myself, has run it against real input.
What This System Actually Produces
Commercial output: a client’s video subtitles, squeezed from 2-3 hours of manual correction per video down to 15-30 minutes of automation (that pipeline deserves its own post, which I’ve already written)
Daily productivity: calendar, reminders, email summaries, daily planning — all of it Claude Code gluing native Apple apps together, zero SaaS subscriptions
Investment infrastructure: brokerage API integrations, position-anomaly scans, options positioning snapshots, all running on schedule
No employees, no SaaS purchases. The marginal cost of the system is my monthly Claude subscription.
If You Want to Start
You don’t have to build it all at once. The order I’d suggest:
Write a minimal CLAUDE.md first: who you are, where your projects live, and what must never happen
Every time the AI screws up, write the lesson back in (this step is where the compounding comes from)
Once the file gets big, split it into layers: rules, memory, wiki
Multiple machines and multiple roles come last
There’s one more line from that Hoffman interview: “Even most people who say ‘Oh yeah I’m using AI’ are not using it seriously enough.” Using it seriously doesn’t mean writing prettier prompts. It means being willing to tear your work down and rebuild its structure.