一个人的 game jam:一份需求,四路同时开工
一个人参加 game jam,周五晚上有 bug 要修,没图标,也没音乐。你只写一份需求,Octuo 把活分头交给你自己的两个 Codex 账号、一个图像工具和一个音乐服务,逐路跟进,最后给你一份汇报;需要你拍板的事会单独提醒你,登录和批准仍由你来。
一个人参加 game jam,周五晚上有 bug 要修,没图标,也没音乐。你只写一份需求,Octuo 把活分头交给你自己的两个 Codex 账号、一个图像工具和一个音乐服务,逐路跟进,最后给你一份汇报;需要你拍板的事会单独提醒你,登录和批准仍由你来。
把“完成”写成 agent 能自己证明的检查:一个可衡量的终点、怎么证明、哪些东西不能动,再加一个上限。本文讲 Claude Code 和 Codex 的 /goal 怎么用、agent 说做完后你还要查什么,以及 Octuo 适合放在哪里。
Six lines to write into the brief for a recurring data pull (source, period, fields, what to do when the source changes, output name and a sanity range) so later runs stay comparable with the first.
How to write a one-page project kickoff covering purpose, what done looks like, fixed and open constraints, who decides, check-ins and where things live, before the first task is handed over.
How to build a one-page voice sheet from your own writing (samples, sentence habits, word lists, openers and hard limits) so drafts from any helper need fewer edits, and how to test and maintain it.
How to ask for a one-page meeting pre-read built around what you will be asked to say or decide, in six parts you can read in about three minutes.
A two-minute trim before you paste an email thread into a brief: five things to leave out, how to replace rather than delete, and a one-line note that tells the helper the gaps are deliberate.
A four-question filter for deciding which tasks to hand over whole, which to keep and which to split, so the hard-to-undo, personal and judgment-heavy parts stay with you.
Five quick edits that turn a rambling voice note into a brief a helper can act on: put the outcome first, separate facts from wishes, cut repeats, add the obvious and end with a done line.
How to spot a conversation that has gone stale and restart it with a six-line note covering the goal, decisions, rejected options, current state, open questions and next step.
Four levels of finish (rough, working, usable and final), how to name the one you want in the first line of a brief, and how to match your review to each level.
A five-step method for sorting requirements into must, should and nice, turning musts into testable lines and asking for options in a simple pass-or-fail table.
How to turn a brief that worked into a reusable template in about ten minutes: labelled blanks, wording kept as it was, a note on what changed last time, fixed versus varying parts, and an owner and date.
Three checks for every point where one step's output feeds the next (shape, completeness and assumptions), plus a four-line handover note and a simple rule for who checks what.
Why to build a checkpoint into a long job, what a useful partial result should contain and where to place the pause so a change of direction is still cheap.
How to build a small invented or masked sample with the same shape as your real data, so you can brief a helper without handing over anyone's personal details.
Five habits for sending several requests in one message so none gets lost: one request per number, order by need, mark dependencies, ask for replies by number, and quote numbers in follow-ups.
How to hand over one good example with clear notes on what to copy, what to change and why it works, so a helper matches your style without reusing old details.
A ten-minute postmortem for a handed-off job that came back wrong: check the brief, the inputs, the fit, the check and the scope in order, and change one thing at a time.
How to write a one-page project glossary: which words belong in it, a four-line format for each entry, where each word is used, words to avoid, and how to hand it over with every task.
How to write down a repetitive browser chore so anyone can take it over: where it starts, the steps as verbs, what done looks like, what must not happen, and what comes back to you.
A five-part brief for handing off research: the question and the decision it feeds, scope, source rules, the shape of the answer, and what would change your mind, with a full example.
Four sentences that describe a small interactive view clearly enough to lay it out: who uses it and when, what it keeps, what you do with it, and what stays in view.
A five-part bug-report brief that a coding tool, a new teammate or you next week can start from: what you saw, minimal repro steps, where to look and not touch, how you'll know it's fixed, and what to send back.