安仔
3周前
我们平时兴冲冲打开 Claude Code,然后就开始瞎写代码(尤其是小白),结果项目越做越乱,最后发现自己在一堆烂摊子里挣扎? 这个视频里的老哥 Avthar 说他以前就是这么干的,直到他摸索出了一套叫 PSB 的系统——Plan(计划)、Setup(配置)、Build(构建),现在他每个项目都用这套流程,效率直接翻了 10 倍。 他说的第一个阶段是计划阶段,听起来似乎大家都知道对吧?但他强调花 15 分钟做计划能省你好几天的时间。 这个阶段核心就是问自己两个问题: 1. 你到底想干什么? 2. 你想要哪些功能里程碑? 比如你是在做原型验证还是要上线给真实用户,这完全决定了你的开发方式。 如果只是做原型,那就快速迭代不用管边界情况;但如果要上线,安全性、错误处理这些都得考虑进去。 他建议把项目拆成 MVP(最小可行产品)和后续几个版本,别想着一次做完所有功能。 然后他提到一个特别实用的技巧: 让 AI 来问你问题。 你把初步想法丢给 Claude,让它问你三个最重要的问题,通过回答这些问题你会发现很多自己没想清楚的地方。 他甚至会用语音模式跟 ChatGPT 聊天,把模糊的想法说出来,然后让 AI 整理成文档。 最后这个阶段要输出一个项目规格文档,包含产品需求和技术需求两部分。 产品需求就是你要解决什么问题、给谁用、具体交互是什么样; 技术需求就是选技术栈,他自己偏好的是 Next.js + Tailwind + Supabase 这套组合,但重点是你得明确告诉 Claude 用什么,不然它会自己瞎选。 第二阶段是配置阶段,他列了个七步清单。 首先是建 GitHub 仓库,这样你能在网页端和手机上用 Claude Code,还能用 GitHub CLI 和自动化 PR 审查。 然后是配置环境变量文件,把所有 API key 提前填好,省得 Claude 老是停下来问你。 接着是重头戏—— 文件,这个文件会一直在 Claude 的上下文里,但不能塞太多东西。 他建议放项目目标、架构概览、设计规范、约束条件这些核心信息,其他详细内容可以链接到别的文档。 他特别强调自动化文档这个概念,就是让 Claude 在开发过程中自动更新几个关键文档: 记录系统设计、 记录变更历史、 记录当前进度和下次从哪继续。这样即使你几周没碰项目,回来也能快速接上。 然后是配置插件和 MCP(模型上下文协议)服务器,比如前端开发插件能避免那种千篇一律的紫色渐变 UI,数据库 MCP 能让 Claude 直接操作你的 MongoDB 或 Supabase。 最后是设置自定义命令和子代理,比如他有个命令专门用来更新所有项目文档,还有个子代理专门做前端测试。 两个高级技巧也值得一提: 一是预配置权限,让 Claude 不用每次都问你能不能运行 git 命令; 二是设置钩子(hooks),比如测试失败时自动让 Claude 继续修复,或者 Claude 需要权限时自动发 Slack 通知你。 第三阶段就是构建阶段了,终于可以写代码了。 他推荐三种工作流: 1. 通用工作流适合单个功能开发,分为研究、计划、实现、测试四步,其中计划模式最重要,别上来就让 Claude 写代码; 2. 基于 Issue 的工作流把 GitHub Issues 当作任务管理中心,适合保持项目整洁; 3. 多代理工作流最高级,用 git worktrees 让多个 Claude 实例同时开发不同功能; 他试过同时开三个功能,效率爆炸。 最后他给了四个保持高效的建议: 1. 尽量用最好的模型,Opus 4.5 做规划和复杂任务,Sonnet 做实现,Haiku 只做简单修复; 2. 定期更新 文件; 3. 看到 Claude 犯错时用 # 号快速添加规则防止重复错误; 4. 别怕扔掉代码,原型阶段如果不满意就重来,代码很便宜时间才贵。 他这套 PSB 系统确实很系统化,特别适合那种容易一头扎进代码然后迷失方向的人。 所以还是那句话,别急着写代码,宁愿花时间做好计划和配置,后面开发你会感觉顺畅得多。
安仔
3个月前
最近发现了一个很有意思的现象,越来越多人拿着 AI 写出来的代码找我,问我能不能帮他们把这些东西变成真正能用的产品。 这些人通常不是技术背景,可能是律师、销售或者其他领域的专业人士。他们有好点子,也用上了最新的 AI 工具,甚至真的把一个看起来能跑的 demo 做出来了。 但到了某个节点,他们就卡住了,然后开始满世界找技术合伙人或者 CTO。 这让我想到一个问题:如果 AI 真的能完全取代软件工程师,为什么这些人还需要我们? 我也一直用 AI 辅助写代码,也看了很多别人的演示。慢慢地我意识到一件事:AI 确实会写代码,但它造不出软件。 这两者之间有条很深的鸿沟。 写代码其实不难,解决一个个独立的、定义清晰的小问题,现在的 AI 已经做得很好了。但软件工程难的从来不是这个。 真正的挑战是当你要把 demo 变成产品的时候,你得同时处理几百个这样的小问题,还要让整个系统保持可维护、可扩展。 这就是那些人找上门来的根本原因。他们能用 AI 快速搭出一个功能演示,但要让它变成真正能上线运行的产品,就完全是另一回事了。 我看过他们发来的代码,说实话,所谓的"让它变得可以上线",基本上就是推倒重来的意思。 不是代码写得不对,而是整个结构、集成方式、长期维护的考量,这些东西根本就不在那些代码里。 软件工程师的核心工作其实是管理复杂度。 一个真正的生产系统做的事情,单独拆开看都不复杂,但要同时做好几百件简单的事,还要让它们协同工作,这才是真正考验人的地方。 我也不知道为什么 AI 现在还做不到这一点,可能这就是这个职业的本质吧。但至少现在,这条线还是很清晰的: AI 能帮你写代码,但把代码变成软件,还是得靠人。 工具在进化,但有些能力的门槛,并没有因此降低。