最终：项目复盘

​

目标：做一套帮助产品、前端、后端和非 Coding 背景的人，学会指挥 AI 完成行业项目的教程。​

​

​

​

不是从 Prompt 直接跳到代码​

整个项目经历了六个连续阶段：​

​

代码块​

Plain Text

定义业务​

→ 设计产品​

→ 选择技术​

→ 拆开发任务​

→ 分阶段实现与验收​

→ 判断部署责任​

​

​

⭕

•

产品定义阶段，我们先回答给谁使用、解决什么问题、第一版做到哪里，以及什么结果才算成功。​

•

PRD 阶段把角色、权限、AI 状态、失败状态、数据对象和验收标准写清楚。​

•

原型阶段先画七页面和主路径，再通过同类产品、多个方案和设计契约冻结 UI，而不是让 AI 自由发挥。​

•

技术选型阶段没有听框架宣传，而是用同一道业务实验比较前端、后端、ORM、RAG、模型接入和任务队列。​

​

最终产品不是一个聊天框​

登录、工单、AI、知识、评测和审计七个页面​

​

​

第一版一共包含七个页面：​

首页和产品入口；​

登录与角色；​

工单列表；​

工单详情、AI 建议与人工确认；​

企业知识库；​

固定评测；​

管理与审计。​

它们共同服务一条闭环：客服登录后查看工单，系统检索企业知识，模型生成结构化建议，服务端校验来源与风险，客服编辑并确认最终稿，最后保存结果并进入审计和固定评测。​

少了任何一层，都只能算局部 AI 功能，不能算完整企业 Agent。​

AI 真正完成了哪些工作​

AI 承担了大量执行工作：​

•

搜集和拆解同类产品；​

•

生成页面与组件方案；​

•

把选择写成设计契约；​

•

比较技术候选并执行实验；​

•

生成数据库、API、前端和测试代码；​

•

构造合成工单与企业知识；​

•

调用真实 DeepSeek 并保存脱敏证据；​

•

自动运行测试和 production build；​

•

根据截图定位布局、路由和状态问题；​

•

整理任务书、审计记录、截图和验收报告。​

到项目结束，D01～D10 一共留下 150 个证据文件，其中包括 80 份 Markdown 文档和 53 张过程截图。​

这些数字不是为了证明工作量，而是为了让每个结论都有出处。​

人在整个过程中负责什么​

我没有逐行指挥 AI 怎么写代码。人的工作主要是连续做五类选择：​

1. 范围选择：第一版做什么、不做什么；​

2. 业务选择：角色权限、状态、人工确认和失败结果是否合理；​

3. 方案选择：多个 UI、技术和部署候选中选择哪一个；​

4. 风险选择：哪些限制可以接受，哪些问题必须停止；​

5. 阶段选择：证据是否足够，是否允许冻结并进入下一阶段。​

这就是我对“AI 执行，人做选择”的理解。​

人不需要比 AI 更快地写所有代码，但必须知道项目在为谁负责、什么证据足以支持一个决定。​

最值得保留的五个失败​

这个项目里，失败比顺利生成的页面更有教学价值。​

第一，原型里“转人工”按钮没有反应。它让我们意识到 Human-in-the-loop 不是一个按钮，而是原因、目标队列、状态变化和审计共同组成的新路径。​

第二，真实模型会生成伪来源、补充无依据操作和漏判风险。它证明模型不能直接形成企业业务结果。​

第三，RAG 在小规模通过，不代表 10 万片段下仍然可靠。我们冻结了 pgvector 的适用边界，没有把实验结论无限外推。​

第四，自动测试全部通过后，production build 里仍然出现文字比例、横向溢出和列表往返跳动。代码完成不等于产品完成。​

第五，项目可以上免费云，并不意味着应该立刻上云。没有备份恢复、告警、回滚和责任人，就不能把公网地址包装成企业生产环境。​

最终冻结的工程边界​

第一版使用 Next.js + React + TypeScript、独立 TypeScript API、PostgreSQL + Prisma、pgvector、PostgreSQL Worker 和模型适配层。​

但真正不可变的不是框架名称，而是这些工程规则：​

•

权限必须由服务端判断；​

•

关键写入必须使用事务和版本冲突保护；​

•

AI 只能看到授权、脱敏、最小化上下文；​

•

引用必须属于本轮检索白名单；​

•

高风险结果必须人工确认；​

•

AI 原稿与人工终稿分别保存；​

•

失败、拒绝、转人工和确认都有审计；​

•

模型、Prompt、知识和代码版本可以固定评测；​

•

没有证据的能力写“待验证”；​

•

当前发布等级是 L0 本地 Demo，不是公网生产上线。​

一套可以复用到其他行业的 Loop​

这个方法不只适用于客服工单。换成合同审阅、采购审批、财务异常、招聘筛选或医疗文档，仍然可以使用同一条循环：​

​

代码块​

Plain Text

定义目标和边界​

→ 生成多个候选​

→ 人选择一个方向​

→ AI 执行最小验证​

→ 保存成功和失败证据​

→ 人工验收​

→ 固化为规范​

→ 进入下一阶段​

​

如果过程中出现新问题，不只是修当前项目，还要把判断规则补回任务书、Prompt、设计契约或 Skill。这样下一次 AI 执行时，已经学会了这次的补充。​

可以直接复制的项目总控 Prompt：​

​

代码块​

Plain Text

你的目标不是一次生成完整网站，而是把一个行业问题交付为可运行、可验收、可追溯的第一版产品。​

​

先完成产品定义、轻量 PRD、页面地图、可点击原型、UI 选择和技术选型。然后把开发拆成有依赖关系的阶段任务书。​

​

​

这个项目最终证明了什么​

以前做产品，需要先学习大量工具，自己把需求、原型、前端、后端和部署逐一实现。​

现在更重要的能力正在变化：知道去哪里找资源，怎样把业务讲给 AI，怎样要求多个方案，怎样选择，怎样设计实验，怎样验收，以及怎样把选择固化成 AI 可以持续遵守的规则。​

AI 并没有让产品设计、技术选型和验收消失。​

它让这些决定变得更重要，因为代码生成得越快，错误方向被放大的速度也越快。​

这个系列的最终成果不只是一套企业售后工单工作台。​

更是一条可以复用的路径：从一个行业问题出发，指挥 AI，把产品真正做出来。​