💡阅读指南

你有一个模糊的想法:想做一个知识管理系统,想做一个视频生成工具,想做一个热点追踪系统。 但模糊的想法和能运行的项目之间,有很长一段路要走。

这一节把整条路画出来给你看:一共五个阶段,从想法到项目。 先看到全貌,再逐个看这些阶段内部的动作,你就不会迷路。

2.1 一张图看完全程

从模糊想法到 Shell 项目,功能开发的主线一共五个阶段。第二阶段和第三阶段里面,还各自包含几个具体动作。

code
模糊想法
   ↓
需求:需求澄清 → 需求简报
   ↓
SPEC:规范生成 → 初版 SPEC → 二次澄清
   ↓
Agent 开发:plan → tasks → implement → converge
   ↓
  部署上线

这五个阶段构成了 Shell Engineering 从 0 到 1 的功能开发主链条。

后面几节我们会一步步展开,但先记住这张图——它是这一章的骨架,之后每个细节都能在这张图上找到位置。

2.2 五个阶段之上,还有一层项目宪章

上面这张图,画的是一个功能从想法到交付的主线。但一个项目并不是每做一个功能,就重新从空白开始。有些原则一旦定下来,后面所有功能都要遵守,不能让 Agent 每次重新决定。

比如胶囊系统里的资料必须能对照原始资料(证据),Hermes 负责理解和判断,飞书负责保存和展示。这些不是某一个功能的临时需求,而是整个项目的长期边界。今天做内容入库要遵守,以后做主题演化、搜索和问答,也不能违反。

在这套方法里,我们可以把这类项目级的长期规则称为项目宪章。它回答的不是“这次要做什么功能”,而是整个项目以后必须一直遵守什么。它可以规定系统的职责边界、数据原则、测试要求、安全约束和开发流程。

所以项目宪章不是另一份功能 SPEC。可以先这样理解:

文档 它回答的问题 生效范围
项目宪章 整个项目长期必须遵守什么 所有功能和开发阶段
需求简报 用户遇到了什么问题、第一版要做什么 当前产品或功能
SPEC 当前功能做成什么样才算对 当前功能
技术方案 当前功能用什么方法实现 当前功能的实现阶段

因为宪章管的是整个项目,所以它不是五个阶段后面的“第六个阶段”,而是压在后续开发上方的一层约束:

Text
项目宪章(长期原则)
        ↓ 约束
SPEC → plan → tasks → implement → converge

一个新项目开始开发时,通常先把宪章定下来,再开始写第一个功能 SPEC。后面每增加一个功能,Agent 都应该先检查新的规范和方案是否违反宪章。只有项目的长期原则真的发生变化时,才需要修订宪章本身。

2.3 五个阶段里,哪两个最值得讨论

现在把这五个阶段展开看看。

第一阶段,模糊想法。你脑子里有一个念头——想做点什么东西。这一阶段不需要学,你已经有想法了。

第二阶段,需求。模糊的想法往往不能用来做开发,还需要进一步把模糊的想法变成需求。这一阶段你完全可以自己凭借经验来编写,但更推荐先用问答式的需求访谈来帮助自己整理需求,再把问答整理成一份简短的需求简报。而常用的问答式工具是grill-me ,我们在后面会讨论这个工具。

第三阶段,SPEC 文档。把需求简报整理成初版 SPEC,再对初版 SPEC 做二次澄清,最后得到一份精确、可验证的规范:数据模型、业务规则、验收场景。11.4 会讲清楚这一步的通用方法。

第四阶段,交给 Agent 开发。SPEC 写好了,交给 Agent。它自己出技术方案、拆任务、写代码。你不需要操心怎么实现,只需要审批。

第五阶段,部署上线。项目做完了,部署到 Hermes 上运行。

这五个阶段里真正需要你学的东西其实很少。真正值得研究的,就是第二阶段和第三阶段——把模糊想法变成需求,再把需求变成 SPEC。

尤其是第三阶段,从需求到 SPEC。这是 SDD(规范驱动开发)的核心,也是大多数人做错的地方。

2.4 难点在哪里

很多人做 Shell 项目,第一步就急着让 Agent 开始写代码。想法刚有一个轮廓,就告诉 Agent:帮我写一个什么东西。

我举个例子。你想做一个"每天自动汇总 AI 新闻发给我的工具"。这个想法本身很明确,你告诉 Hermes:帮我写一个每天抓取 AI 新闻并发送邮件的工具。

Agent 收到指令,开始自己猜。

它猜你早上 9 点想看,于是设了定时任务。它猜你想看英文新闻,于是抓了 TechCrunch 的 RSS。它猜你关心大模型,于是加了关键词过滤。它猜你习惯用 Gmail,于是接上了 SMTP 服务。

一段时间后,Agent 把做好的东西交给你。

你打开一看,问题来了。你下午 2 点才有空看新闻,它在 9 点就发了。你只关心中文来源,它抓的全是英文。你不需要过滤,你想看的是技术论文更新,不是产业新闻。你用的是 QQ 邮箱,不是 Gmail。

Agent 不是故意的。它只是按自己的理解替你做决定。你给它的指令太模糊,它只能从指令里提取它认为合理的默认值。你也没有告诉它不要这样做,它当然不知道自己在猜。

反过来,如果你在写 SPEC 这一步多花一点时间,把需求说清楚,后面就完全不一样了。

SPEC 写清楚了,Agent 不用脑补乱猜,直接照着做;验收场景也为后续检查提供了明确依据。你不需要再凭感觉判断代码像不像,但仍然要确认交付物是否符合这些场景。

这就是 SDD 的价值:把精力花在写规范上,而不是花在返工上。

💡Prompt 和 SPEC 的区别

很多同学问我,Prompt 和 SPEC 有什么区别。我认为它们不是同一个层面的东西。从广义上讲,SPEC 本质上也属于一种 Prompt——你可以把 SPEC 理解成"被写得很严谨的 Prompt"。但从狭义上讲,我们平时说的 Prompt 更随意,可能是一段口头描述,不需要太规范。做小东西可以这么来,但要做工程化的严谨项目,就得把 Prompt 逐步细化、完善、约束,写得非常详细才能交给 Agent 去开发——这就是 SPEC。

2.5 ■ 学点英语

中文 English 音标 说明
规格说明 SPEC /spek/ 把功能的正确行为和验收依据写清楚的规范
简易信息聚合 RSS /ˌɑːr es ˈes/ 让网站以订阅源形式持续发布内容更新的格式
简单邮件传输协议 SMTP /ˌes em tiː ˈpiː/ 负责在邮件服务器之间发送邮件的标准协议