我最近在认真考虑一件事：做一家一人公司，也就是 OPC。
不是一个人接几个项目，也不只是做出一款产品。我想试试，一个人借助 AI，能不能逐步建立产品、营销、销售和服务能力，最终让一套业务持续运转。
但真准备开始时，我先撞上的不是公司注册，也不是商业模式，而是一个更基础的问题：一个人的有限资源，到底该怎么分？
公司可以把不同工作交给不同的人，还可以用预算换人、换技术、换渠道。一人公司也能购买外部服务，但最后做取舍的还是同一个人。
投入一件事的也不只是时间。精力、注意力，以及真金白银花出去的钱，都是投入。做产品、写内容、找用户、处理反馈，会同时争夺这些有限资源。
如果我说不清资源去了哪里，就很难判断自己是在推进一门生意，还是只是在忙。
这让我想到了马斯克。
Timeboxing 能管时间，但 OPC 要管的是投入
研究时间管理时，我先注意到了 timeboxing。它不是马斯克发明的理论。借用《时间盒》作者 Marc Zao-Sanders 在个人效率场景下的解释，timeboxing 可以理解为把待办事项预先放进日历：为一项任务留出一段固定时间，时间到了就交付当前结果，或者重新安排下一步。它解决的是“我打算做什么”与“我实际把时间留给了什么”之间的落差。
马斯克经常被二手文章拿来解释这种方法，他对如何在多家公司之间分配注意力的公开发言更有参考价值。
2023 年，在《华尔街日报》CEO Council Summit 上，马斯克谈到自己怎样在 Tesla、SpaceX 和当时的 Twitter 之间安排工作。据 CNBC 对这次活动的直接报道，他说上下文切换很痛苦，因此会尽量让某一天主要处理一家公司的事情。但现实中，几家公司的工作仍然会交叉进来。
他还说，排程难以完全交给别人处理，因为别人不可能完全知道当下的优先级。
我当然复制不了他的工作强度，也没必要模仿他的具体作息。真正给我启发的是两点：
- 给任务划出时间边界，可以减少计划停留在待办清单里；
- 比排满日程更重要的，是减少上下文切换，并判断什么值得投入注意力。
这恰好是一人公司绕不开的问题。一个人能做的事情越多，越容易同时开很多坑。AI 又进一步降低了启动成本，想到一个功能、一个选题、一个产品，都可以立刻开始。最后限制我的，可能不再是“有没有人干”，而是有限的时间、精力、注意力和资金该投在哪里。
Timeboxing 给了我一个起点，但只记录日历还不够。
一项工作占用了两个小时，不代表这两个小时同样有效。有些任务需要高度专注，有些只是机械处理；有些项目投入了很多时间，却没有投入获客预算；有些功能持续消耗精力，最后并没有推动当前目标。
所以我想先给自己做一套综合管理工具，把目标、日程、待办、时间记录、资金支出和复盘放到一起，再逐步加入对精力与注意力投入的记录和估算。我要看到的不只是“今天做了什么”，还包括：
- 时间、精力、注意力和资金分别投向了哪些目标；
- 原来的计划与实际投入有什么偏差；
- 这些投入带来了什么结果；
- 下一阶段该继续、减少，还是停止什么。
量化不是为了把自己变成一张报表，而是为了反复校准：我口头上认为重要的事情，是否真的得到了资源。
这个想法后来又和 Dan Koe 的一段产品观接上了。
先解决自己的问题，再把过程做成产品
Dan Koe 长期讨论一人业务。2026 年 1 月 3 日，他发布了 《How I’d build a one-person business if I started over in 2026》。他在文中把产品描述为曾经解决自己问题、带来改善的过程。我对这段话的理解是：产品可以从自己解决过的问题和已经验证过的过程出发，再把它做成别人能够使用的东西。
Dan Koe 认为，借助 agentic AI，一个人兼任营销、销售、产品和设计等职能，比过去更可行。他的另一个判断是，AI 降低了制作内容、资产和部分软件产品的门槛，但更难复制的部分，仍是个人积累的兴趣、经历、洞见和具体知识。
这与我的处境正好接上了。
我一直被“时间不够用”困扰。但准备做 OPC 后，我发现这个说法太笼统。真正的问题可能是资源配置失真：时间花了，注意力被切碎了，精力耗掉了，钱也投了，却没有形成可以复盘的记录，更不知道这些投入是否推动了目标。
我需要为接下来的一人公司实验建立一套个人经营系统。与其继续拼凑几个互不相连的工具，不如先把我需要的方式做出来，再看它是不是也能解决其他人的问题。
于是有了 BOXUS.ai。它从时间管理切入，但我真正想做的，是把一个人的目标、任务和资源投入连接起来。
但当我准备把这个想法做成产品时，另一个老问题又回来了：谁来开发？
AI 编程先补上产品生产力
我虽然会写程序，但是写代码不是因为热爱。
十年前，我想做互联网产品，但找不到合适的技术合伙人，也没钱请人，只能从零开始学开发。
代码对我一直是手段。我真正想做的是产品，是解决实际问题。只是过去从一个想法走到一个能用的产品，中间隔着需求、设计、前端、后端、测试和上线。没有团队，这些工作就只能自己逐项补齐。
写了十年以后，AI 改变了这条路。
我现在依然是一个人，却可以把过去分散在多个角色之间的大量执行工作，放进同一条协作链路里。人没有变多，产品研发的组织方式变了。
过去做一个小型产品，需求、设计、前端、后端和测试需要在不同角色之间交接。需求没有确定，设计无法继续；设计稿没有出来，开发就要等；接口发生变化，前后端还要重新对齐。
在 BOXUS.ai 的开发过程中，我感受最明显的变化，是这些工作的连接方式。
我使用 OpenCode 配合不同模型推进项目。OpenCode 是一个开源 AI 编程 Agent，可以在权限配置与审批规则允许时读取项目、修改文件和执行命令。这意味着我不必从聊天窗口复制一段代码，再自己寻找该放进哪个文件。AI 可以直接进入项目上下文，提出方案、执行修改、运行测试，再根据结果继续排错。
需求分析、交互设计、系统拆分和测试并没有消失。变化在于，其中一部分执行被模型接走，原来按岗位展开的流程，被压缩成了一个人与 AI 反复对齐、执行和验收的过程。
对我来说，过去最常见的问题是“下一项工作谁来做”，现在更常见的问题是“我能不能把下一项工作定义清楚”。
BOXUS.ai 不是一句提示词生成的
如果把“一人开发团队”理解成给 AI 一句话，然后等它生成完整产品，很快就会失控。
BOXUS.ai 的实际开发，更接近带着一支速度很快、但必须持续管理的执行队伍。
先把模糊的问题讲清楚
最初的问题看起来很简单：每天觉得时间不够用，回看一天时却说不清时间花在了哪里。
继续往下拆，问题就不只剩时间。计划里的优先级是否真的得到了注意力？某项工作消耗了多少精力和资金？投入之后有没有产生预期结果？如果没有，下一轮应该调整目标、做法，还是停止投入？
我先让 AI 帮我整理用户场景、现有解决方式，以及一个最小版本需要验证什么。AI 可以快速展开材料，但哪些观察是真需求，哪些只是听起来合理，仍然需要我判断。
这一步不是为了生成一份很长的报告，而是把“时间不够用”的模糊困扰，收紧成一个可以验证的问题：能否把目标、行动、资源投入和结果连起来，帮助一个人持续校准自己的 OPC 实践。
把产品拆成可以验收的任务
方向确定以后，我继续拆用户故事、核心流程、功能优先级和版本边界。
如果只给一句“帮我做一个时间统计功能”，AI 不知道用户是谁、为什么需要这个功能、当前流程是什么、不能破坏哪些已有能力，也不知道做到什么程度才算完成。它只能用概率补上这些空白。
现在我给任务时，通常会交代五类信息：
- 背景和当前问题；
- 使用者与具体场景；
- 希望改变的结果；
- 现有代码和技术约束；
- 验收条件。
我也不会让 AI 拿到需求后立刻大改。先让它阅读相关代码并提出方案，我确认拆分和影响范围，再进入实现。
OpenCode 自带的 Plan 与 Build 思路，正好对应这两步。按照其官方文档，Plan 用于分析和规划，默认会在文件修改和 Bash 命令执行前请求批准；Build 则是默认的开发 Agent，启用全部工具。
一次只推进一个可检查的变化
把整个产品一次性交给 AI，表面上省事，实际很容易失控。它可能同时改动数据结构、页面和接口。等结果偏离预期时，很难判断问题从哪里开始。
我更常用的节奏是：
- 先拆模块；
- 再拆成单个功能或问题；
- 确认方案和影响范围；
- 让 AI 实现；
- 查看改动并运行测试；
- 确认后再进入下一项。
任务变小，不只是为了让模型答得更准，也是为了让我仍然看得懂项目发生了什么。
传统团队里的需求评审、设计交付和开发验收没有凭空消失。它们变成了高频、短周期的人机往返。
我不再亲手写完，但必须看得懂结果
AI 接过更多执行以后，我的角色发生了变化。
以前大量时间花在查语法、写重复代码、补页面和对接口。现在我更常做的是定义问题、拆任务、看方案、检查改动和决定是否上线。
但这不意味着人的工作更少了。过去可以分给不同角色的判断，现在集中到了一个人身上。
我至少要守住三件事。
-
第一是上下文。AI 不知道我脑子里默认的产品逻辑。需求里省略的背景，它会自己补。补对了像是理解，补错了也可能生成一套结构完整的错误方案。
-
第二是改动范围。Agent 能读写文件、运行命令，因此可以直接参与项目执行。这种能力也需要控制。对不熟悉的部分先只读分析，对删除、提交和部署等影响较大的动作保留人工确认。
-
第三是验收。代码能生成，不等于功能已经完成；测试通过，也不等于用户路径一定成立。我会分别检查代码改了什么、系统有没有受到影响，以及用户能不能走完真实流程。
AI 可以参与检查，但“可以上线”的决定仍然要由人做。
十年经验，从编码迁移到了判断
AI 写的代码越来越多以后，一些手上的能力确实可能变弱，比如对语法细节的即时记忆和连续敲代码的熟练度。
但过去十年的开发经验没有因此失效。它从直接生产代码，迁移到了系统拆分、风险识别和结果判断。
面对一个实现方案，我需要判断它是否符合现有架构；面对一个界面，我需要判断用户是否知道下一步该做什么；面对一组改动，我需要判断它解决了问题，还是只把复杂度挪到了别处。
这些能力不能靠一句提示词临时补齐。没有开发经验的人也能借助 AI 做出产品，但项目越复杂，越需要建立对代码、系统和测试的基本理解。否则 AI 执行得越快，人越可能失去对结果的控制。
所以，我理解的**“一人开发团队”不是一个人模拟所有岗位，也不是让 AI 自动完成全部工作**。
它是一种新的研发分工：AI 承担更多搜索、生成、修改和重复执行，人负责提出问题、提供上下文、划定边界、验收结果，并对最终交付负责。
产品做出来后，OPC 才刚刚开始
BOXUS.ai 对我有两层意义。
第一层，它是我正在为自己搭建的一套个人经营系统。BOXUS.ai 目前从时间管理切入，我希望逐步把时间、精力、注意力和资金的投入及其结果放进同一套复盘框架。只有看清这些资源投向了哪里、产生了什么结果，我才有可能持续推进产品、内容和经营，而不是只让自己一直忙下去。
第二层，它验证了我能不能借助 AI 建立产品生产能力。至少在研发这一段，过去需要等待团队协作的很多工作，现在可以由一个人连续推进。
但如果目标是做一家 OPC，完成产品生产闭环只是起点。
当“怎么把产品做出来”不再是唯一瓶颈，我接下来必须把同一套投入逻辑用到经营上：这个产品为谁解决问题，我准备把多少注意力和预算投向哪些渠道，怎样判断触达是否有效，用户为什么愿意尝试、留下和付费，以及这些结果如何回到下一轮资源配置。
这不是在研发流程后面补一个“运营”岗位，而是另一套完整的经营闭环：定位、触达、转化、交付、留存和收入。
AI 同样可以参与这些环节，但它不能凭空带来客户，也不能替我证明这是一门成立的生意。
所以，一人开发团队只是我的 OPC 起点。下一步，我要研究的是：一个人加 AI，怎样把做产品的能力继续推到获客和经营，让 BOXUS.ai 从“我做出来的工具”，变成一套能够持续运转的业务。
