案例实践5 – 从0到1开发项目
本实践介绍如何用 CoStrict 从一个项目想法出发，完成需求梳理、系统设计、任务拆分、代码生成和调试验证。适合用于新项目启动、原型开发、课程项目、内部工具开发等场景。
示例项目：论文管理系统
目标能力：论文上传、自动分类、全文检索、团队协作
1. 适用场景
当你遇到以下情况时，可以优先使用 Spec 模式启动 0-1 开发：
- 只有一个项目想法，还没有完整设计
- 需要 AI 帮你梳理需求、设计架构、拆分任务
- 项目包含多个模块，不适合直接一句话生成代码
- 希望先形成规划文档，再逐步执行开发
如果只是修改几行代码，建议使用 Vibe 模式；如果是在已有项目中新增一个功能，建议使用 Plan 模式。
2. 模型与模式选择
模型选择
0-1 项目开发涉及需求理解、多 Agent 协作、代码生成和上下文管理，建议选择综合能力较强的模型，例如 GLM5.1 或其他在复杂任务规划、代码生成方面表现稳定的模型。
模式选择
| 模式 | 适用场景 | 预计耗时 | 说明 |
|---|---|---|---|
| Vibe | 代码微调、即时调试、小修改 | 约 10 分钟 | 适合快速修复明确问题 |
| Plan | 实现或改造一个小功能 | 约 30 分钟 | 适合已有项目中的功能级调整 |
| Spec | 从 0-1 规划新项目 | 视项目规模而定 | 适合需求、设计、任务拆分都需要系统规划的场景 |
简单判断：
改几行代码 → Vibe
改一个功能 → Plan
从零做项目 → Spec
3. 0-1 开发流程
步骤 1：准备项目输入
建议先准备以下材料：
- 需求文档：说明项目要解决什么问题、有哪些功能
- 技术栈文档：说明前端、后端、数据库等技术选择
- 架构文档：说明模块关系、接口约束、数据模型等
- 参考资料：原型图、表格、历史项目说明、聊天记录整理稿等
如果原始资料是 Word、Excel 或聊天记录，建议先整理成 Markdown，方便 CoStrict 读取和引用。
示例：
@需求文档.md @技术栈文档.md @架构文档.md
请基于这些文档，帮我设计一个论文管理系统。
系统需要支持论文上传、自动分类、全文检索和团队协作。
请先完成需求分析、技术设计和任务拆分，不要直接写代码。
如果暂时没有正式文档，也可以先用一句话描述：
我想做一个论文管理系统，支持论文上传、自动分类、全文检索和团队协作。
请先帮我梳理需求、设计系统架构，并拆分开发任务。
步骤 2：使用 Spec 模式生成规划文档
切换到 Spec 模式后，让 CoStrict 先完成项目规划。
Spec 模式通常会生成三份核心文档：
| 文档 | 内容 | 对应 Agent |
|---|---|---|
| requirements.md | 需求定义 | Requirements Agent |
| design.md | 技术设计方案 | Design Agent |
| tasks.md | 任务拆分与规划 | Task Agent |
这一步的目标不是马上写代码，而是先让项目结构清晰下来。
步骤 3：检查并调整规划文档
生成规划文档后，建议先检查三件事：
-
requirements.md 是否准确
- 功能是否完整？
- 是否有不需要的功能？
- 是否遗漏异常场景？
-
design.md 是否合理
- 技术栈是否符合预期？
- 数据库设计是否完整？
- API、模块关系是否清楚？
-
tasks.md 是否可执行
- 任务是否拆得太大？
- 是否能按顺序逐个开发？
- 每个任务是否有明确产出？
如需调整，可以直接修改文档，也可以继续让对应 Agent 辅助修改。
示例：
请帮我补充论文分类模块的需求边界，重点说明自动分类失败时的处理方式。
请调整 design.md 中的数据库设计，增加论文标签、上传人和团队权限字段。
请重新拆分 tasks.md，把论文上传、全文检索和团队协作拆成可独立开发和验证的任务。
步骤 4：按 tasks.md 执行开发
规划确认后，打开 tasks.md，按任务顺序逐个执行开发。
推荐开发节奏：
| 策略 | 做法 | 适用场景 |
|---|---|---|
| 逐个开发调试 | 开发一个功能 → 调试一个功能 → 再开发下一个 | 新项目、功能依赖较多 |
| 批量开发后调试 | 一次性生成多个功能，最后统一调试 | 功能相对独立、想快速看到整体框架 |
对于 0-1 项目，建议优先选择 逐个开发调试。这样更容易定位问题，也能避免一次性生成大量代码后难以排查。
示例顺序：
- 先完成基础项目结构
- 再完成论文上传模块
- 再完成论文分类模块
- 再完成全文检索模块
- 最后补充团队协作、权限、页面优化等功能
步骤 5：运行项目并调试
代码生成后，需要启动项目并检查功能是否符合预期。
调试时可以根据问题类型选择不同模式：
| 问题类型 | 推荐模式 | 处理方式 |
|---|---|---|
| 报错明确的小问题 | Vibe | 直接粘贴报错，让 AI 修复 |
| 功能实现和预期差距较大 | Plan | 重新规划该功能并补充开发 |
| 前端页面或交互问题 | Vibe + Playwright / MCP | 让 AI 辅助检查页面和交互 |
示例：
项目启动后出现以下报错，请帮我分析原因并修复。
要求：只修改必要文件，不要重构整体项目结构。
当前论文上传页面布局不够清晰，请在不改变现有接口逻辑的前提下，优化页面结构和表单交互。
4. 实践效果
通过本次实践，CoStrict 在 0-1 项目开发中主要发挥了四类作用：
| 能力 | 具体表现 |
|---|---|
| 需求结构化 | 将一句话想法整理成明确的功能需求 |
| 系统设计 | 自动生成技术方案、模块设计、数据模型和接口设计 |
| 任务拆分 | 将复杂项目拆成可逐步执行的开发任务 |
| 开发调试 | 支持代码生成、问题修复、功能补充和页面优化 |
对于新项目来说，CoStrict 的价值不只是“生成代码”，而是帮助开发者把项目从想法推进到可执行计划，再从计划推进到可运行代码。
5. 使用建议
1. 不要一开始就让 AI 写完整项目
0-1 项目最容易出问题的地方不是代码，而是需求和设计不清楚。建议先用 Spec 模式完成规划，再进入开发。
2. 文档输入越清晰，生成结果越稳定
尽量把需求、技术栈、业务规则、接口约束整理成 Markdown。输入越明确，AI 生成的结构越可控。
3. 优先逐个任务开发和验证
新项目不要盲目批量生成全部功能。建议每完成一个任务就运行一次、检查一次、修复一次。
4. 开发者仍然需要审查关键结果
AI 可以辅助生成需求、设计和代码，但数据库设计、权限逻辑、异常处理、业务规则等关键内容仍需要人工确认。
5. 灵活切换不同模式
- 用 Spec 做项目规划
- 用 Plan 做功能补充
- 用 Vibe 做快速调试
根据任务阶段切换模式，比全程使用单一模式更稳定。
6. 总结
对于复杂项目，AI 不应被当成“一次性生成完整项目”的工具，而应被当成一个可以持续协作的开发助手。先规划、再执行、再验证，才能更稳定地完成从想法到可运行项目的开发过程。
推荐使用路径：
准备 Markdown 文档
↓
Spec 模式生成 requirements / design / tasks
↓
检查并调整规划文档
↓
按 tasks.md 逐个执行开发
↓
使用 Vibe / Plan 调试和补充功能