两者的共同点。
Tessl 做得好的地方。
Tessl 有两处很容易混在一起。下面的说明把它们分开，依据是 2026年10月30日读过的页面。
把“规格即源头”讲清楚了
Simon Maple 在 2025年6月27日的文章说，产品需求文档（PRD）——写给人看、说明要构建什么的散文——通常会过时，代码反而成了唯一的事实来源。文章给出的另一条路是：你改的是规格，由大语言模型生成代码、测试和文档。这是一个认真的立场，不是口号。
给代理准备上下文的平台
Tessl 的文档描述了注册表、会扫描技能并给技能打分的治理、评测，以及跨代理的可观测性。文档说技能就是你仓库里的普通产物，平台可以配合 Claude Code、Cursor、Copilot、Gemini 等使用。那里的打分，打的是技能，不是产品规格。
官方的规范驱动 tile，带 shell 检查
tessl-labs/spec-driven-development 这个 tile，在公开的 tile 仓库里以 MIT 许可发布。它教代理先访谈、写出 .spec.md 文件、等批准，然后再实现。注册表页面列出了 scripts/validate-specs.sh 和 scripts/check-spec-links.sh，用来检查前置元数据、targets 以及 [@test] 链接。同一页说，这个 tile 是引导用的上下文：没有专用命令，也没有框架。
功能对比。
“规格即源头”是 Tessl 的文章。tile 是叠在今天这套平台上的技能包。SpecScore 是带版本号的检查器所检查的格式。
| 能力 | Tessl | SpecScore |
|---|---|---|
| 主要角色 | 智能体技能平台，外加一个规范驱动的 tile，以及 2025 年一篇谈规格即源头的文章 | 开放的规格格式 + CLI |
| 规格是什么 | 文章：那份长期留下的源头，代码由它生成。tile：一份 .spec.md，代理对照它来实现，代码仍由你留着。 | 放在代码旁边的契约。检查不会重新生成代码。 |
| 规格的形状 | tile：YAML 前置元数据、targets 通配符，以及指向测试文件的 [@test] 链接 | Markdown + YAML、REQ: slug、给定/当/那么 |
| 如何检查规格 | 随 tile 一起提供的 shell 脚本，只检查这个 tile 自己的前置元数据和链接 | specscore spec lint，针对 SpecScore 格式，跑在本仓库的 CI 里。/score 是手动的 AI 评分。 |
| 许可证 | 这个 tile 是 MIT。平台是一项产品。文档没有公布平台的源代码。 | CC BY 4.0 格式 · Apache-2.0 CLI |
| 价格 | 2026年10月30日读过的Tessl 主页写明：有免费档（一个工作区每月 1,000 点额度），也有付费的企业方案。 | 不收费，格式和 CLI 都如此 |
SpecScore 增添了什么。
发布的是格式，不是 tile 的脚本
tile 的 shell 脚本检查的是这个 tile 让代理去写的 .spec.md 文件。SpecScore 检查的是本站写明的格式。dogfood.yml 会安装一个钉住版本的 specscore 发行版，并运行 specscore spec lint。/score 不是这项作业：它是一项手动技能，AI 评审报出问题时以非零状态退出。
$ specscore spec lint features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds features/apply-discount/refunds:0 [error] readme-exists: README.md not found 3 violations found (3 errors)
代码两边都还在你手里——文章走得更远
2025 年的文章认为，代码应当从规格重新生成。2026年10月30日读到的 tile 页面，是让代理对照一份已批准的规格去实现，并没有描述一个会换掉你源码树的编译器。SpecScore 从不把代码拿走。规格是审过的契约；代码仍归你。
需求有自己的名字
tile 用 targets 和 [@test] 把一条需求指向文件。SpecScore 把需求命名为 REQ: slug，这样计划、任务和提交尾注在文件挪走之后仍能引用它。
何时使用哪个。
更适合用 Tessl 的时候……
- 你需要注册表、评测和治理，用来管理许多代理和许多仓库一起共用的技能。
- 你想把“规格即源头”那篇文章里的工作流做成一块引导 tile：先访谈，批准一份 .spec.md，然后再实现。
- 你已经在付费使用或试用 Tessl 平台，并希望它的规格 tile 就放在那个注册表里。
以下场景适合使用 SpecScore……
- 规格格式本身必须在 CI 里有效，包括那些不安装 Tessl 的仓库。
- 你要需求标识，以及一个不会去调用模型的检查器。
- 你希望这份格式开源，用的是知识共享许可，并且和技能平台分开。
规格可以当源头，也可以被检查。
Tessl 的文章说得对：过时的 PRD 比不过代码。格式检查，是让规格继续成为你信任的那份东西的办法。SpecScore 不会从规格生成你的应用。结构、链接或状态不对时，它会让规格在 CI 里失败。
要平台和 tile，就用 Tessl。拉取请求必须证明的是 git 里的那份产物，就用 SpecScore。
来源。
下方公开页面阅读于 2026 年 10 月 30 日。价格、方案名称和发布线会变化。
反馈
本对比基于公开可用的文档和源代码。发现不准确或过时的信息？请 提交勘误 issue. 希望我们将 SpecScore 与其他工具进行对比？请 提交请求.