夜雨聆风如何让 AI 更加体系化地完成一个从 0 到 1 的项目
🏗️ 用 AI 写代码不难，难的是让它像一个靠谱的团队一样，系统地把一个项目从无到有交付出来。
AI 编程的"最后一公里"问题
很多人已经习惯了用 AI 写代码。写一个组件、改一个 Bug、加一个接口——这些单点任务，AI 已经能完成得很好。
但当你尝试让 AI 独立完成一个完整项目时，你会发现它就像一个缺乏管理的天才程序员：
• 前后矛盾：上午写的架构下午就忘了，同一个功能用三种不同模式实现 • 没有全局观：每次对话只看眼前需求，不知道自己在整体项目中处于什么位置 • 质量随机：偶尔惊艳，偶尔离谱，全看运气 • 无法收口：功能一直在堆，但永远差那么一点就是交付不了
这不是 AI 能力的问题，是使用方式的问题。
你需要给 AI 一套体系化的工作框架——就像一个好的项目经理管理团队一样，让 AI 在清晰的边界、明确的流程、可衡量的标准下工作。
体系化的三层架构
我把"让 AI 体系化做项目"这件事拆成三层：
┌──────────────────────────────────────────┐│ 第一层：战略层 — 定义"做什么" ││ PRD、架构决策、技术选型 │├──────────────────────────────────────────┤│ 第二层：规则层 — 定义"怎么做" ││ Skills、约束规则、设计规范 │├──────────────────────────────────────────┤│ 第三层：执行层 — 让 AI "动手做" ││ 分阶段执行、自动验证、增量迭代 │└──────────────────────────────────────────┘每一层都不可或缺。缺了第一层，AI 不知道方向；缺了第二层，AI 各干各的；缺了第三层，停留在纸上谈兵。
第一层：战略层 — 在写代码之前把事情想明白
1.1 先写 PRD，而不是先写代码
很多人用 AI 做项目的第一句话就是"帮我写一个 xxx"。这就像你招了一个程序员，一句需求都没说清楚就让人动手，结果必然不断返工。
正确的起手式：
你："我想做一个 xxx 产品，目标用户是 xxx，核心场景是 xxx。 请帮我做一次头脑风暴，列出核心功能、技术方案和可能的风险点。"AI 在头脑风暴阶段的表现通常非常好——它见过无数项目，能快速给出多种方案对比。关键是你要引导它做充分讨论，而不是急于进入编码。
一份好的 PRD 至少包含：
1.2 架构决策要前置
AI 最容易犯的错就是架构漂移——同一个项目里用了三种状态管理方案，或者前半部分用 REST 后半部分变成了 GraphQL。
解法：在 PRD 中明确技术架构决策，让它成为后续所有开发的"宪法"。
## 技术架构决策记录（ADR）### ADR-001: 状态管理方案- 决策：使用 Riverpod 3.x- 原因：类型安全、编译时检查、生态成熟- 约束：所有状态一律通过 Provider 管理，禁止使用全局变量### ADR-002: 目录结构- 决策：按 Feature 分模块（Feature-First）- 原因：模块之间低耦合、便于 AI 分模块开发- 约束：每个 Feature 包含 presentation/domain/data 三层这些决策一旦写进 PRD，后续每次让 AI 写代码时，都把 ADR 作为上下文传入。AI 不会再自由发挥。
第二层：规则层 — 把标准"烧"进 AI 的工作环境
战略层解决"做什么"的问题，但光有方向不够。你还需要告诉 AI 代码应该长什么样。
2.1 用 Skills 固化编码规范
Skills（AI 技能规则）是 Harness Engineering 的核心概念。它本质上就是一套写给 AI 看的开发规范。
一个典型的项目 Skills 结构：
.agents/├── AGENTS.md # 全局规则└── skills/ ├── coding-style/ │ └── SKILL.md # 编码风格规范 ├── architecture/ │ └── SKILL.md # 架构约束规则 ├── testing/ │ └── SKILL.md # 测试标准 └── ui-design/ └── SKILL.md # UI 设计规范以编码风格为例：
# 编码风格规范## 命名规则- 文件名：小写 + 下划线（user_profile_page.dart）- 类名：大驼峰（UserProfilePage）- 变量名：小驼峰（userName）- 常量：大写 + 下划线（MAX_RETRY_COUNT）## 代码结构- 每个文件不超过 300 行- 每个函数不超过 50 行- 每个函数只做一件事- 优先使用 final 和 const## 错误处理- 使用 Result 模式（而非 try-catch 层层透传）- 所有对外 API 调用必须有错误兜底- 禁止空的 catch 块2.2 用模板和示例做"教学"
规则是抽象的，模板是具体的。比起告诉 AI "按照 Clean Architecture 写"，不如直接给它一个已有模块的代码作为范例：
# 新功能开发规范## 参考实现请参考 `lib/features/auth/` 模块的实现方式：- presentation/ → 页面和 Widget- domain/ → 实体和用例- data/ → 数据源和仓库实现## 创建新功能时的 Checklist1. [ ] 在 lib/features/ 下创建新目录2. [ ] 定义 Domain 层的实体和接口3. [ ] 实现 Data 层的数据源4. [ ] 创建 Presentation 层的页面5. [ ] 注册路由6. [ ] 编写测试AI 看到具体的参考实现，远比看一段抽象的架构描述更能理解你的意图。
2.3 质量门禁：让 AI 自己检查自己
好的体系不依赖人的 review，而是内建自动检查机制：
# 代码质量门禁## 每次代码生成后，必须自行执行以下验证1. 运行 `dart analyze` 确保无分析错误2. 运行测试确保无回归3. 检查本次修改是否影响了已有功能4. 确保新增文件已加入对应的 barrel file## 如果验证不通过- 先自行修复，不要等用户反馈- 如果三次修复仍失败，停下来报告问题而非继续尝试第三层：执行层 — 分阶段、可验证、可回退
有了方向、有了规则，最后一步是如何组织 AI 的执行节奏。
3.1 把大项目拆成小批次
永远不要说"帮我把整个项目写完"。AI 的上下文窗口有限，一次塞太多内容，质量必然下降。
推荐的拆分策略：
Phase 1: 基础设施搭建 ├── 项目初始化与目录结构 ├── 基础依赖配置 ├── 主题与设计系统 └── 路由框架Phase 2: 核心功能开发 ├── Feature A（按完整的 data → domain → presentation 顺序） ├── Feature B └── Feature CPhase 3: 集成与完善 ├── 功能间联调 ├── 异常场景处理 └── 性能优化Phase 4: 打磨与交付 ├── UI 细节调优 ├── 测试覆盖 └── 文档与部署每个 Phase 结束后，做一次验收。确认无误再进入下一个。
3.2 每个阶段的工作模板
每次让 AI 开始一个新阶段时，使用统一的指令结构：
## 当前阶段：Phase 2 - Feature A### 上下文- 项目 PRD：[链接或内容]- 架构决策：[ADR 内容]- 已完成的阶段：Phase 1（基础设施就绪）- 参考实现：lib/features/auth/### 本阶段目标实现用户个人资料功能，包含：1. 个人资料页面（展示 + 编辑）2. 头像上传功能3. 本地缓存用户信息### 约束- 遵循项目 Skills 中的所有规范- 不修改 Phase 1 中已完成的代码（除非有 Bug）- 每个子任务完成后运行验证### 验收标准- [ ] 个人资料页面可正常展示- [ ] 编辑功能可正常保存- [ ] 头像上传和裁剪流程通畅- [ ] 无分析错误和测试失败3.3 增量构建，而非推倒重来
AI 最糟糕的习惯是——遇到问题就想重写整个文件。你需要明确约束：
## 修改规则- 新增功能时，不修改已有的、正常工作的代码- 如需修改已有代码，先说明原因和影响范围- 禁止一次性重写超过一个文件- 每次变更必须是可独立验证的最小单元这条规则看似简单，但能避免 80% 的"改出新 Bug"问题。
实战流程：一个项目的完整生命周期
把上面三层串起来，一个完整的 AI 项目从 0 到 1 应该是这样的：
Day 1: 战略对齐 │ ├── 1. 头脑风暴：和 AI 讨论产品方向、功能规划 ├── 2. 写 PRD：确定 MVP 范围、技术选型、数据模型 └── 3. 架构决策：写 ADR，确定不可更改的技术边界 │Day 2: 环境搭建 │ ├── 4. 创建 Skills：编码规范、架构约束、质量门禁 ├── 5. 准备模板：参考实现、开发 Checklist └── 6. 项目初始化：脚手架、配置、设计系统 │Day 3-7: 分阶段开发 │ ├── 7. Phase by Phase 推进 ├── 8. 每个 Phase 结束后验收 └── 9. 发现问题 → 修复 Skills → 继续 │Day 8: 收口交付 │ ├── 10. 全局验证：跑一遍所有测试 ├── 11. 查漏补缺：UI 对齐、边界场景 └── 12. 部署上线注意 第 9 步 的反馈循环：每当 AI 犯了一个"本不该犯的错"，你要思考的不是"怎么让它改对"，而是"我的 Skills 里缺了什么规则，导致它犯了这个错"。
这就是 Harness Engineering 的核心思想——修环境，而非修代码。
常见陷阱与应对策略
陷阱 1：需求蔓延
症状：做着做着突然想加新功能，AI 来者不拒全都实现了，最后项目膨胀失控。
对策：PRD 中明确 MVP 边界。任何 MVP 范围外的需求，记入"后续迭代"列表，本期不做。
陷阱 2：上下文丢失
症状：新的对话里 AI 把之前定的规则全忘了，写出风格完全不同的代码。
对策：
• 把 Skills 写成文件，每次对话自动加载 • 用 AGENTS.md 作为项目级别的全局指令 • 关键决策写进项目README，而非只留在对话里
陷阱 3：过度依赖 AI 的判断
症状：AI 说"我建议用 xxx 方案"就直接采纳，不做独立思考。
对策：AI 的建议是输入，不是决策。所有涉及架构、安全、成本的决策，必须人来拍板。
陷阱 4：验证缺失
症状：AI 说"已完成"你就信了，上线后发现一堆问题。
对策：
• 每个 Phase 结束后必须运行自动化验证 • 关键功能要用浏览器/模拟器实际走查 • 不看 AI 的自我报告，只看客观的测试结果
陷阱 5：一步到位心态
症状：想让 AI 一次性把所有功能完美实现。
对策：接受迭代。第一轮先跑通主流程，第二轮处理边界场景，第三轮打磨细节。每一轮都验收后再进入下一轮。
工具链推荐
写在最后
让 AI 体系化地完成项目，本质上就是把你脑子里的项目管理经验，翻译成 AI 能理解和遵守的规则。
你不需要教 AI 怎么写代码——它写代码的能力已经足够强了。你需要教它：
1. 做什么 — 清晰的 PRD 和架构决策 2. 怎么做 — 详尽的 Skills 和编码规范 3. 做到什么程度 — 明确的验收标准和质量门禁
一旦这三件事到位，AI 就不再是一个需要你盯着的"代码生成器"，而是一个能在轨道上自主运行的"开发团队"。
从混乱到体系的距离，不是更好的模型，而是更好的管理。
好了，本期的内容到这里就结束了，如果你觉得对你有帮助的话，欢迎点赞、在看、转发。Bye~
