从生成代码到实验验证：拆解 Luca Ferrari 自述的协作流程

代码已经生成，接下来交给谁？工程负责人批准之后，是否就能说明这次改动值得上线？这两个问题，决定了 AI 编程工作流能否从产出代码走向可控的产品迭代。

Luca Ferrari 的访谈提供了一段值得拆解的流程描述：使用者确认方案后，工具生成代码；工程负责人审核，并在认为合适时批准；由于流程与公司的 A/B 测试系统集成，系统会建立用于测试新方案的分组。

本文依据的是 Luca Ferrari 访谈的第三方转录片段。这些内容属于受访者自述，并非对工具能力或运行效果的独立验证。它的参考价值，在于呈现了生成、人工审核与实验之间的交接，而不是证明某种工具已经提高开发效率。

访谈片段明确描述了两个环节：使用者对方案满意后，工具会生成代码；随后，工程负责人可以审核，并在认为合适时批准。

片段还称，这套流程与公司的 A/B 测试系统集成，可以自动建立测试新方案的分组，并以新用户引导流程为例。

这里需要区分三种判断：

这张表是对协作流程的分析，不是访谈披露的内部审批规范。

尤其要注意，建立实验分组不等于完成效果验证。片段没有提供实验结果，也没有说明代码批准、部署和分组创建的具体先后关系。因此，不能把这段描述扩写成“审核通过后自动上线，并被证明有效”。

对软件工程师、产品设计师和产品经理而言，这种区分能帮助团队明确：当前拿到的是哪一种批准，还有哪一种证据没有取得。

“对方案满意”可以启动实现，但如果满意的理由没有记录，工程审核就容易变成逐行看代码，却不知道改动究竟要解决什么问题。

以下是可借鉴的交接方法，并非 Ferrari 团队已披露的做法。

以片段提到的新用户引导流程为例，方案确认时至少应写清：

这些信息可以很短，放在任务描述或代码审查请求中即可。关键是让审核者能够对照，而不是只看到一句“优化引导体验”。

设计师可以说明交互状态与异常路径；产品经理可以说明目标和实验假设；工程师可以补充接口、数据和实现约束。这是职责分配建议，实际负责人仍取决于团队安排。

方案也不必一次写到完美。生成代码后，如果发现原方案遗漏了重要边界，应回到方案层面确认，而不是让工具自行决定产品行为。代码生成能够推动实现，但不能替团队补做未经确认的产品决策。

按访谈自述，工程负责人仍保留审核与批准职责。这说明该流程没有因为引入代码生成，就取消人工判断。

不过，片段没有披露审核标准、自动化测试覆盖、安全检查或回滚机制，不能据此认定这些保障已经存在。

如果借鉴这一流程，可以把生成代码的审核分成几个具体检查点：

这些是一般工程实践建议，不代表访谈中的工具已经自动完成了检查。

交接时，审核者需要的不只是代码，还包括改动摘要、验证方式和已知限制。批准记录也应说明批准的范围：是允许合并，还是允许进入实验环境？二者不应默认等同。

测试通过能够支持部分工程判断，但仍不足以说明用户会更顺利地完成引导。到了这里，团队确认的是实现是否具备进入下一环节的条件，产品效果还需要另外验证。

访谈所述的集成能力，连接了生成代码与测试分组的建立。它减少了哪些操作、是否缩短周期，片段没有提供可独立验证的数据。

从协作角度看，自动创建分组之后，仍有几件事需要明确：

这同样是一份建议清单，不是对该公司实验系统功能的描述。访谈未披露随机分配方式、样本规模、观察周期或结果判断标准。

因此，“实验组的指标看起来更高”也不能直接写成“改动有效”。还需要检查差异是否可靠、数据是否异常，以及改善是否伴随其他损失。若结果暂不支持判断，就应保留“尚未验证”的状态。

对于准备美国软件工程师（Software Engineer）、产品经理（Product Manager）或产品设计师（Product Designer）岗位的读者，这条流程也能用于整理项目经历。与其只说“用 AI 生成了代码”，不如说明自己参与了哪个环节、提交了什么审核证据、实验如何设计，以及结果能够支持什么结论。

如果项目没有上线或没有完成实验，就明确写到已经完成的阶段。方案被接受、代码获批准和效果得到验证，各有价值，但不能互相替代。下一次使用代码生成工具时，先确定这三个判断分别由谁负责、依据什么证据作出，交接才算真正清楚。