用 Claude Code、Codex 这类 AI 编程助手写了一段时间代码后，我越来越觉得一件事：AI 帮我写出来的东西，最后都散落在聊天记录里了。需求是怎么定的、架构为什么这么选、测试跑没跑、发布前谁审过——这些信息全压在会话历史里，会话一关，什么都没了。换个 Agent 接手，它连我昨天干到哪一步都不知道。

于是我做了 making-things——一个面向 Electron 桌面应用的全栈 AI 编程工作流插件，最近已经发布到 GitHub（v1.0.0，MIT 协议）。它支持 Codex、ZCode、Claude Code 三套主流 AI 编程客户端，装上即用，不需要额外配置。这篇文章就聊聊我为什么做它，以及它到底解决了什么问题。

核心理念：让 AI 编程的产出不再是聊天记录

making-things 最反直觉、也是我最得意的一点是：把每一个被激活的需求变成一个持久化的工作包（durable work package），存放在你项目里的 docs/making-things/<ID>/ 目录下，而不是临时聊天历史里。

换句话说，工作包才是事实的来源，聊天记录不是。无论哪个 Agent、哪次会话，只要打开这个目录，就能看到这个需求从立项到发布的完整工程证据：PRD、架构、计划、任务、测试、评审、发布、交付，一个都不少。

这带来的直接好处是——AI 辅助开发终于从”聊天式”升级成了可审计、可追溯、可交付的工程化过程。

证据门控：13 个状态，每次转换都要拿出真凭实据

整个生命周期是一条状态机，从草稿一路走到归档关闭：

1
2
3
DRAFT → PRD_APPROVED → ARCHITECTURE_APPROVED → PLANNED → IN_DEVELOPMENT
  → TESTED → IN_REVIEW → [DEBUGGING] → ACCEPTED → RELEASE_READY
  → PACKAGED → DELIVERED → POST_RELEASE_RECORDED → CLOSED

这条链上每一个状态的转换，都要求提供新鲜的命令输出或记录在案的证据。我在项目里反复强调一句话：

“Passed,” “complete,” and “releasable” always mean verified, not claimed.

“通过了”、”完成了”、”可以发布了”——这些词永远意味着已验证，而不是口头声称。如果一个测试没跑，那就老老实实写 NOT RUN；如果一个检查不适用，就写 NOT_REQUIRED。我在设计时特意把 BLOCKED、NOT_REQUIRED、NOT RUN、NOT VERIFIED 都当成诚实的结果，而不是需要掩盖的失败。我觉得这一点对 AI 编程尤其重要——Agent 太容易”自信地汇报完成”了，必须有机制逼它拿出证据。

十个专精 Skill，各管一段生命周期

making-things 不是一个”大而全”的提示词，而是拆成了十个各司其职的 Skill，每个只负责生命周期的一个阶段：

Skill 职责
making-things 编排、规划、阶段路由（唯一需要显式触发）
product-prd 需求与验收标准
solution-architecture 架构与 IPC 契约
electron-implementation 功能实现
electron-ipc-security 权限边界审计
electron-test-e2e 测试策略与 E2E
electron-review 独立评审与裁决
electron-debug 根因分析与最小修复
electron-release 打包与发布矩阵
github-delivery Git 分支/提交/推送/PR

其中只有 $making-things 需要你手动敲一次来启动，其余九个会根据当前所处阶段自动接管。我也定了条规矩——别把它用在改个错别字、解释一段代码这种琐碎任务上，工作流是有成本的，得留给真正需要全流程把关的需求。

双 Agent 制衡：把”权力分立”引进 AI 编程

这是我最想聊的设计，也是 making-things 最独特的卖点。

我让两个 AI Agent 形成制衡关系：

  • Codex 负责发现需求、写 PRD、定架构、做计划、实现功能、写测试、自我评审、产出交接文档；
  • ZCode 独立负责代码评审、问题复现、Debug 收尾、回归验证，以及最终的发布裁决；
  • 两个 Agent 都不能把对方未经核实的声明当作证据。

这就像现实工程里的”开发”和”测试/验收”岗位分立——自己写的代码不能自己盖章放行。STATE.md 会记录每次交接时的 active_agent，HANDOFF.md 则是 Agent 之间传递上下文的接力棒。当然，单人单 Agent 也能跑，只是评审的独立性会打折扣。

Electron 安全作为一等公民

做 Electron 应用，安全边界（IPC、preload、contextBridge、sandbox）是绕不开的坑。我不想让安全变成”事后审计”，所以直接把它做成了生命周期里的一个独立阶段（electron-ipc-security）。

整套安全模型包括：

  • 渲染进程只能用浏览器能力，禁直接访问 Node.js 或 Electron 特权 API；
  • Preload 通过 contextBridge 只暴露很窄的能力，绝不暴露 raw ipcRenderer、require、fs、shell、process；
  • 默认 nodeIntegration: false、contextIsolation: true、sandbox: true、webSecurity: true；
  • 发布检查时只打印密钥变量名（PRESENT/MISSING），永不打印值。

我还立了一条硬规矩：永远不要用关掉 sandbox、关掉 context isolation、关掉 web security、删掉校验或测试的方式来”修”问题——一次干净的静态扫描，不等于安全证明。

栈中立：不绑定任何工具链

另一个我比较坚持的设计是技术中立。making-things 不预设你用 electron-builder 还是 Forge，不预设你用 React 还是 Vue，不预设你用 npm 还是 Bun。这些都是在工作项里探测并记录的，插件本身只提供方法论和工作流骨架。这样它才能真正插进任何一个 Electron 项目。

安装与使用

安装

Claude Code / ZCode：

1
2
3
4
5
6
# 从 marketplace 安装
/plugin marketplace add SuShuHeng/making-things
/plugin install making-things@making-things

# 或直接安装
/plugin install https://github.com/SuShuHeng/making-things

Codex（OpenAI）：

1
2
3
4
5
6
7
/plugins
# 搜索 making-things → Install

# 或在 ~/.codex/config.toml 添加 marketplace
# [marketplaces.making-things]
# source_type = "git"
# source = "https://github.com/SuShuHeng/making-things"

装完是零配置的——SessionStart hook 会自动注入一条轻量提示，告诉你 $making-things 已就绪。

启动或恢复一个工作项

1
$making-things

编排器会自动完成五件事：

  1. 校验工作流结构；
  2. 读取 docs/making-things/CURRENT.md；
  3. 初始化新工作项，或恢复进行中的那一个；
  4. 路由到当前阶段对应的专精 Skill；
  5. 在每次状态转换前索要证据。

它甚至会在你打开会话时智能检测活动工作项的状态，给出针对性的下一步提示——比如工作项已经 TESTED 且交接准备就绪时，它会提醒你该让 ZCode 介入评审了。

写在最后

做 making-things 的初衷很简单：我想要一个能让我信任 AI 编程产出的工作流。不是相信它”说完成了”，而是相信它”真的完成了、并且我能追溯全过程”。

如果你也在用 AI 编程助手做 Electron 开发，或者单纯对”怎么把 AI 编程工程化”这个问题感兴趣，欢迎来 GitHub 仓库 看看，给我提 issue 或建议。这是我的第一个正式开源发布的插件，还有很多想继续完善的地方 🚀

仓库地址：https://github.com/SuShuHeng/making-things
许可证：MIT