从 0 行代码到 App Store：非技术项目经理用 Claude Code 六周发布压力管理应用

1. 引言：AI 编程工具正在改变“谁能做产品”

2026 年 5 月，Anthropic 官方博客发布了一篇很有代表性的案例：How a non-technical project manager built and shipped a stress management app with Claude Code in six weeks。故事主角是来自乌克兰基辅的项目经理 Kostiantyn Vlasenko。他在 Mythical Games 拥有约十年项目管理经验，但在开始这个项目之前，几乎没有正式编程背景，甚至可以说“从未写过一行代码”。

但他最终完成了一件过去通常需要一个小型工程团队才能完成的事情：

• 构思一款压力管理应用 Respiro；
• 用 Claude Code 快速做出可运行原型；
• 将最初的 React Native MVP 重写为 Swift iOS 应用；
• 集成 Sentry、Amplitude 等工程化与数据分析能力；
• 在 Apple App Store 上线，并获得数百名真实用户。

这不是一个“AI 替代工程师”的简单故事，更像是一个“非技术产品负责人如何用 AI Agent 组织一支虚拟研发团队”的实践样本。Vlasenko 成功的关键不在于他突然掌握了所有底层技术，而在于他把项目管理能力迁移到了 Claude Code 工作流中：拆解目标、补充上下文、分派任务、审查结果、持续迭代。

说明：原文未提供可复用的截图 URL，App Store 页面也未能稳定抓取到目标应用截图。本文中的配图为基于公开信息整理的技术示意图，用于辅助理解，不冒充官方真实截图。

2. 产品构思：压力管理不应只依赖固定时间提醒

Respiro 的出发点来自一个非常具体的生活痛点：很多压力管理、冥想、呼吸训练类 App 只会在用户设定的固定时间提醒，比如晚上十点弹出“该做一次深呼吸了”。这种方式的问题在于，压力并不总是按时出现。

Vlasenko 自己长期面对项目交付、利益相关方沟通、会议和发布节奏带来的压力，也一直使用呼吸训练、正念等方式管理状态。他发现真正有价值的干预时机不是“预设时间”，而是“压力正在上升的当下”。

原文开头给了一个很好的例子：在采访开始前十五分钟，Vlasenko 正处于紧张准备状态，自己甚至没有完全意识到焦虑，但 Respiro 检测到了他的压力信号，并提醒他可以做一次短暂的方块呼吸练习。提醒语大意是：

你可以去做一次简短的 box breathing，之前方块呼吸曾经帮助你减压。

这句话里其实包含了 Respiro 的三个核心产品判断：

1. 实时性：不要只按固定时间提醒，而要捕捉用户真正需要帮助的时刻；
2. 个性化：不是推荐所有人都一样的练习，而是基于用户过去有效的方式；
3. 低摩擦：压力上升时，用户不需要打开复杂页面，只需要接受一次短时引导。

从产品设计角度看，这比“做一个呼吸练习计时器”复杂得多。它需要感知、判断、提醒、引导和反馈闭环，也需要在“不打扰”和“及时帮助”之间找到平衡。

3. 六周路线图：从 Hackathon 原型到 App Store 上线

根据原文信息，Vlasenko 的项目大致经历了五个阶段。

这里最值得注意的是，Vlasenko 一开始并没有写出严谨的技术需求文档。原文提到，他最初给 Claude 的提示非常朴素，接近于：

Hey Claude, just give me an application that will make me less stressed.

这句话在传统软件开发中几乎不能算需求，但它足够触发一个原型。Claude Code 生成的首版应用能在手机上跑起来，让 Vlasenko 看到“这个想法真的可以落地”。之后，他才逐步把模糊想法拆成可执行的工程任务。

这也反映出 AI 辅助开发的一个重要变化：早期产品探索的成本被显著降低了。过去你可能要先找开发者、写需求、搭环境、做 UI、跑真机；现在一个非技术人员也可以先拿到一个会动的版本，再围绕真实反馈收敛需求。

4. 技术选型：先 React Native 快速验证，再 Swift 原生落地

原文披露的技术路线非常有代表性：

1. 最初使用 React Native 做 MVP；
2. 由于没有 Android 手机，不方便做跨平台测试；
3. 借助 Claude Code 将应用从零重写为 Swift；
4. 最终作为 iOS 应用提交 Apple App Store。

这条路径看似“绕路”，但在 AI 辅助开发场景下反而合理。

4.1 React Native 适合快速验证

React Native 的优势是跨平台、生态成熟、原型速度快。对于 Hackathon 场景，先用它验证交互和产品假设很自然。Vlasenko 需要的不是一开始就构建最完美的架构，而是确认：

• 用户是否需要实时压力提醒；
• 呼吸练习是否能形成闭环；
• 手机端体验是否成立；
• Claude Code 是否能持续帮助他推进开发。

4.2 Swift 更适合 iOS 深度集成与发布

当产品目标收敛到 iOS，并且需要研究 Apple APIs、发布到 App Store 时，Swift 原生实现更适合。原因包括：

• 更直接地调用 Apple 生态能力；
• 更容易与 Apple Developer、App Store 审核流程对齐；
• 真机调试和权限处理更清晰；
• 后续集成通知、传感器、健康相关数据、图形或动画能力时更自然。

原文没有披露具体使用了哪些 Apple APIs，因此不能武断地写成“使用了某某 API”。更严谨的说法是：Claude 帮助 Vlasenko 研究了哪些 Apple APIs 可以为压力检测逻辑提供设备信号，并指导他完成相应实现。

4.3 AI 让“技术路线切换”的成本下降

传统团队中，从 React Native 重写为 Swift 是一个不小的决策，可能涉及人员技能、排期、测试和风险评估。但 Vlasenko 借助 Claude Code 在数小时内完成重写，这说明 AI 编程工具正在改变技术选型的成本结构：

• 原型阶段可以更大胆地选择“最快验证”的方案；
• 产品方向清晰后，再迁移到更合适的技术栈；
• 非技术负责人也可以通过 AI 解释和执行重构计划。

5. 开发组织方式：把 Claude Code 当作一支虚拟工程团队

这篇案例最有价值的部分，不是“Claude 会写代码”，而是 Vlasenko 如何使用 Claude Code。他不是把 Claude 当成一个单次问答工具，而是像管理真实团队成员一样管理 IDE 中的 agents。

原文提到，他让 Claude 帮助设计并构建了一套包含 15+ 个专业 subagents 的开发体系，其中明确提到的角色包括：

• TCA architect agent：负责架构设计，TCA 很可能指 The Composable Architecture；
• Swift developer agent：负责 Swift 代码实现；
• Metal specialist：负责 Apple Metal 相关底层或图形/性能问题；
• Code reviewer：负责代码审查和质量把关。

这套模式本质上是把传统项目管理流程映射到 AI Agent 协作流程：

产品目标
  ↓
需求拆解
  ↓
分派给专业 Agent
  ↓
代码生成与修改
  ↓
人工验收与反馈
  ↓
继续迭代

Vlasenko 虽然不会从零手写复杂 iOS 代码，但他擅长项目管理：定义目标、拆任务、管理上下文、推动交付、审查结果。这些能力在 AI 辅助开发中反而被放大了。

一个更工程化的提示词模板可以这样设计：

你是 Respiro 项目的 Swift Developer Agent。

背景：
- Respiro 是一款 iOS 压力管理应用。
- 当前目标是在检测到压力上升后，引导用户完成一次方块呼吸练习。
- 项目使用 Swift，并按功能模块组织代码。

任务：
1. 实现 BreathingSession 状态模型。
2. 支持 inhale / hold / exhale / hold 四个阶段。
3. 每个阶段默认 4 秒，可配置。
4. 结束后返回练习完成事件，供分析系统记录。

约束：
- 不要改动无关模块。
- 先给出实现计划，再修改代码。
- 完成后说明需要人工验证的交互路径。

验收标准：
- 启动练习后可以按阶段推进。
- 用户可以中途取消。
- 完成后能触发 session_completed 事件。

对非技术人员来说，关键不是一开始就懂所有代码细节，而是要学会给 AI 足够的上下文和可验收目标。

6. 关键技术链路：从设备信号到个性化干预

Respiro 的核心体验可以抽象为一条闭环链路：采集信号、判断压力、触发提醒、完成练习、记录反馈、优化下一次推荐。

需要强调的是，原文没有披露压力检测算法和具体 Apple API 名称。下面的代码是基于公开描述抽象出的工程示意，目的是解释这类应用可能如何组织核心逻辑，而不是声称 Respiro 内部真实代码就是这样。

6.1 信号模型：把复杂设备输入统一成可判断的特征

struct StressSignal {
    let timestamp: Date
    let source: SignalSource
    let value: Double
    let confidence: Double
}

enum SignalSource {
    case motion
    case usagePattern
    case calendarContext
    case userFeedback
}

struct StressWindow {
    let startedAt: Date
    let endedAt: Date
    let signals: [StressSignal]

    var weightedScore: Double {
        let totalWeight = signals.reduce(0) { $0 + $1.confidence }
        guard totalWeight > 0 else { return 0 }
        return signals.reduce(0) { $0 + $1.value * $1.confidence } / totalWeight
    }
}

这个模型的重点不是某个具体算法，而是把不同来源的信号统一成 StressSignal，再按时间窗口聚合。这样后续压力判断逻辑就不需要关心信号来自运动、使用习惯还是用户反馈。

6.2 干预策略：避免“有压力就打扰”

真正的产品难点在于，压力检测不是越敏感越好。如果提醒太频繁，用户会关闭通知；如果提醒太迟，应用又失去了价值。因此干预策略至少要考虑：

• 压力分数是否超过阈值；
• 最近是否已经提醒过；
• 当前场景是否适合打扰；
• 用户过去对哪类练习反馈更好；
• 用户是否正在形成长期使用习惯。

示意代码如下：

struct InterventionPolicy {
    let stressThreshold: Double
    let minimumInterval: TimeInterval

    func shouldIntervene(
        currentWindow: StressWindow,
        lastInterventionAt: Date?,
        now: Date
    ) -> Bool {
        guard currentWindow.weightedScore >= stressThreshold else {
            return false
        }

        if let lastInterventionAt,
           now.timeIntervalSince(lastInterventionAt) < minimumInterval {
            return false
        }

        return true
    }
}

这类策略可以先从简单规则开始，再结合用户反馈逐步调优。对于早期产品来说，能解释、可调整、容易验证，往往比一开始追求复杂模型更重要。

6.3 个性化推荐：优先选择曾经有效的练习

原文中 Respiro 的提醒会提到“方块呼吸之前帮助你减压过”。这意味着应用需要记录练习效果，并将其用于下一次推荐。

struct ExerciseEffectiveness {
    let exercise: BreathingExercise
    let completedCount: Int
    let positiveFeedbackCount: Int

    var score: Double {
        guard completedCount > 0 else { return 0 }
        return Double(positiveFeedbackCount) / Double(completedCount)
    }
}

enum BreathingExercise: String {
    case boxBreathing
    case deepBreathing
    case mindfulPause
}

func recommendExercise(from history: [ExerciseEffectiveness]) -> BreathingExercise {
    history
        .sorted { $0.score > $1.score }
        .first?
        .exercise ?? .boxBreathing
}

这里的核心思路是“先做有效的小闭环”：记录用户是否完成、完成后是否觉得有帮助，再用这个反馈影响下一次推荐。它不一定需要复杂机器学习，也可以先用透明的规则系统支撑 MVP。

7. 呼吸练习模块：把体验拆成可测试的状态机

压力管理应用看起来是“内容型产品”，但好的呼吸训练体验背后往往是一个状态机。以方块呼吸为例，它通常包含四个阶段：吸气、屏息、呼气、屏息。每个阶段持续固定或可配置的秒数。

如果用 TCA 一类架构思想来组织，可以把状态、动作和副作用拆开。下面仍然是示意代码：

enum BreathingPhase: String {
    case inhale
    case holdAfterInhale
    case exhale
    case holdAfterExhale
}

struct BreathingSessionState {
    var phase: BreathingPhase = .inhale
    var secondsRemaining: Int = 4
    var completedCycles: Int = 0
    var targetCycles: Int = 4
    var isRunning: Bool = false
}

enum BreathingSessionAction {
    case start
    case tick
    case pause
    case cancel
    case complete
}

状态机的好处是便于拆任务：

• TCA architect agent 可以先设计状态流转；
• Swift developer agent 实现视图和计时逻辑；
• Code reviewer 检查边界条件，例如中途取消、后台切换、重复启动；
• 产品负责人只需要围绕用户路径验收：开始、暂停、完成、反馈是否顺畅。

这也是非技术人员与 AI 协作的一个技巧：不要只说“做一个好看的呼吸页面”，而要把体验拆成状态、动作和验收路径。

8. 工程化：监控、分析和发布不是上线前才补的事情

很多 Hackathon 项目止步于 Demo，但 Respiro 的目标是 App Store 上线，因此必须补齐工程化能力。原文提到 Claude 协助 Vlasenko 集成了：

• Sentry：日志与错误监控；
• Amplitude：产品分析；
• 用户漏斗；
• 留存指标；
• 日活跃用户、月活跃用户追踪；
• 复杂后台配置，例如 Meta API token。

这些工作对非技术人员通常很难，因为它不只是“写代码”，还包括后台注册、权限配置、API Key、SDK 初始化、事件命名、隐私合规、发布环境区分等一系列细节。

一个压力管理应用的分析事件可以这样设计：

相应的漏斗可以是：

压力信号检测
  → 展示干预提醒
  → 用户点击开始练习
  → 完成呼吸训练
  → 提交效果反馈
  → 下一次推荐更准确

对早期产品来说，分析体系不一定要复杂，但必须回答几个基础问题：

1. 用户是否真的在压力时刻打开了应用？
2. 提醒是否被点击？
3. 呼吸练习是否完成？
4. 用户是否觉得有帮助？
5. 哪类练习更容易形成留存？

这也是 Claude 的价值所在：它不只帮你写功能，还能帮你把产品验证指标一起搭起来。

9. Claude Vision：把“看不懂后台”变成可操作步骤

原文中特别提到，Vlasenko 认为 Claude 的视觉能力被低估了。他的使用方式很朴素：当自己卡在 Apple Developer Program、第三方服务控制台、Meta API token 创建等复杂页面时，就把截图发给 Claude，问它“我应该点哪里”。

这个能力对非技术人员很关键，因为产品上线过程中大量阻碍并不来自代码，而来自陌生后台：

• Apple Developer Program 的证书、标识符和发布配置；
• App Store Connect 的应用信息、隐私说明和提交流程；
• Sentry、Amplitude 的项目、环境、SDK 配置；
• Meta 等平台的 API token 创建与权限选择。

如果没有 Claude Vision，非技术人员遇到这些页面时很容易陷入“我不知道这个按钮是什么意思”的状态。有了截图理解能力，Claude 可以把复杂 UI 转译成一步步操作说明。

一种有效的提问方式是：

我正在配置 Apple Developer Program，截图如上。
目标：为 Respiro 创建 iOS App 发布所需配置。
我不确定下一步应该点击哪里。
请你：
1. 识别当前页面处于哪个流程；
2. 告诉我下一步点击哪个按钮；
3. 说明每个字段应该填写什么；
4. 标出可能导致审核失败或配置错误的风险点。

这种“截图 + 目标 + 风险点”的组合，能让 AI 从单纯解释页面升级为发布流程助手。

10. 上线之后：增长、内容和真实用户反馈

构建产品只是开始。Vlasenko 后来意识到，如果能回到过去，他会更早认识到：产品构建相对容易，传达产品价值更难。

这句话很重要。AI 工具降低了开发门槛，但没有自动解决定位、传播、信任和增长问题。Respiro 的营销同样借助 Claude 完成，包括：

• 撰写博客文章；
• 制作 TikTok 内容；
• 制定增长策略；
• 设计用户漏斗和留存指标；
• 寻找心理学家、正念练习从业者合作，让他们向客户推荐应用。

其中“联系心理学家和正念练习从业者”是 Claude 提出的策略之一。Vlasenko 执行后发现确实有效，有从业者开始推荐 Respiro。

从这个角度看，Claude Code 并不是孤立的编码工具，而是完整创业工作流中的一环：

同时，产品上线后还需要围绕内容传播、专家推荐、数据分析和真实用户反馈持续迭代：

11. 对本职工作的反哺：项目经理开始直接交付代码

原文还提到，构建 Respiro 的经历反过来改变了 Vlasenko 在 Mythical Games 的工作方式。他现在能够直接提交代码发布，也会把自己在 Respiro 中形成的 Claude 工作流分享给工程团队。

这背后有一个很有意思的现象：一些资深工程师反而不容易接受“不完全控制每一行代码”的工作方式，而 Vlasenko 因为没有深厚编程背景，反而更自然地把 Claude agents 当作协作对象。他不执着于每一行代码都由自己亲手写出，而是关注目标是否达成、结果是否可验收、产品是否能上线。

这并不意味着工程能力不重要。相反，随着 AI 生成代码越来越多，下面这些能力会变得更重要：

• 能否定义清晰的成功标准；
• 能否识别不合理的实现或风险；
• 能否建立测试与监控闭环；
• 能否让 AI 在正确的上下文中工作；
• 能否把功能开发、发布、运营串成完整系统。

非技术人员可以借助 AI 进入产品开发，但要做出可靠产品，仍然需要学习基本的软件工程常识和质量意识。

12. 非技术人员使用 Claude Code 的实践清单

结合这个案例，可以总结出一份可复用的实践清单。

12.1 从可运行原型开始，而不是从完美架构开始

先让 Claude Code 帮你做一个能跑的版本，哪怕技术栈不是最终形态。原型的目标是验证“这个产品是否值得继续做”。

12.2 把模糊需求改写成可验收任务

不要一直停留在“帮我做一个压力管理 App”。可以逐步改成：

当用户完成一次方块呼吸后，记录完成事件，并展示一个简单反馈弹窗。
验收标准：
- 点击完成按钮后弹窗出现；
- 用户可以选择有帮助或无帮助；
- 选择结果写入本地历史记录；
- 不影响下一次练习启动。

12.3 给 Agent 明确角色

同一个 Claude 会话既做架构、又写 UI、又做审查，容易上下文混乱。可以像 Vlasenko 一样拆成多个角色：

12.4 不懂后台就截图问 Claude

配置类问题不要只复制错误文案。截图、当前目标、卡住点一起给 Claude，效果通常更好。

12.5 早接入监控和分析

即使是早期产品，也应该尽早知道：哪里崩了、用户走到哪一步、哪些功能真的被使用。否则上线只是“发布了一个 App”，不是“开始了一个可学习的产品系统”。

12.6 接受重构，但保留人工验收

AI 让从 React Native 到 Swift 这类重写变得更容易，但不意味着可以跳过验收。每次大改后都要验证核心路径：启动、权限、提醒、练习、反馈、分析事件、崩溃监控。

13. 总结：AI 降低门槛，但没有降低对目标感的要求

Respiro 的故事说明，AI 编程工具正在把产品开发能力从“会写代码的人”扩展到“能清晰定义问题并组织交付的人”。一个非技术项目经理能在六周内发布压力管理应用，不是因为软件工程突然变得不重要，而是因为 Claude Code 把大量编码、查文档、重构、后台配置、发布排障的工作变成了可对话、可迭代、可委派的任务。

这类工作流给我们的启发是：

• 非技术人员可以用 AI 快速跨过“从 0 到 1”的门槛；
• 项目管理、产品判断和上下文组织能力会变得更有价值；
• 多 Agent 协作会成为 AI 编程的重要模式；
• 快速构建只是第一步，价值表达、真实反馈和持续运营同样关键；
• AI 可以帮你写代码，但不能替你决定产品为什么存在。

如果说过去的创业起点是“找一个技术合伙人”，那么今天越来越多人的起点可能是：打开 Claude Code，先把想法变成第一个能运行的版本。

参考资料

• How a non-technical project manager built and shipped a stress management app with Claude Code in six weeks
• Respiro: Stress Relief on the App Store
• Claude Vision documentation
• Claude Code blog category

× 爱折腾的工程师

真诚赞赏，手留余香

2元 5元 10元 50元 100元 任意金额

2元

使用微信扫描二维码完成支付

• ← Previous Post
• Next Post →