One-Computer Company: A Real Playbook For Running Solo On Grok Bot｜ZER
输入“/”快速插入内容
One-Computer Company: A Real Playbook For Running Solo On Grok Bot｜ZER
One-Computer Company: A Real Playbook For Running Solo On Grok Bot｜ZER
用户3931用户3931今天修改
导读
本文适合独自经营业务的独立开发者与一人团队阅读。作者指出同一账号下的多个 Bot 共享同一台云端电脑的文件与登录状态，安全边界必须靠录入凭证的范围来切分，无法指望角色名称防范越权。落地时建议优先交接获客调研与日常行政这类低风险琐事，且所有外发动作都要前置人工审批门。读完可以先只配置一个处理订单跟进的 Bot，仅绑定单个系统的账号，跑满两周草稿审核再决定是否增加角色。理解文中的凭证防护与审批拦截机制，可以搭配知识库的 4.4 权限、安全与人闸 一并阅读。
Every pitch for running a company solo with AI agents leans on the same image: hire one agent per job, watch an org chart fill itself in without a single human resume. Grok Bot, the always-on agent product SpaceXAI (the company Elon Musk folded xAI into this July) pushed into public beta on August 11, 2026, makes that image tempting, and if you take it literally, wrong in a way that actually matters. Read the product's own security documentation and the picture flips: you are not staffing five separate hires. You are opening five conversations on one shared computer, and the gap between those two mental models is most of what decides whether this actually works for a one-person business.
What Actually Launched On August 11
Strip away the launch-week enthusiasm and the mechanics are fairly plain. A Bot runs as a computer-use agent: it gets a browser, a terminal, and a filesystem, and it operates your actual tools the way you would, by clicking, typing, and reading screens, rather than calling a clean API. That matters more than it sounds like it should, because most of the software a solo operator actually depends on, a supplier's ordering portal, a marketplace seller dashboard, a bank's business login, was never built with an API or an MCP connector in mind. A Bot doesn't need one. It signs in with credentials you provide and works the interface directly.
It also keeps working after you close the laptop. The Bot runs on infrastructure SpaceXAI hosts, not your machine, and it comes back to you specifically when it hits a step it's been told requires a human, not on a fixed schedule and not for every step. Multiple Bots on one account can coordinate with each other, loosely organized around what the company describes as a "chief of staff" pattern: one Bot supervising, several specialists underneath it handling inbox triage, expense processing, recruiting logistics, bug fixes, passing work back and forth in shared threads instead of you manually routing every task yourself.
One line from someone who worked on the product before launch is worth sitting with longer than the marketing copy around it: most AI gets you to ninety percent done, and the actual difference here is that the work lands where a human would put it, inside the real tool, not in a draft waiting for you to copy it over by hand. That's the entire pitch, compressed. Whether it holds up outside a controlled demo is a separate question, and a little over two weeks into a public beta with no independent reliability testing published yet, it's still an open one.
The Detail That Changes The Whole Plan
Here's what the org-chart pitch skips, and what SpaceXAI's own documentation says in plain language: every Bot on your account shares one cloud computer. Not five machines standing in for five hires. One machine, with one filesystem, one set of browser sessions, and one command-line credential store, and every Bot you create can reach all of it. The company's own security guidance states this outright: "Do not use separate Bots as a security boundary."
Sit with what that actually means for a solo operator. In a real company, a sales hire cannot open payroll, not because they're more or less trustworthy than anyone else, but because they were never issued a badge for that door. Grok Bot has no doors between roles unless you build them yourself, and you build them by being genuinely disciplined about which logins you ever type into that shared machine in the first place, not by naming one Bot "Sales" and another "Ops" and assuming the names are a wall. If a Bot gets fooled by a malicious page into leaking a credential, or simply misreads an instruction and acts in the wrong tool, that credential and that access were available to every other Bot on the account anyway, because they were always sharing the same desk.
That's the actual starting principle for everything below: scope by credential, not by role label. Whatever you never hand that shared computer, no Bot can touch, no matter what you called it.
Why This Isn't Just Better Zapier
It's worth being precise about what makes this different from the automation stack you may have already tried and half-abandoned. A Zapier-style workflow needs a clean API on both ends, a trigger and an action some engineer already built a connector for. A huge share of what a solo operator actually spends time on lives outside that world entirely: a supplier's ordering system with no public API, a marketplace dashboard that only exists as a webpage, a bank portal that was never going to expose one. A Bot works those the way a person does, by opening the page, reading it, and clicking through it, which is exactly why it can pick up tasks a decade of no-code automation tools were structurally unable to touch.
That same capability is the source of its main technical weakness. A page redesign, a fresh CAPTCHA, or a login flow that suddenly adds a verification step can stall a Bot in a way that would never touch an API call, because there's no stable contract underneath it, just a website that happens to look a certain way today. Treat that as the trade for reach into places APIs never went, not as a flaw that disqualifies the approach.
Four Jobs Worth Handing Over First
Four roles are the sensible place to start, not because they're the only ones a Bot can do, but because they're the ones where a mistake is cheap and a review is fast.
Growth and outreach research. A Bot can research accounts, judge which ones look like a genuine fit rather than a surface match, and draft outreach that references something specific and true about the account instead of a mail-merge field. Keep it in draft-only mode from day one, using the platform's own Require Approval rules to force a hard stop before anything reaches an inbox that isn't yours. Nothing about this role needs write access to more than your CRM and a drafts folder.
Operations and admin. Scheduling, invoice and expense processing, onboarding checklists, the correspondence that has to happen but never needs a creative decision. This is genuinely the best place to start precisely because it's boring: SpaceXAI's own teams reportedly piloted this exact category internally before launch, on data cleanup and hiring logistics, and boring, repetitive, low-consequence work is where a machine that doesn't get tired or distracted earns its keep fastest.
Content execution. A Bot can turn a content calendar you've already decided on into scheduled posts and copy variations across channels, and watch early engagement so you're not manually refreshing four platforms a day. It should not be deciding what the calendar says. Positioning and voice are judgment calls, and judgment calls belong in the next section, not this one.
Shipping and maintenance. For a solo operator with any codebase, a Bot can reproduce a reported bug, apply a small fix, and file the ticket, working through its own terminal much like SpaceXAI's internal teams reportedly used it before public launch. Keep this one on the shortest leash of the four. Code failures compound silently in ways a bad email draft simply doesn't, and a change that looks fine today can surface a problem three unrelated changes later.
What Never Leaves Your Desk
None of the four roles above include the actual decisions: which market to chase, which risk is worth taking, whose word you trust enough to act on without checking first. That isn't a temporary gap the next model update closes. A Bot has no stake in the outcome of a bet it recommends and no way to weigh a risk against a life it isn't the one living. The entire value of handing over the four roles above is that it clears the routine noise competing for your attention, so the decisions that actually need you get your real focus instead of fighting for scraps of it against work that never needed a human in the first place.
A Worked Trajectory
Concretely, here's a realistic run for a solo operator selling a physical product online.
Weeks one and two, they hand the shared computer exactly one Bot, scoped narrowly to order-status replies and shipping-carrier follow-ups, and log nothing else into that machine yet. Every reply sits in an approval queue. Roughly half the drafts need a real rewrite before they're usable, not because the underlying capability is weak, but because the brief they gave it was thin.
Weeks three through six, the brief gets rebuilt around three real past emails to imitate and an explicit description of tone to avoid, not just tone to use. Draft quality jumps noticeably, and review turns into a skim instead of a rewrite. Only now does a second Bot get added, checking reorder points against the supplier portal, still under a tight approval rule, still with no access beyond that one login.
By month two, with two Bots each earning trust on their own record, on a shared machine whose credential list has grown by exactly two logins and not twelve, a third gets added for social scheduling against a calendar they set themselves. The scorecard by this point stops being "is this working" and becomes "which of these three jobs now takes under fifteen minutes a day to review," and that number, not enthusiasm, is what decides whether a fourth role gets added at all.
Where People Get Burned
A handful of mistakes show up predictably, and most trace back to the same root cause: treating the shared-computer reality as a technicality instead of the actual operating constraint it is.
Granting broad access on day one because narrow scoping felt like friction. It's slower to set a Bot up with exactly the two logins it needs instead of your whole password manager, and it's the only version of this that stays safe on infrastructure explicitly not designed to wall roles off from each other.
Assuming separate Bots mean separate consequences. They don't, by the product's own admission. A Bot named for one job and a Bot named for another are two screens on the same desk, not two employees behind two locked doors.
Losing track of the usage meter. The subscription price feels flat, like a SaaS seat, but it isn't a hard ceiling. Once whatever weekly allowance comes with your tier runs out, overage bills at the underlying model's standard rate, in Grok 4.6's case roughly two dollars per million input tokens and six dollars per million output tokens, and an agent that keeps working while you sleep is, by definition, a heavier token consumer than a chat window you close between questions.
Treating a declined approval as if it undid something already done. An approval gate stops a proposed action before it happens. It has no power over a step that already landed a turn earlier. The gate is a checkpoint, not a rewind button, and the workflow only stays safe if the checkpoints sit in front of the actions that would actually hurt to get wrong.
What It Actually Costs
Grok Bot isn't sold on its own with a simple per-task price. It rides inside SpaceXAI's SuperGrok subscription, on the higher tiers, and inside select Cursor plans, with a weekly usage allowance included and metered overage on top once that allowance runs out, priced at the underlying Grok 4.6 model's standard API rate.
The honest comparison for a solo operator isn't Bot versus nothing. It's Bot versus a part-time contractor for that exact same single job, and the real advantage isn't that a Bot outperforms a person at any one of these roles. It's that the cost of finding out whether a given role is even worth staffing at all drops to whatever your setup time and a subscription you may already be paying for cost, instead of a hiring process and a monthly commitment you're locked into before you know whether delegating that specific job was the right call.
Keep A Running Scorecard, Not A Vibe
Once more than one Bot is live, the useful habit isn't checking whether each one still feels good. It's a short, honest monthly note per role: how many real hours it saved compared to doing the task by hand, how much editing its output still needs before you'd actually send or ship it, and whether your trust in it is climbing, flat, or quietly sliding. That last question catches the one failure pattern that's easy to miss: a role that was genuinely excellent at setup, which is exactly what makes you stop reviewing it as closely three months in, can drift as its inputs change, a new competitor with an odd site layout, a product line the original brief was never written around, without ever announcing itself. A role that keeps failing the same way despite real attempts to fix the brief isn't a reason to blame the tool. It's information that this specific job, in this specific business, may just be a poor fit for this kind of delegation, and that's a legitimate finding, not a setback.
The Beta Seams, Honestly
This is genuinely early. A little over two weeks past a public debut is not enough time for independent reliability data to exist yet, whatever the launch-week hands-on impressions say. Access currently runs through desktop and iOS, with Android still pending. Enterprise-tier access sits behind a waitlist rather than open signup. And because the underlying approach is computer use, clicking and typing through real interfaces instead of calling a clean API, it's inherently more brittle against a redesigned page or an unexpected CAPTCHA than an API integration would be. Expect occasional friction as a normal cost of this approach, not a sign the whole idea failed.
Build the current version of this playbook around what the product reliably does this week, not around where it's headed. Improvements are a bonus that expands what's possible later. They aren't a foundation your current business should be standing on yet.