AI 工程实战一套可复用的提示词库与质量门禁如何让 AI 辅助研发「可验证、可沉淀」摘要本文从AI 工程的认知边界出发拆解 AI 幻觉的成因提出一套 通用的 AI 辅助研发方法论用「标准提示词库 文档模板库 语言适配层 质量清单」六道约束把 AI 从聊天工具变成可验收的研发环节。同时给出贯穿 12 个阶段的角色分工、瀑布/敏捷双流程调度以及一套可落地的 AI 输出验证标准。目录一、我对 AI 工程的认识二、AI 幻觉从哪来我如何规避三、全链路 AI 辅助研发工作流四、提示词模板的沉淀与设计五、如何验证 AI 的输出六、阶段 × 角色 × 任务的拆解分析七、总结与展望一、我对 AI 工程的认识1.1 先厘清三个概念模型 / Harness / AI 工程很多人把用 AI 干活笼统地叫提示词工程其实这个认知会把自己的工作价值读窄。我理解的技术栈分四层层是什么谁负责举例模型层LLM 本体厂商GPT / DeepSeek / ClaudeHarness 层Agent 运行时工具调用、子代理派发、工作流编排、沙箱平台/框架作者LangGraph、Cursor Agent、各类 HarnessAI 工程层给 Agent 装配大脑角色规范、提示词、模板、知识库、流程、质量门禁开发者我本文的方法论资产包└ 提示词工程上面这一层中的一个子集设计 prompt我prompts/结论我做的不是 Harness 工程也不只是提示词工程而是 Agent 工程 / 上下文工程Context Engineering。Harness 是引擎提示词是汽油我做的是整车的驾驶规范与标准流程——决定 AI 在什么场景、以什么角色、按什么结构、交付什么标准、如何自检。1.2 T 型人才AI 负责深度人负责广度AI 打破了知识的壁垒但没有打破决策责任和场景上下文的壁垒。我的核心判断是AI 擅长深度给定明确的边界和上下文它能比人更快、更细地生成代码、文档、用例。人必须负责广度用什么项目管理方法、为什么这时候用、有什么取舍用什么存储、什么时候上云、成本与风险如何权衡不同公司有不同的权限体系某个按钮为什么不能对某个角色显示……这些是 AI 拿不到的、也是它不该替人拍板的东西。这些场景上下文 决策责任必须由懂业务的人先对需求进行拆解再喂给 AI。所以我的定位很明确AI 是辅助我是第一责任人输出必须过我的审查。二、AI 幻觉从哪来我如何规避2.1 幻觉的本质AI 幻觉Hallucination不是 bug而是概率生成 缺约束的必然产物。具体三个来源上下文不足AI 不知道你的项目背景、权限体系、历史决策只能脑补。约束不足prompt 太随意AI 不知道该按什么结构、什么边界、什么风格输出。缺乏验证闭环生成了就交付没有人或机制去校验错误自然沉淀下来。2.2 我的规避方法论六道约束对抗幻觉的本质是给 AI 加约束、加边界、加验证。我沉淀了六道约束#约束作用落点1模板约束结构对齐产出物套固定章节骨架禁止自由发挥templates/2角色约束身份对齐固化 system 角色 职责边界 禁止行为每个 prompt 的「角色定义」3少样本约束风格对齐给示例片段让 AI 对齐颗粒度与写法每个 prompt 的「少样本示例」4质量清单交付门禁生成后逐项自检不达标重写每个 prompt 的「质量清单」5契约传递可追溯上一阶段产出 下一阶段输入方法论的工作流定义6事实源单一规则不冲突通用规范只定义一次语言规范只定义一次方法论 适配层其中「质量清单」是把隐性质量要求显式化为可勾选项这是保证输出质量最直接的方法也就是让AI自行根据标准检查一遍自己的输出内容。三、全链路 AI 辅助研发工作流我把研发链路拆成12 个阶段分成需求侧、设计侧、开发侧三大块开发侧设计侧需求侧用户原始需求① 用户路线图② 用户画像③ BRD 商业需求④ PRD 产品需求⑤ 功能开发说明书⑥ 产品开发说明书⑦ HLD 概要设计⑧ 接口规范⑨ 数据流图 ER图⑩ 代码生成⑪ 代码审查⑫ 测试用例3.1 每个阶段的输入 / 输出 / 角色#阶段输入输出负责角色①用户路线图原始需求商业目标 → 功能落地路径业务分析师②用户画像需求 路线图目标用户 / 痛点 / 场景业务分析师③BRD路线图 画像为什么做、值不值得做业务分析师④PRDBRD做什么产品需求产品经理⑤功能开发说明书PRD 拆出的功能点单功能需求→交互→接口→验收产品经理⑥产品开发说明书PRD 架构决策产品级开发总纲产品经理/架构师⑦HLDPRD 开发说明书概要设计分层/模块/选型架构师⑧接口规范HLDAPI 契约路径/入参/出参/错误码架构师⑨数据流图 ER图HLD 接口规范数据建模Mermaid架构师⑩代码生成设计文档 表结构 目标语言目标语言代码开发工程师⑪代码审查代码 接口规范审查报告审查工程师⑫测试用例说明书 接口规范 代码正常/异常/边界用例测试工程师3.2 多种管理方法瀑布 / 敏捷双模式关键设计理念资产包是可复用积木瀑布 / 敏捷只是调度节奏不同。提示词、模板、角色、质量清单完全复用区别只在于什么时候执行哪些阶段。瀑布模式需求明确、范围稳定按 ①→⑫ 全量依次执行一次跑完整个链路。敏捷模式需求持续变化、增量交付立项跑一次① 路线图 → ② 画像 → ③ BRD → ④ PRD 总纲 → ⑥ 产品开发说明书 → ⑦ HLD 总体架构每个 Sprint 循环从 Backlog 取用户故事 → ⑤ 功能开发说明书 → ⑦ 局部 HLD → ⑧ 接口规范 → ⑨ 增量更新数据流/ER → ⑩ 代码生成 → ⑪ 代码审查 → ⑫ 测试用例 → 评审 → 下一 Sprint这种流程与资产解耦的设计让同一套方法论既能驾驭瀑布也能驾驭敏捷这是它区别于一次性 prompt 的地方。四、提示词模板的沉淀与设计4.1 从随手写 prompt到沉淀模板的三步发现问题每次让 AI 写文档格式漂移、质量忽高忽低、无法复用。抽象共性任何一次高质量产出都离不开角色 任务 结构 示例 检查这几样东西。固化为模板把共性抽成固定结构每类产出物对应一个 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 个四层的分工层回答的问题语言/管理方法相关方法论整体怎么流转、怎么保证质量无关提示词库AI 怎么生成无关代码项引用适配层模板库产出物长什么样无关语言适配层命名/分层/代码骨架相关4.3 单个 prompt 的「六段式」结构每个提示词文件固定六段这是我的模板设计核心# {阶段} 提示词 ## 角色定义 ← 你是谁、职责、禁止角色约束 ## 输入要求 ← 需要喂什么、缺信息就提问防止脑补 ## 任务 ← 具体生成指令指向目标 ## 输出模板 ← 引用 templates/ 的骨架模板约束 ## 少样本示例 ← 对齐风格少样本约束 ## 质量清单 ← 生成后逐项自检交付门禁六段式对应六道约束里的前四道再配合契约传递 事实源单一就构成了完整的质量体系。4.4 语言无关的关键设计适配层早期版本我把 Java 命名规范直接写进方法论导致换语言就得改核心。后来我把语言相关的三样东西——命名规范、分层目录、代码骨架——从核心剥离下沉到adapters/{语言}.mdJava方法camelCase分层controller/service/mapperC#方法PascalCase接口前缀I分层Controllers/Services/RepositoriesPythonsnake_case分层routers/services/repositories换语言只换一个适配文件核心方法论、全部模板和提示词都不动。这是语言无关、可扩展的落地方式也是最有工程感的点。五、如何验证 AI 的输出这是最容易被追问、也最能体现方法论深度的问题。我的答案是三层验证法态度层 硬手段层 兜底学习层。5.1 第一层人机协同Human in the loopAI 是辅助我是第一责任人输出必须过我的审查绝不直接拿来用。这是安全底线。5.2 第二层硬手段按产出物分标准代码类先看能不能编译、能不能运行、单测过不过再过静态检查Lint / SonarQube 等然后人工审查四件事——安全性SQL 注入、敏感信息泄露性能循环查库、N1规范命名、分层是否符合适配层正确性入参出参是否对齐接口契约、边界条件是否覆盖文档类核心看验收标准是否可量化、可验证。例如❌ 错误优化首页按钮布局✅ 正确将首页 6 个按钮合并为一行水平排列间距 8px超出宽度自动换行再看是否与上游需求对齐、可追溯PRD 是否对应 BRD接口是否对应 HLD。通用类质量清单门禁我给每类产出物定了一个可勾选的质量清单AI 生成后先逐项自检我再按清单验收。以代码生成为例## 质量清单生成后逐项自检 - [ ] 命名、分层符合 adapters/{目标语言}.md - [ ] 控制层不含业务逻辑、业务层承担事务、数据层只做数据访问 - [ ] 接口路径/入参/出参与接口规范完全一致 - [ ] 统一返回体 {code, message, data} - [ ] 入参有校验非空/格式 - [ ] 实体含通用字段 id/create_time/update_time - [ ] 未引入未确认的第三方依赖交叉验证存疑的地方让 AI 给出依据、去查官方文档重要代码我会开第二个会话/换模型做复核。5.3 第三层兜底 学习开发中不可避免会碰到没碰过的技术。这时判断的前提是先建立判断基准至少让 AI逐行讲清楚它为什么这么写、考虑了哪些边界、我的顾虑它怎么处理相当于把每条内容完整过一遍也当自己学一遍这次慢但下次生成同类内容时就回到第一层的审查了。这三点是递进的自己懂的走审查不懂的先建立基准再审查。长期目标是——AI 负责深度我负责广度。六、阶段 × 角色 × 任务的拆解分析把 12 个阶段按角色职责和任务类型再拆一层能更清楚地看到人机分工的边界角色负责阶段核心任务AI 能做人必须把关业务分析师①②③路线图、画像、BRD结构化拆解、生成文档商业目标、用户价值、可行性结论产品经理④⑤⑥PRD、功能/产品开发说明书模块拆分、规则细化需求边界、验收标准、优先级架构师⑦⑧⑨HLD、接口规范、数据流图/ER分层设计、图生成、契约定义技术选型、取舍、风险决策开发工程师⑩代码生成按规范生成代码代码正确性、是否脑补需求审查工程师⑪代码审查发现问题、定位问题分级、是否放行测试工程师⑫测试用例生成用例、覆盖核对场景完整性、验收对应按任务类型的三类拆解任务类型阶段AI 的价值人的价值验证重点决策类为什么做①③⑥提供分析框架、罗列维度拍板、担责结论是否明确、是否有理由定义类做什么②④⑤⑧结构化、补细节定边界、定验收验收标准是否可量化执行类怎么做⑦⑨⑩⑪⑫高速产出、查错审查、放行是否对齐契约、是否安全合规这个拆解的洞察是越靠决策人的权重越高越靠执行AI 的权重越高。所以方法论的正确姿势不是AI 全包而是人定标准与边界AI 做高速执行人做质量验收。七、总结与展望这套方法论解决的核心问题是让 AI 的产出从一次性、不可控变成可复用、可追溯、可验收。认知上区分了 AI 工程 / Harness / 提示词工程定位自己是做 AI 工程。方法上用六道约束模板/角色/少样本/质量清单/契约传递/事实源单一对抗幻觉。工程上用四层资产包方法论 提示词库 模板库 语言适配层实现语言无关、流程无关。验证上用三层验证法态度 硬手段 兜底学习守住输出质量。未来展望把这套资产包进一步产品化成可交互的 Web 工具让不懂 AI 的同事也能复用引入更重的多 Agent 编排子代理派发、审核门禁自动化把人验逐步变成机验 人抽查沉淀更多语言适配层前端 Vue/React、Go 等扩大通用性。AI 不会淘汰工程师但它会淘汰只会用 AI 输出、不会验证 AI 输出的工程师。判断力才是人永远不可替代的部分。