硬件产业链中的"厂"涵盖OEM、ODM、OBM等多类角色，核心区别在于设计、制造、品牌与销售环节的分工。OEM代工生产，按客户设计制造成品；ODM既参与设计又生产，品牌方最终贴牌销售；OBM一词源中文内置语，指具备自有品牌的制造商，如小米、华为等。CMS服务涵盖PCB贴片、组装测试和供应链管理，富士康等典型企业属于此范畴。芯片厂专注于设计半导体，晶圆代工厂完成芯片制造；模组厂把蓝牙、摄像头等复杂模块封装为即插即用组件。在智能设备开发中，IDH方案商通常提供底层技术参考，Tier1一级供应商承接整机方案，Tier2二级供应商供货零部件。例如主流智能手环开发涉及品牌方定义需求，ODM/JDM设计方案，EMS/OEM生产组装，芯片厂提供主控和传感器模组厂整合功能模块，形成完整产品链。理解各环节定位，有助于分析供应链合作模式、硬件项目开发路径及跨领域协作逻辑。

常见信息系统按企业业务场景分为OA（流程管理）、ERP（财务/供应链协同）、MES（生产管理）、CRM（客户管理）、SCM（供应链协同）、WMS（仓储）、TMS（运输调度）、BI（数据分析）、KM（知识管理）、EAM（设备资产）等。按行业划分，医疗包含HIS/EMR系统，教育涉及LMS教务平台，金融覆盖核心银行与风控系统，电商侧重商品/订单/支付模块联动，政务则涵盖审批档案与监管系统。读者可快速掌握通用系统对应的核心业务功能，如OA管人管流程、ERP整合资源、MES聚焦车间管理；同时了解重点行业的垂直化系统应用场景，为业务选型及技术开发提供决策参考。

Android屏幕适配需关注设备尺寸、密度、窗口形态及异形屏等情况，适配核心从早期等比例缩放转向空间重排。基础单位dp（布局）和sp（字体）应替代像素，使用ConstraintLayout或Compose弹性布局替代绝对定位。多窗口、折叠屏需引入Window Size Class动态判断窗口类型（Compact/Medium/Expanded/Large），配置对应布局结构；全面屏适配需结合WindowInsets处理状态栏、导航栏及刘海屏区域，控制元素边缘距离。图片资源采用VectorDrawable和不同密度的drawable目录，避免额外适配成本。传统方案如多套layout、AutoLayout存在维护复杂、大屏僵硬等问题，现代方案应优先采用官方推荐组合：dp/sp+弹性布局+资源限定符+WindowInsets+Window Size Class，分别解决密度、窗口规模、沉浸式交互适配。核心原则为小屏保证可用性，大屏重构布局，避免依赖等比例缩放。

Android沉浸式状态栏需满足状态栏变色、透明、Edge-to-edge覆盖及窗口内边距适配等需求。技术演进经历三个阶段：Android4.4-5.0通过半透明状态栏和假View实现视觉遮罩；6.0-14依赖状态栏颜色变色、深色图标及第三方框架（如ImmersionBar）兼容差异系统；15+ SDK原生于Edge-to-edge和WindowInsets，要求内容避开系统栏并精确控制边距。适配核心已从状态栏颜色调整转向使用WindowInsetsController统一管理顶部 statubar/导航栏隐藏模式、top view的statusBarsPadding、bottom view的navigationBarsPadding、列表项bottom padding调整。新项目推荐使用Material3 Scaffold+enableEdgeToEdge+WindowInsets模式，避免引入第三方框架；旧项目需逐步替换旧的system UI flag方案为 Insets API，重点检测Android15+设备的内容遮挡问题和华为/小米等差异ROM的刘海区适配。

RAG 通过三个核心模型实现精准问答：Embedding 模型将文本转换为语义向量，快速从知识库筛选候选资料；Rerank 模型基于用户问题与候选文档重新排序，提升召回准确性；LLM 大模型结合排序后的资料生成自然语言答案。相较于传统大模型，RAG 机制有效解决知识时效性不足和私有资料缺失问题，通过实时关联资料降低幻觉风险。其流程包含文档入库（收集、切片、向量化、存储）和用户提问（向量检索、重排序、答案生成）两个阶段。应用场景包括企业知识库、法律/医疗文档问答及技术文档检索，尤其在大型复杂知识库中，Rerank 模型能显著优化排序结果。核心价值在于确保大模型基于准确、时效的内部资料输出答案，而非依赖训练时见过的公开数据，可提升问题解决的专业性和可靠性（字数：217）。

grill-me 可以理解成一个 “拷问式需求澄清 / 方案审查 skill”。 它不是让 AI 直接写代码，而是让 AI 像一个很挑剔的技术负责人一样，不断追问你： 这个需求到底要解决什么问题？ 哪些情况不做？ 边界条件是什么？ 有没有更简单的方案？ 现有代码里有没有类似实现？ 这个设计会不会引入

grill-me 可以理解成一个 “拷问式需求澄清 / 方案审查 skill”。 它不是让 AI 直接写代码，而是让 AI 像一个很挑剔的技术负责人一样，不断追问你： 这个需求到底要解决什么问题？ 哪些情况不做？ 边界条件是什么？ 有没有更简单的方案？ 现有代码里有没有类似实现？ 这个设计会不会引入

Trellis是面向AI编程助手的项目级规范、任务和记忆系统，解决长期项目中AI对上下文理解不足的问题。其核心模块包括：Spec（项目规范）存储分层设计、接口响应、异常处理等具体规则，Task（任务文件）明确当前需求边界、范围和验收标准，Workspace（项目内存）记录开发过程和历史决策。 Java Web开发中，Trellis通过分层规范（如Controller仅传递请求、Service处理业务逻辑）避免AI写错代码层级，通过API响应规范（统一使用ApiResponse）确保交互一致性，通过异常处理规范（统一捕获业务异常）减少try-catch滥用。实施流程建议先制定基础规范（分层职责、接口格式、事务规则），再通过实际任务（如新增注册接口）验证规范有效性，持续将开发经验沉淀到Spec中。相比Superpowers的流程驱动，Trellis专注将项目规则固化为可版本控制的文件，适用于长期团队协作项目，特别解决AI跨会话断片、任务范围蔓延及规范缺失等痛点，帮助沉淀可复用的系统级最佳实践。

最近在使用 Trellis 辅助开发项目时，我发现了一个挺有意思的问题：明明项目的主要业务代码不是 Python，但 GitHub 仓库列表里却显示这个仓库的主要语言是 Python。 一开始我还以为是 GitHub 识别错了，后来才发现，问题其实出在 GitHub 的语言统计规则上。 一、问题现象

在 Android 开发中，Service 经常被理解成“后台任务组件”。但从 Android 8.0 开始，系统对后台执行做了越来越严格的限制，普通后台 Service 已经不再适合长期运行任务。 这时候，ForegroundService 就变得非常重要。 不过 ForegroundServic