调度智能体
拆解目标，维护优先级、依赖、预算和进度。
- 交付物
- Paperclip 任务、依赖、验收条件
MIEMIE · V1.0 · 个人交付系统
把一个想法，稳定地变成可运行、可评审、可迭代的产品
LifeOS 管方向，Paperclip 管任务与预算，五个 Codex 智能体协作执行，GitHub 保存事实，Nimbalyst 让原型和 Diff 可见。
01
工作架构
一条主链路贯穿目标、执行、交付与学习；条件能力只在问题出现时加入。
方向LifeOS长期目标与项目选择
控制台Paperclip任务 · 角色 · 依赖 · 预算 · 进度
执行Codex 专业团队调度 · 架构 · 原型 · 开发 · QA
代码事实GitHub分支 · PR · CI
可视化评审Nimbalyst原型 · 文档 · Diff
Agent Skills 是方法层：把审查、测试、调试和发布写成可复用的执行规范，供各角色按任务调用。
02
每类事实只放一个地方
减少重复记录和状态冲突。其他工具可以引用，但不复制维护同一份事实。
| 系统 | 唯一负责的内容 | 它回答的问题 |
|---|---|---|
| LifeOS | 长期目标与项目方向 | 为什么做、何时做 |
| Paperclip | 任务、依赖、角色、预算与进度 | 谁在做、做到哪一步 |
| GitHub | 源码、分支、提交、PR 与 CI | 代码发生了什么变化 |
| Nimbalyst | 原型、产品文档与 Diff 评审 | 用户会看到什么变化 |
| Agent Skills | 审查、测试、调试等工程方法 | 智能体应如何执行 |
03
五个智能体，一套交付责任
角色按产出物交接，不用长篇对话猜测彼此进度。预算比例是首轮运营假设。
软件架构师
界定系统边界、关键接口和技术风险。
- 交付物
- 架构说明、关键决策、接口契约
原型设计师
把需求变成可评审的界面、状态和交互。
- 交付物
- Nimbalyst 原型、页面状态、交互说明
软件开发者
在独立分支或 worktree 中实现任务并自检。
- 交付物
- 代码、提交、Pull Request、局部验证结果
QA 工程师
按风险验证行为和回归范围，给出交付结论。
- 交付物
- 测试证据、缺陷、发布建议
04
标准七阶段 SOP
每一步都有负责人、动作和完成条件。完成条件成立后，任务才进入下一阶段。
- 01
选择本周项目
你 + LifeOS从长期目标中只选当前值得推进的结果，写清成功标准、截止时间和停止条件。
完成条件形成一页项目简报。
- 02
进入任务系统
调度智能体 + Paperclip拆分里程碑与任务，标记负责人、依赖、预算和验收条件；任务状态以 Paperclip 为准。
完成条件首个可交付里程碑可以启动。
- 03
架构与原型并行
架构师 + 原型设计师架构师确定边界与接口，设计师在 Nimbalyst 完成关键路径和状态，两者相互校验。
完成条件代码边界和用户路径没有冲突。
- 04
分支开发
开发智能体 + Codex每项任务使用独立分支或 worktree。Codex 读取任务、仓库规则和 Agent Skills 后实现并自检。
完成条件代码、提交和局部验证结果齐全。
- 05
按风险验证
QA 智能体开发中只跑受影响测试，里程碑做集成检查，最终交付才运行完整测试、构建、lint 或 E2E。
完成条件风险有证据覆盖，已知问题有明确处理。
- 06
人工交付门禁
你 + GitHub在 GitHub 查看最终 Diff、测试结论和预览；范围、体验和商业取舍由你决定。
完成条件合并 Pull Request，并确认线上结果。
- 07
经验回流
调度智能体把可重复的方法沉淀为 Agent Skill，把长期有效的项目结论回写 LifeOS。
完成条件下次同类任务能更快、更稳地完成。
05
条件能力：需要时再启用
这些工具有明确价值，但不应成为每个任务的固定步骤。复杂度必须由真实问题触发。
Code Graph RAG
启用：大型、陌生、多语言代码库中，调用关系已难靠普通搜索判断。
边界：小项目或局部改动不启用。
Semantica
启用：资料跨多个项目，需要实体关系、来源引用和决策追溯。
边界：个人项目早期先用仓库文档。
ComfyUI
启用：产品需要稳定复用的图片、视频或视觉素材生成流程。
边界：不承担代码任务编排。
Prime Agent
启用：任务耗时很长，需要独立的递归执行与验证运行时。
边界：它是特殊任务工人，不替代 Codex 主执行链。
T3 Code
启用：需要额外的多智能体控制界面，并愿意维护另一套操作入口。
边界：Paperclip + Codex 已够用时不增加。
不进入基础设施：Ladybird、TradingAgents、WeatherNext 是浏览器、市场研究和天气预测项目。它们可以作为业务代码或研究案例，但不承担个人编码工作台的基础能力。
06
验证与预算
把成本花在会改变交付结论的检查上。开发阶段快，风险节点严，最终交付有证据。
分层验证
- 单个组件或局部逻辑：只跑相关测试或页面检查。
- 公共接口、配置或跨模块改动：扩大到相关模块。
- 里程碑：进行一次必要的集成测试或完整构建。
- 最终交付：一次综合审查和一次完整验证。
- 同一代码状态下已经通过的命令不重复运行。
首轮预算分配
调度智能体10%
软件架构师15%
原型设计师15%
软件开发者45%
QA 工程师15%
连续运行 2–4 周后，根据任务吞吐、返工率和阻塞原因调整；比例不是固定绩效指标。
07
每日快速检查表
开始工作和结束工作各看一次。没有实质变化时，不为更新状态而更新状态。
开始前
- 当前任务是否直接服务本周目标？
- 验收条件、负责人和依赖是否清楚？
- 架构或原型是否已解决关键不确定性？
- 是否在正确的仓库、分支或 worktree？
结束前
- 代码、任务状态和 PR 是否一致？
- 是否只运行了覆盖新增风险的验证？
- Diff 是否足够小，能由人快速判断？
- 是否产生了值得沉淀的新 Skill 或决策？
SOURCE PROJECTS