为什么要写这篇文章
大语言模型（LLM）改变了很多软件的编写方式，ZAP 也不例外。
ZAP 核心团队的很多人现在每天都在用 LLM 助手，我们也越来越多地看到社区贡献中出现了它们的身影。
这本身没什么问题，但意味着我们得把 ZAP 开发方式的调整讲清楚，让大家知道该抱什么预期。
有些项目正在关上大门
你可能看到过报道：一些知名开源项目开始限制甚至禁止新贡献者提交代码。主要原因是维护者被 AI 生成的 pull request 淹没了——审核这些改动的精力，往往比当初亲手写一遍还多。
我们不想这么做。
ZAP 一直是一个社区项目，以后也会一直是。任何人都可以贡献——不管这是你人生中第一个 pull request，还是第 500 个；不管每一行代码都是手写的，还是在 LLM 的帮助下完成的。我们不会因为你是谁、经验多少、用了什么工具，就给贡献设门槛。
但平衡已经变了
真正改变的是精力天平的两端。
现在任何人写代码都容易了很多，但审核代码一点都没变容易。审核才是当前真正的成本所在：先要弄明白一个改动想干什么，再判断它到底做到没有，然后确认它和代码库其余部分是否合得来，最后还得有把握没有哪里藏着不易察觉的问题。
这种判断，审核者没法外包给别人。如果收到一个让人看不懂的 pull request，里面有提交者自己都讲不清的代码，又或者压根没有测试，那审起来很可能比从头写一遍还费时间——而大家的审核时间就那么多。
说清楚一点：这条规则对所有人都适用，包括 ZAP 核心团队。我们要求别人做到的，自己也一样做到。我们当中已经有好几个人（包括我）的 PR 被打回——或者提交前自己重做——原因就是改动太大、测试太少，或者太难读懂。
PR 提交者要对自己的代码负责
最重要的一条规则是：pull request 的提交者要对自己提出的代码负责。
也就是说，你必须做到：
-
理解它。 如果你讲不清楚这个改动做了什么、为什么这么做——必要时能逐行解释——那你还没准备好提交。“这是 LLM 写的”不能算解释。
-
确信它是对的。 你应该有把握这个改动实现了你的意图，处理了重要的边界情况，也没有破坏别的东西——而不只是能编译通过、在你机器上跑通一次正常流程。
用 LLM 帮忙完全没问题，但躲在它后面不行。PR 上写谁的名字，谁就是负责人。
让 PR 尽量容易审
PR 越好审，我们处理得越快。这不是什么奖励，只是算术——评审时间是稀缺资源，每个改动少花一点，就能多看几个。具体来说：
-
PR 要小。 宁可拆成几个聚焦的 PR，也不要一个大 PR。只改一件事、几百行的改动，比一个几千行、把好几个功能混在一起、或者功能和重构混在一起的大改动要好审得多。如果一个 PR 看起来能拆，就拆。
-
尽量写完整的单元测试。 测试是评审者最快看清你代码要做什么、并建立信心的方式。不要只加一个“能跑通”的测试——要覆盖边界情况和失败路径。如果你确实觉得某部分改动没法做单元测试，在 PR 描述里说明，并解释原因。
-
最好再加端到端测试。 单元测试证明各个部件能工作；端到端测试证明这个功能在真实的 ZAP 里能工作。凡是能用这种方式验证的，都加一个。
-
最好写成 Automation Framework 计划。对 ZAP 来说，最好的端到端测试就是 Automation Framework 计划——我们能直接跑，几乎不用准备：不用手工搭环境，不用特殊配置，也没有没写进文档的前置条件。一个拿来就能跑的计划，能让审查者更快、更全面地了解你的改动，远比一段「我是怎么手动测的」描述有用。
一份简短清晰的 PR 描述同样有帮助：问题是什么、你的思路是什么、你是怎么测的，以及哪些地方你知道还不完整，或者有意留在本次范围之外。
在人工审查之前，LLM 会先看你的 PR
先把我们流程中的一步说清楚：任何稍微像样的改动，我们做的第一件事都是把它交给 LLM 审查。
这不会取代人工审查——审查者仍然要理解这个改动，判断它该不该合进来，并确认它是对的。LLM 这一轮的作用是尽早发现明显问题：漏掉的边界情况、马虎的错误处理、根本没测到东西的测试。这样等真人来看 PR 时，精力就能花在真正需要判断的地方。
由此引出一个建议，我们鼓励所有贡献者都这么做：提交之前，再找一个 LLM 来审查你的改动——注意别用写代码时用的那个。一个全新的模型第一次看到你的代码，往往能发现当初帮你写代码的那个模型漏掉的东西，就像换一双人的眼睛来看一样。如果第二位审查者发现了问题，在开 PR 之前先修掉——先修掉，就能少几轮「请把这个基础问题改一下」的评论。
让集成测试更容易写
为了让上面说的端到端测试更好写，我们正在做的一件事是改造集成测试的构建方式。
我们本来每晚都会跑一批 Integration Tests。其中很多依赖 Dev add-on，它会在 ZAP 内部启动一个简单的测试用 Web 服务，带一个非常基础的模板引擎，我们可以按需扩展出任何功能。因为该 add-on 跑在 ZAP 里面，不需要额外安装软件，我们也能伪造任何需要的接口——这在测试单点登录（Single Sign On）这类功能时非常有用。
到目前为止，这些测试页面都是手写的。但事实证明，LLM 非常擅长生成这类简单的测试页面——这正是 LLM 辅助能发挥价值的场景。
我们正在重构测试服务，让它更可插拔：预计测试用例的数量会快速增长，而测试页面更适合归属到实现对应功能的插件里。改好之后，如果你给某个插件加功能，就能把测试页面和代码放在一起，这样在 PR 里附上端到端测试也会简单很多。
这对未来意味着什么
ZAP 的运作方式没有变——我们仍然是社区项目，仍然欢迎大家的贡献，包括第一次参与的人。变化的是精力投入的方向。写代码的时间少了，理解、测试和审查代码的时间多了。