其实，

别再“喂prompt赌运气”了：我的AI开发工程化管理实践

目录

• 一、为什么 AI 写代码这么容易失控？
• 二、第一步先：别让 AI 写代码，先让它“冻结上下文”
• 三、把 AI 开发切成可以独立验收的“施工单元”
• 四、你可以直接抄走的最小施工单元模板
• 五、这套方法也不是银弹：它适合谁。不适合谁
• 六、工程化不是“酷”，是保命

一、为什么 AI 写代码这么容易失控？

如果你在生产环境里用过 AI 辅助开发。一定经历过这种痛苦：

• 需求变动频繁，导致项目反复重跑。按理说，
• 团队协作不畅。同一个需求给不同模型得到完全不一致的结构。
• AI 的输出缺乏可追溯性，后续维护者连如何让它生成这段代码都看不懂。
• "上次 AI 写的，现在没人敢动" 的黑盒模块随处出现。

"你还在靠运气喂 prompt 吗？"

我意识到。主要问题不是模型本身，而是人对上下文和边界缺乏程序化掌控。

再看主要理念。

用 AI 驱动开发，用工程化思维治理 AI，用流程落地项目。去人化——按流程做事，而非依赖个人记忆与直觉。

二、第一步先：别让 AI 写代码。先让它“冻结上下文”

"我们只给 AI 一句话提示，却总是跑偏。"

"业务细节被遗漏，导致后期大量返工。"

"同一个需求，多次尝试仍然无法得到一致结果。"

1️⃣ 录音 → 纪要 → 结构化摘要

关键步骤：

• - 在沟通前征得同意后录音；- 用飞书自动转文字，- 人工提炼业务定义、数据流向、接口预期与非功能约束；- 输出为结构化摘要，
• "从录音到摘要的闭环，让所有细节都有据可查。"

2️⃣ 把摘要交给 DeepSeek 做初版架构方案

"根据以下需求摘要。生成一个初步技术架构方案，包括技术栈选型、主要包结构、关键模块边界和主要风险点。" — 提示词

DeepSeek 给出骨架。我根据团队技术栈熟悉度和部署习惯逐条补充。骨架最终演变成第二天即可照着施工的文档。)

3️⃣ 双重审查：ChatGPT 与 DeepSeek 的交叉校验 + 人类决策闭环

1. 把原始纪要同步给 ChatGPT。让其重新理解业务原声，再审阅架构文档。
2. ChatGPT 输出修正建议，再交给 DeepSeek 判断哪些合理可采纳。话说回来，
3. 我做最终裁剪。只改那些能减少风险且可落地的点。永远不因 “好像也能这样” 推翻稳定骨干。
4. 人必须留在决策闭环里——AI 提供第二视角，人负责仲裁与担责。
**为什么要双重审查** ① 防止因摘要误差导致全局跑偏 ② 保证最终方案贴合业务原声与团队实际能力 ③ 降低后期大规模返工成本 **" /> `` `` `

` **双重审查带来的收益**

• 准确性提高ChatGPT 能捕捉到摘要中被遗漏的信息
• 一致性保持DeepSeek 与 ChatGPT 的互检减少语义漂移

• 人机共治避免单一模型主导造成偏见

  ``

``

---

**主要提醒** 即使使用最强模型。也需手动梳理关键细节，否则仍会出现不可预见错误。

---

. 反向生成提示词，先“立骨架” ``

---

当骨架确定后我不会直接写业务代码。而是先把文档反向生成一份 “骨架搭建提示词”，让 AI 拉出整个项目空壳——空包/空模块/裸配置/依赖声明/Dockerfile 模板。随后立即跑基础门禁命令，验证目录设计是否存在致命冲突。 这一步叫 “先立骨架”，相当于最低成本验证结构是否能站住。*一句话*: 用 AI 开发。第一步先永远不是写代码，而是彻底冻结上下文。锁不住上下文，就等同于把项目交给娱乐桌上下注。

---

三、《把 AI 开发切成可以独立验收的“施工单元”》

痛点回顾

• 一次性写完全部功能，总是陷入边界细节纠纷。
• 不同阶段间缺乏明确门禁，导致后续修改时无从下手。
• 新同事接手时只能凭记忆推断方法，无实物依据。

解决思路

1. 拆分为若干阶段，每个阶段有独立验收门禁。
2. 每个阶段拆解为若干 施工单元。
3. 严格记录执行日志与进度快照，让任何人或任何实例都能精准复现。

《施工手册》目录示例

text 施工手册/ ├── 执行记录/ # 每一步实际执行日志 ├── README.md # 总原则与阶段说明 ├── manifest.yaml # 機器可读进度快照 ├── p0-最小闭环/ │   ├── README.md # 本阶段目标 │   ├── p0.-xxx/ │   │   ├── -xxx.md # 单个施工单元 │   │   └── ... ├── p1-单项目全自动/ ├── p2-可靠性加固/ └── 通用施工提示词.md # 可复用模板

关键设计解释

a) 阶段拆分—追求每一步可验收而非一次全对

阶段	验收门禁
P0 最小闭环	调度沙箱运行 & 状态落盘
P1 单项目全自动	从规范文档到 Docker 包
P2 可靠性加固	测试可信度、自修复
P3 人机协同	Web UI & 审批流
P4 长期能力	日志查询、安全审计

b) 《施工单元》—AI 的唯一任务是完成当前步骤

每份 ‑xxx.md 必须清晰列明

1. 当前目标
2. 可修改文件列表
3. 验收命令

说到并严格约束。

text 你只能读取必要上下文，包括已完成步骤；其实，但不可自行 任务范围。

c) 执行记录—AI 的「施工日志」

再看格式固定，

yaml step_id: added_or_modified_files: verification_commands: 从result来看。issues_and_resolution: next_step:

再看好处，

• 三个月后的自己不用记忆回溯；
• 新同事仅凭记录即可对齐全部上下文；怎么说呢，
• 多人并行时沟通成本降至最低。

d) manifest.yaml—进度快照供下一轮使用

至于示例片段，

yaml 说到id，p0_1_01_project_skeleton 从phase来看，p0 再看type。code depends_on: - p0_0_04_artifact_schemas outputs: - README.md - pyproject.toml verify_commands: - python -m compileall -q src scripts tests status的观点是，pending

再看作用，

• 对话开启即知道已完成 vs 待完成；
• 明确依赖关系；
• 自动驱动下一个工作流。

---

四、《你可以直接抄走的最小施工单元模板》

模板概览

text

• 实际改动文件：
• 验收结果：
• 遗留问题：
• 接下来骤：

实例演示

text 步骤 ID：p0_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 至于完成后记录，- 新增/修改文件列表 - 验收结果通过 - 遗留问题 - 接下来

即使没有任何工具，只要在每次让 AI 写代码前手工填好上述表格，越界返工概率大幅下降。其实，

---

五、《这套方法也不是银弹》——适合谁。不适合谁，

不适合场景

场景	原因
一次性脚本 / 临时 Demo	上下文本身很小。拆分反而增加负担
团队成员缺乏足够架构判断力	单纯拆分无法弥补基础判断不足
模型基础能力不足	管理层面降低失控概率，但不能替代代码审核

真正产生作用场景

1. 长期维护、多人与多人协作且需要频繁接盘；
2. 有明确交付要求的商业项目；
3. 持续迭代增量开发，需要保留历史版本且避免大幅推翻。

如果你正在进行上述任一类项目。就从《冻结上下文》开始，在下一条需求中试运行一次吧！

---

六、《工程化不是“酷”，是保命》

痛点 至于强调。

• 项目无法接手 → 无法回滚 → 无法解释；
• 团队没有统一流程，只靠「调 prompt」→ 难以预测；
• 错误源头难定位 → 大规模返工成本高昂。

这一年。我将完整流程整合进内部 SpecShip 工作流程序，实现工具化。但将「边界・记录・验收・交接」落到实际开发节奏里。

---

这篇文章并非工具介绍。也非成功学分享，仅是一名曾被AI坑数十次的人，在真实商业项目里反复试错后找到的一套可靠方法。