人脑的上下文容量和大模型比差得太远，和AI相比，人类的优势是发现需求，发现美，敢于畅想和追逐
-
-
每天都要感叹AI的牛逼，我就是个猴子。今天调试支付升级VIP，通过AI一天完成了过去两三周的工作，涉及支付sdk集成，后台回调，六七张数据表的联动，我作为猴子虽然什么都不会，但是能问问题，粘贴，引导，就可以解决问题。
-
大概搞清楚了一个expo开发react native应用遇到的闪退问题原因，我的情况很特殊，特此记录一下：
1、我使用react-native-voice/voice库处理语音识别，这个功能依赖于两个权限：麦克风和语音识别权限。
2、在权限设置环节有两种做法：一是配置expo插件，自动处理；二是修改info.plist文件，由于我的应用使用expo工作流，我一般不会直接修改ios文件夹内的内容。
3、由于我vibe coding，导致生成的代码改了又改，AI认为我的功能需要使用expo-speech和expo-speech-recogonition这两个库，但是我曾经显示地告诉他我希望使用react-native-voice/voice库，导致代码中导入了三个库，但核心逻辑代码确实按我的要求做了，配置app.json中却配置了expo-speech和expo-speech-recogonition的plugins。
4、由于我没使用expo-speech和expo-speech-recogonition，因此我在app.json文件中删除掉expo-speech和expo-speech-recogonition的plugins，这导致没有处理好系统权限请求（其实react-native-voice/voice库有专门的插件，但由于vibe coding，ai没有用），进而导致了一进入语音识别功能就会闪退的问题。
5、我告诉ai应用会crash，它修改代码逻辑了无数次还是会闪退，最终定位到这个原因，我查了一下ios文件夹内的info.plist文件，确实没注册语音识别权限，于是需要重新修改权限配置，清理依赖关系。
总结一下这个问题的原因
移除 expo-speech 和 expo-speech-recognition 导致闪退的原因可能与以下因素相关：
1. Expo 插件的隐式权限管理 Expo 权限自动化：
Expo 的 expo-speech 和 expo-speech-recognition 插件在预构建阶段会自动处理原生权限配置（如 Android 的录音权限 RECORD_AUDIO 和 iOS 的麦克风权限 NSMicrophoneUsageDescription），即使代码没有显式调用这些库，它们仍然可能通过插件机制注入必要的原生配置。
原生配置依赖：
如果直接使用 react-native-voice 但未手动配置原生权限，移除 Expo 插件会导致权限缺失，应用在调用语音功能时因权限拒绝而闪退。
2. Expo 预构建插件的原生依赖
插件与原生模块的绑定：
Expo 的预构建插件（如 expo-speech）可能包含与 react-native-voice 相关的原生依赖或桥接代码。移除后会导致原生模块无法加载，从而触发崩溃。
自动链接的副作用：
即使我未在代码中调用 Expo 插件，它们可能通过 app.json 中的 plugins 字段自动链接到原生项目。移除插件会破坏这种隐式依赖关系。
-
整理一下如何在一台机器上docker部署多个网站，并且多个网站共用同一个证书：
1、统一用docker-compose.yml编排容器
2、nginx，certbot，网站应用都用容器统一编排，可以提高效率
3、服务器环境和本地开发机环境不同，要注意打包镜像时确保环境正确
4、服务器和本地环境的差异导致有很多不好解决的问题，这时候AI的指导非常必须，要感谢腾讯元宝+Deepseek
5、将复杂的命令行指令写成脚本会让整个运维逻辑更加清晰
6、证书要设置自动续期
-
这个网站上线五年，终于弄了个ssl证书，被AI赋能感觉真好啊...
-
12天，从一个idea到完整的iOS应用，明天开始优化界面
-
进入心流状态后处理任务都是两三个小时解决一个核心问题，我好像比较喜欢处理多个不同类型的任务，如果一天安排3-4个不同类型的核心任务比做一个大任务效率更高
-
真正的执行力在于心无旁骛的达成所承诺的事情，没有理由，没有借口
-
阳光一天比一天好
-
过去一年半，我通过AI做了一个半产品，其中第二个还没完成，回顾一年半的经历，我总结了以下心得和改进方向：
1、我投入了很多精力做的产品是“小需求，大产品”，意思是耗费很多精力做产品和工程，但是产品需求刚性不强，分析原因，第一个项目的立项抱着进入AI行业做点什么的初心，看到别人在做chatPDF就开始了，在启动过程中带有学习心态，而chatPDF类的产品当时在业内已经有很多家，所以这是一个跟随战略，产品上线时已经完全没有稀缺性了，事实证明这个策略不适合startup（可能更适合更大规模的公司，因为有更多策略和空间去跟随发现对的方向），虽然学到了东西，但是结果不好。第二个项目是在第一个项目基础上，考虑如何pivot，结合了自己遇到的问题，找到了一个切实存在的场景，但是这个项目的综合难度超出了团队的能力，目前做了四个月，继续学到了很多东西，但是做得很吃力，拿这个项目投递了奇绩创坛，得到投资人的反馈认为这个不是市场上的主要问题，可能缺乏足够的吸引力，加上目前还没有一个完整版本上线，所以最近对这个问题的反思比较多。
2、相对“小需求，大产品”的是“大需求，小产品”，我对这个概念的理解是解决了一个刚性问题（市场不一定很大），但是需求一定要足够强。通过较小的产品投入即可满足，比如2周即可上线产品初始版本。最近的案例是前几周爆火的小猫补光灯，这是典型的“大需求，小产品”，这样的产品稀缺性强，适合startup操作，再往前是24年初的哄哄模拟器，在qq群传播达成了一波流量高峰，这些产品的商业价值不谈，后续商业价值可能也存在较大的操作难度，但是这些案例证明了产品满足了一部分用户的需求，这本身就是价值，先有用户价值才有商业价值，解决一个领域的强需求是更适合startup来操作的。以前成功的脸萌App的商业模式设计是积累足够的用户量然后做游戏发行渠道，虽然后期的发展轨迹和最初的设计有区别，但是团队成功拿到了融资，继续研发产品进而被头条收购，多年以后创始人郭列又进入游戏行业，此时和彼时手里的资源已经完全不同，我看到了创业者的初心和成长轨迹的权衡。换句话说，对startup来说，成功的唯一路径是在一个小市场解决一个刚性问题，并且获得市场的证明。
3、创业多年，timing的重要性我有自己的理解，商业模式我也思考完备，用户需求我非常敏感，当前的问题出在我在启动一个项目时，似乎更多的精力放在了“自身的需求”（比如学习技能，比如肤浅的挣钱），而不是解决“他人的需求”（某个场景的问题），满足他人的需求，是服务他人，满足自身的需求是服务自己，这个细微的差别导致了我潜意识中喜欢做一些有挑战的事（因为这是我自己的需求），而能力与目标始终存在一定的差距，这导致了做事事倍功半，早年的创业和现在创业似乎没有太本质的区别，虽然现在有了AI，但对于所有人这个条件是公平的，所以还是需要调整创业的根基，这样可能才可以带领我走向正确的方向。
根据以上总结，下一个阶段我规划做出以下调整：
1、和团队讨论第二个项目继续的必要性，设定一个切实可行的目标；
2、调整今年的精力分配：
1）投入时间放入可以变现的内容平台，将过去一年半的经验拆解沉淀；
2） 持续发现“大需求，小产品”，充分利用AI辅助编程，验证我的设想，取得一些产品和服务领域的成功结果。
-
Anthropic关于AI Agents的报告要点
- 成功的Agent不依赖于某个特定的框架，他们都使用容易理解的pattern;
- agentic system：区分workflows和agents，前者精心规划流程，后者由LLM自行决定路径和所使用的工具；
- 明智地决定何时使用Agentic system，做好成本和效果的tradeoff；
- 框架vsAPI：大多数情况直接使用API，框架会造成复杂度，如果使用，需要清楚背后逻辑；
- Augumented LLM：Retrieval，memory，tool，推荐使用MCP，方便与生态融合；
- Workflow---Prompt chaining：适用于可以被分为多个子任务的任务，比如生成营销文案然后翻译成多语言，撰写outline，确保outline是否满足既定标准；
- Workflow---Routing：适用于分发不同类型的用户请求，根据任务复杂程度选择不同能力的模型；
- Workflow---Parallelization：适用于sectioning和voting类型的问题；
- Workflow---Orchestrator-workers：由一个核心调度LLM，决定不同的LLM call，通常应用于复杂且不能被明确设计或划分子流程的任务，比如变成任务中需要修改多个相互依赖的为文件，搜索任务中可能从多个信息源搜索并整理数据；
- Workflow---Evaluator-optimizer：给予结果反馈，通常用于文学翻译中检查是否有细微差别，复杂搜索时反馈是否需要进一步搜索；
- Agents：开放和复杂的问题，agent可以获取调用工具的信任；
- 以上pattern不是固定的，可以组合使用，核心原则是：只有确认可以获得更好结果时才增加复杂度。
- 设计agentic system的三个核心原则：1）保持设计的简洁；2）保持透明，明确展示代理的规划步骤；3）通过详尽的工具文档和测试，精心设计代理-计算机接口（ACI）
-
2024个人年终总结
一、年度回顾
1. 主要成绩
工作方面- 完成Chatfiles应用版本发布，获得第一笔应用收入；
- 完成Userguide.press项目立项及demo制作。
- 学习react，next.js，tailwindcss，shadcn/ui，redux等前端技术栈；
- 学习使用v0，cursor，chatGPT快速制作产品原型；
- 学习使用final cut pro，elevenLabs等工具制作和剪辑视频；
- 学习使用Revenuecat给App接入支付；
- 学习使用pageUI快速制作公司和产品落地页；
- 学习AI Agent的设计思路。
- 控制血脂（低密度脂蛋白）到正常水平；
- 停服降压药，血压整体平稳在120+/70+；
- 通过饮食控制将空腹血糖降低到5.2， 糖化红蛋白降低到5.6；
- 坚持每周打网球，每周去健身房，每月录制网球视频；
- 完成山西古建之旅；
- 重庆一周美食之旅。
2. 重要事件
- Chatfiles发布，人生第一次经历完整的App设计、开发和发布流程；
- 投递奇绩创坛（跟进动态中）。
3. 数据总结
关键指标- 工作指标: 完成1.5个项目，达成率70%；
- 学习指标: 学习多个新技术，总体结果满意；
- 健康指标: 网球和健身锻炼总体达标；
- 阅读：读书6-8本。
- 工作：60%；
- 锻炼：10%；
- 娱乐：20%；
- 阅读：10%。
二、反思与经验
1. 成功经验
- 实现了ChatFiles的网页分析功能，从产品思路到实现整体完成的不错。
2. 不足与改进
不足- 时间管理：工作投入比例不够，工作状态波动较大；
- 身体管理：情绪波动，容易被工作压力和对身体的忧虑影响情绪；
- 工作目标：ChatFiles最后一个版本消耗过长的时间，导致转向Userguide.press的时间晚了一个月左右；Userguide.press的demo制作过程有些慢，能力需要再提升；
- 思考：没有足够的时间思考事务的主要矛盾。
- 减少选择：减少生活中不必要的选择，如工作地点，时间，锻炼时间安排等，形成固定节奏；
- 冥想：通过冥想活动增强情绪稳定性，减少负面情绪和消极思想；
- 每周花一天时间思考正在做的事情，分析框架： 1) 主要矛盾； 2) 我当前在主要矛盾上花费的精力是否足够； 3) 是否有解决方案； 4) 解决的目标时限。
三、展望未来
1. 新一年目标
工作目标- Userguide.press种子客户导入及获得收入，获得客户10个以上，持续在AI Agent产品道路上推进产品；
- Mindpower获得第一笔融资。
- 每周至少去3次健身房，1次网球；
- 阅读10本以上书籍；
- 结识 AI 行业新朋友3位以上。
- 血压：120/80以内；
- 体重：72kg以内；
- 糖化红蛋白：<5.6。
2. 计划与方法
- 方法 1: 固定工作和锻炼习惯；
- 方法 2: 每周复盘思考，每月回顾问题。
四、感悟
- 思考事务的主要矛盾，把大部分精力投入到解决主要矛盾；
- 心怀目标，脚踏实地；
- 行动起来永远是解决焦虑的唯一方法。
2024年12月31日夜
-
在大模型时代做产品时更应该考虑一个需求需不需要被实现，因为我们会假设所有的功能都可以被实现，而不是像过去的时代，做产品更多的考虑一个功能的可实现性和怎么去实现。现在由于有了大模型的加持，应该把更多的精力解放出来，思考一件事情应不应该存在，由于过去的资源匮乏和能力所限，很多时候做错了
-
完美主义者蜕变为富有生产力者的必经过程，就是意识到电影只是电影，而生活是真实的，身边牛叉伟大的事情也是由普通人做出来的
-
很有意思的观点，但我有一点不同的理解。在一个稳定的需求内核下，软件功能的确应该是稳定的，但是我认为迭代不一定是降级，而是代表在创作者眼中，软件还没有满足那个内核需求，使用者看到的是他认为的终极形态，创作者眼中也有一个，而往往通往这个终极形态需要相当长一段时间，这个过程产品的迭代也伴随了用户的需求和使用习惯的迭代，而这种软件的价值也会随时间流逝而增加。如果停留在初始的状态可能在某些用户眼中也是美的，但是没有达成创作者的期望，也不能变得更有价值。这背后的驱动因素还是市场需求的判断和市场容量大小。