从混乱到有序：aiops如何重塑AI编程的工程纪律？
Abstract
aiops 是我给 AI 编程补的一层工程规范。团队里不同人用不同 AI IDE 写代码，怎么让产出走同一条门禁链——对齐→设计→测试驱动→精简→评审→漂移检查→人确认提交，断点可续、状态可恢复、提交必须人确认。它不追求让 AI 多写代码，而是把工程纪律从"靠人提醒"变成"系统强制"。文章从 AI 编程加速后容易被跳过的交付步骤说起，解释 aiops 怎么把这条链路落到团队代码库里。
过去几年我几乎每天都在用 AI 编程工具写代码——从 Copilot 补全，到 Claude Code 这类能自己读文件、改代码、跑测试的 Agent。单人用很爽，放到团队里就变味。
这篇想说的判断只有一个：AI 编程的瓶颈不在模型够不够聪明，而在工具只加速了「写」，没管住对齐、测试、评审、提交这些更靠纪律的步骤。 下面先讲团队里这个问题怎么爆出来，再讲我怎么把它做成一条门禁链——aiops。
AI 编程提速之后，Code Review 先成了灾难
AI 编程落地团队之后，代码产出确实变快了。同样五个人，以前一周能合几个 PR，现在每人每天可能都能推一版 diff。表面看是研发效率上去了。
但到 PR 阶段，问题一下就炸了。说一个我见过的典型场景：3 个 Cursor、1 个 Claude Code、1 个 Codex + Copilot。A 的 prompt 很准，改完八成一次过测试；B 刚上手，一句「加个分页」就动文件，一次 PR 两百行；C 更省事，直接让 AI 自己 commit。
三个人、三种习惯、三套 IDE，产出节奏却统一变快了。到 PR 阶段，Code Review 简直就是灾难——由于全部都是 AI 生成的代码，大部分的变更，基本需求没有对齐过，改动也没有评审，测试更是有一搭没一搭。Leader 打开一个 PR，面对的不是「这段代码写得对不对」，而是「这个需求到底要做成什么样、做完了没有、有没有人验证过」——这些问题在提交之前根本没有人回答过。
单人开发时，这些缺失的步骤还能靠个人习惯兜住。放到团队里，AI 生成的代码量一上去，所有裂缝都会被放大：
| 裂缝 | 单人时 | 团队时 |
|---|---|---|
| IDE 碎片化 | 用哪个都行 | 五个人五个 IDE，review 要理解五种 AI 思路 |
| 水平差异 | 自己能控制提示词质量 | 有人精准，有人一句话就让 AI 改代码 |
| 上下文断裂 | 自己记得昨天的对齐结论 | 接手同事工作要重新解释背景 |
| 标准难强制 | 自己的习惯自己能管 | 标准只能留到 PR 阶段查，AI 已经写完了 |
| 跨人交接 | 基本不存在 | 没有可恢复状态，重复解释、重复对齐 |
AI 编程工具加速代码的生成，但是原来传统团队里研发的规范，基本被现有的 AI 研发流程跳过了——对齐没做、测试没写、评审没过——Code Review 成了唯一还在强制执行纪律的地方，偏偏它是最后一道关，信息最少。开发者跟 AI 对话时的思路、权衡和口头约定，不会自动出现在 PR 描述里。Leader 打开一个几百行的 diff，看到的只是结果，看不到过程：为什么选了这种实现、哪些边界条件讨论过、原本打算用什么测试来验证——全得靠脑补。AI 写得越快，堆到 Review 阶段的信息黑洞就越大，合并速度反而被产出速度拖住了。
翻了几十个 PR 之后，我发现 AI 代码跳过对齐和评审，会带来三类反复出现的问题：
做多了： 需求是「加一个 health 接口」，AI 的实现里多了探针、内存监控、运行时间统计——每一行单独看都有道理，但都不是这次要做的。没人在动手前把边界写下来，AI 自然不会替你做减法。
做错了，但没人发现： 修一个 bug，diff 看着像修好了。但原有的测试期待返回错误码，接口实际返回的是成功——AI 写的代码能编译、能跑，不会报编译错，这种逻辑偏差只有提前写好失败测试才能暴露。
改多了，范围失控： 本来只需要改两行，AI 顺手加了一层「可扩展」抽象；本来只需要局部修一下，AI 重构了半个模块。如果没有人在代码进 PR 之前审视一遍改动范围，这种漂移会随每个 PR 一点点叠加，越积越多。
AI 写代码的速度上去了，但对齐、验证、审视这些步骤没有人系统地把关。所有欠下的债，最后全堆在 Code Review 这一步，最后项目代码慢慢变成了所谓的“屎山“。
为了让团队里的 AI 产出可控，我做了 aiops
看到上面的局面，我关心的不是「怎么让 AI 再写快一点」，而是：怎么让不同人、不同 IDE、不同会话，走同一条交付流程规范。
规范不能只写在文档里，也不能只靠 leader 在 PR 里补。它得嵌进每次会话的执行路径——记住当前在哪一步、缺什么产物就不准推进、会话断了能从验证过的位置恢复、提交必须等人确认。
aiops 就是给 AI 团队补的这一层工程运行时。核心规范只有一条：从自然语言需求到代码提交，必须经过对齐、设计、测试驱动、精简审查、代码评审、漂移检查、人确认提交。
它主要做这些事：
- 从任务出发 — 用自然语言描述功能、Bug 或重构，不区分 IDE
- 按流程推进 — 补齐缺失决策，展示当前进度，自动保存状态
- 控制改动规模 — 让 AI 只做最小改动，避免过度工程
- 团队标准一致 — 同一份 Skills/Agents 分发到多个 IDE，走同一条门禁
- 断点可续、可交接 —
/aiops 继续从.scratch/<feature>/flow.state.yaml恢复 - 提交必须人确认 — 只有你明确说 commit，才会动 Git
- 辅助理解代码 —
/code-graph生成代码图谱，辅助设计、重构和 Bug 诊断
三条硬规则贯穿始终：
- 需求没对齐，就别开始写代码
- 设计没过审，就别开始拆任务
- 代码评审没通过，就别提交
一句话：它不替你写代码，它替团队把「该怎么交付」写进工具里。
上手：一条命令进来，不同任务走不同路
aiops 使用起来非常简单，入口只有一个：/aiops 命令。你不需要记住二十多个 Skill 和九个 Agent 的名字，描述目标就行。
安装到当前项目：
npx -y github:yugasun/aiops
安装后在 AI 工具里输入命令和需求描述就行，比如：
# 需求
/aiops 给用户列表添加分页和搜索功能
/aiops 加一个 health 接口，返回 status 和版本号
/aiops 登录从昨天部署后开始 500，帮我修
/aiops 在后台加 CSV 导出页，先看界面草图
/aiops 帮我看看架构有哪些可以优化
# 继续任务
/aiops 继续
/aiops 是一个流程编排器。它不会把自然语言简单翻译成一个更长的提示词，而是先判断任务类型，必要时静默初始化项目配置，生成阶段计划。每一步展示人能看懂的文字说明，再派发对应 Skill 和 Agent。阶段结束后，只有门禁校验通过，状态才会推进。
入口原则是：从任务开始，不从工具开始。
这些输入看起来都是一句话，路线却不一样。小功能走对齐 → 设计 → 评审 → 实现 → 提交；Bug 跳过不必要的规划，直接进入诊断；/aiops 继续 不会重新解释需求，而是恢复上次已经验证过的阶段。
不同任务走不同链路（阶段名是内部标识，使用者看到的是中文步骤说明）：
| 任务类型 | 典型输入 | 大致链路 |
|---|---|---|
| 功能 | 「给用户列表加分页」 | 对齐 → 设计 → 设计评审 → 拆任务 → 实现 → 漂移检查 → 提交 |
| 功能 + 界面 | 「做一个带筛选的用户管理页」 | 对齐 → 设计 → 界面草图 → 设计评审 → 拆任务 → 实现 → 提交 |
| Bug | 「搜索结果偶尔返回空数组」 | 诊断 → 实现 → 漂移检查 → 提交 |
| 大功能 | 「做一个 RBAC 权限系统」 | 对齐 → PRD → 垂直切片 → 逐 Issue 实现 → 交接 / 提交 |
| 架构健康检查 | 「看看架构有哪些可以优化」 | 建图谱 → 架构扫描 → 选中候选项 → 对齐 → 设计 → 实现 |
| 继续 | 「继续」 | 读状态文件 → 校验产物 → 从上次验证通过的位置继续 |
一次真实会话里，你看到的不是一堆内部 agent 名字，而是类似这样的步骤：
这个设计有意把内部复杂度藏起来。使用者只需要知道当前第几步、为什么停在这里、下一步要产出什么。
aiops 适合的场景：
| 场景 | 是否适合 | 原因 |
|---|---|---|
| 正式项目里的功能、Bug、架构优化 | 适合 | 需要对齐、测试、评审和可追溯状态 |
| 已经有 OpenSpec / PRD / Issue | 适合组合使用 | 上游规格给上下文，aiops 管交付门禁 |
| 跨多天的大功能，例如 RBAC 权限 | 适合多会话 | 先产出 PRD 和垂直切片，再逐个实现 |
| 带界面的需求 | 适合先看界面草图 | 先确认界面方向，再写业务代码 |
| 一次性脚本、临时数据清洗、小实验 | 不一定需要 | 直接让 AI 写可能更快 |
| 纯探索性技术验证 | 只用原型分支即可 | 先回答可不可行，不急着进入交付 |
| 没有代码库、只有一个模糊想法 | 先 grilling，不要直接 implement | 先把问题问清楚 |
核心机制一：门禁链——没准备好，就不往下推
aiops 里最「反直觉」的设计是：很多 AI 编程工具追求「尽可能帮你把事做完」，aiops 反过来，没准备好就拒绝继续。
| 门禁 | 通过标准 |
|---|---|
| 项目初始化 | 项目上下文可读 |
| 设计评审 | DESIGN_REVIEW.md 包含 APPROVE |
| 原型结论 | 如果走原型分支，必须有 VERDICT.md |
| 精简审查 | 产出 PRUNE.md，可记录「已经够精简」 |
| 代码评审 | REVIEW.md 包含 APPROVE |
| 漂移检测 | 产出 DRIFT_REPORT.md，确认实现没有偏离设计 |
| 准备提交 | 代码评审已 APPROVE，且用户明确要求提交 |
交付阶段内部还有固定顺序：先求精简 → 测试驱动 → 精简审查 → 代码评审 → 准备提交。这些门禁不是写在文档里的 checklist——校验脚本会检查对应产物，不过就不推进到下一阶段。
门禁的价值不是「让 AI 多做几次自我检查」，而是把质量控制从人的记忆变成系统的强制约束。放到团队里，质量不依赖某个人当时记不记得，不同成员产出的代码在 review 之前就具备同样的可合并基线。
换句话说：门禁把「资深工程师脑子里的 checklist」搬进了工具，谁来了都得遵守。
核心机制二：反过度工程——让 AI 先学会少写
交付链路里有一道贯穿始终的纪律，aiops 叫它 Lean（精简原则）。
做软件开发的人应该听过 YAGNI：You Aren't Gonna Need It——在你真正需要某个功能之前，不要去实现它。
听起来简单，但 LLM 的默认倾向不是这样。它学到的是大量「完整方案」的范式：你让它写分页，它可能顺手搞一个泛型 PaginationService，再加策略模式、缓存层和事件总线。
Lean 把 YAGNI 拆成六个台阶，每次 AI 写代码之前必须逐级过一遍：
| 级别 | 检查问题 | 如果是 → |
|---|---|---|
| 1 | 这个东西真的需要存在吗？ | 不需要就不做 |
| 2 | 标准库能做吗？ | 能就用标准库 |
| 3 | 平台原生支持吗？ | 支持就用原生 |
| 4 | 已安装的依赖能做吗？ | 能就用已有依赖 |
| 5 | 一行代码能搞定吗？ | 能就一行 |
| 6 | 能跑的最小实现是什么？ | 写这个 |
同一份 Lean 纪律通过安装器分发到各 IDE 的 Skills 目录，不用在每个平台各维护一份，也不容易因为换 IDE 而漂移。
说到底，让 AI 学会少写，比让它学会多写更值钱。
落到团队：多 IDE、多人、多会话
团队里缺的不是「让 AI 写得更像资深工程师的提示词」，而是把工程纪律落到 多个 IDE × 多个成员 × 多个会话 都能强制执行的运行层。aiops 把「什么时候该问、什么时候该对齐、什么时候该写测试、什么时候该停」这些原本靠 leader 反复提醒的事，变成每个会话都会经过的强制门禁。
角色分离：不让一个 AI 又写又审又提交
第一章里提到的那些问题——做多了、做错了、改多了——有一个共同根源：一个 AI 会话里，设计、实现、审查、提交全是同一个"人"在做。 没有人 challenge 它的设计，没有人检查它的测试，没有人审视它的改动范围。
传统团队里，这些角色天然分开：架构师出方案，开发者写代码，另一个人做 code review，运维负责发布。aiops 把同样的分工搬进了 AI 编程——用不同的 Agent 扮演不同角色，各司其职，互相制约：
| Agent | 角色 | 核心输出 |
|---|---|---|
| architect | 设计决策 + 技术规格 | NOTES.md、tech-spec.md |
| design-reviewer | 设计评审门控 | DESIGN_REVIEW.md |
| builder | 测试驱动实现 | 源码 + 测试 |
| code-reviewer | 代码评审 | REVIEW.md |
| quality-auditor | YAGNI 审计 | 精简审查发现 |
| gitops | Git 操作 | commit + push（仅用户确认后） |
关键不是 Agent 有几个，而是写代码的和审代码的不能是同一个角色。builder 只管写代码和测试，code-reviewer 独立审查，design-reviewer 单独把关设计——就像传统团队里，你不能让写代码的人自己 approve 自己的 PR。
这套角色定义和流程规则（aiops 里叫 Skills）通过安装器分发到各 IDE，团队成员无论用哪个 IDE，走的是同一套分工。完整清单见 https://aiops.yugasun.com/docs/skills
流程编排为什么要写成代码
aiops 里最核心的一段代码不是提示词，而是 plan_flow()——一个纯函数：输入当前状态，输出阶段计划。
为什么要用纯函数？因为流程编排是确定性逻辑，不该交给 LLM 临场猜。「功能任务第二步该走设计审查」「Bug 是否要跳过 PRD」这类决策，用代码表达比写在提示词里可靠——能测试、能回放、行为可被审计。
flow_cli.py 是这个纯函数外面的一层薄壳：状态读写、门禁校验、阶段推进。改了阶段编排逻辑，测试会告诉你哪个任务类型的顺序被破坏了。
这背后是一条我一直坚持的分工：让 LLM 负责理解和生成，让普通代码负责状态机。 出了问题，你能看状态文件、看阶段计划、看门禁结果，而不是只能回头猜模型当时为什么这么做。
跨会话恢复：隔天还能接着做，跨人也能交接
AI 编程有个很现实的问题：会话断了怎么办？
你可能今天做了对齐和设计，明天才有时间继续。团队里还有另一面：A 做了对齐和设计，转给 B 实现；B 做完，交给 C review。每个交接点如果都要重新解释背景，整个团队的速度会被上下文切换拖垮。
aiops 把进度存到 .scratch/<slug>/flow.state.yaml：
version: 2
slug: add-pagination
task_kind: feature_idea
user_description: '给用户列表添加分页和搜索功能'
current_phase_id: task_breakdown
phases_done:
- alignment
- design_spec
- design_review
gates_satisfied:
- bootstrap_done
- design_review_approve
下次输入 /aiops 继续，系统从 current_phase_id 对应的阶段继续，并先检查必要产物——设计评审是否真的通过，而不是因为状态文件里写了某个阶段就假装已经完成。
大功能走多会话模式：先产出 PRD.md 和 issues/*.md，拆成垂直切片，每个 Issue 在独立会话里实现。
对团队来说，A 完成对齐和设计后，把 .scratch/<slug>/ commit 到仓库，B 在自己的 IDE 里输入 /aiops 继续，就能从 A 验证过的位置继续。对齐结论、设计规格、门禁状态都是仓库里的事实，不靠口头交接。
aiops 跟 OpenSpec、Spec-Kit 的区别
最近 AI 编程圈出现了不少 Spec 类工具——OpenSpec、Spec-Kit 等，它们解决的是同一个问题：把需求和变更变成可追踪的文件，让 AI 知道「要做什么、为什么做、这次改了什么」。
aiops 解决的是另一个问题：需求确定了之后，AI 怎么写代码才不会失控。 它不关心需求文档长什么样，它关心的是——AI 拿到需求之后，有没有先对齐边界、有没有先写测试、有没有人审视过改动范围、提交之前有没有人确认。
一句话：Spec 类工具管「做什么」，aiops 管「怎么做才不乱」。 两者不冲突，反而互补——Spec 类工具给 aiops 提供需求上下文，aiops 确保 AI 拿到需求之后按正确的顺序执行，不跳步、不失控。
写在最后
aiops 目前是 v1.4.0，还在我自己的日常开发中持续迭代。它不是银弹，也不能替代工程判断。
但有一件事它确实做到了：让我在用 AI 编程时，不会因为「太快了」而跳过那些本不该跳过的步骤。 在团队里，每一个成员、每一次会话、每一个 IDE 的 AI 产出，都能走同一条门禁链。
如果你也在带一个用 AI 写代码的团队，大概率遇到过跟我同样的处境，那么现在你可以试试 aiops，看看它能不能帮你解决这个问题。
AI 编程真正缺的不是又一个更长的提示词，而是一层工程运行时——把那些原本靠资深工程师记在脑子里的顺序、门禁和克制，写成工具能执行的约束，aiops 试图做的就是这件事。
项目已开源，欢迎试用，也欢迎提 Issue、PR 或者在 Discussions 里聊聊你们团队的痛点。
参考资料
- aiops 官方站点：https://aiops.yugasun.com
- aiops 项目仓库：https://github.com/yugasun/aiops
Continue your reading
When you finish this article, use these paths to continue the thread.
// tags
Explore adjacent topics and move sideways through the knowledge graph.