AI执行契约：结构化协作框架，提升AI产品构建效率与确定性

1. 项目概述从灵感到成品的AI驱动产品构建框架如果你和我一样经常使用 Cursor、Claude 或 ChatGPT 来辅助构建产品原型或功能那你一定经历过这样的场景你有一个绝佳的想法兴冲冲地打开 AI 对话窗口开始描述你的需求。一开始 AI 似乎理解了生成了一些代码或设计但当你试图深入细节或者要求它调整某个部分时对话开始变得混乱。AI 可能会忘记你之前提到的关键约束或者对“用户体验”的理解与你南辕北辙。几轮拉扯下来你发现自己花费了大量时间在澄清需求、纠正方向而不是在真正地“构建”。这个问题的核心在于我们与 AI 协作时缺乏一个稳定、结构化的“上下文锚点”。我们提供的信息是碎片化、非结构化的导致 AI 的理解也必然是碎片化和不稳定的。今天要深入拆解的这个项目——AI Execution Contract正是为了解决这个痛点而生。它不是一个简单的提示词合集而是一套完整的、可复用的“产品思维工具包”。其核心是引导你将一个模糊的产品想法转化为一份结构清晰的“AI 执行契约”。这份契约定义了你要构建什么、为谁构建、遵循哪些规则以及当前有哪些资源可用。之后无论你使用 Claude、Cursor 还是 ChatGPT都可以将这份契约作为核心上下文让 AI 在清晰的边界和规则内为你工作极大提升从想法到可交付成果的效率和确定性。简单来说它把与 AI 的协作从“即兴聊天”变成了“按合同办事”。这套工具包尤其适合独立开发者、产品经理、创业团队以及任何希望系统化利用 AI 进行产品构建的人。无论你是要开发一个完整的 SaaS 应用、一个营销落地页还是一个内部工具都可以通过这个框架来理清思路、对齐认知并让 AI 成为你高效且可靠的执行伙伴。2. 核心设计哲学为什么“契约”比“聊天”更有效在深入使用细节前理解背后的设计哲学至关重要。这能帮你判断这套方法是否适合你以及如何最大化其价值。2.1 核心理念AI 放大组织性而非取代它项目作者有一个非常清醒的认知AI 不会自动带来更好的结果它放大的是你输入的组织性和清晰度。如果你给 AI 一堆混乱的想法它最多只能给你一堆看似相关但同样混乱的输出。AI Execution Contract 的核心价值在于它强制你在“动手”之前先完成一次深度的产品思考和解构。这个过程本身即使没有 AI 参与也极具价值。它迫使你明确回答以下问题我们到底在解决什么问题Problem我们相信的解决方案会带来什么改变Hypothesis谁会用他们最核心的动作是什么User Core Flow产品由哪些关键部分组成Product Structure有哪些不能逾越的边界Constraints当你把这些问题的答案结构化地写下来你不仅为自己理清了思路更是为 AI 准备了一份无歧义的“工作说明书”。这从根本上改变了协作模式AI 从需要猜测你意图的“聊天对象”变成了严格遵循契约条款的“执行代理”。2.2 契约作为执行工件而非归档文档这是另一个关键区别。我们写过太多 PRD产品需求文档或设计稿一旦进入开发阶段就被束之高阁。AI Execution Contract 的设计初衷就是要被使用。在后续的每一个实现提示中你都会引用或粘贴契约的相关部分。例如当你让 AI 实现“用户注册模块”时你会同时附上契约中关于“目标用户”、“核心流程”和“技术栈约束”的章节。这确保了 AI 在生成代码、文案或设计时其决策始终与最初设定的产品目标和框架保持一致。契约是活的是工作流的一部分会随着项目推进而迭代更新。2.3 分离关注点结构、系统与资产的“就绪度”传统需求文档常常混淆“要做什么”和“有什么可用”。这个框架明确区分了三个层面的“就绪度”设计结构就绪度我们是否已经想清楚了产品的页面流、信息架构和交互逻辑这对应可选的“UX 结构”输出。设计系统就绪度我们是否有现成的设计规范比如颜色、字体、间距的 Design Tokens或者一套可复用的 UI 组件库如 React 组件资产就绪度我们是否有 Logo、插图、图标、图片等视觉素材还是全部需要用占位符在契约中明确这三者的状态对 AI 至关重要。如果设计系统是“就绪”的AI 生成 UI 代码时就会直接引用现有的 Token 和组件保证一致性。如果是“无”AI 就知道需要从头创建一套临时样式并标记为待设计。这种清晰度避免了 AI 做出不切实际的假设也让你能精准地识别出项目前期的依赖和风险。3. 核心工作流深度解析两种启动模式项目提供了两种主要的使用路径适应不同的工作习惯和项目阶段。理解这两种模式能帮你快速上手。3.1 引导者模式与 AI 进行结构化对话这是最具交互性的方式特别适合想法还比较模糊或者你希望借助 AI 来梳理思路的场景。这个模式模拟了一位经验丰富的产品引导师Facilitator在主持一场需求梳理会。实操流程与细节加载上下文在你的 AI 工具如 Cursor中将整个仓库或workflow/文件夹作为上下文加载。对于 ChatGPT 或 Claude你可以将关键的 workflow 文件内容粘贴到对话中。激活引导者向 AI 发出明确的指令例如“请使用本项目中的引导者工作流帮助我创建一份 AI 执行契约。”结构化问答AI 会进入引导者模式。它不会一次性问你所有问题而是严格按照facilitator-questions.md中定义的顺序一次只问一个问题。例如第一问“你想要构建什么产品或功能”项目想法在你回答后第二问“这个产品旨在解决什么核心问题”接着第三问“关于这个解决方案你的核心假设是什么”即你相信如果构建了它会发生什么积极的改变 这个过程会持续进行覆盖用户、核心流程、功能模块、信任要素、设计就绪度、技术栈、约束条件等十多个关键维度。信息汇总与确认在收集了足够信息后AI 会暂停提问并将它理解的所有信息以摘要形式呈现给你请你确认是否有误或遗漏。这是一个关键的纠偏节点。生成契约确认无误后AI 会调用generate-contract-from-session.md中的逻辑将散落的问答整合成一份格式工整、结构完整的 Markdown 契约文档。后续衍生生成契约后你可以选择直接使用进入实现阶段。细化契约使用refine-contract.md流程让 AI 帮你优化契约的表述或补充细节。生成 UX 结构使用contract-to-ux.md让 AI 基于契约推导出具体的页面/屏幕列表、层级关系和主用户流程。这还不是视觉设计而是信息结构。生成技术架构使用contract-to-architecture.md让 AI 建议项目文件夹结构、组件划分、资产存放位置等。实操心得引导者模式非常强大但需要你耐心回答每一个问题。不要跳过或给出过于模糊的答案因为 AI 会基于你的输入生成契约。你的输入质量直接决定了契约的质量。我个人的习惯是即使想法很初步也会强迫自己用完整的句子回答这本身就是一个极佳的思考整理过程。3.2 一键生成模式从已有文档快速出发如果你已经有一份相对清晰的产品简介、需求概要或竞品分析文档那么一键生成模式效率更高。实操流程与细节准备项目描述将你的项目想法整理成一段连贯的文字描述。可以涵盖背景、目标用户、核心功能、技术偏好等。使用生成提示词打开prompts/generate-contract-prompt.md你会找到两个版本的提示词一个简短版一个详细版。根据你项目描述的详略程度选择。执行生成将选中的提示词连同你的项目描述一起粘贴到 AI 对话中。AI 会直接输出一份完整的 AI Execution Contract。审查与细化生成的第一版契约很可能有不完善的地方。此时使用prompts/refine-contract-prompt.md中的提示词将契约粘贴进去让 AI 对其进行优化、扩展或修正。注意事项一键生成模式对输入文档的质量要求较高。如果你的描述存在歧义或遗漏生成的契约也会继承这些问题。因此生成后务必仔细审查“约束条件”、“设计系统就绪度”等部分AI 可能会做出不准确的假设。最好在生成后人工复核并补充这些关键信息。4. 契约内容逐项拆解与编写要点一份标准的 AI Execution Contract 包含多个章节每一部分都有其独特作用。理解如何填写每一部分是发挥其威力的关键。4.1 问题、假设与用户定义项目的“为什么”和“为谁”这是契约的基石决定了产品的方向和灵魂。问题不要描述功能要描述用户的痛苦或未被满足的需求。例如不是“构建一个仪表盘”而是“团队领导者无法快速直观地了解多个项目的实时健康状态导致决策延迟”。假设这是可验证的信念。格式通常是“我们相信通过提供 [解决方案]将会带来 [量化或质化的结果]这可以通过 [验证方法] 来证实。”例如“我们相信通过提供一个集中、可视化的项目健康度仪表盘将使团队领导者的每周复盘会议时间减少 30%这可以通过上线后四周内的会议时长数据来验证。”用户尽可能具体。不仅是“开发者”而是“拥有 3-5 年全栈经验、正在独立开发 side project、希望快速验证想法的个人开发者”。明确他们的首要目标和核心操作流程。核心流程应该像讲故事一样描述用户从接触到完成关键任务的一系列步骤。4.2 产品结构与功能描绘产品的“是什么”这部分将产品拆解为可管理的模块。核心部分/屏幕列出主要的界面单元。例如登录页、主仪表盘、项目详情页、设置页面。核心功能在每个部分下列出具体功能点。例如在“主仪表盘”下项目概览卡片、活动时间线、全局搜索、快速操作浮窗。信任/验证元素这是互联网产品特别是 To B 或涉及交易的产品中至关重要的一环。思考用户凭什么相信你并采取行动。例如客户 Logo 墙、用户评价、安全认证标识、免费试用入口、清晰的价格表、透明的数据使用政策。在契约中明确这些元素AI 在生成界面时就会有意识地为它们留出位置或设计呈现方式。4.3 约束与就绪度划定执行的“边界”和“起点”这部分为 AI 的创造性戴上了“镣铐”是保证输出可用性的关键。技术栈必须明确。是 React Next.js Tailwind CSS还是 Vue 3 Vite TypeScript后端是 Supabase 还是 Firebase版本号是否重要明确的栈信息让 AI 生成可直接使用的代码而非通用伪代码。约束包括性能如“首屏加载时间 2s”、合规性如“遵循 GDPR不默认设置非必要 Cookie”、可访问性如“所有交互元素需满足 WCAG 2.1 AA 标准”、浏览器兼容性等。这些是非功能性需求但至关重要。设计系统就绪度如实填写。如果有现成的 Figma 设计库或代码组件库提供链接或关键 Token如主色#007AFF、字体家族Inter。如果没有就写“无需要创建一套临时设计规范”。AI 会根据此决定是复用还是创建。资产就绪度列出所有可用的图片、图标、Logo 文件及其格式、尺寸。对于没有的资产注明“需要占位符”或“将由 AI 生成符合某风格要求的图片”。4.4 执行规则指导 AI 的“如何做”这是契约中最具操作性的部分直接指导 AI 的编码和构建行为。例如“所有组件必须采用函数式写法并使用 TypeScript 接口明确定义 Props。”“样式使用 Tailwind CSS 工具类禁止内联style或单独的.css文件。”“API 调用必须封装在独立的services/目录下的钩子或函数中。”“错误处理必须使用 try-catch 块并提供用户友好的错误提示。”“代码注释需遵循 JSDoc 格式。”这些规则将你的工程最佳实践固化下来确保 AI 生成的代码符合你的团队规范。5. 从契约到实现工作流整合与实战技巧生成契约只是第一步如何将其融入日常的 AI 辅助开发工作流才是产生价值的关键。5.1 在 Cursor 中的深度集成实践Cursor 因其强大的项目上下文感知能力是使用 AI Execution Contract 的最佳环境之一。项目初始化新建一个 Cursor 项目后第一件事不是写代码而是运行引导者模式生成契约。将契约文件如AI_Execution_Contract.md保存在项目根目录。设置核心上下文在 Cursor 的.cursorrules文件中你可以直接引用或摘要契约中的关键约束和规则。例如在.cursorrules里写上“本项目技术栈为 Next.js 15 with App Router, Tailwind CSS, Shadcn/ui。所有组件需使用 TypeScript。设计主色为#0EA5E9。请始终遵循AI_Execution_Contract.md中的完整要求。” 这样每次与 Cursor 的 AI 对话它都会将这些规则作为背景。分模块开发当需要开发某个具体功能时在 Chat 中除了描述任务同时附上契约中相关的片段。例如“请创建用户个人资料页面。参考契约中‘用户’部分对目标用户的描述以及‘产品结构’中关于个人资料页的功能列表并严格遵守‘技术栈’和‘执行规则’部分。”契约迭代在开发过程中如果发现契约有需要修改或补充的地方比如新增了一个约束直接更新AI_Execution_Contract.md文件。Cursor 的 AI 会感知到文件变化并在后续对话中遵循新的约定。5.2 在 ChatGPT/Claude 中的高效应用策略对于非代码生成类任务或者在没有 Cursor 的环境下ChatGPT 和 Claude 同样可以受益。对话起点开启一个新对话时首先将完整的 AI Execution Contract 粘贴进去并加上指令“这是本项目的工作契约。在后续所有关于此项目的对话中请严格依据此契约的内容来理解和执行我的需求。”分段引用对于复杂任务不要指望 AI 能记住契约的所有细节。在提出具体请求时再次粘贴与之最相关的部分。例如当你要求设计一个弹窗时除了描述弹窗功能可以附上契约中“设计系统就绪度”里关于颜色、字体的定义。用于生成非代码产出契约同样适用于生成产品文案、用户故事、测试用例等。你可以指令 AI“根据契约中‘用户’和‘核心流程’的描述为我生成 5 个主要的用户故事User Story。” 这能保证这些产出与产品定位高度一致。5.3 利用衍生产出UX 结构与技术架构对于中型以上项目强烈建议在生成契约后运行“生成 UX 结构”和“生成技术架构”的步骤。UX 结构这份产出物是一个清晰的树状或列表式结构定义了有哪些页面、页面包含哪些区块、区块之间的跳转关系。它本身不涉及视觉但为后续的 UI 设计和前端路由提供了蓝图。你可以将此结构交给 AI 去生成初步的路由配置或页面组件骨架。技术架构这份产出物会建议项目的文件夹组织方式、核心组件分类、状态管理方案、资产目录等。对于新手或启动新项目时这是一个极佳的参考。你可以让 AI 直接按照这个架构去创建初始的文件和文件夹结构。实操心得不要将契约视为一成不变的圣经。它应该是一个“活文档”。在开发过程中你肯定会遇到契约中未预料到的情况。我的习惯是每周或每个里程碑回顾一次契约根据实际情况进行修订和版本更新。同时为契约文件本身建立版本历史可以用 Git这样就能清晰地追踪产品决策的演变过程。6. 常见问题与避坑指南在实际使用中你可能会遇到一些典型问题。以下是我总结的常见陷阱及解决方案。6.1 契约内容过于空泛无法指导 AI问题表现AI 生成的代码或设计仍然很通用没有解决你的具体问题。根源分析契约中的描述停留在概念层如“用户体验要好”、“界面要美观”缺乏可操作的细节。解决方案量化约束将“性能要好”改为“在 3G 网络环境下首屏可交互时间TTI应低于 5 秒”。具体化描述将“管理仪表盘”改为“一个面向中小团队的项目管理仪表盘核心视图包括按状态未开始、进行中、已完成筛选的项目卡片列表、一个团队活动时间线 Feed 流、以及一个显示本周截止任务的醒目横幅区域”。提供参考在契约中附上竞品截图链接或描述你喜欢的交互模式例如“希望采用类似 Linear 应用中的键盘快捷键导航体验”。6.2 AI 在引导者模式中“跑偏”或忘记上下文问题表现AI 在问答过程中突然开始讨论无关话题或者忘记了之前已经确认过的信息。根源分析可能是对话上下文过长导致 AI 注意力分散或者你的指令不够清晰。解决方案使用“系统指令”强化角色在对话开始时明确强调“你现在是严格遵循facilitator-mode.md指南的 AI 产品引导师。请一次只问一个问题并在生成契约前总结确认所有信息。”分阶段进行对于非常复杂的项目可以分两次会话进行。第一次会话完成“问题、假设、用户”等战略层问答并生成部分契约。第二次会话加载已生成的部分契约作为上下文再继续“功能、约束、技术栈”等战术层问答。及时纠正一旦 AI 偏离立即打断并重申规则“请回到引导者模式提出下一个结构化问题。”6.3 生成的 UX 结构或技术架构不切实际问题表现AI 建议的技术方案过于复杂或 UX 流程不符合用户实际习惯。根源分析AI 的训练数据可能包含各种复杂的企业级方案而你的只是一个简单项目。或者契约中对于用户流程的描述存在模糊地带。解决方案在契约中明确“简单性”原则在“约束”或“执行规则”部分加入一条“技术架构应遵循 KISSKeep It Simple, Stupid原则优先选择最直接、最易维护的方案避免过度设计。”人工评审与调整永远记住AI 是建议者你是决策者。将 AI 生成的架构作为初稿结合你自己的经验进行评审和简化。删除不必要的抽象层合并过于细碎的组件。提供更具体的用户场景在描述核心流程时使用“用户故事”的格式作为 [某类用户]我希望 [达成某个目标]以便于 [获得某种价值]这能帮助 AI 推导出更贴合实际的 UX 路径。6.4 多成员团队中如何协同使用契约问题表现契约由一人创建但团队其他成员不按契约执行导致混乱。根源分析契约未被确立为团队共同遵循的“唯一真相来源”。解决方案设立契约评审会在项目启动初期召集产品、设计、开发等相关角色共同参与引导者模式的问答或共同评审已生成的契约草案。确保所有人对内容达成一致。将契约纳入版本控制将AI_Execution_Contract.md文件放在项目 Git 仓库的根目录。任何修改都需要通过 Pull Request 和团队 review。将契约作为 onboarding 文档新成员加入项目时第一份阅读材料就是 AI 执行契约这能让他们最快速度理解项目全貌和协作规范。7. 进阶技巧与个性化定制当你熟悉基础流程后可以通过以下方式让这套工具包更贴合你的个人或团队需求。7.1 创建你自己的契约模板变体项目提供的project-contract-template.md是一个很好的起点但你可能需要针对不同类型的项目进行调整。针对移动端应用可以增加“移动端特定约束”部分包括手势支持、离线模式、推送通知集成策略等。针对内容型网站可以强化“SEO 规则”和“内容管理系统CMS集成”部分。针对内部工具可以增加“数据源与 API 集成规范”、“权限模型RBAC”等部分。操作步骤复制一份原模板根据你的常见项目类型进行章节的增删改。将这个自定义模板保存在你的知识库中下次启动类似项目时直接使用。7.2 将契约与你的设计工具链连接Figma/即时设计在契约的“设计系统就绪度”部分直接粘贴你的设计系统文件链接。一些 AI 工具如 Cursor已经能够解析 Figma 链接来获取颜色、字体等信息。你还可以将生成的“UX 结构”直接转化为设计稿的页面框架。组件文档工具如 Storybook在“技术架构”部分可以约定组件文档的编写规范和存放位置。让 AI 在生成组件代码时同步生成基础的 Storybook story 文件。7.3 建立契约的质量检查清单为了确保每次生成的契约都足够扎实可以为自己建立一个简单的检查清单在契约生成后逐项核对[ ]问题陈述是否清晰、不含解决方案[ ]用户画像是否具体到足以指导设计决策[ ]核心流程是否涵盖了用户从入门到完成核心任务的全过程[ ]技术栈是否精确到库和主要版本[ ]约束条件是否可衡量如具体的性能指标[ ]设计系统/资产就绪度的描述是否能让开发者/设计师明确知道该做什么[ ]执行规则是否包含了代码风格、提交规范等工程实践这套 AI Execution Contract 框架的精髓在于它将人类擅长的战略性、框架性思考与 AI 擅长的细节性、执行性工作完美地结合了起来。它迫使你在前期投入必要的思考以换取整个构建过程中数十倍的时间节省和方向确定性。最开始使用时会觉得步骤稍显繁琐但一旦形成习惯你会发现它从根本上提升了与 AI 协作的愉悦感和产出质量。这不仅仅是给 AI 用的契约更是给你自己的一份产品思维训练手册。