从 Prompt 到工程体系：如何真正把 AI 用进软件开发

长亭外的少年

280人浏览 · 2026-05-10 23:50:23

长亭外的少年 · 2026-05-10 23:50:23 发布

从 Prompt 到工程体系：如何真正把 AI 用进软件开发

很多开发者刚开始接触 Codex、Claude Code、Cursor、Cline 时，都会经历一个阶段：

一开始觉得 AI 很神奇
后来发现 AI 经常“自由发挥”
再后来发现：真正重要的不是 Prompt，而是工程体系

真正长期可用的 AI 编程，不是“问一句生成一段代码”。

而是：如何让 AI 在多个项目、多人协作、长期维护的环境下稳定工作。

这篇文章不讲花哨 Prompt，也不讲“5分钟生成 App”。

而是从真实工程角度，系统讲清楚：

AGENTS.md 到底是什么
Skill 应该怎么设计
scripts 为什么重要
Skill 粒度怎么拆
公共 Skill 和私有 Skill 的区别
Android / Java 项目如何真正落地
如何逐步沉淀自己的 AI 工程体系

适合：

Android
Java / Spring Boot
SDK 开发
Web 项目
多仓库协作
长期维护型项目

一、真正的问题不是“AI会不会写代码”

现在的大模型：

写页面
写接口
写 SQL
写测试
修简单 Bug

其实已经非常强。

真正困难的地方已经不是：

“让 AI 写代码”

而是：如何让 AI 按照你的项目方式持续工作。

例如：

同样是 Android 项目：

有的项目：

Kotlin + Compose
Clean Architecture
MVI

有的项目：

Java + XML
MVP
大量历史代码

再比如 Java 后端：

有的项目：

Spring Boot 3
JPA
Java 21

有的项目：

Spring MVC
MyBatis XML
大量历史 SQL

AI 并不知道：

你的团队规范
你的架构约束
哪些模块不能动
哪些流程必须执行
哪些问题必须最小修改

于是：AI 工程化真正解决的是“约束”和“流程”。

二、Agent、AGENTS.md、Skill 到底是什么

很多人第一次接触会混淆。

其实可以简单理解为：

名称	本质
Agent	会主动工作的 AI 工程师
AGENTS.md	项目级开发规范
Skill	某类工作的标准流程
scripts	自动执行能力

三、Agent：AI 不再只是聊天

传统 ChatGPT：

你问一句，它答一句。

而 Agent会主动：

读取项目
分析文件
修改代码
执行命令
运行测试
验证结果

例如：

修复 Spring Boot 登录接口偶发 500

Agent 可能会：

读取 Controller
分析 Service
查看日志
跑测试
修改代码
自动 build
输出修复说明

所以：Agent 更像一个新人程序员。

但问题是：新人需要规范。

于是：GENTS.md 和 Skill 开始变得重要。

四、AGENTS.md：项目级规则

AGENTS.md 本质是：“这个项目应该怎么开发”

它通常放在项目根目录：

project/
├── AGENTS.md
├── app/
├── server/
└── ...

它更像：团队开发规范。

例如 Android 项目：

# Android Project Rules

- 使用 Kotlin + Compose
- 使用 MVVM
- ViewModel 禁止持有 Context
- Repository 不允许返回 Retrofit 原始 Bean
- 所有字符串必须进入 strings.xml
- 不允许在 Composable 中直接发起网络请求
- 禁止直接修改 legacy 模块

再例如 Spring Boot 项目：

# Backend Rules

- 使用 Java 17
- Controller 统一返回 Result<T>
- 所有 SQL 使用 MyBatis XML
- Service 不允许直接操作 Mapper
- 禁止在 Controller 写业务逻辑
- 修改接口必须补充 Swagger 注释

AGENTS.md 有一个核心特点：它是全局永久生效的。

无论：

修 Bug
写页面
发版
重构

都必须遵守。

五、Skill：某类工作的标准工作流

如果说AGENTS.md 是项目规则

那么Skill 更像： “专项工作手册”

例如：

skills/
├── bug-fix/
├── compose-screen/
├── release/
├── performance-optimize/
└── sdk-development/

每个 Skill：负责一类完整工作。

例如：

修 Bug
页面开发
发版
SDK 开发
性能优化

六、Skill 不要拆得太细

很多人刚开始会这样拆：

skills/
├── retrofit-skill
├── button-skill
├── recycler-skill

这种设计基本没有意义。

因为：AI 本来就会这些基础技术。

Skill 最好的粒度：

不是：

一个 API

而是：一类完整工作流。

例如：

skills/
├── bug-fix/
├── release/
├── compose-screen/
├── architecture-review/
├── sdk-development/
└── performance-optimize/

这才是合理的粒度。

七、一个完整 Skill 到底长什么样

以 Android Bug 修复 Skill 为例：

bug-fix-skill/
├── SKILL.md
├── examples/
├── scripts/
├── templates/
└── docs/

1. SKILL.md

这是核心。

相当于：AI 的工作说明书。

例如：

# Android Bug Fix Skill

## 修复原则

1. 优先 Root Cause 分析
2. 做最小修改
3. 避免顺手重构
4. 修复后必须运行测试

## 禁止行为

- 禁止为了修复小问题重构整个模块
- 禁止修改无关代码格式
- 禁止升级依赖版本

## Compose 检查

- 是否发生重复重组
- 是否 State 不稳定
- 是否存在生命周期问题

## Coroutine 检查

- 是否使用 viewModelScope
- 是否存在未取消协程
- 是否错误使用 Dispatcher

真正好的 Skill：不会写得很空。

例如：

差的规则：

代码要规范。

这种没有任何意义。

好的规则：

禁止在 Composable 中直接 collect 多个 Flow。
复杂页面统一在 ViewModel 聚合状态。

这才是真实工程经验。

2. examples/

很多人会忽略 examples。

但实际上：examples 往往比规则更重要。

因为 AI 非常擅长：模仿已有风格。

例如：

examples/
├── GoodViewModel.kt
├── GoodController.java
└── GoodComposeScreen.kt

例如一个好的 Spring Boot Controller：

@RestController
@RequestMapping("/user")
public class UserController {

    @GetMapping("/detail")
    public Result<UserVO> detail(Long id) {
        return Result.success(userService.detail(id));
    }
}

AI 会自动学习：

返回结构
命名风格
项目习惯

所以：示例往往比 Prompt 更稳定。

3. scripts/

这是很多人最容易忽略，
但其实非常关键的一部分。

scripts 本质：“AI 的自动执行能力”

例如：

scripts/
├── verify.sh
├── run-tests.sh
└── release.sh

例如：

#!/bin/bash

./gradlew ktlintCheck
./gradlew testDebugUnitTest
./gradlew assembleDebug

或者 Java：

#!/bin/bash

mvn test
mvn package

scripts 为什么重要？

因为：AI 会“自作聪明”。

如果你不定义验证流程：

AI 可能：

跳过测试
直接 build release
跑错误命令
修改大量无关代码

scripts 的本质：是把 AI 固定在你的工作流里。

这和 CI/CD 非常像。

以前：

是 Jenkins、GitHub Actions 在执行脚本。

现在：

是 Agent 在执行脚本。

本质没有变。

八、公共 Skill 和私有 Skill

这是未来 AI 工程体系里最重要的区别之一。

公共 Skill

任何团队都能使用。

例如：

compose-ui-skill
spring-api-skill
bug-fix-skill
release-skill

它们解决的是：通用技术问题。

例如：

Compose 页面规范
Spring Boot API 规范
Bug 修复流程
发版流程

这些几乎所有项目都能复用。

私有 Skill

只有你们公司、你们项目才有意义。

例如：

order-center-skill
payment-risk-skill
video-preload-skill
recommend-engine-skill

例如一个电商订单 Skill：

订单状态流转：

待支付
→ 已支付
→ 已发货
→ 已完成

退款时：
必须同步：
- 库存
- 优惠券
- 积分

例如视频业务：

首页视频：

- WiFi 预加载3个
- 4G 只预加载封面
- 滑动超过50%开始缓存

这些：才是真正的业务资产。

九、为什么 scripts、Skill、AGENTS.md 会越来越重要

因为：
AI 最大的问题不是“不会写”

而是：“不稳定”。

例如：

今天：

修复首页 Crash

AI：

最小修改
测试通过

明天：

同一句话：

AI：

重构整个模块
升级依赖
修改大量无关代码

于是：真正成熟的 AI 工程化，最终一定会变成：

固化规则
固化流程
固化验证

也就是：

AGENTS.md
skills/
scripts/
workflow/

十、真正重要的不是 Prompt，而是工程经验

很多人刚开始会疯狂研究：

怎么写 Prompt

但真正长期使用后会发现：Prompt 只是入口。

真正重要的是：工程经验。

例如：

为什么：

ViewModel 禁止持有 Context

因为：

会导致内存泄漏。

为什么：

修 Bug 必须最小修改

因为：

大规模重构会增加未知风险。

为什么：

Repository 不直接返回 Entity

因为：后期业务变更会导致耦合失控。

这些：都不是 AI 凭空知道的。

而是：大量真实项目踩坑后的沉淀。

十一、未来真正值钱的能力

未来：通用代码能力会越来越便宜。

因为 AI 会越来越强。

但真正值钱的：是你如何组织 AI 长期稳定工作。

例如：

如何拆 Skill
如何定义规则
如何设计 scripts
如何设计验证流程
如何沉淀团队经验
如何组织多个 Agent 协同

这些：才是未来高级工程能力。

十二、建议的落地方式

不要一开始就做几十个 Skill。

真正正确的方式是：在真实项目中不断沉淀。

例如：

今天 AI：

为了修一个空指针重构整个模块

那么：

就在 Skill 里增加：

禁止为了修复小问题大范围重构。

今天 AI：

在 Compose 页面里直接发请求

那么：

增加：

禁止在 Composable 中直接发起网络请求。

慢慢：

你的 Skill、规则、脚本、工作流会越来越成熟。

最终形成：你自己的 AI 工程体系。

十三、一个推荐的项目结构

例如：

workspace/
├── ecommerce-app/
│   ├── AGENTS.md
│   ├── skills/
│   ├── scripts/
│   ├── docs/
│   └── app/
│
├── backend-service/
│   ├── AGENTS.md
│   ├── skills/
│   ├── scripts/
│   └── src/
│
└── shared-skills/
    ├── bug-fix/
    ├── release/
    ├── compose-screen/
    └── spring-api/

其中：