Enso Method 发布 20+ 开源 Agent 技能，面向 Claude Code 与 Codex

适用于 Claude Code 和 Codex 的开源智能体技能

清晰的需求输入。经过测试的软件输出。

Enso Method 是一种用 AI 编程智能体构建生产软件的方法，以及实现它的各项技能。它从需求开始：你用平实的语言说出你想要什么，悬而未决的问题会在一开始就得到解答，然后智能体开始构建，而你的注意力可以转向别处。

告诉 AI 你想要什么，而不是让它做什么。

• 20+ 项技能，从想法到生产
• Claude Code 和 Codex
• 每日精进，基于生产客户项目
• 免费且开源

问题所在

凡是你不告诉 AI 的，它都会去猜。

AI 现在编写了大部分代码，而它通常都是这样开始的：在对话里说上一两句话，然后看它返回什么。有时候猜得不错。猜得不对时，你得到的软件能运行，但没人真正想构建它。

01

每一处空白都会被猜测填补。

“给结账加上退款”留下了真正的问题。部分退款？商店积分？如果支付服务商宕机了怎么办？智能体自己回答了每一个问题，却不告诉你，而你之后才发现哪些答案是错的。

02

一分钟一分钟地操控它。

接着就是各种修正：做这个，现在修那个，不，不是那样。你在告诉它做什么，而不是你想要什么，所以你无法抽身，而智能体也永远看不到全貌。

03

没人能解释的代码。

一个月后出了问题，有人问它本该做什么。代码说不出来，下一个 AI 会话也说不出来。没有把意图写下来，修复就只是又一次猜测。

解决办法不是更好的提示词。而是在构建之前先思考：让利益相关者能读懂的需求、一份设计，以及每一个悬而未决的问题都得到解答或作为假设记录下来。然后智能体一路构建下去，一个阶段接一个阶段，而你的注意力回到只有你才能做的决策上。

方法

六个理念，一种纪律。

技能是这套方法运转的方式。以下是它所信奉的理念，无论哪项技能在干活，它们都成立。

1. 一

   需求引领构建。

   工作从一份 PRD 和一份技术设计开始，任何有意义的变更都会在构建之前先修订它们。小修复仍然会直接在代码里进行，一如既往，但意图始终被写下来，所以每个新会话都从已决定的内容开始，而不是对代码的猜测。

2. 二

   假设就是绿灯。

   当出现业务问题时，智能体去研究它，提出一个答案，连同其置信度写入假设文档，然后继续构建。利益相关者按自己的节奏确认或纠正。什么都不等待。

3. 三

   去研究，别去问。

   技术问题都对照真实的代码、数据和 API 来回答。只有真正的业务决策才会交给人，而且它们以提案的形式出现，从不是悬而未决的问题。

4. 四

   要结果，不要指令。

   描述结果，而不是步骤。该方法将其转化为验收标准、设计和计划， 因此智能体基于意图工作，而不是一连串指令，并且能在你最初的想法 是解决问题的错误方向时告诉你。

5. 五

   小步推进，而非半成品。

   没有智能体能一次性构建整个系统，因此大型工作沿着自然的接缝切分成薄的 垂直切片，每一片都小到足以在一次 AI 会话中完成，并且能独立运行。当一个阶段 比计划中更大时，就再次拆分。

6. 六

   每一条验收标准，都经过验证。

   在工作被宣布完成之前，PRD 中的每一条验收标准都会对照一个能检验它的测试进行核查， 在存在真实系统的地方对照真实系统，并且如果行为有误该测试就会失败。 完成意味着每一条验收标准都得到验证，而不是智能体说它完成了。

工作原理

从想法到生产，一条连续的线。

每一步都是你的智能体运行的一项技能。每一步都把一份可信的文档交给下一步， 而它们都不会停下来问文档已经回答的问题。

决定要构建什么

1. Roadmap prd-roadmap

   把一个大到无法用单份 PRD 容纳的想法，切分成一份有序的 PRD 路线图，每一份都以可交付的东西收尾。

2. Requirements prd-writing-standards

   一份用业务语言写成的 PRD，带有可测试的验收标准和明确的超出范围。

3. Design technical-design-writing-standards

   架构、接口、数据模型和集成点，遵循你的内部标准。

4. Refinement autonomous-requirements-refinement

   一遍又一遍，找出每一个缺口，研究答案并将它们融入文档。 设有检查点，因此它会恢复而不是重新开始。

分片构建它

1. Phasing phase-split

   把工作切分成可独立交付的阶段，每个阶段的大小适合一次 AI 会话。

2. Build implement-from-requirements

   加载每一份文档，评估工作量，构建一个阶段并对照真实资源进行测试。没有 人需要说明该读哪些文件。

3. Continue continuation-prompt

   把下一阶段交给一个全新的会话，它确切知道自己在服务于哪份 PRD 和哪个阶段。

证明它能工作

1. Review deliverable-review

   一个全新视角的智能体重新阅读每一个更改过的文件，并将每项需求追溯到输出。

2. Harden test-hardening

   把每一条验收标准映射到证据，并将模拟替换为真实的沙箱资源。

3. Commit pre-commit-validation

   在提交之前检查更改：只有本次工作的文件，没有机密，也没有其他 会话在此期间提交的任何内容。

整个流程，一步一步，以及每一项技能 →

变更请求变成一次 diff，而不是一次绕路。

当业务在项目中途改变主意时，变更从需求开始。需求被修订 并单独提交，构建基于该 diff 进行，因此变更是可审查的， 需求也能跟上实际构建的内容。

1. 1修订 PRD 和设计
2. 2单独提交修订
3. 3基于 diff 构建

假设登记册

利益相关者回答的是提案，而不是问题。

在开始构建任何东西之前，智能体会列出如果它今天来构建这个项目会有的所有问题， 并针对真实的代码、数据和 API 逐一研究。研究无法解决的问题会作为提案提交给相关方， 而绝不会是一个光秃秃的问题。

凡是它至少有 95% 把握的事情，它就直接决定，所以你永远不会被那些它自己能解决的问题淹没。 假设是绿灯，而不是阻碍：构建会立即基于它开始， 如果答案回来是否定的，它就会被写入需求，那部分工作会被重新构建。

研究是如何进行的

• 它在任何东西被实现之前运行。 autonomous-requirements-refinement 会找出 PRD 和技术 设计中尚未回答的每一个问题，然后在一个长会话中研究它们，把每个答案折回 需求中，这样在构建开始前一切都已理清。 implementation-readiness-check 会运行同样的检查一次，供你审阅。
• 技术问题：它会一直深挖到弄明白为止。它会与数据源对话，编写 针对 API 的临时测试程序，并尝试第三方组件和集成 点，直到得到它需要的答案。它们几乎从不变成假设。
• 业务问题：更精准的假设。研究无法决定业务 想要什么，但它可以提高所提答案的置信度：一个从 55% 开始的答案可能最终达到 85%， 这让相关方更容易回应。达到 95% 或以上时，它根本不会被声明。
• 当业务方给出答案时。确认会被记录下来。更正会写入 需求，基于它们构建的工作会被重新实现。只有当 证据完全不支持任何答案时，该方法才会停下来询问。

构建

提前决定。然后走开。

需求准备好后，phase-split 会把工作切成若干阶段，每个阶段都大到 有意义，又小到能让一次 Claude Code 或 Codex 会话可靠完成。一份大型 PRD 往往会变成 十几个这样的阶段。

用 implement-from-requirements 将你的智能体指向每个阶段，它就会构建、测试并关闭该阶段。决策在构建开始前就已做出，因此无需有人坐在聊天中做决定。 如果某个阶段比计划中更大，它会再次拆分，2 拆成 2a 和 2b，无需停下来询问。

内置于技能中

智能体不会做的事。

八条规则写入技能中，因此无需有人将它们输入聊天。每条规则都指明了承载它的技能。

越出范围。

implementation-lifecycle

在编辑计划未要求的文件之前，它必须指出需要该编辑的验收标准。“顺便改一下”不算数。当无人要求的编辑开始破坏下游时，它会撤销该编辑，而不是修复之后的一切。

在长聊天中丢失线索。

continuation-prompt implement-from-requirements

每个阶段都在一个全新的会话中开始，该会话自行加载 PRD、设计和阶段文档。在交接之前，下一个会话所需的任何内容都会写入这些文档，因此重要内容不会只存在于即将结束的聊天中。

拿不可逆的事情去赌一个猜测。

implementation-lifecycle engineering-principles

假设可以让构建继续，但绝不能是不可撤销的操作。收费、删除数据和写入生产环境都要等人来，无论智能体多么自信。它在开发环境和沙盒中构建，只有在没有其他方式能回答问题时才读取生产环境。

推翻你的利益相关者。

assumptions-document-writing

当新证据与利益相关者已经决定的事情相矛盾时，智能体会在其原始条目下重新开启该问题，将他们的裁决和证据并排放置。它绝不会为了迎合而修改他们的决定，检查该决定的测试会一直保持红色，直到他们再次裁决。

对一份精美的设计照单全收。

review-technical-design

一份 AI 撰写的设计无论对错都读起来很自信。对于包含难以逆转决策的设计，资深评审会先勾勒出自己的设计，对照真实代码和基础设施检查其承重主张，并为你指出最需要你判断的决策。

忽视你团队的构建方式。

engineering-principles

你仓库的智能体指令中有一行指明你团队的工程标准，它们会与方法自身的原则一起加载。在技术栈、风格、命名、配置和部署方面，你的标准优先。

在第一个可行的修复处停下。

engineering-principles

当修复需要新的锁、队列、重试或特殊模式时，它首先会问系统为什么需要这些。它会发布安全的修复，并将更深层的设计问题写入技术设计，而不是悄悄堆砌机制。

伪造通过的测试。

engineering-principles

在做出任何更改之前，先理解失败的测试，绝不通过削弱断言、跳过测试或硬编码答案来强行让它变绿。当数据或配置缺失时，代码会大声报错，而不是悄悄地在默认值上运行。

证据，而非声称

完成意味着已被证明。

智能体说自己完成了，这不算数。这些技能会在一个阶段被宣布完成之前检查工作，在整个 PRD 完成后再检查一次。

全新视角审查

deliverable-review

一个独立的智能体从磁盘重新读取每一个更改过的文件，并将每项需求追溯到实际构建的内容。当新工作未达到 PRD 要求时，修复的是工作本身；审查绝不会为了迁就代码而削减需求。

测试加固

test-hardening

每项验收标准都要有可信的证据。模拟对象被转换为真实的沙箱资源，薄弱的断言变成精确的断言，除非能说出它会捕获哪种失败，否则不添加任何测试。

测试审计

test-audit

一旦一个阶段或整个 PRD 完成，独立的审计会故意破坏代码，并观察哪些测试能发现。其审查者从 PRD 中获取标准，而不是从编写代码的智能体那里获取，并且会持续修复，直到每项标准都得到证明。

不留尾巴

implementation-lifecycle

会话注意到的每件事要么被驳回，要么现在就完成，要么归档到下一个会话能找到的地方。收尾报告说明的是已落地的东西，而不是留给你去梳理的一堆注意事项。

适用对象

适用于做决定的人并非坐在键盘前的人的情况。

大多数 AI 方法是为同时担任开发者和产品负责人的独立构建者编写的。这对副业项目有效。在客户和公司工作中，决策属于别人——客户、业务负责人、部门主管——而他们的时间很稀缺。Enso 方法让构建工作基于他们可以稍后确认或纠正的提案持续推进，并留下他们真正能读懂的文档。

工程负责人

给整个团队一种可以运行的方法，以及任何人都能读懂的文档，而不是十几种个人提示风格。

顾问和代理机构

在客户按自己的时间表回复的同时，让十几个构建项目同时推进，并交付自带需求和设计的系统。

改造现有系统的团队

为正在变化的部分编写需求，并只为差异部分编写设计：保留什么、复用什么、关闭什么，以及哪些行为绝不能改变。

为什么是 ensō

一笔。圆合。

在禅宗书法中，ensō 是一笔划出的圆。线条不能重描，圆合之时即为完成。这就是该方法要求每次会话遵循的纪律：审慎决定，毫不犹豫地行动，在宣布完成之前闭合回路。

如何比较

伟大的方法。不同的信念。

领先的 AI 开发方法，从 GitHub Spec Kit 这类规范驱动的工具包到 Superpowers 这类技能库，在它们各自设定的目标上都表现出色。它们大多解决同一个问题；分歧在于它们的信念：谁来做决定、提前规划多远，以及什么能证明工作已经完成。这正是 Enso Method 的立足之处。

横向滑动表格以查看每一列。

内置 部分 非重点 基于各项目已发布的技能和文档，2026 年 9 月和 10 月。

每种方法相信什么，以及 Enso Method 在哪里做出了不同选择 →

开始使用

安装它，然后三步到达你的第一个阶段。

安装技能

在 Claude Code 和 Codex 中，这些技能作为插件安装，会为每个技能命名 enso-method:<skill>，因此不会与其他任何地方的技能冲突。 不熟悉插件？看看它们在 Claude Code 和 Codex 中如何工作。其他 agent 通过 skills CLI 获得普通副本。要更新，或从仓库的克隆版本开始工作，请参阅 安装指南。

claude plugin marketplace add EnsoDynamics/enso-method
claude plugin install enso-method@enso-method

1. 编写 PRD

   在你的 agent 中，运行 /prd-writing-standards（在 Codex 中，从 $ 菜单中选择它） 并用你自己的话描述你想要什么。把它讲清楚；凌乱的版本比整齐的 指令更好。然后审查它。

2. 设计与细化

   运行 /technical-design-writing-standards 来设计它将如何构建，并审查它。 然后 /autonomous-requirements-refinement 研究两份文档中的未决问题，并将答案融入其中。

3. 构建

   运行 /implement-from-requirements。它会将工作拆分为会话大小的阶段，并在需要时使用 phase-split，然后构建、审查并测试第一个阶段。

在 GitHub 上查看

背后是谁

Enso Method 由 Doug Kerwin 创建和维护，他是 The Enterprise Vibe Coding Playbook 的作者，就职于 EnsoDynamics。其中的每条规则都源于一个真实的 客户项目需要它，并且每天都在生产系统上不断完善。

与 EnsoDynamics 合作 →

常见问题

常见问题。

什么是 Enso Method？

Enso Method 是一种开源软件开发方法论，打包为 20 多项 agent 技能， 适用于 Claude Code 和 OpenAI Codex。它通过 PRD、技术 设计、自主细化、会话大小的阶段、实现、审查和测试加固，将工作从想法推进到生产， 由书面需求而非聊天记录驱动构建。

它适用于哪些 AI 编程 agent？

Claude Code 和 OpenAI Codex，它们作为插件安装。这些技能遵循开放的 Agent Skills 格式，即一个包含 SKILL.md 文件的文件夹，因此其他读取该格式的 agent 可以使用 标准 skills CLI 安装它们。

在 agent 构建时，我必须回答它的问题吗？

很少。技术问题会根据你的代码、数据和 API 进行研究。agent 对某个业务问题 的确定度低于 95% 时，它会成为一个书面假设，附带其最佳答案和 置信度，由你的利益相关者在构建继续期间稍后确认或纠正。只有当 证据完全不支持任何答案时，它才会停下来询问，然后它会列出选项。

它适用于现有代码库吗？

是的，它的大部分用途都是在现有系统上。PRD 涵盖正在进行的变更，技术 设计只描述差异：保留、复用或关闭了什么，以及哪些行为不得 改变。技术问题会根据真实代码进行研究，因此文档从系统 的现状出发。

它与 Spec Kit 等规范驱动工具有何不同？

规格驱动的工具通常会为每个功能编写一份规格，然后将其弃置一旁。在 Enso 方法中，PRD 和技术设计会持续存在：有意义的变更会先修改它们，并基于该修改进行构建，因此系统背后的意图始终被记录下来。它为利益相关者增加了一个假设登记册，将阶段划分到适合一次 AI 会话的规模，并为每个验收标准提供针对真实系统的证据。

“ensō”是什么意思？

ensō 是禅宗书法中用一笔画出的圆。当圆闭合时它便完整，这正是该方法规则背后的理念：每次会话结束时都不留未了之事。旁边的红色印章写着 円（en），意为“圆”。