1. 项目概述一种全新的AI协作范式如果你和我一样每天都在和AI打交道从写代码到做规划那你肯定也经历过这种时刻你有一个模糊的想法扔给AI它给你吐出一大段代码或者一个冗长的计划。你看着这堆东西总觉得哪里不对劲但又说不上来。问题出在哪AI替你做了太多决定而你却失去了对整个过程的掌控感。你得到的只是一个结果而不是一个经过深思熟虑、每一步都清晰可见的思考过程。这就是我最初接触Decision Kit时的感受。它不是一个帮你写代码的工具也不是一个帮你生成文档的助手。它是一个思考伙伴一个专门用来“做决策前准备工作”的系统。它的核心哲学极其简单却又无比深刻AI负责探索和呈现选项人类负责判断和拍板。这个看似简单的分工彻底改变了我和AI协作的方式。想象一下你想做一个社区工具共享应用。传统流程是你写一个详细的PRD产品需求文档或者直接给AI一个模糊的提示然后等待它生成一个可能很庞大、也可能很片面的方案。而使用 Decision Kit你只需要输入/decide I wanna make a tool-sharing app for my neighborhood。接下来发生的事情会让你重新理解“协作”这个词。AI不会直接给你一个应用。它会先停下来反问你“等等在写第一行代码之前我们是不是得先想清楚邻里之间如何建立信任” 它会为你生成一个完整的决策页面在浏览器里打开清晰地展示出建立信任的几种可行方案是做一个信誉评分系统还是采用押金模式每种方案都有可视化的流程图、详细的利弊分析Pros Cons和一个并排对比的表格。它甚至会给一个推荐选项。但最终选择权在你手里。你点击一个选项告诉AI你的理由。然后它才会基于你这个选择引出下一个关键决策比如“工具损坏的责任如何界定” 或“预约系统应该怎么设计”这个过程就是Decision Driven Development决策驱动开发。它认为无论是软件还是其他任何复杂事物其构建过程本质上是一系列决策的串联。Decision Kit 的目标就是让这些决策变得结构化、可视化、可追溯。你不是在和一个黑箱对话而是在一个清晰的决策流水线上与AI并肩工作。每一个决策都变成一个实实在在的“工件”Artifact——一个可以随时打开、回顾、分享的HTML页面保存在项目的.decisions/文件夹里。几个月后当新成员加入或者你忘了当初为什么选择某种技术方案时答案就在那里历历在目。这套系统特别适合产品经理、创业者、独立开发者以及任何需要在高不确定性环境中做出复杂决策的从业者。它把我们从“拍脑袋”和“盲目执行”中解放出来提供了一种系统性的、人机协同的思考框架。接下来我将深入拆解它的设计思路、核心组件以及我是如何将它融入实际工作流的。2. 核心架构思考与执行的清晰边界Decision Kit 的威力源于其极其清晰和坚定的架构哲学。它将整个决策流程严格划分为两个领域思考和执行并通过一个名为“决策”的门控机制将它们分开。理解这个架构是高效使用它的关键。2.1 两大技能类型各司其职系统内置了多种“技能”但它们都严格归属于以下两类1. 思考技能只探索不执行思考技能的职责是为你做决策前的所有准备工作。它们像是你的高级研究助理和策略顾问。当你抛出一个问题或想法时思考技能会识别关键决策从你的模糊描述中提炼出5-7个可配置最核心、影响最深远的决策点并按重要性排序。搜集背景信息基于你配置的研究源自动搜集相关市场、技术或案例信息。生成可视化选项为每个决策生成多个通常是4个具体的、可视化的选项。这可能是UI线框图、系统架构图、商业模式画布、流程图等。分析利弊为每个选项列出客观的“优点”和“缺点”并生成多维度的对比表格。给出建议基于分析提供一个推荐选项。然后它就停下来了。它会打开一个决策页面等待你的判断。它永远不会替你按下“执行”按钮。它的全部工作就是让你的判断尽可能明智。2. 执行技能只执行不思考执行技能是纯粹的行动派。它们只做一件事读取你已经做出的决策存储在.decisions/文件夹中的结构化记录然后生成相应的交付物。输入你的决策记录。输出路线图、发布计划、任务简报、代码框架等。执行技能不会质疑你的决策也不会提出新选项。它们忠实地将你的思考成果转化为可操作的下一步。2.2 决策门控人类意志的体现“决策”本身就是这个系统中的门控。它是由思考技能生成、经你确认后保存下来的那个HTML页面。这个页面包含了问题的上下文、所有被考虑的选项、你的最终选择以及你提供的理由。关键理解在Decision Kit的流程中没有任何事情可以绕过人类的判断而自动推进。思考技能必须等待你做出选择并保存决策后这个决策才会成为后续步骤的合法输入。这强制了“人在回路中”的原则确保了最终产物的所有权和意图清晰度。2.3 决策复合上下文的无损传递这是Decision Kit最强大的特性之一决策会复合。每个技能无论是思考还是执行在运行时都会自动读取之前所有相关的决策记录。例如一个典型的产品开发流程可能是你运行/product-strategy思考技能决定了产品的目标用户和核心价值主张。你运行/product-design思考技能。它不会再问你“目标用户是谁”因为它已经从第一步的决策记录中读到了。它直接基于这个上下文开始和你讨论技术选型、UI框架等设计决策。你运行/ticket-breakdown思考技能来拆解一个具体功能。它读取了前两步的所有策略和设计决策因此生成的实现方案如API设计、数据库 schema是高度贴合既定方向的。最后你可以将整个.decisions/文件夹交给一个AI编程工具如 Cursor, Claude Code让它生成代码。此时AI拥有完整的“决策上下文”写出的代码与你的整体构思一致性极高。这种复合效应就像为思考过程加上了“复利”。你永远不会从零开始每一次决策都为下一次提供了更丰富、更精确的输入极大地减少了信息损耗和重复沟通。3. 核心技能深度解析与实战要点Decision Kit 提供了一套丰富的技能覆盖从战略到落地的全流程。掌握每个技能的使用场景和技巧能让你如虎添翼。我将重点剖析几个最常用、也最能体现其设计哲学的核心技能。3.1 入口技能/decide及其变体这是大多数人的起点。你不需要知道该用哪个具体技能只需把想法说出来。基本用法/decide I want to build a daily briefing app for my calendar幕后机制系统内置一个“调度器”会分析你的语句判断其意图是产品创意、商业问题还是生活决策然后自动路由到最合适的思考技能如/product-strategy,/strategize。实战技巧描述问题而非解决方案与其说“做一个用React和Supabase的看板应用”不如说“我想管理我的个人项目但讨厌现有的复杂工具”。让AI帮你探索“做什么”和“为什么”而不是预设“怎么做”。利用变体控制决策粒度/overdecide [主题]生成8-12个决策。适合极其重要的、开创性的项目你需要审视每一个角落。/underdecide [主题]只生成2-3个最关键的决策。适合时间紧迫或你对次要决策已有成熟惯例的情况。/autodecide [主题]AI自动为每个决策选择其推荐选项最后生成一个批量审核页面让你一次性确认或推翻。这极大地加快了探索速度同时保留了最终控制权。你甚至可以组合使用如/overdecide /autodecide [主题]进行快速而全面的扫描。3.2 战略与设计基石/product-strategy与/product-design这对组合是产品从0到1的黄金搭档。/product-strategy定义“是什么”和“为什么”这个技能专注于回答产品存在的基本问题。它会引导你做出以下类型的决策目标用户画像不仅仅是 demographics更是他们的核心痛点、现有解决方案和未被满足的需求。核心价值主张我们究竟在为什么样的用户解决什么样的关键问题带来什么样的独特价值市场定位与竞争我们如何与众不同是性能更好、更易用、更便宜还是服务于一个完全被忽视的细分市场商业模式如何创造和捕获价值是订阅制、一次性付费、交易抽成还是其他成功指标我们如何衡量成功是用户增长、收入、参与度还是其他避坑指南很多团队会跳过战略决策直接进入功能讨论。这会导致产品缺乏焦点和一致性。强制使用/product-strategy能确保团队在动手前至少在核心战略层面达成共识并留下可追溯的记录。/product-design定义“怎么做”在战略清晰之后/product-design接手将战略转化为具体的设计和技术方案。它的决策包括技术栈选型前端框架、后端语言、数据库、部署平台等。AI会基于你的战略例如“要求快速原型验证” vs. “要求高并发稳定”给出不同的选项组合。信息架构与核心用户流程用户如何导航关键任务如注册、发布内容、支付的流程是怎样的视觉设计方向整体风格是极简、专业、活泼还是复古这里它提供的是方向性选择例如“现代极简主义”或“温暖亲和力”。核心组件设计对于关键UI元素如卡片、导航栏、表单的设计语言。两者的无缝衔接这是决策复合的完美体现。如果你先运行了/product-strategy并做出了“目标用户是时间紧迫的专业人士”的决策那么当你在/product-design中讨论“仪表盘设计”时AI生成的选项会天然倾向于“信息密度高”、“一目了然”、“支持快速操作”的风格而不会给出面向新手用户的、充满引导和动画的选项。上下文自动传递决策环环相扣。3.3 工程实践利器/ticket-breakdown与/self-code-review这对组合将决策思维带入了日常开发工作流能显著提升代码质量和开发效率。/ticket-breakdown从工单到实施计划收到一个功能需求或Bug修复工单时不要立刻开始编码。先运行/ticket-breakdown Add OAuth2 login with Google and GitHub providers。 它会扫描你的代码库理解现有技术栈和模式然后引导你完成“适应性五问”范围与边界这个工单的明确范围是什么有哪些模糊地带需要澄清例如“社交登录的头像和用户名是否同步到用户资料”实施方案具体如何实现参考项目中的哪些现有模式或文件需要创建哪些新模块测试策略需要哪些类型的测试单元、集成、端到端测试哪些关键路径和边缘情况PR计划是作为一个大PR还是拆分成多个小PR提交的顺序是什么最小的可交付单元是什么风险与陷阱实现过程中可能遇到哪些技术风险对现有系统有何潜在影响回滚方案是什么这个过程产生的implementation-plan.md文件是一个极佳的、包含上下文的“迷你规格说明书”不仅指导你自己编码也极大方便了后续的代码审查。/self-code-review提交前的最后一道防线在代码写完后、提交PR之前运行/self-code-review。它会基于你的代码变更、整个代码库的上下文以及之前的任何相关决策比如来自/ticket-breakdown的实施计划进行多维度的自动化审查并生成可视化的评估报告范围漂移检查你写的代码是否超出了原定工单的范围架构契合度新代码是否符合项目的整体架构模式和约定测试充分性新增的测试是否覆盖了核心逻辑和边缘情况复杂度与可读性代码是否过于复杂命名是否清晰PR就绪度提交信息是否清晰变更集是否合理每个维度都会给出“绿色通过”、“黄色警告”或“红色问题”的评级并附上具体的代码引用和建议。这相当于一个不知疲倦的、知识渊博的结对编程伙伴在你把代码暴露给同事之前帮你先过滤掉一大批低级错误和设计瑕疵。3.4 遗产代码救星/excavate与/journal面对一个陌生的、文档匮乏的遗留代码库是每个开发者的噩梦。Decision Kit 提供了考古学工具。/excavate挖掘被埋葬的决策运行/excavate它会像考古学家一样分层扫描你的代码库表层package.json,docker-compose.yml依赖项——揭示了技术选型。结构层路由结构、数据模型、中间件——揭示了应用架构。模式层错误处理方式、状态管理、测试结构——揭示了工程哲学。意义层UI交互模式、特定的业务逻辑——甚至能推断出一些产品或业务决策。它会将挖掘出的“隐藏决策”呈现给你确认。例如“项目选择使用JWT而非Session Cookies进行认证”、“所有错误通过一个中央中间件处理并记录到Sentry”、“用户注册需要邮箱验证但密码重置不需要”。确认后这些决策就被正式记录到.decisions/文件夹从此变得可见、可管理。/journal决策的演进史决策不是一成不变的。/journal技能让你可以记录决策的演变过程。例如当你发现早期“目标用户是都市租客”的决策不再正确时可以运行/journal our target user ended up being suburban homeowners, not urban renters系统会生成一个新的决策页面来记录这个变化并清晰地展示决策的“成熟度”早期草图只有选择没有或只有很少的理由。已确定有明确的理由支持。已演进有理由并且有完整的历史变更记录。这为团队知识库的构建提供了动态的、可追溯的基础。4. 实战工作流从灵光一现到可执行代码理论说得再多不如看一个完整的实战案例。假设我是一个独立开发者想做一个帮助自由职业者管理项目报价和合同的小工具。以下是我使用 Decision Kit 的全过程记录。4.1 阶段一战略探索与定义我打开终端进入我的项目目录启动 Decision Kit 环境。第一步用/decide开启对话我输入/decide I need a simple tool to help me, a freelancer, generate quotes and manage contracts for my projects.系统识别出这是一个产品创意自动路由到/product-strategy技能。第一个决策页面弹出“谁是核心用户他们的首要痛点是什么”选项A“新手自由职业者”- 痛点对报价没概念怕报低价亏了报高价丢客户。需要大量模板和指导。选项B“经验丰富的自由职业者/小型工作室”- 痛点项目多重复劳动多每次都要改模板容易遗漏条款需要效率和专业度。选项C“特定行业从业者如设计师、开发者、写手”- 痛点行业有特殊条款如知识产权归属、修订次数限制通用工具不适用。推荐选项B基于我的描述“help me”和“manage”推断我已非新手更关注效率。我的选择我选择了B并在理由框中输入“我本人就是这类用户痛点抓得准。市场可能也更大因为新手最终会成长为资深者。”第二个决策页面“产品的核心价值主张是什么”基于我选择了“资深自由职业者”AI生成的选项也随之聚焦选项A“从模板库到签署的一站式平台”- 价值省去在多个工具间切换的麻烦。选项B“智能化的条款建议与风险提示”- 价值降低法律风险提升合同专业性。选项C“深度集成现有工作流如Calendly, Trello, QuickBooks”- 价值无缝融入现有习惯减少数据孤岛。我的选择经过权衡我选择了A。因为“一站式”对提升效率的感知最强且可以作为后续扩展B和C的基础。后续AI又引导我完成了关于商业模式一次性收费 vs. 订阅制、核心差异化极简设计 vs. 强大自定义、成功核心指标用户付费率 vs. 合同生成数量等决策。生成物在.decisions/文件夹下生成了strategy-freelancer-tool.html和对应的strategy-freelancer-tool.json。我的产品战略被清晰地结构化保存。4.2 阶段二产品设计与技术选型运行/product-design the v1 quote and contract manager we just plannedAI自动读取了上一步的战略决策。因此它不再询问用户和核心价值直接进入设计阶段。第一个设计决策“技术栈与架构”选项A“全栈JavaScript (Next.js Prisma PostgreSQL)”- 优势开发速度快前后端一致Vercel部署方便。选项B“Python后端 React前端 (FastAPI SQLAlchemy)”- 优势后端逻辑清晰生态成熟适合复杂业务规则。选项C“无服务器优先 (SST AWS Lambda DynamoDB)”- 优势几乎零运维按使用量付费自动扩展。推荐与我的选择考虑到我是独立开发追求快速上线和低成本运维我选择了C。AI基于这个选择在后续的“数据模型设计”、“认证方案”等决策中给出的选项都偏向无服务器模式如使用Cognito进行用户管理。第二个设计决策“核心用户流程与界面框架”AI生成了几个线框图选项展示了从“创建新报价”到“发送合同”的主要界面流。我选择了一个基于仪表盘侧边导航的清晰布局。生成物新增了design-v1-architecture.html和design-v1-ui-flow.html等决策文件。我的技术选择和产品形态得以确定。4.3 阶段三功能实施与代码生成现在我要开始实现第一个核心功能“创建一份报价单”。运行/ticket-breakdown Implement the ‘Create Quote’ feature for v1AI扫描我的项目目前只有一些决策文件和基础配置结合之前的“无服务器架构”和“仪表盘UI”决策生成了详细的实施计划。它引导我做出的关键实施决策包括范围v1的报价单包含项目描述、服务项列表名称、描述、单价、数量、总计、有效期、基础条款。排除复杂的税率计算、多货币支持、客户电子签名v2。API设计设计一个POST /api/quotes端点使用SST的API构造器。数据验证使用Zod。前端组件创建一个可复用的QuoteForm组件包含动态增减服务项的行内编辑。状态管理由于是无服务器且页面不复杂优先使用React状态 通过API与后端通信暂不引入全局状态库。测试策略为QuoteForm组件编写单元测试React Testing Library为POST /api/quotes编写集成测试。生成物implementation-plan-create-quote.md。这成了我的开发指南。开始编码我使用AI编程助手如Cursor将整个.decisions/文件夹作为上下文提供给它并给出指令“请根据我们的决策记录和实施计划实现‘创建报价单’功能。” 由于AI拥有了完整的上下文从战略到设计到实施细节它生成的代码质量非常高直接采用了我们选定的无服务器框架SST数据结构与设计决策一致组件命名也符合我们的约定。编码后自查代码写完后我运行/self-code-review。它指出我的QuoteForm组件中有一个输入框缺少对非数字字符的过滤一个黄色警告并建议为API响应添加更明确的错误类型。我根据提示进行了修改。4.4 阶段四决策的维护与演进几周后我收到用户反馈他们希望报价单能支持“折扣”字段。这是一个对原有决策的修改。运行/journal We need to add a ‘discount’ field (percentage or fixed amount) to the quote, applied before the final total.AI生成一个新的决策页面记录这个功能演进。它会链接到受影响的旧决策design-v1-ui-flow和implementation-plan-create-quote并提示我可能需要更新相关文件和测试用例。整个流程下来我从一个模糊的想法到拥有一个架构清晰、决策可追溯、代码质量可控的项目原型。所有的思考过程都被固化下来不再是散落在聊天记录或我脑海中的碎片。5. 常见问题、配置技巧与避坑指南在实际使用中你可能会遇到一些疑问或挑战。以下是我总结的一些高频问题和实战技巧。5.1 安装与配置核心要点安装流程回顾与细节# 1. 克隆仓库 git clone https://github.com/jnemargut/decision-kit.git # 2. 安装技能假设你的AI助手技能目录在 ~/.skills/ cp -r decision-kit/thinking/* ~/.skills/ cp -r decision-kit/action/* ~/.skills/ cp -r decision-kit/configuration/* ~/.skills/ cp -r decision-kit/orchestrator/* ~/.skills/注意确保你的AI助手如Claude Desktop, Cursor已正确配置并识别~/.skills/目录。不同工具的技能安装路径可能不同请查阅对应文档。关键配置技能/whoiam务必首先运行。用15秒告诉系统你的角色如“全栈开发者”、“产品经理”、“创业者”和对当前领域的熟悉程度。这会让AI生成的选项描述、类比和权衡维度更贴合你的认知水平大幅提升沟通效率。/research-sources配置AI在为你搜集背景信息时参考哪些来源。你可以指定信任的科技媒体、学术数据库、特定论坛等。这能确保决策所依据的信息质量。5.2 决策疲劳与流程优化问题即使是5-7个决策如果每个都深思熟虑也可能让人感到疲惫。解决方案善用/autodecide在探索性阶段或当你对某个领域比较有把握时使用此模式快速获得一个“草案”方案然后集中精力在最后的批量审核页面上进行修正。明确“决策阈值”不是每个决策都需要同等程度的精力。对于低风险、可逆的决策如某个按钮的颜色可以信任AI的推荐或快速选择。对于高风险、不可逆的决策如核心数据模型、技术栈则投入更多时间。分阶段进行不要试图在一个会话中完成从战略到代码的所有决策。可以今天做战略 (/product-strategy)明天做设计 (/product-design)后天拆解任务 (/ticket-breakdown)。让决策在脑海中沉淀一下有时会有新的灵感。5.3 与现有工作流和工具的整合问题Decision Kit 生成的.decisions/文件夹如何与 Git、项目管理工具如Jira, Linear协同实践建议Git版本控制将.decisions/文件夹纳入版本控制。这样决策的演变历史就和代码的提交历史绑定在一起。查看某次代码提交时也能看到当时是基于什么决策做出的改动。与项目管理工具的联动通过Hooks虽然Hooks功能尚在早期但其设计理念很清晰。理论上你可以配置一个Hook将每个确认的决策自动创建为项目管理工具中的一个“决策记录”工单并链接到相关的功能工单。这建立了从“为什么这么做”到“具体做什么”的可追溯链条。作为AI编程工具的超级上下文这是目前最成熟、价值最高的整合。无论是使用 Cursor 的“/ask”功能还是 Claude 的长时间对话在开始编码前将整个.decisions/文件夹的内容作为上下文提供给它。你会发现AI的理解深度和代码相关性有质的飞跃。5.4 处理分歧与团队协作问题在团队中使用时如果对某个决策选项有分歧怎么办解决方案利用决策页面作为讨论基础将生成的决策页面HTML分享给团队成员。由于所有选项、利弊、对比都清晰罗列讨论可以聚焦在事实和逻辑上而非个人的模糊感觉。运行/challenge技能在做出重要决策后运行此技能。它会像一个公正的顾问检查你的决策集中是否存在矛盾、假设是否未经检验、是否有信息缺失。这能为团队讨论提供额外的视角。记录分歧与最终理由在决策页面中除了选择最终选项务必在“理由”框中详细记录为什么选择这个以及为什么放弃那个。特别是记录下团队讨论中反对意见的主要论点。这为未来的复盘和可能的决策反转提供了宝贵依据。5.5 性能与规模考量问题.decisions/文件夹会随着项目增长变得很大会影响AI读取上下文的速度吗经验之谈结构化存储是优势JSON和HTML格式的决策记录远比散乱的会议纪要、聊天记录或长篇文档更容易被AI解析和检索。现代AI模型的上下文窗口正在不断增大容纳一个中等规模项目的所有决策历史通常没有问题。选择性提供上下文对于非常庞大的项目在让AI处理某个具体任务时如/ticket-breakdown可以手动指定只提供与之最相关的几个决策文件作为上下文而不是整个文件夹。定期“决策摘要”可以定期如每个里程碑运行/brief技能生成一个当前所有关键决策的摘要页面。这个摘要可以作为更高层次的入口点供快速查阅。Decision Kit 不是一个魔法棒它是一套严谨的思维体操装备。它要求你投入思考但回报给你的是清晰的思路、可追溯的决策和真正意义上的人机协同。它改变了我和AI的关系——从“下达指令与等待结果”变成了“共同探索与共同决策”。当你开始习惯在行动前先和AI一起把关键决策想清楚、记下来时你会发现无论是构建软件还是处理复杂问题路径都变得前所未有的清晰和扎实。