HiFox 团队每天都有十几甚至几十项功能更新和体验改进发布。内测群里的用户提了一个功能需求，可能第二天就上线了。
这样的开发效率，是如何做到的？
核心就是使用 HiFox 本身来开发 HiFox，从而做到了全开发流程的 AI-native。人只需要做很少的事情，绝大部分事情都是 AI 做的。
我们团队具体是怎么做的？这篇文章就来分享一下我们的具体工作流程。
HiFox 是一个多人与多 Agent 的协作空间，你可以像 Jira 一样规划和跟进任务，并让 Agent 或小队直接执行开发任务，实现自动化测试，让整个产品-研发-测试流程完全 AI-native。
我们如何工作
我们常用的几条工作路径：
- 飞书群作为需求来源
- 产品经理的需求设计
- 完整的需求开发验证
- 设计师直接参与开发
- 全流程的自动化测试
飞书群作为需求来源
Hifox 的吐槽和交流群是很多需求的来源。以前，我们需要花费大量时间来整理用户建议，跟进开发进度，还时不时被客户催。现在，这些群被接入 HiFox，可以一键把用户建议整理为需求，Agent 自动开发和测试，进展自动同步回飞书群。
我们的内部同事和外部用户每天都会提出很多使用上的问题和功能建议。在群里讨论得差不多有结论的时候，我们就会@HiFox 任务助手创建任务。Agent 会收集群里的讨论上下文，总结大家讨论出的方案，在 HiFox 中创建出任务，并指派给相应的同事。之后，关于这个任务的所有后续进展也会同步回这个话题，反馈给所有参与讨论的同事，在飞书中就形成了任务闭环。
Agent 会阅读代码库，结合以往的任务和本次的结论，创建出一个任务。把任务指派给 Agent，它就会自己去开发了。
Agent 开发完成后，会自行验证结果并提交截图证据；而后把提交的 commit 关联到这个任务。
这样，解决用户反馈的效率比以往高了十倍以上，用户反馈的问题，大多当天就能解决，第二天就能发布了。
产品经理的需求设计
在用户反馈的需求之外，更多需求是产品经理调研并设计出来，然后进入开发的。以往，产品经理需要花很多时间做调研、写 PRD、做原型，耗费大量时间在前期设计上。而在使用 HiFox 之后，产品经理只需要简单描述，Agent 就可以调研和撰写可靠的产品需求了。
在 HiFox 团队，产品经理会先简单列出需求的背景信息和要点，或者让 Agent 去调研当前的代码实现和类似产品的处理方案。
HiFox 中的 Agent 不是像其他产品那样的简单聊天 Agent，而是掌握整个产品的丰富上下文，包括：
- 代码库及其中的文档
- HiFox 中以往的相关任务
然后结合本次的需求，给出设计方案。
Agent 会在调研之后给出几个需要产品做决策的选项，产品经理跟 Agent 讨论确认之后，就可以让 Agent 创建成一个任务了。
对于比较复杂的任务，产品经理会交给开发同事推进；而简单一些的任务，产品经理就可以直接指派给 Agent 来做。
完整的需求开发验证
当需求确认之后，就可以安排给“快速开发需求和修复 BUG” Agent 来具体执行了。Agent 可以独立给出技术方案，实现小时级的长时间开发，并给出可靠的验证。
将任务指派给 Agent 后，Agent 会开始读取代码库，为这个需求创建一个独立的 Worktree，把这个任务标记为开发中。
然后，Agent 会基于任务内容，首先确认一些具体实现的技术细节。
当用户确认了这些实现细节，Agent 就会开始做代码实现。在截图的这个例子里，Agent 一次工作了 57 分钟，然后完美地完成了整个需求和测试并提交代码，一次成型。
对于大部分没有特别复杂的需求，Agent 基本上可以做到一次成功。
在人工审阅环节，Agent 会提供三种待审阅材料：
- 验证链接和账号，人可以直接登录验证
- 代码 Diff
- 界面截图
当开发确认效果无误之后，Agent 就会把代码提交 PR，并把任务状态改为「待测试」。
我们会把常用的回复保存在“快捷回复”里，方便每次一键发送。
关于「快速开发需求和修复 BUG」Agent 的具体配置，我们会在后续文章中介绍，可以加入 HiFox 内测群，第一时间收到新文章推送~
设计师直接参与开发
以上这些实践里，似乎都跳过了设计师。实际上，在 HiFox 的开发流程里，设计师是非常重要的。但设计师参与的时间点跟传统的产研团队完全不同：HiFox 的设计流程是后置的。HiFox 团队的设计师已经完全放弃了 Figma 等设计工具，设计师直接用 Agent 写代码和提交代码。
具体来说，设计师的工作核心分成两个部分。首先是设计风格的制定和组件的实现，这部分当然是前置的。
第二个部分是设计每个具体界面。但是在有 Agent 的情况下，设计师就不需要把每一个界面都画出来了。因为风格和组件已经 ready，大部分的需求可以直接由开发或者产品经理在没有设计稿的情况下直接开发出来。然后设计师再用类似“走查”的方式 review 已经提交的新任务，发现界面问题就直接让 Agent 修改界面。
在这样的协作方式之下，协作效率大大提升，设计工作就不会成为瓶颈了。
以下是 HiFox 设计师的任务面板，大多纯前端样式的修改，都会直接由设计师完成。
后续我们会有一篇《设计师后置的工作流程》来介绍我们设计师的具体工作流程，可以加入 HiFox 内测群，第一时间收到新文章推送~
全流程的自动化测试
当一个任务被 Agent 开发完成，提交代码，并把任务状态改为“待测试”，就会进入自动化测试流程。HiFox 的 Agent 可以实现自动白盒测试、自动生成测试用例，自动准备数据，自主执行用例并给出测试结果证据。全流程完全自动化。
HiFox 的自动化测试主要由五个 Agent 配合完成。
白小浅从代码和测试结果判断实现是否正确；测小案负责生成测试用例；凤小九和端小九按照测试用例实际进行测试；测小统则确保任务与测试版本对应。
每个任务按实际需要选择测试路径。凤小九和端小九都是负责黑盒测试的，普通 Web 功能可以交给凤小九，涉及客户端安装、升级或本地环境时，再安排端小九。
这些 Agent 的工作流程大致如下。
关于 HiFox 测试团队流程的更多细节，参考另一篇文章《每天都发新版本：HiFox 团队如何做到全流程自动化测试？》。
Vano
我们如何配置
要让这些 Agent 持续协作，需要将分工落实到 HiFox 的 Agent 配置、自动化规则、任务字段和测试环境中。
1. Agent
在 HiFox 中，以上的产品设计、白盒分析、用例设计和实际执行等流程都需要被创建为 Agent，并配置指令，连接 Git 等等。
这些 Agent 使用本地运行模式，通过绑定的电脑和 Runtime 执行工作。
2. 自动化
在 HiFox 的「自动化」功能中，配置触发条件、执行 Agent、执行指令，就能把让各种任务自动流转。
比如，测试流程中就常用这两条自动化：
在自动化详情中可以看到提示词和运行记录。
除了任务状态变化触发 Agent 之外，我们还会使用定时自动化，每天自动更新帮助文档和 Changelog，具体见另一篇文章《让文档更新跟着产品发布走：用 Hifox 搭一条自动化文档流水线》。
Vano
3. 共享 Skill
将公用的 Skill 导入到 HiFox，就可以被多个 Agent 共享使用，并且所有的变动可以方便地同步到整个团队。
比如我们测试团队使用的 Electron 和 HiFox Stage 测试流程等等 Skill。
4. IM 集成
HiFox 支持集成飞书、企业微信、钉钉，可以从 IM 创建和指派任务，把运行结果推送到 IM 等等。
关于 IM 配置的详情，具体见另一篇文章《HiFox 连接飞书：让 AI 把群聊里的问题真正推进下去》。
5. Git 集成
HiFox 支持集成 Github、Gitlab 等代码仓库，可以把任务和代码对应起来，从而推进自动化测试。
关于 Git 配置的详情，我们会在后续推文《HiFox 集成代码仓库》中详细介绍，欢迎关注我们，第一时间收到新文章推送~
6. 快捷指令
HiFox 中支持随时从任务随时发起跟其他 Agent 的对话，并可以配置常用的会话指令，一键发送给 Agent。特别适合测试场景。
必要的团队准备
要让 Agent 顺畅地完成从需求调研到自动化测试的全流程，团队还需要做好一系列准备。
1. 前后端代码放在同一个仓库
在这套实践中，前后端代码放在同一个仓库，方便 Agent 沿着用户操作追踪完整实现：从页面入口，到接口请求，再到业务逻辑和数据存储。这样，开发可以一次性把前端和后端代码一并实现，测试也能顺畅地发现 bug 的具体出现位置。
仓库里还应写清前后端启动方式、测试命令、依赖安装和测试数据库准备方法，减少每次执行时重新摸索环境的成本。
2. 在仓库里沉淀可重复执行的单元测试和 UI 自动化测试
要实现 Agent 开发一次成型，测试用例是核心的基础设施建设。这里的测试用例，包括单元测试、UI 测试、E2E 测试，都需要沉淀到仓库里。
要让 Agent 顺利使用这些测试，需要提前做到：
- 覆盖重要且容易出错的逻辑。权限判断、状态流转、边界条件、数据转换这些部分要有测试兜底，Agent 才能在改动出现时立刻验证预期，而不是逐行推断。
- 测试稳定、结果确定。不依赖外网、特定电脑的本地状态、当前日期或随机值。
- 运行命令写进仓库。仓库往往同时包含多种语言（例如前端、后端、客户端各有一套测试），要把怎么跑全部测试、怎么只跑与某个改动相关的测试都写清楚，Agent 才能选对范围最小的验证。
- 把测试接进提交门禁。提交改动前自动运行受影响的测试，让基础问题在进入版本之前就被拦下；白盒预检面对的干扰也会更少。
3. 按全栈方式交付功能
一个 Feature 应当有贯穿前后端的负责人，将界面交互、接口行为、权限规则和数据变化作为整体交付。
这不要求所有代码都由同一个人编写，但需要有人对完整用户路径负责。提测时，前后端改动、部署条件和验收规则都应已经对齐，让测试 Agent 能沿着同一条业务链路验证。
目前，在 HiFox 团队大概有 50% 的产品功能需求无需专业开发人员参与，产品经理直接把需求指派给 Agent 即可，Agent 会自己写代码、提交 PR、提测。只有比较复杂，风险比较大的需求，才会有专业开发人员介入。
专业开发人员更多时间都花在基建、Agent 的设计和持续迭代上，让代码库更加 AI-friendly，让质量保持机制、自动化测试机制更完善，确保产品经理、设计师使用 Agent 也能开发出高质量、高性能、高可靠的代码。
4.使用 24 小时在线的共享测试机
自动化测试适合运行在专门的共享测试机上。测试机应保持在线，避免个人电脑休眠、关机或被日常工作占用后，Agent 执行中断。
共享机需要预先准备浏览器、测试客户端、Runtime 和测试工具；登录专用测试账号，以及所需的组织、空间和角色权限等。
5. 把测试环境准备写成脚本
仓库中提供统一的依赖安装、数据库初始化、服务启动和测试命令，让 Agent 能重复执行。
环境检查也应自动化：开测前确认服务可访问、数据库迁移完成、测试机在线、Runtime 可用。准备失败时直接报告具体原因，避免耗费大量时间探索环境。
6. 给每个 Feature 写清验收标准
需求中至少说明主流程、权限限制、异常行为和保存后的预期。
“支持切换 Runtime”还不够，需要明确：切换影响当前会话还是整个 Agent？运行中能否切换？换电脑后路径如何处理？失败重试使用哪个 Runtime？
这些规则先确定，Agent 才能据此判断对错，减少把实现现状直接当作预期结果的情况。
结语
回顾整个流程：从飞书群里的一个用户反馈，到 Agent 自动创建任务、完成开发、提交证据，再到自动化测试把关后上线，一条需求可以在一天内走完全程。人始终掌握着方向——提需求、做决策、定标准、把关效果，而重复的、确定性的工作，都交给了 Agent。
这套方法的核心，并不是某个单一的工具或配置，而是把开发流程重新设计成 AI 可以参与的形式：需求沉淀成可执行的任务，验收标准写得清楚，环境可以自动准备，结果有据可查。当这些基础打好之后，Agent 的加入就不是简单的效率叠加，而是让整个团队的节奏发生了质变。
更值得关注的是飞轮效应：HiFox 团队用 HiFox 开发 HiFox，产品每解决一个自己的痛点，能力就向前一步；团队在使用中沉淀的 Skill、自动化和最佳实践，又反过来让产品更懂开发。工具和团队在互相塑造中共同进化。
AI-native 的开发才刚刚开始。随着 Agent 能力的增强，人机协作的边界还会不断拓展，更多环节会变得自动化、可沉淀、可复用。如果你也想尝试，不妨从最痛的一个环节开始：把需求整理交给 Agent，把测试交给 Agent，让团队先跑起来，再逐步扩大 AI 参与的范围。
欢迎使用 HiFox，一个多人与多 Agent 的协作平台，轻松指挥一堆 Agent 同时并行工作！
HiFox
