Spec-driven development 这个概念的拥护者不少, 但真正落地时常常遇到同一个尴尬: 规格文档往往是工程师在写代码前临时敲出来的, 其他人要么没看见, 要么看见了也没法参与。更常见的情况是, 规格写完之后就躺在文档库里, 和最终代码完全脱节。Penling 想把这个流程彻底翻转过来。
Penling 是一个 agentic spec-driven workflow 工具, 核心思路是"先写规格, 再写代码"。它把规格文档从 CLI 和单个工程师的键盘上拿出来, 放到一个团队共享的工作区。产品经理、设计师、技术负责人和工程师都可以在这个空间里共同定义"究竟要构建什么", 而这些讨论的结果会作为后续代码生成的依据。也就是说, 在 Penling 里,"规不规格"不是某个人拍脑袋, 而是整个团队的集体共识。
官网列出了三个支柱, 基本可以当作产品理念来看:
- Specified — 规格由团队共同写下, 而不是某个人独自完成;
- Shared — 每个角色、每个决策都在共享空间里流转;
- Traceable — 从最初目标到合并后的 PR, 整个过程可追溯。
这三点的价值很容易被低估。很多团队不是没有规格, 而是规格和代码经常脱节。Penling 试图把规格变成活文档, 让 AI 在编码阶段直接参考团队共识, 同时把推理过程保留下来。对远程办公或者异步协作的团队来说, 这种透明度尤其有意义——不再是事后补写文档, 而是文档本身就参与构建。
一个更重视协作的 AI 开发流程
和市面上大多数 AI 编程工具相比, Penling 的切入点不太一样。那些工具通常假设你已经知道要写什么, 然后帮你补全代码; Penling 则希望大家在写任何代码之前, 先通过结构化目标和共享上下文达成一致。这种模式更接近产品评审, 而不是程序员日常的代码补全。它把"写代码"这件事从个人行为变成了团队行为。
从公开信息看, Penling 目前处于 v0.14.2, 提供 14 天免费试用, 无需绑定信用卡, 而且可以通过 Google、Microsoft 或 GitHub 账号快速登录。如果你所在团队经常在"需求到底是什么意思"上拉扯, 或者希望减少后期返工, 这套工作流值得试一下。
适合谁, 又有什么限制
典型的使用场景是: 一个团队在项目启动时, 用 Penling 定义结构化目标, 所有相关角色都能看到并编辑规格, 然后 AI 根据规格生成代码, 最终输出一个附带完整构建说明的可评审 PR。这个过程把"写规范"和"写代码"绑定在一起, 也把责任分摊给了整个团队。
当然, 它也不是万能药。Penling 要求团队接受一种新的工作方式, 对于几个人快速试想法的原型项目, 可能显得有点重。另外, 官方公开的技术细节不多, 比如 AI 具体使用什么模型、支持哪些代码托管平台的深度集成, 都没有在页面上说明, 建议在实际使用前先关注这些问题。
如果你们团队正在寻找一种让所有人都能参与产品决策的 AI 开发工具, Penling 算是目前思路比较清晰的一个。它不一定适合所有项目, 但至少把"规格"重新放回了开发流程的核心位置。
评论
暂无评论
成为第一个评论的人