从 Prompt 到 Spec：一套通用 AI 编码规范工程化落地方法论

原创已于 2026-06-17 17:02:45 修改 · 296 阅读

5 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#prompt #人工智能

于 2026-06-17 17:00:53 首次发布

全栈专栏收录该内容

8 篇文章

订阅专栏

AI 时代程序员必备技能

Codex、Claude Code、Cursor、Hermes Agent、OpenClaw等工程化实战专栏，讲透 AI 如何接管脏活累活

一键订阅

统一 Cursor / Claude Code / GitHub Copilot / JetBrains AI 的项目级代码生成规则。

前言

如今 Cursor、Claude Code、GitHub Copilot、JetBrains AI 等工具，已经逐渐成为团队日常开发流程的一部分。

初期使用 AI 编码时，体验通常非常高效：

简单描述需求，就能生成样板代码
粘贴报错信息，AI 可以快速给出修复方案
批量生成注释、测试、接口适配代码，显著减少重复劳动
对新人来说，也能降低理解陌生代码的门槛

但长期落地之后，几乎所有团队都会遇到同一个问题：

AI 生成的代码，开始脱离项目体系。

这些代码往往语法没错，逻辑也能跑，但和现有工程架构、编码风格、领域约束、异常处理方式并不一致。

典型问题包括：

Android 普通项目：AI 随意创建新工具类、混用 MVI / MVVM、协程生命周期泄漏、硬编码字符串
后端 Spring / Ktor 项目：擅自新增统一返回体、乱用线程池、事务边界混乱
金融 / 电商高风险项目：误用 Double 处理金额、敏感日志打印、RTL 适配缺失，直接埋下线上事故隐患
多人多工具协作场景：Cursor、Copilot、Claude 各自生成一套实现，代码库风格持续分裂，技术债不断堆积

举一个更具体的例子。

在一个 Android 金融项目里，同样是“生成金额展示逻辑”：

Cursor 可能生成 Double + String.format
Claude Code 可能使用 BigDecimal，但新增了项目里不存在的 MoneyUtils
GitHub Copilot 可能顺手补全一个硬编码美元符号
Codex 修改时可能绕过项目已有的 NumericFormat

这些代码单独看都能跑，但放进同一个项目里，就是维护灾难。

问题根源并非 AI 能力不足，而是我们只使用一次性的临时 Prompt，却没有给 AI 划定项目级统一工程边界。

本文提出一套更适合团队长期落地的方案：

从碎片化对话 Prompt，升级为纳入版本管理的 AI Coding Spec。

一套规则兼容多种 AI 编码工具，适用于 Android、后端、前端、桌面端、开源组件等不同类型项目。

一、为什么单次临时 Prompt 无法支撑长期团队开发

1. 生命周期极短，无记忆持久化

临时 Prompt 只作用于当前对话窗口。

关闭会话、新建聊天后，之前所有约束都会清空。上次反复提醒 AI 的禁用规则、项目工具类、架构分层，下次生成代码时可能全部失效。

开发者不得不反复口述同一套规则。

2. 多 AI 工具规则割裂，无法统一

团队成员的工具选择通常并不一致：

有人用 Cursor
有人用 GitHub Copilot
有人使用 Claude Code
有人使用 JetBrains AI
有人使用 Codex 类 Agent

如果只靠个人聊天框里的 Prompt，各工具之间没有共享规则，最终产出的代码会形成多套标准，统一 Review 成本极高。

3. 不可版本管理、不可迭代、不可评审

写在聊天框、本地备忘录或个人文档里的提示词，存在几个天然问题：

无法提交 Git，变更没有记录
无法组织团队 Review，规范好坏全靠个人主观判断
业务迭代新增约束时，无法批量同步给所有开发者
团队成员手里的提示词版本可能完全不一致

4. 只能约束代码生成，难以支撑重构与自动评审

临时 Prompt 通常只服务单次代码生成。

在重构旧代码、修复线上 Bug、提交前自查、代码评审等环节，它很难被稳定复用，也很难形成自动化规则校验。

最终，违规代码仍然只能依靠人工肉眼排查。

核心结论

Prompt 解决单次临时需求。
Spec 解决项目长期、多人、多工具统一编码管控。

从临时 Prompt 升级到工程化 Spec，是 AI 辅助研发长期落地中非常关键的一步。

维度	临时 Prompt	AI Coding Spec
生命周期	单次对话有效	项目长期有效
存储位置	聊天窗口 / 个人笔记	Git 仓库托管
团队协作	难同步，难集体评审	可提交、可评审、可持续迭代
工具兼容	每个工具单独提醒	多工具共用同一套规则源
适用场景	单次代码生成	生成、重构、Review、Bug 修复全流程
风险控制	依赖人工反复口头提醒	规则前置约束

二、什么是通用 AI Coding Spec

AI Coding Spec 是一份同时面向开发者与 AI 双可读的标准化规则文档。

它区别于传统只给人阅读的代码规范文档，核心特点是：

使用 MUST / MUST NOT / SHOULD 三级强约束语法，减少模糊描述，让 AI 更容易稳定识别并执行
存放于项目仓库，由 Git 统一版本管理
作为唯一规则源，被 Cursor、Copilot、Claude、JetBrains AI、Codex 等工具共同引用
覆盖三层约束：通用代码风格、项目专属架构规范、业务领域红线规范

三级约束语法

约束等级	含义	典型落地场景
`MUST`	强制要求，必须遵守；AI 生成违规代码时需要主动修正，提交前必须整改	空安全、结构化并发、统一返回体、数据存储类型、线程调度
`MUST NOT`	绝对禁止，不允许生成、保留、重构出对应代码	`GlobalScope`、`!!` 非空断言、硬编码常量、裸线程、敏感信息日志打印
`SHOULD`	推荐统一规范，无明显线上致命风险，主要用于对齐团队代码风格	命名规范、作用域函数选型、单行长度、注释格式

三层规则模型

建议把 AI Coding Spec 拆成三层：

层级	作用	示例
通用代码规范	约束基本代码质量	命名、空安全、函数长度、集合类型、异常处理
项目架构规范	约束 AI 不要破坏现有工程体系	MVVM / MVI / DDD、Repository、统一返回体、错误封装
业务领域红线	约束高风险业务边界	金额精度、库存扣减、事务边界、权限校验、敏感日志

三、通用标准化仓库目录结构

顶层架构设计思想

specs/：唯一真实规则源，所有规范只在此维护，不做多份副本
根目录工具入口文件：仅做规则引用转发，不重复编写约束，减少维护成本
prompt-templates/：标准化自然语言提示词模板，降低开发者描述需求的学习成本
examples/：正反示例代码，给 AI 提供项目标准实现参考，减少理解偏差

推荐目录如下：

project-root/
├── specs/                        # 核心规则源（全 AI 共用）
│   ├── 01-base-code-style.md     # 通用编码规范
│   ├── 02-concurrent-spec.md     # 并发 / 协程 / 线程池统一规范
│   ├── 03-architecture-limit.md  # 项目专属架构约束
│   ├── 04-i18n-ui-spec.md        # UI、多语言、布局适配规范（客户端 / 前端按需启用）
│   ├── 05-security-safe-spec.md  # 通用安全红线
│   └── 06-domain-rule.md         # 业务领域专属规范
├── prompt-templates/             # 标准化自然语言提示词库
│   ├── generate-business-code.md # 业务代码生成标准话术
│   ├── refactor-old-code.md      # 代码重构专用提示词
│   ├── ai-auto-review.md         # 提交前自动化评审模板
│   └── fix-bug-template.md       # Bug 修复约束模板
├── examples/                     # 规范正反示例代码
│   ├── correct/                  # 项目标准正确写法
│   └── bad/                      # 禁止使用的错误示例
├── AGENTS.md                     # Codex / AI Agent 全局入口
├── CLAUDE.md                     # Claude Code 自动读取入口
├── .github/
│   └── copilot-instructions.md   # GitHub Copilot 仓库级全局规则
├── .cursor/
│   └── rules/
│       └── global-spec-all.mdc   # Cursor 模块化规则，统一引用全部 specs
└── README.md                     # 规范接入文档、多工具配置教程

注意：不同 AI 工具的规则加载机制不同，入口文件只负责声明规则，实际效果以工具当前版本能力为准。团队落地时，建议结合工具官方文档验证规则是否被正确读取。

四、分文件 Spec 内容示例

下面给出几份通用模板，可以根据项目情况直接删减或扩展。

示例 1：`specs/01-base-code-style.md`

# 通用基础代码风格 Spec

## 命名约束

MUST：类、接口、枚举使用 PascalCase；函数、局部变量、成员属性使用 camelCase；常量使用 UPPER_SNAKE_CASE。

MUST：包名 / 文件路径全小写，禁止大写、下划线拼接。

MUST：布尔变量以 is / has / can / should 开头，语义清晰。

SHOULD：扩展函数命名贴合原生系统 API，保持风格统一。

## 变量与集合

MUST：优先使用不可变声明 val / const val；仅真实可变状态使用 var。

MUST：对外暴露接口优先返回只读集合 List / Set / Map，Mutable 集合仅允许内部实现使用。

MUST NOT：非单元测试场景禁止使用 !! 非空断言；空值依赖安全调用 ?. / ?: / let 处理。

SHOULD：集合多步链式运算可使用 sequence 减少中间对象。

## 函数设计

SHOULD：复杂参数建议封装为请求对象 / 配置对象，避免函数参数持续膨胀。

MUST：对外 SDK / 公共 API 必须补充完整文档注释，标注入参、返回值、异常。

MUST NOT：对外 API 禁止直接返回无语义 null，优先使用空集合、密封状态类、Result 包装。

SHOULD：单行简单逻辑使用单表达式函数；高阶函数 lambda 后置，使用尾随语法。

## 格式规范

SHOULD：单行代码长度不超过 120 字符，超长语句规范换行对齐。

SHOULD：避免多层嵌套作用域函数，复杂逻辑拆分为独立函数。

示例 2：`specs/02-concurrent-spec.md`

# 并发、协程、线程统一 Spec

## 结构化并发通用约束

MUST：全程遵循结构化并发，协程生命周期与宿主绑定，自动取消。

MUST NOT：全局禁用 GlobalScope、裸线程、手动创建无管理线程池。

## 调度器 / 线程池分配

MUST：IO、网络、文件、数据库操作切换至 IO 调度器 / 专用线程池。

MUST：UI 渲染、视图回调固定主线程执行；CPU 密集计算使用 Default 调度器或项目指定线程池。

MUST：所有远程 IO、第三方调用强制增加超时保护。

## suspend 挂起函数规范

MUST：仅耗时阻塞逻辑声明 suspend；普通纯计算函数禁止随意添加 suspend。

MUST NOT：suspend 函数内部使用 Thread.sleep、同步锁长时间阻塞线程，优先使用 delay 或可取消机制。

## 异常与取消

MUST：耗时循环内主动响应取消；资源释放统一写在 finally。

MUST：顶层协程配置全局异常处理器，独立任务异常隔离使用 supervisorScope 或项目已有封装。

MUST NOT：空捕获异常，catch 块必须日志、包装结果或重新抛出。

示例 3：`specs/03-architecture-limit.md`

# 项目架构强制约束 Spec

MUST：生成 / 修改代码前，优先检索项目现有基类、工具类、扩展函数、分层组件。

MUST：严格遵循项目统一分层架构，禁止擅自新增分层、数据模型、返回体。

MUST：复用已有封装能力，无同类实现时才可新增工具类 / 方法。

MUST NOT：AI 不得臆造项目不存在的基类、Manager、Repository、第三方依赖。

MUST NOT：同一业务域同时维护两套实现方案，重构时统一收敛为项目标准写法。

示例 4：`specs/06-domain-rule.md`

业务领域红线是 AI Coding Spec 最容易拉开差距的部分。

通用代码风格只能解决“看起来是否统一”，领域红线解决的是“会不会出事故”。

下面以金融项目为例：

# 业务领域红线 Spec（金融项目示例）

MUST：所有金额计算 / 存储 / 展示使用 BigDecimal 或项目统一 Money 类型，禁止使用 Double / Float。
理由：Double / Float 存在二进制浮点误差，可能导致金额展示和对账异常。

MUST：金额精度统一由项目金额格式化工具控制，禁止业务代码手写 scale、舍入模式、String.format。
理由：分散格式化会导致不同页面金额展示规则不一致。

MUST NOT：日志中打印用户手机号、银行卡号、身份证号、交易密码、token 等敏感信息。
理由：敏感信息泄露会引发合规和安全风险，必须脱敏后输出。

MUST：库存扣减、金额扣减、账户余额变更必须在事务保护内完成，必要时增加分布式锁或幂等校验。
理由：并发场景下缺少事务 / 锁 / 幂等保护，可能导致超卖、重复扣款、资产不一致。

不同业务可以替换成自己的领域红线：

电商项目：库存扣减、优惠券核销、订单状态流转
支付项目：幂等号、回调验签、重复通知处理
游戏项目：道具发放、充值到账、排行榜结算
企业后台：权限校验、审计日志、批量操作确认

五、各主流 AI 工具接入配置模板

核心原则：

所有工具入口文件不重复编写完整规则，仅声明读取 specs/ 下全部规范，降低维护成本，杜绝多版本规则分叉。

1. Cursor 配置：`.cursor/rules/global-spec-all.mdc`

---
description: 项目全局 AI Coding Spec 统一约束
globs: ["**/*.kt", "**/*.java", "**/*.xml", "**/*.ts", "**/*.go"]
alwaysApply: true
---

# 代码生成、重构、Bug 修复、评审前强制读取全部规范

@specs/01-base-code-style.md
@specs/02-concurrent-spec.md
@specs/03-architecture-limit.md
@specs/04-i18n-ui-spec.md
@specs/05-security-safe-spec.md
@specs/06-domain-rule.md

执行规则要求：

1. 所有 MUST 约束必须严格落地，MUST NOT 禁止出现违规代码。
2. 生成代码前检索项目已有实现，禁止自创不存在组件。
3. 评审阶段优先排查安全、并发、架构三类高危违规项。

验证技巧：

在 Cursor 中输入“生成一个金额计算函数”，观察生成结果是否规避 06-domain-rule.md 中“禁止使用 Double / Float 处理金额”的规则。

2. Claude Code 根目录入口：`CLAUDE.md`

# 项目全局 AI Coding Spec 总入口

本项目所有代码生成、重构、Bug 修复、代码评审操作，执行前必须完整读取仓库 specs 目录全部规范文件：

1. specs/01-base-code-style.md 通用基础编码规范
2. specs/02-concurrent-spec.md 协程 / 并发线程规范
3. specs/03-architecture-limit.md 项目分层架构约束
4. specs/04-i18n-ui-spec.md UI 与多语言适配规范
5. specs/05-security-safe-spec.md 通用安全红线规范
6. specs/06-domain-rule.md 业务领域专属规范

强制约束：

1. 文档内所有 MUST 规则必须遵守，MUST NOT 禁止生成对应代码。
2. 优先复用项目现有工具类、扩展、架构封装，不得凭空创建新组件。
3. 评审时优先校验并发泄漏、安全日志、架构分层三类高危风险。

验证技巧：

让 Claude Code 在读取项目已有工具类后生成业务代码，检查它是否复用现有 MoneyUtils / NumericFormat / Result 封装，而不是自创一套新工具。

3. GitHub Copilot：`.github/copilot-instructions.md`

内容可与 CLAUDE.md 主体保持一致。仓库内所有成员使用 GitHub Copilot 时，统一遵循项目级规则。

# GitHub Copilot 项目级编码规范入口

本项目所有代码补全、代码生成、重构建议、测试生成与代码解释，必须遵循仓库 specs 目录下的全部规范：

1. specs/01-base-code-style.md
2. specs/02-concurrent-spec.md
3. specs/03-architecture-limit.md
4. specs/04-i18n-ui-spec.md
5. specs/05-security-safe-spec.md
6. specs/06-domain-rule.md

强制要求：

1. 所有 MUST 规则必须遵守。
2. 所有 MUST NOT 规则禁止生成。
3. 优先复用项目已有架构、工具类、扩展函数、错误处理和依赖配置。
4. 不得臆造项目不存在的 API、基类、Manager、Repository、第三方依赖。

验证技巧：

在代码中尝试输入 GlobalScope.launch 或金额相关 Double 字段，观察 Copilot 是否倾向于提示项目规范中的替代写法。

4. Codex / Agent 类工具：`AGENTS.md`

# 项目 AI Agent 编码规范入口

你是本项目的 AI 辅助研发工程师。

执行代码生成、重构、Bug 修复、代码评审前，必须先读取并遵守：

1. specs/01-base-code-style.md
2. specs/02-concurrent-spec.md
3. specs/03-architecture-limit.md
4. specs/04-i18n-ui-spec.md
5. specs/05-security-safe-spec.md
6. specs/06-domain-rule.md

执行要求：

1. 先阅读相关代码和已有实现，再进行修改。
2. 优先复用项目已有架构、工具类、扩展函数、错误处理和依赖配置。
3. 不做无关重构，不顺手格式化无关文件。
4. 命中 MUST NOT 规则时，必须主动修复或在 Review 中标记为高危问题。
5. 输出结果必须包含修改摘要、影响范围、测试结果和残余风险。

验证技巧：

给 Codex 一个小型重构任务，检查它是否先阅读相关文件、复用现有实现，并在最终结果中说明修改摘要、影响范围和测试结果。

六、Spec 两大核心落地场景：代码生成 + 自动化评审

场景 1：业务代码生成（日常开发）

开发者使用 prompt-templates 标准化自然语言描述需求。

全局 Spec + 单次提示词双重约束，可以大幅降低 AI 脱离项目体系乱写代码的概率。

通用标准提示词模板：

你是资深项目开发工程师，生成代码严格遵循仓库 specs 全部规范。

需求描述：
{此处填写业务功能、入参、出参、执行场景}

强制额外约束：
{补充当前场景专属限制，如协程超时、禁止硬编码、统一返回体}

输出要求：
仅输出完整可运行代码，公开方法补充标准文档注释，单行长度不超过 120 字符。

场景 2：提交前自动化 AI 评审

复制 prompt-templates/ai-auto-review.md 内评审模板，粘贴至 AI 对话，一键扫描本次代码变更，分级拦截规范违规。

通用评审模板：

基于仓库 specs 全套规范评审本次代码变更，逐项输出风险清单，分级标注【高危 / 规范优化】：

1. 基础编码：命名、val / var、集合类型、!! 非空断言违规检查。
2. 并发安全：GlobalScope、裸协程、无超时、线程调度错误。
3. 架构分层：擅自新增组件、重复工具类、脱离项目分层。
4. 安全约束：敏感日志、硬编码常量、入参未校验。
5. UI / 多语言：布局硬编码、字符串写死、RTL 适配缺失。
6. 领域规则：业务专属红线校验。

高危项必须提供完整修复代码，规范优化项给出修改建议。

七、这套通用 Spec 方法论的核心价值

1. 统一多 AI 工具输出风格

团队混用 Cursor、Copilot、Claude、JetBrains AI 时，不再各写各的。

一套规则全局生效，可以显著降低 Code Review 工作量。

2. 规范可版本化、可团队协作迭代

Spec 文件纳入 Git。

新增业务约束、调整编码标准均可提交变更、组织评审，所有人同步最新规则，不存在个人提示词版本差异。

3. 提前拦截线上风险，降低长期维护成本

并发泄漏、安全日志、错误数据类型、架构混乱等问题，无需人工逐行排查。

AI 在生成阶段自动规避，从源头减少线上故障。

从团队落地经验看，规则稳定执行后，Code Review 中“架构混乱、并发泄漏、金额精度错误、敏感日志”等高危问题占比通常会明显下降。

如果团队有历史数据，可以进一步量化，例如：

高危 Review 问题占比下降 60% 以上
新人编码适配周期从 1-2 周缩短到 3-5 天
因 AI 生成违规代码引发的返工次数持续下降

这些数字不必一开始就追求精确，但建议团队在落地后逐步记录，用数据证明 Spec 的工程价值。

4. 降低新人上手成本

新人无需资深开发反复讲解项目规范。

AI 生成代码时自动对齐项目标准，可以帮助新人快速融入团队编码体系。

5. 适配全行业、全端项目

项目类型	配套补充 Spec 内容
Android / iOS 客户端	UI、多语言、页面生命周期、协程生命周期规范
Spring / Ktor / Go 后端	事务边界、线程池、接口统一返回体、数据库操作约束
Web / 前端	JS / TS 编码、组件规范、状态管理、接口请求封装
金融、电商、游戏等高风险项目	扩展 `06-domain-rule.md`，增加领域专属业务红线

6. 拓展 AI 能力边界：覆盖完整研发链路

传统临时 Prompt 主要支持单次代码生成。

工程化 Spec 可以支撑完整流程：

编码
重构
Bug 修复
提交前自动化自查
代码评审

这时 AI 不再只是简单代码生成器，而是标准化研发辅助工具。

八、轻量 MVP 落地步骤

首次接入时，不建议一上来就追求“全量规则 + 全工具适配”。

更稳的方式是先跑通最小闭环：

1. 先梳理 3-5 条项目最高危业务红线。
   例如金融项目“金额必须使用 BigDecimal”、Android 项目“禁止 GlobalScope”。

2. 将这些规则写入 06-domain-rule.md 和 02-concurrent-spec.md。

3. 先配置团队使用最多的 1 个核心工具。
   例如团队主要使用 Cursor，就先配置 .cursor/rules/global-spec-all.mdc。

4. 用一个真实小需求验证规则是否生效。
   跑通“生成代码 -> AI Review -> 人工 Review”闭环。

5. 规则稳定后，再逐步补充通用代码风格、架构约束、安全规范。

6. 最后扩展到 Claude Code、GitHub Copilot、Codex 等多工具适配。

这样做的好处是接入成本低，团队更容易接受，也能快速验证 Spec 是否真正有用。

九、完整落地执行流程

项目根目录引入完整 Spec 目录结构，根据项目类型删减 / 补充领域规则。
团队全体成员在编辑器配置对应 AI 工具，开启全局规则自动应用。
日常开发时，使用标准化自然语言提示词模板描述需求。
AI 自动读取仓库 Spec，生成符合项目架构、编码、安全规范的代码。
代码提交前，执行 AI 自动化评审，拦截高危违规代码。
Spec 随业务迭代持续更新，修改后提交 Git，团队统一 Review 同步。

十、落地常见误区避坑

误区 1：Spec 写得越长越完善

Spec 不是百科全书。

它应该优先覆盖高频问题、高风险业务红线，例如并发泄漏、安全日志、金额精度、事务边界、权限校验、架构分层。

文档过于冗长，反而会导致 AI 无法抓取核心约束，团队也难以长期维护迭代。

更推荐遵循“高频 + 高危优先”原则：

每个规则文件聚焦 3-5 个核心约束
02-concurrent-spec.md 只抓结构化并发、调度器分配、超时保护、异常处理
05-security-safe-spec.md 只抓敏感日志、密钥硬编码、入参校验、权限边界
06-domain-rule.md 只抓最容易造成业务事故的领域红线

误区 2：规则语言过于模糊

Spec 不适合写成普通自然语言建议。

例如：

尽量避免在线程里做耗时操作。

这种写法对人和 AI 都不够明确。

建议改成：

MUST：网络、文件、数据库操作必须切换至 IO 调度器或项目指定线程池。
理由：避免阻塞主线程或业务调度线程，导致卡顿、超时和线程饥饿。

每条 MUST / MUST NOT 规则建议配 1 行简短理由。

这样既方便 AI 理解规则意图，也方便新人知道规则背后的风险。

误区 3：为每个 AI 工具维护一份完整规则

这是最容易造成规则分叉、版本不一致的做法。

正确思路是：

specs/ 作为唯一规则源
各类工具入口文件仅做引用转发
不在多个入口文件里重复写完整约束

工具可以多样化，但规则只能有一套。

误区 4：只约束代码风格，忽略业务领域红线

缩进、命名、换行主要影响可读性。

真正引发线上事故的，往往是业务边界被破坏。

例如：

金融项目里的金额精度
后端项目里的事务边界
电商项目里的库存扣减
移动端项目里的协程泄漏
登录系统里的权限校验
敏感信息被打印到日志

AI Coding Spec 的核心目标是管控业务风险，而不是单纯美化代码格式。

误区 5：Spec 仅用于代码生成，不接入评审流程

只在写代码时启用 Spec，仅发挥一半价值。

完整落地应该覆盖：

生成
重构
修 Bug
提交评审
人工 Code Review

Spec 应该成为人工 Code Review 的统一判断标准。

十一、总结

单纯依赖对话内临时 Prompt，只能实现短期开发提效。

长期来看，它很容易带来代码风格分裂、技术债堆积、线上风险不可控等问题。

从临时 Prompt 升级为仓库托管、全 AI 工具共用、三级强约束的通用 AI Coding Spec，是目前非常值得采用的 AI 辅助开发工程化路径。

这套方法论没有明显行业和端侧限制，前端、后端、移动端、桌面端、开源组件均可落地。

一套规则统一 Cursor、Copilot、Claude、JetBrains AI 等主流工具，约束 AI 不再自由发挥，而是贴合项目工程边界，最终实现：

高效
统一
安全
可长期维护

我已将这套方法论落地到 Android 金融垂直场景，开源仓库可供参考实践：

https://github.com/brycegao/android-finance-spec

这个仓库包含金融数值、RTL 国际化、Kotlin 架构风格三类 Spec，可以作为垂直领域 AI Coding Spec 的参考实现。

通用 Spec 方法论解决“如何设计统一规范”，垂直领域开源仓库验证“规范如何落地真实业务项目”。二者结合，可以帮助团队快速搭建自己的 AI 编码规范体系。

AI 时代程序员必备技能

Codex、Claude Code、Cursor、Hermes Agent、OpenClaw等工程化实战专栏，讲透 AI 如何接管脏活累活

一键订阅

从 Prompt 到 Spec：一套通用 AI 编码规范工程化落地方法论

前言

一、为什么单次临时 Prompt 无法支撑长期团队开发

1. 生命周期极短，无记忆持久化

2. 多 AI 工具规则割裂，无法统一

3. 不可版本管理、不可迭代、不可评审

4. 只能约束代码生成，难以支撑重构与自动评审

核心结论

二、什么是通用 AI Coding Spec

三级约束语法

三层规则模型

三、通用标准化仓库目录结构

顶层架构设计思想

四、分文件 Spec 内容示例

示例 1：specs/01-base-code-style.md

示例 2：specs/02-concurrent-spec.md

示例 3：specs/03-architecture-limit.md

示例 4：specs/06-domain-rule.md

五、各主流 AI 工具接入配置模板

1. Cursor 配置：.cursor/rules/global-spec-all.mdc

2. Claude Code 根目录入口：CLAUDE.md

3. GitHub Copilot：.github/copilot-instructions.md

4. Codex / Agent 类工具：AGENTS.md

六、Spec 两大核心落地场景：代码生成 + 自动化评审

场景 1：业务代码生成（日常开发）

场景 2：提交前自动化 AI 评审

七、这套通用 Spec 方法论的核心价值

1. 统一多 AI 工具输出风格

2. 规范可版本化、可团队协作迭代

3. 提前拦截线上风险，降低长期维护成本

4. 降低新人上手成本

5. 适配全行业、全端项目

6. 拓展 AI 能力边界：覆盖完整研发链路

八、轻量 MVP 落地步骤

九、完整落地执行流程

十、落地常见误区避坑

误区 1：Spec 写得越长越完善

误区 2：规则语言过于模糊

误区 3：为每个 AI 工具维护一份完整规则

误区 4：只约束代码风格，忽略业务领域红线

误区 5：Spec 仅用于代码生成，不接入评审流程

十一、总结

示例 1：`specs/01-base-code-style.md`

示例 2：`specs/02-concurrent-spec.md`

示例 3：`specs/03-architecture-limit.md`

示例 4：`specs/06-domain-rule.md`

1. Cursor 配置：`.cursor/rules/global-spec-all.mdc`

2. Claude Code 根目录入口：`CLAUDE.md`

3. GitHub Copilot：`.github/copilot-instructions.md`

4. Codex / Agent 类工具：`AGENTS.md`