游牧周记第86期
知识
NAD+等所谓返老还童网红药物靠谱吗？
由于认识朋友做这些进口药赚了大钱，我就请AI总结了一下。 NAD等返老还童药靠谱吗-最新研究总结
日常
一些照片
巫家坝公园开张，又一堆网红宣传。我溜达了一半，感觉：晒，空，半成品，细节和维护有问题，像是为了赶时间赶快交差的项目。
朋友在云南野生动物园卖文创，顺便还要管免费盖章。
我买了只毛象，标价98。
参观一个真实dotNet项目
部署在阿里云，用阿里的代码仓库和流水线管理。 客户端是微信小程序。 前段dashboard是Vue。 后端居然是dotNet，最离谱的是版本似乎很老（虽然我不太清楚，但在macos部署时，AI提示才6，现在至少应该10）。 数据库Mysql。 不管怎么样，人家基本上还是Agentic Engineering了，但代码质量总体不高。 是一个订单管理平台。
开发
Google Play限制了外部支付方式
我之前在App里集成了Creem的支付链接，已经一年多了吧，现在Google Play提示违规（除俄罗斯印度外）, 要求：
- 移除会将用户引导至非 Google Play 结算系统进行付款的链接。
或者
如果您计划将美国境内的用户引导至应用之外进行一些操作（包括通过这种方式来推广优惠活动），请加入我们的外部内容链接计划。如需了解更多详情，请参阅我们的常见问题解答。
先懒得看他的“外部内容链接计划”，改了再说吧，反正我这个creem从来没卖出过任何东西。
建立自己的Harness架构
这个作者Gary Chen的内容非常解压清晰有益。 导致我开始反思之前借助AI Coding的效果，至少可维护性问题已经出现。 从Vibe Coding到Agentic Engineering的改变应该开始了。 我要打造一个自己可以控制，有成就感的环境，而不是全部依赖不同Modal的AI大脑。
名言： Harness是你的地盘，是你唯一能控制、最值得投资的地方。 人的角色是什么？Conductor 和 Orchestrator的不断切换，前者要盯着关键代码，后者是任务调度。 生成问题已经被解决了，Verification才是真正的手艺活（之一）。 rules,skills,evals才是会有复利的资产，是最值得人投入时间的地方。（model是流水的兵，越强，整个系统水位越高）。
我下一个版本的yi app应该这样做了。
Skill用英文就比中文的强吗？
和ChatGPT讨论了一下，它说：
结论：Coding Skill 用英文通常更稳，但中文不会明显变差。
原因是代码、API、命令、错误信息和官方文档基本都是英文，英文 Skill 更容易与代码直接对应。
最佳实践：
-
name、description、技术术语、执行流程：英文 -
个人偏好、业务规则、项目限制：中文
-
代码符号、命令、文件名：始终保留英文
因此，最推荐：英文技术骨架 + 中文业务约束。
真正决定效果的首先是指令是否明确、可执行、可验证，语言是次要因素。
...
在 Coding 领域，英文确实存在小幅但真实的结构 性优势，因为源码、工具链、错误信息和文档以英文为主。
但决定效果的首要因素仍是指令是否明确、可执行、可验证。对于你的个人 Coding Skill，建议元数据、工程流程和技术术语使用英文；产品规则、个人偏好和业务边界使用中文。
一个例子：
---
name: expo-project-maintainer
description: Maintain and modify Expo React Native TypeScript projects.
Use for dependency upgrades, bug fixes, feature implementation,
expo-router navigation, EAS Build issues, and native configuration.
---
# Expo Project Maintainer
## Core workflow
1. Inspect `package.json`, Expo configuration, and relevant source files.
2. Identify existing project conventions before proposing changes.
3. Prefer the smallest coherent patch.
4. Preserve public APIs unless the requested change requires otherwise.
5. Run the narrowest relevant validation first, then broader checks.
## Validation
- TypeScript changes: run the existing type-check script.
- Lint-related changes: run the existing lint script.
- Expo configuration changes: run `npx expo-doctor`.
- Dependency changes: use `pnpm` and preserve `pnpm-lock.yaml`.
- Do not claim that EAS Build succeeds unless an actual build was run.
## 用户项目约束
- 包管理器使用 pnpm。
- 不得生成或修改 `yarn.lock`、`package-lock.json`。
- 优先复用现有组件和依赖。
- 移动端样式优先使用 `StyleSheet` 和项目已有 tokens。
- 不为未经要求的未来功能提前增加抽象层。
- 如果工作区已有用户修改，必须保留无关改动。
我觉得自己从来不看skills内容，以至于懒得自己写skill的一个主因就是语言的懒惰性。
现在Expo项目中Unistyles库的价值是啥？
SDK 57以后，原生组件使用越来越多，我之前深入采用的Unistyles是否又拖后腿了？价值是啥呢？我们和AI聊天后，总结一下。
只有当 App 几乎完全由 @expo/ui 原生组件构成、RN 自定义样式非常少时，才值得去掉 Unistyles。
**在大量采用 @expo/ui（SwiftUI/Jetpack Compose）的最新 Expo 项目中，原生组件已经负责平台外观和部分主题适配，Unistyles 的职责应收缩到自研 RN 组件、语义化 tokens 和动态样式，而不是统管全部 UI。
Unistyles 的优势是主题样式写法简洁、减少组件订阅和重复代码，并能高效更新样式；缺点是增加原生依赖、配置与升级成本，不支持 Expo Go，而且部分能力会与日益完善的 Expo 原生 UI 重叠。纯 StyleSheet + tokens 最轻、最稳定、最贴近 Expo 发展方向，但大量主题化自研组件会产生样板代码和 React 重渲染。
因此：原生 UI 占绝对主体、定制较少时不用 Unistyles；仍有大量自研界面和主题样式时保留 Unistyles，并把它限定为 RN 样式层。 不应仅因 Expo UI 出现就删除它，也不应让它包办原生组件已经解决的问题。
Q: 用户最喜欢的动态theme,rt参数功能，是否仅仅是一个代码糖？
Answer:
不是。语法表面像代码糖，Unistyles 3 中的运行机制不是。
StyleSheet.create((theme, rt) => ({
container: {
backgroundColor: theme.colors.background,
paddingTop: rt.insets.top,
},
}));
[KNOWN｜CONFIDENCE: HIGH]
-
theme、rt参数让样式声明更简洁，这部分确实属于代码糖。 -
但 Unistyles 会追踪这些动态依赖；主题、屏幕尺寸、安全区等变化时，自动重新计算并更新相关原生样式，普通场景不要求 React 组件重新渲染。
-
自己写
createStyles(theme)只能模仿语法，通常还需要 Hook、状态订阅和 React 重渲染，并不具备相同底层机制。
所以准确说：
theme, rt的函数参数是友好的声明语法；背后的依赖追踪、原生样式更新和避免 React 重渲染，才是 Unistyles 的实质价值。
如果只使用固定 tokens，主要得到的是代码便利；如果大量使用主题、安全区、方向、尺寸和断点，得到的就不只是语法糖，而是一套真正的响应式样式运行时。
Q: 预配置支持明暗themes的共享styles，在其他组件直接调用（或通过hook）, 其实不需要unistyles，用RN也可以做到，对吗？有性能或体验差异吗?
Answer:
对，完全可以。预先生成 light/dark 两套共享 StyleSheet，再通过 Hook 选择，本身不需要 Unistyles。
const stylesByScheme = {
light: StyleSheet.create(createStyles(lightTheme)),
dark: StyleSheet.create(createStyles(darkTheme)),
};
export function useSharedStyles() {
const scheme = useResolvedColorScheme();
return stylesByScheme[scheme];
}
组件只需：
const styles = useSharedStyles();
差异
-
日常渲染性能：预生成的 RN StyleSheet 非常轻，通常与 Unistyles 没有值得关注的差距。
-
切换主题：RN 方案需要订阅该 Hook 的组件重新渲染；Unistyles 3 可以直接更新普通原生样式，减少 React 重渲染。
-
开发体验：封装 Hook 后，RN 方案也只需一行；但每个组件的独立主题样式仍要建立两套映射或使用 factory。Unistyles 的
theme, rt写法更自然。 -
能力范围：RN 方案适合固定明暗主题；安全区、断点、方向、尺寸、variants 等动态依赖增多后，自己封装会逐渐接近“重写一个简化版 Unistyles”。
-
维护成本：RN 方案零额外原生依赖、支持 Expo Go、升级风险更低；Unistyles 需要原生构建和额外兼容维护。
主题切换是极低频操作，因此 RN 方案的重新渲染通常不构成实际性能问题。在 @expo/ui 占主体、只需要明暗主题和固定 tokens 的项目中，StyleSheet + 预生成双主题 + 一个 Hook 是合理且更轻的选择；只有主题化自研组件很多或大量依赖 rt 时，Unistyles 的体验优势才会明显。
关于Andrej Karpathy的访谈总结视频
来源：Gary Chen，YouTube《AI 时代工程师怎么重新定位自己：Andrej Karpathy 访谈解析》
内容很精彩，Gary Chen的总结也很好，我请AI把文字再提炼归纳如下：
Andrej Karpathy 访谈解析｜核心摘要
范式已经改变
AI 不是把软件工程加速，而是在改写“软件是什么”及工程师的职责。Software 1.0 是人写规则，2.0 是神经网络从数据学习，3.0 则以自然语言调用大模型：程序正在变成提示词。真正的机会不是给旧功能套一层聊天框，而是做过去不可能实现的事；如果用户三句话就能从通用模型得到同样结果，那个 App 可能没有存在的必要。
理解“锯齿状智能”
当前 AI 是“锯齿状智能”：它能在高难度任务上像天才，却会在常识问题上犯荒谬错误——例如建议步行去 50 米外的洗车场，忘了车也必须到场。能力不是平滑增长的曲线；模型升级或任务换域，都可能使表现突然跃升或坠落。因此不能笼统地问“AI 聪不聪明”，而要知道它在具体任务上强在哪里、弱在哪里。
工程师的新天花板
工程师的天花板不再是手写代码速度，而是能否把问题想清楚、把需求说明白、建立可验证的反馈闭环。只要结果能自动评分，就可以让 AI 反复运行一百次，从“生成一次答案”升级为持续搜索、测试、修正。Vibe Coding 是接 受第一个看似可用的答案；Agentic Engineering 则是设计任务、边界、工具、测试和复核，让一个人能组织大量代理工作。
什么可以外包
可以外包 API 细节、样板代码和重复执行，但不能外包抽象、系统边界、数据归属、安全与失败模式。视频最重要的警告是：“你可以外包思考，但不能外包理解。”一旦不理解系统，AI 生成得越快，错误扩散得也越快。
结论
未来最值钱的不是记住更多语法，而是判断什么值得做、把复杂问题拆成可验证任务，并对最终结果负责。AI 扩大了软件创造的入口，也会扩大深思者与只想赶快交差者之间的差距。不要把 AI 当成让你少想一点的工具，而要用它把思考推到更高层。