我如何用 AI 独立完成产品闭环
过去几个月里，我一直在尝试许多不同的AI编程工具和技术，目标是简化自己作为一人团队构建个人项目的工作流程。我的目标是创建一个让软件开发变得高效、轻松且有趣的系统。虽然新模型、新功能和新工具总有改进空间，但与刚开始时相比，我的工作流程已经有了显著提升。
真正起到作用的有三类东西：使用智能体技能框架、搭建测试自动化，以及设计远程优先的人体工程学工作流。这些改变带来的生产力提升相互叠加，我估计它们至少让我效率提升了10倍，同时产出质量也更高了。
1. 使用 /superpowers 构建
当我最初开始用Claude Code构建个人应用时，我非常依赖Plan Mode：我会在一个运行最新Opus模型的新会话中按Shift+tab进入Plan Mode，把尽可能多的产品和技术上下文倾倒进去，反复迭代直到计划看起来合适，然后绿灯放行，看着它执行。
这对简单功能还行，但对更复杂的东西就时好时坏了。我有一个叫LemmeCook的烹饪应用，其中的新手引导流程、推荐餐食逻辑、食谱导入和库存管理都以微妙的方式相互关联。当这些交互关系很重要时，Claude Code总是做出不直观的产品和UX选择。
我搞不清问题出在计划规格不够详细、执行偏离了计划，还是两者都有。我花了大量时间修复bug和非预期行为，很累，也降低了构建的乐趣。
真正改变局面的是使用/superpowers，这是Jesse Vincent创建的Claude插件，可以从Anthropic官方插件市场轻松安装。1它打包了四个关键技能，对应传统产品开发的步骤：头脑风暴（brainstorming）、编写计划（writing-plans）、执行计划（executing-plans）和代码审查（code-review）2。这四个技能可以作为独立步骤直接调用，也可以作为链式序列一起调用。
1.1 头脑风暴
头脑风暴技能帮助你从产品想法生成结构化的PRD（产品需求文档）。当我有一个想法——通常是关于某个功能应该如何工作的半成型想法——我会把脑子里的东西一股脑倒给Claude，让头脑风暴技能接管。它会向我复述听到的内容，提出澄清问题，并发现我之前没有考虑到的产品空白和张力。对于前端工作，它生成线框图，让我可以在浏览器中决定视觉和UX方向。感觉就像同时拥有一个PM讨论伙伴和设计师。
作为构建者，我非常享受头脑风暴阶段。我发现从一组选项中回答问题（尤其是有视觉辅助时）比从零开始生成正确的问题和潜在答案要容易得多。我还能管理这个过程并注入我的个人品味：很容易引导Claude探索更多选项并发挥创意，或者让它更快地收敛到一个足够好的方案。
/superpowers引导你完成关键产品和设计决策的交互式头脑风暴过程
1.2 编写计划
当头脑风暴技能产出我满意的产品规格后，编写计划技能会将规格转化为详细的实施计划。计划是一个包含离散任务的markdown文件，每个任务包含详细指令。以下是它为我们刚才头脑风暴的规格编写的计划片段：
# Cook Tab — "Tonight" Trio Implementation Plan
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** Replace the Cook tab's filtered 6+ card grid with a daily-ritual surface showing exactly 3 AI-curated picks — each with a personalization reason chip — plus a single reroll button, refreshing once per local calendar day.
**Architecture:** Mobile rewrites `cook.tsx` to render three `TonightCard` rows (new) + one reroll button. `usePoolSuggestions` is simplified to a 3-pick query with a `reroll` action; filter state is removed. The API engine `generateSuggestionsForUser` accepts an `excludeTitles` array (used to avoid repeats on reroll) and produces a `reason: { type, text }` field per suggestion via a new post-composition reasoning step. The `suggestion_pool` table gains a small `reason` JSONB column.
**Tech Stack:** React Native / Expo Router / TanStack Query / NativeWind on mobile · Express / Zod / Anthropic SDK / Supabase on API · TypeScript end-to-end · Maestro for E2E.
**Spec reference:** `docs/superpowers/specs/2026-05-02-cook-tab-tonight-trio-design.md`
---
## File Structure
| File | Action | Responsibility |
|------|--------|----------------|
| `packages/shared/src/types/suggestion.ts` | Modify | Add `ReasonType` union and optional `reason` field on `PreGeneratedSuggestion` |
| `supabase/migrations/00031_suggestion_pool_reason.sql` | Create | Add nullable `reason` JSONB column to `suggestion_pool` |
| `apps/api/src/services/preGenerationEngine.ts` | Modify | Accept `excludeTitles` option; replace feasibility-only selection with `(cuisine, protein-class)` diversity-aware selection; add post-composition reason selection step; persist `reason` to row |
...
Total: 7 new files, 6 modifies, 2 deletes, 4 Maestro flows. ~700-900 LOC delta.
---
### Task 1: Add `ReasonType` and `reason` field to shared types
**Files:**
- Modify: `packages/shared/src/types/suggestion.ts`
- [ ] **Step 1: Add the `ReasonType` union and `Reason` interface**
In `packages/shared/src/types/suggestion.ts`, add **before** `PreGeneratedSuggestion`:
export type ReasonType = 'history' | 'inventory' | 'variety' | 'library'
export interface Reason {
type: ReasonType
text: string
}
...
根据我正在做的工作，我通常会花几分钟对高层计划和任务做合理性检查。我通常不会花时间去深挖每个任务中的实现细节。不过，我确实经常试探Claude，了解计划如何处理某些边界情况，验证它是否会实现我期望的产品行为。
例如，这里我问Claude计划是否能确保所有推荐的餐食足够不同（它不能），然后建议了一个修复方案：
Claude为我发现的非预期产品行为推荐了修复方案
1.3 执行计划
当实施计划看起来不错时，执行计划技能会读取计划并编写代码。我通常可以选择串行执行或为每个任务启动一个新的子智能体，后者使用了另一个打包技能——子智能体驱动开发。我通常选择更快的并行选项。Claude会自动识别哪些任务可以并行化，哪些彼此有依赖关系，哪些任务可以由更弱的模型处理（例如用Sonnet或Haiku代替Opus）。
根据我的经验，执行通常是最长的步骤，根据任务不同可以自主运行10分钟到数小时。这是个离开电脑的好时机。我通常会启动执行阶段，然后利用这个间歇去散步或买杯咖啡。
/superpowers提供不同的执行选项
1.4 代码审查
第四个技能是代码审查，在构建完成后运行并检查工作成果。它识别并修复bug，标记实现偏离计划的地方，并捕获你希望更资深工程师能捕获的问题。
这个步骤可以与执行计划链式组合，这样Claude就可以自主运行代码审查和编辑的循环，直到审查者标记的所有问题都被解决，无需我的参与。
使用superpowers构建让我认识到，AI尚未消除识别问题、用户、使用场景和待完成任务的需要。产品思维对于使用智能体进行产品开发至关重要，但现在我们可以以AI辅助的高度压缩方式完成这些工作——而拥有一个智能体技能框架来强制执行这些最佳实践，带来了很大的不同。
事实上，在一个代码生成成本很低、很容易的世界里，上游工作实际上变得更加重要，而非更少。直接跳入执行并用最终输出迭代是很诱人的，但一次又一次，我发现在一开始就认真对待头脑风暴、审查规格和审视实施计划，最终会缩短达到满意的时间并提高产品质量。
在前期的产品定义上投入更多时间，可以节省大量人力和日历时间！
2. 测试自动化
使用像superpowers这样的结构化产品开发框架显著提高了我的产出质量，但还远远做不到万无一失。例如，Claude Code有时会生成重叠的抽屉和弹出模态框，导致我的烹饪应用中某些UI元素无法点击。在后端方面，它有时会遗漏竞态条件，导致加载错误或无数据。这些类型的bug在产品规格的测试计划中不容易被测试到。
2.1 Codex审查
虽然我更倾向于使用Claude Code作为主要编程伙伴，但我也尝试过Codex，发现它作为模型/工具通常更严谨、更有条理。与Claude Code相比，Codex不那么有创意，但会更严格地遵循指令。我已经在让Codex审查Claude的较大提交了。
3月下旬，OpenAI发布了Claude Code的Codex插件，我决定将其纳入工作流程。我会让Codex使用codex:rescue技能审查Claude编写的实施计划。实施步骤完成后，Claude Code会启动Codex作为子智能体来审查代码。然后Claude会解决Codex标记的任何问题并再次提交审查。这个循环会持续到所有问题都被解决，有时需要多达3或4次迭代。
虽然额外的审查轮次需要时间（有时30分钟以上），而且Codex在审查中有时过于学究气（例如将一个小问题归类为关键问题），但它通常能捕获Claude Code遗漏的真实bug或不一致之处。我发现纳入Codex审查显著提高了整体产品质量，尤其是在后端功能和数据密集型流程中。
Codex在Claude的实现中标记问题，然后Claude修复它们
2.2 implementation-review技能
无论代码审查多么出色，都替代不了对实际用户行为和产品流程的端到端测试。在Stripe，实现审查（implementation review）是产品开发中最重要的上线前步骤之一，训练有素的人类审查员会审核你的产品发布并编制问题列表（包括阻断性反馈）供团队解决。对于有许多流程的新产品或复杂产品，可能需要数周的来回沟通，但这是维护产品质量标准的关键环节。
为了模拟这个过程，我创建了自己的implementation-review Claude技能。对于我的移动应用，它与我一起生成一组测试场景。对于每个场景，它运行一个类似于人类审查员测试应用的循环：截取当前状态的屏幕截图，分析它，记录发现，决定并执行下一个操作，再截取一张屏幕截图来理解行为。最后，它生成按严重程度组织的发现总结。
在底层，该技能使用不同的工具来审查不同类型的产品。对于移动应用，它使用由Sentry维护的名为XcodeBuildMCP的MCP服务器，让Claude能够构建和测试iOS移动应用。XcodeBuildMCP将许多底层AppleScript和simctl Xcode模拟器工具封装成对智能体友好的界面。对于Web应用，它使用playwright-mcp来导航浏览器。
当把这些串联起来时，这个设置变得非常强大：
- 每份实施计划和每行代码都由Codex审查。
- 每个关键用户场景都由implementation-review技能自动审查。
- 每个实现审查发现的问题都会被捕获并发回给Claude处理（然后由Codex进行代码审查）。
添加实现审查可能会让我的开发周期增加数小时，但如果设置得当，它可以自主运行，非常值得投入。
使用implementation-review技能和Codex审查的自动化迭代测试可以节省数天的手动调试
3. 远程优先的人体工程学
在我开始使用superpowers和测试自动化设置后，我与Claude的工作从主要是交互式会话转变为短暂的交互式头脑风暴和产品定义，然后是Claude自主运行的长时间会话。这让我的工作流更高效了，因为我可以在睡前启动一个任务，早上查看结果。
但我开始遇到一些其他问题：
- 打字成了一个主要瓶颈。向LLM输入更多上下文一直会带来更好的结果，但在新的工作流中，上下文量成了一个限制因素——更多上下文意味着更好的头脑风暴，意味着更好的规格，意味着更好的执行和输出。但我不想为每个想构建的新功能都打一篇文章。
- 监控和保持长时间运行的会话存活。我需要保持笔记本电脑打开才能让长时间运行的执行会话继续，但当我在共享办公空间工作需要回家时就很难做到。其他时候，任务需要决策，而我会离开键盘数小时，让我的智能体一直在等待。我希望能随时随地查看进度并解除智能体的阻塞。
- 管理并行智能体。在等待Claude的时候，我开始并行处理多个项目和同一项目中的多个功能。在Ghostty的标签页和窗口3中管理一切变得很困难。
这些都是新颖的开发者人体工程学问题，我找到了不错的解决方案：
3.1 语音输入
我开始默认使用WisprFlow说话而非打字，这对我的头脑风暴迭代的质量和速度产生了巨大的积极影响4。我能传达的信息吞吐量至少是打字的3-4倍，尤其是在手机上工作时。虽然我的意识流远不如打字时结构清晰或语法正确，但它在实现目标方面效果很好：如今的前沿模型相当宽容，善于从噪声中提取信号。
过去几个月，我在桌面和移动端与Claude Code的绝大部分交互都是通过WisprFlow进行的。小贴士：花几分钟将常用词（如Claude、Tailscale、Codex）添加到它的字典中是一项很好的投资，可以避免后续许多不必要的错误和浪费的循环。
在家工作的一个意想不到的好处是你可以自由口述，不用像个疯子一样窃窃私语 :)
3.2 远程开发
为了让持久会话继续运行，我把所有开发工作都搬到了我的Mac Mini上5。我考虑过云VM方案，但对于我的iOS开发，我需要运行MacOS，而大多数性价比高的云选项运行的是Linux。
我参考了这份指南，配置了tmux（用于持久会话）、Tailscale（用于手机、Macbook和Mac Mini之间的可靠网络）以及Claude远程控制（用于同步Claude会话）。假设你有一台Mac Mini，设置过程相当快。tmux和Tailscale是免费的，我还花了20美元买了Blink的iOS应用，它让我可以从手机上获得终端和直接的ssh访问。最后一部分不是必须的，但我希望有一个备用选项，以防远程控制连接断开时需要重启它们。
现在，当我在家或共享办公空间从笔记本电脑工作时，我ssh到我的Mac Mini，这样当我合上笔记本盖子需要回家时，智能体可以继续运行。当我在路上时，我通过Claude移动应用在火车或汽车上继续监控我的会话。
偶尔我会被系统权限阻塞，不得不求助于笔记本电脑上的原生屏幕共享应用（或者不太理想的手机上的RVNC Viewer iOS应用）来直接控制我的Mac Mini。
通过远程控制在Claude桌面应用、移动应用和TUI（未显示）中使用同一个Claude Code会话
3.3 智能体编程环境
在过去6个月里，出现了一整个产品类别来更好地服务这些新的智能体编程工作流。
为了更好地管理我的并行编程会话，我尝试了几款工具：6
- Superset.sh是一款智能体原生终端产品，内置与Github和Git worktree的原生集成，让你可以轻松创建新分支和功能。你可以配置设置和拆卸脚本来处理运维任务，如设置.env文件。它带有差异查看器、markdown查看器和内置浏览器。当Claude需要我的输入时，我会收到通知切换到那个标签页。Claude Code TUI是Claude所有产品界面中响应最快、功能最全的，所以这是使用该工具的一个不错好处。
- Claude桌面应用在过去几个月得到了很多关注，现在支持SSH连接以及多项目和并行会话，也有Git worktree集成。我也喜欢在同一个应用中有Claude Cowork和Chat，这使键盘快捷键导航变得容易：仍然有一些产品研究和通用知识工作我更喜欢在非代码优先的UI中完成。7
- cmux是一款由libghostty（Ghostty所基于的终端库）驱动的开源终端，内置垂直标签页和并行会话通知。与Superset不同，它专注于纯粹的终端体验，而不是端到端的编程工作流。我喜欢cmux的地方在于速度和原生ssh支持，可以处理自动端口转发等事务——这在头脑风暴期间测试和可视化模拟时非常有用。
我最终采用了混合设置。我喜欢在Macbook上使用Claude桌面应用同时SSH到Mac Mini，但我通过Ghostty中的TUI保持相同的交互式会话。每个会话都配置为使用/remote-control运行，这会在两个界面之间同步我的所有会话。它还使我的会话可以通过Claude移动应用访问，这给了我一个不错的界面来在移动中监控、解除阻塞和引导。
对于我的实际工作流，我喜欢与TUI交互（即：说话），因为它更响应、更可靠，也是第一个收到新功能的界面。但混合设置让我可以在Claude桌面应用中滚动和阅读执行历史，或快速在会话之间切换，而不会中断CLI。它是一个比终端更好的阅读规格和计划markdown文件的界面。复制粘贴和图片输入在桌面应用中也好用得多：例如，你不能将图片从本地机器拖到远程CLI会话中。
我的设置确实有一些粗糙之处，我认为这反映了当前的现实：TUI、桌面、移动和Web界面之间缺乏功能和用户体验的一致性。我测试过的所有产品都相对较新且不成熟，显著功能每周都在落地的开发速度就是证据。好消息是这些产品正在快速成熟，8我很乐观地认为6个月内大多数问题都会被解决。也许我们会标准化到一个不那么碎片化的设置上（理想情况下是没有平台锁定的！）。就目前而言，我对已有的设置相对满意。
4、结束语
像/superpowers这样的智能体框架、测试自动化和更好的构建者人体工程学相互叠加。智能体框架将我的主动键盘（或口述）时间压缩成高效的短时爆发。测试自动化让我的编程智能体可以自主运行更长时间，同时产出更好的结果。而远程优先的人体工程学让我可以随时随地查看这些智能体，将空闲时间利用起来。
在使用不同工具和技术不断构建和重建的过程中，我确信使用AI构建是一门技能，就像软件工程或产品管理一样。我们都可以以相同的每月100美元获得相同的前沿模型、工具和编程工具，但使用它们构建好产品的能力分布得相当不均匀。
根据我的经验，AI构建者最重要的技能是双重的：（1）能够在头脑风暴期间通过做出具体的产品和设计决策来定义你想构建什么，（2）能够足够清晰地定义成功是什么样的，以便你的编程智能体可以用正确的目标运行代码+验证循环。要在今天做到这两点，理解数据建模、API设计和客户端/服务器架构等软件工程基础知识仍然有帮助。一年后，我感觉模型、工具和产品可能会把这些抽象掉。我们可能只剩下产品品味和信念。9
学习这些技能最好的方式就是开始构建一些东西——没有替代亲身体验和知识的办法。鉴于工具和技术发展如此之快，静态资源（包括这篇博文）很快就会过时。事实上，我分享的设置在几个月前甚至还不存在，我完全预期它在几个月后就会过时。
最后，作为构建者，驾驭这么大的浪潮让人感到无比兴奋和充满力量，但也因为发展速度太快而令人眼花缭乱。我几个月前学的东西已经感觉过时了。每周我都会遇到尝试更雄心勃勃的事情的人——运行完全自治的公司、编排成千上万个智能体的集群——光是跟上节奏就像一份全职工作。
原文链接: How I build with AI as a 1-person product team
汇智网翻译整理，转载请标明出处