标签: iOS

一个人、一款 App、一个月:从 DoseLoop 看 AI 时代 OPC 的可能与边界

最近,我做了一款 App,叫 DoseLoop,中文名叫“用药有数”,主要功能是用药提醒和服药记录。目前已经上架了 App Store 和 Google Play。

这件事本身不算什么大事,一个用药提醒 App,也不是多么复杂的产品。但让我感受比较深的是,这个 App 从最初的想法,到产品设计、开发完成、App 备案,再到最后上架应用市场,大约只用了一个月,而且基本上是我一个人借助 AI 完成的。

所以,我也想借这个小产品,谈谈我对 AI 时代 OPC(一人公司)的一些感受。

我做 DoseLoop 的原因很简单,就是我自己有时候会忘记吃药。

这并不是说我不重视健康,而是很多时候,提醒响了,但当时正好在忙,心里想着等会儿再吃,结果后面就忘了。早上赶着出门,工作中开会,或者手头正好有别的事情,这些场景都很常见。等到晚上想起来时,药可能还在包里,或者药盒还放在桌上。

我之前也用过一些用药提醒类 App,但总觉得不太满意。有的提醒时效性有问题,响过一次就结束了,后面用户是否真的吃了药,并没有形成闭环;有的提醒又太强烈,给人的感觉像是在被催促,反而产生压力;还有一些 App 的 UI 和交互体验不太好,用起来并不舒服。

所以,我当时就在想,用药提醒这件事,看上去只是一个通知功能,但实际上并没有那么简单。真正重要的不是“通知有没有发出”,而是“用户是否真的完成了服药动作”。

从产品设计的角度看,这里面有一个很重要的矛盾:用药提醒需要闭环,但也需要克制。

所谓闭环,就是不能只在某个时间点响一下,然后就结束了。因为用户看到提醒,只是产生了吃药的意图,并不代表已经完成了吃药这个动作。意图和行动之间,经常隔着一段距离。可能是五分钟,也可能是一场会议,也可能是一整天。

所谓克制,就是提醒不能太粗暴。用药这件事,本身就和身体、疾病、压力有关,如果一个 App 的提醒方式太强硬、太频繁、太像命令,用户未必会更愿意执行,反而可能会想关掉提醒。

这里面其实有一些心理学依据。

第一个是认知负荷。人在忙碌状态下,大脑里同时处理很多事情,一些重要但不紧急的事情,很容易被延后。吃药就是典型的这类事情。它很重要,但在某个具体时刻,可能会输给出门、会议、工作、电话、消息和各种临时任务。

第二个是意图和行动之间的距离。很多提醒工具默认,提醒发出就算任务完成了。但真实情况是,看到提醒只是第一步,用户真正完成服药才是最后一步。如果中间没有持续的机制,就很容易断掉。

第三个是心理反抗。人对过度强制的提醒,天然会有抵触。特别是一些本来就带有压力的事项,如果提醒设计得不好,用户感受到的不是帮助,而是被控制、被催促。

所以,DoseLoop 的核心设计,不是单纯把提醒做得更强,而是让提醒在一段时间内持续存在,直到用户确认,同时尽量保持温和。

比如,DoseLoop 支持设置追踪时间窗口,可以设置 30 分钟、1 小时、2 小时、直到确认。在这个时间窗口内,App 会关注用户是否确认服药,而不是提醒一次就消失。

它也支持记录服药状态,包括已服用、已跳过、已漏服。这样,提醒就不是单向通知,而是形成了一个完整的服药记录闭环。

另外,DoseLoop 还支持不同提醒强度,比如温柔提醒、平衡提醒、强提醒。因为不同用户、不同药物、不同生活场景,对提醒强度的需求是不一样的。不是所有人都需要强提醒,也不是所有时候都适合强提醒。

在 UI 和交互上,我也希望它尽量克制,不要让用户觉得自己被管理、被监督、被惩罚。一个好的用药提醒 App,应该更像一个可靠但安静的助手,在你忘记的时候还在,但不会责备你。

这就是 DoseLoop 的产品出发点。

接下来就是做产品。

从时间上看,整个过程大约用了一个月(5月19日-6月17日,手里有其他主要工作,运用空隙时间)。产品开发大约用了两周多,注册 App Store 和 Google Play 开发者账号,准备应用市场的文字、图片素材,制作宣传视频,大约用了一周多。App 备案也用了大约一周左右。

整个过程基本都是我一个人完成的,并且大量使用了 AI 工具。

App 产品本身的开发,我主要使用了 CodeX、Claude Code、Antigravity,没有手写一行代码。这些工具在需求拆解、代码生成、功能实现、问题排查上都起了决定性作用。特别是现在的 AI 编程工具,已经不是简单的代码补全,而是可以覆盖完整功能的实现过程。

DoseLoop 的 Landing Page 是用 Claude Code 做的。以前做一个产品官网,虽然不算很复杂,但也需要前端开发、设计调整、内容组织,现在借助 AI,基本上一个人就可以完成第一版。

App的Logo、隐私条款、应用商店需要的文案,以及大量图片素材,我主要借助 ChatGPT 和 ChatGPT Image 完成。宣传视频则使用 Gemini 的 Veo 生成。

当然,这并不是说 AI 一键就把所有东西做好了。实际过程里,人还是要不断判断、修改、筛选和调整。AI 可以生成很多内容,但哪些能用,哪些不能用,哪些符合产品定位,哪些表达不准确,最终还是要自己决定。

但无论如何,AI 确实把一个人的能力半径放大了。

过去,一个 App 从 0 到上线,至少需要产品、设计、开发、测试、文案、市场、视频制作、合规等多个角色参与。现在,一个人借助 AI,可以把这些基础工作串起来,先做出一个可用版本。

这就是我这次最直观的感受。

DoseLoop 从一开始也是面向全球用户设计的,目前已经支持英语、中文、西班牙语和日语,后续还会增加葡萄牙语、德语、法语等更多语言。

在过去,多语言支持是一件比较重的事情。它不只是翻译几个按钮,而是包括产品界面、应用市场文案、关键词、截图文字、隐私条款、宣传素材等一整套内容。现在借助 AI,增加语言版本的成本明显降低了。虽然仍然需要人工检查和调整,但相比以前,门槛已经低了很多。

所以,从产品实现的角度看,我认为 AI 时代的 OPC 是完全有可能的。

OPC,也就是 One Person Company,一人公司。过去我们讲超级个体,更多是在内容创作、咨询服务、软件工具等方向。现在因为 AI 编程、AI 设计、AI 文案、AI 视频工具的成熟,一个人做一个完整 App,并不是不现实。

但这次经历也让我看到,AI 让产品开发变快了,并不代表所有事情都变简单了。

真正麻烦的部分,很多反而不在代码里。

比如公司资质、银行账号、开发者账号、主体认证、支付资料等问题,这些都是非常现实的问题。代码有 bug,可以调试;图片不好看,可以重新生成;文案不合适,可以修改。但公司资质和银行账号这些事情,涉及现实世界的规则和流程,并不是 AI 能直接替你解决的。

还有应用商店素材,也比我想象中更耗时间。App Store 和 Google Play 需要大量内容,应用名称、副标题、简短说明、完整描述、关键词、截图、置顶图、隐私说明、多语言版本、不同尺寸素材等等。即使用 AI 生成,也依然要花很多时间去整理、筛选、修改和上传。

所以,AI 并没有消灭工作,只是改变了工作的形态。

更重要的是,产品上线以后,并不代表商业就成立了。DoseLoop 现在已经上线 App Store 和 Google Play,但目前还没有下载量。这一点我觉得很有必要坦诚说出来。

因为它正好说明了 AI 时代 OPC 的边界。

从产品角度看,这次确实是一次完整的一人公司实践。我一个人借助 AI,在一个月左右完成了产品设计、开发、备案、官网、应用市场素材、宣传视频、多语言支持和上架。

但从商业角度看,这件事还没有被验证。没有下载量,就意味着用户还没有被触达,市场还没有感知到这个产品,产品价值还没有被真实用户验证,商业化更谈不上成立。

这并不是失败,而是一个真实的起点。

以前做产品时,我们经常会把“能不能做出来”看得很重要。但这次做完以后,我更加清楚地感受到,做出来只是第一步。

App 上架,只是获得了被下载的资格,并不代表自然会有人下载。现在不是缺产品的时代,而是缺注意力的时代。一个新 App,即使功能做得完整,设计也还可以,也很容易淹没在应用市场和社交媒体里。用户不知道它存在,就不会下载。用户没有建立信任,就不会长期使用。用户没有感受到足够价值,就不会付费。

特别是 DoseLoop 这种用药提醒产品,虽然它不是医疗诊断工具,但毕竟和健康管理有关。用户会关心提醒是否稳定,数据是否安全,产品是否可靠,是否值得长期使用。这些信任,不是靠几张 AI 生成的图片和几段应用商店文案就能建立的。

所以,AI 可以提高生产效率,但不能自动解决分发问题。

做出产品,解决的是生产问题。

获得用户,解决的是分发问题。

留住用户,解决的是价值问题。

让用户付费,解决的是商业问题。

AI 对第一个问题的帮助最大,对后面几个问题也有辅助,但不能替代真实市场的验证。这也是我对 AI 时代 OPC 比较冷静的看法。

从产品实现角度,OPC 已经非常可行。一个人借助 AI,可以更快地做产品,更快地上线,更快地完成过去需要多人协作才能完成的基础工作。

但从商业成功角度,OPC 仍然很难。

AI 降低了产品从 0 到 1 的门槛,但没有取消市场竞争,也没有取消用户获取成本,更没有取消商业模式验证。甚至,AI 可能还会带来一种错觉:因为做产品变快了,所以做成一门生意也会变快。但这两件事并不是一回事。

在我看来,AI 时代 OPC 最大的价值,不是让一个人轻松做成一家公司,而是让一个人可以更低成本地验证一个真实问题。过去,很多想法可能还没开始就结束了。没有团队,没有预算,没有设计师,没有工程师,不知道怎么上架,不知道怎么做素材,也不知道怎么做多语言。现在,这些门槛都降低了。一个人可以先做出 MVP,先上线,先看看有没有人需要,先测试市场反应,再决定是否继续投入。

这已经是很大的变化。

DoseLoop 对我来说,就是这样一次实验。

它证明了一件事:一个人借助 AI,确实可以在很短时间内完成一个完整 App 的产品链路。

但它也提醒我另一件事:产品上线不等于商业成功,全球多语言不等于全球增长,AI 生成内容不等于市场分发,一个人能把产品做出来,不等于一个人能轻松把产品做成。

所以,如果问我 AI 时代 OPC 是否可行,我现在的答案是:

从产品实现角度,可行。

从商业成功角度,不确定。

AI 让 OPC 更容易开始,但并没有让 OPC 更容易成功。

DoseLoop 现在刚刚走到这个阶段。产品已经上线,真正的验证才刚开始。

最后,欢迎下载使用DoseLoop · 用药有数

Apple App Store

Google Play

Android APK下载

星点传媒诚聘iOS开发工程师

星点传媒是我的创业公司,情况之前的Blog也有介绍,我们现在主要从事O2O业务,诚聘iOS开发工程师。

岗位职责:
负责基于公司iOS应用的技术设计和开发工作。
完成模块代码编写、单元测试、代码维护工作;
编写相关技术文档。

岗位要求:
1、学历不限,一年以上iOS平台开发经验;
2、熟练掌握Objective-C,Xcode等相关技术;
3、熟练掌握iOS SDK中基础、图像2D、网络、位置等相关技术开发及应用,以及常用的iOS程序开发和调试方法和技巧;
4、熟悉TCP/IP和无线通讯协议,熟悉XML、JSON等数据交换格式;
5、良好的规范编程习惯和开发文档编写能力;
6、具备较强的学习能力和沟通能力,具备较好的团队合作能力;
7、有责任感,工作态度严谨,能够承担高强度、高压力的工作;
8、有App store上线应用者优先。

有兴趣的朋友,简历请发至 job@starrymedia.com

解决iOS开发中zxing在release下不能正常工作的问题

zxing是一个开源类库,用于解析条码二维码(1D/2D),实现语言为Java,但其中也提供了Objective-C的一个包,Objective-C的实现只能读取QRCode。

我们最近的一个iOS工程需要在手机上识别我们的二维码,所以我采用了zxing,按照zxing的文档将ZXingWidget工程导入自己的工程,过程比较顺利,在我的iPhone上调试也没什么问题,但当我打成AdHoc版交付测试时,测试发现程序不能识别二维码,我挺奇怪,就在网上搜索,在zxing的FAQ上确实有这个现象的解释

Why does my application decode okay in debug mode on iOS but not in release mode?

You’re compiling with an old version of llvm-gcc or clang. If you use Xcode 4.2, either supported compiler should be fine with optimizations turned on. Older compilers, shipped with Xcode 4.1 and earlier, had an optimization bug in llvm that miscompiled ZXing. If you are using Xcode 4.1 or older, you should use gcc to compile ZXing, not llvm-gcc or clang.

意思应该是说可能使用了老版本的编译器,Xcode4.2之前都存在问题,但我的Xcode已经是4.3了,应该不存在问题,继续搜索其他资料,基本都是英文,但说的也不是很明白,应该是编译器的Optimization问题,后来我将项目引用的ZXingWidget工程的Optimization Level设为None,即-O0,再打AdHoc就没问题了。

具体为选择ZXingWidget工程的Targets中选择Build Setting,将Optimization Level设为None,即下面的Debug和Release都设为None。

支付宝无线商户接入遇到的问题总结

最近我在为“星点无线”产品增加手机支付功能,支付当然首先想到的是支付宝,而且也在其他类似无线产品里看到集成支付宝应用。

首先在支付宝无线商户平台里签约,我们分别签了“手机网页支付”和“手机应用内支付”,所在行业的费率会有所不同,请根据实际情况选择,“手机网页支付”和“手机应用内支付”的费率也不同,“手机应用内支付”低一些。

最开始,我只想简单一点,在iOS应用里内嵌Web,采用手机网页支付,服务器端是用PHP,手机网页支付,采用MD5和RSA两种签名方式,MD5相对简单,但安全性不如RSA,我最开始测试MD5,而且之前在网站上集成支付宝,也没啥问题,开始是比较顺利的,到支付宝支付时,支付宝默认选择了短信支付方式(可能和我们签约的分类有关),也就是支付宝会通过手机短信发送一个验证码,然后回复验证码,支付宝再会发送一个短信,短信里包含一个URL,点击这个URL,会提示支付完成,然后转到我们网站的回调地址,我方程序完整成个订单,但支付宝提供的这个URL,有时候打开会报错误,而且也不是每次都错,非常的奇怪,更大的问题是在成功后回调我服务器程序时报签名不对,我仔细检查了配置,没有问题,只能一点点排错,最后发现支付宝提供的Demo包里alipay_function.php的para_filter方法有问题,这个方法会漏掉回传的out_trade_no参数,非常的奇怪,只有修改这个方法为

function para_filter($parameter) {
  $para = array();
  foreach ($parameter as $key=>$val) {
    if($key == "sign" || $key == "sign_type" || $val == "") {
      continue;
    } else {
      $para[$key] = $parameter[$key];
    }
  }
  return $para;
}

签名问题解决,但由于短信支付最后这个URL的诡异表现,我为此专门询问支付宝客户支持,得到的回答是他们也发现这个问题,但不知道是什么原因造成的,技术也解决不了,竟然也有支付宝解决不了的问题啊!

这个问题不能解决,确实对用户的体验不太好,我只能选择“手机应用内支付”,支付宝提供了iOS的集成代码,文档也算详尽,但iOS的签名采用RSA,所以在服务器端先要改为RSA的(RSA的alipay_function.php para_filter方法有同样的问题),生成公钥、私钥的方法在文档里比较清楚,就是注意上传商户公钥时一定要删除文件头“—–BEGIN PUBLIC KEY—–”与文件尾“—–END PUBLIC KEY—–”还有空格、换行,变成一行字符串并保存为TXT文件,商户私钥在PHP程序不需要转为PKCS8格式,而在其他语言里(比如Objective-C)需要转为PKCS8格式,并在iOS应用里设置plist文件中RSA private key变量时,要把PKCS8格式私钥的换行和头尾的“—–BEGIN PRIVATE KEY—–”与“—–END PRIVATE KEY—–”删除。

在iPhone真机调试过程中,跳到支付宝应用时报签名错误,我又仔细检查了好几遍,确定没什么问题,后来在支付宝的指导下先测试运行他们提供的Demo程序,没有问题,说明签名密钥没问题,肯定是要签名的数据有问题,我对比了一下发现AlixPayOrder中的productDescription不能为空,也就是传输数据中的body变量不能为空,终于完成了无线支付的集成。

支付宝提供的文档还算比较全面,但有些地方还是有些含糊,如果是iOS集成的话,先测试它提供的Demo程序,以确定密钥的正确性,仔细调试,记录Log,还是比较容易集成的。

星点无线1.5

今天,星点无线1.5已经通过App Store的审核,上架了,地址在http://itunes.apple.com/cn/app/id448294946?mt=8,也可以在App Store里搜索“星点无线”或是“StarryMobile”找到这个应用。

星点无线1.5的主要改变有
全新UI设计
支持iOS5
更加舒适的用户体验
提高运行速度与稳定性
支持调查任务筛选与优惠券排序
增加信息推送功能
修复优惠券显示文字高度的BUG

星点无线1.0和1.1的原始程序是我们找外包团队开发的,1.0和1.1发布时,我已经修改了其中很多的代码,在我们设计1.5的功能时,我觉得,不能在1.0/1.1的基础上改了,老版本存在许多的问题,特别是在性能及内存使用方面有很多不足,代码整体质量不高,我准备重写1.5版本,来个干净彻底,我是10.1假期之后开始重写,在美工设计的配合下,到10月底完成了这个版本,期间iOS5正好发布,这个工程也转到iOS5下开发。

 

 

星点调查 for iPad

星点调查 for iPad已在10月6日通过App Store的审核,上线了,星点调查是一款依托与星点调查平台的调研终端工具,支持多种调查题型,可以帮助商业用户快速进行调研数据收集,有兴趣的朋友可以下载使用:http://itunes.apple.com/us/app/id467284642?mt=8

星点调查是我独立编写的iOS程序,并且是建立在星点调查开放平台之上(http://open.starrysurvey.com/),因此验证了星点调查开放平台可以方便的为企业灵活构建调查业务。

  

星点无线

星点无线-StarryMobile是一个免费的iPhone应用程序,通过完成基于地理位置的调查任务,可以获得积分或相关优惠券,用户可以方便的管理与使用获得优惠券,或将积分兑换为奖品。

这个产品是我们公司开发的,我编写了其中很大一部分代码,也是我对iOS开发的第一次实践,在后面将不断增加新的功能,并与我们的星点网(www.xingdian.com)有更好的整合。

欢迎大家到App Store里下载使用,http://itunes.apple.com/us/app/id448294946?mt=8

 星点无线 星点无线

星点无线 星点无线 星点无线

iPad程序不能正常翻转显示的问题

最近做了一个星点调查的iPad客户端程序,提交App Store审核之后被打回了,说程序只支持纵向显示,在用户翻转之后(即Home键在上面时)也应该能正常显示。

我想只要在shouldAutorotateToInterfaceOrientation方法里加上反向的支持就可以了,即

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
    // Return YES for supported orientations
    return (interfaceOrientation == UIInterfaceOrientationPortrait || interfaceOrientation == UIInterfaceOrientationPortraitUpsideDown);
}

但是修改之后,发一些页面没有问题,但有些页面还是不能正常显示,有些情况下翻转屏幕有效,有些情况下不行,我百思不得其解,搜索了大量资料(大多是英文的,中文的几乎没有),但也没有完全能解释清楚的,我只能不算试错,发现似乎是UINavigationController默认情况下不能支持UIInterfaceOrientationPortraitUpsideDown,网上的资料也好像提到这个原因,我仔细检查了一下,我的UINavigationController用法似乎不太对,于是我新建一个类,继承自UINavigationController,重写其shouldAutorotateToInterfaceOrientation方法,使其支持UIInterfaceOrientationPortraitUpsideDown,试了一下,果然好了:)