使用提案会话将主意转化为代码
提案会话适合处理“不能只靠一句 prompt 直接开改”的需求。它会先把主意整理成目标、范围、任务和验证方式，再进入真正执行。对于跨仓库修改、需要复盘的需求，或者你希望 AI 先讲清楚再动手的场景，这通常是更稳的入口。
先决条件
开始提案会话前，建议先完成以下准备：
- 已完成 Desktop 安装
- 已完成 初始化向导设置，并创建至少一个项目
- 已对当前项目有基本了解；若还没有，可先阅读 创建普通会话
提案会话适合做什么
提案会话更适合这些任务：
- 需要先确认影响范围，再开始修改
- 涉及多个仓库、多个模块或多个交付物
- 需要把任务拆解成可检查的步骤
- 希望保留变更理由、过程和结果，方便后续复盘
如果你的目标只是先理解代码、解释某个模块，普通会话更轻；如果你已经明确要按结构化流程推进，请继续往下看。
流程概览
当前提案会话可概括为下面 4 个阶段：
| 阶段 | 用户动作 | 系统结果 |
|---|---|---|
| 新建提案 | 打开 New Idea 抽屉并输入需求 | 生成受项目与仓库范围约束的提案入口 |
| 确认结构 | 查看提案详情中的步骤、状态与执行上下文 | 让 AI 先把目标、任务与验证讲清楚 |
| 跟踪推进 | 在会话看板中查看待处理、进行中与归档状态 | 便于同时推进多条提案或多次执行 |
| 回看结果 | 在完成视图中回看提交说明与会话记录 | 方便继续复用这次变更产出 |
步骤 1：从 New Idea 抽屉定义这次变更
当前创建提案的入口是 New Idea 抽屉。这里不会只让你输入一句模糊描述，而是要求你先把这次请求绑定到明确的项目与仓库范围上。
这一屏最值得先看的部分有：
- 项目选择器：先确认本次提案属于哪个项目
- 仓库范围：选择这次要参考或编辑的仓库
- 预览区：在真正提交前，先检查系统理解到的目标范围
- 需求输入框：用自然语言写清楚这次想解决什么问题
如果你的需求会同时影响文档、前端和后端，就应当在这一步把范围先圈清楚，而不是等 AI 进入执行后再临时补充。
步骤 2：在提案详情里先看清目标、步骤和状态
创建完成后，提案会话不会直接跳到“开始改代码”。它会先进入带工作流状态的详情视图，把本次变更的目标、步骤和当前执行状态放在同一个页面中。
这张图最适合用来理解提案会话和普通会话的差别：
- 中央区域不只是对话，还会展示与提案执行直接相关的说明
- 顶部工作流步骤条会明确告诉你当前走到哪里
- 左侧会话列表与右侧详情区一起保留上下文，不容易在长任务中迷路
如果你发现这里的目标、范围或步骤描述还不准确，应该先修正提案，再继续推进。提案会话的价值就在于把“先想明白”做成正式流程。
步骤 3：在会话看板里跟踪多条提案的推进状态
当项目里同时存在多条提案、多个执行轮次，或者你需要区分待处理、执行中与已归档的内容时，会话看板会更直观。
在这个视图里，你通常可以更快完成 3 件事：
- 判断哪条提案还没开始，哪条已经进入执行
- 对比多个会话的推进节奏，而不是逐个点开确认
- 及时把已结束的内容归档，保持工作台清晰
如果你的工作方式更偏“同时推进多条线”，看板会比单条详情页更适合当日常总览。
步骤 4：完成后回看这次执行产物
当提案走到后期，你通常会需要的不只是“它做完了”，还包括这次到底改了什么、提交信息如何整理、后续还能不能继续接着做。
这个完成态视图适合用来做两类事情：
- 回看本次执行产出的提交说明与关键结果
- 基于已有上下文继续派生下一轮修改，而不是重新从零开始
也就是说，提案会话不是一次性的“生成器”。它更像一条可持续延长的工作流记录。
什么时候优先用提案会话
下列场景通常建议优先使用提案会话：
- 需求比较复杂，担心 AI 直接开改会跑偏
- 需要多人协作或后续评审
- 涉及多个仓库、多个模块或多个角色
- 想把执行过程和理由长期保留下来
如果任务很小，只需要先读代码再决定是否修改，普通会话通常更省步骤。