《别再“喂prompt赌运气”了我的AI开发工程化管理实践》分享一套我用了一年多的 AI 工程化实践。不是工具说明书而是一套让 AI 开发可预期、可交接、可回滚的管理方法。目录一、为什么 AI 写代码这么容易失控二、第一步别让 AI 写代码先让它“冻结上下文”1. 录音 → 纪要 → 结构化摘要2. 让 DeepSeek 出初版架构方案3. ChatGPT 审查DeepSeek 复核我做取舍4. 反向生成提示词先“立骨架”三、把 AI 开发切成可以独立验收的“施工单元”1. 阶段拆分不追求一次全对只追求每一步可验收2. 施工单元AI 的唯一任务就是“完成当前这一步”3. 执行记录AI 也必须有“施工日志”4. manifest.yaml给下一个 AI或者下一个人类看的进度快照四、你可以直接抄走的最小施工单元模板AI 开发最小施工单元一个真实示例五、这套方法也不是银弹它适合谁不适合谁它不适合的场景它真正发挥价值的场景六、工程化不是“酷”是保命一、为什么 AI 写代码这么容易失控如果你在生产环境里用过 AI 辅助开发一定经历过这种痛苦白天跑得好好的 Demo晚上加一个需求第二天整个项目红了一片。AI 能帮你从 0 写到 80%但剩下 20% 的边界问题、模块冲突、隐性假设能让你填坑填到怀疑人生。这还不是最可怕的。最可怕的是团队协作同一个需求丢给不同的模型出来的结构天差地别上一次能跑通的提示词下次换一个上下文就崩了三个月后新同事接手连你当时是怎么让 AI 生成这段代码的都看不懂项目里有大量“上次 AI 写的现在没人敢动”的黑盒模块。一年前我开始有意识地把 AI 开发从“赌 prompt”拉回到工程轨道上慢慢形成了一套可复制的工作方式。核心思路只有一句话用 AI 驱动开发用工程化思维治理 AI用工程化管理落地项目。工程化管理的核心就是去人化——按流程做事而不是依靠某个人的记忆和直觉。下面的内容是我这一年反复试错、迭代后剩下的最靠谱的东西。二、第一步别让 AI 写代码先让它“冻结上下文”大部分 AI 开发失控的根源不是模型不够强而是需求上下文没锁死。人脑补了但没写进提示词的细节AI 只能猜猜错了人又懒得对齐最后项目越跑越偏。我现在接手任何一个需求固定走下面这四步在真正写代码之前先把上下文彻底冻结。1. 录音 → 纪要 → 结构化摘要在征得对方同意的前提下不管是跟技术总监沟通还是直接对客户我都会尽量保留完整沟通记录。录音传给飞书自动生成文字纪要然后我做一次人工收敛把业务定义、数据流向、接口预期、非功能约束整理成一段结构化摘要。▲ 从录音到结构化摘要的流程2. 让 DeepSeek 出初版架构方案这段摘要我不会直接拿来写代码而是先丢给 DeepSeek附上一条非常明确的生成约束“根据以下需求摘要生成一个初步的技术架构方案必须包含技术栈选型、核心包结构、关键模块边界和主要风险点。”这时候 DeepSeek 会给我一版骨架。我在这版骨架上反复补充和修正——把我对团队技术栈的熟悉程度、部署习惯、性能底线这些隐性知识一点一点填进去直到它变成一份第二天就能照着施工的文档。▲ 结构化摘要到初版架构方案的转化3. ChatGPT 审查DeepSeek 复核我做取舍到了这一步这份架构文档大概率已经带着我个人的认知偏见。所以我一定会再引入一轮“交叉审查”。这里有一个容易漏掉的关键动作我不仅把架构文档交给 ChatGPT还会把最初跟领导、客户沟通的原文也就是录音纪要原原本本同步给 ChatGPT。这样做有两个目的。第一让 ChatGPT 判断这份架构方案有没有跑偏——有没有脱离最初沟通里明确提到的业务边界、使用场景和非功能约束。第二也是更重要的让 ChatGPT 自己重新理解一遍最原始的需求不是基于我的摘要而是基于业务原声。它重新理解之后再去审架构文档经常能发现我在摘要环节无意中漏掉的信息排错质量比只看架构文档高一个量级。ChatGPT 审完之后我会把它的意见原样转给 DeepSeek让 DeepSeek 逐条判断哪些合理、哪些脱离实际哪些可以采纳哪些不应该动。最后由我来做最终的裁剪和决策。我只改那些确实能降低风险、并且可落地的点绝不为“好像也可以这样”而推翻已经稳定的骨干结构。这一步的核心不是哪个模型说了算而是人必须留在决策闭环里。AI 负责提供第二视角人负责仲裁和担责。4. 反向生成提示词先“立骨架”架构文档稳定之后我不直接进入业务开发而是先把文档反向生成一份“骨架搭建提示词”让 AI 拉出整个项目的空壳——空包、空模块、裸配置、依赖声明、Dockerfile 模板。然后立刻跑一遍pyproject.toml、npm run build、mvn test或者对应项目的基础门禁命令验证目录设计有没有致命冲突。我们内部管这一步叫“先立骨架”本质上是在用最低成本验证这套结构能不能站住。用 AI 开发第一步永远不是写代码而是冻结上下文。上下文锁不住后面写得越快返工越狠。三、把 AI 开发切成可以独立验收的“施工单元”架构和骨架就绪之后真正的开发过程我不是“让 AI 看着办”而是严格按一套施工手册来管理。这套施工手册的结构大概长这样施工手册/ ├── 执行记录/ # 每一步的实际执行日志 ├── README.md # 总原则、阶段说明、门禁命令 ├── manifest.yaml # 机器可读的进度快照 ├── p0-最小闭环/ │ ├── README.md # 本阶段目标 │ ├── p0.1-xxx/ │ │ ├── 01-xxx.md # 施工单元 │ │ ├── 02-xxx.md │ └── ... ├── p1-单项目全自动/ ├── p2-可靠性加固/ └── 通用施工提示词.md # 可复用的 AI 工作约束模板▲ 施工手册目录结构重点标出 manifest.yaml、执行记录文件夹、阶段文件夹下面解释几个关键设计。1. 阶段拆分不追求一次全对只追求每一步可验收我现在做任何 AI 驱动项目一定拆成多个阶段而且每个阶段必须有独立的验收门禁P0 最小闭环验证调度、沙箱执行、状态落盘能不能跑通哪怕只是让 AI 生成一个hello.py然后在 Docker 里跑一遍。P1 单项目全自动从一份规范文档到可交付的 Docker 包首次打通全链路。P2 可靠性加固加入测试可信度、失败归因、自修复、合并冲突处理。P3 人机协同Web 界面、WebSocket 状态推送、审批流。P4 长期能力半路接盘、增量开发、日志查询、安全审计。这种拆法不是过度设计而是因为被坑怕了。以前不拆阶段AI 一上来就写全功能最后表面上 70% 能跑真正难处理的是那 30% 藏在边界条件里的问题。拆了之后每完成一个阶段我就知道什么东西是已经被验证过的。即使后面出新问题排查范围也被死死框住。2. 施工单元AI 的唯一任务就是“完成当前这一步”施工手册里每一个01-xxx.md文件就是一个原子化的施工单元。一份标准的施工单元文件一定写清楚三件事这是要干什么目标允许修改哪些文件写入边界怎么算做完验收命令。给 AI 执行时我只把当前这一份文件丢进去同时硬性约束它你可以读取必要的上下文包括项目结构、依赖关系、已完成步骤但不允许自行扩展任务范围。你只负责完成当前施工单元。人是唯一的调度者和验收者你只是负责执行。这种做法有两个好处。第一防止 AI“自作主张”越改越乱。第二让任何一个 AI 实例或者任何一个新接盘的人拿着同一份文件就能精确工作。3. 执行记录AI 也必须有“施工日志”每完成一个施工单元不管成功还是失败都必须立刻写一份执行记录格式固定步骤 ID实际新增/修改了什么文件跑了什么验收命令验收通过还是失败出了什么问题怎么处理的下一个要执行的步骤。这就是 AI 开发的“施工日志”。好处非常直接三个月后的我自己不用靠记忆回溯“这一步当时到底怎么过的”。新同事接手读记录就能对齐全部上下文而不是对着代码猜。多人并行时A 完成 p0.2 的记录B 可以直接拿过来继续 p0.3沟通成本降到很低。4. manifest.yaml给下一个 AI或者下一个人类看的进度快照除了人类可读的执行记录我还必须维护一份机器可读的进度快照manifest.yaml大概长这样-id:p0_1_01_project_skeletonphase:p0type:codedepends_on:[p0_0_04_artifact_schemas]outputs:-README.md-pyproject.toml-.gitignoreverify_commands:-python-m compileall-q src scripts testsstatus:pending它的作用是新开一个对话时AI 读一遍 manifest就能立刻知道现在项目推进到哪一步、哪些已经 done、哪些还 pending、依赖关系是什么。这极大解决了“上次我们说到哪儿了来着”的史诗级痛点。manifest.yaml 片段示例▲ 箭头标注 done/pending 状态、依赖关系和 verify_commands 字段四、你可以直接抄走的最小施工单元模板上面这套体系你可能觉得“跟我项目关系不大”。但它的核心逻辑可以立刻抽成一个极简模板任何 AI 开发任务都能套用。AI 开发最小施工单元1. 当前目标xxxx 2. 输入资料xxxx 3. 允许修改的文件列表写入边界 4. 禁止修改的文件列表 5. 预期产出 6. 验收命令 7. 完成后记录 - 实际改动文件 - 验收结果 - 遗留问题 - 下一步骤一个真实示例步骤 IDp0_1_01_init_backend 目标 初始化 Spring Boot 工程骨架。 允许修改 - pom.xml - src/main/java/** - src/main/resources/application.yml 禁止修改 - docs/architecture.md - database/** - frontend/** 验收命令 - mvn test - mvn spring-boot:run 完成后记录 - 新增/修改pom.xml, Application.java - 验收结果通过 - 遗留问题application.yml 中数据库配置留空 - 下一步p0_1_02_config_baseline即使你不用任何工具只要你在每次让 AI 写代码之前手动填好上面这张“施工单”AI 越界、返工和破坏已有结构的概率也会明显下降。工程化管理的核心就是把“人记住的事”变成“流程规定的事”然后让这个流程可以被任何一个人、任何一个 AI 实例复现。五、这套方法也不是银弹它适合谁不适合谁我必须非常诚实地写这一节因为它决定你是否该用这套方法。它不适合的场景一次性脚本、临时 Demo、极短期原型验证。这类任务上下文本身很小强行拆施工单元反而增加负担。负责人没有足够架构判断力的场景。施工单元拆得好不好直接决定 AI 跑不跑偏如果拆错了AI 会在错误的约束里快速生产错误代码酿成更严重的返工。模型基础能力不足时。这套方法只能降低管理层面的失控概率不能解决模型本身生成质量不过关的问题。它不能替代代码审查和测试体系也不能替代你对业务的理解。它真正发挥价值的场景长期维护、多人协作、需要反复接盘的项目。有明确交付要求的商业项目。需要持续迭代、增量开发、不能每次都推翻重来的产品。如果你正在做这一类项目那么现在就可以从第一条“冻结上下文”开始在你下一个需求里跑一遍试试。六、工程化不是“酷”是保命AI 开发最可怕的不是不够快而是不可接手、不可回滚、不可解释。这一整年我自己感受最深的一点是很多团队不是用不好 AI而是没有用工程化的方式去管理 AI。他们误以为 AI 开发就是调提示词实际上提示词只是最后一步前面还有上下文管理、边界约束、阶段拆解、验收标准、记录留存。后面我把这套流程方法整合进了内部一直在迭代的SpecShip 工作流体系里核心就是施工手册驱动引擎 多模型交叉审查链路让“按流程做事”这件事本身也被工具化。但名字不重要真正重要的是把这套“边界、记录、验收、交接”的工作方式落到实际开发节奏里。用工程化思维治理 AI不是让它变慢而是让它变得可靠、可预期、可以被团队真正拥有——而不仅仅是某个人电脑上的一堆漂亮 sample。如果你也在用 AI 做长期项目或者正在被 AI 项目的交付折磨欢迎评论区聊聊。我不一定回得快但每一个真正踩过坑的问题我都愿意聊。这篇文章不是工具介绍也不是成功学分享。它只是一个被 AI 坑了无数次的人在真实商业项目里反复试错后找到的一套还能站得住的方法。 《别再“喂prompt赌运气”了：我的AI开发工程化管理实践》
《别再“喂prompt赌运气”了我的AI开发工程化管理实践》分享一套我用了一年多的 AI 工程化实践。不是工具说明书而是一套让 AI 开发可预期、可交接、可回滚的管理方法。目录一、为什么 AI 写代码这么容易失控二、第一步别让 AI 写代码先让它“冻结上下文”1. 录音 → 纪要 → 结构化摘要2. 让 DeepSeek 出初版架构方案3. ChatGPT 审查DeepSeek 复核我做取舍4. 反向生成提示词先“立骨架”三、把 AI 开发切成可以独立验收的“施工单元”1. 阶段拆分不追求一次全对只追求每一步可验收2. 施工单元AI 的唯一任务就是“完成当前这一步”3. 执行记录AI 也必须有“施工日志”4. manifest.yaml给下一个 AI或者下一个人类看的进度快照四、你可以直接抄走的最小施工单元模板AI 开发最小施工单元一个真实示例五、这套方法也不是银弹它适合谁不适合谁它不适合的场景它真正发挥价值的场景六、工程化不是“酷”是保命一、为什么 AI 写代码这么容易失控如果你在生产环境里用过 AI 辅助开发一定经历过这种痛苦白天跑得好好的 Demo晚上加一个需求第二天整个项目红了一片。AI 能帮你从 0 写到 80%但剩下 20% 的边界问题、模块冲突、隐性假设能让你填坑填到怀疑人生。这还不是最可怕的。最可怕的是团队协作同一个需求丢给不同的模型出来的结构天差地别上一次能跑通的提示词下次换一个上下文就崩了三个月后新同事接手连你当时是怎么让 AI 生成这段代码的都看不懂项目里有大量“上次 AI 写的现在没人敢动”的黑盒模块。一年前我开始有意识地把 AI 开发从“赌 prompt”拉回到工程轨道上慢慢形成了一套可复制的工作方式。核心思路只有一句话用 AI 驱动开发用工程化思维治理 AI用工程化管理落地项目。工程化管理的核心就是去人化——按流程做事而不是依靠某个人的记忆和直觉。下面的内容是我这一年反复试错、迭代后剩下的最靠谱的东西。二、第一步别让 AI 写代码先让它“冻结上下文”大部分 AI 开发失控的根源不是模型不够强而是需求上下文没锁死。人脑补了但没写进提示词的细节AI 只能猜猜错了人又懒得对齐最后项目越跑越偏。我现在接手任何一个需求固定走下面这四步在真正写代码之前先把上下文彻底冻结。1. 录音 → 纪要 → 结构化摘要在征得对方同意的前提下不管是跟技术总监沟通还是直接对客户我都会尽量保留完整沟通记录。录音传给飞书自动生成文字纪要然后我做一次人工收敛把业务定义、数据流向、接口预期、非功能约束整理成一段结构化摘要。▲ 从录音到结构化摘要的流程2. 让 DeepSeek 出初版架构方案这段摘要我不会直接拿来写代码而是先丢给 DeepSeek附上一条非常明确的生成约束“根据以下需求摘要生成一个初步的技术架构方案必须包含技术栈选型、核心包结构、关键模块边界和主要风险点。”这时候 DeepSeek 会给我一版骨架。我在这版骨架上反复补充和修正——把我对团队技术栈的熟悉程度、部署习惯、性能底线这些隐性知识一点一点填进去直到它变成一份第二天就能照着施工的文档。▲ 结构化摘要到初版架构方案的转化3. ChatGPT 审查DeepSeek 复核我做取舍到了这一步这份架构文档大概率已经带着我个人的认知偏见。所以我一定会再引入一轮“交叉审查”。这里有一个容易漏掉的关键动作我不仅把架构文档交给 ChatGPT还会把最初跟领导、客户沟通的原文也就是录音纪要原原本本同步给 ChatGPT。这样做有两个目的。第一让 ChatGPT 判断这份架构方案有没有跑偏——有没有脱离最初沟通里明确提到的业务边界、使用场景和非功能约束。第二也是更重要的让 ChatGPT 自己重新理解一遍最原始的需求不是基于我的摘要而是基于业务原声。它重新理解之后再去审架构文档经常能发现我在摘要环节无意中漏掉的信息排错质量比只看架构文档高一个量级。ChatGPT 审完之后我会把它的意见原样转给 DeepSeek让 DeepSeek 逐条判断哪些合理、哪些脱离实际哪些可以采纳哪些不应该动。最后由我来做最终的裁剪和决策。我只改那些确实能降低风险、并且可落地的点绝不为“好像也可以这样”而推翻已经稳定的骨干结构。这一步的核心不是哪个模型说了算而是人必须留在决策闭环里。AI 负责提供第二视角人负责仲裁和担责。4. 反向生成提示词先“立骨架”架构文档稳定之后我不直接进入业务开发而是先把文档反向生成一份“骨架搭建提示词”让 AI 拉出整个项目的空壳——空包、空模块、裸配置、依赖声明、Dockerfile 模板。然后立刻跑一遍pyproject.toml、npm run build、mvn test或者对应项目的基础门禁命令验证目录设计有没有致命冲突。我们内部管这一步叫“先立骨架”本质上是在用最低成本验证这套结构能不能站住。用 AI 开发第一步永远不是写代码而是冻结上下文。上下文锁不住后面写得越快返工越狠。三、把 AI 开发切成可以独立验收的“施工单元”架构和骨架就绪之后真正的开发过程我不是“让 AI 看着办”而是严格按一套施工手册来管理。这套施工手册的结构大概长这样施工手册/ ├── 执行记录/ # 每一步的实际执行日志 ├── README.md # 总原则、阶段说明、门禁命令 ├── manifest.yaml # 机器可读的进度快照 ├── p0-最小闭环/ │ ├── README.md # 本阶段目标 │ ├── p0.1-xxx/ │ │ ├── 01-xxx.md # 施工单元 │ │ ├── 02-xxx.md │ └── ... ├── p1-单项目全自动/ ├── p2-可靠性加固/ └── 通用施工提示词.md # 可复用的 AI 工作约束模板▲ 施工手册目录结构重点标出 manifest.yaml、执行记录文件夹、阶段文件夹下面解释几个关键设计。1. 阶段拆分不追求一次全对只追求每一步可验收我现在做任何 AI 驱动项目一定拆成多个阶段而且每个阶段必须有独立的验收门禁P0 最小闭环验证调度、沙箱执行、状态落盘能不能跑通哪怕只是让 AI 生成一个hello.py然后在 Docker 里跑一遍。P1 单项目全自动从一份规范文档到可交付的 Docker 包首次打通全链路。P2 可靠性加固加入测试可信度、失败归因、自修复、合并冲突处理。P3 人机协同Web 界面、WebSocket 状态推送、审批流。P4 长期能力半路接盘、增量开发、日志查询、安全审计。这种拆法不是过度设计而是因为被坑怕了。以前不拆阶段AI 一上来就写全功能最后表面上 70% 能跑真正难处理的是那 30% 藏在边界条件里的问题。拆了之后每完成一个阶段我就知道什么东西是已经被验证过的。即使后面出新问题排查范围也被死死框住。2. 施工单元AI 的唯一任务就是“完成当前这一步”施工手册里每一个01-xxx.md文件就是一个原子化的施工单元。一份标准的施工单元文件一定写清楚三件事这是要干什么目标允许修改哪些文件写入边界怎么算做完验收命令。给 AI 执行时我只把当前这一份文件丢进去同时硬性约束它你可以读取必要的上下文包括项目结构、依赖关系、已完成步骤但不允许自行扩展任务范围。你只负责完成当前施工单元。人是唯一的调度者和验收者你只是负责执行。这种做法有两个好处。第一防止 AI“自作主张”越改越乱。第二让任何一个 AI 实例或者任何一个新接盘的人拿着同一份文件就能精确工作。3. 执行记录AI 也必须有“施工日志”每完成一个施工单元不管成功还是失败都必须立刻写一份执行记录格式固定步骤 ID实际新增/修改了什么文件跑了什么验收命令验收通过还是失败出了什么问题怎么处理的下一个要执行的步骤。这就是 AI 开发的“施工日志”。好处非常直接三个月后的我自己不用靠记忆回溯“这一步当时到底怎么过的”。新同事接手读记录就能对齐全部上下文而不是对着代码猜。多人并行时A 完成 p0.2 的记录B 可以直接拿过来继续 p0.3沟通成本降到很低。4. manifest.yaml给下一个 AI或者下一个人类看的进度快照除了人类可读的执行记录我还必须维护一份机器可读的进度快照manifest.yaml大概长这样-id:p0_1_01_project_skeletonphase:p0type:codedepends_on:[p0_0_04_artifact_schemas]outputs:-README.md-pyproject.toml-.gitignoreverify_commands:-python-m compileall-q src scripts testsstatus:pending它的作用是新开一个对话时AI 读一遍 manifest就能立刻知道现在项目推进到哪一步、哪些已经 done、哪些还 pending、依赖关系是什么。这极大解决了“上次我们说到哪儿了来着”的史诗级痛点。manifest.yaml 片段示例▲ 箭头标注 done/pending 状态、依赖关系和 verify_commands 字段四、你可以直接抄走的最小施工单元模板上面这套体系你可能觉得“跟我项目关系不大”。但它的核心逻辑可以立刻抽成一个极简模板任何 AI 开发任务都能套用。AI 开发最小施工单元1. 当前目标xxxx 2. 输入资料xxxx 3. 允许修改的文件列表写入边界 4. 禁止修改的文件列表 5. 预期产出 6. 验收命令 7. 完成后记录 - 实际改动文件 - 验收结果 - 遗留问题 - 下一步骤一个真实示例步骤 IDp0_1_01_init_backend 目标 初始化 Spring Boot 工程骨架。 允许修改 - pom.xml - src/main/java/** - src/main/resources/application.yml 禁止修改 - docs/architecture.md - database/** - frontend/** 验收命令 - mvn test - mvn spring-boot:run 完成后记录 - 新增/修改pom.xml, Application.java - 验收结果通过 - 遗留问题application.yml 中数据库配置留空 - 下一步p0_1_02_config_baseline即使你不用任何工具只要你在每次让 AI 写代码之前手动填好上面这张“施工单”AI 越界、返工和破坏已有结构的概率也会明显下降。工程化管理的核心就是把“人记住的事”变成“流程规定的事”然后让这个流程可以被任何一个人、任何一个 AI 实例复现。五、这套方法也不是银弹它适合谁不适合谁我必须非常诚实地写这一节因为它决定你是否该用这套方法。它不适合的场景一次性脚本、临时 Demo、极短期原型验证。这类任务上下文本身很小强行拆施工单元反而增加负担。负责人没有足够架构判断力的场景。施工单元拆得好不好直接决定 AI 跑不跑偏如果拆错了AI 会在错误的约束里快速生产错误代码酿成更严重的返工。模型基础能力不足时。这套方法只能降低管理层面的失控概率不能解决模型本身生成质量不过关的问题。它不能替代代码审查和测试体系也不能替代你对业务的理解。它真正发挥价值的场景长期维护、多人协作、需要反复接盘的项目。有明确交付要求的商业项目。需要持续迭代、增量开发、不能每次都推翻重来的产品。如果你正在做这一类项目那么现在就可以从第一条“冻结上下文”开始在你下一个需求里跑一遍试试。六、工程化不是“酷”是保命AI 开发最可怕的不是不够快而是不可接手、不可回滚、不可解释。这一整年我自己感受最深的一点是很多团队不是用不好 AI而是没有用工程化的方式去管理 AI。他们误以为 AI 开发就是调提示词实际上提示词只是最后一步前面还有上下文管理、边界约束、阶段拆解、验收标准、记录留存。后面我把这套流程方法整合进了内部一直在迭代的SpecShip 工作流体系里核心就是施工手册驱动引擎 多模型交叉审查链路让“按流程做事”这件事本身也被工具化。但名字不重要真正重要的是把这套“边界、记录、验收、交接”的工作方式落到实际开发节奏里。用工程化思维治理 AI不是让它变慢而是让它变得可靠、可预期、可以被团队真正拥有——而不仅仅是某个人电脑上的一堆漂亮 sample。如果你也在用 AI 做长期项目或者正在被 AI 项目的交付折磨欢迎评论区聊聊。我不一定回得快但每一个真正踩过坑的问题我都愿意聊。这篇文章不是工具介绍也不是成功学分享。它只是一个被 AI 坑了无数次的人在真实商业项目里反复试错后找到的一套还能站得住的方法。