- 博客(1079)
- 资源 (17)
- 问答 (3)
- 收藏
- 关注
原创 【HarmonyOS 7 沉浸光感深度实战】 04 interactive、lightEffect 与完整参数实验
materialColor 改变材质整体色调,透明度决定了颜色和背景之间的平衡。colorInvert 需要薄材质、资源颜色和明显的明暗背景。applyShadow 则要和项目原有的阴影体系明确分工。按下卡片以后,interactive 负责交互形变,lightEffect 负责触点附近的光感。先观察纯形变,再加入光感和颜色,整个过程更容易理解。
2026-08-07 09:55:45
226
原创 【HarmonyOS 7 沉浸光感深度实战】 03 五档 ImmersiveStyle 到底怎么选
本文探讨了HarmonyOS中五档沉浸式材质样式(ImmersiveStyle)的选择策略。通过对比ULTRA_THIN到ULTRA_THICK五种厚度,分析了材质透明度、背景信息保留度、前景稳定性及组件视觉重量的差异变化。文章指出选择材质时需综合考虑组件面积、位置(顶部/底部)、背景复杂度及内容信息量,并给出具体场景的初始选择建议。
2026-08-06 09:40:08
200
原创 【HarmonyOS 7 沉浸光感深度实战】 02 全局开关、MaterialState 与最小 Demo
文章摘要: 文章解析了 HarmonyOS 中 ArkUI 与 HDS 组件的沉浸光感材质配置,重点探讨了 MaterialState 的三种状态(DEFAULT、ENABLE、DISABLE)的作用域及使用场景。DEFAULT 允许普通组件主动设置材质,ENABLE 会扩展系统组件的默认材质范围,而 DISABLE 会全局关闭沉浸材质效果。配置需通过 module.json5 的元数据实现,且每次修改需重新构建安装应用。测试页面通过状态信息、主动材质卡片和系统组件验证效果差异,帮助开发者排查问题。
2026-08-05 10:07:28
314
原创 【HarmonyOS 7 沉浸光感深度实战】 01 ArkUI 与 HDS 两套接口如何选择
本文介绍了在HarmonyOS 7应用中实现沉浸光感效果时,需要注意的两套不同接口及其适用场景。普通ArkUI组件使用uiMaterial和ImmersiveMaterial接口,而HDS组件(如HdsNavigation、HdsTabs等)则使用hdsMaterial接口。文章详细说明了如何为普通ArkUI组件创建THIN材质,以及如何为HDS组件查询和设置材质类型与等级。此外,还强调了应用配置、设备算力和系统设置对沉浸光感最终效果的影响,并提供了相关配置建议和注意事项,帮助开发者避免常见混淆和错误。
2026-08-04 09:50:00
188
原创 【HarmonyOS 7开发者前瞻】12 HarmonyOS 7 API 26 验证问题记录指南:环境、日志与回归清单
本文针对HarmonyOS 7 API 26 Beta阶段的实测问题记录提出了系统化建议。文章强调测试记录需包含环境、现象、复现路径和日志等关键要素,并区分不同阶段问题类型:编译构建类需检查SDK配置、依赖冲突等;安装运行类需关注完整链路验证。提供了JSON模板和表格两种标准化记录方式,建议区分本地/远程真机环境,并将工具建议与最终结论分开记录。通过结构化的问题分类和记录方法,帮助开发者高效定位API 26迁移过程中的各类问题,提升测试验证效率。
2026-07-31 08:50:45
269
原创 【HarmonyOS 7开发者前瞻】11 HarmonyOS 7 Beta 更新后怎么办?开发者需要重新验证这些结论
HarmonyOS 7 API 26 Developer Beta1 本身就是面向开发调测的测试活动,能够提前体验 API 26.0.0 Beta1 版本的新能力、新特性,并配合 DevEco Studio 开展应用开发。这个阶段适合持续验证、记录问题和反馈结果,但不适合把某一次测试结论直接写成长期结论。
2026-07-30 09:30:32
238
原创 【HarmonyOS 7开发者前瞻】10 HarmonyOS 7 真实项目适配路线图:API 26、AI / Agent 与多端改造优先级
本文针对已有HarmonyOS 6原生项目适配HarmonyOS 7的路线规划,提出分阶段、渐进式的适配策略。建议首先建立工程基线,确保项目在API 26环境下能编译、运行主流程;其次梳理业务功能为能力清单,区分高低风险能力;最后选择最小AI/Agent链路进行验证,避免大规模重构。适配过程强调"先保证能跑,再整理能力边界"的原则,通过独立分支管理、主流程记录和能力分级等方式降低风险,待文档、设备和业务链路稳定后再逐步接入新特性。
2026-07-29 09:52:29
236
原创 从企业任务到长链路智能体,天津 ADG 沙龙呈现 Seed 2.1 的完整技术落地路径
7 月 27 日,火山引擎 Agent Developer Group 天津站围绕 Seed 2.1 豆包大模型点亮场景化应用展开了一场线下技术分享。四场主题分别从企业 AI 落地、教学应用、多模态客服和长链路智能体工程化切入,呈现了大模型进入真实业务后的不同形态。
2026-07-29 09:06:56
297
原创 从业务材料到产品交付:用两个企业任务实测豆包 Seed 2.1 Pro 与 Turbo
摘要 企业应用大模型的两个典型场景在豆包Seed 2.1系列模型中得到体现。Pro版本针对复杂业务探索任务,成功从零散材料(访谈记录、管理制度等)生成了完整的产品方案、开发任务和可交互原型,覆盖了产品建设全流程。Turbo版本则擅长规模化处理,将40条业务反馈高效分类为标准需求池、重复项清单等5类运营成果,实现了业务反馈的自动化分流。测试表明,Pro适合产品启动和重大调整阶段,Turbo更适用于日常运营和批量处理,两者配合能覆盖企业从探索到规模化应用的全周期需求。
2026-07-28 13:37:01
335
原创 从大模型到第一个 AI 作品,我在济南 ADG 沙龙看到了一条完整的 Vibe Coding 路径
我负责第一场《AI 通识课 从大模型到智能体时代》,潘俊杰老师分享《如何用 AI 定义好你的产品 PRD》,孙斌老师则通过《用 TraeWork × AgentPlan 打造你的自媒体工作流》,把前面的模型能力和需求定义进一步带入实际执行。
2026-07-22 03:27:51
260
原创 大模型正在从会回答走向能交付:Seed 2.1、Agent 与企业 AI 落地全解析
真正拉开差距的不会是使用过多少 AI 工具,而是能否把一项工作拆清楚、跑稳定、形成模板,并持续交付可以被客户和业务接受的结果。模型决定任务能力的上限,工作流和组织能力决定这些能力最终能够产生多少价值。
2026-07-21 01:01:48
231
原创 Agent 进入业务现场以后,我重新理解了 OceanBase Lakebase
我看到 OceanBase 这次发布 Lakebase、DataStudio、DataPilot,以及 PowerMem、PowerRAG 之后,我的关注点更偏向业务落地后的数据问题:Agent 进入业务以后,数据从哪里来,怎样保持最新,权限怎样跟着业务变化,非结构化内容怎样和结构化数据一起被检索,评测环境怎样隔离,长期记忆又怎样沉淀下来。
2026-07-20 08:07:37
957
1
原创 【HarmonyOS 7开发者前瞻】09 HarmonyOS 6 项目升级 API 26 前,先检查这张兼容性清单
如果你手里已经有一个 HarmonyOS 6 项目,比如会议随记、待办工具、本地生活助手、资料整理工具,第一轮迁移目标应该是:先让项目在 API 26 环境下能够编译、安装、启动、运行主流程,再判断哪些 HarmonyOS 7 新能力值得接入。
2026-07-13 10:42:57
5855
原创 【HarmonyOS 7开发者前瞻】08 DevEco Code 与 DevEco CLI 工具链,从 AI 写代码到鸿蒙工程验证闭环
DevEco Studio 本身已经覆盖 AI 辅助编程、编译构建、UI 实时预览、代码调试、性能调优、模拟器等能力。DevEco Code 面向 HarmonyOS 开发场景,覆盖需求、设计、开发、验证四个阶段;DevEco CLI 则面向编程 Agent,提供从工程创建、语法检查、编译构建到运行调测的全流程工具,并将鸿蒙开发知识资源提供给 Agent 调用。
2026-07-10 08:16:38
6037
原创 【HarmonyOS 7开发者前瞻】07 HarmonyOS 7 空间化与多端适配指南,普通应用先改这 5 类页面
这里我们先不要急着把空间化理解成复杂 3D 页面,也不要把多端适配简单理解成平板拉宽。对于大多数工具类、办公类、内容类、会议类应用来说,第一阶段更适合做的是页面层次、信息密度、窗口宽度、交互确认和多端布局这些基础工作。
2026-07-09 09:38:34
8154
原创 【HarmonyOS 7开发者前瞻】06 HarmonyOS 7 AI 能力接入前,先用业务场景判断优先级
HarmonyOS 7 的新能力方向里,智能化部分已经包括 Skill、Agent 和视觉 AI 能力。Skill 关注应用功能被系统级智能入口调用,Agent 关注系统能力和模型能力开放,视觉 AI 能力关注端侧视觉 AI 处理。对于应用开发来说,这些能力并不是越多越好,真正关键的是把它们放到合适的业务环节里。
2026-07-08 08:56:32
2571
原创 【HarmonyOS 7开发者前瞻】05 HarmonyOS 7 Agent 接入指南:从任务链路到确认机制
HarmonyOS 7 的智能化方向已经把 Agent、Skill 和 AI 开放能力放到同一条链路里。Agent 系统能力和模型能力开放,支持 Agent 能力构建和已有 Agent 的 A2A 接入,用来帮助应用 Agent 对接系统级智能入口。所以,Agent 接入前的重点,可以先落到一个更工程化的问题上:你手里的应用,是否已经把任务边界设计清楚。
2026-07-07 09:24:49
8026
原创 【HarmonyOS 7开发者前瞻】04 HarmonyOS 7 应用能力拆分方法:页面功能如何走向 Skill
Skill、Agent、AI 开放能力被放到了系统智能化方向里,应用功能不再只停留在页面内部。HarmonyOS 7 新能力页面里,Skill Vibe Coding 覆盖 Skill 开发、调测、审核、上架,并且目标是让应用功能能够被系统级智能入口调用。
2026-07-06 08:18:53
9444
原创 【HarmonyOS 7开发者前瞻】03 HarmonyOS 7 API 26 新 API 找不到,先用 5 层状态判断能力可用性
拿到 HarmonyOS 7 API 26 Beta 之后,最容易遇到的一类问题,就是发布会或者新能力页面已经出现某个能力,但在本地 SDK、API Reference 或项目代码里暂时找不到对应入口。
2026-07-04 09:36:53
8242
原创 【HarmonyOS 7开发者前瞻】02 HarmonyOS 7 API 26 Beta 上手前,开发者先完成 8 项工程验证
拿到 HarmonyOS 7 API 26 Beta 之后,大家第一反应很容易是先体验系统界面,看看新动效、新入口、新智能能力有没有明显变化。但如果你是从应用开发角度看这个版本,第一轮更应该做的事情其实更基础。先别急着判断某个新能力是否值得接入,也别急着把现有项目改到 API 26。Beta 阶段最重要的工作,是先确认工程环境、设备条件、存量项目、权限签名、API 可见性、运行日志这些基础链路是否稳定。
2026-07-03 09:31:49
11082
原创 【HarmonyOS 7开发者前瞻】01 HarmonyOS 7 开发者适配路线图:从 API 26 Beta 到 Skill、Agent 与 AI 工具链
摘要: HDC 2026后,HarmonyOS 7的新特性(如Agent、Skill、AI能力等)对开发者提出了工程实践挑战。文章建议开发者优先基于API 26 Beta版建立验证基线,确保工程环境稳定后逐步验证新能力。针对Skill开发,需从页面逻辑转向能力拆分,明确输入、输出和异常处理,以适配系统级智能调用。Agent接入则需预先梳理任务边界,避免过度依赖会话交互。通过分层判断(文档、SDK、测试、项目验证)和结构化整理(如能力清单),开发者可平衡新特性适配与现有项目维护,避免盲目重构或停滞等待。
2026-07-02 08:53:12
10678
原创 从“看图说话”到“动手干活”:看看国产多模态模型在生产场景下的真实表现
本文针对国内三款多模态模型(Step 3.7 Flash、Qwen3.6-flash、MiniMax M3)进行了生产环境下的实测对比。通过流程图解析和发票信息提取两个真实业务场景,从生成质量、响应速度和成本三个维度评估模型表现。测试结果显示:三款模型在任务完成质量上基本持平,均能准确理解多模态输入并输出结构化结果;但在性能方面,Step 3.7 Flash在响应速度(最快达5.6s)和token消耗(最低0.006元/次)上更具优势。实验证实多模态模型能有效提升业务流程图解析和票据信息自动化录入的效率,具
2026-07-01 22:38:00
648
原创 Agent 场景下,谁才是真正好用的 Flash 模型
国产大模型近期密集发布新版本,包括Step 3.7 Flash、MiniMax M3、GLM-5.2和Kimi K2.7 Code等,各自侧重不同方向:性价比、长上下文、通用开源和编程场景。行业趋势显示,大模型竞争已从单纯性能比拼转向Agent应用能力,更注重实际场景的稳定性与性价比。 测试选取Step 3.7 Flash等"效率型"模型,通过真实项目对比评估。案例包括搭建开发者日志站(与DeepSeek V4 Flash对比)、GitHub项目雷达(与Gemini 3.5 Flash对比)和源码解读任务。
2026-06-29 22:56:23
602
原创 GitHub Copilot 上下文工程:让 AI 编程更接近真实项目
Copilot 不是在真空里写代码。它会根据当前文件、打开的文件、工作区索引、你显式引用的文件、聊天历史、项目自定义指令、工具执行结果这些信息生成回答。上下文给得准确,它更容易沿着项目原有方式写;上下文混乱或者缺失,它就会回到通用模式。
2026-06-13 12:45:00
288
原创 GitHub Actions 可复用工作流设计模式:把 CI/CD 重复逻辑收起来
GitHub Actions 本身已经提供了几种复用能力。可复用工作流负责把一套 job 编排抽出来,复合 Action 负责把多步操作收成一个 action,OIDC 和 environment 则负责把部署权限和密钥边界管住。它们经常被放在一起讲,但真实落地时不能混用。
2026-06-13 09:30:00
232
原创 GitHub Copilot Free 免费层级使用指南:AI 编程从这里开始
GitHub Copilot Free 刚发布的时候,我最先关注的不是它免费,而是它终于把 AI 编程的入口放到了一个足够低的位置。只要有个人 GitHub 账号,就能在 VS Code 和 GitHub 里体验 Copilot,不需要先绑定信用卡,也不需要先判断自己值不值得买月费订阅。
2026-06-12 14:15:00
465
原创 GitHub Agent HQ 多智能体协作:Copilot、Claude 与 Codex 怎么分工
我以前用 AI 编程工具时,经常会遇到一个很现实的问题:每个工具都有自己擅长的地方,但上下文很难跟着走。Claude 适合分析复杂逻辑和做架构判断,Codex 适合快速执行和产出代码,Copilot 又和 GitHub、VS Code、PR、Issue、代码审查这些流程贴得更近。单独看,它们都能解决一部分问题;放到真实项目里,就会出现来回切换、反复解释项目背景、复制粘贴代码片段的问题。
2026-06-12 09:30:00
354
原创 GitHub Copilot CLI 命令行工具深度使用指南
我以前使用 Copilot,主要还是在 IDE 里。写代码时补全一段逻辑,选中文件让它解释一下,或者在侧边栏里让它帮我改一个函数。这种方式很方便,但它没有覆盖我一天里所有开发动作。很多任务其实发生在终端里。拉分支、看 diff、跑测试、查日志、定位构建失败、处理 PR、整理发布说明,这些动作本来就不在编辑器里完成。每次终端里遇到问题,再切到 IDE 或浏览器问 AI,节奏就会被打断一次。问题越复杂,来回切换越多。
2026-06-11 13:30:00
369
原创 GitHub Actions 可调用工作流:跨仓库复用与团队协作实践
我以前维护多个仓库的 GitHub Actions 时,最怕遇到一类需求:把所有项目的 CI 都升级一遍。表面上只是把 Node 版本从 18 改到 20,或者把 `actions/cache` 的写法调整一下。真正动起来才发现,十几个仓库里的 workflow 长得差不多,但又不完全一样。有的多了安全扫描,有的多了 artifact 上传,有的部署前还要跑一段自定义脚本。每个仓库复制一份 YAML,短期看起来省事,时间长了就会变成维护负担。
2026-06-11 09:30:00
364
原创 GitHub Copilot CLI 斜杠命令,终端里的 AI 开发控制台
GitHub Copilot CLI 的意义就在这里。它把 Copilot 放进命令行环境里,让 AI 不再只是回答问题,而是可以围绕当前目录、当前仓库、当前会话继续工作。2025 年 9 月进入 public preview,2026 年 2 月进入 GA 后,它已经从早期的终端问答工具,变成了更完整的 terminal-native coding agent。
2026-06-10 13:30:00
276
1
原创 【鸿蒙原生开发会议随记 Pro】用 AppStorage 做会议列表和联系人列表的刷新信号
这套机制里会用到 ArkUI 的 `AppStorage`、`@StorageProp` 和 `@Watch`。我在项目里把它们放在工作台、会议列表、联系人列表这些页面之间使用。页面当前可见时马上刷新,页面隐藏时先记录状态,等切回来再检查版本差异。这样可以减少隐藏页面的无效查询,也能让列表、统计、选择器在需要的时候拿到最新数据。
2026-06-10 09:19:02
3219
原创 GitHub Stacked PRs,让巨型 PR 变成可管理的代码堆栈
GitHub 在 2026 年 4 月公开了 Stacked PRs 的 private preview。它解决的正是这种大 PR 堆在一起的问题。一个大功能不再一次性塞进一个 PR,而是拆成一组有顺序的小 PR。底层 PR 先承接基础改动,上层 PR 再继续往前开发,整个链路在 GitHub 里形成一个 stack。
2026-06-09 13:45:00
410
原创 【鸿蒙原生开发会议随记 Pro】用 NavPathStack 收拢会议页面跳转和返回刷新
会议详情页进入编辑页以后,编辑页可能会修改标题、标签、参会人,也可能会调整时间轴笔记。编辑页保存并返回以后,详情页要重新读取当前会议;详情页再返回会议列表时,列表也要知道会议数据已经变化。这个过程如果只靠页面之间互相约定,时间一长就很容易忘记哪条路径负责刷新。
2026-06-09 10:18:22
4257
原创 GitHub Spark:自然语言能把全栈 AI 应用做到什么程度
GitHub Spark 的定位正好卡在这个位置。它不只是帮开发者补几段代码,也不只是生成一张好看的前端页面,而是让用户用自然语言描述应用,然后在浏览器里生成、预览、修改并发布一个全栈 Web 应用。
2026-06-08 21:25:15
416
原创 【鸿蒙原生开发会议随记 Pro】EntryAbility、SplashPage 与首页路由处理
应用可能刚从桌面冷启动,也可能已经在后台,只是系统重新投递了一个 Want。用户可能已经同意隐私协议,也可能是第一次安装后进入应用。首页的导航栈还没有创建之前,新建会议页没有稳定的承接位置。启动页保留动画以后,外部指令还要跨过 Splash 再交给首页,不能在中途丢失。
2026-06-08 08:54:07
1117
原创 Design.md 深入分析,把设计风格写进 AI 编程上下文
我第一次认真看 Design.md,是因为前端页面被 AI 改散了。这类问题不一定马上出现在代码层。页面能启动,组件也能渲染,按钮点击以后状态也会变化。麻烦在于多改几轮以后,页面开始不像同一个产品。第一次生成的卡片是 16px 圆角,第二次加弹窗变成 12px,第三次补空状态又带了很重的渐变背景。每一次单独看都能接受,合在一个项目里,风格就开始漂。
2026-06-07 18:52:23
357
原创 项目周会开了两年,我们的决策轨迹终于能看懂了
本文分享了技术团队使用会议随记 Pro 进行周会记录两年的实践经验。通过HarmonyOS 6悬浮窗实时打点标记关键决策节点,将分散的会议录音转化为结构化、可跳转的项目时间轴,有效解决新人追溯、跨团队对齐等痛点,让决策轨迹从"录完即走"变为持续生长的团队知识资产。
2026-06-06 14:00:00
229
原创 独立开发者做播客,录音整理怎么省点时间
独立开发者做播客时,录音整理往往比录制更耗时。本文介绍如何通过鸿蒙系统下的会议随记 Pro,实现边录边打锚点、秒跳剪辑、服务卡片快速启动等功能,将动辄数小时的回听整理压缩至一小时内,大幅提升播客后期效率。
2026-06-05 14:00:00
288
原创 讲课三小时,学生问的那道题在第几分钟
## 那道题,我到底讲到第几分钟了 上周三晚上,一位学生在微信问我:"老师,您课上讲的那道动态规划例题,能不能再给我理一下思路?" 我下意识打开手机的录音文件。三小时的课,只有一个孤零零的音频图标,文件名是"算法设计_20250601"。拖动进度条,前十五分钟是签到和作业点评,中间某个位置大概是例题,但具体哪一题、哪一分钟开始,完全没概念。我花了二十分钟在录音里反复横跳,最后干脆给学生重新讲了一遍。 这样的场景,每学期重复几十次。课堂录音我从来不缺,缺的是让录音真正能被检索、被复用的能力。 ## 课
2026-06-04 13:00:00
220
原创 鸿蒙 HarmonyOS 6 | Pura X Max 鸿蒙原生适配 20:基于真实折痕区域实现悬停态上下屏
我在处理 OCR 图片预览页时,真正需要关注的不是页面能不能被拆成上下两块,而是折痕区域到底落在页面里的哪个位置。Pura X Max 进入悬停态后,系统会把真实折痕可视化出来,模拟器里那条蓝色区域就是设备层面的折痕位置。业务页面要做的是避让这块区域,而不是再画一条自己的折痕条。
2026-06-04 07:16:01
317
C#实训项目 酒店管理系统 源代码 附数据库(学生自编)
2012-09-09
C#实训项目 酒店管理系统 源代码 完整版 附数据库
2012-09-13
酒店管理系统_项目需求+素材+知识点回顾
2012-09-09
【Go】Gin从入门到精通 实例代码01
2021-09-24
[内存虚拟硬盘工具].SuperSpeed.RamDisk.Plus.v10.0.1.0
2012-09-09
php模拟http请求的类
2013-12-05
加油(•̀ᴗ•́)و ̑̑
2021-06-19
晚上不睡查es文档,快放假我也是拼了[face]emoji:005.png[/face]
2021-04-27
TA创建的收藏夹 TA关注的收藏夹
TA关注的人
RSS订阅