我完全不会 Swift，也没有 iOS 开发背景。但过去一段时间，我用 Codex 从一个模糊想法开始，做完了一个 iOS App；随后又继续准备 App Store 发布材料，搭建官网，并制作 marketing 素材。这件事最值得记录的地方，不是我又做了一个新产品，而是一个原本难以跨过工程门槛的人，借助 AI 编程完成了从想法到发布准备的一整套工作。

这个 App 叫 DailyTrace（日迹），是一个记录真实生活时间的轻量工具。这里先简单交代背景：它不是任务管理器，也不是效率打分系统，而是帮助用户看见自己的时间大致花在了哪里。

但这篇文章不想重点介绍这个产品。我更想写的是这次实践带来的第一手体验和思考：vibe coding 究竟改变了什么，哪些地方真实有效，哪些地方又容易被误解。

AI 编程确实降低了开始做产品的门槛

很多人第一次看到 AI 编程工具时，都会产生一种强烈的感觉：是不是以后只要说一句话，AI 就能写出一个 App 或网页？是不是从此以后，人人都可以编程了？这个想法当然有夸张的部分，但它也不是完全没有道理。

在这次之前，iOS 原生开发对我来说是一道很高的门槛。我可以提出产品想法，可以写需求，可以判断一个工具产品应该轻还是重，也可以评估交互和视觉是否合适。但如果要真正写出 SwiftUI 页面、处理 SwiftData、本地状态、Widget、Live Activity、系统权限和构建配置，这些都不是我能独立完成的工作。

AI 编程改变的是这个入口。它让我可以把“我想做一个这样的工具”继续向前推进，而不是停留在“我有一个想法”。

这次实践最后也不只是一个只有首页的玩具原型：我完成了 SwiftUI 页面、本地存储、时间线、统计视图、分享图、Widget、Live Activity、多语言文案、内部测试和正式版本隔离，也准备了 App Store 发布材料、隐私说明和截图计划。

这些工作放在过去，对一个不会 Swift 的人来说，很难独立完成。AI 编程真正让我兴奋的地方，是它降低了“能不能开始做真实产品”的门槛。

但它不是几句话生成一个 App

门槛降低，并不意味着几句话就能做好一个产品。AI 可以让你更容易开始，但它不会自动产出正确的产品。它可以快速生成页面、代码和文档，也可以迅速把一个错误方向实现得相当完整。如果一开始只是模糊地说“做一个记录时间的 App”，然后不断让 AI 继续扩展，最后很可能得到一个功能很多、但方向不清楚的结果。

所以我不太把 vibe coding 理解成一种随意的开发方式：想到什么就让 AI 写什么，只要能运行就继续叠加功能。

至少在这次实践里，真正有效的 vibe coding 反而需要明确约束。要说明目标，要读已有代码，要匹配项目风格，要控制修改范围，要定义成功标准，要验证结果。很多时候还要明确告诉 AI：不要顺手重构，不要增加没有要求的功能，不要为了一个小问题引入过度设计。

AI 的执行速度很快，这是优点，也是风险。它可以让反馈循环变快，但不应该让标准降低。相反，因为迭代更快，人更应该清楚地知道自己要什么、不要什么，以及为什么。

先把想法问清楚，再开始写代码

这个项目的起点，其实不是一个一开始就完整清晰的产品方案。最初我只是有一个模糊的想法：我想做一个很轻的工具，用来记录真实生活里的时间。不是任务管理器，不是番茄钟，不是习惯打卡，也不是一个给自己打分的效率系统。它应该只是帮助我看见时间是怎么被使用的。

这个方向听起来简单，真正开始想的时候，会遇到很多问题。要不要有任务？要不要有标签？要不要有目标？要不要提醒用户补记？要不要分析空白时间？要不要用 AI 帮用户总结一天？这些功能单独看都合理，但叠在一起，很容易让一个原本想要轻量的工具变成另一个复杂系统。

遇到这种情况，我的做法是先和 AI 讨论，但不要一上来就让它“开始写代码”，而是先让它追问：这个产品解决什么问题？目标用户是谁？使用场景是什么？核心流程是什么？哪些功能看起来有用但可能让产品变重？这个过程的价值不在于让 AI 直接给出答案，而在于它能把一个原本含混的想法展开，让我看到其中尚未想清楚的部分。

但这里也有一个需要警惕的地方：AI 有迎合人的倾向。如果我说“要不要加一个 AI 总结功能”，它很可能会顺着这个方向帮我设计一套看起来合理的方案。如果我说“要不要提醒用户补记”，它也能继续帮我展开提醒策略、触发条件和文案。问题在于，这些方案单独看都能成立，但它们不一定符合这个产品真正想要的方向。所以在需求整理阶段，和 AI 对话不是让它替我决定，而是借助它不断反问自己：这个功能真的需要吗？它解决的是核心问题，还是只是让产品看起来更完整？它会不会让产品变重？它会不会改变我最初想要的克制感？

最后形成的几个核心边界，就是这样逐渐收敛出来的：点击活动即可开始记录；只记录用户主动记录的活动；不分析空白时间；不做自律评分；不做任务管理；第一版也不接入 AI 分析。这些判断并不复杂，但它们很重要。因为它们决定了后面所有设计和开发的方向。

这也是我后来对 vibe coding 的一个理解：它并不是从写代码那一刻才开始。需求整理、产品定义、边界收敛，其实都是 vibe coding 的一部分。

把判断写进文档，而不是留在对话里

想法聊清楚之后，下一步不是马上让 AI 大规模写代码，而是把判断写下来。开发过程中，我越来越确认：文档非常重要。这里说的文档，不是为了显得正式，也不是写给别人检查的流程材料。它更像是我和 AI 之间共享上下文的基础设施。这个判断也不是一开始就有的。

在这之前，我做过一个更小的项目。当时几乎没有写文档，主要依靠和 AI 一边对话、一边开发、一边补需求。早期进展很快，甚至会让人觉得只要先让 AI 把产品做出来，后面再慢慢调整即可。但到了中后期，前面没有想清楚的问题开始集中出现：需求边界不清楚，方案来回变化，局部修补越来越多。一个原本不算复杂的项目，最后用了远超预期的时间。

那次经历让我意识到，AI 可以很快完成很多表面工作，但如果前期判断和文档不足，后面剩下的那一小部分，反而可能消耗最多精力。更麻烦的是，有些问题不是改几个细节就能解决的，而是技术方案、产品边界或信息架构一开始就没有立住。

这次项目里，我把产品规格、业务规则、技术设计、UI 指南、开发计划、开发日志、发布说明、截图计划等内容都写成文档。它们看起来很多，但每一类文档都在解决同一个问题：当开发不是一天完成，而是经过多轮对话、多次修改、多个功能阶段之后，如何保证项目仍然沿着同一个方向前进？

后来我逐渐形成了一个习惯：每次形成关键判断，就把它写进对应文档；每次实现发生变化，就把变化同步回文档。不要假设下一轮对话里，AI 还会自然记得前面已经否定过什么。

人的记忆会模糊，AI 的上下文也会变化。如果一个判断只停留在对话里，很容易在后面的开发中被忘掉。比如不做空白时间分析、不做效率评分、不用 AI 替用户解释自己，这些都不是某个页面上的小细节，而是产品方向。它们必须被写进文档，后面做统计、分享图、App Store 文案和隐私说明时，才能持续对齐。

文档还有另一个作用：它会迫使我把判断说清楚。有时候我以为自己已经想明白了，但一旦要写成产品规则，就会发现仍有许多灰色地带。比如删除活动之后，历史记录怎么办？统计只看已完成记录还是包含进行中记录？分享图应该强调结果，还是保持中性表达？这些问题如果不写下来，开发时就会变成临时决定。临时决定多了，产品就会逐渐失去一致性。

后来加入繁体中文支持时，这一点体现得很具体：问题不只是把简体字转换成繁体字。哪些文案跟随 App 语言，哪些内容应该保持用户原始输入，日期、时间、数字格式和周起始日要不要被 App 语言覆盖，这些都需要提前写清楚。否则 AI 很容易把“本地化”理解成全面替换文字，但真实产品里有些内容不应该被语言设置改变。

把成熟规范变成 AI 可以使用的上下文

在 UI 和交互上，我最能感受到“要求说不清楚”的代价。如果只对 AI 说“让界面好用一点”“更像一个真正的 iOS App”，它很可能给出一个看起来完整、但并不符合平台习惯的方案。这类要求听起来有方向，其实没有标准：什么算好用，什么算像，全靠 AI 自己发挥，我也没有办法验收。

问题不在 AI 的能力，而在我没有给它参照系。而参照系很多时候不需要自己发明。人机交互就是典型的例子：这类知识并不容易掌握，哪怕有很多年经验，也需要在具体场景里反复思考；但 Apple 已经把它沉淀成一套成熟、公开、随每一代 iOS 和 macOS 更新的人机交互规范。对普通开发者来说，能稳定达到这套规范的水平，已经是非常不错的结果。

这也让我对文档的理解又宽了一层：值得沉淀成上下文的，不只是自己形成的判断，还有行业里现成的成熟方案。于是我用爬虫把 Apple 网站上的相关内容保存成 Markdown 文档，放进项目里，变成 AI 随时可以读取的参照。之后做 UI 和交互，我不再说“好用一点”，而是要求它按这套规范检查：当前控件是否符合平台习惯，交互反馈是否足够清楚，层级和导航是否合理，某个设计有没有违背 iOS 用户已经形成的预期。

变化在于，同一个诉求从“凭感觉调整”变成了“按标准逐条检查”。这不是把规范当成束缚，而是给 AI 一个更可靠的参照系：它知道往哪里对齐，我知道按什么验收，结果也更接近一个真实 iOS App 应有的体验。

这件事给我的启发是可以推广的：只要某个领域已经存在成熟标准，就可以把它整理成 AI 能读取的上下文，然后要求 AI 按这个标准设计、实现或检查。这比笼统地说“更专业一点”“更好用一点”有效得多。

真正拉开差距的是人的判断

当 AI 把写代码的门槛降下来以后，理论上，越来越多人都获得了某种“编程”的能力。只要能把想法表达出来，AI 就可以生成代码、页面、文档，甚至一个看起来完整的产品。过去，“能不能写出来”本身就是一道门槛；现在这道门槛降低了，真正重要的问题开始前移：到底应该做什么？不该做什么？什么功能只是看起来有用，实际会让产品变重？什么结果只是完整，什么结果才是真的正确？说到底，产品开发最重要的一件事没有变：满足用户需求。一个功能能不能被 AI 很快做出来，并不等于它真的解决了用户问题；一个方案看起来完整，也不等于它有足够的用户价值。vibe coding 可以改变实现路径，但不能替代对需求本身的判断。

也因为如此，vibe coding 带来的影响并不是平均的。那些原本有产品思维、有产品经验的人，可能会从中受益最大：过去他们知道应该做什么、用户需要什么、产品应该克制到什么程度，只是受限于开发能力，很难把想法真正落地，vibe coding 补上的正是这块短板。对已经会开发的人来说，它更多是提升开发效率和试错速度。而对完全没有产品和开发经验的人来说，它更像是突然得到一个强大的工具，却没有同时得到说明书：工具可以完成很多任务，但使用者仍然需要知道该用它做什么、什么时候停下来、怎样判断结果是否正确。能够区分“该做”和“不该做”，正是经验的价值。

我以前在 Smartisan 和小米工作过，参与过一些工具类产品。那段经验对我这次实践很重要。它让我更容易意识到：一个功能“能做”不等于“应该做”；一个方案“完整”不等于“适合现在”；一个界面“丰富”不等于“更好用”。具体到和 AI 协作，这种经验会出现在五类场景里：产品判断、业务判断、技术判断、工程协作习惯，以及视觉和表达判断。

第一类是产品判断。比如交互文档，AI 可以根据需求整理页面结构、用户流程和交互说明，但它生成的内容是否合理，仍然需要人来审查。入口放在哪里、提醒会不会制造压力、空状态会不会暗示用户做得不够好、某个操作是否打断了原本轻量的记录流程，这些都不是格式问题，而是产品判断问题。

第二类是业务判断。有些业务逻辑，只有真正做这件事、长期面对具体用户和具体流程的人，才会知道为什么必须这样设计。AI 往往会采用最常见、最通用的业务逻辑，生成一个看起来合理的默认方案，但真实产品里的流程差异经常就藏在这些默认方案之外。

之前做另一个垃圾分类识别项目 CanBin 时，就遇到过一个类似问题。最初的识别逻辑采用了一个“通用但不够业务真实”的分类模型：把垃圾分类结果直接归入 green、blue、black、special 四类。这个逻辑看起来合理，因为很多人直觉上会把垃圾分类理解成“绿桶、蓝桶、黑桶、特殊回收”。AI 也容易沿用这种最常见、最抽象的业务模型。

但实际业务里，真正权威的分类不是桶的颜色，而是当地政府发布的官方分类标准。不同城市、不同省份可能有不同的分类名称、回收项目、例外规则和投放方式。桶颜色只是 UI 上的辅助表达，用来帮助用户理解、显示图标颜色、决定是否展示地图入口，并不能作为最终分类依据。

这次调整暴露出的核心问题是：AI 很容易把“表面上常见的分类方式”当成业务真相。它能快速给出一个看似合理的实现，但如果没有业务人员指出“官方分类才是主分类，桶颜色只是辅助信息”，系统就会在关键业务逻辑上偏离真实场景。AI 可以很好地辅助实现、补全代码、优化 prompt，但它默认会倾向于采用通用业务逻辑。真正的业务约束、权威来源、地区差异和流程优先级，往往只有具体做这件事的人才清楚。AI 需要被明确告知这些规则，否则它会把“常见做法”误当成“正确做法”。

第三类是技术判断。开发过程中，我发现周视图里的柱状堆叠图突然不响应点击事件了。这个问题如果只描述成“点击没反应”，AI 当然也可以排查，但范围会很大。我当时的判断是，问题可能不在图表本身，而是之前对划动手势的修改影响了点击事件识别。把这个判断告诉 Codex 后，它就能沿着更接近根因的方向检查手势处理、事件优先级和命中区域，而不是在无关代码里大范围搜索。

第四类是工程协作习惯。以前工作中提交 bug 的格式，在 vibe coding 过程中变得非常实用。一个好的 bug 描述通常会写清楚四件事：前提，明确问题发生在哪个界面、什么条件下；操作，说明复现步骤；预期，描述每一步操作应该得到什么结果；现状，说明实际发生了什么。很多时候，只和 AI 说“这里有 bug”并不够。它需要知道问题发生的上下文、用户做了什么、系统应该怎样响应、现在又偏离在哪里。按照“前提、操作、预期、现状”去描述，问题就会清楚很多，AI 也更容易定位和修复。

后来我在向 Codex 描述问题时，也会自然沿用这个顺序：先写前提，再写操作，再写预期，最后写现状。问题越复杂，越不应该急着让 AI 猜，而应该先把问题描述成可以复现、可以验证的形式。

版本管理也是类似的经验。AI 可以很快修改代码，但如果没有相关经验，问题可能还不是“会不会用 Git”，而是根本不会意识到一个真实项目需要版本管理。你可能只是在和 AI 一轮一轮对话，让它不断修改文件，却没有意识到每一次重要改动都应该被记录，错误方向应该可以回退，不同阶段的改动应该有边界。

尤其是 AI 一次可以修改很多文件，在短时间内推进大量内容。如果没有版本管理意识，项目很快就会堆积出一组说不清来源的改动：不知道哪一次修改引入了问题，也不知道怎样回到一个正确状态。仅仅和 AI 对话，很可能不会自然意识到这些基础设施的重要性。AI 能帮助写代码，但你仍然需要知道一个项目应该怎样被管理。

第五类是视觉和表达判断。开发过程中有很多需要人来验收的时刻，一个典型例子是分享图。分享图看起来只是一个附属功能，但它其实很能体现产品气质。这个工具的统计分享图不能像成绩单，也不能像运动打卡海报。它应该展示用户记录下来的时间分布，但语气仍然保持中性、克制，不制造排名压力，也不暗示用户今天过得好或不好。

Codex 可以很快实现一个分享图页面，也可以根据已有统计数据生成 9:16 图片预览。但第一版能运行，不代表它就是对的。有些视觉方案会太像普通运营海报，有些信息层级会过重，有些标题不够具体，有些图表虽然技术上能够绘制出来，但和“安静地呈现事实”的方向并不一致。

这个时候，我的工作不是简单说“好”或“不好”，而是指出具体偏差：这里太像模板；这里信息密度太高；这里应该直接显示一天的时间线；时间刻度应该更明确；署名文案应该更像品牌表达，而不是功能说明。

AI 的价值在于，它可以根据这些反馈快速调整。但方向必须由我来收。这个过程让我更确认一件事：AI 可以执行，但人必须负责验收。尤其是视觉、文案、产品气质这类问题，很难只靠“代码能运行”来判断。能生成图片不代表它适合分享；布局完整不代表它符合产品；文案通顺不代表它表达正确。

后来我发现，给视觉反馈时也不能只说“不好看”，而要指出“不符合哪里”。比如“不像这个产品的气质”“信息密度太高”“像模板”“不够中性”“时间刻度不清楚”。反馈越具体，AI 越容易沿着正确方向收敛。在这种地方，过去的产品经验和审美判断会直接影响 AI 协作的结果。

一个人像一支小团队

有了想法整理、文档、规范和经验判断之后，AI 的价值才真正展开。我在这个项目里给自己的角色，更接近“产品经理 + 项目负责人”。我负责决定产品要成为什么、不成为什么；负责判断一个设计是否符合这个工具的气质；负责在功能、复杂度和体验之间做取舍；也负责最后验收 AI 给出的结果。

剩下的执行工作，几乎都由 AI 承担。

这也是我为什么觉得 vibe coding 不是“AI 替代人写代码”这么简单。它更像是临时组织起一支小团队。这个团队里有人写工程代码，有人整理文档，有人检查遗漏，有人把一个功能拆成可执行步骤。但这支团队需要有人管理，需要有人设定方向，也需要有人判断最终交付是否正确。

当我需要想清楚产品边界时，AI 可以帮我把问题列出来。当我需要把边界固定下来时，它可以帮我整理成规格。当我需要实现功能时，它可以读代码、改代码、跑检查。当我需要同步文档时，它可以把已经确定的实现写回开发日志和技术设计。当我准备发布时，它又可以帮我检查命名、隐私、Internal scheme 和 App Store 材料。

后来做 Live Activity 和灵动岛提醒时，这种感觉特别明显。它不是“加一个灵动岛界面”这么简单，而是要同时考虑当前记录状态、Widget Extension、启动恢复、误触风险，以及是否需要停止按钮、是否显示统计数据、是否引入远程 push。除此之外，这些决定还要同步写回文档。Codex 可以分别处理这些问题，但我要决定哪些要做，哪些不要做。

这让我感觉一个人不再只是独自写代码，而是在管理一支很小的协作团队。当然，这支团队不会自动运转。AI 不会天然知道这个工具应该克制，也不会天然知道我不希望它变成复杂效率系统。它能完成很多工作，但前提是我不断提供上下文、明确标准、指出偏差，并且在每个阶段验收。

最后还是要把事情说清楚

做完这个 App 后，我对 AI 编程是务实乐观的。我不认为它只是一个玩具，也不认为它已经可以替代开发者。它真正改变的，是一个人能够承担的工作范围，以及把想法推进成真实产品的速度。开发这段时间里，我几乎每天都会把 5 小时使用限额用完；等待限额恢复时，会有一种明显的中断感，甚至会算好时间，限额一恢复就继续推进。它带来的反馈循环太快了：提出想法、看到实现、发现问题、继续调整，整个过程不断给人新的推进感。

以前一个人做独立产品，很容易卡在某个角色上。产品想清楚了，工程推进慢；工程写出来了，文档没跟上；功能做了，发布材料还没准备；视觉想调整，但来回改成本很高。AI 不能消除所有困难，但它确实让这些环节之间的距离变短了。

我不想把它包装成一种神奇方法。它不是不用思考，也不是不用学习，更不是让人随便生成一堆东西然后交差。如果说 AI 改变了什么，我觉得它改变的不只是写代码的速度，而是让“把事情说清楚”变得更重要了：把目标说清楚，把边界说清楚，把判断写进文档，把反馈说具体，把验收标准讲明白。传统开发里，这些能力本来就重要；到了 AI 协作里，它们没有消失，反而变成了更核心的能力。因为 AI 可以很快执行，但它需要知道该往哪里执行，什么算对，什么算偏。

所以对我来说，vibe coding 不是一种偷懒方式，而是一种新的协作方式：AI 让执行变快，人负责方向、标准和最终验收。它的核心不是让 AI 替我思考，而是让我把一个模糊想法推进成真实产品。

这个项目对我来说就是这样一次实践。它最初只是一个关于记录生活时间的模糊想法。通过和 Codex 一轮一轮对话、判断、记录、实现、验证，它慢慢变成了一个可以运行、可以继续打磨、也可以准备发布的 App。

如果你也对 Codex、vibe coding 或独立开发感兴趣，欢迎来和我交流。