这篇仍然是同事（这次是产品经理）整理的分享材料，给有兴趣实验、实践的朋友们提供些参考。
还是一样，走过路过不要错过，下载个 Slax Note 试试看。我用它来做灵感记录（想到什么，拿起手机说几句话，迅速就能转成可用的素材）、每日复盘（晚上拿着手机散步，边走边说，记录一些事，有些就能成为写作素材）。
支持 iOS、安卓和网页版，具体可以看 https://slax.com/note
这份总结基于多个群聊、方案预研文档、3 月 18 日会议记录，以及 3 月中旬到 4 月中旬多篇日报整理而成。
目标不是做技术流水账，而是回答两个问题：
1. 从 2026-03-10 之后，我用 AI coding 重写 Slax Note 的心路历程是什么？
2. 这次实验里，哪些经验值得以后复用，哪些坑必须提前规避？
一、先说结论
这次 AI coding 重写 Slax Note，不是一次“AI 自动写完 App”的轻松胜利，而是一段从 兴奋、怀疑、受挫、调整方法，到重新建立信心 的过程。
如果用一句话概括：
AI 确实把开发门槛打下来了，但真正决定效率的，不是“会不会用 AI”，而是“会不会定义问题、约束上下文、管理质量、建立协作机制”。
这次重写最大的价值，不只是做出了一个 iOS 新版本，而是验证了几件事：
•产品/设计师确实可以借助 AI 深度参与甚至主导实现，不再只是提需求和验收
•AI 很适合高速搭框架、补界面、做中小型修复和批量试错
•一旦进入真实业务链路、真机环境、复杂同步和多端协作，AI 就不会自动帮你收口，反而会暴露出对规格、上下文、验证、代码 review 的更高要求
•后期真正拉开差距的不是“写代码”，而是“发现根因、控制回归、沉淀方法”
所以，这次实验的本质不是“AI 替代研发”，而是：
把原本隐性的研发能力，拆成可以由人 + AI 协作完成的一套流程。
二、为什么会开始这次重写
如果把时间线拉早一点，这件事的起点不是 3 月中下旬，而是 3 月 10 日左右就已经明确浮出水面。
当时团队讨论得已经很直接：想拿 Slax Note 来做一次更激进的 AI coding 试验，甚至有“把 Slax Note 的代码全部删掉，由更小团队借助 AI 重做和维护”的设想。这个起点本身就说明，当时大家讨论的已经不是“用 AI 提高一点效率”，而是在试探一种新的产品开发方式。
从 3 月中旬开始，团队逐渐不再把 AI 看成单点提效工具，而是开始认真讨论一种更激进的开发方式：
•产品确定需求
•不再层层中转给研发实现
•而是由产品/设计师直接借助 AI 生成代码、调试、验收
•甚至后续 review、修 bug 也尽量借助 AI 完成
当时我们对 AI native 开发方式 存疑 ：
1.它能不能能减少任务在多人之间反复流转造成的损耗
2.这次重写本身就是实验：不仅要验证能不能做出来，还要验证能不能形成未来可复用的方法论
但这里有一个很关键的前提，必须单独说清楚：
这次重写不是“直接把需求丢给 AI 让它从零乱写”，而是一次 spec 驱动的 AI coding。
在正式重写前，研发工程师玉洁先基于已有代码仓库，把原有产品里的关键结构、能力边界、页面逻辑、接口契约、模块关系等内容，提炼成了一组可供 AI 消费的 spec 文件。后续的开发，不是让 AI 自由发挥，而是让它围绕这些 spec 分步执行。
这一点非常关键，因为它解释了这次实验为什么不是碰运气：
•AI 不是凭空生成，而是在消费工程化过的上下文
•产品/设计师不是直接面对一整个复杂仓库，而是在面对一组结构化任务说明
•后续遇到问题时，也不是回到“纯口头描述”，而是可以回到 spec 和文档继续修正
换句话说，这次实验真正验证的，不是“有了 AI 就不需要研发”，而是：
研发可以先把自己的经验、架构理解和系统知识沉淀成 spec，再让更多人借助 AI 进入实现层。
三、这次重写为什么能推进：关键协作支撑
如果只看表面，很容易把这次过程理解成“产品 + 设计师 + AI 把 App 重写出来了”。
但更准确的说法应该是：
这次重写的推进，是建立在研发同事、后端同事和 AI 协作的多方支撑之上的。
1）研发工程师先把复杂系统抽成 spec
这是最核心的一步。
玉洁先根据既有代码仓库，把原本散落在代码里的产品结构、模块关系、页面逻辑、接口信息和实现约束，提炼成了十几个 spec 文件。这样后续的 AI coding 才不是“盲写”，而是变成一种 按 spec 分步执行 的过程。
这一步的价值在于：
•降低 AI 幻觉和乱改的概率
•降低非研发角色直接面对复杂工程的门槛
•让开发过程从“凭 prompt 试错”变成“围绕规格执行”
2）研发同事把隐性的工程经验，转成文档化规则
除了 spec，本次推进里还有很多关键经验并不是写在需求文档里的，而是玉洁、姚坤等人在实践中不断补上的，例如：
•某些 UI/交互在当前技术栈下的实现边界
•哪些能力适合先简化实现，哪些地方不能硬刚
•某些接口字段、命名方式、状态处理的真实约束
•哪类问题应该优先查根因，哪类问题可以先跳过
这些内容一旦被写进文档，AI 的稳定性和团队协作效率就会明显提高。
3）后端同事姚坤的配合，不只是后期接口支持，而是贯穿全程
除了前端/客户端侧的 spec 提炼、实现推进和问题排查，这次重写能持续推进，还有一个非常关键的支撑力量：后端同事姚坤的密集配合。
如果把时间线往前拉，他的支持并不是后期才出现，而是从早期就已经参与到能力打磨里了。
早期：参与 prompt、热词提取和多语言支持
在 3 月 10 日当天，姚坤就已经在：
•调整提取专用词的 Prompt
•优化对葡萄牙语和英文的支持
•和我们讨论热词提取、处理速度、可接受性等问题
这说明他一开始参与的，不只是后端接口，而是 产品能力本身的 AI 表达和效果优化。
中期：持续补接口、迁移接口、补充 API 文档
随着重写进入真实链路，他的支持逐渐扩展到：
•迁移和补充一些接口
•持续补齐 API 文档
•帮助大家理解真实的服务端约束
这点很重要，因为 AI coding 要想进入真实业务，不可能只靠前端自己猜接口。很多时候，接口可用性、字段定义、返回格式、鉴权方式和真实行为，必须依赖后端同事同步澄清和修正。
后期：把 API 文档 / Apifox / MCP 一起接进 AI 工作流
到后面，姚坤的支持已经不只是“答疑”了，还进一步演化成：
•让大家对照 Apifox 文档让 AI 分析问题
•提醒先刷新文档缓存，再按接口规约排查
•提供 Apifox MCP 的配置方式
•直接指出参数问题、重复请求、请求体异常等具体问题
这说明一件事：
这次重写的顺利推进，不只是“AI 在写代码”，而是人类同事在不断给 AI 提供正确的边界、上下文、规约和反馈。
4）这次实验的成功，本质上也是一次跨角色协作成功
如果回头看，这次重写之所以能真正跑起来，不是因为某一个角色单独变强了，而是因为：
•研发工程师把已有仓库经验提炼成 spec
•产品 / 设计师借助 AI 推动实现和验证
•后端同事持续补接口、补文档、补交互细节、补定位能力
•大家一起把问题从“AI 会不会写”推进到“产品能不能真的跑通”
所以更准确的说法是：
这次重写不是单纯的“AI 提效案例”，而是一次“spec 驱动 + 文档驱动 + 前后端密切配合 + 人机协作”的综合实践。
四、心路历程：这一个多月里，我怎么一步步走过来的
1）启动期：新鲜、兴奋，但也带着明显的不确定感
3 月 10 日到 3 月 18 日这段时间，整体情绪是兴奋的，但不是笃定的。
一方面，团队一边做准备工作，一边统一认知：
•设计师开始安装和学习 Claude Code
•大家讨论 AI 重写到底要做到什么程度
•也在讨论原生、跨平台、云端环境、本地环境这些路径选择
另一方面，我（玉珍）自己对这件事的第一反应其实也很真实：
•“变天了家人们”
•“我连版本控制都不会，你让我来维护一个产品”
•“就离谱”
这些话很能说明当时的状态：
不是一开始就确信这条路一定能成，而是既兴奋又震惊，既想试又觉得这事太激进。
这个阶段最重要的变化，不是代码本身，而是心态上的切换：
原本“实现”是研发的地盘，但 AI 让“实现”第一次对产品和设计师开放了。
3 月 18 日，第一版基于文档跑出来的 demo 已经有了轮廓。那时的感觉更接近：
•这条路不是幻想
•AI 不是只能写玩具 demo
•只要文档、上下文、目标说清楚，它确实能把一个产品界面和主流程快速搭出来
但也正是在这里，后面的难点其实已经埋下了：
AI 最擅长的是“把东西做出来”，但不等于“把东西做对、做稳、做成产品”。
2）推进期：从“围观 AI 写代码”进入“真实开发现场”
到 3 月 20 日到 3 月 23 日，状态明显变了。
前几天更多是“它能不能做”，这几天开始变成“它做出来的东西到底能不能用”。
这时候我和团队碰到的，不再是抽象问题，而是很具体、很磨人的现实：
•UI 细节改不准
•模拟器看起来没问题，真机就出问题
•接后端接口后，性能、交互、状态管理问题一口气冒出来
•一个地方修好了，另一个地方又坏掉
•AI 明明说已经改好了，但效果和预期还是差很远
我在 3 月 23 日那篇反思里其实已经把核心痛点说得很透了。
第一层受挫：问题开始连锁反应。表面看是一个交互细节，背后却可能牵连手势冲突、页面性能、导航方式、ScrollView / List 取舍。AI 不是不会改，而是它经常会给出一个“能交差但不够对”的局部解。
第二层受挫：自己不懂底层，就无法点拨 AI。这次过程里一个非常关键的心理转折是：我开始意识到，最大的问题不是 AI 不努力，而是当自己不理解 iOS 机制时，AI 给出的方案到底是最优解、次优解，还是临时糊上去的解，自己没有判断力。
第三层认知升级：有些需求不能硬刚。进入 AI coding 现场后，我开始真正理解研发常说的“要调整实现方式”是什么意思：有些需求在产品上看合理，在当前技术路径上却极不经济；有些细节继续死磕，只会陷入低效循环。
3）调整期：开始形成自己的方法，不再盲目硬扛
到了 3 月下旬，我们的状态开始从“被问题推着走”，慢慢变成“我知道该怎么和 AI 协作”。
几个关键转折非常明显：
转折一：开始接受“不是所有问题都该当场解决”。改了很多次还不对的，先跳过；先保主流程，先保可演示，先保真机可跑。因为 AI coding 最大的风险之一就是：
你会被“它好像马上就能改好”的错觉拖进无穷微调。
转折二：开始把经验写进文档，而不是只留在对话里。光靠聊天上下文不够，光靠临场描述也不够，要把约束写成文档，AI 才能越来越稳定。
不是每次重新教 AI，而是把规则沉淀成资产。
转折三：开始理解“工具熟练度”也是生产力。很多问题其实不是代码本身，而是切错文件夹、Xcode 编译旧文件、英文报错看不懂、上下文过长不敢切窗口。这类问题说明：
AI coding 的门槛，不只是“会不会提需求”，还包括“会不会使用整套开发环境”。
4）收敛期：从“能跑”走向“能用”，从个人试验走向团队协作
4 月初到 4 月 10 日，是另一个明显转折。
这时项目已经不再是 demo 阶段，而是在往真实交付推进：
•现场演示
•真机测试
•TestFlight
•团队试用
•多人反馈
这个阶段最大的变化是：
问题的重心从“页面没做完”，切到了“真实使用下的问题暴露”。
几个变化尤其明显：
变化一：Bug 数量突然激增。一旦推到更多同事手里，问题就会集中爆发。你在 4 月 10 日已经非常敏锐地意识到：
必须把 Bug 管理从“文档记录”升级为“结构化台账”。
于是 Bug Tracker 从长文档迁移到多维表格，项目管理方式开始真正升级。
变化二：开始区分“可演示”和“可发布”。前期 demo 看起来已经有 80% 功能，甚至可以现场演示；但到真正要发 TF、上架、给更多人使用时，暴露的问题完全是另一个量级。
AI 很容易帮你冲到“看起来能用”的阶段，但距离“稳定上线”还隔着完整的工程质量关。
变化三：团队协作方式也在升级。不再只是“让 AI 改一下”，而是开始进入 PR、Review、Code Review、自动部署、修复闭环。我也明确提出：使用 CC 编码、用 Codex review 代码。
真正可扩展的 AI coding，不是“靠一个模型从头写到尾”，而是让不同 AI 在不同环节分工协作。
5）冲刺期：最难的不是开发，而是系统性问题的根因定位
4 月 13 日到 4 月 17 日，是一次很典型的“工程深水区”。
我们解决的问题，已经不再是浅层 UI 或单页面逻辑，而是系统性问题：
•Token 401 级联清除导致所有同步静默失败
•会话同步字段类型错误、命名方式错误、重复同步路径
•audioFileId 类型不匹配导致 PUT note 一直失败
•上传竞态把成功状态覆盖回 recognizing
•SwiftUI .refreshable 取消任务导致连续失败
•背景任务时长不足导致 ASR 卡死
•Android 归档状态在 iOS 端无法同步
这一阶段很容易让人沮丧，因为它会让你感觉：
•每修一个问题，背后都牵出一串机制问题
•表面是一个 bug，底层却是整个架构假设不成立
•AI 虽然能帮忙定位，但要想真正修透，仍然需要极强的问题拆解和验证能力
但也正是这段时间，最能说明这次实验的含金量。因为走到这里时，我们已经不只是“会让 AI 写代码”，而是逐渐具备了：
•看日志
•找根因
•做最小修复
•控制回归
•做 PR 说明
•建立 fix 闭环
前期证明了 AI 能帮你“写出东西”，后期证明了我们正在学会“把东西修成产品”。
五、这次过程中最真实的心理变化
如果不写技术细节，只写心路历程，我觉得可以概括成下面几个阶段：
3.最开始：很兴奋，但带着不确定感感觉门被打开了。过去必须依赖研发才能推进的事情，现在自己可以直接下手。AI 不是玩具，而是真的能产出界面和功能。但与此同时，这件事又显得过于激进，甚至带着一点“这也行？”的震惊。
4.很快：开始怀疑一旦进入接口、真机、复杂状态、细节还原，问题就远超预期。AI 说得很自信，但结果常常不够好。开始怀疑：这条路到底是不是高估了？
5.中段：最挫败真正挫败的不是 bug 多，而是 自己不懂底层，所以没法像工程师那样点拨 AI。只能不断测试、反馈、再测试。这是这次实验心理成本最高的一段。
6.后来：开始调整方法不再要求 AI 一步到位，而是开始做：分阶段目标、先主流程后细节、先可演示后可发布、把规则写进文档、把 bug 收口到台账、把 review 也交给 AI 参与。
7.到现在：重新建立信心，但不再天真现在的信心不是“AI 什么都能做”，而是：
只要流程设计对、规格写得清、验证机制够严，AI 确实可以把很多原来做不到的事情做成。
六、这次最值得复盘的经验教训
1. 不要把 AI 当“自动程序员”，要把它当“高执行力但需要约束的协作者”
AI 的特点很鲜明：
•执行快
•产出多
•愿意不断重试
•会给出看似完整的解释
但问题也很明显：
•容易局部最优
•容易在错误路径上越走越远
•容易过度自信
•容易“修了这个坏那个”
所以更好的用法不是把任务一扔，等它交结果，而是：
•明确目标
•收紧上下文
•控制变更范围
•每一轮都验证结果
2. 文档不是辅助物，而是 AI coding 的核心生产资料
这次很明显验证了一件事：
AI coding 的上限，很大程度取决于文档质量。
好的文档会直接提升：
•需求理解准确率
•UI 还原稳定性
•接口对齐效率
•多人协作一致性
•新问题的处理速度
反过来，如果文档不清晰，AI 就只能靠猜；而一旦靠猜，返工几乎不可避免。
所以以后这类项目，文档至少要分三层：
•产品规格：目标、边界、优先级
•实现约束：命名、接口字段、状态机、组件规范
•经验文档：已经踩过的坑、禁止再试的低效路径
3. 真正耗时的往往不是“写”，而是“验”
前期会误以为 AI coding 的核心挑战是生成；但做下去就会发现，真正吃时间的是：
•验证是否符合预期
•验证是否影响别的功能
•验证模拟器和真机是否一致
•验证多端状态是否一致
•验证是不是只修了表面
AI 把“编码成本”打下来了，但“验证成本”反而变得更重要了。
4. Bug 一多，必须立刻结构化管理，不能靠聊天和长文档扛
4 月 10 日建立 Bug Tracker 是一个非常正确的动作。
因为当问题规模上来以后，如果没有结构化管理，就会出现：
•同一个问题反复讨论
•优先级混乱
•负责人不清
•修复状态不可追踪
•版本对应关系丢失
所以以后只要进入多人测试阶段，就应该立刻有：
•编号
•优先级
•负责人
•当前状态
•复现路径
•所属版本
5. “会不会点拨 AI”会决定效率上限
不会写代码，并不代表不能做 AI coding；但如果完全不理解底层机制，就会有一个明显上限：
•你只能描述现象
•很难判断方案优劣
•很难识别假修复
•很难主动调整实现路径
所以以后如果还要扩大这种模式，有两条路都值得做：
路线 A：提高非研发角色的工程素养至少要懂：
•日志怎么看
•文件关系怎么看
•编译链路怎么看
•常见错误怎么判断
路线 B：让 AI 补上“解释层”和“审查层”例如强制要求 AI 输出：
•根因假设
•改动范围
•风险点
•验证步骤
•回滚方式
6. 真正高效的 AI coding，不只是 prompt 写得好，而是把 spec、API 文档、工具和人工纠偏一起接进来
这次后面越来越清楚的一件事是：
AI coding 真正高效，不是因为 prompt 神奇，而是因为 AI 被放进了一个有规约、有文档、有工具、有人工反馈的系统里。
这次我们实际跑通的链路，已经不只是“对 AI 说一句需求”，而是：
•用 spec 定边界
•用文档定约束
•用 Apifox / MCP 接入接口规约
•让人工同事持续纠偏和补信息
•再让 AI 围绕这些材料执行
这个才是后面真正能复制的方法。
7. 先做可用闭环，再追求完美还原
这次很多痛苦都来自一个很真实的问题：
当你还没有稳定闭环时，过早追求细节，会把项目拖进低效微调。
正确顺序应该是：
8.主流程跑通
9.真机可用
10.核心状态稳定
11.多人可测
12.再逐步追 UI/动效/交互精细度
8. Review 代码不能省，而且越到后期越重要
这次后期很明显已经进入一个新阶段：
•不只是让 AI 写
•而是用不同 AI 做 code review、找风险、补测试、做 PR 说明
这说明一个关键事实：
AI coding 项目越往后，review 的重要性越高，而不是越低。
所以以后如果要规模化，建议把 review 机制前置成默认动作：
•写完必 review
•关键链路必做根因说明
•关键改动必带验证方案
•高风险修复必控制变更范围
七、如果回头看，这次最宝贵的收获是什么
我觉得最宝贵的收获，不是“做出了一个版本”，而是我们已经摸到了一套更真实的认知：
13.AI coding 不是神话，但也不是噱头它既没有想象中那么自动，也绝对不像外界怀疑的那样只是 demo 工具。
14.产品、设计、研发的边界会被重写不是谁替代谁，而是谁能更快进入问题现场，谁就更有推动力。
15.未来比拼的不是谁会用 AI，而是谁能建立更好的 AI 协作系统包括文档系统、约束系统、review 系统、bug 管理系统、测试与发布系统。
16.这次实验已经证明：非研发人员可以深入到实现层以前产品进入实现层，往往会被工具链和技术细节挡住；这次虽然很辛苦，但也证明了一件事：
你已经不是只能“提需求”的角色，而是可以真正推动实现落地的人。
八、给下一次 AI coding 实验的建议
启动前
•先写清楚目标：是 demo、可演示、TF、还是正式上线
•先定优先级：主流程 > 稳定性 > UI 细节
•先准备规范文档、接口文档、设计约束
开发中
•每天沉淀经验文档，不要只留在聊天记录里
•改 2~3 次还不对的问题，及时跳过或换路径
•AI 每次提交改动时，要求附带风险点和验证步骤
•重要问题必须做根因定位，不能只修表面现象
进入测试后
•立刻建立 Bug Tracker
•把问题按 P0/P1/P2 分层
•一轮只收口最关键问题，不贪多
•开始引入 AI review、PR 规范和回归验证
准备发布时
•把“能演示”和“能发布”明确区分
•同步、登录、支付、音频、状态管理这些链路优先级最高
•一切高频核心路径都要真机验证，不迷信模拟器
十、最后一句
如果只看过程，这次重写其实并不轻松，甚至可以说很折腾；但如果看结果，它很值。
但未来的挑战依然存在，我们这次是重写 App，如何挖掘需求、迭代产品，还没有实践起来。
参考资料 / 来源文档
这篇总结主要参考了以下材料：
一、方案 / 预研
17.AI 重写 Slax Note App 方案预研
二、会议记录 / 文字记录
18.文字记录：v5.38 需求牌桌会 2026年3月18日
三、阶段日报 / 复盘 / Coding 日报
19.2026-03-23 Coding 日报
20.SlaxNote iOS AI coding 日报 - 2026-0407
21.2026-04-10 Coding 日报
22.SlaxNote iOS · 今日研发日报（2026-04-13）
23.SlaxNote iOS · 研发日报（2026-04-14）
24.Slax Note iOS 日报 2026-04-15
25.SlaxNote iOS 日报 · 2026-04-16
四、设计 / 经验沉淀
26.AI Coding - iOS 设计还原经验总结
五、问题管理 / 过程佐证
27.Slax Note iOS TF Bug Tracker
六、群聊消息上下文
此外，本文还参考了以下群聊在 2026-03-10 至 2026-04-17 期间的消息讨论：
•oc_0f288ac96b328b89e415183f2cf93691（Slax Note AI Coding 试验群）
•oc_5febabd51308c5aa6af7593d0911deda（Slax PR bot）
•oc_fa6df3c9330ad0b770c859fa49818c8b（Slax Note · All）
•oc_9d791f992b9ccb04306e1506adabad64（Slax Note · Mini）
说明：本文是基于群聊、日报、会议记录和过程文档做的综合整理，不是逐条会议纪要式摘录。个别判断和归纳，为基于多份材料交叉整理后的总结表达。
点击阅读原文，可以跳转到 Slax Note 下载这个产品体验感受。有什么反馈建议，欢迎留言。