选一项能独立验收的改动，例如在项目列表里增加状态筛选。固定仓库提交、测试数据和完成标准。每种工作流从同一提交出发，分别记录花在说明需求、修订实现和复核结果上的时间。
给三种工作流相同的输入
行内补全由你先找到组件和测试入口，再在写代码时接受建议。对话式协作先让助手解释数据流，再逐次提交小改动。Agent 执行则给出允许修改的目录、现成测试命令与停止条件，让它完成后交付差异和检查记录。为三组保留同一份需求和测试数据。
用相同的回归检查比较输出
准备包含开放和已关闭状态的样例列表。用 Webapp Testing 检查默认列表、筛选结果、清空条件和无匹配状态，再检查原有分页是否仍能用。分别记录首次通过的时间、是否需要人工纠错、改动涉及的文件及新增的维护负担。
把结果转成选择规则
如果目标只是局部补齐一个函数，记录行内补全是否足够。涉及多个文件时，比较对话协作和 Agent 执行的审阅成本。团队决定采用哪种方式时，可以参考自己可复现的结果，再针对不同规模的任务重复比较。
把任务放进一个隔离分支
在开始前用基线版本打开项目列表，记录默认页的顺序和分页方式。为三个工作流分别建立从同一提交开始的分支，安装同一锁定版本的依赖，使用同一份匿名样例数据。固定浏览器视口与账号权限。对照组的差别是人和工具如何协作，分支、数据和验收方式保持一致。若不同工具使用的模型或权限不同，把这些差异一起写进记录。
这次需求可以写为：在项目列表增加状态筛选，默认显示全部，选择已关闭后只显示已关闭项目。换筛选条件时回到第一页，清空筛选后恢复全部项目。数据由现有接口提供，不新增表、不改变权限、不重写列表组件。打开已有测试目录，找到覆盖列表或分页的用例，用它们作为扩展入口。未说明的交互，例如刷新后是否保留筛选条件，应先确定约定，再开始做对照。
三组实验怎么跑
行内补全：由人负责路线
先自己阅读列表组件和加载函数，决定筛选状态保存在哪里。写出一段小范围变更，再看补全是否沿用已有请求结构。接受建议前检查它有没有改接口参数含义、重置页码或把过滤放在浏览器内。如果接口只返回一页数据，前端过滤这一页会漏掉后续页中的匹配项。保留最终差异，并记录遇到不合适的建议后花了多少时间修正。
对话式协作：每次只交付一个可验收的改动
把入口文件和既有分页测试给助手，先请它解释列表、参数与接口之间的关系。核对解释后，让它先加筛选控件，再接入请求与分页，最后补上空列表的展示。每一步先读差异再跑对应检查。若它建议增加新组件库，让它用现有组件再给一版；比较代码量和将来维护成本。记录为补足上下文进行了几轮往返，以及哪一步需要你提供仓库里的约定。
Agent 执行：约定改动范围与停止点
给 Agent 可以修改的目录、运行命令和允许使用的本地测试资源。任务单要求它先确认仓库规则，再报告计划与入口，遇到缺少权限、连接非测试环境或需要安装额外服务就停下来说明。交付时包含变更文件、运行过的测试、失败输出和未覆盖场景。审阅人从最终差异检查有没有新增全局状态、改变其他列表或改写无关配置，并核对实际运行记录。
用一份结果表算复核成本
使用至少两页样例数据，其中第二页要有一个已关闭项目。分别核对默认列表、仅已关闭、无匹配、清空筛选、从第二页切换条件。Webapp Testing 用于在本地应用启动后组织这些浏览器步骤和可见断言。每个用例写清输入、预期条目、页码和实际结果；遇到失败记录当前地址和能复现问题的最小数据。若服务端支持多个状态参数，再用已有接口测试验证无效值如何处理。
分开记录机器等待时间和人需要投入的时间。人力时间包括写需求、读代码、审查差异、解释失败、修改测试数据和返工；运行时长包括生成、构建与测试。提交后由另一位同事复核一次，记录有多少结论可以从差异和用例直接验证。一次试验只说明这项任务的表现，下一轮可换成修复错误或跨组件改动，看同一套检查能否复用。
常见问题
三种方式能不能混用
可以。先用对话梳理仓库，再用补全写局部改动，最后让 Agent 整理可重复的检查。做对照时把混合方式记成第四组，记录每次交接需要补充的信息。
Agent 很快说完成，为什么还要看数据
成功提示可能只对应界面渲染。固定第二页含有匹配项的数据，确认筛选覆盖完整结果，再测换条件回到第一页。把结果表和测试日志对应起来，才能看出实现是否符合初始需求。
哪种方式适合团队默认采用
从团队常做的几类任务分别抽一项，例如表单校验、跨组件交互和接口调整。复用同一计时口径和交付标准，保留每组的失败案例。把选择规则限定到相似改动与仓库环境，后续工具或流程有变时再复测。