宁舟 AI实践

手柄 Vibe Coding

定目标，AI 实现，灰度实验。真正有效的协作不是把一句愿望扔给模型，而是让每一步都有可以观察的结果。

写于
本地整理
主题
方法 · 硬件交互
阅读
12 分钟
白色游戏手柄与实验节点和代码模块构成的青绿色技术插画

很多人谈 Vibe Coding，第一反应是“我有一个想法，请 AI 帮我把它做出来”。但一个项目真正困难的部分，通常不在于让模型生成第一版代码，而在于回答三个问题：我们到底想做成什么？应该先验证哪一个假设？每一次实验之后，如何知道下一步该往哪里走？

在“手柄 VB”项目中，我们逐渐形成了一套适合 AI 协作项目的方法：

定目标 → AI 实现 → 灰度实验

这三个步骤不是一次性的流水线，而是会在项目和每个阶段内部递归发生。本文记录这套方法如何从一个创意开始，逐步形成终极目标、项目目录、调研路径和阶段路线。

一、从创意开始，但不要急着实现创意

最初的创意很简单：能不能用 PS5 DualSense 手柄来操作 Codex，进行 Vibe Coding？

一个常见的做法是立刻拆实现任务：读取按钮、绑定快捷键、调用 API、做一个界面。这样当然可以快速得到第一版原型，但也很容易把项目锁死在最初的表达方式里。手柄只是输入设备，Codex 只是被触发的工具，最后得到的可能只是“用手柄按几个键执行几个命令”。

所以，创意出现之后，我们先暂停实现，改为追问：

  • 如果这个方向最终成功，用户体验的终点是什么？
  • 手柄在这个终点里，究竟是遥控器、快捷键面板，还是一种新的交互方式？
  • Codex 需要适配手柄，还是 Codex 本身应该被设计成适合手柄操作的形态？
  • 这个创意和别人已经做过的事情有什么不同？

这些问题把“做一个手柄控制器”提升成了“重新思考 AI 编程工具的交互形态”。项目的终极方向最终表述为：不是让手柄适配 Codex，而是让 Codex 主动适配手柄，逐步把 Codex 重构成一个以角色、空间、行动和事件承载 Agent 工作流的 2D 游戏世界。

这一步的关键不是把愿景写得宏大，而是把实现动作放回正确的目标之下。按钮监控、功能绑定和输入桥接仍然有价值，但它们是学习和验证路径，不是产品终局。

二、目标之前，先做三类调研

高质量的终极目标不能只靠想象。确定目标的第一步，是研究相似项目；但软硬件项目还有一个容易被忽略的前置工作：确认硬件本身究竟能提供什么能力。

1. 调研相似创意

我们先研究别人已经做了什么，哪些体验已经被验证，哪些地方仍然有空白，以及自己的想法是否真的具有独创性。调研对象不应只是宣传页面，也应该包括源码、许可证、平台限制和可运行性。

围绕“PS5 手柄 + Vibe Coding + AI 编程工具”这一交叉方向，我们使用过几类关键词：

  • PS5 DualSense Vibe Coding
  • gamepad AI coding
  • Codex controller
  • Claude Code gamepad
  • AI coding controller open source
  • DualSense macOS input
  • controller trigger coding workflow

关键词的组合方式也很重要：先用宽关键词找到相邻项目，再加入平台、工具、许可证或开源等约束，把结果收窄到可以实际验证的候选。

2. 补做硬件能力调研

这一步尤其容易被有经验的人跳过。因为自己已经熟悉 PS5 手柄，就会下意识认为“手柄有哪些功能”不需要再查。但在软硬件结合项目里，熟悉并不等于已经把能力转译成工程边界；很多能否实现、值不值得实现的问题，恰恰取决于硬件、驱动、操作系统和开发库之间的差异。

硬件能力调研至少要回答：

  • 有哪些输入：按键、方向键、摇杆、扳机、触摸板、动作传感器等。
  • 有哪些输出：指示灯、扬声器、普通震动、自适应扳机等。
  • 每项能力是否有连续数据，还是只有二值状态。
  • USB 和蓝牙连接是否存在差异。
  • 操作系统、驱动和开发库是否暴露了这项能力。
  • 能力是否适合当前目标，还是会把项目带入新的底层研发问题。

以 DualSense 为例，硬件能力可以粗略分为四层：传统按键与摇杆输入；扳机的连续行程和自适应阻力；触摸板的点击、坐标和多点触摸；加速度计、陀螺仪、震动执行器等运动与反馈能力。真正做方案时，还要进一步确认当前平台和库能否读取或控制这些能力，不能因为硬件存在就默认软件可以直接使用。

硬件调研的意义，不是把产品说明书抄一遍，而是建立一张“能力—接口—限制—机会”的地图。这样后面做阶段规划时，才不会漏掉关键能力，也不会把不可用的能力写成已经确定的功能。

3. 调研能不能实际运行

我们对候选软件项目做了三层检查：

  1. 概念检查：它解决的是什么问题，交互模型和我们的创意是否相似。
  2. 工程检查：源码结构、依赖、平台要求、许可证和可扩展性如何。
  3. 运行检查：能否在本机安装、构建、启动，并用真实手柄完成最小闭环。

这一步产生了几个相似项目。我们重点选择了 CodingMacro 进行深度试用：完成源码部署、依赖安装、检查、测试、构建和 macOS App 构建，并在模拟模式及真实 DualSense 上验证输入事件和工作流 Deep Link。

实际运行带来了单纯阅读介绍无法得到的认识：手柄事件采集、标准化和发送 Prompt 的链路确实可行；Hook、权限和键盘注入会成为真实工作流中的重要约束；“手柄触发 Codex”可以成立，但它还没有改变 Codex 的核心交互模型。

因此，调研的产出不是“发现一个可以照抄的项目”，而是帮助我们看清机会：已有方案证明了连接是可行的，也暴露出“让 Codex 适配手柄”这一层仍然值得探索。

三、先建立项目目录，再让 AI 工作

确定了值得继续探索的方向之后，第二步不是让大模型无脑调研、生成一大堆报告，而是先建立项目目录。目录的作用是给 AI 一个稳定的上下文边界，也给人一个可以回溯决策、区分事实和假设的工作台。

一个通用的 AI 软硬件项目结构可以按下面的方式组织：

项目根目录/
├── 00-项目入口/       # 项目首页、目录说明、元数据规范
├── 01-愿景与范围/     # 终极目标、边界、成功标准
├── 02-用户场景/       # 用户任务、旅程、使用情境
├── 03-交互设计/       # 输入、状态、反馈、交互规则
├── 04-技术方案/       # 架构、接口、权限、关键技术路径
├── 05-原型与实验/     # 可运行原型、实验记录、验证结果
├── 06-设计决策/       # 重要取舍和 ADR
├── 07-测试与评估/     # 指标、测试计划、验收标准
├── 08-会议与日志/     # 项目日志、会议记录、过程摘要
├── 09-参考资料/       # 行业调研、硬件资料、源码和外部项目
├── 10-分享/           # 对外发布的文章和案例
├── 90-模板/           # 可复用的文档模板
└── 99-归档/           # 被取代或不再维护的资料

目录建设的顺序也有讲究：先有入口和日志，再建立愿景、参考资料、方案、实验和分享等内容区。这样每次 AI 会话都能先知道项目当前走到哪里、哪些内容已经验证、哪些只是计划。

可复刻提示词：建立通用项目目录

下面这段提示词可以直接交给 Codex 或其他能够操作文件的 AI，创建一个适用于大多数 AI 软硬件项目的初始结构：

请在当前工作区建立一个可长期维护的 AI 软硬件项目文档目录。

要求：
1. 先阅读当前目录已有文件，不覆盖、不删除用户已有内容。
2. 创建 00-项目入口、01-愿景与范围、02-用户场景、03-交互设计、04-技术方案、
   05-原型与实验、06-设计决策、07-测试与评估、08-会议与日志、09-参考资料、
   10-分享、90-模板、99-归档。
3. 在 00-项目入口创建项目首页、目录说明和元数据规范。
4. 在 08-会议与日志创建项目日志，并记录本次目录初始化。
5. 每份 Markdown 都使用 YAML frontmatter，至少包含 project、type、status、tags、
   created、updated；project 使用项目名称，tags 必须包含项目名称。
6. 为每个目录创建简短索引或说明，说明该目录存放什么、不存放什么。
7. 不要把计划写成已完成，不要虚构调研、测试或实验结果。
8. 完成后输出创建的文件清单、目录用途和仍待用户确认的事项。

用 Obsidian 管理 AI 产生的一切文档

Obsidian 的价值不只是打开 Markdown，而是把 Markdown 文件、双链、标签和目录组合成一个可持续维护的知识网络。实践中有几条技巧尤其重要：

  • 每份文档使用 YAML frontmatter，统一记录项目、类型、状态、标签和日期。
  • 用双链连接上游目标、相关决策、实验和参考资料，而不是只依赖文件夹层级。
  • 用索引文档作为人工导航入口；目录解决“在哪里”，双链解决“为什么有关联”。
  • 用标签和属性视图筛选草案、调研、实验或已完成内容。
  • 把计划、事实、推断和验证结果分开写，避免 AI 把猜测写成结论。
  • 代码、构建产物和依赖放到另行指定的执行目录，项目笔记库只保留方案、证据和结论。

第二个关键文件：AGENTS.md

仅有目录还不够。目录告诉 AI 文件放在哪里，AGENTS.md 才告诉 AI 在这个项目里应该怎样工作。

我们在项目根目录补充了 AGENTS.md，把项目协作约定写成每次会话都必须遵守的规则，包括：Markdown 的 frontmatter 要求、双链要求、状态不能超前、第三方目录的排除范围，以及“每次会话开始先读项目日志、最终回复前完成日志更新”。

其中最重要的一条，是把项目日志从“可有可无的会议记录”变成持续的项目记忆：无论本次是写文档、写代码、调研、讨论、排查问题，还是最终没有产生文件变更，都要用摘要记录目标、行动、结论和待办。

这对使用 AI 的个人开发者尤其有帮助。很多人不是不工作，而是每次工作都散落在不同聊天窗口、终端和临时文件里，到了日报或周报时又要重新回忆。让 AI 自动维护项目日志，就可以从日志快速生成日报、周报和阶段复盘，把汇报从“重新整理一次工作”变成“读取已经持续沉淀的项目记忆”。

可复刻提示词：建立项目规则和自动日志

目录创建完成后，可以使用下面的提示词修复或建立项目级 AGENTS.md：

请为当前项目创建或修订根目录 AGENTS.md，使 AI 在后续会话中能够稳定遵守项目协作规则。

请先阅读项目目录、项目首页、目录说明、元数据规范和项目日志。规则至少包括：
1. 每次会话开始先阅读项目日志，了解当前进展、结论和待办。
2. 每次会话结束前必须更新项目日志；记录目标、完成的行动和产出、关键决定或发现、
   未完成事项、风险和建议下一步。没有文件变更也要记录。
3. 所有 Markdown 必须有统一 YAML frontmatter；项目名、状态、类型、标签和日期不得缺失。
4. 新文档必须建立有意义的上游或相关双链，并在索引或上游文档中留下返回路径。
5. 不得把计划、推断或未验证内容写成 completed；不得删除历史日志。
6. 排除 .venv、node_modules、构建输出和第三方依赖中的 Markdown。
7. 修改文件后进行适度的格式和结构检查，并在最终摘要中说明验证结果。

请保留已有 AGENTS.md 中仍然有效的规则，只补充缺失内容；完成后检查规则是否与项目实际目录一致。

如果 AI 具备文件操作能力，还可以把“最终回复前更新日志”作为执行流程的一部分，而不是仅仅作为建议。这样项目日志才会真正成为可靠的时间线。

四、从调研结果构建终极目标

调研完成后，才进入“定目标”的核心阶段。这里的目标不是一句产品宣传语，而是一组能够指导取舍的判断标准。

我们的终极目标包含四层含义：

  1. 空间：Codex 不再只是窗口和消息列表，而是一个可以被探索的 2D 世界。
  2. 角色：用户、Agent、任务和结果不再只是抽象数据，而是世界中的玩家角色、Agent 人物和可感知对象。
  3. 行动：手柄输入不止触发快捷键，而是表达移动、选择、确认、召唤、切换和领取结果等意图。
  4. 事件：Agent 工作、权限请求、等待、完成和失败都被转化成可理解的世界事件与反馈。

这个目标也提供了一个反向检验：如果某项功能只是增加了更多按钮映射，却没有让 Codex 更像一个适合手柄操作的世界，它可能属于阶段性工具，而不是终局能力。

可复刻提示词：从调研形成终极目标

请基于当前项目的创意、硬件能力调研、相似项目调研和用户场景，帮助我构建一个可执行的终极目标。

请按以下结构输出：
1. 当前创意想解决的根本问题。
2. 相似项目已经解决了什么、留下了什么空白。
3. 硬件能力、软件接口和平台限制带来的机会与边界。
4. 一句话终极目标。
5. 终极体验中的核心对象、用户行动、系统事件和反馈。
6. 明确哪些是阶段性手段，哪些才是产品终局。
7. 非目标、风险和仍需验证的关键假设。

要求：区分事实、推断和假设；不要把调研中尚未验证的内容写成结论；不要直接开始写实现代码。

五、从起点走向终点：阶段目标与路径

终极目标很远，不能直接交给 AI 一次完成。因此，我们把从起点到终点的路径拆成若干阶段。每个阶段只承担一个主要学习任务，并设置清晰的阶段性目标，避免“边做边发散”。

流程概览
  1. 创意
  2. 硬件与相似项目调研
  3. 终极目标
  4. 阶段一：认识手柄
  5. 阶段二：理解意图并绑定能力
  6. 阶段三：重构 Codex 交互
  7. 灰度实验与复盘

↻ 修正目标或假设

阶段一：认识手柄

核心目标： 建立可靠的硬件输入与反馈事实。

需要回答的问题：

  • 设备是否能稳定连接和重连？
  • 按键、方向键、摇杆、扳机、触摸板和运动传感器分别能提供什么数据？
  • 震动、灯光、扬声器和自适应扳机等反馈能力是否能被当前平台和开发库使用？
  • 哪些能力是连续值，哪些只是二值事件？采样率、延迟和漂移如何？

阶段产出： 硬件能力清单、输入输出数据模型、设备兼容性边界和最小可观察原型。

进入下一阶段的条件： 我们能够解释每类关键输入的含义、限制和可测试方式，而不是只知道“按钮能触发事件”。

阶段二：理解意图并绑定现有能力

核心目标： 把原始手柄输入转化为可确认、可执行、可反馈的用户意图。

需要回答的问题：

  • 用户如何通过有限的按键表达复杂任务？
  • 单击、长按、组合键、摇杆和触摸操作分别适合表达什么意图？
  • 哪些动作需要确认、撤销或权限提示？
  • Codex 的输入、执行、等待、权限和结果状态如何反馈给用户？

阶段产出： 意图模型、控制映射、执行桥接协议、反馈状态和安全边界。

进入下一阶段的条件： 用户能够完成一条低风险、可回退的完整闭环，并且知道系统当前正在做什么、为什么停下以及结果在哪里。

阶段三：重构 Codex 的交互形态

核心目标： 让 Codex 原生适配手柄，而不只是被手柄遥控。

需要回答的问题：

  • 会话、Agent、任务、权限、等待和结果如何成为游戏世界中的对象？
  • 用户如何在空间中发现任务、召唤 Agent、观察进度和领取结果？
  • 高信息密度的编程反馈如何转化为不打断工作的视觉、声音和触觉反馈？
  • 游戏化表达如何保留 AI 工具的效率、可控性和安全性？

阶段产出： 游戏世界模型、角色与事件模型、核心交互流程、视觉和反馈语言，以及可灰度验证的最小世界。

进入下一阶段的条件： 手柄不再只是快捷键集合，而成为用户理解、控制和感知 Codex 工作流的主要入口之一。

阶段路线不是一次性承诺所有细节。每完成一个阶段，都要根据真实实验重新检查终极目标是否仍然成立，并调整下一阶段的重点。

六、把方法压缩成三个动作

从创意到目录，从调研到愿景，再从愿景到阶段路线，可以压缩成一套适用于 AI 项目的工作循环。

1. 定目标

先明确终极体验和成功标准，再决定当前阶段需要验证什么。相似项目调研和硬件能力调研都是定目标的一部分，因为没有比较和边界，目标很容易只是未经检验的想象。

可复刻提示词：

我有一个新的 AI 产品或软硬件项目创意。请不要直接写代码，先帮助我定目标。

请依次完成：
1. 复述创意，并指出其中可能混淆的“手段”和“终极体验”。
2. 列出需要调研的相似项目、用户需求、硬件能力、软件接口和平台限制。
3. 为每个调研方向给出关键词、验证方法和判断标准。
4. 根据调研结果提出 2—3 个候选终极目标，说明差异和取舍。
5. 最终形成一句话目标、核心体验、非目标、关键假设和成功标准。

请明确区分已知事实、合理推断和待验证假设；在目标确认前不要开始实现。

2. AI 实现

让 AI 根据当前阶段目标生成方案、代码、文档和测试。但实现必须放在项目目录和项目规则中进行，所有产出都要能回到目标、决策或实验记录上。

可复刻提示词：

请根据当前项目的终极目标和当前阶段目标实现一个最小可验证版本。

开始前：
1. 阅读项目日志、AGENTS.md、相关方案、用户场景和已有实验记录。
2. 列出本次要验证的一个核心假设，以及明确不做的事情。
3. 先给出实现计划、文件变更范围、风险和验证方式。

执行时：
4. 遵守项目目录、frontmatter、双链、状态和日志规则。
5. 优先实现可回退、可观察、可测试的最小闭环。
6. 不虚构接口、硬件能力、测试结果或外部资料。

完成后：
7. 运行适度的检查和测试。
8. 更新相关文档和项目日志。
9. 输出完成内容、验证证据、未完成事项和下一轮实验建议。

3. 灰度实验

先用小范围、低风险、可回退的方式运行真实原型。观察用户操作、系统数据、失败信息和意外发现，再决定继续、修改或放弃哪条路径。

可复刻提示词：

请为当前阶段设计一次灰度实验，不要直接扩大功能范围。

请输出：
1. 本次只验证的一个核心假设。
2. 实验范围、参与者、设备、环境和前置条件。
3. 用户操作步骤与预期行为。
4. 要记录的事件、数据、错误、延迟和主观反馈。
5. 成功、部分成功、失败和中止的判定标准。
6. 风险、权限边界、回退方案和数据清理方式。
7. 实验结束后的复盘问题，以及根据不同结果进入哪条下一步路径。

实验完成后，请把事实结果写入项目日志；不要把计划、推断或未发生的结果写成结论。

完成一次灰度实验后，又会回到“定目标”：目标是否需要修正？阶段目标是否合理？下一次 AI 实现应该解决哪一个最关键的不确定性？

总结

这次项目的第一步并不是写代码，而是把创意放进一个更大的问题中：我们究竟想创造一种怎样的 AI 工作体验？通过相似项目调研和硬件能力调研，我们确认了已有路径的可行性，也看清了硬件、平台和软件接口的边界。通过项目目录、AGENTS.md 和自动项目日志，我们把目标、资料、方案、实验和决策组织成可持续协作的上下文，也减少了日后整理日报、周报和阶段汇报的负担。最后，通过终极目标和阶段目标，我们把远期愿景转化为可以逐步验证的开发路径。

因此，Vibe Coding 不应被理解为“让 AI 直接写代码”，而可以被理解为：

定目标，AI 实现，灰度实验；在每个阶段递归执行。

这套方法不仅适用于手柄与 Codex，也适用于各类由 AI 参与完成的产品、工具、自动化流程和交互实验。只要项目同时面对开放创意、技术不确定性和快速迭代，就应该先问清终点，再让 AI 实现，最后用真实实验校正方向。