首页 文章 精选 留言 我的

精选列表

搜索[CODING DevOps],共7261篇文章
优秀的个人博客,低调大师

快来一起 Coding 吧!

作者: Billmay表妹 原文来源:https://tidb.net/blog/cf364859 2023 TiDB Future App Hackathon 来啦!本届 Hackathon 的主题为:Code, Innovate & Build Amazing Data Applications —— 释放你的创造力、构建突破性的应用、在全球范围内寻找你的队友、体验最新最 in 的 Serverless 技术,更有总计$36k 奖金等你来拿! 本次大赛要求参赛者基于 TiDB Serverless 版本进行应用的开发,TiDB Serverless 专为规模化交易、实时分析和混合工作负载以及流量激增的应用程序而构建,可以自动扩缩容以满足实时需求。开发人员只需点击几下,就可以部署和配置一个具备完整功能的 Serverless TiDB 数据库。TiDB Cloud Serverless 与 MySQL 高度兼容,开发人员可以继续使用他们熟悉的 MySQL 开发框架和工具。 无论你对数据、人工智能、物联网、跨平台开发或任何软件工程的领域感兴趣,在 2023 TiDB Future App Hackathon 上,你都能充分发挥想象力、创造力,在 TiDB Serverless 上构建可扩展的、强大的、高性能的应用程序都将更加简单! 报名即日开启,接受这份来自 TiDB 的邀请,和我们一起在代码世界中创新,体验 Serverless 的魅力,打造专属你的 Data Application! 参赛福利 参赛即可获得 5GB 的 TiDB serverless 云资源,如若使用超过 5GB 还可以额外申请价值 $100 Credit(按照汇率价值 700+ 人民币) 初赛评审通过的 60 支队伍皆可获得 限量定制款 TiDB hackathon 礼包(收到过往届礼物的小伙伴们,每一届的新周边,都有新惊喜!) 技术专家在线答疑,有问题可以随时提问,再也不用自己苦苦烦恼遇到问题无法解决啦! 与全球顶尖开发者们组队、交流、探讨技术和项目。(顺便锻炼下自己的英文) 奖项设置 Award Category Award Prize Cash Count Total Top 7 1st Place $13,500 1 $13,500 2nd Place $7,500 1 $7,500 3rd Place $3,500 1 $3,500 4th-7th Place $1,500 4 $6,000 Special Award Verce 赞助: Best User Experience Award $1500 in usage credit to the Vercel platform 1 $1500 in usage credit to the Vercel platform Best AI Application Award $1,500 1 $1,500 Prize for Social Good $1,500 1 $1,500 Incentive Awards Top 5 Idea-makers with the most votes $100 5 $500 Top 5 Storytellers with the most votes $100 5 $500 一个团队可以同时获得三种奖项,一个人仅能参加一个团队 需要做什么呢? 在本次 Hackathon 中,你需要使用 TiDB serverless 和任何你喜欢的框架,来构建一个可运行的应用。我们对应用的形式和用途不作限制,充分发挥你的想象力吧! 一些可能的方向: 领域 描述 HTAP 处理大批量交易并同时对大数据或流数据进行分析查询的应用。 API & 集成 与流行的API集成以提供独特服务或功能的应用程序。 人工智能 利用 AI 能力的应用 一些可能可以实现的应用案例 Category Samples Hybrid Transactional/Analytical Processing * Personal health data tracking and personalized suggestions * Short link services with high-performance transactional processing and analytics * Real-time sports match analytics and predictions platform>* Smart parking solution with real-time space availability tracking *Real-time fraud detection in financial transactions * WEB 3 in HTAP: decentralized e-commerce marketplaces with secure transaction processing and real-time supply chain data analysis. API & Integration * Integrate with popular tools (Elasticsearch, Kafka, TensorFlow); * Integrate TiDB with different languages and frameworks. * Integrate TiDB Data API with 3rd-party PaaS/SaaS Artificial Intelligence * News article classification based on real-time trends * AI-based adaptive pricing engine for e-commerce platforms * AI-driven project management tool that predicts task completion times 一些已经使用 TiDB serverless 实现的应用案例 混合事务/分析处理(Hybrid Transactional/Analytical Processing) OSSInsight(Open Source Software Insight):基于 TiDB Cloud Serverless 和 OpenAI 的开源软件洞察,一款人工智能的工具,可以分析 GitHub 事件的数十亿行数据。 Fortune 500 Insight《财富》500 强洞察:财富 500 强公司的营收分析(https://github.com/tidbcloud/vercel-fortune500-demo)。 Steam Insight1《Steam》游戏洞察 :分析《Steam》游戏(GitHub - pingcap/steam-insight-template: Steam Insight vercel template based on TiDB Cloud Data API:)。 Hacker News Insight1;基于 AutoGPT 的《黑客新闻》洞察 ,通过将 AutoGPT 与 TiDB Serverless 数据库相结合,几乎实时地为用户提供有价值的见解和信息。 S&P500 Insight基于 Vercel 和 Serverless TiDB & TiDB 数据 API 的 S&P500 洞察(S&P500 Insight):这是一个强大的工具,用于分析在标普500指数上市的股票的表现。 人工智能 Ai Insight:将自然语言翻译成 SQL,然后从任何 csv 文件中获取见解(https://ai-insight.vercel.app/)。 如何报名? 报名链接:点击链接提交报名表(由于是全球赛事,所以需要使用合法的 VPN 访问) 活动流程 Stage 1 初赛(6/6 - 7/28) 报名、组队、注册TiDB serverless账户并开发应用 提交一段不超过 4 分钟的演示视频,并向评委提供试用参赛的应用程序的途径,可以是接口、账户、网站链接等;同时需要提交参赛项目 GitHub 链接:你的仓库可以是公共的或私人的。如果它是私有的,请在你的测试说明中提供访问权限。记住要包括所有必要的部署文件和测试说明,以方便你的应用程序的测试。 评委将通过初赛阶段提交的 demo、程序、代码等评选出 60 只队伍进入决赛阶段,初赛结果将于 8 月 3 日公布。 Stage 2 决赛(8/4-8/6) 进入决赛的队伍可以在这三天的时间内优化参赛的程序,并且向最终的大奖发起冲击! 最终的获奖结果将于 8 月 15 日公布。 参赛流程 1、报名 2、组队(自行组队(1 - 4 人)) 3、在TiDB Serverless上创建一个集群 4、查看开发指南 5、分工开发应用 6、撰写 PPT(PPT 模板帮你准备好了,点击即可领取) 7、录制 Demo 视频(由于评委是国际评委,所以最好使用英文演讲,如若不能使用英文演讲,可以通过添加英文字幕来解决这个问题),录制视频后把视频上传到 yutube 8、提交作品 部分评委 加群寻找队友&技术支持 中文区交流:微信群 加入流程: 扫码加入微信群 入若群满或者失效,可以添加表妹微信:billmay,报上 2023 暗号进群! 查看群公告 英文区交流: discord 加入流程: 下载并安装 discord 加入群组:https://discord.gg/PQ9J66rfgW 资源&文档 案例及开发工具合集 Sample Applications & Development tools ——TiDB Future App Hackathon 2023 - #2 by billmay - TiDB hackathon - TiDB Forum Sample Applications built with TiDB Serverless 公开数据集 Dataset—— TiDB Future App Hackathon 2023 应用 idea Creative ideas list——TiDB Future App Hackathon 2023 激励奖项参与规则 Post to win the TOP 5 $100 cash incentive award!——TiDB Future App Hackathon 2023 奖项说明 TiDB Future App Hackathon 2023 Award description 作品提交指南 Project Submission Guidelines - TiDB Future App Hackathon 2023 视频录制指南 Video recording guide——TiDB Future App Hackathon 2023 TiDB serverless FAQ TiDB serverless FAQ——TiDB Future App Hackathon 2023

优秀的个人博客,低调大师

数据库DevOps:我们如何提供安全、稳定、高效的研发全自助数据库服务-iDB/DMS企业版

数据管理DMS企业版地址: https://dms.aliyun.com/ 阿里云数据管理DMS 企业版已于2017.7.18正式发布,一期我们提供 MySQL、ORACLE、SQLServer、PostgreSQL、Mongo这几种数据库类型的数据管理服务,支持RDS、ECS自建、其他公网自建类型,支持经典网络、VPC网络,提供实例管理、用户管理、任务管理、安全规则、操作审计、权限管理、数据查询、数据变更/数据订正、数据导出、库表同步、SQL审核/sqlreview等功能。 DMS企业版在集团内部产品代号为iDB,是阿里巴巴集团从2010年开始逐步积累迭代出来的研发全自助数据库服务平台。 从最初解决数据安全访问诞生一个简单的查询页面(2011,iDB1.0时代-提升数据安全),到解决变更在线提交、满足既定设计规范的研发全自助线下表结构设计(2012,iDB2.0时代-解决变更在线化),再到sqlreview、研发有限自助变更线上、DMS个人版的上线(2013-2015,iDB3.0时代-提升研发效率),再到规则引擎、工作流引擎、任务调度引擎、CloudDBA、研发全自助变更(2016,iDB4.0时代-灵活、智能管控最大化提升研发效率); iDB在阿里内部不断完善,服务于内部几万用户每天各种各样的数据库研发使用的同时;2017年产品提出正式云化为云上广大中小企业提供成熟的企业数据库管理服务。 我们的目标是: 赋能研发全自助的数据库研发设计能力,提升企业的研发效率(不再因为集中管控人员瓶颈导致项目延期);在满足既定规范内全自助设计与变更,同时辅助CloudDBA性能诊断与优化让研发主动优化改造问题SQL、回收碎片空间、建立合适索引、删除无效索引提升研发的数据库专业技能 解放传统DBA的人肉操作,使其可以将精力转向诸如数据库架构设计等领域深挖;管理员、DBA轻松管理全局,只需要事先制定研发设计规范、研发流程即可轻松管理大批量实例的使用 数据分级、权限管控、操作审计、安全规则、访问IP白名单等一系列解决方案进一步提升企业的数据安全 以下是产品内部分主要功能的详细讲解介绍: 普通使用 权限管理 支持库、表、列三种对象粒度申请,列是指表上打标为敏感或机密的字段(即数据分级管控) 库权限包含有库下所有表含后续新增表的非敏感机密字段的权限 表权限仅包含表上非敏感机密字段的权限 权限申请对应的审批流程由管理员、DBA在【安全规则】按需实例级别进行指定配置 支持查询、导出、变更三种权限类型申请 导出、变更,是指可以提交对应的工单;并非直接执行对应操作 支持指定有效期,到期自动失效 数据owner可以随时查看对应库、表的权限开通情况进行回收或者追加授权 申请者本人也可以随时查看所开通权限情况进行主动释放或者续期申请 数据查询 开通“查询”权限后可以进行对应库、表的结构、数据等进行查询 全局单次查询返回行数有上限限制(默认200,由管理员按需调整;但不建议过大,过大可能会造成页面卡顿) 每人每天查询返回行数有上限限制(默认20000,由管理员按需调整) 每人每天查询次数有上限限制(默认2000,由管理员按需调整) 实例级别可指定查询超时时间(默认60,由管理员、DBA按需调整) 全局禁止大表全表扫描查询(默认10G,由管理员按需调整) 允许执行的SQL类型由管理员、DBA在【安全规则】按需实例级别进行指定配置 查询已经显示在页面的结果可导出excel、txt或insert脚本格式 逻辑库下对逻辑表配置路由算法可自动路由查询返回结果 数据变更/数据订正 开通“变更”权限后可以进行对应库、表的结构与数据等进行变更 工单提交时 会校验语法正确性(不正确则阻断不能提交) 会校验影响行数(可以与预期影响行数进行对比,不一致场景要注意SQL逻辑是否正确书写) 工单执行时 支持立即执行、指定时间执行(定时调度) 支持工单级别开启事务(不开启默认串行执行,遇到失败则终止不回滚;开启则遇到失败会全部回滚) 支持备份(默认开启,对update、delete语句影响的整行记录进行insert脚本的全备;如果变更不符合预期时可快速download附件进行恢复操作) 允许执行的SQL类型、不同需求对应工单的审批流程由管理员、DBA在【安全规则】按需实例级别进行指定配置 安全管控 串行调度:多人同时发起同一个实例的不同变更需求时,串行调度避免任务造成过大负载影响业务正常运行 并发检测:执行任务前会探测目标实例的繁忙程度,活跃会话超过指定阀值则退出休眠5秒再重新尝试;重试5次仍然繁忙则退出失败 执行间隔:每个SQL执行完根据SQL类型以及影响行数进行对应的间隔再调度下一条SQL,防止主备复制延迟 锁检测:在执行DDL语句时还会额外检测元数据锁,设置获取等待时长超过则重试直至获取到才执行DDL语句;重试5次仍然繁忙则退出失败 数据导出 开通“导出”权限后可以进行对应库、表的数据等进行导出 工单提交时 会校验语法正确性,仅支持select(不正确则阻断不能提交) 会校验影响行数(可以与预期影响行数进行对比,不一致场景要注意SQL逻辑是否正确书写) 工单执行时 可选择excel、csv、insert脚本三种格式 默认按照数据库字符集导出,部分场景库表字符集不一致可以指定表的字符集避免乱码 审批通过后24小时内要完成导出,24小时内可反复导出 导出成功后可直接下载最后一次成功的结果集(下载文件距离最后一次导出时间必须是一个月内) 不同需求对应工单的审批流程由管理员、DBA在【安全规则】按需实例级别进行指定配置 库表同步 开通源库的“查询”权限、目标库的“变更”权限后可以进行对应源库与目标库表结构的对比与同步 支持结构同步、空库初始化、表一致性修复三种常见场景 结构同步:源库表、目标库表,对比进行新建表或者修改表达到与源库表一致结构(表数量1:1对应) 适用于测试环境变更同步到其他环境,如生产环境发布等 空库初始化:将源库表结构完整拷贝至目标库 适用于多套环境的搭建,如测试环境搭建等 表一致性修复:将源库表、目标苦逼,对比进行新建表或者修改表达到与源库表一致结构(表数量1:N对应) 适用于分库分表场景下,分表结构一致性的保障check 不同需求对应工单的审批流程由管理员、DBA在【安全规则】按需实例级别进行指定配置 SQL审核/sqlreview 开通“查询”权限后可以进行对应库表代码内增删改查访问SQL进行审核 审核的是增删改查的SQL,非DDL语句 主要审核SQL语法书写是否正确、合规 不通过场景:存在`select * `、动态SQL、SQL注入写法 通过场景:SQL语法正确并且执行计划可以走上索引、执行计划走不上索引(会主动建议添加合适的索引,确保每个经过审核后上线的SQL都能有索引可走) java语言:支持Ibatis、Mybatis两种格式的附件 其他语言:需要将代码中的增删改查SQL按照模板整理后提交附件 不同需求对应工单的审批流程由管理员、DBA在【安全规则】按需实例级别进行指定配置 属于应用发布前的事前管控,限制选择的数据库是非生产环境(测试阶段结构已经变更,但线上结构是发布后才变更的) 系统管理 实例管理 目前支持类型 支持MySQL、ORACLE、SQLServer、PostgreSQL、Mongo几种数据库类型 支持RDS、ECS自建数据库、其他公网自建数据库 支持经典网络、VPC网络 实例级别灵活设置进行管理:查询超时时间、导出超时时间、运维负责人/DBA、【安全规则】 默认会在注册时自动采集实例上schema、表、字段、索引等相关元数据提供普通使用的权限管理及数据分级依据,也可以主动触发增量的同步 对于不需要使用的实例可以进行禁用或者删除:如大促期间禁用某个实例避免非生产服务压力 在授权后,可以自动同步当前账号下购买的rds实例列表;但正式使用需要完善相关信息测试账号可用后进行保存 与所有传统工具不一样,管理员一次录入后所有用户通过产品内各模块权限管控访问数据库表;所有用户不再接触数据库账号密码,即使人员流动账号也没有频繁修改更新的烦恼 用户管理 目前支持阿里云平行账号、主子账号两种形式 对于主子账号,在主账号作为管路员时可以一键同步所有关联的子账号 对于不需要使用的账号可以“禁用” 任务管理 所有从普通使用各个模块产生的变更SQL任务均会记录在此模块 管理员、DBA也可以直接对目标库表进行SQL变更(DML、DDL)任务的部署,区别在工单提交有对应流程审核管控;后台部署因为人员有限可控所以无流程管控 任务的执行的安全管控策略,同【数据变更/数据订正】的“安全管控”一致 安全规则 由审批节点、审批流程线、安全规则依次组成 审批节点:默认的有管理员、DBA(跟随实例走)、数据owner(跟随数据库、表走)三个节点,其他可以按需自定义;如安全管理员、测试负责人、研发负责人等 审批流程线:默认有5个组合好的流程线,单向逐一通过处理;同一个节点多个人时任意一个审批通过即通过 安全规则:默认有3个组合好的安全规则,高、中、低;可以按照业务实际需要组合新的安全规则或调整已有规则的审批流程达到根据不同的业务重要程度及所处阶段灵活管控不同的变更需求 操作审计 平台上产生的所有用户操作都会详细记录,管理员可以便捷的查看、溯源 某个用户某段时间做了哪些操作、针对某个模块做了哪些操作等 某个数据库、表,在某段时间被做了哪些操作、在某个模块内做了哪些操作等 访问IP白名单 对于每个企业都是独立的一套企业版部署,管理员在加入企业的员工、企业的数据库后,可以决定是否开启访问IP白名单限制 限制:仅在指定的服务器ip发出的请求才能登录使用DMS企业版,对于企业宽带运营商有固定的ip出口,可由管理员进行配置 在访问安全上DMS企业版做了四层管控: 1)阿里云账号、密码正确性校验 2)DMS企业版对应本企业员工校验:确保本企业员工才可使用 3)DMS企业版访问IP白名单校验:确保办公网内才可使用(规避员工流失未及时清理禁用账号的潜在风险、员工账号被外部非法盗用的潜在风险) 4)目标库表操作权限的校验(产品内体系化保障,规避员工接触数据库账号密码要频繁变更维护的风险与投入) 在以上这些主要功能之外,我们也提供如owner管理、代码生成器、配置管理、我的SQL、逻辑库逻辑表等诸多功能服务。 入口: 数据管理DMS企业版地址: https://dms.aliyun.com/

优秀的个人博客,低调大师

《从知识库到本体驱动应用》第5招 本体驱动开发 Ontology-driven Development——AI Coding 不能从一句需求直接跳到代码,中间应

## 01、痛点 我是老李,这几年带团队用生成式 AI 做业务系统,最大的感受不是“生成得太慢”,而是“生成得太快,快到来不及发现它悄悄变了意思”。去年我们做一个合同管理系统,一开始很顺:对着对话框说“帮我生成一个合同管理系统”,几分钟后数据库脚本、接口、页面骨架全出来了。可越往后越不对劲。销售同事说“合同金额”在前端叫“合同金额”,导出报表时字段名变成 total_amount;审批流里“法务审核”和“财务复核”的触发条件经常串;权限配置里“合同归档”按钮有时出现在销售角色下,有时又不见了。最麻烦的是,这些问题不是一次性的,每重新生成一版,不一致的地方就换一批。后来我们才意识到,这不是指令写得不够细,而是系统里缺少一个把业务语义固定下来的东西。AI 生成代码时,模型会根据概率选择表达方式,同一个业务概念在不同位置可能被翻译成不同名字、不同类型、不同约束,这就是语义漂移。它不像语法错误那样直接报错,而是像慢性病,等你发现时,数据库、接口、页面、流程已经各说各话。 ## 02、是什么 本体驱动开发,简单说,就是把“本体”从知识资产变成软件工程资产。过去我们谈本体,往往想到知识图谱、语义网,觉得那是科研或数据治理的事。但在这个项目里,本体被放到开发流程的中心位置。它不再只是描述领域知识的文档,而是生成数据库、API、菜单、权限和流程的共同源头。具体做法是:在需求确认之后、代码生成之前,先产出六类模型——对象模型、行为模型、规则模型、事件模型、权限模型、场景模型。对象模型定义系统里有哪些核心实体、字段和关系;行为模型定义实体能做什么操作;规则模型定义业务约束和状态流转;事件模型定义什么情况下触发什么消息;权限模型定义谁能在什么场景下做什么;场景模型把前面几类串起来,描述完整的业务用例。这六类模型合在一起,就是一个可评审、可版本化、可执行的“语义单一来源”。后续生成数据库表结构、接口契约、前端页面、流程配置、权限策略时,都必须从这个来源读取,不允许各模块自行发挥。换句话说,本体驱动开发不是多写一份文档,而是把语义变成一种工程化资产,让 AI 生成的内容有据可依。 ## 03、为什么 为什么一定要这么做?因为生成式 AI 最容易忽视的恰恰是语义一致性。很多人觉得 AI 写代码快,但快的前提是它可以在不同位置独立生成内容。数据库脚本生成时,模型可能把“合同金额”命名为 amount;接口生成时,可能叫 total_amount;前端页面生成时,又可能显示成“合同总价”。单独看每一处都合理,合在一起系统就乱了。传统开发中,人脑会自觉对齐这些概念,因为同一个开发者在写不同层时会记得自己用过的词。但 AI 每次生成都是概率采样,没有跨文件的稳定记忆,除非你给它一个明确的外部约束。本体就是那个约束。它把业务概念、字段名、类型、枚举值、状态流转、权限边界提前固定下来,AI 在生成任何部分时都先读取本体,再输出代码。这样就从“事后找不一致”变成“事前消除漂移源”。另一个原因是可维护性。系统上线后需求会变,如果没有本体,改一个字段名可能要全局搜索,还容易漏改。有了本体,先改本体,再驱动各层重新生成或校验,改动路径清晰。人工确认门禁也非常关键:模型可以快速产出本体草案,但必须由业务和技术负责人确认后才能进入代码生成阶段。这不是不信任 AI,而是把人类判断放在语义层,因为语义错误一旦进入代码,修复成本远高于在建模阶段拦截。 ## 04、架构 整个底座可以看成三层。最上层是需求探索,负责把模糊的业务想法转成结构化需求,输出用户故事、业务规则、边界条件。中间层是本体建模,这是核心。它接收需求探索的结果,产出六类模型,并存储为机器可读的结构化文件,比如 JSON 或 YAML。这层设有人工确认门禁,确认动作不可跳过。最下层是应用构建,它读取本体文件,调用不同的生成器,分别生成数据库模式、后端接口、前端页面、流程配置、菜单和权限策略。同时,AI 对话上下文也会注入本体内容,这样后续的增量修改、问答、排障都能基于同一套语义。关键点在于:数据库字段名、接口参数名、前端展示名、流程节点名、权限标识,都从本体中的同一个概念派生。比如本体里定义“合同金额”的标识为 contract_amount,类型为 decimal(18,2),最小值为 0,那么数据库列、接口字段、前端表格列、导出映射、校验规则都使用 contract_amount,不允许出现 amount 或 total_amount 之类的别名。架构上并不复杂,但需要纪律:任何生成器都不允许绕过本体直接生成;任何人工确认未完成的阶段,后续生成任务不能启动。这样底座就从“工具集合”变成了“语义流水线”。 ## 05、实战 回到合同管理系统。我们第一次按下生成按钮之前,没有说“帮我生成一个合同管理系统”,而是先用一张表格做需求探索和本体建模。对象模型列了合同、客户、合同条款、审批记录、附件、收款计划等实体。每个实体标注字段名、类型、是否必填、唯一性、关联关系。例如“合同”有合同编号、合同名称、客户ID、合同金额、签订日期、状态、创建人、创建时间。行为模型列出创建合同、提交审批、审核通过、审核驳回、财务复核、归档、作废等操作。规则模型约定:合同金额超过100万时,审批流必须增加法务复核节点;合同状态只能从“草稿”到“审批中”到“已通过”或“已驳回”,已通过的合同才能归档;附件缺失时不能提交审批。事件模型定义合同创建事件、审批通过事件、到期前提醒事件。权限模型定义销售、法务、财务、管理员四类角色,销售只能创建和提交自己的合同,法务只能审核,财务只能复核和查看,管理员可查看全部但不可修改业务数据。场景模型把上面串起来:销售登录后创建一个合同,填写客户和金额,上传附件,提交审批;系统校验金额和附件,触发审批流;如果金额超100万,自动加入法务复核节点;法务通过后财务复核;全部通过后合同状态变为已通过,触发归档和后续事件。这些内容用结构化文档写好后,我们开了一次评审会,业务负责人确认规则,技术负责人确认字段和关系。确认通过后,才进入代码生成。生成的数据库表结构里,合同表字段就是 contract_amount,接口参数也是 contract_amount,前端表格列显示“合同金额”但数据绑定同一个字段,权限策略里销售角色没有“归档”按钮。整个系统不再是“看起来像”,而是“各个部分说同一套话”。后续我们在对话中修改需求时,也会先更新本体,再让 AI 基于新本体调整代码,漂移明显减少。 ## 06、洞见 本体驱动开发的转折意义在于,它把“本体”从一种知识管理概念变成了软件工程资产。过去本体可能被用来做知识问答、语义检索,但很少直接参与代码生成。这个项目证明,本体可以成为生成式 AI 的“语义锚点”。语义漂移之所以难发现,是因为它发生在不同文件、不同层之间,单看每一处都合理。传统开发中,人脑是隐性的对齐机制;AI 编程把生成速度提升后,这种隐性机制被绕过,漂移被放大。本体把隐性的对齐变成显性的工程产物。还有一个洞察:人工确认门禁不是流程负担,而是把人的注意力集中在语义层。代码语法错误 AI 能自己修,但“法务审核”和“财务复核”谁先谁后,AI 只能根据常见模式猜,只有业务负责人知道。在建模阶段确认,成本最低。另一个值得注意的点是本体粒度。如果本体太粗,只写“合同”“客户”几个名词,约束力不足;如果太细,把每个按钮都建模,又会失去灵活性。合适的粒度是“业务语义单位”:一个概念、一个规则、一个状态、一个权限边界。最后,本体不是一次性的。系统演进时,本体要与代码同步更新,最好纳入版本管理。这样每次生成或修改,都能追踪语义变更历史,团队沟通也有了统一语言。 ## 07、行动 如果你下一个项目要用 AI 编程,建议别急着说“帮我生成一个 XX 系统”。先花半天到一天做本体建模。第一步,需求探索:把业务目标、用户角色、核心流程、边界条件写清楚,不用太正式,但要把关键名词和动作列出来。第二步,本体建模:按对象、行为、规则、事件、权限、场景六类模型整理成结构化文档。可以用表格、JSON、YAML,关键是每个字段、操作、状态、角色都有明确标识和定义。第三步,设置人工确认门禁:找业务负责人和技术负责人一起评审,确认对象关系、规则条件、权限边界。这一步不能跳过,即使时间再紧。第四步,再生成代码:把确认后的本体作为输入,生成数据库、接口、页面、流程、权限。生成后做一致性校验,抽查关键字段是否在各层一致。第五步,把本体文件放进版本库,后续修改先改本体,再重新生成或局部调整。常见坑:本体过度设计,把简单系统搞得像学术项目;跳过确认,直接生成,结果返工;生成后不校验,漂移积累;本体与代码脱节,时间一长又变成两张皮。只要守住“先建模、后生成、再校验”的节奏,AI 生成的速度优势才能变成真正的交付优势。 ## 08、小结 本体驱动开发不是让 AI 生成得更快,而是让它生成得更稳。它用对象、行为、规则、事件、权限、场景六类模型,把业务语义从人脑里搬到工程资产里,作为数据库、接口、前端、流程、权限的共同源头。人工确认门禁确保语义在进入代码前已经被业务和技术双方认可。这种做法的核心价值,是减少 AI 编程中的语义漂移,让系统各部分说同一套话。对团队来说,它带来的不只是效率提升,更是一种可控的生成方式。 ## 09、链接与概念说明 - 本体:这里指领域内共享的概念模型,包含实体、属性、关系、规则等。在软件工程中,本体可以是结构化文档或模型文件。 - 语义漂移:指同一业务概念在系统不同部分被表达为不同名称、类型、约束,导致语义不一致的现象。 - 单一来源:系统中的事实或定义只在一个地方维护,其他地方引用该来源,避免多份拷贝不一致。 - 人工确认门禁:在关键阶段必须由人类确认后才能继续的流程控制点,防止错误语义自动流入下游。 - 六类模型:对象模型、行为模型、规则模型、事件模型、权限模型、场景模型,是本体驱动开发的核心工件。 - 建议延伸阅读:领域驱动设计、模型驱动工程、语义网基础、生成式 AI 的上下文工程。

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

优质分享App

优质分享App

近一个月的开发和优化,本站点的第一个app全新上线。该app采用极致压缩,本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册