第3节：动第一行代码前，你应该想清楚什么-编程实验室

AI编程企业级实战
上一节：第2节：规范驱动开发SDD，让AI永远在轨道上
本节：第3节：动第一行代码前，你应该想清楚什么
下一节：待更新

做一个简版 Dify，名字叫 Hify。

这句话听起来很具体，其实非常模糊。

Dify 有几十个功能模块，你到底做哪些，不做哪些？

面向谁用？部署在哪里？扛多大的量？

技术怎么选？运维怎么做？

这些问题如果不想清楚就开始写代码，后面通常只会出现两种结果：

要么越做越多，范围膨胀到收不住。
要么做到一半才发现方向不对，只能推倒重来。

用 Claude Code 开发，这个问题会更明显。

你说一句“帮我做个 Agent 管理”，它可能顺手把权限体系、版本控制、审计日志都给你补上，因为这些在 Dify 里本来就存在。你没定边界，它就会替你定边界。

所以这一节要解决的，不是“怎么写第一段代码”，而是：

在动第一行代码之前，先把产品边界、技术选型、运维预期想清楚，并写进 CLAUDE.md。

还有一个很重要的提醒：

产品定义阶段，一样可以用 AI。

不是只有写代码的时候，Claude Code 才有用。

下面这篇文章，我就按真实过程，带你看一遍我是怎么让 Claude Code 参与前期决策的。

一、先搞清楚业界标杆到底在做什么

做任何项目，第一步都不是急着想“我要做什么”。

而是先看：

这个领域里，最成熟的产品到底在做什么。

这不是为了照抄，而是为了先建立全貌感。

你连全貌都没有，就很难判断：

哪些功能是核心能力
哪些功能只是增强项
哪些功能根本不适合你当前阶段

我们这次选的标杆是 Dify。

但 Dify 的功能很多，自己一点点翻官网和文档，效率并不高。这个时候，Claude Code 很适合拿来做第一轮信息整理。

我给它的提示词很简单：

帮我梳理 Dify（https://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 人使用。帮我对比以下技术方案的优劣：1）Spring Boot + Vue 2）Go +React3）Python 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-Aside
LLM 最终回答不做缓存
对话历史先直接读数据库

原因很简单：

50 人规模下，很多“看起来应该缓存”的东西，其实缓存收益并不大，反而会增加系统复杂度。

4. 数据持久化不是细节，而是底线

下面这些数据必须挂载 volume：

容器内不应该成为任何业务数据的最终存储位置。

这件事看起来像常识，但真到自己部署时，很多人就是会漏。

而一旦漏掉，容器重启就可能直接丢数据。

六、这些判断不需要绝对精确，但必须提前存在

这一步里最重要的不是算得有多准。

而是你必须先做出判断。

比如因为当前 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 + Grafana

CLAUDE.md 不是写完就不动的文件。

随着项目推进，你对产品的理解会越来越深，功能范围可能会调整，技术决策也可能会变化。

但不管怎么变，有一点不会变：

所有关键判断，都应该被明确写下来。