先把接口规则定清楚，再让 AI 写代码。 在 AI 辅助开发中，接口设计是一个非常容易“看起来能用，最后越来越乱”的地方。 让 AI 帮你写几个接口，它可能很快就生成： /getUser /createUser /update_user /delete-user /userList 功能都能跑。但项目继续发展，就很容易出现： 同一个资源，不同命名 同一个动作，不同 HTTP 方法 同一种错误，不同返回结构 同一个分页，不同字段名称 最后前端、后端、测试人员，甚至 AI 自己都开始猜： “这个接口到底应该怎么调用？” 这时候真正缺少的，并不是代码能力，而是： 统一的接口契约。 ...
在 AI 辅助编程越来越普遍之后，一个很容易被忽略的问题正在出现： AI 很会写日志，但不一定会写“有用的日志”。 让 AI 实现一个功能，它很可能顺手生成： logger.info("start") logger.info("processing...") logger.info("data loaded") logger.error("failed") 单独看似乎没有问题，但项目越来越大之后，你会发现日志开始变成这样： start processing... loading data... done request failed retry... success 真正出了故障，却很难回答几个最基本的问题： 哪个请求出的错？ 哪个模块出的错？ 哪一步出的错？ … 问题并不是“日志太少”，而往往是： 日志很多，但没有体系。 因此，和异常处理、依赖注入、接口规范一样，日志也应该成为项目架构的一部分，而不是让开发者或者 AI 自由发挥。 ...
AI 写代码时，非常喜欢一种“最快能跑”的方式,，例如： db = Database() cache = RedisCache() mailer = EmailService() service = UserService() 哪里需要，就在哪里创建。 短期看很方便，但当项目越来越大以后，就会出现： 数据库实例到处创建 缓存客户端到处创建 配置散落 Service 互相 new 测试时无法替换依赖 这类代码最明显的问题是： 对象把自己的依赖写死了。 而 DI（Dependency Injection，依赖注入） 要解决的，就是这件事。 ...
AI 很擅长快速写接口，比如你告诉它： “增加一个创建用户接口。” 它很可能几分钟就能给出一段能运行的代码，但如果项目里没有统一规范，不同接口很快就会变成这样： { "success": true } 另一个接口返回： { "code": 0, "msg": "ok", "result": {} } 再一个接口出错时直接返回： { "error": "user not found" } 甚至有些地方直接把数据库异常抛给前端。单个接口都“能跑”，整个系统却越来越难维护。 所以，AI 编程里有一类非常重要、却经常被忽略的基础架构： 统一返回值 + 全局异常处理 + 统一参数校验。 它们的作用，就是提前规定： 成功怎么返回，失败怎么返回，非法输入在哪里拦截。 ...
AI 写代码有一个很常见的问题： 它知道功能应该怎么实现，却不一定知道代码应该放在哪里。 比如你告诉 AI： “增加一个删除 Agent 的功能。” 如果没有清晰的工程结构，它可能直接在 API 接口里：查数据库、判断业务规则、清理缓存 … 功能可能很快就跑起来了。但随着 AI 一次次这样写，项目最终会变成： API 里有业务逻辑 Service 里也有数据库操作 Repository 里又夹着业务判断 工具类到处被引用 这时候，我们就需要另一种非常基础、却极其重要的架构思想： 分层。 ...
AI 写一个功能，通常并不难，真正难的是： 当 AI 连续写几十个、几百个功能以后，代码还能不能保持清晰？ 很多项目一开始结构还不错，用户功能放一点，权限功能放一点，订单功能放一点，日志功能放一点。 随着需求越来越多，不同模块开始互相调用、互相引用、互相修改，最后可能变成这样： user.py ↓ permission.py ↓ agent.py ↓ tool.py ↓ knowledge_base.py ↓ conversation.py ↘ 又调用 user.py 文件很多，代码也不少，但谁负责什么，已经越来越说不清。 软件架构里有一个非常形象的名字： 大泥球（Big Ball of Mud） 而领域驱动设计，也就是我们经常听到的 DDD，其中一个非常重要的作用，就是在系统开始变乱之前，先把边界划清楚。 对于 AI 编程来说，这个作用尤其重要。 ...
AI 很会写代码。但如果没有明确的架构边界，它也很容易出现一个问题： 哪里写起来方便，就把代码写到哪里。 本应由后端负责的业务规则，可能被塞进 Vue 页面；本应统一封装的接口调用，可能散落在各个组件里；前端甚至可能根据页面需求，自己“发明”一套与后端不一致的数据结构。 代码可能能运行，但项目会逐渐失去边界。 而前后端分离，就是给 AI 划下的第一条重要边界。 ...
上一篇我们讨论了一个核心原则： 先定义边界和规则，再让 AI 在边界内发挥能力。 那么问题来了： 这些架构规则，怎样才能真正交给 AI？ 答案就是本文的主题——Project Rules（项目规则）。 ...
随着 GPT、Claude、Gemini、Qwen 等大模型的发展，软件开发正在进入一个新的时代。 过去需要数小时甚至数天完成的编码工作，如今 AI 几分钟便可以完成。 然而，很多团队却发现了一个令人困惑的现象： 代码越写越多，项目却崩溃得越来越快。 原因并不是 AI 不够聪明，而是： 缺少架构约束。 现代 AI Agent 能够相对稳定地运行，一个重要原因就是：不会让大模型毫无约束地自由发挥。 成熟的 Agent 系统通常会通过 系统提示词、权限控制、工作流、状态管理和结果校验等机制，为大模型划定明确的行为边界。 从本质上说，这与软件架构的思想高度一致： 先定义边界和规则，再让 AI 在边界内发挥能力。 即使能力很强的大模型，在缺乏明确约束、上下文持续膨胀或工具权限过大的情况下，也可能逐渐出现格式漂移、职责越界、错误调用工具或代码风格不一致等问题。 ...
架构筑基：驾驭 AI 编程的底层方法论 内容提要 当 GPT、Claude、Gemini 等大模型让"几分钟写出可用代码"成为现实，一个新的困境却悄然蔓延——代码越写越多，项目却崩溃得越来越快。 问题不在 AI 的能力，而在缺少架构约束。AI 是世界上最快的施工队，但如果没有施工图纸，它大概率只会把砖越堆越高。好架构会被 AI 复制，坏架构同样会被放大——几十次迭代之后，原本清晰的工程就可能沦为成千上万行难以维护的"大泥球"代码。 本书正是一部为 AI 编程时代量身定制的架构实战指南。作者从真实企业级项目（开源框架 miniagent）的工程实践中提炼经验，不堆砌空洞理论，而是将软件架构的经典理念——前后端分离、领域驱动设计、分层整洁架构、依赖注入、面向切面编程、统一鉴权、多级缓存、异步并发、流式推送、插件化扩展——逐一转化为 AI 能读懂、可执行的项目规则与提示词模板。每章遵循统一节奏：通俗比喻引入概念 → 架构规范拆解 → 收益分析 → AI 失控现场还原 → 提示词落地 → 正面代码产出，让读者不仅知其然，更能直接照着做。 不同于传统架构书籍面向资深工程师的厚重论述，本书刻意面向更广泛的读者：中新手开发者、技术管理者、正在尝试用 AI 编程的跨界开发者。全程以生活化的比喻替代晦涩术语，用"反面教材 + 正面产出"的对照讲透每一个知识点。读完本书，您将完成一次身份跃迁——从亲手砌砖的"码农"，升级为给 AI 立规矩、搭骨架、做审查的"系统指挥官"。 AI 提升开发速度，架构决定软件能走多远。 目录 导论篇：为什么 AI 时代更需要架构 第一章 总序：为什么越依赖 AI 写代码，越不能丢掉架构设计？ 1.1 一个令人困惑的现象：代码越多，项目越脆弱 1.2 AI 的三大天然缺陷：近视眼、坏结构复制、安全盲区 1.3 从"砌砖工"到"施工总指挥"：人类工程师的新角色 1.4 实战对比：无约束自由发挥 vs 架构约束下的代码质量 1.5 人类与 AI 的新分工：谁负责宏观决策，谁负责微观实现 第二章 架构图纸 Prompt 化：如何用 Context / Rule 约束 AI 的编码边界 ...