grasys 如何做 AI 驱动开发：LLM 路由、TDD 测试护栏与 Human-in-the-loop

自2014年创立以来，株式会社grasys以坚韧的工程技术，从云基础设施的构建与运维，到云端应用的开发与运维，支撑着企业客户所拥有的、规模达数亿人的高流量业务基础。

该公司的技术实力在运用IaC（Infrastructure as Code，基础设施即代码）进行基础设施构建，以及敏捷应用开发这两大领域均得以发挥。尤其近来，在生成式AI的兴起使开发范式发生剧变的背景下，该公司率先将AI置于工作流的核心。

继上次介绍运用“Policy as Code”的基础设施工程之后，本次将聚焦“grasys流AI驱动开发（AI-Driven Development）”。从LLM（大语言模型）的路由策略，到向AI安全地共享上下文（Context），再到通过测试驱动来防止AI失控的测试护栏（Test Harness）实现，以及组织层面“Human-in-the-loop（人类的适当介入）”应有的形态，我们深入采访了在前线引领开发的Cloud Development Sec. Chief品地哲弥先生。

株式会社grasys Cloud Development Sec. Chief 品地哲弥先生

――今天，我们希望通过采访深入了解grasys所推进的AI驱动开发。事不宜迟，首先能否请您谈谈自身职业经历的变迁，以及加入grasys的时间？

品地：我此前一直作为全栈工程师在多个现场积累职业经验，而加入grasys是在2024年4月。入职后不久，我便参与了公司内部的基础平台开发项目，以及承接自客户企业的大规模系统的运维与开发业务。入职当时，整个社会正逐渐将AI在开发现场的使用视为理所当然，正是开发概念开始发生巨大变化的时期。

――随着技术的变化，具体而言是云的进化和AI的渗透，基础设施与开发的边界日益模糊。在此背景下，请谈谈grasys决定将AI正式纳入开发流程的背景及其时间。

品地：在我于2024年入职的时候，公司整体上似乎已经在推进将AI一举引入开发流程的动向。就我个人的实际体验而言，从2026年1月、2月左右起，工程师圈子里开始出现“通过实践护栏工程（Harness Engineering），几乎不用手写代码了”这样的对话。我自己也实际将AI智能体引入自己的开发环境进行尝试，结果手动编码和修改大幅减少，因此从同年2月左右起，我便正式转向以AI为主的开发风格。

以前，从架构的基本设计到逻辑的编码，全部都由人类工程师从零开始敲键盘构建，而现在我感觉“写代码”这一物理性作业的大半已被AI取代。

――您加入grasys，身处积极引入AI的现场。请谈谈在实际开发现场感受到的“压倒性优势”，以及相反遇到的“技术壁垒和组织课题”。

品地：首先，明确的优势在于，在IDE（集成开发环境）上可以实现高度自动补全，以及仅通过聊天界面用自然语言下达指令，就能完成复杂的环境操作和重构。

例如，在使用云服务商提供的全新功能或API时，只要将官方文档（PDF或参考手册）完整读入AI的上下文，并询问“这个要怎么在我们的环境中实现？”，它就能一口气提出合适的代码实现方案，并给出实现示例。从认知负荷的角度来看，这可以说是革命性的。

另一方面，作为缺点（课题）感受到的，是包括年轻人在内的“工程师根本性技能提升”是否会变得迟缓这一担忧。过去，人们要一边盯着官方文档一边让程序报错，通过辛苦调试，从而构建起对系统的深层“心智模型”。

然而现在，这一过程被大幅省略，也不再需要付出超出必要的辛苦，容易陷入“总之交给AI，即使内部结构仍是黑箱，也能做出某种能运行的东西”的状态。结果，我感觉“扎扎实实地学习”本质性架构和技术根基的“机会”减少了，我认为这将成为今后人才培养上的课题。

LLM路由策略：根据任务选择AI模型的方针与Token优化

――在开发中，面对众多LLM（大语言模型），你们依据什么标准来选型与路由模型呢？

品地：我们并非“总是使用最新最重的模型”，而是根据任务的性质和复杂度明确区分使用AI模型。例如，对于单纯的编码或重构这类规则和语法已在一定程度上文本化、作业内容有限且明确的任务，我们会使用相对较老世代的轻量模型。这是因为即使读入大量代码导致Token消耗增多，成本也不会飙升。

另一方面，在从零开始定义需求、我们自己也得不出架构最优解的卡壳状态下，或者希望从完全不同的视角获得超出预想范围的创意时，我们会刻意选择最新且推理能力最强的聪明模型。

目前，我们并行使用OpenAI的ChatGPT和Google Cloud的Gemini等，尤其是Gemini的最新模型等具备处理超长上下文的能力，因此我们将其用于：在参考各客户的基础设施构成、现行架构演变历程的基础上，还全面参照和分析类似其他客户系统的公司内部文档，基于多角度的数据来制定今后的设计方针。

还有一点，grasys也是一家擅长基于Google Cloud进行开发的公司，因此在这一点上我认为与Gemini的契合度很好。

grasys在承接客户重要系统时，请谈谈向AI传递上下文（领域知识）时的安全以及访问权限（IAM）管理。

品地：作为大前提，公司方针是“谁可以访问哪些资源与数据”这类权限，通过IAM（Identity and Access Management）等进行严格的集中管理。运行AI智能体的环境也不例外，完全遵循这一权限设计。也就是说，对于公司机密信息或特定客户数据等该工程师个人本来没有访问权限的信息，架构上确保绝对无法向AI侧传递（无法访问）。有了这道护栏，我们将数据泄露风险降到极小，从而能在安全环境下放心地充分利用AI。

品地：实际上，这正是当前AI驱动开发的一大瓶颈。由于AI以超高速输出代码，工程师自身并未深入理解其逻辑，就以“总之在本地能跑就行”为由提交Pull Request（评审）的案例，正作为课题显现出来。

乍看之下实现阶段似乎以极快速度完成了，但我认为在评审者阶段确认时，可能会引发若干问题。

例如，“重构作业中只做表面应付，或者重构中删除的函数被原样遗留在别处”“由于对目的理解不足，导致一个函数承担多项作业”“缺少面向人的注释”等。导致这些情况发生的原因，在于使用AI的一方原本就没有理解想让AI做什么。

本来，从Human-in-the-loop的角度出发，必须在经过评审之前的阶段（工程师个人责任范围内）完全理解AI的输出，并在拥有代码所有权的前提下进行流转。而“人类的确认与理解速度追不上AI的生成速度”这一点，已成为实践中的一大障碍。

——为了防止这种“人工确认遗漏”和“AI质量波动”，grasys在实际开发现场中，究竟将AI嵌入怎样的工作流（开发流程）来进行控制呢？

品地：作为防止AI失控的最大机制，我们采用了将“Issue Driven（课题驱动）”与“AI驱动的测试驱动开发（TDD）”相结合的流程。

例如，首先由AI以易于理解的粒度用日语在GitHub上创建诸如“在演示用EC网站上实现商品搜索功能”这样的Issue。与以往直接让AI编写实现代码的做法不同之处在于，我们在实现之前会向AI发出如下指令：“请从develop创建feature分支，并按照tdd-playbook以TDD方式实现功能。本次目标Issue为#100。请先从Step 1开始。”

接下来，在测试用例创建完成的时间点，系统会进入等待人工批准测试用例内容的状态。在这里，经人工批准后，流程将转入技能内所描述的实现步骤，AI随即开始实现。

于是，AI会解读Issue的内容，自主地用日语创建实现所需的测试用例框架。工程师首先要严格评审的并非生成的实现代码本身，而是这个用日语定义的测试用例的规格与逻辑。

如果我们设想的业务需求与测试用例完全一致，就先将该测试用例框架提交到仓库。

品地：在满足规格的测试用例确定之后，这次我们会对AI说“批准测试用例”。AI将基于已确定的测试用例这一“绝对正确答案的框架”开始后续的实现步骤，因此工程师只需一边做其他工作，一边等待AI完成实现即可。实际作业就是高速重复这一循环。

在进入实现阶段之前，通过在测试用例阶段插入一次人工评审（将Human-in-the-loop前移＝左移），我们铺设了坚固的护栏，防止AI的行动偏离需求、走向错误方向。

从IDE发出创建GitHub Issue的指令（放大图片）

AI创建的Issue（放大图片）

测试用例的生成与批准（放大图片）

按照测试用例实现测试代码（放大图片）

实现前（左）与实现后（右）生成结果的比较（放大图片）

不过，采用这种方法，由于在测试用例阶段人类与AI之间已经充分共享了需求，因此即便在实现阶段AI一时输出错误，AI也能通过测试自行察觉该错误，并自主反复修正。因此，工程师无需每次都重新给出细致指令，可以交由AI自主完成实现，直到所有测试通过并满足需求为止。

结果就是，在人工进行评审的时间点，满足需求的实现已经得到保障，从而消除了返工，同时也解决了评审的因人而异问题。

grasys式的“知识共享”与工程师组织的进化

品地：技术的学习方式和知识吸收过程（Developer Experience）因AI的引入而发生了根本性改变。以前在学习新的中间件或架构时，需要从头到尾通读厚厚的官方文档或PDF技术书籍来学习。但如今，人们已开始觉得，让人用眼睛去阅读这种格式固定的静态PDF是非常吃力的（低效的）。

作为替代方案，我们开始采用RAG（检索增强生成）式的方法，将目标文档整体作为上下文读入AI聊天引擎，并向其发送提示词：“请针对本次项目需求，仅摘要出需要注意的配置项和必要的部分”。这样一来，AI就能根据公司自身环境的上下文，动态地只抽取并告知“应该阅读的要点”，技术验证的速度得到了压倒性的提升。

品地：为了避免依赖个人化的“AI使用者”，团队内部以“Internal Developer Portal（内部开发者门户）”的形式，准备了一个专用仓库，用于共享某人创建并成功运行的便捷AI操作脚本，以及用于注入特定上下文的系统提示词模板。在那里以Readme的形式留下Markdown文档，建立起一套“高可复现性的机制”，让其他成员也能在相同的环境、以相同的精度立即使用AI。

grasys所重视的是，在制定组织所需护栏的基础上，扩大一线的裁量权。应当遵守的规则和重要方针由管理层和经理明确指示，在这一范围内，为每一位工程师创造能够自主思考、判断并发挥创意的环境。我们并不把推进方式在细节上一律规定死，而是重视最大限度地发挥一线产生的想法与可能性。

在AI应用方面，我们也认为不应把“交给AI”本身当作目的，而应根据业务目的，看清哪些部分交给AI、哪些部分由人判断和确认，这一点很重要。包括质量、安全性以及确认和运维所需的负担在内，探索能够带来更好成果的使用方式。为此，需要能够活用一线知识与经验的裁量权。

我们所追求的是，以技术力解决客户的课题，实现其目的。AI是实现这一目的的手段之一。在利用AI进行代码实现或文档要点整理时，我们也重视工程师自身理解内容和意图并做出判断。从云基础设施和应用两个方面，思考客户需要什么，并将其连接到设计与实现之中。在这一过程中有效活用AI，就是grasys所思考的AI驱动开发。

grasys希望与那些直面客户课题和目的、自主思考、选择技术并致力于实现的工程师一起工作。我们也希望将AI作为实现这一目标的手段加以活用。如果各位阅读本文后觉得“似乎和自己很合拍”，欢迎与我们联系。

――谢谢。