企业使用 AI 代理进行代码开发的规范
2026Q1 v1 (简略版)
文档使用说明
本《简略版规范》旨在为研发团队提供一套"10 分钟可读、即刻可执行"的 AI 开发红线与行为准则。它浓缩了详细版中 4 万字的核心治理逻辑，删减了复杂的背景论证，保留了必须执行的动作清单。请注意，简略版不代表标准的降低，而是对执行效率的极致追求。
适用范围与边界
本规范强制适用于公司全体服务端研发人员（包括后端、架构、中间件、平台工程及测试开发团队）。适用场景覆盖软件开发全生命周期（SDLC），具体包含但不限于：需求分析、架构设计、代码编写、单元测试、Code Review 以及运维脚本编写。
工具覆盖范围： 本规范同等约束"基于 Chat 的辅助编程"（如 Copilot Ghost Text, Chat Panel）与"基于 Agent 的自主代理开发"（如 Cursor Composer, Windsurf, Devin 等）。任何涉及将代码或业务逻辑委托给 AI 处理的行为，均受本规范管辖。
注： 本规范暂不适用于市场营销文案、行政通知等非工程类 AIGC 内容的生成。
执行力度定义
为确保执行过程无歧义，我们沿用 RFC 2119 标准定义以下三个执行层级。请所有 Tech Lead 在 Review 时严格把关：
版本与反馈
AI 技术演进极快，本规范实行**"季度（Quarterly）迭代制"**。当前版本为 2026Q1_v1，有效期至 2026 年 3 月 31 日。
如果在执行过程中发现规范阻碍了合理的生产力，或者发现了新的 Prompt 注入风险，请立即通过 [内部工单-AI 治理专区] 提交反馈。我们的原则是"治理服务于效率"，优秀的反馈将被采纳并记入技术贡献。
总纲：效率与治理的辩证统一
核心总纲：真正的效率提升，必须且只能在系统性治理的框架内发生。
我们必须清醒地认识到，脱离了质量约束的"AI 编程速度"只是在加速技术债务的堆积。Gartner 预测 2028 年 75% 的工程师将使用 AI，但只有那些建立了完整治理体系的企业，才能将这种"代码生成能力"转化为可持续的"业务交付能力"。
五条核心带走点 (Key Takeaways)
如果你记不住整本规范，请务必死守以下五条底线，它们是保障你职业安全与系统稳定的生命线：
数据红线不可越： 数据分类分级（L1-L4）是物理隔离的铁律。核心密钥（AK/SK）、用户隐私（PII）与未公开财报绝对严禁输入公有云 AI 模型。无论 AI 多么智能，它本质上是一个不可控的第三方服务，泄密即事故。
流程锁死不发散： 严格执行 Spec -> Plan -> Task 的标准作业程序。坚决摒弃"一句话需求直接生成代码"的盲盒模式。必须先用文档定义清楚"做什么（Spec）"和"怎么做（Plan）"，再让 AI 去"做（Task）"。
策略选择要分级： 根据任务风险动态切换模式。对于常规 CRUD 迭代，默认使用 Vibe + Rules 提升手感；但对于涉及资金、鉴权的核心高危模块，必须强制切换到 SpecKit + TDD 模式，用测试用例作为硬性验收标准。
CI 门禁是底线： 自动化流水线（CI Pipeline）是最后一道防线。构建失败、SAST 高危漏洞、单元测试覆盖率不达标（按风险分级），一律 Block。严禁任何形式的"强制通过"或"人情放行"，AI 生成的代码必须比人工代码经受更严苛的机检。
审计留痕防甩锅： 人是最终责任人，但审计记录是还原真相的关键。所有 AI 生成的代码提交必须打上 [AI] 标记，MR 必须附带 Prompt/Spec 摘要。这不仅是为了追责，更是为了在发生"模型幻觉漂移"时，我们能复盘并优化 Rules。
六大原则：红线与默认设置
原则不是挂在墙上的口号，而是指导每一个工程决策的底层逻辑。我们将详细版中的六大原则提炼为以下执行导向的解释。
基础原则
原则 6：治理优先 (Governance by Design)
我们将"治理"硬编码进开发环境的三项默认设置：
默认最小权限 (Default Least Privilege)
解释： AI Agent 不应获得整个文件系统的读写权。默认情况下，Agent 只能读取当前上下文（Context）中的文件，且只能修改用户明确指定的文件。IDE 插件配置应默认关闭"自动读取全库"功能，防止无关敏感文件被上传。
默认门禁阻断 (Default Block)
解释： 在 CI 流水线中，针对 AI 生成代码的检查策略应设为"Strict Mode"。任何 Warning 级别的静态扫描问题（如未使用的变量、潜在的空指针），在 AI 代码中应升级为 Error 并阻断合并。我们不接受 AI 带来的"坏味道"。
默认记录留存 (Default Log)
解释： AI 网关（AI Gateway）必须默认开启日志记录功能。每一条发往 LLM 的 Request 和 Response 都必须被脱敏存储至少 6 个月。如果开发者试图绕过网关直接调用 API，网络层应默认阻断。
两套分级体系：工具 L0-L4 与 治理 L0-L3
注意： 本文同时存在两套"L"编号——自动化分级 L0-L4（工具能力维度）与治理分级 L0-L3（组织维度）。当两者同句出现时，必须写成"工具 L2/治理 L2"以避免误读。
为避免概念混淆，我们明确区分"工具的能力等级（Automation Level）"与"管理的治理等级（Governance Level）"。这是两个独立的坐标系，请勿混为一谈。
L0-L4：工具自动化分级 (Automation Levels)
此分级描述的是**"AI 能帮我做什么"**。级别越高，AI 接管的操作越多，风险也随之指数级上升。
治理 L0-L3：治理分级 (Governance Levels)
此分级描述的是**"我必须遵守什么规矩"**。级别越高，适用的对象范围越小，但管控力度越严。
治理分级体系是本规范的核心骨架。我们通过建立 L0-L3 四级治理模型，旨在解决"一管就死，一放就乱"的难题。L0/L1 级侧重于基础底线与效率赋能，允许团队在红线之上灵活探索；而 L2/L3 级则侧重于确定性与安全性，通过刚性制度与自动化门禁，确保核心资产万无一失。
特别提醒： 同一段落如同时提到工具等级与治理等级，统一写法"工具 Lx/治理 Ly"（例如：工具 L2/治理 L3），以避免概念混淆。
如何组合使用？
治理分级与自动化分级是两套独立坐标。 不要以为治理 L3 级别的核心项目就不能用 AI。相反，你完全可以在治理 L3 严管项目中使用工具 L2（问答）或工具 L3（代理）工具，前提是你必须严格遵守治理 L3 的治理要求（TDD + 双人复核）。
示例： 在一个治理 L2（普通项目）中，可以使用工具 L3（Cursor Agent）进行开发；但在一个治理 L3（支付网关）中，可能仅允许使用工具 L1（补全）或受限的工具 L2，且必须先写测试。
策略怎么选：研发团队速查矩阵
面对不同类型的开发任务，Tech Lead 应在 5 分钟内根据下表完成策略决策。核心逻辑是：风险越低越追求速度（Vibe），风险越高越追求稳健（SpecKit）。
决策原则
常规迭代默认 Vibe+Rules；核心高风险默认 SpecKit+TDD。 如果无法判断风险等级，请遵循"就高不就低"原则，优先选择更严谨的策略。宁可开发慢一点，也不要事后救火。
最小可执行流程：Spec-Plan-Task
为防止 AI 在长任务中发散（Hallucination Loop），我们采用"阶段锁定"的标准作业程序（SOP）。本流程通过将大任务拆解为原子步骤，确保每一步都可验证。
标准作业流程 (SOP)
1. 定义规格 (Spec Phase)
输入： 原始需求 (PRD/User Story)、项目宪法 (Constitution)
动作： 开发者与 AI 对话，明确 API 契约、数据结构、异常处理逻辑，生成 spec.md。
产出： 清晰、无歧义的 Spec 文档。
Gate (硬关口)： Spec Review。必须由 Tech Lead 或对等同事进行人工确认。Spec 不对，坚决不开工。
2. 技术规划 (Plan Phase)
输入： 确认后的 spec.md
动作： AI 分析代码库，规划修改路径，生成步骤清单（ToDo List）。此时 AI 只读不写，不修改业务代码。
产出： plan.md（含依赖分析、影响面评估）。
Gate (硬关口)： Plan Confirmation。开发者确认规划合理，无遗漏文件。
3. 任务执行 (Task Phase)
输入： 锁定的 plan.md
动作： AI 逐个执行 Plan 中的原子任务（Implement）。每完成一个 Task，运行一次测试。
产出： 代码变更 (Code Changes)、单元测试。
Gate (硬关口)： Test Passed。单测绿灯。
4. 审查验收 (Review Gate)
输入： Merge Request
动作： 人工 Code Review，CI 自动化扫描。
Gate (硬关口)： Security & Quality Check。无高危漏洞，覆盖率达标。
Plan/Develop 两段式执行规则
为避免 AI 越做越乱，必须严格区分两个模式：
Plan 阶段（思考模式）： 禁止 AI 写代码。只让它看代码、想方案、写文档。如果发现 Spec 有漏洞，退回到 Spec 阶段修改，不要在 Plan 阶段打补丁。
Develop 阶段（执行模式）： 锁定 Plan 文档。 严禁 AI 在执行过程中随意发散（Scope Creep）或"顺便重构"。如果发现 Plan 行不通，必须停止执行，退回 Plan 阶段重新规划，严禁"硬写"。
三类资产：Rules / Constitution / Prompt
在 AI 时代，Prompt 和 Rules 是新的源代码。我们通过三层资产体系来管理 AI 的行为。
1. Rules (工程规范)
2. Constitution (项目宪法)
3. Chain of Command
当指令冲突时，AI 听谁的？
Platform System Prompt (平台兜底)
Project Constitution (宪法)
User Prompt (你的指令)
Tool Output (工具结果)
规则： 如果你的 Prompt 违反了 Constitution（例如要求关闭鉴权），AI 必须拒绝执行并报错。
质量门禁（按风险分级）
AI 生成代码容易出现"看起来对，实际有坑"的情况。我们不再实行一刀切的门禁，而是根据风险等级执行差异化阻断。
Hard Gates (阻断性门禁)
覆盖率分级阈值
规则： AI 生成代码量越大，测试要求越高。Tech Lead 需在 constitution.md 中固化本项目适用的具体阈值。
TDD + AI 五步法
对于治理 L3 级系统，必须严格执行：
人写 Spec
AI 生成测试用例 (Test)
人 Review 测试 (Gate)
AI 写实现代码 (Code)
CI 绿灯通过 (Pass)
安全红线（数据与供应链）
数据分级输入策略
严禁将高等级数据输入低等级信任域。
供应链安全行动
疑似敏感信息处理 SOP
如果在 AI 对话框中不小心粘贴了敏感信息：
停止 (Stop)： 立即停止当前对话，不要试图解释。
删除 (Delete)： 删除该 Session/Chat 历史。
上报 (Report)： 向安全团队报备（免责条款：主动报备可免责）。
轮换 (Rotate)： 如果是密钥，立即作废并轮换。
审计留痕与事故响应
审计留痕三件套
事故响应 SOP (4 步法)
当发生疑似由 AI 代码导致的线上故障时：
止损 (Mitigate)： 优先回滚版本，切断流量。立即暂停该项目使用 AI 工具，防止 AI 基于错误上下文继续"胡说"。
取证 (Evidence)： 提取生成该代码的 Prompt 记录、Spec 文档、模型版本。不要只看代码，要看"它是怎么被生成出来的"。
分析 (Analyze)： 进行 5Why 分析。根因通常是：Spec 描述不清？Prompt 误导？还是 Reviewer 盲目 Accept？
改进 (Improve)： 必须将本次教训写入 .cursor/rules，形成一条新的"防复发规则"（例如：禁止使用某个有 Bug 的库）。
