[{"data":1,"prerenderedAt":61},["ShallowReactive",2],{"article-detail":3,"article-related-pool":19},{"category":4,"content":5,"cover_image":6,"create_dept":7,"create_time":8,"create_user":7,"created_at":8,"id":9,"is_pinned":10,"published_at":11,"slug":12,"sort_order":13,"status":14,"summary":15,"tags":16,"title":17,"updated_at":18,"view_count":13},"tech","\u003Ch2>引言\u003C\u002Fh2>\u003Cp>2026 年，低代码平台已经进入 AI 原生时代。传统的拖拽式表单已经不再是卖点——AI 驱动的模型生成、智能表单填充、自然语言查询正在成为标配。但市场上数十款低代码平台，如何选择适合自己企业的那一款？\u003C\u002Fp>\u003Ch2>评估维度一：AI 能力深度\u003C\u002Fh2>\u003Cp>不是所有所谓AI低代码都是真正的AI原生。关键区分点：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>Level 1 - AI 辅助开发\u003C\u002Fstrong>：AI 帮你写代码片段、生成 SQL。本质还是写代码。\u003C\u002Fli>\u003Cli>\u003Cstrong>Level 2 - AI 驱动配置\u003C\u002Fstrong>：描述业务需求，AI 自动生成数据模型和页面配置。非研发人员可以参与。\u003C\u002Fli>\u003Cli>\u003Cstrong>Level 3 - AI Agent 自治\u003C\u002Fstrong>：AI 不仅能生成，还能根据运行时数据自动优化模型、推荐改进方案。这是我们衍数平台的目标。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>评估维度二：数据安全与私有化\u003C\u002Fh2>\u003Cp>如果你的业务数据不能离开企业内网，SaaS 模式直接排除。需要确认：\u003C\u002Fp>\u003Cul>\u003Cli>是否支持完全私有化部署（不只是混合云）\u003C\u002Fli>\u003Cli>LLM 推理是否可以本地化（Ollama \u002F vLLM），还是强依赖云端 API\u003C\u002Fli>\u003Cli>数据库是否可以使用企业已有的 PostgreSQL \u002F MySQL 实例\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>评估维度三：扩展性\u003C\u002Fh2>\u003Cp>低代码平台最大的风险是能快速上手但遇到复杂需求就被卡住。确保平台提供代码级别的逃生舱：自定义后端逻辑（Go\u002FJava Hook）、自定义前端组件（Vue\u002FReact 组件嵌入）、自定义 API 集成。\u003C\u002Fp>\u003Ch2>总结\u003C\u002Fh2>\u003Cp>选择低代码平台不是选功能最多的，而是选最匹配你的团队能力和业务阶段的。如果你有研发团队，优先考虑可扩展、可私有化的方案；如果团队以业务人员为主，SaaS 模式的一站式方案更合适。\u003C\u002Fp>","\u002Fimages\u002Fbrand\u002Fcover-tech.webp","","2026-07-16T10:32:31+08:00","1217a079-6c7b-42d1-b3cb-065e348a0bde",1,null,"ai-lowcode-platform-guide",0,"published","如何选择适合企业的低代码平台？从 AI 能力、数据安全、扩展性和部署方案四个维度全面对比。","[\"AI\", \"低代码\", \"平台选型\"]","AI 低代码平台选型指南：从 LLM 集成到私有化部署","2026-07-17T09:33:56+08:00",[20,21,28,35,46,54],{"category":4,"content":5,"cover_image":6,"create_dept":7,"create_time":8,"create_user":7,"created_at":8,"id":9,"is_pinned":10,"published_at":11,"slug":12,"sort_order":13,"status":14,"summary":15,"tags":16,"title":17,"updated_at":18,"view_count":13},{"category":4,"content":22,"cover_image":6,"create_dept":7,"create_time":8,"create_user":7,"created_at":8,"id":23,"is_pinned":13,"published_at":11,"slug":24,"sort_order":13,"status":14,"summary":25,"tags":26,"title":27,"updated_at":18,"view_count":13},"\u003Ch2>引言\u003C\u002Fh2>\u003Cp>2026 年，大语言模型已经从炫技走向实用。但要构建一个真正可用的企业级 LLM 应用，远不止调用 API 那么简单。本文从实践角度梳理 LLM 应用开发的核心概念。\u003C\u002Fp>\u003Ch2>第一层：Prompt Engineering\u003C\u002Fh2>\u003Cp>最基础的 LLM 应用就是写一个好的 Prompt。但好的 Prompt 不是一次写成的——需要像写代码一样迭代测试。核心技巧：明确角色、提供示例（Few-shot）、结构化输出要求（JSON Schema）。\u003C\u002Fp>\u003Ch2>第二层：RAG（检索增强生成）\u003C\u002Fh2>\u003Cp>Prompt 能解决的问题有限——模型的知识截止于训练日期，无法回答关于你的私有文档的问题。RAG 通过在生成前检索相关文档片段，让模型看到它原本不知道的信息。\u003C\u002Fp>\u003Cp>一个生产级 RAG 系统至少需要：文档解析 → 文本分割 → 向量化 → 向量存储 → 检索 → 重排序 → 生成。每个环节都有坑。\u003C\u002Fp>\u003Ch2>第三层：AI Agent\u003C\u002Fh2>\u003Cp>Agent 是 LLM 应用的终极形态——模型不再是回答问题，而是能自主规划、调用工具、执行多步任务。但 Agent 也是最难做好的——自主性越高，不可控性越强。\u003C\u002Fp>\u003Ch2>总结\u003C\u002Fh2>\u003Cp>不要一上来就做 Agent。先做好 Prompt，再引入 RAG，最后考虑 Agent。80% 的企业场景，RAG 就够了。\u003C\u002Fp>","39005d54-307b-4834-b21d-1c9ec129fbef","llm-app-development","从 API 调用到构建企业级 LLM 应用，理解 Prompt Engineering、RAG 和 AI Agent 的核心概念与实践。","[\"LLM\", \"RAG\", \"AI Agent\"]","大语言模型应用开发入门：从 Prompt 到 Agent",{"category":4,"content":29,"cover_image":6,"create_dept":7,"create_time":8,"create_user":7,"created_at":8,"id":30,"is_pinned":13,"published_at":11,"slug":31,"sort_order":13,"status":14,"summary":32,"tags":33,"title":34,"updated_at":18,"view_count":13},"\u003Ch2>引言\u003C\u002Fh2>\u003Cp>组件是 Vue 应用的基本单元。一个好的组件设计能让项目维护成本降低 50% 以上。本文以一个搜索框+表格+分页的组合组件为例，分享我们的组件设计方法论。\u003C\u002Fp>\u003Ch2>原则一：Props 是组件的 API\u003C\u002Fh2>\u003Cp>Props 是组件的公共接口，设计 Props 本质上是在设计 API。好 API 的标准：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>向下传递数据，向上传递事件\u003C\u002Fstrong>——组件不应该通过 Props 接收回调函数，使用 Emits 代替。\u003C\u002Fli>\u003Cli>\u003Cstrong>提供合理的默认值\u003C\u002Fstrong>——让组件在最常见的场景下零配置即可使用。\u003C\u002Fli>\u003Cli>\u003Cstrong>使用 TypeScript 类型\u003C\u002Fstrong>——\u003Ccode>defineProps<{...}>()\u003C\u002Fcode> 而不是运行时校验，编译时就能发现错误。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>原则二：组合优于继承\u003C\u002Fh2>\u003Cp>Vue 3 的 Composition API 天然支持组合模式。不要试图设计一个万能组件，而是设计一组职责单一的小组件，通过插槽和 provide\u002Finject 组合。\u003C\u002Fp>\u003Ch2>原则三：插槽是扩展的钥匙\u003C\u002Fh2>\u003Cp>任何可能需要自定义渲染的地方都应该提供插槽。我们的 \u003Ccode>GenericCrud\u003C\u002Fcode> 组件通过 10+ 个具名插槽，在保持 80% 场景零配置的同时，允许 20% 的复杂场景完全自定义。\u003C\u002Fp>\u003Ch2>总结\u003C\u002Fh2>\u003Cp>好的组件设计是第一眼简单，深入后强大。花 30 分钟设计 Props 和插槽，比花 3 小时重构一个设计糟糕的组件更值得。\u003C\u002Fp>","baab5398-26ea-4847-9560-a9af5ff40410","vue3-component-design","设计一个好的 Vue 3 组件不只是写 template。从 Props 设计、Emits 定义到插槽布局，完整的设计思路。","[\"Vue 3\", \"前端\", \"组件设计\"]","Vue 3 组件设计实战：从 API 到模板的完整思考",{"category":36,"content":37,"cover_image":38,"create_dept":7,"create_time":39,"create_user":7,"created_at":39,"id":40,"is_pinned":10,"published_at":41,"slug":42,"sort_order":13,"status":14,"summary":43,"tags":44,"title":45,"updated_at":18,"view_count":13},"industry","\u003Ch2>引言\u003C\u002Fh2>\u003Cp>数字化转型不是一次性项目，而是一个持续演进的过程。根据我们服务 50+ 企业的经验，成功的数字化转型通常经历三个阶段。每个阶段有不同的核心任务和典型陷阱。\u003C\u002Fp>\u003Ch2>阶段一：信息化——把数据从纸质搬到数字世界\u003C\u002Fh2>\u003Cp>这是最基础但最关键的一步。很多企业以为上了 OA、买了财务软件就是完成了信息化，但实际上各系统数据不互通，仍是信息孤岛。\u003C\u002Fp>\u003Cp>\u003Cstrong>核心任务：\u003C\u002Fstrong>建立统一的数据标准和主数据管理体系。至少确保客户、产品、员工三个核心实体在各系统中口径一致。\u003C\u002Fp>\u003Ch2>阶段二：数字化——让数据流动起来\u003C\u002Fh2>\u003Cp>信息化的数据是死的——在各个系统里躺着。数字化的核心是让数据在不同系统、不同部门之间流动，驱动业务流程自动化。\u003C\u002Fp>\u003Cp>\u003Cstrong>核心任务：\u003C\u002Fstrong>构建企业级数据中台或集成平台，打通 ERP、CRM、MES、WMS 等核心系统。重点是 API 治理和数据血缘。\u003C\u002Fp>\u003Ch2>阶段三：智能化——让 AI 参与决策\u003C\u002Fh2>\u003Cp>有了高质量的数据和流畅的数据管道，AI 才能真正发挥价值。这不是买一个 AI 产品能解决的——需要企业的数据基础设施已经就绪。\u003C\u002Fp>\u003Cp>\u003Cstrong>核心任务：\u003C\u002Fstrong>识别高价值的 AI 应用场景，建立数据到模型的持续迭代闭环。\u003C\u002Fp>\u003Ch2>总结\u003C\u002Fh2>\u003Cp>三个阶段不能跳跃。没有高质量数据基础的 AI 项目，90% 都会失败。建议企业先完成信息化和数字化的基础工作，再考虑 AI 应用。\u003C\u002Fp>","\u002Fimages\u002Fbrand\u002Fcover-industry.webp","2026-07-16T10:19:32+08:00","929d4109-40a3-4be2-a788-ce0090b30ef3","2026-07-16T10:00:00+08:00","digital-transformation-stages","从信息化到数字化再到智能化，企业数字化转型的正确路径和每个阶段的核心挑战。","[\"数字化转型\", \"企业管理\"]","企业数字化转型的三个关键阶段",{"category":4,"content":47,"cover_image":6,"create_dept":7,"create_time":48,"create_user":7,"created_at":48,"id":49,"is_pinned":13,"published_at":41,"slug":50,"sort_order":13,"status":14,"summary":51,"tags":52,"title":53,"updated_at":18,"view_count":13},"\u003Ch2>背景\u003C\u002Fh2>\u003Cp>我们的低代码平台最初使用 MySQL 8.0 作为默认数据库。随着平台能力增长——特别是 JSON Schema 存储、全文检索、复杂分析查询的需求——MySQL 的局限性越来越明显。\u003C\u002Fp>\u003Ch2>为什么选择 PostgreSQL\u003C\u002Fh2>\u003Cul>\u003Cli>\u003Cstrong>JSONB 支持\u003C\u002Fstrong>——MySQL 的 JSON 类型本质是 TEXT 的语法糖，不支持索引。PostgreSQL 的 JSONB 支持 GIN 索引，查询性能提升 10-50 倍。\u003C\u002Fli>\u003Cli>\u003Cstrong>全文检索\u003C\u002Fstrong>——pg_trgm + tsvector，无需额外部署 Elasticsearch。\u003C\u002Fli>\u003Cli>\u003Cstrong>窗口函数与分析查询\u003C\u002Fstrong>——PostgreSQL 的分析函数比 MySQL 8.0 更丰富、更稳定。\u003C\u002Fli>\u003Cli>\u003Cstrong>扩展生态\u003C\u002Fstrong>——PostGIS（地理）、pgvector（向量检索）、TimescaleDB（时序）——一个数据库解决所有场景。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>迁移遇到的坑\u003C\u002Fh2>\u003Cp>\u003Cstrong>1. 自增 ID 转 UUID\u003C\u002Fstrong>——迁移后所有 API 的 ID 类型从 int 变成 UUID 字符串，前端需要全局修改。\u003C\u002Fp>\u003Cp>\u003Cstrong>2. datetime 精度差异\u003C\u002Fstrong>——MySQL 的 datetime 精确到秒，PostgreSQL 的 timestamptz 精确到微秒。创建时间排序时行为不同。\u003C\u002Fp>\u003Cp>\u003Cstrong>3. 保留字差异\u003C\u002Fstrong>——MySQL 和 PostgreSQL 的保留字集合不同，部分字段名需要加引号。\u003C\u002Fp>\u003Ch2>结论\u003C\u002Fh2>\u003Cp>迁移成本不低，但对于需要存储 JSON 数据和复杂查询的平台型产品，PostgreSQL 是更优选择。\u003C\u002Fp>","2026-07-16T10:18:58+08:00","33cd9df3-334b-4d20-9511-fcb714ecd1de","mysql-to-postgresql-migration","为什么我们从 MySQL 迁移到 PostgreSQL？迁移过程中的 5 个坑和最终的性能对比数据。","[\"数据库\", \"PostgreSQL\", \"MySQL\", \"迁移\"]","MySQL 到 PostgreSQL 迁移实战：一个低代码平台的数据库演进",{"category":4,"content":55,"cover_image":6,"create_dept":7,"create_time":48,"create_user":7,"created_at":48,"id":56,"is_pinned":10,"published_at":41,"slug":57,"sort_order":13,"status":14,"summary":58,"tags":59,"title":60,"updated_at":18,"view_count":13},"\u003Ch2>引言\u003C\u002Fh2>\u003Cp>Go 语言以高性能著称，但在微服务场景下，不合理的配置和用法仍然会导致严重的性能问题。本文总结了我们在交付 20+ 微服务项目过程中反复遇到的 5 个性能瓶颈，以及经过生产验证的优化方案。\u003C\u002Fp>\u003Ch2>1. 数据库连接池配置\u003C\u002Fh2>\u003Cp>大多数 Go 项目使用 \u003Ccode>database\u002Fsql\u003C\u002Fcode> 的连接池，默认配置非常保守：\u003Ccode>MaxOpenConns: 0\u003C\u002Fcode>（无限制）和 \u003Ccode>MaxIdleConns: 2\u003C\u002Fcode>。在高并发场景下，无限制的连接数会导致数据库压力过大，而空闲连接太少又会导致频繁建立新连接。\u003C\u002Fp>\u003Cp>\u003Cstrong>优化方案：\u003C\u002Fstrong>根据压测结果合理设置。我们的经验公式是：\u003Ccode>MaxOpenConns = CPU 核心数 * 2\u003C\u002Fcode>，\u003Ccode>MaxIdleConns = MaxOpenConns \u002F 2\u003C\u002Fcode>。同时设置 \u003Ccode>ConnMaxLifetime\u003C\u002Fcode> 为 5 分钟，避免长连接被数据库侧断开。\u003C\u002Fp>\u003Ch2>2. GC 调优\u003C\u002Fh2>\u003Cp>Go 的 GC 在 1.19+ 版本已经非常优秀，但在内存分配密集的微服务中，频繁的 GC 仍可能导致 P99 延迟飙升。\u003C\u002Fp>\u003Cp>\u003Cstrong>优化方案：\u003C\u002Fstrong>使用 \u003Ccode>sync.Pool\u003C\u002Fcode> 复用高频分配的对象；通过 \u003Ccode>GOGC=200\u003C\u002Fcode> 调高 GC 触发阈值（默认 100），在内存充裕的场景下可以减少 GC 频率 40%。\u003C\u002Fp>\u003Ch2>3. HTTP Client 复用\u003C\u002Fh2>\u003Cp>每个微服务都需要调用其他服务。最常见的错误是为每个请求创建新的 \u003Ccode>http.Client\u003C\u002Fcode>，导致连接无法复用。\u003C\u002Fp>\u003Cp>\u003Cstrong>优化方案：\u003C\u002Fstrong>全局复用一个 \u003Ccode>http.Client\u003C\u002Fcode> 实例，设置合理的超时（Dial Timeout 3s, Response Header Timeout 10s）。在 Kubernetes 环境中，将 \u003Ccode>MaxIdleConnsPerHost\u003C\u002Fcode> 设置为目标服务的 Pod 数量。\u003C\u002Fp>\u003Ch2>4. JSON 序列化优化\u003C\u002Fh2>\u003Cp>标准库 \u003Ccode>encoding\u002Fjson\u003C\u002Fcode> 使用反射，性能一般。对于高频调用的 API 网关或消息处理服务，JSON 序列化可能成为瓶颈。\u003C\u002Fp>\u003Cp>\u003Cstrong>优化方案：\u003C\u002Fstrong>使用 \u003Ccode>github.com\u002Fbytedance\u002Fsonic\u003C\u002Fcode> 替代标准库，实测序列化性能提升 3-5 倍。但注意 sonic 需要 amd64 + Linux 环境才能充分发挥性能。\u003C\u002Fp>\u003Ch2>5. Goroutine 泄漏排查\u003C\u002Fh2>\u003Cp>Goroutine 泄漏是最隐蔽的性能问题——程序不会崩溃，但内存和 CPU 会缓慢增长。我们在一个运行 3 个月的服务中发现 50 万+ 泄漏的 goroutine。\u003C\u002Fp>\u003Cp>\u003Cstrong>排查工具：\u003C\u002Fstrong>使用 \u003Ccode>pprof.Lookup(\"goroutine\").WriteTo()\u003C\u002Fcode> 定期输出 goroutine 栈，对比分析增长趋势。常见泄漏场景：channel 发送端未关闭且无接收者、HTTP 请求未设置超时、\u003Ccode>context.Context\u003C\u002Fcode> 未正确传递取消信号。\u003C\u002Fp>\u003Ch2>总结\u003C\u002Fh2>\u003Cp>性能优化不是一蹴而就的——关键是在上线前建立性能基线，通过持续压测和监控发现问题、验证改进效果。\u003C\u002Fp>","44689c0a-6094-45e6-8adf-152a7d343c97","go-microservice-perf","从连接池配置到 GC 调优，5 个经过生产验证的 Go 微服务性能优化技巧，附真实案例数据。","[\"Go\", \"微服务\", \"性能优化\"]","Go 微服务性能优化的 5 个实战技巧",1785746739056]