dashbear-ai/grant-master/auto

Grant Master

[直接启动工作台](../../start-workbench.cmd) · Linux/WSL：运行 python3 ../../workbench/launch.py。无需先请求 AI。

首次使用或恢复时明确告诉用户：主流程在 Codex 的 AI 对话框中进行，网页只作为报告展示、资料编辑和辅助交互。请配合 Codex 一起使用；AI 停止后，请回到此对话发送“继续”。

即使用户只是询问用法，也先运行插件的 workbench/launch.py --no-browser，读取它返回的 URL 并通过 mcp__codex_app__open_in_codex 在内置浏览器打开；不要只发链接或询问是否打开。用户明确不打开时尊重其选择。只问用法时介绍 Demo，不创建项目或启动研究。

研究原则

每次对话开始，hook 只检查小型修改索引；发现未读记录后，先运行 gm.py changes --project ID，按 more 逐页读到 false，理解并响应用户修改，再继续研究。没有 hook 提示时，恢复项目仍通过 context 核对 userRevision 与 changesReadRevision。读取回执仅表示已接收，不代表修改要求已经完成；把未完成工作说明留在研究报告或待办中，不通过手写状态绕过后端。

进入阶段时先读取 context 返回的 stageGuidance 中对应文件。这是网页“本阶段研究经验”展示的同一份长期共用指导；文献调研前运行 gm.py method --project ID，读取 Grant Master 固定检索入口及完整搜索协议（references/academic-search），再按需读取学科与站点资源。CLI 回执绑定入口和核心协议内容；修改后需重新读取。研究报告说明实际采用的方法步骤和证据范围，不能只说“已遵循”。方法只提供研究规则，其外部操作仍受用户授权与可用工具约束。

研究文件以工作台返回的项目目录为准，与 Codex 当前工作目录无关。用户新建项目默认位于 ~/.grant-master/<随机项目编号>/；位置可更改。原始资料、下载论文、候选稿和交付物都放入该项目，外部课题资料先导入副本。通用经验、调研方法、默认模板属于工具长期资产，直接读取 context 提供的共用路径，禁止复制进 projects；项目只记录方法来源和版本。只读取当前阶段需要的报告，需要核实具体论据时再追溯原件。

• 课题准备：先区分用户已有事实、你的假设和待确认事项。把宽泛主题收敛成研究对象、问题、条件和边界；尚未调研时不声称发现文献空白。
• 文献调研：使用 Grant Master 学术检索。先拟本轮问题与查询计划，再多源轻量筛选、核心论文全文核验、DOI/arXiv 去重和下载清单；方法来源及 MIT 声明见同目录 NOTICE.md。当前 AI 默认执行研究，只按需读相关参考，不强制启动 worker。检索报告与结构化清单通过 gm 发布到本项目 literature。每篇阅读报告解释研究问题、方法、关键结果、局限和启发，最新视角比较证据。
• 方案制定：围绕一条可验证主线，讲清问题为何值得做、已有方法为何不足、拟议方法为何可能有效，以及如何证伪。指标、资源和实验应匹配申请人条件，未确认条件不能写成已有基础。
• 大纲规划：以用户最新保存的修改为调整依据：字数规划、完整大纲 Markdown、单元规划都可能产生新意图，按 changes 序号理解先后。用户改字数时同步大纲与 unit；用户改完整大纲时可相应更新 allocations 与 unit；用户改单元时可反向协调章节配额与完整大纲。三者地位相同，不用某页的旧值压回最新修改。若修改间确有歧义，通过待办澄清。用户创建时设置体量，前期调研和方案据此控制范围；协调后通过 allocate、publish outline、plan-units 保存一致结果。完整大纲每个主要部分使用同级 Markdown 标题，并在其下标注 目标字数：N 字，发布时传当前 outlineStatus.revision 为 outline_revision。用户修改后的三个视图可暂时不同，AI 恢复后负责协调；不把网页不一致提示作为下一步入口。再为每节分配论证责任、证据和篇幅，并通过 plan-units 建立有序 unit 计划：每个单元具有章节、目标字数、目的、段落安排、证据和边界。章节引言、标题与叶子章节都要有明确归属，确认大纲前完成单元预算校验。大纲必须能读出完整推理链，避免重复背景、同一创新点多处改写以及空泛标题。
• 正文写作：依据已确认的 unit 计划逐单元写作，按 context 状态续写和返修；发布带单元计划版本，不重写已完成单元。全部完成后按计划 assemble 成完整 Markdown。审阅意见定位到单元，修订后重新组装；全文有人工编辑时先合并候选并确认覆盖版本。术语统一，首次解释缩写；事实、计划和预期效果分开；引用能追溯到项目资料。审阅、修订、组装与 DOCX 导出都属于本阶段。段落、标题、表格之间保留空行以保证导出排版。

与工作台合作

使用 workbench/gm.py 的 context 读取资产、校验状态和未处理回答。currentStage 表示最早需要重新验证的位置，不代表用户退回了研究阶段；先响应最新修改，不机械重跑已有研究。继续时先处理已提交回答和拒绝，处理完成后确认；已有问题继续等待原问题，不重复投递。用户只要求当前一步时止于该范围，要求完整流程时持续推进至交付。

内容交付及等待的具体命令见 工作台调用，按需读取。你只提供研究内容、判断和待确认的问题；项目状态、资产索引、版本和事件记录由后端创建和维护，不手写状态文件。

需要用户参与时向统一待办中心投递解释、背景、选项和自由输入，等待真实回答；用户拒绝不视为同意。网页保存动作不启动模型。回答在停止期间也会保留，下次恢复后接收。不能把“请去网页点击下一步”当作本次研究已完成。