北京
过去做代码审查，人和代码之间总有一道沟。开发者能确认代码编译通过、逻辑跑得通，但很难快速回答另一个更关键的问题：这个功能真的做到产品文档和设计稿要求的样子了吗？测试人员得花大量时间在预发布环境里手动点击，反复对齐设计细节和功能预期，这让交付速度变慢，流程里也容易出现不一致和回归问题。Baz 想填补的正是这层断层——把产品意图、行为表现和代码实现收进同一条审查流水线里。
他们给出的解法叫 Spec Review 智能体，这个智能体并不是只看代码差异，而是从头去验证这一次提交是否真正符合所要交付的产品要求。过去团队大量依赖分散在人的经验里的隐性质检知识，盯着语法和样式差异做审查，像“它跑得对不对”“它长得是不是和设计稿一样”“它的行为是否符合规格”这类问题总被推到很晚才回答，于是代码和产品意图之间的缝隙就越积越深。Baz 在设计这一套智能体时，目标就是把检查对象从单纯的代码扩展到真正交付出来的体验。
Spec Review 智能体拉起了一道分阶段的多层验证管线。当 GitHub 上的代码库通过 webhook 或手动方式产生一次触发，智能体同时从 Figma 和 Jira 把各类需求文档拉到一起，覆盖技术、产品和设计三个维度。每一条需求会派生出独立的子智能体，各自领走一条需求去验证。这些子智能体一边躺在代码仓库里做静态检查，一边通过 Amazon Bedrock AgentCore 提供的浏览器工具完成动态运行时验证。它们会直接操作临时环境，检查 DOM 结构、模拟事件、比对视觉效果，让每一次部署在实现上是不是对得上 Figma 设计稿，行为上是不是按预期运转，全都被纳入一套从规格到实现的端到端验证里。
整套编排都跑在 Amazon Bedrock 提供的大语言模型上，推理层跟随整个管线做规模化支撑。从 GitHub webhook 被触发的那一刻起，这条流就开始运转，把原来依赖手工的模式转成了一套可以自动比对设计、产品和代码行为的审查闭环。Baz 和亚马逊云科技一起把这个方案落地后，产品验证不再是一场发生在代码审查之后的、漫长的人工补课，而是变成了开发流程里自动运转的一环。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
