首页 文章 精选 留言 我的

精选列表

搜索[工程化]，共3385篇文章
优秀的个人博客,低调大师

(五)Java工程化--Jenkins

Jenkins简介 Jenkins 是一种用Java语言实现的持续集成工具,Jenkins是一个平台, 在此基础上实现下面两个目的. CI 持续集成(Continous Integration) CD 持续交付(Continous Delivery) 安装 下载地址: https://jenkins.io/ 文件名为jenkins.war 启动命令：java -jar jenkins.war --httpPort=8099 访问http://localhost:8099 第一次访问会有guide,按guide配置好用户/插件等 插件安装：建议安装推荐的插件， 如不安装插件有的配置项出不来；系统管理-->插件管理-->可选插件 可以查找和安装插件 配置 （进入“系统管理”菜单） 全局工具配置 点击 系统管理-->全局工具配置 在此目录下配置JDK和MAVEN环境,以及git; (不安装git相关插件看不到配置项) JDK和Maven是配置home路径, git需要配置git.exe文件的全路径 创建任务 Jenkins的学习主要是要自己动手, 本文不再截图凑篇幅, 实践中遇到相应问题可以从管网查找资料,该下载插件的下插件,该在流程中作相应配置的做配置. 在我从上家公司离职之前的几个月, 公司的运维正在做CI方面的工作, 其间也是根据实际情况慢慢摸索, 一方面是要满足各种不同语言,项目,场景的CI, 另一方面也证实Jenkins的强大适应性,丰富的插件几乎能满足各种需求.
2018-08-28
优秀的个人博客,低调大师

(二)Java工程化--Maven实践

Maven项目版本号 默认版本号: 1.0-SNAPSHOT 最佳实践是约定该版本为不稳定版本,如果发布一定要删除; 建议的版本规则: 主版本号.次版本号.增量版本号-<里程碑版本> 如:1.0.0-RELEASE 10.2.5-FINAL 等. 最佳实践是结合自身情况制定大家都认可的版本号规则. 常见命令 内置的maven插件提供了常见的命令, 可以在以下位置找到对应的包: .m2\repository\org\apache\maven\plugins compile clean 删除/target,将已编译的二进制文件等删除 test test case junit/testNG package 打包 install 把项目install到本地仓库 deploy 发布jar到remote服务器 mvn help:system 查看环境变量 插件 插件仓库 https://maven.apache.org/plugins/ http://www.mojohaus.org/plugins.html 常见插件 findbugs 静态代码检查 versions 统一升级版本号 统一升级版本 http://www.mojohaus.org/versions-maven-plugin/ 可以查看使用示例, 常用的设置版本的命令为mvn versions: set –DnewVersion=1.1.0-final mvn versions:set -DnewVersion=1.1 source 打包源代码，当jar提供给外部的时候斟酌使用 assembly 打包zip、war tomcat7 <plugins> <!--静态代码bug扫描--> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>findbugs-maven-plugin</artifactId> <version>3.0.0</version> <configuration> <threshold>High</threshold> <effort>Default</effort> <findbugsXmlOutput>true</findbugsXmlOutput> <findbugsXmlOutputDirectory>target/site</findbugsXmlOutputDirectory> </configuration> </plugin> <!--版本号管理--> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>versions-maven-plugin</artifactId> <version>2.3</version> </plugin> <!--打包源代码--> <plugin> <artifactId>maven-source-plugin</artifactId> <version>2.3</version> <executions> <execution> <id>attach-sources</id> <phase>install</phase> <goals> <goal>jar-no-fork</goal> </goals> </execution> </executions> </plugin> <!--这个有点晕,生成可执行jar包什么的--> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>3.0.0</version> <configuration> <archieve> <manifest> <mainClass>com.xlx.Test</mainClass> </manifest> </archieve> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> </configuration> </plugin> <!--tomcat插件--> <plugin> <groupId>org.apache.tomcat.maven</groupId> <artifactId>tomcat7-maven-plugin</artifactId> <version>2.2</version> <configuration> <port>8080</port> <path>/</path> </configuration> </plugin> </plugins> 自定义插件 学习地址https://maven.apache.org/guides/plugin/guide-java-plugin-development.html 创建项目 修改pom的<packaging>maven-plugin</packaging> 添加依赖 <dependencies> <dependency> <groupId>org.apache.maven</groupId> <artifactId>maven-plugin-api</artifactId> <version>LATEST</version> </dependency> <dependency> <groupId>org.apache.maven.plugin-tools</groupId> <artifactId>maven-plugin-annotations</artifactId> <version>LATEST</version> <scope>provided</scope> </dependency> </dependencies> 写代码实现AbstractMojo @Mojo(name="xlxTest",defaultPhase = LifecyclePhase.PACKAGE) public class Test extends AbstractMojo { /** * 接收的参数 */ @Parameter private String message; /** * 接收多个值的参数 */ @Parameter private List<String> options; /** * 命令行中接收,注意必须有property mvn:package -Dargs=this is from cmd */ @Parameter(property = "args") private String args; public void execute() throws MojoExecutionException, MojoFailureException { System.out.println("my first maven plugin message is : " + message); System.out.println("my first maven plugin options is : " + options); System.out.println("my first maven plugin args from evm is : " + args); } } mvn install 使用, maven可以接收参数, 也可以使用环境变量取,如${settings.localRepository},${project.baseUri}等 <!--项目pom修改--> <build> <plugins> <plugin> <groupId>com.xlx</groupId> <artifactId>engineering</artifactId> <version>1.0-SNAPSHOT</version> <executions> <execution> <phase>package</phase> <goals> <goal>xlxTest</goal> </goals> </execution> </executions> <configuration> <message>message</message> <options> <option>one</option> <option>two</option> </options> </configuration> </plugin> </plugins> </build> Profile 不同运行环境 dev/prod/test等 mvn clean package –P dev settings.xml 可以指定不同服务器仓储配置<profile.active>私服或者官方</profile.active> 多环境配置的配置文件路径 <profiles> <profile> <id>dev</id> <properties> <profile.active>dev</profile.active> </properties> <activation> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <id>test</id> <properties> <profile.active>test</profile.active> </properties> </profile> </profiles> <build> <resources> <resource> <directory>${baseDir}/src/main/resources</directory> <excludes> <exclude>conf/**</exclude> </excludes> </resource> <resource> <directory>src/main/resources/conf/${profile.active}</directory> </resource> </resources> </build> 私服 下载： https://www.sonatype.com/download-oss-sonatype?hsCtaTracking=920dd7b5-7ef3-47fe-9600-10fecad8aa32%7Cf59d5f10-099f-4c66-a622-0254373f4a92 安装， 解压即可， 如果需要修改端口号等信息, 可以修改文件\nexus-3.13.0-01\etc\nexus-default.properties 启动命令 转到\nexus-3.13.0-01\bin下， nexus /run 可查看启动日志 使用： http://books.sonatype.com/nexus-book/reference3/index.html pom中增加发布节点 <distributionManagement> <repository> <id>nexus-release</id> <name>nexus-release</name> <url>http://localhost:8099/repository/maven-releases/</url> </repository> <snapshotRepository> <id>nexus-snapshot</id> <name>nexus-snapshot</name> <url>http://localhost:8099/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement> 修改settings.xml 增加服务器账号密码信息 <server> <id>nexus-release</id> <username>admin</username> <password>admin123</password> </server> <server> <id>nexus-snapshot</id> <username>admin</username> <password>admin123</password> </server> 生成脚手架 mvn archetype: create-from-project 从项目生成脚手架 cd /target/generated-soource/archetype 转到此目录 mvn install 发布到仓库 可以添加到ide的脚手架列表 mvn archetype:generate –DarchetypeCatagory=local 命令行方式创建项目 local参数指定走本地仓库
2018-08-27
优秀的个人博客,低调大师

(三)Java工程化--Git起步

GIT学习参考：https://git-scm.com/book/zh/v2 版本控制 版本控制记录了一个或若干文件的历史变化，便于今后查阅，恢复。 三类版本控制系统 本地版本控制系统 RCS : 本地存储文件变更系统,无法协作及对权限做统一管理 集中化版本控制系统 CVCS : 变更存储于集中的一台服务器 分布式版本控制系统 DVCS : 分布式存储版本库镜像, 包含文件历史变更的所有信息 Git的历史 git来自于linux团队， 是linux为了解决之前版本管理工具Bitkeeper收费的问题研发出来的。 设计目标 速度 简单 对非线性开发模式的强力支持(多个并行开发的分支) 完全分布式 适用超大规模项目 linux是开源的, 所以当他们之前使用的版本工具开始收费的适合,他们决定自己研发一个版本控制工具,即Git. 说起开源, 我们需要了解下常见的开源协议,以便我们做技术选型时考虑.例如一般的开源协议都要求使用开源框架的项目也要开源. Git与SVN(或者说其他版本控制系统)的区别 直接记录快照,而非差异比较 了解此项差异的底层实现方式非常重要,有利于我们更准确的理解和学习Git.具体可以参考文章开始的网站资料.(有图有真相) 近乎所有操作都在本地执行(得益于第一点的底层实现,即分布式存储) Git使用sha1哈希算法算出的校验和保证完整性 Git的索引是校验值而不是文件名,如果在传送过程中有信息丢失和损坏,Git就能发现. Git一般只添加数据 (只要提交便不会丢失数据,可以执行可逆操作) 使用前的配置 git config --list 显示所有配置 git config --global user.name 'user' 设置用户名 git config --global user.email 'user@xxx.com' 设置用户邮箱 ssh-keygen -t rsa -C 'user@xxx.com' 生成ssh密钥 多用户配置方法: 在.ssh路径下(C:\Users\xueli.ssh)创建文件config, 添加下面内容 # Default github user(usergithub@mail.com) Host github.com HostName github.com User git IdentityFile C:\Users\xueli.ssh\id_rsa # Default mygitlib user(second@mail.com) Host mygitlib.com HostName mygitlib.com User git IdentityFile C:\Users\xueli.ssh\mygitlib 上面是Git起步和背景知识, 下次将学习Git常用命令.
2018-08-25
优秀的个人博客,低调大师

(一)Java工程化--Maven基础

Maven 读作['mevən] 翻译成中文是"内行,专家" Maven是什么 包依赖的前世今生: 原始的jar包引用--> ant --> maven. 是一种项目管理工具 Maven优势: convertion over configuration 约定优于配置: 这个原则不仅适用于maven, 更是目前大多数框架遵循的原则,如mvc 简单 易于测试 构建简单 CI(持续集成) 插件丰富 下载和安装 下载: http://maven.apache.org/download.cgi 安装: 解压安装即可 环境变量配置: windows: 配置path MAVEN_HOME linux: 在 .bash_profile 文件中 运行参数: 定义环境变量MAVEN_OPS 配置settings.xml: settings.xml文件是个空模板,我们可以在这个文件进行一些自定义配置. 常用的配置如:repo存储目录 创建maven项目 项目结构: 遵循约定优于配置原则, 项目包的组织结构如下 pom.xml groupId 公司组织id artifactId 功能命名 version 版本号 packageing 打包方式,默认jar,可修改为maven-project,war dependancyManagement 最好之出现在父pom中,用于统一版本号,只做声明依赖,子模块pom中还需要引用,但不需要制定version. dependancy type 默认jar scope 指定哪个阶段适用,各阶段如下: compile 编译,打包,默认 如spring-core test 测试 如spring-test provided 编译 如servlet runtime 运行时 如JDBC驱动实现包 system 本地一些jar 依赖传递 依赖仲裁:(1)最短路径原则,根据依赖树就近取最接近的版本;(2)加载顺序原则;(3)exclusions 排除包 命令: mvn dependancy:tree Maven生命周期(三个过程) 区分术语:lifecycle/phase/goal 生命周期: clean 包含的phase: pre-clean --> clean --> post-clean default compile package install deploy ... site pre-site --> site -->post-site --> site-deploy A Build Lifecycle is Made Up of Phases 一个构建生命周期是有多个phase组成 A Build Phase is Made Up of Plugin Goals 一个构建phase是由多个插件目标goal构成
2018-08-20
优秀的个人博客,低调大师

前端工程化之路-语法检查

javascript作为前端的利器，上可撸AI，下可写驱动，（好吧，我承认我瞎编的），但是js作为一门弱类型的动态语言，在给我们带来方便的同时，也会悄悄的埋下坑，尤其是在大型项目中，一不小心，就要加班填坑，所以为了愉(早)快(下)工(班)作，我们选择使用eslint作为javascript的语法检查工具，tslint作为TypeScript 的语法检查工具，我们的目标是 提高代码质量，避免低级的bug 规范化编码，统一代码风格 eslint官方地址 配置规则 eslint 和 tslint 的规则网上介绍已经非常多，配置项也简单易懂，为了避免该文章篇幅过长，配置规则文件另起一篇语法检查-配置规则 eslint 'extends': [ "eslint:recommended", "standard", "plugin:react/recommended", "plugin:vue/base", ], 推荐这几个插件，都是业内流行的规范，插件地址如下 standard react检查规范plugin:react/recommended vue检查规范plugin:vue/base tslint 开启如下插件 "extends": [ "tslint:recommended" ] 搭配vscode使用 推荐两个插件 eslint插件地址 可共享的配置 当有多个项目的时候，我们就可以考虑将配置独立出来，统一管理，可以通过npm来管理的配置文件，将配置文件独立为一个项目维护，如果是内网项目，可使用 npm install <git remote url> 进行安装 详细使用方法如下： npm install <git remote url>: <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>] tip：项目名称需要按照这样的格式 eslint-config-mylint 在配置文件.eslintrc.js中，改为如下 module.exports = { "extends": [ "mylint" ] }; 填坑 行内规则 在某些情况下需要对个别文件和某行代码特殊处理时，使用注释的形式 eslint 该文件不参与语法校验 /* eslint-disable */ 允许使用 console /* eslint no-console: 0 */ or /* eslint-disable no-console */ tslint 该文件不参与语法校验 /* tslint:disable */ 允许使用 console /* tslint:disable:no-console */ jquery 与箭头函数 因为箭头函数的优势和其简洁，所以我们在项目中推荐使用箭头函数，箭头函数有个特性 箭头函数没有它自己的this值，箭头函数内的this值继承自外围作用域，没有局部this的绑定，即this不在是动态改变的 因部分项目还是基于jquery的，所以避免不了在dom元素上绑定事件监听函数，在使用 function的时候，dom事件被触发，回调函数中的this指向该dom，可当我们换成箭头函数时，this就不在是dom，而是上下文，举个栗子 <div class="outer"> <div class="inner">ww</div> </div> 复制代码 $('.outer').on('click', (event) => { console.log(this) // 不再是dom对象 console.log(event.target) // 这个才是dom对象 }) 因此在修改dom元素的监听事件回调的时候，记得要同步将this一同修改 currentTarget 与 target 的区别与使用 在监听的节点里面还有嵌套节点的情况下，使用event.target将会有问题，栗子如下 <div class="outer"> <div class="inner">cc</div> </div> // 在需要监听的节点里，还有嵌套节点的情况下，需要注意 $('.outer').on('click', (event) => { console.log(event.target) // 获取的是点击的对象 inner console.log(event.currentTarget) // 获取的监听的对象 outer }) 所以在点击 cc的时候，event.target获取到的是点击的元素对象，而监听的对象就需要改成这样获取 event.currentTarget，这个才是function 下的 this typescript 自定义声明文件 TypeScript 是javascript的超集，用起来那是一个爽啊，谁用都说好 公司内部研发了一套UI框架，在配合ts使用的时候，发现很多方法缺少声明，所以我们需要编写声明文件，官方地址如下 typescript-声明文件 鹅外话 css的格式化，我们推荐使用 csscomb ，且它还支持在线生成规则，不能在人性化了，目前对主流编辑器和构建工具都支持良好 原文发布时间为：2018年07月02日 原文作者： 小黎也 本文来源： 掘金 如需转载请联系原作者
2018-07-17
优秀的个人博客,低调大师

我的 AI 辅助开发工程化实战

> **🚀 进化之路：从"人教 AI"到"AI 带人**" AI 可以写代码，但它不知道该做什么；AI 可以替我写，但不能替我想。 会写代码不再是核心能力**，会思考、会定规范、会审代**码，才是。 --- ## 写在前面：一个"工具人"的自白 最近我陷入了一种奇怪的状态—— **我感觉自己成了一个工具人。** 每天都在尝试各种 AI 工具，各种工具筐筐一顿往项目里造。今天是提示词工程，明天是 MCP，后天又是 Skill、Rules…… 从前是向 ChatGPT 提问代码，再把回答粘贴到 IDE；到如今是各路 AI 辅助编程工具轮番上阵。 一路走来，我学会了什么？ **Prompt 工程、项目规划、规范约束的能力。** 好像都不是，我什么也不会 各种概念满天飞：MCP、Skill、Agent……项目里疯狂一顿 AI 炫。 但说实话，AI 能力的扩展也确实让我的专业能力得以延伸——**我可以不知道，AI 知道就够了。** 但我真正的目标，不是被工具牵着走。 **我的终极目标：成为那个驾驭它们的老板。** --- ## 开篇：一个真实的"翻车"现场 > "帮我实现一个 XX 功能" AI 秒出代码，看起来还不错，简单体验了一下功能，好像是那么回事... 但仔细一看：class 组件？我们用的是函数组件；全局 CSS？我们用的是 UnoCSS；命名风格也不对... 改完这些，时间都花在"纠错"上了。最后花在"纠错"上的时间，比自己写还长。 **这种"AI 写完人来收拾残局"的经历，是不是很熟悉？** ### 😫 常见痛点与根因分析 |😫 痛点|🔍 根因| | --- | --- | |代码风格和项目不一致|AI 不了解项目规范| |同一问题，换个上下文答案完全不同|AI 没有"记忆"| |大需求一次生成，质量惨不忍睹|上下文超载（Context Overflow）| |每次都要重复解释项目背景|知识没有沉淀| |调教好的提示词，换个项目又要重来|经验无法复用| **今天分享我探索出的两个核心武器**： 1. **OpenSpec** —— 规范驱动，让 AI 输出可控 1. **OpenSkills** —— 能力增强，让经验可复用 --- ## 一、OpenSpec：建立 AI 的"数字围栏" ### 核心理念 > **AI 是纯执行角色，你给的边界越清晰，输出越可控** 把 AI 想象成"超级实习生"： - ✅ 执行力强、不知疲倦、知识面广 - ❌ 但需要明确的指令和规范，否则容易"自由发挥" **一个判断标准**：如果人类工程师无法明确说出在给定情况下应该怎么做，AI 智能体也不能做得更好。 与其让人在 review 时逐步想起遗漏告诉 AI，不如建立系统化的上下文管理，让 AI 自动获取**精简且高信号**的信息。 ### 三层规范体系 ``` ┌─────────────────────────────────────────────────┐ │ 📄 Context（上下文-项目地图） │ ← 项目是什么 ├─────────────────────────────────────────────────┤ │ 📏 Rules（代码规范-自动驾驶辅助线） │ ← 代码怎么写 ├─────────────────────────────────────────────────┤ │ 🔄 Workflow（流程规范-标准操作程序） │ ← 需求怎么做 └─────────────────────────────────────────────────┘ ``` --- ### 1️⃣ Context：让 AI "认识"你的项目 **问题**：AI 上下文窗口有限，一次塞太多会产生"记忆丢失"（Context Overflow） **解法**：结构化文档，分阶段沉淀 ``` context/ ├── 项目概览.md → 技术栈、目录结构 ├── 架构设计.md → 模块职责、数据流 ├── 当前需求.md → 需求背景、预期目标 └── 代码映射.md → 需求与代码的对应关系 ``` **进阶玩法：OpenSpec 规范优先** 在写代码之前，先让人和 AI 对规范达成一致： ``` specs/ ├── proposal.md → 问题陈述、方案概述、预期收益 ├── design.md → 技术设计、架构决策、接口定义 └── tasks.md → 实现清单、任务拆解、验收标准 ``` **流程**：需求输入 → 生成 proposal → 确认后生成 design → 拆解为 tasks → 逐个实现 → 归档 > 💡 好处：AI 在动手前就理解了"为什么做"和"怎么做"，减少返工 --- ### 2️⃣ Rules：让 AI 输出"像你写的" 制定代码风格规范（如：优先使用 TypeScript、UnoCSS），让输出像你亲手写的一样。 |原则|实践方法| | --- | --- | |需求理解是基础|反复确认："你懂了吗？不懂就问我"| |代码理解是参考|用 md 文档沉淀现有代码的设计意图| |规范统一是保障|制定代码风格规范，保持一致性| --- ### 3️⃣ Workflow：需求实现三步走 |步骤|做什么|关键话术| | --- | --- | --- | |聊需求|确保 AI 理解|"你懂了吗？不懂哪里？"| |定方案|对齐技术方案|"你打算怎么实现？最佳实践是什么？"| |分步做|小步快跑|"先做 xxx，完成后再做下一步"| > ⚠️ **黄金法则：永远不要让 AI 一口气完成大需求** 任务越小 → AI 完成度越高 → Review 越轻松 ### OpenSpec 小结 |层级|作用|效果| | --- | --- | --- | |Context|让 AI 了解项目|不用每次重复解释| |Rules|统一代码风格|输出质量稳定| |Workflow|规范开发流程|小步快跑，可控| > 💡** 核心价**值：让 AI 输**出可控、可预**期 --- ## 二、OpenSkills：让经验"原子化"与资产化 ### 什么是 Skill？ > **Skill = 可复用的能力单元 = 提示词 + 文档 + 脚本** 简单说：**Skill 就是 .md 格式编写的"技能包"** 本质是把专家的"最强状态"打包成 SOP，让经验在 Git 仓库里持续演进。 ### 💡 为什么需要 Skill？ |优势|说明| | --- | --- | |按需加载|需要时再喂给 AI，不占用宝贵的上下文空间| |全员外挂|让新人的指尖瞬间具备架构师的经验| |可移植性|复制一个文件夹，即可完成团队能力的快速迁移| --- ### 知识复利的演进路径 随着开发次数的增加，从最初的"规范化命名"到"提取自定义 Hooks"，再到最后的"AI 预设脚手架"，开发效率会从"小时级"降至"分钟级"。 |阶段|你的动作|产生的"复利"| | --- | --- | --- | |第 1 次|规范化命名与文档|以后不用翻设计稿找尺寸| |第 2 次|提取 useHooks|业务逻辑与 UI 彻底解耦| |第 6 次+|配置化/脚手架/AI 预设|开发效率从"小时级"降至"分钟级"| > 💡** 我们复用的是思想、模式和最佳实践，而不仅仅是代码实现**。 --- ### 如何自己制作 Skill？ **三步搞定**： 1. 新建文件夹 `skills/my-custom-skill/` 1. 编写 `SKILL.md`（定义触发条件、执行流程、规范要求） 1. 添加配套资源（docs/、scripts/，可选） **SKILL.md 模板**： ``` --- name: my-custom-skill description: 这个技能做什么 --- # 技能说明 ## 触发条件 当用户需要 xxx 时触发 ## 执行流程 1. 第一步做什么 2. 第二步做什么 ## 规范要求 - 规范 1 - 规范 2 ``` ### OpenSkills 小结 |维度|无 Skill|有 Skill| | --- | --- | --- | |效率|每次重复解释|一次加载，直接干活| |质量|靠运气|靠规范| |复用|经验在脑子里|经验在文件里| |协作|口口相传|复制粘贴| > 💡** 核心价**值：让经**验可复用、可传**承 --- ## 三、1 + 2 = 最大化效能 ### 完整工作流 ``` ┌──────────────────────────────────────────────┐ │ 完整工作流 │ ├──────────────────────────────────────────────┤ │ 📄 Context → AI 了解项目背景 │ │ 📏 Rules → AI 遵循代码规范 │ │ ⚡ Skill → AI 具备专业能力 │ │ 🔄 Workflow → 人机高效协作 │ └──────────────────────────────────────────────┘ ``` ### 知识的复利效应 ``` 需求 #1 ───→ 建立 context/（从0到1，投入） 需求 #2 ───→ 复用 context/（边际成本开始下降） 需求 #3-5 ──→ 沉淀 rules/（规范逐渐完善） 需求 #6+ ───→ 封装为 Skill（能力产品化） 团队共享 ───→ 全员复用（知识复利爆发） ``` ### 效果对比 |阶段|传统模式|OpenSpec + OpenSkills| | --- | --- | --- | |新人入职|老人讲解 4-7 小时|加载文档 20 分钟| |首次质量|不稳定，靠运气|稳定，有规范保障| |知识传承|口口相传，易丢失|文件化，可追溯| |边际成本|固定不变|持续递减| --- ## 四、核心理念转变：从代码复用到规范复用 AI 时代最大的变化是**代码生成成本的急剧下降**。 当编写一个新组件的边际成本接近于零时，我们为什么还要承受复杂组件带来的维护负担？ **新的解决思路**： 与其构建一个极其复杂的"万能组件"来适配所有场景，不如为每个具体场景定制专门的实现： - 为每个具体场景定制专门的组件实现 - 通过 AI 按需生成，而不是试图构建万能组件 - 让每个组件专注于特定场景，逻辑更简洁清晰 我们通过规范约束 AI 快速生成，保持逻辑的简洁与纯粹。 **规范驱动开发的价值**： |维度|传统方式|规范驱动| | --- | --- | --- | |复用方式|复杂的万能组件|简洁的专用组件| |质量保障|依赖个人经验|规范约束 AI 生成| |开发效率|小时级|分钟级| |真正复用的是|具体代码实现|思想、模式和最佳实践| > 💡** 这就是基于规范的复用——我们复用的是设计理念、接口规范和最佳实践，而不是具体的代码实现**。 --- ## 五、我的思考与展望 ### 只要提示词写得够好？ 有段时间我沉迷于打磨提示词，觉得"只要我的提示词写得够好，AI 就能完美执行"。 但后来我发现，**提示词只是冰山一角**。 真正让 AI 高效工作的，是背后那套完整的规范体系：Context 让它了解项目，Rules 让它遵循规范，Skill 让它具备能力，Workflow 让协作顺畅。 ### 未来的畅想 我越来越相信一件事： > **只要文档落地、规范落地、维护得好，未来人写代码就变得越来越简单了，0门槛。** 当规范足够完善，当 Skill 库足够丰富，当 Context 足够清晰——AI 就能自动完成从需求理解到代码生成的全过程。 **人的角色会从"代码编写者"变成"规范制定者"和"质量把关者"。** ### 核心公式 > **AI Coding 效能 = 需求理解能力 × 技术判断力 × 规范完善度** 三者缺一不可，规范是放大器！ ### 不变的核心 工具在进化： - 2024：Agent 爆发 - 2025：MCP / OpenSpec / Skill ... - 未来：更多可能 但有些东西永远不会变： > **需求理解**和**技术判断**永远是核心竞争力 会写代码，不再是核心能力。**会思考、会提炼观点、会审校**，才是。 我们正在完成从"代码编写者"到"规范制定者"与"质量把关者"的转型。 从"会写代码"到"会提需求 + 会审代码"——这是我们这一代开发者必须完成的转型。 --- ## 写在最后 不是所有工作都值得交给 AI，但**所有低价值的重复性工作都应该被 AI 替代**。 这样做的核心价值不在于省了多少人力，而在于让我们得以从繁琐的执行中抽身，**专注于更高价值的事情**：设计流程、优化体验、创造新价值。 **我把我的经验都写进了规范里，祝我早日成为一个 Prompt 工程师管理师！** --- > 🔗** 一个小技**巧：如果你在 AI 编程中，同一个错误出现了 2 次以上，或者某个需求反复不符合预期，请务必让 AI 记下来（写入 Rules）。这能显著提高效率，避免重复踩坑。 --- **路漫漫其修远兮，吾将上下而求索。** 期待和大家一起探索 AI 辅助开发的更多可能！ ---
2026-07-20
优秀的个人博客,低调大师

数字孪生架构工程化体系的思考与落地

# 数字孪生不是 3D 大屏：一套可落地的架构方法 > 很多人以为数字孪生就是把设备画成 3D 模型放到大屏上转一转，大错特错。真正的数字孪生，是一套从感知到决策的完整工程体系。本文基于工程实践，拆解一套可复用的数字孪生总体架构与关键技术，不谈具体行业，只讲通用方法论。 --- ## 🧭 一、先破除误区：数字孪生到底是什么 先给结论：**数字孪生不是三维可视化，而是"物理实体"与"数字镜像"之间持续双向映射、同步进化的一套系统工程。** 它至少要满足三个特征： 1. **实时映射**：物理世界每时每刻的状态，都能在数字世界里找到对应镜像 2. **可计算可仿真**：镜像不只是"看"的，还能被推演、预测、优化 3. **闭环反哺**：仿真和决策的结果，能反过来指导物理世界的运行 用一张图理解它的本质： ![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/2d3e0257f8bf9012a706d89fadff0cf1.png) > 一句话：**物理世界产生数据，数字世界产生价值，价值再反哺物理世界。** --- ## 🏗️ 二、总体架构：1+1+1+N 管控体系 一套能落地的数字孪生平台，推荐采用 **"1+1+1+N"** 总体架构：**一库（时空大数据）**、**一平台（数字孪生系统平台）**、**一张图（综合态势图）**、**N 应用（多场景智慧应用）**。 ![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/f95920c29db02ddd50ea9251d9d9d8c1.png) - **一库**：把空间数据、物联数据、业务数据、模型数据统一沉淀，解决"数据孤岛" - **一平台**：承载数字孪生模型创建、BIM 可视化引擎、多源数据融合等通用能力 - **一张图**：在统一地理坐标系下，把所有要素叠加呈现，辅助管理者全面掌控 - **N 应用**：基于底座灵活生长出的各类业务场景，按需扩展 > 核心思想：**底座要稳，平台要厚，应用要薄。** 通用能力沉淀到平台层，业务应用才能快速搭建、持续迭代。 --- ## 🧱 三、五层技术架构拆解 把这套体系落成技术栈，可以拆成五层。每一层职责单一、边界清晰： | 层级 | 核心职责 | 关键技术点 | | --- | ---------- | ---------------------- | | 感知层 | 采集物理世界数据 | 各类传感器、智能终端、物联网接入 | | 数据层 | 数据治理与存储 | 清洗、格式转换、分布式存储、区块链安全存证 | | 模型层 | 构建可计算的虚拟镜像 | 多维度建模、BIM 可视化引擎、模型实时更新 | | 应用层 | 支撑业务场景 | 监测、预测、调度、培训、故障诊断 | | 展示层 | 多端统一呈现 | PC、移动、大屏，无插件浏览器渲染 | > 五层之间通过标准接口（REST / Socket / MQ 等）通信，层与层解耦，任何一个环节升级不影响整体。 --- ## ⚙️ 四、四个关键技术，缺一不可 ### 1. 高精度建模技术 单一建模方法撑不起复杂系统，工程上采用**三类方法组合**： - **机理建模**：基于物理规律（如电池等效电路、流体方程），可解释性强 - **数据驱动建模**：基于历史数据学习，擅长复杂非线性关系 - **混合建模**：两者结合，取长补短，是大型系统的必然选择 ### 2. 多源数据融合与处理 现实中的数据是"脏"的：结构化（电表数据）、半结构化（设备日志）、非结构化（图像视频）混杂。必须经过**清洗、转换、关联分析**，消除噪声和不一致，才能喂给模型。 ### 3. 实时通信与时间同步 - 通信手段：5G、工业以太网、电力线载波等多链路冗余 - 时间同步：依托 GPS / 北斗授时，保证各环节数据在时间轴上严格对齐——**时间不同步，孪生即失真** ### 4. 人工智能与机器学习 深度学习、强化学习、支持向量机等算法，用于功率预测、负荷预测、故障诊断、优化调度决策，让数字孪生从"看见"升级到"预见"。 ![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/c2b80e0b49c6c9808163623c7601c81c.png) --- ## 📐 五、建模标准体系：容易被忽略的地基 很多项目模型建了一大堆，最后"合不到一起"，根因是**缺一套统一的建模标准**。规范化的建模体系包含两个维度： ### 模型单元分级 从粗到细共四级，可嵌套： ![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/66b37e3ab73b46d5e9f8bdb46cba8206.png) ### 三维精度体系 | 维度 | 等级 | 说明 | | --------- | --------------- | ---------------- | | 模型精细度 LOD | LOD1.0 ~ LOD4.0 | 从项目级到零件级的最小单元要求 | | 几何表达精度 G | G1 ~ G4 | 从符号化识别到制造加工级精度 | | 信息深度 N | N1 ~ N4 | 从身份/定位信息到资产/维护信息 | > 关键原则：**"够用就好，按需取级"** —— 在满足设计深度和应用需求的前提下，选取较低等级的几何精度，避免过度建模拖垮性能。同时每个属性值都要标注**数据来源**（设计、建造、厂家、软件等），保证可追溯。 --- ## 🚀 六、BIM 可视化引擎：轻量化与高性能渲染 数字孪生最终要在浏览器里"跑得动"，原始模型动辄几个 G，**轻量化是命门**。工程实践的技术链路如下： ![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/1549650cffb13438ac42164239d7a788.png) ### 引擎的五大能力要求 1. **多格式兼容**：兼容 Revit、DWG、IFC、OSGB、SHP、CityGML 等主流格式，BIM 与 GIS 数据同场融合 2. **统一坐标基准**：内置 CGCS2000、WGS84、地方坐标系动态转换，多源数据精准套合 3. **丰富仿真效果**：PBR 物理渲染、动态光照阴影、粒子系统（雨雪雾/烟雾）、物理引擎（碰撞/刚体） 4. **灵活易用接口**：开箱即用 + 深度可调，GPU 能力自动探测，支持降级软渲染 5. **插件化扩展**：主类 + 插件类双机制，支持按需定制、热更新、跨项目复用 > 实测经验：**原生模型经轻量化后体积可压缩约 90%**，同时保留构件级交互能力，浏览器内丝滑运行。 --- ## 🔄 七、全生命周期应用：从建设期到运营期 数字孪生不是"建成才用"，而是**从建设期就开始积累数字资产**： ![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/822dd23e2b4c4cc44b2304006ac60965.png) ### 建设期典型应用 - **4D 进度模拟**：进度计划与实际进度动态对比，偏差超阈值自动预警 - **5D 资源优化**：材料需求预测、最优采购方案、成本预警联动 - **数字化移交**：把建设期所有模型、数据、档案完整移交运营期 ### 运营期典型应用 - **全景监测**：三维漫游、设备状态实时映射、健康度评估 - **智能巡检**：视频监控 + AI 识别，替代人工巡检高危区域 - **预测调度**：预测以及优化运行调度 - **故障自愈**：快速定位故障、模拟影响范围、生成恢复方案 > 核心观点：**建设期交付的不仅是工程，更是一套"活的"数字资产；运营期吃的就是这套资产的"红利"。** --- ## 🗺️ 八、实施路径：三阶段滚动推进 数字孪生建设切忌一步到位，工程上采用三阶段滚动： | 阶段 | 周期 | 核心任务 | | --- | ------ | ------------------------------- | | 阶段一 | 约 2 个月 | 需求调研、方案设计、设备选型、平台搭建、感知层与数据层初步建设 | | 阶段二 | 约 3 个月 | 构建各环节孪生模型、参数调试验证、多源数据融合、虚实联调 | | 阶段三 | 约 2 个月 | 平台试运行、根据反馈持续优化模型与应用功能 | > 落地建议：**先跑通一个最小闭环，再逐步扩场景**。一上来就追求"全要素、全覆盖"，大概率烂尾。 --- ## 💎 九、结语：数字孪生的本质是"数据资产工程" 回到开头的问题：数字孪生和 3D 大屏的区别是什么？ - 3D 大屏是**结果展示**，数字孪生是**过程治理** - 3D 大屏服务于"看"，数字孪生服务于"算"和"决策" - 3D 大屏是一次性投入，数字孪生是全生命周期持续增值的数字资产 一套成功的数字孪生体系 = **标准（建模规范）+ 架构 + 引擎（轻量化渲染）+ 数据（融合闭环）+ 应用（场景落地）** 五要素缺一不可。
2026-08-06

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Spring

Spring

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

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册