最近项目中，我需要把一个 Android 项目的全部页面迁移到鸿蒙。目标不是重新设计，而是尽可能完整地复刻原项目的页面、UI、交互、状态和跳转。

实际效果比我预想得好：我只设置了一次总 Goal，中间没有继续指挥，Agent 持续执行了四天多。阶段结果里，鸿蒙界面的主体完成度已经接近九成。

这里最重要的不是“四天”这个数字，而是：Agent 为什么能够在没有人持续补充指令的情况下，知道下一步该做什么，并且没有把大型迁移变成一堆不可追踪的改动？

按原书章节顺序整理《彼得·林奇的成功投资》微信读书划线笔记，保留核心原文，方便后续按主题回看。

这篇文章记录我如何把在线表格里的 Bug、功能想法和执行计划，拆成一组可复用的 Agent Skills，让 AI 开发从‘一句话改代码’变成‘有状态、有隔离、有验收’的工程流水线。

最近项目中做了一次平板适配。项目是 Kotlin Multiplatform + Compose 写的，界面代码主要在 commonMain，也就是说 Android 和 iOS 会共用大部分页面逻辑。

一开始看到“平板适配”这几个字，很容易想到两种做法：

• 判断是不是平板，然后重新写一套平板页面；
• 在每个页面里判断屏幕宽度，手动决定显示单栏还是双栏。

但这两种方式后期都比较难维护。页面越来越多以后，每个页面都写一遍适配判断，代码会很散；如果单独写一套平板页面，又容易和手机页面逻辑不同步。

所以本文就以这个项目为例，看一下如何使用 Navigation 3 + Material3 Adaptive 实现一套更适合真实项目的平板适配方案：手机上仍然是普通的全屏页面跳转，平板横屏时自动变成左侧 start pane + 右侧 end pane 的双栏结构。

本文只看平板 / 大屏适配相关代码，业务逻辑不展开。

226个笔记 书籍作者：李笑来 说明：本文由 GA（GenericAgent）对整份读书笔记进行自动化整理、阅读友好增强，并发布到博客。 阅读友好增

在上篇文章中，我们使用的是 Android 自带的 AudioTrack 来音频播放的，现在我们要切换成 OpenSL ES 来播放，那为什么要换成这个呢 ？ 一个方面是因为 OpenSL ES 性能会好一些，且都是在

在之前的文章中，我们已经编译好了 ffmpeg so 库了，本章中，我们开始使用它进行编解码音频播放，需要先了解一些前置知识 音视频前置知识和之前写的一些 C 代码

前言 在上两篇文章中，我们已经学习了 CMake 和 Shell 的使用，接下来本篇文章开始对 ffmpeg 进行编译, 在编译开始之前 需要准备好 Linux 环境，下载 NDK，配置 NDK 环境变量等

当编译过程比较复杂的时候, 我们就可以使用 shell 脚本来简化这个过程, 同时版本升级, 重复构建的基础上 shell 脚本也能够重复利用, 下面直接开始看看 shell 脚本是如

在 Android NDK 开发中, CMake 是帮助我们来生成 makefle 文件的, 本文的示例是在 windows 中进行的, CMake 安装相关的可以参考本文 Windows10下配置CMake+Make+C