Develop an AI Develop Team
网络上，已经有人在 build AI team 了，这样的 team 就嫌事情太少，停下来一分钟，都是对与时俱进的不尊重。
这样的人很努力的在晒着自己的 commit 和 PR 频率，在我唾弃这些行为的时候，我也在 build 自己的 AI dev team，恨不得明天就运行起来！
这篇文章就会介绍一下 build 这样一个 AI Develop Team 的思路。 实际上，我们已经在这样运行了。
由下到上，点到线
当我拿到一个 Agentic coding tools 时，我要思考的是，我要拿它做什么呢？如果我没有一个很好的切入点，我就会开始拿它开玩笑，写藏头诗了。
我认为你工作中的某个步骤，就是很好的切入点，比如每周都要生成的报告，每隔一段时间就要查询的用户数据。大到 release note，开发某个 task，小到打开一个软件，提交一次 commit，都可以交给它。
从个体到团队，从具体的人到角色来看，那就是开发在这个节点要做的事情，比如大家评估完 story point，排列好 priority 之后，开发需要开始评估工作量，技术设计，QA 需要开始写测试用例。这些都是非常好的 workflow AI 的切入点。
当我把分析和 coding 两个 workflow 节点串起来之后，它就是团队的一个工作流。说的厉害一点，就是你雇了一个 24 小时帮你做这件事的员工。
Jira task 就是你的一个很好跟踪的线，一个很明确的任务。或许将来从纯粹的 AI Driven 的角度看，这样的工作流程可能会被彻底颠覆，但是从今天团队的工作流程来看，这是一个非常好的切入点。
当某个 task 具备软件开发的条件时，它会触发我们团队下面的流程：
节点1: 评估
我开发的第一个 agent 是 AI 分诊员，它做的第一件事就是评估，这个 task 是否适合通过 AI 来做开发，我不想一口吃成一个胖子，我不想 AI 的速度过于迅速，导致我就算只 review 也跟不上它的步伐，我在调试整个 workflow 的初期。所以一次粗筛很有必要。
如果某个 task 没有晦涩难懂（比如那些隐藏在人类大脑里的黑话，专业术语）的业务逻辑，没有 cross team 的影响，没有超大的工作量（小于 5 story point）我都会给这个 task 打上 AI_FRIENDLY 的 tag。一个迭代，两周时间，10 个人的 pizza 团队里，这样的 task 也有接近 7-10 个，工作量也有 7-10 人天。
没错，这些就是我一开始想啃的骨头，如果团队能把这些 task 中的 70%-80% 的代码工作交给 AI，不说这是革命性的，至少也是颠覆性的。
节点2: 设计
这个步骤，只有一个关键字 SDD。
对于较长的编程任务来说，目前只有 SDD 是比较可靠的开发方式，SDD 让你的开发可控，让你的开发不再是依赖直觉的随机行为。
这里一般情况也有两步，plan + coding，大家参考 SDD 的工作流程，不再赘述。
节点3: Checkstyle + PR
这一点让你的 Agent 总是提交可运行的代码，虽然逻辑上，这个 PR 可能是不符合预期的，但是一个可运行的代码是确保流程能继续的基础。
节点4: 人工介入
在我们的 MVP 阶段，这个流程从 PR 阶段，就需要开始人工介入，理想情况，代码修复的很好，review 之后直接 merge。
目前 AI 的能力，对于一些简单的 bug 和简单业务的修改，真的能做到一次就提交到位。这是我们团队每个人在结合 SDD 之后，特别吃惊的地方。
接手之后，还是有大量的工作需要做的，review，自测，修复 bug（当然修复 bug 可以重新走一遍以上的流程）。
往后我们会继续探索，是否能将这部分工作也全部都自动化掉，人的介入只是下一个流程的 trigger。
要点: 环境
这个运行环境特别的讲究，这个环境的搭建，实际上是赋予 AI 能力的过程，为了在这个阶段就避免自动化流程对现有系统造成过多误伤，我们可以严格限制账号和权限，比如 Confluence 权限只赋予 read 和 comment 权限，比如一些关键的 key，需要有较好的加密措施，即使 agent 提交错误的文件，也不会导致 key 泄漏，对于 Git 权限，也应该限制在提交 PR 的级别，严格控制主要分支（master main develop）的 merge 权限。
同样的工作，如果是在云端环境运行，要考虑的问题就非常非常多了，比如 sandbox 环境如何维护，要用什么技术实现 sandbox？有很多团队，比如
一个 sandbox 环境需要：
- file system
- code execution 环境
- LLM access
网络通讯安全
如果考虑 debug 过程中需要的所有东西，比如日志，RAM 管理，CPU 管理，这一切就变得永远无法开始了。- https://x.com/elvissun
而这位大哥，他巧妙的利用claude -p命令，自动化一切。
所以我们决定以网络上这个大哥的方案来继续一切。
要点: 依赖
现实是怎样的，AI Agent 也应该是怎样工作的。其实不然，只是在切入现有流程的语境下，这个假设是成立的。
理想情况，所有人所有 agent 在执行的 task 都不应该有任何依赖，但是实际情况是，依赖是在所难免的。最常见的情况是，很多 task 都有前端后端的改动，往往前端依赖后端。
我们在 MVP 阶段，不想卷入无尽的依赖和代码冲突，所以在评估过程中，我们就会排除这样的任务。
想象中，将来的解决方案是：
- AI 直接处理所有有相互依赖的任务，前后端一起改，某一个模块的两三个 task 都一起交由 AI 统一处理。或者不需要统一处理，而是统一 plan，分别处理。
- 前置处理，设计有依赖关系的工作流。（烦，不优雅）
要点: 并发
当然，排除依赖的问题，所有的工作，都应该是并发的，就像我临时雇佣了 10 个人，10 个人分别做各自的任务。
业界很流行的做法是，GitHub Workflow 和 tmux，或者我用的 Claude Code 和 OpenCode 都支持 subagent，它们能够根据需要额外启动 sub agent。
原子化
task 级别，Agent 运行，都应该做到原子化。为了做到这一点，每个 workflow 步骤，都要有一个唯一的跟踪 key，我们用的就是 Jira task ID。在这样的前提下，每个 workflow 节点，都要避免共享任何临时资源。
传递给下一个步骤的输入，都要以持久化的形式在传递，比如 Jira comment，有唯一 key 的分支，对应 worktree 里的文件。
同时，我们也要求自己，所有节点，都要有幂等的设计。因为开发调试这样的 workflow 时，你需要反复运行这些 agent。或者是某一个步骤开始，效果不够理想时，我们常常需要重新调整上下文，并且重试。
要点: 验证每一步
当这样的系统一直运行下去，代码逐渐成为开发人员眼里非常非常陌生的存在。如果没有一个全面多维度的测试方案，那么你的项目必然会走向失控。
AI-Evals 的维度
Agent 让测试脱离出了代码，曾经这样的自动化测试，都是通过代码实现的，现在即便是文档阶段，我们一样可以有 Agent 验证。当 Agent 能轻易的读懂日志时，日志也是我的验证手段之一。当 AI 能操作我的浏览器时，浏览器的 e2e test，也能成为 AI-Evals 的一个维度。
我觉得 AI 对测试的颠覆更是压倒性的，传统的测试将覆灭，用 AI 写测试用例，只是 AI adjust to your workflow，把测试的维度拉到三维四维，才是 AI-driven 的开发流程。
AI-Evals 比你想象中的，能做的，要多的多。
可不可能，我有 10 个 agent，从空间中的各个角度来验证 AI 生成出来的代码？比如：
- UT 是每个人第一点就能想到的。
- 直接在页面上模拟人的操作进行验证。
- 通过上线后的数据来验证功能的完整性。
- 通过 Datadog，或者 browser console 输出的日志来验证。
天马行空一点，我不觉得夸张- AI 自动下单某个第三方测试公司的订单，让公司的外包人员来验证。
当验证功能本身也是 agent 的时候，你的想象力可以尽情的发挥。它们就是你的小黄人，为了达成目的殚精竭虑。
最后
我会在下周，或者下下周，分享真实的用例，和运行的实际效果，以及我们是如何评估这个 workflow 给团队能带来了多少价值的。