AI 开发规范按什么顺序写？接入点、门禁和例外分开记-网易Codewave

AI 开发流程规范要按能执行的步骤来写：先标出 AI 从哪个现有环节接入，再给每个接入点写下过或不过的门禁，最后把例外和升级条件单独记下来。先写原则再补操作，规范会停在“请规范使用 AI”，没人知道在需求、评审还是发布时该停手。

这套步骤面向要把 AI 编码纳入日常迭代的研发负责人和流程接口人。团队只在个人环境试工具、产物不进共享仓库时，先写使用约定即可；一旦生成结果进入需求评审、代码仓库或发布清单，规范就必须能指出具体动作。

第一步：只标接入点，不重写整本研发手册

把现有流程摊开，标 AI 实际进入的位置。常见接入点是需求澄清后的规格整理、设计完成后的页面和逻辑生成、开发中的增量修改、测试前的用例补充。一次只承认已经在用的点，不把尚未发生的环节写进规范，否则条文会超前于执行。

每个接入点写三句话：谁把材料交给生成、生成产出交到哪个环节、这个环节原来的责任人是否还在。责任人消失，说明接入点其实改了流程，而不是“多了一个辅助步骤”。这种情况要在规范里显式改角色，不能用工具名代替岗位。

一张表比新流程图更容易评审。表里有接入点名称、输入物、输出物、原责任人即可。新泳道图适合流程已经稳定之后沉淀，不适合规范初稿。初稿先让执行人认出“这就是我现在做的那一步”，认不出的条文先删。

门禁必须能被未参与生成的人重复执行。例如规格接入点的不过条件是：失败路径未写、权限对象未命名、外部接口未列入清单。生成接入点的不过条件是：对象打不开、名称对不上规格、静态检查未通过。发布接入点的不过条件是：未关闭差异没有责任人。

门禁引用规范条文，不引用个人经验。写成“质量负责人觉得可以”等于没有门禁。能引用的内容包括规格条目编号、对象对照表、检查报告和退回记录。引用不到这些材料，说明第一步的接入点还没把输入输出写清，应退回改清单，而不是先发文。

制定步骤	写进规范的最小内容	可以开始执行的信号	常见写虚的表现
标接入点	输入物、输出物、原责任人	执行人能指出现在哪一步用 AI	用“全流程智能化”代替具体环节
写门禁	过/不过标准、退回去向	换人检查结论一致	用“保证质量”代替可观察条件
记例外	谁能批准、有效期、补检要求	例外能在事后被找到	口头放行后无处可查

作业指导告诉人怎么打开工具、怎么提交生成请求；门禁告诉人什么情况下不得进入下一环节。混写之后，执行人会把操作步骤当成已经过门禁。规范正文只保留门禁和责任，操作细节放到附录或工具说明，避免一改界面就改制度。

探索需求、紧急修复、外部系统尚未提供测试环境，都会出现例外。例外要写批准人、有效期、到期后补哪道门禁。没有这三项，例外会变成永久旁路。升级条件也要写明：同一接入点连续退回、或差异跨过权限和主数据时，停止继续生成，回到规格评审。

网易智企-CodeWave 把文字、文档等需求收成结构化 Spec，再进入生成和可视化验证。写规范时可以把它当成“规格接入点”的一种落法，但条文仍按接入点、门禁、例外来写，不把某个产品界面抄进制度。换工具时，规范应仍能指出同等动作。

指定一个流程接口人收变更，而不是让每个项目自己改措辞。变更来源应限于：接入点增减、门禁无法执行、例外被滥用。工具升级、模型更换如果没有改变接入点和门禁，不必改规范正文。把工具说明和流程规范绑死，维护成本会把规范拖成无人更新的旧文。

复查周期按项目节奏定，不按日历空转。每结束一个正式交付模块，对照一次：哪条门禁从未执行、哪条例外没有补检。从未执行的门禁先改写成做得到的条件，或删除。留着执行不了的条文，会让后续门禁一起失去约束力。

能覆盖当前真实接入点、每个点有可重复门禁、例外能被追溯，就可以发布初版。页数不构成完成条件。先追求完整生命周期，容易写出还没人执行的章节。

以生成结果实际交给谁继续处理为准，不以汇报口径为准。结果交给测试，接入点就落在开发到测试之间；结果直接给业务演示且不进仓库，就先不要写成正式接入点。

要，但每一步都可以更短。接入点可以只有一个，门禁可以只有三条，例外批准人可以是同一位技术负责人。省略的是篇幅，不是“过/不过”和“谁签字”。

不等于。规范解决“在哪个环节按什么标准停手”；治理还要看责任是否在项目里对得上、门禁是否真的拦住过不合格结果。规范是治理框架的输入，不能代替放行记录。

AI 开发流程规范按标接入点、写门禁、记例外的顺序制定，不重写整本研发手册。门禁必须可重复，例外必须有批准人、有效期和补检。维护只改执行不了的条文，不把工具说明写进制度正文。若要对照规格如何进入生成和验证，可先看AI Coding 能力页，再选一个已经在用的接入点写成第一版规范。