骨传导耳机，办公室戴只要不是音量特别特别大，附近的同事是听不到我在听什么的（除非音量调整到 50%以上）。
但是用蓝牙音箱外放我想大家应该都懂是什么效果。

音质问题，运动的时候其实对音质要求就没有那么离谱了。而且对于大部分人而言其实也听不出来多少区别。甚至有可能因为用了骨传导反而感觉低音效果更好了😂。

----

至于跑步的话，确实会推荐骨传导耳机。入耳式耳机多多少少会阻隔掉一部分环境音。
现在骑行玩家多了起来，有蛮人晚上多会去公园里面骑行，阻隔掉就有可能移动的时候不下小心会被撞上。

至于带音箱啥的，抛开羞耻干，也会影响到其他运动的人。运气不好可能就会遇到一个狂躁 buff 的人被锤了。

全天候有影响的，而且说头几天 iCloud 会疯狂同步。
但是 Pro 续航本来就不太行吧…15Pro 出行使用的话半天就开始电量焦虑了。

一单一单送的话还是可以的，但是这样的骑行，运动强度并不会很高。
而且需要考虑取完餐 or 送晚餐回来单车被偷的问题……

就是看你自己取舍不到二十块钱是不是值得自己这样去做。换我的话就会选择专心骑行。

16 岁了如果都还不放心小孩子自己我 i 出，过几年念大学了咋办？
你这还是有成年人接送站的，不至于 16 岁了还没坐过高铁吧（和家长一起）。

如果小孩没有身份证就去派出所办一下，16 岁可以办身份证了。

自从去年 ChatGPT 爆火之后，每天都能在 sf 的众审中心看到一堆 AI 生成的技术类分享文章 和 AI 生成的技术类回答。

其实不光是搜索引擎，其实直接用 Github Copilot 这种 AI 辅助编程工具，也会遇到给你一个并不存在的 API 。

评论前先看一看主题问的是 VS 还是 VSC……

别还没分清 Visual Studio 和 Visual Studio Code 就开始输出了。

@xinghen57 #22 ，这个需求我确实不太有，基本上一台设备会用 5~6 年以上，期间几乎不会重装系统。
我现在是选择尽量减少个性化配置，能开箱即用就开箱即用，实在不行就用软件提供的云同步功能。换工作重新搞一下环境得累死。

看完 OP 的帖子，马上点了更新。数据都在……
应该是 OP 说的删 default 导致的。

不太想折腾包管理工具，一直是自己下安装包。

不用过户，大部分保险跟着车走。一部分保险是保车主的，续保的时候改成保驾驶员的险种就行了。
续保的问题，等你车子保险到期之后，让你父亲联系保险公司续保就行了，续保价格不会变动的。

至于其他回复提到的事故责任的问题，就全看你自己了。如果自用的家庭车不用考虑 #9 提到的运营车案例。

@Desdemor #23 ，感觉应该会和之前的 ECG 一样，在国内认证通过之后才会推送启用吧。

@xunandotme #20 ，心脏健康和 ECG 不是从 S6 开始就有了么😂，最新的是睡眠监测的呼吸暂停。

@Anshay #15 ，软件的使用体验不同。如果单纯只关注功能，手环就能满足几乎所有除社交外的所有功能，续航还比手表长。
如果关注使用体验的话手表就会强很多，各种的“生态接力”实现是手环没法办到的。
也就是需求只是运动记录 + 身体监测，手环就能全覆盖你的需求，如果想更进一步就可以选择手表。
有点类似于现阶段辅助编程中 Copilot 和 Cursor 的区别。

1. 运动就是硅胶表带，日常穿搭和睡眠还是针织表带舒服（补充：有一些人对硅胶表单过敏）
2. 如果你有外出跑步的需求，买蜂窝出门装备会轻很多。我现在出门户外跑就一个表+Airpods ，收发微信和支付（被扫）都没问题。如果没有我提到的这个需求，那就不用买蜂窝。
3. 充电问题，基本上一个小时充的电就足够日常使用了。每天运动完洗澡前摘掉，一直到入睡前再戴回来，这个时间段充的电足够（基本上 80%的电量一天使用下来没问题的）。

我就是普通的 S6 首发到用到现在了，使用量是每天佩戴时间 21 小时+，运动时间 128 分钟（向下箭头）。关闭了全天候显示这样能省很多电量。之前可以两天一充，现在电池健康不到 75%得每天一冲。
每天就是晚上运动完充到入睡前，其他时间段不充电的。偶尔有几天晚上跑 10 公里会断电，如果准备长时间跑步，最好是前一天晚上充到 100%。

如果对电量有焦虑的可以考虑 Ultra ，但是 Ultra 跑步的时候会会明显感觉手腕会有负重的感觉，所以如果不是特别电量焦虑的，不需要入 Ultra ，普通版就足够了。

如果做不到固定的开发工作流，确保每一个 MR 都会 review 通过后才会被合并。
那么 OP 你关注于“技术”部分的规范，确实会补充中领导的长远看法一样。

---
关于团队开发规范一般都是开发团队中互相理解认可，最终达成一致的规范。而不是一两个人拍脑袋确定下来的。
至于项目 A 使用，不代表项目 B 也适用。其实和团队 A 认可，不代表团队 B 也会认可一样的。

比如你的举例就很“技术”，并不是一个对于开发流程的规范，更像是 Lint 相关的规范（也就是 Coding Style ），那么确实并不一定适用所有项目。
---

比如你可能会觉得<问题 1>很不爽，但是可能项目开始时期 `script:setup` 并没有实现，所以当时只是使用了 `setup` 并没有使用 `script:setup`。
那么按照你<问题 4>的认定，你多半也不会认可在一个项目中同时出现选项式和组合式两种写法。那么比较合适的情况就是延续旧有的“开发规则”，继续使用 `setup` 开发而不是 `script:setup`，而不是全部重构成 `srcipt:setup`。

至于<问题 2>和<问题 3> 是出于一个中间地带，首先代码量少并不一定就是“好代码”，举个很极端的例子 `const result = condition1 ? condition2 ? 'A' : 'B' : condition3 ? 'C' : 'D';`
虽然示例和 OP 你表达的并不一样，我这样举例有一点抬杠的意味，但想表达的是 代码结构清晰，可以让所有人都可以快速理解的代码，才是真的“好代码”。
不知道你举例的 `useRequest` 是 [VueUse]( https://vueuse.org/core/useFetch/) 这种比较大众的工具类库提供的，还是自己内部实现的工具类库。

API 都声明在一个 `index.js` 文件中，我也觉得会是一个问题，但是可能开发团队已经习惯了直接使用 `import { xx } from '@api' 中引入对应的接口了。
可以贡献一个模块化拆分后 API 维护的 MR ，并且提供和原本一样的聚合后的 `@api/index.js`出口（`export * from './modulesA'`）。
这个 MR 就可以当成首次 review 的一个样例。

---

但是 OP 你得和你的领导确定好，你们想要制定的规范是什么，是开发流程的规范，还是编码风格的规范。
开发流程的规范当形成习惯之后是可以随团队一直延续、传承下去的，但是编码风格的规范会随着不同项目的主导人而不同的。

后面还会有二番战的 😆

@crocoBaby #50 ，我现在手里头的 15pro 周末出游会有电量焦虑。可能和 5G 有关？如果外出目的地有 wifi 的话，电量下的会比较慢。户外下电真的很快。

看了发布会，真的提不起兴趣……所以现在准备马上换的应该都是 13 以前的换个新吧。
对 AI 感兴趣的就算现在买了也用不了，而且今年想用还不能买国行版……不想刷 beta 版的，等到 AI 真的推送的时间节点 pro 和 promax 还不是随便买。