AI 工程实战：一套可复用的提示词库与质量门禁，如何让 AI 辅助研发「可验证、可沉淀」

摘要：本文从"AI 工程"的认知边界出发，拆解 AI 幻觉的成因，提出一套 通用的 AI 辅助研发方法论：用「标准提示词库 + 文档模板库 + 语言适配层 + 质量清单」六道约束，把 AI 从"聊天工具"变成"可验收的研发环节"。同时给出贯穿 12 个阶段的角色分工、瀑布/敏捷双流程调度，以及一套可落地的 AI 输出验证标准。

目录

• 一、我对 AI 工程的认识
• 二、AI 幻觉从哪来，我如何规避
• 三、全链路 AI 辅助研发工作流
• 四、提示词模板的沉淀与设计
• 五、如何验证 AI 的输出
• 六、阶段 × 角色 × 任务的拆解分析
• 七、总结与展望

一、我对 AI 工程的认识

1.1 先厘清三个概念：模型 / Harness / AI 工程

很多人把"用 AI 干活"笼统地叫"提示词工程"，其实这个认知会把自己的工作价值读窄。我理解的技术栈分四层：

结论：我做的不是 Harness 工程，也不只是提示词工程，而是 Agent 工程 / 上下文工程（Context Engineering）。

Harness 是"引擎"，提示词是"汽油"，我做的是"整车的驾驶规范与标准流程"——决定 AI 在什么场景、以什么角色、按什么结构、交付什么标准、如何自检。

1.2 T 型人才：AI 负责深度，人负责广度

AI 打破了知识的壁垒，但没有打破"决策责任"和"场景上下文"的壁垒。我的核心判断是：

• AI 擅长深度：给定明确的边界和上下文，它能比人更快、更细地生成代码、文档、用例。
• 人必须负责广度：用什么项目管理方法、为什么这时候用、有什么取舍；用什么存储、什么时候上云、成本与风险如何权衡；不同公司有不同的权限体系，某个按钮为什么不能对某个角色显示……这些是 AI 拿不到的、也是它不该替人拍板的东西。

这些"场景上下文 + 决策责任"，必须由懂业务的人先对需求进行拆解，再喂给 AI。所以我的定位很明确：AI 是辅助，我是第一责任人，输出必须过我的审查。

二、AI 幻觉从哪来，我如何规避

2.1 幻觉的本质

AI 幻觉（Hallucination）不是 bug，而是概率生成 + 缺约束的必然产物。具体三个来源：

1. 上下文不足：AI 不知道你的项目背景、权限体系、历史决策，只能"脑补"。
2. 约束不足：prompt 太随意，AI 不知道该按什么结构、什么边界、什么风格输出。
3. 缺乏验证闭环：生成了就交付，没有人或机制去校验，错误自然沉淀下来。

2.2 我的规避方法论：六道约束

对抗幻觉的本质是给 AI 加约束、加边界、加验证。我沉淀了六道约束：

其中「质量清单」是把隐性质量要求显式化为可勾选项，这是"保证输出质量"最直接的方法，也就是让AI自行根据标准检查一遍自己的输出内容。

三、全链路 AI 辅助研发工作流

我把研发链路拆成12 个阶段，分成需求侧、设计侧、开发侧三大块：

3.1 每个阶段的输入 / 输出 / 角色

3.2 多种管理方法：瀑布 / 敏捷双模式

关键设计理念：资产包是"可复用积木"，瀑布 / 敏捷只是"调度节奏不同"。提示词、模板、角色、质量清单完全复用，区别只在于什么时候执行哪些阶段。

瀑布模式（需求明确、范围稳定）：按 ①→⑫ 全量依次执行，一次跑完整个链路。

敏捷模式（需求持续变化、增量交付）：

• 立项跑一次：① 路线图 → ② 画像 → ③ BRD → ④ PRD 总纲 → ⑥ 产品开发说明书 → ⑦ HLD 总体架构
• 每个 Sprint 循环：从 Backlog 取用户故事 → ⑤ 功能开发说明书 → ⑦ 局部 HLD → ⑧ 接口规范 → ⑨ 增量更新数据流/ER → ⑩ 代码生成 → ⑪ 代码审查 → ⑫ 测试用例 → 评审 → 下一 Sprint

这种"流程与资产解耦"的设计，让同一套方法论既能驾驭瀑布也能驾驭敏捷，这是它区别于一次性 prompt 的地方。

四、提示词模板的沉淀与设计

4.1 从"随手写 prompt"到"沉淀模板"的三步

1. 发现问题：每次让 AI 写文档，格式漂移、质量忽高忽低、无法复用。
2. 抽象共性：任何一次高质量产出，都离不开"角色 + 任务 + 结构 + 示例 + 检查"这几样东西。
3. 固化为模板：把共性抽成固定结构，每类产出物对应一个 prompt 文件，从此只填空、不重写。

4.2 资产包的四层结构

ai-dev-workflow/ ├── 方法论.md # 语言无关、流程无关的"宪法" ├── adapters/ # 语言适配层（换语言只换这里） │ ├── java.md │ ├── csharp.md │ └── python.md ├── templates/ # 文档模板库（产出物骨架，语言无关） │ ├── BRD模板.md │ ├── PRD模板.md │ ├── HLD模板.md │ ├── 接口规范模板.md │ └── ...（共 12 个） └── prompts/ # 提示词库（每阶段固定 prompt） ├── BRD.md ├── PRD.md ├── 代码生成.md ├── 代码审查.md └── ...（共 12 个）

四层的分工：

4.3 单个 prompt 的「六段式」结构

每个提示词文件固定六段，这是我的模板设计核心：

# {阶段} 提示词 ## 角色定义 ← 你是谁、职责、禁止（角色约束） ## 输入要求 ← 需要喂什么、缺信息就提问（防止脑补） ## 任务 ← 具体生成指令（指向目标） ## 输出模板 ← 引用 templates/ 的骨架（模板约束） ## 少样本示例 ← 对齐风格（少样本约束） ## 质量清单 ← 生成后逐项自检（交付门禁）

六段式对应六道约束里的前四道，再配合"契约传递 + 事实源单一"，就构成了完整的质量体系。

4.4 语言无关的关键设计：适配层

早期版本我把 Java 命名规范直接写进方法论，导致换语言就得改核心。后来我把语言相关的三样东西——命名规范、分层目录、代码骨架——从核心剥离，下沉到adapters/{语言}.md：

• Java：方法camelCase，分层controller/service/mapper
• C#：方法PascalCase，接口前缀I，分层Controllers/Services/Repositories
• Python：snake_case，分层routers/services/repositories

换语言只换一个适配文件，核心方法论、全部模板和提示词都不动。这是"语言无关、可扩展"的落地方式，也是最有工程感的点。

五、如何验证 AI 的输出

这是最容易被追问、也最能体现方法论深度的问题。我的答案是三层验证法：态度层 + 硬手段层 + 兜底学习层。

5.1 第一层：人机协同（Human in the loop）

AI 是辅助，我是第一责任人，输出必须过我的审查，绝不直接拿来用。这是安全底线。

5.2 第二层：硬手段（按产出物分标准）

代码类：

1. 先看能不能编译、能不能运行、单测过不过；
2. 再过静态检查（Lint / SonarQube 等）；
3. 然后人工审查四件事——
   • 安全性（SQL 注入、敏感信息泄露）
   • 性能（循环查库、N+1）
   • 规范（命名、分层是否符合适配层）
   • 正确性（入参出参是否对齐接口契约、边界条件是否覆盖）

文档类：

• 核心看验收标准是否可量化、可验证。例如：
  • ❌ 错误：优化首页按钮布局
  • ✅ 正确：将首页 6 个按钮合并为一行水平排列，间距 8px，超出宽度自动换行
• 再看是否与上游需求对齐、可追溯（PRD 是否对应 BRD，接口是否对应 HLD）。

通用类（质量清单门禁）：
我给每类产出物定了一个可勾选的质量清单，AI 生成后先逐项自检，我再按清单验收。以代码生成为例：

## 质量清单（生成后逐项自检） - [ ] 命名、分层符合 adapters/{目标语言}.md - [ ] 控制层不含业务逻辑、业务层承担事务、数据层只做数据访问 - [ ] 接口路径/入参/出参与接口规范完全一致 - [ ] 统一返回体 {code, message, data} - [ ] 入参有校验（非空/格式） - [ ] 实体含通用字段 id/create_time/update_time - [ ] 未引入未确认的第三方依赖

交叉验证：存疑的地方，让 AI 给出依据、去查官方文档；重要代码我会开第二个会话/换模型做复核。

5.3 第三层：兜底 + 学习

开发中不可避免会碰到没碰过的技术。这时判断的前提是先建立判断基准：

• 至少让 AI逐行讲清楚它为什么这么写、考虑了哪些边界、我的顾虑它怎么处理；
• 相当于把每条内容完整过一遍，也当自己学一遍；
• 这次慢，但下次生成同类内容时，就回到第一层的"审查"了。

这三点是递进的：自己懂的走审查，不懂的先建立基准再审查。长期目标是——AI 负责深度，我负责广度。

六、阶段 × 角色 × 任务的拆解分析

把 12 个阶段按"角色职责"和"任务类型"再拆一层，能更清楚地看到"人机分工"的边界：

按"任务类型"的三类拆解

这个拆解的洞察是：越靠"决策"，人的权重越高；越靠"执行"，AI 的权重越高。所以方法论的正确姿势不是"AI 全包"，而是"人定标准与边界，AI 做高速执行，人做质量验收"。

七、总结与展望

这套方法论解决的核心问题是：让 AI 的产出从"一次性、不可控"变成"可复用、可追溯、可验收"。

• 认知上：区分了 AI 工程 / Harness / 提示词工程，定位自己是"做 AI 工程"。
• 方法上：用六道约束（模板/角色/少样本/质量清单/契约传递/事实源单一）对抗幻觉。
• 工程上：用四层资产包（方法论 + 提示词库 + 模板库 + 语言适配层）实现语言无关、流程无关。
• 验证上：用三层验证法（态度 + 硬手段 + 兜底学习）守住输出质量。

未来展望：

1. 把这套资产包进一步"产品化"成可交互的 Web 工具，让不懂 AI 的同事也能复用；
2. 引入更重的多 Agent 编排（子代理派发、审核门禁自动化），把"人验"逐步变成"机验 + 人抽查"；
3. 沉淀更多语言适配层（前端 Vue/React、Go 等），扩大通用性。

AI 不会淘汰工程师，但它会淘汰"只会用 AI 输出、不会验证 AI 输出"的工程师。判断力，才是人永远不可替代的部分。