​ 最近我在尝试一套更“顺手”的新项目启动方式： 不是 先闷头建目录、搭脚手架、写 README 而是 全程让 AI 先参与需求整理、方案拆分、代码落地和后续补全。

使用工具

1. OpenSpec：把模糊的需求拆解成清晰的任务

链接：https://github.com/Fission-AI/OpenSpec OpenSpec是一款基于SPEC范式的、轻量的代码提示词辅助工具，帮助你优化提示词，更精准的表述代码编写意图

核心思想：把原来“一句话”就要AI干的活儿，细化成“四个文档”。以此提高AI代码编写质量，主要有如下四个文档：

• proposal：为什么要做
• specs：需求和场景
• design：技术设计
• tasks：具体实施清单

2. Codex CLI：真正的“落地入口”：

CLI相对IDE对话Agent有如下优势：

• 方便并发工作（同时开启多个终端界面工作）
• 直接执行命令行并清晰可见
• 生态丰富，各种CLI插件/工具适配

面向文档的开发两个核心

1. 面向文档编程 (Documentation-Oriented Programming)

这种范式主张文档即代码，文档领先于代码。

核心理念

• Markdown 是AI时代的源代码。
• 编程的重点从“编写代码”到“编写需求文档”

关键实践

在项目根目录构建如下格式Markdown文件夹

README.md // 项目介绍
AGENTS.md //给所有AI编程工具读的项目概览、参考书。
.codex(以codex为例)
 - rules //给AI设定的“电子围栏”和“宏命令”
docs
 - requirements //需求文档
   - archive //需求归档
   - requirename-date //需求名+日期的需求，完成需求后文件放入archive归档
      - require.md //需求具体描述
	  - test.md //测试用例、描述文档 
 - PRD.md   // 产品宏观描述，最终形态
 - CURRENT.md  // 产品当前描述，现状
 - ARCHITETUCTURE.md  // 产品架构
 - API.md  //当前项目API文档

---

2. 面向测试编程 (Test-Oriented Programming)

这是目前主流开发中保证质量的核心，最典型的代表是 TDD (测试驱动开发)。

核心范式：TDD (Test-Driven Development)

TDD 遵循一个严谨的循环：红 -> 绿 -> 重构。

1. 红 (Red)： 编写一个必将失败的测试用例（因为功能还没实现）。
2. 绿 (Green)： 编写最少量的代码让测试通过。
3. 重构 (Refactor)： 在测试保护下，优化代码结构，消除冗余，保持功能不变。

核心步骤

1. 根据PRD\CURRENT\ARCHITETUCTURE\API\AGENTS生成requirename-date文件夹，里面有具体的需求描述require和测试目标test
2. 执行opsx-propose并携带requirename-date文件夹作为需求描述，生成propose.md、task.md、design.md、spec.md
3. 执行opsx-apply执行代码生成，并依据requirename-date下的test.md进行测试
4. 归档requirename-date下的需求