FRAME框架：为AI编程助手引入结构化协作流程，提升人机协作质量

1. 项目概述：当AI助手太快时，我们失去了什么？

你正和Claude Code并肩作战，试图修复一个棘手的Bug。你刚把问题描述清楚，它几乎在瞬间就给出了修复方案和测试代码。你看着屏幕上飞速滚动的代码行，心里却泛起一丝不安：“等等，它真的理解我的全部意图了吗？这个修复方案有没有考虑那个特殊的边界情况？我们是不是应该先讨论一下验收标准？”但Claude Code已经完成了任务，它正安静地等待下一个指令。这种“速度眩晕”感，正是我在深度使用AI编程助手几个月后，决心开发FRAME的起点。

FRAME不是一个试图让Claude Code变得更聪明的工具。恰恰相反，我故意让它“变慢”了。它的核心价值，是在AI那令人目眩的执行速度与人类对问题本质的审慎思考之间，强行插入一个结构化的“减速带”。它通过一套纯Markdown文件定义的“卡带”系统，为Claude Code赋予明确的角色（如需求工程师、架构师、QA工程师），并在每个关键决策点设置“关卡”，强制进行人工确认。没有复杂的安装流程，没有运行时依赖，更没有多智能体编排的炫技——它只是一个让你和AI在编码前先对齐“我们要建造什么”以及“怎样才算完成”的简单框架。

我最初的想法很简单：当任务本身是明确的、封闭的（比如一个已知的Bug修复），Claude Code的“快”是无与伦比的优势。但当任务模糊、充满决策点，或者其结果需要向他人解释时，这种“快”反而会成为负担。我们可能在不经意间，用极快的速度建造了错误的东西。FRAME要做的，就是把那本该发生在人类大脑中的、关于目标和范围的内部对话，外化成一个可追踪、可审计的协作流程。接下来的内容，我将详细拆解FRAME的设计哲学、核心机制、实操对比，并分享在真实项目中应用它的心得体会。

2. 核心问题诊断：为什么“快”有时是种诅咒？

在深入FRAME的细节之前，我们有必要先厘清它所针对的痛点。这不仅仅是关于Claude Code或某个特定AI工具，而是关于人类与高速AI协作时普遍面临的结构性挑战。

2.1 “上下文失忆”与决策漂移

想象一个典型的长时间会话：你从定义一个模块的接口开始，Claude Code快速给出了实现；你接着要求它添加错误处理，它照做了；然后你想到需要优化性能，它又生成了一版代码。40分钟后，你回看最初的接口定义，可能已经模糊不清。更糟糕的是，Claude Code本身也可能在漫长的上下文窗口中“遗忘”或混淆早期的决策。这种“上下文失忆”会导致项目目标在无形中发生漂移，你最终构建的东西与最初的设想南辕北辙。

FRAME的应对策略是“强制存档”。在每个阶段（如SHAPE阶段确定需求）结束时，它都会将达成共识的结论（例如，用Markdown写成的PROJECT.md）保存到磁盘。这不仅为Claude Code提供了清晰、持久的参考点，更重要的是，它为作为人类的你创建了一份不可篡改的“决策日志”。当后续出现疑问时，你可以随时回溯到这些存档文件，明确“我们当时为什么这样决定”。

2.2 模糊需求下的“建造即探索”陷阱

对于需求明确的任务（“修复函数X在输入Y时的崩溃”），AI可以直线冲刺。但大量实际工作，尤其是软件开发、内容创作和项目规划，始于模糊的需求（“我们需要一个提升用户参与度的功能”）。此时，如果直接进入“建造”模式，整个会话就变成了一场“建造即探索”的冒险。你和AI在黑暗中摸索，通过不断试错来厘清需求本身。这个过程效率极低，且极易产生大量需要返工的半成品。

FRAME通过严格的阶段划分来规避这个陷阱。它将一个会话明确分为五个阶段：SHAPE（塑形）、BREAKDOWN（分解）、DESIGN（设计）、BUILD（建造）、CHECK（检查）。最关键的是，在SHAPE阶段结束、任何代码或内容被创造之前，必须产出一份双方（你和AI）确认的“项目形状”文档。这迫使模糊的需求在动手前就必须变得清晰、可衡量。

2.3 验证缺失与“看起来正确”的幻觉

AI生成的代码或内容，在表面上往往非常“合理”和“完整”。它通过了语法检查，逻辑看似通顺。但这种“看起来正确”的幻觉是危险的。它可能遗漏了关键的边缘情况，可能误解了业务规则的细微之处，也可能采用了与项目整体架构背道而驰的实现方式。在传统的快速交互中，人类需要承担全部的、高强度的验证负担，而这在高速产出面前很容易力不从心。

FRAME在CHECK阶段引入了结构化的验证角色。例如，在sw-development卡带中，QA工程师角色会系统地将SHAPE阶段定义的“验收标准”映射到已编写的测试用例上，生成一个覆盖度表格。任何未被测试覆盖的验收标准都会高亮显示。这种机制将模糊的“检查一下”变成了可执行的、无遗漏的验证流程。

注意：FRAME不替代你的专业判断，而是增强它。它提供的不是“正确答案”，而是一个确保所有重要问题都被提出和讨论过的“过程保障”。最终的决定权，始终在每一个关卡处掌握在你的手中。

3. FRAME架构深度解析：极简主义下的精巧设计

FRAME的核心理念是“结构至上，工具极简”。它的整个架构可以用一句话概括：一个引擎，多个卡带，全部由Markdown驱动。下面我们来拆解这个看似简单实则精妙的设计。

3.1 引擎：单一文件的智慧

FRAME的“引擎”本质上是一个精心编写的Markdown文件（例如frame.md）。这个文件包含了Claude Code需要理解的所有会话流程逻辑、角色定义和关卡控制指令。它本身不执行任何代码，而是作为一份“超级提示词”或“剧本”，指导Claude Code如何行为。

这种设计的优势显而易见：

1. 零依赖：任何能运行Claude Code的环境都能使用FRAME，无需安装Python、Node.js或其他任何运行时。
2. 完全透明：你可以打开frame.md，逐行阅读Claude Code将遵循的每一条指令。没有黑盒魔法。
3. 易于调试和定制：如果你觉得某个阶段的提示词不够好，直接编辑这个Markdown文件即可。调试过程就是阅读和修改文本。
4. 状态持久化：引擎指示Claude Code在每个阶段结束后，将关键输出（如PROJECT.md， 任务清单，设计文档）保存为工作目录下的物理文件。这实现了会话状态的持久化，即使你清空Claude的上下文或关闭会话，也能从上次的存档点继续。

3.2 卡带：工作流的可插拔定义

如果说引擎是播放器，那么卡带就是唱片。一个“卡带”定义了特定类型工作（如软件开发、代码审计、博客写作）的完整工作流。它本质上是一个包含特定Markdown文件的目录，这些文件扩展或覆盖了基础引擎中的角色和阶段定义。

以sw-development（软件开发）卡带为例，它可能包含：

• roles.md: 精确定义“需求工程师”、“协调员”、“架构师”、“开发者”、“代码评审员”、“QA工程师”等角色的职责和思考模式。
• phases.md: 详细说明SHAPE到CHECK每个阶段的具体产出物和通关条件。
• templates/: 存放PROJECT.md、DESIGN_DECISIONS.md等文档的模板。

卡带机制使得FRAME具备了强大的领域适应性。为博客写作设计的工作流（可能包含“选题策划”、“大纲撰写”、“初稿创作”、“SEO优化”、“校对”等阶段）与为代码审计设计的工作流截然不同，但它们共享同一个轻量级引擎。你可以直接使用官方提供的卡带，也可以利用cartridge-creator卡带，在不到一小时内为自己的特定工作流程创建定制卡带。

3.3 关卡控制：人类始终在驾驶位

这是FRAME与全自动AI工作流工具最根本的区别。FRAME中，阶段与阶段之间设有明确的“关卡”。例如，从SHAPE阶段进入BREAKDOWN阶段前，Claude Code会呈现生成的PROJECT.md并等待你的确认。你必须输入y（或约定的确认指令）后，它才会继续。

这个简单的机制带来了深远的影响：

• 强制反思点：它迫使你停下来，阅读并思考AI对需求的理解是否准确。这是一个低成本修正错误方向的绝佳机会。
• 上下文管理：你可以在确认一个阶段的输出后，使用Claude的/clear命令清空上下文，以节省Token，然后通过/frame load [cartridge]重新加载FRAME和已保存的存档文件，无缝继续。关卡成为了天然的上下文分界点。
• 节奏控制：你可以随时在关卡处暂停会话，去开会、思考甚至睡一觉，回来时整个项目状态清晰可循。

4. 实战对比：一次Bug修复的两种旅程

理论说得再多，不如一次真实的对比。我设计了一个实验：用同一个代码库、同一个起始分支、同一个提示词，去修复同一个Bug。一次使用原生的Claude Code（“极速模式”），一次使用FRAME配合sw-development卡带（“结构化模式”）。这个Bug是：一个名为_get_daily_limit()的函数，当环境变量NOTEBOOKLM_DAILY_LIMIT被设置为非数字值或零时会崩溃。

4.1 极速模式：Claude Code的单刀直入

我的提示词很简单：“修复_get_daily_limit()函数，当NOTEBOOKLM_DAILY_LIMIT设为非数字或零时它会崩溃。修复它并添加测试。”

过程如下：

1. 读取与理解：Claude Code快速读取了相关文件，理解了函数逻辑。
2. 实施修复：它直接修改了函数，添加了类型检查和默认值处理（例如，无效输入时返回默认值50）。
3. 编写测试：它生成了2-3个pytest测试用例，覆盖了非数字字符串、零等场景。
4. 提交代码：它生成了一条规范的commit信息，完成了任务。

耗时：约1分钟。结果：代码在功能上是正确的。修复方案合理，测试通过了。体验：流畅、高效、令人惊叹。对于这种定义明确、范围狭窄的任务，Claude Code是无懈可击的伙伴。它完美地执行了指令。

4.2 结构化模式：FRAME的审慎推进

同样的提示词，在加载/frame load sw-development后，会话性质彻底改变。

阶段一：SHAPE (塑形)Claude Code首先切换到了“需求工程师”角色。它没有立即去读代码，而是开始向我提问，以澄清需求的边界：

• “我们应该为这个修复创建一个新的Git分支吗？请提供分支名。”
• “除了修复崩溃，是否有其他硬性约束？比如性能要求、向后兼容性要求？”
• “具体的验收标准是什么？能否详细说明‘非数字值’包含哪些情况（空字符串、纯空格、字母数字混合）？‘修复’具体指不抛出异常并返回一个安全值吗？”
• “有没有明确排除在范围外的事情？比如，是否需要同时修改其他相关函数？”

经过几轮问答，它生成了一份PROJECT.md文件，内容结构清晰：

# 项目：修复 _get_daily_limit() 崩溃问题 **目标**：修复 `_get_daily_limit()` 函数，防止因环境变量 `NOTEBOOKLM_DAILY_LIMIT` 为无效值（非数字或零）而崩溃。 **技术栈**：Python 3.9+, pytest **分支**：`bugfix/daily-limit-validation` **约束**：无特殊性能或兼容性约束。 **验收标准**： 1. 输入为非数字字符串（如 `"abc"`, `"123abc"`）时，函数应返回默认值50，且不抛出异常。 2. 输入为字符串 `"0"` 时，函数应返回默认值50，且不抛出异常。 3. 输入为负数字符串（如 `"-5"`）时，函数应返回默认值50，且不抛出异常。 4. 输入为有效正整数字符串（如 `"100"`）时，函数行为保持不变，返回100。 5. 至少为上述每一种无效输入情况编写一个测试用例。 **范围外**：不修改其他函数，不进行接口重构，不改变函数签名。

系统在此处设置了一个关卡。我必须仔细审阅这份文档，确认它完全符合我的期望。我注意到它对“非数字”的解读比我最初想的更周全（包含了负数和空格），我表示认可并输入y确认。

阶段二：BREAKDOWN (分解) & DESIGN (设计)角色切换为“协调员”和“架构师”。它将目标分解为两个工作单元：1) 修改函数实现；2) 编写测试套件。并简要设计了实现方案：使用try-except进行转换，并在except块和值为零时返回默认值。这个过程很快，但产生了明确的计划文档。

阶段三：BUILD (建造)角色切换为“开发者”。它依次执行每个工作单元，生成代码。代码质量与“极速模式”下相当。

阶段四：CHECK (检查)这里出现了关键差异。角色先后切换为“代码评审员”和“QA工程师”。

• 代码评审员检查了代码风格、潜在错误和与设计的一致性。
• QA工程师做了一件至关重要的事：它创建了一个验收标准覆盖矩阵。它列出SHAPE阶段定义的所有5条验收标准，并映射每条标准到具体的测试用例。

然后，它进行了差距分析：“根据常见边界情况分析，我们可能遗漏了对‘空字符串’和‘纯空格字符串’的测试。虽然AC-1（非数字字符串）在逻辑上可能涵盖它们，但建议显式添加测试用例test_empty_string和test_whitespace_only_string以增强鲁棒性。”

耗时：约10分钟。结果：代码功能同样正确，但多了一份详细的PROJECT.md设计文档、一份清晰的验收覆盖矩阵，以及一个关于空白字符测试的重要建议。体验：过程更具对话性和反思性。最终的产出不仅是一个修复，更是一份完整的、可追溯的“工作包”。

4.3 对比分析：速度 vs. 清晰度

• 原生Claude Code：像一位技艺高超、但不太爱说话的工匠。你把图纸（需求）给他，他立刻埋头工作，一分钟后就交给你一个完美的零件。你信任他的手艺，但你不完全确定他是否理解了这个零件在整台机器中的用途。
• FRAME + Claude Code：像一位严谨的项目经理带领一个专业团队。他先和你一起评审并签字确认图纸（SHAPE），然后让规划师拆解任务（BREAKDOWN），让设计师确认细节（DESIGN），再由工匠制作（BUILD），最后让质检员对照图纸逐项检查（CHECK）。花了十分钟，但交付时附上了完整的质检报告和图纸变更记录。

对于这个简单的Bug修复，“极速模式”无疑效率更高。那十分钟的“开销”看起来像是浪费。但请仔细看，这十分钟里真正“写代码”的时间可能只有两分钟，其余八分钟花在了沟通、澄清和建立共识上。对于复杂任务，这八分钟能避免后续八小时甚至八天的返工。

5. FRAME适用场景与实操指南

FRAME不是万能的。明智地选择使用它的时机，才能最大化其价值。以下是我总结的适用与不适用场景，以及具体的上手步骤。

5.1 何时应该使用FRAME？

1. 需求模糊或存在歧义时：当你对“到底要做什么”只有大致概念时（例如，“优化这个页面的用户体验”），FRAME的SHAPE阶段能帮你把模糊的想法转化为具体、可衡量的目标。
2. 重返陌生代码库时：面对一个六个月没碰过的项目，你的记忆已经模糊。使用codebase-analysis卡带或从一次结构化的FRAME会话开始，能系统性地重建上下文，避免盲目修改引入新问题。
3. 需要生成审计或评估报告时：例如进行安全审计、代码健康度评估。code-audit卡带能确保你的检查全面、有据可查，最终产出结构化的发现列表和证据，方便向他人汇报。
4. 进行复杂项目规划时：project-planner卡带能引导你将一个宏大的目标（如“开发一个微服务”）分解为有序的、依赖关系明确的任务列表，避免一开始就陷入细节。
5. 需要过程留痕和知识传承时：当你的工作成果需要交付给客户、同事或未来的自己时，FRAME产生的全套文档（项目定义、设计决策、验收矩阵）是无价的。它回答了“我们做了什么”以及“我们为什么这样做”。

5.2 何时可能不需要FRAME？

1. 简单、明确的原子性任务：如重命名变量、格式化代码、编写一个简单的工具函数。原生Claude Code的快速交互更合适。
2. 探索性、实验性的编码：当你只是在快速验证一个想法或原型，失败成本很低时，不需要完整的过程。
3. 时间极度紧迫的救火任务：首要目标是快速恢复服务，事后复盘时再用FRAME来记录和分析。

5.3 一步步上手FRAME

1. 获取FRAME：

   git clone https://github.com/SeriousByDesign/frame.git cd frame bash install.sh

   这通常只是将frame脚本复制到你的某个可执行路径下。

2. 开始一个新会话： 在你的项目目录中，像往常一样启动Claude Code。然后，输入：

   /frame load sw-development

   你会立刻看到Claude Code的响应风格变了，它开始以“需求工程师”的口吻与你对话，引导你进入SHAPE阶段。

3. 与关卡交互：

   • 在每个阶段结束时，仔细阅读Claude Code生成的摘要或文档。
   • 如果同意，输入y或yes继续。
   • 如果需要修改，直接提出你的反馈（例如，“验收标准还需要加上对None值的处理”）。Claude Code会根据你的反馈更新文档，并再次等待你确认。
   • 你可以随时输入/frame status查看当前处于哪个阶段。

4. 管理上下文与暂停：

   • 在一个阶段确认后，如果你想清空上下文以节省Tokens，可以放心使用/clear。
   • 之后，只需再次输入/frame load sw-development，FRAME引擎会读取之前阶段保存到磁盘的存档文件（如PROJECT.md），自动恢复到正确的阶段，你可以继续工作。

5. 探索其他卡带：

   • 查看可用卡带：通常可以在FRAME的仓库或文档中找到列表。
   • 加载不同卡带：/frame load blog-writing会开启一个博客写作工作流，角色和阶段都会相应变化。

5.4 自定义你的工作流

FRAME最大的潜力在于其可定制性。如果你发现某个卡带的某个阶段提示词不符合你的团队习惯，或者你想为一个内部特定流程（如“数据库迁移审查”）创建卡带，可以：

1. 使用cartridge-creator卡带，它会引导你一步步定义新卡带的角色、阶段和模板。
2. 或者直接手动复制一个现有卡带目录（如sw-development），然后修改其中的Markdown文件。引擎文件（frame.md）通常不需要动。
3. 关键文件是roles.md和phases.md。你可以在这里用自然语言描述你希望AI在每个角色、每个阶段如何思考、提问和产出。

实操心得：不要试图在第一次就创建完美的卡带。先在一个真实的小项目上使用官方卡带，记录下所有让你觉得“这里要是能那样问就好了”或“这个产出格式不适合我们”的时刻。这些正是你自定义卡带时需要优化的地方。定制的过程，其实就是将你团队的最佳实践编码化的过程。

6. 与同类工具的差异化思考

市面上已经存在一些优秀的AI工作流编排工具，如SPARC、Claude-Flow等。它们功能强大，支持多智能体并行、复杂计划编排。FRAME与它们并非竞争关系，而是面向不同需求的选择。

FRAME的定位是“超轻量级结构化会话框架”，其设计哲学体现在几个关键取舍上：

1. 纯文本 vs. 复杂运行时：SPARC等工具通常是需要安装的Python包，有自身的运行时和API。FRAME只是一个脚本和一堆Markdown文件。它的启动和运行没有任何环境依赖，这降低了使用门槛和心智负担。
2. 线性流程 vs. 并行编排：FRAME严格遵循线性阶段（SHAPE -> BREAKDOWN -> DESIGN -> BUILD -> CHECK）。它不试图管理多个AI代理并行工作。这种简单性使得流程更容易理解和控制，特别适合需要深度思考、顺序推进的任务。
3. 人类中心 vs. 自动化中心：FRAME在每个关卡都强调人工确认。它的目标不是全自动完成任务，而是增强人机协作的清晰度和可控性。其他工具可能更倾向于在人类给出高层指令后，最大化自动化执行的程度。
4. 文档即流程 vs. XML/JSON计划：FRAME的所有中间状态和计划都保存在人类可读的Markdown文件中。而其他工具可能使用结构化的XML或JSON来定义复杂的计划。Markdown的优点是任何人都能立即阅读和编辑，无需学习特定语法。

如何选择？

• 如果你需要处理极其复杂、可分解为数百个子任务的项目，并且希望AI代理们能像流水线一样自动协同，那么SPARC、Claude-Flow这类功能丰富的框架可能更合适。
• 如果你追求的是在与AI结对编程或创作时，获得更多的控制感、过程透明度和可审计性，希望用一个极其简单的方式为会话注入结构，那么FRAME很可能是你的菜。
• 简而言之，FRAME是给你的AI会话加上“安全带”和“行车记录仪”，而不是给它换上“自动驾驶系统”。

7. 常见问题与故障排除

在实际使用FRAME的过程中，你可能会遇到一些典型情况。以下是我总结的FAQ和解决思路。

Q1: 加载卡带后，Claude Code没有按预期进入角色或阶段怎么办？A1: 首先检查是否在正确的项目目录下运行。FRAME依赖当前目录来存放和读取存档文件。其次，尝试输入/frame restart重新初始化当前卡带。如果问题依旧，检查你使用的Claude Code模型版本，极旧版本可能对长提示词响应不佳。确保你复制的是最新版本的FRAME文件。

Q2: 会话中途卡住了，或者AI的回应变得奇怪。A2: 这通常是Claude的上下文窗口过载或出现混淆的迹象。首先，尝试使用/clear命令清空上下文。然后，不要直接重新开始，而是再次输入/frame load [你的卡带名称]。FRAME引擎会读取磁盘上的最新存档文件（如last_state.md或阶段产出物），并试图恢复到中断的地方。这是FRAME状态持久化设计的核心优势。

Q3: 我觉得某个卡带里“需求工程师”问的问题太多余了，能跳过吗？A3: 当然可以，这就是自定义的意义。你可以直接编辑该卡带目录下的roles.md或phases.md文件，修改“需求工程师”的提示词，让它减少提问或按你的喜好调整提问方式。你也可以在会话中直接给出更明确的初始指令，比如在加载卡带后立刻说：“我们的目标是明确的，请直接基于以下详细需求生成PROJECT.md文档：……”，从而引导它跳过部分澄清环节。

Q4: FRAME产生的中间文件（如PROJECT.md）很乱，我可以整理吗？A4: 完全可以。这些文件是给你看的，也是给后续阶段AI看的。保持它们的清晰整洁对会话流畅度有帮助。你可以在关卡处，手动编辑这些Markdown文件，调整格式、修正错别字、补充要点，然后再确认进入下一阶段。AI会基于你修改后的最新文件继续工作。

Q5: 我能把FRAME用于其他AI编码助手吗？比如Cursor或通义灵码？A5: FRAME的核心是Markdown格式的“剧本”或“提示词流”。理论上，只要AI助手具备足够的上下文理解能力和文件操作能力，你可以尝试将FRAME的提示词逻辑适配过去。但官方目前主要针对Claude Code优化。其关卡控制（依赖Claude的指令如/clear）和文件操作命令可能需要调整才能在其他环境中完美工作。

Q6: 在团队中如何使用FRAME？A6: FRAME产出的标准化文档（PROJECT.md， 验收矩阵）是绝佳的团队协作工具。你可以：

• 在SHAPE阶段，邀请同事一起评审和确认PROJECT.md，确保需求对齐。
• 将CHECK阶段生成的验收覆盖矩阵作为代码审查的一部分，确保测试完整性。
• 将整个FRAME会话的存档文件作为项目交接文档，新成员可以快速理解代码变更的完整上下文和决策依据。

8. 个人实践心得与未来展望

使用FRAME几个月后，它已经彻底改变了我与Claude Code的协作模式。我不再把它仅仅当作一个“更快的打字员”，而是一个可以被有效引导的“思考伙伴”。最大的转变在于，我从“急于得到代码”变成了“乐于先厘清问题”。那十分钟的“塑形”时间，从感觉上的“开销”变成了实际上的“投资”。

我发现自己最常使用FRAME的场景，恰恰是那些我一开始觉得“应该很快能搞定”的中等复杂度任务。例如，为一个现有模块添加一个新特性。没有FRAME时，我可能会直接让Claude Code开始写，然后在实现过程中不断发现之前没考虑到的依赖、边界情况或设计矛盾，导致来回修改。有了FRAME，在SHAPE和DESIGN阶段的短暂停留，迫使我把这些潜在问题提前暴露并达成共识，后续的BUILD阶段反而变得异常顺畅和线性。

给新手的建议：不要在所有任务上都用FRAME。从一个小型但需求有点模糊的任务开始（比如“重构这个有点乱的工具函数，并提高其可测试性”）。完整地走一遍流程，感受每个阶段的价值。你会亲身体会到，那份在编码前就诞生的PROJECT.md和DESIGN_DECISIONS.md，如何像航海图一样指引整个会话，避免你迷失在代码的海洋里。

至于未来，FRAME作为一个开源项目，其生命力在于社区。cartridge-creator卡带已经降低了创作门槛。我期待看到更多针对特定领域的工作流卡带出现，比如“机器学习实验报告撰写”、“前端组件库开发”、“技术方案评审”等等。每个卡带都凝结了一个领域的最佳实践。

工具的终极价值，不在于它做了什么，而在于它让你成为了什么样的思考者和创作者。FRAME或许让AI“变慢”了，但它让我在构建复杂事物的过程中，思考得更快、更清晰、更自信了。这十分钟的“减速”，换来的可能是整个项目方向上“不翻车”的确定感，这笔交易，在我看来无比划算。如果你也在寻找一种更可控、更清晰、更具可重复性的AI协作方式，不妨克隆下那个仓库，从bash install.sh开始，亲自体验一下这种“慢下来”的智慧。