
一人公司(OPC, One Person Company)的真实瓶颈从来不是"会不会写代码",而是创始人的注意力带宽。需求、编码、评审、发布、客服全压在一个大脑上,切换成本吞掉了大半产能。Codex 在 OPC 场景中的定位,不是"更快的补全",而是一组可编排、可并行、可校验的执行单元——让一个人同时开多条产线。本文从四个工程动作拆解这套用法。
一人公司最大的隐性成本是"每次都要重新交代背景"。Codex 支持仓库内的 AGENTS.md 作为持久化指令,本质是把创始人的工程习惯写成机器可读的组织记忆——这是 OPC 唯一能规模化的"带人"方式。
# AGENTS.md
## 项目
- Python 3.12 + FastAPI,包管理用 uv,禁止 pip install 直接改环境
- 所有新接口必须有 pydantic 入参/出参模型与 pytest 用例
## 纪律
- 改数据库必须走 alembic,禁止手写 DDL
- 提交前运行 `make check`(ruff + mypy + pytest),失败不得提交
- 不引入新依赖,除非在 PR 描述里写明理由与替代方案
## 不要做
- 不要改 `.github/` 与 `deploy/` 下的文件
- 不要重命名公共函数,先开 issue要点:AGENTS.md 的价值在于把"评审时才想起的规则"前置成生成时的约束。规则越具体,返工越少——这比在 prompt 里重复叮嘱可靠得多。
OPC 的时间应该花在决策上,而非搬运上。Codex CLI 的 exec 子命令支持非交互运行,适合挂进脚本做批处理:批量补测试、批量迁移旧接口、批量处理 issue。
#!/usr/bin/env bash
set -euo pipefail
# 为缺测试的模块批量生成用例,每个模块独立一次 agent 运行
for f in $(git ls-files 'src/**/*.py' | while read -r f; do
[ -f "${f%.py}_test.py" ] || echo "$f"; done); do
codex exec --full-auto \
"为 $f 生成 pytest 用例,覆盖正常路径与两个边界条件。
只新建 ${f%.py}_test.py,不改动 $f 本身。运行 pytest 确认通过。" \
> "logs/gen-$(basename "$f" .py).log" 2>&1 || echo "FAILED: $f"
done要点:--full-auto 允许 agent 自主执行与修改,前提是前面的 AGENTS.md 已划定边界。每个文件独立一次运行、独立日志,单个失败不污染其余批次——这是批处理的基本容错纪律。
一人公司的产能放大器是并行度。用 git worktree 为每个任务开独立工作目录,每个目录跑一个 Codex 会话,互不干扰,最后统一走 PR。
#!/usr/bin/env bash
set -euo pipefail
TASK="$1"
BRANCH="task/$TASK"
DIR="../wt-$TASK"
git worktree add -b "$BRANCH" "$DIR" main
(cd "$DIR" && codex exec --full-auto \
"读取 TASKS/$TASK.md,按其验收标准实现。
完成后运行 make check,把改动 git commit -m 'feat: $TASK'。" \
> "../logs/$TASK.log" 2>&1) &
echo "已派发 $TASK,PID $!"要点:任务先写成 TASKS/*.md 文件(含验收标准),agent 读文件而非读聊天记录——需求文档化本身就是 OPC 的质量保障。worktree 隔离让多个 agent 并行改代码不会互相踩踏。
一人公司没人做 code review,所以门禁必须自动化且不可绕过。这是 OPC 用 agent 的唯一安全阀:agent 的产出与人类 PR 走完全相同的检查。
# scripts/gate.py —— 合并前唯一入口
import subprocess, sys
STEPS = [
["uv", "run", "ruff", "check", "."],
["uv", "run", "mypy", "src"],
["uv", "run", "pytest", "-q"],
]
def run(step: list[str]) -> None:
r = subprocess.run(step, capture_output=True, text=True)
if r.returncode != 0:
print(f"❌ {' '.join(step)}\n{r.stdout}\n{r.stderr}")
sys.exit(1)
def diff_guard() -> None:
changed = subprocess.run(
["git", "diff", "--name-only", "origin/main"],
capture_output=True, text=True).stdout.split()
forbidden = [f for f in changed if f.startswith(("deploy/", ".github/"))]
if forbidden:
sys.exit(f"❌ 触碰禁区文件: {forbidden}")
if __name__ == "__main__":
diff_guard() # 先查禁区,再看质量
for s in STEPS:
run(s)
print("✅ gate passed")要点:diff_guard() 放在最前——先拦截 agent 越界修改部署与 CI 配置,再谈代码质量。门禁是纯代码、纯退出码,不依赖人的记忆,这才撑得起"一人公司"的信任模型。
OPC 对成本敏感,agent 调用必须带预算意识:小任务用小模型或短上下文,只在复杂重构时升级;每次 exec 限定工作目录与允许改动的文件范围,避免 agent 在大仓库里乱逛烧 token。
# 限定范围的一次 exec:只在单文件上下文内工作
codex exec --full-auto --cd src/billing \
"只修改 invoice.py 中的 calc_tax 函数,其余文件不动"Codex 对 OPC 的真正价值,是把"一个人"扩展为"一个编排者 + 若干受约束的执行通道":AGENTS.md 固化经验,exec 批处理重复劳动,worktree 提供并行度,自动门禁兜住质量底线。这四者缺一不可——只有 agent 没有门禁,是事故加速器;只有门禁没有并行,产能上不去。判断标准很朴素:一个任务如果 agent 做完后你还得逐行读才敢合,说明门禁没建好;如果读都不用读就能合,你才真正拥有了第二个自己。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。