对 ODC 而言，最优的方法是“轻量 TDD + 规范驱动（Spec-Driven）的组合”，因为它在单人有限时间内以最低的认知负担锁定了核心逻辑的可维护性，同时利用 AI 快速生成样板，使得抛弃失败方向与长期演化同样安全。

1. 方法筛选与理由

完全不适合 ODC 的方法

方法	理由
经典 TDD	强迫所有代码（UI、胶水、配置）先写测试，导致测试维护成本超出单人承受范围；开发节奏下降 40% 以上，且无法像团队那样互相审查测试质量。
BDD / ATDD	Gherkin 场景、验收测试框架（如 Cucumber）的编写和执行开销过大；一人公司通常没有专职 BA 或 QA，维护行为定义与代码同步的成本远高于收益。
PDD（提示词驱动）	.prompt 文件作为源码 → 生成代码如同黑盒，3 个月后无法理解、无法安全修改；AI 幻觉导致的逻辑漏洞难以追踪。仅可用于一次性原型。
Vibe Coding	没有可复现的构造过程，代码完全依赖“手感”；修改时等于重写，认知负担无限大，生产事故率极高，完全不适用于需要长期维护的产品。
完整 TPDD（测试计划驱动）	编写完整测试计划、测试用例矩阵过于重量级，对单人属于过度工程。

最适合 ODC 的方法（组合）

推荐组合：轻量 TDD + Spec-Driven Development（规范驱动） + 主动防御（取自 TPDD 的“禁止空间”概念）

理由	对应 ODC 约束
轻量 TDD：仅为核心业务逻辑、算法、数据验证编写单元测试。不测试 UI 事件、不测试框架胶水、不测试纯 getter/setter。	维护成本低、快速捕捉关键回归；3 个月后仍敢修改核心模块。
Spec-Driven：用结构化规范（TypeScript 类型、OpenAPI、Protocol Buffers、JSON Schema）直接定义输入/输出和状态机。规范即“可执行文档”，AI 可据此生成代码。	减少沟通歧义、降低认知负担；规范作为单一事实源，支持快速抛弃（改规范即可）。
主动防御（禁止空间）：预先列出“永远不允许做的事”（如：不允许吞掉异常、不允许在循环中调用外部 API、不允许使用 any 类型），并通过 lint/测试自动检查。	防止低级技术债，弥补无人审查的缺口。

对于 纯 SaaS 无 AI 与 AI Agent 产品：上述组合通用。但当产品内含概率性模块（推荐、LLM 调用）时，额外加入 EDD（评估驱动开发） 的轻量变体：定义 1~3 个核心指标（如准确率、延迟 p95）和阈值，每次改动后运行评估（可本地小样本），阈值不通过则拒绝合并。

---

2. 最优方法的操作定义

操作流程（实现一个功能的 6 步）

以“用户注册时邮箱唯一性校验”为例：

步骤	人类（ODC 创始人）	AI 辅助	是否必须人工介入
1. 写规范（Spec）	用 TypeScript 定义 register(req: {email: string}) 的输入/输出类型和错误码；在注释中写明“邮箱已存在时返回 409”。	无（或 AI 补全格式）	✅ 人工（定义业务边界）
2. 定义“禁止空间”	在本功能上加一条：禁止直接对数据库抛出的唯一约束异常不做 catch。写入 .cursorrules 或 lint 配置。	无	✅ 人工
3. 编写核心单元测试（轻量 TDD）	写 2~3 个测试用例：正常注册、重复邮箱、邮箱格式非法。不写数据库连接、HTTP 层的测试。	AI 可辅助生成测试模板，但断言逻辑需人工确认。	⚠️ 人工确认断言
4. AI 生成核心代码	将规范 + 测试文件作为上下文，让 AI 实现 register 函数（纯逻辑，不涉及框架）。	生成代码、错误处理、日志占位符。	❌ AI 做，但需下一步审查
5. 人工审查与集成	检查 AI 生成的代码：是否符合规范、是否触发“禁止空间”、测试是否通过。然后手动粘接到框架路由中。	无	✅ 人工（集成与审查）
6. 提交与 CI	git commit 触发 GitHub Actions：运行核心单元测试 + 类型检查 + lint（含禁止空间规则）。通过则合并。	自动执行	❌ CI 自动

每个功能迭代重复以上 6 步。抛弃失败方向时，直接删除对应的规范、测试、代码文件即可，零残留。

人类必须做的三件事（不可交给 AI）

1. 定义规范边界：输入/输出类型、错误码、状态机（AI 无法代替你对业务的理解）。
2. 编写核心测试的“预期结果”：断言什么值正确，必须由人决定。
3. 集成与部署：将 AI 生成的安全代码块手动组装到主程序中，并负责环境配置。

---

3. 成本与收益估算

对比基准：「纯 Vibe Coding」—— 无测试、无规范、完全依赖自然语言驱动编码。

维度	本方法 vs Vibe Coding	定量估计
开发初期速度	慢 20~30%	因为需要写规范+少量测试，但 AI 生成代码后补回部分时间。
3 个月后维护成本	降低 60~70%	规范即文档，核心测试保回归；无需通读整个代码库就能安全修改。
严重生产 bug 概率	降低约 80%	核心逻辑被测试覆盖；禁止空间阻止低级错误（如吞异常、无限循环）。
抛弃失败方向的成本	降低 90%	只需删除规范、测试、代码文件，无隐藏耦合（因规范强制解耦）。

定性成本-收益权衡表

场景	收益	成本（额外时间）	推荐
核心业务逻辑（支付、权限、计费）	极高（避免破产级 bug）	中（写测试 +20% 时间）	✅ 强制使用
数据模型与 API 契约	高（避免前后端不一致）	低（写 TypeScript/OpenAPI 比写代码快）	✅ 强制使用
UI 事件/胶水代码（如按钮点击后调 API）	低（bug 易发现、易修）	中（写测试收益低）	❌ 不写测试，仅靠类型检查
第三方集成（Webhook 解析）	中（解析错误会导致数据丢失）	低（只对解析函数写 1~2 个测试）	⚠️ 可选
一次性管理脚本（数据迁移）	低（用完即弃）	低（可跳过测试）	❌ 豁免

---

4. 风险与护栏

最可能失败的原因

1. 纪律崩塌：赶时间时跳过“写规范/测试”步骤，直接让 AI 生成代码并提交 → 迅速积累技术债。
2. 测试膨胀：不自觉给所有代码（含 UI、框架）写测试，维护成本超载 → 放弃方法。
3. AI 幻觉：AI 生成的代码虽通过测试，但存在未发现的逻辑漏洞（如竞态条件）。

强制性护栏规则（5 条，每条 ≤20 字）

1. 核心逻辑无测试，禁止合并主分支（可通过 CI 强制）。
2. 每个功能先写类型规范，再写代码（用 interface 锁定契约）。
3. 禁止让 AI 生成数据库事务、锁、并发代码 – 人工撰写。
4. 每周重构一次：删除未使用的规范/测试/代码。
5. 任何 AI 生成的函数行数 >30 行，必须人工拆分。

---

5. 工具链推荐（低成本/免费）

用途	推荐工具	成本	备注
IDE	VS Code + Cursor（免费版）/ Continue（开源）	免费或 $0~20/月	Continue + 本地 Ollama 完全免费
类型/规范	TypeScript（前端/Node）、Pydantic（Python）、OpenAPI 3.0	免费	规范即代码
轻量单元测试	Vitest（JS/TS）、pytest（Python）	免费	只测核心逻辑，不测框架
禁止空间检查	ESLint + 自定义规则、Pyright（strict 模式）	免费	配置 no-explicit-any、no-throw-literal 等
CI	GitHub Actions（免费 2000 分钟/月）	免费	跑测试 + lint + 类型检查
AI 代码生成	Copilot（$10/月）或 Codeium（免费）	$0~10	优先选免费，足以完成 80% 样板
评估（EDD）	自定义脚本 + 本地小样本数据集（JSON）	免费	仅当产品含 AI/概率模块时使用

---

项目类型补充说明

• 纯 SaaS 无 AI：使用上述组合即可，无需 EDD。重点放在 Spec-Driven（API 规范）和 轻量 TDD（计费、权限、积分等规则）。
• AI Agent 产品（如 LLM 调用链）：额外加入 EDD 轻量变体：为每个 prompt 模板定义 2 个指标（成功率、平均 token 数），本地跑 20 条样本，超过阈值则 alert。不强制自动化回归（成本高），但每次改 prompt 后手动跑一次。