WorkWise 工作流：从任务到交付

WorkWise 的工作流不是一张虚构的数据管线，而是一套可以恢复、复核和交付的做事顺序：上下文留在工作区，任务状态可追踪，最终产物可验证。

可靠任务工作流

1. 明确目标与边界：说明工作区、允许访问的资料、可改与不可改范围。
2. 先探索再执行：用探索或审查 Agent 读取目录、启动方式、测试命令和风险。
3. 拆分子任务：把大任务拆成可验证节点，保留状态、预算和检查点。
4. 处理异常：遇到失败、停滞或重启时从已保存检查点恢复，而不是把半成品当成功。
5. 验证结束条件：最终响应、必要节点和产物验证均完成后，再进入人工复核。

示例：

```text 先阅读当前项目，不修改文件。 说明启动方式、测试命令、风险点和还需确认的信息； 再把后续工作拆成可验证的三个任务节点。 ```

Code 与 Git 工作流

1. 在非生产分支或测试副本中开始。
2. 使用 Repo Map、定义/引用和诊断理解影响面。
3. 每次修改后运行相应检查，并保留失败原因。
4. 通过 Git 检查点查看变更；回滚前先预览，注意嵌套仓库边界。
5. 由责任开发者完成代码审查与合并决定。

Write 与交付工作流

1. 放入已核实的背景、数字、格式要求和目标读者。
2. 先定标题层级和信息缺口，再逐段写作。
3. 使用 AI Word 或去 AI 味写作等 Skills 做有边界的辅助修改。
4. 导出前检查源稿结构，导出后验证 DOCX、XLSX、PPTX、PDF 等产物格式。
5. 打开最终文件核对标题、表格、图片、分页和待确认项。

复核清单

• 人名、单位、日期、数字和引用是否与原始材料一致。
• 模型是否把推测写成事实，或把停止请求误判为任务完成。
• 交付文件是否真实可打开、格式正确，且没有将 HTML 或文本伪装为 Office/PDF 文件。
• 是否将 API Key、客户资料或未脱敏内容带入不应分享的上下文。