很多 AI 辅助开发项目，问题不是出在“模型不会写代码”，而是出在我们太早让它开始写代码。
一个常见的场景是：先给 AI 一段模糊描述，让它把页面、路由、表单、数据库一起生成出来。第一轮看上去进展很快，页面有了，CRUD 也跑起来了；但继续往下做，就会发现前端、后端、数据库三边各自带着不同的假设。字段越补越多，状态越改越乱，最后的返工往往不是因为实现差，而是因为系统从一开始就没有被想清楚。
最容易走错的一步：把所有项目都当成同一种项目来做。 展示型项目和业务系统型项目，风险根本不是一个维度。前者最怕页面表达跑偏，后者最怕结构建错。流程不分型，后面再怎么补 Prompt，都只是在放大前面的误差。
第一步：判断项目分型
AI 辅助开发不是只有一条标准流水线。我们建议先判断项目更接近“展示型”还是“系统型”，再决定执行路径。
A 类：展示与表达为主的轻项目
核心目标：把信息讲清楚，把页面做对。
- 典型场景：Landing page、营销官网、品牌展示页、静态博客、演示原型。
- 主要风险：视觉风格跑偏、信息架构混乱、交互节奏不顺。
- 推荐路径：
背景澄清->页面结构->视觉规则->前端生成->补齐少量数据。
这类项目如果先花很多时间建模型架构，往往属于过度设计。先把视觉约束收敛住，数据层只补到够用为止。
B 类：业务与数据为主的系统型项目
核心目标：确保系统运转逻辑的闭环。
- 典型场景：CRUD 后台、CMS、工作流、订单/资产管理、SaaS 平台。
- 主要风险：需求理解偏差、对象建模错误、状态流转混乱、后期返工成本极高。
- 推荐路径：
背景澄清->需求挖掘->领域对象->Schema 设计->场景反验->数据/状态流->Spec Pack->AGENT.md->交付代码。
避开“系统型项目先画页面”的陷阱
表面上看，先出页面能让团队有“进度感”。但系统型页面的字段、状态和权限，经常只是 AI 根据模板脑补出来的“默认答案”。
一旦这些模棱两可的页面先行，返工压力会沿着整条链路传下去：
- 页面先假设了对象结构。
- 接口为了配合页面，临时补丁式加字段。
- 数据库被迫贴着接口走。
- 最后：遇到历史记录、权限边界或状态回滚时，发现架构根本承载不住。
深度 Discovery：消灭模糊性
系统型项目的第一阶段不是“设计”，而是 Discovery。目标是先把项目想明白。
1. 钉住项目边界
先用最小篇幅回答几个基础问题：
- 这个项目到底解决什么问题？
- 谁是目标用户？在什么场景下使用？
- 现在的痛点在哪里？成功标准是什么？
- MVP 这期只做什么？哪些明确不做？
2. 通过 AI 连环追问挖掘“空洞”
不要让 AI 直接出方案，而是让它作为采访者，把需求中的灰色地带逼出来。
- 多角色：是否存在不同的权限体系？
- 业务深度：哪一步最容易出错？哪一步最不能错？
- 持久化细节：哪些操作需要保留历史？哪些状态必须持久化？
- 外围能力：是否需要通知、导入导出、搜索和筛选？
3. 梳理业务场景，而非 UI 流程
在定结构前，先讲清楚业务逻辑：
动作发起者->作用对象->状态变化->可见性/回滚/历史。
建立稳定规格：识别对象与 Schema 反验
4. 识别领域对象 (Domain Objects)
不要急着多建表。区分什么是“真实对象”，什么只是某个对象上的“附属字段”。
- 误区 A：把字段误建成对象（结构臃肿）。
- 误区 B：把独立对象硬塞进 JSON 字段（导致后续查询、约束和历史追踪极其困难）。
5. 用 Schema 锁定系统级事实源
定义实体、字段、必填项、默认值、枚举、约束和删除策略。这不仅是给数据库看，更是给后续参与实现的多个 AI Agent 看。
6. 场景反验：在写代码前进行“推演”
把之前整理的业务场景逐条拿来对 Schema 进行压力测试：
- 这个输入落到哪张表？那个状态变化有没有地方记？
- 删除这条记录时，历史链路会断吗？
- 如果推演发现表达不了，就在 Schema 层改，这比改代码便宜 100 倍。
Spec Pack：将信息拆解为可执行规格
不要写一份巨大的 PRD。AI 处理高密度、职责单一的细分文档效果更好。建议采用如下 specs/delivery 结构：
| 规格文件 | 核心职责 |
|---|---|
00-product-spec.md |
总控。定义目标、非目标及技术边界。 |
01-user-flows.md |
路径。定义页面结构、跳转关系和交互结果。 |
02-data-model.md |
结构。核心实体、关系、命名规范和约束。 |
03-rules-and-edge-cases.md |
边界。异常、空状态、权限、自动保存等。 |
04-ui-guidelines.md |
视觉。组件标准，避免 UI 风格在生成中漂移。 |
05-acceptance-runbook.md |
运行。环境、Build 命令、部署约束、验收标准。 |
建议保留 discovery/（原始思考过程）和 domain/（结构推演过程）作为前置文档。这样 delivery 文件夹可以保持高信噪比，而决策过程依然有迹可循。
执行层：Agent 编排与分轮投喂
核心入口：AGENT.md
在仓库根目录放一份 AGENT.md（英文）。它不负责展开细节，而是作为一个高密度索引，告诉 AI Agent：
- 这个项目用什么架构？
- 谁是 Single Source of Truth？
- 目录结构如何分布？
- 新增功能需遵循什么 Workflow？
- 什么是 Out-of-Scope 的行为？
分轮执行策略
避免一次性投喂全量上下文，按轮次推进：
- 第一轮：打骨架。执行
00-product-spec、02-data-model，生成 Schema 和模块边界。 - 第二轮：通主流程。执行
01-user-flows，打通页面、路由和 CRUD 主路径。 - 第三轮：补边界。执行
03-rules-and-edge-cases，完善报错、校验和回滚逻辑。 - 第四轮：收敛 UI。执行
04-ui-guidelines，精细化处理视觉表达。
结论：让 AI 不要替你脑补系统
这套流程的核心：先分型，再决定流程的权重。
展示型项目先“页面”；业务型项目先“业务/数据/流转”，再“页面”。
对 AI 辅助开发来说，真正稳定的不是“更强的模型”，而是 更清楚的事实源 和 更少的脑补空间。通过 Spec Pack 和分轮执行，让 AI 在既定结构里执行任务，而不是让它替你决定系统应该长什么样。