按项目恢复上下文，原文按需读取。
先保留当前目标、任务状态和来源引用。进入具体工作后，再读取需要的合同或产物正文。
这样能保留判断所需的线索，也让不相关项目的内容留在各自边界内。
个人项目 / AI 协作与能力积累系统
Grace OS让任务接得住，也交得清。
复杂工作往往要跨多次对话、不同工具和执行角色。如何让后续工作仍围绕同一个目标，保留已作出的判断，并明确什么才算完成？
我的工作：提出目标与产品要求、设计协作边界、作出架构取舍，并与 AI 协作实现和核对。
供应商补报一项费用后，继续修订经营方案。
把当前任务、必要材料和交付要求一起交接，下一轮工作能从已有判断继续。
- 01 / 恢复当前项目
先知道正在解决什么
- 目标
- 修订候选方案与客户沟通稿
- 需要的材料
- 更正邮件、成本表、上轮判断的来源引用
- 当前状态
- 待核费用，以及已确认的业务条件
- 02 / 写清执行交接
把任务写到可以验收
- 交付物
- 方案比较、收益初算、客户草稿
- 允许的动作
- 读取、分析、重算与草拟；外发需另有授权
- 完成条件
- 费用口径一致，变动有依据，待补项明确
- 03 / 核对并接续
让结果可以被检查
- 检查什么
- 计算、材料出处、相对上轮的变化
- 保留什么
- 当前方案、选择理由与未决事项
- 下一次工作
- 沿同一项目继续，按需读取相关材料
我作出的三个设计取舍
交接包含完成标准和行动权限。
一份交接需要说明目标、交付物、成功标准、禁止行动、完成条件和验证要求。执行端可以据此判断该做什么、做到哪一步。
当前交接校验会检查这些字段是否齐备，避免一句模糊的“继续处理”成为执行依据。
默认保持简洁，额外协作按缺口加入。
从强模型与工具开始。只有遇到具体问题，才增加专门角色或处理步骤；已有机制也要接受是否仍有增量价值的检查。
产品取舍同时考虑结果质量，以及使用者需要承担多少协调工作。
已形成的产物
当前项目的必要信息
已有代码投影项目合同、任务状态、审批与证据引用。相应用例检查引用得到保留、正文不被预读、无关内容不进入当前上下文。
可检查的交接约定
已有代码校验目标、产物与完成要求。配套用例检查上下文读取不改变任务状态，以及插件的调用边界。
查看实现与验证范围
本页依据现行架构、上下文插件代码及配套测试用例整理。展示的是项目接续这一设计切面与对应局部实现；上方报价更新是结构示意，不是一次 Grace OS 端到端运行记录。
这次作品集编辑没有重新运行全系统测试或验证线上经营效果。产品目标与要求由本人提出，架构取舍、代码实现与检查由人与 AI 协作完成。