AI 编程思想
很多人用 AI 写代码越写越崩溃，本质是因为被 AI 牵着鼻子走，接受了一套自己完全不熟悉的复杂架构。AI 时代最高效的工程化流程，不是听 AI 吹嘘所谓的“最佳实践”，而是参考成熟架构与 AI 对齐思路，用你最顺手、最习惯的代码风格去约束 AI。本文分享一套“人主导、契约驱动”的极简 AI 工程化落地指南。
一、 AI 开发的核心认知：你才是“主架构师”
- 用 AI 辅助开发，最容易踩的坑就是： 给 AI 发了个需求，AI 吐出了一套极其晦涩、分层繁琐的代码（比如复杂的 DDD 或不必要的抽象）。代码虽然能跑，但你看着极度别扭。后续调试 Bug 或加新功能时，你发现自己根本改不动。
必须明确一个前提：AI 只是执行层，代码是你天天要看的，你才是最后接盘和维护的人。 让 AI 写代码的唯一标准，不是它有多“先进”，而是它符不符合你熟悉、顺手且认可的模式。
二、 人为主导的 9 步极简落地主线
- 我们遵循 “带着需求确定架构，带着架构设计模块，带着模块确定 UI” 的递进逻辑，把控制权死死抓在自己手里：
[1. 功能梳理]
回答什么：项目有哪些业务模块，每个模块大概做什么
产出物 ：功能梳理.md
边界 ：只写“有哪些模块、各做什么”，不写内部实现、不写技术选型[2. 确定项目全局框架]
回答什么：用什么框架、语言版本、部署方式、顶层目录
产出物 ：项目 agent.md
边界 ：只写全局技术与部署约束，不写单个模块的内部设计[3. 业务模块确定]
回答什么：单个模块负责什么、能做什么、内部怎么处理、内部架构
自身职责边界、模块专属技术设计、模块内部待确认事项
产出物 ：models/*.md
边界 ：只写本模块职责与内部设计，不写跨模块共同规则[4. 模块约束]
回答什么：两个或以上模块必须共同达成的结果、不得突破的业务红线
产出物 ：模块约束.md
边界 ：只写“跨模块共识与红线”，不重复单模块内部设计[5. 公共组件]
回答什么：多个模块都依赖的公共组件——公开 Interface、内部实现、
组件依赖、外部运行依赖
产出物 ：公共组件.md
边界 ：只写“被多个模块复用的部分”，不写单模块私有逻辑[6. UI]
回答什么：视觉方向、公共 UI 组件、页面状态面
产出物 ：UI设计文档.md
边界 ：通过设计最复杂的页面出三种 UI 图，用图定方向；
只写视觉与交互规范，不写业务规则[7. 数据库设计]
回答什么：根据已确认业务形成的表、字段、索引、关系、约束
产出物 ：数据库设计.md
边界 ：只写正式数据库设计，不堆一堆规范说明[8. 开发进度 Goal]
回答什么：完整项目开发的当前里程碑、状态、验证证据、
Git 提交、待外部验收事项
产出物 ：开发进度.md
边界 ：这是“做什么、做到哪里算完”的账本，
不保存业务需求，也不保存技术定义[9. 项目 agents]
回答什么：项目约束，以及各文档的职责和读取顺序
产出物 ：项目 agents.md
边界 ：只做“总约束 + 索引”，不重复前面文档的具体内容快速沟通需求，完善文档，快速根据goal跑一个版本，在从全局进行查看，根据业务细节在进行修改调整
版权所有
版权归属：念宇