这个网站上的声音素材用来作为 Marketing Video 的背景声挺不错的

本文作者Takuya分享了他如何为SaaS产品Inkdrop（一款Markdown笔记应用）吸引到首批500名付费用户的经验。Inkdrop目前拥有600名客户，月收入3200美元，定价为每月4.99美元或每年49.9美元。作者强调，成功并非依赖于大型博客的报道或广告，而是通过专注于提升现有用户满意度、口碑传播以及分享个人产品策略和经验来实现的。...

本文详细介绍了作者如何独立开发并成功运营一款名为 Inkdrop 的多平台 Markdown 编辑器，实现了每月 1300 美元的盈利。作者在东京担任自由职业者期间，利用项目制收费模式为自己争取了充足的开发时间。Inkdrop 的月收入从最初的 360 美元增长到 1361 美元，作者希望未来能以此为生。

文章的核心思想围绕着“发现痛点、构建 MVP、获取早期用户、关注可持续性、优化用户体验和营销策略”展开。作者强调，他从自身日常遇到的问题出发，开发了一款满足自己需求的 Markdown 笔记应用，该应用专注于 GitHub 风格的 Markdown 编辑、简洁美观的 UI、快速同步和离线支持。在技术选型上，作者采用了 Electron 构建跨平台桌面应用，ReactJS 用于移动版本，并利用 CouchDB 和 PouchDB 实现快速同步。...

本文由 Thorsten Ball 撰写，旨在提供关于如何进行有效产品演示的实用建议。作者强调，成功的演示不仅仅是展示产品功能，更重要的是与观众建立连接，清晰地传达产品的价值和解决的问题。文章开篇即指出，演示者应首先明确产品解决的问题及其背后的原因，从而为观众提供一个理解产品的背景和动机。

在演示过程中，作者强调了保持流畅性和同步性的重要性。他建议演示者不要自我打断，并确保口头讲解与屏幕内容保持一致，避免观众分心。时间管理也是一个核心要素，作者反复强调要“保持简短”，甚至“更短”，以避免冗余信息和观众疲劳。

为了确保观众抓住重点，作者建议演示者主动指出关键信息，例如在展示一个处理大型文件的工具时，要明确告知观众其处理能力，而不是期望他们自行发现。同时，演示中应避免展示不必要的内容，例如全屏录制时显示无关的菜单栏图标或电池电量，这些都可能分散观众的注意力。...

这个开灯/关灯的效果太酷了

又踩了一坑：在模拟器里稳定复现的 Bug，在真机上居然没有问题。更有意思的是，拿这个 "Bug" 去问两个 Coding Agents，一个个都回答地头头是道，信心满满，还不一样···

首选 Sonnet-4.5，实在解决不了再找 GPT-5-Codex，这是目前我的最佳实践。

GPT-5-Codex 和 Sonnet-4.5 真是两个极端，前者不会有任何情绪输出，非常地 Nerd（即使错了，也不会道歉），后者则是时不时找到了 Root Cause（虽然常常不是）。

有时真的会被 GPT-5-Codex 气到，花了半小时写了一小段代码，然后告诉你，你自己去 build 一下（明明已经把 build command 写在了 Agents.md 里），结果一 build，各种 error···。

相比之下 Sonnet-4.5 则是会很主动地去 build，出结果也很快，就是不怎么靠谱···

又学到了，用 Text(context.state.startDate, style: .timer) 来 update Live Activity，但显示的时间总是不能右对齐，GPT-5-Codex，Sonnet 4.5 都失败了，最后还是在 StackOverflow 找到了解决方案，加一个 modifier .multilineTextAlignment(.trailing)，虽然看起来是用于修饰多行显示的，但其实单行也可以。

今天的 GPT-5-Codex VS Sonnet 4.5，前者完胜。一个 Feature，后者啰里八嗦了 10 来遍，找到了 Root Cause，改了半天，根本不 Work。前者 One Shot，直接搞定！

Vibe Coding 带来了大量的碎片时间，这些碎片时间该如何高效利用 🤔

本文作者丹尼尔·德·莱尼（Daniel De Laney）指出，自由开源软件（FOSS）领域普遍存在一个问题：许多功能强大的工具拥有“高级用户”界面，这使得普通用户望而却步，甚至放弃使用，或者不得不寻求技术人员的帮助。作者以视频转换工具Handbrake为例，说明普通用户常常因视频格式问题而感到困扰，但Handbrake复杂的界面令他们感到不适。

为了解决这一问题，作者提出了一个解决方案：为这些功能强大的工具开发一个简化的前端界面，隐藏其复杂性，只保留普通用户最常用、最核心的功能。他以自己开发的Magicbrake为例，这是一个Handbrake的简化前端，只有一个按钮，其唯一功能是将“奇怪”的视频文件转换为通用的MP4格式。作者强调，这种简化并非削弱软件功能，而是通过隐藏不常用功能，让普通用户更容易上手和使用。对于需要高级功能的用户，他们仍然可以使用原版软件。...

We've streamlined the entire RAG process. File Search automatically manages file storage, optimal chunking strategies, embeddings and the dynamic injection of retrieved context into your prompts. It works within the existing generateContent API, making it easy to adopt.

这可太方便了，一个 API 搞定一整套 RAG！

用 Rive 做的动画，效果还挺不错的

对舒服的 UI 毫无抵抗力···

把 Prompts 也录入到项目中了，感觉还不错，会 push 你去思考这次改动到底要做什么，也方便将来 Review。

AI Agents 有一个共同的「毛病」：过于顺从。给一个 command 后，都会想着如何去实现它，而不会反思这个 command 结合当前的 context 是否合理，是否有更优的解决方案。

为了这寸土寸金的 Context，还是把 XcodeBuild mcp 给 disable 了吧···

这个设计看着很舒服

这个苹果官方的视频中提到了不少性能优化技巧，挺值得一看的。

做了个自省的 App -- PingMind（暂不支持国区），方便做 Daily/Weekly/Monthly Reflection，用来写晨间日记也是不错的。不需要注册，开箱即用，支持 iCloud 同步。

又踩了一个坑（其实是代码不严谨）：国行 iPhone 在首次打开 App 时，会弹出「是否允许联网」的窗口，在用户点击允许网络请求之前，所有网络请求都会失败，要做好兜底。

Claude Code 又进化了，Plan Mode 下，用户可以方便地给 Input 了

发现 Sonnet 4.5 的 Ego 还蛮大的，抛了一个 bug 让它解，它说找到了 Root Cause（其实不是），然后我发现了真正的 Root Cause，跟它 Argue 时，它会极力维护自己之前的结论，并声称「虽然你找到了 Root Cause，但你之前的代码也是有问题的，按照我这么改会更好」，并罗列了理由，当我反馈它的理由不成立时，就听不进去了···

踩了个小坑，原来 CloudKit 的 Schema 初始化/改动要在 iCloud Developer 网页后台手动 Deploy 到生产环境后才能正常工作。

原来苹果的 App Store Small Business Program 需要单独申请，不会默认开通···

如果平时的一些 Bug / Feature 都让 AI 来完成，代码都让 AI 来写，那么遇到 AI 实在搞不定的棘手 Bug 或 Feature 时，作为人又有什么自信能够解决 🤔

调试 SwiftUI 的一个 performance 问题，最终还是通过 Color.random() 找到了端倪。

同一个 Bug，让 Claude Code (Sonnet 4.5) 和 Codex (GPT-5-Codex) 分别试了 5 - 10 次，都搞不定，结果 gemini-cli 一次搞定···

看来要把 gemini-cli 扶正了。

Update: 又给了一个 case 让它解，一塌糊涂···

终于找到了在 iOS 26 上 disable 系统自动加上的 Liquid Glass on toolbar，奥义就是使用 .sharedBackgroundVisibility(.hidden) modifier.

因为 Copilot / Codex / Claude Code 全部 hit limit，索性试试让 Copilot 接入 OpenRouter 的 Sonnet 4.5，好家伙，不到 10 分钟，$10 没了，问题还没解决···

让 AI 写代码，很重要的一点是判断力：

• 这是一个多大难度的 Feature？
• 应该交给哪个 Agent 来实现？
• 需求是否要再细分？
• 需求是否没有说清楚？
• Agent 是否已经撞墙？
• 是否要换一个技术方案？
• 是否已经到了 Agent 的能力极限？
• 是否要拉另一个 Agent 来一起 Review 代码？
• 是否需要自己介入？

这些判断力就是一个程序员综合素质的体现。

MCP 真是把双刃剑，一方面真是能提高效率，另一方面也真是耗 Token，实现一个 SwiftUI Feature，Agent 一大半时间都在跟 MCP 沟通（比如 XcodeBuild mcp，在那又是截屏，又是跳转页面，来来回回，token 都快用完了，目标按钮都还没找到）。

一个 Prompt 耗时一个小时成就达成。

发现自己的 Blog 用 node serve 时，会消耗 200M+ 的内存，想着 Bun 以性能著称，就试了下用 Bun serve，结果内存直接翻倍···

Claude Code 和 Codex 真是一个都不能少，前者适合需求明确的小任务，后者适合需要思考量的复杂任务。

目前对 GitHub Copilot Pro + Claude Code Pro + Codex Pro 的配搭比较满意。

Codex 在执行任务时，需要用到 Zip 来打包，一生要强的 Ta，最后手写了一个···

Replaced the use of missing system ZIP APIs with a custom zero‑dependency ZIP builder (Shared/Utilities/ReviewExportService.swift:244) so CSV export now packages daily/weekly/monthly answers without compilation errors. Nothing else needed

踩了个坑，iOS 18 上，如果 place 一个 menu（label 为 Image） 到 .topBarTrailing，那么它是不会水平居中的，会向右横移几个像素（同样的代码设置为 .topBarLeading 就没有问题），解决方案就是手动为这个 image 设置 offset。

本文作者 Peter Steinberger 分享了他在使用代理工程（Agentic Engineering）方面的最新进展和经验，强调了“直接对话”（Just Talk To It）的无废话方法。他指出，代理工程已能生成几乎 100% 的代码，但许多人仍在尝试复杂的方法而非直接解决问题。作者主要使用 codex CLI 工具，并行运行多个代理，并让它们进行原子提交，以保持 Git 历史的整洁。他偏爱 gpt-5-codex 模型，认为它在智能和速度之间取得了很好的平衡，并能自动调整思考深度。...

Coding Agents have fundamentally changed the way I code.

这个 menu bar 小工具挺方便的，可以让网页驻留在工具栏

现在一些有点复杂度的 Feature 都是让两个 Coding Agent 互相 Review，效果还可以。

前几天看完《梵高手稿》有点不过瘾，就整理了下他的通信记录，并做成了一个网站。

在一个 iOS 项目里，refactor 一个 struct name，Xcode 搜索了两分钟，还没有找到所有引用该 struct 的地方，而这个项目大概只有二十个文件，每个文件不超过 1000 行，真正引用的文件只有1 个 🙂‍↕️。

这个月才刚过一半，Copilot 300 Requests 的份额就快用光了，感觉得开启 GLM 4.6 了。

看来还是要开启 Plan Mode，尤其是对于有一定复杂度的 Feature

这个 Timeline 的效果挺不错的，还是开源的。

同一个需求分别让 Copilot、Codex 和 Claude Code 来实现，最后是 Claude Code 在第三次完整地实现了。Copilot 和 Codex 都失败了，其中 Codex 更是辛辛苦苦做了 20 分钟，最后拉了坨大的，给了反馈后，也调整不好，属于班里那种非常勤奋，但成绩又不拔尖的同学。