本文内容
2026 年 AI 编程工具链实测：用 Pi 等四个工具排查前端回归
用户在订单页面选中 Open（未关闭）。第一页显示两笔未关闭的订单。开发人员把截图贴进工单，标记修复完成。可用户只要再点一次“下一页”，就会看到两笔 Closed（已关闭）的订单。用 AI 写代码时，谁来发现这个问题？
ChunkHound 作者 Ofri Wolfus 在公开教程里用四个工具开发了一款多人游戏。Pi 运行编程会话，ChunkHound 调查代码，pi-schematic 安排分工，agent-browser 查看前端实际运行的结果。我们沿用这套分工，把任务换成熟悉的维护场景：一个已有应用出了问题，审查者需要看到什么，才有依据合并修复？Wolfus 的作者介绍 · 四工具协作的原版教程
核查日期：2026 年 11 月 14 日。我们安装了四个软件包，在 Pi 中加载扩展，用 ChunkHound 为示例代码建索引，并在 Chromium 中操作订单页面。当前环境限制了 agent-browser 守护进程需要的本地套接字，浏览器实测改由 Playwright 驱动。下文的模型研究、编写补丁环节是建议流程。本次验证没有发起付费模型请求。
这套 AI 开发工具链中，四个工具各负责什么？
Pi 让模型获得可操作的编程环境。ChunkHound 从仓库中找出相关实现。pi-schematic 在 Pi 内把调查、修改和审查分开。agent-browser 可以定位页面上实际渲染出来的控件。评估这四个工具时，可以逐项问：这一步结束后，下一位同事能拿到什么？
| 组件 | 在订单工单中的职责 | 应保留的证据 | 代码许可证 |
|---|---|---|---|
| Pi 1.5.2 | 使用选定的模型、仓库工具和项目说明运行编程会话。 | 范围明确的代码差异，以及验证改动的命令。 | MIT |
| ChunkHound 6.1.0 | 找到读取筛选条件和生成翻页链接的代码。 | 每个判断对应的文件、符号和行号。 | MIT |
| pi-schematic 0.7.1 | 让调查、实现和审查各自围绕一个具体问题展开。 | 交接记录，列清已确定的约束和尚待验证的行为。 | MIT |
| agent-browser 0.43.0 | 在真实浏览器中按用户的顺序操作页面。 | 地址栏、可见订单号和状态，以及刷新后的结果。 | Apache-2.0 |
这四个项目的代码均免费开源。模型 API、托管向量服务、云浏览器和 GPU 仍可能产生费用。本文的正则检索和本地浏览器示例无需模型账号。Pi 许可证 · ChunkHound 仓库与许可证 · pi-schematic 许可证 · agent-browser 仓库与许可证
怎样把 Pi、pi-schematic 和 ChunkHound 接起来？
先安装 Pi 命令行工具，再把 pi-schematic 安装为 Pi 扩展。随后把 ChunkHound 注册为项目级 MCP 服务。MCP 即模型上下文协议，Pi 通过这个接口发现和调用仓库工具。目前 Pi 已内置 MCP 支持。agent-browser 可以独立作为命令行工具使用。Pi 运行环境和内置 MCP 支持
以下命令固定了我们核查过的软件版本，环境使用 Node 24 和 Python 3.12。在执行界面测试的机器上安装浏览器，并确保 Pi 所在环境的 PATH 能找到它要启动的工具。Pi CLI 安装与身份验证 · agent-browser 安装说明
npm install -g --ignore-scripts @earendil-works/[email protected]
pi install npm:@chunkhound/[email protected]
uv tool install chunkhound==6.1.0
npm install -g [email protected]
agent-browser install
# 在要交给 Pi 使用的项目仓库中执行以下两条命令。
pi mcp add -l chunkhound -- chunkhound mcp --no-daemon
pi mcp list-l 会把服务定义写进项目的 .pi/mcp.json。在 Pi 中信任这个项目之前，先查看配置文件。Pi 找不到可执行文件，或项目配置还未被信任时，写入配置也可能无法调用工具。先检查 Pi 发现了哪些工具，再查询一段已知代码，核对返回的源文件位置。Pi 的项目配置、信任机制与 MCP 命令
实测环境限制了共享守护进程的本地套接字。我们使用 ChunkHound 的单客户端模式 --no-daemon。信任测试项目后，Pi 显示服务已连接，并列出了 search 和 daemon_status。随后用独立的 MCP 客户端执行正则检索，查询 PAGE_SIZE，返回结果指向示例中的定义。这验证了通信和查询，无需让模型自行选择工具。ChunkHound CLI 与单客户端模式
我们还在一个全新的离线 Pi RPC 进程中加载了已安装的 pi-schematic。Pi 返回了扩展提供的 model-groups、notebook、handoff 和 readonly 命令。由此可以确认这组版本能够一起加载。具体模型能写出什么质量的补丁，还要给它一张真实工单来验证。
怎样用 ChunkHound 找到回归的原因？
先提一个能在源码中核对的问题。在这张工单里就是：哪个函数把订单状态写进下一页的 URL？如果地址没有这个参数，请求处理函数会返回什么？调查结果需要指向链接生成和参数读取两处，才能解释用户为何看到错误的订单。
把本地订单筛选示例下载到空目录。数据包含六笔虚构订单，每页两笔。缺陷模式和修复模式共用同一组数据。在该目录建索引即可搜索，不必接入向量服务。示例保留了 next_status 这个变量名，方便读者复现查询。ChunkHound 建索引、正则检索、语义检索和代码研究
chunkhound index --no-embeddings .
chunkhound search --regex 'next_status'ChunkHound 把一个文件划分成 20 个代码片段，生成 0 个向量。查询得到三个内容有重叠的结果，都来自同一个文件。在缺陷模式下，一行代码将 next_status 设为所有订单，下一行用 page_url 生成链接。URL 没有 status 参数时，请求处理函数默认返回所有订单。三处命中解释的是同一个缺陷。
已经知道变量名，普通文本搜索就够用。实际仓库可能把界面链接、路由解析、API 筛选和测试放在四个不同的包里。这时再试语义检索，或要求 ChunkHound 的研究工具追踪整个调用路径，每一步给出源码位置。审查时在目标提交上核对这些行。修改后先刷新索引，或确认索引已经收录变更，再参考下一次查询。
索引保存在本机，模型推理的地点则由后端配置决定。正则检索无需模型服务，语义检索需要向量模型，深入研究还依赖语言模型和兼容的重排配置。选用远程服务时，核对各阶段会向哪个地址发送代码片段和查询内容。如果仓库要求数据留在本地，先单独验证每个后端，再向团队开放。ChunkHound 的模型服务与索引配置
Pi 和 pi-schematic 应该怎样分配同一项改动？
把待调查的问题交给研究者，把范围明确的改动交给实现者，再让审查者独立验证用户能看到的结果。pi-schematic 的 spawn 可以启动拥有全新对话的子智能体，handoff 将已有决策带到下一阶段。子智能体继承当前工作目录。即使对话相互独立，两个智能体也可能改写同一份文件。pi-schematic 角色、模型组、笔记和工作目录
| 角色 | 任务 | 交接条件 |
|---|---|---|
| 研究者 | 从第一页开始，追踪筛选状态怎样进入翻页链接、再由请求处理函数读取。给出源码位置。 | 接手的人能指出参数在哪里丢失，解释默认值如何影响结果。 |
| 实现者 | 生成下一页 URL 时保留当前状态。保留现有路由和空结果行为。 | 提交范围小的代码差异，相关文件由一位实现者负责。 |
| 审查者 | 打开第二页之前，先根据测试数据写下预期的订单号，再检查 URL、行内容、刷新、后退和空结果。 | 保留预期值和实测值，做到下一次发布也能复核。 |
把预期订单号和改动范围写进工单，或者随代码提交回归测试。扩展的 notebook 适合在交接时保留当前决策。它与工作流绑定，开始新的工作流后会清空。下次发布时，两位同事若要还原当时的判断，可以从 Git 差异、测试和工单入手。多个实现者需要并行修改时，分别准备工作树或隔离写入范围。编程智能体运行框架怎样管理工具、状态与验证。
怎样证明用户点到下一页后，修复依然有效？
操作界面之前先写清预期。选择 Open 后，第一页应列出 ORD-101 和 ORD-102。点击下一页，应列出 ORD-105 和 ORD-106，两笔状态均为 Open。地址栏要保留筛选条件和页码，刷新后才能还原同一组结果。
先以缺陷模式运行本地服务。在允许 agent-browser 启动本地浏览器守护进程的机器上，打开第二个终端执行以下命令。示例按链接的可访问角色和名称定位界面控件。快照生成的元素编号即使发生变化，这些命令仍能找到对应的链接。agent-browser 的导航、定位与状态检查命令
# 终端 1
python3 order_filter_lab.py --mode broken --port 8765
# 终端 2
agent-browser open http://127.0.0.1:8765/orders
agent-browser snapshot -i
agent-browser find role link click --name "Open" --exact
agent-browser find role link click --name "Next page" --exact
agent-browser get url
agent-browser snapshot
agent-browser reload
agent-browser snapshot
agent-browser back
agent-browser snapshot
agent-browser find role link click --name "Cancelled" --exact
agent-browser snapshot
agent-browser close交互快照（-i）适合定位控件。完整快照还会返回表格中可读的行内容。使用 @e3 这类引用时，导航后重新获取快照，从新结果中选择引用。如果验收涉及元素对齐或文字是否被截断，再补一张截图。这处缺陷则要看订单号、状态和 URL 是否都正确。快照类型与元素引用
| 检查点 | 缺陷模式 | 修复模式 |
|---|---|---|
| 选择 Open | ORD-101、ORD-102，状态都是 Open。 | 第一页相同。 |
| 点击 Next page | /orders?page=2。显示 ORD-103 和 ORD-104，状态都是 Closed。 | /orders?status=open&page=2。显示 ORD-105 和 ORD-106，状态都是 Open。 |
| 刷新第二页 | URL 没有筛选参数，仍显示同样两笔已关闭的订单。 | URL 保留筛选参数，仍显示同样两笔未关闭的订单。 |
| 浏览器后退 | 回到 Open 的第一页，显示 ORD-101 和 ORD-102。 | 恢复翻页之前的 URL 和订单。 |
| 选择 Cancelled | 没有数据行，显示“No matching orders.”（没有符合条件的订单）。 | 同样显示空结果，URL 保留已取消状态。 |
按 Ctrl-C 停止服务，使用 --mode fixed 重新启动，再重复相同操作。两个版本都能通过“第一页筛选正常”这一项。把行内容和路由状态放在一起检查，才能解释为什么下一页和刷新会失败。后退和空结果则验证了相邻操作是否仍然可用。
如需在后续版本中反复验证，把Playwright 回归测试放在示例文件旁。测试对两个版本使用完全相同的验收条件。即使探索性浏览会话已经结束，另一位审查者也能独立复现。在缺陷模式下，测试在“下一页”失败，退出码为 1。在修复模式下，五项检查全部通过，退出码为 0。
python3 -m pip install playwright
python3 -m playwright install chromium
python3 test_order_filter.py http://127.0.0.1:8765/orders更大范围上线时，可参考产品发布前 QA 检查清单。
团队什么时候值得引入这四个工具？
先从交付中反复出现的问题入手。工程师本来就能快速找到相关函数，为一处六行改动接入向量服务，收益有限。如果代码审查放行的功能经常在用户下一次点击时出错，就应先投资可重复的浏览器断言。已有项目可以逐个引入工具，观察效果后再扩大范围。
- 代码定位太慢：让同一位工程师用现有搜索和 ChunkHound 分别处理难度相近的工单。记录找到正确文件所需的时间，并核对调查结果中有多少条引用真正支持结论。
- 任务范围经常漂移：在 pi-schematic 中保存一套流程，由一位实现者修改、一位审查者复核。统计重复调查、冲突改动和可复现的问题。把简单改动分配给三个付费模型会话，也可能只增加成本。
- 审查漏掉界面缺陷：在浏览器中记录失败，独立写下预期值，打补丁后用同一组条件复测。需要在每次发布都保证的行为，可以把确定性的断言加入 CI。
试点的分母可以用满足约定验收条件的修复数。假设八项修复验收通过，模型调用共花 12 欧元，审查花三小时，按示例费率每小时 80 欧元计算，总计 252 欧元，每项通过验收的修复花费 31.50 欧元，另加基础设施费用。被驳回的尝试同样会占用审查时间，要计入分子。把结果和团队处理同类工单的现有流程对照。更多模型路由与采购取舍见多模型编程智能体技术栈选型指南。
原型进入企业试点时还有其他交付工作，可参考 Twinsoft AI 项目案例。Wavect 的智能体运行框架工程服务帮助团队把仓库工具、智能体流程和发布检查接起来。用一张现有工单设计试点。