add yangrudan.md

assignments/lesson1/yangrudan.md

@@ -0,0 +1,40 @@
+# 开源商业模式分析报告模板
+
+## 学员GitHub用户名: yangrudan
+
+## 选择的商业模式
+安卓商业模式（Android 商业模式）
+
+## 分析内容
+
+### 1. 商业模式概述
+安卓采用“开源基础 + 封闭增值服务”的双轨策略：AOSP（Android Open Source Project）以 Apache 2.0 开源，免费提供给手机厂商与开发者；Google 通过在设备上提供并绑定 Google Mobile Services (GMS) / Play Services、默认搜索与 Google Play 应用商店等闭源服务，将巨大设备规模转化为搜索流量、广告收入、应用分成与云/订阅服务收益，从而实现间接变现。
+
+### 2. 收入来源
+- 搜索广告（最大）：通过默认搜索引擎与 Chrome 将移动搜索流量导入 Google 广告生态，估算为数百亿美元级别（2024年移动广告估算 800–1000 亿美元）。
+- Google Play 抽成：对付费应用、应用内购买与订阅抽成（历史标准 30%，后续针对小开发者与订阅有降幅），估算抽成收入约 100–150 亿美元量级（总交易额 ~480 亿美元，抽成约 144 亿美元）。
+- GMS 授权/分成：尤在欧盟合规后对部分地区收取单台授权费或通过搜索分成实现间接收益（欧洲单台收费，其他地区以搜索分成为主）。
+- 云与订阅：Google One、YouTube Premium、Workspace 等（累计若干十亿美元）。
+- 硬件（Pixel）：用于示范与技术展示，营收较小，主要价值在生态控制与 AI 能力展示。
+
+### 3. 社区与生态
+- 社区基础：AOSP 开源代码、Linux 内核与上游社区贡献，吸引大量开发者与设备厂商参与。
+- 生态规模：全球活跃设备数 30 亿+，开发者 2000 万+，Google Play 应用 ~350 万。
+- 生态构建策略：免费开源吸引厂商与开发者，Play Services 提供关键基础服务（账号、推送、地图等）形成平台依赖，形成用户—开发者—厂商的双边/多边网络效应。
+- 区域差异：在中国大陆无 GMS，厂商与生态自建（HMS、各厂商应用商店）；在欧美/印度等市场，GMS 与 Play Store 为主导。
+
+### 4. 竞争优势
+- 规模效应：通过免费获取大量设备占领市场，形成规模化的流量与数据入口，增强广告变现能力。
+- 双轨架构优势：开源降低厂商准入门槛，封闭服务（GMS/Play Services）绑定关键体验与 API，兼顾开放与控制。
+- 网络效应：庞大的用户基数吸引开发者，丰富的应用又反向提升用户对平台的依赖。
+- 灵活的区域策略：在不同市场采用差异化策略（例如 Android Go 面向低端市场），实现全球覆盖。
+
+### 5. 挑战与风险
+- 反垄断与监管风险：欧盟与多个司法管辖区对预装捆绑、默认搜索等做出限制与罚款（如 2018 欧盟罚款），新法规（如 DMA）要求开放应用商店与侧载，影响既有变现策略。
+- 隐私与广告效率下降：隐私保护趋势（如淘汰广告 ID、Privacy Sandbox）可能削弱广告精准投放能力，进而影响收入。
+- 碎片化问题：设备/版本碎片化导致更新缓慢、开发与测试成本高、用户体验不一致；长期可能影响平台形象。
+- 区域市场失利（中国）与去Google化风险：在中国市场无法提供 GMS，导致间接收入损失并催生替代生态（HMS）；厂商若选择去Google化，会削弱平台控制力与变现路径。
+- 抽成争议与开发者关系：应用商店抽成、支付方式限制等引发法律诉讼与开发者不满（Epic 等案例）。
+
+### 6. 个人见解
+安卓的商业模式巧妙地将“免费”作为扩张手段，用规模换取“流量与数据”，再通过多条服务管道实现巨额变现——这是对传统软件销售模式的颠覆。未来方向应侧重两点：一是合规与开放的平衡（在满足监管要求的同时，保留核心变现能力）；二是将 AI 能力与本地化服务融合，创造新的订阅/服务收入（例如系统级 AI 助手、车载与可穿戴订阅）。对开发者与厂商而言，Google 需继续优化抽成/分成政策与隐私保障，以维持生态黏性并避免大规模去Google化。

assignments/lesson2/yangrudan.md

@@ -0,0 +1,150 @@
+# Git工具安装与使用报告
+
+**学员GitHub用户名**: yangrudan
+
+## 1. Git安装过程
+
+### 操作系统
+
+macOS Sequoia 15.3.1
+
+### 安装方法
+
+#### 通过Homebrew安装
+
+Homebrew是macOS专属包管理器，可高效管理Git的安装与更新，适配Intel和Apple Silicon芯片。
+
+1. **安装Homebrew（未安装时执行）**：
+打开终端（通过Spotlight搜索“终端”或按Command+Space调出搜索框输入“Terminal”），执行以下命令，过程中按提示输入系统密码并等待安装完成：
+`/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"`
+
+2. **安装Git**：
+终端执行以下命令，Homebrew会自动下载并安装最新版本Git：
+`brew install git`
+
+3. **验证安装**：
+执行版本查询命令，若输出类似“git version 2.39.5”的信息，安装成功：
+`git --version`
+
+
+## 2. 遇到的问题及解决方法
+
+### 问题：终端提示“git: command not found”
+
+- **现象**：安装完成后执行Git命令，系统无法识别。
+
+- **原因**：Git的可执行路径未添加到系统环境变量PATH中，常见于手动安装或Homebrew配置不完整的场景。
+
+- **解决方法**：
+        执行`echo $PATH`查看当前环境变量，确认是否包含Git路径。
+
+- 若缺失，执行对应命令添加（根据安装方式选择）：
+- 手动安装：`echo 'export PATH="/Applications/Git.app/Contents/Resources/bin:$PATH"' >> ~/.zshrc`
+- Homebrew安装（M1/M2）：`echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zshrc`
+
+- 执行`source ~/.zshrc`使配置生效，重启终端后重试。
+
+
+## 3. 版本信息截图
+
+
+![Git版本信息截图](./git_version.png)
+
+
+## 4. Git命令使用过程总结
+
+### 基础配置（首次使用必备）
+
+安装完成后，需配置全局用户名和邮箱（与GitHub账号一致），用于标识提交记录的作者身份：
+
+```Plain Text
+
+git config --global user.name "example-user"  # 你的GitHub用户名
+git config --global user.email "example@xxx.com"  # 你的GitHub绑定邮箱
+git config --global core.editor "nano"  # 可选：配置默认编辑器（如nano、vim）
+git config --list  # 查看当前所有Git配置
+```
+
+### 核心命令使用体验与理解
+
+#### 1. git clone：克隆远程仓库到本地
+
+- **功能**：将远程GitHub仓库完整复制到本地，自动关联远程仓库（默认名为origin）。
+
+- **使用命令**：
+- HTTPS方式（需输入用户名和个人访问令牌）：
+`git clone https://github.com/example-user/your-repo.git`
+- SSH方式（配置后免密，推荐）：
+`git clone git@github.com:example-user/your-repo.git`
+
+- **实用技巧**：克隆大型仓库时，可添加`--depth 1`仅获取最新版本（减少下载量）：
+`git clone --depth 1 git@github.com:example-user/your-repo.git`
+
+#### 2. git add：添加文件到暂存区
+
+- **功能**：将本地修改（新建、修改、删除）的文件标记为“待提交”状态，暂存区是本地与仓库的中间层。
+
+- **使用命令**：
+`git add README.md`（添加单个文件）
+`git add src/`（添加指定目录）
+`git add .`（添加当前目录所有修改，推荐）
+`git add -u`（仅添加已跟踪文件的修改/删除，不含新建文件）
+
+- **注意事项**：执行后通过`git status -s`查看状态，“A”表示已添加，“M”表示已修改，“D”表示已删除。
+
+#### 3. git commit：提交更改到本地仓库
+
+- **功能**：将暂存区的更改永久保存到本地仓库，生成包含提交信息的版本记录。
+
+- **使用命令**：
+`git commit -m "feat: 完成Git安装报告初稿"`（直接附带简洁提交信息，推荐）
+`git commit`（打开默认编辑器输入多行提交信息）
+`git commit --amend`（修改最近一次提交信息或补充遗漏文件）
+
+- **最佳实践**：提交信息遵循“类型: 描述”格式，如“fix: 修复SSH连接错误”“docs: 更新安装步骤”，便于版本回溯。
+
+#### 4. git push：推送本地更改到远程仓库
+
+- **功能**：将本地仓库的提交同步到远程GitHub仓库，实现代码共享与备份。
+
+- **使用命令**：
+`git push origin main`（推送本地main分支到远程origin仓库）
+`git push -u origin main`（首次推送绑定分支，后续可直接执行`git push`）
+
+- **常见问题**：若远程有新提交，需先执行`git pull`拉取合并，否则会提示冲突；HTTPS方式需使用GitHub个人访问令牌（而非密码）登录。
+
+#### 5. git pull：从远程仓库拉取最新更改
+
+- **功能**：获取远程仓库的最新提交并合并到本地当前分支，确保本地代码与团队同步。
+
+- **使用命令**：
+`git pull origin main`（拉取远程main分支并合并）
+`git pull`（已绑定分支时可省略参数）
+
+- **冲突处理**：若出现合并冲突，Git会标记冲突文件（含“<<<<<<< HEAD”等标记），需手动编辑保留正确代码，再执行`git add 冲突文件`和`git commit`完成合并。
+
+#### 其他常用命令
+
+- **git branch**：分支管理
+`git branch -b dev`（创建dev分支）
+`git switch dev`（切换到dev分支，Git 2.23+支持）
+`git branch -d dev`（删除本地dev分支）
+
+- **git merge**：合并分支
+`git switch main && git merge dev`（切换到main分支，合并dev分支更改）
+
+- **git log**：查看提交历史
+`git log --oneline`（简洁显示版本记录）
+`git log --graph`（图形化展示分支合并历史）
+
+- **git reset**：版本回退（谨慎使用）
+`git reset --hard HEAD~1`（回退到上一个版本）
+`git reset --hard 提交哈希值`（回退到指定版本，哈希值通过git log获取）
+
+### 整体使用心得
+
+macOS下Git的安装与使用更贴近Unix风格，通过Homebrew可实现Git的一键安装与版本更新，极大降低了环境配置成本。Git的核心价值在于“分布式协作”与“版本追溯”，通过暂存区（add）、本地仓库（commit）、远程仓库（push/pull）的流程设计，能清晰管控代码变更，避免团队协作中的版本混乱。
+
+实际使用中，养成“先pull再开发、频繁提交、清晰备注”的习惯，减少冲突概率；SSH密钥配置虽需额外步骤，但能实现免密访问，提升开发效率；对于分支管理，可采用“main（稳定分支）+dev（开发分支）+fix-xxx（修复分支）”的模式，确保主分支代码的安全性。结合GitHub的Pull Request功能，还能实现代码审查与协作流程的规范化，进一步提升开发质量。
+
+---

yangrudan.md

@@ -0,0 +1,108 @@
+
+## 目录
+
+- [1. 愿景：用科技守护每一份牵挂](#1-愿景用科技守护每一份牵挂)
+	- [1.1 发展目标](#11-发展目标)
+	- [1.2 todo lists](#12-todo-lists)
+- [2. 加入我们：一起点亮守护的微光](#2-加入我们一起点亮守护的微光)
+	- [2.1 招募伙伴](#21-招募伙伴)
+	- [2.2 使命](#22-使命)
+- [3. 商业模式画布（Business Model Canvas）](#3-商业模式画布business-model-canvas)
+	- [3.1 目标用户](#31-目标用户)
+	- [3.2 产品价值](#32-产品价值)
+	- [3.3 收入来源](#33-收入来源)
+	- [3.4 主要渠道](#34-主要渠道)
+	- [3.5 关键核心](#35-关键核心)
+	- [3.6 主要成本](#36-主要成本)
+	- [3.7 关键合作](#37-关键合作)
+- [4. 小结](#4-小结)
+
+##  1. 愿景：用科技守护每一份牵挂
+
+在超级智能体 Campathon 的赛场上，我们诞生了一个朴素而坚定的初心——**OPS-agent** 。它不仅仅是一个项目，更是一份承诺，一种责任。我们希望通过技术的力量，为那些渐渐老去的父母、祖辈，为每一位需要被温柔守护的长者，搭建一座连接关怀与安全的桥梁。
+
+我们相信，科技不应只是年轻人的专属，更应是温暖人心的工具。OPS-agent 的使命，就是让智能硬件真正"活"起来 ，让数据不再冰冷，让陪伴不再遥远。
+
+###  1.1 发展目标
+
+我们将持续推动 OPS-agent 走向成熟，让它从创意走向落地，从代码走向生活：
+
+### 1.2 todo lists
+
+- **更广泛的硬件接入**：兼容更多智能设备，让守护无界；
+
+- **更智能的记忆系统**：构建长短期的行为与健康记忆，让关怀更懂人心；
+
+- **更流畅的数据架构**：优化数据流转，让信息价值真正服务于人；
+
+- **更实用的场景落地**：让 OPS-agent 真正走进家庭，成为老年人生活中不可或缺的守护者。
+
+##  2. 加入我们：一起点亮守护的微光
+
+OPS-agent 的核心初心，**始终是「成为老年人的守护者」** 。我们相信，技术最有温度的归宿，是服务于人，尤其是那些最需要被看见、被关怀的群体。
+
+我们诚挚邀请你，无论你身在何方，无论你擅长什么，只要你也怀揣着同样的初心，就请加入我们，一起把这份守护的力量传递下去：
+
+###  2.1 招募伙伴
+
+-  **如果你有硬件资源**：欢迎参与设备适配与测试，让更多智能硬件成为守护的"眼睛"与"双手"
+-  **如果你擅长编程**：无论是前端、后端还是算法，都欢迎你参与核心功能的开发与优化
+-  **如果你关注用户体验**：欢迎参与文档撰写、界面设计、交互优化，让产品更贴心、更易用
+-  **如果你有实际场景需求**：欢迎分享你的故事与场景，参与模板设计，让 OPS-agent 更贴近真实生活
+
+---
+
+###   2.2 使命
+
+我们不仅仅是在开发一个项目，我们是在编织一张温暖的网，托起那些容易被遗忘的日常 🕸️✨。
+
+让我们一起，把 Campathon 中的那颗初心，种进现实的土壤 ，浇灌成荫 。  
+让 OPS-agent 不止于代码，而是成为每一位老人身边，最可靠的守护者。
+
+---
+
+>  **因为我们相信**：科技，终将回归于人。守护，从不应该孤单。
+
+## 3. 商业模式画布（Business Model Canvas）
+
+### 3.1 目标用户
+- 老年人，及其子女
+
+### 3.2 产品价值
+- 让老人健康、安全、生活便利
+- 子女可实时了解老人情况、远程守护
+
+### 3.3 收入来源
+- 会员订阅（如￥10/月，子女为父母账号付费，享健康提醒、报告、紧急呼叫等高级功能）
+- 养老机构/社区SaaS：为机构提供管理后台，批量付费
+- 服务佣金：结合药店、体检、护理等服务，交易收取佣金
+- 合作硬件利润：智能手环、紧急按钮等销售+后续数据服务
+
+### 3.4 主要渠道
+- 微信小程序/APP，让老人用得上，子女可代管
+- 合作养老机构导入用户 
+- 微信/抖音等子女群体推广
+
+### 3.5 关键核心
+- 稳定易用的自动化软件平台
+- 健康数据与AI分析能力
+- 精准触达子女、老人群体
+
+### 3.6 主要成本
+- 技术开发与服务器运维
+- 简单客服和渠道推广
+- 硬件采购/合作分成
+
+### 3.7 关键合作
+- 养老机构/社区
+- 医疗健康类服务商
+- 硬件厂商
+
+## 4. 小结
+1. 最大化自动化运营，团队可极小（参考 Peter Levels）；
+2. 产品体验足够“傻瓜化”，老人门槛低，子女可远程操控/充值；
+3. 偏重“家庭为单位”的会员订阅+增值服务，减少单点销售压力；
+4. 机构级别与B2C可并行、试点合作；
+5. 服务场景由“提醒-健康-生活-安全”逐步纵深。
+
+---