【免费下载链接】three-man-teamA structured 3-agent AI dev team — Architect, Builder, Reviewer. Built from production use. Token-optimized. Works with Claude Code, VS Code, Cursor, and any AI that supports context files.项目地址https://gitcode.com/gh_mirrors/th/three-man-team点击查看免费下载用 AI 写代码时有没有遇到过这种情况AI 默默加了没人要的功能、做到一半突然跑题、或者反复重读文件浪费 tokenthree-man-team是一个由 Architect架构师、Builder构建者、Reviewer评审者组成的三角色 AI 开发团队框架源于真实生产环境的打磨。本文是角色拆解系列的第一篇带你拆解 Architect 如何写出零歧义的构建 Brief让 AI 开发不跑题、不超支。为什么 AI 开发总容易跑题大多数 AI 编码工具的问题是有能力但没纪律明明只需要一个函数它去读整个代码库顺手加功能没人要求的也写上任务中途漂移做着做着方向就变了每次会话都烧 token 做不必要的工作three-man-team 给出的答案不是更好的提示词而是一套流程三个角色、明确的交接文件、防止最昂贵失败模式的规则。三角色默认名字是Arch架构师、Bob构建者、Richard评审者安装时可自由改名。其中 Architect 是整个团队的固定点——方向不清时大家都看它。它的设定见 ARCHITECT.md。Architect 的三大职责先对齐再开工在 ARCHITECT.md 中Arch 的职责被清晰地分为三件事和项目负责人对话——先判断问题是产品缺口还是代码缺口描述代码当前行为让对方确认是否符合预期再给出修复建议指挥 Bob 和 Richard——写 Brief、启动 Builder、完成后再启动 Reviewer全程锁定范围拥有部署权——没有 Arch 的确认和项目负责人的许可任何东西都不上生产这套设计背后的研究思路写在 METHODOLOGY.md 里给 AI 一个人设背景故事、价值观、声音比一句你是架构师能激活更精准的行为模式。零歧义 Brief 怎么写看懂这份模板Brief 不是聊天而是一份写入handoff/ARCHITECT-BRIEF.md的结构化文件。每步覆盖重写它不是日志而是当前生效的构建指令。模板见 ARCHITECT-BRIEF.md。一份合格的 Brief 由四个板块组成一个都不能少## Step N — [要构建什么] ### Decisions - [决策或约束只写决定不写散文] ### Build Order 1. [先构建什么] ### Flags - Flag: [Builder 不允许猜的任何事] ### Definition of Done - [ ] [可验证的完成标准]四个板块各自消灭一类歧义Decisions只写决策和约束。用框架内置校验器不要自己写正则就是一句决策省掉 Builder 一次错误尝试Build Order构建顺序明确避免 Builder 自己发明一个顺序Flags这是灵魂板块——Builder 不能猜的东西全部显式声明。AI 跑题的根源往往是替人做决定Flag 直接掐断这个空间✅Definition of Done完成标准必须可验证。做好邮件校验是模糊的服务端返回的错误格式与现有错误一致是可检查的一个完整 Sprint从需求到部署看完模板用官方示例 sprint-walkthrough.md 走一遍完整流程。项目负责人提出注册表单的服务端没有校验邮箱格式只有 JS 前端校验。 Arch 读相关文件、确认缺口、对齐方案后写出 Step 12 的 Brief## Step 12 — 注册流程的服务端邮箱校验 - 注册处理器中增加服务端邮箱格式校验 - 在数据清洗之后、写入数据库之前校验 - 返回的错误信息与现有错误格式保持一致 - JS 校验已存在 —— 不要修改它 - Flag: 使用框架内置校验器不要用自定义正则注意 Brief 里的每一条都对应一个具体动作或禁令Builder 拿到手不需要做任何理解意图的工作。随后流程严格沿着工作流走Bob 读完 Brief 先报计划、得到确认才动代码Richard 按 REVIEWER.md 对照 Brief 逐条核对揪出错误信息不可翻译的问题打回Bob 修完复审通过最后由 Arch 部署并更新日志。没有任何一步被跳过。为什么文件交接既省 token 又不跑题three-man-team 的 agent 之间不用对话沟通而是通过结构化文件交接详见 how-it-works.mdArchitect 写ARCHITECT-BRIEF.mdBuilder 写REVIEW-REQUEST.mdReviewer 写REVIEW-FEEDBACK.md这意味着每个角色都以干净的上下文启动只读自己岗位需要的文件Builder 永远不加载完整项目规格Reviewer 永远不加载数据库 schema。token 浪费从行为问题变成结构问题——结构对了行为自然对。配合每次会话自动加载的 token 规则见 CLAUDE.md 与 token-optimization.md纪律是内建在基础设施里的。快速上手三步让 Arch 开始写 Briefgit clone https://gitcode.com/gh_mirrors/th/three-man-team.git .claude/skills/three-man-team cd .claude/skills/three-man-team ./setupsetup 会接管后续步骤并给出精确指令。每个项目使用团队时的启动提示词整理在 session-start.md首次会话只需要一句You are the Architect on this project. Please read new-setup.md.Arch 会自动完成项目上下文文件、团队命名和首次会话提示词的搭建。本篇小结 跑题的根源不是模型能力而是缺乏结构和交接纪律Architect 的零歧义 Brief 四板块模板Decisions / Build Order / Flags / Definition of Done其中Flags不许猜的清单 可验证的完成标准是让 AI 开发不跑题的关键文件交接 token 规则让流程既是质量保障也是成本保障下一篇角色拆解将继续拆解BobBuilder 如何严格执行 Brief敬请期待。赞分享【免费下载链接】three-man-teamA structured 3-agent AI dev team — Architect, Builder, Reviewer. Built from production use. Token-optimized. Works with Claude Code, VS Code, Cursor, and any AI that supports context files.项目地址https://gitcode.com/gh_mirrors/th/three-man-team点击查看免费下载相关推荐three-man-team角色拆解③Reviewer三级反馈机制如何守住代码质量最后一道门three man team角色拆解③Reviewer三级反馈机制如何守住代码质量最后一道门 three man team 是一个由 Architect架构AI开发团队框架three-man-team完整指南Architect、Builder、Reviewer三人协作如何重塑你的AI编程流程AI开发团队框架three man team完整指南Architect、Builder、Reviewer三人协作如何重塑你的AI编程流程 你是否遇到过这样的困Android 手势检测实战基于 GestureDetector 捕获与识别常用触摸手势android-training-course-in-chinese 课程解读Android 手势检测实战基于 GestureDetector 捕获与识别常用触摸手势android training course in chinese上一篇如何利用Siddhi实现实时数据处理5个核心功能解析与实战下一篇Win11Debloat免费可回滚的 Windows 11 去臃肿与隐私清理完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考