用 Claude+Codex 开发生产级 AIOps：提示词约束、开发流与验收方法
很多人用 AI 写代码时，最容易遇到的问题不是“AI 不会写”，而是“AI 写得太快，边界没有跟上”。一个生产级 AIOps 平台，不能只看功能是否跑通，还要看权限、审计、SQL、版本、构建、部署、回滚和敏感信息是否都被管住。
这个 AIOps 项目已经完成上线，代码实现由 Claude+Codex 完成。这里说的“AI 开发”，不是把一句话丢给模型，也不是小白复制提示词就能交付生产平台。它需要先具备足够的运维、架构、权限、安全、发布和验收经验，再把这些经验转成 AI 能执行的提示词和工程规则。
本文重点讲开发方法，不贴源码，讨论如何用脚手架、提示词和文档约束，让 AI 从需求一路推进到可交付版本。
1. 一行代码不写，不等于没有工程门槛
如果只对 AI 说“帮我做一个公网 IP 管理功能”，它很可能先生成页面，再补接口，最后留下权限、审计、导入模板、SQL 幂等和发布文档的缺口。
所以第一道门槛不是写代码，而是知道一个生产功能应该包含哪些部分。没有这层知识储备，AI 生成得越快，缺口越隐蔽。
更稳的方式，是把 Codex 当成一个工程团队来管理。每个需求进入开发前，都要先回答这些问题：
| 问题 | 目的 |
|---|---|
| 这个功能属于哪个菜单和能力域 | 避免功能入口混乱 |
| 哪些操作是高风险写操作 | 决定权限、二次确认和审计 |
| 数据模型是否需要新表或字段 | 决定 SQL 和兼容升级 |
| 是否影响 edge-agent | 决定是否升级边缘组件 |
| 如何验收 | 决定测试、截图和浏览器冒烟范围 |
| 如何发布和回滚 | 决定版本、镜像、SQL 和升级文档 |
这些问题回答清楚以后，AI 写代码才不会散。
这也是为什么“一行代码不写”并不等于“任何人都能做”。真正难的是把隐性的生产经验显性化，再让 AI 按这个结构执行。
2. 工程规模越大，越需要提示词纪律
这个项目最终不是一次性生成的小工具，而是一个 30 万行级别的生产工程。按非空行粗略统计，排除常见构建产物、依赖目录和图片资产后，仓库仍约有 2,957 个文件、30.7 万行工程内容。
其中后端 Java 约 10.6 万行，前端 TS/TSX 约 7 万行，edge-agent Python 约 3.5 万行；后端包含 42 个 Maven 模块/聚合、69 个 Controller、112 个 Service 实现、143 个 DAO 接口；前端 src/pages 下约 258 个页面文件；边缘 Agent src 下约 82 个 Python 文件。
前端目录还包含部分静态运行时资产，所以不能把所有行数都简单理解为业务代码。但这个体量足以说明一件事：AI 不是在替人写几个函数，而是在一个跨前端、后端、数据库、边缘执行器、文档和发布流程的大工程里持续协作。
规模一上来，提示词就不能只写“帮我实现某功能”。它必须变成工程约束，明确菜单、权限、SQL、审计、版本、敏感信息、测试、截图和发布文档，否则每一轮自动生成都可能扩大债务。
3. 先搭脚手架，再谈 AI 速度
AI 适合在清晰边界内高速推进，不适合在一片空地上替人决定所有工程秩序。
这个项目能用 Claude+Codex 持续开发，前提是先搭好了基础脚手架：
| 脚手架 | 作用 |
|---|---|
| 前端路由和菜单体系 | 让新功能知道放在哪个能力域 |
| 后端分层和模块边界 | 让接口、Service、DAO、模型不混乱 |
| 权限和菜单 SQL 规则 | 让页面入口、接口鉴权、角色授权同步 |
| edge-agent runtime 规范 | 让边缘能力保持受控 API，而不是任意脚本 |
| 文档和发布目录 | 让设计、进度、升级和回滚有固定位置 |
| 版本和镜像规则 | 让生产交付不会被临时 tag 污染 |
有了这些地基，AI 才能像工程团队一样扩展功能。没有这些地基，AI 只能不断生成局部补丁。
4. 提示词要先约束边界
这个项目里最重要的提示词约束，不是“代码写得优雅”，而是“哪些事情不能做”。
提示词不是模板魔法。高质量提示词背后，是对业务、架构和生产风险的理解。你必须知道哪些字段敏感、哪些操作危险、哪些状态不能跳过、哪些发布动作会影响线上，才能写出有效约束。
典型约束包括：
不要泄露真实 IP、客户名、主机名、密码、Token、私钥。
不要把构建产物、node_modules、target、dist 长期留在项目目录。
不要只做前端隐藏，危险操作必须后端强校验。
不要使用 latest、local 或长后缀 tag 作为生产版本。
不要把 edge-agent 当成有状态数据库或任务中心。
不要把任意 shell 执行能力暴露给边缘 Agent。
这些“不要”比“要实现什么”同样重要。它们决定了平台最终是不是生产系统，而不是演示项目。
5. 开发流文档是 AI 项目的记忆
AIOps 项目里，每个重要功能都有设计文档和开发进度文档。它们不是形式主义，而是长周期 AI 开发的记忆系统。
例如边缘运维能力会记录：设计结论、目标、非目标、菜单结构、总体架构、责任边界、数据模型、安全策略、接口草案和验收清单。
开发流则记录每轮变更：
阶段：
本轮目标：
修改范围：
测试命令：
测试结果：
风险：
下一步：
这样做有两个好处。
第一，Codex 在下一轮开发时可以从文档恢复上下文，不需要靠聊天记录猜测历史决策。
第二，人工验收时能快速判断这轮改动是否越界，是否漏掉 SQL、权限、版本或发布说明。
6. 需求拆分必须包含非目标
生产项目里，非目标经常比目标更重要。
以 Ceph 巡检为例，目标是通过 edge-agent 做只读采集，中心平台生成 Excel、统计图和 AI 分析。非目标则包括：不让中心平台直连边缘 SSH、不开放任意 shell、不执行 Ceph 变更命令、不复用 PVE runtime 接口、不把历史脚本目录打进生产镜像。
这些非目标能防止 AI 为了“快速实现”做出危险捷径。
再以公网 IP 管理为例，第一阶段只做 IPv4 公网 IP 台账、CIDR 拆分、客户分配、回收、批量导入和运营商识别，不做 IPv6 地址池展开，不自动下发防火墙，不做带宽计费。
功能越复杂，越要把第一阶段范围压清楚。
7. 前端、后端、SQL、权限要一起验收
AIOps 这类平台常见的问题是“页面看起来完成了，但生产不能用”。原因通常是其中一层没闭环。
一项功能至少要同时检查：
| 层 | 检查点 |
|---|---|
| 前端 | 菜单、按钮、表单、表格、弹窗、导入导出、错误提示 |
| 后端 | 接口、参数校验、状态机、异常分支、权限强校验 |
| SQL | 表、字段、索引、菜单、接口权限、幂等升级 |
| 权限 | 有权限可见可用，无权限隐藏且后端拒绝 |
| 审计 | 高风险写操作有成功/失败记录，敏感字段脱敏 |
| 发布 | 组件版本、镜像 tag、升级文档、回滚路径 |
Codex 可以同时改多层，但验收时必须按层拆开看。
这里的验收能力也是门槛。你要能看懂接口返回、构建日志、SQL 升级结果、权限缓存、浏览器截图和容器镜像 tag。否则 AI 说“完成了”，你也无法判断它是不是真的能上线。
8. 浏览器截图是很有效的验收方式
在这个项目里，截图不是为了好看，而是为了发现真实 UI 问题。
比如搜索栏是否拥挤、表格横向滚动条是否可见、按钮是否越权展示、弹窗是否能表达二次确认、页面是否仍显示旧版本文案，这些问题靠读代码不一定能发现。
平台中也保留了前端自动截图工作流：扫描路由、自动登录、截取页面、收集 DOM 摘要和可访问性树。这样 AI 可以用截图和 DOM 反向分析页面结构，再给出修复建议。
9. edge-agent 变更要单独上锁
AIOps 的边缘能力依赖 edge-agent。只要变更涉及 runtime、capabilities、API 入参/出参、内置脚本或运行时资产，就必须把 edge-agent 纳入发布影响面。
典型场景包括：
| 场景 | 是否需要评估 edge-agent |
|---|---|
| PVE 虚机清单字段采集 | 需要 |
| PVE/Ceph/网络巡检 | 需要 |
| 网络设备测试连接 | 需要 |
| 巡检 artifact 下载 | 需要 |
| 只改前端展示文案 | 通常不需要 |
| 只改后端查询筛选 | 视是否依赖 Agent 返回字段而定 |
这条规则能避免一个常见生产事故：backend/frontend 已升级，但边缘 Agent 仍是旧版本，结果页面有按钮，后端有接口，实际边缘执行失败。
10. 版本和发布规则要写死
AI 开发很容易产生很多临时版本名，例如带日期、功能名、环境名或 SNAPSHOT。这对生产交付很危险。
AIOps 的版本规则被固定为：
backend/control：v0.1.x
frontend：v1.0.x
edge-agent：v1.1.x
生产镜像 tag 必须是 vX.Y.Z。禁止使用 latest、local、日期后缀、功能名后缀、环境名后缀或覆盖旧 tag。
发布文档也必须记录：组件版本、是否包含 MySQL 变更、SQL 文件清单、升级步骤、验证步骤、回滚方案和用户侧注意事项。
11. AI 开发的真正优势
Claude+Codex 的优势不是少写几行代码，而是能在同一轮工作里完成多层联动。
一个需求从设计到上线，可能同时涉及前端页面、后端接口、DAO、SQL、权限、审计、测试、文档、升级手册和截图验收。传统开发里这些工作容易分散到多人、多天、多次沟通。AI 适合在明确边界内连续推进。
但前提是人要把目标和边界说清楚。AI 越强，越需要明确约束，否则它会用很高的效率扩大错误。
当工程规模达到数千文件、数十万行时，真正节省的不是某一个接口的编码时间，而是跨模块联动的上下文切换成本。Codex 可以把“改页面、补接口、加 SQL、更新权限、写文档、跑验证”放在同一条工作流里完成，人的重点则转向设计、约束和验收。
这类项目的含金量，恰恰在于人能把复杂系统拆成 AI 可执行的任务，并持续判断 AI 的产出是否满足生产标准。
12. 小结
用 Claude+Codex 开发生产级 AIOps，我认为最关键的是 5 件事。
第一，先有知识储备和脚手架，再谈 AI 开发速度。
第二，先写设计和非目标，再让 AI 执行。
第三，把提示词约束写成工程规则，尤其是安全、权限、版本、发布和敏感信息。
第四，开发流文档必须持续更新，让 AI 项目有长期记忆。
第五，前端、后端、SQL、权限、审计和发布要一起验收。
第六，截图和浏览器冒烟要进入流程，因为真实页面能暴露很多代码审查看不到的问题。
AI 可以写完整个平台，但生产边界必须由工程纪律来守住。所谓一行代码不写，不是没有能力门槛，而是把能力从“敲代码”迁移到“定义系统、约束系统、验收系统”。
