我新的 AI 原生软件工程原则是：尽可能删除更多抽象层。到目前为止，我所有的 web 应用都是用 Rust 编写并编译成 wasm 的，UI 直接用 HTML 和/或原生 WebGPU 调用来渲染——没有 React、Three.js、Next.js 或任何其他中间抽象层。我所有的精力都花在为每个应用编写自定义验证框架上，完全量化性能、可用性，以及对编码代理来说“好“的标准是什么，这样代理就可以在此基础上不断爬坡优化。

每次代理会话都通过我的 explore unknowns 技能来规划，所以所有重大决策都提前完成了，然后我就让代理自由发挥 12 个小时以上。到目前为止，我已经在独立交付一年前想都不敢想的产品了。

dzhng/skills

来源：https://github.com/dzhng/skills

技能

skills.sh

用于构建软件工厂的 AI 技能。

我的个人领域无关代理技能库，在每个项目中重复使用。小巧、可组合、可自由修改——适用于任何支持技能的框架：Claude Code、Codex、opencode、Cursor、duet 以及 70 多种其他框架。

npx skills add dzhng/skills

加上 --list 可以选择单个技能，或者将任何 skills/<类别>/<技能> 文件夹复制到你的框架技能目录中（例如 .claude/skills/）。

从克隆的仓库中，npm run install-skills 可以在不使用注册表的情况下执行相同操作：

npm run install-skills                 # 安装到 ~/.agents/skills，从 ~/.claude/skills 链接
npm run install-skills -- ../my-app    # 安装到仓库而非主目录
npm run install-skills -- --only write-spec,review ../my-app
npm run list-skills                    # 列出名称和类别

.agents/skills/<技能>/ 存放真实文件（扁平化，无类别区分，跨类别链接已重写以匹配）；.claude/skills/ 是指向其中的相对符号链接，因此两个框架读取的是同一份副本。

重新运行会覆盖已安装的副本——如果你保留的是真实目录的 .claude/skills/ 则不会被修改，已经是符号链接的 .claude/skills 也保持原样。加上 --dry-run 可以先查看计划。

为什么

软件正在从任务转向工厂：代理自主追求目标，直到输出可以被信任。难点不在于将目标拆分为任务——而在于将其拆分为可以独立验证的部分，并且知道这些部分在哪里。这些技能就是用来运行这个循环的。

将未知视为战争迷雾：先绘制地形，将其划分为可以独立构建和验证的区域，然后递归地重新切分任何隐藏更多地图的部分。而且重新规划不会在规划结束时停止——规格说明是一份活文档，在实现过程中随时更新和重新切分，只要工作教会代理计划已经过时了。

每一部分都必须证明自己——架构审查、代码审查，以及与基线的视觉审查——然后循环才能继续。每次迭代都会更少出错，直到目标完成。

一次自主运行——3 天 18 分钟追求一个目标

证据：一次无人值守的 Codex 运行，在这些技能之上持续追求一个目标 3 天 18 分钟，不断切分和迭代直到完成。

如何使用

使用链式流水线来构建功能，使用研究循环来发现有效的方法，或者按需使用单独的技能。每个技能都可以独立使用。

完整循环——一个大功能，从头到尾

完整循环——探索、编写规格、无人值守构建、审查决策

1. 绘制迷雾。 对想法运行 /explore-unknowns。它会按象限逐一采访你，并提供渲染好的选项、原型和决策表格让你反应，而不是要求你凭空想象。到最后你就知道这个功能应该是什么样的了。

2. 固化。 对那张地图运行 /write-spec。大多数决策已经在上游完成，所以这一步主要是转录——我不会读这份规格。任何真正的新内容，它会先询问而不是自行决定。

3. 构建。 启动循环：

   /goal /implement-spec specs/
   

   /goal 是让框架进入循环模式的命令——在 Claude Code 或 Codex 中操作相同——然后由规格来驱动。一个小功能几小时，一个大功能两三天。加上任何合适的框架：在 xyz 分支上，或者使用 /codex 作为实现者，而你保持为父级编排者和审查者。

4. 审查决策，而不是差异。 运行结束时会整合 specs/<技能>/choices.md——代理在规格沉默处所做的每个决策，按信心最低排在前面。这就是审查界面。将修改意见发回，下一轮会重新审计：每次 AI 写代码时，你审查它的选择。其余部分自动触发：每个切片结束时的 /review 审查，任何视觉内容的 /screenshot-critique 和 /compare-screenshots，最后一个切片完成时的 /close-spec，以及当实现证明计划过时时的计划重新切分。

   预算：步骤 1–2 花 30 分钟到几小时，步骤 4 花 30 分钟到几小时。一个运行两天的任务，两端各约 2–3 小时。你的时间花在首尾，中间无人值守。

研究——通过快速实验学习

当下一个决策需要实验证据时，使用 Auto Research。它从一个快速、有启发性的任务开始，测试一小批假设，检查组合，并随着方法改进扩大覆盖范围。新的失败成为焦点；之前的任务变成回归检查。

/auto-research 相对于已保存的基线，每个任务的成本至少降低 15%，且不降低任务成功率。
从一个快速开发任务开始。

如果评估器、指标、基线或所需改进不明确，该技能会在实验前先询问。通过评估和达到改进目标是两个独立的要求。输出包括最佳已验证的工件和一张参数效果地图：测试了什么，哪些地方有帮助或有伤害，以及各改动如何相互作用。在研究准备好实现时，使用这些证据来指导规格。

单点使用——即兴路径

• 一个头脑风暴最终变成了一个功能。 /explore-unknowns 在讨论结束时和开始时一样好用——运行它来清扫你们双方都没想到的角度，然后在步骤 2 接续循环。
• 任何不是来自规格的代码修改。 一个临时修复，影响范围超出预期：先运行 /review（重构清理 → 代码审查 → 编写文档），然后 /audit-choices。当差异大到无法阅读时，决策账本是你仍然理解代码库现状的方式。

技能

工程——切分、构建、验证、重复

视觉审查——绝不凭感觉接受视觉效果

技能编写——让技能本身保持锋利

图形

许可证

MIT

致谢

感谢 Matt Pocock 提供的 retro 技能，此处复制后将其中的写作指南引用指向本仓库的 write-skills。同时也感谢 Matt 和 Thariq 提出的战争迷雾和探索地图概念，这些概念帮助塑造了这些技能。

lauren (@poteto)： 代码库中从来都充斥着垃圾代码。我们一直对此心安理得，因为除了关键任务的“硬“（例如嵌入式）软件之外，代码很少需要完美。

软件工程是一种独特的工程形式，因为你常常在构建一个不断演进的东西，而且……