【标签】 学习工作
【学习工作赛道】「一人军团」让一个人指挥一支 AI 团队，快而不失控
0. 先和大家打个招呼
大家好，我是一名测试工程师，同时也是一名在职创业的“一人公司”开发者——本职做测试，业余以一人之力维护着多个 AI 项目（新闻聚合平台、AI 处理中枢、跨项目看板等）。
测试工程师的职业本能深深塑造了这个作品：我天然不信任“能跑就行”，更在意流程有没有卡点、每一步能不能追溯、一处改动会不会悄悄弄坏别处。所以当我用 AI 高速开发时，第一焦虑从来不是“写得快不快”，而是“这么快，协作和质量怎么守得住”。这次我提交的不是一个 App，而是我给“AI 编程时代”开的一剂药：一套把质量门禁、职责边界、可追溯性写进流程本身的 AI 研发操作系统 + 一个能回放每一句 AI 协作的跨项目看板。它不是纸面方法论——本帖里你看到的看板迭代，就是用这套工作流自己跑出来的。
1. Demo 简介
**是什么：**一套面向个人开发者 / 一人公司的分层 AI 研发操作系统，由两部分组成——Agent Workflow（分层工作流）把“谁能改什么、每步过哪些门禁”写死成文件，是协作真源；Workboard（跨项目看板）把散在多个仓库的进度、需求、阻塞乃至 AI 原始对话，聚合成一个可回放、可审计的驾驶舱。一句话：它管的不是“怎么写代码”，而是“AI 帮你写代码时，怎么不失控”。
面向谁：
-
同时维护多个 AI 项目的独立开发者 / 一人公司
-
用 AI 编程但苦于“聊天记录管不住项目”的开发者
-
需要跨项目追踪进度、发现阻塞的小团队
-
对“AI 产出质量与可追溯性”敏感的人（比如像我一样的测试 / QA 背景）
核心功能（五大块）：
**① 分层工作流 —— 权限写死，不靠自觉：**三层物理隔离（生态层 / 跨项目沟通层 / 项目内部层）+ 4 个固定角色（产品 / 架构 / 开发 / 运维）+ 5 道硬门禁：无 PRD 不开工、无设计不编码、不 Review 不定稿、不自测不部署、不收尾不关闭迭代。门禁是真会拦——本帖第 5 节就有架构师首轮 Review 打回 3 高 5 中问题的实录。
**② 双通道需求池 —— 业务和框架分开管：**最容易失控的，是“改业务需求”和“改协作规则本身”被混在一条线里。这里拆成两条独立通道：普通需求走 REQUESTS 需求池，框架自身变更走独立的 BCR 提案池，流程、评审人、留痕全分开，规则越改越清楚而不是越改越乱。
**③ 版本游标 —— 规则版本永不漂移：**每个下游项目用一个 .workflow-version 游标文件，精确记录自己同步到框架真源的哪一个 commit。哪个项目还在用旧规则、差几个版本，一眼可查。多项目最怕的“各用一套土规则”，被这一个文件锁死。
**④ 跨项目看板 —— 多个仓库的全局，收进一页：**项目总览 / 部署 / 需求池-BCR 多视图，60 秒自动轮询、严格只读（绝不回写被监控项目）。原本要翻五六个仓库才能拼出的“谁在等谁、哪里卡住、整体健康度”，变成一个页面，且全是真实运转数据，不是演示数据。
**⑤ 会话回放 —— AI 协作全程可审计（本轮新增）：**项目会话视图 + 对话查看器 + 双层时间轴。每一轮迭代里 PM 怎么写 PRD、Review 怎么打回、开发怎么修 bug，原始 AI 对话可直接点开回放——AI 做了什么、为什么这么做，不再是黑盒，而是一条可追溯的证据链。
核心数据（全部真实）
-
5 个真实项目跑在同一套工作流上（新闻聚合 / AI 中枢 / 协调仓 / 看板 / 工作流真源）
-
4 个固定角色 + 5 道硬门禁，权限写死成文件
-
2 条独立通道分离业务需求与框架变更（REQ / BCR）
-
4 次真实框架自我改造留痕可查（BCR-004/006 角色 6→4 合并、BCR-007 升级“指挥官—参谋长制”、BCR-009 参谋长并入框架维护）
-
workboard v0.2：79/79 单测通过后部署生产
-
看板 60 秒自动轮询、严格只读，多视图聚合
一句话亮点（差异化）
-
真实自证：作品本身就是用这套工作流迭代出来的，看板数据全部真实。
-
门禁不是摆设：有真实的 Review 打回、真实的版本游标、真实的 BCR 改造历史。
-
全程可审计：从需求到部署，每一步、每一句 AI 对话都留痕可回放。
本轮迭代新增（workboard v0.2，用这套工作流按标准迭代跑完）：项目会话视图、对话查看器、双层时间轴（迭代轴 + 会话轴）、多会话源接入与映射配置、数据库升级 PostgreSQL；实现阶段经 Architect + DevOps 两方 Review，79/79 单测通过后部署生产。
产品截图：
工作台总览：跨项目待办、REQ/BCR 状态与全局健康概览
生态分层结构：参谋长席位、框架真源、公告板与项目组关系
双层迭代时间轴：v0.1 到 v0.2、阶段状态与角色映射
跨项目需求池：REQ/BCR、谁等谁、沟通与跨项目协作状态
查看跟AI的对话记录
2. Demo 创作思路
灵感来源：
自己以一人公司方式同时维护多个 AI 项目，发现只靠聊天记录管理 AI 协作很快会失控。不同项目的 AI 会话互相不知道对方在做什么，也不知道每个项目用的是不是最新版本的协作规则。
想解决的问题：
AI 编程速度很快，但“改业务需求”和“改协作框架本身”经常被混在一起处理，导致协作规则越改越乱、各项目用的规则版本逐渐漂移不一致；同时缺一个能一眼看清所有项目状态的地方。
为什么做这个方向：
AI 编程的瓶颈已经从“写代码”转移到“治理”：项目记忆、职责边界、Review、跨项目协调。这套系统真实做过自我精简与升级（BCR-004/006 角色 6→4 合并、BCR-007 组织定位升级为“指挥官—参谋长制”），有真实契约文件和决策记录，是可验证、可复制的方法论。本次参赛的另一个作品「牛马程小报」也运行在这套工作流之上，两个作品互为证明。
3. 后续迭代 & 产品完全态
近期迭代（v0.3，规划中）
-
会话“迭代标签”精准匹配：自动识别某段 AI 对话属于“哪个迭代下的哪个角色”（如“v0.2 的 PM 会话”），让回放定位更快。
-
信息架构精简 5→3：顶级菜单收敛为「看板 / 项目会话 / 需求池」，部署与接入诊断降级进项目卡片详情。
-
多来源会话同步：打通 Codex 等更多 AI 编程工具的会话来源，看板不绑定单一工具。
-
生态根可钻取：公告板、框架真源两张只读卡片支持点击下钻，看到框架版本与演进详情。
产品完全态（大胆预期）
这套系统现在是半自动的——指挥官（我本人）仍要亲自进组当 PM 拍板，看板严格只读。它的终局分三步走：
-
只读看板 → 可操作管理中枢：看板从“看”进化到“指挥”，能直接在页面上派活、审批、触发同步，而不只是展示。
-
半自动 → 全自动回流：框架规则一旦更新，经 CI / hook 自动回流到所有下游项目，版本漂移归零，人不再是同步的瓶颈。
-
决策权下放：门禁与审计足够可信后，把一部分拍板权安全地交给 AI，人只在关键节点介入——从“一人公司”走向“一人指挥一支 AI 团队”。
终局愿景一句话：让一个人，用一套可治理、可审计、可复制的操作系统，稳定地指挥一支 AI 团队，同时推进多个真实产品。
4. Demo 体验地址
两种体验方式，按深度递进：
- 交互式导览页（60 秒看懂，含门禁对话回放）：User Dashboard Design + 一段“你让 AI 直接写代码、它拒绝你”的门禁实录回放，最快理解这套系统在管什么。
交互式导览页封面：
- 看板（线上直接访问）：https://workboard.huiyiyou.cloud推荐路径（2 分钟）：项目总览 → 点开一条会话回放 → 需求池 / BCR / 版本游标。看板上所有数据都是真实项目运转产生的，不是演示数据。
5. TRAE 实践过程
开发流程（workboard v0.2 标准迭代，全程按工作流角色推进）：
-
PM 阶段：v0.2 PRD（项目会话视图 + 对话查看器 + 映射配置）+ UI 方案定稿。
-
实现阶段：Developer 全量实现（会话视图 / 对话查看器 / 双层时间轴 / 双数据源同步）；期间三项实现变更（数据库 SQLite→PostgreSQL、双数据源、会话源兼容）按 Change Note 机制留痕。
-
Review 阶段：Architect R2 首轮不通过（3 高 + 5 中问题），修复后复审通过；DevOps 独立检查再拦下部署配置问题，修复后通过。门禁不是摆设，打回记录都在。
-
部署验证：79/79 单测通过，生产部署 workboard.huiyiyou.cloud，健康检查通过。
关键步骤截图：
跟产品讨论迭代。
架构师对产品的PRD进行评审。
架构师根据PRD产出设计文档。
开发根据PRD和设计文档进行开发。
开发根据我提交的bug进行修复。
运维部署到生产上。
关键任务 Session ID：
-
3551843294149419:ac87a4eeb3f5d1643257c746cb371ea1_6a48c7d4139447da16e994ce.6a4ccfae9fa80da662393ac2.6a4ccfae9fa80da662393ac0:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/7/7 18:06:38)— 产品阶段：明确 workboard v0.2 会话视图与对话查看器迭代目标。 -
3551843294149419:a165d4932cd130c8f90ad778704bd66a_6a48c7d9139447da16e994d7.6a4cd7e99fa80da662393c54.6a4cd7e99fa80da662393c52:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/7/7 18:41:45)— 架构师阶段：评审会话视图、角色映射与数据源设计。 -
3551843294149419:b358b77ffe9b3fab92351a92219e3ad8_6a48c7de139447da16e994e3.6a4cd8d49fa80da662393ca7.6a4cd8d49fa80da662393ca5:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/7/7 18:45:40)— 开发阶段：实现项目会话视图、对话查看器和双层时间轴。 -
3551843294149419:d81d36d470c8dd4301c93bdca2b50e0e_6a48c7e4139447da16e994ec.6a4cd6ba9fa80da662393c1f.6a4cd6ba9fa80da662393c1d:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/7/7 18:36:42)— 运维阶段：部署检查、生产验证与上线收尾。
6. TRAE 使用感受
这套系统能成立，恰恰依赖 TRAE 的两个能力：
**① 多角色分工，一个人干成一支团队：**产品、架构、开发、运维四个角色，我用不同的会话和职责约束在 TRAE 里逐一推进。TRAE 的长上下文让每个角色都能“记住”自己该守的规则，而不必每次从零解释。
**② 会话可分享（Session ID）让“可审计”从口号变成现实：**这是我最看重的一点。正因为每段 AI 对话都能通过 Session ID 稳定回放，我才敢把“开发过程全程可审计”写进产品——它不是事后补的文档，而是 TRAE 本身留下的、可追溯的证据链。本帖第 5 节的 4 个 Session ID，就是这条证据链的入口。
**最打动我的一个瞬间：**在导览页里有一段真实回放——我让 AI 直接上手写代码，它拒绝了我，理由是“还没有 PRD，按门禁不能开工”。作为一名测试工程师，那一刻我确认：AI 不只是会写代码的手，也能成为守规则的人。这正是我想让更多独立开发者体验到的——快，但不失控。
7. 对应的报名审核通过的帖子链接
我的报名帖已通过审核：https://forum.trae.cn/t/topic/66752
另一个作品「牛马程小报」正在整理中，发布后我会在评论区或本文更新互链。
如果你也是一个人扛多个 AI 项目、被“聊天记录管不住项目”困住，欢迎在评论区聊聊你的做法，也欢迎点开线上看板直接体验，我会一一回复。
