他只用 Claude 写代码，真的把一个完整笔记应用「迭代」出来了

不是 Demo，不是玩具项目。Riley Brown 在这期视频里展示了一件更反直觉的事：一个功能不断膨胀的笔记应用，几乎所有改动、重构和新功能，都是直接让 AI 写代码完成的，而且成功率高得惊人。

最反直觉的一点：AI 不是“帮你写代码”，而是在“接管迭代”

如果你以为这期视频只是“Claude 又能写代码了”，那你会低估它的冲击力。Riley Brown 做的事情不是从零生成一个项目，而是在一个已经有前端（TypeScript）、后端（Python）、认证体系的真实应用里，反复让 AI 改代码、加功能、修 UI。

视频一开场，他几乎是带着惊讶在夸 Claude：代码直接能跑，改动是对的，而且不是一次，是连续多次。更关键的是，他没有把 AI 当成“函数生成器”，而是像对待一个初级工程师——告诉它：我要改 sidebar、我要加新的 note plan、我要让某个状态默认选中。

这和很多人用 AI 写代码的失败经验恰恰相反。失败的人往往希望 AI 一次性给出完美答案；而 Riley 的方式是：小步修改、立即验证、再继续压需求。这让 AI 真正参与到了“产品迭代”而不是“代码拼接”里。

从侧边栏到日历：AI 真正擅长的是“局部但完整”的改动

一个很有代表性的片段是 sidebar 的修改。Riley 明确说：这会有点难，但看起来只需要改一个组件文件。结果呢？Claude 不仅找对了文件，还立刻做出了正确的 UI 状态调整，让新选项自动高亮。

这类成功并不是偶然。你会发现，只要满足三个条件，AI 的表现就会非常稳定：
1）作用范围清晰（只改 sidebar / 只改一个组件）
2）上下文完整（已有代码结构，而不是空白项目）
3）目标是“行为变化”，不是“架构重写”

同样的模式也出现在日历集成的讨论里。Riley 并没有要求 Claude 直接给出一个“完美方案”，而是先确认：TypeScript 前端 + Python 后端，这件事“是不是可行”。在得到肯定后，再逐步推进。这其实是在用 AI 做技术可行性评估，而不是单纯写代码。

认证、图片、视频：AI 开始进入“脏活累活”区间

真正让我觉得这期视频“含金量很高”的，是后半段那些不性感、但极其耗人的功能：认证、图片上传、不同文件格式支持。

Riley 提到他几天前已经加过 authentication，现在直接让 Claude“生成我需要实现的完整代码”。注意这里的前提：不是从零设计 auth，而是在已有系统里补齐实现细节。这种任务对人类工程师来说非常烦，但对 AI 来说却异常友好。

更有意思的是文件测试。他随手截图一条“乱七八糟”的笔记，让 AI 帮忙处理，结果 webp 和 PNG 都一次通过。没有玄学调参，没有反复 debug。这意味着什么？意味着在这类 CRUD + 文件处理的典型 Web 应用里，AI 已经能稳定覆盖 70%–80% 的体力活。

到视频后段，他甚至开始说“我真的很喜欢这个绿色，超级干净”。这句话本身很轻，但背后的信号很重：当你开始和 AI 一起讨论审美和体验，而不是 bug，本质上说明工程问题已经被压平了。

这不是“AI 写 App”，而是“人类在学怎么管理 AI”

如果你完整看完这期视频，会发现 Riley 的角色非常清晰：他不写代码，但他一直在做三件事——定义问题、判断结果、决定是否继续。

当 AI 给的方案不理想时，他不会卡死，而是“给它一些别的想法”。当页面还有一块白色区域没解决，他会停下来，说：我们得 figure this out。这种工作方式，本质上更像产品经理 + 技术负责人，而不是传统开发者。

视频最后的总结也很克制：功能还可以继续加，但现在已经“很干净、很即时”。这不是炫技，而是一种对边界的尊重——知道什么时候该停，什么时候继续让 AI 干活。

这或许才是这期视频真正的价值：它没有证明 AI 无所不能，而是展示了一种已经可行的新分工模式。

总结

如果你是开发者，这期视频给你的最大启发不是“去用 Claude 写代码”，而是重新设计你的工作流：把需求拆小、把上下文交代清楚、用验证而不是信任来对待 AI。如果你是做产品或创业的，这意味着 MVP 的成本正在被系统性拉低，但前提是你得学会“指挥”AI。一个值得你思考的问题是：如果 70% 的实现都能被 AI 覆盖，你真正不可替代的能力，是什么？

关键词： Claude， 代码生成， AI 编程， 笔记应用， 产品迭代

事实核查备注： 视频发布时间（2024-08-15）；作者/频道名 Riley Brown；使用的 AI 产品为 Claude；项目技术栈提及 TypeScript 前端与 Python 后端；视频为 part 2