AI编程企业级实战上一节第2节规范驱动开发SDD让AI永远在轨道上本节第3节动第一行代码前你应该想清楚什么下一节待更新做一个简版 Dify名字叫 Hify。这句话听起来很具体其实非常模糊。Dify 有几十个功能模块你到底做哪些不做哪些面向谁用部署在哪里扛多大的量技术怎么选运维怎么做这些问题如果不想清楚就开始写代码后面通常只会出现两种结果要么越做越多范围膨胀到收不住。要么做到一半才发现方向不对只能推倒重来。用 Claude Code 开发这个问题会更明显。你说一句“帮我做个 Agent 管理”它可能顺手把权限体系、版本控制、审计日志都给你补上因为这些在 Dify 里本来就存在。你没定边界它就会替你定边界。所以这一节要解决的不是“怎么写第一段代码”而是在动第一行代码之前先把产品边界、技术选型、运维预期想清楚并写进 CLAUDE.md。还有一个很重要的提醒产品定义阶段一样可以用 AI。不是只有写代码的时候Claude Code 才有用。下面这篇文章我就按真实过程带你看一遍我是怎么让 Claude Code 参与前期决策的。一、先搞清楚业界标杆到底在做什么做任何项目第一步都不是急着想“我要做什么”。而是先看这个领域里最成熟的产品到底在做什么。这不是为了照抄而是为了先建立全貌感。你连全貌都没有就很难判断哪些功能是核心能力哪些功能只是增强项哪些功能根本不适合你当前阶段我们这次选的标杆是 Dify。但 Dify 的功能很多自己一点点翻官网和文档效率并不高。这个时候Claude Code 很适合拿来做第一轮信息整理。我给它的提示词很简单帮我梳理 Difyhttps://dify.ai这个产品的核心功能模块按类别分组每个模块用一两句话说明它做什么。它最后给出的结论我没有原样贴进文章而是把关键信息收成了下面这张图和这几个类别应用构建知识库与 RAG模型与 AI 能力接入工具、插件与外部集成Agent 能力发布与交付监控、日志与优化工作区与团队管理部署方式这一步的意义不是“让 AI 帮你记笔记”。而是让你先对这个赛道形成一个完整地图。只有地图先出来了后面你才知道哪些该拿哪些该放。二、从 Dify 到 Hify先做减法再谈开发接下来真正重要的事情不是“功能越多越好”而是做取舍。我的约束非常明确一个人开发面向团队内部 20-50 人使用本地部署在这样的前提下Hify 不可能做成另一个 Dify。所以我继续让 Claude Code 参与判断但我问的不是“应该做什么”而是约束条件一个人开发面向团队内部 20-50 人使用本地部署。请从刚才梳理的功能列表中帮我判断哪些是必须做的核心功能哪些可以砍掉给出每个的理由。它给我的分析里有一个判断让我重新思考了自己的方案知识库 RAG 不能直接砍掉。我原本是想先不做的因为这条链路更长一个人做起来周期也更长。但 Claude Code 提醒我“接入私有文档这是团队选择 Hify而不是直接用 ChatGPT 的主要理由。”这句话点醒了我。如果 Hify 只能做通用对话那团队直接用 ChatGPT 就够了。真正的差异化价值不在“能不能聊天”而在“能不能接入团队自己的知识”。所以这个功能最后我保留了但做了降级一期只支持 TXT分块先用最简单的固定长度策略工作流也是一样的处理方式。不做可视化拖拽不做复杂编排只保留最小可用能力JSON 配置线性流程条件分支先覆盖最常见的“问题分类后走不同路径”这种场景就够了。当然也不是 AI 给的建议都要照单全收。比如它建议我做一个最小权限体系分管理员和普通用户。但我最后没有采纳。原因很简单内部 50 人以内的小团队大家彼此认识很多事情完全可以在系统外约定不值得为了这个能力让每个模块都多一层权限逻辑。这也是一个很重要的边界感Claude Code 可以帮你拓宽思路但最终取舍必须由你拍板。三、我总结了一套“三问裁剪法”经过这一轮取舍之后我把自己的判断方法收成了一个简单模型后面几乎每个功能都可以这么判断。第一问没有它产品还成立吗这一步是为了区分核心能力和边缘能力。对 Hify 来说下面这些属于核心能力模型管理Agent 配置对话引擎MCP 工具接入管理控制台这几块少任何一块Hify 都不成立。而知识库和工作流砍掉以后产品还能跑但价值会明显下降所以适合降级做而不是彻底不做。至于这些功能可以直接后置可视化拖拽编排多租户插件市场计费系统它们对当前核心链路没有决定性影响。第二问做到什么程度才算够用这一步是为了防止“核心功能必须做满”这种误区。很多时候核心功能确实要做但完全没必要一步做到最完整。例如模型管理先做 CRUD 连通性测试Agent 配置先做选模型、绑工具、设系统提示词对话引擎先做流式输出 多轮对话知识库先做 TXT 固定长度分块工作流先做 JSON 配置不做拖拽管理控制台先做到能用不追求精美一句话总结核心能力要有但实现深度必须服从你的资源约束。第三问能不能一句话把产品说清楚如果一个产品你没法一句话说明白通常说明你的边界还没有收干净。最后我给 Hify 的定义是Hify 是一个可本地部署的 AI Agent 开发平台支持多模型管理、Agent 配置、知识库 RAG、简版工作流、对话交互和MCP工具接入面向团队内部小规模使用。如果一句话说不清那说明你还没真正想明白。四、技术选型不是选最好的是选最匹配的功能边界定下来以后下一步才轮到技术选型。我仍然让 Claude Code 先做第一轮方案比较。我问它Hify 是一个 AI Agent 平台一个人开发本地部署目标 20-50 人使用。帮我对比以下技术方案的优劣1Spring Boot Vue 2Go React3Python FastAPI React。重点考虑开发效率、生态成熟度、AI 领域 SDK 支持、运维复杂度。它的结论是如果追求 AI 生态和开发效率FastAPI React 更占优势。这个判断本身没有问题但我最后还是选了Spring Boot Vue理由就三个而且都很现实。1. 我最熟这个栈一个人开发时效率不是看“理论最快”而是看“你自己最快”。最熟的技术栈通常才是交付效率最高的技术栈。2. Java 侧 AI SDK 已经够用了OpenAI、Claude 这些模型都已经有可用的 Java SDK。RAG 里最关键的向量化、召回、模型调用也可以通过 API 方式接起来。我现在做的是一个内部小规模平台不是要搭一个 AI 框架生态。所以“够用”比“最丰富”更重要。3. 一个人维护一套技术栈更稳如果后端主栈是 Java却又为了 AI 能力单独拆一套 Python 服务短期看似灵活长期维护成本其实更高。一个人开发时技术栈统一本身就是一种巨大的工程优势。所以技术选型的关键不是“哪种技术更先进”而是哪种方案最符合你当前的目标、经验和维护能力。最终我定下来的技术栈是后端Spring Boot 3.x MyBatis-Plus MySQL 8.x Redis 7.x前端Vue 3 TypeScript Element Plus容器化Docker Docker Compose五、功能能不能跑起来运维预期要提前想很多人做项目的时候只关心功能不关心运维。结果就是代码写完了服务一部署问题才开始出现。例如实际并发到底有多大SSE 长连接会不会把线程占满哪些数据必须持久化缓存到底值不值得做Nginx 要不要特殊配置这些问题如果等到上线前再想往往已经晚了。所以这一轮我先自己做一遍预估再让 Claude Code 帮我查漏补缺。我给它的提示词是Hify 是一个 AI Agent 平台Docker Compose 本地部署目标 20-50 人同时在线主要压力在对话接口流式 SSE。帮我估算 QPS、建议缓存策略、列出需要提前考虑的运维事项。它给出的结果里我最后保留了 4 个特别关键的判断。1. QPS 很低真正的瓶颈不是并发请求数50 人在线假设活跃率 60%每人每分钟发 2 条消息峰值也就大约 1 QPS。就算算上 RAG 检索、内部调用放大整体也大概在 3-5 QPS 这个量级。对于 Spring Boot 单实例来说这个压力并不大。真正要担心的不是 QPS而是LLM 一次响应要持续 3-30 秒这会长期占用连接。所以这不是“吞吐压力”而是“长连接管理压力”。2. SSE 长连接是唯一需要认真对待的压力点如果同时有 50 个 SSE 连接每个连接持续 10-30 秒那问题就不是“接口快不快”而是“连接能不能稳住”。这里有几个细节非常关键Spring Boot 里优先用 SseEmitter不要用普通阻塞式 ResponseBody 去硬顶流式输出设置超时例如 60 秒避免僵尸连接长期占用资源Nginx 必须关闭缓冲proxy_buffering off最后这一条特别容易被忽略。如果 Nginx 缓冲不关用户看到的就不是打字机效果而是等模型全部生成完以后一次性整段吐出来。3. 缓存策略要简单直接不要一上来就做重我最后的判断是模型提供商配置可以缓存Agent 配置可以缓存会话上下文可以做 Redis Cache-AsideLLM 最终回答不做缓存对话历史先直接读数据库原因很简单50 人规模下很多“看起来应该缓存”的东西其实缓存收益并不大反而会增加系统复杂度。4. 数据持久化不是细节而是底线下面这些数据必须挂载 volumeMySQL 数据目录向量库数据目录上传文档目录容器内不应该成为任何业务数据的最终存储位置。这件事看起来像常识但真到自己部署时很多人就是会漏。而一旦漏掉容器重启就可能直接丢数据。六、这些判断不需要绝对精确但必须提前存在这一步里最重要的不是算得有多准。而是你必须先做出判断。比如因为当前 QPS 并不高我就不会一开始把精力放在复杂缓存上。比如因为 SSE 才是主要压力点我会优先关注连接管理和代理配置。比如因为是本地部署我会特别强调 volume 挂载和 Compose 的部署稳定性。这些判断会反过来影响技术选型系统架构数据存储方式部署方案监控重点所以运维预期从来都不是“最后再想”的事情。它从项目开始的第一天就已经在影响你的设计决策了。七、最后把结论写进 CLAUDE.md所有前面的思考如果只停留在脑子里其实没有意义。因为你下一次继续开发Claude Code 不会自动记得。你自己隔几天回来看也未必还能完整复原当时的判断背景。所以最后一步是把这些结论沉淀成明确的项目上下文写进 CLAUDE.md。## 项目概述 Hify 是一个简版的 AI Agent 开发平台参考 Dify可本地部署 面向团队内部小规模使用20-50 人同时在线。 ### 做什么 - 多模型提供商管理OpenAI、Claude、Gemini、Ollama - Agent 创建与配置选模型、绑工具、设系统提示词 - 对话引擎流式响应、多轮对话、上下文管理 - 知识库 RAG一期只支持 TXT 文档固定长度分块 - 简版工作流JSON 配置线性 条件分支不做可视化拖拽 - MCP 工具接入Agent 可通过 MCP 协议调用外部工具 - 管理控制台模型管理、Agent 配置、对话界面 ### 不做什么 - 不做可视化工作流拖拽编排 - 不做多租户 / 权限体系 - 不做插件市场、计费系统 - 不做文本生成应用、WebApp 发布、嵌入组件 - 不做标注与微调 ### 技术栈 后端Spring Boot 3.x MyBatis-Plus MySQL 8.x Redis 7.x 前端Vue 3 TypeScript Vite Element Plus 容器化Docker Docker Compose ### 部署与运维预期 - Docker Compose 本地一键部署JVM 内存设上限-Xmx512m - 目标20-50 人同时在线峰值 3-5 QPS瓶颈在 LLM 长连接 - 缓存Redis Cache-Aside配置信息 会话上下文 - 监控起步 Actuator 日志后期 Prometheus GrafanaCLAUDE.md 不是写完就不动的文件。随着项目推进你对产品的理解会越来越深功能范围可能会调整技术决策也可能会变化。但不管怎么变有一点不会变所有关键判断都应该被明确写下来。总结在真正开始写代码之前我会先走完这 5 步调研标杆让 Claude Code 帮我快速梳理 Dify 的能力全景功能取舍用“三问裁剪法”判断哪些必须做、哪些该降级技术选型让 Claude Code 做方案比较再由我基于约束拍板运维预期提前估算负载、识别瓶颈、决定缓存和部署策略落成文字把最终结论写进 CLAUDE.md这 5 步做完之后你再去写第一行代码整个项目会稳很多。因为从那一刻起你写的就不再只是功能而是在执行一套已经想清楚的方案。