Star Star的日记

独立开发者如何用 AI 开发：先产品，再原型，最后工程

记录时间：2026-07-17 20:26:02

这篇笔记整理自一次关于 Codex Skills、独立开发者工作流，以及如何避免过早思考架构的长对话。

真正的问题不是 Skills 不够多

讨论最初从「如何禁止 Codex 自动调用 Skills」开始，后来逐渐扩展到：从一个 Idea 出发，独立开发者如何借助 AI 完成产品、网站、管理后台、App、API、数据库、Docker 和云端发布。

过程中出现了许多 Skills，也产生了一个明显问题：每轮建议似乎都不一样。

原因并不复杂。不同 Skill 分别服务于产品探索、需求规格、界面设计、编码、调试、审查和发布。如果不先区分阶段，它们就会混成一条又长又重的流水线，让一个简单问题也经历头脑风暴、写计划、建 Worktree、TDD、代码审查和分支收尾。

对独立开发者而言，最大的风险通常不是不会写代码，而是：

工程能力太强，AI 执行速度太快，于是在用户问题还没有确定时，就开始设计数据库、API、Docker 和云服务。

这是一种「过早解决方案化」。架构越来越完整，产品价值却仍然模糊。

最合适的三阶段模型

整个项目只需要分成三个彼此隔离的阶段：

产品探索
→ 产品设计
→ 工程实现

每个阶段只解决一种问题，并设置清晰的进入条件。

第一阶段：产品探索

这一阶段只回答四个问题：

  1. 谁遇到了问题？
  2. 问题发生在什么具体场景？
  3. 用户现在如何解决？
  4. 现有方法为什么不够好？

输入： 产品 Idea、目标用户猜想、真实案例、现有替代方案。

AI 做什么： 追问用户、场景、频率、严重程度和行为改变的可能性，找出最关键的价值假设，并设计最低成本的验证方法。

可用 Skill： brainstorming。它不是必需品，一段明确限制讨论范围的 Prompt 也可以完成同样的工作。

输出： problem.md、待验证假设和验证计划。

阶段门禁： 必须能用一句话说清楚：某类用户在某个场景下，因为某个障碍，无法完成某个重要目标。

这一阶段禁止讨论技术栈、数据库、API、代码、Docker 和部署。想到的技术方案可以放进 parking-lot.md，但不进入当前决策。

第二阶段：产品设计

问题明确以后，才开始回答：用户如何通过产品完成任务？

输入： 已确认的问题、核心用户任务、第一版要验证的价值、明确不做的功能。

AI 做什么： 编写用户故事、核心流程、异常状态、验收标准和非范围；随后使用静态数据制作可点击原型。

可用 Skills：

  • speckit-specify：把想法整理成产品规格，回答「做什么」。
  • speckit-clarify：找出规格中的歧义，并把产品决定写回规格。
  • frontend-design：把已确认的流程做成静态可体验原型。
  • web-design-guidelines：审查已经存在的 UI 代码，不负责产品定位。

输出： spec.md、user-flow.md、mvp.md 和静态原型。

阶段门禁： 核心流程能在原型中完整走通，MVP 的「必须做」和「明确不做」已经冻结，并且自己或目标用户认可这个体验。

这一阶段仍然不建立真实数据库、API 和生产基础设施。静态原型的任务是验证价值与体验，不是偷偷开始写生产系统。

第三阶段：工程实现

只有用户问题、核心流程和 MVP 都被确认，才进入工程模式。

输入： 冻结的产品规格、已验证的原型、技术约束和真实内容样本。

AI 做什么： 设计满足当前需求的最小架构，定义数据与 API 契约，初始化工程，再把项目拆成可以独立验收的垂直切片。

可用 Skills：

  • speckit-plan：把已确认的产品规格转换为技术方案。
  • writing-plans：为一个明确功能写可执行的小步计划。
  • test-driven-development：用于核心业务规则和 Bug 回归，不机械覆盖所有 UI 调整。
  • systematic-debugging：出现异常时先复现、收集证据、验证假设，再修复根因。
  • verification-before-completion：声称完成前实际运行测试、构建和检查。
  • requesting-code-review：在独立上下文中根据规格、Diff 和测试结果找问题。
  • finishing-a-development-branch：开发、审查和验收完成后整理 PR 与合并。

输出： 架构文档、数据契约、API 契约、可运行工程、功能代码、测试、迁移、审查报告和发布记录。

工程设计有一条硬约束：每个技术决策都必须能指向某条已经确认的产品需求。 不为尚未出现的规模问题建设微服务、消息队列或复杂平台。

先打通一条垂直闭环

不要先做完所有数据库，再做所有 API，最后才联调网站和 App。正确做法是先交付一条完整、可观察的用户能力。

对投资内容平台，第一条闭环应该是：

生成一篇财报、演讲或访谈内容
→ 管理后台导入
→ 系统校验和预览
→ 管理员发布
→ 网站能够阅读
→ App 能够阅读同一篇内容

这条闭环跑通以后，再增加公司管理、筛选、搜索、收藏或其他能力。系统是否成立，应由真实流程证明，而不是由目录数量和架构图证明。

每个功能的固定循环

每个功能不必重新走完整项目流程，只需要重复下面的小循环：

轻量功能规格
→ 简短实施计划
→ 实现与测试
→ 完成前验证
→ 新上下文审查 Diff
→ 人工验收
→ PR、CI、合并

你每次只输入：一个用户能力、验收标准、明确非范围和相关原型。

AI负责阅读项目规则、定位相关代码、写短计划、完成最小实现、运行验证，并报告仍未覆盖的风险。AI不应自行增加需求，也不应在未经允许时提交、推送或部署。

Bug 则使用更短的流程：

稳定复现
→ 找到根因
→ 写回归测试
→ 修复
→ 完整验证
→ 发布

每次发布的固定循环

部署 Staging
→ 真实浏览器与 App 流程测试
→ 人工批准
→ 数据库备份
→ 生产部署
→ Smoke Test
→ 观察日志和监控

浏览器端可以使用 agent-browser 或 Codex 的浏览器控制能力。阿里云发布流程更适合做成项目自己的 aliyun-release-checklist，其中固定检查镜像版本、数据库迁移、备份、ECS、OSS、域名、HTTPS、回滚命令和生产 Smoke Test。

另一个值得自建的 Skill 是 content-package-contract：它负责约束财报、CEO 演讲和管理层访谈采用相同的数据格式，使后台、网站和 App 面对的是同一个稳定输入。

Skills 应该怎样取舍

Skills 不是装得越多越好。重复能力只保留一套：

  • brainstorming 与 grill-me 二选一；
  • speckit-specify 可以替代通用的 to-prd；
  • speckit-clarify 可以替代 grill-with-docs 的大部分作用；
  • frontend-design 可以承担静态原型工作，不必再保留独立的 prototype；
  • test-driven-development 与 tdd 二选一；
  • 项目自己的 aliyun-release-checklist 替代通用发布清单。

Worktree、子 Agent、并行 Agent、架构优化和复杂诊断，都只在任务真的需要时使用。它们不是每个功能的固定仪式。

自动调用也要分类型

可以把 Skills 分成两类：

护栏型 Skills用于防止明显质量问题，例如 systematic-debugging 和 verification-before-completion，可以允许按需自动触发。

编排型 Skills会改变整个工作方式，例如 brainstorming、writing-plans、using-git-worktrees、test-driven-development 和多 Agent 开发，更适合手动调用。

希望保留手动调用、禁止隐式触发时，可以在对应 Skill 的 agents/openai.yaml 中设置：

policy:
  allow_implicit_invocation: false

如果某个 Skill 完全不需要，再在 Codex 配置中将它禁用。关键不是一刀切地禁止所有 Skills，而是避免让编排型 Skill 在不合适的阶段接管任务。

最后的极简版本

新项目只执行一次：

问题定义
→ 产品规格
→ 静态原型
→ 用户验证
→ 冻结 MVP
→ 最小技术设计
→ 第一条垂直闭环

每个功能重复：

轻量规格
→ 小步实现和测试
→ 独立 AI 审查
→ 人工验收
→ CI 合并

每次发布重复：

Staging
→ E2E
→ 人工批准
→ 备份和部署
→ Smoke Test
→ 监控

整套方法最终只剩下一条纪律：

产品探索阶段不讨论实现；静态原型阶段不建设生产架构；工程阶段不随意增加需求；发布阶段不绕过验证、备份和回滚。