反对纯 Vibe Coding

本文档说明本项目对代码贡献的最低要求，以及对 asco/core 等核心模块的额外要求。

本项目不反对 AI 辅助开发，但反对一种不可接受的提交方式：作者本人没有充分检查、没有真正理解、也没有能力在出现问题后独立修复，却仅因为“代码看起来能跑”就将其提交。

这种行为在本文中称为“纯 Vibe Coding”。它不是指使用了 AI，而是指作者把生成结果当作完成标准，而不是把自己对代码、文档和行为语义的理解当作完成标准。

目标

本规则的目标只有两个：

保证提交者真正理解自己贡献的内容。
保证提交者在改动出现问题后有能力继续维护和修复。

任何贡献，无论是否使用 AI，最终责任都在提交者本人。

适用范围

本文适用于所有向本项目提交的代码与文档改动。

为避免流程失衡，本项目按改动影响分为三类：

微小改动：错别字、死链接修复、纯格式调整、不会改变语义的注释修订。
普通改动：一般功能、测试、文档、示例、非核心模块实现。
核心改动：涉及 asco/core，或影响调度、取消、生命周期、并发语义、资源释放路径等基础行为的改动。

微小改动可以不适用本文中的完整材料要求；普通改动与核心改动均适用，其中核心改动适用更严格的额外要求。

本项目反对的不是 AI，而是不可维护的提交

以下行为可以接受：

使用 AI 辅助整理思路、润色文档或生成样板代码。
使用 AI 辅助起草测试、重构建议或命名建议。
使用 AI 提供实现草案，但提交者随后亲自逐段核对并自行修正。

以下行为不可接受：

作者无法解释自己提交的关键逻辑为何成立。
作者无法说明边界条件、失败路径或资源释放路径。
作者将“AI 给出的总结”当作自己对代码的理解。
作者在 review 中无法独立修正自己提交中的明显问题。

在本项目中，“代码能跑”不是完成标准；“作者真正理解并能独立维护”才是完成标准。

普通改动的最低证明义务

每个非微小 PR 原则上都应附带一份作者自证说明。该说明不是变更摘要，而是作者对自己已经亲自检查并理解本次改动的责任声明。

作者自证说明只需要覆盖与本次改动真正相关、真正必要的部分，不需要为了过模板而逐项补满。通常可以围绕以下内容按需说明：

这次改动要解决什么问题。
关键行为发生了什么变化。
自己亲自检查了哪些文件、哪些路径、哪些风险点。
最可能出错的边界条件是什么。
当前测试覆盖了什么，尚未覆盖什么。
如果这里出现 bug，自己会先从哪里开始排查。
本次改动哪些部分使用了 AI，AI 分别参与了哪些环节。
对于 AI 参与生成的内容，自己做了哪些核对与修正。

如果提交者拒绝提供与本次改动直接相关的必要说明，或材料明显只是对改动的表面复述，则该 PR 不会被 review 和合并。

`asco/core` 的额外要求

asco/core 及其他核心路径承担运行时稳定性与长期维护责任，因此要求高于普通改动，提交的代码必须大部分手写。

对于核心改动，作者在提交 PR 前，还应先发 issue 说明自己要提交的改动。该说明同样只需要覆盖必要部分，不需要机械回答所有问题。通常应优先围绕以下问题按需说明：

本次改动维护的语义、不变量或契约是什么。
改动涉及哪些并发、取消、调度、生命周期或资源管理风险。
为什么选择当前方案。
当前方案的已知代价、限制与后续维护负担是什么。

对于核心改动，本项目不接受“我理解大意”式提交。作者必须能够脱离 AI 提供的摘要，独立说明：

关键执行路径如何推进。
状态如何变化。
失败路径如何收束。
资源在何处释放。
并发或取消条件下有哪些风险点。

如果作者只能复述表面目标，而不能清楚说明上述内容，则不视为满足核心模块贡献要求。

“大部分手写”

对于核心模块开发者，本项目要求关键逻辑必须主要由作者本人真正掌握。

这里的“大部分手写”不是对字符数、行数或提交量的机械统计，也不是要求维护者去猜测某段代码“像不像 AI 写的”。本项目采用更严格、也更可执行的标准：

关键逻辑必须处于作者本人可独立维护的控制之下。
维护者有权要求作者脱离 AI 总结，独立解释关键代码的运行方式。
维护者有权要求作者对关键路径做小幅修改、补测试或修边界条件。
任何作者无法清楚解释、无法独立修改、无法独立修复的关键代码，都不应视为满足贡献要求。

因此，“大部分手写”的真正含义不是形式上的输入来源，而是关键逻辑没有脱离作者本人的理解和维护能力。

AI 使用披露

本项目要求贡献者主动披露 AI 的参与情况。披露的目的不是羞辱或惩罚，而是帮助维护者正确判断这次提交的风险边界和 review 深度。

AI 使用披露也只需要说明对本次改动有实际意义的部分，不需要把所有类别都逐项解释。通常可以说明 AI 是否参与了以下类型的工作：

文档润色。
测试样例草拟。
非核心样板代码生成。
核心逻辑草案或实现建议。
重构建议、命名建议或 review 辅助。
风险分析、边界条件整理或说明文字撰写。

如果 AI 参与了关键逻辑，作者还应补充说明：

自己如何逐段核对生成结果。
自己修改了哪些关键点。
自己如何验证语义、边界条件与失败路径。

“我使用了 AI，但我已经亲自核对并对 AI 生成的代码负责”可以接受；“这部分是 AI 写的，但我没有逐段检查”不可以接受。

维护者的验证方式

维护者可以通过以下方式验证提交者是否满足要求：

检查作者自证说明和相关说明是否覆盖了这次改动真正必要的部分，并且与代码一致。
在 PR 讨论中随机抽取两到三个具体问题，要求作者解释实现、边界条件或失败路径。
要求作者补充一个测试、修正一个边界条件、调整一段核心逻辑，观察其是否能独立完成。
对核心改动要求作者说明对象生命周期、状态迁移、取消语义、并发约束或资源释放顺序。

维护者不需要证明作者“使用了多少 AI”，只需要判断作者是否已经充分理解并能够独立维护该改动。

不达标的处理方式

出现以下任一情况时，维护者可以拒绝合并，或要求作者补充材料后重新进入评审：

拒绝提供与本次改动直接相关的必要自证说明。
核心改动未发 issue 说明，或 issue 未覆盖本次改动真正关键的问题。
AI 使用披露明显缺失，或回避与本次改动直接相关的关键问题。
作者无法解释关键逻辑或边界行为。
作者无法独立修正自己提交中的明显问题。
维护者合理判断该改动一旦出问题，提交者本人并不具备后续维护能力。

对于核心模块，上述任一问题都足以构成拒绝合并的理由。

结语

本项目不要求每个贡献者都完全不用 AI，也不把“纯手写”视为形式目标。本项目要求的是更直接、也更严肃的一点：

你提交的代码和文档，你必须亲自看过。
你提交的代码的行为语义，你必须真正清楚。
你提交的关键逻辑一旦出问题，你必须有能力自己继续修。

Keyboard shortcuts

ASCO协程异步框架